Huny's Dev Blog
huny.dev

.NET 11 출시와 8·9 지원 종료: 배포 런타임 점검하기

11월 10일 .NET 11 출시와 8·9 지원 종료에 맞춰 SDK·실행 런타임을 분리해 확인한다. .NET 10·11의 같은 지원 종료일, 자체 포함 배포·컨테이너·IIS의 갱신 경계와 전환 검증 순서를 정리한다.

Hun Jang
Hun Jang Nov 11, 2026

개발 도구, 배포 패키지, 운영 서버의 런타임을 따로 확인하는 과정을 표현한 AI 생성 편집 이미지다. 실제 제품 화면이나 시스템 구성도가 아니다.

Microsoft가 2026년 11월 10일 .NET 11을 정식 출시했다. 같은 날 .NET 8과 .NET 9의 지원도 종료됐다. 기존 서비스는 계속 실행될 수 있지만, 지원 종료 뒤에는 해당 버전의 새 보안 업데이트와 기술 지원을 받을 수 없다. 운영 중인 API·배치·Windows 서비스가 있다면 새 기능 검토와 함께 실제로 배포된 런타임의 버전부터 확인할 시점이다. 출시 발표, 8·9 지원 종료 공지

개발 PC에서 dotnet --version이 11로 나온다고 운영 서비스까지 전환된 것은 아니다. 빌드에 쓰는 SDK, 프로젝트의 대상 프레임워크, 배포 파일에 포함되거나 서버에서 선택되는 런타임을 각각 확인해야 한다.

1. .NET 10과 11의 지원 종료일은 현재 같다

11월 10일 갱신된 공식 지원 정책은 다음과 같다.

버전
지원 구분
최신 런타임 패치
지원 종료일
.NET 8
LTS, 지원 종료
8.0.34
2026-11-10
.NET 9
STS, 지원 종료
9.0.23
2026-11-10
.NET 10
LTS, 지원 중
10.0.15
2028-11-14
.NET 11
STS, 지원 중
11.0.0
2028-11-14

LTS는 출시부터 3년, STS는 2년 지원이다. .NET 10은 1년 먼저 출시됐으므로 지금 선택하면 10과 11의 남은 지원 종료일이 같다. 위 버전은 런타임 패치 번호이며 SDK 버전 번호와 혼동하면 안 된다. 지원 기간 중에도 최신 서비스 패치를 유지해야 한다. 공식 지원 정책

선택은 서비스 조건에 맞춘다. 아래는 공식 지원 기간을 바탕으로 한 실무 판단 기준이다.

  • 이미 검증한 라이브러리·호스팅 조합이 .NET 10이라면, 10으로 지원 종료 문제를 먼저 해결할 수 있다.
  • C# 15, .NET 11의 API나 도구 개선이 실제로 필요하고 의존성·운영 환경도 준비됐다면 11을 검증한다.
  • 공급업체가 만든 프로그램이라 소스를 고칠 수 없다면 지원되는 런타임을 사용한 새 배포판을 요청한다. 설치된 이전 런타임부터 지우면 기존 프로그램이 실행되지 않을 수 있다.

마지막 항목은 Microsoft의 지원 종료 안내와도 일치한다. 이 글의 범위는 현대 .NET 8·9·10·11이며, Windows의 .NET Framework 4.x 지원 수명과는 별개다. 지원 종료 안내, 플랫폼별 지원 정책

2. SDK 목록과 서비스 실행 버전을 분리한다

먼저 개발 PC와 CI에서 다음 읽기 전용 명령으로 상태를 기록한다. 운영 서버에 SDK가 없다면 --version이 실패할 수 있으므로 SDK 설치를 점검 목적으로 강제하지 않는다.

  • --version: 현재 위치에서 CLI가 선택한 SDK.
  • --list-sdks: 설치된 SDK 목록.
  • --list-runtimes: 해당 dotnet이 찾은 설치 런타임 목록.
  • --info: 설치·운영체제·아키텍처 등 추가 환경 정보.

--list-runtimes는 호출한 dotnet의 아키텍처에 영향을 받는다. x64 명령 결과만 보고 x86 프로세스까지 확인했다고 판단하지 않는다. 서비스 계정, 실행 경로, 컨테이너가 다르면 조사 대상도 분리한다. CLI 옵션, 설치 버전 확인

저장소에서는 global.json과 프로젝트의 TargetFramework 또는 TargetFrameworks를 함께 본다. global.json은 SDK 선택을 제어하며 앱의 대상 런타임을 바꾸지 않는다. 새 SDK를 설치했어도 프로젝트가 net8.0이면 그대로 이전 프레임워크를 대상으로 빌드할 수 있다. global.json 문서

배포 폴더의 *.runtimeconfig.json도 확인한다. 이 파일은 요구 프레임워크와 런타임 설정을 이해하는 자료지만 현재 실행 중인 프로세스가 어떤 패치를 로드했는지의 증거는 아니다. 기본 런타임 선택 규칙이 새 메이저 버전으로 자동 전환해 준다고 가정해서도 안 된다. 버전 선택 규칙

코드를 관리할 수 있다면 아래처럼 앱 시작 시 내부 로그에 실행 런타임을 기록하는 방법이 있다. 해당 서비스 프로세스 안에서 기록해야 의미가 있으며, 확인용 정보를 공개 HTTP 엔드포인트에 노출할 필요는 없다.

이 속성은 현재 실행 중인 .NET 구현을 설명하며 보통 버전도 포함한다. 운영 점검에서는 이 기록을 배포 식별자·시각과 연결하고, ASP.NET Core 구성과 배포 의존성 목록도 함께 확인한다. FrameworkDescription API

