자사 제품을 자기 팀이 안 쓴다면 뭔가 잘못된 겁니다. LangChain 팀이 정확히 그 상황에 직면했죠. 지원 엔지니어들은 회사가 만든 AI 챗봇 대신 손으로 문서를 뒤지고 코드를 검색하는 걸 선호했습니다. 고장 나서가 아니라 충분하지 않았기 때문이었어요. 그래서 챗봇을 완전히 새로 만들었고, 그 과정에서 RAG 시스템 구축에 대한 중요한 교훈을 얻었습니다.

LangChain의 Liam Bush가 자사 챗봇을 재구축한 전 과정을 상세히 공개한 글입니다. 팀 내부에서조차 사용하지 않던 챗봇을 어떻게 실제로 유용한 도구로 바꿨는지, 벡터 임베딩의 한계를 발견하고 완전히 다른 접근법을 택한 이유를 설명합니다. 특히 상황에 맞게 두 가지 아키텍처를 선택하는 전략과, 서브그래프로 컨텍스트 폭발을 막는 방법이 핵심입니다.

출처: Why We Rebuilt LangChain’s Chatbot and What We Learned – LangChain Blog

팀이 자기 제품을 안 쓴 진짜 이유

지원 엔지니어들은 자신만의 3단계 워크플로를 만들었습니다. 먼저 공식 문서를 검색해서 기능이 어떻게 작동해야 하는지 확인하고, 지식베이스에서 다른 사용자들이 겪은 비슷한 문제를 찾아보고, 마지막으로 Claude Code로 실제 구현 코드를 열어서 진짜로 어떻게 작동하는지 확인했죠. 문서는 공식 설명용, 지식베이스는 실제 문제용, 코드베이스는 진실 확인용이었습니다.

팀은 이 패턴을 하루에도 수십 번 반복하는 걸 보고 생각했습니다. “이 워크플로를 그냥 자동화하면 되잖아?” 그래서 세 개의 전문 서브에이전트를 가진 Deep Agent를 만들었고, 엔지니어들은 매주 몇 시간씩 절약할 수 있었습니다.

벡터 임베딩을 버린 이유

그런데 누군가 질문했습니다. “이게 우리한테 잘 되는데, 왜 공개 버전은 이렇게 안 만들죠?” 공개 챗봇은 문서를 조각내서 임베딩하고 벡터 데이터베이스에 저장하는 전통적인 방식을 쓰고 있었거든요.

LangChain 팀은 구조화된 제품 문서에 대해 벡터 임베딩이 세 가지 문제를 일으킨다는 걸 발견했습니다.

청킹이 구조를 파괴합니다. 문서를 500토큰 조각으로 자르면 제목, 하위 섹션, 전후 맥락이 사라집니다. 예를 들어 “스트리밍 설정하기”라는 섹션의 중간 부분만 조각으로 잘리면, 에이전트는 “streaming=True로 설정하세요”라는 코드만 보고 답변하게 됩니다. 하지만 그 위의 설명(언제 필요한지)과 아래의 주의사항(어떤 경우 작동 안 하는지)은 다른 조각에 있어서 놓치게 되죠.

끊임없는 재인덱싱이 필요합니다. 문서는 하루에도 여러 번 업데이트되는데, 변경이 생길 때마다 다시 청킹하고 임베딩하고 업로드해야 했습니다.

인용이 모호합니다. 사용자는 답변을 검증하거나 정보의 출처를 추적할 수 없었습니다.

돌파구는 잘못된 문제를 풀고 있었다는 깨달음에서 왔습니다. 문서는 이미 조직화되어 있고, 지식베이스는 이미 분류되어 있으며, 코드베이스는 이미 탐색 가능합니다. 더 똑똑한 검색이 아니라 에이전트에게 기존 구조에 직접 접근할 수 있게 해주는 게 필요했던 거죠.

사람처럼 검색하는 에이전트

청킹과 임베딩 대신 LangChain 팀은 에이전트에게 실제 콘텐츠에 직접 접근하도록 했습니다. 문서는 Mintlify API를 통해 전체 페이지를 반환하고, 지식베이스는 먼저 제목으로 쿼리한 뒤 가장 유망한 것만 전체를 읽습니다. 코드베이스 검색은 ripgrep로 패턴 매칭하고, 디렉토리를 탐색하고, 파일을 읽어서 특정 구현을 추출하죠.

