.NET 8·9 지원 종료 전에 .NET 10 LTS로 옮길지 판단하는 기준

.NET 버전을 올릴 때는 새 기능 목록보다 현재 운영 중인 버전의 지원 종료 시점을 먼저 확인하는 편이 실용적입니다. Microsoft Lifecycle에 따르면 .NET 8 LTS와 .NET 9는 2026년 11월 11일(미국 태평양 시간 기준)에 지원이 종료될 예정입니다. 그 시점이 가까워진 지금 .NET 10으로 옮길지, 서비스별로 순서를 나눌지 검토할 필요가 있습니다.

이 글은 프로젝트를 실제로 마이그레이션해 본 결과가 아니라, 공식 지원 일정과 실서비스 전환 때 확인할 항목을 정리한 점검표입니다. 2026년 10월 18일 Microsoft Lifecycle 페이지를 기준으로 확인했으며, 실제 작업 전에는 대상 OS·런타임·프레임워크 지원표를 다시 확인하십시오. Microsoft .NET 수명주기 표에서 .NET 10은 2028년 11월까지, .NET 8 LTS와 .NET 9는 2026년 11월까지 지원되는 것으로 표시됩니다.

지원 종료 날짜는 운영 일정으로 바꿉니다

지원 종료일은 프로젝트 계획에 적어 두는 것으로 끝나지 않습니다. 프로덕션의 런타임이 어떤 버전인지, 서비스가 컨테이너 이미지나 앱 서비스 스택에 묶여 있는지, 배포가 자동으로 최신 패치를 받는지 확인해야 합니다. 개발 PC가 .NET 10을 설치했어도 배포 환경이 .NET 8을 실행할 수 있습니다.

먼저 서비스별로 현재 target framework, 런타임 버전, 운영체제, 배포 이미지, 빌드 에이전트를 기록합니다. ASP.NET Core와 EF Core도 .NET의 지원 일정과 연결되므로 애플리케이션만 바꾸고 런타임이나 데이터 공급자가 그대로 남지 않도록 구성 요소를 함께 살펴야 합니다. 지원 종료 전날을 전환일로 잡기보다 검증과 복구 기간을 포함해 내부 마감일을 정하는 편이 좋습니다.

.NET 10 LTS가 적합한지 서비스 단위로 판단합니다

.NET 10은 LTS 릴리스로 2028년 11월 15일까지 지원 일정이 표시되어 있습니다. LTS라는 이유만으로 모든 서비스가 즉시 옮겨야 하는 것은 아닙니다. 사용하는 라이브러리와 호스팅 환경, 빌드 도구가 해당 버전을 지원하는지, 변경으로 얻을 운영상 이점이 무엇인지 확인하십시오.

• 의존성: NuGet 패키지, 데이터베이스 드라이버, 인증·로깅 구성요소가 대상 버전에서 지원되는지 확인합니다.
• 빌드와 배포: CI 이미지, SDK 선택, 컨테이너 베이스 이미지, 서버 런타임을 같이 점검합니다.
• 외부 계약: 직렬화 결과, API 응답, 인증 흐름, 파일 처리처럼 다른 시스템과 맞닿은 동작을 목록화합니다.
• 유지 계획: 다음 업그레이드까지 확보할 시간과 담당자를 정합니다.

서비스가 작고 의존성이 단순하면 전환을 빠르게 검토할 수 있습니다. 오래된 패키지나 운영체제 제약이 있으면 우선 지원 종료 위험을 정리하고 단계적으로 변경하는 것이 낫습니다. 예상보다 큰 라이브러리 변경이 필요하다면 런타임 업그레이드와 기능 개편을 한꺼번에 묶지 마십시오.

검증은 성공 시나리오와 실패 시나리오를 함께 봅니다

