지식 시스템: AI 시대의 새로운 GTM 스택

URL: https://www.youtube.com/watch?v=GBg-fY82y84
날짜: 2026-08-28
채널: Tech Bridge
발표자: Jeffrey Wang, Exa 공동 창업자
러닝타임: 18분 20초

---

📌 핵심 질문 / AI 시대의 GTM은 어떤 엔지니어링 시스템이 되는가

==제품을 잘 만드는 일과 시장에 제품을 전달하는 일을 동시에 해야 하며, AI 시대에는 GTM(Go-To-Market)을 데이터와 에이전트로 구성된 엔지니어링 문제로 다룰 수 있다.==

• GTM의 고객 조사, 타깃 발굴, 담당자 탐색, POC(Proof of Concept) 제작은 모두 제품 세계와 잠재 고객 세계를 연결하는 데이터 문제다.
• 내부 데이터와 웹 전체의 외부 데이터를 합쳐 에이전트가 행동할 수 있는 실시간 세계 모델(live model of the world)을 만들어야 한다.
• ICP 대시보드, Request Lens, Slack 에이전트, Jeffbot, API, GUI, FDE(Forward Deployed Engineer)를 하나의 운영 스택으로 연결하면 소수의 인원으로도 생산적인 GTM 조직을 만들 수 있다.

Jeffrey Wang은 엔지니어가 제품만 만들면 회사가 완성된다고 생각하는 편향을 인정하면서도, 좋은 제품을 만드는 일과 사람들의 손에 제품을 쥐여주는 일을 분리할 수 없다고 말한다. Exa는 인터넷을 임베딩한 검색 엔진과 사내 시스템을 결합해 시장 전체를 구조화하고, 고객의 변화 신호를 포착하며, 창업자의 판단과 말투까지 보조하는 방식으로 GTM을 운영한다.

1. 엔지니어가 GTM을 엔지니어링 문제로 바라봐야 하는 이유

제품과 유통 중 하나만 고르는 논쟁은 잘못된 선택지이며, 회사는 두 기능을 함께 수행할 때만 성립한다.

1.1. 기술 청중을 위한 문제 설정

1. 발표의 대상과 구성

   1. 엔지니어 관점의 GTM: Jeffrey Wang은 기술 청중을 기준으로 GTM을 정리하도록 발표를 구성했다.
   2. 청중 확인: 기술 직군에 해당하는 사람에게 손을 들어 달라고 요청했고, 상당수가 기술 배경을 가진 청중임을 확인했다.
   3. 상호작용 약속: 발표 중 언제든 질문해 달라고 요청했다. 이미 많은 발표를 듣고 있는 청중을 지루하게 만들고 싶지 않다는 농담 섞인 태도를 보였다.

2. Exa의 위치

   1. 에이전트를 위한 검색 엔진: Exa는 웹에 접근하지 못하는 지능형 에이전트가 인터넷을 사용할 수 있게 하는 검색 엔진이다.
   2. MCP 웹 도구: Exa는 에이전트가 호출하는 웹 MCP(Model Context Protocol) 도구로 제공된다.
   3. 사용처: Cursor, Cognition을 비롯해 AI 생태계의 여러 제품이 Exa를 사용한다.

1.2. 제품 대 유통 논쟁의 허점

1. 제품만 중요하다는 주장

   1. 제품 우선 서사: 최근에는 제품만 잘 만들면 된다는 주장이 반복된다.
   2. 에이전트 구매자 가설: 에이전트가 제품을 직접 비교하고 가장 좋은 제품을 선택하므로 유통은 덜 중요하다는 논리가 나온다.

2. 유통만 중요하다는 주장

   1. 유통 우선 서사: 반대로 유통(distribution)만 잘하면 된다는 주장이 있다.
   2. Glean 논쟁: Twitter의 논쟁에서는 Glean이 유통을 잘하기 때문에 성공하는지, 아니면 제품이 도대체 무엇인지 모호한데도 유통으로 버티는지를 두고 의견이 갈린다.

3. 두 기능의 결합

   1. 경험에서 나온 결론: 최근 몇 년의 경험을 통해 제품과 GTM을 모두 제대로 해야 한다는 결론을 얻었다.
   2. 회사의 최소 조건: 제품을 만들고 품질을 확보하는 일에 더해 사람들의 손에 제품을 전달해야 한다. 둘 중 하나라도 빠지면 회사가 되지 않는다.

