개발 일상 | 백엔드 김승원의 실무 노트

들어가며"프론트엔드에서 필요한 데이터가 바뀔 때마다 API를 새로 만들어야 하나요?" 백엔드 개발자라면 이 질문에 공감하실 것입니다. 모바일 앱은 화면별로 필요한 데이터가 다르고, 웹은 또 다른 조합이 필요합니다. REST API로는 Over-fetching(불필요한 데이터까지 전달)과 Under-fetching(여러 API를 호출해야 원하는 데이터를 조합) 문제가 반복됩니다.GraphQL은 이 문제를 클라이언트가 필요한 데이터만 정확히 요청하는 방식으로 해결합니다. 하지만 GraphQL이 항상 REST보다 좋은 것은 아닙니다. 이 글에서는 Spring for GraphQL을 활용한 실전 구현부터 N+1 문제 해결, Subscription을 이용한 실시간 통신, 그리고 REST와 GraphQL을 언제 각..

들어가며마이크로서비스 아키텍처(MSA)에서 API Gateway는 클라이언트와 백엔드 서비스 사이의 단일 진입점(Single Entry Point) 역할을 합니다. MSA 아키텍처 완벽 가이드에서 기본 개념 확인하기 라우팅, 인증/인가, Rate Limiting, 로드밸런싱, 요청/응답 변환 등을 담당하며, 클라이언트가 개별 마이크로서비스를 직접 호출하지 않게 합니다.이 글에서는 Spring Cloud Gateway를 중심으로, 실무에서 필요한 라우팅 설정, 필터 체인, Redis 기반 Rate Limiter, Circuit Breaker 통합, 커스텀 필터 작성까지 심층적으로 다루겠습니다.API Gateway의 역할역할설명구현 방식라우팅요청 URL을 적절한 서비스로 전달Route Predicate인증/..

들어가며헥사고날 아키텍처(Hexagonal Architecture)는 Alistair Cockburn이 2005년에 제안한 아키텍처 패턴으로, 포트와 어댑터(Ports and Adapters)라고도 불립니다. 핵심 아이디어는 단순합니다: 비즈니스 로직(도메인)을 외부 기술(DB, HTTP, 메시지 큐 등)로부터 완전히 분리하는 것입니다. 이를 통해 도메인 로직은 순수하게 유지되고, 외부 기술이 변경되어도 도메인은 영향을 받지 않습니다.이 글에서는 전통적인 레이어드 아키텍처와의 비교부터, Spring Boot에서의 실제 패키지 구조 설계, 테스트 전략까지 실전적으로 다루겠습니다.왜 헥사고날 아키텍처인가?전통적인 레이어드 아키텍처의 문제// 전형적인 레이어드 아키텍처Controller → Service → ..

들어가며얼마 전 금요일 저녁, 기획자가 "주문 취소 후 환불까지 걸리는 리드타임을 절반으로 줄여달라"고 요청했습니다. 3년 동안 쌓인 OrderService 클래스를 열어보니 1,800줄이 넘었고, 환불 로직이 어느 메서드에 흩어져 있는지 파악하는 데만 20분이 걸렸습니다. 결국 수정은 2시간이었는데, "어디를 고쳐야 할지" 결정하는 데 반나절을 써야 했습니다.익숙한 장면 아닌가요? 서비스 계층은 해가 갈수록 비대해지고, 새 요구사항 하나를 넣으려면 먼저 다른 5개 메서드가 뭘 하는지 해독해야 합니다. 비즈니스 로직이 Service에 있는지 Util에 있는지, 아니면 JPA Entity의 setter 뒤에 숨어 있는지조차 불분명해집니다. 팀에 들어온 지 6개월 된 동료에게 "이 도메인 설명 좀 해달라"고..

MSA에서 Observability가 중요한 이유모놀리식 아키텍처에서는 하나의 애플리케이션 로그와 스택 트레이스만으로 대부분의 문제를 파악할 수 있었습니다. 하지만 MSA(Microservices Architecture) 환경에서는 수십에서 수백 개의 서비스가 네트워크를 통해 상호작용하므로, 단일 요청이 여러 서비스를 거치며 어디서 지연이 발생하고 어디서 오류가 났는지 추적하기가 극도로 어려워집니다.관측 가능성(Observability)은 시스템의 외부 출력(로그, 메트릭, 트레이스)을 통해 내부 상태를 이해할 수 있는 능력을 의미합니다. 이는 단순 모니터링을 넘어, 예측하지 못한 장애 상황에서도 문제의 근본 원인을 파악할 수 있게 해줍니다.Observability의 3축 (Three Pillars)Ob..

MSA에서 Observability가 중요한 이유모놀리식 아키텍처에서는 하나의 애플리케이션 로그와 스택 트레이스만으로 대부분의 문제를 파악할 수 있었습니다. 하지만 MSA(Microservices Architecture) 환경에서는 수십에서 수백 개의 서비스가 네트워크를 통해 상호작용하므로, 단일 요청이 여러 서비스를 거치며 어디서 지연이 발생하고 어디서 오류가 났는지 추적하기가 극도로 어려워집니다.관측 가능성(Observability)은 시스템의 외부 출력(로그, 메트릭, 트레이스)을 통해 내부 상태를 이해할 수 있는 능력을 의미합니다. 이는 단순 모니터링을 넘어, 예측하지 못한 장애 상황에서도 문제의 근본 원인을 파악할 수 있게 해줍니다.Observability의 3축 (Three Pillars)Ob..

CQRS란 무엇인가CQRS(Command Query Responsibility Segregation)는 시스템의 쓰기(Command)와 읽기(Query) 책임을 명확히 분리하는 아키텍처 패턴입니다. 전통적인 CRUD 아키텍처에서는 동일한 데이터 모델로 생성, 조회, 수정, 삭제를 모두 처리하지만, CQRS에서는 Command 모델과 Query 모델을 별도로 설계하고 최적화합니다.이 패턴은 Bertrand Meyer의 CQS(Command Query Separation) 원칙에서 발전한 것으로, Greg Young에 의해 체계화되었습니다. 읽기와 쓰기의 요구사항이 크게 다른 복잡한 도메인에서 특히 유용합니다.왜 CQRS가 필요한가전통적인 CRUD 아키텍처의 한계를 이해하면 CQRS의 필요성이 명확해집니다...

들어가며서비스가 성장하면서 코드베이스가 비대해지고, 배포 한 번에 전체 시스템이 흔들리는 경험을 해본 적 있으신가요? 많은 팀이 이 시점에서 MSA(Microservice Architecture) 전환을 고민합니다. 하지만 MSA는 단순히 서비스를 쪼개는 것이 아닙니다. 잘못 도입하면 모놀리식보다 더 복잡한 "분산 모놀리스"라는 최악의 상황을 만들 수도 있습니다.이 글에서는 모놀리식에서 MSA로 전환할 때 반드시 알아야 할 설계 원칙, 핵심 패턴, 그리고 실무에서 자주 겪는 함정까지 정리해 보겠습니다.1. MSA vs 모놀리식 아키텍처 비교모놀리식 아키텍처모놀리식은 하나의 배포 단위로 전체 애플리케이션이 구성되는 전통적인 방식입니다. 모든 비즈니스 로직, 데이터 접근 계층, UI가 단일 프로세스 안에서 ..