💊 영양제 Check! 개발기

개인 맞춤과 신뢰 기반을 모두 갖춘 건강기능식품 추천 시스템의 설계와 구현

🔗 GitHub repository

프로젝트 기간:  2025.06.30 - 2025.07.03  (4인 프로젝트)

0. 목차

1. 프로젝트 도입: 왜 '영양제 추천'인가?
2. 프로젝트 목표
3. 어떤 기술을 왜 선택했는가?
4. 문헌 수집 및 전처리 방식
5. 기술적 설계 포인트
6. 사용자 입력 처리 및 Case 분류 로직
7. 공공데이터 기반 제품 추천 파이프라인
8. Streamlit 기반 UI 구성 및 사용자 경험 설계
9. 실행 결과
10. 개선 방향
11. 프로젝트 회고

1. 프로젝트 도입: 왜 '영양제 추천'인가?

최근 몇 년 사이 건강기능식품 시장은 트렌드를 넘어 일상 소비로 정착되었다. 그러나 수백 개의 브랜드와 성분, 제품군이 동시에 쏟아지는 상황에서 소비자는 여전히 어떤 영양제를 어떻게 선택해야 할지 명확한 기준을 갖기 어렵다.

게다가 최근에는 검색보다 ChatGPT, Gemini와 같은 대형 언어모델(Large Language Model, LLM) 기반 챗봇에게 직접 질문하여 정보를 얻는 게 자연스러운 시대가 되었다.

“무슨 영양제를 먹는 게 좋을까?”, “루테인은 눈에 진짜 효과 있어?”, “이 제품은 당뇨 환자도 먹을 수 있어?” 같은 질문도 전문가가 아니라 챗봇에게 먼저 묻고는 한다.

그런데 "그 정보, 그대로 믿어도 될까?" 하는 의문도 가지고 있을 것이다.

실제로 건강 정보나 성분 추천에 대해 이들 챗봇이 제공하는 응답은 과거에 비해 상당히 정확하고 자연스럽게 보이지만, 여전히 다음과 같은 구조적인 문제가 존재한다.

• 모델마다 답변이 다르며 사용자는 어떤 응답이 진짜인지 판단할 기준이 없다.
• 출처가 명시되지 않거나, 논리의 근거가 불분명하여 검증이 어렵다.
• 특히 건강 도메인에서는 존재하지 않는 성분을 제시하거나, 의학적으로 권장되지 않는 정보를 사실처럼 응답하는 '환각(Hallucination)' 현상이 여전히 발생한다.
  

이러한 배경에서 본 프로젝트는 '영양제 추천 시스템'을 만드는 것이 아니라, LLM의 불확실한 응답 구조 자체를 신뢰 가능한 구조를 제공하기 위한 기술적 실험으로 시작되었다.

" GPT보다 믿을 수 있는, 실제로 도움이 되는  영양제 추천 시스템 ”

2. 프로젝트 목표

우리 팀은 하나의 방향 속에서 세 가지의 목표를 정확하게 잡았다.

2.1  신뢰 가능한 정보 제공

• GPT-4 기반 LLM이 답변을 생성할 때 임의의 성분을 '창작'하지 않도록 하기 위해 오직 문서 기반의 RAG 구조를 채택하였다.
  
• 사용된 문서는 학술 논문, 정부 가이드라인, 식약처 자료 등 46편의 PDF 문서이며, LLM은 반드시 이 문서 내 정보에 기반하여 답변을 생성해야 한다.
  

2.2  사용자 맞춤형 추천

• 사용자로부터 나이, 성별, 질환, 복용 중 약물, 선호 성분 등의 정보를 입력받고, 키워드 기반으로 사전 정의된 Case A~D 시나리오 로 분류하여 각기 다른 처방을 반환하도록 설계하였다.
  
• 동일한 사용자 질문이라도 복용 중 약물 또는 질환에 따라 금기 성분이 달라질 수 있으며, 이 분류를 통해 상호배타적인 조건 처리 및 다중 처방 적용이 가능하도록 구성하였다.
  

2.3  실제 제품 추천 및 실행 가능성 확보

• 성분 정보를 알려주는 데 그치지 않고, 식품의약품안전처 공공데이터(API)를 통해 추천 성분이 포함된, 피해야 할 성분은 제외된 실제 제품을 추천한다.
  
