RSS

그 챗봇 설계, 이름이 다 있습니다: 쿼리 라우팅부터 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이 필요하고 어디는 규칙과 쿼리로 충분한지가 드러나고, 그 지점이 곧 비용과 정확도가 결정되는 지점입니다.

새 용어가 쏟아지는 시기일수록, 오래된 이름들이 여전히 일을 잘한다는 사실이 좋은 나침반이 됩니다.