로슬린의 인생잡담

작은 서비스에서 로그 다음으로 필요한 것은 상태를 보는 화면입니다

Roslyn — Thu, 9 Jul 2026 19:23:10 +0900

서비스를 만들다 보면 로그를 먼저 생각하게 됩니다. 문제가 생겼을 때 원인을 찾아야 하고, 어떤 요청에서 실패했는지 확인해야 하기 때문입니다. 저도 닷넷 프로젝트를 만들 때 Serilog 같은 구조화 로깅 도구를 자주 떠올립니다.

하지만 로그를 남기기 시작하면 곧 다른 질문이 생깁니다. 로그는 문제가 생긴 뒤에 뒤져보는 기록에 가깝습니다. 그렇다면 지금 서비스가 어떤 상태인지, 오늘 어떤 일이 있었는지, 사용자가 실제로 어떤 흐름을 지나고 있는지는 어디에서 봐야 할까요.

이 지점에서 작은 대시보드나 상태 확인 화면이 필요해집니다. 거창한 분석 시스템이 아니라, 운영자가 매일 한 번쯤 열어보고 서비스의 현재 상태를 감각할 수 있는 화면입니다. 혼자 운영하는 서비스일수록 이런 화면이 생각보다 중요합니다.

로그는 자세하지만 한눈에 보이지 않습니다
로그는 운영에 꼭 필요합니다. 요청 경로, 예외 메시지, 사용자 식별자, 처리 시간 같은 정보는 문제가 생겼을 때 큰 도움이 됩니다. 구조화된 로그를 잘 남겨두면 특정 사용자나 특정 기능을 기준으로 상황을 좁혀볼 수도 있습니다.

하지만 로그는 기본적으로 자세한 기록입니다. 한 줄 한 줄을 따라가며 맥락을 찾아야 합니다. 어떤 문제를 이미 알고 있을 때는 로그가 강력하지만, 아직 무엇을 봐야 할지 모르는 상태에서는 오히려 부담스럽습니다.

예를 들어 어제보다 오류가 늘었는지, 특정 작업이 계속 실패하고 있는지, 사용자가 생성한 데이터가 정상적으로 쌓이고 있는지 알고 싶을 때가 있습니다. 이때 모든 로그를 검색해서 판단하는 것은 번거롭습니다. 운영자가 먼저 봐야 할 신호는 조금 더 압축된 형태로 보여야 합니다.

상태 화면은 이 역할을 합니다. 로그가 현미경이라면, 상태 화면은 작은 지도에 가깝습니다. 지금 어디를 봐야 하는지 알려주는 첫 화면입니다.

작은 서비스에도 관찰 가능한 지점이 필요합니다
관찰 가능성이라는 말을 쓰면 조금 거창하게 들립니다. 대규모 시스템, 분산 추적, 메트릭 수집, 알림 체계 같은 것들이 먼저 떠오르기 때문입니다. 하지만 작은 서비스에서도 관찰 가능한 지점은 필요합니다.

사용자 수가 많지 않아도 작업은 실패할 수 있습니다. 배치 작업이 멈출 수도 있고, 외부 API 호출이 실패할 수도 있고, 특정 데이터가 예상과 다르게 쌓일 수도 있습니다. 혼자 운영하는 서비스에서는 이런 문제를 누가 대신 알려주지 않습니다.

그래서 처음부터 완성된 모니터링 시스템을 만들 필요는 없지만, 최소한 자주 확인해야 할 상태는 화면으로 꺼내두는 편이 좋습니다. 오늘 생성된 항목 수, 실패한 작업 수, 최근 오류, 대기 중인 작업, 오래 처리되지 않은 요청 같은 정보만 있어도 운영 감각이 달라집니다.

이 화면은 예쁜 차트가 아니어도 됩니다. 숫자 몇 개와 목록 몇 개로 시작해도 충분합니다. 중요한 것은 운영자가 지금 서비스를 확인할 수 있는 입구가 있다는 점입니다.

대시보드는 의사결정을 위한 화면이어야 합니다
대시보드를 만들 때 조심해야 할 부분도 있습니다. 보기 좋은 숫자를 많이 모아놓는다고 해서 좋은 운영 화면이 되는 것은 아닙니다. 오히려 너무 많은 숫자는 중요한 신호를 가리기도 합니다.

혼자 운영하는 서비스에서 대시보드는 의사결정과 연결되어야 합니다. 이 숫자를 보고 제가 무엇을 할 수 있는지 생각해야 합니다. 실패한 작업 수가 보인다면 다시 실행하거나 원인을 확인할 수 있어야 합니다. 미처리 문의가 보인다면 바로 상세 화면으로 들어갈 수 있어야 합니다. 최근 오류가 보인다면 로그로 이어질 수 있어야 합니다.

즉, 대시보드는 단순한 통계판이 아니라 작업의 출발점이어야 합니다. 숫자를 보고 끝나는 화면보다, 숫자를 보고 다음 행동으로 넘어갈 수 있는 화면이 운영에는 더 도움이 됩니다.

저는 이 기준이 특히 1인 서비스에 중요하다고 느낍니다. 시간이 넉넉하지 않기 때문에, 화면을 열었을 때 바로 확인하고 바로 처리할 수 있어야 합니다. 보는 화면과 일하는 화면이 너무 멀리 떨어져 있으면 결국 다시 사용하지 않게 됩니다.

로그와 상태 화면은 서로 이어져야 합니다
로그와 대시보드는 서로 다른 역할을 하지만, 따로 떨어져 있으면 힘이 줄어듭니다. 상태 화면에서 이상한 신호를 발견하면 로그로 내려갈 수 있어야 합니다. 반대로 로그에서 반복되는 오류를 발견했다면, 다음에는 그 오류를 상태 화면에서 빨리 볼 수 있도록 정리할 수 있어야 합니다.

예를 들어 최근 24시간 동안 실패한 작업 수를 대시보드에 보여준다고 가정해보겠습니다. 숫자만 보여주면 아쉬움이 남습니다. 클릭했을 때 실패한 작업 목록으로 들어가고, 각 항목에서 관련 로그나 오류 메시지를 볼 수 있으면 훨씬 실용적입니다.

또한 로그에 남긴 요청 ID나 작업 ID를 상태 화면에서도 함께 보여주면 문제를 추적하기 쉬워집니다. 로그를 잘 남기는 것과 운영 화면을 잘 만드는 일은 결국 같은 방향을 향합니다. 나중에 원인을 찾을 수 있게 맥락을 남기는 일입니다.

이런 연결은 처음부터 완벽할 필요가 없습니다. 중요한 작업부터 하나씩 이어두면 됩니다. 실패한 생성 작업, 결제 실패, 외부 API 오류, 오래 걸리는 요청처럼 운영자가 실제로 불안해하는 지점부터 화면으로 꺼내면 됩니다.

닷넷에서는 작은 상태 API부터 시작할 수 있습니다
닷넷 기반 서비스라면 처음부터 복잡한 대시보드 시스템을 붙이지 않아도 됩니다. ASP.NET Core에서 간단한 관리자용 API를 만들고, 필요한 상태 데이터를 모아 내려주는 것만으로도 시작할 수 있습니다.

예를 들어 /api/admin/status 같은 엔드포인트에서 오늘의 가입자 수, 최근 오류 수, 실패한 작업 수, 대기 중인 작업 수를 내려줄 수 있습니다. React 화면에서는 이 데이터를 TanStack Query로 가져와 카드나 목록으로 보여주면 됩니다.

이때 중요한 것은 데이터의 기준입니다. 오늘이라는 범위를 어느 시간대로 볼 것인지, 실패 상태는 어떤 값을 기준으로 볼 것인지, 운영자가 직접 처리해야 하는 항목과 자동 재시도될 항목을 어떻게 구분할 것인지 정해야 합니다.

결국 상태 화면을 만든다는 것은 단순히 SQL을 몇 개 작성하는 일이 아닙니다. 서비스의 현재 상태를 어떤 언어로 설명할지 정하는 일에 가깝습니다. 이 기준이 생기면 운영이 조금 더 차분해집니다.

처음에 볼 만한 항목들
작은 서비스에서 처음 대시보드에 올릴 만한 항목은 많지 않아도 됩니다. 오히려 적은 편이 좋습니다. 제가 먼저 생각하는 항목은 다음과 같습니다.

최근 24시간 동안 생성된 주요 데이터 수
최근 24시간 동안 발생한 오류 수
실패 상태로 남아 있는 작업 목록
처리 대기 중인 요청이나 문의 수
최근 배포 이후 발생한 주요 예외
이 정도만 있어도 매일 서비스를 확인하는 기준이 생깁니다. 사용자가 많지 않은 단계에서는 숫자가 작을 수 있습니다. 그래도 괜찮습니다. 중요한 것은 숫자의 크기가 아니라 흐름을 보는 습관입니다.

나중에 필요해지면 응답 시간, 외부 API 실패율, 결제 전환, 기능별 사용량 같은 항목을 추가할 수 있습니다. 처음부터 모든 것을 넣으려 하면 화면이 무거워지고, 운영자가 실제로 보지 않는 정보가 늘어납니다.

상태 화면은 불안을 줄이기 위한 도구입니다
혼자 서비스를 만들고 운영하다 보면 작은 불안이 계속 생깁니다. 사용자가 작업하다가 막히지는 않았을까, 어제 배포한 기능이 제대로 동작하고 있을까, 백그라운드 작업이 멈춰 있지는 않을까 하는 생각입니다.

