[커널아카데미] 백엔드 개발 부트캠프 12기 19주차

RAG 기반 부동산 AI 챗봇 프로젝트 회고: 문제 해결과 성장의 기록

1. 프로젝트를 돌아보며: 우리가 이뤄낸 것

이번 프로젝트의 목표는 단순히 정보를 검색하는 챗봇을 넘어, 사용자의 복잡하고 주관적인 의도를 파악하여 신뢰성 있는 답변을 제공하는 지능형 RAG 에이전트를 구축하는 것이었다. 수많은 기술적 도전과 시행착오 끝에, 우리는 안정적인 서비스와 고성능 AI 추론이라는 두 마리 토끼를 모두 잡는 성공적인 시스템을 완성했다. 이 회고는 그 과정에서 우리가 무엇을 잘했고, 어떤 어려움을 극복했으며, 무엇을 배웠는지 기록하기 위함이다.

2. 무엇을 잘했는가? (What Went Well)

1. 견고한 아키텍처 설계와 선택:
   • Spring Boot와 FastAPI의 역할 분리: 프로젝트 초기에 구상했던 **'안정성의 Spring Boot'**와 **'AI 전문성의 FastAPI'**라는 이중 백엔드 구조는 매우 성공적이었다. Spring Boot가 사용자 인증, 데이터 관리, 프록시 역할을 굳건히 지켜주었기에, FastAPI는 오롯이 AI 추론과 RAG 파이프라인 고도화에만 집중할 수 있었다. 이 아키텍처 덕분에 복잡한 문제들을 각 서버의 책임에 맞게 분리하여 해결할 수 있었다.
2. 사용자 경험(UX)을 최우선으로 고려한 기능 구현:
   • 실시간 스트리밍 프록시: AI의 답변 생성 시간을 기다리게 하는 대신, StreamingResponseBody와 StreamingResponse를 이용해 답변을 실시간으로 중계한 것은 '신의 한 수'였다. 사용자가 느끼는 체감 속도를 비약적으로 향상시켜, 긴 추론 시간이라는 LLM의 단점을 효과적으로 극복했다.
   • 가독성을 고려한 프론트엔드 포맷팅: 단순히 텍스트를 뿌리는 것을 넘어, JavaScript 단에서 각 항목(아파트명:, 가격: 등)을 정규식으로 파싱하여 자동으로 줄 바꿈과 여백을 추가했다. 이 작은 디테일이 최종 결과물의 완성도를 크게 높였다.
3. 체계적인 문제 해결 능력:
   • 오류의 근본 원인 추적: 우리는 수많은 에러를 마주쳤지만, 단순히 코드를 수정하는 데 그치지 않았다. ModuleNotFoundError를 통해 환경 설정의 중요성을, RateLimitError를 통해 API 사용량 관리의 필요성을, Git 충돌을 통해 협업 프로세스의 이해를, 그리고 잘못된 SQL 쿼리 로그를 통해 AI 에이전트의 동작 원리를 깊이 있게 파고들었다. 이러한 근본적인 접근 방식은 일시적인 해결이 아닌, 시스템 전체의 안정성을 높이는 결과로 이어졌다.

3. 어떤 어려움이 있었고, 어떻게 극복했는가? (Challenges & How We Overcame)

1. 초기 설정의 함정 (Initial Setup Challenges):
   • 문제점: 프로젝트 초반, dotenv 파싱 경고, DB 커넥션 타임아웃(AttributeError), 프롬프트 로딩 실패 등 환경 설정과 관련된 문제들로 많은 시간을 소비했다. 이는 애플리케이션의 핵심 로직 개발을 지연시키는 요인이 되었다.
   • 극복 과정: .env 파일의 문법을 바로잡고, pool_recycle 옵션으로 DB 커넥션 안정성을 확보했으며, 프롬프트 버전 관리의 중요성을 깨달았다. 이 과정을 통해 **"핵심 기능 구현 전, 안정적인 인프라와 환경 구성이 얼마나 중요한지"**를 체감했다.
2. AI 에이전트의 예측 불가능성 (AI Agent's Unpredictability):
   • 문제점: AI 에이전트가 "용마산역"을 주소 컬럼에서 검색하거나, 관련 없는 review_search_tool을 먼저 호출하는 등 예상과 다르게 동작하는 경우가 잦았다. 이는 잘못된 SQL 쿼리 생성과 검색 실패로 이어졌다.
   • 극복 과정: 문제의 근본 원인이 최적화된 프롬프트를 불러오지 못했기 때문임을 로그를 통해 밝혀냈다. 프롬프트 로딩 문제를 해결하고, AI에게 더 명확한 지시를 내리도록 프롬프트를 수정하면서 AI의 행동을 원하는 방향으로 유도하는 **'프롬프트 엔지니어링'**의 중요성을 실감했다.
3. 협업과 버전 관리의 복잡성 (Git Conflicts):
   • 문제점: 여러 기능 브랜치(feature/tools, feature/chat-ui-enhance 등)를 병합하는 과정에서 다수의 Git 충돌(Conflict)을 경험했다.
   • 극복 과정: stash를 활용해 작업을 안전하게 보관하고, merge와 rebase의 차이를 이해하며 충돌을 해결하는 과정을 직접 겪었다. 이는 단순히 Git 명령어를 아는 것을 넘어, 팀원과 함께 코드베이스를 건강하게 유지하는 협업의 본질을 배우는 계기가 되었다.

4. 무엇을 배웠고, 앞으로 무엇을 할 것인가? (Action Items & What I Learned)

• 배운 점:
  1. 로그의 가치: 모든 문제 해결의 실마리는 로그에 있었다. 에러 메시지뿐만 아니라, AI의 추론 과정(Entering new AgentExecutor chain...)과 SQL 쿼리 로그를 꼼꼼히 분석하는 것이 디버깅의 핵심임을 배웠다.
  2. 추상화 너머의 원리 이해: LangChain과 같은 프레임워크는 편리하지만, 그 내부 동작 원리를 모르면 문제 해결이 어렵다. 이번 프로젝트를 통해 RAG 파이프라인의 각 단계(Retrieve, Generate)와 AI 에이전트의 Tool Calling 메커니즘을 깊이 있게 이해하게 되었다.
  3. 아키텍처의 중요성: 왜 백엔드 서버의 역할을 분리해야 하고, 왜 프록시 패턴을 사용하며, 왜 비동기 처리가 중요한지 이론이 아닌 실제 경험으로 체득했다.
• 다음 목표:
  • 프롬프트 고도화: 현재의 프롬프트를 넘어, 사용자의 숨겨진 의도까지 파악할 수 있는 더 정교한 프롬프트 시스템을 연구하고 적용해보고 싶다.
  • 성능 모니터링 및 최적화: LangSmith와 같은 도구를 더 적극적으로 활용하여 각 도구의 실행 시간, LLM의 토큰 사용량을 정량적으로 분석하고, 비용과 성능을 최적화하는 작업을 진행하고 싶다.
  • 테스트 자동화: 현재는 기능 구현에 집중했지만, 향후 안정적인 운영을 위해 각 컴포넌트(Tool, Service)에 대한 단위 테스트 및 통합 테스트 코드를 작성하여 시스템의 신뢰도를 높이고 싶다.