개요

MSA의 기술적 어려움은 결국 분산 시스템의 어려움과 동일함 네트워크는 불안정, 데이터는 서비스별로 분산, 한 번의 요청이 여러 프로세스를 통과하는 구조 특성상 실패와 지연이 쉽게 전파됨 리더급 실무 경험을 검증하려면 이 분산 시스템의 고통을 직접 다뤄본 흔적이 있는지 확인해야 함 아래는 실무 난이도가 높은 세 영역과 면접 시 검증 포인트, 실전형 답변 예시 정리

분산 트랜잭션과 데이터 정합성

핵심 맥락

  • 모놀리식에서는 단일 DB 트랜잭션으로 주문·결제·재고 감소를 한 번에 처리 가능
  • MSA에서는 주문 서비스 DB, 결제 서비스 DB, 재고 서비스 DB가 분리되어 원자적 커밋 불가
  • 일부 단계 성공 후 후속 단계 실패 시 이미 성공한 작업을 어떻게 보상할지 정의 필요

면접에서 확인할 질문

  • A, B, C 세 서비스가 관여하는 비즈니스 로직에서 A, B 성공 후 C 실패 시 정합성을 어떻게 맞췄는지
  • 이미 반영된 A, B 작업을 어떤 방식으로 되돌렸는지

좋은 답의 핵심

  • Saga 패턴 언급 필수
  • 두 가지 접근 중 하나를 명확히 설명
    • 오케스트레이션 방식 사용, 중앙 Saga 매니저가 A→B→C를 실행하고 실패 시 보상 트랜잭션 호출로 A, B 상태 되돌림
    • 코레오그래피 방식 사용, 각 단계가 이벤트 발행, 후속 서비스가 구독하여 처리, 최종 실패 이벤트를 기반으로 이전 단계들이 자체 보상 처리
  • 결과적 일관성 수용, 사용자 UX는 처리 중 상태 표시 후 최종 반영
  • 보상 트랜잭션의 멱등성 확보 언급이 있으면 신뢰도 상승
  • 이벤트 발행의 유실 방지를 위해 트랜잭셔널 아웃박스 같은 패턴을 고려했다는 언급 가능

나쁜 답의 신호

  • DB를 하나로 합쳐 해결 주장, 분산 모놀리식으로 회귀
  • 실패 API를 호출하면 끝 주장, 재시도 실패·네트워크 분할 상황 미고려
  • C의 안정성을 높여서 회피 주장, 장애 대비 전략 부재

주의와 베스트 프랙티스

  • 보상 트랜잭션은 비즈니스 의미가 있는 반대 작업으로 정의, 단순 롤백 환상이 아님
  • 중복 이벤트 수신 대비 멱등 처리 필수
  • 상태 전이가 많은 도메인은 오케스트레이터로 명시적 흐름 관리가 유리, 결합도를 낮추려면 코레오그래피 채택

서비스 간 통신과 장애 전파

핵심 맥락

  • 단일 화면 렌더링에 다수 서비스 호출이 연쇄적으로 묶이는 구조
  • 하위 서비스 지연이 상위 서비스로 전파되어 전체 지연·장애로 비화하는 캐스케이딩 실패 위험 상존

면접에서 확인할 질문

  • A가 B를 동기 호출할 때 B가 무응답이거나 극도로 느려지면 A는 어떻게 동작해야 하는지
  • 장애가 전체로 확산되지 않도록 어떤 방어선을 두었는지

좋은 답의 핵심

  • 서킷 브레이커 적용 언급, 실패율이 임계치를 넘으면 회로를 Open하여 즉시 실패 처리로 자원 보호
  • 타임아웃 기본값 설정, 장시간 블로킹 회피
  • 재시도 적용 시 백오프와 지터 사용, 단시간 일시 오류 회복 기대, 과도한 동시 재시도 폭주 방지
  • 폴백 경로 정의, 캐시 데이터 노출 또는 기능 강등으로 사용자 영향 완화
  • 호출 건격리 필요 시 벌크헤드나 연결 풀 격리 선택 언급 시 가산점

나쁜 답의 신호

  • B 응답을 무기한 대기 주장
  • 알람 전파만으로 해결 주장, 전파 차단 부재
  • 단순 증설로 해결 주장, 구조적 회복탄력성 미확보

주의와 베스트 프랙티스

  • 타임아웃은 상·하위 서비스 SLA를 고려해 예산화, 체인 전체 합성 지연 관리
  • 재시도는 멱등 연산에 한해 제한적으로 적용
  • 서킷 상태 전이는 메트릭 기반, Half-Open에서 소량 탐침으로 회복 확인

분산 모니터링과 로깅

핵심 맥락

  • 하나의 사용자 요청이 A→B→D→E 등 다단계를 통과하는 구조에서 특정 오류의 원인을 끝까지 추적하기 어려움
  • 로그가 서비스·인스턴스별로 분산되어 개별 파일 탐문으로는 재현 불가

면접에서 확인할 질문

  • 특정 사용자 결제 실패 요청 흐름을 여러 서비스에 걸쳐 어떻게 추적했는지
  • 대규모 로그에서 해당 트랜잭션만 빠르게 필터링하는 기준이 무엇인지

좋은 답의 핵심

  • 분산 추적 도입 언급, OpenTelemetry 같은 표준 기반 수집과 Jaeger·Zipkin 등의 뷰어 사용
  • Correlation ID 또는 Trace ID를 최초 진입점에서 생성, HTTP 헤더나 메시지 메타데이터로 전파
  • 모든 서비스 로그에 Trace ID 포함, 중앙 집중 로그 스택에서 단일 키로 검색 가능하게 구성
  • 메트릭과 트레이스 연계, APM으로 외부 의존성 지연과 오류율 시각화

나쁜 답의 신호

  • 각 서비스 로그를 시간순으로 열람해 육안 탐색 주장
  • 테스트 환경 재현 중심 접근만 언급, 비결정적 장애 대응 한계 노출
  • 담당자별 구두 확인 의존, 근거 추적 불가

주의와 베스트 프랙티스

  • 로그 스키마 통일, PII 마스킹, 로그 레벨과 샘플링 정책 명확화
  • 게이트웨이·워크커·비동기 큐 모두 동일한 Trace 컨텍스트 전파
  • 지표는 RED 또는 USE 프레임으로 표준화, 알림은 소음 최소화 기준 설정

마무리

MSA의 난제는 분산 트랜잭션, 장애 전파 억제, 관측 가능성으로 수렴함 경험자의 답변에는 패턴의 이름이 아니라 운영 상의 선택과 트레이드오프, 실패 시나리오와 회복 절차가 담겨 있음 결과적 일관성 수용, 회복탄력성 패턴의 기본기 적용, 추적 가능한 운영 체계가 핵심 조직 차원에서는 SLO와 에러 버짓, 표준 라이브러리화된 통신·관측 컴포넌트, 런북과 사후분석의 반복 개선이 필수

참고자료