상태 화면은 이 불안을 완전히 없애주지는 않습니다. 하지만 불안을 확인 가능한 항목으로 바꿔줍니다. 막연히 걱정하는 대신 오늘의 실패 목록을 보고, 최근 오류를 확인하고, 필요한 작업을 처리할 수 있게 해줍니다.

이 점에서 상태 화면은 운영자의 정신적인 부담을 줄이는 도구이기도 합니다. 문제가 생겼을 때 어디를 봐야 하는지 알고 있으면, 서비스 운영이 조금 덜 막막해집니다.

마무리
로그는 서비스 운영의 중요한 기록입니다. 하지만 로그만으로는 지금 서비스가 어떤 상태인지 한눈에 보기 어렵습니다. 작은 서비스에서도 현재 상태를 압축해서 보여주는 화면이 필요합니다.

대시보드는 처음부터 거창할 필요가 없습니다. 오늘의 주요 숫자, 실패한 작업, 최근 오류, 처리해야 할 항목 정도로 시작해도 충분합니다. 중요한 것은 그 화면이 다음 행동으로 이어지는가입니다.

저는 요즘 작은 서비스를 만들 때 로그 다음에는 상태 화면을 생각하게 됩니다. 기록을 남기는 것에서 한 걸음 더 나아가, 그 기록을 운영자가 볼 수 있는 형태로 정리하는 일입니다. 아직 완성된 기준은 아니지만, 혼자 오래 운영할 수 있는 서비스를 만들기 위해 계속 다듬어가야 할 부분이라고 느낍니다.

BFF 구조에서 리액트는 화면에 집중하고 인증은 서버가 맡는 방식

Roslyn — Thu, 9 Jul 2026 19:21:26 +0900

프론트엔드를 리액트로 만들다 보면 어느 순간 인증 처리를 어디까지 맡겨야 하는지 고민하게 됩니다. 화면을 그리는 일은 리액트가 잘합니다. 상태를 다루고, 컴포넌트를 나누고, 사용자와 빠르게 상호작용하는 것도 리액트의 장점입니다.

하지만 인증은 조금 다릅니다. 토큰을 어디에 저장할지, 쿠키는 어떻게 다룰지, API 호출 권한은 어디서 확인할지, 새로고침 후 세션은 어떻게 유지할지 같은 문제들이 따라옵니다. 처음에는 단순해 보이지만, 실제 서비스를 운영하려고 하면 생각보다 신경 쓸 부분이 많아집니다.

그래서 요즘 다시 관심을 두고 있는 구조가 BFF입니다. Backend for Frontend의 줄임말인데, 이름 그대로 프론트엔드를 위한 백엔드 계층을 하나 두는 방식입니다. 저는 이 구조를 “서버사이드가 프론트엔드를 한 번 감싸주는 방식”으로 이해하고 있습니다.

리액트가 모든 것을 직접 알 필요는 없습니다
SPA 구조에서는 리액트 앱이 브라우저에서 실행되고, 필요한 데이터를 API로 직접 가져오는 흐름이 자연스럽습니다. 이 방식 자체가 나쁜 것은 아닙니다. 작은 서비스나 내부 도구에서는 충분히 단순하고 빠르게 만들 수 있습니다.

문제는 인증과 권한 처리까지 브라우저 쪽으로 많이 내려왔을 때입니다. 액세스 토큰을 브라우저에 저장해야 하고, 갱신 토큰을 어떻게 보호할지도 고민해야 합니다. API 서버 주소나 인증 흐름도 프론트엔드 코드에서 점점 많이 알게 됩니다.

BFF 구조에서는 이 부담을 조금 다르게 나눕니다. 사용자는 먼저 서버사이드에 접근합니다. 서버는 사용자가 로그인되어 있는지 확인합니다. 조회 가능한 페이지라면 리액트 앱을 내려주고, 리액트는 그 안에서 화면을 그립니다. 반대로 권한이 없거나 인증이 필요한 상태라면 서버가 먼저 막거나 로그인 흐름으로 보냅니다.

서버사이드가 문지기 역할을 합니다
이 구조에서 중요한 점은 서버사이드가 문지기 역할을 한다는 것입니다. 브라우저에 있는 리액트 앱이 “이 사용자가 누구인지”를 모든 책임으로 들고 있지 않습니다. 서버가 먼저 세션이나 쿠키를 확인하고, 이 사용자가 이 화면에 접근할 수 있는지 판단합니다.

예를 들어 관리자 페이지가 있다고 가정해보겠습니다. 사용자가 /admin 경로에 접근하면 서버가 먼저 인증 상태를 확인합니다. 권한이 있으면 리액트 앱과 필요한 초기 정보를 내려줍니다. 권한이 없으면 리액트가 렌더링되기도 전에 접근을 막습니다.

이렇게 하면 프론트엔드는 화면에 집중할 수 있습니다. 물론 리액트 안에서도 사용자의 상태에 따라 버튼을 숨기거나 메뉴를 다르게 보여줄 수는 있습니다. 하지만 그것은 사용자 경험을 위한 처리이지, 최종 보안 판단의 기준이 되어서는 안 됩니다.

조회 가능한 페이지라면 리액트가 그립니다
BFF를 쓴다고 해서 모든 화면을 서버 렌더링으로 만들어야 하는 것은 아닙니다. 제가 관심 있는 방식은 조금 더 현실적인 절충입니다. 인증과 접근 가능 여부는 서버가 확인하고, 실제 화면 구성은 리액트가 맡는 방식입니다.

이 방식에서는 서버가 먼저 “이 사용자가 이 페이지를 볼 수 있는가”를 확인합니다. 볼 수 있다면 리액트 앱을 실행할 수 있는 HTML을 내려줍니다. 이후 화면 안에서 필요한 데이터는 BFF를 통해 가져오게 합니다. 리액트는 외부 API를 직접 호출하기보다, 같은 서버의 엔드포인트를 호출하는 형태가 됩니다.

이 구조가 좋은 이유는 역할이 비교적 분명해지기 때문입니다. 서버는 인증, 권한, 민감한 API 호출, 외부 서비스 연동을 맡습니다. 리액트는 화면 상태, 사용자 입력, 목록과 상세 화면, 컴포넌트 구성을 맡습니다. 서로의 책임이 겹치지 않도록 선을 그을 수 있습니다.

토큰을 브라우저에 오래 들고 있지 않아도 됩니다
BFF 구조를 선택하는 이유 중 하나는 토큰 관리입니다. 브라우저 안에 액세스 토큰이나 갱신 토큰을 직접 보관하는 방식은 늘 조심스럽습니다. 저장 위치에 따라 XSS 같은 공격에 취약해질 수 있고, 만료와 갱신 흐름도 프론트엔드 코드에 많이 들어가게 됩니다.

BFF를 두면 민감한 토큰은 서버 쪽에서 다루고, 브라우저에는 세션 쿠키만 전달하는 방식으로 정리할 수 있습니다. 물론 쿠키도 안전하게 설정해야 합니다. HttpOnly, Secure, SameSite 같은 설정을 제대로 해야 하고, CSRF에 대한 고려도 필요합니다.

다만 중요한 차이는 있습니다. 프론트엔드 코드가 직접 토큰을 읽고 들고 다니는 구조보다, 서버가 인증 흐름을 감싸는 구조가 운영 관점에서는 더 다루기 쉬울 때가 많습니다. 특히 혼자 서비스를 만들고 운영하는 입장에서는 인증 관련 코드를 여러 군데 흩뿌리지 않는 것이 중요합니다.

API도 프론트엔드 전용으로 정리할 수 있습니다
BFF의 또 다른 장점은 프론트엔드에 맞춘 API를 만들 수 있다는 점입니다. 실제 내부 API나 외부 API는 서비스 구조에 맞게 복잡할 수 있습니다. 하지만 화면에서 필요한 데이터는 조금 다릅니다. 한 화면을 그리기 위해 여러 API를 호출해야 할 수도 있고, 반대로 너무 많은 데이터가 내려올 수도 있습니다.

BFF는 이 중간에서 화면에 맞는 형태로 데이터를 정리해줄 수 있습니다. 리액트는 여러 내부 시스템의 구조를 몰라도 됩니다. 화면에 필요한 모델만 받아서 렌더링하면 됩니다.

예를 들어 대시보드 화면이 있다고 하면, BFF가 사용자 정보, 알림 개수, 최근 활동, 권한 정보를 한 번에 조합해서 내려줄 수 있습니다. 리액트는 그 결과를 받아 화면을 그립니다. 내부 API가 나중에 바뀌어도, BFF 계층에서 맞춰줄 수 있다면 프론트엔드의 변경 범위를 줄일 수 있습니다.

단점도 있습니다
물론 BFF가 항상 정답은 아닙니다. 백엔드 계층이 하나 더 생긴다는 것은 관리할 코드가 늘어난다는 뜻이기도 합니다. 단순한 정적 사이트나 인증이 거의 없는 서비스라면 오히려 구조가 무거워질 수 있습니다.

또한 BFF가 모든 것을 대신해주다 보면, 어느 순간 화면 전용 로직이 서버에 너무 많이 쌓일 수도 있습니다. 그러면 서버도 복잡해지고, 프론트엔드도 서버 응답에 과하게 묶일 수 있습니다. 그래서 BFF를 둘 때는 “보안과 조합은 서버가 맡고, 표현과 상호작용은 프론트가 맡는다”는 기준을 계속 유지해야 합니다.

