2026-06-18T20:59:09Z

Com239: /* 상세설계 내용 */

__TOC__

==프로젝트 개요==

=== 기술개발 과제 ===
''' 국문 : ''' 냉고(냉장고 고수)
''' 영문 : ''' fridge-expert

===과제 팀명===
냉고

===지도교수===
이동희 교수님

===개발기간===
2026년 3월 ~ 2026년 6월 (총 4개월)

===구성원 소개===
*서울시립대학교 컴퓨터과학부 2022920007 김나린(팀장)
*서울시립대학교 컴퓨터과학부 2020920092 최유성
*서울시립대학교 컴퓨터과학부 2022920034 백민정
*서울시립대학교 컴퓨터과학부 2023920023 박진우

==서론==

===개발 과제의 개요===

====개발 과제 요약====
본 과제는 1인 가구 및 자취생을 위한 AI 기반 레시피 추천 모바일 애플리케이션 '냉고(냉장고 고수)'를 개발하는 것을 목표로 한다. 사용자가 보유한 식재료를 텍스트 또는 이미지 형태로 입력하면, RAG(Retrieval-Augmented Generation) 기반 의미 검색 기술을 활용하여 가장 적합한 단일 레시피를 추천한다. 또한 사용자와의 대화를 통해 "다이어트", "맵기 조절" 등의 추가 조건을 반영하여 레시피를 재추천하는 대화형 추천 시스템을 제공한다. 더불어 만개의 레시피와 유튜브 등의 플랫폼에서 약 5,000건 이상의 데이터를 구축하고, 사용자 참여형 레시피 커뮤니티를 통해 지속적으로 데이터를 확장하는 것을 목표로 한다.

====개발 과제의 배경====
*2025년 대한민국 1인 가구는 804만 5천 가구로 전체 가구의 36.1%를 차지하여 역대 최고치를 경신했다.
*기존 요리 애플리케이션은 가족 단위 식사나 복잡한 요리를 중심으로 구성되어 있어, 자취생이나 1인 가구가 활용하기에 실용성이 낮은 경우가 많다.
*자취생은 냉장고에 남은 재료를 효율적으로 활용하기 어려워, 식재료 낭비가 발생하는 문제가 존재한다.
*재료 기반 레시피 추천과 간단한 요리 중심의 콘텐츠를 제공함으로써 1인 가구의 요리 접근성을 높일 수 있다.
*사용자 간 레시피 공유 커뮤니티를 통해 실생활에 적합한 간단하고 현실적인 요리 정보를 확산할 수 있다.

====개발 과제의 목표 및 내용====
*사용자가 보유한 재료를 입력하거나 사진 촬영을 통해 재료를 인식하여 레시피를 추천하는 기능을 구현한다.
*챗봇 기반 인터페이스를 활용하여 사용자와의 대화를 통해 개인 맞춤형 레시피를 제공한다.
*사용자들이 직접 레시피를 등록하고 공유할 수 있는 커뮤니티 게시판 기능을 구현하며, AI는 이를 학습하여 레시피 추천에 반영한다.
*안드로이드 기반 모바일 애플리케이션으로 개발하며, Node.js 서버와 PostgreSQL 데이터베이스를 활용하여 시스템을 구축한다.

===관련 기술의 현황===

====관련 기술의 현황 및 분석(State of art)====
*전 세계적인 기술현황
**최근 인공지능 분야에서는 대형 언어모델(LLM)과 이를 보완하는 RAG(Retrieval-Augmented Generation) 기술이 핵심 패러다임으로 자리 잡고 있다.
**최근에는 RAG와 추천 시스템을 결합한 구조가 활발히 연구되고 있다. 2026년 발표된 연구에서는 Retrieval-Augmented LLM 기반 추천 시스템이 제안되었으며, retrieval 모듈과 사용자 행동 데이터를 결합하여 추천 성능을 향상시키는 구조가 제시되었다.
*특허조사 및 특허 전략 분석
**'''[특허조사]'''
**카테고리로 분류된 식재료 추출 방법과 이를 이용한 레시피 추천 방법 및 이를 위한 관리 장치 (공개번호: 1020240099972, 출원인: 숭실대학교산학협력단) — 영수증 이미지 등에서 식재료를 추출하고, BERT 기반 모델로 재료를 카테고리화하여 사용자 식재료 DB를 구축한 후 레시피를 추천한다.
**AI를 이용한 개인 맞춤형 레시피 제공 플랫폼 시스템 (공개번호: 1020230075299, 출원인: 성신여자대학교 연구 산학협력단) — 전용 애플리케이션을 통해 레시피를 제공받는 사용자 단말 중심의 개인 맞춤형 레시피 제공 플랫폼이다.
**'''[특허전략]'''
**기존 특허가 단순 매칭 기반 추천 또는 정적 추천 시스템에 집중되어 있다는 점을 고려하여, "RAG 기반 의미 검색 + 대화형 조건 반영 + 재료 기반 추천"의 결합적 구조를 핵심 차별 요소로 설정한다.
**재료 메타데이터 기반 사전 필터링과 벡터 검색 결합 구조, 사용자 대화 입력을 반영한 Query 재구성 및 재검색 방식, 이미지 기반 재료 추출과 RAG 시스템의 연동 구조를 중심으로 특허 가능성을 고려한다.
**기존 기술 대비 정확도·개인화·실시간성 측면에서 차별화된 시스템으로 발전시키고, 향후 특허 출원을 검토한다.
*기술 로드맵
**기본 시스템 구축 : 크로스 플랫폼(iOS & Android) UI 구현 및 Spring Boot 서버·PostgreSQL DB 구축
**API 연동 및 기본 기능 구현 : REST API 설계, 프론트-백엔드 연동 및 데이터를 활용한 레시피 추천 흐름 구현
**RAG 기반 추천 시스템 구축 : 임베딩 모델 적용, pgvector 기반 벡터 DB 구축, 코사인 유사도 기반 검색 구현
**대화형 추천 기능 확장 : 사용자 조건 입력 처리 및 Query 재구성·재검색 기능 구현
**이미지 기반 재료 인식 : Vision API 적용 및 이미지 재료 추출 후 RAG 연계
**커뮤니티 기능 구현 : 레시피 게시판 기능 개발 및 사용자 데이터 축적 구조 구축

====시장상황에 대한 분석====
*경쟁제품 조사 비교
**'''만개의 레시피''' : 다양한 사용자 레시피와 방대한 요리 데이터를 제공하는 대표적인 레시피 플랫폼. 커뮤니티 기반 공유가 활발하나, 특정 재료 기반 추천 기능이 제한적이고 1인 가구·자취생용 간단 레시피 중심 서비스는 부족하다.
**'''삼성푸드''' : 식단 관리와 레시피 추천을 제공하는 음식 관리 플랫폼. 다양한 콘텐츠와 식단 관리 기능이 강점이나, 사용자와 상호작용하는 AI 챗봇 기능이 없어 개인 맞춤형 추천이 제한적이다.
**'''Fridge Scanner''' : 냉장고 재료를 촬영·입력하면 해당 재료로 만들 수 있는 레시피를 추천. 재료 인식 기능이 특징이나, 카테고리 구조가 복잡하고 자취생에게는 난이도가 높은 레시피가 많으며 추가 정보 입력 기반 추천 기능이 없다.
**'''해먹으리''' : 외부 영상을 AI가 자동으로 레시피로 변환하고 단계별 영상-레시피 동기화를 제공. AI 기반 요리 Q&A를 포함하나, 추천보다는 저장 기능에 치중하여 상황 기반 자동 추천이 제한적이다.
**'''쿡잉''' : 냉장고 재료를 스캔·등록하면 조리 도구 등 현재 상황에 맞는 요리를 AI가 추천. 레시피 관리·저장·커스터마이징 기능이 부족하고 취향 기반 개인화가 제한적이다.

{| class="wikitable"
|+ 경쟁제품 비교표
! 구분 !! 만개의 레시피 !! 삼성푸드 !! Fridge Scanner !! 해먹으리 !! 쿡잉
|-
! 핵심 기능
| 레시피 공유 || 식단 관리 || 재료 기반 추천 || 영상 레시피 추출 + AI 변환 || 재료 기반 AI 추천
|-
! 재료 기반 추천
| △ || X || O || X || O
|-
! AI 활용
| 없음 || △ || △ || O || O
|-
! 개인화 추천
| X || △ || △ || △ || △
|-
! 사용 목적
| 레시피 탐색 || 식단 관리 || 재료 활용 || 레시피 저장/활용 || 빠른 메뉴 결정
|-
! 사용 난이도
| 낮음 || 보통 || 높음 || 낮음 || 낮음
|}

*마케팅 전략 제시
**'''[냉고의 차별점 및 특성]'''
**RAG 기반 의미 검색을 통해 재료와 조건을 종합적으로 고려한 레시피를 추천한다.
**재료 중심 구조를 기반으로 현재 보유 식재료로 만들 수 있는 요리를 우선 추천한다.
**챗봇을 통해 추가 조건을 반영하는 대화형 추천 시스템을 제공한다.
**자취생을 대상으로 간단하고 실용적인 레시피에 집중하며, 데이터 5,000개 이상을 수집·정제한다.
**사용자 레시피 공유를 통해 데이터가 축적되는 참여형 구조를 구축한다.

{| class="wikitable"
|+ SWOT 분석
! Strength !! Weaknesses
|-
|
* RAG 기반 의미 검색으로 정확한 레시피 추천이 가능하다.
* 재료 기반 및 대화형 AI 구조를 동시에 제공한다.
* 자취생 중심의 간편 레시피에 특화되어 있다.
|
* 초기 데이터 규모가 작아 추천 다양성이 제한된다.
* 초기 사용자 확보가 어렵다.
|-
! Opportunities !! Threats
|-
|
* 1인 가구 증가로 간편 요리 수요가 증가하고 있다.
* 숏폼 기반 요리 콘텐츠 소비가 확대되고 있다.
* AI 개인화 서비스에 대한 수요가 증가하고 있다.
|
* 기존 플랫폼의 기능 확장 가능성이 있다.
* 유사 서비스의 빠른 모방이 가능하다.
* 데이터 수집 관련 제약이 존재한다.
|}

===개발과제의 기대효과===

====기술적 기대효과====
*단일 단계의 RAG 활용을 넘어, 사용자 입력에 따라 반복적으로 Retrieval과 Generation을 수행하는 다단계 RAG 구조를 구현할 수 있다. 초기에는 보유 재료를 기반으로 1차 레시피를 추천하고, 이후 사용자가 추가 조건을 입력할 경우 이를 반영하여 재검색·재생성을 수행한다.
*다단계 RAG 구조는 단순 검색 결과 반환이 아닌, 조건 기반 재랭킹 및 필터링을 포함한 반복적 추천 프로세스(iterative recommendation pipeline)를 가능하게 한다. 이를 통해 사용자 요구 변화에 유연하게 대응하고 추천 결과의 정밀도와 개인화 수준을 동시에 향상시킬 수 있다.
*조건 반영 과정에서 메타데이터 필터링과 의미 기반 검색을 함께 활용함으로써, 검색 공간을 효과적으로 축소하고 불필요한 후보를 제거할 수 있다. 이는 시스템 효율성 및 응답 속도 개선에 기여한다.
*임베딩 모델 및 유사도 계산 방법의 비교·적용을 통해 의미 기반 검색 성능 최적화에 대한 실험적 결과를 도출할 수 있다.
*메타데이터 기반 필터링과 벡터 검색을 결합하여 검색 정확도 향상 및 응답 속도(latency) 개선 효과를 기대할 수 있다.

====경제적, 사회적 기대 및 파급효과====
*1인 가구 증가에 따라 간편 요리에 대한 수요를 충족시키는 실용적인 생활 밀착형 서비스로 활용될 수 있다.
*식재료 활용도를 높여 음식물 쓰레기 감소 및 자원 절약에 기여함으로써, 환경적 지속가능성 측면에서 긍정적인 효과를 기대할 수 있다.
*개인 맞춤형 식단 추천을 통해 건강한 식생활 형성 및 식습관 개선에 기여할 수 있다.
*사용자 참여 기반 레시피 공유를 통해 지속적인 콘텐츠 생산 구조를 형성할 수 있다.

===기술개발 일정 및 추진체계===

====개발 일정====
개발 기간은 2026년 3월부터 2026년 6월까지 약 4개월간 진행되었으며, 단계별 추진 순서는 위 '기술 로드맵'(기본 시스템 구축 → API 연동 및 기본 기능 → RAG 기반 추천 시스템 → 대화형 추천 확장 → 이미지 기반 재료 인식 → 커뮤니티 기능)을 따른다.
※ 원문에는 월별 세부 일정표(Gantt 등)가 별도로 포함되어 있지 않다.

====구성원 및 추진체계====
*김나린(팀장) : 프론트엔드, 서류 정리
*최유성(팀원) : 백엔드(AI 담당)
*백민정(팀원) : UI/UX 디자인, 프론트엔드
*박진우(팀원) : 백엔드(서버)

==설계==

===설계사양===

