.NET 11 정식 출시 전 점검 — 실서비스 마이그레이션 체크리스트

달력을 보니 .NET 11 정식 출시까지 세 달 남짓 남았습니다. 예년대로라면 2026년 11월에 GA가 나올 예정이고, 지금은 프리뷰 단계입니다. 저는 이 시기가 되면 늘 같은 고민을 반복합니다. 나오자마자 올릴 것인가, 아니면 몇 달 지켜볼 것인가.

회사에서라면 이 결정을 여럿이 나눠 지지만, 메리톡톡처럼 혼자 만들고 혼자 운영하는 서비스에서는 결정도 수습도 제 몫입니다. 그래서 저는 버전을 올리는 일 자체보다 올리기 전에 무엇을 확인해두었는가를 더 중요하게 봅니다. 확인 목록이 부실하면 올린 다음 날 새벽에 로그를 뒤지게 됩니다.

이 글에서는 GA 전에 미리 해둘 수 있는 점검을 순서대로 적어보겠습니다. 아래 내용 중 프리뷰 기능에 대한 부분은 현재 프리뷰 기준이며 GA까지 바뀔 수 있습니다. 최종 확인은 출시 시점의 공식 문서로 하시는 편이 안전합니다.

STS라는 사실이 판단에 미치는 영향

.NET 11은 STS(Standard Term Support) 릴리스입니다. 지원 기간이 2년이라는 뜻입니다. 반면 .NET 10은 LTS라서 더 긴 기간 지원을 받습니다. 이 차이가 1인 운영자에게는 생각보다 크게 작동합니다.

• 업그레이드 주기가 강제됩니다: STS를 택하면 2년 안에 다음 버전으로 옮겨야 합니다. 그 작업을 할 시간이 확보되는지가 먼저입니다.

• 새 기능의 값이 그만큼 커야 합니다: 압축이나 관측처럼 지금 당장 아쉬운 부분이 있어서 올린다면 명분이 섭니다. 막연히 최신이라서 올리는 것은 비용만 늘립니다.

• 보안 패치 창구가 닫히는 시점을 미리 적어둡니다: 저는 캘린더에 지원 종료 예정 월을 미리 넣어둡니다. 그 달이 다가오면 자연스럽게 다음 계획을 세우게 됩니다.

제 기준은 이렇습니다. 서비스의 핵심 트래픽을 받는 프로젝트는 LTS에 두고, 새 기능을 먼저 써보고 싶은 부속 프로젝트를 STS로 올려 감을 익히는 방식입니다. 혼자 하는 입장에서는 전부를 한 번에 옮기는 것보다 이쪽이 회복이 쉽습니다.

GA 전에 끝내둘 사전 점검

아래 항목은 프리뷰 상태에서도 대부분 미리 확인이 가능합니다. 하나씩 지워나가는 방식으로 쓰시면 됩니다.

점검 항목확인 방법막혔을 때

대상 프레임워크프로젝트 파일의 TargetFramework를 새 값으로 바꿔 빌드브랜치를 따로 파고 원본은 그대로 둡니다
NuGet 패키지 호환주요 의존성이 새 버전을 지원하는지 저장소와 릴리스 노트 확인대체 패키지 후보를 미리 찾아둡니다
분석기 경고경고를 오류로 올려 빌드해 새로 생긴 항목 파악사용 중단 API는 GA 전에 미리 교체합니다
컨테이너 베이스 이미지런타임과 SDK 이미지 태그가 준비됐는지 확인태그가 없으면 GA까지 기다립니다
CI 런타임빌드 서버의 SDK 설치 단계에 새 버전 추가매트릭스 빌드로 두 버전을 함께 돌립니다
배포 파이프라인배포 대상 서버나 호스팅의 지원 여부 확인호스팅이 늦으면 일정 자체를 미룹니다
런타임 동작통합 테스트와 주요 시나리오 수동 확인차이를 기록해두고 원인을 좁힙니다

이 중에서 실제로 제 발목을 자주 잡은 것은 세 번째와 네 번째였습니다. 코드는 잘 도는데 베이스 이미지 태그가 아직 없어서 배포가 안 되거나, 분석기가 새로 뱉는 경고가 수십 개라 어디부터 손대야 할지 막막해지는 식입니다. 둘 다 미리 알면 일정에 반영할 수 있고, 모르면 배포일에 알게 됩니다.

