LangChain GTM 에이전트 완전 분석
How We Built LangChain’s GTM Agent — 상세 기술 해설
작성 기준 : LangChain 공식 블로그 및 Deep Agents 공식 문서 (2026년 3월 기준)
원문 출처 : https://blog.langchain.com/how-we-built-langchains-gtm-agent/
목차
- 도입: GTM 에이전트를 만든 이유
- 핵심 성과 지표
- 설계 원칙과 제약 조건
- 에이전트 아키텍처 전체 그림
- 인바운드 리드 처리 플로우
- Account Intelligence Engine
- 멀티에이전트 서브에이전트 구조
- 기술 스택: Deep Agents를 선택한 이유
- 메모리 시스템: 에이전트가 학습하는 방법
- 평가(Eval) 및 피드백 루프
- 예상치 못한 사내 확산
- 핵심 교훈
- LangChain 생태계 관점에서의 의미
1. 도입: GTM 에이전트를 만든 이유
LangChain의 영업 팀은 오랫동안 비효율의 반복에 시달리고 있었다. 한 명의 영업 담당자(Rep)가 새로운 리드에 접근하기 위해서는 Salesforce에서 계정 정보를 확인하고, Gong에서 통화 이력을 검색하며, LinkedIn에서 담당자 프로필을 파악하고, 회사 웹사이트에서 맥락을 파악하는 일련의 과정을 탭을 전환해가며 수동으로 반복해야 했다. 이 조사 과정에만 이메일 한 통을 쓰기 전에 평균 15분이 소요되었고, 팀원 중 누군가가 이미 어제 해당 리드에 연락을 취했는지조차 쉽게 확인할 방법이 없었다.
인바운드 팔로업 역시 마찬가지였다. 새로운 컨택이 등록될 때마다 Apollo에 동일한 메시지를 수동으로 입력해야 했고, 이 반복적이고 가치 낮은 작업이 영업 팀의 생산성을 갉아먹고 있었다.
LangChain은 이 전체 프로세스를 처음부터 끝까지 자동화하는 GTM(Go-To-Market) 에이전트를 구축하기로 결정했다. 이 에이전트는 단순한 자동화 스크립트가 아니라, 여러 데이터 소스를 조율하고 컨텍스트를 이해하며 인간의 최종 승인 하에 동작하는 진정한 의미의 AI 에이전트다.
2. 핵심 성과 지표
GTM 에이전트가 실제 프로덕션에 배포된 이후 나타난 결과는 놀라운 수준이었다.
리드-투-기회 전환율이 2025년 12월부터 2026년 3월까지 불과 3~4개월 만에 250% 상승했다. 이는 단순히 더 많은 리드를 처리한 결과가 아니라, 에이전트가 각 리드의 컨텍스트를 정확히 파악하고 관계 상태에 맞는 개인화된 접근을 가능하게 했기 때문이다. 같은 기간 동안 파이프라인 금액도 3배 증가했다.
팔로업 비율 측면에서도 의미 있는 변화가 나타났다. 실버 등급 리드에 대한 팔로업 비율이 97% 상승했고, 골드 등급 리드는 18% 향상되었다. 특히 실버 리드의 경우, 48시간 SLA 자동 발송 정책의 도입이 결정적인 역할을 했다. 이전에는 담당자가 바쁘거나 우선순위에서 밀려 응답 없이 흘러가버리던 리드들이, 이제는 시스템이 자동으로 처리하도록 설계된 것이다.
각 영업 담당자는 매달 40시간씩을 단순 조사와 드래프팅 업무에서 되찾았다. 팀 전체로 보면 월간 1,320시간이라는 방대한 시간이 실질적인 영업 활동으로 재투입될 수 있게 되었다. 사용률도 높았는데, 영업 팀원 중 50%가 매일, 86%가 매주 이 에이전트를 사용하고 있었다. 이는 형식적인 도입이 아닌 실질적인 업무 도구로 정착했다는 강력한 증거다.
3. 설계 원칙과 제약 조건
LangChain 팀이 코드를 한 줄도 작성하기 전에 먼저 한 일은 “이 에이전트가 실제로 무엇을 해야 하는가”를 명확히 정의하는 것이었다. 이 접근 방식 자체가 이 프로젝트가 전달하는 중요한 교훈 중 하나다.
두 가지 핵심 목표
첫 번째 목표는 리드당 연구 및 드래프팅에 소요되는 시간을 줄이는 것이었다. 두 번째는 마케팅에서 생성된 인바운드 리드의 전환율을 높이는 것이었다. 아웃바운드 조사와 드래프팅은 충분히 체계적인 과정이므로 자동화가 가능하지만, 시스템이 안전하고 감사 가능하며 사용할수록 개선되는 방식으로 작동해야 한다는 조건이 달려 있었다.
절대 타협할 수 없는 조건 (Non-Negotiables)
Human-in-the-Loop(인간 검토 필수) : 에이전트가 아무리 정확한 드래프트를 작성하더라도, 영업 담당자의 명시적인 검토와 승인 없이는 단 하나의 이메일도 발송되지 않는다. 이 원칙은 단순한 안전장치가 아니다. 잘못된 시점의 이메일 한 통이 수개월간 쌓아온 관계를 무너뜨릴 수 있다는 현실적 인식에서 비롯된 것이다.
연락 이력 인지 : 에이전트는 드래프트를 작성하기 전에 반드시 팀원 누군가가 이미 해당 리드에 연락을 취했는지 확인해야 한다. 이 체크가 없으면 같은 사람에게 중복으로 연락하는 실수가 발생할 수 있다.
핵심 기능 요건
관계 인식 개인화 : 드래프트는 해당 계정의 현재 상태(기존 고객인지, 따뜻한 가망 고객인지, 완전히 차가운 컨택인지)를 반영해야 하며, 모든 리드를 동일하게 취급해서는 안 된다.
설명 가능성(Explainability) : 영업 담당자는 에이전트가 왜 특정 각도를 선택했는지 알 수 있어야 한다. 소스와 추론 과정을 함께 제시함으로써 담당자가 드래프트를 정제하고 피드백을 제공할 수 있도록 해야 한다.
학습 루프 : 에이전트는 담당자의 수정 내용을 통해 시간이 지날수록 스스로 개선되어야 하며, 이를 위해 누군가 수동으로 프롬프트를 업데이트하는 작업은 필요 없어야 한다.
4. 에이전트 아키텍처 전체 그림
GTM 에이전트는 크게 두 가지 기능을 수행한다. 첫째는 리드를 조사하고 개인화된 이메일 드래프트를 작성하는 것이고, 둘째는 웹 활동, 개발자 생태계, 제품 사용 현황, 마케팅 접점 전반에 걸친 계정 수준의 신호를 집계하여 영업 담당자가 어디에 집중해야 할지를 보여주는 것이다.
에이전트가 연결된 데이터 소스는 다음과 같다.
내부 시스템 : Salesforce(CRM 및 계정 데이터), Gong(통화 녹취 및 트랜스크립트), BigQuery(제품 사용 데이터 및 이벤트), Gmail(이메일 이력)
외부 시스템 : Apollo(컨택 정보 및 아웃리치), Exa(웹 검색 및 AI 이니셔티브 조사), LinkedIn(담당자 프로필)
이 다양한 데이터 소스를 가로지르며 신호를 종합하고 개인화된 아웃풋을 생성하는 것은 단순한 LLM 호출로는 처리할 수 없는 복잡성을 요구한다. 바로 이 점이 LangChain이 Deep Agents를 선택한 핵심 이유다.
5. 인바운드 리드 처리 플로우
새로운 리드가 Salesforce에 등록되는 순간, 에이전트가 즉시 작동을 시작한다. 이 플로우는 단계별로 다음과 같이 진행된다.
1단계: 발송 거부 체크 (Do-Not-Send Checks)
에이전트가 가장 먼저 하는 일은 이메일을 보내지 말아야 할 이유를 찾는 것이다. 만약 해당 리드가 방금 지원 티켓을 제출했다면, 자동화된 영업 이메일을 보내는 것은 명백한 실수다. 팀원 중 누군가가 이미 이번 주에 연락을 취한 경우도 마찬가지다. 에이전트는 기본적으로 신중하게 행동하도록 설계되어 있다. 이 체크를 통과하지 못하면 이후 단계는 실행되지 않는다.
2단계: 컨텍스트 수집 (Context Gathering)
모든 체크를 통과하면, 에이전트는 이전에 영업 담당자가 수동으로 하던 것과 동일한 조사 과정을 실행한다. Salesforce에서 전체 계정 기록을 가져오고, Gong 트랜스크립트를 읽어 미팅 이력을 파악하며, LinkedIn 프로필을 확인한다. 내부 이력이 많지 않은 경우에는 Exa를 활용한 웹 검색으로 해당 회사가 현재 AI 분야에서 무엇을 하고 있는지를 파악한다.
3단계: 아웃바운드 스킬 기반 드래프트 작성
이메일 드래프트를 작성하는 방식은 관계의 상태에 따라 달라진다. 에이전트는 드래프팅 전에 아웃바운드 스킬(Outbound Skill) 이라고 불리는 플레이북을 로드한다. 이 스킬은 따뜻한 관계와 차가운 관계 모두를 커버하도록 설계되어 있다.
- 기존 고객 : 관계 맥락을 살린 확장 지향적 접근
- 따뜻한 가망 고객 : 이전 상호작용을 반영한 개인화된 메시지
- 차가운 컨택 : 조사 기반의 간결한 메시지로 플레이북에 정의된 형식을 따름
4단계: Slack 드래프트 전달 및 승인
완성된 드래프트는 Slack DM으로 해당 영업 담당자에게 전달된다. 이때 단순히 드래프트만 전달하는 것이 아니라, 에이전트가 왜 이 각도를 선택했는지에 대한 추론 과정과 사용된 소스도 함께 보여준다. 담당자는 Send(발송), Edit(수정), Cancel(취소) 버튼 중 하나를 선택할 수 있다.
발송을 선택하면, 에이전트는 해당 가망 고객을 선택적으로 등록할 수 있는 팔로업 이메일 시퀀스도 대기열에 올린다.
5단계: 48시간 SLA 자동 발송 (실버 리드)
팀이 에이전트를 고도화하면서 추가된 규칙이다. 실버 등급 리드의 경우, 담당자가 48시간 내에 승인 또는 거절을 하지 않으면 자동으로 발송된다. 이 정책이 추가된 이후 이전이라면 응답 없이 흘러갔을 리드들의 팔로업 비율이 의미 있게 상승했다.
6. Account Intelligence Engine
담당자 한 명이 50~100개 이상의 계정을 관리하는 규모에서는, 무언가 조용히 사라지거나 확장 기회를 놓치는 일이 빈번하게 발생한다. 일회성 이벤트 처리를 넘어서, 팀이 필요로 한 것은 정기적으로 계정 전반의 신호를 능동적으로 수집하고 표면화하는 주간 인텔리전스 시스템이었다.
트리거와 데이터 수집
이 엔진은 매주 월요일 아침마다 자동으로 실행된다. 실행이 시작되면 에이전트는 세 곳에서 데이터를 수집한다. Salesforce에서는 CRM 데이터와 현재 계정 상태를 가져온다. BigQuery에서는 제품 사용 데이터와 이벤트 로그를 분석하여 사용 트렌드와 활동 수준을 파악한다. 그리고 Exa를 통해 외부 세계의 신호를 수집하는데, 투자 유치 소식, 신제품 론칭, AI 관련 이니셔티브 등 계정의 미래 방향을 암시하는 정보들이 여기서 나온다.
두 팀을 위한 서로 다른 리포트
동일한 데이터를 기반으로 하지만, Account Intelligence Agent는 관심사가 다른 두 팀을 위해 서로 다른 리포트를 생성한다.
영업 팀 리포트 (확장 기회 중심)
영업 팀이 “어디에 기회가 있는가?”라는 질문에 답하기 위해 에이전트는 다음 신호들을 집계한다.
패키지 설치 및 사용 급증은 개발자 생태계 신호로, 고객사가 LangChain 관련 패키지를 최근에 설치하기 시작했거나 사용량이 급증했다면 확장 수요를 예고하는 강력한 신호다. AI 엔지니어 채용 동향도 중요한 지표인데, 고객사가 AI 엔지니어를 적극적으로 채용하거나 에이전틱 시스템을 구축 중이라는 신호는 확장 가능성이 높음을 의미한다. 임원 이동 역시 주목해야 하는 신호다. 새로운 CTO나 VP가 취임했다면 새로운 관계 구축의 기회가 열릴 수 있다. 피처 적합 매칭 기능도 포함되어 있는데, 새로운 기능 론칭 시 최근 활동이 해당 기능과 잘 맞는 계정을 자동으로 식별한다. 마지막으로 단순히 계정이 활성화되어 있다는 것만으로는 부족하기 때문에, 에이전트는 가장 많이 참여하고 있는 개인을 식별하여 누구에게 먼저 연락해야 할지도 제안한다.
배포 엔지니어링 팀 리포트 (계정 건전성 중심)
배포 엔지니어링 팀이 “어떤 계정이 도움을 필요로 하는가?”라는 질문에 답하기 위해 에이전트는 다른 각도의 신호들을 수집한다.
BigQuery에서 추출한 제품 사용 현황은 사용 트렌드와 활동 수준을 보여준다. 크레딧 소진 알림은 크레딧을 거의 다 사용한 고객을 미리 파악하여 갱신 또는 업그레이드를 준비할 수 있게 한다. 갱신 일정은 다가오는 계약 만료를 플래그로 표시하고, Gong 통화 요약을 통해 최근 고객 미팅에서 중요한 맥락을 빠르게 파악할 수 있다. 최근 통화에서 해결되지 않은 질문과 스레드도 별도로 식별되어, 팀이 실제로 개입이 필요한 곳이 어디인지를 알 수 있게 한다.
목표는 실제로 사람이 개입해야 하는 상황을 플래그로 표시하는 것이다. 덕분에 담당자가 일요일 저녁마다 대시보드를 직접 뒤지는 일 없이 월요일 아침에 즉각 행동에 집중할 수 있게 된다. 두 리포트 모두 최종적으로 각 팀에게 맞춤화된 Slack Weekly Digest로 전달된다.
7. 멀티에이전트 서브에이전트 구조
Account Intelligence가 어떻게 수십~수백 개의 계정을 효율적으로 처리하는지는 멀티에이전트 아키텍처를 통해 설명된다.
부모 에이전트의 역할
전체 프로세스를 지휘하는 부모 에이전트(Parent Agent) 는 가장 먼저 Salesforce에 쿼리를 실행하여 관리 대상 계정 목록을 가져온다. 이 목록이 이후 병렬 처리의 기반이 된다.
계정별 서브에이전트 병렬 실행
핵심 설계 아이디어는 부모 에이전트가 각 계정마다 독립적인 서브에이전트를 생성한다는 것이다. 이 서브에이전트들은 서로 격리되어 실행되기 때문에 동시에 병렬로 처리될 수 있다. 각 서브에이전트는 자신이 담당하는 계정에 대해 AI 이니셔티브, 임원 이동, 채용 동향, M&A 등 다양한 신호를 조사한다.
이 구조가 중요한 이유는 세 가지다. 첫째로 컨텍스트 격리다. 각 서브에이전트는 자신의 계정에 관한 정보만 다루기 때문에, 부모 에이전트의 컨텍스트 창이 수십 개 계정 분량의 데이터로 넘쳐흐르는 “컨텍스트 블로트” 문제를 원천적으로 방지한다. 둘째로 제한된 도구 세트다. 영업 조사 서브에이전트는 Apollo, Exa, BigQuery에만 접근하고, 배포 엔지니어 서브에이전트는 Salesforce, Gong, 지원 도구만 사용한다. 이를 통해 도구 사용이 예측 가능하고 안전하게 유지된다. 셋째로 병렬성을 통한 효율성이다. 수십~수백 개 계정을 순차적으로 처리하면 시간이 지나치게 오래 걸리지만, 병렬 실행을 통해 전체 처리 시간을 크게 단축한다.
집계 및 우선순위화
모든 서브에이전트의 결과물이 수집되면, 부모 에이전트는 이를 집계하고 우선순위를 매기는 단계를 실행한다. 단순히 모든 신호를 나열하는 것이 아니라, 어떤 계정이 이번 주에 가장 먼저 주목받아야 하는지를 판단하여 구조화된 Slack Weekly Digest를 생성한다. LangSmith Deployment가 수평적 스케일링과 내구성 있는 실행을 처리하므로, 계정 수가 늘어나도 시스템이 안정적으로 유지된다.
8. 기술 스택: Deep Agents를 선택한 이유
LangChain은 왜 이 GTM 에이전트를 구축할 때 Deep Agents를 선택했는가? 이 질문에 대한 답은 이 프로젝트에서 가장 중요한 아키텍처 결정 중 하나다.
Deep Agents란 무엇인가?
Deep Agents는 LangChain이 개발한 오픈소스(MIT 라이선스) 에이전트 하네스(Agent Harness) 다. 단순한 LLM + 도구 루프를 넘어, 복잡하고 장기적인 작업을 처리하기 위한 네 가지 핵심 요소를 내장하고 있다.
플래닝 도구 : 에이전트가 복잡한 목표를 단계별 할 일 목록으로 분해하고, 진행 상황을 추적하며, 새로운 정보를 기반으로 계획을 조정할 수 있다. 이 플래닝은 Claude Code에서 영감을 얻었으며, 심지어 실질적인 동작을 하지 않는 “no-op” 도구 호출도 에이전트를 궤도에서 이탈하지 않게 유지하는 컨텍스트 엔지니어링 전략으로 활용된다.
가상 파일 시스템 : 대용량 도구 결과물을 컨텍스트 창이 아닌 파일 시스템에 자동으로 오프로드한다. Salesforce 기록이 매우 길거나 Gong 트랜스크립트가 방대한 경우, 이를 모두 컨텍스트 창에 넣으면 모델의 성능이 저하된다. Deep Agents는 이 문제를 자동으로 처리한다. 백엔드는 인메모리, 로컬 디스크, LangGraph Store, 샌드박스 등으로 교체 가능한 플러그인 구조다.
서브에이전트 스폰 : 메인 에이전트가 특화된 서브에이전트를 생성할 수 있다. 각 서브에이전트는 격리된 컨텍스트와 제한된 도구 세트를 가지며, 병렬로 실행될 수 있다.
장기 메모리 : LangGraph의 Memory Store를 통해 스레드 간에 정보를 저장하고 검색할 수 있다. 이 GTM 에이전트에서는 담당자별 스타일 관찰을 저장하는 데 활용된다.
GTM 에이전트에서 Deep Agents가 해결한 문제
GTM 에이전트의 입력 데이터는 본질적으로 불규칙(spiky) 하다. 미팅 데이터, CRM 이력, 웹 조사 결과는 크기와 구조가 매우 다양하다. Deep Agents는 대용량 도구 결과물을 가상 파일 시스템으로 자동 오프로드하기 때문에, 팀은 자체적인 트런케이션 및 검색 레이어를 구축할 필요가 없었다.
또한 하네스의 네이티브 플래닝 도구를 사용하여 일관된 체크리스트를 강제할 수 있었다. 체크리스트는 다음 순서를 따른다.
발송 거부 체크 → 조사 → 드래프트 → 추론 → 팔로업
이 순서를 코드가 아닌 에이전트의 플래닝 도구로 강제함으로써, 실행 과정이 훨씬 디버깅하기 쉬워지고 에이전트가 무작위로 방황하는 현상이 줄어들었다.
LangGraph와의 관계
Deep Agents는 LangGraph 위에 구축되어 있다. 즉, Deep Agents로 만든 에이전트는 LangGraph의 스트리밍, 체크포인터, 지속성, Human-in-the-Loop 기능을 모두 그대로 활용할 수 있다. create_deep_agent()가 반환하는 것은 컴파일된 LangGraph 그래프이며, 이를 통해 에이전트가 중간에 실패하더라도 재시작하여 이전 상태에서 계속 작업할 수 있다.
1
2
3
4
5
6
7
8
9
from langchain.chat_models import init_chat_model
from deepagents import create_deep_agent
agent = create_deep_agent(
model=init_chat_model("openai:gpt-4o"),
tools=[salesforce_tool, gong_tool, exa_tool],
system_prompt="You are a GTM research agent...",
subagents=[sales_research_subagent, deployed_engineer_subagent],
)
9. 메모리 시스템: 에이전트가 학습하는 방법
GTM 에이전트를 단순한 자동화 도구가 아닌 학습하는 시스템으로 만드는 핵심 메커니즘이 메모리 시스템이다.
피드백 루프의 작동 방식
영업 담당자가 Slack에서 에이전트의 드래프트를 수정하면, 시스템은 원본과 수정본을 비교한다. 변경 사항이 실질적인 경우(단순 오타 수정이 아닌 내용적 변경), LLM이 차이를 분석하고 구조화된 스타일 관찰을 추출한다.
이 분석은 세 가지 요소를 포함한다. 무엇이 변경되었는지(구체적인 변경 내용), 이 변경이 담당자의 선호에 대해 무엇을 의미하는지(스타일 또는 톤에 대한 인사이트), 그리고 해당 관찰을 뒷받침하는 실제 인용 예시가 선택적으로 저장된다.
이 관찰들은 PostgreSQL에 담당자별로 키가 설정되어 저장된다. 그리고 이후 모든 실행은 드래프팅 전에 이 관찰들을 읽어들인다.
자동 압축
이 시스템의 잠재적 문제 중 하나는 메모리가 시간이 지남에 따라 비대해질 수 있다는 것이다. LangChain은 주간 크론 잡(weekly cron) 을 통해 이 메모리들을 정기적으로 압축하여 블로트를 방지한다.
Human-in-the-Loop가 데이터 수집 메커니즘인 이유
각 담당자는 고유한 스타일적 선호도를 가지고 있다. 메모리 시스템은 이 개인화를 자동으로 학습하기 때문에, 사용할수록 에이전트는 각 담당자의 목소리에 더 가깝게 드래프트를 작성하게 된다. Human-in-the-Loop가 단순히 안전 메커니즘이 아니라 데이터 수집 메커니즘이기도 하다는 인식이 여기서 나온다. 담당자의 모든 수정 행동이 학습 신호가 된다.
10. 평가(Eval) 및 피드백 루프
LangChain이 이 프로젝트에서 강조하는 가장 중요한 운영 원칙 중 하나는 평가를 나중에 추가하는 것이 아니라 처음부터 설계에 포함시키는 것이었다.
평가 설계 프로세스
새로운 워크플로에 대한 프로덕션 코드를 작성하기 전에, 팀은 먼저 성공이 어떻게 보이는가를 정의하고 그것을 중심으로 작은 시나리오 라이브러리를 구축했다. 초기 시나리오 라이브러리는 실제 담당자들이 직면하는 상황들을 기반으로 했다. 기초 기능이 작동하면, 더 어려운 케이스들로 평가 세트를 확장했다. 에이전트 AI나 NLP 분야를 깊이 연구하는 연구자, 재참여를 시도하는 기존 고객, Gong 트랜스크립트가 있는 계정, 의료처럼 전문 용어가 많은 산업 등이 포함되었다.
모든 평가는 외부 API를 모킹하는 테스트 하네스를 통해 실행되기 때문에, 실제 데이터에 접촉하기 전에 통제된 환경에서 에이전트의 동작을 관찰할 수 있다.
두 가지 평가 레이어
규칙 기반 어설션 : 기본 사항들을 검증한다. 올바른 도구가 올바른 순서로 사용되었는가? 중복 드래프트가 생성되지 않았는가? 이런 규칙들은 확실하게 통과하거나 실패해야 하는 항목들이다.
LLM 판단 : 톤, 단어 수, 형식화를 점수로 평가한다. 규칙으로 정량화하기 어려운 질적 측면을 또 다른 LLM이 판단하도록 한다.
이 두 가지가 CI(지속적 통합) 파이프라인에서 전체 평가 스위트로 실행된다. 에이전트 동작에서 설명되지 않는 변동이 발생하면 조사할 가치 있는 버그로 취급한다.
실제 사용 데이터와의 통합
평가는 이야기의 절반만 말해줄 뿐이다. 실제로 중요한 것은 담당자들이 드래프트를 일상적으로 어떻게 사용하는가다. 팀은 모든 Slack 액션(발송, 수정, 취소)을 추적하고, 이를 LangSmith의 트레이스에 직접 연결한다. 시간이 지남에 따라 이 연결은 작성 패턴과 실제 결과물의 상관관계를 드러낸다. 어떤 스타일이 오픈율을 높이는가? 어떤 제목이 답장을 이끌어내는가? 충분한 담당자에 걸쳐 패턴이 나타나면, 그것을 에이전트의 기본 동작으로 코드화한다.
LangSmith 평가 스위트와 담당자 피드백 루프는 서로를 강화한다. 하나는 회귀를 잡고, 다른 하나는 개선을 이끈다.
11. 예상치 못한 사내 확산
GTM 에이전트는 처음에 주변 에이전트(Ambient Agent) 로 시작했다. 백그라운드 프로세스로 실행되어, 리드가 Salesforce에 나타나면 에이전트가 실행되고 드래프트가 담당자의 Slack에 전달되는 방식이었다. 트리거가 없고, 수동 작업도 없었다.
이후 팀은 SDR들이 에이전트와 직접 상호작용할 수 있는 대화형 Slack 인터페이스를 사이드 실험으로 구축했다. 예상치 못한 일이 일어났다. 이 인터페이스가 나머지 사내 팀으로 빠르게 퍼져나갔다.
에이전트가 이미 Salesforce, Gong, BigQuery, Gmail에 연결되어 있었기 때문에, 사람들은 애초에 설계하지 않은 활용 방법을 스스로 발견했다. 엔지니어들은 SQL을 작성하지 않고도 제품 사용 데이터를 조회하기 시작했다. 고객 성공 팀은 갱신 통화 전에 지원 이력을 파악하기 위해 에이전트를 활용했다. 계정 담당자들은 미팅 전에 Gong 트랜스크립트를 요약하기 위해 사용했다.
이 중 어떤 워크플로도 의도적으로 설계된 것이 아니었다. 에이전트에게 데이터 접근 권한이 있었고, 사람들이 최소 저항 경로를 스스로 발견했다. 여섯 개 탭을 열어놓고 전환하는 것보다, 봇에게 말하는 것이 훨씬 더 쉬웠기 때문이다.
12. 핵심 교훈
LangChain 팀이 처음부터 다시 시작하는 누군가에게 전하고 싶은 교훈들을 정리한다.
코드가 아닌 성공의 정의에서 시작하라
새로운 워크플로에 대한 프로덕션 코드를 작성하기 전에, 좋은 결과가 어떻게 보이는지를 먼저 정의하고 그것을 중심으로 소규모 시나리오 라이브러리를 구축하라. 에이전트가 성숙해지면서 이 세트가 확장된다. 무언가가 출시될 때쯤에는 회귀를 잡고, 드리프트에 플래그를 세우고, CI에서 자동으로 실행되는 평가 테스트 스위트가 이미 준비되어 있을 것이다.
Human-in-the-Loop는 안전을 넘어선다
HITL이 데이터 수집 메커니즘으로도 기능했다. 모든 담당자 액션(발송, 수정, 취소)이 학습할 수 있는 신호가 되었다. 메모리 시스템과 피드백 루프가 작동하는 것은 담당자들이 플로우 안에 있기 때문이다.
처음부터 시스템 오브 레코드에 에이전트를 연결하라
사내 전반에 걸친 유기적 확산은 에이전트가 이미 사람들이 필요로 하는 데이터에 접근 권한을 가지고 있었기 때문에 일어났다. 엔지니어나 고객 성공 팀이 이 도구를 사용할 것이라고 계획하지 않았지만, 그 접근 권한이 이미 거기 있었기 때문에 사용이 확산되었다.
장기 실행 워크플로에는 올바른 인프라가 필요하다
이 에이전트는 단순한 LLM 호출 한두 번으로는 처리할 수 없었다. 여러 소스에서 데이터를 가져오고, 이를 가로질러 추론하고, 서브에이전트를 병렬로 실행하고, 턴에 걸쳐 상태를 유지해야 했다. 이런 종류의 오케스트레이션을 위해 구축된 에이전트 하네스인 Deep Agents를 선택함으로써 인프라를 처음부터 다시 구축하는 수고를 덜 수 있었다.
아직 초기 단계임을 인식하라
GTM 에이전트는 오늘날 실제 워크플로를 처리하고 있다. 하지만 구축된 피드백 루프(메모리, 평가, 트레이스에 연결된 담당자 액션)가 앞으로 6개월 동안 이 에이전트를 의미 있게 더 좋게 만들 것이다. 에이전트는 완성품이 아닌 지속적으로 개선되는 시스템이다.
13. LangChain 생태계 관점에서의 의미
이 GTM 에이전트 사례는 LangChain이 단순히 프레임워크 제공자를 넘어 자사가 만든 도구를 직접 활용하는 실증 사례를 제시한다는 점에서 의미가 깊다.
LangChain 생태계의 세 계층 아키텍처가 실제로 어떻게 작동하는지를 이 사례가 구체적으로 보여준다.
LangChain 1.0 (프레임워크 레이어) : 에이전트가 사용하는 모든 도구들(Salesforce 커넥터, Gong 통합, Exa 검색 등)의 기반을 제공한다. 표준화된 인터페이스로 다양한 데이터 소스를 일관되게 연결할 수 있다.
LangGraph (런타임 레이어) : Deep Agents의 기반이 되는 런타임으로, 상태 관리, 스트리밍, 체크포인팅, 내구성 있는 실행을 담당한다. 에이전트가 중간에 실패하더라도 재시작하여 이전 상태에서 계속 작업할 수 있도록 한다.
Deep Agents (하네스 레이어) : LangGraph 위에서 동작하는 오피니언이 담긴 에이전트 하네스로, 플래닝, 파일 시스템, 서브에이전트, 컨텍스트 관리를 배터리 포함 방식으로 제공한다.
LangSmith (관찰 및 평가 레이어) : 에이전트의 모든 실행을 추적하고, 평가를 실행하며, 담당자 액션과 트레이스를 연결하여 지속적인 개선 루프를 가능하게 한다.
이 사례는 “LangChain의 도구가 잘 작동한다”는 것을 보여주는 것을 넘어, 프로덕션 AI 에이전트 구축의 전체 라이프사이클이 어떻게 보여야 하는지에 대한 구체적인 템플릿을 제시한다. 코드 이전에 성공 정의, HITL을 데이터 수집 메커니즘으로, 처음부터 평가 설계, 시스템 오브 레코드 연결 — 이 원칙들은 어떤 기업이 에이전트를 구축하든 적용할 수 있는 보편적 지침이다.
작성 일자: 2026-03-11