====제품의 요구사항====
{| class="wikitable"
! 번호 !! 요구사항 !! D or W !! 비고
|-
| 1 || 소셜 계정을 통한 회원가입 및 로그인 || D ||
|-
| 2 || 메인 화면에서 레시피 추천 기능 접근 || D ||
|-
| 3 || 사용자가 재료를 텍스트로 입력할 수 있다 || D ||
|-
| 4 || 사용자가 재료 사진을 업로드할 수 있다 || D ||
|-
| 5 || 이미지에서 식재료를 추출할 수 있다 || D || Vision API 기반 인식
|-
| 6 || 입력된 재료를 기반으로 질의를 생성한다 || D || RAG 기반 검색 수행
|-
| 7 || 생성된 질의를 임베딩하여 벡터로 변환한다 || D ||
|-
| 8 || 검색된 레시피 중 가장 적합한 레시피를 선택한다 || D ||
|-
| 9 || 추천된 레시피를 사용자에게 출력한다 || D ||
|-
| 10 || 사용자가 추가 조건을 입력할 수 있다 || D || 예: 다이어트, 맵기
|-
| 11 || 추가 조건을 반영하여 질의를 재구성한다 || D || 재료 + 조건 결합
|-
| 12 || 재구성된 질의를 기반으로 레시피를 재검색한다 || D ||
|-
| 13 || 조건이 반영된 새로운 레시피를 출력한다 || D ||
|-
| 14 || 새 채팅방을 생성할 수 있다 || D ||
|-
| 15 || 이전 대화 기록을 볼 수 있다 || D ||
|-
| 16 || 사용자가 게시판에 자신만의 레시피를 작성할 수 있다 || D ||
|-
| 17 || 게시판에서 사용자 레시피 목록을 조회할 수 있다 || D ||
|-
| 18 || 레시피 상세 정보를 조회할 수 있다 || D ||
|-
| 19 || 레시피에 좋아요를 누를 수 있다 || W ||
|-
| 20 || 레시피를 인기순/최신순/내북마크 순으로 볼 수 있다 || D ||
|-
| 21 || 사용자 프로필 조회 및 수정 기능 || W || 닉네임, 프로필 이미지
|-
| 22 || 로그아웃 및 회원탈퇴 기능 || W ||
|-
| 23 || 사용자가 자신이 작성한 레시피 목록을 조회할 수 있다 || D ||
|-
| 24 || 작성한 레시피의 상태를 확인할 수 있다 || D || 상태: 승인/검토/반려
|-
| 25 || 추천 레시피를 북마크할 수 있다 || D ||
|-
| 26 || 북마크한 레시피 목록을 조회할 수 있다 || D ||
|-
| 27 || 추천 레시피의 난이도 및 소요 시간을 제공한다 || D ||
|}
※ D : Demand(필수 요구사항), W : Want(선택 요구사항)

====설계 사양====
시스템은 '사용자 입력 → 의도 분석 → 검색 계획 → 벡터 검색 → 추천 응답 스트리밍'으로 이어지는 파이프라인 구조로 설계되었다. 프론트엔드(Flutter)에서 입력된 메시지·재료·조건·이미지를 백엔드(FastAPI)로 전달하고, AI Agent가 의도를 분류한 뒤 RAG 기반 검색을 수행하여 추천 결과를 SSE(Server-Sent Events) 방식으로 실시간 스트리밍한다.

===개념설계안===
*'''AI 채팅 기반 맞춤형 레시피 추천 기능'''
**'''설명''' : 사용자가 보유 재료, 선호 음식, 조리 시간 등 다양한 요구사항을 자연어로 입력하면, AI를 활용하여 사용자 조건에 적합한 레시피를 추천한다.
**'''기술적 특징 및 AI 활용 이점'''
***LLM 기반 AI로 사용자의 자연어 입력을 이해하고 조건에 맞는 레시피를 생성·추천한다.
***SSE 기반 스트리밍을 적용하여 AI 응답을 청크 단위로 실시간 출력함으로써 응답 대기 시간을 감소시킨다.
***동일 채팅방 내 이전 대화 내용을 AI 컨텍스트로 활용하여 연속적인 질의응답 및 맞춤 추천이 가능하다.
***AI 응답과 함께 추천 레시피 객체를 칩(Chip) 형태로 제공하여 상세 화면으로 즉시 이동할 수 있다.
***사용자별 채팅방 단위로 대화를 분리하여 주제별 대화 관리 및 개인화된 추천 환경을 제공한다.
**'''동작 과정 예시''' : 홈 화면 입력창에 질문 입력 → 새 채팅방 자동 생성 → AI 응답 실시간 스트리밍 → 추천 레시피 칩 선택 → 레시피 상세 화면 이동
*'''사진 인식 기반 재료 분석 및 레시피 추천 기능'''
**'''설명''' : 사용자가 냉장고 내부 또는 식재료 사진을 촬영하면, 멀티모달 AI가 사진 속 재료를 분석하고 이에 적합한 레시피를 추천한다.
**'''기술적 특징 및 AI 활용 이점'''
***재료명을 직접 입력하지 않아도 이미지 기반 AI 분석으로 재료 정보를 자동 추출한다.
***멀티모달 AI로 이미지와 텍스트를 함께 처리하여 재료 인식 정확도를 향상시킨다.
***촬영 직후 미리보기 단계를 제공하여 재촬영·전송 여부를 선택할 수 있다.
***분석된 이미지를 채팅 버블 형태로 대화 흐름에 통합하여 대화 경험의 연속성을 유지한다.
**'''동작 과정 예시'''
***홈 화면에서 카메라 실행 : 카메라 아이콘 선택 → 사진 촬영 → 미리보기 확인 → 전송 → 새 채팅방 생성 및 사진 첨부 → AI 응답 스트리밍 확인
***진행 중인 채팅방에서 카메라 실행 : 카메라 아이콘 선택 → 동일한 촬영·전송 과정 → 기존 채팅 컨텍스트를 활용한 재료 분석 및 레시피 추천
*'''레시피 게시판 기반 정보 공유 기능'''
**'''설명''' : 공식 레시피와 사용자 작성 레시피를 제공하는 게시판을 통해 사용자 간 정보 공유 및 커뮤니티 기능을 지원한다.
**'''기술적 특징 및 AI 활용 이점'''
***전체 레시피와 사용자 작성 레시피를 분리하여 탐색 기능과 개인 관리 기능을 구분한다.
***최신순·좋아요순·북마크순 정렬을 제공하여 다양한 탐색 시나리오를 지원한다.
***ValueNotifier 기반 상태 동기화로 좋아요·북마크 상태 변경을 실시간 반영한다.
***상세 화면에서 재료 목록, 조리 과정, 조리 팁, 인분 수, 조리 시간, 칼로리, 이미지·영상 URL 등 다양한 메타데이터를 제공한다.
***승인된 사용자 레시피 데이터를 AI 학습 데이터로 활용하여 추천 품질 향상에 기여한다.
**'''동작 과정 예시'''
***레시피 탐색 : 게시판 진입 → 정렬 옵션 선택 → 레시피 카드 선택 → 상세 화면 진입 → 좋아요·북마크 활용
***레시피 작성 : 사이드 메뉴 → '레시피 작성하기' 선택 → 제목·재료·조리법·이미지 입력 → 게시글 등록

===이론적 계산 및 시뮬레이션===
{| class="wikitable"
|+ 시뮬레이션 계획
! 시뮬레이션 항목 !! 방법 및 기대 결과
|-
| 의도 분류 정확도 || 테스트 발화 세트를 기준으로 IntentClassifier가 RECIPE_RECOMMENDATION, PROFILE_UPDATE, OFF_TOPIC 등 목표 intent를 맞히는지 측정. (목표: 주요 intent F1-Score 0.85 이상)
|-
| 벡터 검색 정합성 || 추천 요청별 상위 N개 레시피가 재료·상황에 부합하는지 Precision@5로 측정. (목표: Precision@5 60% 이상)
|-
| SSE 이벤트 안정성 || room, metadata, message, profile_update, recipes, done, error 이벤트 순서와 종료 처리가 프론트엔드 렌더링 흐름에 맞는지 통합 테스트. (목표: 정상 시나리오 100% 완료)
|}

{| class="wikitable"
|+ 시뮬레이션 결과
! 시뮬레이션 항목 !! 측정 방법 !! 목표 !! 측정값 !! 판정
|-
| 의도 분류 정확도 || 7개 카테고리 140개 발화로 IntentClassifier의 예측 라벨과 정답 라벨을 비교, Macro F1-Score 산출 || Macro F1 ≥ 0.85 || 0.87 || 통과
|-
| 벡터 검색 정합성 || 20개 추천 시나리오에 대해 사전 라벨링된 정답 셋과 pgvector 검색 상위 5개 결과를 비교, Precision@5 산출 || Precision@5 ≥ 0.60 || 0.68 || 통과
|-
| SSE 이벤트 안정성 || room, metadata, message(×N), recipes(opt), done 이벤트의 순서와 종료 처리를 15개 정상 시나리오로 통합 테스트 || 정상 시나리오 100% 완료 || 100% || 통과
|}

===상세설계 내용===
'''[시스템 아키텍처]''' 사용자 입력 → 의도 분석 → 검색 계획 → 벡터 검색 → 추천 응답 스트리밍 파이프라인.
[[파일:naengo_architecture.png|섬네일|없음|시스템 아키텍처]]

'''2.5 조립도 ― 컴포넌트'''
{| class="wikitable"
! ID !! 컴포넌트 !! 기술 스택 !! 역할
|-
| C1 || 프론트엔드 앱 || Flutter/Dart 기반 클라이언트 || 채팅 화면, 추천 레시피 카드, 레시피 목록·상세, 좋아요·스크랩, 제출 레시피 상태 확인 UI
|-
| C2 || 백엔드 API 서버 || Python 3.13 + FastAPI || REST API, SSE 스트리밍, 인증/권한 경계, OpenAPI 문서 제공
|-
| C3 || AI Agent || PydanticAI + LLM Gateway || 의도 분류, route 결정, 대화 응답 생성, 프로필 업데이트 후보 생성
|-
| C4 || 검색 계획 모듈 || RecipeSearchPlanner || 사용자 발화를 검색 query와 필터 후보 JSON으로 변환
|-
| C5 || 레시피 검색 모듈 || Embedding API + pgvector || 레시피 임베딩 검색, cutoff, metadata 기반 rerank
|-
| C6 || 데이터베이스 || PostgreSQL || 사용자, 레시피, 채팅, 스크랩, staging/import 상태 저장
|-
| C7 || 데이터 수집/정제 || CLI scripts || 공공데이터·만개의레시피 원본 수집, 파싱, 검수, production import
|-
| C8 || 관리자 웹(Admin) || React/Vite/Tailwind 기반 Admin 클라이언트 + Admin API || 제출 레시피 심사, 필수 필드 보완, 승인/반려, recipe source 검수·import, 관리자용 레시피 조회 UI
|-
| C9 || 배포/품질 || Docker, GitHub Actions, Ruff, pytest || 개발·운영 컨테이너, EC2 배포, 테스트 자동화
|}

'''2.5 조립도 ― 데이터 흐름'''
{| class="wikitable"
! 단계 !! 흐름 !! 설명
|-
| 1 || C1 → C2 || 사용자가 Flutter 앱 채팅 화면에서 메시지·보유 재료·조건 또는 이미지를 입력하면 프론트엔드가 Chat API로 전송한다.
|-
| 2 || C2 → C3 || AgentService가 대화 이력을 불러오고 IntentClassifier로 사용자 의도를 분류한다.
|-
| 3 || C3 → C4 || 레시피 추천 의도인 경우 RecipeSearchPlanner가 query_text, main_ingredients, avoid_ingredients, cooking_time_max 등을 만든다.
|-
| 4 || C4 → C5 || RecipeRetrievalService가 embedding 검색과 cosine cutoff를 적용해 후보 레시피를 선별한다.
|-
| 5 || C5 → C6 || 레시피 상세, 재료, 단계, 미디어, 통계, 사용자 좋아요·스크랩 상태를 조합한다.
|-
| 6 || C3 → C2 || StreamEventBuilder가 metadata, message, recipes, done 이벤트를 순서대로 구성한다.
|-
| 7 || C2 → C1 || SSE로 답변 chunk와 추천 레시피 배열을 전송하고, 프론트엔드는 채팅 답변·추천 카드·레시피 상세 진입 UI를 갱신한다.
|-
| 8 || C7 → C6 || batch script가 원본 레시피를 staging에 저장하고, 승인된 source를 production recipes로 import한다.
|-
| 9 || C8 → C2/C6 || 관리자가 Admin 웹에서 제출 레시피와 recipe source를 검수하고, Admin API로 상태 수정·승인·반려·import를 수행한다. 처리 결과는 DB에 반영된다.
|}

'''2.6 부품도 ― AI Agent'''
{| class="wikitable"
! 사양 !! 내용
|-
| 입력 || 사용자 메시지, 최근 대화 이력, 사용자 프로필, 이미지 분석 결과, intent result
|-
| 출력 || assistant message, 추천 레시피 id 목록, 추천 근거, 프로필 업데이트 후보, live research 사용 여부
|-
| 주요 route || RECIPE_RECOMMENDATION, RECIPE_DETAIL_QUESTION, COOKING_TIP, INGREDIENT_SUBSTITUTION, DIET_OR_ALLERGY, PROFILE_UPDATE, IMAGE_BASED_RECIPE, IDENTITY, SMALLTALK, OFF_TOPIC
|-
| 안전 정책 || 취향·알레르기·식이 제한은 AUTO_SAVE, REQUIRE_CONFIRMATION, IGNORE 정책으로 분류한다.
|-
| 품질 기준 || LLM/embedding API는 mock으로 경계 분리하고, route 선택·SSE 이벤트·DB 저장 여부를 서비스 테스트로 검증한다.
|}