패키지 호환은 목록부터 만듭니다

저는 직접 참조하는 패키지만 표로 정리합니다. 이름, 현재 버전, 새 버전 지원 여부, 대체안 네 칸이면 충분합니다. 전이 의존성까지 다 보려고 하면 끝이 없고, 대부분의 문제는 직접 참조하는 쪽에서 먼저 드러납니다.

분석기 경고는 GA 전에 줄여둡니다

버전을 올리면 새 경고가 늘어납니다. 이걸 업그레이드 당일에 처리하려 하면 코드 변경과 런타임 변경이 뒤섞여 원인 판단이 어려워집니다. 그래서 저는 경고 정리는 현재 버전에서 미리 끝내는 편입니다. 그러면 업그레이드 커밋에는 프레임워크 변경만 남습니다.

프리뷰로 미리 검증하는 방법

운영 환경을 건드리지 않고도 검증할 수 있는 방법이 있습니다. 제가 쓰는 순서는 이렇습니다.

• 별도 브랜치와 별도 디렉터리: 프리뷰 SDK를 설치하되, 기존 프로젝트의 빌드가 영향을 받지 않도록 SDK 버전을 고정하는 설정 파일을 둡니다.

• 가장 작은 프로젝트부터: 배치 작업이나 내부 도구처럼 사용자가 없는 것부터 올려봅니다. 여기서 걸리는 문제가 본 서비스에서도 대부분 똑같이 걸립니다.

• 테스트를 두 버전으로 돌립니다: CI에서 기존 버전과 새 버전을 함께 돌려두면 차이가 생긴 시점을 바로 알 수 있습니다.

• 성능은 GA 이후에 다시 봅니다: 프리뷰 빌드의 수치는 최적화가 덜 된 상태일 수 있어서, 이 단계에서는 동작 정상 여부만 봅니다.

프리뷰에서 확인한 결과를 짧게 기록해두면 GA 때 그대로 다시 씁니다. 저는 "무엇을 바꿨고, 무엇이 깨졌고, 어떻게 고쳤는가" 세 줄만 남깁니다. 몇 달 지나면 기억이 사라지기 때문입니다.

롤백 계획을 먼저 세웁니다

혼자 운영하는 서비스에서 가장 무서운 것은 되돌릴 방법이 없는 배포입니다. 저는 올리기 전에 이 네 가지를 확인합니다.

• 되돌릴 아티팩트가 남아 있는가: 직전 버전의 이미지나 배포 패키지를 지우지 않고 보관합니다.

• 데이터베이스 변경이 섞였는가: 프레임워크 업그레이드와 스키마 변경은 따로 배포합니다. 같이 올리면 롤백이 불가능해집니다.

• 되돌리는 데 몇 분이 걸리는가: 한 번 연습해서 실제 소요 시간을 재둡니다. 새벽에 처음 해보는 일이 되면 안 됩니다.

• 어떤 신호를 보고 되돌릴 것인가: 오류율, 응답 시간, 특정 기능의 실패 같은 기준을 미리 정해둡니다. 기준이 없으면 판단이 늦어집니다.

배포 시각도 중요합니다. 저는 사용자가 가장 적은 시간대를 고르고, 그날은 다른 일정을 잡지 않습니다. 올리고 나서 최소 두어 시간은 지표를 볼 수 있는 상태여야 마음이 편합니다.

마치며

.NET 11은 STS 릴리스이고 GA는 2026년 11월 예정입니다. 지원 기간이 2년이라는 점 때문에, 올릴지 말지는 새 기능의 값과 다음 업그레이드에 쓸 시간을 같이 놓고 봐야 합니다. 사전 점검은 프레임워크 지정, 패키지 호환, 분석기 경고, 컨테이너 이미지, CI 런타임, 배포 파이프라인 순으로 훑으면 대체로 빠짐이 없습니다.

오늘 할 수 있는 한 가지는 직접 참조하는 NuGet 패키지 목록을 뽑아 표로 만들어두는 일입니다. 그 표를 채우다 보면 올려도 되는 상태인지, 아직 기다려야 하는지가 대체로 드러납니다. 판단이 필요한 건 그다음입니다.