배경(Problem)
외국인 관광객의 실제 문제
•
방한 외래관광객 급증: 2024년 1,637만 명, 2019년 대비 93.5% 수준 회복.
•
한국 음식에 대한 관심 폭증: 2024년 외국인 관광객의 한국 여행 만족 활동 1위가 식도락 관광(65.3%).
•
그러나 실제 여행 현장에서는
◦
지도/교통 시스템의 한계: Google Maps는 한국 내 주요 기능 제약, 로컬 지도 서비스는 다국어 UX 한계 존재.
◦
언어 장벽: 외국인 관광객의 25.3%가 언어 소통을 주요 불편 요소로 지적.
◦
메뉴 이해 문제: 번역 불완전 + 메뉴 설명 부족 → 음식 선택 어려움.
해결하고자 한 문제
•
외국인 관광객이 “갈 수 있는 곳”이 아닌 “실제로 가기 쉬운 곳”을 추천받지 못하는 문제
•
리뷰 조작/편향 위주의 기존 추천 시스템 한계
•
다국어 환경에서의 사용자 정보 수집과 개인화 추천의 비효율성
이 프로젝트는 “외국인 관광객의 실제 이동과 이해 가능성을 동시에 고려한 음식 추천 시스템”을 목표로 시작되었다.
서비스 소개(Solution)
서비스 개요
여긴어때는 외국인 관광객을 대상으로 하는 다국어 음식 추천 서비스이다.
•
단순 맛집 추천이 아닌,
대중교통 기반 이동 편의성 + 전문 미식 평가 + 사용자 프로필 기반 추천을 결합한 구조
•
지원 언어: 한국어, English, 日本語, 中文
서비스 주요 기능
① LLM 기반 사용자 프로필 자동 수집
•
14개 항목(국적, 여행 유형, 예산, 매운 음식 여부, 출발지 등)을 대화를 통해 수집
•
한 질문당 하나의 정보만 수집하도록 설계 → 응답 품질 안정화
•
모든 데이터는 내부 표준 포맷(한글 키워드 기반)으로 변환하여 RAG 필터링 활용
② 하이브리드 추천 엔진
•
ChromaDB + RAG 기반 1차 후보군 도출
•
GraphHopper 기반 이동거리 및 환승 난이도 계산
•
최종 점수는 4개 요소 가중합:
◦
이동 편의성 40%
◦
외국인 친화도 30%
◦
품질 점수(Blue Ribbon) 20%
◦
가격 적합성 10%
③ 다국어 번역 파이프라인
•
사전 번역 + 번역 API + LLM 검증 구조
•
메뉴명, 지명, 카테고리 불일치 문제 최소화
④ 카드 기반 UI
•
추천 결과를 이미지 + 핵심 태그 + 가격 + 이동 정보로 제공
•
React 및 Gradio 각각의 프로토타입 구현
시연 기록
Gradio
React
아키텍처 및 핵심 기능
전체 시스템 구조
[User]
│
▼
[Survey Chatbot (LLM)]
│ → 사용자 14개 프로필 수집
▼
[Profile Summary + RAG Query Generator]
│
▼
[Vector DB (ChromaDB)]
│ → 후보 식당 Top-N 추출
▼
[Hybrid Scoring Engine]
│ ├ 이동 편의성 점수 (GraphHopper)
│ ├ 외국인 친화도 점수
│ ├ 품질 점수 (Blue Ribbon 기반)
│ └ 가격 적합성 점수
▼
[Final Ranking System]
│
▼
[Multilingual UI (Gradio / React)]
LLVM IR
복사
데이터 흐름(Data Flow)
Step 1. 사용자 입력 & 프로필 수집
•
사용자는 챗봇 UI(Gradio/React)에서 자연어로 대화
•
LLM이 14개 항목의 프로필 스키마를 단계적으로 채워감
•
모든 값은 한글 기반 표준 키워드로 정규화되어 저장
Step 2. 프로필 요약 및 RAG 검색
•
완성된 프로필 JSON → generate_rag_query()를 통해 검색용 쿼리 생성
•
해당 쿼리를 ChromaDB(Vector DB)에 입력
•
다국어 임베딩 모델: paraphrase-multilingual-mpnet-base-v2 사용
•
출력: 추천 후보 식당 Top-N
Step 3. GraphHopper 기반 경로 계산
•
후보 식당 각각에 대해:
◦
사용자 출발 위치 ~ 식당까지의 도보 거리
◦
환승 횟수
◦
총 이동 소요시간을 GraphHopper + GTFS + OSM 데이터로 계산
핵심 기능 목록 및 설명
1. LLM 기반 사용자 프로필 수집 시스템
•
사용자의 국적/연령/여행유형/예산/기피 재료 등 14개 항목 수집
•
한 번에 하나의 질문만 수행 → 응답 신뢰도 상승
•
모든 수집 값은 RAG 필터용 표준 포맷(한글 키워드)로 변환 저장
→ 단순 챗봇이 아니라 추천 데이터 파이프라인의 시작점 역할 수행
2. Hybrid 추천 엔진 (핵심 엔진)
추천 시스템은 2단계 구조로 구성된다.
1단계: RAG + Vector Search
•
사용자 프로필 임베딩
•
ChromaDB에서 유사 사용자/식당 벡터 검색
•
상위 후보 리스트 Top-N 추출
2단계: 하이브리드 점수 계산
각 식당에 대해 아래 4가지 점수를 산출:
항목 | 설명 | 가중치 |
이동 편의성 | GraphHopper 기반 실제 이동 난이도 | 40% |
외국인 친화도 | 메뉴판, 영어 응대, 후기 기반 점수 | 30% |
품질 점수 | Blue Ribbon 전문가 평가 | 20% |
가격 적합성 | 사용자의 budget과의 매칭 | 10% |
3. GraphHopper 기반 라우팅 & 이동 마찰 점수
•
자체 라우팅 서버 구축
•
OSM + GTFS 기반 대중교통 네트워크 적용
•
단순 거리 계산이 아니라:
◦
도보 거리
◦
환승 난이도
◦
체감 소요시간을 종합 → 이동 마찰 점수 생성
4. 다국어 번역 파이프라인
•
한국어 → 영어/중국어/일본어 자동 변환
•
단순 번역 API가 아니라:
◦
사전 기반 Glossary 적용
◦
LLM 후처리 보정
◦
고유명사 정규화
→ 음식명, 지명, 카테고리 오역 방지 목적
5. 프론트엔드 UI (Gradio / React)
•
Gradio: 빠른 프로토타이핑용
•
React: 서비스 구조 확장용
UI 특징:
•
카드뷰 추천 결과
•
상세 모달(메뉴, 가격, 지도 링크 제공)
•
다국어 전환 가능
•
가중치 슬라이더 제공
활용 라이브러리 및 개발 환경
1. 개발 환경
•
언어: Python 3.12 (백엔드/데이터/추천), JavaScript (React 프론트엔드)
•
환경 관리: Conda/venv + .env 기반 API 키 관리
•
배포/테스트: Runpod 서버에 FastAPI + UI 배포
2. 백엔드 & 추천 시스템
•
FastAPI: 챗봇 및 추천 API 서버 구현
•
ChromaDB: 음식점/메뉴 벡터 검색용 Vector DB
•
sentence-transformers: 다국어 임베딩 모델
(paraphrase-multilingual-mpnet-base-v2)
•
OpenAI GPT-4.1-mini / GPT-4o:
사용자 프로필 수집, RAG 쿼리 생성, 다국어 응답 생성
•
GraphHopper (OSM + GTFS):
대중교통 기반 경로 계산 및 이동 편의성 점수 산출
3. 데이터 처리 & 수집
•
pandas / numpy: 음식점 및 메뉴 데이터 정제·가공
•
Selenium 기반 크롤러: 외부 음식점/메뉴 데이터 수집
•
정규표현식(Regex): 메뉴명/옵션/가격 자동 분해 로직 구현
4. 프론트엔드
•
Gradio: 챗봇 및 추천 UI 프로토타입
•
React: 최종 웹 서비스 UI
•
Axios: 프론트–백엔드 API 통신
5. 선택 이유 요약
•
GraphHopper: 상용 지도 API 비용/제약 회피 및 라우팅 커스터마이징
•
ChromaDB: 광고 없는 경량 Vector DB, RAG에 적합
•
Gradio: LLM 기반 서비스 빠른 프로토타이핑
•
React: 확장 가능한 실서비스 UI 구조
트러블 슈팅
1. 대중교통 경로 계산 성능 문제
•
초기에는 Neo4j 그래프 DB로 버스 경로를 구현했지만,
하나의 정류장 노드에 너무 많은 노선 edge가 연결되면서 경로 계산 시간이 기하급수적으로 증가했다.
•
그래프 구조를 재설계하는 대신, 라우팅 특화 엔진(GraphHopper)으로 전환하고
OSM + GTFS 기반 경로 계산 구조로 변경하여 성능 문제를 해결했다.
2. GTFS 데이터 타입 오류로 인한 라우팅 엔진 빌드 실패
•
GraphHopper 빌드 중 34만 건 이상의 노선 데이터가 로드되지 않는 오류 발생.
•
원인은 GTFS 데이터의 정류장 순서 필드가 2.0 같은 실수 문자열 형태였고,
Java 엔진이 이를 정수로 인식하지 못한 언어 간 타입 호환 문제였다.
•
모든 필드를 전수 타입 검사 후 정수형으로 강제 변환하는 전처리 파이프라인을 적용해 해결.
3. 메뉴 데이터 옵션/가격 파싱 오류
•
크롤링된 메뉴 데이터에서
삼선짬뽕 2,8000원, 생오겹살 (180g), 180원 같은 비정형 텍스트가 다수 발생하여
기존 정규식 로직으로는 안정적인 파싱이 어려웠다.
•
해결 방식:
◦
“마지막 숫자+원 = 가격” 규칙 적용
◦
가격 직전 토큰만 옵션 후보로 판단
◦
옵션 패턴(200g, S/M/L 등)에 부합할 때만 옵션 인정
•
이 규칙으로 가격/옵션 분해 정확도를 크게 안정화했다.
4. 다국어 번역 및 프로필 카드 불일치 문제
•
자동 번역만 사용했을 때 음식명·지명 고유명사 오역이 잦았고,
LLM 요약문을 기반으로 프로필 카드를 렌더링하면서 JSON 값과 UI 표시가 달라지는 문제가 발생했다.
•
해결 방식:
◦
한–영–일–중 Glossary(번역 사전) 직접 구축
◦
UI는 요약문이 아닌 JSON 구조를 1순위로 렌더링, 요약은 보조 용도로만 활용
•
그 결과, 번역 일관성과 UI 신뢰도가 모두 개선되었다.
팀 소개
1. 소개말 – 팀명: 여긴어때?
팀명 여긴어때?는 여행 중 풍경, 가게 분위기, 주변 사람들의 추천을 듣고
장소를 떠올리며 자연스럽게 말하게 되는 표현 “여긴 어때?”에서 착안했다.
한국에서 음식을 고를 때 느끼는 막막함을 줄이고, “여기 가도 될까?”라는 고민에 답해주는 서비스를 만들겠다는 의미를 담았다.
2. 팀 구성 및 역할
•
[팀장 / 백엔드 · 라우팅]
◦
GraphHopper 기반 대중교통 경로 계산 엔진 구축
◦
GTFS/OSM 데이터 전처리
◦
이동 편의성 점수 설계 및 전체 기술 흐름 관리
•
[데이터 · 크롤링 / UI · 번역]
◦
음식점/메뉴 데이터 크롤링 및 수집
◦
Figma 기반 UI 프로토타입 제작
◦
Gradio UI 사전변역 준비
◦
한/영/중/일 다국어 번역 기능 설계 및 적용
•
[AI / 서비스 통합]
◦
LLM 기반 사용자 프로필 생성 챗봇 개발
◦
7,700개 음식점 / 55,000개 메뉴 데이터 임베딩 & VectorDB 구축
◦
RAG + Filter 기반 Hybrid Search 엔진 구현
◦
Gradio UI 변환 및 Runpod 서비스 배포
•
[데이터 / 번역]
◦
음식점·메뉴 데이터 전처리
◦
데이터 정규화 및 번역용 Glossary(사전) 구축
◦
Neo4j 가상 데이터 기반 그래프 구조 테스트
◦
프로젝트 기획서, 중간보고서, 발표 자료 작성 담당
3. 프로젝트 리뷰
•
초반에 목표가 컸지만, 실제 구현 단계에서는 MVP 완성에 집중하는 전략적 전환이 필요했음을 체감했다.
•
추천 시스템, 경로 계산처럼 구조 설계가 중요한 영역에서 초기 설계의 중요성을 명확히 경험했다.
•
각자 역할이 있었지만, 라우팅 오류, 데이터 파싱 문제, 번역 오류 등 핵심 이슈는
팀 단위로 구조를 재검토하며 해결하는 협업 방식을 유지했다.
•
단순 구현을 넘어 “기획–데이터–AI–서비스 연결 구조”를 경험한 점이 가장 큰 수확이었다.