컴파일 성공은 전체 마이그레이션의 일부일 뿐입니다. 단위·통합 테스트, 시작과 종료, 인증, 백그라운드 작업, 시간 제한, 로깅과 메트릭, 데이터베이스 연결을 점검합니다. 배포 파이프라인이 런타임을 정확히 선택하는지 확인하고, 운영 환경과 비슷한 스테이징에서 주요 사용자 흐름을 시험합니다.

성공 조건뿐 아니라 실패했을 때의 경로도 준비해야 합니다. 배포 후 오류율이나 시작 실패가 기준을 넘으면 이전 이미지와 설정으로 돌아가는 절차가 있는지 확인하십시오. 데이터베이스 스키마 변경이 포함되면 애플리케이션 바이너리만 롤백할 수 있는지 별도로 점검합니다. 롤백할 수 없으면 배포 전환을 더 작은 단계로 나누어야 합니다.

업그레이드 이후의 지원 책임을 남깁니다

프레임워크 지원 일정은 변할 수 있고, 지원 상태는 패치 수준이나 플랫폼 조건에 따라 달라질 수 있습니다. 배포 날짜, SDK와 런타임 버전, 테스트 범위, 미해결 경고를 기록하고, 정기적으로 지원 일정을 검토하는 담당자를 두십시오. 새로운 서비스나 인수한 프로젝트가 생기면 같은 원장에 추가합니다.

오래된 글의 수명주기 정보를 복사해 두면 현재 상태가 어긋날 수 있습니다. 공식 지원 표를 기준 문서로 연결하고 확인 날짜를 남겨 두면 다음 점검에서 무엇이 바뀌었는지 비교할 수 있습니다. 날짜가 가까워졌다면 공급자 지원과 조직의 배포 승인 절차도 확인해야 합니다.

버전 전환은 새 기능 개발 계획과 분리하면 추적하기 쉽습니다. 운영 로그에서 시작 실패, 연결 실패, 직렬화 오류처럼 핵심 흐름을 확인할 지표를 선택하고, 배포 직후 관찰할 담당자를 정합니다. 일정이 밀릴 때는 기능 개발과 마이그레이션 중 무엇이 먼저인지 정해 두어 지원 종료 임박 후 급하게 배포하는 상황을 줄입니다.

지원 종료 전에 전환할 수 없는 서비스가 있다면 그대로 방치하지 말고 예외 사유와 보완 조치를 기록하십시오. 외부 지원 계약, 격리 수준, 공개 노출, 데이터 민감도 등을 검토하고 책임자가 승인해야 합니다. 이 기록은 위험을 없애 주지는 않지만, 언제까지 어떤 조건으로 예외를 유지할지 다시 판단할 기준이 됩니다.

Microsoft 표의 날짜는 태평양 시간으로 표시됩니다. 한국의 운영 일정으로 변환할 때는 시차와 배포 승인 가능 시간을 고려하십시오. 날짜를 내부 문서에 옮길 때 원문 시간대와 확인일을 함께 적으면 자정 전후의 혼선을 줄일 수 있습니다. 수명주기 페이지가 갱신되었는지도 마이그레이션 직전에 다시 확인합니다.

검토 대상에는 개발 환경에만 남아 있는 오래된 SDK도 포함하십시오. 로컬 재현과 CI 빌드가 서로 다른 SDK를 선택하면 개발 중 통과한 변경이 배포 파이프라인에서 실패할 수 있습니다. 전역 설치 버전에 기대지 말고 저장소에서 사용할 SDK와 런타임을 명시하는 것이 좋습니다.

마치며

.NET 8과 .NET 9 지원 종료는 2026년 11월로 표시되어 있고, .NET 10 LTS는 더 긴 지원 기간을 제공합니다. 그러나 전환 시점은 서비스의 의존성, 운영 창구, 회귀 검증과 복구 가능성에 따라 달라집니다. 다음 배포 계획에 현재 런타임 확인과 롤백 조건을 한 항목으로 넣어 지원 종료를 운영 가능한 일정으로 바꿔 보십시오.