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

🔗  이전 글

💊 영양제 Check! 개발기

이번 프로젝트는 "영양제 추천 서비스 만들기" 가 아니라, LLM이 어떻게 더 신뢰성 있게 정보를 전달할 수 있을까에 대한 고민과 실험이었다고 할 수 있다.

'누가 먹어도 괜찮은 영양제' 같은 모호한 추천이 아니라, “이 사용자에게, 이 질환에 맞는, 이 성분이 왜 필요한가” 를 설명할 수 있는 시스템이 목표였다.

개인적으로는 도메인 이해, 구조 설계, 팀 협업, 프롬프트 튜닝, 실패 사례 복기까지 다방면에서 얻은 게 많은 프로젝트였다.

이 글에서는 그 과정에서 배우고 느낀 점들을 정리해 보려고 한다.

🖇  도메인 지식의 중요성과 전문성 확보의 필요성

기술만 잘 써서 좋은 결과가 나오는 건 아니라는 건 당연하다.

건강기능식품처럼 민감한 도메인에서는 단어 하나가 의학적으로 다른 의미로 해석되기 때문에, GPT가 아무 말이나 하는 경우에 이를 그대로 신뢰하면 안 된다.

예를 들어 “눈에 좋은 영양제 뭐 있어?” 라고 했을 때 나같은 경우에는 루테인 정도를 떠올릴 수 있었다. 하지만 도메인 조사와 시나리오별 신뢰할 수 있는 관련 학술 문헌들을 찾아보면서 실제로는 루테인, 지아잔틴, 비타민A, 아스타잔틴 등 다양한 성분이 있고, 각각의 작용 기전이 다르다는 것을 알 수 있었다.

게다가 당뇨 환자가 섭취하면 안 되는 성분도 있을 수 있고, 특정 약물과 상호작용이 발생하는 경우도 있어서 성분-질환-약물 간 관계를 모르면 그냥 위험한 추천이 될 수도 있다. 이런 부분은 결국 논문을 직접 보고, 근거를 확인하고, 정리하는 과정이 필요했다.

물론 RAG의 지식베이스가 되는 학술 문헌들을 찾는 과정이 쉽지 않았다. 해당 논문이 어떤 전제를 하고, 어떤 근거로, 어떤 결과를 냈는지 확인하고 실제 조사한 내용들과 비교하여 선정하는 과정에서 신중해야 했고 시간도 오래 걸렸다. 이 작업을 통해 성분 정보의 신뢰도가 완전히 달라질 수 있기 때문에 소홀히 할 수 없었다.

그냥 “GPT가 추천해줬대” 가 아니라, “이 논문에서 실제로 A 성분이 B 질환에 효과 있다고 보고했어” 라고 근거를 제시하는 시스템을 목표로 했기 때문이다.

이 프로젝트를 정말 고도화하고 싶다면 아예 당뇨, 치매, 고혈압 등 특정 질환에 중점을 두면 지금보다 더 신뢰할 수 있는 정보를 제공할 수 있을 것 같다는 생각이 들었다. 확실히 어떤 서비스든 관련 도메인을 깊게 알아야 경쟁력이 생긴다는 점을 다시 한 번 이해할 수 있었다.

🖇  학술 논문 기반 RAG에서의 프롬프트 엔지니어링 어려움

잎서 언급한 것처럼 RAG의 지식베이스로 사용할 학술 논문을 선정하는 것에도 어려움이 있었지만, 진짜 힘들었던 건 여기부터였다.

논문 PDF를 벡터화하는 건 어렵지 않은데, 문제는 LLM이 거기서 제대로 된 답을 끌어오게 만드는 과정이었다.

단순히 질문하면 원하는 성분이 바로 딱 나오는 게 아니었던 터라 아래와 같은 고민이 계속 반복됐다.

• 문서 chunk를 어떻게 나누면 정보 손실 없이 분할될까?
• 각 chunk에 어떤 메타 정보를 넣어야 필터링과 응답이 정확해질까?
• 프롬프트 안에 어떤 조건을 넣어야 환각 없이 응답하게 만들 수 있을까?

