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

이 글은 2026년 7월 7일 기준으로 정리한 기록입니다. .NET 11은 아직 프리뷰 단계에 있고, 현재 공개 자료 기준으로는 Preview 5까지 나와 있습니다. 정식 릴리스는 2026년 11월로 안내되어 있으니, 지금 보이는 기능들이 모두 그대로 고정된다고 보기는 어렵습니다. 그래도 프리뷰를 살펴보는 일은 의미가 있습니다. 당장 운영 중인 서비스를 옮기기 위해서라기보다, 앞으로 닷넷 생태계가 어떤 방향으로 움직이는지 미리 감을 잡을 수 있기 때문입니다. 저는 21년차 닷넷 개발자로 일하면서, 요즘은 웹소설 집필 보조 서비스 메리톡톡을 만들고 운영하는 흐름도 함께 고민하고 있습니다. 그래서 새 버전을 볼 때도 “멋진 기능이 나왔는가”보다 “혼자 오래 운영하는 서비스에 어떤 영향을 줄까”를 먼저 보게 ..

닷넷 프로젝트에서 Serilog를 자주 쓰는 이유

닷넷 프로젝트에서 Serilog를 자주 쓰는 이유 닷넷 프로젝트를 만들다 보면 로깅 도구를 고르는 순간이 자주 옵니다. 작은 기능을 만들 때는 Console.WriteLine만으로도 충분해 보이지만, 서비스가 실제로 운영되기 시작하면 이야기가 달라집니다. 문제가 생겼을 때 “어디에서”, “어떤 값으로”, “누가”, “얼마나 자주” 발생했는지 확인할 수 있어야 하기 때문입니다. 저는 닷넷으로 서비스를 만들고 운영하면서 Serilog를 자주 사용합니다. 대단히 특별한 이유라기보다, 혼자서도 상황을 추적하고 정리하기에 현실적인 도구라고 느껴왔기 때문입니다. 로그는 개발 중 확인용 메시지가 아니라, 운영 중인 서비스를 이해하기 위한 기록에 가깝습니다. 그런 관점에서 Serilog는 꽤 오랫동안 손에 익은 선택지..

서비스를 만들다 보면 로그인보다 더 오래 고민하게 되는 부분이 있습니다. 바로 “이 사용자가 어디까지 할 수 있는가”를 판단하는 일입니다. 처음에는 닷넷 코드 안에 Admin, Manager, User 같은 역할을 기준으로 조건문을 넣으면 충분해 보입니다. 하지만 서비스가 조금씩 커지고, 조직이나 기능 단위의 규칙이 늘어나면 접근 제어는 금방 복잡해집니다. 저는 이 문제를 보면서 인증과 인가를 조금 더 분리해서 생각해보고 싶었습니다. 사용자가 누구인지 확인하는 일은 OIDC가 맡고, 그 사용자가 특정 자원에 접근할 수 있는지 판단하는 일은 OPA가 맡는 구조입니다. 닷넷 애플리케이션은 두 세계를 연결하는 얇은 통로가 됩니다. OIDC는 사용자가 누구인지 확인합니다 OIDC, 즉 OpenID Connect..

닷넷 어스파이어를 다시 살펴보게 된 이유 요즘 애플리케이션은 예전처럼 하나의 프로젝트만 실행해서 끝나는 경우가 점점 줄어들고 있습니다. API 서버가 있고, 프론트엔드가 있고, 데이터베이스와 Redis 같은 외부 서비스가 붙습니다. 여기에 로그, 설정, 배포 환경까지 생각하면 작은 서비스도 금방 여러 조각으로 나뉩니다. 닷넷 어스파이어는 이런 분산 애플리케이션을 개발할 때 필요한 실행, 연결, 관찰 흐름을 한곳에서 정리해주는 도구입니다. Microsoft 문서에서는 Aspire를 여러 언어를 지원하는 로컬 개발 시점의 오케스트레이션 도구 체인으로 설명하고 있습니다. 단순히 닷넷 프로젝트를 하나 더 만드는 도구라기보다, 여러 구성 요소를 함께 실행하고 살펴보기 위한 작업 환경에 가깝습니다. 혼자 만드는 서..

