폴백 케이스 스터디 — Netflix·Spotify·카카오가 보여준 7가지 장애 시나리오

폴백 케이스 스터디로 보는 잘 만든 안전망과 무너진 안전망

이전 글에서 폴백이 다시 필수 개념이 된 이유를 정리했습니다. 그럼 실제로는 어떻게 작동하고, 또 어떻게 무너질까요. 이번 폴백 케이스 스터디는 잘 만든 안전망 5가지와 무너진 안전망 2가지를 나란히 놓고 봅니다. 같은 패턴이 보이는 지점과, 한 곳이라도 어긋나면 어떻게 사고로 이어지는지를 함께 짚습니다.

먼저 7가지 사례를 한 줄로 미리 봅니다.

사례	폴백 메커니즘	결과
Netflix 추천 시스템	Hystrix 서킷 브레이커 → 인기 콘텐츠 노출	성공
Spotify Offline Backup	오프라인 감지 → 캐시된 최근 곡 자동 노출	성공
Google Maps 오프라인 지도	사전 다운로드 + GPS → 기본 내비게이션	성공
YouTube ABR 스트리밍	회선 저하 → 저화질 자동 전환	성공
웹 폰트 font-display: swap	폰트 지연 → 폴백 폰트 즉시 노출	성공
AWS S3 2017-02-28	폴백 페이지가 같은 S3 위에 있었음	실패
카카오 2022-10-15	이중화 전환 시스템이 한 데이터센터에 있었음	실패

성공한 폴백 — 사용자는 알아채지 못한다

1. Netflix 추천 시스템 — 멈춰도 홈은 비지 않는다

Netflix는 추천 마이크로서비스가 실패하거나 응답이 느려지면, Hystrix 라이브러리의 서킷 브레이커가 호출을 차단하고 미리 정의된 폴백을 반환합니다. 폴백 내용은 개인화되지 않은 인기 콘텐츠 row 입니다. 추천 모델 한 곳이 죽었다고 홈 화면이 비어 보이지 않습니다. 사용자에게는 "오늘은 추천이 살짝 더 평범한 것 같다" 정도의 변화만 남습니다. 폴백이 잘 동작하면 사용자는 알아채지 못한다는 원칙을 가장 깔끔하게 보여주는 사례입니다.

2. Spotify Offline Backup — 인터넷이 끊겨도 노래는 흐른다

Spotify는 2024년 10월부터 Offline Backup 기능을 도입했습니다. 디바이스가 오프라인 상태가 되면 평소 캐시해두던 데이터를 기반으로 최근 들은 곡과 재생 대기열에 있던 곡을 자동 플레이리스트로 띄워줍니다. 사용자가 사전에 별도 다운로드를 하지 않아도, 평소 사용 패턴이 그대로 오프라인 폴백이 됩니다. 캐시 안에서 동작하는 폴백이라 용량 한계는 있지만, "지하철에서 끊긴 순간"이라는 가장 흔한 실패 시나리오에서 서비스가 멈추지 않게 만들었습니다.

3. Google Maps 오프라인 지도 — 신호가 잡히지 않아도 길은 안내된다

Google Maps는 사용자가 사전에 다운로드한 지역과 단말의 GPS만으로 기본 길 안내를 유지합니다. 실시간 교통, 대안 경로 같은 라이브 데이터 의존 기능은 비활성화되지만, 운전이라는 가장 중요한 사용 케이스는 끊기지 않습니다. 오프라인 지도는 약 30일 유효기간이 있고, 다운로드된 영역 안으로 경로가 들어와 있어야 동작합니다. 사용자에게 "지금은 축소 모드"라는 점을 명시적으로 알리는 폴백의 좋은 예이기도 합니다.

4. YouTube ABR — 회선이 좁아져도 영상은 끊기지 않는다

YouTube는 영상을 240p·360p·720p·1080p·4K 같은 여러 비트레이트로 인코딩해두고, 210초 단위 청크로 나누어 전송합니다. 플레이어가 네트워크 상태를 실시간으로 관측해, 버퍼가 임계치(보통 510초) 아래로 떨어지면 즉시 더 낮은 비트레이트 청크를 요청합니다. "화질이 잠깐 낮아진다"가 "재생이 끊긴다"보다 사용자에게 훨씬 작은 손상이라는 판단이 설계 전체를 관통합니다. 모바일 환경에서 360p가 사실상 최저 폴백 티어 역할을 합니다. 같은 사고방식이 하이브리드 AI 라우팅에서도 그대로 나타납니다 — 클라우드가 닿으면 클라우드 LLM, 안 닿으면 디바이스 SLM으로 떨어지는 구조입니다.

한 줄의 폴백, 큰 차이

5. 웹 폰트 font-display: swap — 폰트가 늦어도 글자는 보인다