1.3. 엔지니어의 편향과 2026년의 기회

1. 만들기 편향

   1. 기술적 자기 확신: 엔지니어는 회사를 시작하거나 프로젝트를 만들 때 “일단 만들고, 정말 끝내주게 좋게 만들겠다”는 쪽으로 기울기 쉽다.
   2. Exa의 초기 실수: Exa를 시작할 때도 같은 편향이 있었고, 마케팅과 영업을 충분히 하지 못했다. Jeffrey Wang이 “우리는 GTM을 정말 못했다”고 인정하자 청중이 웃었다.

2. AI가 바꾼 GTM의 성격

   1. 엔지니어링 문제화: 2026년에는 GTM을 엔지니어링 문제, 더 구체적으로 AI 엔지니어링 문제로 다룰 수 있다.
   2. 개인 생산성: 자동화 덕분에 한 사람이 과거보다 훨씬 많은 GTM 업무를 수행할 수 있다.
   3. 기술 인력의 참여 장벽 하락: 엔지니어가 GTM에 참여하는 일이 예전보다 재미있고 접근하기 쉬워졌다.

2. GTM의 본질은 데이터 문제다

고객 조사부터 POC 제작까지의 업무를 하나로 묶는 공통 주제는 제품 세계와 잠재 고객 세계를 데이터로 파악하는 일이다.

2.1. GTM 팀이 실제로 처리하는 업무

1. 고객과 타깃 조사

   1. 고객 연구: 제품을 사용할 고객이 누구인지 조사한다.
   2. 타깃 연구: 목표 기업에 관한 정보를 찾고, 우선순위를 판단한다.
   3. 담당자 탐색: 특정 회사 안에서 실제로 접촉해야 할 사람을 찾아낸다.

2. 거래와 제품 검증

   1. POC 제작: 고객에게 제품이 실제로 작동하는 모습을 보여주기 위해 POC를 만든다.
   2. 반복 업무의 폭: 위 업무 외에도 GTM 팀이 수행하는 일은 매우 많다. 조사, 선별, 접촉, 데모, 후속 조치가 계속 이어진다.

2.2. 제품 세계와 고객 세계를 연결하는 모델

1. 두 개의 거대한 세계

   1. 제품 세계: 제품이 무엇을 하고 어떤 사용 사례를 지원하는지에 대한 지식이 있다.
   2. 고객 세계: 잠재 고객, 기업, 담당자, 산업, 이벤트가 존재하는 세계가 있다.
   3. GTM의 작업: 두 세계의 구조를 학습하고 현재 자신이 어떤 세계에 있는지 파악하는 것이 GTM이다.

2. 데이터 시스템으로의 전환

   1. 통합된 문제 정의: 개별 영업 활동의 목록이 아니라 데이터 수집·정제·검색·행동의 문제로 GTM을 정의한다.
   2. 엔지니어링 접근: 어떤 데이터를 모으고 어떤 인터페이스로 노출하며 어떤 에이전트가 다음 행동을 수행할지 설계한다.

2.3. 에이전트가 행동할 수 있는 실시간 세계 모델

1. 내부 데이터

   1. 고객 정보: 현재 고객과 잠재 고객에 대해 회사가 알고 있는 정보가 있다.
   2. 구성원 정보: 회사 안에 누가 어떤 역할을 맡고 있는지에 대한 데이터가 있다.
   3. 제품 사용 데이터: 사람들이 제품을 어떻게 사용하는지, 어떤 기능과 검색량을 이용하는지에 대한 데이터가 있다.

2. 외부 데이터

   1. 기업 규모: 전 세계에는 6,000만 개가 넘는 회사가 있다.
   2. 사람과 전문 네트워크: LinkedIn에는 10억 명이 넘는 사람이 있는 것으로 언급된다.
   3. 매일 발생하는 변화: 뉴스와 기업 이벤트가 매일 발생하므로 정적인 CRM만으로는 세계를 충분히 표현하기 어렵다.