• 유사도 기반 벡터 검색을 통해 추천 제품을 찾아주며, 금기 성분이 포함된 제품은 실시간으로 필터링하여 제외한다.
• 실제 제품을 사용자에게 연결하여 정보 소비에 그치지 않고 실행 가능한 사용자 행동으로 이어지는 것을 기대하였다.

프로젝트의 방향 설정 후, 아래와 같이 역할을 분배하였다.

3. 어떤 기술을 왜 선택했는가?

3.1  LLM 환각 방지를 위한 RAG 구조 도입

GPT-4는 강력한 문장 생성 능력을 갖추었지만, 정해진 지식 범위 내에서만 작동하지 않는다. 특히 건강 도메인에서는 존재하지 않는 성분이나 제품명을 제시하는 '환각(Hallucination)' 문제가 치명적이다.

이 문제를 해결하기 위해, 본 프로젝트에서 RAG (Retrieval-Augmented Generation) 구조를 채택하는 것이 적절하다고 판단하였다.

RAG는 외부 문서에서 정보를 검색하고 이를 기반으로 LLM이 응답을 생성하는 방식으로,"문서 기반 지식의 통제" 와 "LLM 응답의 정확성" 을 동시에 확보할 수 있는 구조이다.

• Hallucination을 원천적으로 차단 가능 (문서 외 정보 사용 제한)
• 응답 신뢰도 향상 및 출처 명시 가능
• LangChain 기반으로 RAG 체인을 구성하기 용이함

3.2  문서 임베딩 및 검색을 위한 FAISS 사용

문서 검색 과정에서 핵심이 되는 것은 사용자의 질문과 가장 유사한 문단을 빠르게 찾아내는 것이다. 이를 위해

OpenAI Embedding + FAISS 인덱싱 구조를 선택하였다.

FAISS(Facebook AI Similarity Search)는 고차원 벡터 간 유사도 계산에 특화된 라이브러리로, 수천~수만 개의 벡터에서 유사한 결과를 빠르게 찾아내는 데 적합하다.

Document 객체에 메타 정보를 함께 저장하므로 검색 후 원문 출처, 문서명, 출판연도 등도 함께 추출 가능하다는 점에서 프로젝트의 방향성에 부합한다.

from langchain.vectorstores import FAISS
from langchain.embeddings import OpenAIEmbeddings

embedding = OpenAIEmbeddings()
vectorstore = FAISS.from_documents(documents, embedding)
vectorstore.save_local("faiss_db/")

• 1만 건 이상의 문서를 벡터화하여도 검색 속도가 빠름
• Local 환경에서 저장, 로드, 추가 삽입(add_documents) 가능
• LangChain과 통합 가능 (FAISS.from_documents(), load_local() 등)

3.3  실제 제품 추천을 위한 공공데이터 API 활용

문서 기반 성분 추천만으로는 실제 사용자 액션으로 이어지기 어렵다.

이를 해결하기 위해 식품의약품안전처 건강기능식품정보 Open API 를 사용하였다.

이 API는 약 10,000건의 영양제 제품 정보를 제공하며 기능성, 성분, 주의사항, 섭취방법 등의 정보를 포함하고 있다.

• 공공기관이 제공하는 신뢰 가능한 제품 정보
• 일일 10,000건 호출 가능
• 제품명, 기능성, 주의사항, 섭취량 등의 필드가 존재하여 추천 후 연계 가능

4. 문헌 수집 및 전처리 방식

사용된 문헌은 총 46편의 학술 논문, 건강기능식품 가이드라인, 식약처 자료로 구성되어 있다. 이 문헌들은 PDF 형식으로 수집되었고, 문단 단위로 분할하고 벡터화하기 위한 사전 정제 작업이 필요하였다.

아래의 과정으로 전처리를 수행하였다.

1. 텍스트 추출:  PyMuPDF 기반으로 PDF에서 본문 텍스트 추출
2. 의미 단위 분리:  불필요한 공백/머리말 제거 후, 문단 또는 항목 기반으로 의미 단위 분리
3. LangChain 문서화:  Document 객체로 변환 (메타 정보 포함: 출처, 제목, 문서 유형 등)

