이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
마이크로서비스 기반 프로젝트에서 사용자, 주문, 알림 세 서비스를 분리하고 REST API로 연결했습니다. 서비스 간 통신이 늘어나면서 장애 전파 문제가 생겼고, Circuit Breaker 패턴을 도입해 한 서비스 장애가 전체로 퍼지는 걸 막았습니다. 서비스 경계를 처음 설계할 때 도메인 중심으로 경계를 그어야 한다는 원칙이 실제 구현에서 얼마나 중요한지 체감했습니다. API 버전 관리와 서비스 디스커버리 설정도 처음 다루면서 운영 복잡도가 모놀리식보다 높다는 걸 직접 경험했습니다. 이 프로젝트에서 마이크로서비스는 구조가 아니라 운영 전략이라는 걸 배웠습니다.
마이크로서비스는 도구가 아니라 운영 전략이며, 도메인 경계와 장애 격리 설계가 먼저 돼야 한다는 걸 이 프로젝트에서 배웠습니다.
MSA 기반 시스템을 개발할 때 가장 먼저 결정해야 하는 것 중 하나가 서비스 간 통신 방식입니다. 동기 호출(REST API)과 비동기 이벤트(메시지 큐) 중 무엇을 쓸지는 각 서비스의 결합도와 가용성 요건에 따라 달라지고, 잘못 선택하면 한 서비스 장애가 전체 시스템 장애로 번지는 구조가 생깁니다.
이벤트 드리븐 아키텍처(Event-Driven Architecture)가 서비스 간 직접 의존을 끊고 비동기 메시지로 연결해서 독립적인 배포와 장애 격리를 가능하게 하는 방식입니다. 주문과 재고 서비스처럼 실시간 응답이 중요한 곳은 동기로, 알림과 정산처럼 즉시 처리가 불필요한 곳은 비동기로 분리했습니다. API 게이트웨이가 클라이언트의 단일 진입점이 되어서 인증·라우팅·레이트리밋을 한 곳에서 처리했습니다.
MSA에서 통신 설계가 잘못되면 독립 배포의 이점이 사라집니다. 동기-비동기 통신 분리가 MSA 설계에서 가장 중요한 결정이었습니다.
MSA에서 가장 어렵고 중요한 결정은 서비스를 어떤 기준으로 나누느냐입니다. 기능이나 기술 스택으로 나누면 서비스 간 의존이 복잡해지고, 비즈니스 도메인과 팀 소유권을 기준으로 경계를 나눌 때 독립적인 배포와 변경이 가능해집니다. 도메인 주도 설계(Domain-Driven Design)의 바운디드 컨텍스트 개념이 각 서비스가 자기만의 언어와 데이터를 갖도록 경계를 정의하는 방식입니다.
처음에 주문·결제·배송을 하나의 서비스로 묶었다가, 각 도메인의 변경 주기와 소유 팀이 달라서 결국 분리한 경험이 있습니다. 도메인 경계가 잘못 설정되면 서비스가 나뉘어 있어도 결국 하나의 배포로 묶이는 분산 모놀리스 문제가 생깁니다. 서비스를 나누는 것이 아니라 책임을 나누는 것이 MSA의 핵심입니다. 도메인 경계 설계가 MSA 구조의 성패를 결정하는 첫 번째 단계였습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.