추천 API가 실패했을 때 화면에 남기는 것

FAILURE MAP

모든 오류를 같은 상태로 다루지 않았습니다

메뉴 목록을 받지 못한 경우, 추천 요청만 실패한 경우, 메뉴판 요청이 실패한 경우는 사용자가 할 수 있는 일이 서로 다릅니다. 하나의 공통 오류 화면으로 보내면 이미 확보한 데이터와 가능한 행동까지 버리게 됩니다.

화면은 현재 사용할 메뉴가 있는지, 이전 캐시가 유효한지, 임시 결과를 만들 수 있는지와 같은 요청을 다시 보낼 수 있는지를 나눠 판단합니다. 장애 범위를 좁히면 서비스 전체 대신 실패한 기능만 제한할 수 있습니다.

카탈로그 캐시도 메뉴도 없는 경우에는 추천이 가능한 것처럼 꾸미지 않습니다. 홈 본문을 독립된 장애 안내와 다시 시도로 바꾸되 헤더, 하단 탐색과 정보 문서는 유지합니다.

유효한 메뉴 카탈로그 응답은 버전과 저장 시각을 함께 브라우저에 보관합니다. 15일 이내 재방문에서는 이전 메뉴로 초기 화면을 구성한 뒤 네트워크 요청으로 백그라운드 갱신합니다.

카탈로그 요청이 실패하거나 5초 안에 응답하지 않아도 유효한 이전 캐시가 있으면 메뉴 탐색을 계속합니다. 반대로 저장 시각이 잘못됐거나 만료된 캐시는 최신 데이터처럼 사용하지 않고 로드 과정에서 제거합니다.

15일 안에도 메뉴 원본은 바뀔 수 있어 캐시로 화면을 연 뒤 갱신 요청을 보냅니다. 갱신에 실패하면 이전 목록을 쓰게 된다는 점이 이 방식의 한계입니다.

추천 API만 실패하고 메뉴 데이터가 남아 있다면 싫어요 목록을 제외한 최고 인기 메뉴 한 개를 임시 결과로 표시합니다. 이 결과는 조건 점수를 계산한 정상 추천이 아니므로 화면에서 ‘임시선택중’ 상태로 구분합니다.

메뉴판 요청이 실패한 경우에도 준비된 메뉴 데이터가 있으면 인기 메뉴를 최대 15개까지 제공할 수 있습니다. 어떤 요청이 실패했는지에 따라 추천과 메뉴판이 서로 다른 대체 규칙을 사용합니다.

임시 메뉴를 그대로 선택하거나 추천 요청을 다시 보낼 수 있습니다. 연결이 돌아왔을 때 앱을 처음부터 열지 않아도 되도록 재시도 버튼을 남겼습니다.

추천 방식, 서비스 소개, 개인정보처리방침, 이용약관과 문의 문서는 React 앱과 API 상태에 의존하지 않는 정적 HTML로 제공합니다. 장애 중에도 처리 정보, 서비스 한계와 문의 방법을 확인할 수 있어야 하기 때문입니다.

오류 화면이 문의 링크 자체를 가리거나 앱 재실행만 반복해서 요구하지 않게 합니다. 서비스 기능과 신뢰 문서를 분리하면 기능 장애가 전체 정보 접근 장애로 번지는 일을 줄일 수 있습니다.

광고를 도입하더라도 오류, 유지보수, 빈 결과처럼 게시자 콘텐츠가 없는 화면에는 표시하지 않는 원칙을 유지합니다.

운영 검증에서는 성공 화면만 보지 않습니다. 카탈로그만 실패한 경우, 추천 API만 실패한 경우, 메뉴판이 먼저 실패한 경우, 캐시가 만료된 경우와 저장 자체가 제한된 경우를 별도 시나리오로 다룹니다.

자동 테스트는 캐시·추천·메뉴판의 상태 전환과 대체 결과를 확인하고, 실제 브라우저에서는 안내 문구, 다시 시도, 남아 있는 탐색과 공개 문서 접근을 확인합니다. 장애 발생률과 이탈률의 변화는 이 검사에서 측정하지 않았습니다.

메뉴가 남아 있으면 탐색과 임시 선택을, 아무 데이터도 없으면 재시도와 안내를 보여 줍니다. 장애 화면에서 확인할 것은 오류 문구 하나보다 이 버튼들이 실제로 열리는지입니다. 캐시가 있는 재방문과 데이터가 없는 첫 방문을 따로 검사하고 있습니다.