이야기를 디버깅하는 개발자.

개발과 창작 사이에서, 사람들이 자기만의 이야기를 만들 수 있는 도구와 기록을 만듭니다.

roslyn.dev 자세히보기

2026/09 15

Kestrel 개선과 Zstandard 압축 — 응답 크기와 CPU를 같이 줄이기

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

Minimal API 비동기 검증과 OpenAPI 3.2 — .NET 11에서 달라지는 것

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

.NET 11 정식 출시 전 점검 — 실서비스 마이그레이션 체크리스트

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

사용자가 아직 0명일 때 봐야 할 지표와 대시보드 최소 구성

사용자가 0명인 서비스의 7일 리텐션은 몇 퍼센트일까요. 계산이 되지 않습니다. 분모가 0이기 때문입니다. 그런데도 많은 개인 서비스의 관리자 화면 첫 줄에는 DAU와 리텐션 자리가 마련되어 있고, 거기에는 대개 0과 하이픈이 표시되어 있습니다.관리자 화면을 먼저 만들어두는 편이 낫다는 이야기와, 로그 다음에 필요한 것이 상태를 보는 화면이라는 이야기는 앞서 따로 쓴 적이 있습니다. 이 글은 그 다음 단계입니다. 그래서 그 화면에 정확히 무엇을 몇 개나 넣을 것인가를 목록으로 정리합니다.기준은 하나입니다. 그 숫자를 보고 내일 할 일이 바뀌는가. 바뀌지 않는 숫자는 아무리 그럴듯해도 초기에는 자리만 차지합니다. 사용자 0명 구간에서 그 조건을 만족하는 항목은 생각보다 적습니다.0명일 때 의미가 생기는 다..

"자동 생성" 대신 "이어 쓰기"를 택한 이유 — 창작 보조 도구 설계 기록

이전에 이 주제로 관점을 한 번 정리한 적이 있습니다. 자동 생성이 아니라 이어 쓰기여야 한다는 이야기였는데, 그때는 문제 제기에 가까웠습니다. 이번 글은 그 뒤의 기록입니다. 실제로 메리톡톡을 만들면서 어디서 멈출지, 무엇을 포기할지를 코드 단위로 정해야 했고, 그 결정들을 남겨둡니다.가장 먼저 확인한 것은 제 자신의 반응이었습니다. 초기 버전에서 문단 하나를 통째로 생성해 화면에 띄워봤는데, 문장은 꽤 그럴듯했는데도 손이 멈췄습니다. 고쳐 쓸지 지울지를 판단하는 동안, 원래 쓰려던 문장이 머릿속에서 사라졌습니다. 잘 쓰인 남의 문장이 내 문장을 덮어쓴 셈입니다.그때 알았습니다. 창작 보조 도구에서 진짜 위험한 것은 품질이 낮은 결과물이 아니라, 품질이 적당히 높아서 판단을 대신해버리는 결과물입니다. ..

반응형