The Rise of DeployCos: 엔지니어를 고객사에 심어 AI를 실제 업무로 옮기는 회사들

AI 랩과 하이퍼스케일러가 2026년 들어 엔지니어를 고객사에 상주시키는 별도 회사, DeployCo를 잇달아 세우고 있습니다. 모델 성능보다 기업이 그 성능을 업무에 넣는 속도가 병목이라는 판단입니다. 우리 쪽에서 이 흐름을 쓰려면 어떤 유형의 DeployCo에 무엇을 먼저 맡길지, 그리고 배포 중에 쌓이는 업무 기록과 성과 기준을 누가 갖는지부터 정해야 합니다.

요약

Wing 파트너 Tanay Jaipuria는 2026년 10월 13일 뉴스레터에서 DeployCo라는 회사 형태를 정리했습니다. DeployCo는 기업 안에 엔지니어를 들여보내 AI 에이전트를 실제 워크플로에 넣고 운영하도록 돕는 조직입니다. 올해 Anthropic과 OpenAI가 각각 이런 회사를 만들었습니다. AWS도 forward-deployed engineering(고객 현장에 엔지니어를 보내 직접 구축하는 방식, 이하 FDE) 조직에 10억 달러를 약속했습니다. Palantir와 Accenture처럼 오래 이 일을 해 온 회사도 계속 커지고 있습니다. 저자는 두 랩이 만든 회사의 구조를 비교한 뒤, 이런 회사가 왜 지금 늘어나는지, 어떤 유형이 있고 안에서 어떻게 일하는지를 짚습니다.

2026년에는 랩, 하이퍼스케일러, 기존 서비스 강자가 모두 고객사 상주 배포에 돈과 사람을 넣고 있습니다.

저자가 꼽는 이유는 두 가지입니다. 모델이 할 수 있는 일과 기업이 실제로 쓰는 일 사이의 거리(diffusion gap)가 큽니다. 그 거리를 좁히려면 시스템 접근권, 워크플로 재설계, 부서 간 합의가 필요한데 모두 조직이 풀 문제라 AI가 혼자 해결하지 못합니다. 랩에게는 덤도 있습니다. 배포 현장에서 실제 업무 기록이 쌓이고 경쟁 모델로 갈아타기 어려워지며 토큰이 아니라 성과로 값을 매길 수 있습니다. 새 DeployCo는 horizontal, function-specific, vertical-specific의 세 유형으로 나뉩니다. 어느 유형이든 공통 시스템을 만드는 builder와 고객사에서 마무리하는 deployer로 팀을 나눕니다. 아래에서는 이 구조와 동기를 풀고 우리 조직이 DeployCo와 계약하거나 내부에 같은 기능을 세울 때 정할 것을 덧붙였습니다. FDE 팀이 현장에서 일하는 방식은 OpenAI FDE 노트에 따로 정리했습니다.

저자가 보는 주된 이유는 두 가지이고, 랩에게는 세 가지 덤이 따라옵니다.

핵심 메커니즘

DeployCo: 별도 자본으로 세운 배포 전담 회사

DeployCo는 모델을 만드는 본체와 떨어진 법인이 고객사 배포를 전담하는 구조입니다. 저자는 두 랩의 회사에서 같은 뼈대 네 가지를 찾습니다. 따로 자본을 모은 법인, 핵심 팀이 되는 인수한 applied-AI(모델을 실제 업무에 붙이는 일을 하는) 서비스 회사, 합류한 랩 엔지니어 일부, 첫 고객인 PE 운용사의 포트폴리오 회사입니다. 인수한 팀 덕분에 현장 인력은 첫날부터 갖춰지고 고객은 PE 스폰서가 한꺼번에 묶어 줍니다. Anthropic의 회사가 중견기업, 그중에서도 스폰서의 포트폴리오 회사부터 시작하는 것도 이 구조와 맞물립니다.

이 구조는 자체 AI 팀이 얇고 같은 주인 아래 비슷한 회사가 여럿 있을 때 힘을 냅니다. 가상 예시로, PE 운용사가 보유한 중견 제조사 다섯 곳에 같은 DeployCo가 들어가면 첫 회사에서 만든 구매 발주 에이전트를 나머지 네 곳에 맞춰 옮길 수 있습니다.

