171. 폴백 (Fallback) 회복탄력성 패턴

핵심 인사이트 (3줄 요약)

1. 본질: 폴백 (Fallback)은 원격 호출 실패나 서킷 브레이커 (Circuit Breaker) 개방 시, 오류를 그대로 전파하지 않고 안전한 대체 응답으로 전환하는 회복탄력성 (Resilience) 응답 전략이다.
2. 가치: 핵심 사용자 흐름을 완전히 끊지 않고, 캐시·기본값·기능 축소를 통해 우아한 성능 저하 (Graceful Degradation)를 제공함으로써 장애의 체감 범위를 줄인다.
3. 판단 포인트: 읽기 위주의 부가 기능에는 강력하지만, 결제 승인·주문 생성처럼 정합성이 중요한 쓰기 작업에는 "거짓 성공"을 만들 수 있으므로 폴백보다 빠른 실패와 보상 절차가 우선이다.

Ⅰ. 개요 및 필요성

폴백은 분산 시스템에서 "호출이 실패했을 때 무엇을 반환할 것인가"에 답하는 패턴이다. 타임아웃은 얼마나 기다릴지를 정하고, 재시도는 한 번 더 시도할지를 정하며, 서킷 브레이커는 계속 호출할지를 정한다. 그 다음 단계에서 폴백은 이제 원래 응답 대신 무엇을 줄지를 결정한다.

이 패턴이 필요한 이유는 실패 자체보다 사용자 경험의 붕괴가 더 크게 느껴지기 때문이다. 예를 들어 상품 상세 화면에서 추천 서비스가 잠시 죽었을 때, 페이지 전체를 500 오류로 끝내는 것은 과한 대응이다. 이 경우 "추천 영역만 인기 상품으로 대체"하거나 "추천 영역을 잠시 숨김"으로써 핵심 구매 흐름은 살릴 수 있다.

하지만 폴백은 장애를 마법처럼 없애는 기술이 아니다. 정확히 말하면 실패를 안전하게 축소하는 기술이다. 따라서 어떤 기능은 폴백이 적합하고, 어떤 기능은 오히려 위험하다. 조회성 기능과 거래성 기능을 구분하지 않으면 회복탄력성이 아니라 정합성 사고를 만들 수 있다.

아래 그림은 원래 경로와 폴백 경로가 어디서 갈리는지 보여 준다.

┌──────────────────────────────────────────────────────────────────────┐
│                 Primary path and fallback path split                 │
├──────────────────────────────────────────────────────────────────────┤
│ User -> Product API -> Recommendation service                        │
│                         │                                            │
│                         ├─ success -> personalized list              │
│                         └─ fail/open breaker -> cached popular list  │
│                                                                      │
│ goal: keep the page usable without pretending the dependency is fine │
└──────────────────────────────────────────────────────────────────────┘

핵심은 "정상 응답처럼 보이게 속이는 것"이 아니라, 사용 가능한 최소 서비스 수준을 유지하는 것이다. 그래서 폴백 응답은 가능한 한 출처와 한계를 분명히 가져야 한다.

• 📢 섹션 요약 비유: 주연 배우가 갑자기 못 나오더라도 공연 전체를 취소하는 대신 대역 배우가 핵심 장면만 이어 가게 만드는 것이 폴백이다. 다만 결말까지 바꿔 버리면 그건 대체가 아니라 사고다.

Ⅱ. 아키텍처 및 핵심 원리

폴백은 보통 타임아웃, 재시도, 서킷 브레이커와 함께 동작한다. 정상 경로가 실패했을 때만 호출되므로, 독립 기능이라기보다 실패 처리 체인의 마지막 응답 계층에 가깝다. 따라서 폴백 설계의 핵심은 "무엇으로 대체할 것인가"뿐 아니라 "언제 폴백으로 전환할 것인가"를 같이 정하는 데 있다.

실무적으로 좋은 폴백은 세 조건을 만족해야 한다. 첫째, 안전성이다. 폴백 결과가 비즈니스 정합성을 깨지 않아야 한다. 둘째, 명시성이다. 오래된 캐시인지, 제한된 정보인지 시스템과 운영자가 알 수 있어야 한다. 셋째, 관측 가능성이다. 폴백 발생률이 메트릭과 알림으로 드러나야 한다.

