01 배경
VINO의 제안 배경
와인 입문자
와인 정보의 복잡성
- 와인 정보는 라벨, 품종, 빈티지, 산지, 생산자 등 비정형 요소가 많아 입문자가 핵심을 빠르게 이해하기 어렵다. 이로 인해 입문자는 무엇을 기준으로 선택해야 하는지 판단하기 어렵다.
- 라벨·품종·빈티지 등 복잡한 정보 구조
- 입문자에게 명확한 선택 기준 부재
실생활 음식과의 연결 부족
- 대부분의 와인 정보와 추천은 서양 음식 중심으로 구성되어 있어 한식·매운 음식 등 일상 식사에 바로 적용하기 어렵다.
- 서양 음식 중심의 와인 페어링 정보
- 일상 식사에 적용하기 어려운 추천
검색 기반 정보의 한계
- 검색을 통해 얻는 와인 정보는 단편적이고 표현이 제각각이어서 입문자가 질문 맥락에 맞는 답을 종합해 해석하기 어렵다.
- 단편적이고 파편화된 정보
- 질문 맥락을 반영하지 못하는 검색 결과
02 기획 의도
VINO의 기획 의도
“흩어진 와인 정보의 파편을, 대화로 풀어주는 입문 가이드”
단순 정보 나열 중심의 와인 콘텐츠
질문 맥락을 이해하는 대화형 가이드
검색 기반 정보의 파편화
흩어진 정보를 하나의 답으로 재구성
실생활 적용까지 이어지지 않는 와인 추천
실생활 중심의 설명형 추천
정보 신뢰도 판단 부담의 사용자 전가
응답 신뢰도를 보강하는 다단계 구조
03 구조
VINO의 서비스 흐름 설계
- 1
질문 유형에 따라 응답 경로 분기
모든 질문을 동일한 방식으로 처리하지 않음.
- 2
생성과 평가를 분리한 다단계 구조
sLLM 응답 생성 후 적절성 평가 수행.
- 3
내부 지식과 외부 정보를 단계적으로 활용
RAG → 외부 검색 순으로 단계적 보완
- 4
사용자에게는 하나의 정제된 답만 제공
복잡한 처리 과정은 내부에서만 수행
04 주요 기능
VINO의 주요 기능
일반 사용자 (와인 입문자)
- 챗봇과의 대화를 통해 와인 정보를 질문 맥락에 맞게 이해하고 정리
- 품종·산지·스타일 등 흩어진 와인 정보를 하나의 설명으로 통합 제공
- 요약 + 핵심 포인트 구조로 입문자가 기억해야 할 정보만 직관적으로 제시
- 음식, 상황, 취향을 기준으로 실생활에 바로 적용 가능한 설명형 추천 제공
- 이전 질문을 반영한 연속 대화를 통해 검색 없이 이해를 확장하는 경험 제공
- 추가 질문을 유도하는 자연스러운 응답으로 와인 선택까지의 판단 부담 감소
05 고려사항
주요 고려사항
주요 고려사항 1
Hallucination (환각문제)을 어떻게 해결할 것인가?
기존 문제점
- 일반 LLM 응답은 모델 내부 지식에 의존하여 환각 문제 발생 가능
- 질문 맥락과 무관한 정보까지 함께 생성되어 응답 신뢰도 판단이 어려움
- 출처가 불명확한 설명으로 인해 입문자가 정보를 그대로 신뢰하기 어려움
접근 방식
- FAISS Vector Store를 활용해 와인 문서를 임베딩·인덱싱하고, 질문과 유사한 정보만 선별 활용
- RAG 파이프라인 적용으로 추측성 생성이 아닌, 근거 기반 설명 중심 응답 생성
- 평가 결과에 따라 재탐색·재생성·외부 검색을 단계적으로 적용
- 최종적으로 검증된 하나의 응답만 사용자에게 제공하여 신뢰도 판단 부담 최소화
주요 고려사항 2
LLM 응답은 언제 '충분하다'고 판단할 수 있을까?
생성 응답만으로 판단하기 어려운 이유
- LLM 생성 응답은 자연스럽게 보이더라도 질문을 충분히 충족했는지 판단하기 어려움
- 내부 지식만 활용한 답변은 정보 누락 여부를 사용자 입장에서 확인하기 어려움
- 결과적으로 언제 추가 검색(RAG/외부 검색)이 필요한지 기준이 불명확함
접근 방식
- GPT 모델을 평가자(LLM-as-a-Judge)로 활용해 생성 응답의 충분성·적합성 평가
- 응답이 질문을 충분히 충족하는지 여부를 평가 결과로 판단
- 불충분하다고 판단될 경우 내부 지식 기반 RAG 단계로 분기
- 내부 문서로도 보완이 어려운 경우에만 외부 검색(Tavily) 단계로 확장
06 회고
VINO 회고
팀장으로서의 역할 인식
이번 VINO 프로젝트는 와인 입문자를 위한 챗봇을 직접 기획하고, 설계부터 구현까지 전 과정을 책임진 첫 팀장 경험이었다. AI·LLM을 함께 공부해 온 동료들이 아닌, 각자 강점과 속도가 다른 팀원들과 협업해야 했기 때문에 기술 구현보다도 의사결정의 맥락을 설명하고 방향을 공유하는 역할이 중요했다. 단순히 "되는 코드"를 만드는 것이 아니라, 팀 전체가 구조를 이해하고 따라올 수 있도록 정리하는 과정에서 팀장이라는 자리의 무게를 실감했다.
응답 구조의 재설계
단순한 LLM 응답 생성에 그치지 않고, sLLM → GPT 기반 응답 평가 → RAG → 외부 검색(Tavily)으로 이어지는 다단계 응답 흐름을 설계했다. LLM의 응답을 그대로 신뢰하기보다, GPT 모델을 활용해 "이 응답이 충분한가?"를 평가 기준으로 삼고, 필요할 때만 검색 범위를 확장하는 구조를 코드로 구현했다. 이 과정에서 생성과 평가를 분리한 구조가 hallucination을 줄이고, 사용자에게는 하나의 정제된 답변만 제공할 수 있다는 점이 특히 인상 깊었다.
선택과 집중의 경험
제한된 개발 기간과 인프라 환경 속에서, 모든 기능을 완성하기보다 핵심 파이프라인의 안정성에 집중했다. AWS 배포 과정에서 디스크 용량 이슈로 완전한 CI/CD 구성까지는 도달하지 못했지만, 파인튜닝된 모델을 직접 업로드하는 대안적 접근을 검토하며 현실적인 문제 해결 방식을 고민했다. 또한 Django Admin 권한 이슈를 해결하며, 단순한 버그 수정이 아닌 프레임워크 구조를 이해하는 경험을 쌓을 수 있었다.