닷넷 11 프리뷰에서 지켜볼 만한 것들

이 글은 2026년 7월 7일 기준으로 정리한 기록입니다. .NET 11은 아직 프리뷰 단계에 있고, 현재 공개 자료 기준으로는 Preview 5까지 나와 있습니다. 정식 릴리스는 2026년 11월로 안내되어 있으니, 지금 보이는 기능들이 모두 그대로 고정된다고 보기는 어렵습니다.

그래도 프리뷰를 살펴보는 일은 의미가 있습니다. 당장 운영 중인 서비스를 옮기기 위해서라기보다, 앞으로 닷넷 생태계가 어떤 방향으로 움직이는지 미리 감을 잡을 수 있기 때문입니다. 저는 21년차 닷넷 개발자로 일하면서, 요즘은 웹소설 집필 보조 서비스 메리톡톡을 만들고 운영하는 흐름도 함께 고민하고 있습니다. 그래서 새 버전을 볼 때도 “멋진 기능이 나왔는가”보다 “혼자 오래 운영하는 서비스에 어떤 영향을 줄까”를 먼저 보게 됩니다.

프리뷰는 정답보다 방향을 보는 단계입니다
.NET 11은 LTS가 아니라 STS, 즉 비교적 짧은 지원 주기를 가진 버전입니다. 안정성을 우선해야 하는 서비스라면 .NET 10 같은 LTS 버전을 중심에 두는 판단이 더 현실적일 수 있습니다. 다만 STS 버전은 그 시점의 실험과 개선 방향을 빠르게 보여줍니다.

그래서 이번 .NET 11 프리뷰도 “바로 갈아타야 할 버전”이라기보다 “다음 구조를 준비할 때 체크해둘 버전”에 가깝게 보고 있습니다. 특히 개인 서비스나 작은 제품을 운영하는 입장에서는 새 기능 자체보다 업그레이드 비용, 운영 안정성, 배포 흐름, 관찰 가능성이 더 중요합니다.

런타임과 JIT 개선은 조용하지만 중요합니다
.NET 11에서 먼저 눈에 들어오는 부분은 런타임과 JIT 개선입니다. 공식 문서에서는 Runtime Async, JIT 최적화, 하드웨어 요구사항 갱신 같은 내용을 언급하고 있습니다. 이런 내용은 겉으로 보기에는 화려하지 않습니다. 하지만 실제 서비스를 운영하다 보면 이런 낮은 층의 개선이 누적되어 체감되는 경우가 많습니다.

예를 들어 비동기 처리의 오버헤드가 줄고, 스택 트레이스가 더 읽기 쉬워진다면 장애를 추적하는 시간이 줄어들 수 있습니다. JIT 최적화가 좋아지는 것도 마찬가지입니다. 한 번에 큰 변화를 느끼기 어렵더라도, 서버 비용이나 응답 시간에 민감한 서비스에서는 이런 변화가 결국 운영 부담과 연결됩니다.

저처럼 혼자 서비스를 만들고 보는 사람에게 성능 개선은 단순히 “더 빠르다”의 문제가 아닙니다. 문제가 생겼을 때 원인을 찾기 쉬운가, 작은 서버로도 버틸 수 있는가, 배포 후에 예상하지 못한 부담이 늘어나지 않는가의 문제입니다. 그래서 런타임 개선은 늘 조용히 살펴보게 됩니다.

라이브러리 변화는 일상적인 코드의 마찰을 줄입니다
.NET 11의 라이브러리 쪽에서는 Systehttp://m.Text.Json, LINQ, 압축, 암호화, Process 관련 API 등이 눈에 띕니다. 특히 JSON Lines 직렬화, LINQ의 FullJoin, X25519 키 교환, Random의 제네릭 숫자 API 같은 항목이 Preview 5에서 소개되었습니다.