'''2.6 부품도 ― 레시피 검색 및 RAG'''
{| class="wikitable"
! 사양 !! 내용
|-
| 입력 || 검색 query_text, 보유/제외/필수 재료, 조리 시간, 난이도, cuisine, taste, diet 조건
|-
| 처리 || Embedding API로 query를 벡터화하고 recipe_embeddings의 pgvector similarity를 검색한다.
|-
| 후처리 || 낮은 score는 cutoff로 제외하고, 재료·카테고리·제목 일치·사용자 선호·인기도 신호로 rerank한다.
|-
| 출력 || 프론트엔드가 바로 렌더링 가능한 Recipe 배열과 추천 근거 요약
|-
| 확장 || 프로필 기반 가중치, 싫어하는 재료 패널티, 최근 추천 중복 회피, live research 보강
|}

'''2.6 부품도 ― 데이터 수집/정제 파이프라인'''
{| class="wikitable"
! 사양 !! 내용
|-
| Source || foodsafetykorea 공공데이터, 만개의레시피 웹 스크래핑 데이터
|-
| Staging || recipe_sources.raw_payload에 원본을 보존하고 recipe_source_extractions*에 파싱 결과를 저장한다.
|-
| 검수 || parse_status, review_status, import_status로 lifecycle을 분리해 운영자가 승인 가능한 상태를 관리한다.
|-
| Import || APPROVED + NOT_IMPORTED source만 recipes*, recipe_ingredients, recipe_steps, recipe_labels, recipe_nutrition으로 이동한다.
|-
| 후속 작업 || classification backfill, embedding backfill, 선택적 AI image generation을 import 이후 분리 실행한다.
|}

'''2.7 소프트웨어 설계 ― 백엔드 API 엔드포인트'''
{| class="wikitable"
! Method !! Endpoint !! 입력 !! 출력 !! 비고
|-
| GET || /api/v1/users/me || - || 사용자 계정 정보 || 인증 연동 전 임시 사용자 컨텍스트 사용
|-
| POST || /api/v1/users/me/profile || {text} || 최신순 user_input || 개인화 정보 저장
|-
| GET || /api/v1/recipes || cursor, limit, sort || items, next_cursor, has_next || 전체 레시피 목록 및 무한 스크롤용 페이지네이션
|-
| GET || /api/v1/recipes/{recipe_id} || - || 레시피 상세, 재료, 단계, 미디어, likes_count, scrap_count, is_liked, is_scrapped || 상세 화면 및 토글 후 상태 동기화용
|-
| POST || /api/v1/chat/rooms || 초기 메시지 || SSE 이벤트 || 새 채팅방 생성
|-
| POST || /api/v1/chat/rooms/{room_id} || message || SSE 이벤트 || 기존 채팅방 메시지
|-
| POST || /api/v1/pending-recipes || title, description, ingredients_raw, instructions/content, servings, cooking_time, difficulty, category 등 || pending_recipe_id, status || 사용자 제출 레시피 생성 및 내 레시피 상태 표시
|-
| GET || /api/v1/admin/recipe-sources || cursor/status || source 목록 || 관리자 검수
|-
| POST || /api/v1/admin/recipe-sources/{source_id}/import || - || import 결과 || 승인 source 반영
|-
| POST/DELETE || /api/v1/recipes/{recipe_id}/likes || - || likes_count, scrap_count || 좋아요 추가/취소 토글
|-
| POST/DELETE || /api/v1/recipes/{recipe_id}/scraps || - || likes_count, scrap_count || 스크랩 추가/취소 토글
|}

'''2.7 소프트웨어 설계 ― 핵심 알고리즘: 채팅 기반 레시피 추천'''
# ChatService가 room과 message를 저장하고 AgentService를 호출한다.
# RuleBasedFastPath와 LLMIntentClassifier가 사용자 의도를 분류한다.
# 추천 의도이면 RecipeSearchPlanner가 검색 query와 조건 필터를 생성한다.
# RecipeRetrievalService가 embedding 검색과 cutoff를 수행한다.
# 레시피 상세, 재료, 조리 단계, 미디어, 좋아요·스크랩 상태를 응답 구조로 결합한다.
# StreamEventBuilder가 metadata → message chunk → profile_update → recipes → done 순으로 이벤트를 만든다.
# 프론트엔드는 SSE 이벤트를 받아 채팅 답변과 추천 카드 UI를 점진적으로 렌더링하고, 추천 카드에서 레시피 상세 화면으로 이동한다.
# 오류 발생 시 error 이벤트를 전송하고 스트림을 닫아 프론트가 채팅 실패 상태를 표시한 후 재시도한다.

==결과 및 평가==

===완료 작품의 소개===

====프로토타입 사진 혹은 작동 장면====
완성된 애플리케이션의 주요 화면은 다음과 같다.

;메인 화면
[[파일:냉고_메인화면.jpg|섬네일|없음|메인 화면]]

;프로필 및 패널 (비로그인 상태)
[[파일:냉고_프로필_비로그인_1.jpg|섬네일|없음|프로필 및 패널 (비로그인)]]
[[파일:냉고_프로필_비로그인_2.jpg|섬네일|없음|프로필 및 패널 (비로그인)]]
[[파일:냉고_프로필_비로그인_3.jpg|섬네일|없음|프로필 및 패널 (비로그인)]]

;메인 화면 및 패널 (로그인 상태)
[[파일:냉고_메인_로그인_1.jpg|섬네일|없음|메인 화면 및 패널 (로그인)]]
[[파일:냉고_메인_로그인_2.jpg|섬네일|없음|메인 화면 및 패널 (로그인)]]
[[파일:냉고_메인_로그인_3.jpg|섬네일|없음|메인 화면 및 패널 (로그인)]]
[[파일:냉고_메인_로그인_4.jpg|섬네일|없음|메인 화면 및 패널 (로그인)]]
[[파일:냉고_메인_로그인_5.jpg|섬네일|없음|메인 화면 및 패널 (로그인)]]
[[파일:냉고_메인_로그인_6.jpg|섬네일|없음|메인 화면 및 패널 (로그인)]]

;채팅 화면 및 상세보기
[[파일:냉고_채팅화면.jpg|섬네일|없음|채팅 화면 및 상세보기]]

;게시판 및 내 레시피
[[파일:냉고_게시판_1.jpg|섬네일|없음|게시판 및 내 레시피]]
[[파일:냉고_게시판_2.jpg|섬네일|없음|게시판 및 내 레시피]]

;레시피 작성
[[파일:냉고_레시피작성_1.jpg|섬네일|없음|레시피 작성]]
[[파일:냉고_레시피작성_2.jpg|섬네일|없음|레시피 작성]]
[[파일:냉고_레시피작성_3.jpg|섬네일|없음|레시피 작성]]

;Google Play 사전 체험판 등록
[[파일:냉고_플레이스토어.jpg|섬네일|없음|Google Play 사전 체험판 등록]]

'''[배포 / 설치]'''
*현재 비공개 테스트(클로즈드 베타)를 진행 중이며, 정식 출시 전이다.
*최신 버전의 실행 파일을 드라이브에 별도로 업로드하고 있으며, 비공개 테스터 이외의 이용자는 아래 링크에서 최신 버전을 다운로드한다.
*다운로드 링크 : https://drive.google.com/drive/folders/1f7xzgQxNDeQ3Mokn1mX6B--wGYAx4Too?usp=sharing

====포스터====
※ 원문에 포스터 항목은 포함되어 있지 않다.

===관련사업비 내역서===
'''[개발사업비 내역서]''' (직접개발비, 단위: 원)
{| class="wikitable"
! 항목 (품명·규격) !! 세부 내역 !! 금액 !! 비고
|-
| OpenAI API 사용료 || 8,349 + 8,368 + 8,368 + 16,752 + 41,818 || 83,655원 ||
|-
| Anthropic Claude API 사용료 || 33,876 + 8,265 + 33,092 + 25,366 + 18,752 + 34,392 + 25,786 + 18,867 || 198,396원 ||
|-
| AWS 서버 || 22,961 + 146,123 || 169,084원 ||
|-
| 플레이 스토어 등록 || 38,445 || 38,445원 || 현금
|-
| 호스팅케이알 도메인 || 19,800 || 19,800원 || 현금
|-
| 도서 구매 || 65,700 (도서 2권) || 65,700원 || 현금
|-
! colspan="2" | 합계 !! colspan="2" | 575,080원
|}
※ 총 예산 600천원 중 575,080원 집행 (잔액 24,920원). 학교부담금 600천원 / 과제팀부담금 0원.

'''[자재소요서 ― 외부 서비스 및 API]'''
{| class="wikitable"
! No. !! 품목 !! 규격 !! 용도 !! 비고
|-
| 1 || OpenAI 호환 LLM API || Chat completion model || 의도 분류, 답변 생성, 프로필 후보 생성 || 사용량 기반 과금
|-
| 2 || OpenAI Embedding API || embedding model || 레시피 검색 query 및 recipe embedding 생성 || 사용량 기반 과금
|-
| 3 || AWS EC2 || Docker host || FastAPI 운영 서버 || 운영 배포
|-
| 4 || AWS RDS PostgreSQL || PostgreSQL + pgvector || 서비스 DB와 벡터 검색 || 운영 DB
|-
| 5 || AWS S3 || Object storage || AI 생성/선택 이미지 저장 || 이미지 기능 확장 시 도입
|-
| 6 || GitHub Actions || CI/CD || main 브랜치 push 시 EC2 배포 || deploy workflow 사용
|}

'''[자재소요서 ― 오픈소스 라이브러리]'''
{| class="wikitable"
! No. !! 라이브러리 !! 버전/계열 !! 용도
|-
| 1 || Python || 3.13 || 백엔드 런타임
|-
| 2 || FastAPI || current || REST API와 SSE 엔드포인트
|-
| 3 || PydanticAI || current || AI Agent orchestration
|-
| 4 || SQLAlchemy || current || ORM 및 DB transaction boundary
|-
| 5 || Pydantic || current || 요청/응답 schema와 settings
|-
| 6 || PostgreSQL pgvector || extension || 레시피 embedding 유사도 검색
|-
| 7 || Ruff || current || lint/format 품질 관리
|-
| 8 || pytest || current || 단위·서비스·통합 테스트
|-
| 9 || Docker Compose || dev/prod || 개발·운영 컨테이너 실행
|}

'''[자재소요서 ― 데이터 자원]'''
{| class="wikitable"
! No. !! 데이터 !! 설명 및 조달
|-
| 1 || foodsafetykorea 레시피 || 구조화된 영양 정보와 초기 대량 레시피 데이터로 사용한다.
|-
| 2 || 만개의레시피 웹 원천 || 실제 사용자형 조리 흐름·표현·이미지 출처를 raw payload로 수집한다.
|-
| 3 || 사용자 제출 레시피 || 사용자 입력 원문을 pending_recipes에 저장하고 관리자 검수 후 반영한다.
|-
| 4 || Golden Test Set || 의도 분류, 검색 계획, 프로필 업데이트 정책, 추천 정합성 평가용 발화·정답 세트
|}

===완료작품의 평가===
{| class="wikitable"
! 평가 항목 !! 평가 방법 !! 적용 기준 !! 개발 목표치 !! 비중(%) !! 평가 결과
|-
| 1. 식재료 인식 정확도 || 테스트 이미지 데이터셋을 활용한 인식 정확도 측정(8개 카테고리) || 전체 테스트 이미지 중 정확히 인식된 식재료 비율 || 인식 정확도 90% 이상 || 20% || 9/10
|-
| 2. 챗봇 응답속도 측정 || 사용자 질의 후 응답까지 걸리는 평균 시간 측정 || 서버 로그 및 테스트 환경에서 평균 응답 시간 측정 || 평균 응답 시간 3초 이내 || 25% || 8/10
|-
| 3. 사용자 경험(UI/UX) || 사용자 테스트 및 피드백 수집 || 불필요하거나 복잡한 과정 최소화 || 4.0/5 || 20% || 10/10
|-
| 4. AI 추천 레시피 품질 검증 || 사용자 피드백 수집(레시피 유효성 평가), JSON 스키마 자동 검증 || 추천 레시피가 입력 식재료에 기반하여 합리적·일관적인지 사용자 평가 || 사용자 평가 4.0/5 이상, 스키마 검증 95% 이상 || 25% || 10/10
|-
| 5. 응답속도 || 사용자 입력(회원가입·채팅입력 등)에 따른 API 처리시간 및 페이지 전환 처리시간 측정 || API 처리 및 페이지 전환이 2초 이내인 요청 비율 || API 처리·페이지 전환 2초 이내 90% 이상 || 10% || 8/10
|}

'''[어려웠던 내용들]'''
*SSE 기반 실시간 채팅 클라이언트를 처음부터 구축하는 과정에서 청크 단위 응답 파싱, 이벤트 타입별 분기 처리, 텍스트와 이미지 동시 전송 등에 시행착오를 많이 겪었다.
*백엔드 서버가 단일 IP에서 다중 서브도메인(api.naengo.com / ai.naengo.com)으로 분리되는 과정에서 환경변수 누락으로 인한 런타임 오류(Failed host lookup)가 반복적으로 발생했다.
*앱 출시 경험 부족으로 패키지명 변경에 따른 키스토어 재서명, 카카오 키 해시 재등록, 개인정보처리방침의 국외 이전 고지 등 출시 직전 정책 요건이 생소하고 복잡했다.

