ORM의 새 기능은 샘플 코드에서는 쉽게 동작하지만, 실제 서비스에서는 모델·데이터베이스·마이그레이션·쿼리 번역이 함께 움직여야 합니다. 특히 EF Core 11처럼 개발 중인 버전은 기능 목록보다 호환성 확인이 먼저입니다.이번 글에서는 Complex Types와 FullJoin 같은 기능을 바로 채택하자는 이야기가 아니라, 적용 여부를 판단하기 위해 어떤 실험을 해야 하는지 정리합니다. 테스트 환경과 버전은 글을 읽는 시점에 다시 확인해야 합니다.기능 이름보다 지원 범위를 고정합니다새 기능을 읽을 때는 무엇이 가능한지보다 어떤 데이터베이스와 런타임에서 가능한지 먼저 기록합니다. EF Core 11은 .NET 11 SDK와 런타임을 요구하는 개발 중 버전이므로, 기존 서비스가 사용하는 타깃 프레임워크와 ..

API에 제한을 붙일 때 가장 먼저 떠오르는 문장은 ‘분당 몇 번 허용할까’입니다. 하지만 같은 분당 열 번이라도 읽기 요청과 파일 변환 요청의 비용은 다릅니다. 제한값 하나를 정하기 전에 정책의 목적을 분리해야 합니다.이번 글에서는 ASP.NET Core의 Rate Limiting 미들웨어를 특정 값의 정답이 아니라 정책 선택 도구로 읽어 보겠습니다. 실제 값은 부하 테스트와 사용자 행동을 보고 조정해야 합니다.제한의 목적을 네 가지로 나눕니다Rate Limiting은 악성 요청만 막는 기능이 아닙니다. 공정 사용량을 보장하고, 백엔드 자원을 보호하고, 외부 비용을 통제하고, 동시 작업 수를 제한하는 데 사용할 수 있습니다. 목적이 다르면 관찰할 지표와 실패 응답도 달라집니다.저는 엔드포인트마다 ‘무엇..

새 런타임 기능을 보면 곧바로 기존 프로젝트에 적용해 보고 싶어집니다. 하지만 운영 서비스에서는 기능이 빠르다는 기대보다 빌드·디버깅·라이브러리 호환성·롤백이 먼저입니다..NET 11의 Runtime Async는 이 글을 쓰는 시점에 프리뷰 문서에서 확인되는 기능입니다. 정식 출시 전까지 사양이 바뀔 수 있으므로, 아래 내용은 도입 권고가 아니라 실험 범위를 정하는 체크리스트로 읽어 주시기 바랍니다.프리뷰 기능은 서비스와 격리해 확인합니다첫 실험은 운영 코드의 브랜치가 아니라 작은 샘플 프로젝트에서 시작합니다. 동일한 SDK와 런타임을 사용하고, 기존 async/await 코드와 새 방식의 호출 경로를 나란히 둡니다. 결과가 다르면 어느 계층에서 달라졌는지 추적할 수 있어야 합니다.실험 환경에는 프로젝트..

서버 지표를 보다가 이상한 장면을 만난 적이 있습니다. 트래픽은 그대로인데 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를 여러 언어를 지원하는 로컬 개발 시점의 오케스트레이션 도구 체인으로 설명하고 있습니다. 단순히 닷넷 프로젝트를 하나 더 만드는 도구라기보다, 여러 구성 요소를 함께 실행하고 살펴보기 위한 작업 환경에 가깝습니다. 혼자 만드는 서..