추천 결과가 마음에 들지 않을 때 갈 곳 만들기

결과 하나로는 결정을 끝낼 수 없었다

점수 추천을 처음 넣었을 때는 필터와 메뉴 속성을 비교해 한 메뉴를 고르는 데 집중했다. 하지만 점심 결정은 정답을 맞히는 문제가 아니라 후보를 좁혀 다시 고르는 과정에 가깝다. 결과가 마음에 들지 않을 때의 다음 행동이 없으면 추천도 신뢰를 얻기 어려웠다.

그래서 추천 버튼만 다듬는 대신 메뉴판을 별도 탐색 경로로 만들고, 카드에서 메뉴를 직접 열 수 있게 했다. 사용자는 조건으로 시작하거나 목록에서 시작할 수 있게 됐다.

점수 필터와 다중 선택값을 메뉴 데이터에 넣고, 추천 계산은 조건과 메뉴를 비교하도록 만들었다. 메뉴판에서는 추천 순위와 관계없이 목록을 둘러보고 직접 고를 수 있게 했다.

메뉴판은 끝에서 멈추는 목록보다 계속 둘러볼 수 있는 흐름을 택했다. 이는 많은 메뉴를 아직 갖지 못한 초기 단계에서 적은 데이터가 반복 노출되는 어색함도 줄이는 방법이었다.

메뉴가 열 개뿐이어서 먼저 화면 이동을 시험했다. 추천 결과에서 메뉴판을 열고, 다른 메뉴를 직접 고른 뒤, 필터를 바꿔 다시 추천받는 경로를 확인했다. 사용자 대상 사용성 조사는 이 단계에 포함하지 않았다.

이때 추천은 열 개 메뉴를 브라우저에서 계산했다. 서버 추천과 대규모 메뉴 목록은 이후에 추가됐다.

첫 추천 로직, 스크롤 메뉴판, 메뉴 선택, 메뉴 이미지와 이미지 fallback을 순서대로 추가했다. 이후 위치 설정을 더하면서 사용자가 저장한 값과 화면 표시가 어긋나지 않도록 localStorage 처리도 손봤다.

필터 조합별 결과가 바뀌는지, 메뉴판의 연속 이동이 경계에서 끊기지 않는지, 이미지가 없는 메뉴가 화면을 깨뜨리지 않는지를 확인했다. 위치 데이터는 지역 이름을 위한 것이지 정확한 좌표를 저장하기 위한 기능으로 만들지 않았다.

초기 추천 계산은 프런트 코드 안에 있었고, 열 개 메뉴로 만든 점수는 사용자 취향의 복잡성을 대표하지 못했다. 이미지 파일을 추가하는 일도 메뉴 ID와 이름이 바뀌면 쉽게 어긋날 수 있다는 문제를 드러냈다.

이 프로토타입에서 추천 결과와 메뉴판 사이의 이동을 먼저 확인했다. 메뉴가 수백 개로 늘어났을 때의 후보 분포나 서버 응답은 후속 작업에서 다뤘다.

마음에 드는 추천이 없으면 메뉴판에서 직접 고를 수 있었다. 추천 카드를 다시 누르는 방법만 남겼다면 사용자는 같은 시도를 반복해야 했을 것이다. 조건을 조정하는 화면과 목록에서 고르는 화면을 함께 둔 이유다.

열 개 메뉴를 순환하는 목록은 금방 익숙해지지만, 메뉴가 늘면 원하는 항목을 다시 찾기 어렵다. 순환 메뉴판만으로 계속 탐색할 수 있을지, 검색이나 분류가 필요할지는 데이터 확장 뒤에 확인할 과제로 남았다.