Why We Rebuilt LangChain’s Chatbot and What We Learned

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

LangChain은 지원 엔지니어의 문서·지식 기반·코드 검색 방식을 재현해 챗봇을 재구축하고, 빠른 createAgent와 심층 분석용 Deep Agent를 결합했다.

📌 핵심 요약

• 기존 Chat LangChain은 제품 질의응답과 고객용 구현 예시를 목표로 했지만, 문서만으로 복잡한 기술 문제를 해결하기 어려워 지원 엔지니어들이 적극적으로 사용하지 않았다.
• 내부 Deep Agent는 문서·지식 기반·코드 검색을 담당하는 세 하위 에이전트의 결과를 통합했으며, 엔지니어들의 복잡한 디버깅 시간을 매주 수 시간 줄였다.
• 공개 챗봇의 기본 모드는 createAgent이며, 대부분의 문서 질문을 3~6회 도구 호출로 처리한다. Claude Haiku 4.5와 결합하면 대부분의 질의에 15초 미만으로 응답한다고 설명한다.
• 코드 구현 검증이 필요한 질문에는 전문 하위 그래프를 갖춘 Deep Agent를 사용한다. 복잡한 질의는 1~3분이 걸리며, 출시 당시에는 일부 사용자에게만 제공됐다.
• 구조화된 제품 문서의 맥락 손실·반복 재색인·모호한 인용을 줄이기 위해 벡터 임베딩 중심 검색에서 Mintlify API, 지식 기반 기사 검색, ripgrep을 통한 직접 접근으로 전환했다. LangSmith로 대화를 추적하고 프롬프트 전략의 속도와 정확도를 평가했다.

🧩 주요 포인트

1. 지원 엔지니어의 세 단계 검색을 자동화 → 문서의 공식 설명, 지식 기반의 해결 사례, 코드의 실제 동작을 함께 확인하는 답변 구조.
2. createAgent와 Deep Agent의 역할 분담 → 일반 문서 질문의 응답 속도와 복잡한 구현 질문의 분석 깊이를 구분해 처리.
3. 전체 페이지 접근·검색어 재정제·LangSmith 평가의 결합 → 문맥과 근거를 유지하면서 불필요한 도구 호출을 줄이는 품질 개선 방식.

🧠 상세 정리

1. 출발점: 작동하는 챗봇과 실제 지원 업무의 간극

LangChain 팀은 기술 질문의 답을 찾는 데 많은 시간을 쓰는 상황이 내부 엔지니어와 사용자 모두에게 병목이 된다고 판단하고, 자사 도구인 LangChain·LangGraph·LangSmith로 챗봇을 만들었다. 초기 chat.langchain.com은 제품 질문에 신뢰할 만한 답을 제공하는 기능과 고객이 에이전트를 구현할 때 참고할 실제 예시라는 두 목적을 가졌다. 그러나 제품이 작동하고 있었음에도 지원 엔지니어들은 이를 적극적으로 사용하지 않았다. 운영 환경에서 스트리밍이 작동하지 않는 이유처럼 복잡한 질문은 문서만으로 충분히 설명하기 어려웠기 때문이다. 팀은 이 사용 부진을 계기로 기존 챗봇이 지원 업무에서 필요한 조사 범위를 충족하지 못한다는 점을 확인했다.

2. 지원 엔지니어의 검색 절차를 내부 에이전트로 구현

지원 엔지니어들은 먼저 공식 문서에서 기능이 어떻게 작동해야 하는지 확인하고, 지식 기반에서 비슷한 문제와 해결 사례를 찾은 다음, Claude Code로 실제 구현을 검색해 코드의 동작을 검증했다. 팀은 하루에도 수십 차례 반복되는 이 절차를 관찰하고, 같은 흐름을 내부 Deep Agent로 자동화했다. 문서·지식 기반·코드 검색을 각각 맡은 세 하위 에이전트는 후속 질문과 결과 선별을 수행한 뒤 핵심 정보를 주 조정 에이전트에 전달했다. 최종 답변은 공식 설명과 알려진 해결책을 연결하고, 필요한 경우 관련 코드 위치까지 제시하는 형태였다. 원문에 따르면 엔지니어들은 이 방식을 유용하게 평가했으며, 복잡한 디버깅에 쓰던 시간을 매주 수 시간 절약했다.

3. 내부 성공을 공개 제품으로 확장하고 실행 경로를 분리

내부 도구가 좋은 반응을 얻자 팀은 공개 Chat LangChain에도 같은 접근을 적용하기로 했다. 당시 공개 도구는 문서를 조각내고 임베딩을 생성해 벡터 데이터베이스에 저장하는 구조였으며, 문서가 바뀔 때마다 재색인이 필요했고 답변의 맥락과 인용에도 개선 여지가 있었다. 재구축 과정에서는 대부분의 질문이 문서와 지식 기반만으로 해결되지만, 나머지는 코드 구현 분석까지 필요하다는 구분이 드러났다. 이에 기본 모드로는 계획 수립이나 조정에 따른 추가 부담 없이 곧바로 도구를 호출하는 createAgent를 선택했다. 이 에이전트는 문서를 검색하고 필요하면 지식 기반을 확인하며, 결과가 불명확하면 검색어를 수정하는 방식으로 대부분의 문서 질문을 3~6회 도구 호출 안에 처리한다.

4. 모델 선택과 LangSmith를 통한 응답 최적화

공개 챗봇은 사용자에게 Claude Haiku 4.5, GPT-4o Mini, GPT-4o-nano 등 여러 모델 선택지를 제공한다. 팀은 Haiku 4.5가 도구 호출 속도가 매우 빠르면서도 높은 정확도를 유지한다고 평가했으며, createAgent와 결합하면 대부분의 질의에 15초 미만으로 응답한다고 설명했다. 최적화에는 LangSmith를 사용해 모든 대화를 추적하고 불필요한 도구 호출이 발생하는 지점을 찾아 프롬프트를 다듬었다. 평가 도구로 서로 다른 프롬프트 전략을 비교하면서 속도와 정확도의 변화를 측정했고, 더 나은 후속 질문을 유도하면 대부분의 질문을 3~6회 호출로 해결할 수 있음을 확인했다. 별도로 제시된 30초 추적 사례는 도구 호출 7회를 포함하며 최종 응답 스트리밍에 20초를 사용해, 실제 요청별 호출 수와 시간 구성이 달라질 수 있음을 보여준다.

5. 코드 검증을 위한 Deep Agent와 시간상의 절충

문서와 기존 지원 사례만으로 답하기 어려운 질문에는 실제 구현을 조사하는 Deep Agent를 구성했다. 이 구조는 문서 검색, 지식 기반 검색, 코드 검색을 담당하는 전문 하위 그래프로 나뉘며, 각 하위 에이전트는 독립적으로 추가 조사를 수행하고 관련성이 높은 내용만 추려 전달한다. 주 조정 에이전트에 모든 검색 결과를 그대로 넣지 않으면서도 각 영역에서 필요한 깊이까지 탐색하게 하려는 설계다. 코드 검색 하위 에이전트는 비공개 저장소에서 패턴을 검색하고 파일 구조를 살펴보며 특정 구현을 줄 번호 수준으로 읽을 수 있다. 복잡한 질의에는 1~3분이 걸릴 수 있어 초기 응답이 핵심 질문을 해결하지 못할 때 활용하며, 원문은 출시 당시 일부 사용자에게만 활성화됐고 며칠 뒤 일반 제공할 예정이라고 명시한다.

6. 구조화된 문서에서 벡터 임베딩 방식을 바꾼 이유

팀은 문서를 분할하고 임베딩을 생성해 유사도로 검색하는 방식이 PDF 같은 비정형 콘텐츠에서는 잘 작동하지만, 구조화된 제품 문서에서는 세 가지 문제가 반복됐다고 설명한다. 문서를 500토큰 단위로 자르면 제목과 하위 절의 연결이 끊겨, 설정값은 찾더라도 그것을 언제 왜 사용해야 하는지에 대한 맥락을 놓칠 수 있었다. 문서가 하루에도 여러 차례 갱신되기 때문에 변경마다 다시 분할하고 임베딩을 계산해 업로드하는 운영 부담도 발생했다. 인용이 모호하면 사용자가 답변의 출처를 추적하거나 내용을 검증하기 어렵다는 문제도 있었다. 팀은 문서·지식 기반·코드가 이미 가진 구조를 활용하는 것이 핵심이라고 보고, 이를 에이전트가 직접 탐색할 수 있도록 접근 방식을 바꿨다.

7. 전체 문서와 기존 구조를 활용하는 검색 도구

문서 검색에는 Mintlify API를 사용해 제목, 하위 절, 코드 예제가 유지된 전체 페이지를 가져오도록 했다. 지식 기반은 지원 기사 제목을 먼저 검색하고 유망한 기사를 골라 전문을 읽는 방식으로 접근한다. 코드베이스는 LangGraph Cloud 배포에 올린 뒤 ripgrep으로 패턴을 검색하고, 디렉터리 탐색과 파일 읽기를 통해 구조와 구체적인 구현을 확인한다. 검색의 중심은 유사도 점수에 따른 조각 회수에서 사람이 수행하는 키워드 탐색, 검색어 수정, 후속 조사로 이동했다. 프롬프트 역시 첫 결과를 그대로 답변에 쓰도록 두지 않고, 정보가 충분한지와 관련 개념이 설명됐는지를 평가한 다음 결과가 모호하거나 불완전하면 다시 검색하도록 유도한다.

8. 메모리 질문 사례로 본 반복 검색과 근거 보완

도구 설계 설명에서 팀은 에이전트에 4~6회 도구 호출 예산을 주고, 최초 검색이 실제 질문에 답하는지 검토하면서 필요한 탐색에 전략적으로 사용하도록 했다고 밝힌다. 사용자가 에이전트에 메모리를 추가하는 방법을 묻는 사례에서는 첫 검색에 체크포인팅, 대화 기록, Store API가 함께 등장한다. 에이전트는 메모리가 한 스레드의 대화 상태 유지인지 여러 대화에 걸친 정보 저장인지 모호하다는 점을 파악하고, 체크포인팅으로 검색을 좁혀 관련 지원 기사를 확인한다. 이어 해당 기사가 스레드를 넘나드는 메모리를 다루지 않는다는 점을 확인하고 Store API를 추가로 검색해 빠진 내용을 보완한다. 최종 답변은 대화 기록을 위한 체크포인팅과 장기 메모리를 위한 Store API를 함께 설명하고 사용한 문서와 지원 기사를 인용하며, 원문은 이 반복 과정이 createAgent에서 수초 안에 이루어진다고 설명한다.

🧾 핵심 주장 / 시사점

• 실제 사용자의 성공적인 조사 절차를 관찰한 것이 재설계의 출발점이었다. 문서·사례·구현을 함께 확인하는 흐름이 내부 도구의 효용을 높였고 공개 제품 개편으로 이어졌다.
• 응답 속도와 조사 깊이는 질문 유형에 따라 다르게 배분됐다. 일반 문서 질문과 코드 검증 질문을 분리한 구조가 두 요구를 함께 다루는 핵심이다.
• 검색 품질 개선은 출처의 기존 구조를 보존하는 접근과 검색 결과의 충분성을 판단하는 반복 탐색이 결합될 때 이루어졌다.

✅ 액션 아이템

• 지원 질문을 문서·지식 기반으로 해결할 수 있는 유형과 코드 검색이 필요한 유형으로 구분.
• createAgent와 Deep Agent의 적용 범위를 응답 속도와 구현 분석 깊이에 맞춰 검토.
• LangSmith로 불필요한 도구 호출과 프롬프트별 속도·정확도를 평가.

❓ 열린 질문

• createAgent에서 Deep Agent로 전환할 때 초기 답변의 부족함을 어떤 기준으로 판단할 것인가?
• Mintlify API와 지식 기반 기사 검색을 통한 직접 접근은 문맥 보존과 인용 정확도를 얼마나 개선했는가?
• LangSmith 평가에서 프롬프트 전략별 속도와 정확도는 각각 얼마나 달라졌는가?