이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
마이크로서비스 환경에서 가장 중요하게 생각한 것은 서비스 간 API 계약 관리였습니다. 한 서비스의 응답 구조가 바뀌면 다른 서비스가 깨지는 상황이 발생할 수 있어, API 스펙 변경 시 하위 호환성을 유지하거나 버전을 명확히 관리하는 규칙을 팀과 함께 정했습니다.
장애 추적이 어렵다는 것도 직접 경험했습니다. 단일 서비스에서는 로그 하나면 됐는데, 여러 서비스를 거치는 요청은 어느 단계에서 실패했는지 파악하기 어려웠습니다. 분산 트레이싱 도구를 도입하니 요청 경로 전체를 하나의 트레이스로 볼 수 있었습니다.
독립 배포는 마이크로서비스의 핵심 장점이었습니다. 한 서비스를 배포할 때 다른 서비스에 영향 없이 진행할 수 있어 릴리즈 주기가 유연해졌고, 빠른 피드백 루프가 가능해졌습니다.
마이크로서비스를 운영하면서 가장 당황했던 순간은 한 서비스가 응답이 느려지자 호출 체인 전체가 멈추는 상황이었습니다. 업스트림 서비스에서 타임아웃이 쌓이면서 스레드 풀이 모두 소진됐고, 결국 연관 기능 전부가 응답 불가 상태가 됐습니다. 처음엔 타임아웃 값을 늘리면 나아질 것 같았는데, 오히려 대기 시간만 길어졌습니다.
원인이 장애 격리 설계의 부재임을 파악한 뒤, Resilience4j를 도입해 서킷 브레이커를 달았습니다. 오류율이 50%를 넘으면 해당 호출을 즉시 차단하고 사전에 정의한 폴백 응답을 반환하도록 구성했습니다. 이후 특정 서비스가 다운돼도 나머지 기능은 폴백으로 계속 동작했습니다.
이 경험으로 마이크로서비스에서 장애 경로 설계가 정상 경로보다 먼저라는 걸 배웠습니다. 지금도 서비스 의존성을 연결할 때 폴백이 빠진 자리를 먼저 찾습니다.
마이크로서비스에서 가장 처음 막혔던 부분은 서비스를 나눴더니 데이터 일관성이 깨지는 문제였습니다. 주문 서비스와 재고 서비스가 분리돼 있어서, 주문이 완료돼도 재고 차감이 실패하면 두 서비스의 상태가 어긋나는 상황이 생겼습니다. 처음엔 2PC(두 단계 커밋)로 해결하려 했는데, 락이 길어지면서 성능이 눈에 띄게 나빠졌습니다.
결국 Saga 패턴을 도입했습니다. 각 서비스가 성공하면 이벤트를 발행하고, 중간에 실패가 나면 앞 단계를 되돌리는 보상 트랜잭션을 실행하도록 설계했습니다. 보상 로직이 정상 흐름보다 더 복잡했고, 먼저 장애 시나리오를 그리고 정상 경로를 짜는 순서를 배웠습니다.
이 경험으로 분산 시스템에서 강한 일관성이 필요한 자리와 최종 일관성으로 충분한 자리를 먼저 구분하는 것이 설계의 시작임을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 포트원 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.