두 랩의 DeployCo는 자본, 인수 팀, 랩 엔지니어, PE 포트폴리오 고객이라는 같은 뼈대를 씁니다.

Diffusion Gap: 모델이 할 수 있는 일과 실제로 쓰는 일의 거리

diffusion gap은 모델이 해낼 수 있는 가치 있는 일에 비해 실제 활용이 훨씬 적은 상태를 가리킵니다. 저자는 Pat Grady의 설명을 빌려 이 말을 소개하고 같은 현상을 capability overhang(쓰이지 않고 남아 있는 능력)이라고도 부른다고 덧붙입니다. OpenAI의 Capability Overhang 보고서는 이를 사용자 수준에서 숫자로 보여 줍니다. 근거로 드는 것은 OpenAI의 GDPval입니다. 지식노동 직군의 실제 업무 산출물을 전문가가 채점하는 평가인데, 모델이 절반이 넘는 과제에서 전문가를 앞섰습니다. 그런데도 대부분의 조직은 모델을 그 수준으로 쓰지 못합니다.

저자는 이 거리를 좁히는 주된 수단으로 다음 모델이 아니라 배포를 꼽습니다. 가상 예시로, 영업팀이 제안서 초안에 모델을 쓰지만 CRM과 가격표에 연결되지 않아 사람이 숫자를 옮겨 붙이고 있다면 모델이 더 좋아져도 그 팀의 생산성은 거의 그대로입니다.

둘 사이의 거리가 diffusion gap입니다. 저자는 이 거리를 좁히는 주된 수단을 배포로 봅니다.

Organizational Alignment: 배포의 병목은 기술보다 조직

에이전트를 실제 업무에 넣으려면 올바른 시스템 접근권, 워크플로 재설계, 전사 차원의 동의, 일하는 방식의 변화가 함께 필요합니다. 이 일들은 여러 팀에 걸쳐 있고 한 사람이 책임지지 않습니다. 저자는 AI가 조직 정렬, 인센티브, 신뢰를 스스로 만들어 내지 못하므로 이 자리를 외부 인력이 채운다고 봅니다. Accenture가 3년 동안 생성형 AI 일감 약 115억 달러를 수주했습니다. 10여 년 전 FDE 역할을 처음 만든 Palantir는 12분기 연속으로 매출 성장이 빨라졌습니다. Palantir CTO Shyam Sankar는 실적 발표에서 다른 회사에는 “sparkling sales engineers”가 있을 뿐이라고 말했습니다.

가상 예시로, 구매 에이전트가 ERP에 발주를 쓰려면 IT 보안, 구매, 재무 세 팀의 결재가 필요합니다. 어느 팀도 이 결재를 자기 일로 여기지 않으면 시범은 읽기 전용에서 멈춥니다. deployer는 일의 상당 부분을 이런 결재를 끝까지 끌고 가는 데 씁니다.

필요한 일이 여러 팀에 흩어져 있어 책임자가 없고, 그 빈자리를 외부 인력이 채웁니다.

Lab Incentives: 랩이 직접 배포에 나서는 세 가지 덤

저자는 랩이 배포 회사를 만드는 부차적인 이유를 셋으로 봅니다. 첫째, 배포 작업은 산업별 실제 업무를 여러 단계에 걸쳐 수행한 long-horizon trace(긴 작업의 단계별 기록)를 남깁니다. 랩은 이 기록을 학습 데이터로 쓰거나 모델을 어디서 개선할지 정하는 데 씁니다. 둘째, 대부분의 기업 워크플로에서 랩 간 모델 성능은 비슷하므로, 고객사 에이전트를 직접 심어 두면 경쟁 모델로 넘어가기 어려워집니다(lock-in). 셋째, 에이전트를 만들고 배포하면 토큰이 아니라 실제 성과에 값을 매길 수 있어 시장 규모(TAM)가 커집니다.

고객 쪽에서 보면 세 가지 덤이 그대로 계약 조항이 됩니다. trace를 어디에 두고 학습에 써도 되는지, 모델을 바꿀 수 있는 구조인지, 성과를 무엇으로 재는지를 계약 전에 정해야 합니다.

왼쪽 두 칸은 저자의 해석이고, 오른쪽 칸은 고객이 계약 전에 정할 항목으로 AX Review가 덧붙였습니다.