3. 실시간성의 의미

   1. 행동 가능한 모델: 여러 데이터 소스를 모아 에이전트가 질문에 답하는 데 그치지 않고 다음 행동까지 수행할 수 있는 모델을 만든다.
   2. 데이터 소스의 폭: 내부 시스템, 제품 사용 이벤트, 웹, LinkedIn, 뉴스 등 에이전트가 접근할 수 있는 모든 소스를 설계 단계에서 고려한다.

3. Exa가 구축한 GTM 인터페이스

Exa는 2023년 중반 출시 직후부터 AI 에이전트 우선 관점으로 GTM을 설계했으며, 핵심 인터페이스 두 가지로 시장과 고객을 관찰한다.

3.1. ICP 대시보드: 우리가 속한 세계를 정의하기

1. ICP의 질문

   1. 세계의 범위: ICP(Ideal Customer Profile) 대시보드는 Exa가 관심을 가져야 할 고객과 사용 사례의 세계가 어디까지인지 묻는다.
   2. TAM의 구조화: 총주소가능시장(TAM, Total Addressable Market) 안에 어떤 기업이 들어가는지 분류한다.

2. 기업 전체의 자동 분류

   1. 대규모 분류: Exa를 사용해 TAM에 해당하는 가능한 모든 회사를 분류한다.
   2. 세그먼트 사례: 모델 제공업체, Cursor 같은 AI 코딩 플랫폼, GTM 인텔리전스 도구 등이 카테고리로 들어간다.
   3. 매출 정보의 비공개: 대시보드 화면에서 각 카테고리로부터 얼마를 버는지와 같은 세부 정보는 흐리게 처리했다.

3. 회사별 딥다이브

   1. SpaceX 사례: SpaceX를 선택하면 예상 연간 지출 규모와 회사의 여러 메타데이터를 확인할 수 있다.
   2. 목록과 상세의 결합: 전체 기업 목록을 보면서 특정 기업 하나의 구매 가능성과 맥락을 깊게 조사할 수 있다.
   3. 영업 행동으로의 연결: 어떤 기업을 공략할지, 어느 정도의 가치를 기대할지, 어떤 정보를 추가 조사할지 결정하는 출발점이 된다.

4. 기술적 기반

   1. 웹 크롤링: Exa는 인터넷을 크롤링하고 웹 문서를 수집한다.
   2. 검색용 임베딩: 웹 검색을 잘 수행하도록 임베딩(embedding)을 학습한다.
   3. 인터넷 위의 임베딩: 기술적으로 Exa를 인터넷 전체에 임베딩이 깔린 구조로 볼 수 있다.
   4. 의미 기반 슬라이싱: 인터넷 데이터에 임베딩이 있으면 의미에 따른 필터링, 분할, 조합을 임의의 기준으로 수행할 수 있다.
   5. ICP 생성: 이 의미 검색 능력을 사용해 거대한 잠재 ICP 목록을 만든다.

3.2. Request Lens: 고객의 중요한 변화를 감지하기

1. 알림의 목적

   1. 고객 이벤트 감시: 고객에게 중요한 변화가 일어날 때마다 팀에 알려주는 시스템이다.
   2. 행동 가능한 신호: 알림은 데이터 기록으로 끝나지 않고 GTM 팀이 다음 행동을 하도록 만드는 신호다.

2. 주요 이벤트

   1. 신규 가입: 누군가 Exa에 가입하면 알림을 보낸다.
   2. 대량 사용: 특정 사용자가 검색을 매우 많이 사용하면 관심 신호로 포착한다.
   3. 사용 중단: 고객이 검색 사용을 멈추면 이탈 위험 또는 후속 연락이 필요한 신호로 본다.
   4. 중요 인물의 등장: Exa가 매우 중요하게 생각하는 사람이 서비스에 나타나면 팀에 알려준다.

3. ICP와 Request Lens의 역할 분담

   1. ICP 대시보드: 시장의 정적·구조적 지도를 만든다.
   2. Request Lens: 그 지도 안에서 고객 행동이 변하는 순간을 실시간으로 포착한다.
   3. GTM 루프: 시장 정의 → 고객 이벤트 감지 → 조사와 접촉 → 제품 사용과 거래로 이어지는 피드백 루프를 구성한다.

4. GTM 조직을 움직이는 에이전트 스택

