그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Architecture
Architecture

동기 방식으로 외부 서비스를 호출할 때 외부 서비스 장애가 나면 어떻게 조치할 수 있나요?

실무5/5
설계5/5
인간4/5
기초3/5

면접관의 질문 의도

장애를 어디서 끊고 어디서 격리할지를 시나리오로 풀어낼 수 있는지 본다. 한 가지 패턴만 외워서 답하는지, 즉시 완화와 구조적 방어를 구분해 우선순위로 가져가는지를 가른다.

큐레이션 답변

학습 자료

동기 호출은 외부가 느려지면 내 쪽 스레드와 커넥션이 그대로 묶인다. 장애가 길어지면 대기가 쌓여 정상 트래픽까지 같이 터진다. 1차 방어는 타임아웃으로 대기를 끊는 것이고, 그 다음은 벌크헤드로 자원을 격리해 한 의존성의 장애가 전체로 번지지 않게 막는다. 지속 실패가 보이면 서킷 브레이커로 빠르게 실패시켜 자원을 아끼고, 회복 신호가 오면 점진적으로 다시 열어준다.

좋은 답변 구조

  1. 01동기 호출이 외부 장애로 어떻게 자원 고갈까지 번지는지 단계로 설명한다
  2. 02타임아웃·벌크헤드·서킷 브레이커를 어떤 순서로 적용할지 우선순위를 잡는다
  3. 03각 패턴의 임계값을 트래픽·SLA·다운스트림 응답 분포와 함께 정한다
  4. 04회복 후 점진적 재개와 알람·관측 설계로 마무리한다

자주 실수하는 포인트

서킷 브레이커만 답하고 타임아웃·벌크헤드와 어떻게 묶이는지 못 푼다
임계값을 '적절히' 같은 표현으로 넘기고 무엇을 보고 정하는지 못 말한다
패턴을 나열만 하고 어떤 장애 양상에 어떤 패턴이 듣는지 매핑을 못한다
복구가 시작된 뒤 점진적 재개와 모니터링 설계는 빠뜨린다

실무 맥락

  • 결제·인증·외부 API 같은 다운스트림 의존이 많은 동기 호출 중심 백엔드
  • 한 다운스트림 장애가 다른 API 응답까지 묶어 SLA가 깨졌던 운영 환경
  • 마이크로서비스 호출 체인이 길어 한 노드 장애가 위로 전파되는 구조

본인 경험에 녹이는 힌트

외부 의존이 느려져 커넥션 풀이 마르거나 스레드가 묶였던 경험이 있다면, 그때 무엇을 가장 먼저 끊었는지로 연결할 수 있다

특정 다운스트림 하나가 전체 응답을 묶었던 경험이 있다면, 벌크헤드 분리 단위 설계 이야기와 엮을 수 있다

서킷 브레이커를 도입했다가 임계값이 너무 빡빡해 정상 호출까지 막아본 경험이 있다면, 임계값 보정 과정으로 풀 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1타임아웃 값은 어떤 지표를 기준으로 결정하나요
Q2벌크헤드는 어떤 단위로 자원을 격리하는 게 맞나요
Q3서킷 브레이커 반개방 상태에서 트래픽을 어떻게 흘려보내나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문