GTM을 위한 AI가 성과를 내지 못한 이유 (그리고 해결 방법)

AI SDR, 인텐트 도구, 자동 리서치, 이메일 카피 생성 등 다양한 AI를 도입한 GTM(Go-To-Market) 팀 대부분이 기대만큼 영업 생산성·파이프라인·매출 향상을 체감하지 못하고 있습니다. 왜 그럴까요? 이 글은 그 원인과 해결책을 정리합니다.

원천 데이터와 실행 도구 사이에 자사 고유의 GTM Context Layer를 두는 것이 핵심

도입 — AI가 GTM 성과를 내지 못하는 현실

대부분의 GTM 팀은 이미 이메일 작성, AI SDR, 인텐트 도구, 신호 기반 아웃바운드, 자동 리서치, 딜 리뷰 등 어떤 형태로든 AI를 도입하고 있습니다. 본래 AI는 담당자 효율, 파이프라인, 실제로 성성된 거래에서 발생한 매출을 측정 가능한 수준으로 끌어올려야 하지만, 대다수 팀의 결과는 여전히 미흡합니다.

AI에 계정 공략을 시키면 다음과 같은 결과가 나옵니다.

"Acme is hiring SDRs and had a closed-lost opportunity last year. Reach out about renewed pipeline growth."

기술적으로는 맞지만 완전히 일반적입니다. 담당자는 여전히 수동 리서치를 해야 하고, 우선순위 판단은 추측에 머물며, 아웃리치가 인위적으로 느껴집니다. 핵심 문제는 의사결정에 필요한 컨텍스트(context)와 로직(logic) 없이 AI에 GTM 의사결정을 맡기는 데 있습니다.

GTM의 North Star — AI가 실제로 개선해야 할 지점

첫 원칙에서 보면 GTM 팀은 세 가지에 집중해야 합니다.

1. 더 많은 파이프라인
2. 더 빠른 파이프라인 진행
3. 더 많은 클로즈드원 매출

영업 조직이 통제 가능한 세 가지 "입력(input)"으로 더 깊이 들어가면 다음과 같습니다.

계층	정의	AI 레버리지	실제 효과
Targeting (타겟팅)	어떤 계정과 사람에 집중할지	상 (upstream)	가장 큰 영향
Hypothesis (가설)	어떤 문제를 제기하고 해결을 제안할지	상 (upstream)	큰 영향
Execution (실행)	아웃리치·콜·발표 등 전환	중 (downstream)	품질 향상만

세 영역 모두 AI가 레버리지를 더할 수 있는 지점이지만, 실제로 어디에 나타나는지에서 문제가 시작됩니다. 대부분의 GTM AI 도구가 세 번째 계층인 Execution에 지나치게 집중해 이메일 작성·계정 요약·콜 스크립트 생성·활동 자동화에는 유용하지만, 진짜 레버리지가 있는 곳은 아닙니다.

The Reality — 진짜 알파는 상위(upstream)에 있다

타겟팅과 관점(point of view)의 품질이 보내는 이메일의 품질보다 훨씬 더 중요합니다. 흔한 신호로 계정을 고르고 약한 가설을 세우면, '훌륭한' 이메일도 아무 효과가 없습니다. 반대로 올바른 계정에 날카로운 가설로 접근하면, 카피가 완벽할 필요 없이 관련성만 있으면 됩니다.

같은 채용 신호라도 계정별로 우선순위와 가설이 완전히 다릅니다

오늘날의 에이전트는 다음을 판단하는 전문가가 아닙니다.

• 어떤 계정이 중요한지
• 왜 지금 그 계정이 중요한지
• 누가 가장 관련 있는지
• 어떤 페인이 가장 가능성 높은지
• 어떤 메시지가 실제로 신뢰를 줄지

그 결과 GTM AI 시도가 부진합니다. 두 가지 서로 연관된 근본 원인이 존재합니다.

Problem One — AI가 올바른 컨텍스트를 갖지 못함

GTM 스택은 파편화되어 있고, 뛰어난 영업자는 어떤 신호가 구매 결정을 좌우하는지, 어떻게 포착·우선순위화·관계 파악하는지 정확히 압니다. 이들은 CRM, 콜 녹취, 인텐트 활동, 상호 인맥, 채용 공고, Reddit, 온라인 포럼 등 가용한 모든 정보를 파고들어 타겟팅·가설·메시징을 설계합니다.