특히 JSON 형태의 응답을 유도하는 게 쉽지 않았다.

"허용된 성분 외에는 말하지 마라", "형식은 JSON만 허용", "마크다운 금지" 같은 조건을 쭉 나열해도 종종 형식이 틀어졌다.

이런 경우는 파싱이 깨져버리기 때문에 응답을 어떻게 안정적으로 받을지에 대한 예외처리도 필요했다.

수동으로 확인해서 수정하기도 하고, 많은 시행착오가 있었지만 그 과정에서 놓치고 있던 부분을 다잡을 수 있었다.

프롬프트 엔지니어링은 내가 원하는 걸 요구하는 과정이 아니라, 문서 구조와 LLM 동작 방식을 함께 고려한 설계라는 것 !

🖇  TAVILY AI 적용 과정에서의 시행착오

초반에는 TAVILY AI를 사용해서 RAG를 구성해 보려고 했다.

실시간 검색도 되고, 웹 결과를 요약해서 보여주니까 뭔가 요긴할 것 같았는데 결론부터 말하면 이 프로젝트에는 맞지 않았다.

가장 큰 문제는 “출처가 신뢰할 만한가?” 였다.

논문이 아니라 블로그, 뉴스 기사 위주로 결과가 제공될 수 있는데 이런 정보는 챗봇이 답변할 근거로 삼기엔 너무 불안정하다. TavilyClient 는 원하는 도메인(PubMed, 식약처 등)을 지정하더라도 정확히 그 문서만 가져오진 못하고, 결국 AI가 요약한 결과를 출력하는 구조라 LLM 자체의 창작이 섞이게 된다.

우리 팀이 만들고자 한 건 논문 기반의 응답이었고, "왜 이 성분이 추천되는지" 를 출처까지 정리해서 설명할 수 있는 구조여야 했다. 결국 TAVILY는 실험용으로 써보는 데 그쳤고, 본 구현에서는 완전히 제외하게 되었다.

그래도 덕분에 프로젝트에서 설정한 방향과 목표에 적절한 구조는 어떤 것인지를 계속해서 상기하고 고민해 나갈 수 있었다.

🖇  시스템 설계와 사용자 경험 관점

이번 프로젝트를 기술 과시형 챗봇이 아니라 "진짜 쓸모 있는 서비스" 처럼 느껴지도록 하고 싶었다. 그러기 위해서는 사용자 경험(UX)을 고려한 설계가 필요했다.

성분을 뽑아주는 데서 끝나는 게 아니라,

• 어떤 성분을 추천하는지
• 왜 추천하는지
• 어떤 성분은 피해야 하는지
• 출처는 무엇인지
• 그 성분이 실제로 들어간 제품은 무엇인지까지

하나의 흐름으로 연결되어 있다는 점이 중요했다.

게다가 모든 결과는 출처가 있는 문서 기반이고, 최종 추천도 단순 응답이 아니라 실제 공공데이터에 있는 제품 목록에서 골라주기 때문에 "이걸 먹어볼까?" 라는 사용자 행동까지 자연스럽게 이어지는 것을 기대할 수 있었다.

Streamlit 기반으로 UI를 구성했는데, 프론트엔드가 과하지 않아서 오히려 더 깔끔했다. 전체 구조를 사용자 입장에서 체계적으로 연결할 수 있었던 점이 인상 깊었다.

다만, 시간의 한계로 구현하지 못했던 성분에 대한 출처 명시 부분에서는 고민이 좀 더 필요하다. 피드백 주신 것처럼 사용자에게 "추천 성분" 또는 "피해야 할 성분"을 제시할 때, 사용자 경험을 해치지 않도록 해당 내용을 뒷받침하는 연구 결과나 임상 근거를 함께 제시하는 것이 중요할 것 같다.

🖇  좋은 팀원과의 협업, 명확한 목표 설정