에이전트는 유사도 점수로 검색하지 않습니다. 사람이 하듯이 검색합니다 – 키워드, 개선, 추가 질문으로요.

여기가 마법이 일어나는 곳입니다. LangChain 팀은 에이전트에게 한 번만 검색하라고 하지 않습니다. 충분한 정보가 있는지 비판적으로 생각하도록 프롬프트를 작성했어요. 결과가 애매하거나 불완전하면 에이전트는 쿼리를 개선해서 다시 검색합니다. 사용자가 “에이전트에 메모리를 어떻게 추가하나요?”라고 물으면, 에이전트는 먼저 “memory”를 검색하고, 질문이 애매하다는 걸 깨닫고, “checkpointing”과 “store API”로 좁혀가며 최종적으로 두 가지를 모두 다루는 답변을 만듭니다.

빠름과 정확함 사이의 선택

LangChain 팀은 질문 유형에 따라 두 가지 아키텍처를 사용합니다.

간단한 문서 질문에는 Create Agent를 씁니다. 즉각적인 툴 호출과 답변만 있죠. 대부분의 문서 질문은 3-6회 툴 호출로 처리되고 Claude Haiku 4.5와 조합하면 15초 이내 응답이 가능합니다.

복잡한 조사가 필요한 질문에는 Deep Agent를 씁니다. 문서, 지식베이스, 코드베이스를 위한 전문 서브그래프가 있는 구조죠. 각 서브에이전트가 독립적으로 작동하면서 추가 질문을 하고 정보를 필터링한 뒤 가장 관련성 높은 인사이트만 메인 에이전트에 전달합니다. 이렇게 하면 메인 에이전트가 컨텍스트에 빠지지 않으면서도 각 도메인 전문가가 필요한 만큼 깊이 파고들 수 있습니다.

코드베이스 검색 서브에이전트가 특히 강력합니다. 패턴 매칭으로 저장소를 검색하고, 파일 구조를 탐색해서 맥락을 이해하고, 특정 구현을 줄 번호까지 정확히 읽을 수 있거든요. Deep Agent는 실행에 1-3분이 걸리지만 철저함이 그만한 가치가 있습니다.

서브그래프로 컨텍스트 폭발 막기

처음에는 메인 에이전트가 문서 페이지 다섯 개, 지식베이스 문서 열두 개, 코드 스니펫 스무 개를 한꺼번에 받았습니다. 컨텍스트 윈도우가 폭발했고 최종 응답은 관련 없는 디테일로 부풀거나 핵심을 놓쳤죠.

서브그래프로 재구조화한 뒤, 각 서브에이전트가 독립적으로 작동하며 황금 데이터만 추출합니다 – 질문에 답하는 데 필요한 핵심 사실, 인용, 맥락만요. 메인 에이전트는 원시 검색 결과를 절대 보지 않고 각 도메인 전문가의 정제된 인사이트만 받습니다. 문서 서브에이전트는 다섯 페이지를 읽어도 핵심 단락 두 개만 반환하고, 코드베이스 서브에이전트는 오십 개 파일을 검색해도 줄 번호가 포함된 특정 구현만 반환합니다.

핵심 교훈

RAG 시스템을 구축할 때 벡터 임베딩이 항상 정답은 아닙니다. 구조화된 콘텐츠에는 기존 구조를 직접 활용하는 게 더 효과적일 수 있어요. 가장 중요한 건 사용자의 실제 워크플로를 관찰하고 그걸 자동화하는 것이죠. 복잡한 질문에는 전문 서브그래프를 가진 Deep Agent가 컨텍스트 폭발을 막아주고, 프로덕션에서는 가드레일, 재시도, 폴백, 캐싱 같은 미들웨어가 필수입니다.

새 시스템 런칭 이후 공개 Chat LangChain 사용자들은 정확한 인용과 함께 15초 이내 응답을 받고, 내부 지원 엔지니어들은 Deep Agent로 가장 복잡한 티켓을 처리합니다. 에이전트가 엔지니어를 대체하지 않습니다 – 증폭시킵니다.

참고자료:

• LangSmith 트레이스 예시 – 실제 에이전트 실행 과정
• Chat LangChain – 재구축된 챗봇 직접 사용해보기

1

Like?