특히 캐시 폴백을 쓸 때는 만료 시간 (TTL, Time To Live) 과 허용 가능한 최신성 수준을 정해야 한다. "최대 5분 이전 데이터는 허용" 같은 기준이 없으면 폴백은 곧 무기한 오래된 데이터 제공으로 변질된다. 따라서 폴백은 캐시가 있다는 사실만으로 완성되지 않고, 얼마나 오래된 정보까지 서비스상 허용할지에 대한 합의가 있어야 한다.

아래 그림은 실패 감지에서 폴백 응답까지의 전형적인 흐름을 요약한다.

┌──────────────────────────────────────────────────────────────────────┐
│        Timeout and circuit breaker decide when fallback runs         │
├──────────────────────────────────────────────────────────────────────┤
│ request -> timeout -> retry?(limited) -> circuit breaker -> fallback │
│                                                        │             │
│                                                        ├─ cache      │
│                                                        ├─ default    │
│                                                        ├─ secondary  │
│                                                        └─ feature off│
└──────────────────────────────────────────────────────────────────────┘

즉 폴백은 장애 회피 그 자체가 아니라, 이미 실패가 감지된 후 사용자와 시스템에 가장 덜 위험한 응답 형태로 착지시키는 기술이다.

• 📢 섹션 요약 비유: 비가 오면 우산을 쓰는 것처럼, 폴백은 비를 멈추게 하지는 못하지만 젖지 않게 도와준다. 다만 폭우인데 종이우산을 주면 오히려 더 위험해진다.

Ⅲ. 비교 및 연결

폴백은 비슷한 회복탄력성 패턴과 역할이 다르다. 재시도는 원래 응답을 다시 받아보려는 시도이고, 서킷 브레이커는 더 이상 호출하지 말자고 결정하는 장치이며, 폴백은 그 이후 대체 응답을 제공하는 계층이다. 이 경계를 구분해야 장애 시 설계가 꼬이지 않는다.

또 하나 중요한 연결은 "우아한 성능 저하"와 "거짓 성공"의 차이다. 추천 상품이 인기 상품 목록으로 대체되는 것은 우아한 성능 저하지만, 결제 승인 실패를 "일단 성공"으로 보여 주는 것은 거짓 성공이다. 둘 다 겉으로는 오류 메시지를 숨기지만, 전자는 안전한 축소이고 후자는 치명적 왜곡이다.

그래서 폴백은 읽기 전용 조회, 비핵심 정보, 일시적인 화면 보완에는 강하지만, 거래 결과를 확정하는 도메인에는 신중해야 한다. 이 경계를 실무에서 구분하지 못하면 "장애 대응"이라는 명목으로 더 큰 업무 사고를 만든다.

• 📢 섹션 요약 비유: 배터리가 없을 때 손전등 앱 밝기를 낮추는 것은 괜찮지만, 잔액이 없는데도 결제 완료라고 표시하는 것은 절대 안 되듯, 폴백도 줄여도 되는 것과 속이면 안 되는 것을 구분해야 한다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 "이 기능이 없어도 핵심 흐름이 유지되는가?"를 먼저 묻는 것이 좋다. 예를 들어 쇼핑몰 메인 페이지의 개인화 추천, 리뷰 요약, 부가 배너는 폴백 후보가 된다. 추천 서비스가 실패하면 최근 인기 상품이나 카테고리 베스트 목록으로 대체하고, 리뷰 분석이 실패하면 리뷰 요약 영역만 숨길 수 있다.

반대로 결제 승인, 재고 차감, 주문 생성, 계좌 이체 같은 쓰기 작업은 폴백으로 성공을 흉내 내면 안 된다. 이런 도메인에서는 오류를 빠르게 드러내고, 필요한 경우 사가 (Saga) 보상 트랜잭션이나 수동 처리 절차로 연결하는 편이 안전하다. 즉 폴백은 정합성을 훼손하지 않는 범위 안에서만 허용되어야 한다.