작은 서비스에서는 특히 더 그렇습니다. 구조가 좋아 보여도 혼자 감당하기 어려우면 오래 유지하기 어렵습니다. 그래서 BFF도 처음부터 크게 만들기보다, 인증과 민감한 API 호출을 감싸는 작은 계층으로 시작하는 편이 현실적이라고 생각합니다.

닷넷으로 만들 때의 느낌
닷넷 환경에서는 ASP.NET Core가 이 BFF 역할을 맡기에 꽤 자연스럽습니다. 쿠키 기반 인증, 정책 기반 권한 처리, API 라우팅, 정적 파일 제공, 프록시 구성 등을 한 서버 안에서 비교적 안정적으로 다룰 수 있습니다.

리액트 앱은 빌드된 정적 파일로 배포하고, ASP.NET Core가 해당 파일을 내려주면서 인증이 필요한 경로를 감싸는 방식으로 구성할 수 있습니다. 필요한 경우 서버 API는 /api 같은 경로로 노출하고, 리액트는 같은 출처의 API를 호출하게 만들 수 있습니다.

이렇게 하면 CORS 설정이나 토큰 전달 문제도 줄어듭니다. 브라우저 입장에서는 같은 서버와 통신하는 구조가 되고, 서버는 내부적으로 필요한 서비스나 데이터베이스에 접근합니다. 구조가 단순해지는 만큼, 장애가 났을 때 원인을 추적하기도 쉬워질 수 있습니다.

제가 이 구조를 보는 이유
저는 요즘 서비스를 만들 때 “기능을 얼마나 많이 넣을 수 있는가”보다 “혼자 오래 운영할 수 있는가”를 자주 생각합니다.

인증은 그중에서도 초반에 잘 정리해두지 않으면 나중에 계속 발목을 잡는 영역입니다.

BFF 구조는 리액트의 장점을 버리지 않으면서도, 인증과 보안의 중심을 서버 쪽에 둘 수 있는 방법입니다. 리액트는 사용자가 볼 수 있는 화면을 빠르게 구성하고, 서버는 사용자가 봐도 되는지 먼저 판단합니다. 이 분리가 생각보다 중요합니다.

특히 관리자 화면, 유료 사용자 전용 화면, 개인 데이터가 포함된 화면처럼 접근 제어가 중요한 서비스에서는 이 방식이 더 안정적으로 느껴집니다. 프론트엔드에서 숨기는 것과 서버에서 막는 것은 완전히 다른 문제이기 때문입니다.

마무리
BFF는 새로운 유행어라기보다, 프론트엔드와 백엔드의 책임을 다시 나누는 방식에 가깝습니다. 서버사이드가 프론트엔드를 한 번 감싸고, 인증과 접근 가능 여부를 먼저 판단합니다. 조회 가능한 페이지라면 리액트가 화면을 그립니다.

이 구조가 모든 서비스에 필요한 것은 아닙니다. 하지만 인증이 중요하고, 브라우저에 민감한 정보를 오래 들고 있게 만들고 싶지 않다면 충분히 검토해볼 만합니다. 특히 혼자 서비스를 만들고 운영하는 입장에서는 보안 판단의 위치를 분명히 해두는 것만으로도 나중의 부담을 줄일 수 있습니다.

아직 이 방식이 제가 만드는 모든 서비스의 정답이라고 말하기는 어렵습니다. 다만 지금 기준에서는 리액트는 화면에 집중하고, 서버는 인증과 권한을 책임지는 구조가 오래 운영하기에 더 편한 방향처럼 느껴집니다. 그래서 이번 글은 BFF를 기술 패턴으로 소개하기보다, 제가 서비스를 만들며 역할을 어떻게 나누고 싶은지 정리해둔 기록에 가깝습니다.

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

Roslyn — Thu, 9 Jul 2026 19:18:46 +0900

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

혼자 운영하는 서비스에서 관리자 화면을 먼저 정리하는 이유

Roslyn — Wed, 8 Jul 2026 06:51:49 +0900

작은 서비스를 만들 때 처음부터 관리자 화면을 신경 쓰는 일은 조금 과해 보일 수 있습니다. 사용자에게 보이는 기능도 아직 충분하지 않은데, 운영자만 보는 화면을 먼저 만든다는 것이 뒤로 미뤄도 되는 일처럼 느껴지기 때문입니다.

저도 예전에는 비슷하게 생각했습니다. 우선 사용자가 보는 화면을 만들고, 데이터가 쌓이면 그때 관리자 기능을 붙이면 된다고 봤습니다. 하지만 혼자 서비스를 만들고 운영하는 시간이 길어질수록, 관리자 화면은 나중에 붙이는 부가 기능이 아니라 서비스를 오래 붙잡기 위한 기본 도구에 가깝다는 생각을 하게 됩니다.

특히 메리톡톡처럼 창작자의 흐름을 돕는 서비스를 만들 때는 더 그렇습니다. 사용자가 어떤 지점에서 막히는지, 어떤 데이터가 쌓이고 있는지, 문제가 생겼을 때 어디를 먼저 봐야 하는지 알 수 있어야 합니다. 관리자 화면은 그런 질문에 답하기 위한 작은 작업대입니다.

운영자는 데이터베이스를 직접 보지 않는 편이 좋습니다

혼자 만드는 서비스에서는 문제가 생겼을 때 데이터베이스에 직접 접속해서 확인하는 일이 어렵지 않습니다. 테이블을 열고, 값을 검색하고, 필요한 경우 직접 수정할 수도 있습니다. 개발자 입장에서는 가장 빠른 방법처럼 느껴집니다.

하지만 이 방식은 오래 지속하기 어렵습니다. 매번 데이터베이스 구조를 떠올려야 하고, 실수로 잘못된 값을 바꿀 위험도 있습니다. 특히 운영 중인 데이터라면 작은 수정 하나가 사용자 경험에 영향을 줄 수 있습니다.

관리자 화면을 만들어두면 자주 확인하는 정보와 자주 처리하는 작업을 안전한 흐름 안으로 가져올 수 있습니다. 게시글 상태를 바꾸거나, 사용자 문의를 확인하거나, 실패한 작업을 다시 실행하는 일을 데이터베이스 쿼리가 아니라 정리된 버튼과 화면으로 처리할 수 있습니다.

이것은 단순히 편의를 위한 일이 아닙니다. 나중의 저를 실수에서 보호하는 장치에 가깝습니다. 혼자 운영하는 서비스일수록 이런 장치가 필요합니다.

관리자 화면은 운영 흐름을 드러냅니다

관리자 화면을 만들다 보면 자연스럽게 서비스의 운영 흐름을 다시 보게 됩니다. 사용자는 어떤 상태를 거치는지, 게시물은 어떤 기준으로 공개되는지, 결제나 구독이 있다면 어떤 시점에 상태가 바뀌는지 정리해야 하기 때문입니다.

처음에는 기능을 구현하는 데 집중하느라 이런 상태들이 코드 안에 흩어지기 쉽습니다. 어떤 상태는 enum으로 있고, 어떤 상태는 문자열로 남아 있고, 어떤 조건은 화면에서만 확인되기도 합니다. 관리자 화면을 만들려면 이 흐름을 다시 한곳으로 모아야 합니다.

예를 들어 글쓰기 보조 서비스라면 초안, 저장됨, 생성 중, 실패, 완료 같은 상태가 있을 수 있습니다. 관리자 화면에서 이 상태들을 보여주려면 각각의 의미가 분명해야 합니다. 실패한 작업은 다시 실행할 수 있는지, 완료된 작업은 수정할 수 있는지, 사용자가 보는 값과 운영자가 보는 값은 어떻게 다른지도 정리해야 합니다.

이 과정은 귀찮지만 중요합니다. 관리자 화면은 단순히 데이터를 보여주는 공간이 아니라, 서비스가 실제로 어떻게 움직이는지를 운영자가 이해할 수 있게 만드는 지도에 가깝습니다.

React는 운영 화면을 빠르게 정리하기에 좋습니다

최근 React와 TanStack Query를 다시 정리하면서, 관리자 화면에는 이 조합이 꽤 현실적이라고 느꼈습니다. 관리자 화면은 목록, 상세, 검색, 필터, 저장, 삭제 같은 패턴이 반복됩니다. 서버 상태를 가져오고, 변경 후 다시 갱신하는 흐름도 자주 등장합니다.

TanStack Query를 사용하면 이런 서버 상태 관리가 비교적 단정해집니다. 데이터를 가져오는 코드는 query로 정리하고, 변경하는 작업은 mutation으로 나눌 수 있습니다. 저장이나 삭제가 끝난 뒤 관련 목록을 다시 불러오는 흐름도 일정한 방식으로 가져갈 수 있습니다.

물론 관리자 화면이라고 해서 프론트엔드가 모든 것을 판단하면 안 됩니다. 권한과 접근 제어는 서버에서 최종적으로 막아야 합니다. React는 운영자가 보기 좋은 화면을 만들고, 서버는 이 사용자가 정말 이 작업을 해도 되는지 확인하는 구조가 더 안전합니다.

이 기준은 BFF 구조와도 이어집니다. 서버가 먼저 인증과 권한을 확인하고, React는 허용된 범위 안에서 화면을 그립니다. 이렇게 역할을 나누면 프론트엔드는 화면에 집중하고, 서버는 운영의 안전선을 맡을 수 있습니다.

처음부터 거창할 필요는 없습니다

