Apollo가 Deep Agents와 LangSmith로 GTM AI를 구동하는 방법

TMT

https://www.langchain.com/blog/how-apollo-rebuilt-its-ai-assistant-on-deep-agents-to-power-the-full-gtm-loop

Apollo는 잠재 고객 발굴부터 연락처 데이터 보강, 아웃리치 시퀀스, 딜 관리, 분석까지 영업 사이클 전체를 아우르는 GTM(go-to-market) 플랫폼입니다. Apollo는 AI 어시스턴트의 기반으로 Deep Agents를 사용하고, 트레이싱·평가·관측에는 LangSmith를 함께 사용합니다.

과제: 너무 많은 제품, 너무 많은 단계

Apollo는 거의 10년에 걸쳐 가장 포괄적인 GTM 플랫폼 중 하나를 만들어 왔는데, 그 제품 폭이 오히려 문제가 되기 시작했습니다. 최근 설문에서 고객들은 제품이 버겁게 느껴진다고 답했습니다. 사실상 하나의 목표를 실행하는 데 모듈과 단계가 너무 많고 수작업 조율까지 필요하다는 것이었습니다.

새 잠재 고객 아웃리치 캠페인 하나를 시작하려면 리드를 찾고, 연락처 데이터를 보강하고, 시퀀스 초안을 쓰기 위해 별도 모듈들을 일일이 오가야 했고, 성과를 측정하려면 또 다른 대시보드로 이동해야 했습니다.

Claude나 ChatGPT 같은 요즘 에이전트는 의도만 말하면 에이전트가 방법을 알아서 찾아 준다는 사용자 기대를 만들어 놓았습니다. Apollo는 자사 플랫폼이 가진 풍부한 컨텍스트 데이터와 도구 전반에 이와 같은 사용자 경험을 그대로 가져오고 싶었습니다. 그 답으로 만든 것이 Apollo AI 어시스턴트입니다. 사용자가 자연어로 GTM 목표를 말하면 어시스턴트가 '찾기-보강-접촉-측정' 루프 전체를 처음부터 끝까지 실행해 주는 채팅 기반 인터페이스입니다.

슈퍼바이저 계층 구조에서 Deep Agents로: 목표 기반 실행을 위한 재설계

Apollo 멀티 에이전트 시스템의 첫 버전은 LangGraph 위에 슈퍼바이저 기반 아키텍처로 구축했습니다. 주 에이전트가 작업을 전문화된 서브 에이전트들에게 라우팅하고, 각 서브 에이전트가 워크플로의 한 부분씩을 담당하는 구조였습니다. 동작은 했지만, LangGraph의 결정적(deterministic) 그래프 구조는 팀이 만들고자 하는 에이전트 경험에 맞지 않았습니다.

Apollo의 엔지니어링 매니저 Anshul Pahwa는 *"새 유스케이스가 생길 때마다 서브 에이전트를 새로 작성하고, 슈퍼바이저에 연결하고, 정해진 경로를 따르는지 확인해야 했습니다"*라고 말했습니다.

사용자 입장에서 이 아키텍처는 의도를 확인하는 프롬프트가 자꾸 뜨는 경험으로 이어졌습니다.

Apollo는 Deep Agents와 Anthropic의 Claude Agent SDK 두 가지 방향을 검토했습니다. 비교 끝에 모델 중립성을 이유로 Deep Agents를 선택했습니다.

*"Claude SDK를 쓰면 Anthropic 모델에 묶이게 됩니다. 그러면 문이 영영 닫혀 버리죠. Deep Agents는 여러 LLM 벤더를 쓸 수 있는 문을 열어 둡니다"*라고 Anshul은 설명했습니다.

새 Deep Agents 아키텍처에서는 사용자가 말한 목표에 따라 동적으로 선택되는 스킬 라이브러리가 어시스턴트를 움직입니다. 에이전트가 스스로 계획을 세우고 해당되는 스킬을 골라 실행하므로, Apollo 엔지니어가 경로를 미리 지정할 필요가 없습니다.

Image

현재 스킬에는 잠재 고객 발굴, 시퀀스 생성, 계정·연락처 리서치, 이메일 도달률(deliverability), 분석, 계정 스코어링, 구매 의도 신호 감지 등이 있습니다.

새 아키텍처로 바꾼 뒤 지연 시간이 개선되었고 사용자가 마주치는 확인 프롬프트 수도 크게 줄었습니다. *"훨씬 자연스럽게 느껴집니다"*라고 Anshul은 말했습니다.

개발 주기도 짧아졌습니다. 슈퍼바이저 아키텍처에서는 새 에이전트 하나를 세우려면 서브 에이전트를 작성하고 슈퍼바이저와 통합한 다음, 첫 시도에 20~30% 수준인 사전 배포 정확도를 Apollo가 출시 기준으로 삼는 80%까지 끌어올리는 긴 평가 단계를 거쳐야 했습니다.

평평한 스킬 아키텍처에서는 팀이 내부용 메타 스킬을 만들었습니다. 문제 정의를 주면 에이전트가 아키텍처 계획을 생성하고, 시니어 엔지니어가 검토하고, 다른 에이전트가 실제 구현을 수행합니다. *"초기 개발부터 출시까지 드는 작업량이 80~85% 정도 줄었습니다"*라고 Anshul은 전했습니다.

AI Watchtower: LangSmith 위에 세운 6단계 평가 전략

Apollo가 LangSmith를 쓰기 시작한 것은 자체 관측 도구의 한계에 부딪히고 나서입니다. 기존 멀티 에이전트 아키텍처에서는 특정 스레드 안에서 무슨 일이 벌어지는지 — 어떤 도구가 어떤 순서로 호출됐고, 지연 시간은 얼마였고, 어디서 잘못됐는지 — 파악하기가 거의 불가능했습니다.

이제 LangSmith는 AI 팀 모든 엔지니어의 기본 디버깅 화면입니다. 프로덕션에서 타임아웃이나 오류가 나면 엔지니어는 GCS 로그, Mongo 데이터, 여러 다운스트림 시스템을 대조하는 대신 스레드 ID를 가져와 정확히 어느 단계가 실패했는지 추적합니다.

Apollo는 자사의 6단계 평가 프레임워크를 AI Watchtower라고 부릅니다.

  1. 품질 차원: 코드를 한 줄이라도 쓰기 전에 정확성, 톤, 관련성 같은 3~5개 차원의 루브릭을 정의하고 구체적인 예시와 함께 1~5점으로 채점합니다. 출시 전에는 결과물 50~200개를 독립된 검토자 두 명이 평가하는 사전 평가를 반드시 거칩니다.
  2. 엔드투엔드 품질 테스트: 항상 통과해야 하는 골든 시나리오입니다. 프롬프트나 모델 설정을 건드리는 모든 PR과 모든 배포에서 실행합니다.
  3. 라이브 트레이스: 신호가 감지되면 요청별로 전체 프롬프트, 컨텍스트, 도구 호출, 출력, 지연 시간을 담아 LangSmith로 디버깅합니다. 새 제품이라면 첫날부터 필수입니다.
  4. 라이브 인사이트: 샘플링한 트래픽에 대해 LLM 심판(LLM-as-judge) 점수, 거부율, 지연 시간이 시간에 따라 어떻게 변하는지 보여주는 집계 품질 지표입니다. 의미 있는 하락이 나타나면 3단계 드릴다운(카테고리 → 하위 카테고리 → 세그먼트)을 수행하고 샘플링 비율을 일시적으로 50~100%까지 올립니다.
  5. 펄스 리포트: 모든 계층을 종합한 주간 스냅숏으로, 요금제 등급·회사 규모·업종별 코호트 분석을 담습니다.
  6. 고객 피드백: 좋아요/싫어요(제품 내 사용자 피드백)는 기능과 같은 PR로 함께 배포합니다. 싫어요 이벤트는 몇 분 안에 일일 분류 큐로 들어갑니다. 최근 7일 구간에서 싫어요 비율이 8%를 넘는 상태가 지속되면 P1 장애로 취급합니다.

모든 접점에서 하나의 어시스턴트: 헤드리스 확장

AI 어시스턴트는 처음에 UI에 내장된 제품으로 출발해, 사용자가 보고 있는 페이지에서 컨텍스트를 얻고 Apollo 인터페이스 안에서 액션을 수행했습니다. 목표 기반 스킬 주도 아키텍처로 옮기면서 어시스턴트를 UI에서 완전히 분리할 수 있게 되었습니다.

Apollo는 어시스턴트를 API와 MCP 서버로 노출할 수 있는 헤드리스 에이전트로 확장했습니다. 제품 내 채팅 경험을 움직이는 바로 그 어시스턴트가 이제 Claude, ChatGPT, Perplexity에서의 Apollo MCP 서버 연동은 물론, MCP 기반 상호작용의 컨텍스트 크기 비용을 줄이기 위해 만든 Apollo CLI까지 움직입니다.

Apollo의 엔지니어링 VP Himanshu Gahlot은 *"MCP 서버 쪽이 이렇게까지 커질 줄은 아무도 몰랐습니다. 여러 배포 채널을 실험하고 있었고 MCP는 그중 하나였을 뿐인데, 채택 속도가 정말 놀라웠습니다. Apollo의 GTM 운영자 사용자층이 우리 예상보다 기술적이라는 걸 보여준 셈이죠"*라고 말했습니다.

4만 개가 넘는 팀이 Apollo MCP로 개발하고 있고, Apollo API를 쓰는 50만 개 이상의 팀을 빠르게 따라잡는 중입니다. Apollo API는 매달 2억 3천만 건이 넘는 API 호출을 처리합니다.

앞으로의 방향: 자율 GTM 에이전트

팀은 두 가지 큰 확장에 투자하고 있습니다.

  1. 어시스턴트 스킬 라이브러리의 깊이와 폭 확대. 기존 스킬을 더 정확하게 실행하고 새로운 유스케이스까지 커버하기 위함입니다.
  2. 자율 에이전트. 어시스턴트가 헤드리스 API로 제공되므로 Apollo 사용자는 에이전트를 일정에 맞춰 돌리거나 상시 백그라운드 프로세스를 맡길 수 있습니다. 예를 들어 Slack이나 다른 연동 도구에서 어시스턴트에게 매일 아침 ICP에 가장 잘 맞는 리드 50개를 전달하라고 지시할 수 있습니다. Apollo UI를 열 필요도 없이 말입니다.

*"고객이 있는 곳이라면 어디든 함께하고 싶습니다. AI 어시스턴트가 고객이 이미 쓰는 도구 안에 동료처럼 앉아 있는 모습이죠"*라고 Anshul은 마무리했습니다.

Edit this page