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

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

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

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

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

React로 화면을 만들다 보면 생각보다 많은 시간이 API 데이터를 다루는 데 쓰입니다. 데이터를 불러오고, 로딩 상태를 표시하고, 실패했을 때의 처리를 만들고, 다시 새로고침해야 하는 시점을 고민합니다. 처음에는 단순한 fetch 코드로 충분해 보이지만, 화면이 늘어나면 이 흐름이 금방 복잡해집니다. TanStack Query, 예전 이름으로 React Query는 이 문제를 꽤 잘 정리해주는 도구입니다. React 애플리케이션에서 비동기 데이터, 특히 서버에서 가져오는 데이터를 가져오고, 캐싱하고, 동기화하고, 업데이트하는 일을 도와줍니다. 클라이언트 상태와 서버 상태는 다릅니다 React에서 상태라고 하면 보통 useState나 Zustand 같은 상태 관리 도구를 떠올립니다. 하지만 서버에서 가..

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

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

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

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

React와 Vue를 다시 비교해보며 정리한 기준

프론트엔드 기술을 고를 때마다 React와 Vue는 자주 비교 대상에 올라옵니다. 둘 다 오래 사용되어 왔고, 생태계도 충분히 성숙했습니다. 그래서 이제는 어느 쪽이 더 뛰어난지보다, 지금 만들고 있는 서비스의 성격에 어느 쪽이 더 잘 맞는지를 보는 편이 더 현실적이라고 느낍니다. 2026년 6월 기준으로 React는 19.2 계열, Vue는 3.5 계열을 기준으로 보면 됩니다. 버전 숫자만 보면 둘 다 이미 안정적인 단계에 들어와 있습니다. 새로운 프로젝트에서 선택할 때는 최신 기능 자체보다, 팀이나 개인이 얼마나 오래 유지보수할 수 있는지가 더 중요해졌습니다. React는 생태계와 유연성이 강점입니다 React는 라이브러리에 가깝습니다. 화면을 구성하는 핵심 방식은 제공하지만, 라우팅, 상태 관리, ..

아토믹 디자인이 더 이상 유행하지 않는 이유를 생각해보았습니다

메리톡톡을 리팩토링하면서, 예전에 많이 썼던 아토믹 디자인 패턴이 떠올랐습니다. 한때는 React 컴포넌트를 atom, molecule, organism으로 나누는 것이 무척 체계적으로 느껴졌는데, 지금은 이 패턴에 대해 더 이상 이야기하는 사람을 만나기 어렵습니다. 왜 그럴까 하는 생각이 들어, 이번 기회에 정리해보기로 했습니다. 유행하던 시절 아토믹 디자인은 UI를 가장 작은 단위(atom)로 쪼개고, 이를 조합해 molecule, organism, template, page 순으로 구성하는 방법론입니다. 재사용성을 높이고, 디자인 시스템과 개발 컴포넌트를 일치시키는 데 강점이 있었습니다. 한동안 React 생태계에서 널리 참고되었고, 저도 몇몇 프로젝트에 적용해보면서 그 장점을 체감했습니다. 실무에..

닷넷 개발자가 본 Next.js — 최근 방식으로 시작해본 기록

저는 21년째 닷넷 개발자로 일하고 있습니다. 오래 전에 Next.js를 사용하다가 문득 최근의 Next.js는 어떻게 변했을지 궁금해졌습니다. 공식 문서가 워낙 잘 되어 있지만, 오래전에 접하고 잊고 있었던 제 눈에는 생소한 부분이 많았습니다. 이 글은 그냥 시작해보고 정리한 기록입니다. 완벽한 튜토리얼이 아니라, 개발자가 React 생태계의 최신 도구를 접했을 때 느낀 점과 선택한 방식을 공유하려고 합니다. 왜 지금 Next.js인가 제가 손놓기 직전 Next.js는 App Router를 기본으로 채택하면서 구조가 크게 바뀌었습니다. Pages Router에서 App Router로의 전환은 단순한 업데이트가 아니라, 파일 시스템 기반 라우팅과 서버 컴포넌트를 기본으로 삼는 패러다임 변화였습니다. 저는..

리액트 시작하기

React / TypeScript 프로젝트 코딩 규칙 가이드 본 문서는 프로젝트의 일관된 아키텍처와 유지보수성 향상을 위한 작업 규칙 정의서입니다. 새로운 기능을 추가할 때는 아래 구조와 규칙을 반드시 준수하며, 기존 파일의 지역 관례를 최우선으로 적용합니다. 1. 프로젝트 구조 (Directory Architecture) 역할 중심의 디렉터리 분리를 통해 스파게티 코드를 방지하고, 특정 도메인 로직과 UI 컴포넌트의 결합도를 낮춥니다. 경로 (Path) 역할 및 준수 사항 src/main.tsx 애플리케이션의 진입점입니다. 전역 CSS, i18n, 인증 Provider, React Query Provider 등 시스템 전역에 영향을 주는 컨텍스트 및 환경 설정만 배치합니다. src/App.tsx 전체 ..

메리톡톡을 다시 만들면서, 서비스가 스스로 상태를 점검하고 문제를 발견한 뒤, 필요하다면 개선 제안까지 할 수 있는 시스템이 필요하다는 생각이 들었습니다.단순히 장애 여부를 감시하는 모니터링 수준이 아니라, 사람의 개입을 최소화하면서도 위험한 작업은 자동으로 실행되지 않도록 막아주는 구조가 필요했습니다. 그래서 백그라운드 서비스를 몇 가지 계층으로 나누어 설계하기로 했습니다.전체 구조전체 구조는 크게 세 가지 계열로 구분했습니다.Watcher 계열, Control 계열, Communication 계열입니다. 각각의 역할은 명확하게 분리했습니다.WatcherWatcher는 말 그대로 관찰만 담당합니다.Site Health Watcher, Log Analyzer, GitHub Watcher, Content ..