에이전트도 다르지 않습니다. LLM에 누구를 타겟할지·무엇을 말할지 물을 때, (a) 퍼즐의 일부만 갖고 있거나 (b) 조각들이 어떻게 맞물리는지 모르면(혹은 둘 다라면) 효과적일 수 없습니다.

예시 — 같은 채용 신호, 전혀 다른 두 계정

두 회사가 최근 SDR 채용 공고를 올렸다고 가정합니다. 올바른 컨텍스트·로직이 없는 에이전트는 두 계정에서 동일한 채용 신호를 감지해 둘 다 우선순위화하고 유사한 아웃바운드를 생성합니다. 실제로는 적합성·인텐트·상황, 따라서 우선순위가 완전히 다를 수 있습니다.

회사	상황	우선순위	에이전트가 모를 때의 결과
Company A	아웃바운드 확장, 자사 연동 도구 사용, 최근 웹사이트 방문, 과거 챔피언 신규 채용	높음	일반적 메시지로 경쟁자에게 양보
Company B	대체 어려운 도구 사용, 워크플로 비연동, 지난달 SDR 3년 계약 성사	매우 낮음	시간 낭비 + 평판 손상

에이전트가 모든 데이터에 접근하지 못하고, 자사가 어디서 이기고 부족한지·기존 도구 대비 비교·연동 시스템·가장 잘 푸는 페인·추구할 가치 있는 구매 시나리오를 모르면 효과를 낼 수 없습니다. 신호를 AI에 공급하는 것은 쉬운 부분이고, 어려운 부분은 어떤 신호가 중요한지·어떻게 순위를 매길지·무엇을 앞세울지 AI가 비즈니스를 충분히 이해하도록 보장하는 것입니다.

Problem Two — 빌려온 로직은 경쟁력이 될 수 없음

전략적 결함은 자사의 핵심 경쟁 우위여야 할 것을 외부에 위탁하는 데 있습니다. 타겟팅·가설 생성 등 상위 인텔리전스(upstream intelligence)를 AI GTM 벤더로부터 구매하는 행위, 이를 위탁하면 해당 모델·벤더를 쓰는 모든 이와 동일한 의사결정 로직을 돌리게 됩니다. 모두가 접근 가능한 신호나 전략은 정의상 우위가 될 수 없습니다.

독점적일 수 있는 유일한 것은 그것으로 무엇을 하느냐, 즉 어떤 신호가 중요한지·어떻게 결합되는지·자사에 무엇을 의미하는지를 결정하는 해석(interpretation) 계층입니다. 그 해석 계층마저 벤더에게서 사면, 마지막 남은 우위까지 일반재화가 됩니다.

다만 워크플로의 일부는 구매가 합당합니다. 계정 보강, 채용 공고 검색, 웹사이트 스크래핑, 초안 생성, 콜 요약, 리드 라우팅, 데이터 동기화, 이메일 발송 같은 실행 계층(execution layer) 도구를 직접 만드는 것은 비효율적입니다. 반면 위탁해서는 안 되는 상위·핵심 영역이 있습니다.

Buy vs Own — 단순한 규칙

• Buy (일을 실행하는 도구): 채용 공고 식별, 연락처 보강, 이메일 카피 생성, 이메일 발송 등
• Own (의사결정에 영향을 주는 로직): 채용 공고에서 무엇을 찾을지, 어떤 신호를 스크래핑할지, 계정 우선순위를 어떻게 매길지 등

The Fix — GTM Context Layer 구축

AI로 성과를 내는 팀은 원천 데이터와 실행 도구 사이에 인텔리전스 계층(intelligence layer)을 둡니다. 신호를 자사만 만들 수 있는 관점으로 전환하는 것이 핵심입니다. 이것이 GTM Context Layer이며, 어떤 신호가 중요한지·어떻게 해석할지·어떤 시나리오를 시나리오하는지·누가 관심 있을지·어떤 메시지가 맞는지를 사람과 에이전트에게 알려주는 독점 시스템입니다.

강력한 GTM Context Layer는 Data Foundation, Decision Logic, AI Orchestration의 3계층으로 구성됩니다

강력한 GTM Context Layer의 세 부분

1) Data Foundation (데이터 기반)

CRM 데이터, 기회 이력, 실주 사유, 제품 사용, 웹사이트 활동, 보강(enrichment), 채용 공고, 뉴스, 테크노그래픽, 콜 노트, 이메일 인게이지먼트, 파트너 노트, 담당자 활동 등 원천 재료를 한데 모읍니다.

• 구축 방식: Warehouse + ETL 파이프라인, CRM 동기화, 보강 API, 제품 이벤트, 스크래핑, 정규화 테이블
• 효과: 사람과 에이전트에게 계정의 전체 그림 제공

2) GTM Decision Logic (의사결정 로직)

ICP, 페르소나, 계정 스코어링, 신호 가중치, 라우팅 로직, 구매 시나리오, 제외 기준(disqualifier), 플레이북을 정의하는 규칙 기반 계층입니다.

• 구축 방식: SQL/dbt 모델, 스코어링 테이블, 룰 엔진, 세그먼트, 비즈니스가 소유한 로직
• 효과: 원천 데이터를 자사 고유의 GTM 판단으로 전환하는 진짜 경쟁력(edge)

3) AI Orchestration Layer (AI 오케스트레이션 계층)

검색(retrieval), 도구 호출, 프롬프트 라우팅, 에이전트 스킬, 컨텍스트 조립, 출력 생성을 조율하는 워크플로 계층입니다. 어떤 컨텍스트를 가져올지·어떤 소스를 확인할지·어떤 신호를 랭킹할지·어떤 플레이북을 적용할지·어떤 스킬을 실행할지를 결정합니다.

• 구축 방식: 벡터 검색, SQL 쿼리, 프롬프트 라우팅, 시스템 프롬프트, 도구 호출, 에이전트 스킬, 구조화 출력, 피드백 루프
• 효과: 전략을 행동으로 전환, 더 나은 우선순위화·더 날카로운 메시징·GTM 로직을 따르는 에이전트

제대로 하면 에이전트의 출력이 다음과 같이 바뀝니다.

변경 전

"Acme is hiring SDRs and had a closed-lost opportunity last year. Reach out about renewed pipeline growth."

변경 후

"Acme is hiring SDRs and RevOps, uses a stack we consolidate well, and lost last time due to timing. Prioritize RevOps with a tooling-efficiency angle, Sales with a pipeline-growth angle, and tailor outreach to the pain each team owns."

Where to Start — 어디서 시작할지

전체 GTM 스택을 하룻밤에 재구축할 필요 없습니다. 세 가지를 점검하며 시작하면 됩니다.

1. Decision Logic의 위치 감사: 누구를 타겟하고 가치를 어떻게 포지셔닝할지를 서드파티 AI 알고리듬이 결정하게 두고 있는지 확인합니다. 그렇다면 ICP 정의를 내부로 되돌리세요.
2. 신호에서 시나리오로 전환: 단일·고립된 이벤트로 아웃리치를 트리거하지 말고, 데이터 팀이 부정할 수 없는 페인을 가리키는 이벤트 조합을 찾는 모델을 만들도록 지시하세요.
3. 오케스트레이션 페이로드 제약: 도구에 무엇을 말할지 추측시키지 말고, 모든 잠재고객마다 고도로 제한적이고 초맥락적인 페이로드를 전달하세요.

세 가지를 한 번에 할 필요는 없으며, 하나만 해도 실제 의사결정을 비즈니스 내부로 되돌려 동일한 기본 로직을 돌리는 경쟁사보다 앞설 수 있습니다.

결론

GTM용 AI가 부진한 이유는 단순합니다. 팀이 실행은 자동화하면서 그 이면의 상위 판단(upstream judgment)에는 투자하지 않기 때문입니다. 이제 모두가 같은 모델과 같은 기성 신호를 가집니다. 앞서가는 팀을 가르는 것은 실행 상위에서 자사가 소유한 것, 즉 직접 만든 커스텀 신호와 왜 이 계정·왜 지금·누구에게·무엇을 말할지 아는 컨텍스트 계층입니다.

AI는 전략을 대체하지 않으며, 그 전략이 실제로 얼마나 좋은지를 드러낼 뿐입니다. 오늘날 대부분의 구현이 그 증거입니다.

---

원문: GTM을 위한 AI가 성과를 내지 못한 이유 (그리고 해결 방법) — GeekNews