그 챗봇 설계, 이름이 다 있습니다: 쿼리 라우팅부터 Agentic RAG까지
왜 이 주제가 중요한가
지난 글(챗봇이 목록을 자꾸 틀린다면: 생성이 아니라 조회를 시키세요)에서 "재고 질문은 LLM이 아니라 DB가 답하게 하라"는 구조를 소개했습니다. 그런데 이 구조, 저희가 발명한 게 아닙니다. 부품 하나하나에 이미 정식 이름이 있고, 수십 년 된 것도 있습니다.
이름을 아는 것은 생각보다 실용적입니다. 이름을 알면 검색이 되고, 검색이 되면 선행 사례와 라이브러리와 함정 목록이 따라옵니다. 개발사와 대화할 때도 "챗봇이 똑똑했으면 좋겠어요"보다 "정형 질문은 라우팅으로 빼주세요"가 훨씬 빠릅니다. 이번 글은 그 부품들의 이름표입니다.
핵심 개념: 부품별 이름표
쿼리 라우팅 (Query Routing)
질문을 성격에 따라 서로 다른 처리 경로로 보내는 관문입니다. "재고 질문 → DB 조회", "지식 질문 → RAG"처럼 갈림길을 만드는 것. LLM 애플리케이션 설계에서 라우터 패턴이라고 부르며, 라우팅 판정을 규칙으로 하면 결정적(항상 같은 판정), 모델로 하면 유연하지만 확률적이 됩니다.
인텐트 분류 + 슬롯 필링 (Intent Classification + Slot Filling)
챗봇 자연어 이해(NLU)의 고전 기법입니다. 문장에서 의도(재고 조회)를 판별하고, 실행에 필요한 파라미터(위치=이케아 철재장)를 슬롯에 채웁니다. 시리, 알렉사, 콜센터 봇이 전부 이 구조 위에 서 있습니다. LLM 시대에도 사라진 게 아니라, "슬롯을 채우는 도구"가 정규식에서 LLM까지 넓어졌을 뿐입니다.
NLIDB와 Text-to-SQL
자연어로 데이터베이스에 질의하는 분야를 NLIDB(Natural Language Interface to Database)라고 합니다. 요즘 유행하는 Text-to-SQL은 그 최신형으로, LLM에게 SQL 문장 자체를 짜게 합니다. 강력하지만 모델이 잘못된 쿼리를 만들 위험이 함께 옵니다. 대안은 쿼리를 코드에 미리 고정해 두고 슬롯 값만 끼우는 방식입니다. 표현력은 낮지만 잘못된 쿼리가 원천적으로 불가능해서, 사내 데이터에는 이쪽을 먼저 검토할 가치가 있습니다.
툴 유즈 / 함수 호출 (Tool Use / Function Calling)
LLM이 답을 "말로 지어내는" 대신 계산기·검색·DB 조회 같은 도구를 호출하게 하는 패턴입니다. 상용 LLM API들이 표준으로 지원합니다. 지난 글의 구조는 이것의 결정적 변형입니다. 어떤 도구를 쓸지 모델이 아니라 규칙이 정하고, 도구 실행 결과를 모델이 다시 만지지 않게 한 것. "모델이 데이터를 거치지 않으므로 틀릴 수 없다"는 성질이 여기서 나옵니다.
거제티어 매칭 (Gazetteer / 사전 기반 개체 인식)
거제티어는 지명 사전이라는 뜻의 고전 용어로, 미리 가진 이름 목록(위치명 111개)과 문장을 대조해 개체를 찾는 기법입니다. 머신러닝 개체명 인식(NER)보다 촌스러워 보이지만, 사전이 곧 우리 DB인 사내 시스템에서는 오히려 정답에 가깝습니다. 사전에 없는 건 어차피 조회할 수 없으니까요.
퍼지 매칭과 편집 거리 (Fuzzy Matching, Levenshtein Distance)
"철제장"이라고 쳐도 "철재장"을 찾아주는 오타 흡수 기법입니다. 편집 거리는 한 문자열을 다른 문자열로 바꾸는 데 필요한 최소 수정 횟수(삽입·삭제·교체)로, 거리 1~2까지 허용하면 표기 흔들림 대부분이 잡힙니다. 1965년에 나온 알고리즘이 2026년 챗봇에서 여전히 일합니다.
Agentic RAG / Hybrid RAG
검색-생성 일변도의 기본 RAG에서 벗어나, 라우팅·도구 호출·다단계 판단을 섞은 구조를 묶어 부르는 최신 용어입니다. 위 부품들을 조립한 결과물에 붙는 상표명 정도로 이해하면 됩니다. 이 이름으로 검색하면 프레임워크와 사례가 쏟아지지만, 알맹이는 결국 "무엇을 모델에게 시키고 무엇을 시스템에 시킬 것인가"라는 설계 문제입니다.
실제 적용 포인트: 용어 → 코드 대응표
지난 글의 재고 챗봇을 부품 이름으로 다시 읽으면 이렇게 됩니다.
| 동작 | 부품 이름 |
|---|---|
| "재고 질문인가?"를 판별해 경로를 가른다 | 쿼리 라우팅 + 인텐트 분류 |
| 질문에서 "이케아 철재장"을 찾아낸다 | 슬롯 필링 (거제티어 매칭) |
| "철제장" 오타를 흡수한다 | 퍼지 매칭 (편집 거리) |
| 위치로 아이템을 조회한다 | NLIDB (고정 쿼리 방식) |
| 조회 결과로 표를 만든다 | 결정적 도구 실행 (툴 유즈의 변형) |
| 전체 구조의 통칭 | Hybrid / Agentic RAG |
설계 회의에서 이 표의 왼쪽 열로 말하면 서로 다른 그림을 그리기 쉽지만, 오른쪽 열로 말하면 검색 가능하고 오해가 적은 공통어가 됩니다.
주의할 점
- 용어는 수단이지 목적이 아닙니다. "Agentic RAG 도입"이 목표가 되는 순간 배가 산으로 갑니다. 문제(목록이 자꾸 틀린다)에서 출발해 부품을 고르는 순서가 맞습니다.
- Text-to-SQL은 매력적이지만 권한 설계가 먼저입니다. 모델이 만든 쿼리가 DB에 그대로 닿는 구조라면, 읽기 전용 계정·테이블 화이트리스트·쿼리 검증 없이 운영에 두면 안 됩니다.
- 고전 기법을 무시하지 마세요. 슬롯 필링과 거제티어는 LLM 이전 시대 기술이지만, 결정적이고 빠르고 공짜입니다. LLM은 이것들이 못 잡는 롱테일에만 쓰는 게 비용·정확도 모두에서 이득입니다.
듀오랩스가 보는 관점
AI 기능 상담을 하다 보면 "챗봇" 한 단어 안에 전혀 다른 열 가지 요구가 들어 있는 경우가 많습니다. 저희가 하는 일의 절반은 그 요구를 위 부품 이름으로 분해하는 것입니다. 분해가 되면 어디에 LLM이 필요하고 어디는 규칙과 쿼리로 충분한지가 드러나고, 그 지점이 곧 비용과 정확도가 결정되는 지점입니다.
새 용어가 쏟아지는 시기일수록, 오래된 이름들이 여전히 일을 잘한다는 사실이 좋은 나침반이 됩니다.
우리 서비스에 적용할 계획이 있으신가요?
AI 챗봇·업무 자동화 살펴보기 →함께 읽기
- 에이전트 RAG를 작은 모델로 짜는 법: 도구 선택은 코드가, 답은 모델이에이전트 RAG라는 말을 처음 들었을 때 떠올린 그림은, 모델이 스스로 판단해 도구를 부르는 거였습니다. "이 질문은 검색을, 이 질문은 DB 조회를" 모델이 결정하고, 그 결과를 받아 다시 답을 쓰는 구조. 그런데 막상 작은 로컬 모델로 이걸 짜려니 한 가지가 걸렸습니다. 도구를 고르는 결정을 모델에게 맡길 수가 없었…
- RAG 대표 기술 한눈에 보기: 검색부터 GraphRAG까지RAG(Retrieval-Augmented Generation)는 사용자의 질문과 관련된 외부 지식을 먼저 찾고, 그 근거를 언어 모델에 전달해 답변을 생성하는 방식입니다. 모델이 학습 과정에서 기억한 정보에만 의존하지 않으므로 조직의 최신 문서나 전문 자료를 답변에 반영하고 출처를 제시하기 좋습니다.
- 혼자 쓰는 RAG: 인증·권한을 빼고 남은 설계 결정들ChatGPT에 문서를 전부 올리면 끝나는 일 아닌가,라고 한동안 생각했습니다. 그런데 제가 쓰는 데이터를 전부 올리는 건 사정이 달랐습니다. 재고 목록, 영업 리드, 기도 기록, 가계부까지 한 사람의 전 삶이 들어있는 DB였거든요. 그래서 로컬 LLM 기반 RAG를 직접 짰습니다. 이 글은 그 과정에서 내린, 그리고 …
- 한국어 RAG에서 벡터만 쓰면 안 되는 이유: 하이브리드 검색 설계처음 RAG를 짤 때는 벡터 검색만 썼습니다. 코사인 유사도 하나로 충분할 줄 알았죠. 그런데 한국어 질문에서 이상한 일이 잦았습니다. 분명 문서에 있는 단어를 물었는데 검색이 안 됩니다. 비슷한 의미의 다른 문서만 계속 위에 뜹니다. 원인을 찾다 보니, 벡터 검색이 "의미가 비슷한가"는 잘 재는데 "그 단어가 실제로 …
- 운영에서만 AI 답변이 한 번에 나온다면, nginx가 스트림을 삼키고 있습니다챗봇 답변을 한 글자씩 흘려보내는 것은 기술적 과시가 아닙니다. 사람이 기다릴 수 있게 만드는 장치입니다. 같은 5초라도 빈 화면을 보는 5초와 글자가 차오르는 5초는 완전히 다른 시간입니다.