핵심 인사이트 (3줄 요약)
- 본질: MSA(Microservice Architecture)에서 API 게이트웨이는 외부 접점을 단일화하고, 서비스 메시(Service Mesh)는 서비스 간 내부 통신을 안전하고 관찰 가능하게 만드는 두 개의 독립적인 역할이다.
- 가치: 서킷 브레이커(Circuit Breaker)와 BFF(Backend for Frontend) 패턴은 MSA의 분산 장애가 전파되는 것을 막고, 클라이언트별 최적 인터페이스를 제공한다.
- 판단 포인트: 서비스 메시의 사이드카(Sidecar) 방식은 코드 변경 없이 mTLS와 트래픽 제어를 구현하지만, 오버헤드와 운영 복잡성이 증가한다.
Ⅰ. 개요 및 필요성
MSA에서 수십~수백 개의 서비스가 서로 통신할 때 세 가지 문제가 발생한다:
- 외부 클라이언트 복잡성: 각 서비스의 IP/포트를 직접 알아야 하는 문제
- 횡단 관심사(Cross-Cutting Concerns): 인증, 로깅, 암호화를 모든 서비스에 중복 구현하는 문제
- 분산 장애 전파: 한 서비스 장애가 전체로 확산되는 Cascading Failure 문제
이 세 문제를 각각 API 게이트웨이, 서비스 메시, 서킷 브레이커가 담당한다.
- 📢 섹션 요약 비유: MSA는 여러 식당이 모인 푸드코트다. API 게이트웨이는 안내 데스크이고, 서비스 메시는 식당 간 음식 전달 시스템이며, 서킷 브레이커는 한 식당이 망해도 다른 식당이 피해 안 받는 방화벽이다.
Ⅱ. 아키텍처 및 핵심 원리
MSA 통신 계층 구조:
┌─────────────────────────────────────────────────────────────┐
│ 외부 클라이언트 (모바일/웹/IoT) │
└───────────────────────┬─────────────────────────────────────┘
↓
┌───────────────────────────────────────────────────────────┐
│ API Gateway (Kong / AWS API GW / Nginx) │
│ 인증/인가 │ 라우팅 │ Rate Limiting │ LB │ 로깅 │
└──────┬─────────────┬────────────────┬──────────────────────┘
↓ ↓ ↓
┌──────────┐ ┌──────────┐ ┌──────────────┐
│ 주문 서비스│ │ 재고 서비스│ │ 결제 서비스 │
│ +Sidecar │ │ +Sidecar │ │ +Sidecar │
└──────────┘ └──────────┘ └──────────────┘
↑ 서비스 메시 (Istio/Linkerd): 사이드카 간 mTLS + 트래픽 관리
| 기술 | 역할 | 구현 위치 | 대표 도구 |
|---|---|---|---|
| API Gateway | 외부 진입점, 인증, 라우팅 | 클러스터 엣지 | Kong, AWS API GW |
| Service Mesh | 내부 서비스 간 통신 제어 | 각 Pod 사이드카 | Istio, Linkerd |
| Circuit Breaker | 장애 전파 차단 | 서비스 내 또는 사이드카 | Hystrix, Resilience4j |
| BFF (Backend for Frontend) | 클라이언트별 API 최적화 | 클라이언트 전용 API 계층 | 커스텀 서비스 |
사이드카(Sidecar) 프록시: 각 서비스 Pod에 Envoy 프록시 컨테이너를 자동 주입. 서비스 코드 변경 없이 mTLS(mutual TLS, 상호 인증 암호화), 재시도, 타임아웃, 트래픽 분산 등을 투명하게 처리.
- 📢 섹션 요약 비유: 사이드카는 모터사이클 옆에 붙은 사이드카처럼, 본체(서비스)를 바꾸지 않고 기능(보안/모니터링)을 옆에 탑재하는 방식이다.
Ⅲ. 비교 및 연결
서킷 브레이커(Circuit Breaker) 상태 전환:
- Closed(정상): 요청 정상 전달, 실패율 모니터링
- Open(차단): 실패율 임계값 초과 시 즉시 오류 반환(폴백), 서비스 호출 차단
- Half-Open(시험): 일정 시간 후 소수 요청 허용, 성공 시 Closed 복귀
BFF(Backend for Frontend) vs GraphQL:
| 구분 | BFF | GraphQL |
|---|---|---|
| 방식 | 클라이언트별 전용 API 계층 | 단일 유연한 쿼리 언어 |
| 오버패칭 해결 | ✓ (클라이언트 맞춤 응답) | ✓ (필드 선택 쿼리) |
| 복잡도 | 서비스 수 증가 | 스키마/리졸버 관리 |
| 적합 상황 | 클라이언트 종류 다양 | 단일 유연 API 필요 |
- 📢 섹션 요약 비유: 서킷 브레이커는 전기 회로 차단기다 — 과부하(실패율 초과)가 걸리면 자동으로 끊어 전체 시스템을 보호하고, 안전해지면 다시 연결한다.
Ⅳ. 실무 적용 및 기술사 판단
기술사 시험 판단 포인트:
- API 게이트웨이(외부)와 서비스 메시(내부)의 역할을 명확히 분리하여 설명한다.
- 서킷 브레이커 세 가지 상태(Closed/Open/Half-Open)와 전환 조건을 그림으로 제시한다.
- BFF 도입 근거를 "오버패칭/언더패칭 해소"와 "클라이언트별 최적화"로 구체적으로 기술한다.
실무 시나리오: 모바일 앱과 웹의 API 응답이 달라야 하는 상황 — 모바일은 배터리/대역폭 제약으로 필드 최소화, 웹은 상세 데이터 필요. BFF 패턴으로 모바일 BFF, 웹 BFF를 분리 운영하면 각 클라이언트 요구사항에 최적화된 API를 독립적으로 발전시킬 수 있다.
- 📢 섹션 요약 비유: BFF는 맞춤 메뉴판이다 — 어린이 메뉴, 어른 메뉴, 다이어트 메뉴를 따로 만들어 각 손님이 불필요한 항목을 보지 않도록 한다.
Ⅴ. 기대효과 및 결론
MSA 패턴을 체계적으로 적용하면:
- 확장성: 각 서비스 독립 스케일링, 병목 서비스만 선택적 확장
- 장애 격리: 서킷 브레이커로 단일 서비스 장애가 전체 시스템으로 확산 방지
- 보안 강화: 서비스 메시 mTLS로 서비스 간 통신 자동 암호화
- 개발 속도: 팀별 독립 배포, 마이크로서비스당 독립 CI/CD
그러나 MSA는 분산 시스템의 복잡성(트랜잭션, 네트워크 지연, 디버깅 어려움)을 수반하므로, 서비스 규모와 팀 성숙도를 고려한 점진적 전환이 중요하다.
- 📢 섹션 요약 비유: MSA는 여럿이 나눠 일하는 방식이다. 혼자보다 빠르지만 소통 비용(네트워크 복잡성)이 생긴다. API 게이트웨이와 서비스 메시는 그 소통을 체계적으로 관리하는 방법이다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| 서킷 브레이커 (Circuit Breaker) | Resilience4j, 장애 격리, 폴백 · 507 |
| mTLS (mutual TLS) | 상호 인증, 서비스 메시, Istio · 508 |
| CQRS / 사가 패턴 (Saga Pattern) | 분산 트랜잭션, 이벤트 드리븐 · 506 |
| BFF (Backend for Frontend) | 오버패칭, 클라이언트 최적화 API · 531 |
| Kubernetes (K8s) | Pod, 사이드카 주입, Service · 502 |
📈 관련 키워드 및 발전 흐름도
[Resilience4j · 장애 격리] → [마이크로서비스 · API 게이트웨이] → [Pod · 사이드카 주입]
👶 어린이를 위한 3줄 비유 설명
- API 게이트웨이는 학교 정문 경비원이에요 — 누가 들어오는지 확인하고, 어느 교실(서비스)로 가야 하는지 안내해줘요.
- 서비스 메시는 교실 간 우편 시스템이에요 — 편지(요청)가 암호화되어 전달되고, 전달 기록도 자동으로 남아요.
- 서킷 브레이커는 과전류 차단기예요 — 한 교실에 전기가 너무 많이 흐르면 자동으로 끊어서 다른 교실을 지켜요.