이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
캡스톤 프로젝트에서 이벤트 기반 알림 시스템을 설계하면서 분산 시스템의 기초를 처음 경험했습니다. 여러 서비스가 동일 이벤트를 소비해야 했는데, 동기 호출로 연결하면 한 서비스 장애가 전체로 전파되는 문제를 직접 겪었습니다. 메시지 큐를 중간에 두고 각 소비자가 독립적으로 처리하게 분리하니, 한 소비자가 느려져도 다른 서비스는 영향을 받지 않았습니다.
분산 시스템에서 가장 까다로운 건 일관성보다 장애 전파를 막는 경계 설계였는데, 서비스 간 결합도를 줄이는 것이 실질적인 안정성 향상으로 이어진다는 걸 배웠습니다. 지금도 새 서비스를 설계할 때 장애 격리 단위를 먼저 그려보는 순서를 지킵니다.
분산 시스템에서 여러 서비스에 걸친 데이터 일관성을 유지하는 부분이 가장 어려웠습니다. 결제는 성공했는데 재고 감소가 실패하는 케이스를 어떻게 처리할지 몰라서 막혔습니다. 혼자 풀기 어렵다고 판단하고 백엔드 경험이 있는 팀원에게 먼저 물어봤습니다. 팀원이 사가(Saga) 패턴과 보상 트랜잭션 개념을 짚어줬는데, 각 서비스가 로컬 트랜잭션을 처리하고 실패 시 보상 이벤트를 발행하는 구조였습니다. 이후 CAP 정리가 왜 필요한지도 이 맥락에서 이해됐는데, 분산 환경에서는 강한 일관성보다 결과적 일관성(Eventual Consistency)이 현실적인 선택이라는 것을 배웠습니다. 나중에 팀원이 막힌 부분에서는 제가 도운 경우도 생겼고, 분산 시스템 학습은 혼자보다 같이 할 때 훨씬 빠르다는 것을 이 경험에서 얻었습니다.
트래픽이 많은 조회 API를 개선하면서 읽기 부하를 여러 인스턴스로 분산하는 구조를 처음 설계해봤습니다. 레플리카 읽기 분리(Read Replica)로 시작했는데, 복제 지연이 발생하는 구간에서 방금 쓴 데이터가 바로 보이지 않는 케이스가 생겼습니다. 이 상황이 CAP 정리에서 말하는 가용성과 일관성의 트레이드오프라는 것을 이때 체감했습니다. 이후에는 쓰기 직후 재조회가 필요한 케이스는 주 DB로, 나머지는 레플리카로 라우팅하는 방식으로 처리했습니다. 서비스 간 지연을 추적하기 위해 요청마다 추적 ID를 심고 로그에 남겼고, 나중에 특정 서비스에서 P99 지연이 튀는 것을 이 추적 로그로 발견했습니다.
분산 시스템은 설계도 어렵지만, 운영 중 무슨 일이 일어나는지 볼 수 있는 구조를 미리 만드는 것이 더 중요하다는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 배달의민족(우아한형제들) 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.