서버 지표를 보다가 이상한 장면을 만난 적이 있습니다. 트래픽은 그대로인데 CPU 사용률만 눈에 띄게 올라가 있었습니다. 원인을 좁혀보니 압축 설정을 바꾼 배포가 그 시점에 있었습니다. 응답 크기를 줄이려고 켠 옵션이 CPU를 대신 먹고 있었던 겁니다.응답 압축은 켜기만 하면 이득처럼 보이지만 실제로는 거래입니다. 네트워크로 나가는 바이트를 줄이는 대신 프로세서 시간을 씁니다. 이 거래가 이득인지 손해인지는 서비스마다, 심지어 엔드포인트마다 다릅니다..NET 11에서는 Zstandard 압축이 들어옵니다. Brotli에 준하는 압축률을 더 낮은 CPU 비용으로 얻는다는 성격의 알고리즘입니다. 이 글에서는 압축의 기본 거래 구조를 먼저 짚고, Zstandard가 1인 서비스에서 어떤 상황에 실익이 되는지,..

"이 이메일은 이미 사용 중입니다." 회원가입 화면에서 이 문구 하나를 띄우려고 코드를 어디에 둘지 한참 고민했던 기억이 있습니다. 형식이 이메일인지 확인하는 건 어트리뷰트 한 줄이면 끝나는데, 이미 가입된 주소인지 확인하려면 데이터베이스를 봐야 합니다. 그리고 이 두 가지는 성격이 전혀 다릅니다.Minimal API를 쓰기 시작한 뒤로 이 구분이 더 선명해졌습니다. 형식 검증은 프레임워크가 알아서 해주는데, DB가 필요한 검증은 갈 곳이 애매해서 결국 핸들러 안으로 들어가곤 했습니다. .NET 11에서는 이 지점이 다뤄질 예정입니다. 다만 현재 프리뷰 기준이며 GA까지 바뀔 수 있습니다. 구체적인 메서드 이름이나 시그니처는 출시 시점의 공식 문서에서 확인하시는 편이 좋습니다.지금까지 검증 코드를 두던 ..

달력을 보니 .NET 11 정식 출시까지 세 달 남짓 남았습니다. 예년대로라면 2026년 11월에 GA가 나올 예정이고, 지금은 프리뷰 단계입니다. 저는 이 시기가 되면 늘 같은 고민을 반복합니다. 나오자마자 올릴 것인가, 아니면 몇 달 지켜볼 것인가.회사에서라면 이 결정을 여럿이 나눠 지지만, 메리톡톡처럼 혼자 만들고 혼자 운영하는 서비스에서는 결정도 수습도 제 몫입니다. 그래서 저는 버전을 올리는 일 자체보다 올리기 전에 무엇을 확인해두었는가를 더 중요하게 봅니다. 확인 목록이 부실하면 올린 다음 날 새벽에 로그를 뒤지게 됩니다.이 글에서는 GA 전에 미리 해둘 수 있는 점검을 순서대로 적어보겠습니다. 아래 내용 중 프리뷰 기능에 대한 부분은 현재 프리뷰 기준이며 GA까지 바뀔 수 있습니다. 최종 확..

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

닷넷 프로젝트에서 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..