닷넷으로 작은 서비스를 만들다 보면 데이터베이스 작업이 생각보다 자주 발목을 잡습니다. 테이블을 먼저 설계하고, 그에 맞춰 모델을 만들고, 다시 API 코드를 연결하는 흐름은 익숙하지만 손이 많이 갑니다. 그래서 요즘은 Entity Framework Core의 Code First 방식이 다시 편하게 느껴집니다. 특히 VS Code에서 Codex나 Claude Code 같은 AI 코딩 도구를 함께 사용할 때, Code First 방식은 궁합이 꽤 좋습니다. 이유는 단순합니다. 데이터 구조가 C# 코드 안에 먼저 표현되기 때문입니다. AI 도구 입장에서도 엔티티 클래스, DbContext, 설정 코드, 마이그레이션 흐름을 한 프로젝트 안에서 읽고 이해하기가 좋습니다. Code First는 데이터 구조를 코드..

CQRS 패턴을 닷넷에서 이야기할 때 MediatR은 거의 자연스럽게 함께 언급되곤 했습니다. Command와 Query를 나누고, Controller나 Minimal API endpoint에서는 요청만 보내고, 실제 처리는 Handler에 맡기는 구조가 익숙했기 때문입니다. 저도 이 흐름이 꽤 마음에 들었습니다. 기능이 늘어날수록 Controller가 비대해지는 것을 막을 수 있고, 요청 단위로 코드를 나누면 나중에 다시 열어봤을 때 흐름을 따라가기 쉬웠습니다. 특히 혼자 서비스를 만들고 운영할 때는 “이 기능이 어디에 있지?”를 빨리 찾는 것이 생각보다 중요합니다. CQRS는 거창한 구조라기보다 역할을 나누는 방식입니다 CQRS는 Command Query Responsibility Segregatio..

먼저 Cmd에서 다음 명령어로 프로젝트를 생성합니다. dotnet new worker --name 그런 다음 WIndowsServices 라이브러리를 설치해 줍니다. dotnet add package Microsoft.Extensions.Hosting.WindowsServices 이제 프로젝트 기본으로 주어지는 Worker.cs 파일을 WindowsBackgroundService.cs 파일로 교체합니다. namespace App.WindowsService; public sealed class WindowsBackgroundService( WorkService workService, ILogger logger) : BackgroundService { protected override async Task E..

닷넷의 발전 속도는 감히 따라가기 힘들 만큼 빠르게 변화하고 있습니다. 클린 아키텍처에 대한 이야기야 이전에도 많이 나왔지만, 닷넷은 아직 어려움을 겪고 있는 이들에게 좀 더 명확한 방향성을 제시해 주고 있습니다. 본 포스트에서 작성된 텍스트는 모두 다음 영상을 기초로 작성되었습니다. 영상에서는 클린 아키텍처에 대해 그 의존성을 도메인 중심으로 구성함으로써 전통적으로 데이터베이스를 중심으로 소프트웨어를 설계하는 것보다 도메인 중심으로 설계하는 것이 더 유리하다는 점을 강조하고 있습니다. 이를 통해 인프라 의존성을 최소화하고 소프트웨어를 테스트하거나 의존성을 변경하는 것이 쉬워집니다. 클린 아키텍처는 도메인 주도 설계를 따르고, 비즈니스 로직이 복잡한 경우에 적합하다고 이야기 하고 있습니다. 영상에서 이야..

본문 글은 원문(https://docs.duendesoftware.com/identityserver/v7/quickstarts/js_clients/js_without_backend/)을 참고하여 작성되었습니다. (1) 먼저 사용할 프로젝트를 생성해 줍니다. (예시에서는 SPA) dotnet new web -n SPA (2) 해당 프로젝트를 솔루션에 추가해 줍니다. dotnet sln add ./{프로젝트경로} (3) wwwroot 디렉토리를 만들어 주고, package.json 파일을 생성해 줍니다. npm init (4) oidc-client 라이브러리를 설치해 줍니다. (시작파일은 app.js로 지정) npm i oidc-client (5) 설치된 라이브러리에 있는 js 파일을 wwwroot 로 복사..

본 내용은 원문(https://docs.duendesoftware.com/identityserver/v7/quickstarts/js_clients/js_with_backend/) 내용을 참고하여 작성되었습니다. (1) JavaScript기반 클라이언트로 사용할 프로젝트를 추가해 줍니다. dotnet new web -n JavaScriptClient 이렇게 하면 빈 Asp.net Core 프로젝트가 생성됩니다. (2) 다음으로 솔루션에 해당 프로젝트를 추가해 줍니다. dotnet sln add ./{프로젝트경로} (3) IdentityServer의 BFF관련 라이브러리들을 추가해 줍니다. dotnet add package Microsoft.AspNetCore.Authentication.OpenIdConne..