이런 기능들은 발표 자료에서 크게 보이지 않을 수 있지만, 실제 코드에서는 자주 마주치는 작은 불편을 줄여줍니다. 예를 들어 로그나 이벤트 데이터를 한 줄 단위 JSON으로 다루는 경우가 많아지고 있습니다. AI 도구나 작업 큐, 분석 파이프라인과 연결할 때도 이런 형식은 자주 등장합니다. Systehttp://m.Text.Json에서 관련 지원이 늘어나는 흐름은 개인적으로 반갑게 느껴졌습니다.

LINQ의 FullJoin도 비슷합니다. 데이터 비교나 동기화 작업을 하다 보면 양쪽에 모두 있는 값뿐 아니라 한쪽에만 있는 값까지 함께 봐야 할 때가 있습니다. 그동안은 직접 구현하거나 우회하는 코드가 필요했는데, 이런 기능이 표준 라이브러리 안으로 들어오면 코드의 의도가 조금 더 분명해집니다.

SDK 개선은 작은 프로젝트일수록 체감될 수 있습니다
이번 프리뷰에서 SDK 쪽 변화도 살펴볼 만합니다. Linux와 macOS의 SDK 설치 크기를 줄이기 위한 작업, dotnet sln 명령의 solution filter 지원, 파일 기반 앱에서 여러 C# 파일을 포함하는 기능, dotnet run에서 환경 변수를 바로 넘기는 옵션 등이 소개되어 있습니다.

이런 변화는 대규모 팀보다 오히려 작은 프로젝트에서 더 반가울 때가 있습니다. 간단한 실험을 만들고, 확인하고, 버리고, 다시 정리하는 과정이 빨라지기 때문입니다. 개인 서비스나 내부 도구를 만들 때는 거창한 프로젝트 구조보다 빠르게 검증할 수 있는 흐름이 중요할 때가 많습니다.

특히 파일 기반 앱이 조금씩 확장되는 흐름은 흥미롭습니다. C#이 꼭 큰 솔루션과 프로젝트 파일 안에서만 시작해야 하는 언어가 아니라, 작은 스크립트나 실험 코드의 자리까지 넓히려는 방향으로 보입니다. 닷넷 개발자로 오래 일해온 입장에서는 이 변화가 꽤 상징적으로 느껴집니다.

C# 15와 union 관련 흐름도 지켜보고 있습니다
.NET 11과 함께 언급되는 C# 15에서는 collection expression arguments와 union types가 주요 항목으로 안내되어 있습니다. 특히 union 관련 흐름은 앞으로 도메인 모델을 표현하는 방식에 영향을 줄 수 있어 보입니다.

서비스를 만들다 보면 성공과 실패, 여러 상태, 서로 다른 결과 타입을 표현해야 하는 일이 많습니다. 지금도 record, enum, interface, discriminated union에 가까운 패턴을 조합해 표현할 수는 있습니다. 다만 언어 차원에서 이런 표현을 더 자연스럽게 지원하게 되면, 코드가 조금 더 읽기 쉬워질 가능성이 있습니다.

물론 프리뷰 단계의 언어 기능은 조심해서 봐야 합니다. 당장 운영 코드에 넣기보다는, 어떤 문제를 해결하려는 방향인지 살펴보는 정도가 적당하다고 생각합니다. 그래도 C#이 단순히 문법을 늘리는 것이 아니라, 복잡한 상태를 더 안전하게 표현하는 방향으로 움직이는 점은 계속 지켜볼 만합니다.

ASP.NET Core와 Blazor는 운영 관점에서 확인해야 합니다
Preview 5에서는 ASP.NET Core 쪽에서도 Blazor SSR의 클라이언트 사이드 검증, QuickGrid의 비대화형 환경 지원, Blazor WebAssembly Gateway, 세션 기반 파라미터 공급 같은 항목이 소개되었습니다.

