우문현답
愚 問 賢 答
회사별 면접직군별진행 방식
    홈›회사별›쿠팡›백엔드›질문 상세
    問
    쿠쿠팡백엔드직무 역량2026년 출제

    Microservices Architecture를 사용할 때의 장점과 단점은 무엇이라고 생각하시나요?

    답변 미리보기

    졸업 프로젝트에서 팀원 5명이 기능별로 서비스를 나눠 독립 배포했는데, 그게 제가 처음 경험한 마이크로서비스 구조였습니다. 가장 좋았던 점은 한 서비스가…

    예상 답변 시간
    60~90초
    예상 꼬리질문
    3회
    난이도
    난이도 중상
    출제 빈도
    높음
    INTERVIEWER'S INTENT · 면접관의 의도

    이 질문, 네 갈래로 뜯어봅니다.

    면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

    問
    01
    장점은 무엇인가?
    Microservices의 장점에 대한 명확한 이해가 답에 있어야 합니다. 없으면 면접관이 '구체적인 사례는 없었나요?'를 추가로 묻는 경우가 자주 보입니다.
    骨
    02
    단점은 무엇인가?
    Microservices의 단점에 대한 인식이 드러나는 답이 필요합니다. 없으면 면접관이 '그럼 어떻게 해결했나요?' 같은 질문을 던지는 자리가 자주 보입니다.
    語
    03
    어떤 경험이 있는가?
    Microservices를 실제로 사용한 경험에 대한 이야기가 있을 때 긍정적으로 보일 수 있습니다. 없으면 면접관이 '그 경험은 어떻게 했나요?'를 추가로 묻는 경우가 흔합니다.
    本
    04
    어떤 기술 스택을 사용했는가?
    Microservices를 구현하는 데 사용한 기술 스택에 대한 언급이 답에 있어야 합니다. 없으면 면접관이 '어떤 도구를 사용했나요?' 같은 질문을 할 가능성이 높습니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    쿠팡 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    독립 배포·확장성의 장점과 네트워크 복잡도·운영 비용 단점을 경험 중심으로 연결약 90초모놀리식 구조의 한계를 경험한 후 점진적으로 서비스를 분리해나간 경험 중심약 82초운영 모니터링과 장애 대응 관점에서 마이크로서비스의 복잡성을 관찰한 경험 중심약 80초
    실제 프로젝트 경험 기반 장단점 비교
    약 90초

    독립 배포·확장성의 장점과 네트워크 복잡도·운영 비용 단점을 경험 중심으로 연결

    졸업 프로젝트에서 팀원 5명이 기능별로 서비스를 나눠 독립 배포했는데, 그게 제가 처음 경험한 마이크로서비스 구조였습니다. 가장 좋았던 점은 한 서비스가 다운돼도 다른 서비스는 살아있다는 것이었습니다. 결제 서비스가 오류가 나도 상품 목록 조회는 정상 동작했고, 그 경험이 장애 격리 개념을 몸으로 익힌 계기였습니다. 반면 서비스 간 통신 설계가 생각보다 복잡했습니다. API 호출 실패 시 재시도 로직을 각 서비스마다 따로 구현해야 했고, 로그도 서비스별로 흩어져서 추적이 어렵다는 걸 느꼈습니다. 기술 스택은 Docker + FastAPI + PostgreSQL을 서비스별로 독립 운영했는데, 인프라 설정이 모놀리식보다 몇 배 손이 많이 갔습니다. 규모가 작을 때는 모놀리식이 더 빠를 수 있다는 판단도 그때 생겼습니다.

    이 결의 특징
    결제 서비스 장애에도 상품 조회는 정상 동작했다는 장애 격리 경험과, 서비스별 재시도 로직 중복과 로그 분산으로 추적이 어려웠던 단점을 함께 짚은 흔적이 있습니다. 규모가 작을 때는 모놀리식이 더 빠를 수 있다는 균형 판단이 담긴 결이 보입니다.
    이 결이 통하는 자리
    장점과 단점을 같은 경험 안에서 대비시켜 설명하는 균형이 살아 있을 때 통합니다. Docker와 FastAPI 같은 구체 스택이 근거로 제시될 때 면접관이 실전 경험을 읽는 결이 보입니다.
    예시 답변 2
    약 82초

    모놀리식 구조의 한계를 경험한 후 점진적으로 서비스를 분리해나간 경험 중심

    처음 시작할 때는 모놀리식 구조로 개발했습니다. 기능이 늘어나면서 배포할 때마다 전체를 다시 빌드해야 했고, 하나의 로직을 수정하면 다른 기능에 영향이 갈까봐 항상 조심스러웠습니다. 팀에서 결제 로직만 따로 분리하자는 논의가 나왔을 때, 저는 처음으로 서비스 간 API 설계를 담당했습니다. 기존 내부 함수 호출이 HTTP 요청으로 바뀌면서 응답 지연과 타임아웃 처리를 따로 고려해야 한다는 것을 그때 처음 깨달았습니다.

    Docker로 서비스를 컨테이너로 격리했고, 결제 서비스가 독립적으로 배포되는 것을 처음 확인했을 때 분리의 장점이 실감났습니다. 반면 로그가 두 서비스에 분산되어 있어서 디버깅이 복잡해졌고, 중앙 로그 수집 도구를 도입하는 계기가 됐습니다. 구조를 나누기 전에 서비스 경계를 어디에 그을지를 먼저 충분히 고민하는 것이 이후 복잡도를 줄인다고 생각합니다.

    이 결의 특징
    내부 함수 호출이 HTTP 요청으로 바뀌며 응답 지연과 타임아웃을 처음 고려하게 된 전환점을 짚고, 로그 분산 문제를 중앙 로그 수집 도구 도입으로 해결한 흔적이 있습니다. 서비스 경계를 먼저 고민하는 습관까지 담긴 결이 보입니다.
    이 결이 통하는 자리
    모놀리식에서 점진적으로 분리해 간 과정이 구체적일 때 통합니다. 분리 전 경계를 충분히 고민한다는 원칙이 살아 있을 때 면접관이 설계 성숙도를 읽는 결이 보입니다.
    예시 답변 3
    약 80초

    운영 모니터링과 장애 대응 관점에서 마이크로서비스의 복잡성을 관찰한 경험 중심

    사이드 프로젝트에서 세 개의 서비스를 나눠 운영해봤는데, 초기 설계보다 운영이 더 어려웠습니다. 서비스별로 독립적으로 스케일링할 수 있다는 장점은 실제로 확인됐지만, 장애가 났을 때 어느 서비스가 원인인지를 빠르게 파악하는 것이 예상보다 어려웠습니다. 각 서비스가 제각각의 로그 포맷을 쓰고 있었기 때문에 grep으로 추적하는 데 시간이 걸렸고, 공통 로그 형식을 정하는 것이 얼마나 중요한지 그때 알았습니다. 서비스 간 호출이 많아지면서 특정 서비스 응답이 느려지면 전체 흐름이 지연되는 상황도 생겼습니다. 이를 막기 위해 타임아웃과 retry 로직을 각 서비스에 직접 구현했는데, 같은 패턴이 반복되어 공통 라이브러리로 빼내야 했습니다. 마이크로서비스는 팀이 서비스를 독립적으로 배포할 수 있을 때 장점이 가장 크고, 그 전에는 오히려 관리 비용이 먼저 올라간다는 것을 배웠습니다.

    이 결의 특징
    장애 원인 파악이 예상보다 어려웠던 이유를 서비스별 제각각의 로그 포맷으로 짚고, 공통 로그 형식과 재시도 로직을 공통 라이브러리로 뺀 흔적이 있습니다. 특정 서비스 지연이 전체 흐름을 늦춘다는 관찰이 담긴 결이 보입니다.
    이 결이 통하는 자리
    독립 배포가 가능할 때 장점이 가장 크고 그 전엔 관리 비용이 먼저 오른다는 균형 잡힌 결론이 살아 있을 때 통합니다. 운영 중 겪은 구체 문제와 해결책이 짝을 이룰 때 면접관이 실전 감각을 읽는 결이 보입니다.
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

    같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

    • ✕떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
    • ✕선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
    • ✕결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
    • ✕지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.
    ▶이어질 꼬리질문

    진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

    壹Microservices Architecture의 단점은 무엇이라고 생각하시나요?
    貳이전 프로젝트에서 Microservices를 사용해본 경험이 있나요?
    參Microservices가 필요한 상황은 어떤 경우인가요?
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. 쿠팡 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

    같은 흐름에서 자주 이어지는 질문들이에요.

    쿠팡 · 백엔드
    Microservices Architecture 기반의 시스템 개발 시 어떤 접근 방식을 취했는지 사례를 들어 설명해 주세요.
    이 질문 보기
    넛지헬스케어 · 백엔드
    Microservice Architecture(MSA) 구현 경험이 있다면, 어떤 장단점이 있었는지 말씀해 주세요.
    이 질문 보기
    쿠팡 · 백엔드
    MSA(Microservices Architecture)에 대한 이해도를 어떻게 쌓아왔나요?
    이 질문 보기
    라인 · 백엔드
    RESTful API와 마이크로서비스 아키텍처의 장점에 대해 어떻게 생각하나요?
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, 쿠팡 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기