Standard Playbook: 좁은 워크플로에서 learning loop까지

저자가 정리한 표준 플레이북은 여섯 단계입니다. FDE가 고객사에 상주하며 가치가 큰 워크플로 몇 개로 시작합니다. 가능하면 범위가 좁고 결과를 검증할 수 있는 일을 고릅니다. 그 워크플로를 따라가며 이해한 다음 모델을 회사 데이터와 시스템에 연결하는 agent harness(모델을 감싸 도구·데이터·권한을 붙이는 실행 틀)를 만듭니다. 필요한 evals(평가 세트)를 만들어 품질이 기준을 넘으면 반복해서 배포합니다. 가능하면 운영 중에 에이전트가 나아지는 learning loop까지 붙입니다.

순서의 요점은 평가가 배포보다 앞선다는 데 있습니다. 결과를 검증할 수 없는 일로 시작하면 4단계에서 기준을 세울 수 없습니다. 그러면 5단계의 배포 결정도 감에 기댑니다.

저자가 정리한 표준 플레이북. 좁고 검증 가능한 일과 learning loop는 저자도 '가능하면'이라는 조건을 붙입니다.

Three Types와 Builder·Deployer: 무엇을 팔고 누가 마무리하나

대기업에는 Palantir, Accenture, 그 밖의 컨설팅·SI처럼 수년간 이 일을 해 온 기존 강자가 있습니다. 저자는 새 AI DeployCo를 세 유형으로 나눕니다. horizontal은 여러 기능과 산업에 걸쳐 일하며 공용 플랫폼과 모듈을 먼저 만듭니다. 랩의 벤처, Distyl, BrainCo가 여기에 듭니다. function-specific은 한 기능에서 산업을 가리지 않고 믿을 만한 벤더가 되려 합니다. 고객지원의 Sierra와 Decagon(둘 다 다른 기능으로 넓히는 중), 구매의 Lio가 예입니다. vertical-specific은 한 산업 안의 기업에 에이전트를 넣습니다. 헬스케어의 Tennr, 물류의 Happyrobot이 예입니다.

새 AI DeployCo는 다루는 범위로 나뉩니다. 대기업에는 Palantir, Accenture 같은 기존 강자가 있습니다.

기능형과 버티컬형은 속 구조가 비슷합니다. 그 기능이나 산업에 공통인 워크플로를 위한 core system을 만든 뒤 고객마다 상당한 last-mile(현장에서 실제로 돌게 만드는 마지막 맞춤) 작업을 합니다. 그래서 팀이 core system을 만드는 builder와 고객사에서 일하는 deployer로 나뉩니다. deployer의 직함은 agent deployment, FDE, deployment strategist 등으로 회사마다 다릅니다. 저자는 대기업에 파는 버티컬 AI 앱 회사 상당수도 사실상 DeployCo라고 봅니다. 워크플로가 고객마다 크게 달라 맞춤 통합, 맞춤 evals, 큰 변화관리가 붙기 때문입니다.

기능형과 버티컬형 DeployCo는 속 구조가 비슷합니다. 공통 시스템을 만드는 팀과 고객마다 마무리하는 팀이 나뉩니다.

통념과 다른 주장

흔히 이렇게 봅니다모델이 더 좋아지면 기업 도입은 자연히 따라온다. 벤더는 모델과 소프트웨어를 팔고 구축은 고객이 맡는다.

저자는 이렇게 봅니다모델은 이미 충분히 좋습니다. 병목은 배포와 조직 정렬입니다. 그래서 모델 회사가 직접 사람을 고객 현장에 넣는 회사를 세웁니다.

근거GDPval에서 모델이 절반 넘는 과제에서 전문가를 앞섰지만 조직의 활용은 그에 못 미칩니다. 같은 시기에 Accenture의 생성형 AI 수주와 Palantir의 성장은 커지고 있습니다.

GDPval 결과와 Accenture · Palantir의 성장이 저자의 근거입니다.

흔히 이렇게 봅니다버티컬 AI 앱 회사는 소프트웨어 회사라서 제품을 팔면 일이 끝난다.

저자는 이렇게 봅니다대기업에 파는 버티컬 AI 앱 회사 상당수는 사실상 DeployCo입니다.

