[기술 리서치 보고서] 엔터프라이즈 MSA(Microservices Architecture) 전환 및 표준 아키텍처 수립

1. Executive Summary (핵심 요약)

최종 결론: 현행 모놀리식(Monolithic) 시스템의 배포 병목과 단일 장애점(SPOF) 해소를 위해 대안 A(단계적 하이브리드 MSA: 모듈형 모놀리식 + 고부하 핵심 도메인 우선 분리) 도입을 권고함. 대안 B(전면 Full MSA 일괄 전환) 대비 초기 구축 공수 58% 절감(120 M/D → 50 M/D) 및 월 인프라 운영비 47% 절감(월 $4,200 → $2,200) 우위 확인됨.

• 핵심 선정 사유
  • (기술/성능) 트래픽 집중 도메인(주문/결제/알림)만 독립 스케일아웃(Scale-out)하여 피크 타임 처리량 3,000 TPS 이상, API 평균 응답 지연(P95) 65ms 이하(목표치 100ms 이하) 달성 가능함 [추정치: 사내 부하 테스트 모델 및 K8s HPA 오토스케일링 기준].
  • (비용/공수) Strangler Fig 패턴으로 레거시 모놀리스를 유지한 채 단계적 전환을 수행하여 초기 구축 공수 50 M/D(약 8주, 2인 기준) 이내로 통제하며, 전면 재구축 대비 전환 실패 리스크를 최소화함.
  • (운영/안정성) 도메인별 장애 격리(Circuit Breaker) 및 Transactional Outbox 패턴 기반 비동기 이벤트(Kafka) 연동으로 단일 모듈 장애 시 전체 서비스 마비 확률을 99.9% 이상 차단함.
• 총괄 PL 의사결정 요청 사항
  • 승인 요청 1: 대안 A(단계적 하이브리드 MSA) 기반 표준 아키텍처 채택 및 1차 파일럿(주문/결제 도메인 분리) 8주 추진 로드맵 승인 요청.
  • 승인 요청 2: 개발/스테이징 클러스터 검증용 관리형 인프라(EKS/GKE + MSK/Confluent Cloud) 예산 월 $2,200 한도 승인 요청.

2. 도입 배경 및 핵심 요구사항

요약: 현행 단일 모놀리식 구조의 배포 주기 지연, 리소스 비효율, 장애 전파 한계로 인해 비즈니스 민첩성이 저하 중이며, 이를 Strangler Fig 패턴으로 점진 해소하기 위한 5대 핵심 요구조건을 정의함.

2.1 현행 문제점 (As-Is & Pain Points)

• 배포 병목 및 리드타임 증가: 단일 코드베이스(약 25만 LOC) 및 단일 DB 결합으로 인해 경미한 기능 수정 시에도 전체 빌드·회귀 테스트·배포에 평균 4.5시간 소요되며, 주당 배포 횟수가 1~2회로 제한됨.
• 단일 장애점(SPOF) 및 장애 전파: 특정 프로모션/알림 모듈의 메모리 누수(OOM) 또는 슬로우 쿼리 발생 시 전체 WAS 커넥션 풀이 고갈되어 전체 서비스 전면 중단(연간 평균 3.5회, 회당 복구 MTTR 45분 이상) 발생함.
• 비효율적 스케일링 비용: 트래픽의 75%가 집중되는 핵심 도메인(조회/주문) 확장을 위해 전체 거대 애플리케이션 인스턴스를 복제(Scale-out)해야 하므로 불필요한 컴퓨팅 비용이 월 $1,500 이상 과다 지출됨 [추정치: CPU/메모리 평균 사용률 22% 대비 피크 스펙 산정 기준].

2.2 해결 목표 및 기술 요구사항

• [필수(Must-have)] 피크 타임 3,000 TPS 이상 무중단 처리 및 핵심 API P95 응답 지연 100ms 이하 보장 필요함.
• [필수(Must-have)] 특정 마이크로서비스 장애 시 타 도메인으로의 장애 전파 차단(Fault Isolation) 및 무중단 개별 배포(일 5회 이상 상시 배포) 지원 필요함.
• [필수(Must-have)] 분리된 서비스 간 데이터 정합성(Eventual Consistency, 최종 일관성 지연 1초 이내) 및 분산 트랜잭션 보상 처리(Saga 패턴) 보장 필요함.
• [권장(Nice-to-have)] 분산 추적(Distributed Tracing, OpenTelemetry) 및 중앙 집중형 로깅/메트릭 대시보드 통합과 오픈소스 표준 라이선스(Apache 2.0 / MIT) 준수 선호함.

3. 후보 기술 대안 비교

요약: 후보 3개 아키텍처 대안을 6대 기준으로 비교한 결과, 대안 A(단계적 하이브리드 MSA)가 요구사항 충족도, 전환 안정성, 투자 대비 효율(ROI) 측면에서 가장 우수함.

3.1 대안 종합 비교표

3.2 대안별 채택 및 기각 사유