관리자 화면이라고 하면 복잡한 대시보드나 통계 화면을 떠올리기 쉽습니다. 하지만 작은 서비스에서 처음 필요한 것은 그렇게 거창하지 않습니다. 오히려 자주 확인하는 목록 하나, 상태 변경 버튼 하나, 최근 오류를 보는 작은 화면 하나가 더 중요할 때가 많습니다.

처음에는 세 가지 정도만 있어도 충분하다고 생각합니다. 첫째, 사용자가 만든 주요 데이터를 조회하는 화면입니다. 둘째, 운영자가 수동으로 처리해야 하는 작업을 모아둔 화면입니다. 셋째, 실패하거나 확인이 필요한 항목을 볼 수 있는 화면입니다.

이 정도만 있어도 데이터베이스에 직접 들어가는 횟수를 줄일 수 있습니다. 문제를 확인하는 속도도 빨라집니다. 무엇보다 서비스의 현재 상태를 운영자가 눈으로 볼 수 있게 됩니다.

혼자 운영하는 서비스에서 중요한 것은 완벽한 백오피스를 만드는 일이 아닙니다. 지금 가장 자주 불안해지는 지점을 화면으로 꺼내는 일입니다. 그 불안을 줄이는 화면부터 만들면 됩니다.

관리자 화면은 미래의 운영자를 위한 기록입니다

제가 관리자 화면을 중요하게 보는 또 다른 이유는 기록성 때문입니다. 좋은 관리자 화면은 단순한 조작 도구가 아니라, 운영자가 어떤 기준으로 서비스를 보고 있는지를 남기는 기록이 됩니다.

어떤 항목을 목록에 보여줄지, 어떤 상태를 강조할지, 어떤 작업에는 확인 단계를 둘지 같은 선택에는 운영자의 관점이 들어갑니다. 이 서비스에서 무엇이 위험한지, 무엇을 자주 확인해야 하는지, 어떤 작업은 자동화하고 어떤 작업은 사람이 확인해야 하는지가 화면에 반영됩니다.

이런 기준은 시간이 지나면 더 중요해집니다. 몇 달 뒤 다시 프로젝트를 열었을 때, 관리자 화면은 코드보다 먼저 현재 서비스를 이해하게 해줄 수 있습니다. 화면에 남은 항목과 버튼을 보면, 그때 제가 무엇을 중요하게 봤는지 다시 떠올릴 수 있습니다.

마무리

혼자 운영하는 서비스에서 관리자 화면은 나중에 붙이는 장식이 아닙니다. 사용자에게 보이지 않지만, 운영자가 서비스를 계속 붙잡기 위해 필요한 기본 도구입니다.

데이터베이스를 직접 만지는 일을 줄이고, 자주 확인하는 상태를 화면으로 꺼내고, 위험한 작업에는 안전한 흐름을 두는 것. 이런 작은 정리가 쌓이면 서비스는 조금 더 오래 운영할 수 있는 모양이 됩니다.

아직 제가 만드는 모든 서비스에 완벽한 관리자 화면이 있는 것은 아닙니다. 다만 요즘은 새 기능을 만들 때마다 이 기능을 운영자가 어디서 확인할 것인지도 함께 생각하게 됩니다. 이번 기록은 관리자 화면을 거창한 백오피스가 아니라, 혼자 만드는 서비스를 오래 유지하기 위한 작은 작업대로 다시 바라보기 위한 기준점에 가깝습니다.

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

Roslyn — Mon, 6 Jul 2026 20:00:35 +0900

닷넷 프로젝트에서 Serilog를 자주 쓰는 이유
닷넷 프로젝트를 만들다 보면 로깅 도구를 고르는 순간이 자주 옵니다. 작은 기능을 만들 때는 Console.WriteLine만으로도 충분해 보이지만, 서비스가 실제로 운영되기 시작하면 이야기가 달라집니다. 문제가 생겼을 때 “어디에서”, “어떤 값으로”, “누가”, “얼마나 자주” 발생했는지 확인할 수 있어야 하기 때문입니다.

저는 닷넷으로 서비스를 만들고 운영하면서 Serilog를 자주 사용합니다. 대단히 특별한 이유라기보다, 혼자서도 상황을 추적하고 정리하기에 현실적인 도구라고 느껴왔기 때문입니다. 로그는 개발 중 확인용 메시지가 아니라, 운영 중인 서비스를 이해하기 위한 기록에 가깝습니다. 그런 관점에서 Serilog는 꽤 오랫동안 손에 익은 선택지였습니다.

문자열 로그보다 구조화된 기록이 필요했습니다
일반적인 로그는 사람이 읽기 좋은 문장으로 남습니다.

사용자 로그인 실패: userId=1234, reason=password_mismatch
이런 로그도 당장은 충분해 보입니다. 하지만 운영 중 비슷한 로그가 수천 줄씩 쌓이면, 단순 문자열 검색만으로 원인을 찾기 어렵습니다. 특정 사용자만 확인하고 싶을 수도 있고, 실패 사유별로 건수를 보고 싶을 수도 있습니다. 요청 경로, 응답 시간, 예외 정보, 사용자 식별자 같은 값을 따로 묶어서 보고 싶을 때도 있습니다.

Serilog의 장점은 이 지점에서 드러납니다. Serilog는 메시지 안에 들어간 값을 단순 문자열로 합쳐버리지 않고, 이름이 붙은 속성으로 함께 기록할 수 있습니다.

Log.Information("Login failed for {UserId} because {Reason}", userId, reason);
이렇게 남기면 로그 문장은 사람이 읽을 수 있고, 동시에 UserId와 Reason은 검색하거나 필터링할 수 있는 값으로 남습니다. 나중에 Seq, Elasticsearch, Application Insights 같은 도구와 연결했을 때 이 차이가 꽤 크게 느껴집니다.

Serilog를 쓰면 로그의 목적지가 유연해집니다
Serilog에서 로그를 어디로 보낼지는 Sink라는 개념으로 정리합니다. 콘솔에 출력할 수도 있고, 파일로 남길 수도 있고, Seq나 Elasticsearch 같은 로그 수집 도구로 보낼 수도 있습니다.

개발 중에는 콘솔 로그가 편합니다. 로컬에서 바로 확인할 수 있기 때문입니다. 반면 운영 환경에서는 파일이나 별도의 로그 서버에 남겨야 할 때가 많습니다. 중요한 것은 이 구성이 코드 곳곳에 흩어지지 않는다는 점입니다. 보통은 appsettings.json 같은 설정 파일에 정리해두고, 환경에 따라 다르게 적용합니다.

{
  "Serilog": {
    "MinimumLevel": {
      "Default": "Information",
      "Override": {
        "Microsoft": "Warning",
        "System": "Warning"
      }
    },
    "Enrich": [ "FromLogContext" ],
    "WriteTo": [
      { "Name": "Console" },
      {
        "Name": "File",
        "Args": {
          "path": "logs/app-.log",
          "rollingInterval": "Day"
        }
      }
    ]
  }
}
이런 방식은 혼자 서비스를 운영할 때 특히 편합니다. 개발 환경에서는 자세히 보고, 운영 환경에서는 필요한 수준만 남기도록 조정할 수 있습니다. 로그 설정을 바꾸기 위해 매번 코드를 수정하는 부담도 줄어듭니다.

Enrich는 운영 중 맥락을 남기는 데 도움이 됩니다
서비스 장애를 확인할 때 가장 답답한 순간은 로그 한 줄만으로는 상황을 알 수 없을 때입니다. 예외 메시지는 남아 있지만 어떤 요청에서 발생했는지 모를 때가 있습니다. 사용자는 누구였는지, 어떤 화면이나 API를 거쳤는지, 어떤 서버에서 실행됐는지 알 수 없으면 원인을 좁히는 데 시간이 오래 걸립니다.

Serilog의 Enrich 기능은 이런 맥락을 로그에 덧붙이는 역할을 합니다. 예를 들어 요청 ID, 사용자 ID, 머신 이름, 스레드 ID 같은 정보를 함께 남길 수 있습니다.

using (LogContext.PushProperty("UserId", userId))
{
    Log.Information("User requested novel draft list");
}
이렇게 남긴 값은 해당 흐름 안에서 발생하는 로그에 함께 붙습니다. 나중에 특정 사용자나 특정 요청을 기준으로 로그를 묶어볼 수 있습니다. 단순히 “오류가 났다”가 아니라 “어떤 맥락에서 오류가 났는지”를 볼 수 있는 것입니다.

ASP.NET Core에서는 요청 로그 정리가 편합니다
ASP.NET Core 프로젝트에서는 Serilog.AspNetCore를 함께 사용하는 경우가 많습니다. 기본 요청 로그를 Serilog의 흐름으로 정리할 수 있고, UseSerilogRequestLogging()을 통해 HTTP 요청 단위의 로그를 남길 수 있습니다.

builder.Host.UseSerilog((context, services, configuration) => configuration
    .ReadFrom.Configuration(context.Configuration)
    .ReadFrom.Services(services)
    .Enrich.FromLogContext());

app.UseSerilogRequestLogging();
요청 로그가 정리되면 운영 중 확인해야 할 기본 정보가 훨씬 안정적으로 남습니다. 어떤 API가 느린지, 어떤 경로에서 오류가 자주 나는지, 특정 시간대에 요청이 몰리는지 살펴보기 쉬워집니다. 큰 시스템이 아니더라도 이런 기록은 나중에 서비스를 다듬는 기준이 됩니다.