===향후계획===
*'''iOS 클라이언트 출시 및 다국어 지원''' : Flutter 단일 코드베이스의 이점을 활용해 iOS 앱을 동시 운영하고, 영문 등 다국어 지원으로 사용자 접근성을 확대한다.
*'''사용자 맞춤형 추천 고도화''' : 채팅 대화 중 사용자의 취향(선호 재료, 회피 식재료, 조리 방식, 식단 목표 등)을 점진적으로 학습·축적하고, 이를 모든 AI 채팅 응답과 레시피 추천 결과에 반영하여 사용자별 차별화된 경험을 제공한다.
*'''AI 응답속도 개선''' : 의도 분류 결과와 레시피 임베딩의 Redis 캐싱을 통해 외부 LLM API 호출 빈도를 줄이고 평균 응답 시간을 단축한다.

===특허 출원 내용===
※ 현재 출원된 특허는 없으며, 향후 특허 출원을 검토 중인 단계이다. 차별화 핵심 요소는 다음과 같다.
*RAG 기반 의미 검색 + 대화형 조건 반영 + 재료 기반 추천을 결합한 구조
*재료 메타데이터 기반 사전 필터링과 벡터 검색을 결합한 구조
*사용자 대화 입력을 반영한 Query 재구성 및 재검색 방식
*이미지 기반 재료 추출과 RAG 시스템의 연동 구조

2분반-냉고

2026-06-18T20:55:58Z

Com239: /* 상세설계 내용 */

__TOC__

==프로젝트 개요==

=== 기술개발 과제 ===
''' 국문 : ''' 냉고(냉장고 고수)
''' 영문 : ''' fridge-expert

===과제 팀명===
냉고

===지도교수===
이동희 교수님

===개발기간===
2026년 3월 ~ 2026년 6월 (총 4개월)

===구성원 소개===
*서울시립대학교 컴퓨터과학부 2022920007 김나린(팀장)
*서울시립대학교 컴퓨터과학부 2020920092 최유성
*서울시립대학교 컴퓨터과학부 2022920034 백민정
*서울시립대학교 컴퓨터과학부 2023920023 박진우

==서론==

===개발 과제의 개요===

====개발 과제 요약====
본 과제는 1인 가구 및 자취생을 위한 AI 기반 레시피 추천 모바일 애플리케이션 '냉고(냉장고 고수)'를 개발하는 것을 목표로 한다. 사용자가 보유한 식재료를 텍스트 또는 이미지 형태로 입력하면, RAG(Retrieval-Augmented Generation) 기반 의미 검색 기술을 활용하여 가장 적합한 단일 레시피를 추천한다. 또한 사용자와의 대화를 통해 "다이어트", "맵기 조절" 등의 추가 조건을 반영하여 레시피를 재추천하는 대화형 추천 시스템을 제공한다. 더불어 만개의 레시피와 유튜브 등의 플랫폼에서 약 5,000건 이상의 데이터를 구축하고, 사용자 참여형 레시피 커뮤니티를 통해 지속적으로 데이터를 확장하는 것을 목표로 한다.

====개발 과제의 배경====
*2025년 대한민국 1인 가구는 804만 5천 가구로 전체 가구의 36.1%를 차지하여 역대 최고치를 경신했다.
*기존 요리 애플리케이션은 가족 단위 식사나 복잡한 요리를 중심으로 구성되어 있어, 자취생이나 1인 가구가 활용하기에 실용성이 낮은 경우가 많다.
*자취생은 냉장고에 남은 재료를 효율적으로 활용하기 어려워, 식재료 낭비가 발생하는 문제가 존재한다.
*재료 기반 레시피 추천과 간단한 요리 중심의 콘텐츠를 제공함으로써 1인 가구의 요리 접근성을 높일 수 있다.
*사용자 간 레시피 공유 커뮤니티를 통해 실생활에 적합한 간단하고 현실적인 요리 정보를 확산할 수 있다.

====개발 과제의 목표 및 내용====
*사용자가 보유한 재료를 입력하거나 사진 촬영을 통해 재료를 인식하여 레시피를 추천하는 기능을 구현한다.
*챗봇 기반 인터페이스를 활용하여 사용자와의 대화를 통해 개인 맞춤형 레시피를 제공한다.
*사용자들이 직접 레시피를 등록하고 공유할 수 있는 커뮤니티 게시판 기능을 구현하며, AI는 이를 학습하여 레시피 추천에 반영한다.
*안드로이드 기반 모바일 애플리케이션으로 개발하며, Node.js 서버와 PostgreSQL 데이터베이스를 활용하여 시스템을 구축한다.

===관련 기술의 현황===

====관련 기술의 현황 및 분석(State of art)====
*전 세계적인 기술현황
**최근 인공지능 분야에서는 대형 언어모델(LLM)과 이를 보완하는 RAG(Retrieval-Augmented Generation) 기술이 핵심 패러다임으로 자리 잡고 있다.
**최근에는 RAG와 추천 시스템을 결합한 구조가 활발히 연구되고 있다. 2026년 발표된 연구에서는 Retrieval-Augmented LLM 기반 추천 시스템이 제안되었으며, retrieval 모듈과 사용자 행동 데이터를 결합하여 추천 성능을 향상시키는 구조가 제시되었다.
*특허조사 및 특허 전략 분석
**'''[특허조사]'''
**카테고리로 분류된 식재료 추출 방법과 이를 이용한 레시피 추천 방법 및 이를 위한 관리 장치 (공개번호: 1020240099972, 출원인: 숭실대학교산학협력단) — 영수증 이미지 등에서 식재료를 추출하고, BERT 기반 모델로 재료를 카테고리화하여 사용자 식재료 DB를 구축한 후 레시피를 추천한다.
**AI를 이용한 개인 맞춤형 레시피 제공 플랫폼 시스템 (공개번호: 1020230075299, 출원인: 성신여자대학교 연구 산학협력단) — 전용 애플리케이션을 통해 레시피를 제공받는 사용자 단말 중심의 개인 맞춤형 레시피 제공 플랫폼이다.
**'''[특허전략]'''
**기존 특허가 단순 매칭 기반 추천 또는 정적 추천 시스템에 집중되어 있다는 점을 고려하여, "RAG 기반 의미 검색 + 대화형 조건 반영 + 재료 기반 추천"의 결합적 구조를 핵심 차별 요소로 설정한다.
**재료 메타데이터 기반 사전 필터링과 벡터 검색 결합 구조, 사용자 대화 입력을 반영한 Query 재구성 및 재검색 방식, 이미지 기반 재료 추출과 RAG 시스템의 연동 구조를 중심으로 특허 가능성을 고려한다.
**기존 기술 대비 정확도·개인화·실시간성 측면에서 차별화된 시스템으로 발전시키고, 향후 특허 출원을 검토한다.
*기술 로드맵
**기본 시스템 구축 : 크로스 플랫폼(iOS & Android) UI 구현 및 Spring Boot 서버·PostgreSQL DB 구축
**API 연동 및 기본 기능 구현 : REST API 설계, 프론트-백엔드 연동 및 데이터를 활용한 레시피 추천 흐름 구현
**RAG 기반 추천 시스템 구축 : 임베딩 모델 적용, pgvector 기반 벡터 DB 구축, 코사인 유사도 기반 검색 구현
**대화형 추천 기능 확장 : 사용자 조건 입력 처리 및 Query 재구성·재검색 기능 구현
**이미지 기반 재료 인식 : Vision API 적용 및 이미지 재료 추출 후 RAG 연계
**커뮤니티 기능 구현 : 레시피 게시판 기능 개발 및 사용자 데이터 축적 구조 구축

====시장상황에 대한 분석====
*경쟁제품 조사 비교
**'''만개의 레시피''' : 다양한 사용자 레시피와 방대한 요리 데이터를 제공하는 대표적인 레시피 플랫폼. 커뮤니티 기반 공유가 활발하나, 특정 재료 기반 추천 기능이 제한적이고 1인 가구·자취생용 간단 레시피 중심 서비스는 부족하다.
**'''삼성푸드''' : 식단 관리와 레시피 추천을 제공하는 음식 관리 플랫폼. 다양한 콘텐츠와 식단 관리 기능이 강점이나, 사용자와 상호작용하는 AI 챗봇 기능이 없어 개인 맞춤형 추천이 제한적이다.
**'''Fridge Scanner''' : 냉장고 재료를 촬영·입력하면 해당 재료로 만들 수 있는 레시피를 추천. 재료 인식 기능이 특징이나, 카테고리 구조가 복잡하고 자취생에게는 난이도가 높은 레시피가 많으며 추가 정보 입력 기반 추천 기능이 없다.
**'''해먹으리''' : 외부 영상을 AI가 자동으로 레시피로 변환하고 단계별 영상-레시피 동기화를 제공. AI 기반 요리 Q&A를 포함하나, 추천보다는 저장 기능에 치중하여 상황 기반 자동 추천이 제한적이다.
**'''쿡잉''' : 냉장고 재료를 스캔·등록하면 조리 도구 등 현재 상황에 맞는 요리를 AI가 추천. 레시피 관리·저장·커스터마이징 기능이 부족하고 취향 기반 개인화가 제한적이다.

{| class="wikitable"
|+ 경쟁제품 비교표
! 구분 !! 만개의 레시피 !! 삼성푸드 !! Fridge Scanner !! 해먹으리 !! 쿡잉
|-
! 핵심 기능
| 레시피 공유 || 식단 관리 || 재료 기반 추천 || 영상 레시피 추출 + AI 변환 || 재료 기반 AI 추천
|-
! 재료 기반 추천
| △ || X || O || X || O
|-
! AI 활용
| 없음 || △ || △ || O || O
|-
! 개인화 추천
| X || △ || △ || △ || △
|-
! 사용 목적
| 레시피 탐색 || 식단 관리 || 재료 활용 || 레시피 저장/활용 || 빠른 메뉴 결정
|-
! 사용 난이도
| 낮음 || 보통 || 높음 || 낮음 || 낮음
|}

*마케팅 전략 제시
**'''[냉고의 차별점 및 특성]'''
**RAG 기반 의미 검색을 통해 재료와 조건을 종합적으로 고려한 레시피를 추천한다.
**재료 중심 구조를 기반으로 현재 보유 식재료로 만들 수 있는 요리를 우선 추천한다.
**챗봇을 통해 추가 조건을 반영하는 대화형 추천 시스템을 제공한다.
**자취생을 대상으로 간단하고 실용적인 레시피에 집중하며, 데이터 5,000개 이상을 수집·정제한다.
**사용자 레시피 공유를 통해 데이터가 축적되는 참여형 구조를 구축한다.

{| class="wikitable"
|+ SWOT 분석
! Strength !! Weaknesses
|-
|
* RAG 기반 의미 검색으로 정확한 레시피 추천이 가능하다.
* 재료 기반 및 대화형 AI 구조를 동시에 제공한다.
* 자취생 중심의 간편 레시피에 특화되어 있다.
|
* 초기 데이터 규모가 작아 추천 다양성이 제한된다.
* 초기 사용자 확보가 어렵다.
|-
! Opportunities !! Threats
|-
|
* 1인 가구 증가로 간편 요리 수요가 증가하고 있다.
* 숏폼 기반 요리 콘텐츠 소비가 확대되고 있다.
* AI 개인화 서비스에 대한 수요가 증가하고 있다.
|
* 기존 플랫폼의 기능 확장 가능성이 있다.
* 유사 서비스의 빠른 모방이 가능하다.
* 데이터 수집 관련 제약이 존재한다.
|}

===개발과제의 기대효과===

====기술적 기대효과====
*단일 단계의 RAG 활용을 넘어, 사용자 입력에 따라 반복적으로 Retrieval과 Generation을 수행하는 다단계 RAG 구조를 구현할 수 있다. 초기에는 보유 재료를 기반으로 1차 레시피를 추천하고, 이후 사용자가 추가 조건을 입력할 경우 이를 반영하여 재검색·재생성을 수행한다.
*다단계 RAG 구조는 단순 검색 결과 반환이 아닌, 조건 기반 재랭킹 및 필터링을 포함한 반복적 추천 프로세스(iterative recommendation pipeline)를 가능하게 한다. 이를 통해 사용자 요구 변화에 유연하게 대응하고 추천 결과의 정밀도와 개인화 수준을 동시에 향상시킬 수 있다.
*조건 반영 과정에서 메타데이터 필터링과 의미 기반 검색을 함께 활용함으로써, 검색 공간을 효과적으로 축소하고 불필요한 후보를 제거할 수 있다. 이는 시스템 효율성 및 응답 속도 개선에 기여한다.
*임베딩 모델 및 유사도 계산 방법의 비교·적용을 통해 의미 기반 검색 성능 최적화에 대한 실험적 결과를 도출할 수 있다.
*메타데이터 기반 필터링과 벡터 검색을 결합하여 검색 정확도 향상 및 응답 속도(latency) 개선 효과를 기대할 수 있다.

====경제적, 사회적 기대 및 파급효과====
*1인 가구 증가에 따라 간편 요리에 대한 수요를 충족시키는 실용적인 생활 밀착형 서비스로 활용될 수 있다.
*식재료 활용도를 높여 음식물 쓰레기 감소 및 자원 절약에 기여함으로써, 환경적 지속가능성 측면에서 긍정적인 효과를 기대할 수 있다.
*개인 맞춤형 식단 추천을 통해 건강한 식생활 형성 및 식습관 개선에 기여할 수 있다.
*사용자 참여 기반 레시피 공유를 통해 지속적인 콘텐츠 생산 구조를 형성할 수 있다.

===기술개발 일정 및 추진체계===

====개발 일정====
개발 기간은 2026년 3월부터 2026년 6월까지 약 4개월간 진행되었으며, 단계별 추진 순서는 위 '기술 로드맵'(기본 시스템 구축 → API 연동 및 기본 기능 → RAG 기반 추천 시스템 → 대화형 추천 확장 → 이미지 기반 재료 인식 → 커뮤니티 기능)을 따른다.
※ 원문에는 월별 세부 일정표(Gantt 등)가 별도로 포함되어 있지 않다.