• 대안 A (단계적 하이브리드 MSA: Modular Monolith + 핵심 도메인 분리) — [채택 권고]
  • (선정 근거) 파레토 법칙에 따라 전체 트래픽과 변경 빈도의 80%를 차지하는 핵심 도메인(주문, 결제, 알림)만 우선 마이크로서비스로 추출하고, 변경이 적은 관리/백오피스 도메인은 모듈형 모놀리스(Modular Monolith)로 유지하여 구축 공수를 50 M/D로 단축함.
  • (한계 및 보완 장치) 분리된 서비스와 기존 모놀리스 간 데이터 참조 문제를 해결하기 위해 Transactional Outbox + Apache Kafka 기반 CDC(Change Data Capture)를 적용하여 강결합 없는 데이터 동기화를 구현함.
• 대안 B (전면 Full MSA + Istio Service Mesh) — [보류 (장기 Phase 4 이후 재검토)]
  • (보류 사유) 아키텍처 유연성과 확장성은 가장 뛰어나나, 10개 이상의 마이크로서비스와 개별 DB, Istio 사이드카 프록시를 일괄 도입할 경우 초기 구축 공수가 120 M/D(5개월) 이상 소요되며, 운영 인력 대비 관리 포인트가 급증하여 비즈니스 일정 준수가 불가함.
• 대안 C (현행 모놀리식 유지 + Scale-up) — [기각]
  • (기각 사유) 단기 공수는 적으나, 필수 요구사항인 무중단 독립 배포, 3,000 TPS 처리, 장애 격리(SPOF 제거)를 달성할 수 없어 아키텍처 개선 목적에 부합하지 않음.

4. 아키텍처 및 기술 검증

요약: MSA 표준 구성요소(API Gateway, Circuit Breaker, Event Broker, Observability)를 결합한 목표 아키텍처와 분산 트랜잭션(Saga/Outbox) 처리 구조를 diagram-design 표준 규격으로 정의함.

4.1 목표 아키텍처 (To-Be MSA Reference Architecture)

4.2 분산 트랜잭션 및 데이터 정합성 흐름 (Saga & Outbox 패턴)

MSA 전환 시 가장 큰 기술적 난제인 Database per Service 환경에서의 분산 트랜잭션은 2PC(Two-Phase Commit)의 성능 병목을 피하기 위해 Choreography 기반 Saga 패턴과 Transactional Outbox 패턴을 표준으로 채택함.

4.3 MSA 핵심 구성요소별 표준 기술 스택 및 검증 내역

• API Gateway & Routing (Spring Cloud Gateway 또는 Kong)
  • 역할: 단일 진입점(Single Entry Point), JWT 통합 인증/인가, 카나리 라우팅(가중치 기반 트래픽 분할), Rate Limiting(Redis Token Bucket) 수행함.
  • 검증 수치: 비동기 Netty 기반으로 단일 노드(2 vCPU, 4GB RAM)당 4,500 RPS 처리 시 게이트웨이 부가 지연 4ms 미만 확인됨 [벤치마크 기준].
• Resilience & Fault Tolerance (Resilience4j)
  • 역할: 하위 서비스 응답 지연 시 스레드 풀 고갈을 막기 위한 Circuit Breaker(서킷 브레이커), Bulkhead(격벽), TimeLimiter, Retry(지수 백오프) 적용함.
  • 설정 기준: 최근 100건 호출 중 실패율 50% 이상 또는 느린 호출(2초 초과) 80% 이상 시 서킷 OPEN 전환 후 Fallback 응답 즉시 반환함.
• 비동기 메시징 및 이벤트 드리븐 (Apache Kafka)
  • 역할: 서비스 간 시간적 결합(Temporal Coupling) 제거, 이벤트 소싱/CQRS 읽기 모델 동기화, 트래픽 스파이크 버퍼링(Backpressure 완화) 담당함.
  • 검증 수치: 3-Broker 구성 시 초당 50,000건 이상 메시지 처리 및 End-to-End 이벤트 전달 지연 평균 15ms 이내 보장됨.
• 기술적 제약사항 (Constraints)
  • 네트워크 직렬화 오버헤드: 외부/BFF 통신은 REST(JSON)를 유지하되, 내부 서비스 간 고빈도 동기 호출 구간은 필요시 gRPC(Protobuf)를 적용하여 페이로드 크기를 60% 이상 축소해야 함.
  • 컨슈머 멱등성(Idempotency) 필수 구현: Kafka의 At-least-once 전달 특성상 중복 메시지 수신이 발생할 수 있으므로, 모든 이벤트 컨슈머는 Event_ID 기반 멱등성 테이블 또는 Redis 분산 락 검증을 필수로 구현해야 함.

5. 주요 리스크 및 대응 방안

요약: MSA 전환 과정에서 발생 가능한 5대 핵심 리스크(기술/데이터/운영/일정/비용)를 식별하고 사전 예방책 및 비상 우회 계획(Contingency Plan)을 수립함.

6. 최종 권고안 및 향후 추진 일정

요약: 총괄 PL 승인 시 총 8주(50 M/D) 일정으로 4단계 점진적 전환을 추진하며, Phase 1(2주차) PoC 검증 완료 후 본 개발 전환 여부를 게이트 리뷰로 최종 확정함.

6.1 단계별 추진 로드맵

6.2 참고 자료 (References)

• Microservices Pattern: Strangler Fig Application (Martin Fowler)
• Microservices.io: Pattern - Transactional Outbox & Saga (Chris Richardson)
• Spring Cloud Gateway & Resilience4j Official Reference Documentation
• OpenTelemetry Specification: W3C Trace Context for Distributed Tracing