3. 배포 방식에 따라 갱신할 위치가 다르다

프레임워크 종속 배포는 실행 환경에 설치된 호환 런타임을 사용한다. 자체 포함 배포는 앱 배포물에 런타임을 포함한다. 후자는 서버에 새 런타임을 설치해도 기존 배포물 안의 런타임이 바뀌지 않으므로 앱을 다시 게시하고 배포해야 한다. 배포 방식 문서

확인 대상
갱신·검증할 위치
프레임워크 종속 서비스
프로젝트 대상, 서버의 호환 런타임, 재시작 후 실제 실행 버전
자체 포함 서비스
게시에 사용한 도구·런타임 팩, 새 배포물, 교체 후 실행 버전
컨테이너 서비스
빌드 단계와 최종 실행 단계의 이미지, 새 이미지 식별자, 교체된 실행 인스턴스
IIS의 ASP.NET Core 서비스
앱 배포물, 필요한 런타임, ASP.NET Core Module과 Hosting Bundle 구성

위 표는 배포 특성을 바탕으로 정리한 운영 점검 항목이다. 단일 실행 파일로 배포됐다는 이유만으로 자체 포함 방식이라고 단정하지 않는다. 단일 파일 배포는 프레임워크 종속·자체 포함 양쪽에 사용할 수 있다. 배포 방식 문서

컨테이너에서는 Dockerfile의 SDK 빌드 단계만 올리고 마지막 런타임 이미지는 이전 버전으로 남기지 않았는지 본다. 호스트의 .NET 업데이트가 기존 컨테이너 이미지를 교체해 주지도 않는다. 새 이미지를 만들고 실제 배포 대상이 그 이미지를 사용하도록 전환했는지 확인한다. 공식 컨테이너 가이드

IIS에서는 Hosting Bundle이 .NET 런타임과 ASP.NET Core Module을 설치한다. IIS보다 먼저 Bundle을 설치했다면 복구 설치가 필요하며, 설치 뒤 수동 IIS 재시작이 필요할 수도 있다. 전체 IIS 재시작은 다른 사이트에도 영향을 줄 수 있으므로 점검 명령과 섞지 말고 승인된 점검 시간에 수행한다. Hosting Bundle 문서

4. .NET 11 신기능과 프리뷰 기능을 구분한다

이번 릴리스에는 C# 15의 union types와 closed hierarchies, 기본 Native AOT CLI host, 재사용되는 MSBuild server 등 언어·도구 개선이 포함됐다. 다만 앱 코드의 Runtime Async 전환은 여전히 프리뷰다. .NET 11 정식 출시를 이유로 모든 실험 옵션까지 한꺼번에 켤 필요는 없다. 출시 발표

AI 기능도 도입 조건을 나눠 본다. SDK에는 MCP 서버 템플릿이 추가됐지만, Microsoft.Extensions.AI는 NuGet 패키지로 제공되므로 AI 추상화를 쓰기 위해 모든 앱을 반드시 .NET 11로 바꿔야 하는 것은 아니다. 실제 패키지의 대상 프레임워크와 의존성을 확인한다. 출시 발표의 AI 라이브러리·도구 설명

업그레이드 테스트에서는 컴파일 성공 외에 동작 변화도 확인한다. .NET 11의 공식 호환성 목록에는 압축 파일 검사, 구성 공급자, 백그라운드 서비스 예외 처리 등 여러 영역의 변경이 나뉘어 있다. 사용하는 기능을 중심으로 목록을 읽고, 8에서 11로 이동한다면 중간 버전의 변경도 검토한다. 11 호환성 변경 목록, 업그레이드 안내

5. 전환 완료 기준을 배포 결과로 정한다

다음은 이 글에서 제안하는 최소 검증 순서다.

  1. 서비스별 현황을 남긴다. 대상 프레임워크, 배포 방식, OS·아키텍처, 배포 위치, 담당자를 기록한다.
  1. 목표 버전을 정한다. 10 또는 11의 지원 조건과 필요한 패키지·호스팅 지원을 확인한다.
  1. 빌드 경로를 맞춘다. SDK 선택, 프로젝트 대상, CI 이미지, 게시 설정을 함께 변경한다.
  1. 스테이징에서 실제 배포물을 검증한다. 인증, DB 연결, JSON 계약, 파일 처리, 예약·백그라운드 작업을 실행한다.
  1. 새 프로세스와 이미지를 확인한다. 배포 성공 표시뿐 아니라 실행 런타임·이미지 식별자와 오류율을 확인한다.
  1. 이전 환경을 정리한다. 의존 서비스와 복구 계획을 확인한 뒤 불필요한 이전 런타임을 제거한다. 이전 배포물로의 긴급 복구는 장애 대응책일 뿐 지원 종료를 해결하지는 못한다.

이 글의 명령과 코드는 공식 문서에 근거한 점검 예시다. 특정 운영 시스템의 업그레이드나 서비스 실행 검증을 수행한 결과는 아니다.

정리

이번에는 .NET 11 출시와 .NET 8·9 지원 종료가 겹쳤다. 먼저 운영 중인 서비스가 어떤 런타임을 사용하고 있는지 확인하고, 검증 가능한 목표 버전으로 전환하자. SDK 설치부터 새 배포물 생성, 실행 인스턴스 교체, 재시작 후 확인까지 끝나야 전환 여부를 판단할 수 있다.

확인 기준일: November 11, 2026 (한국 시간, 공식 출시·지원 종료일은 11월 10일)

추천 글