문서 분할은 단순 길이 기준이 아닌 문맥 보존을 위한 chunk overlap 기법을 적용하였으며 이후 Embedding 과정으로 연결된다.

from langchain.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter

loader = PyPDFLoader("간건강_가이드라인.pdf")
pages = loader.load()
splitter = RecursiveCharacterTextSplitter(chunk_size=700, chunk_overlap=100)
documents = splitter.split_documents(pages)

5. 기술적 설계 포인트

RAG(Retrieval-Augmented Generation)를 두 번 활용해 신뢰성과 정밀도를 동시에 확보합니다.

1. 첫 번째 RAG는 사용자의 건강 상태와 선호에 따라 논문 기반 성분 정보를 추출하고,
2. 두 번째 RAG는 해당 성분을 기준으로 공공데이터에서 실제 제품을 추천한다.

이렇게 2단계로 분리된 구조는 "왜 이 성분을 추천하는가" 와 "그 성분이 포함된 제품은 무엇인가" 를 연결할 수 있다.

5.0  RAG 구조

5.1  카테고리별 문서 벡터 DB 분리 및 앙상블 리트리버 구성

사용자 입력은 단일 증상이 아닌 여러 건강 영역을 포함할 수 있다.
     ex. 눈 건강 + 피로 + 커피 과다 섭취

이를 고려하여 문서 벡터 DB를 질환/이슈별 시나리오 케이스를 분리 저장하였으며, LangChain의 EnsembleRetriever를 통해 다중 검색이 가능하도록 구성하였다.

retriever1 = FAISS.load_local("faiss_db/case_A", embedding)
retriever2 = FAISS.load_local("faiss_db/case_b", embedding)

ensemble_retriever = EnsembleRetriever(
    retrievers=[retriever1, retriever2],
    weights=[0.5, 0.5]
)

5.2  사용자 입력 처리 및 Case 분류 로직

사용자 입력 키워드 추출 후, 시나리오별 Case를 분류하여 화이트리스트 기반 프롬프트를 설계하였다.

• RAG 응답 생성 시, LLM이 사용할 수 있는 성분 리스트를 사전에 명시하여 전달
• 프롬프트 내에 "JSON only", "마크다운 금지", "허용된 성분 외 사용 금지" 명시
• 결과적으로 환각 방지 + 응답 일관성 + 파싱 안정성 확보

>>  6. 사용자 입력 처리 및 Case 분류 로직 참고

5.3  공공데이터 기반 제품 추천 파이프라인

>>  7. 공공데이터 기반 제품 추천 파이프라인 참고

6. 사용자 입력 처리 및 Case 분류 로직

의료·영양 도메인은 "창의성" 보다 안전성·근거 기반이 최우선이다.

실제 논문마다 결과가 엇갈리고, 전문가들조차 단일 정답을 내리기 어려운 영역이므로, "모든 상황에 맞는 답변" 대신 시나리오(case) 단위로 검증된 성분만 제공하도록 구현하였다. 이 과정에서 논문/연구 자료 등 신빙성 있는 자료 조사를 통해 도메인에 대한 정확한 이해가 필요했다.

본 프로젝트는 사용자에게 다음 항목의 입력을 요구한다.

• 나이, 성별
• 현재 가지고 있는 질환 혹은 증상
• 복용 중인 약품 및 영양제
• 원하는 영양제의 특징 또는 조건 (ex. 눈 건강, 근육 회복, 뇌 건강 개선 등)

이 입력은 단순히 문자열로 구성되어 있으나, 이후 전체 파이프라인에서 핵심적인 역할을 하게 되며

특히 "사용자 상태 분류 → case별 처방 분기" 의 기준이 된다.

6.1  Case A~D 분류 체계

초기 설계 단계에서 구체적인 페르소나를 지정하여 사용자 요구를 몇 가지 유형으로 분류하였다.

이는 질문의 형태를 제한하기 위함이 아니라, LLM의 프롬프트 안정성과 응답 품질을 확보하기 위한 구조적 장치이다. 앞서 언급한 것처럼 도메인 특성 상 "모든 상황에 맞는 답변" 보다는 한정된 대상이라도 검증된 성분 정보를 제공하는 것이 중요하기 때문이다.

