[EATceed] CH04. 돌고 돌아 마침내 정식 출시까지

최종 출시 버전

<Google Playstore: EATceed>

 

여러 번의 수정과 방향 전환을 거쳐 2월 8일에 드디어 EATceed 서비스를 구글 플레이스토어에 정식 출시했다!👏

이전 글에 작성했듯이 EATceed는 기존 시장 트렌드인 체중 감량과는 반대로, 저체중 사용자를 위한 체중 증가 앱이라는 독특한 목표로 시작했다. 사실 이는 팀원 모두가 체중 증량에 관심이 있었기에 “우리가 직접 사용해보자”라는 의도로 기획이 이루어졌다.

 

초기 Version 1에서는 챗봇 중심의 음식 추천을 구현했고, 이를 위해 GPT-3.5-turbo 모델에 Fine-Tuning까지 시도했는데 동아리 발표회 후 얻은 사용자 피드백과 팀원들과의 의논 끝에 서비스에서 “현재 서비스와 챗봇이 잘 어울리지 않는다”라는 결론에 도달했다. 

 

이후 Version 2에서는 음식 이미지 판별을 통한 등록 자동화와 개인 맞춤형 식단 분석으로 기능을 변경했고, UI/UX 역시 사용자 친화적으로 개선했다.  음식 이미지 판별 기능같은 경우 원래는 AI Hub에 있는 음식 분류 모델을 이용할 계획이었지만 다음과 같은 문제가 발생했다. 

1. 클라우드 서버에서 모델 구동 비용이 많이 나온다.(GPU와 인프라 비용 제약사항)
2. 이미지 내 여러 음식을 판별하지 못하고, 정확도가 낮다.

또한, 해당 모델을 구성해준 팀원이 개인 사정으로 빠지면서 EATceed의 AI 기능 개발을 홀로 담당하게 되었다. 이러한 어려움을 해결하기 위해 OpenAI API로 모든 기능을 구현하게 되었다.

 

• CH01. Version01 회고록
• CH02. 프로젝트 소개

 

아키텍처 및 주요 기능

<EATceed Architecture>

 

EATceed의 아키텍처를 간단히 설명하자면 AWS 환경 내에서 Nginx를 게이트웨이로 사용하며 Spring Boot(프로젝트 전반적인 백엔드)와 FastAPI(AI 로직)를 각각 컨테이너를 실행하는 구조를 갖추고 있다. 개발(dev)과 운영(prod) 환경을 분리해 배포와 테스트를 독립적으로 진행하고 Nginx를 이용해 라우팅을 처리했다. 또한, 데이터 보안을 위해 Redis와 MariaDB를 Private Subnet에 배치하고 외부에서 접근을 위해 NAT 인스턴스를 사용했다. 여기서 내가 담당한 부분은 FastAPI 구성과 인프라 설계이다.

 

다음 포스팅에 AI 기능 및 데이터 자동화에 대한 자세한 내용을 다룰 예정인데 미리 소개하자면 다음과 같다.

첫 번째로 음식 이미지 판별 기능인 푸드렌즈이다.

<FoodLens API>

 

유저가 앱에 음식 이미지를 업로드 하면 멀티모달 처리가 가능한 OpenAI API(gpt-4o)를 통해 음식명을 얻고, 이를 VectorDB인 Pinecone에 미리 세팅해둔 음식명 목록과 비교해 유사도가 임계값을 넘는 상위 3개 음식명을 찾아낸다. 최종적으로 음식명과 이에 해당하는 PK를 반환해 주어 사용자가 편리하게 음식 등록(음식명 + 영양소 데이터)을 할 수 있도록 돕는 기능이다.

 

두 번째로는 일명 AI 영양사라고 불리는 식습관 분석 기능이다.

 

<AI Nutritionist API>

 

사용자의 신체 정보, 활동량 및 최근 일주일간의 식사 기록을 기반으로 매주 월요일에 분석을 진행하여 식습관 조언, 영양소 분석, 식사 개선점, 개인 맞춤 식단 추천을 제공하는 기능이다. 여기서 강조할만한 점은 첫 번째 기능인 푸드렌즈 API와는 달리 "생성된 답변이 과연 믿을만한가?"라는 의문점이 존재하여 이를 보완하기 위해 LLM의 답변을 LLM이 검토하는 G-Eval 방법론을 도입했고, 만약 특정 지표가 설정한 임계값에 도달하지 못하면 멀티 체인을 재수행한 뒤 이전 답변과 비교해 더 나은 답변을 제공하는 A/B 테스트 로직을 반영했다.

 

마지막으로는 데이터 엔지니어링 자동화, 즉 ETL 파이프라인 구축이다.

 

<ETL Pipeline>

 

공공데이터 포털에서 제공하는 전국통합식품영양성분정보(음식)표준데이터 API를 이용해 AWS EventBridge(Time-based)를 통해 매일 한 번 신규 데이터를 추출(Extract)한다. 만약 새로운 데이터가 존재한다면 변환(Transform)과정을 거친 뒤 Slack 알림을 발송하도록 설정했다. 이후 Google Sheets에서 결과를 검증하고 문제가 없으면 Slack 채널에서 Load 버튼을 클릭해 DB와 VectorDB에 음식 데이터를 자동으로 적재할 수 있게 구현했다. ETL 파이프라인이라고 했는데 엄밀히 말하면 ETvL(validate를 추가한 내가 지어낸 개념이다!)에 가깝다고 할 수 있다. 

 

<파이프라인 결과 화면>

 

아쉬운 점

기술적으로는 푸드렌즈 기능의 정확도를 상당히 끌어올려 목표치를 달성했다는 점이 만족스러웠지만, 조금 더 높은 정확도를 구현했다면 좋지 않을까라는 생각에 다소 아쉬움이 있다. 비즈니스적으로는 아쉬움이 훨씬 크다. 서비스 출시를 하면서 기쁜 마음이 크지만 초창기에 "우리에게 필요하니까 만들자"라는 가벼운 아이디어에서 출발한 탓에 실제로 저체중이라는 니치(niche) 사용자층을 어떻게 효과적으로 확보할지에 대한 구체적인 전략이 부족해서 사용자 확보가 어렵다고 생각한다. 이게 연결되어 명확한 수익 모델이 정립되지 않는다는 문제도 있다. 

그럼에도 불구하고 팀의 초기 목표였던 서비스 출시를 이뤄냈다는 점은 의미있는 성과라고 생각한다. 이번 프로젝트를 통해 사용자가 정말로 원하는 것과 사용자가 어떤 불편함을 겪고 있는지를 충분히 조사하고 기획하는 과정이 얼마나 중요한지를 알게 되었다. 앞으로의 프로젝트에서는 이러한 경험을 바탕으로 보다 철저히 사용자 니즈를 평가하고 비즈니스적인 관점까지 고려한 기획을 해야겠다고 생각했다.