그 챗봇 설계, 이름이 다 있습니다: 쿼리 라우팅부터 Agentic RAG까지
지난 글(챗봇이 목록을 자꾸 틀린다면: 생성이 아니라 조회를 시키세요)에서 "재고 질문은 LLM이 아니라 DB가 답하게 하라"는 구조를 소개했습니다. 그런데 이 구조, 저희가 발명한 게 아닙니다. 부품 하나하나에 이미 정식 이름이 있고, 수십 년 된 것도 있습니다.
지난 글(챗봇이 목록을 자꾸 틀린다면: 생성이 아니라 조회를 시키세요)에서 "재고 질문은 LLM이 아니라 DB가 답하게 하라"는 구조를 소개했습니다. 그런데 이 구조, 저희가 발명한 게 아닙니다. 부품 하나하나에 이미 정식 이름이 있고, 수십 년 된 것도 있습니다.
사내 데이터에 AI 챗봇을 붙이면 누구나 한 번쯤 이런 질문을 던지게 됩니다.
모바일 서명 파일이나 환경설정을 백업하다 보면 값 대부분이 Base64처럼 보일 때가 있다. 이때 가장 먼저 구분해야 할 사실이 있다.
사내 문서 RAG 챗봇처럼 비용을 아껴야 하는 환경에서는 작은 모델을 쓰게 됩니다. 그런데 작은 모델은 시스템 프롬프트의 금지 규칙을 자주 어깁니다. 이때 흔히 하는 대응이 프롬프트를 더 강하게 쓰는 것입니다. "절대 하지 마세요", "반드시" 같은 말을 덧붙이고, 예시를 추가하고, 규칙 번호를 매깁니다.
모바일 앱의 운영 환경을 정리하다 보면 Android Keystore, iOS 인증서, Provisioning Profile 같은 낯선 자격 증명을 만나게 된다. 이런 파일을 보고 있으면 새로운 컴퓨터에서 앱을 다시 빌드하는 일이 상당히 복잡할 것처럼 느껴진다.
Expo EAS를 사용하면 모바일 앱의 빌드와 스토어 제출을 자동화할 수 있다. 편리한 만큼 운영에 필요한 자격 증명이 여러 곳에 나뉘어 저장되기 때문에, 각각의 역할을 구분하지 않으면 토큰 하나만 보관하고도 백업이 끝났다고 생각하기 쉽다.
사내 문서를 근거로 답하는 RAG 챗봇을 도입하면 대부분 비슷한 지점에서 막힙니다. 첫 질문에는 그럴듯하게 답하는데, 이어서 "그럼 그건 언제 바뀐 거야?" 같은 질문을 던지면 갑자기 엉뚱한 문서를 근거로 들고 옵니다. 사용자는 "AI가 헛소리를 한다"고 느끼고, 도입은 거기서 멈춥니다.
회사 사이트와 기술 블로그를 따로 운영하는 구성은 흔합니다. 회사는 duolabs.co.kr, 블로그는 blog.duolabs.co.kr.
RAG(Retrieval-Augmented Generation)는 사용자의 질문과 관련된 외부 지식을 먼저 찾고, 그 근거를 언어 모델에 전달해 답변을 생성하는 방식입니다. 모델이 학습 과정에서 기억한 정보에만 의존하지 않으므로 조직의 최신 문서나 전문 자료를 답변에 반영하고 출처를 제시하기 좋습니다.
문서는 많지만 필요한 순간에 찾기 어렵고, 검색 결과를 열어 일일이 내용을 비교해야 한다면 지식은 충분히 활용되지 못합니다. 이번 글에서는 문서와 업무 데이터를 자연어로 검색하고, 근거와 함께 답을 생성하는 RAG 시스템을 작은 범위에서 시작해 운영 가능한 구조로 확장한 과정을 정리합니다.