1. Case_A, Case_B 에서는 동일한 "음주/흡연" 이라는 변수를 주어 비교 실험을 설계하였다.
2. Case_C, Case_D 에서는 특정 질환에 중점을 두고 정확한 결과를 도출해 내는 것을 목표로 하였다.

• Case_A:  눈 건강 + 간 건강 관련
• Case_B:  커피/카페인 과다 섭취
• Case_C:  심혈관 및 혈압 관리
• Case_D:  복용 중인 약품과 충돌 가능성 (예: 철분 + 항생제)

6.2  사용자 입력 분석 함수

사용자의 자유 입력을 사전 정의된 Case에 매핑하기 위한 함수를 구성하였다.

def categorize_user_query(user_input: str) -> list:
    case_list = []
    if "간" in user_input or "음주" in user_input or "회식" in user_input:
        case_list.append("A")
    if "커피" in user_input or "카페인" in user_input:
        case_list.append("B")
    if "눈" in user_input or "루테인" in user_input:
        case_list.append("C")
    if "약" in user_input or "복용" in user_input:
        case_list.append("D")
    return case_list

해당 함수는 자유 입력을 분석하여 중첩된 case를 다중 반환한다.

즉, 한 사용자가 동시에 간 건강 + 눈 건강 + 약물 복용 정보를 입력한 경우, 세 가지 처방 논리를 모두 프롬프트에 반영할 수 있도록 설계하였다.

6.3  프롬프트 템플릿과 연결

각 case에는 다음과 같은 구조의 JSON 응답 템플릿이 사전에 정의되어 있다.

{
  "recommended": [...],
  "avoid": [...],
  "caution": [...],
  "reference": [...]
}

이 템플릿은 각 case별로 다르게 정의되고, 사용자의 입력이 여러 case에 해당될 경우 해당 템플릿을 병합하여 LLM 프롬프트로 전달한다.

프로젝트 진행 과정에서

프롬프트는 "허용된 성분만 사용하라" 는 whitelist 구조를 갖추도록 설계 방향을 잡게 되었다. 이 구조 덕분에 구조화된 응답, 일관된 필드, 안정적인 파싱이 가능해졌다.

7. 공공데이터 기반 제품 추천 파이프라인

7.1  데이터 출처 및 형식

사용된 데이터는 식약처 건강기능식품정보 공공 API로, 총 10,000건의 영양제 제품 정보를 사용하였다.

본 프로젝트에서는 다음 5가지 필드만 유지하여 벡터화 대상 문서를 구성하였다.

• 제품명
• 기능성
• 섭취 방법
• 주의사항
• 주성분

[참고] 식품의약품안전처_건강기능식품정보 Open API

7.2  데이터 수집 및 저장 전략

사용한 식약처 API에 아래과 같은 제약이 존재하는 것을 확인하였다.

• numOfRows 최대값: 100
• 호출 단위: 페이지당 100개
• 일일 최대 호출 건수: 10,000회

이를 고려하여 다음 전략으로 수집을 진행하였다.

단계	처리 방식	목적
① 1,000건 프로토타입	500 + 500건을 호출하여 테스트	응답 형식 분석, 파싱 테스트
② 임베딩 토큰 초과 대응	500건씩 수집 → 다시 100개씩 나누어 임베딩	OpenAI 임베딩 토큰 제한 회피
③ 전체 수집	100페이지 × 100개 = 10,000건 수집 완료	전체 데이터 확보
④ 문서화	필요한 필드만 LangChain Document로 저장	임베딩 부하 최소화, 검색 정확도 향상

7.3  제품 추천 로직

제품 추천은 recommended 성분 리스트를 기준으로 FAISS 검색을 수행하고,

동시에 avoid 성분 리스트에 해당하는 제품은 필터링하여 제외한다.

def filter_avoid_products(results, avoid_list):
    return [
        r for r in results
        if not any(avoid in r.page_content for avoid in avoid_list)
    ]

최종적으로 5개 제품만 추려서 사용자에게 카드 형태로 제시하고, 제품 정보는 UI 상에서 확장 가능(expandable)하게 구성하였다.