====구성원 및 추진체계====
*김나린(팀장) : 프론트엔드, 서류 정리
*최유성(팀원) : 백엔드(AI 담당)
*백민정(팀원) : UI/UX 디자인, 프론트엔드
*박진우(팀원) : 백엔드(서버)

==설계==

===설계사양===

====제품의 요구사항====
{| class="wikitable"
! 번호 !! 요구사항 !! D or W !! 비고
|-
| 1 || 소셜 계정을 통한 회원가입 및 로그인 || D ||
|-
| 2 || 메인 화면에서 레시피 추천 기능 접근 || D ||
|-
| 3 || 사용자가 재료를 텍스트로 입력할 수 있다 || D ||
|-
| 4 || 사용자가 재료 사진을 업로드할 수 있다 || D ||
|-
| 5 || 이미지에서 식재료를 추출할 수 있다 || D || Vision API 기반 인식
|-
| 6 || 입력된 재료를 기반으로 질의를 생성한다 || D || RAG 기반 검색 수행
|-
| 7 || 생성된 질의를 임베딩하여 벡터로 변환한다 || D ||
|-
| 8 || 검색된 레시피 중 가장 적합한 레시피를 선택한다 || D ||
|-
| 9 || 추천된 레시피를 사용자에게 출력한다 || D ||
|-
| 10 || 사용자가 추가 조건을 입력할 수 있다 || D || 예: 다이어트, 맵기
|-
| 11 || 추가 조건을 반영하여 질의를 재구성한다 || D || 재료 + 조건 결합
|-
| 12 || 재구성된 질의를 기반으로 레시피를 재검색한다 || D ||
|-
| 13 || 조건이 반영된 새로운 레시피를 출력한다 || D ||
|-
| 14 || 새 채팅방을 생성할 수 있다 || D ||
|-
| 15 || 이전 대화 기록을 볼 수 있다 || D ||
|-
| 16 || 사용자가 게시판에 자신만의 레시피를 작성할 수 있다 || D ||
|-
| 17 || 게시판에서 사용자 레시피 목록을 조회할 수 있다 || D ||
|-
| 18 || 레시피 상세 정보를 조회할 수 있다 || D ||
|-
| 19 || 레시피에 좋아요를 누를 수 있다 || W ||
|-
| 20 || 레시피를 인기순/최신순/내북마크 순으로 볼 수 있다 || D ||
|-
| 21 || 사용자 프로필 조회 및 수정 기능 || W || 닉네임, 프로필 이미지
|-
| 22 || 로그아웃 및 회원탈퇴 기능 || W ||
|-
| 23 || 사용자가 자신이 작성한 레시피 목록을 조회할 수 있다 || D ||
|-
| 24 || 작성한 레시피의 상태를 확인할 수 있다 || D || 상태: 승인/검토/반려
|-
| 25 || 추천 레시피를 북마크할 수 있다 || D ||
|-
| 26 || 북마크한 레시피 목록을 조회할 수 있다 || D ||
|-
| 27 || 추천 레시피의 난이도 및 소요 시간을 제공한다 || D ||
|}
※ D : Demand(필수 요구사항), W : Want(선택 요구사항)

====설계 사양====
시스템은 '사용자 입력 → 의도 분석 → 검색 계획 → 벡터 검색 → 추천 응답 스트리밍'으로 이어지는 파이프라인 구조로 설계되었다. 프론트엔드(Flutter)에서 입력된 메시지·재료·조건·이미지를 백엔드(FastAPI)로 전달하고, AI Agent가 의도를 분류한 뒤 RAG 기반 검색을 수행하여 추천 결과를 SSE(Server-Sent Events) 방식으로 실시간 스트리밍한다.

===개념설계안===
*'''AI 채팅 기반 맞춤형 레시피 추천 기능'''
**'''설명''' : 사용자가 보유 재료, 선호 음식, 조리 시간 등 다양한 요구사항을 자연어로 입력하면, AI를 활용하여 사용자 조건에 적합한 레시피를 추천한다.
**'''기술적 특징 및 AI 활용 이점'''
***LLM 기반 AI로 사용자의 자연어 입력을 이해하고 조건에 맞는 레시피를 생성·추천한다.
***SSE 기반 스트리밍을 적용하여 AI 응답을 청크 단위로 실시간 출력함으로써 응답 대기 시간을 감소시킨다.
***동일 채팅방 내 이전 대화 내용을 AI 컨텍스트로 활용하여 연속적인 질의응답 및 맞춤 추천이 가능하다.
***AI 응답과 함께 추천 레시피 객체를 칩(Chip) 형태로 제공하여 상세 화면으로 즉시 이동할 수 있다.
***사용자별 채팅방 단위로 대화를 분리하여 주제별 대화 관리 및 개인화된 추천 환경을 제공한다.
**'''동작 과정 예시''' : 홈 화면 입력창에 질문 입력 → 새 채팅방 자동 생성 → AI 응답 실시간 스트리밍 → 추천 레시피 칩 선택 → 레시피 상세 화면 이동
*'''사진 인식 기반 재료 분석 및 레시피 추천 기능'''
**'''설명''' : 사용자가 냉장고 내부 또는 식재료 사진을 촬영하면, 멀티모달 AI가 사진 속 재료를 분석하고 이에 적합한 레시피를 추천한다.
**'''기술적 특징 및 AI 활용 이점'''
***재료명을 직접 입력하지 않아도 이미지 기반 AI 분석으로 재료 정보를 자동 추출한다.
***멀티모달 AI로 이미지와 텍스트를 함께 처리하여 재료 인식 정확도를 향상시킨다.
***촬영 직후 미리보기 단계를 제공하여 재촬영·전송 여부를 선택할 수 있다.
***분석된 이미지를 채팅 버블 형태로 대화 흐름에 통합하여 대화 경험의 연속성을 유지한다.
**'''동작 과정 예시'''
***홈 화면에서 카메라 실행 : 카메라 아이콘 선택 → 사진 촬영 → 미리보기 확인 → 전송 → 새 채팅방 생성 및 사진 첨부 → AI 응답 스트리밍 확인
***진행 중인 채팅방에서 카메라 실행 : 카메라 아이콘 선택 → 동일한 촬영·전송 과정 → 기존 채팅 컨텍스트를 활용한 재료 분석 및 레시피 추천
*'''레시피 게시판 기반 정보 공유 기능'''
**'''설명''' : 공식 레시피와 사용자 작성 레시피를 제공하는 게시판을 통해 사용자 간 정보 공유 및 커뮤니티 기능을 지원한다.
**'''기술적 특징 및 AI 활용 이점'''
***전체 레시피와 사용자 작성 레시피를 분리하여 탐색 기능과 개인 관리 기능을 구분한다.
***최신순·좋아요순·북마크순 정렬을 제공하여 다양한 탐색 시나리오를 지원한다.
***ValueNotifier 기반 상태 동기화로 좋아요·북마크 상태 변경을 실시간 반영한다.
***상세 화면에서 재료 목록, 조리 과정, 조리 팁, 인분 수, 조리 시간, 칼로리, 이미지·영상 URL 등 다양한 메타데이터를 제공한다.
***승인된 사용자 레시피 데이터를 AI 학습 데이터로 활용하여 추천 품질 향상에 기여한다.
**'''동작 과정 예시'''
***레시피 탐색 : 게시판 진입 → 정렬 옵션 선택 → 레시피 카드 선택 → 상세 화면 진입 → 좋아요·북마크 활용
***레시피 작성 : 사이드 메뉴 → '레시피 작성하기' 선택 → 제목·재료·조리법·이미지 입력 → 게시글 등록

===이론적 계산 및 시뮬레이션===
{| class="wikitable"
|+ 시뮬레이션 계획
! 시뮬레이션 항목 !! 방법 및 기대 결과
|-
| 의도 분류 정확도 || 테스트 발화 세트를 기준으로 IntentClassifier가 RECIPE_RECOMMENDATION, PROFILE_UPDATE, OFF_TOPIC 등 목표 intent를 맞히는지 측정. (목표: 주요 intent F1-Score 0.85 이상)
|-
| 벡터 검색 정합성 || 추천 요청별 상위 N개 레시피가 재료·상황에 부합하는지 Precision@5로 측정. (목표: Precision@5 60% 이상)
|-
| SSE 이벤트 안정성 || room, metadata, message, profile_update, recipes, done, error 이벤트 순서와 종료 처리가 프론트엔드 렌더링 흐름에 맞는지 통합 테스트. (목표: 정상 시나리오 100% 완료)
|}

{| class="wikitable"
|+ 시뮬레이션 결과
! 시뮬레이션 항목 !! 측정 방법 !! 목표 !! 측정값 !! 판정
|-
| 의도 분류 정확도 || 7개 카테고리 140개 발화로 IntentClassifier의 예측 라벨과 정답 라벨을 비교, Macro F1-Score 산출 || Macro F1 ≥ 0.85 || 0.87 || 통과
|-
| 벡터 검색 정합성 || 20개 추천 시나리오에 대해 사전 라벨링된 정답 셋과 pgvector 검색 상위 5개 결과를 비교, Precision@5 산출 || Precision@5 ≥ 0.60 || 0.68 || 통과
|-
| SSE 이벤트 안정성 || room, metadata, message(×N), recipes(opt), done 이벤트의 순서와 종료 처리를 15개 정상 시나리오로 통합 테스트 || 정상 시나리오 100% 완료 || 100% || 통과
|}

===상세설계 내용===
'''[시스템 아키텍처]''' 사용자 입력 → 의도 분석 → 검색 계획 → 벡터 검색 → 추천 응답 스트리밍 파이프라인.
[[파일:냉고_시스템아키텍처.png|섬네일|없음|시스템 아키텍처]]

'''2.5 조립도 ― 컴포넌트'''
{| class="wikitable"
! ID !! 컴포넌트 !! 기술 스택 !! 역할
|-
| C1 || 프론트엔드 앱 || Flutter/Dart 기반 클라이언트 || 채팅 화면, 추천 레시피 카드, 레시피 목록·상세, 좋아요·스크랩, 제출 레시피 상태 확인 UI
|-
| C2 || 백엔드 API 서버 || Python 3.13 + FastAPI || REST API, SSE 스트리밍, 인증/권한 경계, OpenAPI 문서 제공
|-
| C3 || AI Agent || PydanticAI + LLM Gateway || 의도 분류, route 결정, 대화 응답 생성, 프로필 업데이트 후보 생성
|-
| C4 || 검색 계획 모듈 || RecipeSearchPlanner || 사용자 발화를 검색 query와 필터 후보 JSON으로 변환
|-
| C5 || 레시피 검색 모듈 || Embedding API + pgvector || 레시피 임베딩 검색, cutoff, metadata 기반 rerank
|-
| C6 || 데이터베이스 || PostgreSQL || 사용자, 레시피, 채팅, 스크랩, staging/import 상태 저장
|-
| C7 || 데이터 수집/정제 || CLI scripts || 공공데이터·만개의레시피 원본 수집, 파싱, 검수, production import
|-
| C8 || 관리자 웹(Admin) || React/Vite/Tailwind 기반 Admin 클라이언트 + Admin API || 제출 레시피 심사, 필수 필드 보완, 승인/반려, recipe source 검수·import, 관리자용 레시피 조회 UI
|-
| C9 || 배포/품질 || Docker, GitHub Actions, Ruff, pytest || 개발·운영 컨테이너, EC2 배포, 테스트 자동화
|}

'''2.5 조립도 ― 데이터 흐름'''
{| class="wikitable"
! 단계 !! 흐름 !! 설명
|-
| 1 || C1 → C2 || 사용자가 Flutter 앱 채팅 화면에서 메시지·보유 재료·조건 또는 이미지를 입력하면 프론트엔드가 Chat API로 전송한다.
|-
| 2 || C2 → C3 || AgentService가 대화 이력을 불러오고 IntentClassifier로 사용자 의도를 분류한다.
|-
| 3 || C3 → C4 || 레시피 추천 의도인 경우 RecipeSearchPlanner가 query_text, main_ingredients, avoid_ingredients, cooking_time_max 등을 만든다.
|-
| 4 || C4 → C5 || RecipeRetrievalService가 embedding 검색과 cosine cutoff를 적용해 후보 레시피를 선별한다.
|-
| 5 || C5 → C6 || 레시피 상세, 재료, 단계, 미디어, 통계, 사용자 좋아요·스크랩 상태를 조합한다.
|-
| 6 || C3 → C2 || StreamEventBuilder가 metadata, message, recipes, done 이벤트를 순서대로 구성한다.
|-
| 7 || C2 → C1 || SSE로 답변 chunk와 추천 레시피 배열을 전송하고, 프론트엔드는 채팅 답변·추천 카드·레시피 상세 진입 UI를 갱신한다.
|-
| 8 || C7 → C6 || batch script가 원본 레시피를 staging에 저장하고, 승인된 source를 production recipes로 import한다.
|-
| 9 || C8 → C2/C6 || 관리자가 Admin 웹에서 제출 레시피와 recipe source를 검수하고, Admin API로 상태 수정·승인·반려·import를 수행한다. 처리 결과는 DB에 반영된다.
|}

