WTHeat Blog
WTHeat 메뉴 태그를 붙이고 검사하는 기준
102개 음식 데이터에서 카테고리와 태그를 어떻게 나누고, 빌드 전에 어떤 오류를 검사하는지 실제 구조를 기준으로 설명합니다.
카테고리는 음식 이름이 아니라 탐색 범위입니다
현재 음식 데이터는 한식, 중식, 일식, 양식, 분식, 패스트푸드, 카페, 기타 JSON 파일로 나뉩니다. 카테고리는 정답 분류표가 아니라 화면에서 후보를 빨리 줄이기 위한 기준입니다. 한 메뉴가 여러 문화권에 걸쳐 있어도 사용자가 어디에서 찾을지 우선합니다.
한식이 30개로 가장 많은 이유도 일상 점심에서 자주 보는 후보가 많기 때문입니다. 모든 지역 음식을 넣는 사전이 아니라 반복해서 고민하는 메뉴 목록이라 범위를 무작정 넓히지 않습니다.
태그는 이름으로 찾기 어려운 상태를 담습니다
메뉴 이름이 떠오를 때는 검색창에 이름을 입력하면 됩니다. 태그는 국물, 면, 든든함, 가벼움처럼 오늘 필요한 상태를 찾는 데 씁니다. 같은 의미의 태그를 여러 표현으로 만들면 검색 결과가 갈라지므로 짧고 반복 가능한 단어를 사용합니다.
가격, 영양, 알레르기처럼 실제 식당과 조리법에 따라 달라지는 값은 단정적인 태그로 쓰지 않습니다. WTHeat의 메뉴 데이터는 의료 정보나 실시간 가격표가 아닙니다.
빌드 전에 102개 항목을 검사합니다
저장소에는 validate-foods 스크립트가 있습니다. 현재 실행 결과는 102개 항목 모두 활성 상태입니다. ID가 비어 있거나 중복되는지, 이름과 카테고리가 유효한지, 태그 형식이 맞는지 확인한 뒤 빌드를 진행합니다.
이 검사는 메뉴가 맛있는지 판단하지 못합니다. 대신 데이터 한 줄의 오타 때문에 선택 상태가 꼬이거나 같은 메뉴가 두 번 보이는 문제를 막습니다. 음식 목록이 작아도 자동 검사를 두는 이유입니다.
메뉴를 추가할 때 보는 것
새 메뉴는 기존 후보와 실제로 다른 선택지를 주는지 봅니다. 이름만 조금 다른 메뉴를 계속 넣으면 목록은 커지지만 결정은 어려워집니다. 계절 메뉴나 자주 찾는 메뉴라도 비슷한 후보가 이미 있다면 태그 보강으로 끝낼 수 있습니다.
추가 뒤에는 검색어로 찾을 수 있는지, 카테고리 화면에서 튀지 않는지, 모바일에서 이름이 잘리지 않는지 확인합니다. 데이터 수보다 실제 후보 목록에서 쓸 수 있는지가 우선입니다.