제가 Serilog를 사용할 때 신경 쓰는 기준
Serilog를 쓴다고 해서 로그가 자동으로 좋아지는 것은 아닙니다. 오히려 아무 기준 없이 많이 남기면 나중에 더 찾기 어려운 기록이 됩니다. 그래서 저는 몇 가지 기준을 두고 사용하려고 합니다.

첫째, 문자열 보간보다 메시지 템플릿을 사용합니다.

// 피하고 싶은 방식
Log.Information($"Order {orderId} completed in {elapsedMs}ms");

// 선호하는 방식
Log.Information("Order {OrderId} completed in {ElapsedMs}ms", orderId, elapsedMs);
두 번째 방식은 OrderId와 ElapsedMs가 속성으로 남습니다. 나중에 검색과 집계가 쉬워집니다.

둘째, 로그 레벨을 너무 가볍게 쓰지 않습니다. Information은 서비스 흐름을 이해하는 데 필요한 기록에 사용하고, Warning은 당장 실패는 아니지만 확인이 필요한 상황에 사용합니다. Error는 실제로 처리가 실패했거나 사용자가 영향을 받을 수 있는 경우에 남기는 편이 좋습니다.

셋째, 민감한 정보는 로그에 남기지 않습니다. 이메일, 전화번호, 토큰, 결제 정보, 비밀번호 같은 값은 운영 편의를 위해 남기기 시작하면 나중에 더 큰 위험이 됩니다. 로그는 문제 해결을 돕는 기록이어야지, 개인정보 저장소가 되어서는 안 됩니다.

넷째, 운영자가 실제로 볼 수 있는 위치에 로그를 둡니다. 아무리 좋은 로그를 남겨도 확인하기 어렵다면 의미가 줄어듭니다. 작은 서비스라면 파일 로그와 콘솔만으로도 시작할 수 있습니다. 규모가 커지거나 추적이 어려워지면 Seq 같은 도구를 붙여 구조화된 검색 환경을 만드는 식으로 단계적으로 늘리는 편이 현실적입니다.

작은 서비스일수록 로그가 더 중요할 때가 있습니다
큰 조직에서는 모니터링, 알림, 장애 대응 체계가 따로 마련되어 있는 경우가 많습니다. 하지만 혼자 만드는 서비스에서는 그런 체계를 처음부터 모두 갖추기 어렵습니다. 그렇다고 문제가 생겼을 때 감으로만 대응할 수는 없습니다.

저는 작은 서비스일수록 최소한의 로그 기준이 필요하다고 느낍니다. 사용자가 어떤 흐름에서 막혔는지, 특정 기능이 실제로 호출되고 있는지, 예외가 반복되는 구간은 어디인지 확인할 수 있어야 합니다. Serilog는 이 기준을 너무 무겁지 않게 시작할 수 있게 도와줍니다.

특히 메리톡톡처럼 창작 흐름을 돕는 서비스를 만들 때는 사용자의 작업 흐름을 방해하지 않는 안정성이 중요합니다. 기능이 많아지는 것보다, 문제가 생겼을 때 원인을 찾아 다시 이어갈 수 있는 구조가 먼저일 때가 있습니다. 로그는 그 구조를 받쳐주는 가장 기본적인 기록입니다.

마무리
Serilog는 닷넷에서 많이 쓰이는 로깅 라이브러리입니다. 하지만 제게는 단순히 유명해서 쓰는 도구라기보다, 서비스를 오래 운영하기 위해 필요한 기록 방식을 정리해주는 도구에 가깝습니다.

로그는 개발자의 습관처럼 보이지만, 실제로는 운영자의 태도와도 연결됩니다. 문제가 생겼을 때 원인을 찾을 수 있게 남기는 것, 나중에 다시 읽어도 상황을 이해할 수 있게 정리하는 것, 필요한 정보와 남기면 안 되는 정보를 구분하는 것. 이런 작은 기준들이 쌓이면 서비스는 조금 더 오래 버틸 수 있습니다.

아직 모든 프로젝트에 완벽한 로깅 구조를 갖추고 있는 것은 아닙니다. 다만 닷넷 프로젝트를 다시 만들 때마다 Serilog를 먼저 떠올리는 이유는 분명합니다. 혼자 만들고 운영하는 입장에서, 나중의 저를 도와주는 기록을 남기기에 꽤 현실적인 도구이기 때문입니다.

OIDC와 OPA로 접근 제어를 분리해보는 닷넷 설계 기록

Roslyn — Sun, 5 Jul 2026 20:41:35 +0900

서비스를 만들다 보면 로그인보다 더 오래 고민하게 되는 부분이 있습니다. 바로 “이 사용자가 어디까지 할 수 있는가”를 판단하는 일입니다.

처음에는 닷넷 코드 안에 Admin, Manager, User 같은 역할을 기준으로 조건문을 넣으면 충분해 보입니다. 하지만 서비스가 조금씩 커지고, 조직이나 기능 단위의 규칙이 늘어나면 접근 제어는 금방 복잡해집니다.

저는 이 문제를 보면서 인증과 인가를 조금 더 분리해서 생각해보고 싶었습니다. 사용자가 누구인지 확인하는 일은 OIDC가 맡고, 그 사용자가 특정 자원에 접근할 수 있는지 판단하는 일은 OPA가 맡는 구조입니다. 닷넷 애플리케이션은 두 세계를 연결하는 얇은 통로가 됩니다.

OIDC는 사용자가 누구인지 확인합니다
OIDC, 즉 OpenID Connect는 OAuth 2.0 위에 인증 계층을 얹은 표준입니다. 쉽게 말하면 “이 사용자가 누구인지”를 애플리케이션이 신뢰할 수 있는 방식으로 전달받기 위한 구조입니다.

닷넷에서는 ASP.NET Core의 OpenID Connect 인증 미들웨어를 사용하면 비교적 익숙한 방식으로 붙일 수 있습니다. 예를 들어 Microsoft Entra ID, Keycloak, Auth0, Duende IdentityServer 같은 OIDC Provider를 통해 로그인하고, 애플리케이션은 ID Token이나 Access Token에 담긴 클레임을 읽습니다.

여기서 중요한 것은 OIDC가 모든 접근 제어 문제를 해결해주지는 않는다는 점입니다. OIDC는 사용자의 식별자, 이메일, 조직, 역할, 그룹 같은 정보를 전달해줄 수 있습니다. 하지만 “이 사용자가 이 문서의 수정 버튼을 눌러도 되는가”, “이 프로젝트의 결제 정보를 볼 수 있는가” 같은 판단은 결국 서비스의 정책에 가깝습니다.

처음에는 이 판단을 컨트롤러나 서비스 코드 안에 직접 넣게 됩니다. 문제는 시간이 지나면서 이 규칙들이 흩어진다는 점입니다. 어떤 규칙은 컨트롤러에 있고, 어떤 규칙은 서비스 레이어에 있고, 어떤 규칙은 데이터 조회 조건에 숨어 있게 됩니다. 나중에 접근 정책을 바꾸려면 코드를 따라다니며 확인해야 합니다.

OPA는 접근 판단을 밖으로 꺼냅니다
OPA, Open Policy Agent는 정책을 코드 바깥에서 판단할 수 있게 해주는 정책 엔진입니다. 정책은 Rego라는 선언형 언어로 작성합니다. 애플리케이션은 OPA에게 “이 입력값에서 접근을 허용해도 되는가”를 물어보고, OPA는 정책에 따라 결과를 돌려줍니다.

이 구조의 장점은 접근 제어 규칙이 애플리케이션 코드 안에 흩어지지 않는다는 데 있습니다. 닷넷 서비스는 사용자의 클레임, 요청 경로, HTTP 메서드, 대상 리소스의 소유자 정보 같은 데이터를 모아 OPA에 전달합니다. OPA는 그 데이터를 기준으로 허용 여부를 판단합니다.

예를 들어 이런 흐름을 생각할 수 있습니다.

사용자가 OIDC Provider를 통해 로그인합니다.
ASP.NET Core 애플리케이션은 토큰을 검증하고 사용자 클레임을 확보합니다.
요청이 들어오면 닷넷 미들웨어나 AuthorizationHandler가 접근 판단에 필요한 정보를 구성합니다.
닷넷 애플리케이션은 OPA의 REST API로 정책 판단을 요청합니다.
OPA가 허용 여부와 필요한 사유를 응답합니다.
닷넷 애플리케이션은 그 결과에 따라 요청을 계속 처리하거나 차단합니다.
이렇게 보면 OPA는 로그인 시스템이 아니라 판단 시스템에 가깝습니다. OIDC가 “누구인가”를 알려주고, OPA는 “그래서 지금 이 행동을 해도 되는가”를 판단합니다.

닷넷에서는 어디에 붙일 수 있을까
ASP.NET Core에서는 몇 가지 위치에서 OPA를 붙일 수 있습니다. 가장 단순한 방식은 커스텀 미들웨어를 만드는 것입니다. 요청이 컨트롤러에 도달하기 전에 사용자 클레임과 요청 정보를 모아 OPA에 질의하고, 허용되지 않으면 403 응답을 반환합니다.

조금 더 닷넷다운 방식으로는 IAuthorizationHandler를 구현할 수 있습니다. 이 경우 기존의 [Authorize] 특성과 정책 기반 권한 부여 흐름을 유지하면서, 실제 판단만 OPA에 위임할 수 있습니다. 이미 ASP.NET Core Authorization을 사용하고 있다면 이 방식이 구조적으로 더 자연스럽습니다.

입력값은 대략 이런 형태가 될 수 있습니다.