'''2.6 부품도 ― AI Agent'''
{| class="wikitable"
! 사양 !! 내용
|-
| 입력 || 사용자 메시지, 최근 대화 이력, 사용자 프로필, 이미지 분석 결과, intent result
|-
| 출력 || assistant message, 추천 레시피 id 목록, 추천 근거, 프로필 업데이트 후보, live research 사용 여부
|-
| 주요 route || RECIPE_RECOMMENDATION, RECIPE_DETAIL_QUESTION, COOKING_TIP, INGREDIENT_SUBSTITUTION, DIET_OR_ALLERGY, PROFILE_UPDATE, IMAGE_BASED_RECIPE, IDENTITY, SMALLTALK, OFF_TOPIC
|-
| 안전 정책 || 취향·알레르기·식이 제한은 AUTO_SAVE, REQUIRE_CONFIRMATION, IGNORE 정책으로 분류한다.
|-
| 품질 기준 || LLM/embedding API는 mock으로 경계 분리하고, route 선택·SSE 이벤트·DB 저장 여부를 서비스 테스트로 검증한다.
|}

'''2.6 부품도 ― 레시피 검색 및 RAG'''
{| class="wikitable"
! 사양 !! 내용
|-
| 입력 || 검색 query_text, 보유/제외/필수 재료, 조리 시간, 난이도, cuisine, taste, diet 조건
|-
| 처리 || Embedding API로 query를 벡터화하고 recipe_embeddings의 pgvector similarity를 검색한다.
|-
| 후처리 || 낮은 score는 cutoff로 제외하고, 재료·카테고리·제목 일치·사용자 선호·인기도 신호로 rerank한다.
|-
| 출력 || 프론트엔드가 바로 렌더링 가능한 Recipe 배열과 추천 근거 요약
|-
| 확장 || 프로필 기반 가중치, 싫어하는 재료 패널티, 최근 추천 중복 회피, live research 보강
|}

'''2.6 부품도 ― 데이터 수집/정제 파이프라인'''
{| class="wikitable"
! 사양 !! 내용
|-
| Source || foodsafetykorea 공공데이터, 만개의레시피 웹 스크래핑 데이터
|-
| Staging || recipe_sources.raw_payload에 원본을 보존하고 recipe_source_extractions*에 파싱 결과를 저장한다.
|-
| 검수 || parse_status, review_status, import_status로 lifecycle을 분리해 운영자가 승인 가능한 상태를 관리한다.
|-
| Import || APPROVED + NOT_IMPORTED source만 recipes*, recipe_ingredients, recipe_steps, recipe_labels, recipe_nutrition으로 이동한다.
|-
| 후속 작업 || classification backfill, embedding backfill, 선택적 AI image generation을 import 이후 분리 실행한다.
|}

'''2.7 소프트웨어 설계 ― 백엔드 API 엔드포인트'''
{| class="wikitable"
! Method !! Endpoint !! 입력 !! 출력 !! 비고
|-
| GET || /api/v1/users/me || - || 사용자 계정 정보 || 인증 연동 전 임시 사용자 컨텍스트 사용
|-
| POST || /api/v1/users/me/profile || {text} || 최신순 user_input || 개인화 정보 저장
|-
| GET || /api/v1/recipes || cursor, limit, sort || items, next_cursor, has_next || 전체 레시피 목록 및 무한 스크롤용 페이지네이션
|-
| GET || /api/v1/recipes/{recipe_id} || - || 레시피 상세, 재료, 단계, 미디어, likes_count, scrap_count, is_liked, is_scrapped || 상세 화면 및 토글 후 상태 동기화용
|-
| POST || /api/v1/chat/rooms || 초기 메시지 || SSE 이벤트 || 새 채팅방 생성
|-
| POST || /api/v1/chat/rooms/{room_id} || message || SSE 이벤트 || 기존 채팅방 메시지
|-
| POST || /api/v1/pending-recipes || title, description, ingredients_raw, instructions/content, servings, cooking_time, difficulty, category 등 || pending_recipe_id, status || 사용자 제출 레시피 생성 및 내 레시피 상태 표시
|-
| GET || /api/v1/admin/recipe-sources || cursor/status || source 목록 || 관리자 검수
|-
| POST || /api/v1/admin/recipe-sources/{source_id}/import || - || import 결과 || 승인 source 반영
|-
| POST/DELETE || /api/v1/recipes/{recipe_id}/likes || - || likes_count, scrap_count || 좋아요 추가/취소 토글
|-
| POST/DELETE || /api/v1/recipes/{recipe_id}/scraps || - || likes_count, scrap_count || 스크랩 추가/취소 토글
|}

'''2.7 소프트웨어 설계 ― 핵심 알고리즘: 채팅 기반 레시피 추천'''
# ChatService가 room과 message를 저장하고 AgentService를 호출한다.
# RuleBasedFastPath와 LLMIntentClassifier가 사용자 의도를 분류한다.
# 추천 의도이면 RecipeSearchPlanner가 검색 query와 조건 필터를 생성한다.
# RecipeRetrievalService가 embedding 검색과 cutoff를 수행한다.
# 레시피 상세, 재료, 조리 단계, 미디어, 좋아요·스크랩 상태를 응답 구조로 결합한다.
# StreamEventBuilder가 metadata → message chunk → profile_update → recipes → done 순으로 이벤트를 만든다.
# 프론트엔드는 SSE 이벤트를 받아 채팅 답변과 추천 카드 UI를 점진적으로 렌더링하고, 추천 카드에서 레시피 상세 화면으로 이동한다.
# 오류 발생 시 error 이벤트를 전송하고 스트림을 닫아 프론트가 채팅 실패 상태를 표시한 후 재시도한다.

==결과 및 평가==

===완료 작품의 소개===

====프로토타입 사진 혹은 작동 장면====
완성된 애플리케이션의 주요 화면은 다음과 같다.

;메인 화면
[[파일:냉고_메인화면.jpg|섬네일|없음|메인 화면]]

;프로필 및 패널 (비로그인 상태)
[[파일:냉고_프로필_비로그인_1.jpg|섬네일|없음|프로필 및 패널 (비로그인)]]
[[파일:냉고_프로필_비로그인_2.jpg|섬네일|없음|프로필 및 패널 (비로그인)]]
[[파일:냉고_프로필_비로그인_3.jpg|섬네일|없음|프로필 및 패널 (비로그인)]]

;메인 화면 및 패널 (로그인 상태)
[[파일:냉고_메인_로그인_1.jpg|섬네일|없음|메인 화면 및 패널 (로그인)]]
[[파일:냉고_메인_로그인_2.jpg|섬네일|없음|메인 화면 및 패널 (로그인)]]
[[파일:냉고_메인_로그인_3.jpg|섬네일|없음|메인 화면 및 패널 (로그인)]]
[[파일:냉고_메인_로그인_4.jpg|섬네일|없음|메인 화면 및 패널 (로그인)]]
[[파일:냉고_메인_로그인_5.jpg|섬네일|없음|메인 화면 및 패널 (로그인)]]
[[파일:냉고_메인_로그인_6.jpg|섬네일|없음|메인 화면 및 패널 (로그인)]]

;채팅 화면 및 상세보기
[[파일:냉고_채팅화면.jpg|섬네일|없음|채팅 화면 및 상세보기]]

;게시판 및 내 레시피
[[파일:냉고_게시판_1.jpg|섬네일|없음|게시판 및 내 레시피]]
[[파일:냉고_게시판_2.jpg|섬네일|없음|게시판 및 내 레시피]]

;레시피 작성
[[파일:냉고_레시피작성_1.jpg|섬네일|없음|레시피 작성]]
[[파일:냉고_레시피작성_2.jpg|섬네일|없음|레시피 작성]]
[[파일:냉고_레시피작성_3.jpg|섬네일|없음|레시피 작성]]

;Google Play 사전 체험판 등록
[[파일:냉고_플레이스토어.jpg|섬네일|없음|Google Play 사전 체험판 등록]]

'''[배포 / 설치]'''
*현재 비공개 테스트(클로즈드 베타)를 진행 중이며, 정식 출시 전이다.
*최신 버전의 실행 파일을 드라이브에 별도로 업로드하고 있으며, 비공개 테스터 이외의 이용자는 아래 링크에서 최신 버전을 다운로드한다.
*다운로드 링크 : https://drive.google.com/drive/folders/1f7xzgQxNDeQ3Mokn1mX6B--wGYAx4Too?usp=sharing

====포스터====
※ 원문에 포스터 항목은 포함되어 있지 않다.

===관련사업비 내역서===
'''[개발사업비 내역서]''' (직접개발비, 단위: 원)
{| class="wikitable"
! 항목 (품명·규격) !! 세부 내역 !! 금액 !! 비고
|-
| OpenAI API 사용료 || 8,349 + 8,368 + 8,368 + 16,752 + 41,818 || 83,655원 ||
|-
| Anthropic Claude API 사용료 || 33,876 + 8,265 + 33,092 + 25,366 + 18,752 + 34,392 + 25,786 + 18,867 || 198,396원 ||
|-
| AWS 서버 || 22,961 + 146,123 || 169,084원 ||
|-
| 플레이 스토어 등록 || 38,445 || 38,445원 || 현금
|-
| 호스팅케이알 도메인 || 19,800 || 19,800원 || 현금
|-
| 도서 구매 || 65,700 (도서 2권) || 65,700원 || 현금
|-
! colspan="2" | 합계 !! colspan="2" | 575,080원
|}
※ 총 예산 600천원 중 575,080원 집행 (잔액 24,920원). 학교부담금 600천원 / 과제팀부담금 0원.

'''[자재소요서 ― 외부 서비스 및 API]'''
{| class="wikitable"
! No. !! 품목 !! 규격 !! 용도 !! 비고
|-
| 1 || OpenAI 호환 LLM API || Chat completion model || 의도 분류, 답변 생성, 프로필 후보 생성 || 사용량 기반 과금
|-
| 2 || OpenAI Embedding API || embedding model || 레시피 검색 query 및 recipe embedding 생성 || 사용량 기반 과금
|-
| 3 || AWS EC2 || Docker host || FastAPI 운영 서버 || 운영 배포
|-
| 4 || AWS RDS PostgreSQL || PostgreSQL + pgvector || 서비스 DB와 벡터 검색 || 운영 DB
|-
| 5 || AWS S3 || Object storage || AI 생성/선택 이미지 저장 || 이미지 기능 확장 시 도입
|-
| 6 || GitHub Actions || CI/CD || main 브랜치 push 시 EC2 배포 || deploy workflow 사용
|}

'''[자재소요서 ― 오픈소스 라이브러리]'''
{| class="wikitable"
! No. !! 라이브러리 !! 버전/계열 !! 용도
|-
| 1 || Python || 3.13 || 백엔드 런타임
|-
| 2 || FastAPI || current || REST API와 SSE 엔드포인트
|-
| 3 || PydanticAI || current || AI Agent orchestration
|-
| 4 || SQLAlchemy || current || ORM 및 DB transaction boundary
|-
| 5 || Pydantic || current || 요청/응답 schema와 settings
|-
| 6 || PostgreSQL pgvector || extension || 레시피 embedding 유사도 검색
|-
| 7 || Ruff || current || lint/format 품질 관리
|-
| 8 || pytest || current || 단위·서비스·통합 테스트
|-
| 9 || Docker Compose || dev/prod || 개발·운영 컨테이너 실행
|}

'''[자재소요서 ― 데이터 자원]'''
{| class="wikitable"
! No. !! 데이터 !! 설명 및 조달
|-
| 1 || foodsafetykorea 레시피 || 구조화된 영양 정보와 초기 대량 레시피 데이터로 사용한다.
|-
| 2 || 만개의레시피 웹 원천 || 실제 사용자형 조리 흐름·표현·이미지 출처를 raw payload로 수집한다.
|-
| 3 || 사용자 제출 레시피 || 사용자 입력 원문을 pending_recipes에 저장하고 관리자 검수 후 반영한다.
|-
| 4 || Golden Test Set || 의도 분류, 검색 계획, 프로필 업데이트 정책, 추천 정합성 평가용 발화·정답 세트
|}

===완료작품의 평가===
{| class="wikitable"
! 평가 항목 !! 평가 방법 !! 적용 기준 !! 개발 목표치 !! 비중(%) !! 평가 결과
|-
| 1. 식재료 인식 정확도 || 테스트 이미지 데이터셋을 활용한 인식 정확도 측정(8개 카테고리) || 전체 테스트 이미지 중 정확히 인식된 식재료 비율 || 인식 정확도 90% 이상 || 20% || 9/10
|-
| 2. 챗봇 응답속도 측정 || 사용자 질의 후 응답까지 걸리는 평균 시간 측정 || 서버 로그 및 테스트 환경에서 평균 응답 시간 측정 || 평균 응답 시간 3초 이내 || 25% || 8/10
|-
| 3. 사용자 경험(UI/UX) || 사용자 테스트 및 피드백 수집 || 불필요하거나 복잡한 과정 최소화 || 4.0/5 || 20% || 10/10
|-
| 4. AI 추천 레시피 품질 검증 || 사용자 피드백 수집(레시피 유효성 평가), JSON 스키마 자동 검증 || 추천 레시피가 입력 식재료에 기반하여 합리적·일관적인지 사용자 평가 || 사용자 평가 4.0/5 이상, 스키마 검증 95% 이상 || 25% || 10/10
|-
| 5. 응답속도 || 사용자 입력(회원가입·채팅입력 등)에 따른 API 처리시간 및 페이지 전환 처리시간 측정 || API 처리 및 페이지 전환이 2초 이내인 요청 비율 || API 처리·페이지 전환 2초 이내 90% 이상 || 10% || 8/10
|}

