이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 팀원 5명이 기능별로 서비스를 나눠 독립 배포했는데, 그게 제가 처음 경험한 마이크로서비스 구조였습니다. 가장 좋았던 점은 한 서비스가 다운돼도 다른 서비스는 살아있다는 것이었습니다. 결제 서비스가 오류가 나도 상품 목록 조회는 정상 동작했고, 그 경험이 장애 격리 개념을 몸으로 익힌 계기였습니다. 반면 서비스 간 통신 설계가 생각보다 복잡했습니다. API 호출 실패 시 재시도 로직을 각 서비스마다 따로 구현해야 했고, 로그도 서비스별로 흩어져서 추적이 어렵다는 걸 느꼈습니다. 기술 스택은 Docker + FastAPI + PostgreSQL을 서비스별로 독립 운영했는데, 인프라 설정이 모놀리식보다 몇 배 손이 많이 갔습니다. 규모가 작을 때는 모놀리식이 더 빠를 수 있다는 판단도 그때 생겼습니다.
처음 시작할 때는 모놀리식 구조로 개발했습니다. 기능이 늘어나면서 배포할 때마다 전체를 다시 빌드해야 했고, 하나의 로직을 수정하면 다른 기능에 영향이 갈까봐 항상 조심스러웠습니다. 팀에서 결제 로직만 따로 분리하자는 논의가 나왔을 때, 저는 처음으로 서비스 간 API 설계를 담당했습니다. 기존 내부 함수 호출이 HTTP 요청으로 바뀌면서 응답 지연과 타임아웃 처리를 따로 고려해야 한다는 것을 그때 처음 깨달았습니다.
Docker로 서비스를 컨테이너로 격리했고, 결제 서비스가 독립적으로 배포되는 것을 처음 확인했을 때 분리의 장점이 실감났습니다. 반면 로그가 두 서비스에 분산되어 있어서 디버깅이 복잡해졌고, 중앙 로그 수집 도구를 도입하는 계기가 됐습니다. 구조를 나누기 전에 서비스 경계를 어디에 그을지를 먼저 충분히 고민하는 것이 이후 복잡도를 줄인다고 생각합니다.
사이드 프로젝트에서 세 개의 서비스를 나눠 운영해봤는데, 초기 설계보다 운영이 더 어려웠습니다. 서비스별로 독립적으로 스케일링할 수 있다는 장점은 실제로 확인됐지만, 장애가 났을 때 어느 서비스가 원인인지를 빠르게 파악하는 것이 예상보다 어려웠습니다. 각 서비스가 제각각의 로그 포맷을 쓰고 있었기 때문에 grep으로 추적하는 데 시간이 걸렸고, 공통 로그 형식을 정하는 것이 얼마나 중요한지 그때 알았습니다. 서비스 간 호출이 많아지면서 특정 서비스 응답이 느려지면 전체 흐름이 지연되는 상황도 생겼습니다. 이를 막기 위해 타임아웃과 retry 로직을 각 서비스에 직접 구현했는데, 같은 패턴이 반복되어 공통 라이브러리로 빼내야 했습니다. 마이크로서비스는 팀이 서비스를 독립적으로 배포할 수 있을 때 장점이 가장 크고, 그 전에는 오히려 관리 비용이 먼저 올라간다는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.