CHALLENGE
클라이언트 매장에는 외국인 방문객과 처음 온 고객이 많았지만, 메뉴 수가 늘어날수록 직원 설명 없이 무엇을 골라야 할지 결정하기 어려웠습니다. 번역된 메뉴판만으로는 글자를 읽을 수 있을 뿐, 취향·식이 조건·알레르기와 현재 판매 가능 여부를 한 번에 판단하기 어려웠습니다.
클라이언트가 필요로 한 이유
클라이언트 매장에서 필요했던 것은 번역 문구를 더 추가하는 일이 아니었습니다. 고객은 매운맛을 원하는지, 따뜻한 음식이 좋은지, 피해야 할 재료가 있는지를 먼저 생각하지만 기존 메뉴판은 카테고리와 가격부터 보여줬습니다. 고객의 결정 순서와 화면의 정보 순서가 어긋나면서 메뉴가 많을수록 탐색 시간이 길어지고 직원 설명도 반복됐습니다.
추천 화면이 실제 준비 수량과 분리되면 품절 메뉴가 계속 노출되는 문제도 있었습니다. 그래서 언어별 메뉴판을 여러 벌 만드는 대신, 짧은 설문으로 선택 조건을 먼저 좁히고 알레르기 안전 조건과 현재 판매 상태를 확인한 뒤 추천 근거를 보여주도록 설계했습니다. 고객 화면과 직원 화면이 같은 메뉴 상태를 읽게 한 이유도 추천과 현장 운영이 어긋나지 않게 하기 위해서였습니다.
번역된 메뉴판을 늘리는 대신, 고객의 조건을 먼저 좁히고 추천 이유까지 설명하는 태블릿 흐름을 설계했습니다.
| 이용자 과제 | 시스템에서 다룬 방식 |
|---|---|
| 긴 메뉴 탐색 | 6문항의 짧은 단계형 설문으로 선택 범위 축소 |
| 추천 이유 불명확 | 각 메뉴에 선택 조건과 일치한 추천 근거 표시 |
| 언어 전환 시 맥락 손실 | 진행 단계와 답변을 유지한 채 4개 언어 전환 |
| 품절 메뉴 노출 | 메뉴 준비 수량·판매 상태를 추천과 즉시 연결 |
클라이언트 요청사항과 기획 방향
클라이언트 요청을 단순 번역 화면으로 해석하지 않고, 처음 방문한 고객이 짧은 시간 안에 안전하게 메뉴를 고르는 과정으로 다시 설계했습니다.
| 클라이언트 요청 | 이렇게 기획한 이유 | 해결 방식 |
|---|---|---|
| 한국어가 익숙하지 않아도 스스로 주문하고 싶다 | 메뉴 전체를 번역해도 선택지가 많으면 결정 시간은 줄지 않음 | 4개 언어와 6문항 단계형 설문으로 선택 범위를 먼저 축소 |
| 추천 결과를 믿을 수 있게 설명하고 싶다 | 결과만 보여주면 알레르기·채식·매운맛 조건이 반영됐는지 알기 어려움 | 제외 조건을 먼저 적용하고 메뉴마다 추천 근거를 표시 |
| 현장 품절과 준비 상태를 즉시 반영하고 싶다 | 추천 뒤 주문할 수 없는 상황이 생기면 고객과 직원 모두 다시 확인해야 함 | 준비 수량·품절·판매 상태를 추천 후보와 운영 화면에 동시에 반영 |
SOLUTION
클라이언트가 원한 셀프 선택 경험에 맞춰 고객용 키오스크와 직원용 운영 화면을 분리하되, 둘이 같은 메뉴 상태를 읽도록 구성했습니다. 고객은 매장을 선택한 뒤 한국어·영어·일본어·중국어 중 하나를 고르고, 6개 질문에 답해 조건에 맞는 메뉴 3개를 추천받습니다.
고객과 직원이 함께 쓰는 순서
처음 방문한 고객은 언어를 고르고 ‘든든한 한 끼인지, 가벼운 메뉴인지’, ‘따뜻한 음식인지’, ‘매운맛을 원하는지’, ‘피해야 할 재료가 있는지’를 차례로 선택합니다. 한 화면에 질문 하나만 보여주므로 메뉴 이름을 잘 몰라도 자신의 조건부터 정리할 수 있습니다. 언어를 중간에 바꿔도 앞서 고른 답은 그대로 유지됩니다.
알레르기 충돌 메뉴와 품절 메뉴는 점수 계산 전에 제외합니다. 그다음 남은 메뉴 가운데 취향과 현재 준비 상황이 가장 잘 맞는 3개를 고릅니다. 고객은 결과에서 ‘따뜻한 음식 선호 일치’, ‘채식 조건 충족’, ‘현재 8개 준비 가능’처럼 추천 이유를 읽고 선택할 수 있습니다. 단순히 인기 메뉴를 보여주는 방식과 다른 지점입니다.
직원이 운영 화면에서 메뉴를 품절로 바꾸면 다음 추천부터 바로 빠집니다. 직원 호출도 요청·확인·완료 상태로 나뉘어 고객에게 처리 상황을 알려줍니다. 90초 동안 입력이 없으면 첫 화면으로 돌아가 다음 고객의 답변과 섞이지 않도록 했습니다.
시스템 흐름
90초 동안 입력이 없으면 개인 식별값을 남기지 않고 초기 화면으로 돌아갑니다. 설문 답변은 익명 세션 단위로 저장해 언어별 이용량과 추천 유형을 집계합니다.
메뉴 적합도 계산
추천은 먼저 안전 조건을 통과시키고, 그다음 취향 적합도를 계산하는 2단계 방식입니다. 알레르기 충돌, 품절, 준비 중지 중 하나라도 해당하면 점수와 무관하게 추천 후보에서 제외합니다.
| 점수 항목 | 반영 비중 | 계산 기준 |
|---|---|---|
| 식사 목적·기분 | 35% | 든든함, 가벼움, 새로운 메뉴 등 선택 일치 |
| 온도 선호 | 25% | 차가운 메뉴와 따뜻한 메뉴 선호 일치 |
| 매운맛 | 20% | 선호 단계와 메뉴 단계의 거리 |
| 운영 적합도 | 20% | 현재 준비 수량, 대기 시간, 매장 인기 |
각 추천 카드에는 최종 점수만 쓰지 않고 “따뜻한 음식 선호 일치”, “채식 조건 충족”, “현재 8개 준비 가능”처럼 점수를 만든 근거를 함께 표시했습니다. 같은 점수라면 준비 가능 수량, 예상 대기 시간, 메뉴 ID 순서로 정렬해 결과가 매번 바뀌지 않도록 했습니다.
추천 공개 조건
추천 결과는 안전 조건 충족, 판매 상태 활성, 준비 수량 1개 이상, 필수 번역 완료라는 네 조건을 모두 만족해야 고객 화면에 공개됩니다. 조건이 바뀌면 운영 화면의 메뉴 상태 이력과 동기화 작업에 기록되고, 다음 조회부터 즉시 추천 후보에서 제외됩니다.
고객 화면
- 큰 터치 영역과 한 화면 한 질문 방식
- 질문마다 이전·다음 이동과 자동 저장 피드백
- 메뉴 3개의 사진, 가격, 추천 이유, 매운맛, 채식, 알레르기 표시
- 메뉴 전체 검색과 카테고리·식이 조건·가격 정렬
- 직원 호출 상태와 완료 피드백
운영 화면
- 기간·매장·언어별 설문 완료와 추천 분포
- 전체 메뉴 검색, 25·50건 페이지 이동, 2페이지 이후 상세 수정
- 판매·품절·준비 상태와 변경 이력
- 직원 호출과 동기화 작업의 성공·실패·복구 상태
BUILD
메뉴, 카테고리, 질문, 선택지, 익명 설문 세션, 답변, 서비스 이벤트, 메뉴 상태 이력, 동기화 작업을 각각 분리했습니다. 설문 답변은 언어별 문구가 아니라 공통 선택 코드로 저장해 언어를 바꿔도 의미가 유지됩니다.
데이터를 추천으로 푸는 방식
답변은 세션 ID와 문항 코드로 정규화하고, 메뉴의 식이·알레르기·온도·매운맛 속성과 대조합니다. 먼저 SQL에서 판매 가능한 후보를 줄인 뒤 애플리케이션 계층에서 가중치를 계산하고, 추천 결과와 근거 코드를 함께 반환합니다. 운영 대시보드는 원본 답변을 개인 단위로 보여주지 않고 매장·언어·기간별 집계로만 제공합니다.
검증한 데이터 규모
| 데이터 | 규모 |
|---|---|
| 매장 / 메뉴 | 48 / 384 |
| 설문 세션 | 2,400 |
| 설문 답변 | 14,288 |
| 서비스 이벤트 | 5,599 |
| 메뉴 상태 이력 | 837 |
| 동기화 작업 | 768 |
| 로컬 메뉴 이미지 | 24 |
VALIDATION
- 자동 테스트 13건 통과
- 프로덕션 빌드 완료
- 4개 언어의 설문·추천·메뉴 상세 흐름 확인
- 알레르기 충돌과 품절 메뉴가 점수와 무관하게 제외되는 조건 확인
- 운영 화면 2페이지 이후 메뉴 조회·수정 확인
- 준비 실패와 복구, 일시정지·재개, 새로고침 지속성 확인
- 태블릿과 모바일에서 가로 넘침 및 콘솔 오류 없음
RESULT
| 이용 장면 | 기존에 생기던 문제 | 구축 후 처리 방식 |
|---|---|---|
| 첫 메뉴 선택 | 번역된 전체 메뉴를 처음부터 읽어야 함 | 6개 질문으로 조건을 좁히고 메뉴 3개와 추천 이유를 제시 |
| 알레르기·품절 확인 | 주문 직전에 직원 설명으로 다시 확인 | 안전 조건과 판매 상태를 점수 계산 전에 제외 |
| 언어 전환과 다음 고객 | 언어를 바꾸면 선택 맥락이 끊기고 이전 답변이 남을 수 있음 | 답변을 유지한 언어 전환과 90초 무입력 초기화 적용 |
48개 매장, 384개 메뉴, 2,400개 설문 세션으로 언어·매장·재고 상태가 달라져도 같은 안전 조건과 추천 근거가 유지되는지 확인했습니다.
비슷한 업무에 적용할 수 있는 부분
활용 범위는 음식점에만 머물지 않습니다. 상품 수가 많고 고객 조건을 먼저 확인해야 하는 건강기능식품, 화장품, 체험 프로그램 안내에도 같은 흐름을 쓸 수 있습니다. 핵심은 인기순 추천이 아니라 제외 조건을 먼저 지키고 선택 이유를 설명하는 것입니다.
본 프로젝트는 고객사 실제 업무 요건을 바탕으로 설계한 결과물이며, 보안 정책에 따라 일부 화면만 공개했습니다.
