RAG, 들어는 봤는데... 내 서비스엔 어떻게 쓰지? #우아콘2025 #우아한형제들

우아한테크·우아콘 2025 2025·7개월 전·

#embedding#prompt-engineering#llm-evaluation#retrieval-augmented-generation#spring-ai#vector-database

AI 요약

database·Google Drive·Calendar에 흩어진 비공개 교육 운영 정보를 자연어로 조회하는 server를 사례로, RAG가 정말 필요한 조건과 production 구현 절차를 단계별로 설명한다. MCP 접근의 한계에서 출발해 요구사항 정의부터 indexing·retrieval·generation·평가까지 선택 기준을 제시한다.

핵심 포인트

교육 data가 여러 system에 나뉘어 사용자가 관계를 직접 해석하던 문제를 자연어 통합 검색으로 풀되, 지원 client 의존·local 실행의 격리 network 접근 불가·반복 tool call로 커지는 context window 때문에 MCP 대신 내부 network의 독립 RAG server로 전환
비공개·상시 갱신·근거 기반 정확성 요건을 점검해 단순 prompt보다 RAG가 맞는지 먼저 판단하고, 검색 5분→30초·방문 3회→1회 같은 측정 가능한 목표를 세운 뒤 최고 기능보다 team의 Java 경험·배포·logging을 우선해 LangChain 대신 Spring AI 선택
고정 크기·parent-child chunking에 출처·시간 metadata를 붙여 1,024차원 embedding으로 Redis vector store에 적재하고, context relevance·faithfulness·answer relevance 세 축을 평가 LLM과 human·ground-truth로 반복 측정하며 작은 변경에도 전체 평가를 재수행

왜 읽나RAG 도입 여부부터 framework·chunking·embedding·평가까지 production 관점의 판단 기준이 필요한 백엔드 엔지니어에게 결정 체크리스트가 담긴 실전 가이드.

챕터별 상세

011:20 – 5:40

Query와 context의 결합을 자동화하는 RAG

LLM의 학습 data에 없는 개인 일정과 최신 전문 지식은 context를 함께 주지 않으면 hallucination을 만들지만, 질문마다 올바른 file을 사람이 골라 넣으면 query-context 결합도가 커진다. RAG는 질문에 맞는 자료를 knowledge base에서 자동 검색해 LLM에 통합하며, 문서를 검색 가능하게 만드는 indexing, 답을 만드는 generation과 품질을 측정하는 evaluation으로 범용 model을 domain 전문 assistant로 확장한다.

교육생·자료·일정이 database, Drive와 Calendar에 나뉘어 사용자가 여러 system을 방문하고 관계를 직접 해석해야 했으므로 한 browser에서 자연어로 묻는 통합 검색을 목표로 삼았다. 기존 MCP server는 모든 사용자가 지원 client와 연동법을 알아야 하고 local 실행으로 격리 network에 접근하지 못했으며, 반복 tool call과 pagination이 context window와 latency를 키워 내부 network의 독립 RAG server로 전환했다.

비공개·상시 갱신 정보, 근거 기반 정확성과 출처 필요성을 점검해 단순 prompt보다 RAG가 맞는지 먼저 판단하고, 검색 시간을 5분에서 30초로 줄이며 system 방문을 세 번에서 한 번으로 줄인다는 측정 가능한 목표를 세웠다. Query 90%를 30초 안에 답하고 개인정보 masking·접근 제어를 제공한다는 requirement를 정한 뒤, 최고 기능보다 team의 Java 경험·배포 platform·logging 생산성을 우선해 LangChain 대신 Spring AI를 선택했다.

Database·Drive·Calendar의 JSON·text·XML을 loading하며 개인정보와 중복을 정리하고, 고정 크기와 parent-child 구조로 chunk를 나눠 출처·시간·구조 metadata를 함께 저장한다. Foundation embedding model의 기본 1,024차원을 먼저 검증하고 Redis vector store에 적재하며, chunk 크기의 문맥 손실과 검색 성능, embedding 차원의 품질·비용, managed hosting과 data expiry를 domain 요구에 맞춰 조절한다.

질문을 LLM으로 검색에 적합하게 정리한 뒤 contextual embedding과 metadata filter로 유사 chunk를 가져오고, 검색 자료로만 정해진 형식에 답하라는 persona·constraint를 prompt에 넣어 foundation model이 응답하게 한다. 검색 context가 질문과 맞는 context relevance, 답이 근거에 충실한 faithfulness, 답이 질문을 해결하는 answer relevance를 별도 evaluation LLM과 human·ground-truth sample로 반복 측정하며, indexing이나 prompt의 작은 변경도 전체 평가를 다시 수행한다.