LangChain 챗봇을 재구축한 이유와 우리가 배운 점

Liam Bush

배경

성공적인 플랫폼이라면 누구나 신뢰할 수 있는 지원이 필요합니다. 하지만 저희 팀 스스로가 기술 질문에 대한 답변을 찾는 데 몇 시간을 쓰고 있다는 것을 깨달았습니다. 이러한 마찰은 엔지니어들의 속도를 늦출 뿐만 아니라, 사용자들에게도 치명적인 **병목 현상(bottleneck)**이었습니다.

저희는 우리가 지지하는 바로 그 도구들, 즉 LangChain, LangGraph 및 LangSmith를 사용하여 이를 해결하고자 했습니다. 저희는 원래 chat.langchain.com을 프로토타입으로 구축했으며, 명시적으로 두 가지 기능을 수행하도록 설계했습니다:

제품 Q&A: 사용자(그리고 저희 팀)가 제품 질문에 대한 즉각적이고 권위 있는 답변을 얻도록 돕기.
고객 프로토타입: 고객들이 LangChain 스택을 사용하여 정교하고 신뢰할 수 있는 에이전트를 구축하는 방법을 보여주는 살아있는 예시 역할을 합니다.

저희는 강력한 의도와 기능적인 제품을 가지고 있었습니다. 하지만 고백하자면, 저희 지원 엔지니어들은 LangChain 챗봇을 적극적으로 사용하지 않았습니다. 여기서부터 우리의 진정한 학습이 시작되었습니다. 이것은 우리가 우리 자신의 에이전트를 어떻게 수정했는지—그리고 고객들이 적응하고 사용할 수 있는 진정으로 신뢰할 수 있는 프로덕션급 애플리케이션을 구축하는 것에 대해 무엇을 배웠는가에 대한 이야기입니다.

저희 팀이 Chat LangChain을 적극적으로 사용하지 않은 것은 그것이 고장 났기 때문도 아니고, 믿지 못해서도 아니었습니다. 하지만 누군가가 *

이 3단계 루틴은 믿을 수 없을 만큼 잘 작동했습니다. 우리는 그들이 하루에도 몇 번씩 이 과정을 수행하는 것을 지켜보았고 생각했습니다: 만약 우리가 이 정확한 워크플로우를 자동화한다면 어떨까?

그래서 우리는 내부 Deep Agent (복잡하고 다단계적인 작업을 처리할 수 있는 에이전트를 구축하기 위한 라이브러리)을 만들었습니다. 여기에는 세 가지 전문 서브에이전트가 포함되었는데, 각각 문서 검색용, 지식 기반 검색용, 코드베이스 검색용입니다. 각 서브에이전트는 후속 질문을 하고 결과를 필터링한 다음, 주요 오케스트레이터 에이전트에게 통찰력을 전달합니다.

주요 에이전트는 이 모든 것을 종합하여 다음과 같은 답변을 제공했습니다:

예시 출력: "서브그래프에서 스트리밍하려면, LangGraph 스트리밍 문서를 참조하여 스트림 설정에 subgraphs: true를 설정하세요. ['업그레이드 후 토큰 스트리밍이 작동하지 않는 이유']라는 제목의 지원 문서가 이 정확한 문제를 설명하고 있습니다 — 중첩된 에이전트로부터 토큰 수준 업데이트를 얻으려면 서브그래프 스트리밍을 활성화해야 합니다. 구현은 pregel/main.py의 3373-3279행에 있으며, 여기서 subgraphs 플래그는 중첩 그래프 출력이 스트림에 포함되는지 여부를 제어합니다."

우리 엔지니어들은 이것을 매우 좋아했습니다.

이것은 복잡한 디버깅 과정에서 매주 몇 시간을 절약해 주었습니다. 그들은 프로덕션 문제를 설명하면, 문서 인용과 알려진 해결책 참조, 그리고 중요한 정확한 코드 라인을 가리키는 포괄적인 답변을 받았습니다.

그러다 우리는 깨달음을 얻었습니다

그러자 누군가 당연한 질문을 던졌습니다: 이것이 우리에게 이렇게 잘 작동한다면, 왜 우리의 공개 Chat LangChain은 이런 방식으로 작동하지 않는 걸까?

그것은 타당한 지적이었습니다. 우리의 공개 도구는 문서를 조각(fragment)으로 나누고 임베딩을 생성하여 벡터 데이터베이스에 저장했습니다. 문서가 업데이트될 때마다 우리는 지속적으로 재인덱싱해야 했습니다. 사용자들은 답변을 받았지만, 인용 정보에는 개선이 필요했고 컨텍스트는 파편화되어 있었습니다.

우리는 실제로 작동하는 것을 복사하면서 내부적으로 더 나은 무언가를 우연히 만들었습니다. 이제 그와 동일한 접근 방식을 공개 제품에 적용할 때가 왔습니다.

재구축을 시작했을 때, 우리는 두 가지 광범위한 질문 범주에 의해 구동되는 서로 다른 두 가지 아키텍처를 결합해야 한다는 것을 빠르게 깨달았습니다. 대부분의 질문은 문서(docs)와 지식 기반(knowledge base)을 사용하여 답변할 수 있었습니다. 나머지 질문들은 코드의 기초 분석을 필요로 했습니다.

새로운 에이전트 구축 방법

단순 문서용: Create Agent 사용하기

저희는 chat.langchain.com에 기본 모드로 createAgent (langchain에서의 에이전트 추상화)를 선택했습니다. 이는 속도에 가장 적합하기 때문입니다.

계획 단계나 오케스트레이션(orchestration) 오버헤드가 전혀 없습니다. 즉각적인 도구 호출과 답변만 이루어집니다. 이 에이전트는 문서를 검색하고, 필요하면 지식 기반을 확인하며, 결과가 불분명할 경우 쿼리를 개선한 다음 답변을 반환합니다. 대부분의 문서 관련 질문은 3~6개의 도구 호출로 처리할 수 있으며, Create Agent는 이를 몇 초 만에 실행합니다.

모델 옵션:

저희는 최종 사용자들에게 여러 모델—Claude Haiku 4.5, GPT-4o Mini, 그리고 GPT-4o-nano—에 대한 접근 권한을 제공하며, Haiku 4.5가 강력한 정확도를 유지하면서도 도구 호출에서 예외적으로 빠르다는 것을 발견했습니다. createAgent와 Haiku 4.5의 조합은 대부분의 쿼리에 대해 15초 미만의 응답 시간을 제공하는데, 이는 문서 Q&A가 요구하는 바와 정확히 일치합니다.

최적화 방법:

저희는 LangSmith를 사용하여 모든 대화를 추적하고, 에이전트가 불필요한 도구 호출을 하는 지점을 식별하며, 프롬프트를 개선했습니다. 데이터를 통해 대부분의 질문은 에이전트에게 더 나은 후속 질문을 하도록 가르치면 3~6개의 도구 호출로 답변할 수 있다는 것을 알게 되었습니다. LangSmith의 평가 스위트는 다양한 프롬프팅 전략을 A/B 테스트하고 속도와 정확성 모두에서 개선 사항을 측정할 수 있게 해주었습니다.

이 30초 트레이스는 7개의 도구 호출을 포함합니다: 문서 검색 4회, 지식 기반 기사 조회 1회, 기사 읽기 2회이며, 최종 응답 스트리밍에 20초가 할애되었습니다.

여기서 보기

코드 기반 답변을 위한 심층 에이전트 (Deep Agent with Subgraphs)

많은 질문들은 문서 활용 외에도, 구현 세부 사항을 검증하기 위해 저희의 코드베이스를 깊이 탐색하고, 지식 기반 및 알려진 이슈들을 교차 참조하는 것을 필요로 했습니다.

아키텍처:

이러한 작업을 위해 저희는 **전문화된 서브그래프(subgraphs)**를 가진 Deep Agent를 구축했습니다. 이 서브그래프들은 문서 검색, 지식 기반 검색, 그리고 코드베이스 검색을 위한 각각의 역할을 담당합니다.

각 서브에이전트는 독립적으로 작동하며, 후속 질문을 하고, 정보를 필터링하며, 가장 관련성 높은 통찰력만을 추출한 다음 이를 메인 오케스트레이터 에이전트에게 전달합니다. 이는 주 에이전트가 너무 많은 컨텍스트에 압도되는 것을 방지하는 동시에, 각 도메인 전문가가 필요한 만큼 깊게 파고들 수 있게 합니다.

코드베이스 검색의 장점:

코드베이스 검색 서브에이전트는 특히 강력합니다. 패턴 매칭을 사용하여 저희의 비공개 리포지토리를 검색할 수 있고, 파일 구조를 탐색하여 컨텍스트를 이해하며, 라인 번호 정밀도로 특정 구현 내용을 읽어낼 수 있습니다.

트레이드오프:

이 심층 에이전트 아키텍처는 실행 시간이 더 오래 걸립니다. 복잡한 쿼리의 경우 때로는 1~3분이 소요되지만, 그 깊이는 충분히 가치가 있습니다. 초기 응답만으로는 핵심 질문에 답하지 못할 때 저희는 DeepAgent를 활용합니다.

면책 조항: 이 모드는 출시 시점에 일부 사용자에게만 활성화되며 며칠 내로 일반 사용 가능하게 될 예정입니다.

벡터 임베딩에서 벗어난 이유 (Why We Got Moved Away from Vector Embeddings)

문서 검색의 표준 접근 방식—문서를 조각(chunk)으로 나누고, 임베딩을 생성하며, 벡터 데이터베이스에 저장하고, 유사성으로 검색하는 방식—은 PDF와 같은 비정형 콘텐츠에는 잘 작동합니다. 하지만 구조화된 제품 문서의 경우, 저희는 세 가지 문제에 계속 부딪혔습니다.

청킹이 구조를 깨뜨립니다. 문서를 500 토큰 조각으로 자르면 헤더, 하위 섹션 및 컨텍스트가 손실됩니다. 에이전트는 왜 또는 언제인지 설명하지 않은 채 `

지속적인 재인덱싱(Constant reindexing). 저희 문서는 매일 여러 번 업데이트됩니다. 변경 사항이 있을 때마다 청크 분할(re-chunking), 임베딩(re-embedding), 그리고 다시 업로드하는 과정을 거쳐야 했습니다. 이 과정 때문에 속도가 느려졌습니다.

모호한 출처 표기(Vague citations). 사용자들이 답변을 검증하거나 정보가 어디서 왔는지 추적할 수 없었습니다.

획기적인 발견은 우리가 잘못된 문제를 해결하고 있었다는 것을 깨달은 것이었습니다. 문서는 이미 체계적으로 정리되어 있습니다. 지식 기반도 이미 분류되어 있습니다. 코드베이스 역시 탐색하기 쉽습니다. 우리는 더 똑똑한 검색(smarter retrieval)이 필요한 것이 아니라, 에이전트가 이러한 기존 구조에 직접 접근할 수 있도록 할 필요가 있었습니다.

더 나은 접근 방식: 직접 API 액세스 및 스마트 프롬프팅

청크 분할과 임베딩 대신, 우리는 에이전트에게 실제 데이터에 대한 직접적인 접근 권한을 부여했습니다. 문서의 경우, 모든 헤더, 하위 섹션, 코드 예제가 온전히 포함된 전체 페이지를 반환하는 Mintlify's API를 사용합니다. 지식 기반의 경우, 제목으로 지원 문서를 먼저 조회한 다음 가장 유망한 것들을 전체 내용으로 읽습니다. 코드베이스 검색의 경우, 저희가 코드베이스를 LangGraph Cloud 배포에 업로드하고 패턴 매칭을 위한 ripgrep, 구조 이해를 위한 디렉터리 순회(directory traversal), 특정 구현 추출을 위한 파일 읽기 기능을 사용합니다.

에이전트는 유사도 점수(similarity scores)를 기반으로 검색하지 않습니다. 인간이 하는 것처럼 — 키워드, 정제(refinement), 그리고 후속 질문을 통해 — 검색합니다.

여기서 마법 같은 일이 벌어집니다. 우리는 에이전트에게 한 번만 검색하고 발견한 것을 반환하라고 지시하는 데 그치지 않습니다. 우리는 에이전트가 자신이 충분한 정보를 가지고 있는지에 대해 비판적으로 생각하도록 프롬프팅합니다. 결과가 모호하거나 불완전하면, 에이전트는 쿼리를 정제하여 다시 검색합니다. 문서에서 어떤 개념을 언급했지만 설명하지 않은 경우, 에이전트는 그 개념을 구체적으로 검색합니다. 여러 해석이 가능한 경우, 에이전트는 가장 관련성 높은 것으로 범위를 좁힙니다.

도구 설계: 인간의 워크플로우를 위한 구축

우리는 우리의 도구가 검색 알고리즘이 작동하는 방식이 아니라, 인간이 실제로 검색하는 방식을 반영하도록 설계했습니다.

문서 검색: 조각이 아닌 전체 페이지

문서 검색: 조각이 아닌 전체 페이지

Mintlify의 API를 쿼리하여 전체 페이지를 반환합니다. 누군가 스트리밍에 대해 질문하면, 에이전트는 여러 섹션에서 나온 세 개의 분절된 단락을 받는 것이 아니라, 인간이 읽는 방식 그대로 구조화된 전체 스트리밍 문서 페이지를 받습니다.

@tool

def SearchDocsByLangChain(query: str, page_size: int = 5, language: Optional[str] = None) -> str:

"""Mintlify API를 통해 LangChain 문서를 검색합니다."""

params = {"query": query, "page_size": page_size}

if language:

params["language"] = language

response = requests.get(MINTLIFY_API_URL, params=params)

return _format_search_results(response.json())

하지만 여기서 멈추지 않습니다. 우리는 에이전트에게 초기 결과가 실제로 질문에 답하는지 평가하도록 프롬프트를 제공합니다. 이 섹션이 맞을까? 명확히 할 필요가 있는 관련 개념은 없을까? 더 구체적인 검색어가 좋을까? *

에이전트는 4~6회의 도구 호출 예산을 가지며, 응답하기 전에 이해도를 높이기 위해 이를 전략적으로 사용하도록 장려합니다.

실제 사례는 다음과 같습니다:

사용자가 "내 에이전트에 메모리를 추가하려면 어떻게 해야 하나요?"라고 질문합니다.

에이전트는 `

이 반복적인 검색 과정은 Create Agent를 사용하면 몇 초 만에 이루어지지만, 근본적으로 응답의 품질을 변화시킵니다. 에이전트는 단순히 정보를 검색하는 것이 아니라, 사용자가 실제로 무엇을 필요로 하는지에 대해 추론합니다.

지식 기반 검색: 스캔 후 읽기

저희는 인간이 지식 기반을 사용하는 방식대로 지식 기반(Pylon으로 구동) 검색을 2단계 프로세스로 구축했습니다.

먼저, 에이전트는 기사 제목들—때로는 수십 개에 달하는—을 가져와서 관련성이 높아 보이는 것을 식별하기 위해 스캔합니다. 그런 다음 그 기사들만 전체 내용을 읽습니다.

@tool

def search_support_articles(collections: str = "all", limit: int = 50) -> str:

"""1단계: 스캔할 기사 제목 가져오기"""

articles = pylon_client.list_articles(collections=collections, limit=limit)

return json.dumps([{