'''[어려웠던 내용들]'''
*SSE 기반 실시간 채팅 클라이언트를 처음부터 구축하는 과정에서 청크 단위 응답 파싱, 이벤트 타입별 분기 처리, 텍스트와 이미지 동시 전송 등에 시행착오를 많이 겪었다.
*백엔드 서버가 단일 IP에서 다중 서브도메인(api.naengo.com / ai.naengo.com)으로 분리되는 과정에서 환경변수 누락으로 인한 런타임 오류(Failed host lookup)가 반복적으로 발생했다.
*앱 출시 경험 부족으로 패키지명 변경에 따른 키스토어 재서명, 카카오 키 해시 재등록, 개인정보처리방침의 국외 이전 고지 등 출시 직전 정책 요건이 생소하고 복잡했다.

===향후계획===
*'''iOS 클라이언트 출시 및 다국어 지원''' : Flutter 단일 코드베이스의 이점을 활용해 iOS 앱을 동시 운영하고, 영문 등 다국어 지원으로 사용자 접근성을 확대한다.
*'''사용자 맞춤형 추천 고도화''' : 채팅 대화 중 사용자의 취향(선호 재료, 회피 식재료, 조리 방식, 식단 목표 등)을 점진적으로 학습·축적하고, 이를 모든 AI 채팅 응답과 레시피 추천 결과에 반영하여 사용자별 차별화된 경험을 제공한다.
*'''AI 응답속도 개선''' : 의도 분류 결과와 레시피 임베딩의 Redis 캐싱을 통해 외부 LLM API 호출 빈도를 줄이고 평균 응답 시간을 단축한다.

===특허 출원 내용===
※ 현재 출원된 특허는 없으며, 향후 특허 출원을 검토 중인 단계이다. 차별화 핵심 요소는 다음과 같다.
*RAG 기반 의미 검색 + 대화형 조건 반영 + 재료 기반 추천을 결합한 구조
*재료 메타데이터 기반 사전 필터링과 벡터 검색을 결합한 구조
*사용자 대화 입력을 반영한 Query 재구성 및 재검색 방식
*이미지 기반 재료 추출과 RAG 시스템의 연동 구조

파일:냉고 시스템아키텍처.png

2026-06-18T20:45:06Z

Com239: Com239님이 파일:냉고 시스템아키텍처.png의 새 판을 올렸습니다

2026-06-17T07:20:19Z

Com239:

파일:투표.png

2026-06-17T07:20:10Z

Com239:

파일:게시글2.png

2026-06-17T07:20:00Z

Com239:

2026-06-17T07:13:41Z

Com239:

2분반-몇대몇

2026-06-17T07:12:17Z

Com239: /* 상세설계 내용 */

<div>__TOC__</div>
==프로젝트 개요==
=== 기술개발 과제 ===
''' 국문 ''': 온라인 게임 중 분쟁사항 판단 투표 서비스

===과제 팀명===
몇대몇

===지도교수===
유하진 교수님

===개발기간===
2026년 3월 ~ 2026년 6월 (총 4개월)

===구성원 소개===
서울시립대학교 컴퓨터과학부 2021920036 심재용 (팀장)

서울시립대학교 컴퓨터과학부 2020920036 유원호

서울시립대학교 컴퓨터과학부 2021920005 권동현

서울시립대학교 컴퓨터과학부 2021920025 문세현

==서론==
===개발 과제의 개요===
====개발 과제 요약====

◇ 본 과제는 게임 플레이 중 팀 단위 온라인 게임인 “리그 오브 레전드”에서의 서로 간의 의견이 충돌하여 분쟁이 발생하였을 때, 그 분쟁을 해결할 수 있는 사이트를 생성한다.
◇ 사이트는 누군가가 플레이 영상을 올리고 특정 판단의 내용을 글로 작성하게 하면, 다른 사람들의 의견을 투표 및 댓글을 통해 받도록 한다. 이때 투표나 댓글은 포인트를 지불하는 방식으로 한다.
◇ AI 모델을 활용하여 해당 경기의 승률 변화 그래프를 자동으로 생성하고, 승률이 급격히 변동하는 핵심 지점 3곳을 표시하여 사람이 분쟁 상황을 판단할 때 도움을 주는 객관적인 보조 도구로 활용한다.
◇ 이후 특정 시간까지는 투표의 상황을 비공개 처리하고, 특정 조건을 달성하게 되면 전문가(게임의 티어가 높은 사람)의 의견을 공개하여 그 의견에 해당되는 투표를 한 사람들에게 포인트를 지급하게 된다.
◇ 포인트 지급은 회원가입, 출석체크 등을 통해 지속적으로 지급할 수 있도록 하고, 포인트를 통해 교환할 수 있는 간단한 상품을 통해 사용자의 동기를 끌어올린다.

====개발 과제의 배경====
1) 개발 동기 및 필요성

◇ 팀 단위 경쟁 온라인 게임인 리그 오브 레전드에서는 패배의 원인이나 특정 상황의 책임 소재를 두고 “누가 더 잘못했는가”에 대한 논쟁이 자주 발생하며, 이는 유저 간 갈등으로 이어지는 경우가 많다.이런 갈등이 커뮤니티상에서 화제가 되어 교통사고 과실 비율을 판정하는 프로그램인 ‘한문철의 블랙박스 몇 대몇’을 모티브로 인터넷 방송인들이 팀 내 분쟁 상황의 과실 비율을 판정해주는 콘텐츠(일명 ‘롤문철’)가 유행하고, 수요가 늘어나기 시작하였다.
◇ 게임 내 분쟁 상황의 과실 판정에 대한 수요가 늘어났지만, 이러한 컨텐츠는 일부 방송에 한정되어 있어 접근성이 낮고 일관된 판정 기준이 없다는 한계가 있어, 본 서비스를 통해 접근성을 높이고, 정돈된 환경의 서비스가 필요하다고 판단하였다.
◇ 또한 기존 판정 방식은 영상 시청 및 주관적 판단에 의존하여 분쟁 지점 파악이 어렵다는 문제가 있으며, 이를 AI 기반 승률 그래프 분석 기능으로 보완하고자 한다.

2) 향후 예상 효과
◇ AI 승률 그래프를 통해 핵심 지점을 시각적으로 제공해 분쟁 상황에 관한 보다 객관적인 판단을 제공함으로 유저 간의 갈등을 완화하여 건전한 게임 플레이 문화를 형성을 유도한다.
◇ 의견 제시 및 토론을 통해 게임 플레이에 대한 이해도와 전략적 판단 능력을 향상시켜 플레이어의 게임 실력을 향상시키는데 도움을 준다.
◇ 게임 관련 추가 컨텐츠 제공을 통한 홍보 효과로 게임 활성화에 도움을 준다.

====개발 과제의 목표 및 내용====
1. 분쟁과 관련한 투표 서비스 제공
◇ 본 프로젝트의 목표는 게임 내 발생하는 분쟁 상황에 대해 여러 사용자에게 투표를 받아 보다 객관적인 판단 기준을 제공하는 투표형 서비스를 구축하는 것이다. 사용자는 분쟁 사항 설명과 분쟁 사항이 담긴 영상을 업로드하여 게시하고, 다른 사용자들은 어떤 쪽이 더 맞는지 투표할 수 있고, 해당 상황에 대한 자신의 생각을 댓글/대댓글 기능으로 남길 수 있다.
2. AI 기반 승률 분석 그래프 제공
◇ 라이엇 게임즈 api를 통해 경기 데이터를 수집하고, AI 모델을 학습시켜 시간대별 팀 승률 변화를 그래프로 시각화하는 기능을 제공한다.
◇ 학습된 AI 모델은 경기 전반에 걸친 승률 곡선을 생성하며, 승률이 급격하게 변동(급등 또는 급락)하는 구간 상위 3개 지점을 그래프 위에 마커로 표시한다.
◇ AI 기반 승률 분석 그래프는 최종 판정의 근거가 아닌 참고 자료로 제공된다.
3. 동기부여를 위한 포인트 지급
◇ 처음 회원가입을 할 때, 출석체크를 할 때 포인트를 지급하여 사용자가 포인트를 이용하여 투표에 참여할 수 있도록 유도한다. 이후 맞추게 될 시 포인트를 대량 지급하고, 포인트 상점을 통해 프로필 사진, 배경 꾸미기 등의 아이템을 제공한다.

===관련 기술의 현황===
====관련 기술의 현황 및 분석(State of art)====
가. State of art

◇ E-스포츠 데이터 기반 딥러닝 : 최근 리그 오브 레전드의 실시간 매치 타임라인 데이터를 활용해 게임의 승패를 예측하는 연구가 활발히 진행 중이다. RNN, LSTM, Transformer 등 시계열 데이터를 처리하는 모델이 주로 사용되며, 골드 격차, 오브젝트 획득 수 등 다양한 피처(Feature)를 분석한다.
◇ 웹 서비스 아키텍처 : React, Vue.js 등을 활용한 SPA(Single Page Application) 기반의 직관적인 사용자 UI 설계와, 실시간 트래픽을 처리하기 위한 AWS 클라우드 서버 구축이 일반화되어 있다.

나. 기술 로드맵

◇ 데이터 수집 및 전처리 : Riot API를 통해 리그 오브 레전드 매치 타임라인 데이터 수집 및 정제
◇ AI 모델 구축 및 학습 : 외부 API에 의존하지 않고 시계열 데이터 기반 자체 딥러닝 승률 예측 모델 설계 및 학습 진행
◇ 핵심 기능 구현 : 회원가입(티어 인증 연동), 게시판(영상 및 댓글/투표), 포인트 시스템 개발
◇ AI 기능 구현 : 시간대별 기대 승률 및 주요 타임라인을 추출하는 AI 모델 개발
◇ 테스트 및 배포 : AWS 환경을 이용한 서버 배포 및 라이브 서비스 테스트

====시장상황에 대한 분석====
가. 경쟁제품 조사 비교

◇ op.gg/lol.ps/deep.lol
● 특징: 챔피언 티어, 유저 전적, 아이템 통계 등 게임 내 수치 데이터를 제공하는 데 특화되어 있다.
● 한계: 게임 내 분쟁 상황을 판단하거나 영상 기반의 유저 간 투표, 전문가 판정을 내리는 커뮤니티 기반의 기능이 제한적이다.

◇ 리그 오브 레전드 커뮤니티
● 특징: 유저 간 텍스트 및 영상 업로드를 통한 자유로운 토론이 가능하다.
● 한계: 익명성에 기반한 무분별한 비난이 주를 이루며, 투표나 티어 인증 전문가의 체계적인 판정 시스템이 미흡하여 명확한 결론을 도출하기 어렵다.

◇ 인터넷 방송 컨텐츠 (롤문철)
● 특징: 유명 방송인(전문가)이 직접 유저들의 제보를 받아 과실 비율을 판정하며, 높은 화제성과 인기를 보유하고 있다.
● 한계: 특정 방송인에게 제보가 집중되어 일반 유저의 접근성이 매우 낮으며, 방송 일정에 의존해야 하므로 실시간 판정이 어렵다. 또한 일부 사행성 논란으로 인해 신뢰도가 저하되었다.

◇ 경쟁제품 비교 요약표

{| class="wikitable sortable" style="text-align: center; width: 100%;"
! width="15%" | 구분
! width="28%" | op.gg/lol.ps/deep.lol
! width="28%" | 리그 오브 레전드 커뮤니티
! width="29%" | 인터넷 방송 컨텐츠 (롤문철)
|-
! 서비스 유형
| 통계/전적 분석 사이트
| 유저 커뮤니티(갤러리)
| 인터넷 방송 콘텐츠
|-
! 주요 특징
| 챔피언 티어, 유저 전적, 아이템 통계 등 게임 내 수치 데이터 분석에 특화
| 텍스트, 영상 업로드를 통한 자유로운 유저 간 토론 가능
| 전문 방송인이 직접 유저 제보를 받아 과실 비율을 판정, 높은 화제성
|-
! 분쟁 판정 기능
| 없음
| 비체계적(댓글/논쟁 형태)
| 있음(방송인 직접 판정)
|-
! 전문가 참여
| 없음
| 없음(비인증 일반 유저)
| 있음(특정 방송인 한정)
|-
! 접근성
| 높음(누구나 즉시 조회)
| 높음(자유 게시 가능)
| 매우 낮음(제보 경쟁 심각)
|-
! 참여 보상 시스템
| 없음
| 없음
| 없음
|-
! AI 기반 분석
| 일부 있음(전적 통계 기반)
| 없음
| 없음
|-
! 주요 한계
| 분쟁 판정·커뮤니티 기능 매우 제한적
| 익명 기반 무분별 비난, 체계적 판정 시스템 미흡
| 접근성 낮음, 실시간성 부족, 신뢰도 저하
|}

나. 마케팅 전략

◇ 접근성 극대화 : 기존 인터넷 방송 컨텐츠(롤문철)의 높은 진입장벽을 낮추어 누구나 쉽게 영상을 올리고 투표를 받을 수 있는 웹 생태계를 구축한다.
◇ 참여 보상 : 포인트 제도를 통해 투표 참여자와 정답자에게 보상을 제공하여 지속적인 서비스 이용을 유도한다.
◇ AI 기술을 통한 편의성 제공 : 기존 커뮤니티에 없는 AI를 통한 승률 변동 및 타임라인 추천 시스템을 도입하여 유저가 주요 구간을 쉽게 찾아 합리적인 투표를 할 수 있도록 지원한다.