근거대기업의 워크플로는 고객마다 크게 달라, 계약마다 맞춤 통합과 맞춤 evals, 큰 변화관리가 함께 들어갑니다.

저자는 이를 업계의 'dirty secret'이라고 부릅니다.

저자가 든 사례

Anthropic과 PE의 AI 서비스 회사 Ode

상황: 중견기업, 그중에서도 PE 스폰서가 보유한 포트폴리오 회사를 첫 시장으로 겨냥했습니다.
한 일: 5월에 Blackstone, Hellman & Friedman, Goldman Sachs 등 PE와 함께 15억 달러 규모의 AI 서비스 회사를 발표했습니다. 7월에는 Fractional AI 인수를 기반으로 Ode라는 이름으로 출범했습니다.
결과: 배포 성과 수치는 원문에서 밝히지 않았습니다.
연결: DeployCo 구조의 사례입니다. 자본과 첫 고객을 PE가 함께 댑니다.

PE가 자본과 첫 고객을 함께 대는 구조입니다.

OpenAI deployment company

상황: 고객사 배포를 맡을 현장 인력을 처음부터 갖춰야 했습니다. 출범 배경은 원문에서 따로 설명하지 않았습니다.
한 일: TPG 주도로 40억 달러 넘게 조달했고 OpenAI가 과반 지분을 갖습니다. 출발점으로 Tomoro를 인수했습니다.
결과: 출범 첫날부터 FDE 100명 이상을 갖췄습니다.
연결: DeployCo 구조에서 인수 팀이 핵심이 되는 사례입니다.

인수로 현장 인력을 한꺼번에 확보한 사례입니다.

하이퍼스케일러와 기존 강자: AWS, Accenture, Palantir

상황: 랩 밖에서도 고객 현장 배포 수요가 커지고 있습니다.
한 일: AWS는 6월 말 forward-deployed engineering 조직에 10억 달러를 약속했습니다. Accenture와 Palantir는 오래 해 온 현장 배포를 계속 키우고 있습니다.
결과: Accenture는 3년간 생성형 AI 일감 약 115억 달러를 수주했고(매출이 아닌 수주 기준), Palantir는 12분기 연속으로 매출 성장이 빨라졌습니다.
연결: Organizational Alignment의 근거입니다. 조직 문제를 풀어 줄 사람에 대한 수요가 숫자로 드러납니다.

클라우드 회사와 기존 서비스 회사의 숫자도 배포 수요가 크다는 쪽을 가리킵니다.

AI-native rollup: 회사를 사서 안에서 바꾸기

상황: DeployCo는 남의 회사를 돕는 방식이라 바꾼 결과의 이익 대부분이 고객에게 갑니다.
한 일: 회사를 사들여 안에서 AI를 심는 AI-native rollup이 함께 나타났습니다. Long Lake는 Amex GBT를 63억 달러에 비공개화했습니다. Sequence는 보험중개사 Baldwin을 77억 달러에 비공개화했습니다.
결과: 자산을 소유하면 프로세스 재설계와 AI 이익을 직접 가져갑니다. 대신 자본이 많이 들고 확장이 어렵다고 저자는 봅니다.
연결: DeployCo와 같은 문제(diffusion gap)를 소유로 푸는 다른 길입니다.

DeployCo가 고객을 돕는다면, rollup은 회사를 직접 소유해 바꿉니다.

기술 디테일: DeployCo와 첫 워크플로를 돌릴 때 필요한 것

아래는 저자의 플레이북과 랩의 동기를 우리 조직에 대입할 때 필요한 설계로, AX Review가 새로 작성했습니다. 숫자는 가상 예시입니다.

좁고 검증 가능한 첫 워크플로를 고르려면(Standard Playbook 1단계) 후보마다 다섯 항목을 0~3점으로 채점합니다. 결과를 정답과 비교할 수 있는지(검증 가능성), 월 건수, 건당 처리 시간, 연결해야 할 시스템 수(적을수록 높은 점수), 틀렸을 때 피해(작을수록 높은 점수)입니다. 검증 가능성이 3점이고 합계가 15점 중 11점 이상인 후보만 첫 워크플로로 올립니다. 연결 시스템 수를 넣는 이유는 last-mile 작업량이 대개 여기서 갈리기 때문입니다. 아래 표는 피해 항목을 빼고 네 항목만 보인 예입니다.

가상 예시. 검증 가능성 3점에 합계 11점 이상인 후보만 첫 워크플로로 올립니다.

agent harness를 설계하려면(3단계, Lab Incentives의 lock-in) 네 부품으로 나눠 요구합니다. 커넥터는 읽기 전용부터 열고 시스템마다 서비스 계정을 따로 둡니다. 도구 정의에는 입력·출력 스키마를 붙이고 쓰기 작업에는 사람 승인 단계를 둡니다. 모델 호출은 한 계층에 모아 다른 랩 모델로 바꿀 수 있게 둡니다. 분기마다 같은 eval을 다른 모델로 돌려 점수 차를 기록합니다. 차이가 3%p 안이면 교체할 수 있는 상태로 보고 그보다 크면 어느 문항에서 갈리는지 따로 봅니다. 저자 말대로 기업 워크플로에서 랩 간 성능이 비슷하다면 이 교체 시험이 lock-in을 막는 가장 싼 방법입니다. 로그는 건마다 trace로 남기고 고객 테넌트에 보관합니다.

가상 설계. 모델 호출을 한 계층에 모아 두면 lock-in을 줄이고 다른 랩 모델과 비교할 수 있습니다.

evals와 quality bar를 정하려면(4~5단계) 현업 담당자가 정답을 단 골든셋 200건을 먼저 만듭니다. 결정이 있는 업무는 결정 일치율을, 값을 뽑는 업무는 필드 정확도를 잽니다. 같은 입력을 3회 돌려 결과가 갈리는 비율도 봅니다. 결정 단계의 temperature는 0~0.2로 낮춥니다. 통과 기준은 결정 일치율 95% 이상, 3회 반복 불일치 2% 이하, 금액·권한 관련 치명 오류 0건으로 둡니다. 세 기준을 넘으면 2주 그림자 운영(사람과 에이전트가 같은 건을 처리해 비교)을 거쳐 부분 자동화로 넘어갑니다. 골든셋은 분기마다 최근 처리 건 50건을 새로 넣어 업무 변화에 맞춥니다.

가상 예시. 네 줄을 모두 넘어야 부분 자동화로 넘어갑니다.

learning loop를 실제로 돌리려면(6단계, Lab Incentives의 trace) 운영 중 건마다 아래 trace를 남기고 사람이 수정하거나 반려한 건을 매주 골라 eval 문항으로 넣습니다. 이 기록은 랩이 원하는 long-horizon trace와 같은 종류이므로, 저장 위치와 학습 사용 여부는 계약서에 따로 적습니다. 기본값은 고객 테넌트 보관, 학습 사용은 별도 서면 동의입니다.

{
  "run_id": "po-2026-11-0412",
  "workflow": "invoice_po_match",
  "model": "<공급사 모델명>",
  "model_version": "<배포 시점 버전>",
  "input_ref": "s3://tenant-bucket/invoices/0412.pdf",
  "tool_calls": [{"tool": "erp.get_po", "args": {"po_no": "PO-88213"}, "ok": true}],
  "output": {"decision": "match", "mismatch_lines": []},
  "human_action": "edit",
  "edit_note": "단가 단위 오류 수정",
  "outcome_unit": false,
  "latency_ms": 8400,
  "cost_krw": 31,
  "training_use_consent": false
}

가상 설계. 운영 중 사람이 고친 건을 매주 eval에 넣어야 loop가 실제로 돕니다.

성과 기준 가격을 받아들이려면(Lab Incentives의 TAM) 성과 단위를 먼저 정의합니다. 예를 들어 사람 수정 없이 끝난 건(outcome_unit: true)을 한 단위로 봅니다. 도입 전 3개월의 건당 처리 시간과 비용을 기준선으로 남기고 측정 소스는 위 trace로 고정합니다. 쉬운 건만 자동 처리해 성과를 청구하는 일을 막으려면 난이도 구간을 나눠 구간별 단가를 둡니다. 월 청구액에는 상한을 둡니다.

가상 설계. 성과 단위가 느슨하면 쉬운 건만 자동 처리하고 성과를 청구하는 일이 생깁니다.

실패하는 경우와 대응. 배포가 멈추는 자리는 대개 모델 밖에 있습니다. 맞춤 통합이 일정을 잡아먹는 경우는 후보 채점 단계에서 연결 시스템 수로 미리 걸러 냅니다. 쓰기 권한 결재가 몇 주씩 걸리는 경우는 0주차에 필요한 권한 목록을 만들어 스폰서 결재를 받아 둡니다. deployer가 떠난 뒤 에이전트가 멈추는 경우는 처음부터 내부 엔지니어를 짝으로 붙이고 인수 기준(내부 인원이 eval을 혼자 돌리고 프롬프트를 고칠 수 있음)을 계약에 넣습니다.

가상 예시. 배포가 멈추는 자리는 대개 모델 밖에 있습니다.

현업 실행 디테일: 누가, 언제, 무엇을

역할	담당	12주 동안 하는 일
스폰서	대상 업무를 맡은 임원 1명	범위와 권한 결재, 6주·12주 판정
업무 오너	현업 팀장 1명, 담당자 2명	워크플로 설명, 골든셋 200건 정답
deployer	DeployCo 엔지니어 1~2명	상주, harness·evals 구축, 배포
내부 짝 엔지니어	IT 또는 AX 조직 1명	deployer와 함께 구축, 12주차 운영 인수
IT·보안	담당 1명	서비스 계정, 쓰기 권한, 로그 보관
구매·법무	담당 1명	trace 소유와 학습 사용, 성과 단위, 해지·인수 조항
재무	담당 1명	기준선 측정, 성과 과금 검증

시작 전 준비물: 후보 워크플로 3~5개와 각각의 월 건수·건당 시간, 연결할 시스템 목록과 담당자, 최근 3개월 처리 기록 표본, 쓰기 권한이 필요한 작업 목록, 현재 외부 SI·컨설팅 계약 현황.

기간	할 일	산출물
0~2주	후보 채점, 첫 워크플로 1개 선정, 권한·계약 결재	채점표, 권한 목록, 계약서
3~6주	워크플로 따라가기, harness 구축, 골든셋 작성	harness 1차, 골든셋 200건
7~10주	eval 통과, 2주 그림자 운영, 부분 자동화	eval 결과표, 그림자 운영 비교표
11~12주	learning loop 가동, 내부 인수, 판정 회의	인수 확인서, 판정 보고서

가상 예시. 외부 deployer 옆에 처음부터 내부 짝을 붙여 12주차에 운영을 넘겨받습니다.

DeployCo에 물을 질문: 우리와 같은 기능이나 산업에서 core system이 이미 있습니까, 아니면 처음부터 만듭니까? 투입되는 deployer는 몇 명이며 builder 팀과는 어떻게 이어집니까? 배포 중 생긴 trace는 어디에 저장되고 모델 학습에 쓰입니까? 모델을 다른 랩 것으로 바꾸려면 무엇을 고쳐야 합니까? 철수한 뒤 우리 인원이 eval을 돌리고 프롬프트를 고칠 수 있게 무엇을 넘겨줍니까?

진행 판정 기준(예시): 6주차에 골든셋 결정 일치율이 90% 미만이면 워크플로 범위를 줄이거나 후보를 바꿉니다. 12주차에 그림자 운영에서 사람 수정 없이 끝난 건이 60% 이상이고 내부 짝 엔지니어가 eval을 혼자 돌릴 수 있으면 다음 워크플로로 넓힙니다. 둘 중 하나라도 못 넘으면 계약을 연장하지 않고 원인을 정리합니다.

적용 제언. 유형은 우리 문제가 한 기능에 있는지, 한 산업의 특수성에 있는지, 전사 공통인지로 고릅니다.

AX 적용 제언. DeployCo를 고르는 기준은 회사 규모보다 문제의 모양입니다. 고객지원이나 구매처럼 한 기능에 문제가 몰려 있으면 그 기능의 core system을 가진 function-specific 회사가, 헬스케어·물류처럼 규제와 데이터가 특수하면 vertical-specific 회사가 빠릅니다. 여러 기능을 전사 공용 플랫폼 위에 올리려면 horizontal 회사나 랩의 DeployCo가 맞습니다. 이미 큰 SI 계약이 있는 대기업은 기존 강자와 새 DeployCo를 같은 첫 워크플로로 비교해 볼 만합니다. PE 포트폴리오 회사라면 스폰서가 묶어 오는 랩 DeployCo를 먼저 검토합니다. 어느 쪽이든 계약 전에 trace 소유, 모델 교체 가능성, 성과 단위 세 가지를 정해 두면 랩이 얻는 덤과 우리 몫이 섞이지 않습니다. 외부 deployer에게 모두 맡기지 않고 처음부터 내부 짝을 붙여 두면 12주 뒤에도 에이전트가 계속 돕니다.

원문 사례

항목	내용
저자·발표처	Tanay Jaipuria(Wing 파트너), Tanay’s Newsletter, 2026.10.13
정의	DeployCo: 기업 안에 엔지니어를 상주시켜 AI 에이전트를 실제 워크플로에 도입·운영하게 돕는 조직
Anthropic	5월 발표, Blackstone · Hellman & Friedman · Goldman Sachs 등 PE와 15억 달러 규모 AI 서비스 회사. 7월 Ode로 출범, Fractional AI 인수 기반. 중견기업, PE 포트폴리오 회사부터
OpenAI	deployment company, TPG 주도 40억 달러 이상 조달, OpenAI 과반 지분. Tomoro 인수, 첫날 FDE 100명 이상
공통 구조	별도 자본 법인 · 인수한 applied-AI 서비스 팀 · 랩 엔지니어 일부 · PE 포트폴리오 회사가 첫 고객
AWS	6월 말 forward-deployed engineering 조직에 10억 달러 약속
생기는 이유	diffusion gap(capability overhang), 조직 정렬
근거 수치	GDPval에서 모델이 절반 넘는 과제에서 전문가 앞섬. Accenture 3년간 생성형 AI 수주 약 115억 달러. Palantir 12분기 연속 매출 성장 가속
랩의 부차적 이유	long-horizon trace, 경쟁 모델 대비 lock-in, 성과 기반 가격으로 커지는 TAM
표준 플레이북	상주와 좁은 워크플로 선택 → 워크플로 이해 → agent harness → evals → 기준 통과 뒤 배포 → learning loop
세 유형	Horizontal(랩 벤처, Distyl, BrainCo) · Function-specific(Sierra, Decagon, Lio) · Vertical-specific(Tennr, Happyrobot)
팀 구조	core system을 만드는 builder와 last-mile을 맡는 deployer
AI-native rollup	Long Lake의 Amex GBT 비공개화 63억 달러, Sequence의 Baldwin 비공개화 77억 달러. 자본이 많이 들고 확장이 어려움

핵심 개념

FDE (forward-deployed engineer): 고객사에 들어가 현장에서 직접 에이전트를 구축하고 배포하는 엔지니어. Palantir가 10여 년 전 처음 만든 역할.
GDPval: OpenAI의 평가. 여러 지식노동 직군의 실제 업무 산출물을 모델이 만들고 전문가가 채점한다.
Capability Overhang 보고서: 쓰이지 않고 남아 있는 모델 능력을 사용자 수준에서 숫자로 보여 준 OpenAI 보고서.
agent harness: 모델을 회사의 데이터·시스템·권한에 연결해 에이전트로 돌게 하는 실행 틀.
last-mile: 공통 시스템을 특정 고객사에서 실제로 돌게 만드는 마지막 맞춤 작업.
deployment strategist: deployer 역할의 다른 직함. 고객사에서 배포 범위와 변화관리를 이끈다.
TAM: Total Addressable Market. 이론상 닿을 수 있는 전체 시장 규모.
take-private(비공개화): 상장사를 사들여 상장을 폐지하는 거래. AI-native rollup의 사례가 이 방식을 썼다.

내 메모

TODO: 내 생각 추가

원문: Tanay Jaipuria, “The Rise of DeployCos”(Tanay’s Newsletter, 2026.10.13). 요약·메커니즘·통념과 다른 주장·사례·원문 사례 표는 저자가 언급한 내용을 AX Review가 다시 정리했습니다. 원문의 차트는 옮기지 않았습니다. 기술·현업 디테일, JSON 예시, 채점표, quality bar, 12주 일정, 판정 기준, 유형 선택 제언, 인포그래픽은 새로 작성했으며 숫자는 가상 예시입니다. FDE의 현장 운영 방식은 같은 사이트의 OpenAI FDE 노트를 참고하세요. 원문 전체는 Tanay’s Newsletter에서 볼 수 있습니다.