최근 B2B SaaS 업계에 새로운 직무가 등장했습니다: GTM Engineer (Go-To-Market Engineer). Apollo와 같은 회사들은 이들을 '엔지니어링 방식으로 revenue(수익)를 창출하는 사람'이라고 적극적으로 소개하고 있습니다.

이 역할은 확실히 흥미롭지만, 이들이 '왜 지금 나타났는지'를 이해하려면 바로 뛰어들어서는 안 됩니다. 먼저 세 가지 기초를 다져야 합니다: GTM이란 무엇인가, Sales Pipeline과 CRM이란 무엇인가, 그리고 AI(특히 agent)가 이 모든 것을 어떻게 변화시키는가입니다. 이 글에서는 이 순서에 따라 한 단계씩 설명하겠습니다.

1. GTM이란 무엇인가

GTM (Go-To-Market), 중국어로는 '시장 진입'이라 하며, 기업이 제품을 적절한 고객에게 전달하고 그들을 설득하여 구매하게 만드는 일련의 전체 과정을 의미합니다.

이는 특정 부서가 아니라, 여러 부서를 가로지르는 하나의 '액션 체인(action chain)'입니다:

• Marketing (마케팅): 적절한 사람들에게 당신을 알리고 관심을 갖게 만드는 역할 (수요 창출, 리드 유입);
• Sales (영업): 관심 있는 사람을 실제 결제 고객으로 전환하는 역할 (팔로업, 협상, 계약 체결);
• Customer Success (고객 성공): 고객이 잔류하고, 재계약하며, 더 많은 제품을 구매하도록 만드는 역할.

한 회사가 '어떻게 체계적으로 물건을 판매하는가'가 바로 그 회사의 **GTM motion (시장 진입 방식)**입니다. 영업 사원이 능동적으로 나서는 방식(outbound, 아웃바운드)이 있는가 하면, 콘텐츠와 제품이 스스로 고객을 끌어들이는 방식(inbound, 인바운드)이 있습니다. 어떤 방식이든 결국 동일한 질문에 답해야 합니다: '누구를 찾아야 하는가, 어떻게 그를 찾을 것인가, 어떻게 그를 「계약 체결」로 이끌 것인가.'

그리고 '계약 체결로 가는' 이 길은 B2B 세계에서 구체적인 매개체인 Sales Pipeline을 통해 나타납니다.

2. Sales Pipeline과 CRM: GTM의 실행 매개체

Sales Pipeline (영업 파이프라인)은 하나의 비즈니스가 '낯선 명단'에서 '계약 체결'에 이르기까지 거치는 단계입니다. 전형적인 B2B pipeline은 다음과 같습니다:

팀은 또한 각 단계의 계약 확률을 사용하여 이 파이프라인이 대략 어느 정도의 수익을 가져올 수 있을지 추정합니다. 이것이 바로 매일 확인하는 'pipeline의 건강 상태'입니다.

이 파이프라인은 어디에 존재할까요? 바로 CRM (Customer Relationship Management, 고객 관계 관리 시스템), 즉 Salesforce나 HubSpot 같은 소프트웨어 안에 있습니다. CRM은 전체 영업의 '시스템 기록 (system of record)'입니다. 모든 연락처, 모든 회사, 모든 기회, 모든 상호작용이 그 안에 기록됩니다. Sales Pipeline은 CRM 내에서 눈에 보이고 앞으로 밀고 나갈 수 있는 핵심 주선입니다.

이 관계를 명확히 이해하면 GTM의 목표가 구체화됩니다. (범위를 먼저 명확히 하자면: 이후 내용은 「고객 획득부터 계약 체결까지」의 구간에 집중합니다. 완전한 GTM에는 계약 체결 이후의 유지 및 확장, 즉 Customer Success 영역도 포함되지만 이 글에서는 다루지 않습니다.) 고객 획득부터 계약 체결까지의 구간에서 GTM이 존재하는 의미는, 이 파이프라인을 가득 채우고 그것이 원활하게 흘러가도록 만드는 것입니다:

• 상류 채우기: 적절한 사람이 들어오게 하기 — **ICP (Ideal Customer Profile, 이상적 고객 프로필, 즉 '어떤 유형의 고객이 당신에게 가장 적합한가')**에 부합하는 명단을 찾는 것;
• 중류 밀어주기: 그들이 한 단계에서 다음 단계로 넘어가도록 하기 (점수 산정, 팔로업, 접촉, 적절한 영업 담당자 배정);
• 청결 유지: 데이터가 망가지지 않게 하고, 명단이 누락되지 않게 관리하기 (data hygiene, 데이터 위생).

GTM은 어디에서 value를 add(가치 창출)할까요? 파이프라인은 스스로 채워지거나 스스로 깨끗하게 유지되지 않기 때문입니다. 누군가는 반드시 다음과 같은 결정을 내려야 합니다: '누구를 찾을 것인가 (ICP 및 TAM — Total Addressable Market, 전체 잠재 시장 규모), 누가 더 뜨거운 고객인지 어떻게 판단할 것인가 (scoring, 점수 산정), 부족한 데이터는 어떻게 보충할 것인가 (enrichment, 데이터 보강), 어떻게 접촉할 것인가 (outreach, 대외 접촉), 들어온 명단을 누구에게 배정할 것인가 (routing, 명단 배정).' 이러한 업무들은 과거에 marketing ops, sales ops, RevOps (Revenue Operations, 마케팅, 영업, 고객 성공을 연결하는 운영 직무) 등 여러 역할에 흩어져 있었습니다. GTM Engineer는 이 일련의 과정을 다시 묶어 「엔지니어링화되고 규모 확장이 가능한 시스템」으로 만드는 사람입니다.

Sales Pipeline 六階段:Lead → MQL → SQL → Opportunity → Negotiation → Closed Won/Lost;這條線住在 CRM 裡,GTM 在上面做三件事——填上游、推中游、保乾淨。

여기까지 AI에 대한 이야기는 나오지 않았습니다. 이 역할의 뼈대는 사실 AI가 등장하기 전부터 존재해 왔습니다. 다만 지금, AI가 그 중요성을 단번에 증폭시킨 것뿐입니다.

3. data-driven에서 agent-first로: 방법론의 진화

동일한 과업(파이프라인(pipeline)을 채우고 추진하는 것)을 수행하는 방식은 계속해서 진화해 왔습니다.

초기: 경험에 의존. 영업 담당자가 CRM 대시보드를 보며 직관에 따라 누구에게 먼저 연락할지 결정했습니다.

다음: data-driven (데이터 주도). 더 이상 직관에만 의존하지 않고, 데이터를 근거로 판단합니다. 예를 들어 리드 스코어링 (lead scoring) 시 '기업 규모, 산업군, 상호작용 여부'를 사용하여 점수를 산출하고, 점수가 높은 대상부터 공략합니다. 의사결정의 근거가 '감'에서 '데이터'로 변한 것입니다. 이 단계는 이미 많은 성숙한 팀들이 실행하고 있습니다.

현재: AI-driven, 그리고 그 실천 방식은 agent-first입니다. 여기서 먼저 agent(에이전트)가 무엇인지 명확히 정의하겠습니다. 에이전트는 하나의 목표에 따라 스스로 도구를 호출하고 여러 단계를 연속적으로 실행할 수 있는 AI 시스템을 의미합니다. 단순히 묻고 답하는 챗봇(chatbot)과는 다릅니다. 과거에는 데이터가 그저 '사람이 보기 위한 것'이었고 사람이 이를 보고 판단했다면, 이제 에이전트는 스스로 이 일들을 수행할 수 있습니다. 특정 기업을 자동으로 조사하고, 누락된 필드를 채우며, 맞춤형 오프닝 멘트를 작성하고, 점수를 산출하여 배정 여부를 결정합니다. 에이전트는 '사람이 데이터를 보는 것을 보조하는 역할'에서 '주요 실행자'로 업그레이드되었습니다. 이것이 바로 agent-first입니다. 에이전트를 최전선에 배치하고, 사람의 역할은 목표 설정, 규칙 수립, 승인 단계(approval gate)를 관리하는 상위 단계로 이동하는 것입니다.

이는 진정한 도약입니다. 하지만 여기에는 agent-first가 자산이 될지 재앙이 될지를 결정짓는 핵심 전제 조건이 있습니다.

만약 에이전트를 구속할 workflow (고정된 입력, 단계, 체크포인트가 있는 프로세스)가 없다면, 에이전트의 출력값은 매우 불안정할 수 있으며, 근거 없는 내용을 매우 그럴듯하게 생성해낼 수도 있습니다.

다시 말해, agent-first가 가치를 더할 수 있는지(add value) 여부는 에이전트 자체가 얼마나 똑똑한가가 아니라, 그 에이전트를 가두어 둘 프로세스가 있느냐에 달려 있습니다. 여기서 혼동하기 쉬운 지점을 특별히 주의해야 합니다. 이 프로세스는 앞서 언급한 Sales Pipeline과는 별개의 것입니다.

• Sales Pipeline은 비즈니스가 추진되는 단계(Lead → … → 계약 체결)입니다.
• 여기서 말하는 것은 **agent workflow (에이전트 워크플로우)**입니다. 즉, 에이전트가 어떤 입력을 받고, 어떤 단계를 거치며, 어떤 검증을 통과하여 출력을 내보낼지를 규정하는 기술적 프로세스입니다.

후자는 전자가 더 빠르고 깨끗하게 돌아가도록 지원하는 역할을 합니다. 에이전트 워크플로우라는 지지 기반이 있어야 에이전트가 '유연함'과 '통제 가능함'을 동시에 달성할 수 있습니다. 이것이 없다면 에이전트는 그럴듯하게 말하지만 직접 믿고 맡기기에는 불안한 블랙박스(black box)에 불과합니다. 다음 질문은 이것입니다: 에이전트가 내놓은 결과물을 다음 단계로 넘겨도 되는지 어떻게 판단할 것인가?

4. 에이전트의 출력이 파이프라인에 깨끗하게 가치를 더하게 만드는 법

핵심은 매우 간단한 개념입니다: 에이전트가 내놓은 것은 우선 '데이터(data)'로 간주해야 하며, '사실(fact)'이 아닙니다. 에이전트가 생성한 것은 당연히 데이터입니다. 하지만 다음 단계에서 안전하게 사용할 수 있어야 비로소 '정보(information)'라고 부를 수 있습니다. 이 중간 단계인 '데이터를 정보로 업그레이드하는' 전환 과정이 바로 에이전트 워크플로우의 진정한 가치입니다.

이 전환을 수행하기 위해, 먼저 각 필드에 **출처 신뢰도 (provenance)**를 네 가지 계층으로 라벨링합니다.

그 후, 하나의 데이터가 낮은 신뢰도 계층에서 높은 신뢰도 계층으로 **'승격(promote)'**되기 위해 어떤 조건을 충족해야 하는지 명확히 정의합니다. 하나의 완전한 프로세스를 예로 들면 이해가 빠를 것입니다. 예를 들어, 당신의 에이전트가 특정 목표 기업을 조사하고 있다고 가정해 봅시다.

1. 에이전트가 "이 회사는 최근 보안 팀을 확장하고 있습니다"라는 문장을 생성합니다. 이 시점에서 이것은 generated (생성됨) 상태입니다. 즉, 에이전트가 스스로 말한 것이며, 맞을 수도 있고 환각 (hallucination)일 수도 있습니다. 우선 검증 없이 그대로 generated로 표시해야 하며, CRM의 사실 (fact) 필드에 직접 기록해서는 안 됩니다.
2. 그다음 근거를 찾습니다. 예를 들어, 해당 회사의 공식 웹사이트에서 이번 달에 게시된 세 건의 보안 관련 채용 공고를 발견했다고 가정해 봅시다. **출처(source) + 시간(time)**이 확보되면, 이 문장은 "에이전트가 한 말"에서 "근거 있는 관측"으로 변하며, 시그널 (signal)로 업그레이드됩니다. 이를 CRM에 기록할 때는 "출처: 공식 채용 페이지, 2026-07"과 같은 정보를 함께 첨부합니다.
3. 만약 출처가 충분히 권위 있고 안정적이라면 (예: 회사의 공개 재무 보고서에 보안 투자가 명시된 경우), 이는 심지어 fact (사실) 필드를 뒷받침할 수 있습니다.
4. 한편, 스코어링 (scoring) 모델은 이 시그널 + 회사 규모 + 상호작용 기록을 입력받아 "우선 순위 팔로업 가치 있음, 점수 0.72"를 산출합니다. 이 점수는 **derived (도출됨)**된 것이며, 어떤 모델 버전을 사용했는지, 신뢰도는 얼마인지, 유효 기간은 언제인지 함께 기록해야 합니다.

資料的升級路徑:generated(agent 說「這家公司在擴充資安團隊」)—找到來源+時間→ signal(官網職缺,帶時效)—來源夠權威→ fact(可當真相);derived 是推算欄位如分數 0.72,記版本與信心;核心規則是 generated 不冒充 fact。

이 과정을 거치면 "데이터가 어떻게 정보 (information)가 되는가"가 구체화됩니다. 에이전트가 내뱉은 원시 문장은 데이터 (data)입니다. 하지만 "계층 표시 → 출처 찾기 → 검증 → 버전 기록"의 처리를 거쳐야만, 다음 단계(영업 담당자 또는 다음 에이전트)가 안전하게 사용할 수 있는 정보 (information)가 됩니다.

이 과정에서 반드시 지켜야 할 가장 중요한 규칙은 generated된 것을 직접 fact로 위장해서는 안 된다는 것입니다. 검증되지 않은 추측이 사실로 기록되는 순간, 하류(downstream)의 모든 사람과 모든 후속 에이전트가 이를 믿게 됩니다. 즉, 단 하나의 환각이 전체 파이프라인 (pipeline)을 오염시키게 됩니다. 반대로 이 규칙만 잘 지킨다면, 에이전트 우선 (agent-first) 방식은 순수한 가치 창출이 됩니다. 에이전트는 "기업 조사, 데이터 보완, 초안 작성, 점수 산출"과 같이 본래 많은 인력이 소모되던 작업들을 대폭 가속화하는 동시에, 모든 출력물에 계층이 명확히 표시되므로 전체 파이프라인은 오히려 더 투명해지고 유지보수하기 쉬워집니다. 에이전트가 파이프라인을 더 빠르게 달리게 한다면, 워크플로우 (workflow)는 에이전트가 신뢰받으며 달릴 수 있게 합니다. 이 둘은 서로를 완성합니다.

5. 인간은 어디에 서 있는가

에이전트 우선 (agent-first) 방식이 "인간의 퇴장"을 의미하는 것은 아닙니다. 오히려 인간의 위치가 바뀌는 것입니다. 잘 설계된 GTM 시스템에서 인간은 세 가지 지점을 지킵니다:

1. 목표 설정 — "이번 분기에 어떤 시장 세그먼트를 공략할 것인가, 어떤 고객을 우량 고객으로 볼 것인가"는 에이전트가 아닌 인간이 결정합니다.
2. 에이전트와의 협업 — 인간은 방향과 제약 조건을 제공하고, 에이전트는 방안과 초안을 제안하며, 인간은 이를 수정, 반려 또는 승인합니다.
3. 최종 검토 및 책임 — 특히 되돌릴 수 없거나 브랜드 평판에 영향을 미치는 동작 (대외 메일 발송, 고객 기록 작성 등)에 대해서는 인간이 관문에서 최종 승인을 해야 합니다.

이는 AI를 불신하는 것이 아니라 책임의 본질에 관한 것입니다. 실행은 에이전트에게 위임할 수 있지만, 책임은 위임할 수 없습니다. 환각 내용이 담긴 메일을 대외적으로 발송하거나, 잘못된 데이터를 고객 CRM에 기록하는 결과는 에이전트가 아닌 회사와 개인에게 돌아갑니다. 따라서 실무적인 원칙은 다음과 같습니다. 검증 비용이 리스크에 비해 적절한 곳에서는 에이전트가 자동으로 실행되도록 맡기고, 리스크가 높고 되돌릴 수 없는 곳에서는 에이전트가 "초안" 단계에서 멈추게 하여 인간의 검토 후 발송되도록 하는 것입니다.

이 점은 또한 "왜 이 역할의 명칭이 **Engineer (엔지니어)**인가"에 대한 답이 되기도 합니다. 이 역할이 실제로 책임지는 것은 이 시스템이 실제 운영될 때의 행동, 오류 패턴, 그리고 데이터 품질이기 때문입니다. 즉, 잘못된 영업 담당자에게 할당하거나, 메일 발송 도메인의 평판을 손상시키거나, 가짜 데이터를 공용 CRM에 섞어버리는 문제들입니다. 이는 단순히 "도구를 사용할 줄 아는 것"을 넘어선 엔지니어링적 책임입니다.

6. 그래서, GTM Engineer는 누구인가

앞서 언급한 계층들을 종합하면 이 역할이 명확해집니다:

GTM Engineer는 GTM을 이해하고, Sales Pipeline과 CRM을 이해하며, 에이전트 워크플로우를 사용하여 AI를 "신뢰할 수 있는 가치 창출 도구"로 프레임화할 줄 아는 사람입니다. 이들이 하는 일은 다음과 같습니다: 에이전트가 깔끔하게 세일즈 파이프라인을 채우고 추진할 수 있도록 프로세스를 설계하고, 데이터 품질을 수호하며, 인간이 마땅히 책임져야 할 위치에 머물 수 있도록 만드는 것입니다.

다양한 분들에게 드리는 몇 가지 핵심 요약입니다:

• 입문하려는 사람: 단순히 "특정 outreach 도구를 사용할 줄 안다"는 것을 실력으로 착각하지 마세요. 지속 가능한 가치는 전체 파이프라인 (pipeline)의 운영과 데이터 품질에 책임을 질 수 있는 능력에서 나옵니다. 도구는 바뀌어도, 이 책임은 바뀌지 않습니다.
• Revenue leader (수익 리더): 자동화를 논하기 전에 프로세스와 데이터 규칙을 먼저 구축하세요. 외부 활동은 기본적으로 사람의 검토(human review)를 거친다고 가정해야 합니다. "플랫폼을 하나 구매했다"는 것이 곧 "깨끗한 파이프라인을 가졌다"는 것과 동일하지 않음을 명심하세요. 에이전트 (agent)가 실제로 인력을 절감하고 비용을 낮출 수 있는지 여부는 비전(vision)을 듣는 것이 아니라, 당신만의 숫자로 검증해야 합니다.
• B2B SaaS: 미국식의 아웃바운드 (outbound) 중심 전략이 관계 중심 영업, 채널, 또는 규모가 작은 시장에 반드시 그대로 적용되는 것은 아닙니다. 하지만 "계층화 + 생성된 콘텐츠가 사실을 사칭하지 않도록 하는 것"이라는 데이터 규율은 시장의 규모와 상관없이 당신의 CRM에서도 동일하게 적용됩니다.

AI는 GTM을 "사람이 데이터를 보고 판단하는 단계"에서 "에이전트가 통제된 워크플로 (workflow) 상에서 실행하는 단계"로 이끌고 있습니다. 이 변화는 실재하며, 현재 일어나고 있습니다. 하지만 이것이 "인간을 완전히 자동화로 대체하는" 종착지는 아닙니다. 진정한 모습은 에이전트가 유연하면서도 통제 가능하게 작동하는 워크플로와, 목표·품질·책임을 수호하는 사람이 결합된 형태입니다. GTM Engineer는 바로 이 두 가지를 연결하는 사람입니다.

본문은 Apollo.io의 GTM Engineer 소개를 인용하였습니다 (해당 글은 "에이전트가 자동으로 실행하고 사람은 우선순위가 높은 계정만 검토한다"는 플랫폼 비전을 홍보하고 있습니다). 본문 내 Sales Pipeline / CRM은 B2B 공통 개념이며, 4단계 출처 신뢰도 (provenance) 및 "생성 콘텐츠의 사실 사칭 방지" 업그레이드 (promotion) 규칙은 본문에서 제안하는 v0.1 실무 프레임워크이며, 공식 표준이 아닙니다.