2026-07-07 · DEVELOPMENT RECORD
Cloudflare 이전을 준비하며 로딩 경계 나누기
메뉴판 요청이 늦다는 이유로 추천에 필요한 카탈로그까지 기다리고 있었다. Cloudflare용 어댑터를 준비하면서 첫 화면에 필요한 데이터와 나중에 받아도 되는 데이터를 나눴다.
- 플랫폼
- Node API와 Cloudflare Functions
- 초기 요청
- 카탈로그·메뉴판 병렬
- 검증
- 필터 런타임 일관성
가장 느린 요청이 첫 화면을 지배했다
카탈로그와 메뉴판은 서로 다른 목적의 데이터다. 둘 중 하나가 늦거나 실패했는데도 둘을 모두 기다리면, 사용자는 추천에 필요한 메뉴가 준비됐어도 화면을 볼 수 없었다.
Node 환경에서만 동작하던 API를 Cloudflare Pages Functions로 옮기려면 추천·메뉴판 규칙을 플랫폼 파일에 복사하지 않는 구조도 필요했다.
코어와 어댑터, 시작과 보조 데이터를 분리했다
API 코어는 공통 응답을 만들고 Node와 Functions는 전송만 맡도록 준비했다. 초기 화면은 카탈로그 준비를 기준으로 열고, 메뉴판 로딩은 본문에서 이어 가는 방향을 택했다.
오프닝 화면에는 최소 표시 시간과 fallback을 두었다. 응답이 빠르면 화면이 순간적으로 번쩍이고, 느리면 오프닝이 조작을 오래 막을 수 있어 종료 조건을 함께 정했다.
이번 변경에 포함하지 않은 것
서버리스 배포를 준비하면서 첫 화면이 기다릴 데이터도 나눴다. 메뉴를 고르는 데 필요한 데이터는 먼저 받고 장식과 보조 정보는 늦게 읽도록 했다. 운영 도메인과 검색 설정은 이후 배포 작업에서 다뤘다.
느린 요청과 잘못된 입력으로 시작 경계를 시험했다
Cloudflare 경로와 개발 설정을 준비하고, 메뉴 이미지 선요청과 초기 로딩 흐름을 다듬었다. 추천 필터는 프런트와 서버가 같은 입력을 받아들이도록 검증 규칙을 추가했다.
느린 요청, 잘못된 필터 값, 오프닝 종료 조건, 이미지 요청 실패를 점검했다. 문서 구조도 정리해 실제 코드와 오래된 계획서가 서로 다른 사실을 말하지 않게 했다.
캐시 없는 장애는 아직 막을 수 없었다
이 단계에서는 실패를 감지하고 화면을 열 기준을 정했지만, 네트워크가 끊긴 뒤 이전 메뉴를 복구하는 정책은 완성되지 않았다. API가 실패해도 무엇을 보여 줄지에 대한 답은 다음 작업에서 더 구체화됐다.
서버리스 이전도 배포 완료가 아니라 준비 단계였다. 실제 도메인, canonical, 검색 도구와의 연결은 공개 운영 단계에서 검증해야 했다.
운영에서 확인할 지점
요청 순서를 바꿔도 메뉴 API의 응답 자체가 빨라지는 것은 아니다. 첫 화면에서 기다리는 요청을 줄인 효과와 서버가 준비되는 시간은 배포 환경에서 각각 확인할 필요가 있었다. Node 서버와 Cloudflare Functions가 같은 응답을 내는지도 따로 대조했다.
제한된 재시도와 안내를 넣었지만, 저장된 메뉴가 없고 API에도 연결되지 않으면 추천할 데이터가 없었다. 이 경우를 보완하려고 이후 캐시와 앱 밖의 정적 안내 페이지를 추가했다.