저는 Blazor를 볼 때마다 “기술적으로 가능한가”보다 “혼자 운영하는 서비스에서 부담이 적은가”를 먼저 생각하게 됩니다. 화면과 서버의 경계가 복잡해질수록 개발 경험은 편해질 수 있지만, 배포와 장애 추적은 오히려 어려워질 수도 있습니다. 반대로 잘 맞는 구조를 찾으면 작은 팀이나 1인 개발자에게는 꽤 생산적인 선택지가 될 수 있습니다.

그래서 .NET 11의 ASP.NET Core 변화는 기능 목록만 보기보다, 실제 운영 흐름에서 얼마나 단순하게 가져갈 수 있을지를 기준으로 보는 편이 좋겠습니다. 새 기능이 많아지는 것보다, 기존 구조의 빈틈이 줄어드는지가 더 중요할 수 있습니다.

EF Core 변화는 데이터 작업의 안정성과 연결됩니다
EF Core 쪽에서는 file-based apps 지원, SQL Server 2022 호환성 기본값, 비동기 쿼리가 동기적으로 실행될 때의 경고, 더 깔끔한 SQL 생성 등이 Preview 5 항목으로 소개되었습니다.

개인적으로는 EF1004처럼 잘못된 비동기 사용을 알려주는 방향이 반갑습니다. 작은 서비스에서는 성능 문제가 아주 큰 트래픽에서만 생기는 것이 아닙니다. 몇 개의 잘못된 쿼리, 예상보다 오래 잡히는 연결, 추적하기 어려운 동기 실행이 쌓이면서 문제가 생기기도 합니다.

데이터 계층은 서비스의 중심에 가깝습니다. 그래서 EF Core의 변화는 새 문법보다 “실수하기 어려워지는가”라는 관점으로 보게 됩니다. 혼자 운영하는 서비스일수록 코드 리뷰를 해줄 사람이 부족하기 때문에, 도구가 위험한 패턴을 빨리 알려주는 것이 중요합니다.

지금 당장 해야 할 일은 많지 않습니다
.NET 11 프리뷰를 보면서도, 당장 모든 프로젝트를 올려야겠다는 생각은 들지 않습니다. 오히려 지금은 몇 가지를 차분히 확인하는 정도가 맞다고 봅니다.

첫째, 현재 운영 중인 프로젝트가 어떤 .NET 버전에 묶여 있는지 확인해야 합니다. 둘째, 외부 패키지와 배포 환경이 새 버전을 따라갈 수 있는지 살펴봐야 합니다. 셋째, 성능이나 SDK 개선 중에서 실제로 내 작업 흐름을 줄여줄 부분이 있는지 작게 실험해보면 좋겠습니다.

프리뷰는 기대를 키우는 시기이기도 하지만, 동시에 거리를 두고 보는 시기이기도 합니다. 특히 서비스를 운영하는 입장에서는 새 기능보다 안정적인 전환 경로가 더 중요합니다.

마무리
.NET 11 프리뷰에서 제가 지켜보는 것은 거창한 한 가지 기능이 아닙니다. 런타임의 조용한 개선, 일상적인 라이브러리 API의 정리, 작은 실험을 돕는 SDK 변화, 그리고 C#이 상태와 결과를 더 분명하게 표현하려는 흐름입니다.

이런 변화들은 당장 눈에 띄는 성공담을 만들어주지는 않습니다. 하지만 오래 운영할 서비스를 만들 때는 이런 조용한 개선들이 꽤 중요합니다. 코드를 조금 덜 복잡하게 만들고, 장애를 조금 더 빨리 찾게 해주고, 작은 실험을 조금 더 가볍게 시작하게 해주기 때문입니다.

아직 .NET 11은 완성된 결론이 아니라 진행 중인 버전입니다. 그래서 이 글도 확정된 평가라기보다, 앞으로 몇 달 동안 무엇을 지켜볼지 정리해둔 기록에 가깝습니다. 정식 릴리스가 가까워지면, 실제 프로젝트에 어떤 기준으로 적용할 수 있을지도 다시 정리해보려 합니다.