{
  "user": {
    "sub": "user-123",
    "roles": ["writer"],
    "tenant_id": "tenant-a"
  },
  "request": {
    "method": "POST",
    "path": "/api/articles/100/publish"
  },
  "resource": {
    "owner_id": "user-123",
    "status": "draft"
  }
}
OPA 정책은 이 입력값을 보고 판단합니다. 예를 들어 글의 소유자이고, 상태가 초안이며, 사용자의 역할이 작성자라면 발행을 허용할 수 있습니다. 반대로 소유자가 아니거나 이미 발행된 글이라면 차단할 수 있습니다.

이 방식은 역할 기반 접근 제어만으로 부족할 때 특히 유용합니다. 실제 서비스에서는 역할보다 맥락이 더 중요할 때가 많습니다. 같은 작성자라도 자기 글은 수정할 수 있지만 다른 사람의 글은 수정할 수 없고, 같은 관리자라도 특정 테넌트 안에서만 권한을 가져야 할 수 있습니다.

운영 관점에서 조심해야 할 부분
물론 OPA를 붙인다고 해서 구조가 자동으로 단순해지는 것은 아닙니다. 오히려 작은 서비스에서는 과한 선택이 될 수도 있습니다. 정책 엔진이 하나 더 생긴다는 것은 배포, 모니터링, 장애 대응 지점도 하나 늘어난다는 뜻입니다.

그래서 처음부터 모든 권한을 OPA로 옮기기보다는, 바뀔 가능성이 높고 코드 안에 흩어지기 쉬운 정책부터 분리하는 편이 현실적입니다. 예를 들어 관리자 메뉴 접근처럼 단순한 규칙은 닷넷의 기본 Authorization만으로도 충분할 수 있습니다. 반면 테넌트, 리소스 소유자, 상태, 요청 행위가 함께 얽히는 규칙은 OPA로 분리했을 때 장점이 생깁니다.

또 하나 중요한 점은 OPA에 전달하는 입력값의 기준을 잘 정리하는 일입니다. 정책 엔진은 입력값이 정확할 때만 좋은 판단을 할 수 있습니다. 사용자 클레임을 그대로 믿을 것인지, 데이터베이스에서 리소스 정보를 다시 조회할 것인지, 토큰에 들어 있는 역할과 내부 권한 테이블이 다를 때 무엇을 우선할 것인지 같은 기준이 필요합니다.

성능도 고려해야 합니다. 모든 요청마다 OPA를 호출하면 네트워크 비용이 생깁니다. 사이드카로 붙일지, 별도 정책 서버로 둘지, 일부 결과를 캐시할지, 실패했을 때 기본적으로 차단할지 허용할지 같은 운영 기준도 함께 정해야 합니다.

제가 이 구조에 관심을 두는 이유
제가 OIDC와 OPA 조합에 관심을 두는 이유는 최신 기술을 더 붙이고 싶어서라기보다, 역할과 정책이 커지는 순간을 미리 상상하게 되었기 때문입니다. 혼자 서비스를 만들고 운영하다 보면 기능을 빨리 붙이는 것만큼이나 나중에 고치기 쉬운 구조가 중요해집니다.

특히 닷넷 기반의 서비스는 인증과 권한 부여 기능이 이미 잘 정리되어 있습니다. 그래서 모든 것을 바깥으로 밀어내기보다, 닷넷이 잘하는 부분은 그대로 두고, 자주 바뀌는 정책 판단만 분리하는 방식이 더 현실적으로 느껴집니다.

OIDC는 신원을 확인하는 안정적인 입구가 되고, OPA는 정책을 기록하고 검증하는 별도의 공간이 됩니다. 닷넷 애플리케이션은 그 사이에서 요청의 맥락을 정리해 전달합니다. 이 구분이 명확해지면 나중에 정책을 바꿀 때도 “코드 어디에 조건문을 넣었더라” 하고 헤매는 시간을 줄일 수 있습니다.

마무리
접근 제어는 처음에는 단순한 권한 체크처럼 보이지만, 서비스가 오래 갈수록 운영의 언어에 가까워집니다. 누가, 어떤 상황에서, 어떤 자원에, 어떤 행동을 할 수 있는지를 정리하는 일이기 때문입니다.

OPA와 OIDC를 닷넷에 붙이는 구조는 모든 서비스의 정답은 아닙니다. 다만 인증과 정책 판단을 분리해두면, 나중에 서비스가 커졌을 때 규칙을 더 차분하게 다룰 수 있습니다. 지금 제 기준에서는 이것이 “멋진 아키텍처”라기보다, 혼자 운영하는 서비스에서 복잡도를 한곳에 모아두기 위한 실험에 가깝습니다.

아직 이 구조를 어디까지 적용하는 것이 적당한지는 더 실험해봐야 합니다. 다만 이번 기록은 닷넷 서비스에서 접근 제어를 바라볼 때, 로그인과 권한 판단을 같은 덩어리로 보지 않기 위한 기준점으로 남겨두고 싶습니다.

닷넷 어스파이어를 다시 살펴보게 된 이유

Roslyn — Sun, 5 Jul 2026 20:40:36 +0900

닷넷 어스파이어를 다시 살펴보게 된 이유
요즘 애플리케이션은 예전처럼 하나의 프로젝트만 실행해서 끝나는 경우가 점점 줄어들고 있습니다. API 서버가 있고, 프론트엔드가 있고, 데이터베이스와 Redis 같은 외부 서비스가 붙습니다. 여기에 로그, 설정, 배포 환경까지 생각하면 작은 서비스도 금방 여러 조각으로 나뉩니다.

닷넷 어스파이어는 이런 분산 애플리케이션을 개발할 때 필요한 실행, 연결, 관찰 흐름을 한곳에서 정리해주는 도구입니다. Microsoft 문서에서는 Aspire를 여러 언어를 지원하는 로컬 개발 시점의 오케스트레이션 도구 체인으로 설명하고 있습니다. 단순히 닷넷 프로젝트를 하나 더 만드는 도구라기보다, 여러 구성 요소를 함께 실행하고 살펴보기 위한 작업 환경에 가깝습니다.

혼자 만드는 서비스에서 더 필요한 도구
혼자 서비스를 만들다 보면 기능 자체보다 운영 흐름이 더 부담스러울 때가 있습니다. 로컬에서 여러 프로젝트를 켜고, 포트를 맞추고, 환경 변수를 확인하고, 로그를 따로 열어보는 일은 생각보다 자주 집중을 끊습니다.

어스파이어는 이런 부분을 조금 더 구조화해줍니다. AppHost를 통해 애플리케이션의 구성 요소를 코드로 정의하고, 대시보드에서 각 서비스의 상태와 로그, 트레이스 정보를 확인할 수 있습니다. 개발 중에 무엇이 실행되고 있는지, 어디에서 문제가 생겼는지 보는 일이 조금 더 쉬워집니다.

기술 과시보다 운영 가능한 구조
제가 이 도구를 흥미롭게 보는 이유는 최신 기술이라는 점 때문만은 아닙니다. 오히려 작은 서비스를 오래 운영하려면 복잡한 구조를 얼마나 덜 흔들리게 만들 수 있는지가 더 중요하다고 느끼기 때문입니다.

어스파이어는 모든 문제를 대신 해결해주는 정답은 아닙니다. 하지만 서비스가 여러 조각으로 나뉘기 시작했을 때, 그 조각들을 어떻게 함께 실행하고 관찰할지에 대한 기준점을 만들어줍니다. 특히 닷넷 기반으로 API, 백그라운드 작업, 데이터 저장소를 함께 다루는 프로젝트라면 한 번쯤 살펴볼 만합니다.

지금의 기준점
아직 제 프로젝트에 어디까지 적용하는 것이 적당한지는 더 실험해봐야 합니다. 작은 서비스에 너무 많은 구조를 얹으면 오히려 부담이 될 수 있기 때문입니다.

다만 분명한 것은 있습니다. 혼자 만드는 서비스일수록 실행과 관찰의 흐름은 더 단순해야 합니다. 문제가 생겼을 때 바로 확인할 수 있어야 하고, 새로운 기능을 붙일 때 기존 구성과 충돌하지 않아야 합니다.

닷넷 어스파이어는 그런 관점에서 다시 살펴볼 만한 도구입니다. 이번 기록은 사용법을 깊게 정리한 글이라기보다, 앞으로 작은 서비스의 개발 환경을 어떻게 정리할지 고민하기 위한 출발점에 가깝습니다.

React에서 서버 상태를 다루기 편하게 해주는 TanStack Query

Roslyn — Sun, 5 Jul 2026 20:39:28 +0900

React로 화면을 만들다 보면 생각보다 많은 시간이 API 데이터를 다루는 데 쓰입니다. 데이터를 불러오고, 로딩 상태를 표시하고, 실패했을 때의 처리를 만들고, 다시 새로고침해야 하는 시점을 고민합니다. 처음에는 단순한 fetch 코드로 충분해 보이지만, 화면이 늘어나면 이 흐름이 금방 복잡해집니다.

TanStack Query, 예전 이름으로 React Query는 이 문제를 꽤 잘 정리해주는 도구입니다. React 애플리케이션에서 비동기 데이터, 특히 서버에서 가져오는 데이터를 가져오고, 캐싱하고, 동기화하고, 업데이트하는 일을 도와줍니다.

클라이언트 상태와 서버 상태는 다릅니다
React에서 상태라고 하면 보통 useState나 Zustand 같은 상태 관리 도구를 떠올립니다. 하지만 서버에서 가져온 데이터는 일반적인 화면 상태와 조금 다릅니다.