Exa의 GTM 조직은 엔지니어링 조직만큼 에이전트를 깊게 사용하며, Slack을 내부 에이전트의 공용 인터페이스로 활용한다.

4.1. 코딩 에이전트와 Slack 에이전트

1. GTM 팀의 높은 에이전트 사용량

   1. 조직 전체의 사용: Exa의 엔지니어링 팀이 에이전트를 많이 쓰지만 GTM 팀의 사용량도 매우 높다.
   2. 도구 지출: Devin을 비롯한 코딩 에이전트 사용 지출이 “정말 엄청나게 높다”고 표현할 정도다.
   3. 고객 질문: GTM 구성원은 고객에 대해 더 알아보기 위해 에이전트에게 지속해서 질문한다.

2. 영업 현장의 제작 활동

   1. AE의 데모 제작: AE(Account Executive)가 고객을 위한 데모를 직접 만든다.
   2. 거래별 커스터마이징: 고객의 상황을 조사하고 맞춤형 결과물을 만드는 과정에 코딩 에이전트를 사용한다.
   3. 업무 경계의 변화: 영업 담당자가 소프트웨어를 소비하는 데 그치지 않고 필요한 영업 도구를 직접 생산한다.

3. Slack 안의 에이전트 생태계

   1. 에이전트 수: Slack 안에 약 12개, 즉 10여 개의 서로 다른 에이전트가 상주한다.
   2. 접근성: 회사 구성원 누구나 해당 에이전트를 사용할 수 있다.
   3. 데이터 연결: 에이전트는 사내 데이터에 광범위하게 접근한다.
   4. 사용 순간: 계정을 더 깊게 조사하거나 데모를 만들 때 구성원은 에이전트에 크게 의존한다.

4.2. Jeffbot: 창업자의 지식과 판단을 에이전트로 만들기

1. 탄생 배경

   1. 시점과 장소: Jeffrey Wang은 겨울 휴가 기간에 멕시코에서 일주일의 시간을 확보했다.
   2. Opus 4.5 실험: 당시 사람들이 Opus 4.5를 가지고 놀던 흐름에 맞춰, 자신을 디지털 복제하는 것을 휴가의 목표로 삼았다.
   3. 이름: 결과물에 Jeffbot이라는 이름을 붙였다.

2. 말투 모델링

   1. 이메일 표본: 자신의 이메일 약 760통을 분석했다.
   2. 평균 길이: 이메일 한 통의 평균 길이가 18단어라는 특성을 확인했다.
   3. 맺음말 습관: “Sincerely”보다 “Best”로 이메일을 끝내는 습관을 포착했다.
   4. 음성의 재현: 단어 수, 맺음말 등 반복 패턴을 바탕으로 자신의 이메일 목소리(email voice)를 만들었다.

3. 의사결정 프레임워크

   1. 과거 결정 수집: 과거에 내린 수백 건의 의사결정을 분석했다.
   2. 판단 기준 추출: 결정이 내려진 맥락과 선택의 기준을 정리해 의사결정 프레임워크를 만들었다.
   3. 평가(Eval) 구성: 과거 결정에서 평가 문제를 만들고, 에이전트가 자신의 판단과 얼마나 유사하게 행동하는지 보정했다.

4. 권한과 업무 흐름

   1. 개인 데이터 권한: Jeffrey Wang이 개인적으로 접근하는 모든 데이터에 Jeffbot의 읽기·쓰기 권한을 부여했다.
   2. 창업자 좌석의 특권: 창업자이기 때문에 회사의 거의 모든 시스템에 접근할 수 있고, Jeffbot도 그 넓은 범위를 활용한다.
   3. 구성원용 기능: 회사 구성원은 Jeffbot에게 Slack 메시지 초안을 요청할 수 있다.
   4. 결정과 답변의 초안: Jeffbot은 이미 내려진 답변이나 결정에 맞는 메시지를 작성한다.
   5. GTM 활용: GTM 팀은 Jeffbot으로 영업 이메일 초안을 만든다.

5. 조직 효과

   1. 린 조직: Exa의 GTM 조직은 규모가 작다.
   2. 생산성: 내부 데이터, 에이전트, 인터페이스를 결합해 적은 인원으로 높은 생산성을 낸다.
   3. 복제의 범위: Jeffbot은 단순한 챗봇이 아니라 말투, 과거 판단, 시스템 권한을 조합한 업무 대리인이다.

