이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
캡스톤 프로젝트에서 배달 중개 플랫폼을 MSA 구조로 설계했습니다. 주문·가게·배달·알림을 각각 분리했고, 서비스 간 통신은 동기 REST와 비동기 이벤트를 용도에 따라 나눴습니다. 주문 생성 시 가게 유효성 확인은 동기로 처리했고, 알림은 이벤트 발행으로 느슨하게 연결했습니다. 데이터는 서비스별 독립 DB를 유지해서 주문 서비스가 가게 DB를 직접 참조하지 않도록 했습니다. 가장 어려웠던 점은 장애 추적이었는데, 로그가 서비스마다 흩어져 있어서 요청 흐름을 따라가기가 어려웠습니다.
trace ID를 헤더로 전파하는 방식으로 개선했지만, 모놀리스보다 운영 복잡도가 확실히 높다는 것을 실감했습니다. MSA는 팀 규모와 도메인 경계가 명확할 때 비용이 줄어드는 자리라는 생각을 갖게 됐습니다.
MSA를 처음 도입했을 때 가장 과소평가한 부분이 데이터 일관성이었습니다. 단일 DB 트랜잭션으로 처리하던 주문·결제·포인트 차감을 분리된 서비스로 나누자 부분 실패 시 데이터가 어긋나는 상황이 생겼습니다. 2PC(2단계 커밋)를 검토했지만 성능 저하가 커서, 대신 SAGA 패턴으로 보상 트랜잭션을 설계했습니다. 결제 실패 시 포인트 적립을 롤백하는 보상 이벤트를 별도로 발행하는 방식입니다.
일관성보다 가용성을 택하는 결정이 비즈니스에서 허용되는지 먼저 확인하지 않으면 설계가 잘못된 방향으로 갈 수 있다는 것을 이때 배웠습니다. 분리의 단위가 곧 장애의 단위가 된다는 감각, 그리고 경계가 흐리면 운영 중에 문제가 터진다는 것이 MSA 설계의 핵심이라고 생각합니다.
MSA 구조를 실제 운영해보면서 관측 가능성(Observability)이 생존 조건이라는 것을 실감했습니다. 로컬에서는 잘 되던 결제 흐름이 스테이징에서 간헐적으로 실패했는데, 로그가 서비스마다 분산돼 있어 어느 서비스에서 지연이 시작됐는지 추적이 불가능했습니다.
분산 추적을 적용해 trace_id를 각 요청에 붙이고 서비스 경계를 넘어 흐름을 따라가도록 구성하자 문제가 결제 서비스와 포인트 서비스 사이의 네트워크 타임아웃임을 빠르게 확인할 수 있었습니다. 추가로 서킷 브레이커를 적용해 한 서비스 장애가 연쇄적으로 전파되지 않도록 방어했습니다. 주니어 시절에는 서비스가 뜨는 것까지만 생각했는데, 시니어로 갈수록 장애 시 원인을 얼마나 빨리 찾고 복구하는가가 설계 기준이 된다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 세나클소프트 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.