왜 다시 폴백(Fallback)인가 — MSA·AI 시대 필수가 된 안전망 설계

오래된 개념인데 왜 다시 화두일까

폴백(Fallback)은 새로운 단어가 아닙니다. "주 경로가 실패하면 보조 경로로 대체해 서비스를 계속 유지한다" — 30년 전 시스템 설계 교과서에도 있던 개념입니다. 그런데 최근 1~2년 사이 기획·개발 회의에서 이 단어가 부쩍 자주 들립니다. 이유가 있습니다. 시스템이 '실패하는 빈도'와 '실패하는 방식'이 동시에 바뀌었기 때문입니다.

예전엔 단일형(Monolithic) 시스템에서 에러가 나면 프로그램이 멈추거나 500 에러 페이지를 띄우는 게 일반적이었습니다. 사용자도 그 정도는 받아들였습니다. 지금은 다릅니다. 한 화면 뒤에 수십 개의 서비스가 통신하고, 그중 하나에 LLM이 끼어 있고, 사용자는 어제 본 ChatGPT 수준의 경험을 오늘도 기대합니다. 이 환경에서 "에러 페이지로 끝내자"는 사실상 사형 선고에 가깝습니다.

이 글에서는 폴백의 개념을 다시 짚고, 왜 지금 다시 필수 개념이 됐는지, 그리고 기획자·개발자가 실무에서 어떻게 적용해야 하는지를 정리합니다.

폴백이란 — 그레이스풀 디그라데이션의 다른 이름

폴백은 한 마디로 "주 기능이 실패했을 때 시스템이 완전히 멈추지 않고, 축소된 기능으로 계속 동작하게 만드는 설계" 입니다. 영어권에서는 그레이스풀 디그라데이션(Graceful Degradation)이라는 더 넓은 용어와 자주 묶입니다. 핵심은 두 가지입니다.

첫째, 실패 자체를 피하지 않습니다. 실패는 일어난다는 가정에서 출발합니다. 둘째, 실패가 사용자에게 도달하기 전에 가로채서 대체 응답으로 바꿔치기합니다. 사용자는 "기능이 조금 단순해진 것" 정도로 느끼고, 서비스는 멈추지 않습니다.

이 사고방식은 옛날부터 있었지만, 옛날엔 '있으면 좋은 것'에 가까웠습니다. 지금은 '없으면 안 되는 것'이 됐습니다. 환경이 바뀌었기 때문입니다.

왜 최근에 더 자주 쓰일까

폴백이 최근 다시 필수 개념이 된 배경은 세 가지로 정리됩니다.

마이크로서비스 아키텍처(MSA)

요즘 서비스는 결제·추천·인증·검색·로그·알림이 잘게 쪼개져 서로 통신합니다. 이 중 추천 서버 하나가 고장 났다고 해서 앱 전체가 켜지지 않으면 안 됩니다. 추천 영역만 '기본 인기 상품 노출' 같은 폴백으로 바꿔치우고, 결제·검색은 정상 동작해야 합니다. 서비스 단위가 잘게 쪼개진 만큼 부분 실패가 일상화됐고, 부분 실패를 다루는 표준 도구가 폴백입니다.

AI 및 LLM 도입

LLM은 기존 결정형 프로그램보다 실패 양상이 훨씬 다양합니다. 응답이 느려지거나, 가끔 이상한 답을 내거나, API 자체가 잠시 먹통이 되거나, 비용 한도에 걸려 컷오프되거나 — 실패가 '예외'가 아니라 '확률 분포'에 가깝습니다. 그래서 "AI 응답이 5초 이상 걸리면 미리 준비된 템플릿 답변을 보여준다", "신뢰도가 일정 이하이면 룰 기반 답으로 회귀한다" 같은 폴백 설계가 사실상 필수가 됐습니다. 최근에 정리한 하이브리드 AI 글에서도 결국 라우팅의 한 축이 "클라우드가 안 닿으면 디바이스 안의 SLM으로 떨어진다"는 폴백 구조였습니다.

사용자 경험(UX)의 기대치 상승

예전엔 에러 페이지가 일종의 양해 신호였지만, 지금은 다릅니다. 사용자는 한 서비스에서 막히면 1초 안에 경쟁 서비스로 옮겨갑니다. 에러 화면을 보여주며 유저를 내쫓는 대신, '기능은 제한되지만 서비스는 계속 쓸 수 있는 상태'를 유지하는 것이 리텐션 지표와 직결됩니다. 폴백은 이제 기술 설계가 아니라 제품 정책에 가깝습니다.

직무별 실무 적용 예시

기획자·개발자·디자이너가 같은 회의에서 '폴백'이라는 단어를 쓰지만, 머릿속 그림이 서로 다른 경우가 많습니다. 두 갈래로 나눠 정리하면 조율이 빨라집니다.

① 시스템·개발 폴백 (Technical Fallback)

코드 레벨에서 백엔드·인프라·외부 API 장애에 대응하는 폴백입니다.

• 외부 API 장애 대응: 외부 날씨 연동 API가 죽었을 때, 시스템이 뻗는 대신 가장 최근에 성공적으로 저장된 날씨 데이터를 보여주거나 '서울 기준 기본값'으로 회귀합니다.
• 네트워크 환경 대응: 사용자의 인터넷 연결이 끊기거나 느려지면, 고화질 영상 대신 저화질 영상으로 자동 전환해 재생을 유지합니다.
• LLM 응답 폴백: 1차로 호출한 모델이 타임아웃·과부하·콘텐츠 필터에 걸리면, 더 가벼운 보조 모델로 재시도하거나 미리 준비된 정형 답변으로 회귀합니다.
• AI 도구 장애 폴백: 작년에 정리한 Codex 장애 시 백업 CLI로 전환하는 가이드도 결국 같은 사고방식입니다 — 메인 도구가 안 될 때 보조 도구로 무중단 전환합니다.

② 서비스·UI/UX 폴백 (UI/UX Fallback)

화면 단위에서 사용자에게 어떻게 보이게 할지를 다루는 폴백입니다.

• 이미지 로딩 실패: 웹페이지에서 메인 배너 이미지를 못 불러왔을 때 깨진 아이콘 대신 회사 로고가 그려진 기본 대체 이미지(Fallback Image)를 보여줍니다.
• 웹폰트 다운로드 실패: 유료 서체를 받아오지 못할 상황을 대비해 font-family: '원래 서체', '맑은 고딕', sans-serif; 처럼 뒤에 대안 폰트(Fallback Font)를 지정합니다.
• AI 응답 지연: 응답 대기 중에는 스켈레톤 UI나 '비슷한 질문에 대한 과거 답변 보기' 같은 보조 흐름을 노출해 체감 대기 시간을 깎습니다.
• 결제 모듈 장애: 메인 결제수단이 실패하면 '간편결제로 시도해 보기' 같은 보조 결제 진입점을 같은 화면 안에서 즉시 제안합니다.

폴백 설계 시 챙겨야 할 4가지

폴백을 설계할 때 자주 놓치는 지점을 표로 정리합니다.

설계 포인트	핵심 질문
폴백 트리거	무엇을 '실패'로 볼 것인가 (타임아웃·에러 코드·신뢰도 임계치)
폴백 결과의 품질	대체 응답이 사용자 신뢰를 깎지 않을 만큼은 의미 있는가
폴백 가시화	사용자가 '지금은 축소된 모드'임을 인지하게 할 것인가, 감출 것인가
폴백 관측성	폴백이 발동된 비율·시간대·원인을 추적 가능한가

특히 마지막 항목이 자주 빠집니다. 폴백이 잘 동작하면 사용자에게 보이지 않으니, 개발팀도 인지 못 한 채 "메인 경로가 계속 실패하는 상태"가 몇 주씩 굳어버리는 일이 있습니다. 폴백 발동률을 메트릭으로 띄우는 것이 사실상 필수입니다.

멈추지 않는 시스템이 곧 제품의 신뢰

폴백은 30년 전부터 있던 개념이지만, 시스템이 잘게 쪼개지고 AI가 들어오고 사용자 기대치가 올라간 지금 다시 무게가 실립니다. 핵심은 단순합니다. 실패는 일어난다. 단, 사용자에게는 멈춤이 아니라 축소된 기능으로 도달하게 한다.

기획자라면 "이 기능이 실패하면 사용자에게 무엇을 대신 보여줄 것인가"를 처음부터 스펙에 적어두는 습관이 필요합니다. 개발자라면 외부 의존성마다 폴백 경로를 같이 코드 리뷰에 올리는 게 표준이 됩니다. 디자이너라면 정상 화면·로딩 화면·에러 화면 뒤에 '축소 모드 화면' 한 장을 더 그려두는 게 좋은 출발점입니다.

멈추지 않는 시스템을 만든다는 건 결국 사용자가 우리 제품을 떠나지 않게 만든다는 뜻입니다. 폴백은 그 출발점에 놓이는 가장 단순하고 가장 강력한 설계 도구입니다.