5. 에이전트 우선 회사의 세 가지 설계 원칙

에이전트를 도입하는 일은 모델을 붙이는 문제가 아니라 데이터 접근, 사용자 인터페이스, 커스터마이징 가능성을 함께 설계하는 일이다.

5.1. 에이전트 우선은 API 우선이어야 한다

1. 프로그램 접근성의 전제

   1. 내부·외부 데이터 API: 에이전트와 GUI가 사용하는 내부·외부 데이터 위에 좋은 API가 있어야 한다.
   2. 접근 실패의 결과: 좋은 API가 없으면 에이전트가 데이터에 접근할 수 없고, 에이전트 우선 전략도 작동하지 않는다.
   3. 인터페이스의 이름보다 기능: MCP, CLI(Command-Line Interface) 등 무엇이라고 부르는지는 중요하지 않으며, 프로그램이 호출할 수 있는 인터페이스면 된다.

2. API 우선의 운영 효과

   1. 데이터 재사용: 한 번 만든 데이터 접근 계층을 대시보드, 챗봇, 코딩 에이전트, Slack 봇이 함께 사용할 수 있다.
   2. 자동화 범위 확대: 데이터가 프로그램적으로 노출되면 에이전트가 조사·분류·초안·후속 조치를 이어서 수행할 수 있다.

5.2. GUI와 챗봇을 함께 설계한다

1. 챗봇 만능론의 오류

   1. 잘못된 질문: 에이전트 세계에서 모든 것을 챗봇으로 만들어야 한다는 가정이 있다.
   2. 두 도구의 공존: GUI(Graphical User Interface)와 챗봇은 각각 장점이 있으므로 둘 다 유용하다.

2. 동적 UI와 고정 UI

   1. 동적 사용자 인터페이스: AI는 질문에 답하기 위해 매번 새로운 UI를 생성할 수 있다. 단순한 질문에도 HTML이나 Markdown 파일을 만들어 보여줄 수 있다.
   2. 일관된 경험: 같은 사용 사례에 같은 구조의 UI를 반복해서 방문하면 사용자가 도구 사용법을 학습할 수 있다.
   3. 결정화된 UI: 반복 업무에는 결정화된(crystallized) GUI를 제공한다.
   4. 유연한 에이전트: 예상하지 못한 질문과 복잡한 조합에는 임의로 강력하고 유연한 대화형 에이전트를 제공한다.

3. 균형점

   1. 고정된 루틴: 일관된 UI는 탐색 비용을 줄이고 팀이 반복 업무를 빠르게 수행하게 한다.
   2. 열린 탐색: 챗봇은 미리 버튼으로 정의하지 않은 질문과 데이터 조합을 처리한다.
   3. 에이전트 우선의 구성요소: 결정화된 UI와 임의로 강력한 채팅 에이전트가 함께 있어야 한다.

5.3. 구매와 자체 개발의 이분법을 버리고 무한 커스터마이징을 확보한다

1. 잘못된 선택지

   1. 전통적 질문: Salesforce 같은 SaaS를 구매할지, CRM을 직접 만들지 선택해야 한다는 질문이 있다.
   2. 거짓 이분법: 구매와 자체 개발 중 하나만 가능한 세상은 아니다.

2. 무한 커스터마이징의 기준

   1. 자체 개발: 직접 만든 시스템은 코드를 수정해 언제든 더 좋게 만들 수 있으므로 본질적으로 커스터마이징 가능하다.
   2. 구매한 SaaS: 구매한 SaaS라도 회사가 그 위에서 원하는 동작을 만들고 에이전트로 조정할 수 있으면 같은 효과를 얻는다.
   3. 최고 우선순위: 무엇을 구매했는지보다 시스템을 임의로 확장하고 회사의 변화에 맞게 바꿀 수 있는지가 더 중요하다.