기술사 판단 체크리스트

1. 이 기능은 실패해도 핵심 사용자 흐름이 유지되는가?
2. 폴백 응답이 오래된 데이터여도 업무적으로 안전한가?
3. 폴백 결과가 사용자와 운영자에게 식별 가능하게 기록되는가?
4. 폴백 호출률, 캐시 신선도, 서킷 브레이커 상태를 관측하고 있는가?
5. 쓰기 작업이라면 폴백 대신 실패 처리와 보상 절차를 설계했는가?

채택 / 회피 판단

• 채택: 추천, 검색 보조, 리뷰 요약, 통계 패널, 읽기 전용 외부 API 연동
• 조건부 채택: 계정 프로필, 배송 추적처럼 약간의 최신성 지연을 허용하는 조회
• 회피: 결제 승인, 주문 생성, 포인트 적립, 계좌 이체, 재고 확정

자주 나오는 안티패턴

• "오류가 없으면 좋은 것"이라는 생각으로 빈 응답을 200 성공으로 돌려주는 경우
• 만료 정책 없이 오래된 캐시를 무기한 서비스하는 경우
• 폴백 발생을 메트릭으로 남기지 않아 장애를 장시간 숨기는 경우
• 1차 장애보다 위험한 보조 공급자를 무분별하게 연결하는 경우
• 화면은 정상처럼 보이지만 실제 데이터 출처와 최신성은 설명하지 않는 경우

좋은 폴백은 장애를 감추기보다 영향 범위를 줄이면서 운영자에게 더 빨리 드러내는 설계다. 그래서 구현보다 관측, 데이터 신선도 정책, 도메인 안전성 판단이 더 중요하다.

• 📢 섹션 요약 비유: 자동차 네비게이션이 길이 막히면 우회로를 보여 주는 것은 좋지만, 다리가 끊어졌는데도 "곧 도착"이라고 말하면 큰일 나는 것과 같다.

Ⅴ. 기대효과 및 결론

폴백을 올바르게 적용하면 장애 중에도 핵심 사용자 경험을 유지하고, 원격 의존성 실패가 전체 서비스 중단으로 번지는 것을 줄일 수 있다. 운영 측면에서는 서킷 브레이커와 함께 장애를 국소화하고, 캐시와 기본 응답을 활용해 서비스 연속성을 확보할 수 있다.

하지만 폴백은 공짜가 아니다. 오래된 데이터 노출, 기능 편차, 장애 은폐, 다중 경로 운영 복잡도가 늘어난다. 특히 비즈니스 정합성을 검토하지 않은 폴백은 원래 장애보다 더 큰 사고를 만든다.

결론적으로 폴백은 "실패를 숨기는 장치"가 아니라, 실패가 발생했을 때 어떤 수준까지 서비스를 줄여도 안전한지 정의하는 정책적 패턴이다. 안전한 축소가 가능할 때만 쓰고, 그렇지 않으면 빠른 실패가 더 좋은 설계다.

• 📢 섹션 요약 비유: 좋은 폴백은 다친 선수 대신 수비형 교체 선수를 넣어 경기 흐름을 지키는 선택이지, 골이 들어가지 않았는데도 점수를 올려 놓는 속임수가 아니다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

Remote call failure
    │
    ▼
Timeout / Retry / Circuit Breaker
    │
    ├─ safe read path  -> cache / default / secondary source
    └─ unsafe write    -> fail fast / compensation flow
    │
    ▼
Graceful degradation with observability

이 흐름은 원격 호출 장애가 발생했을 때 폴백이 어디에 들어가고, 어떤 경우에는 오히려 쓰지 말아야 하는지를 보여 준다.

👶 어린이를 위한 3줄 비유 설명

1. 친구가 준비한 특별 간식이 없으면 냉장고에 있는 안전한 간식으로 대신 주는 게 폴백이에요.
2. 그래서 모두가 배고프다고 울지 않고 수업을 계속할 수 있어요.
3. 하지만 돈을 내야 하는 가게에서는 없는 물건을 있다고 속이면 안 되기 때문에 폴백도 함부로 쓰면 안 돼요.