[SKALA] 대화형 STT AI 기반 상품 추천 시스템, 개발과 회고

프로젝트 개요

약 3일간 진행된 단기 팀 프로젝트로, TTS(Text-to-Speech)와 STT(Speech-to-Text) 기술을 활용해 AI와 관련된 주제를 자유롭게 설정하고 구현했다.
정해진 문제 없이 기술 주제만 제시된 상태에서 각 팀이 아이디어를 도출하고 기획부터 개발까지 전 과정을 자율적으로 진행했다.
해커톤 형식에 가까운 방식으로, 짧은 시간 동안 집중적으로 협업하며 실질적인 결과물을 만들어내는 데 중점을 두었다.

주제 선정

먼저 팀원들이 각자 시간을 갖고 아이디어를 구상한 뒤, 모여서 브레인스토밍을 진행했다. 각자의 아이디어를 공유하고 자유롭게 의견을 나누는 방식으로, 다양한 가능성을 검토할 수 있었다.
브레인스토밍 결과 크게 세 가지 방향의 아이디어가 도출되었다.

1. 의료 현장에서의 외국인 환자와의 음성 기반 소통 지원 서비스
   의사나 간호사가 상태가 좋지 않은 외국인 환자와 마주했을 때, 손을 자유롭게 사용할 수 없는 상황에서는 말로만 의사소통을 해야 한다. 이때 언어 장벽이 큰 문제가 되기 때문에, 의료 분야의 필수적인 외국어 표현을 학습한 AI가 음성 기반으로 의사소통을 중재해주는 서비스.
2. 대화 요약 및 목적·감정·향후 흐름 예측 서비스
   사람 간의 대화를 AI가 분석해, 이 대화가 어떤 목적에서 시작되었고, 말하는 사람의 감정은 어떤 상태이며, 향후 어떤 방향으로 진행될 가능성이 높은지를 요약하고 예측하는 서비스.
3. 회의 대화 요약 및 과거 회의 학습 기반 문서화 지원 서비스
   실시간 회의 내용을 요약하는 동시에, 과거 회의 내용을 학습한 AI가 맥락을 이해하고 더욱 구조적이고 체계적인 요약본을 제공해주는 서비스.

 

판단 기준

아이디어를 평가할 때는 다음과 같은 기준을 적용했다.

• 이해관계자의 설정 및 분석: 서비스의 잠재 사용자와 그들의 필요를 얼마나 잘 정의하고 반영할 수 있는가.
• 현실 적용 가능성: 실제 서비스로 구현될 수 있을 정도로 현실적인가.
• 수요 타당성: 이해관계자 입장에서 이 서비스를 진짜 필요로 할까?

이 기준에 따라 각 아이디어를 검토한 결과는 다음과 같다.

• 1번 아이디어는 매우 구체적이고 필요한 상황이 존재하지만, 의료기관이라는 특수한 환경과 보수적인 조직 문화를 고려할 때 실제 도입까지 이어지기 어렵다고 판단했다.
• 2번 아이디어는 흥미롭고 가능성이 높았지만, 구체적인 서비스 시나리오가 추가적으로 필요했다.
• 3번 아이디어는 이미 유사한 서비스들이 시장에 많이 나와 있어, 차별점을 명확히 하기 위한 전략이 필요했다.

 

최종 주제 선정

최종적으로는 2번 아이디어를 발전시킨 형태로 주제를 선정하게 되었다.
은행이나 보험 상담과 같은 고객 응대 상황에서, 대화 내용 속 키워드를 분석하여 고객이 관심을 갖고 있는 상품의 방향성을 파악하고, 상담사에게 적절한 상품 추천과 응대 멘트를 제시하는 서비스다.
이를 통해 상담사는 고객의 니즈를 더 빠르고 정확하게 파악할 수 있으며, 실제 상품 가입으로 이어질 확률을 높일 수 있다.
또한 이 서비스는 단순한 요약을 넘어 의도 파악과 예측까지 가능하다는 점에서, 기존의 요약 서비스들과 차별화된다는 강점이 있다.
 

서비스 설계

 

1. 고객 정보 입력

서비스 초기 화면에서 사용자를 기존 고객과 신규 고객으로 분류한다.
기존 고객의 경우, 데이터베이스를 조회하여 이전에 등록된 고객 정보를 불러오고, 이를 기반으로 이후 예측 및 추천에 활용한다.
신규 고객은 기본적인 인적 사항을 입력하며, 이 정보는 모델이 개인화된 추천을 수행하는 데 사용된다.
 

2. STT : 상담사와 고객의 발언 구분

고객과 상담사 간의 실시간 대화를 음성에서 텍스트로 변환한다.
이 과정에서 화자 구분을 통해 누가 어떤 발언을 했는지를 명확하게 구분하여 이후 분석의 정확도를 높인다.
 