예를 들어 모달이 열려 있는지, 입력창에 어떤 값이 들어 있는지는 클라이언트 안에서만 관리하면 됩니다. 반면 게시글 목록, 사용자 정보, 알림 개수 같은 데이터는 서버에 원본이 있습니다. 화면에 보이는 값은 그 원본을 잠시 가져와 보여주는 캐시에 가깝습니다.

TanStack Query는 이 서버 상태를 다루는 데 집중합니다. 단순히 API를 호출하는 도구라기보다, 가져온 데이터의 생명주기를 관리해주는 도구에 가깝습니다.

반복되는 코드를 줄여줍니다
직접 API 호출 코드를 작성하면 보통 loading, error, data 상태를 따로 관리하게 됩니다. 같은 패턴이 여러 화면에 반복되고, 캐시를 직접 관리하려면 더 복잡해집니다.

TanStack Query를 사용하면 useQuery 훅으로 데이터를 가져오고, 로딩 여부나 에러 상태, 성공한 데이터를 함께 받을 수 있습니다. 같은 query key를 사용하는 데이터는 캐시로 관리되기 때문에, 이미 가져온 데이터를 다시 활용하기도 쉽습니다.

또한 서버 데이터를 변경하는 작업은 mutation으로 분리할 수 있습니다. 예를 들어 게시글을 등록하거나 삭제한 뒤, 관련 목록을 다시 불러오게 만드는 흐름도 Query Invalidation이라는 방식으로 정리할 수 있습니다.

작은 프로젝트에서도 장점이 있습니다
TanStack Query는 큰 서비스에서만 필요한 도구처럼 보일 수 있습니다. 하지만 작은 프로젝트에서도 장점이 있습니다. API 데이터 처리 방식이 일정해지기 때문입니다.

혼자 서비스를 만들 때는 새로운 기능을 빠르게 붙이는 것도 중요하지만, 나중에 다시 열어봤을 때 구조를 이해할 수 있어야 합니다. TanStack Query를 사용하면 “서버에서 가져온 데이터는 query로 관리한다”는 기준이 생깁니다. 이 기준 하나만으로도 코드가 덜 흩어집니다.

특히 목록, 상세, 저장, 삭제 같은 화면이 반복되는 관리자 페이지나 작은 SaaS 형태의 서비스에서는 체감이 큽니다. 매번 로딩 상태와 새로고침 시점을 직접 고민하지 않아도 되기 때문입니다.

그래도 모든 상태를 맡기는 도구는 아닙니다
TanStack Query를 사용할 때 주의할 점도 있습니다. 이 도구는 서버 상태를 다루는 데 강하지만, 모든 클라이언트 상태를 대신하는 도구는 아닙니다. 입력 폼의 임시 값, UI 토글, 화면 안에서만 쓰이는 상태는 여전히 React의 기본 상태나 다른 상태 관리 도구가 더 단순할 수 있습니다.

또 하나는 query key를 잘 정리해야 한다는 점입니다. 캐시는 query key를 기준으로 관리되기 때문에, 키 이름이 제각각이면 나중에 무효화하거나 다시 불러오는 흐름이 복잡해질 수 있습니다.

결국 TanStack Query를 잘 쓰려면 “이 데이터의 원본이 어디에 있는가”를 먼저 생각해야 합니다. 원본이 서버에 있다면 query로 관리하고, 화면 안에서만 의미가 있다면 로컬 상태로 두는 식입니다.

마무리
TanStack Query는 React에서 서버 데이터를 다루는 반복 작업을 줄여주는 실용적인 도구입니다. 데이터를 가져오고, 캐싱하고, 다시 동기화하고, 변경 후 관련 데이터를 갱신하는 흐름을 한 가지 방식으로 정리해줍니다.

저는 이런 도구가 작은 서비스에도 꽤 잘 맞는다고 느낍니다. 기능이 많아질수록 API 호출 코드는 자연스럽게 흩어지기 쉬운데, TanStack Query는 그 흐름을 다시 모아주는 기준이 됩니다.

물론 도구 하나가 설계를 대신해주지는 않습니다. 하지만 서버 상태와 클라이언트 상태를 구분하는 습관을 만들어준다는 점에서, React 프로젝트를 오래 관리하려는 사람에게는 한 번쯤 제대로 써볼 만한 선택지라고 생각합니다.

EF Core Code First와 AI 코딩 도구의 궁합을 다시 봅니다

Roslyn — Sun, 5 Jul 2026 20:38:24 +0900

닷넷으로 작은 서비스를 만들다 보면 데이터베이스 작업이 생각보다 자주 발목을 잡습니다. 테이블을 먼저 설계하고, 그에 맞춰 모델을 만들고, 다시 API 코드를 연결하는 흐름은 익숙하지만 손이 많이 갑니다. 그래서 요즘은 Entity Framework Core의 Code First 방식이 다시 편하게 느껴집니다.

특히 VS Code에서 Codex나 Claude Code 같은 AI 코딩 도구를 함께 사용할 때, Code First 방식은 궁합이 꽤 좋습니다. 이유는 단순합니다. 데이터 구조가 C# 코드 안에 먼저 표현되기 때문입니다. AI 도구 입장에서도 엔티티 클래스, DbContext, 설정 코드, 마이그레이션 흐름을 한 프로젝트 안에서 읽고 이해하기가 좋습니다.

Code First는 데이터 구조를 코드로 남기는 방식입니다
EF Core는 닷넷 개발자가 데이터베이스를 .NET 객체로 다룰 수 있게 도와주는 ORM입니다. 복잡한 데이터 접근 코드를 많이 줄여주고, 여러 데이터베이스 공급자와 함께 사용할 수 있습니다.

Code First 방식에서는 먼저 C# 클래스로 엔티티를 정의합니다. 예를 들어 Post, User, Comment 같은 클래스를 만들고, DbContext에 DbSet으로 연결합니다. 그 다음 EF Core 마이그레이션을 통해 이 모델의 변화가 데이터베이스 스키마로 반영됩니다.

공식 문서에서도 EF Core 마이그레이션은 데이터 모델의 변경 사항에 맞춰 데이터베이스 스키마를 점진적으로 업데이트하는 기능으로 설명합니다. 실제 프로젝트에서는 기능이 늘어나면서 속성이 추가되거나 관계가 바뀌기 때문에, 이 흐름이 꽤 자연스럽습니다.

VS Code와 AI 도구는 코드 중심 흐름을 잘 따라옵니다
Codex의 VS Code 확장은 IDE 안에서 코드를 읽고, 수정하고, 실행하는 코딩 에이전트로 사용할 수 있습니다. Claude Code 역시 코드베이스를 이해하고 기능 구현, 버그 수정, 개발 작업 자동화를 돕는 도구로 안내되어 있습니다.

이런 도구들은 데이터베이스 안쪽을 직접 바라보기보다, 현재 열려 있는 프로젝트의 코드와 명령어 흐름을 기반으로 작업할 때 더 편합니다. EF Core Code First는 이 점에서 잘 맞습니다. 테이블 설계가 C# 클래스와 설정 코드로 표현되어 있으니, AI에게 “이 엔티티에 상태 값을 추가하고 마이그레이션까지 만들어줘”처럼 요청하기가 쉽습니다.

물론 AI가 만든 결과를 그대로 믿으면 안 됩니다. 데이터베이스 변경은 되돌리기 어려운 경우가 있기 때문에, 마이그레이션 파일과 생성된 SQL은 사람이 직접 확인해야 합니다. 그래도 초안을 만들고 반복 작업을 줄이는 면에서는 도움이 됩니다.

dotnet CLI 덕분에 흐름이 단순해졌습니다
VS Code에서 닷넷 개발을 할 때 중요한 장점은 대부분의 작업을 CLI로 처리할 수 있다는 점입니다. EF Core 도구는 마이그레이션 생성, 데이터베이스 업데이트 같은 설계 시점 작업을 .NET CLI로 수행할 수 있습니다.

예를 들어 엔티티를 수정한 뒤에는 dotnet ef migrations add 명령으로 변경 이력을 만들고, dotnet ef database update 명령으로 데이터베이스에 반영할 수 있습니다. 이 흐름은 AI 코딩 도구와도 잘 맞습니다. 명령어가 명확하고, 결과물이 파일로 남고, 변경 내용을 Git diff로 확인할 수 있기 때문입니다.

Visual Studio의 강한 도구 지원도 여전히 좋지만, VS Code 기반 작업은 가볍고 반복이 빠릅니다. 특히 작은 서비스나 개인 프로젝트에서는 에디터, 터미널, AI 도구, Git diff만으로도 꽤 안정적인 개발 흐름을 만들 수 있습니다.

궁합이 좋은 이유는 책임 경계가 보이기 때문입니다
AI 코딩 도구를 잘 쓰려면 프로젝트의 책임 경계가 코드에 드러나야 합니다. EF Core Code First는 이 점에서 장점이 있습니다. 엔티티는 데이터 구조를 표현하고, DbContext는 데이터베이스 연결과 모델 구성을 담당하며, 마이그레이션은 구조 변경 이력을 남깁니다.

이렇게 역할이 나뉘어 있으면 AI에게 작업을 맡길 때도 요청이 구체적이 됩니다. “게시글에 공개 여부를 추가해줘”, “조회용 DTO에는 작성자 이름만 포함해줘”, “마이그레이션 이름은 AddPostVisibility로 만들어줘”처럼 말할 수 있습니다. 요청이 구체적일수록 결과를 검토하기도 쉬워집니다.

