How we built LangChain’s GTM Agent
Quick Summary
LangChain은 리드 조사, 개인화 이메일 초안, 계정 신호 분석을 자동화하되 승인·근거·평가 체계를 붙인 GTM 에이전트로 영업 생산성과 전환율을 크게 높였다.
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
LangChain은 리드 조사, 개인화 이메일 초안, 계정 신호 분석을 자동화하되 승인·근거·평가 체계를 붙인 GTM 에이전트로 영업 생산성과 전환율을 크게 높였다.
📌 핵심 요약
- LangChain의 영업 담당자들은 기존에 Salesforce, Gong, LinkedIn, 회사 웹사이트를 오가며 리드마다 약 15분씩 조사했고, 팀원이 이미 연락했는지 확인하기도 어려웠다.
- GTM 에이전트는 Salesforce의 새 리드를 트리거로 삼아 연락해도 되는지 먼저 점검하고, 미팅 이력과 계정 정보를 모은 뒤, 근거와 출처가 포함된 Slack 초안을 담당자에게 보낸다.
- 시스템은 사람의 명시적 승인, 연락 이력 확인, 관계 상태에 따른 개인화, 초안 선택 이유의 설명 가능성, 담당자 수정 내역을 반영하는 학습 루프를 핵심 조건으로 설계됐다.
- 도입 결과 2025년 12월부터 2026년 3월까지 리드의 적격 기회 전환율이 250% 상승했고, 같은 기간 파이프라인 금액은 3배가 되었으며, 담당자 1인당 월 40시간을 절약했다.
- 초기 SDR용 에이전트였던 시스템은 계정 인텔리전스, 배포 엔지니어 지원, Slack 대화형 인터페이스로 확장되며 영업 외 조직에서도 제품 사용량 확인, 통화 요약, 지원 이력 조회 등에 활용됐다.
🧩 주요 포인트
- LangChain의 영업 담당자들은 기존에 Salesforce, Gong, LinkedIn, 회사 웹사이트를 오가며 리드마다 약 15분씩 조사했고, 팀원이 이미 연락했는지 확인하기도 어려웠다.
- GTM 에이전트는 Salesforce의 새 리드를 트리거로 삼아 연락해도 되는지 먼저 점검하고, 미팅 이력과 계정 정보를 모은 뒤, 근거와 출처가 포함된 Slack 초안을 담당자에게 보낸다.
- 시스템은 사람의 명시적 승인, 연락 이력 확인, 관계 상태에 따른 개인화, 초안 선택 이유의 설명 가능성, 담당자 수정 내역을 반영하는 학습 루프를 핵심 조건으로 설계됐다.
- 도입 결과 2025년 12월부터 2026년 3월까지 리드의 적격 기회 전환율이 250% 상승했고, 같은 기간 파이프라인 금액은 3배가 되었으며, 담당자 1인당 월 40시간을 절약했다.
- 초기 SDR용 에이전트였던 시스템은 계정 인텔리전스, 배포 엔지니어 지원, Slack 대화형 인터페이스로 확장되며 영업 외 조직에서도 제품 사용량 확인, 통화 요약, 지원 이력 조회 등에 활용됐다.
🧠 상세 정리
1. 반복적인 수동 조사에서 출발한 문제
LangChain의 아웃바운드 영업은 매번 비슷한 방식으로 시작됐다. 담당자는 Salesforce에서 계정 기록을 확인하고, Gong에서 통화 이력을 찾고, LinkedIn에서 연락처 정보를 보고, 회사 웹사이트에서 맥락을 모아야 했다. 한 문장을 쓰기 전까지 약 15분의 조사가 필요했고, 전날 팀원이 이미 연락했는지도 쉽게 알기 어려웠다. 인바운드 후속 조치도 새 연락처마다 Apollo에 같은 메시지를 수동으로 넣는 방식이어서, 시간이 많이 들고 일관성도 낮았다.
2. GTM 에이전트의 기본 흐름
LangChain이 만든 GTM 에이전트는 새 Salesforce 리드가 생기면 자동으로 실행된다. 먼저 연락을 해도 되는 상황인지 확인하고, 지원 티켓이나 최근 팀원의 연락처럼 보내면 안 되는 신호를 찾는다. 문제가 없으면 Salesforce 기록, Gong 미팅 이력, LinkedIn 정보, 필요한 경우 웹 검색을 통해 회사의 현재 상황을 조사한다. 이후 담당자가 검토할 수 있도록 Slack에 이메일 초안을 보내며, 초안에는 왜 그런 접근을 선택했는지에 대한 근거와 출처도 함께 포함된다.
3. 성공 기준과 안전장치
이 프로젝트의 목표는 리드별 조사와 초안 작성 시간을 줄이고, 마케팅에서 생성된 인바운드 리드의 전환을 높이는 것이었다. 그러나 자동화가 관계를 해치면 안 되기 때문에, 아무 메시지도 담당자의 명시적 검토와 승인 없이 보내지 않는 것이 핵심 원칙이었다. 또한 에이전트는 담당자나 팀원이 이미 연락했는지 확인해야 했고, 기존 고객인지, 따뜻한 잠재고객인지, 차가운 신규 연락처인지에 따라 다른 어조와 내용을 사용해야 했다. 모든 담당자 행동은 LangSmith의 trace에 연결되어 품질 평가와 회귀 확인, 효과 측정에 활용됐다.
4. 성과 지표와 현장 채택
본문은 GTM 에이전트가 실제 영업 성과에 의미 있는 영향을 냈다고 설명한다. 2025년 12월부터 2026년 3월까지 리드에서 적격 기회로 전환되는 비율은 250% 증가했고, 같은 기간 파이프라인 금액은 3배가 되었다. 담당자들은 낮은 의도 리드에 대한 후속 조치를 97%, 높은 의도 리드에 대한 후속 조치를 18% 늘렸다. 영업 담당자 1인당 월 40시간을 되찾았고, 팀 전체로는 1,320시간에 해당했으며, 영업팀의 일간 활성 사용률은 50%, 주간 활성 사용률은 86%로 제시됐다.
5. 인바운드 리드 처리와 개인화 초안
새 리드가 들어오면 에이전트는 먼저 보내지 말아야 할 이유를 찾는 보수적인 절차를 따른다. 누군가 방금 지원 티켓을 제출했거나 같은 주에 팀원이 이미 연락했다면 자동 이메일은 부적절할 수 있기 때문이다. 이후에는 담당자가 하던 조사를 대신 수행하고, 내부 이력이 부족할 경우 Exa를 사용해 회사가 현재 인공지능을 어떻게 다루고 있는지 외부 맥락을 찾는다. 초안 작성은 정의된 아웃바운드 스킬, 즉 플레이북을 기반으로 하며, 기존 고객·따뜻한 잠재고객·차가운 연락처를 서로 다르게 다룬다.
6. 계정 인텔리전스로의 확장
에이전트는 단발성 이메일 초안 작성에 머무르지 않고 계정 수준의 신호를 모아 담당자가 어디에 집중해야 할지도 보여준다. 매주 월요일 Salesforce와 BigQuery에서 데이터를 가져오고, 외부에서는 투자 유치, 제품 출시, 새로운 인공지능 관련 움직임을 확인한다. 영업팀에는 제품 사용량, 개발자 생태계, 웹 활동, 채용 흐름, 회사 뉴스를 종합해 확장 기회를 보여주고, 패키지 설치 급증이나 임원 이동 같은 신호도 표시한다. 배포 엔지니어에게는 제품 사용량, 최근 고객 통화의 핵심 내용, 갱신일, 크레딧 소진 위험, 미해결 질문을 중심으로 계정 건강 상태를 알려준다.
7. Deep Agents 기반 구현 방식
LangChain은 이 작업이 단순한 LLM 호출만으로 안정적으로 처리하기 어렵다고 판단했다. 입력이 미팅 데이터, CRM 기록, 웹 조사처럼 크기와 구조가 크게 달라지고, 여러 도구를 순서 있게 오케스트레이션해야 했기 때문이다. 그래서 Deep Agents를 사용해 긴 도구 결과를 가상 파일시스템으로 자동 분리하고, 별도의 절단·검색 계층을 직접 만들지 않아도 되게 했다. 또한 계획 도구를 활용해 보내지 말아야 할지 확인하고, 조사하고, 초안을 쓰고, 근거를 남기고, 후속 메일을 준비하는 체크리스트를 일관되게 유지했다.
8. 학습 루프와 서브에이전트
프로덕션 운영 과정에서 핵심 과제는 사용자의 수정에서 학습하는 것과 규모가 커져도 효율적으로 실행하는 것이었다. 담당자가 Slack에서 초안을 고치면 시스템은 원본과 수정본을 비교하고, 변화가 의미 있을 경우 LLM이 어조, 간결함, 선호 표현 같은 구조화된 스타일 관찰을 추출한다. 이 관찰은 담당자별로 PostgreSQL에 저장되고, 이후 초안 작성 전에 다시 읽혀 개인별 스타일을 반영한다. 계정 인텔리전스는 제한된 도구와 구조화된 출력 스키마를 가진 서브에이전트들이 계정별로 병렬 실행되며, 부모 에이전트는 이 결과를 예측 가능한 형태로 모은다.
9. 평가, 피드백, 조직 내 확산
새 워크플로의 프로덕션 코드를 쓰기 전부터 LangSmith에서 성공 기준을 정의한 점도 중요하게 다뤄진다. 처음에는 실제 담당자들이 마주치는 대표 상황을 작은 평가 세트로 만들고, 이후 연구자, 기존 고객 재접촉, Gong transcript가 있는 계정, 의료처럼 전문 용어가 많은 산업군 등 더 어려운 사례로 확장했다. 규칙 기반 검사는 도구 사용 순서와 중복 초안 같은 기본을 확인하고, LLM judge는 어조, 단어 수, 형식을 평가한다. 이후 Slack 대화형 인터페이스가 생기면서 엔지니어, 고객 성공, 계정 담당자들도 SQL 없이 제품 사용량을 확인하거나 통화 기록과 지원 이력을 빠르게 조회하는 방식으로 활용하기 시작했다.
🧾 핵심 주장 / 시사점
- 이 사례의 핵심은 영업 자동화를 완전 자동 발송이 아니라, 담당자가 검토할 수 있는 근거 있는 초안과 승인 흐름으로 설계했다는 점이다.
- 성과 개선은 단순히 초안 생성 속도에서 나온 것이 아니라, 연락 금지 조건 확인, 계정 맥락 수집, 개인화, 평가, 사용자 수정 학습이 하나의 폐루프로 연결된 데서 나왔다.
- 처음에는 특정 영업 업무를 위해 만든 에이전트였지만, 이미 여러 내부 데이터 소스에 연결되어 있었기 때문에 조직 구성원들이 자연스럽게 다른 업무에도 재사용했다.
✅ 액션 아이템
- 리드당 15분씩 소요되던 수작업 조사를 줄이기 위해 Salesforce 트리거 기반으로 연락 가능성·미팅 이력·계정 신호를 한 번에 모아 Slack 초안을 생성하는 GTM 설계를 정한다.
- 담당자 승인 중심을 유지하기 위해 연락 가능성 판단, 근거·출처 첨부, 초안 선택 이유 설명, 수정 반영 학습 루프를 운영 조건으로 고정한다.
- 도입 성과 표준으로 적격 기회 전환율 250%, 파이프라인 3배, 월 40시간 절감 지표를 기준 구간별로 설정해 초기 SDR용에서 영업 외 조직 확장 효과를 점검한다.
❓ 열린 질문
- 초기 SDR용 에이전트를 계정 인텔리전스·배포 엔지니어 지원으로 확장할 때 계정 데이터 접근 범위는 어디까지 설정해야 하는가?
- 리드의 중복 연락 방지를 위해 '이미 연락했는지' 판단 규칙을 관계 상태별로 다르게 둘지, 단일 기준으로 통합할지 어떤 근거가 필요한가?
- 파이프라인 3배 증대를 재현할 때 적격 기회 전환율 250%를 선행예측하기 위한 비교군 설계는 어떤 방식이 적절한가?