3. 생성형 AI : 대화 분석기

STT를 통해 텍스트화된 대화를 생성형 AI(LLM)에 전달한다.
모델은 전체 대화를 요약하고, 고객이 어떤 목적을 가지고 있는지, 어떤 키워드와 주제를 중심으로 이야기하고 있는지를 분석한다.
이를 통해 고객의 니즈와 관심사를 보다 정밀하게 파악할 수 있다.
 

4. 예측형 AI를 통한 상품 추천 : 학습 모델

고객 정보와 대화 분석 결과를 기반으로, 사전에 학습된 예측형 AI 모델이 해당 고객에게 적합한 상품을 추천한다.
이 모델은 실제 보험 상품 가입 데이터를 학습하였으며, 주요 학습 피처로는 고객의 나이, 성별, 결혼 여부, 직업, 소득 수준, 기존 보험 가입 개수, 대화 목적, 최종 가입 상품 등이 있다.
이를 통해 고객의 상황과 니즈에 가장 부합하는 상품을 도출한다.
 

5. RAG + LLM : 추천 멘트 생성

예측형 AI로부터 추천된 상품 정보를 바탕으로, RAG 방식과 LLM을 활용하여 상담 멘트를 생성한다.
DB손해보험의 상품 설명서를 벡터 DB에 저장해 두고, 고객과의 대화에서 추출한 핵심 키워드를 입력값으로 활용하여 해당 상품의 강점을 효과적으로 강조할 수 있는 맞춤형 멘트를 생성한다.
이로써 상담사는 고객에게 더욱 설득력 있는 설명을 제공할 수 있게 된다.
 

개발

이번 프로젝트에서 나는 전체 개발 환경 세팅과 RAG + LLM 기반 추천 멘트 생성 모듈 개발을 담당했다.

개발 환경 세팅

팀 내 일부 팀원들이 Git 협업 환경에 익숙하지 않아, 이번 기회를 통해 Git 기반 협업 경험과 Git Flow 전략을 실습해볼 수 있도록 개발을 진행했다.
프로젝트 저장소는 GitHub에 구성하였고, 기능 브랜치 개발 → PR 리뷰 → 병합이라는 Git Flow를 기반으로 작업 프로세스를 설계했다.
단순한 로컬 테스트 환경이 아니라, PR이 병합되면 자동으로 배포까지 이루어지는 구조를 만들고자 했다.
이를 위해 GitHub Actions를 활용한 CI/CD 파이프라인을 구성하고, 코드가 main 브랜치에 병합되면 자동으로 Docker 기반으로 패키징되어 AWS EC2에 배포되도록 설정했다.
또한 Nginx를 리버스 프록시 서버로 구성하여, API 서버와 프론트엔드를 분리하고 외부 접근을 안정적으로 제어할 수 있도록 설계했다.
이러한 구조를 통해 단순 개발 환경이 아닌 운영 환경에 가까운 시스템 아키텍처를 구현할 수 있었다.
더불어, 고객 정보 및 상담 이력 데이터를 안정적으로 관리하기 위해 AWS RDS를 도입하여 관계형 데이터베이스를 구축했다.
고객 정보는 RDS에 저장되고, 예측형 AI 및 추천 로직에서 해당 데이터를 실시간으로 조회하여 개인화된 추천 결과를 생성할 수 있도록 연동하였다.
 

RAG + LLM 모듈 개발

추천 멘트를 생성하는 핵심 모듈인 RAG + LLM 부분은 다음과 같은 절차로 개발하였다.
먼저, DB손해보험의 상품 설명서를 분석한 결과 대부분 PDF 형식으로 되어 있었고, 많은 부분이 표 형태로 구성되어 있었다.
일반적인 텍스트 추출 도구는 표 구조를 잘 인식하지 못해, 정확한 정보 추출을 위해 pdfplumber 라이브러리를 사용하였다.
이 도구는 표 형태의 데이터를 비교적 잘 보존한 채로 텍스트를 추출할 수 있어, 필요한 상품 설명 정보를 정확히 가공할 수 있었다.
텍스트 데이터는 OpenAI의 text-embedding-3-small 임베딩 모델을 이용하여 벡터화하였고, 벡터 저장소는 Pinecone을 선택하여 구성하였다.
문서 삽입 시, 상품명, 카테고리 등의 메타데이터를 함께 저장해두어, 추후 검색 시 필터링 조건으로 활용할 수 있도록 설계했다.
RAG 기반 검색 과정에서는 고객과 상담사의 대화 내용에서 추출한 주요 키워드와 관심사를 쿼리로 사용하여, 관련 있는 상품 설명 내용을 벡터 DB에서 찾아왔다.
이후 검색된 내용을 기반으로 LLM에 프롬프트를 구성하여, 해당 고객에게 적합한 상품을 어떻게 설명하면 좋을지에 대한 맞춤형 추천 멘트를 생성하도록 했다.
 

