ebson

API Gateway 패턴을 공부하다 보면 결국 다음 질문으로 이어지게 됩니다. 실제 서비스에서는 Gateway를 어떻게 설계해야 할까입니다. 개념적으로는 클라이언트와 마이크로서비스 사이에 하나의 진입점을 둔다고 설명할 수 있지만, 실제 운영 환경에서는 훨씬 더 많은 설계 판단이 필요합니다. 특히 Spring Cloud Gateway를 사용해 API Gateway를 구성할 경우 보안 정책, 트래픽 제어, 장애 대응, 로그 관측 같은 다양한 요구사항을 함께 고려해야 합니다. Gateway는 단순한 라우터가 아니라 서비스 경계에서 트래픽을 통제하는 인프라 역할을 하기 때문입니다. 이 글에서는 Spring Cloud Gateway를 기반으로 실제 프로젝트에서 사용할 수 있는 설계 방식을 정리해 보려고 합니다...

마이크로서비스 아키텍처를 처음 접했을 때 가장 먼저 느끼는 변화 중 하나는 서비스 간 통신 방식입니다. 모놀리스 환경에서는 내부 메서드 호출로 해결되던 문제들이 마이크로서비스에서는 네트워크 호출로 바뀝니다. 단순히 서비스가 분리되는 것처럼 보이지만 실제로는 시스템의 복잡도가 다른 차원으로 이동하게 됩니다. 특히 클라이언트와 백엔드 서비스 간 통신 구조를 설계할 때 많은 팀이 비슷한 문제를 경험합니다. 서비스 수가 증가하면서 클라이언트는 여러 개의 서비스와 직접 통신해야 하고, 인증이나 로깅 같은 공통 기능이 여러 서비스에 중복 구현되는 상황이 발생합니다. 이러한 문제를 해결하기 위해 등장한 대표적인 아키텍처 패턴이 API Gateway입니다. 이 글에서는 API Gateway 패턴이 등장하게 된 배경을 ..

4편에서 Saga의 실패 복구 전략을 다루었습니다. 보상 트랜잭션과 재시도, 멱등성, 다단계 실패 격리까지 설계하면 Saga의 에러핸들링 체계가 갖춰집니다. 그런데 이 체계가 실제 운영 환경에서 의도대로 동작하고 있는지를 어떻게 확인할 수 있을까요? 보상 트랜잭션이 정상적으로 실행되었는지, Dead Letter Topic에 메시지가 쌓이고 있지는 않은지, 어떤 단계에서 지연이 발생하는지를 파악하려면 체계적인 관찰가능성(Observability)이 필요합니다.또한 여러 Saga가 동시에 실행되면서 같은 데이터에 접근할 때 발생할 수 있는 데이터 이상현상도 고려해야 합니다. 이 글에서는 Saga 시스템의 관찰가능성 설계, 동시 Saga 실행 시의 데이터 정합성 심화 주제, 그리고 시리즈 전체를 관통하는 설계..

3편에서 Outbox 패턴으로 DB 변경과 메시지 발행의 원자성을 보장하는 방법을 살펴보았습니다. Outbox 패턴은 메시지가 "반드시 발행된다"는 보장을 제공하지만, 발행된 메시지를 수신한 서비스가 처리에 실패하면 어떻게 되는지에 대해서는 답하지 않습니다. Saga는 여러 서비스에 걸쳐 단계적으로 진행되는 흐름이므로, 어느 단계에서든 실패가 발생할 수 있고, 이에 대한 체계적인 복구 전략이 필요합니다.이 글에서는 Saga 실패 시 보상 트랜잭션으로 되돌리거나 재시도로 전진하는 두 가지 복구 방향을 정리하고, 재시도의 전제 조건인 멱등성, 그리고 실패 메시지를 격리하는 구체적인 전략을 다룹니다.복구의 두 가지 방향Saga의 특정 단계에서 실패가 발생했을 때, 복구 방향은 크게 두 가지입니다. 이전 단계를..

2편에서 Saga 패턴의 서비스 간 통신이 왜 비동기 메시징으로 설계되는지 살펴보았습니다. 비동기 메시징은 시간적 결합을 제거하고 장애 전파를 차단하여 Saga를 안정적으로 진행할 수 있게 합니다. 그런데 비동기 메시징을 도입하면 곧바로 마주치는 문제가 있습니다. 서비스가 자신의 데이터베이스를 업데이트하고 메시지 브로커에 이벤트를 발행하는 두 가지 작업을, 어떻게 원자적으로 처리할 것인가의 문제입니다.이 글에서는 이 문제의 본질인 이중 쓰기 문제(Dual Write Problem)를 정의하고, 이를 해결하는 Transactional Outbox 패턴의 구조와 Message Relay 구현 전략을 정리합니다.이중 쓰기 문제Saga의 각 단계에서 서비스는 두 가지 작업을 수행해야 합니다. 자신의 데이터베이스..

1편에서 MSA 환경의 분산 트랜잭션 문제와 동기식 해법들의 구조적 한계를 살펴보았습니다. ChainedTransactionManager는 부분 커밋 실패에 대한 보호 장치가 없었고, 2PC는 가용성과 확장성을 희생해야 했습니다. 이번 글에서는 이 문제에 대한 근본적인 대안인 Saga 패턴의 구조를 깊이 들여다보고, 왜 비동기 메시징이 Saga의 표준적인 통신 방식이 되는지 정리합니다.Saga 패턴이란Saga 패턴은 하나의 글로벌 트랜잭션 대신, 각 서비스의 로컬 트랜잭션을 순차적으로 연결하여 분산 데이터 정합성을 보장하는 패턴입니다. Microservices.io에서는 Saga를 다음과 같이 정의합니다."A saga is a sequence of local transactions. Each local ..

모놀리식 애플리케이션에서는 하나의 데이터베이스에 대해 @Transactional 하나면 ACID가 보장됩니다. 비즈니스 로직이 아무리 복잡해도 커밋과 롤백의 경계가 명확하고, 개발자가 트랜잭션 정합성을 의식하지 않아도 프레임워크가 이를 처리해 줍니다. 그런데 마이크로서비스 아키텍처(MSA)로 전환하면 이 전제가 무너집니다. 서비스마다 독립된 데이터베이스를 갖게 되면서, 하나의 비즈니스 작업이 여러 서비스에 걸칠 때 기존의 로컬 ACID 트랜잭션으로는 데이터 정합성을 보장할 수 없게 됩니다. 이 글에서는 이 문제가 왜 발생하는지, 그리고 이를 해결하려는 동기식 접근들이 왜 근본적인 한계를 갖는지 정리합니다. 트랜잭션 경계가 분리되는 순간모놀리스에서 MSA로 전환할 때 가장 먼저 마주치는 구조적 변화 중 ..

이 글은 RAG 아키텍처 발전사 시리즈의 다섯 번째이자 마지막 편입니다. 1편에서 Naive RAG의 단순한 Retrieve → Read 파이프라인으로 출발하여, 2편에서 Hybrid Search와 Reranker로 검색 품질을 높이고, 3편에서 Self-RAG와 CRAG로 자기 성찰과 교정 능력을 도입했으며, 4편에서 Ontology-Enhanced RAG로 도메인의 형식적 지식을 파이프라인에 심는 과정까지 살펴보았습니다. 이번 편에서는 그 여정의 2026년 3월 기준 현재 도달점인 4세대 Agentic RAG를 다룹니다.정적 파이프라인의 한계이 시리즈를 관통하는 하나의 흐름이 있습니다. 각 세대는 이전 세대의 명확한 한계에 대한 응답으로 등장했고, 그 한계의 상당 부분은 파이프라인이 사전에 설계된 정..