3. Salesforce 사례

   1. 좋은 데이터베이스: Exa는 Salesforce를 사용하며, Salesforce를 영업 데이터베이스로 평가한다.
   2. 검증된 영업 선택: Salesforce는 영업 프로세스가 어떤 모습이어야 하는지에 대해 이미 많은 좋은 선택을 해두었다.
   3. 불필요한 재발명 방지: Exa가 영업 시스템의 모든 기능과 로드맵을 직접 결정하고 싶어 하는 것은 아니다.
   4. MCP 연결: Salesforce는 MCP를 노출하므로 Exa의 에이전트가 Salesforce 데이터와 기능에 접근할 수 있다.
   5. 일상 사용: 팀은 Salesforce MCP를 매일 사용한다.

6. Q&A: 데이터 출처, 조직 역할, 보안, FDE

질문은 Jeffbot의 학습 자료, GTM 인력의 기술 수준, 권한 경계, FDE 조직의 탄생으로 이어졌다.

6.1. Jeffbot은 과거 의사결정 자료를 어디서 얻었는가

1. 질문의 핵심

   1. 기록의 부재: 일반적으로 사람들은 자신의 결정을 별도 문서로 저장하지 않는다.
   2. 가능한 자료원: 질문자는 Slack, 이메일, 기타 업무 아티팩트 중 무엇을 사용했는지 물었다.

2. 실제 자료원

   1. Slack과 이메일: Jeffrey Wang은 Slack과 이메일에서 자신이 내린 결정을 찾았다.
   2. Slack의 밀도: 회사에서 일어나는 일의 놀라울 정도로 많은 부분이 Slack에 남는다.
   3. 과거 결정의 복원: Slack 기록을 대량으로 읽으면 과거에 내린 수백 건의 결정을 찾아낼 수 있다.

6.2. GTM 조직의 전문성 및 기술 수준

1. 조직 구성

   1. AE: Account Executive는 거래를 진행하고 성사시키는 역할을 맡는다.
   2. SDR: Sales Development Representative는 수요 창출(demand generation)을 돕는다.
   3. FDE: Forward Deployed Engineering 조직은 별도로 존재한다.

2. 비-FDE 구성원의 AI 활용

   1. AI 숙련도: FDE가 아닌 사람도 AI를 매우 잘 사용하도록 학습했다.
   2. 바이브 코딩의 범위: 일반적으로 직접 바이브 코딩(vibe coding)으로 인터페이스를 만들지는 않는다.
   3. 도구 활용: 대신 이미 만들어진 AI 도구를 매우 잘 사용한다.
   4. 교육 체계: 교육 세션을 열고 구성원이 도구를 실제로 사용하는 방법을 확실히 이해하도록 한다.

3. FDE의 이중 역할

   1. 거래 지원: FDE는 거래를 진행하고 거래 과정에서 기술 지원을 제공한다.
   2. 시스템 구축: 동시에 AI 시스템의 유지보수와 기능 개발을 수행한다.
   3. 영업 시스템 자체 개선: 영업을 하면서 영업 시스템을 직접 만들어 업무를 매끄럽게 한다.
   4. 조직적 특징: 영업을 지원하는 사람과 내부 도구를 만드는 사람이 분리되지 않은 다소 독특한 운영 모델이다.

6.3. Jeffbot의 권한과 보안 가드레일

1. 제기된 우려

   1. 창업자 권한: Jeffbot이 Jeffrey Wang의 전체 권한으로 실행된다는 설명이 있었다.
   2. 전사 접근 가능성: 누구나 Jeffbot을 호출할 수 있다면 모든 구성원이 모든 정보를 보는 구조인지 질문이 나왔다.

2. 호출자별 권한 분리

   1. Jeffrey Wang 본인 호출: 본인이 Jeffbot을 호출하면 많은 시스템에 접근하고 읽기·쓰기 작업까지 수행할 수 있다.
   2. 다른 구성원 호출: 다른 사람이 호출하면 메시지 초안 작성만 허용한다.
   3. MCP 제한: 다른 구성원의 호출에서는 모든 MCP와 도구에 대한 권한을 부여하지 않는다.
   4. 보안 원칙: 호출자와 작업 종류에 따라 데이터 접근과 실행 권한을 분리해 가드레일을 둔다.

6.4. FDE 조직의 기원과 확장성

1. 기존 직무와 FDE

   1. 초기 FDE: 과거에는 FDE라는 역할 자체가 널리 존재하지 않았다.
   2. Palantir의 명명: Palantir가 일부 사람을 FDE라고 부르기 시작했지만, 당시에는 그 정도가 대부분이었다.
   3. 전통적 조합: 기술 회사에는 솔루션 엔지니어, 세일즈 엔지니어, Account Executive가 따로 있었다.

2. AI가 만든 역할 통합

   1. 기술 기반 수익 지원: AI 시대에는 수익 창출을 지원하는 기술 인력이 단순히 거래를 돕는 데서 끝나지 않는다.
   2. 도구의 즉시 제작: AI를 사용하면 자신의 업무와 AE의 업무를 매끄럽게 만드는 도구를 직접 만들 수 있다.
   3. 두 직무의 결합: 과거에는 두 사람이 해야 했던 기술 지원과 도구 개발이 이론상 한 사람의 역할로 합쳐졌다.

3. 현재 규모와 한계

   1. FDE 인원: Exa에는 현재 약 8~9명의 FDE가 있다.
   2. 미래의 분업: 조직이 커지면 모든 사람이 모든 일을 하는 모델이 그대로 확장되지는 않을 가능성이 높다.
   3. 현재의 유효성: 그래도 현재 규모에서는 거래와 시스템 구축을 결합한 모델이 상당히 멀리 갈 수 있는 좋은 운영 방식이다.
   4. GTM 전체 규모: Exa의 GTM 조직은 약 115명이다.

주요 발언 모음

“제품을 제대로 만들어야 하고, GTM도 제대로 해야 한다. 제품을 만들고 좋게 만든 다음 사람들의 손에 쥐여줘야 한다. 둘 다 하지 않으면 회사가 아니다.”

“2026년의 GTM은 엔지니어링 문제, 특히 AI 엔지니어링 문제처럼 다룰 수 있다.”

“GTM은 데이터 문제다.”

“에이전트 우선이 되려면 API 우선이어야 한다.”

“모든 것이 챗봇이어야 하는 것은 아니다. 결정화된 UI와 임의로 강력하고 유연한 채팅 에이전트가 둘 다 중요하다.”

“무한한 커스터마이징이 정말 가장 중요한 우선순위다.”

핵심 데이터 & 수치

• 2023년 중반: Exa가 출시됐다. GPT-4 이후 시기였고, 초기부터 AI 에이전트 우선 GTM을 고민했다.
• 6,000만 개 이상: 전 세계 회사 수로 제시된 규모이며, ICP 대시보드가 잠재 시장을 분류해야 하는 이유다.
• 10억 명 이상: LinkedIn에 존재하는 사람의 규모로 언급된 수치다.
• 약 760통: Jeffbot이 Jeffrey Wang의 이메일 말투를 분석한 표본 수다.
• 평균 18단어: Jeffrey Wang의 이메일 한 통에 들어가는 평균 단어 수다.
• 수백 건: Jeffbot의 의사결정 프레임워크와 평가를 만들기 위해 분석한 과거 결정의 규모다.
• 약 12개: Exa Slack에 상주하며 누구나 사용할 수 있는 내부 에이전트의 대략적인 수다.
• 약 8~9명: 현재 Exa FDE 조직의 인원이다.
• 약 115명: Exa GTM 조직 전체 인원이다.
• 비공개 수치: ICP 대시보드의 카테고리별 매출은 화면에서 흐리게 처리되어 구체적인 값이 공개되지 않았다.
• 미제시 수치: SpaceX의 예상 연간 지출은 대시보드 사례로 언급됐지만 정확한 금액은 제시되지 않았다.
• 18분 20초: 전체 발표와 Q&A의 러닝타임이다.

결론 및 시사점

1. 제품과 GTM을 하나의 회사 능력으로 본다

   1. 제품 품질과 유통 역량 중 하나만 선택하지 않는다.
   2. 엔지니어 조직도 고객 조사, 시장 분류, 데모 제작을 기술 시스템으로 다룰 수 있다.

2. GTM 데이터 기반을 먼저 만든다

   1. 내부 고객·사용·조직 데이터를 외부 웹·기업·사람·뉴스 데이터와 결합한다.
   2. 에이전트가 검색만 하는 것이 아니라 판단과 다음 행동을 수행할 수 있도록 실시간 세계 모델로 제공한다.

3. 정적 시장 지도와 실시간 신호를 분리한다

   1. ICP 대시보드로 TAM과 기업별 메타데이터를 구조화한다.
   2. Request Lens로 가입, 대량 사용, 사용 중단, 중요 인물 등장 같은 순간을 포착한다.

4. 에이전트의 성능은 데이터 접근성과 인터페이스에서 결정된다

   1. MCP나 CLI처럼 이름에 상관없이 안정적인 프로그램 인터페이스를 제공한다.
   2. 반복 업무에는 학습 가능한 GUI를, 열린 탐색에는 유연한 챗봇을 제공한다.

5. SaaS 구매와 자체 개발을 재정의한다

   1. Salesforce처럼 검증된 업무 모델과 데이터베이스를 구매할 수 있다.
   2. MCP와 API로 구매한 시스템을 회사 방식에 맞게 임의로 확장하면 자체 개발의 장점을 일부 확보할 수 있다.

6. 창업자 지식을 데이터와 평가로 변환한다

   1. 이메일 760통에서 말투와 형식을 추출한다.
   2. Slack과 이메일의 수백 건 의사결정에서 판단 규칙과 Eval을 만든다.
   3. 권한을 넓게 주더라도 호출자별 읽기·쓰기·초안 권한을 분리한다.

7. FDE를 수익과 도구를 연결하는 역할로 활용한다

   1. 기술 인력이 거래를 지원하면서 내부 영업 시스템을 직접 개선하게 한다.
   2. 조직이 커질 때는 모든 업무를 한 사람에게 맡기는 모델의 확장성을 다시 검토한다.

핵심 요약 (20줄)

제품 품질과 유통 역량은 양자택일이 아니라 회사가 함께 확보해야 하는 두 가지 핵심 능력이다.

엔지니어는 GTM을 데이터와 자동화로 구성된 AI 엔지니어링 문제로 다룰 수 있다.

Exa는 웹에 접근하지 못하는 에이전트를 위한 검색 엔진이자 웹 MCP 도구다.

GTM의 고객 조사와 POC 제작은 제품 세계와 잠재 고객 세계를 연결하는 데이터 문제다.

에이전트가 행동하려면 내부 데이터와 외부 웹 데이터를 합친 실시간 세계 모델이 필요하다.

전 세계 6,000만 개 이상의 기업과 10억 명 이상의 LinkedIn 사용자는 GTM 데이터의 거대한 외부 영역을 이룬다.

Exa는 2023년 중반 출시 때부터 AI 에이전트 우선 관점으로 GTM 시스템을 구축했다.

ICP 대시보드는 TAM 안의 기업을 자동 분류하고 관심 고객과 사용 사례의 범위를 정의한다.

대시보드에서 SpaceX 같은 기업을 선택하면 예상 연간 지출과 회사 메타데이터를 확인할 수 있다.

Exa는 인터넷 크롤링과 임베딩을 통해 잠재 ICP를 의미 기반으로 필터링하고 조합한다.

Request Lens는 가입, 대량 검색, 사용 중단, 중요 인물 등장 같은 고객 이벤트를 알린다.

Exa GTM 팀은 Slack에서 약 12개의 에이전트를 사용하며 고객 조사와 데모 제작을 자동화한다.

Jeffbot은 Jeffrey Wang이 멕시코 휴가 중 Opus 4.5로 만든 창업자 AI 클론이다.

Jeffbot은 이메일 약 760통과 평균 18단어의 말투 패턴을 분석해 답변 스타일을 모방한다.

과거 수백 건의 Slack·이메일 의사결정은 Jeffbot의 판단 프레임워크와 Eval으로 변환됐다.

에이전트 우선 조직은 반드시 API 우선이어야 하며 MCP와 CLI 같은 프로그램 인터페이스가 필요하다.

반복 업무에는 일관된 GUI를 사용하고 열린 질문에는 유연한 챗봇을 사용하는 조합이 효과적이다.

SaaS 구매와 자체 개발의 이분법보다 구매한 시스템도 무한히 커스터마이징할 수 있는지가 중요하다.

Exa는 Salesforce MCP를 통해 검증된 영업 데이터베이스를 매일 에이전트와 연결한다.

FDE는 거래 지원과 영업 도구 개발을 결합하며 Exa는 약 8~9명의 FDE와 115명 규모의 GTM 조직을 운영한다.