프론트엔드를 리액트로 만들다 보면 어느 순간 인증 처리를 어디까지 맡겨야 하는지 고민하게 됩니다. 화면을 그리는 일은 리액트가 잘합니다. 상태를 다루고, 컴포넌트를 나누고, 사용자와 빠르게 상호작용하는 것도 리액트의 장점입니다. 하지만 인증은 조금 다릅니다. 토큰을 어디에 저장할지, 쿠키는 어떻게 다룰지, API 호출 권한은 어디서 확인할지, 새로고침 후 세션은 어떻게 유지할지 같은 문제들이 따라옵니다. 처음에는 단순해 보이지만, 실제 서비스를 운영하려고 하면 생각보다 신경 쓸 부분이 많아집니다. 그래서 요즘 다시 관심을 두고 있는 구조가 BFF입니다. Backend for Frontend의 줄임말인데, 이름 그대로 프론트엔드를 위한 백엔드 계층을 하나 두는 방식입니다. 저는 이 구조를 “서버사이드가 프..

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

닷넷 프로젝트에서 Serilog를 자주 쓰는 이유 닷넷 프로젝트를 만들다 보면 로깅 도구를 고르는 순간이 자주 옵니다. 작은 기능을 만들 때는 Console.WriteLine만으로도 충분해 보이지만, 서비스가 실제로 운영되기 시작하면 이야기가 달라집니다. 문제가 생겼을 때 “어디에서”, “어떤 값으로”, “누가”, “얼마나 자주” 발생했는지 확인할 수 있어야 하기 때문입니다. 저는 닷넷으로 서비스를 만들고 운영하면서 Serilog를 자주 사용합니다. 대단히 특별한 이유라기보다, 혼자서도 상황을 추적하고 정리하기에 현실적인 도구라고 느껴왔기 때문입니다. 로그는 개발 중 확인용 메시지가 아니라, 운영 중인 서비스를 이해하기 위한 기록에 가깝습니다. 그런 관점에서 Serilog는 꽤 오랫동안 손에 익은 선택지..

먼저 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..

닷넷의 발전 속도는 감히 따라가기 힘들 만큼 빠르게 변화하고 있습니다. 클린 아키텍처에 대한 이야기야 이전에도 많이 나왔지만, 닷넷은 아직 어려움을 겪고 있는 이들에게 좀 더 명확한 방향성을 제시해 주고 있습니다. 본 포스트에서 작성된 텍스트는 모두 다음 영상을 기초로 작성되었습니다. 영상에서는 클린 아키텍처에 대해 그 의존성을 도메인 중심으로 구성함으로써 전통적으로 데이터베이스를 중심으로 소프트웨어를 설계하는 것보다 도메인 중심으로 설계하는 것이 더 유리하다는 점을 강조하고 있습니다. 이를 통해 인프라 의존성을 최소화하고 소프트웨어를 테스트하거나 의존성을 변경하는 것이 쉬워집니다. 클린 아키텍처는 도메인 주도 설계를 따르고, 비즈니스 로직이 복잡한 경우에 적합하다고 이야기 하고 있습니다. 영상에서 이야..

API access 관련 내용을 다음과 같이 정리합니다. 원문링크 : https://docs.duendesoftware.com/identityserver/v7/quickstarts/3_api_access/ (1) 새롭게 추가할 스코프를 정의해 줍니다. (중요! 원문에서 누락된 부분) public static IEnumerable IdentityResources => new IdentityResource[] { new IdentityResources.OpenId(), new IdentityResources.Profile(), new IdentityResource() { Name = "verification", UserClaims = new List { JwtClaimTypes.Email, JwtClaimT..

이번에는 Scope를 추가해 보도록 합시다. (1) api 프로젝트의 Program.cs 파일을 수정해서 인가정책을 추가해 줍니다. using System.Security.Claims; var builder = WebApplication.CreateBuilder(args); builder.Services.AddAuthentication() .AddJwtBearer(options => { options.Authority = "https://localhost:5001"; options.TokenValidationParameters.ValidateAudience = false; }); builder.Services.AddAuthorization(options => { options.AddPolicy("ApiS..

(1) IdentityServer가 추가되어있는 솔루션에 새로운 API 프로젝트를 추가해 줍니다. dotent new webapi -n {프로젝트명} --no-openapi (2) 해당 프로젝트를 솔루션에 추가해 줍니다. dotnet sln add ./src/{프로젝트폴더} (3) Microsoft.AspNetCore.Authentication.JwtBearer 라이브러리를 Nuget에서 설치해 줍니다. dotnet add ./{프로젝트폴더} package Microsoft.AspNetCore.Authentication.JwtBearer (4) 추가한 프로젝트의 Program.cs 를 다음과 같이 수정합니다. using System.Security.Claims; var builder = WebApplic..

본 내용은 다음 원문을 정리한 글입니다. 원문링크 : https://docs.duendesoftware.com/identityserver/v7/quickstarts/1_client_credentials/ 예제 프로젝트 생성 순서 * 본문의 작성 기준은 .net8을 기준으로 작성되었습니다. (1) 다음 명령으로 Duende.IdentityServer.Templates를 설치해 줍니다. dotnet new install Duende.IdentityServer.Templates (2) 빈 솔루션 하나를 생성해 줍니다. dotnet new sln -n {솔루션명칭} (3) 빈 IdentityServer 템플릿을 추가합니다. dotnet new isempty -n IdentityServer (4) 솔루션에 프로젝..

이제 Efcore를 설치할 차례인데, 정식 명칭은 EntityFramework Core로, 나름 Microsoft의 철학이 녹아든 ORM입니다. 초기부터 Code First, Db First 등과 같이 다양한 방법으로 DB를 제어하는 기능해왔으며, 현재는 이 Entity framework와 유사한 접근 방식을 Node.js에 TypeORM이나 Sequelize 같은 orm 들이 따라하고 있습니다. Db 테이블을 하나의 Entity와 매칭하여 관리하는 것은 굉장히 큰 메리트를 제공하며, Dotnet의 linq, lambda와 함께 "아름다운 코드"를 생성하는 극한의 매력을 선사합니다. 저는 2014년도에 처음 이 Entity framework를 접했고, 당시에 java 코드가 C# 코드랑 거의 똑같다고 생..