서비스 화면

 

트러블 슈팅 과정

1. .env 파일 EC2로 이동 시 경로 설정 문제

CI/CD 과정에서 .env 파일을 EC2 서버로 복사할 때, source 경로와 target 경로가 명확하게 지정되지 않아 환경 변수 로딩에 실패하는 문제가 발생했다.
이를 해결하기 위해 GitHub Actions 워크플로우 내에서 .env 파일을 정확하게 복사하도록 경로를 수정하였다.
앞으로는 환경 변수 파일 위치가 정확히 일치하는지 배포 전 꼭 확인해야겠다.

2. Docker 설정 및 이미지 교체 시 충돌 문제

코드가 Docker 컨테이너로 배포될 때, 최신 코드가 반영되지 않는 현상이 있었다.
이는 기존에 실행 중이던 컨테이너를 종료하거나 제거하지 않고 새 이미지를 실행하려다 발생한 문제였다.
배포 시 기존 컨테이너를 stop → remove하고, 사용하지 않는 이미지나 캐시를 삭제한 후 새 이미지를 pull하고 재실행하는 로직이 필요하다는 점을 실감했다.
자동화 스크립트나 GitHub Actions 워크플로우 내에 이러한 절차를 반드시 포함시켜야 한다는 점을 배웠다.

3. requirements.txt 관리 및 모델 호환성 문제

협업 중 패키지를 추가했음에도 requirements.txt 파일을 최신화하지 않아, EC2에서 서버 실행 시 패키지 누락 오류가 발생했다.
작업 후 항상 pip freeze > requirements.txt로 패키지를 갱신하는 습관이 필요하다는 것을 다시 느꼈다.
또한, whisper 라이브러리에서 사용하는 numpy 버전과, pickle로 저장된 예측 모델이 요구하는 numpy 버전이 달라 모델 로딩 시 오류가 발생했다.
결국 예측 모델만 별도의 서버로 분리하여 배포하는 방식으로 문제를 해결했다.
이번 경험을 통해 Python 환경에서는 라이브러리 버전 관리가 얼마나 중요한지, 그리고 모델을 저장할 때부터 실행 환경을 염두에 두어야 한다는 점을 배웠다.

4. Nginx 설정 적용 후 재시작 누락

EC2 서버에서 Nginx를 리버스 프록시로 설정한 후에도, 설정 변경 사항이 적용되지 않아 당황했던 경험이 있었다.
이유는 설정 파일을 수정한 뒤 재시작 명령을 누락했기 때문이었다.
이후부터는 nginx -t 명령어로 문법 오류를 먼저 확인한 뒤, sudo systemctl restart nginx 명령으로 안전하게 서버를 재시작하는 절차를 반드시 따르게 되었다.

5. CI=false npm run build 누락

프론트엔드 빌드 시, 사용되지 않는 import 문 등 사소한 경고가 에러로 처리되며 빌드가 실패하는 문제가 있었다.
처음에는 문제가 무엇인지 몰라 시간을 허비했지만, 이는 Create React App의 기본 CI 설정 때문이라는 것을 알게 되었다.
해결 방법은 단순했다. CI=false npm run build 명령어를 사용하여, CI 환경에서도 경고를 무시하고 빌드를 진행하도록 설정하였다. 다음부터는 자동화된 빌드 환경에서는 해당 옵션을 반드시 추가해야겠다.
 

느낀 점

해결해보는 소중한 경험을 할 수 있었다.
특히 처음부터 끝까지 CI/CD, Docker, Nginx, Python 모델 배포, 프론트엔드 빌드 등 전체 개발 및 배포 파이프라인을 스스로 구성하면서, 평소 공부해왔던 내용을 실제로 활용할 수 있었다는 점이 인상 깊었다.
GitHub Actions, Docker, RDS, Nginx 등 여러 도구들을 유기적으로 연결해 하나의 흐름을 만드는 과정에서, 각 도구의 역할과 경계, 그리고 전체적인 시스템 아키텍처에 대한 감각도 한층 더 명확해졌다.
무엇보다 이번 경험을 통해 가장 크게 느낀 점은, “사소해 보이는 설정 하나가 전체 시스템 동작에 치명적인 영향을 줄 수 있다”는 것이다.
.env 파일의 경로, 컨테이너 종료 누락, 패키지 버전 미관리, Nginx 재시작 누락 등, 사소해 보이는 실수들이 실제 배포에서 문제를 일으키는 상황을 반복하며, 하나만 틀어져도 전체 시스템이 정상 작동하지 않을 수 있다는 사실을 뼈저리게 느꼈다.
다음에는 이 경험을 바탕으로 더 빠르고 정확하게 개발 환경을 구성할 수 있을 것이라 생각한다.