8. Streamlit 기반 UI 구성 및 사용자 경험 설계

8.1  전체 UI 흐름

UI는 Streamlit 기반으로 구성하였으며, 사용자는 한 화면 내에서 다음과 같은 흐름을 경험하게 된다.

1. 정보 입력 (폼 기반)
2. RAG 기반 챗 응답 (성분 추천 및 주의사항 포함)
3. 해당 성분 기반의 제품 카드 추천
4. 모든 응답의 출처 명시 및 JSON 기반 시각화

이러한 구성은 사용자가 응답 신뢰도를 기반으로 실시간 제품 비교 행동으로 이어질 수 있도록 UX 흐름을 설계하였다.

8.2  파싱 오류 및 예외 처리

LLM의 응답은 JSON으로 제한되어 있지만,

응답이 누락되거나 포맷 오류가 발생할 가능성을 대비하여 다음과 같은 안전 장치를 마련하였다.

• json.loads() 실패 시 즉시 오류 메시지 출력
• Streamlit 상에서 응답 중단 없이 이전 결과 유지
• 잘못된 응답이 반복되는 경우 로그 저장 후 LLM 호출 재시도

9. 실행 결과

💬  영양제 Check! 실행 결과

아래는 최종적으로 완성된 "영양제 Check!" 서비스를 실행한 화면이다.

사용자가 정보를 입력하면, 추천 성분과 피해야 할 성분, 주의사항, 실제 제품까지 순차적으로 출력되고, 각 결과는 모두 논문 또는 공공데이터에 기반한 검증된 정보만을 사용한다.

사용자는 자신의 상태에 따라 다른 결과를 받게 되며, 그 차이를 명확히 체감할 수 있다.

• Case_A, Case_B

• Case_C, Case_D

실행 결과를 해석할 때 가장 중요했던 건, 제시된 성분이 실제로 해당 사용자에게 적절한가를 도메인 기준에서 검증하는 것이었다.

공부하고 이해한 도메인 지식을 바탕으로 나와야 할 성분이 빠지거나 나오면 안 되는 성분이 포함된 경우를 구분할 수 있었고, 이 과정을 통해 현재 로직에 어떤 문제가 있는지 짚어내는 것도 가능했다.

궁극적으로는 “그럴듯한 답변” 이 아니라 정확하고 신뢰 가능한 결과만을 사용자에게 제공하는 것에 가까워질 수 있었다.

10. 개선 방향

응답 정밀도 개선 전략 및 후속 개선 방향

랭체인톤 발표 후,
퍼실님의 피드백을 통해 얻은 인사이트로 개선 방향을 생각해 볼 수 있었다.

10.1  문제점: 성분 간 유사도와 우선순위 불일치

본 프로젝트는 RAG를 두 단계로 구성하여 사용자 질문에 대한 질의응답과, 이후 조건 기반 영양제 추천까지 모두 언어 모델 기반 유사도 검색을 활용하였다. 그러나 성분 간 유사성이 높은 상황에서는 벡터 유사도 기반의 정렬이 기대만큼 명확한 우선순위를 제공하지 못할 가능성도 있다.

유사한 효능을 지닌 성분들이 다수 존재할 때, 유사도 기반 검색이 실제 추천의 우선순위와 다르게 작동할 수 있으며 이 경우 정형화된 구조의 RDB(Relational Database)를 활용한 정렬 방식이 더 효과적일 수 있다. 향후에는 RAG 기반 추천과 RDB 기반 정렬의 성능을 비교하여 추천 정확도 및 사용자 만족도를 기준으로 하이브리드 구조 도입도 고려할 수 있다.

10.2  연구 근거 인용 기능 강화

사용자에게 "추천 성분" 또는 "피해야 할 성분"을 제시할 때, 해당 내용을 뒷받침하는 연구 결과나 임상 근거(논문, 가이드라인 등)를 함께 제시하면 정보의 신뢰도와 전문성이 한층 높아질 수 있다. RAG의 응답 결과에 논문 출처 또는 핵심 문장을 인용하는 기능을 추가하거나, 근거 기반 요약 기능을 보완하는 방향으로도 개선이 가능하다.

11. 프로젝트 회고

🔗  다음 글

💊 영양제 Check! 프로젝트 회고