01 배경
요리왕 좌룡의 제안 배경
자취생
요리 이름 중심 검색의 구조적 한계
- 기존 레시피 서비스는 '요리 이름' 또는 키워드 검색을 전제로 한다. 하지만 사용자는 원하는 요리명이 명확하지 않은 경우가 많으며, 이 경우 검색 자체가 어려워진다.
- 요리 이름을 모르면 검색 불가
- 재료 중심 탐색 불가능
현실적인 조리 환경과 사용자 제약
- 자취생이나 바쁜 직장인의 경우 보유 재료, 조리 도구, 조리 시간에 제약이 존재한다. 그러나 기존 레시피 서비스는 이러한 현실적 조건을 충분히 반영하지 못한다.
- 냉장고 재료 소진 어려움
- 조리 도구·시간 조건 고려 부족
정보 제공 중심 레시피의 한계
- 대부분의 레시피 정보는 '정확한 재료와 정해진 과정'을 전제로 제공된다. 이로 인해 일부 재료가 없거나 조건이 맞지 않는 경우 실제 조리로 이어지기 어렵다.
- 대체 재료 안내 부족
- 사용자 상황에 맞는 조정 어려움
02 기획 의도
요리왕 좌룡의 기획 의도
“냉장고 속 재료를 바로 요리로 연결해주는 대화형 레시피 가이드”
요리 이름 중심의 검색 구조
재료 중심 입력으로 검색 기준 전환
재료·도구·시간 조건 반영 부족
도구·시간 제약을 필터로 반영한 추천
정보 제공에 그치는 레시피 추천
대체 재료를 포함한 실행 중심 레시피 제안
실행 판단을 사용자에게 전가
응답 적절성을 판단하는 단계적 구조
03 구조
요리왕 좌룡의 서비스 흐름 설계
- 1
요리 질문 여부에 따른 처리 분기
요리와 무관한 질문은 레시피 추천 대상에서 제외.
- 2
레시피 응답 생성과 적절성 판단 분리
레시피를 생성한 뒤, 바로 출력하지 않음.
- 3
내부 레시피 데이터 우선 보완
유튜브 자막·레시피 데이터 기반 RAG 활용. 정보가 부족한 경우에만 외부 검색으로 확장
- 4
하나의 실행 가능한 답변만 사용자에게 제공
여러 단계를 거쳐 하나의 레시피로 정제.
04 주요 기능
요리왕 좌룡의 주요 기능
1. 보유 재료만으로 가능한 요리 추천
- 여러 재료를 자유 텍스트로 입력하여 요리 탐색 가능
- 일부 재료만 있어도 실제로 만들 수 있는 요리만 추천
- 특정 재료 제외 조건을 반영해 현실적인 선택지 제공
2. 조리 도구·시간 제약을 고려한 추천
- 전자레인지, 후라이팬 등 보유 도구 기준으로 요리 제한
- 희망 조리 시간을 반영해 과도한 조리 과정 제거
- 빠르게 완성 가능한 요리를 우선적으로 추천
3. 상황에 맞게 변형 가능한 요리 안내
- 재료가 부족한 경우 대체 가능한 재료를 함께 안내
- 사용 환경에 맞게 조리 순서와 분량 조정 제안
- 실패 가능성을 줄이기 위한 핵심 조리 팁 제공
4. 바로 따라 할 수 있는 단계별 레시피
- 조리 과정을 단계별로 나누어 명확히 안내
- 요리 경험이 적은 사용자도 바로 따라 할 수 있는 설명 제공
- 불필요한 정보 없이 완성 결과에 집중한 레시피 구성
5. 추가 질문을 통한 추천 개선
- 후속 질문을 통해 추천 범위를 자연스럽게 확장
- 재료 추가·제외 요청에 따라 추천 결과를 즉시 재조정
- 이전 대화를 반영해 반복 입력 부담 감소
6. 신뢰도 높은 레시피 추천을 위한 응답 구조
- 생성된 레시피 응답의 적절성을 한 번 더 판단
- 내부 레시피 데이터 우선 활용, 필요 시 외부 정보로 보완
- 사용자에게는 하나의 정제된 최종 레시피만 제공
05 고려사항
주요 고려사항
주요 고려사항 1
Hallucination (환각문제)을 어떻게 해결할 것인가?
기존 문제점
- Fine-tuned sLLM이라도 모델 내부 지식만으로는 재료·도구·시간 조건을 완벽히 만족하지 못해 환각/누락이 발생할 수 있음
- 질문과 직접적으로 관련 없는 정보까지 함께 생성되어 응답의 신뢰도를 판단하기 어려움
- 그럴듯한 설명 위주의 응답으로 인해 사용자가 실행 가능 여부를 스스로 판단해야 하는 부담이 발생
접근 방식
- Fine-tuned sLLM이 사용자 조건(재료·도구·시간)을 기반으로 1차 레시피 응답 생성
- 생성된 응답을 GPT 모델이 적절성 평가하여, 바로 출력할지 여부를 판단 (예: 조건 충족 여부 / 실행 가능성 / 내용 일관성 등)
- 부적절 판정 시, 멀티 쿼리를 생성해 내부 문서 RAG(FAISS)로 근거를 검색하고 재생성
- 내부 RAG 결과도 부족하거나 관련 문서가 없으면 외부 검색(RAG, Tavily)으로 fallback
주요 고려사항 2
LLM 응답은 언제 '충분하다'고 판단할 수 있을까?
생성 응답만으로 판단하기 어려운 이유
- Fine-tuned LLM이 생성한 응답은 자연스럽더라도 질문 조건을 모두 충족했는지 즉시 판단하기 어려움
- 단순 생성 응답만으로는 재료·조리 도구·조리 시간 등 사용자 제약 조건이 충분히 반영되었는지 검증 불가
- 내부 지식만으로 답변한 경우 정보 누락 또는 과도한 추론 여부를 사용자가 직접 판단해야 함
접근 방식
- Fine-tuned LLM이 1차 레시피 응답을 생성
- GPT 모델을 활용해 응답의 충분성·적합성 평가
- 충분하다고 판단되면 바로 사용자에게 출력
- 부족할 경우에만 내부 레시피 RAG 단계로 분기
- 내부 정보로도 보완이 어려울 때만 외부 검색 단계로 확장
- 최종적으로 하나의 정제된 답변만 제공
주요 고려사항 3
대화는 복잡해도, 결과는 어떻게 단순하게 할 수 있을까?
기존 문제점
- 대화형 인터페이스에서는 재료, 도구, 시간 조건이 여러 질문에 나뉘어 입력됨
- 질문이 누적될수록 정보가 분산되어 어떤 조건을 기준으로 요리해야 할지 혼란 발생
- LLM 응답이 설명 위주로 확장되면서 사용자가 직접 정보를 정리하고 판단해야 하는 상황이 생김
접근 방식
- 이전 대화에서 입력된 조건을 모두 하나의 맥락으로 통합
- 중간 추론·분기·보완 과정은 시스템 내부에서만 처리하도록 설계
- 사용자에게는 지금 바로 따라 할 수 있는 단일 레시피 결과만 제공
- 불필요한 설명은 줄이고 재료·조리 순서·대체 방법 중심으로 응답 구성
06 회고
요리왕 좌룡 회고
역할과 기여
요리왕 좌룡 프로젝트에서 나는 팀장은 아니었지만, 설계와 구현의 공백을 메우는 역할을 자발적으로 맡아 프로젝트에 참여했다. 일부 팀원들의 참여도가 고르지 않은 상황에서도, 끝까지 완성도 있는 결과물을 만들어내기 위해 적극적으로 의견을 제시하고 구현에 시간을 투자했다. 특히 파인튜닝, 데이터 전처리, 응답 구조 설계 과정에서 단순히 주어진 역할을 수행하는 데 그치지 않고, "이 구조가 실제로 사용자에게 의미가 있는가"를 기준으로 문제를 제기하고 개선 방향을 제안했다. 그 과정에서 자연스럽게 기술적 의사결정에 관여하며 프로젝트의 완성도를 높이는 데 기여할 수 있었다.
응답 구조에 대한 고민
이번 프로젝트에서 가장 인상 깊었던 경험은 Fine-Tuning과 RAG를 무작정 결합하면 오히려 모델이 혼란스러워질 수 있다는 점을 직접 체감한 것이다. 처음에는 두 방식을 함께 사용하면 정확도가 올라갈 것이라 기대했지만, 실제로는 응답의 일관성이 깨지는 문제가 발생했다. 이를 해결하기 위해 각 방식을 독립적인 실행 경로로 분리하고, 응답의 적절성을 기준으로 다음 단계를 판단하는 구조로 수정했다. 이 경험을 통해 모델 성능 자체보다도, 언제 어떤 정보를 쓰고 언제 멈춰야 하는지를 설계하는 것이 더 중요하다는 관점을 얻었다.
실행 가능한 서비스
요리왕 좌룡은 단순한 레시피 추천 챗봇이 아니라, 사용자의 현실적인 제약을 고려한 실행 가능한 AI 서비스를 목표로 했다. 유튜브 자막 기반 데이터 수집, RAG 파이프라인 구성, API 사용량 제한 문제 해결, 프롬프트 구조 개선까지의 과정은 단순한 실습을 넘어 실제 서비스 환경을 고민하는 경험이었다. 특히 OpenAI API 제한 문제를 CSV 분할과 요청 딜레이로 해결하고, 프롬프트가 의도대로 동작하지 않던 문제를 반복적인 수정으로 개선하면서, 문제 해결은 기술 스택보다도 구조 이해와 집요함에서 나온다는 점을 다시 한 번 느꼈다.