CSS 한 줄짜리 폴백이지만 효과가 큽니다. 웹 폰트가 도착하기 전까지 폴백 시스템 폰트로 즉시 텍스트를 보여주고(FOUT — Flash of Unstyled Text), 웹 폰트가 도착하면 부드럽게 교체합니다. 기본값(auto 또는 block)이면 폰트가 올 때까지 텍스트가 보이지 않는 FOIT 상태가 되어 사용자가 "빈 화면"을 보게 됩니다. font-family 선언의 마지막에 '맑은 고딕', sans-serif 같은 폴백 체인을 두고, font-display: swap을 더하는 것 — 두 줄짜리 폴백이 사용자 경험을 크게 바꿉니다.

실패한 폴백 — 같은 교훈, 두 회사

6. AWS S3 2017 — 폴백 페이지가 같은 S3 위에 있었다

2017년 2월 28일, AWS 엔지니어가 빌링 시스템을 디버깅하면서 명령어 파라미터를 잘못 입력해 S3의 핵심 서브시스템이 의도치 않게 종료됐습니다. US-EAST-1 리전이 약 4시간 동안 마비됐고, 인터넷 대부분이 흔들렸습니다. 더 뼈아픈 점은 AWS Service Health Dashboard 자체가 S3에 의존하고 있어, 장애 안내 페이지조차 띄울 수 없었다는 사실입니다. AWS 공식 포스트모템과 이후 업계 회고가 공통으로 짚는 교훈은 단순합니다 — 폴백 경로가 본 경로와 같은 의존성 위에 있다면, 그건 폴백이 아닙니다.

7. 카카오 2022-10-15 — 이중화 전환 시스템이 한 곳에 있었다

2022년 10월 15일 SK C&C 판교 데이터센터에서 발생한 화재로 카카오의 다수 서비스가 장시간 마비됐습니다. 카카오 공식 발표에 따르면 데이터 자체는 이중화되어 있었지만, 이중화 전환을 돕는 시스템 일부가 판교 데이터센터에만 설치돼 있었습니다. 그래서 자동 전환이 작동하지 않았고, 결국 수동 복구로 시간이 더 걸렸습니다. 카카오는 사후 사과문에서 시스템 레이어 전체를 다중화하겠다고 밝혔고, 향후 5년간 직전 5년 대비 3배 이상의 인프라 투자를 예고했습니다. AWS 사례와 표현은 다르지만 교훈은 같습니다 — 이중화 자체가 단일 장애점 위에 있으면 이중화가 아닙니다.

7개 사례에서 뽑은 4가지 공통 패턴

성공한 5개와 실패한 2개를 가르는 지점은 표로 정리하면 또렷합니다.

패턴	성공 케이스가 챙긴 것	실패 케이스가 놓친 것
폴백의 독립성	본 경로와 다른 의존성 위에 있음	본 경로와 같은 시스템·같은 위치
폴백의 자동 트리거	신호가 떨어진 순간 즉시 발동	자동 전환이 작동하지 않아 수동 복구
폴백 결과의 품질	"축소 모드"라도 의미 있는 결과 제공	사용자에게 도달하는 결과 없음
폴백의 가시성·관측성	발동 비율을 메트릭으로 추적	발동 자체가 외부 안내조차 못 함

특히 첫 번째 행이 핵심입니다. "폴백이 있다"가 아니라 "폴백이 본 경로와 다른 의존성 위에 있다"가 진짜 폴백입니다. AWS도 카카오도 폴백 자체는 존재했습니다. 다만 그 폴백이 본 경로와 같은 곳에 있었기 때문에 같이 무너졌습니다.

잘 만든 안전망은 보이지 않는다

이번 폴백 케이스 스터디 7가지를 한 번 더 훑어보면, 폴백은 두 가지 얼굴을 가지고 있다는 점이 분명해집니다. 잘 작동할 때는 사용자에게 거의 보이지 않고, 무너질 때는 모든 사용자에게 한꺼번에 보입니다. 그래서 폴백 설계의 좋고 나쁨은 평소에는 잘 드러나지 않다가, 결정적인 순간에 회사의 신뢰도를 좌우합니다.

기획자라면 "이 기능이 실패하면 사용자에게 무엇이 대신 도달하는가"를 모든 핵심 플로우에 한 번씩 던져보면 좋습니다. 개발자라면 폴백 코드가 본 경로와 같은 인프라·같은 의존성 위에 있는지를 한 번 더 확인해보는 것이 출발점입니다. 최근 정리한 폴백 개념 글에서 다룬 4가지 설계 포인트를 이번 7가지 케이스에 대입해보면, 같은 질문이 사례마다 다르게 적용되는 것을 확인할 수 있습니다.

잘 만든 안전망은 보이지 않습니다. 다만 안 보이는 채로 매일 사용자를 받치고 있다는 점에서, 사실 가장 비싼 코드 한 줄입니다.