171. 폴백 (Fallback) - 서킷 브레이커의 대안 반환 로직

핵심 인사이트: 서킷 브레이커가 차단기를 팍 내려서 에러가 났을 때, 사용자 화면에 흉측한 "500 Internal Server Error" 창을 띄우는 건 최악이다. 폴백(Fallback)은 차단기가 내려간 순간, 재빨리 "어제 받아놓은 데이터(캐시)"나 "기본 메시지"를 대신 띄워주어 장애를 우아하게 숨기는 플랜 B다.

Ⅰ. 폴백 (Fallback)의 개념

마이크로서비스 아키텍처(MSA)에서 특정 서비스 호출 시 장애가 발생했거나, 서킷 브레이커(Circuit Breaker)가 OPEN되어 요청이 차단되었을 때, 예외(Exception)를 그대로 사용자에게 던지는 대신, 미리 준비해 둔 기본값(Default Value)이나 캐시(Cache)된 데이터를 대신 반환하도록 처리하는 로직입니다.

Ⅱ. 폴백이 필요한 이유 (UX 보호)

  • '쇼핑몰 메인 페이지'를 로딩하는데, 사용자의 '최근 검색한 상품(추천 서비스)'이 뻗었다고 칩시다.
  • 폴백이 없다면: 메인 페이지 전체가 500 에러를 내며 하얗게 다운됩니다. (단일 장애가 전체 장애로 번짐)
  • 폴백이 있다면: 추천 서비스 대신 "인기 베스트 상품 10선(정적 데이터)"을 화면에 슬쩍 띄워줍니다. 사용자는 추천 서비스가 죽었는지 전혀 눈치채지 못하고 쇼핑을 계속합니다.

Ⅲ. 주요 폴백 전략 (Fallback Strategies)

전략설명 및 예시
캐시(Cache) 반환원본 DB나 서비스가 죽으면, Redis나 로컬 메모리에 저장해 두었던 과거 데이터(Stale Data) 를 대신 보여줍니다. (예: 날씨 정보가 죽으면, 1시간 전에 받아둔 날씨를 노출)
기본값(Default) 반환과거 데이터도 없으면, 사전에 정해둔 텅 빈 빈값이나 하드코딩된 기본 문구를 띄워줍니다. (예: 개인화 추천 상품 대신 "현재 인기 상품" 고정 리스트를 노출)
기능 축소 (Graceful Degradation)핵심 기능만 남기고 부가 기능은 화면에서 아예 안 보이게 숨깁니다. (예: 결제 장애 시 '결제하기' 버튼을 아예 회색으로 비활성화하여 에러 발생 자체를 막음)

Ⅳ. 폴백을 쓰면 안 되는 곳 (주의점)

모든 API에 폴백을 적용할 수는 없습니다. 조회(GET)가 아닌, 데이터의 정합성이 생명인 생성(POST)이나 결제 로직에는 절대 폴백(캐시 반환 등)을 쓰면 안 됩니다.

  • 잘못된 예: 결제 API가 죽었다고 폴백으로 "결제 성공(임시)" 메시지를 띄워주면 회사는 파산합니다. 이런 핵심 로직은 폴백 대신 확실하게 에러(Fail Fast)를 내고 즉각적인 복구 절차에 들어가야 합니다.

📢 섹션 요약 비유: 연극 무대에서 주연 배우(메인 서비스)가 갑자기 배탈이 나서 무대에 못 오를 때, 관객들에게 환불해주고 공연을 아예 취소(500 에러)하는 것이 아니라, 분장실에서 대기하던 조무래기 대역 배우(Fallback)를 빨리 내보내어 비록 연기는 어설프더라도 연극 자체는 멈추지 않고 끝까지 돌아가게 만드는 위기관리 대책입니다.