저는 이 부분이 Code First와 AI 도구의 가장 큰 접점이라고 봅니다. AI가 모든 설계를 대신해주는 것이 아니라, 이미 코드 안에 드러난 구조를 따라 반복 작업을 빠르게 처리해주는 방식입니다.

그래도 기준은 사람이 잡아야 합니다
Code First가 편하다고 해서 모든 데이터베이스 설계를 가볍게 다뤄도 되는 것은 아닙니다. 인덱스, 관계, 삭제 정책, nullable 여부, 마이그레이션 순서 같은 부분은 여전히 사람이 판단해야 합니다. 특히 운영 중인 서비스에서는 마이그레이션 하나가 실제 데이터에 영향을 줄 수 있습니다.

AI 도구도 마찬가지입니다. Codex나 Claude Code는 좋은 보조자가 될 수 있지만, 프로젝트의 기준을 대신 정해주지는 않습니다. 어떤 이름을 쓸지, 어떤 관계를 허용할지, 어느 시점에 DB 변경을 배포할지는 결국 운영자가 결정해야 합니다.

그래서 저는 이 조합을 “자동 개발”이라기보다 “검토 가능한 초안을 빠르게 만드는 흐름”에 가깝게 보고 있습니다. 코드는 AI가 도와서 빠르게 만들 수 있지만, 기준과 책임은 여전히 사람에게 남습니다.

마무리
EF Core Code First, VS Code, Codex나 Claude Code 같은 AI 코딩 도구는 서로 잘 맞는 편입니다. 데이터 구조가 C# 코드로 표현되고, 마이그레이션은 파일로 남으며, CLI 명령으로 흐름을 반복할 수 있기 때문입니다.

작은 서비스를 혼자 만들고 운영하는 입장에서는 이런 단순한 흐름이 꽤 중요합니다. 복잡한 도구를 많이 붙이기보다, 코드로 구조를 남기고, AI에게 반복 작업을 맡기고, 사람은 변경 내용을 검토하는 방식이 현실적입니다.

결국 좋은 궁합은 도구가 똑똑해서만 생기는 것이 아닙니다. 사람이 이해할 수 있는 구조로 프로젝트를 정리해두었을 때, AI 도구도 그 구조를 따라 더 잘 도와줄 수 있습니다. EF Core의 Code First 방식은 그런 점에서 지금의 닷넷 개발 흐름과 잘 어울리는 선택지라고 느낍니다.

MediatR 유료화를 보며 CQRS를 다시 생각했습니다

Roslyn — Sun, 5 Jul 2026 20:36:53 +0900

CQRS 패턴을 닷넷에서 이야기할 때 MediatR은 거의 자연스럽게 함께 언급되곤 했습니다. Command와 Query를 나누고, Controller나 Minimal API endpoint에서는 요청만 보내고, 실제 처리는 Handler에 맡기는 구조가 익숙했기 때문입니다.

저도 이 흐름이 꽤 마음에 들었습니다. 기능이 늘어날수록 Controller가 비대해지는 것을 막을 수 있고, 요청 단위로 코드를 나누면 나중에 다시 열어봤을 때 흐름을 따라가기 쉬웠습니다. 특히 혼자 서비스를 만들고 운영할 때는 “이 기능이 어디에 있지?”를 빨리 찾는 것이 생각보다 중요합니다.

CQRS는 거창한 구조라기보다 역할을 나누는 방식입니다
CQRS는 Command Query Responsibility Segregation의 줄임말입니다. 말은 조금 무겁지만, 기본 생각은 단순합니다. 데이터를 바꾸는 요청과 데이터를 조회하는 요청을 구분하자는 것입니다.

예를 들어 게시글을 등록하는 작업은 Command에 가깝습니다. 반대로 게시글 목록을 읽어오는 작업은 Query에 가깝습니다. 이렇게 나누면 코드의 목적이 분명해집니다. 이 코드는 상태를 바꾸는 코드인지, 단순히 읽어오는 코드인지가 파일 이름과 구조에서 바로 드러납니다.

여기에 중재자 패턴을 더하면 호출하는 쪽과 처리하는 쪽의 연결이 느슨해집니다. API는 “이 요청을 처리해 주세요”라고만 말하고, 실제 Handler를 찾아 실행하는 일은 중재자가 맡습니다. MediatR은 이 역할을 닷넷에서 아주 편하게 제공해준 대표적인 라이브러리였습니다.

MediatR의 라이선스 변화는 한 번쯤 생각해볼 계기가 됐습니다
최근 MediatR은 13.0.0 버전부터 라이선스 정책이 바뀌었습니다. 공식 안내에 따르면 MediatR 13.0.0 이후 버전은 Lucky Penny Software의 상업 라이선스 대상이며, 그 이전 버전은 기존 오픈소스 라이선스 조건이 유지됩니다. 현재 NuGet 기준 최신 MediatR은 14.x 계열까지 올라와 있습니다.

이 변화 자체를 좋다거나 나쁘다고 단정하고 싶지는 않습니다. 오픈소스 유지에도 비용과 시간이 들고, 오랫동안 널리 쓰인 라이브러리가 지속 가능한 방식을 찾는 것은 자연스러운 일입니다. 다만 사용하는 입장에서는 이제 “그냥 늘 쓰던 패키지니까 넣는다”에서 한 번 더 멈춰 생각하게 됩니다.

특히 작은 서비스나 개인 프로젝트에서는 의존성을 하나 추가하는 일도 운영의 일부입니다. 라이선스, 업데이트, 보안, 장기 유지보수까지 함께 따라옵니다. 그래서 MediatR의 변화는 단순히 비용 문제가 아니라, 이 정도 구조를 꼭 외부 라이브러리에 맡겨야 하는가를 다시 묻게 만들었습니다.

요즘 닷넷에서는 직접 구현도 크게 어렵지 않습니다
예전에는 이런 구조를 직접 만들려면 DI 컨테이너나 리플렉션 처리 때문에 신경 쓸 일이 많았습니다. 하지만 지금의 닷넷은 기본 의존성 주입 기능이 꽤 강해졌습니다. ASP.NET Core는 기본적으로 IServiceProvider와 IServiceCollection 기반의 DI 컨테이너를 제공하고, 서비스 수명 관리나 생성자 주입도 자연스럽게 사용할 수 있습니다.

.NET 8 이후에는 Keyed Services도 공식적으로 제공됩니다. 같은 인터페이스의 여러 구현을 키로 구분해 등록하고 가져오는 방식입니다. 물론 CQRS용 중재자를 만들 때 반드시 Keyed Services가 필요한 것은 아니지만, 닷넷의 기본 DI가 예전보다 훨씬 표현력이 좋아졌다는 점은 분명합니다.

간단한 CQRS 구조라면 직접 만드는 것도 어렵지 않습니다. IRequest, IRequestHandler 같은 인터페이스를 만들고, Dispatcher가 IServiceProvider를 통해 알맞은 Handler를 찾아 실행하도록 구성하면 됩니다. 여기에 필요한 공통 로깅이나 트랜잭션 처리는 프로젝트 상황에 맞게 조금씩 붙이면 됩니다.

직접 만든다는 것은 모든 기능을 다시 만들겠다는 뜻은 아닙니다
물론 MediatR이 해주던 모든 기능을 직접 다시 만들겠다는 뜻은 아닙니다. MediatR은 요청/응답, 알림, 파이프라인 동작, 예외 처리 등 여러 기능을 안정적으로 제공해왔습니다. 이미 그 기능들을 깊게 사용하고 있다면 계속 사용하는 편이 더 현실적일 수 있습니다.

다만 많은 프로젝트에서는 MediatR의 모든 기능을 쓰지 않습니다. Command 하나 보내고 Handler 하나 실행하는 정도로만 사용하는 경우도 많습니다. 그런 상황이라면 작은 Dispatcher를 직접 두는 편이 오히려 더 단순할 수 있습니다. 외부 패키지의 변화에 덜 흔들리고, 우리 프로젝트에 필요한 만큼만 유지하면 되기 때문입니다.

저는 이 지점이 중요하다고 느꼈습니다. 직접 구현은 라이브러리를 부정하는 선택이 아닙니다. 지금 내 서비스 규모에서 필요한 추상화가 어디까지인지를 다시 정리하는 일에 가깝습니다.

마무리
MediatR의 유료화는 닷넷 개발자들에게 작은 불편함이자, 동시에 좋은 점검 기회가 된 것 같습니다. 그동안 너무 자연스럽게 추가하던 의존성이 정말 필요한지, 아니면 지금의 닷넷 기본 기능만으로도 충분한지 돌아보게 만들었기 때문입니다.

제 기준에서는 단순한 CQRS와 중재자 패턴 정도라면 이제 직접 구현해서 사용하는 것도 충분히 현실적인 선택입니다. 닷넷의 기본 DI가 좋아졌고, 작은 서비스에서는 필요한 만큼만 단순하게 가져가는 편이 오래 운영하기에 더 편할 때가 있습니다.

결국 선택은 프로젝트의 크기보다 운영 방식에 달려 있습니다. 이미 MediatR의 풍부한 기능을 잘 쓰고 있다면 유지하는 것이 맞고, 단순한 요청 분리만 필요하다면 직접 구현도 좋은 선택이 될 수 있습니다. 이번 기록은 어느 한쪽을 정답으로 정하기보다, 의존성을 추가하기 전에 한 번 더 생각해보자는 기준에 가깝습니다.