===개발과제의 기대효과===
====기술적 기대효과====
◇ 팀원들이 직접 대용량 게임 데이터를 수집 및 정제하여 승률 예측 AI 모델을 처음부터 끝까지 파이프라인으로 구축하는 경험을 축적할 수 있다.
◇ 동시다발적인 투표 및 포인트 증감 처리 시 발생할 수 있는 동시성 이슈를 해결하는 등 백엔드 트랜잭션 처리 역량을 기를 수 있다.

====경제적, 사회적 기대 및 파급효과====
◇ 새로운 플랫폼 시장 창출: 기존 대형 커뮤니티나 통계 사이트가 충족시키지 못했던 '게임 내 분쟁 해결 및 과실 판정'이라는 특정 수요를 공략하여, e-스포츠 파생 콘텐츠의 새로운 플랫폼 시장을 개척할 수 있다.
◇ 건전한 게임 문화 조성 및 사이버 폭력 감소: 온라인 게임 내 분쟁이 감정적인 욕설이나 트롤링 등 비매너 행위로 번지는 것을 방지하고, 제3자의 객관적 시선과 AI 데이터를 통해 분쟁을 이성적으로 해결할 수 있는 창구를 제공함으로써 게임 문화 개선에 기여한다.

===기술개발 일정 및 추진체계===
====개발 일정====
{| class="wikitable" style="text-align: center; width: 100%;"
! rowspan="2" width="35%" | 단계별 세부개발 내용
! rowspan="2" width="20%" | 담당자
! colspan="4" width="30%" | 개발기간 (월단위)
! rowspan="2" width="15%" | 비고
|-
! width="7.5%" | 3
! width="7.5%" | 4
! width="7.5%" | 5
! width="7.5%" | 6
|-
! 주제 선정
| 팀원 전체
| style="background-color: #333;" |
|
|
|
|
|-
! 요구사항 분석 및 UI 기획
| 팀원 전체
| style="background-color: #333;" |
| style="background-color: #333;" |
|
|
|
|-
! 웹 사이트 연동
| 권동현, 문세현
|
| style="background-color: #333;" |
|
|
|
|-
! 회원가입 / 게시판 기능
| 권동현, 문세현
|
| style="background-color: #333;" |
| style="background-color: #333;" |
|
|
|-
! 투표 / 댓글 기능
| 권동현
|
| style="background-color: #333;" |
| style="background-color: #333;" |
|
|
|-
! AI 승률 모델 학습 및 개발
| 심재용, 유원호
|
| style="background-color: #333;" |
| style="background-color: #333;" |
| style="background-color: #333;" |
|
|-
! AI 모델 적용 및 보완
| 심재용, 유원호
|
|
| style="background-color: #333;" |
| style="background-color: #333;" |
|
|-
! 포인트 시스템 / 라이엇 api 연동
| 문세현
|
|
| style="background-color: #333;" |
| style="background-color: #333;" |
|
|-
! 통합 테스트 및 배포
| 팀원 전체
|
|
|
| style="background-color: #333;" |
|
|}

====구성원 및 추진체계====
1. 구성원
◇ 심재용(팀장) : AI 승률 모델 학습 및 개발과 적용, 백엔드 구현
◇ 유원호 : AI 승률 모델 학습 및 개발과 적용, 백엔드 구현
◇ 권동현 : UI 설계 및 구현, 댓글, 영상, 투표 기능 구현
◇ 문세현 : 회원가입 및 게시판 기능 구현, 라이엇 api 연동 시스템 구축, 포인트 시스템 구축

2. 추진체계
[[파일:추진체계2.png]]

==설계==
===설계사양===
====제품의 요구사항====
{| class="wikitable" style="width: 100%;"
|- style="text-align: center;"
! width="10%" | 번호
! width="60%" | 요 구 사 항
! width="15%" | D or W
! width="15%" | 중요도
|-
| style="text-align: center;" | 1
| 편의성 (UI/UX)
| style="text-align: center;" | D
| style="text-align: center;" | 중
|-
| style="text-align: center;" | 2
| 로그인 성공 :
| style="text-align: center;" | D
| style="text-align: center;" | 대
|-
| style="text-align: center;" | 3
| AI 정확성
| style="text-align: center;" | W
| style="text-align: center;" | 중
|-
| style="text-align: center;" | 4
| 댓글 기능 :
| style="text-align: center;" | D
| style="text-align: center;" | 대
|-
| style="text-align: center;" | 5
| 동영상 업로드
| style="text-align: center;" | D
| style="text-align: center;" | 대
|-
| style="text-align: center;" | 6
| 포인트 지급
| style="text-align: center;" | w
| style="text-align: center;" | 소
|-
| style="text-align: center;" | 7
| 시스템 안정성
| style="text-align: center;" | D
| style="text-align: center;" | 소
|-
| style="text-align: center;" | 8
| 전문가의 판정
| style="text-align: center;" | D
| style="text-align: center;" | 소
|}

====목적 계통도====
[[파일:목적_계통도.png]]

===개념설계안===

자체 개발한 AI 를 활용해 온라임 게임 경기 내에서 승률이 급격하게 바뀌는 시점을 제공한다.
◇Match data와 Match timeline data를 활용해 분단위 승률 예측 모델을 개발
◇LSTM모델과 TRANSFORMER모델 두가지를 후보군으로 두고 실험 진행
◇더 나은 예측을 보이는 모델을 사용
유저가 논쟁상황이 일어난 경기를 영상및 게임 태그로 업로드
◇게임 태그를 따로 업로드 할 수 있는 창을 제공
◇영상은 유튜브 영상을 바로 재생할 수 있는 창을 사용
신뢰할수있는 전문가의 평가
◇AI를 활용해 중요한 시간대를 선정해 전문가가 판정 하나를 하는 시간을 감축
◇신뢰할 수 있는 전문가의 이유와 판정으로 논쟁상황을 납득할 수 있도록 정리
평가에 따른 포인트의 분배
◇평가를 해서 승패를 나눈 후 정답인 쪽에 투표한 유저들에게 일정수준의 포인트를 지급
◇오답인 쪽에 투표한 유저들에게는 일정수준의 포인트를 몰수
포인트의 유통량
◇포인트를 접속하는 접속보상, 댓글을 달았을때 얻는 활동보상, 업로드를 했을때 얻는 업로드 보상, 투표로 얻는 보상등으로 얻을 수 있게 한다.
◇포인트획득량을 적절히 조절해 포인트 획득에 적절한 만족감을 얻도록 설계.

===이론적 계산 및 시뮬레이션===
[[파일:Lstm.png]]
<LSTM> <Transformer>

[[파일:모델구조.png]]

◇ 데이터 수집의 경우 Riot API의 Match Timeline 데이터를 수집하여 분 단위 13개의 피처(블루/레드팀 총 골드/경험치, 골드/경험치 격차, top/mid/bottom 포탑 파괴 여부, 드래곤/유충/전령/바론 처치 여부)를 추출한다. 이를 전처리하고, 5분단위 슬라이딩 윈도우 과정을 거치게 된다. 이를 LSTM, Transformer와 비교하여 human data하고 비교하였을 때 성능이 더 좋다고 생각이 드는 모델을 선정하게 된다.

===상세설계 내용===
[[파일:소프트웨어_설계.png]]
◇ 기술스택으로는 프론트엔드는 React 기반 SPA를 사용하였으며 구글 소셜 로그인을 통해 로그인을 할 수 있도록 하였고, YouTube API를 통한 영상 임베드를 지원하여 영상을 볼 수 있도록 하였다. 백엔드 부분은 Node.js를 사용하였고, Riot API를 받아 경기를 가져오고, 이를 AI 모델을 통해 분석하여 승률 예측 값을 보여주는 방식이다. 데이터베이스는 SQLite를 사용하였고 서버는 AWS EC2에서 사용한다.
◇ 포인트 시스템의 경우, 출석 체크나 투표 정답 시 포인트를 획득하고, 투표 참여 및 글/댓글 작성을 통해 포인트를 사용하게 된다.

[[파일:데이터베이스_설계.png]]
◇ 데이터베이스는 SQLite를 사용하며 총 8개의 테이블로 구성된다. USERS 테이블은 유저 정보와 포인트 잔액을 관리하고, ATTENDANCE는 하루 1회 출석 체크 기록을 저장한다. POSTS는 게시글 정보를 저장하며 판정 완료 여부(is_closed), 최종의견(final_opinion), 정답 항목(correct_option_id)을 포함한다. VOTE_OPTIONS는 게시글별 투표 항목을, VOTES는 유저별 투표 기록(1인 1회)을 저장한다. COMMENTS는 댓글 및 대댓글(parent_id)을 관리하며, POST_LIKES와 COMMENT_LIKES는 각각 게시글과 댓글의 추천/비추천 기록을 저장한다.

==결과 및 평가==
===완료 작품의 소개===
====프로토타입 사진 혹은 작동 장면====
내용
====포스터====
내용

===관련사업비 내역서===
{| class="wikitable" style="width: 100%;"
|+ 4. 개발사업비 산정내역서
| colspan="7" style="text-align: right; border: none; background: none;" | ( 단위 : 천원 )
|- style="text-align: center;"
! colspan="2" width="45%" | 항 목<br>(품명, 규격)
! width="10%" | 수 량
! width="10%" | 단 가
! colspan="2" width="20%" | 금 액
! width="15%" | 비 고
|- style="text-align: center;"
| colspan="4" style="background:#f2f2f2;" |
! width="10%" | 계
! width="10%" | 현금
| style="background:#f2f2f2;" |
|-
! rowspan="6" style="text-align: center; width: 5%;" | 직<br>접<br>개<br>발<br>비
| 프로젝트 진행을 위한 Claude 구독
| style="text-align: right;" | 2
| style="text-align: right;" | 33
| style="text-align: right;" | 66
| style="text-align: right;" | 0
| style="text-align: center;" | 2개월
|-
| 프로젝트 진행을 위한 회의 진행
| style="text-align: right;" | 8
| style="text-align: right;" | 15
| style="text-align: right;" | 120
| style="text-align: right;" | 0
| style="text-align: center;" | 4인 x 2번
|-
| 프로젝트 진행을 위한 AWS 서버 사용료
| style="text-align: right;" | 1
| style="text-align: right;" | 15
| style="text-align: right;" | 15
| style="text-align: right;" | 0
|
|-
| 프로젝트 진행을 위한 도메인 구매
| style="text-align: right;" | 1
| style="text-align: right;" | 25
| style="text-align: right;" | 25
| style="text-align: right;" | 0
|
|-
| 프로젝트 관련 문헌 구매
| style="text-align: right;" | 10
| style="text-align: right;" | 37
| style="text-align: right;" | 370
| style="text-align: right;" | 0
|
|-
| 발표 문서 인쇄 비용
| style="text-align: right;" | 80
| style="text-align: right;" | 0.05
| style="text-align: right;" | 4
| style="text-align: right;" | 0
|
|- style="text-align: center; font-weight: bold;"
! colspan="2" | 합 계
|
|
| style="text-align: right;" | 600
|
|
|}

===완료작품의 평가===
제공해주신 이미지 속 '평가 항목 및 목표치' 표를 위키백과(Wikipedia) 형식에 맞춘 위키텍스트 문법으로 변환해 드립니다.

가독성을 높이기 위해 수치 데이터가 들어가는 '개발 목표치'와 '비중 (%)' 열은 가운데 정렬(text-align: center)을 적용했고, 줄바꿈이 많은 평가 방법과 적용기준은 자연스럽게 표현되도록 구성했습니다.

위키백과 표 코드
Plaintext
{| class="wikitable" style="width: 100%;"
|- style="text-align: center;"
! width="22%" | 평가 항목
! width="38%" | 평가 방법
! width="20%" | 적용기준
! width="10%" | 개발 목표치
! width="10%" | 비중 (%)
|-
! 1. 라이엇 api 연동 기능
| 라이엇 api 연동 후 티어 출력 테스트 확인
| 회원가입시 연동 성공률
| style="text-align: center;" | 100%
| style="text-align: center;" | 10%
|-
! 2. 댓글, 대댓글 기능
| 댓글 작성 후 프론트엔드에 나타나는지 확인
| 댓글 작성 성공률
| style="text-align: center;" | 100%
| style="text-align: center;" | 20%
|-
! 3. 영상 재생 기능
| 유튜브에 올린 영상을 잘 가져와서 모든 사람들에게 보이는지 확인
| 유튜브 영상 재생 성공률
| style="text-align: center;" | 80%
| style="text-align: center;" | 20%
|-
! 4. 투표 기능
| 업로드 후 특정 조건까지는 비공개 처리 후 특정 시간 이후 모든 사람들에게 보이는지 확인
| 투표 적용 성공률
| style="text-align: center;" | 100%
| style="text-align: center;" | 20%
|-
! 5. 포인트 시스템
| 계정마다 출석을 할 때 포인트 지급되는지, 투표를 할 때 포인트가 사용되는지, 맞추게 될 시 포인트가 지급되는지 확인
| 포인트 지급/사용 성공률
| style="text-align: center;" | 100%
| style="text-align: center;" | 15%
|-
! 6. AI 모델이 승률 예측 시스템
| 경기에 대해 매분 예측 승률이 human data와 비교했을 때 승률의 일치율이 얼마나 비슷한지 확인
| 전체 분 단위 승률 예측 일치율
| style="text-align: center;" | 70%
| style="text-align: center;" | 15%
|}

===향후계획===
내용

===특허 출원 내용===
내용

파일:데이터베이스 설계.png

2026-06-17T07:11:32Z

Com239:

파일:소프트웨어 설계.png

2026-06-17T07:11:02Z

Com239: