LangChain의 GTM 에이전트를 구축한 방법

Vishnu Suresh와 Jess Ou 작성

LangChain의 모든 아웃바운드(Outbound) 업무는 영업 담당자가 여러 탭을 번갈아 가며 확인하는 동일한 방식으로 시작되곤 했습니다. 계정 기록을 위한 Salesforce, 통화 이력을 위한 Gong, 연락처를 위한 LinkedIn, 그리고 맥락 파악을 위한 회사 웹사이트까지. 단 한 마디를 쓰기 전 15분 동안의 조사가 필요했고, 동료가 어제 이미 연락을 취했는지 쉽게 알 수 있는 방법도 없었습니다. 인바운드(Inbound) 후속 조치는 새로운 연락처가 생길 때마다 Apollo에 동일한 메시지를 수동으로 입력하는 것을 의미했습니다.

우리는 이 프로세스를 엔드 투 엔드(End-to-end)로 실행하는 GTM 에이전트를 구축했습니다. 이 에이전트는 새로운 Salesforce 리드(Lead)가 발생하면 트리거되어, 우리가 연락을 취해야 하는지 확인하고, 맥락(회의 이력 포함)을 수집한 뒤, 영업 담당자가 승인할 수 있도록 (이유와 출처가 포함된) Slack 초안을 보냅니다. 우리는 이를 Deep Agents를 기반으로 구축했는데, 이는 여러 도구와 방대한 양의 데이터를 안정적으로 오케스트레이션(Orchestrate)해야 하는 장기 실행형 다단계 프로세스이기 때문입니다.

주요 결과

• 2025년 12월부터 2026년 3월까지 리드에서 적격 기회(Qualified Opportunity)로의 전환율이 250% 상승하였으며, 동일 기간 동안 파이프라인 금액이 3배 더 증가했습니다.
• 12월 이후, 영업 담당자들은 의도가 낮은(Lower intent) 리드에 대한 후속 조치는 97%, 의도가 높은(Higher intent) 리드에 대한 후속 조치는 18% 늘렸습니다.
• 영업 담당자들은 각각 월 40시간을 확보했으며, 팀 전체로는 총 1,320시간을 절약했습니다.
• 영업 팀 구성원의 일간 활성 사용률(DAU) 50%, 주간 활성 사용률(WAU) 86%를 기록했습니다.

팀의 반응

GTM 에이전트는 SDR 에이전트로 시작하여 이후 더 넓은 범위의 GTM 팀에서 사용되었습니다.

제약 조건 및 성공 기준

코드를 작성하기 전에, 우리는 에이전트가 실제로 수행해야 할 작업을 정의했습니다.

우리는 두 가지 목표를 가졌습니다: 리드당 영업 담당자가 조사 및 초안 작성에 소비하는 시간을 줄이는 것, 그리고 마케팅에서 생성된 인바운드의 전환율을 높이는 것입니다. 아웃바운드 조사 및 초안 작성은 자동화할 수 있을 만큼 체계적이지만, 이는 시스템이 안전하고, 감사 가능하며(Auditable), 사용함에 따라 개선될 때만 가능합니다.

타협할 수 없는 원칙 (Non-negotiables)

Human-in-the-loop (인간 참여형): 영업 담당자(Rep)의 명시적인 검토와 승인 없이는 아무것도 발송되지 않습니다. 타이밍이 맞지 않은 이메일 단 한 통이 수개월간 쌓아온 관계를 망칠 수 있기 때문입니다. 연락 이력 지식 (Contact history knowledge): 에이전트는 초안을 작성하기 전에 영업 담당자나 팀원이 이미 연락을 취했는지 여부를 확인해야 했습니다.

핵심 역량 (Core capabilities)

관계 인지 개인화 (Relationship-aware personalization): 초안은 계정의 현재 상태(기존 고객 vs. 잠재 고객 vs. 콜드 리드)를 반영해야 하며, 모든 리드를 동일하게 취급해서는 안 됩니다. 설명 가능성 (Explainability): 영업 담당자는 주요 입력값을 확인하고 에이전트가 왜 특정 관점을 선택했는지 이해할 수 있어야 하며, 이를 통해 내용을 개선하고 피드백을 제공할 수 있어야 합니다. 학습 루프 (Learning loop): 에이전트는 시간이 지남에 따라 영업 담당자의 수정 사항으로부터 학습해야 하며, 이를 통해 누군가 수동으로 프롬프트(Prompt)를 업데이트하지 않아도 초안의 품질이 향상되어야 합니다.

측정 (Measurement)

모든 영업 담당자의 행동(발송, 수정, 취소)은 LangSmith에 기록되며 하위 트레이스(Trace)에 연결됩니다. 이를 통해 품질을 평가하고, 성능 저하(Regression)를 포착하며, 무엇이 효과적인지 정량화할 수 있습니다.

범위 확장: 계정 인텔리전스 (Account intelligence)

일회성 초안 작성을 넘어, 우리는 에이전트가 딜 리스크(Deal risks), 확장 기회(Expansion opportunities), 경쟁사의 움직임과 같은 계정 수준의 신호를 선제적으로 제시하여 영업 담당자가 매주 어디에 집중해야 할지 알 수 있기를 원했습니다.

우리가 구축한 것 (What we built)

GTM 에이전트는 두 가지 일을 수행합니다: (1) 리드를 조사하고 개인화된 이메일 초안을 작성하며, (2) 웹 활동, 개발자 생태계, 제품 사용량, 마케팅 접점을 아우르는 계정 수준의 신호를 집계하여 영업 담당자에게 집중할 곳을 보여줍니다. 이러한 의도 데이터(Intent data)를 영업 담당자의 계정과 연결함으로써, 의미 있는 활동을 포착하고, 딜 리스크와 경쟁사의 움직임을 표시하며, 다음에 연락하기에 가장 이상적인 대상이 누구인지 명확히 해줍니다.

우리는 에이전트를 다음과 같은 데이터 소스에 연결했습니다:

인바운드 리드 처리 (Inbound lead processing)

Salesforce에 새로운 리드 (lead)가 나타나면, 에이전트가 즉시 업무를 인계받습니다. 에이전트가 가장 먼저 하는 일은 무언가를 보내지 말아야 할 이유를 찾는 것입니다. 만약 누군가가 방금 지원 티켓 (support ticket)을 제출했거나, 팀원이 이번 주 초에 이미 연락을 취했다면, 자동화된 이메일을 보내는 것은 실수가 될 것입니다. 에이전트는 신중하도록 프로그래밍되어 있습니다.

이러한 확인 절차를 통과하면, 에이전트는 영업 담당자 (rep)가 과거에 수동으로 수행하던 것과 동일한 조사를 수행합니다. 즉, Salesforce의 전체 레코드 (record)를 가져오고, Gong 트랜스크립트 (transcripts)를 읽으며, 잠재 고객 (prospect)의 LinkedIn 프로필을 확인합니다. 만약 내부 이력이 많지 않다면, Exa를 사용하여 웹으로 나가 해당 기업이 현재 AI를 통해 무엇을 하고 있는지 파악합니다.

이메일 초안을 작성하는 방식은 관계의 상태에 따라 달라집니다. 에이전트는 초안을 작성하기 전에 로드하는 플레이북 (playbook)인 정의된 아웃바운드 스킬 (outbound skill)을 따릅니다. 이 스킬은 워밍 (warm) 케이스와 콜드 (cold) 케이스를 모두 다룰 수 있도록 설계되었습니다. 기존 고객은 워밍 잠재 고객과는 다른 내용을 받게 되며, 워밍 잠재 고객은 콜드 연락처와는 또 다른 내용을 받게 됩니다. 콜드 아웃리치 (cold outreach)의 경우, 에이전트는 우리가 스킬 내에 정의한 플레이북을 따라 간결하고 조사에 기반한 내용을 유지합니다.

영업 담당자는 Slack DM을 통해 전송, 수정 또는 취소 버튼이 포함된 완성된 초안을 확인합니다. 또한 에이전트의 추론 과정 (reasoning)을 볼 수 있어, 왜 특정 관점을 취했는지 명확히 알 수 있습니다. 담당자가 초안을 전송하면, 에이전트는 잠재 고객을 선택적으로 등록할 수 있는 일련의 후속 이메일 (follow-up emails)을 대기열에 추가합니다.

에이전트를 개선하면서, 우리는 실버 리드 (silver leads)에 대해 48시간의 SLA (Service Level Agreement)를 추가했습니다. 만약 해당 시간 내에 담당자가 초안을 승인하거나 거절하지 않으면, 이메일이 자동으로 발송됩니다. 이를 통해 응답 없이 놓칠 수 있었던 리드들에 대한 후속 조치율 (follow-up rate)이 유의미하게 증가했습니다.

계정 인텔리전스 (Account intelligence)

팀 규모가 커짐에 따라, 영업 담당자들은 각각 50개에서 100개 이상의 계정 (accounts)을 담당하기 시작했습니다. 이 정도 규모에서는 상황이 조용해지거나 확장 기회 (expansion opportunities)를 놓치기 쉽습니다.

매주 월요일 아침, 에이전트는 Salesforce와 BigQuery에서 데이터를 가져옵니다. 그런 다음 펀딩 라운드 (funding rounds), 제품 출시 (product launches), 그리고 새로운 AI 이니셔티브 (AI initiatives)와 같은 외부 세계의 정보를 확인합니다. 우리는 두 그룹의 대상, 즉 영업 팀 (sales team)과 배포된 엔지니어링 팀 (deployed engineering team)에 맞춰 보고서를 맞춤화했습니다. 이들은 서로 다른 데이터 포인트 (data points)에 관심을 갖기 때문입니다.

영업 팀을 위해, 에이전트는 제품 사용량 (product usage), 개발자 생태계 (developer ecosystems), 웹 활동 (web activity), 채용 트렌드 (hiring trends), 그리고 기업 뉴스 (company news) 전반에 걸친 신호들을 집계하여 확장 기회 (expansion opportunities)를 드러냅니다. 에이전트는 경영진의 이동, 패키지 설치 급증, 그리고 기업이 AI 엔지니어를 적극적으로 채용하고 있는지 또는 에이전틱 시스템 (agentic systems)을 구축하고 있는지 여부를 표시합니다. 이는 해당 기업이 확장할 준비가 되었다는 강력한 신호입니다. 또한 우리가 새로운 기능을 출시할 때, 최근 활동이 새로운 기능과 잘 일치하는 계정 (accounts)을 매칭하여 잠재적인 적합 사례를 식별합니다. 그리고 단순히 계정이 활성 상태라는 것을 아는 것만으로는 충분하지 않기 때문에, 어떤 개인이 가장 활발하게 참여하고 있는지 드러내고 다음에 누구에게 연락해야 할지를 제안합니다.

배포된 엔지니어들을 위해, 초점은 계정 상태 (account health)로 전환됩니다. 에이전트는 BigQuery에서 제품 사용량을 가져오고, 최근 고객 통화의 주요 내용, 다가오는 갱신 날짜 (renewal dates), 그리고 고객의 크레딧 (credits)이 소진될 위기에 처한 사례들을 강조합니다. 또한 최근 통화에서 발생한 미결 질문과 해결되지 않은 스레드 (unresolved threads)를 드러냅니다. 목표는 실제로 사람이 개입해야 하는 사항을 표시하는 것이며, 이를 통해 팀이 일요일 저녁에 대시보드 (dashboards)를 뒤지는 데 시간을 허비하지 않도록 하는 것입니다.

구축 방법

에이전트는 여러 소스에서 데이터를 가져오고, 이를 바탕으로 추론하며, 개인화된 결과물을 생성해야 했습니다. 이는 단순한 LLM 호출 (LLM call)만으로는 신뢰성 있게 처리할 수 있는 수준 그 이상입니다.

우리는 다단계 오케스트레이션 (multi-step orchestration)을 위해 Deep Agents를 선택했습니다. 입력 데이터가 본질적으로 급격한 변동성 (spiky)을 보이기 때문입니다. 회의 데이터, CRM 이력, 웹 조사 결과는 크기와 구조가 매우 다양합니다. Deep Agents를 사용하면 대규모 도구 결과물 (tool results)이 가상 파일 시스템 (virtual filesystem)으로 자동 오프로드되므로, 별도의 절단 (truncation) 및 검색 (retrieval) 레이어를 직접 구축할 필요가 없었습니다. 또한, 우리는 프레임워크의 네이티브 플래닝 도구 (planning tooling)를 사용하여 일관된 체크리스트(전송 금지 확인 → 조사 → 초안 작성 → 근거 제시 → 후속 조치)를 강제했으며, 이를 통해 실행 과정을 디버깅하기 쉽게 만들고 에이전트가 경로를 이탈하는 현상 (agent wandering)을 줄였습니다.

우리는 영업 담당자들이 실제로 에이전트를 어떻게 사용하는지 이해하고, 에이전트가 시간이 지남에 따라 개선되고 있는지 측정하기 위해 에이전트를 LangSmith에 연결했습니다. 이는 나중에 사후적으로 적용하는 것이 아니라 처음부터 평가 (evaluations) 체계를 구축해야 함을 의미했으며, 프롬프트를 반복 수정하거나 모델 버전을 교체할 때 회귀 (regressions) 문제를 포착하는 데 결정적인 역할을 했습니다.

에이전트 패턴 (Agent patterns)

GTM 에이전트를 프로덕션 환경으로 전환하면서 우리가 해결해야 했던 두 가지 문제, 즉 에이전트가 사용자로 하여금 학습하게 만드는 방법과 대규모 환경에서 실행 효율성을 유지하는 방법이 드러났습니다.

메모리 (Memory)

영업 담당자가 Slack에서 초안을 수정하면, 시스템은 원본과 수정된 버전을 비교합니다. 변경 사항이 실질적이라면, LLM이 차이점 (diff)을 분석하여 구조화된 스타일 관찰 사항을 추출합니다. 즉, 무엇이 바뀌었는지, 그것이 담당자의 선호도에 대해 무엇을 시사하는지, 그리고 선택 사항으로 인용된 예시를 추출합니다. 이러한 관찰 사항은 PostgreSQL에 담당자별 키(key)로 저장되며, 향후 모든 실행 단계에서 초안을 작성하기 전에 이를 읽어옵니다.

각 담당자는 어조와 간결함에 대한 스타일 선호도를 가지고 있습니다. 피드백 루프는 자동입니다. 모든 수정 사항은 에이전트를 학습시키며, 다음 초안에 이를 반영합니다. 매주 실행되는 크론 (cron) 작업은 이러한 메모리들이 시간이 지남에 따라 비대해지는 것을 방지하기 위해 이를 압축 (compacts)합니다.

서브에이전트 위임 (Subagent delegation)

계정 인텔리전스 (Account intelligence)는 컴파일된 서브에이전트 (subagents)를 통해 실행됩니다. 서브에이전트는 제한된 도구 세트 (tool sets)와 메인 에이전트와의 계약 역할을 하는 구조화된 출력 스키마 (structured output schemas)를 가진 경량 에이전트입니다. 영업 조사 (sales research) 서브에이전트는 Apollo, Exa, BigQuery에 접근하여 구조화된 잠재 고객 (prospect) 및 시장 컨텍스트 (market context)를 반환합니다. 배포 엔지니어 (deployed engineer) 서브에이전트는 Salesforce, Gong 및 지원 도구들을 사용하여 사용 트렌드, 오픈 티켓 (open tickets), 확장 신호 (expansion signals)를 반환합니다.

부모 에이전트 (parent agent)는 계정당 하나의 서브에이전트를 생성하여 도구를 격리하고 출력을 예측 가능하게 유지합니다. 서브에이전트는 독립적으로 실행되므로 병렬로 실행할 수 있습니다. LangSmith Deployment는 수평적 확장 (horizontal scaling)과 내구성 있는 실행 (durable execution)을 처리하므로, 볼륨이 증가하더라도 시스템의 신뢰성을 유지할 수 있습니다.

평가 (Evals) 및 피드백

새로운 워크플로우를 위한 프로덕션 코드를 작성하기 전에, LangSmith에서 성공의 기준이 무엇인지 정의합니다. 저희는 영업 담당자들이 실제로 직면하는 상황에 기반한 대표적인 시나리오 라이브러리를 작게 시작하여, 이를 사용하여 초기 에이전트나 기능을 구축하고, 확장하기 전에 기본 사항이 제대로 작동하는지 확인했습니다.

기능이 정상화된 후에는 LangSmith의 평가 세트를 확장하여 더 어려운 케이스들을 다루었습니다. 에이전틱 AI (agentic AI)나 NLP에 깊이 관여하는 연구자, 재참여를 시도 중인 기존 고객, 기존 Gong 트랜스크립트 (transcripts)가 있는 계정, 헬스케어와 같이 전문 용어가 많은 수직 시장 (verticals) 등이 포함됩니다. 모든 과정은 외부 API를 모킹 (mock)하는 테스트 하네스 (test harness)를 통해 실행되므로, 실제 데이터에 닿기 전에 통제된 환경에서 동작을 관찰할 수 있습니다.

저희는 두 가지 수준에서 평가합니다. 첫째, 규칙 기반 어설션 (rule-based assertions)이 올바른 도구 사용, 올바른 순서, 중복 초안 없음과 같은 기본 사항을 체크합니다. 둘째, LLM 심판 (LLM judge)이 톤 (tone), 단어 수, 포맷팅을 점수화합니다. 이 두 가지 모두 CI 내의 전체 평가 스위트 (eval suite)의 일부로 실행되며, 에이전트 동작에서 설명되지 않는 드리프트 (drift)가 발생하면 조사할 가치가 있는 버그로 취급합니다.

하지만 평가 (evals)만으로는 전체 상황을 파악할 수 없습니다. 실제로 중요한 것은 영업 담당자 (reps)들이 일상적으로 초안을 어떻게 사용하는가입니다. 우리는 모든 Slack 작업 (전송, 수정, 취소)을 추적하고 이를 LangSmith의 트레이스 (trace)에 직접 연결합니다. 시간이 흐르면서, 이를 통해 작성 패턴과 실제 결과 사이의 상관관계를 파악할 수 있게 됩니다. 즉, 어떤 스타일이 오픈율을 높이는지, 어떤 제목이 답장을 이끌어내는지 알 수 있습니다. 충분한 수의 영업 담당자들에게서 공통된 패턴이 나타나면, 이를 에이전트의 기본 동작으로 코드화 (codify)합니다.

LangSmith 평가 스위트 (eval suite)와 영업 담당자의 피드백 루프 (feedback loop)는 서로를 강화합니다. 하나는 퇴보 (regressions)를 잡아내고, 다른 하나는 개선을 이끕니다.

영업 팀을 넘어선 도입

GTM 에이전트는 백그라운드 프로세스로 실행되는 앰비언트 에이전트 (ambient agent)로 시작되었습니다. Salesforce에 리드 (lead)가 나타나면 에이전트가 실행되고, 영업 담당자의 Slack으로 초안이 전달됩니다. 트리거 (trigger)도, 수동 작업도 필요 없습니다.

나중에 우리는 부수적인 실험으로서 대화형 Slack 인터페이스를 구축했는데, 이는 주로 SDR (Sales Development Representatives)들이 에이전트와 직접 상호작용할 수 있는 방법을 제공하기 위함이었습니다. 우리가 예상하지 못했던 점은 이것이 회사 전체로 얼마나 빠르게 확산되었는가 하는 점이었습니다. 에이전트가 이미 Salesforce, Gong, BigQuery, Gmail에 연결되어 있었기 때문에, 사람들은 우리가 설계하지 않은 용도들을 찾아냈습니다. 엔지니어들은 SQL을 작성하지 않고도 제품 사용량을 확인했습니다. 고객 성공 (Customer Success) 팀은 갱신 (renewal) 통화 전에 지원 이력을 확인했습니다. 어카운트 이그제큐티브 (Account Executives)들은 회의 전에 Gong 트랜스크립트 (transcripts)를 요약했습니다.

우리는 이러한 워크플로우 (workflows)를 의도적으로 구축하지 않았습니다. 에이전트에게 권한이 있었고, 사람들은 가장 저항이 적은 경로를 찾아낸 것입니다. 봇과 대화하는 것이 6개의 서로 다른 탭을 여는 것보다 쉬웠기 때문입니다.

다른 팀들이 GTM 에이전트를 어떻게 사용하고 있는지는 후속 포스트에서 다루겠습니다.

학습 내용 (Learnings)

처음부터 시작하는 사람에게 해주고 싶은 몇 가지 조언은 다음과 같습니다: