지식 시스템: 새로운 GTM 스택

---

title: "지식 시스템: 새로운 GTM 스택" title_original: "Knowledge Systems: The New GTM Stack — Jeffrey Wang, Exa" source: "aiDotEngineer" channel: "aiDotEngineer" date: "2026-08-27" video_id: "6pbQgnJ9Voc" video_url: "https://www.youtube.com/watch?v=6pbQgnJ9Voc"

URL: https://www.youtube.com/watch?v=6pbQgnJ9Voc
날짜: 2026-08-27
채널: aiDotEngineer
발표자: Jeffrey Wang, Exa 공동창업자

---

📌 핵심 질문 / 지식 시스템이 바꾸는 GTM의 본질

==Go-to-market(GTM)은 영업·마케팅 인력의 감각에만 의존하는 일이 아니라, 내부·외부 데이터를 연결해 에이전트(Agent)가 행동할 수 있는 살아 있는 세계 모델을 만드는 AI engineering 문제다.== 제품을 잘 만드는 것과 고객의 손에 제품을 전달하는 일은 양자택일이 아니며, 두 축을 함께 설계해야 회사가 된다.

• 제품이 좋아도 고객에게 닿지 않으면 회사가 되지 않는다.
• 고객·회사·제품 사용량에 관한 내부 데이터와 시장·기업·사람·뉴스에 관한 외부 데이터를 함께 다뤄야 한다.
• API-first 기반 위에 일관된 GUI, 유연한 chat agent, 업무에 맞게 확장 가능한 SaaS를 결합해야 한다.
• Exa는 이 원칙을 ICP dashboard, Request Lens, Slack coding agents, Jeff Bots로 실제 GTM 운영에 적용한다.

GTM의 핵심 산출물은 사람 머릿속에 흩어진 고객 목록이나 영업 노하우가 아니라, 현재 세계의 상태를 계속 갱신하고 에이전트가 조회·판단·초안 작성·도구 호출까지 수행할 수 있게 하는 지식 시스템(knowledge system)이다.

1. GTM을 엔지니어링 문제로 다시 정의하기

제품을 만드는 기술 인력도 데이터와 자동화를 이용해 GTM을 직접 설계하고 개선할 수 있다.

1.1. 발표 맥락과 Exa의 역할

1. 엔지니어에게 맞춘 GTM 논의

   1. Jeffrey Wang은 Exa의 공동창업자로 소개된 뒤, AI engineering fair의 취지에 맞춰 GTM을 AI engineering 문제로 바꾸는 이야기를 하겠다고 밝혔다.
   2. 청중에게 기술 직군인지 손을 들어 달라고 요청했고, 기술 청중을 전제로 GTM을 설명하겠다고 했다.
   3. 중간에 질문이 있으면 언제든 해 달라고 요청했다. 행사가 여러 발표로 구성되어 있어 청중을 지루하게 만들고 싶지 않다는 농담 섞인 태도였다.

2. Exa는 에이전트용 검색 엔진이다

   1. 에이전트는 똑똑해도 웹에 직접 접근하지 못하는 경우가 많으며, Exa는 에이전트가 사용할 수 있는 웹 MCP(web MCP) 도구 역할을 한다.
   2. Cursor, Cognition을 비롯한 AI 생태계의 여러 제품이 Exa를 사용한다.
   3. 따라서 Exa의 핵심 기술은 외부 세계의 정보를 에이전트가 검색·활용할 수 있도록 만드는 데이터 접근 계층이다.

1.2. 제품과 유통을 함께 해야 하는 이유

1. 제품 우선론과 유통 우선론의 충돌

   1. 현재 업계에는 “제품만 중요하다”와 “Distribution만 중요하다”가 맞서는 서사가 있다.
   2. Glean을 두고도 Distribution은 뛰어나지만 제품이 대체 무엇이냐는 식의 Twitter 논쟁이 벌어진다고 했다.
   3. 반대로 에이전트가 최고의 제품을 골라 쓸 것이므로 제품이 압도적으로 좋아야 한다는 주장도 있다.

2. 두 축을 동시에 최적화해야 한다

   1. 제품을 제대로 만들고 사람의 손에 넣어야 한다. 한쪽만 빠지면 회사가 성립하지 않는다.
   2. 엔지니어는 회사를 시작할 때 “일단 만들고, 아주 훌륭하게 만들겠다”는 쪽으로 편향되기 쉽다.
   3. Exa를 시작했을 때도 기술적으로 좋은 것을 만드는 데 집중한 나머지 마케팅과 영업을 충분히 하지 못했고, GTM을 잘하지 못했다고 회고했다. 이 대목에서 청중의 웃음이 나왔다.

1.3. 2026년의 기회: GTM을 AI engineering으로 다루기

1. 자동화 가능한 GTM

   1. 2026년에는 GTM을 일반적인 운영 문제가 아니라 engineering, 특히 AI engineering 문제로 다룰 수 있다.
   2. 반복적인 조사·분류·초안·데모 제작을 자동화할 수 있으므로 엔지니어에게 GTM은 과거보다 훨씬 재미있는 문제가 된다.
   3. 한 사람이 에이전트를 이용해 예전보다 훨씬 많은 일을 수행할 수 있다.

2. 핵심 가설

   1. 엔지니어든 다른 직군이든 GTM을 엔지니어링 문제로 취급할 수 있다.
   2. 이 관점은 영업을 단순한 관계 형성이나 인력 확충이 아니라 데이터 수집·모델링·자동화·피드백 루프로 바꾼다.

2. GTM의 통합 문제는 데이터 문제다

GTM 팀이 하는 서로 다른 업무를 하나로 묶는 공통 기반은 고객 세계를 지속적으로 알아가는 데이터 처리다.

2.1. GTM 업무의 표면과 공통 구조

1. 고객과 타깃 조사

   1. 어떤 고객을 상대하는지 조사해야 한다.
   2. 타깃 기업에 관한 정보를 찾고, 특정 회사 안에서 적절한 사람을 찾아야 한다.

2. 거래 전 기술 활동

   1. 잠재 고객에게 맞는 POC(proof of concept)를 만들어야 한다.
   2. 고객별 데모와 설명 자료를 준비해야 하며, 그 밖에도 많은 세부 업무가 이어진다.

3. Grand unifying theme은 데이터다

   1. 한쪽에는 제품이 무엇을 하는지에 관한 세계가 있고, 다른 한쪽에는 잠재 고객 전체의 세계가 있다.
   2. GTM은 두 세계를 탐색하면서 회사가 실제로 상대하는 세계가 어떤 모습인지 학습하고 알아가는 과정이다.
   3. 따라서 GTM을 데이터 관점에서 풀어야 하며, 사람별 경험과 기억에 맡긴 상태로는 확장하기 어렵다.

2.2. 에이전트가 행동할 수 있는 살아 있는 세계 모델

1. 내부 데이터

   1. 고객에 관해 회사가 알고 있는 정보가 내부에 쌓인다.
   2. 회사에 소속된 사람과 조직 구조에 관한 정보가 내부 데이터가 된다.
   3. 고객이 제품을 어떻게 사용하는지, 얼마나 검색하는지, 사용을 멈췄는지에 관한 사용 데이터도 포함된다.

2. 외부 데이터

   1. 세계에는 6,000만 개가 넘는 회사가 있다.
   2. LinkedIn에는 10억 명이 넘는 사람이 있으며, 잠재 고객과 의사결정자를 찾을 수 있는 중요한 외부 정보원이다.
   3. 뉴스처럼 매일 새롭게 발생하는 사건도 고객의 사업 상황과 구매 가능성을 바꾼다.

3. 데이터 GTM 시스템의 조건

   1. 외부 세계가 계속 변하므로 한 번 만들어 놓고 끝나는 고객 목록이 아니라 live model이 필요하다.
   2. live model은 내부·외부 출처를 함께 반영하고, 에이전트가 그 위에서 검색·분류·심층 조사·알림 대응을 수행하게 해야 한다.
   3. Exa는 인터넷을 에이전트가 사용할 수 있는 검색 계층으로 바꾸고, 내부 도구는 회사의 맥락을 연결하는 역할을 맡는다.

3. Exa가 구축한 두 가지 운영 인터페이스

Exa는 GTM의 세계 모델을 사람이 탐색하고 신호를 받을 수 있는 두 인터페이스로 구현한다.

3.1. ICP dashboard: 우리가 상대하는 세계를 분류하기

1. ICP dashboard의 질문

   1. ICP(ideal customer profile) dashboard는 “우리의 세계는 무엇인가?”라는 질문에 답하는 내부 제품이다.
   2. 여기서 세계란 회사가 관심을 두는 고객과 사용 사례의 공간이다.
   3. 영업 담당자의 주관적인 후보 목록이 아니라, TAM(total addressable market) 전체를 구조적으로 파악하는 화면이다.

2. TAM 전체를 회사 단위로 분류하기

   1. Exa를 이용해 TAM에 속할 수 있는 거의 모든 회사를 분류한다.
   2. 실제 분류에는 model provider, Cursor 같은 AI coding platform, GTM intelligence tool 같은 카테고리가 포함된다.
   3. 카테고리별 매출 규모와 같은 민감한 세부 정보는 발표 화면에서 가려 두었지만, 각 세그먼트의 회사 목록과 규모를 이해하고 있다고 했다.
   4. 결과적으로 해당 세그먼트 안의 거의 모든 회사에 관한 지식 기반을 갖추게 된다.

3. 기업별 deep dive

   1. 회사 목록에서 특정 기업을 선택하면 그 기업을 깊이 조사할 수 있다.
   2. SpaceX를 사례로 들며 예상할 수 있는 연간 지출 규모와 회사에 관한 여러 메타데이터를 볼 수 있다고 설명했다.
   3. “어떤 회사가 있는가”와 “각 회사에 관해 무엇을 아는가”를 한 시스템에서 연결한다.

3.2. Exa의 기술 기반: 인터넷 위의 embeddings

1. 검색 엔진 구축 방식

   1. Exa는 인터넷을 크롤링한다.
   2. 웹 검색을 잘 수행하도록 embeddings를 학습한다.
   3. 기술적으로 Exa를 “인터넷 위에 놓인 embeddings”로 생각할 수 있다.

2. Semantic filtering의 확장성

   1. 인터넷 전체에 embeddings가 있으면 원하는 데이터 유형을 의미적으로 필터링할 수 있다.
   2. 단순 키워드 일치가 아니라 의미 기반으로 slicing and dicing, 즉 데이터를 잘라 보고 조합할 수 있다.
   3. 이 능력이 ICP 후보를 거대한 목록으로 만들고, 카테고리·기업·메타데이터별로 탐색하는 기반이 된다.

3.3. Request Lens: 중요한 고객 이벤트를 행동 신호로 바꾸기

1. 알림이 되는 사건

   1. Request Lens는 고객에게 중요한 일이 일어날 때 팀에 알리는 시스템이다.
   2. 고객이 가입하면 신호가 발생한다.
   3. 고객이 검색을 매우 많이 사용하면 신호가 발생한다.
   4. 고객이 검색 사용을 중단해도 신호가 발생한다.
   5. 회사가 특히 중요하게 여기는 사람이 나타나도 알림을 받을 수 있다.

2. 알림의 목적

   1. 각각의 사건은 단순한 로그가 아니라 팀이 행동할 수 있는 signal이다.
   2. 팀은 신호를 받아 고객에게 연락하거나 사용 패턴을 조사하거나 거래 기회를 확대한다.
   3. ICP dashboard가 “세계의 구조”를 보여 준다면 Request Lens는 “지금 세계에서 무엇이 변했는가”를 알려 준다.

4. GTM 팀이 사용하는 두 가지 에이전트

Exa의 GTM 조직은 에이전트를 보조 기능이 아니라 일상 업무와 내부 시스템을 구성하는 기본 도구로 사용한다.

4.1. Coding agents: 고객 조사와 데모 제작의 기본 계층

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

   1. Exa의 engineering team도 에이전트를 많이 사용하지만, GTM team의 에이전트 사용은 “crazy crazy crazy deep”할 정도로 깊다고 했다.
   2. Devin과 다른 coding agent의 사용 비용을 보면 GTM 팀의 지출이 매우 높게 나타난다.
   3. 높은 지출은 실험적 유행이 아니라 모든 구성원이 고객에 관해 에이전트에게 지속적으로 질문하기 때문에 발생한다.

2. 업무별 활용

   1. Account executive(AE)는 고객을 위한 데모를 직접 만든다.
   2. 특정 account를 더 깊이 조사할 때 에이전트를 호출한다.
   3. 고객 요구에 맞는 데모를 만들거나 내부 데이터를 조합할 때도 에이전트에 의존한다.

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

   1. Exa는 Slack 안에 약 12개의 서로 다른 에이전트를 둔다.
   2. 회사 구성원 누구나 그 에이전트들을 사용할 수 있다.
   3. 각 에이전트는 방대한 내부 데이터에 접근할 수 있으므로, 고객 조사와 데모 제작이 회사 맥락과 분리되지 않는다.

4.2. Jeff Bots: 창업자의 목소리와 판단을 모델링하기

1. 디지털 클론을 만든 계기

   1. Jeffrey Wang은 Jeff Bots를 가능한 한 자신의 AI clone으로 설명했다.
   2. 겨울 휴가로 일주일을 쉬면서 Mexico에 머물렀고, 많은 사람이 Opus 4.5를 가지고 놀던 시기에 자신도 실험했다.
   3. 그 일주일의 목표는 자기 자신을 디지털 클론으로 만들어 보는 것이었다.

2. 이메일 말투 분석

   1. 과거 이메일 760개를 분석해 자신의 email voice를 추출했다.
   2. 이메일 한 통의 평균 길이가 18단어라는 통계를 얻었다.
   3. “sincerely”보다 “best”로 이메일을 끝내는 습관을 확인했다.
   4. 이런 작은 문체·습관까지 모델에 넣어 자신다운 초안을 만들게 했다.

3. 의사결정 프레임워크와 evals

   1. 과거에 내린 수백 건의 결정을 분석해 의사결정 framework를 만들었다.
   2. 과거 결정에서 evals를 직접 생성했다.
   3. 생성한 evals로 agent system을 calibration해 Jeffrey Wang처럼 행동하는지 평가했다.

4. 광범위한 시스템 접근

   1. Jeffrey Wang은 회사의 거의 모든 시스템에 접근할 수 있는 권한이 있다.
   2. 그가 가진 권한과 데이터를 Jeff Bots에 read·write access로 연결했다.
   3. 결과적으로 Jeff Bots는 개인 이메일뿐 아니라 회사의 여러 시스템과 의사결정에 필요한 맥락을 활용한다.

4.3. Jeff Bots의 실제 사용과 권한 경계

1. 초안 생성 중심의 활용

   1. 회사 구성원 누구나 Jeff Bots를 호출해 Slack 메시지 초안을 만들 수 있다.
   2. 초안은 특정 질문에 대한 답변이나 이미 내려진 결정의 형태가 된다.
   3. GTM 팀은 특히 고객에게 보낼 이메일 초안을 만들 때 사용한다.

2. 린 조직의 생산성

   1. Exa의 GTM 팀은 매우 lean하지만 생산성이 높다.
   2. 사람 수를 단순히 늘리는 대신, 내부 지식·고객 데이터·에이전트를 결합해 한 사람이 처리할 수 있는 범위를 넓힌다.
   3. Jeff Bots는 창업자의 말투를 흉내 내는 장난감이 아니라, 지식 접근과 커뮤니케이션 초안 작성을 묶는 운영 인터페이스다.

5. Agent-first 회사의 세 가지 설계 원칙

Agent-first는 챗봇 하나를 도입하는 일이 아니라 API·인터페이스·구매 소프트웨어를 에이전트가 확장할 수 있게 설계하는 운영 원칙이다.

5.1. Agent-first의 전제는 API-first다

1. 내부·외부 데이터의 programmatic access

   1. Exa가 만든 에이전트와 GUI 위에 좋은 API가 없었다면 내부·외부 데이터에 접근할 수 없어 시스템이 작동하지 않는다.
   2. 에이전트는 데이터가 있는 곳까지 스스로 갈 수 있어야 하므로, 사람이 화면을 클릭하는 방식만으로는 부족하다.
   3. 데이터·업무 기능·권한을 프로그램이 호출할 수 있는 안정적인 인터페이스로 노출해야 한다.

2. 구현 형태보다 호출 가능성이 중요하다

   1. 그 인터페이스가 MCP(Model Context Protocol)인지 CLI인지 다른 방식인지는 본질이 아니다.
   2. 핵심은 에이전트가 이해하고 호출할 수 있는 programmatic interface를 제공하는 것이다.
   3. API가 부실하면 에이전트에게 데이터 접근 능력을 줄 수 없고, Agent-first 전략은 구호로 끝난다.

5.2. 모든 것을 chatbot으로 만들 필요는 없다

1. GUI와 chat agent의 역할 분담

   1. GUI와 chatbot은 서로 대체재가 아니라 각각의 장점을 가진 유용한 구성요소다.
   2. Dynamic user interface를 사용하면 AI가 질문마다 새로운 UI를 만들 수 있다.
   3. 간단한 질문에도 HTML이나 Markdown 파일처럼 즉석에서 생성된 화면을 제공할 수 있다.

2. 일관된 UX의 가치

   1. 같은 업무를 반복할 때는 매번 새로 생성되는 화면보다 같은 일관된 UX를 방문하는 편이 좋다.
   2. 사용자는 고정된 도구의 구조를 학습하고, 다음번에 더 빠르게 사용할 수 있다.
   3. 따라서 crystallized UI, 즉 반복 사용을 위해 형태가 굳어진 화면과 arbitrarily powerful flexible chat agent를 함께 둬야 한다.

5.3. 구매와 직접 구축은 거짓 양자택일이다

1. Salesforce를 살 것인가, CRM을 만들 것인가

   1. “Salesforce를 구매할까, 자체 CRM을 만들까”라는 질문은 두 선택지 중 하나를 고르는 문제가 아니다.
   2. 직접 만들면 코드를 써서 언제든 바꿀 수 있으므로 임의의 확장성이 생긴다.
   3. 구매한 SaaS도 회사가 원하는 방식으로 작동하게 만들고 임의로 확장할 수 있다면 같은 목적을 달성한다.

2. Exa의 Salesforce 사례

   1. Exa는 Salesforce를 사용한다.
   2. Salesforce는 좋은 database이며, 영업이 어떤 방식으로 운영되어야 하는지에 관한 중요한 선택을 이미 해 두었다.
   3. Exa가 자체적으로 만들고 싶지 않은 영업 운영의 기본 결정을 Salesforce가 제공한다.
   4. Salesforce가 MCP를 노출하므로 Exa의 모든 에이전트가 Salesforce MCP에 접근할 수 있다.
   5. 팀은 Salesforce와 연결된 에이전트를 매일 사용하며, 구매한 시스템도 내부 에이전트의 작업 기반으로 만든다.

3. 최상위 설계 기준은 무한한 커스터마이즈 가능성이다

   1. SaaS를 선택할 때 제품 로드맵에 필요한 기능이 언젠가 추가되기를 기다릴 필요가 없다.
   2. 시스템을 구매했더라도 API·MCP·확장 지점으로 회사의 맥락에 맞게 계속 바꿀 수 있어야 한다.
   3. 무한한 커스터마이즈 가능성(infinite customizability)이 Build-versus-buy 논쟁보다 더 높은 우선순위다.

6. Q&A: 데이터, 팀, 보안, FDE 조직

질문은 Jeff Bots의 학습 자료, GTM 인력의 기술 수준, 전사 권한 경계, FDE 직무가 생긴 배경으로 이어졌다.

6.1. 과거 의사결정의 학습 자료

1. 의사결정 artifact의 출처

   1. 청중은 보통 의사결정을 따로 저장하지 않는데, 어떤 artifact를 사용했는지 물었다.
   2. Jeffrey Wang은 Slack과 email 안에서 자신이 내린 결정을 찾았다고 답했다.
   3. 문서화된 결정 기록이 없어도 Slack history를 많이 읽으면 과거의 의사결정 수백 건을 찾아낼 수 있다고 했다.

2. 조직 지식의 실재 위치

   1. 회사에서 일어나는 일의 놀라울 정도로 많은 부분이 Slack에 남는다.
   2. 결정의 배경·논쟁·결론·후속 조치가 대화와 이메일에 분산되어 있다.
   3. 따라서 지식 시스템은 새 데이터베이스를 기다리기보다 기존 커뮤니케이션 기록에서 평가 가능한 사례를 추출할 수 있다.

6.2. GTM 팀의 직무 구성과 AI 숙련도

1. 세 가지 조직

   1. Account executive는 거래를 운영한다.
   2. SDR(sales development representative)은 demand generation을 돕는다.
   3. 별도의 FDE(forward deployed engineering) 조직이 고객 현장과 기술 지원을 담당한다.

2. FDE 밖의 구성원도 AI를 능숙하게 사용한다

   1. FDE가 아닌 구성원도 AI를 매우 잘 사용하도록 학습했다.
   2. 이들이 일반적으로 직접 vibe coding으로 내부 인터페이스를 만들지는 않는다. 일부 예외는 있다.
   3. 대신 이미 제공된 도구를 매우 잘 쓰도록 training session을 운영하고, 구성원이 도구의 사용법을 확실히 이해하게 한다.

3. FDE의 이중 역할

   1. FDE 조직은 고객 거래를 실행하고 지원하는 동시에 AI 시스템의 유지보수와 기능 개발을 담당한다.
   2. 영업을 하면서 영업 시스템 자체를 만든다.
   3. 거래를 지원하고, 반복되는 업무를 매끄럽게 만들고, AE의 삶과 자신의 삶을 쉽게 만드는 도구를 구축한다.
   4. 영업과 시스템 개발이 한 조직에 겹쳐 있는 점이 독특하고 “funky”한 운영 방식이라고 설명했다.

6.3. Jeff Bots의 보안 경계와 guardrails

1. 호출자에 따른 권한 차등

   1. Jeffrey Wang 본인이 Jeff Bots를 호출할 때는 많은 시스템에 read·write할 수 있다.
   2. 다른 구성원이 호출할 때는 Slack 메시지 초안 작성만 할 수 있다.
   3. 다른 구성원이 호출한 Jeff Bots에는 모든 MCP와 도구 권한을 부여하지 않는다.

2. 전사 단일 권한 모델이 아니다

   1. Jeff Bots가 창업자의 모든 권한을 가진다고 해서 모든 구성원이 모든 데이터를 항상 읽는 구조는 아니다.
   2. 호출자의 신원과 사용 맥락에 따라 허용 동작과 도구 목록을 제한한다.
   3. 권한 경계를 명확히 정의하고 guardrail을 신경 써서 설계했다고 답했다.

6.4. FDE 직무의 기원과 현재 규모

1. 기존 직무와 FDE의 등장

   1. 과거에는 FDE라는 역할이 일반적으로 존재하지 않았다.
   2. Palantir가 일부 인력을 FDE라고 부르기 시작한 것이 초기 사례였고, 기존 기술 회사에는 solutions engineer와 sales engineer, account executive가 있었다.
   3. 질문자는 자신도 과거에 solutions engineer였다고 덧붙였다.

2. AI가 두 업무를 겹치게 만들었다

   1. AI 이전에는 기술 지식을 바탕으로 매출을 지원하는 일과 그 업무를 자동화하는 도구를 만드는 일이 사실상 두 직업이었다.
   2. AI 이후에는 매출을 지원하는 technical person이 도구를 직접 만들어 업무 흐름을 매끄럽게 할 수 있다.
   3. “이론적으로는 두 jobs가 하나가 됐다”는 표현으로 가능성과 한계를 함께 강조했다.

3. 현재 규모와 확장성의 한계

   1. Exa에는 현재 약 8~9명의 FDE가 있다.
   2. 회사 전체 인원은 약 115명이다.
   3. 팀이 커지면 모든 사람이 거래·지원·도구 개발을 전부 수행하는 구조가 계속 확장될지는 확실하지 않으며, 아마 그렇지는 않을 것이라고 했다.
   4. 다만 현재 규모에서는 이 모델이 꽤 멀리 갈 수 있는 좋은 working model이라고 평가했다.

주요 발언 모음

“Go-to-market is a data problem.”

“You need basically a live model of your world that agents can act on.”

“If you don't do both things, then you don't have a company.”

“To be agent-first you must be API-first.”

“Does everything need to be a chatbot? I think the answer is no.”

“Infinite customizability is really the highest order bit.”

“Before that was like two jobs, and now it's like one job. In theory.”

핵심 데이터 & 수치

• 2023년 중반: Exa가 출시된 시점이며 GPT-4 이후의 시대에 시작했다.
• 6,000만 개 이상: 세계에 존재하는 회사의 규모로 제시했다.
• 10억 명 이상: LinkedIn에 있는 사람 수로 제시했다.
• 760개: Jeff Bots가 Jeffrey Wang의 이메일 말투를 분석한 이메일 수다.
• 18단어: 평균 이메일 길이다.
• 약 12개: Exa Slack 안에서 구성원이 사용할 수 있는 에이전트 수다.
• 수백 건: 의사결정 framework와 evals를 만들 때 분석한 과거 결정의 규모다.
• 8~9명: Exa의 현재 FDE 인원이다.
• 약 115명: Exa의 전체 인원이다.

핵심 요약 (20줄)

1. Jeffrey Wang은 Exa의 공동창업자로서 GTM을 AI engineering 문제로 다룬다.
2. Exa는 웹에 접근하지 못하는 에이전트를 위해 검색과 웹 MCP를 제공한다.
3. 좋은 제품과 강한 Distribution은 대립 항목이 아니라 함께 갖춰야 할 회사의 두 축이다.
4. 엔지니어의 제품 구축 편향은 마케팅과 영업을 놓치게 만들 수 있다.
5. GTM의 고객 조사·담당자 탐색·POC 제작은 모두 데이터 문제로 통합된다.
6. 에이전트가 행동하려면 내부·외부 데이터를 반영한 살아 있는 세계 모델이 필요하다.
7. Exa는 6,000만 개가 넘는 회사와 10억 명이 넘는 LinkedIn 인맥이 있는 외부 세계를 탐색한다.
8. ICP dashboard는 TAM의 회사를 분류해 고객과 사용 사례의 세계를 보여 준다.
9. SpaceX 같은 기업을 선택하면 예상 연간 지출과 다양한 메타데이터를 심층 조사할 수 있다.
10. 인터넷 위에 학습한 embeddings는 의미 기반 검색과 데이터 slicing을 가능하게 한다.
11. Request Lens는 가입·대량 검색·사용 중단 같은 고객 이벤트를 행동 가능한 신호로 바꾼다.
12. Exa GTM 팀은 약 12개의 Slack 에이전트와 높은 Devin 사용량으로 고객 조사와 데모를 수행한다.
13. Jeff Bots는 이메일 760개와 수백 건의 과거 결정을 분석해 창업자의 말투와 판단을 모방한다.
14. Jeff Bots는 평균 18단어의 이메일과 “best”로 끝내는 습관까지 학습한다.
15. Agent-first 회사의 첫 원칙은 내부·외부 데이터를 호출 가능한 API로 만드는 API-first다.
16. 일관된 GUI와 유연한 chat agent는 서로 다른 사용 맥락을 충족하므로 함께 필요하다.
17. 구매한 Salesforce도 MCP와 확장성을 통해 자체 구축 시스템처럼 커스터마이즈할 수 있다.
18. FDE는 거래 지원과 AI 시스템 유지보수·기능 개발을 동시에 맡는 기술 기반 GTM 역할이다.
19. Jeff Bots는 창업자에게 read·write를 허용하지만 다른 구성원에게는 메시지 초안만 허용한다.
20. 약 115명 회사에서 8~9명의 FDE가 영업과 영업 시스템 구축을 결합하는 실험을 이어 간다.

결론 및 시사점

1. GTM을 데이터 제품으로 설계한다: 고객·회사·제품 사용량·시장 이벤트를 한데 모아 에이전트가 조회할 수 있는 live model을 만든다.
2. 신호를 행동으로 연결한다: 가입, 급격한 사용량, 이탈 같은 이벤트를 놓치지 말고 알림·조사·연락·데모 제작으로 이어지는 Request Lens형 루프를 구성한다.
3. API를 먼저 만든다: MCP·CLI 등 구현 명칭보다 내부·외부 데이터와 기능을 프로그램적으로 호출할 수 있는지가 중요하다.
4. 인터페이스를 이중화한다: 반복 업무에는 학습 가능한 crystallized GUI를 제공하고, 예외적·탐색적 업무에는 유연한 chat agent를 제공한다.
5. Build-versus-buy를 커스터마이즈성으로 판단한다: 직접 만든다는 사실보다 구매한 SaaS도 회사 맥락에 맞게 무한히 확장할 수 있는지가 더 중요한 기준이다.
6. 기술 GTM 직무를 재설계한다: FDE처럼 거래 지원자가 고객 업무를 이해하고 동시에 영업 시스템을 개선하는 구조를 만들면, AI가 사람 수가 아닌 업무 처리 범위를 확장한다.
7. 권한은 호출자별로 나눈다: 창업자에게 필요한 read·write 권한과 전사 구성원의 초안 작성 권한을 분리해 에이전트의 생산성과 보안을 함께 확보한다.