주문 화면에서 추천 상품 API가 응답하지 않습니다. 이때 화면 전체가 30초 동안 멈춘다면 추천 기능의 장애가 주문 기능의 장애로 확대된 셈입니다. 반면 추천 영역을 잠시 숨기고 주문은 계속 받을 수 있다면 고객 영향은 훨씬 작습니다. 이것이 단계적 기능 축소(graceful degradation)의 핵심입니다. 모든 기능을 무조건 계속 제공한다는 뜻이 아니라, 의존성이 고장 났을 때 어떤 업무를 안전하게 남길지 미리 결정하는 것입니다.
먼저 기능의 중요도를 분류한다
고객 여정을 그려 핵심 기능과 부가 기능을 나눕니다. 주문 저장, 결제 확인, 권한 검사는 정확성이 중요한 핵심 경로일 수 있습니다. 추천, 통계 카드, 실시간 채팅, 배송 지도는 상황에 따라 일시 중단할 수 있습니다. 다만 “부가 기능”이라고 개발팀 혼자 정하면 안 됩니다. 어떤 고객은 배송 위치가 핵심 업무일 수 있고, 어떤 고객은 승인 알림이 법정 기한과 연결될 수 있습니다. 제품·운영·고객 담당자가 함께 영향 등급을 정해야 합니다.
각 의존성에 대해 실패 형태를 씁니다. 완전한 연결 실패만이 아니라 느린 응답, 오래된 데이터, 일부 고객만 실패, 잘못된 응답도 있습니다. 타임아웃과 재시도는 필요하지만, 장애 중인 서비스에 모든 요청을 계속 재시도하면 오히려 회복을 늦출 수 있습니다. Microsoft의 회로 차단기 패턴 안내는 실패하는 의존성을 잠시 차단하고 복구를 확인하며 단계적 기능 축소에 활용하는 방식을 설명합니다.
대체 동작에도 안전 등급이 있다
추천을 숨기는 것은 비교적 안전합니다. 마지막으로 확인된 배송 위치를 보여 주는 것도 가능하지만, 반드시 “마지막 갱신 시각”을 표시해야 합니다. 반대로 결제 승인 결과를 모를 때 임의로 성공으로 표시하거나, 권한 서비스가 멈췄다고 모든 사용자를 허용하는 것은 위험합니다. 실패 시 열린 상태로 둘지 닫힌 상태로 둘지는 데이터 정합성과 보안에 따라 다릅니다. 읽기 전용으로 전환하거나 요청을 접수만 하고 나중에 처리하는 방식도 가능하지만, 사용자가 현재 무엇이 확정됐는지 분명히 알 수 있어야 합니다.
기술적으로는 의존성을 경계로 타임아웃, 동시 요청 수 제한, 회로 차단, 대체 데이터를 조합합니다. 회로 차단기가 열린 동안에는 빠르게 실패하거나 대체 경로를 사용하고, 일정 시간이 지나면 제한된 요청으로 회복 여부를 확인합니다. 회로가 닫혔다고 바로 전체 트래픽을 몰아주면 다시 장애가 날 수 있어 점진적으로 복귀합니다. 캐시된 데이터를 쓰는 경우 유효 기간과 데이터의 출처를 사용자와 운영자 모두 볼 수 있어야 합니다.
대체 경로 자체가 새로운 병목이 되지 않도록 용량도 따져야 합니다. 모든 사용자가 외부 검색 대신 내부 DB로 직접 조회하게 만들면 이번에는 DB가 무너질 수 있습니다. 기능 축소 상태에서는 페이지당 조회량을 줄이거나 중요 고객 여정을 우선 처리하는 정책이 필요할 수 있습니다. 운영자는 어느 기능이 제한됐고 몇 명의 사용자가 영향을 받는지 한 화면에서 확인해야 합니다. 단순히 외부 API 오류가 줄었다는 이유만으로 복귀하면 내부 대기열과 사용자의 미완료 작업이 남을 수 있습니다.
UI도 상태를 정직하게 보여 줘야 한다
고객은 “지금 저장되었는지”가 가장 궁금합니다. 부가 영역이 일시 중단됐다면 해당 영역에서만 안내하고, 핵심 버튼은 가능한 상태로 유지합니다. 반대로 접수만 하고 후속 처리가 지연된다면 접수 번호와 예상 처리 방식, 나중에 확인할 위치를 제공합니다. 오류를 조용히 삼켜 빈 화면을 보여 주면 고객은 결과가 없는 것인지 아직 로딩 중인지 알 수 없습니다. 접근성이 필요한 사용자도 상태 변화를 인지할 수 있게 텍스트와 화면 읽기 도구 알림을 함께 설계합니다.
훈련은 실제 외부 서비스를 끊지 않고도 테스트 환경에서 느린 응답·오류·부분 응답을 주입해 할 수 있습니다. 핵심 여정의 성공률, 대체 경로 사용률, 오래된 데이터 노출 시간, 복귀 후 밀린 작업 처리량을 측정하세요. 단계적 기능 축소는 장애를 숨기는 장치가 아니라 고객이 무엇을 할 수 있고 무엇을 기다려야 하는지 정확히 알려 주면서 핵심 업무를 지키는 약속입니다.