원활한 상호 소통으로 유능한! 팀원들과 함께하는 과정에서 많은 것들을 배울 수 있었다. 덕분에 여러 시행착오가 있었음에도 매끄럽게 진행될 수 있었다고 생각한다.

데이터톤에서는 놓쳤던, 프로젝트를 시작할 때부터 “무엇을 만들 것인가” 가 아니라 “왜 만들 것인가” 에 대한 합의가 있었다. 이 논의를 하는 동안, 어떤 프로젝트든 솔직하게 되돌아보고 회고하는 과정이 반드시 필요하다는 소소한 생각이 들었었다.

LLM 프로젝트는 "뭔가 똑똑해 보이는 챗봇을 만들자" 같은 흐름으로 갈 수 있는데, "건강 정보는 신뢰가 생명이다" 라는 명확한 문제의식을 바탕으로 출발했기 때문에 프롬프트 구조를 짤 때도, 데이터를 고를 때도, 기술 선택에 있어서도 모두 사용자 중심의 일관된 기준이 있었다.

아이디어 기획, 기술 조사, 논문 기반 문서 정제, 프롬프트 엔지니어링, 공공데이터 수집, RAG 구조 설계, UI 구성 등 서로가 맡은 파트를 책임감 있게 가져갔고, 필요한 순간엔 빠르게 공유하고 피드백을 주고받았다.

프로젝트 중 기능을 구현하다 보면 가끔 "내가 지금 이걸 왜 하고 있지?" 라는 의문이 들 때도 종종 있었는데, 이번에는 처음부터 끝까지 목적과 방향이 분명했기 때문에 동기부여가 계속 유지될 수 있었던 것 같다.

앞으로도 어떠한 프로젝트에서 뿐만 아니라
무엇을 하는지 보다, 왜 하는지를 끊임없이 생각하는 자세를 지니자.

🖇  배운 점과 앞으로의 각오

이제는 궁금한 게 생기면 일단 GPT나 Gemini 같은 LLM에게 먼저 묻는 게 자연스러울 정도로, 누구나 쉽게 정보에 접근할 수 있는 시대가 되었다.

이번 프로젝트를 하면서 이 지점에 대해 깊이 고민할 수 있었다.

    "LLM이 답변해준 정보가 정확한가?"
    "그 근거는 무엇인가?"
    "사용자가 스스로 검토할 수 있는 구조인가?"

이런 질문에 대해 기술적으로만 접근하는 게 아니라, 전체 구조와 설계의 문제로 확장할 수 있었다.

물론 RAG 구조를 처음부터 직접 설계하고, 프롬프트를 반복해서 튜닝하고, 논문 중심의 도메인을 설계하고, Streamlit으로 UI를 구성하고, 식약처 공공 API까지 연동하는 과정에서 기술적으로도 좋은 경험이 되었다.

구현하고 테스트하는 과정에서 계속 나를 따라다녔던 의문이 있었다.

    “이 시스템을 과연 사용자가 믿고 쓸 수 있을까?”

겉보기엔 그럴듯하게 작동하는 챗봇이지만

정작 그 안에서 사용자가 출처를 확인할 수 없다거나, 논문 기반이 아닌 내용을 생성해버린다거나, 같은 질문에 따라 답이 바뀐다면 그건 신뢰할 수 있는 시스템이 아닐 것이다.

그래서 이번 프로젝트에서는 그런 허점을 막기 위해 하나하나 설계를 조이고, 근거를 명시하고, 정보가 ‘떠도는 말’이 아니라 ‘출처 있는 지식’이 되도록 만드는 데 초점을 맞추게 되었다. 프로젝트를 되돌아보면 기술보다 설계가 중요했고, 설계보다 문제 정의가 더 중요했다고 정리할 수 있겠다.

앞으로 다가올 해커톤이나 프로젝트에서도 그럴듯한 AI가 아니라
진짜 도움을 주는, 그리고 검증 가능한 구조로 신뢰를 줄 수 있는 AI 서비스를 만들고 싶다.

약 3일 간의 짧은 프로젝트였지만 유익한 경험이 되었다.