Anthropic IPO Filing: 기업 고객이 API에서 Claude Code·Cowork로 넓혀 쓰는 구조와 AI 지출 관리
TechCrunch가 읽은 Anthropic S-1에 따르면 연 10만 달러 이상 쓰는 고객은 1만 1,900곳을 넘고 그중 절반 넘게 API와 Claude Code·Cowork를 함께 씁니다(2025년 말 약 30%). 같은 구매자 안에서 층을 넓히는 구조와, 구매하는 쪽이 토큰 지출을 한 장부로 관리하는 방법을 정리했습니다.
Anthropic의 상장 신고서를 보면 기업 고객은 API로 시작해 엔지니어용 Claude Code, 전 직원용 Cowork로 쓰임새를 넓힙니다. 연 10만 달러 이상 쓰는 고객 가운데 절반 넘게 이미 두 층 이상을 함께 씁니다. 사는 쪽은 제품별 계약을 따로 보지 말고 한 벤더에 쌓이는 토큰 지출 전체를 한 장부로 봐야 합니다.
요약
TechCrunch의 Rebecca Bellan 기자는 2026년 10월 26일 Anthropic이 미국 SEC에 낸 S-1(상장 신고서)을 읽고 이 회사가 기업 고객을 어떻게 붙잡는지 정리했습니다. 신고서는 Claude를 세 층으로 나눕니다. 모델, 개발자용 Claude Platform, 최종 사용자용 앱(Claude Code, Cowork)입니다. 한 층이 좋아지면 다른 층도 이득을 보는 구조이고 신고서는 이를 “integrated approach”라고 부릅니다. 기사가 짚은 전형적 경로는 이렇습니다. 기업은 API로 시작하고 이어 엔지니어에게 Claude Code를 주며 그다음 더 넓은 직원에게 Cowork를 엽니다. 기자는 승차 공유에서 음식 배달·화물로 넓힌 Uber, AWS 컴퓨팅에서 스토리지·데이터베이스로 넓힌 Amazon에 이 경로를 견줍니다. 핵심은 제품을 하나 더할 때마다 새 구매자를 찾을 필요가 없다는 점입니다.
숫자는 이 경로가 실제로 돌고 있음을 보여 줍니다. 2026년 9월 30일 기준 최근 12개월(TTM) 동안 10만 달러 이상을 쓴 고객은 1만 1,900곳이 넘습니다. 100만 달러 이상은 1,900곳 이상, 1,000만 달러 이상은 약 250곳입니다. 10만 달러 이상 고객 가운데 Claude Platform과 Claude Code·Cowork 같은 앱을 함께 쓰는 비율은 2025년 말 약 30%였고 지금은 절반을 넘었습니다. 순매출 유지율(NRR)은 약 900%입니다. 신고서는 성장 이유를 고객이 조직 곳곳에 Claude를 배치하면서 사용량이 크게 늘어난 데서 찾습니다. 요금이 토큰 사용량으로 매겨지므로 쓰는 범위가 넓어지면 지출도 함께 커집니다. 아래에서는 이 구조를 네 가지 메커니즘으로 풀고 사는 쪽에서 지출을 어떻게 관리할지 덧붙입니다.
핵심 메커니즘
Integrated Approach: 모델·플랫폼·앱 세 층을 한 회사가 함께 파는 구조
Anthropic은 모델만 파는 회사가 아니라 세 층을 모두 직접 운영합니다. 모델 층은 토큰 단위로 과금되고 고른 모델에 따라 단가가 다릅니다. Claude Platform은 신고서가 agentic 개발 환경이라고 부르는 층으로, 고객이 자기 애플리케이션을 만들 때 쓰는 기본 구성 요소(primitives)를 줍니다. 앱 층에는 coding agent인 Claude Code와 knowledge work agent인 Claude Cowork가 있고 2026년 9월부터 Cowork와 Claude.ai를 합치고 있습니다. 모델이 좋아지면 플랫폼으로 만든 고객 앱과 Anthropic의 자체 앱이 함께 좋아집니다. 신고서는 Cowork의 초기 확산 속도가 같은 시점의 Claude Code보다 빨랐다고도 적었습니다. 고객사 안에 개발 조직과 일반 사무 조직이 모두 있을 때 이 구조의 힘이 커집니다. 작은 가상 예시로, 제조사 IT팀이 API로 주문 문서 분류 앱을 만든 뒤 같은 계약으로 개발자에게 Claude Code를 주고 영업지원팀에 Cowork를 여는 식입니다.
Expansion Path: 같은 구매자 안에서 API → Claude Code → Cowork로 넓히기
이 경로의 입력은 이미 API를 쓰는 고객입니다. 그 고객의 엔지니어가 Claude Code를 쓰기 시작하면 같은 조직의 다른 부서가 Cowork를 씁니다. 결과는 한 고객에게서 나오는 매출이 층마다 더해지는 구조입니다. 기사는 이 덕분에 Anthropic이 제품마다 새 구매자를 설득할 필요가 없다고 봅니다. 신고서도 고객이 Claude를 새 업무 흐름으로 넓혀 쓰는 일이 잦다고 적었습니다. 이 경로는 API 연동으로 신뢰가 쌓인 조직에서 잘 통합니다. 반대로 보안 검토를 앱마다 따로 받아야 하는 조직에서는 층을 하나 넓힐 때마다 시간이 걸립니다.
Pay-for-intelligence와 NRR: 사용량 과금이 지출을 키우는 방식
신고서는 주된 수익 모델을 pay-for-intelligence(consumption)라고 부릅니다. 고객은 토큰 단위로 계량된 사용량만큼 내고 단가는 고른 모델에 따라 다릅니다. Pro·Max 같은 개인 요금제는 정액 구독입니다. 매출 대부분은 사용량 기반이고 상당 부분은 장기 약정에 묶여 있지 않다고 위험 요인에 적혀 있습니다. 그래서 고객이 쓰는 범위를 넓히면 매출은 계약 갱신을 기다리지 않고 바로 커집니다. NRR(Net Revenue Retention, 순매출 유지율)은 이 효과를 재는 지표입니다. 신고서 정의로는 측정일까지 3개월 매출을 1년 전 같은 3개월 매출로 나누며 대상은 기준 기간에 1달러 이상 매출이 있던 고객(Qualified Customers, Pro·Max 구독자 제외)입니다. 약 900%라는 값은 1년 전 고객 묶음이 지금 그때의 약 9배를 쓴다는 뜻입니다. 신고서는 다단계 추론과 반복 도구 호출을 쓰는 agentic 작업이 단발 API 호출이나 채팅보다 상호작용당 컴퓨트를 훨씬 많이 쓴다고도 적었습니다. 에이전트 도입이 늘면 같은 인원이 쓰는 토큰도 늘어납니다.
Joint Go-to-market: 클라우드로 사도 계약은 Anthropic과 맺는 구조
Anthropic은 AWS, Google Cloud, Microsoft Azure로도 팝니다. 신고서가 joint go-to-market이라고 부르는 방식에서는 Anthropic이 고객과 직접 계약을 맺고 각 클라우드 회사에 수수료를 냅니다. 회사는 이렇게 하면 채널끼리 부딪히는 일을 피하고 가격을 스스로 정할 수 있다고 설명합니다. 판매 뒤 확산은 사람이 돕습니다. 사내 Applied AI 팀(forward-deployed engineer, FDE 포함)이 고객의 기존 시스템에 Claude를 맞춰 넣습니다. Blackstone 등 사모펀드와 함께 세운 Ode with Anthropic은 FDE를 기업에 보내 Claude로 맞춤 도구를 만듭니다. 신고서는 Accenture, Deloitte, KPMG, PwC 같은 SI(시스템 통합 업체)와 Salesforce, Snowflake 같은 데이터 플랫폼도 도입 경로로 듭니다. 기업은 이미 쓰는 클라우드 약정으로 사면서도 계약 조건은 Anthropic과 협상하게 됩니다.
Risk Factors: 사는 쪽이 함께 읽어야 할 조항
신고서의 위험 요인은 구매자에게도 점검 목록이 됩니다. 클라우드 회사들은 Anthropic을 점점 경쟁자로 보고 Amazon·Google·Microsoft가 자기 필요나 자기가 투자한 회사를 먼저 챙길 수 있습니다. 회사는 원하는 만큼의 컴퓨트를 받지 못할 수 있다고 적었습니다. 사용량 한도, rate limit(호출 속도 한도), 모델 기능을 바꿔 왔고 앞으로도 바꿀 수 있다고도 밝혔습니다. 예전 모델에 맞춰 연동한 고객이 새 버전으로 옮기기를 꺼릴 수 있다는 점도 위험으로 꼽았습니다. 큰 고객의 지출이 줄거나 이탈하면 사업에 타격이 된다는 고객 집중 위험도 있습니다. 사는 쪽에서 보면 처리량, 한도 변경, 모델 지원 종료가 계약서에서 확인할 항목입니다.
통념과 다른 주장
흔히 이렇게 봅니다기업용 AI 도구는 부서마다 따로 사고 제품이 바뀌면 구매 결정도 처음부터 다시 거친다.
저자는 이렇게 봅니다Anthropic은 같은 고객 안에서 API, Claude Code, Cowork로 층을 넓히므로 제품마다 새 구매자를 찾지 않는다.
근거연 10만 달러 이상 고객 중 Platform과 앱을 함께 쓰는 비율이 2025년 말 약 30%에서 절반 이상으로 올랐고 NRR은 약 900%다.
흔히 이렇게 봅니다클라우드 마켓플레이스에서 모델을 사면 고객 관계와 가격은 클라우드 회사가 쥔다.
신고서는 이렇게 설명합니다세 클라우드 어디서 사든 Anthropic이 고객과 직접 계약하고 클라우드 회사에는 수수료를 낸다.
근거회사는 이 방식으로 채널 충돌을 피하고 가격을 스스로 정한다고 밝혔다.
저자가 든 사례
복수 층 사용 고객: 약 30%에서 절반 초과로
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| 2025년 말, 연 10만 달러 이상 고객 중 Platform과 앱을 함께 쓰는 비율 약 30% | Claude Code와 Cowork를 기존 API 고객에게 넓혀 공급 | 신고서 시점 절반 초과 | Expansion Path |
Claude Code를 쓰는 상위 고객: 월 지출 약 20배
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| Claude Enterprise 고객 가운데 Claude Code 사용 여부로 지출이 갈림 | 3분기 월 지출을 비교 | Claude Code를 쓰는 상위 5%가 쓰지 않는 평균 사용자보다 월 약 20배 지출 | Pay-for-intelligence |
Ode with Anthropic: FDE를 기업에 보내 맞춤 도구 만들기
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| 기업이 Claude를 기존 시스템에 맞춰 넣기 어려움 | Blackstone 등 사모펀드와 새 회사를 세워 FDE를 기업에 배치 | 원문에서 밝히지 않음 | Joint Go-to-market |
기술 디테일: 세 층 지출을 한 장부로 관리하려면
Integrated Approach를 사는 쪽에서 감당하려면 청구 원천부터 한곳에 모읍니다. 같은 벤더라도 돈은 여러 길로 나갑니다. 직접 계약 청구서, AWS·Google Cloud·Azure 마켓플레이스 청구, 앱 구독료입니다. 매월 세 원천을 내려받아 같은 필드로 맞추는 작업을 먼저 만듭니다. 아래 필드명과 값은 가상 예시입니다.
{
"period": "2026-10",
"vendor": "anthropic",
"channel": "aws_marketplace",
"layer": "claude_code",
"model": "<모델 이름>",
"cost_center": "R&D-플랫폼개발",
"project": "order-classifier",
"input_tokens": 182000000,
"output_tokens": 21000000,
"cost_usd": 4380.0,
"active_users": 64,
"contract_ref": "MSA-2026-014"
}layer는 platform·claude_code·cowork 셋으로 고정하고 channel은 direct·aws·gcp·azure로 고정합니다. 신고서상 계약 상대는 어느 채널이든 Anthropic이므로 contract_ref로 한 계약 아래에 묶어야 할인과 약정 소진을 한눈에 봅니다. API 키와 워크스페이스는 프로젝트 단위로 나눠 발급해 project가 비지 않게 합니다.
20배 사례처럼 지출이 소수에 몰리는지 매달 봅니다. 사용자별 월 비용을 정렬해 상위 5% 사용자의 비용 비중과 중앙값 대비 배수를 계산합니다. 몰림 자체는 문제가 아닙니다. 상위 사용자의 산출물(병합된 코드, 처리한 문서 수)과 붙여 봐야 투자인지 낭비인지 갈립니다. 예시 기준으로, 상위 5%가 전체 비용의 40%를 넘는데 산출물 지표가 비어 있으면 해당 팀과 사용 방식을 점검합니다.
Pay-for-intelligence는 모델별 단가이므로 모델 선택을 규칙으로 둡니다. 작업 유형마다 기본 모델을 정하고 상위 모델은 예외 승인으로 씁니다. agentic 작업은 세션 하나가 토큰을 많이 쓰므로 세션당 토큰 상한과 도구 호출 횟수 상한을 둡니다. 상한에 걸린 세션은 로그를 남기고 사람에게 넘깁니다.
우리 쪽 NRR을 신고서 정의 그대로 계산합니다. 측정 분기 3개월 지출을 1년 전 같은 3개월 지출로 나눕니다. 벤더 쪽 900%는 고객 쪽에서 보면 같은 기간 예산이 그만큼 불었다는 뜻일 수 있습니다. 층별로 나눠 계산하면 어느 층이 증가를 이끄는지 보입니다.
Risk Factors에 대비해 모델 교체를 시험할 수 있게 둡니다. 쓰는 모델 버전 목록과 지원 종료 공지를 관리하고 업무별 평가 세트(예시: 업무당 50~100건)를 만들어 새 버전이 나오면 다시 돌립니다. 한도 변경에 대비해 피크 시간 처리량을 측정하고 결과가 기준에 못 미치면 다른 모델로 넘기는 경로를 하나 남겨 둡니다.
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 담당 | 하는 일 |
|---|---|---|
| 스폰서 | CFO 또는 CIO | AI 지출 한도와 층별 확산 승인 |
| 재무 | FP&A 1명 | 원가 배분 규칙, 월간 지출 보고 |
| 구매 | 구매 담당 1명 | 채널별 계약·약정·통지 조항 정리 |
| 플랫폼 | IT 플랫폼 엔지니어 1~2명 | 키·워크스페이스 분리, 청구 정규화, 모델 규칙 |
| 보안 | 보안 담당 1명 | 층별 데이터 범위와 권한 확인 |
| 현업 | 개발·사무 부서 리더 | 산출물 지표 정의, 확산 대상 추천 |
시작 전에 모을 것. 최근 12개월 AI 관련 청구서(직접·클라우드 마켓플레이스·구독), 계약서와 주문서, 발급된 API 키와 워크스페이스 목록, 앱 사용자 명단, 부서별 원가 코드입니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~2주 | 청구 원천과 계약 목록 정리, 키·워크스페이스 소유자 확인 | AI 지출 인벤토리 |
| 3~4주 | 정규화 장부 구축, 층·부서 태깅, 사용자별 분포 계산 | 월간 지출 장부, 분포표 |
| 5~6주 | 모델 규칙·세션 상한 설정, 판정 회의 | 지출 정책, 확산 판정서 |
확인할 질문.
- 지금 Claude 관련 비용이 몇 개의 청구 원천으로 나가고 하나의 계약 아래 묶여 있습니까?
- Claude Code와 Cowork 사용자는 누가 승인했고 사용자별 비용을 볼 수 있습니까?
- 지난 분기 지출을 1년 전 같은 분기와 비교하면 층별로 얼마나 늘었습니까?
- 한도나 모델 지원 종료가 바뀌면 며칠 전에 통지받는 조건입니까?
- 다른 모델로 넘길 업무와 그 평가 세트가 준비돼 있습니까?
진행 판정 기준(예시). 지출의 95% 이상이 layer·cost_center 태그를 갖고 상위 5% 사용자 비용에 산출물 지표가 붙어 있으며 주요 업무 하나 이상에서 대체 모델 평가를 한 번 돌렸으면 다음 층 확산을 승인합니다.
AX 적용 제언. 국내 기업 다수는 API 파일럿을 IT 예산으로, 코딩 도구를 개발 조직 예산으로, 사무용 AI를 부서 예산으로 따로 삽니다. 신고서가 보여 주는 확산 경로를 따르면 이 셋은 결국 한 벤더의 한 계약으로 모입니다. 그러니 AX 추진 조직은 도입 승인보다 먼저 공용 지출 장부와 층별 확산 승인 절차를 세우는 편이 낫습니다. 순서는 개발 조직의 Claude Code 사용 분포 파악, 산출물 지표 연결, 그다음 Cowork 같은 전사 확산입니다. 협상에서는 채널과 무관하게 계약 상대가 Anthropic이라는 점을 써서 클라우드 약정 소진과 사용량 할인을 한 계약에서 함께 다룹니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 원문 | TechCrunch, Rebecca Bellan, 2026.10.26 |
| 근거 문서 | Anthropic S-1 (2026.10.26 SEC 제출) |
| 핵심 주장 | 모델·플랫폼·앱 세 층을 묶어 같은 고객 안에서 넓혀 쓰게 하는 구조가 효과를 내고 있음 |
| 고객 수 (2026.9.30) | 연 10만 달러 이상 1만 1,900곳 초과, 100만 달러 이상 1,900곳 초과, 1,000만 달러 이상 약 250곳 |
| 복수 층 사용 | 10만 달러 이상 고객 중 2025년 말 약 30%, 현재 절반 초과 |
| NRR | 2026년 3분기 말 약 900% |
| 매출 | 2026년 상반기 163억 달러 (전년 같은 기간 12억 달러) |
| Claude Code 효과 | 3분기 Claude Code를 쓰는 Claude Enterprise 상위 5%가 비사용 평균 사용자보다 월 약 20배 지출 |
| 비유 | Uber(승차 → 음식 배달·화물), Amazon(AWS 컴퓨팅 → 스토리지·데이터베이스) |
| 판매 경로 | Applied AI 팀, Ode with Anthropic(Blackstone 등), AWS·Google Cloud·Azure joint go-to-market, SI |
| 위험 요인 | 클라우드 회사와의 경쟁·컴퓨트 확보, 고객 집중 |
핵심 개념
- S-1
- 미국 기업이 상장 전에 SEC에 내는 증권 신고서. 사업, 재무, 위험 요인을 공개합니다.
- TTM
- Trailing Twelve Months. 측정일 직전 12개월 합계입니다.
- Qualified Customers
- NRR 계산에 넣는 고객. 기준 기간 매출이 1달러 이상이고 Pro·Max 구독자는 뺍니다.
- Run-Rate Revenue
- 최근 28일 사용량 요금에 13을 곱하고 월 구독료에 12를 곱해 더한 연 환산 매출입니다.
- Applied AI
- AI 기능을 고객의 실제 업무 환경에 넣는 일을 맡는 Anthropic의 조직과 직무입니다.
- FDE
- Forward-deployed engineer. 고객사 현장에 들어가 맞춤 솔루션을 만드는 엔지니어입니다.
- CSP
- Cloud service provider. 신고서에서는 AWS, Google Cloud, Azure를 가리킵니다.
내 메모
TODO: 내 생각 추가
원문: Rebecca Bellan, 「Anthropic’s IPO filing reveals its strategy for keeping enterprise customers hooked」(TechCrunch, 2026.10.26). 세 층 구조, NRR·Run-Rate Revenue 정의, joint go-to-market, 위험 요인은 Anthropic의 Form S-1(SEC EDGAR, 2026.10.26 제출) 해당 부분으로 확인해 보강했습니다. 복수 층 사용 비율(약 30% → 절반 초과)과 Claude Code 상위 5%의 약 20배 지출은 TechCrunch 보도 기준입니다. 요약·메커니즘·통념과 다른 주장·사례·원문 사례 표는 두 자료의 내용을 AX Review가 다시 정리했습니다. 기술·현업 디테일, JSON 예시, 일정·판정 기준, 인포그래픽은 새로 작성했으며 그 안의 필드명과 기준값은 가상 예시입니다. 원문 전체는 TechCrunch에서 볼 수 있습니다.