2026-07-05 · DEVELOPMENT RECORD

App에 몰린 추천·메뉴판 상태 나누기

대표 카드와 후보 목록이 같은 메뉴를 서로 다른 시점의 결과로 보여 줄 수 있었다. 필터, 추천, 메뉴판과 저장 상태를 누가 만들고 갱신하는지 따라가며 구조를 나눴다.

작성 PPStudio 운영자게시 2026-07-05검토 2026-08-16

화면 상태가 한 파일에 몰렸다

추천 결과, 메뉴판 요청, 좋아요·싫어요, 필터, 현재 카드가 App 컴포넌트에 가까이 모여 있었다. 작은 기능을 고칠 때도 서로 관련 없어 보이는 상태를 함께 살펴야 했고, 결과 카드와 목록이 같은 메뉴를 서로 다른 방식으로 갱신할 위험이 있었다.

특히 후보를 별도 화면으로 넘기는 방식은 선택 흐름을 끊었다. 사용자는 대표 메뉴를 본 뒤 후보를 비교하고, 다시 필터나 퀵픽으로 돌아갈 수 있어야 했다.

대표 카드, 후보, 메뉴판과 저장 목록이 같은 메뉴를 서로 다르게 들고 있으면 표시가 어긋날 수 있었다. 상태를 만드는 곳과 갱신하는 곳을 따라가며 추천, 탐색, 저장 코드를 나눴다.

필터, 추천, 메뉴판, 메뉴 선택, 저장을 각각의 훅으로 나누고 컴포넌트는 상태와 콜백을 받게 했다. 같은 메뉴를 표시하는 코드가 있어도 추천 계산의 소유권을 UI가 갖지 않도록 했다.

추천 결과는 대표 하나와 후보 여섯 개를 캐러셀로 합쳤다. 메뉴판도 다섯 개씩 세 페이지로 구성해 한 번에 너무 많은 카드를 보이지 않도록 했다.

메뉴판 요청 중복을 막고 캐러셀을 리팩터링했으며, 퀵픽을 텍스트 목록에서 이미지 카드로 바꿨다. 카드 이동에 따라 현재 메뉴와 저장 액션이 함께 변하도록 결과 컴포넌트를 정리했다.

검증은 캐러셀의 일곱 메뉴 순환, 메뉴판 페이지 이동과 자동 순환, 새로고침 잠금, 퀵픽 선택 후의 결과 갱신을 중심으로 했다. 구조 분리 뒤에도 기존 화면의 선택 흐름이 끊기지 않는지가 핵심이었다.

훅을 나눈 뒤에도 추천 결과는 한 번의 실행 단위로 갱신해야 했다. 대표 카드만 새 결과로 바뀌고 후보에는 이전 결과가 남는 상황을 막으려면, 새 기능이 어느 상태를 읽고 쓰는지 먼저 확인해야 한다.

대표 1개와 후보 6개를 작은 화면에 넣으면 카드 높이도 탐색에 영향을 준다. 후보 수를 늘리는 변경은 스크롤 거리와 직접 선택, 재추천 버튼까지 함께 보고 결정할 문제로 남겼다.

리팩터링은 기능을 새로 만드는 일보다 회귀를 찾기 어렵다. 상태를 이동하면서 어느 훅이 브라우저 저장을 책임지는지, 현재 카드가 언제 바뀌는지를 계속 대조해야 했다.

이 단계는 UI 구조를 정리한 것이지 네트워크 실패를 모두 해결한 것은 아니다. 다음 단계에서 카탈로그와 메뉴판의 실패 범위를 구체적으로 나눠야 했다.