SDK 공장이 Claude로 간다, MCP 표준의 숨은 권력

Anthropic이 2026년 5월 18일 Stainless 인수를 발표했습니다. 겉으로 보면 "AI 회사가 개발자 도구 스타트업을 샀다"는 흔한 문장으로 지나갈 수 있습니다. 하지만 이번 건은 조금 다릅니다. Anthropic이 산 것은 단순한 SDK 생성기가 아니라, 에이전트가 외부 API를 안전하고 정확하게 쓰기 위해 필요한 연결층입니다.

Anthropic 공식 발표는 Stainless를 SDK와 MCP 서버 tooling의 리더라고 설명합니다. 또 Stainless가 초기 Claude API부터 모든 공식 Anthropic SDK 생성을 맡아 왔고, 수백 개 회사가 Stainless를 통해 SDK, CLI, MCP 서버를 만든다고 밝혔습니다. 여기서 중요한 단어는 SDK만이 아닙니다. MCP 서버입니다. Anthropic이 만든 Model Context Protocol이 에이전트와 외부 도구를 연결하는 사실상의 표준 후보가 되어 가는 동안, 그 MCP 서버를 실제 API 제품에 붙이는 생성 도구까지 Anthropic 안으로 들어간 것입니다.

동시에 Stainless의 공식 글은 고객에게 더 직접적인 메시지를 남겼습니다. Anthropic에 합류한 뒤 Claude Platform capabilities와 agents-to-APIs 연결에 집중하겠고, hosted Stainless products와 SDK generator를 단계적으로 종료한다는 내용입니다. 2026년 5월 18일부터 새 signup, project, SDK 생성을 제공하지 않는다고도 밝혔습니다. 기존 고객이 지금까지 생성한 SDK를 소유하고 수정 및 확장할 권리는 유지된다고 설명했지만, hosted generator에 의존하던 팀에게는 전환 과제가 생겼습니다.

이 뉴스의 진짜 의미는 "Anthropic이 또 하나를 샀다"가 아닙니다. AI 에이전트 시대의 개발자 경험이 어디에서 경쟁력을 얻는지를 보여준다는 점입니다. 2023년과 2024년의 질문이 "어떤 모델이 더 똑똑한가"였다면, 2026년의 질문은 "그 모델이 실제 시스템을 얼마나 안정적으로 다룰 수 있는가"에 가깝습니다. 모델이 코드를 쓰고, API를 호출하고, 데이터를 읽고, 승인 흐름을 거치고, 오류를 복구하려면 모델 바깥의 도구 체인이 필요합니다. Stainless는 바로 그 도구 체인의 낮은 층에 있었습니다.

SDK는 사람 개발자용 편의 기능이 아니게 됐습니다

오랫동안 SDK는 사람 개발자를 위한 DX 도구였습니다. REST API 문서를 읽고, 인증 헤더를 붙이고, pagination과 error object를 처리하는 반복 작업을 줄여주는 역할이었습니다. 좋은 SDK는 onboarding 시간을 줄이고, 타입 힌트를 주고, 언어별 idiom을 맞춰 줍니다. API 회사 입장에서는 SDK와 docs가 제품 채택의 표면이었습니다.

에이전트가 들어오면 이 표면의 의미가 바뀝니다. 이제 SDK는 사람만 읽는 라이브러리가 아니라 모델이 생성한 코드가 실행되는 경로가 됩니다. 문서도 검색 엔진과 사람 독자를 위한 페이지에서 agent planner가 참고하는 실행 설명서가 됩니다. API 명세는 client library의 입력일 뿐 아니라 tool schema, docs chunk, MCP server, eval harness의 원천 데이터가 됩니다.

Stainless가 이 변화를 일찍 포착했다는 점은 자사 제품 설명에서 보입니다. Stainless MCP 제품 페이지는 OpenAPI spec에서 code-mode MCP server를 생성한다고 설명합니다. 전통적인 MCP 서버가 endpoint마다 하나의 tool을 노출하면 context window가 endpoint 정의로 붓거나 discovery loop가 길어질 수 있습니다. Stainless의 접근은 agent에게 search_docs와 execute라는 두 도구를 주고, 에이전트가 SDK와 문서를 이용해 TypeScript 코드를 작성하고 실행하게 하는 방식입니다.

Stainless는 이 방식이 자체 평가에서 94-97% task accuracy, 3배 적은 tool call, 복잡한 작업에서 10만 개 이상의 token 절감을 보였다고 주장합니다. 이 숫자는 독립 검증 결과가 아니라 vendor claim으로 읽어야 합니다. 그래도 방향은 분명합니다. 에이전트에게 수백 개 endpoint schema를 그대로 던지는 방식보다, 잘 설계된 SDK와 검색 가능한 문서와 제한된 실행 도구를 묶어 주는 방식이 더 관리 가능한 agent interface가 될 수 있다는 주장입니다.

Anthropic이 가져간 것은 생성기 이상의 관계망입니다

Anthropic 발표는 Stainless가 "수백 개 회사"에 쓰인다고 말합니다. Stainless 블로그의 사이트 navigation에는 Cloudflare, Letta, Lithic, Modern Treasury, MUX, OpenAI, Replicate, Turbopuffer, Weights & Biases 같은 고객 항목이 보입니다. Stainless는 별도 글 목록에서도 official client libraries for OpenAI, Anthropic, Cloudflare and more를 생성한다고 설명해 왔습니다.

이 대목은 민감합니다. Anthropic이 경쟁사의 SDK까지 통제한다는 식으로 단정하면 과장입니다. 공식 발표와 Stainless 글은 그런 고객별 계약 종료나 경쟁사 차단을 구체적으로 설명하지 않습니다. 다만 hosted Stainless products와 SDK generator가 종료되는 것은 공식으로 확인됩니다. 따라서 실무적으로 말할 수 있는 안전한 결론은 이것입니다. Stainless가 vendor-neutral developer tooling 회사로 제공하던 hosted 생성 서비스는 Anthropic 내부의 Claude Platform 역량으로 재배치되고 있습니다. 그 결과, Stainless 관리형 파이프라인에 의존하던 API 팀은 자체 fork, 대체 generator, 내부 generation workflow, contract test를 검토해야 합니다.

Anthropic 입장에서 이 인수는 자연스럽습니다. Claude Code, Claude Platform, Claude for business, MCP 생태계가 커질수록 에이전트는 더 많은 실제 시스템을 다뤄야 합니다. 그런데 실제 API는 깔끔한 demo 함수 세 개가 아닙니다. 인증 방식, pagination, idempotency, rate limit, 비동기 job, webhook, error recovery, sandbox와 production 환경, 권한 scope, SDK 버전 호환성이 붙습니다. 모델이 아무리 좋아도 이 표면이 지저분하면 agent는 잘못된 endpoint를 고르거나, 파라미터를 빠뜨리거나, 같은 call을 반복하거나, 실패 후 복구하지 못합니다.

Stainless는 이 문제를 모델 바깥에서 줄이는 회사였습니다. API spec을 언어별 SDK와 docs와 MCP 서버로 바꾸고, agent가 그 표면을 더 적은 tool call과 더 명확한 code path로 사용하게 하는 쪽입니다. Anthropic이 "agents are only as capable as the systems they can reach"라고 쓴 것도 이 맥락입니다. 에이전트가 닿을 수 있는 시스템의 품질은 단순히 connector 개수로 정해지지 않습니다. 그 connector가 모델에게 얼마나 읽히고, 얼마나 안전하게 실행되고, 얼마나 관측 가능하게 실패하는지가 중요합니다.

MCP 표준의 다음 병목은 구현입니다

MCP는 표준입니다. 하지만 표준이 성공하려면 좋은 구현이 필요합니다. HTTP가 있다고 해서 모든 API가 쓰기 쉬운 것은 아니고, OpenAPI spec이 있다고 해서 모든 SDK가 좋지는 않습니다. MCP도 마찬가지입니다. 서버가 tool을 많이 노출할수록 모델은 더 많은 선택지를 검토해야 하고, 설명이 부정확하면 잘못된 호출이 늘어납니다. 대형 API는 endpoint 수가 많고, 파라미터 조합이 복잡하며, 실제 작업은 여러 call의 순서로 이뤄집니다.

그래서 Stainless가 말한 code-mode MCP는 흥미로운 타협입니다. endpoint마다 tool을 만드는 대신, 문서를 검색하고 SDK 코드를 실행하는 작은 도구 집합을 제공합니다. 이것은 에이전트가 이미 잘하는 코드 생성 능력을 API 사용에 활용하자는 접근입니다. 동시에 안전한 sandbox, SDK 타입, 문서 검색, 실행 피드백을 붙이면 raw function calling보다 더 높은 수준의 작업 단위를 만들 수 있습니다.

물론 이 접근에도 질문이 있습니다. 모델이 코드를 쓰고 실행하는 방식은 강력하지만, sandbox 경계와 권한 정책이 중요해집니다. SDK가 자동 생성된다고 해도 API spec 자체가 부정확하면 잘못된 client가 생성됩니다. docs가 agent-facing으로 바뀌면 인간에게 친절한 설명과 모델에게 명확한 instruction 사이의 균형도 필요합니다. 그리고 이런 tooling이 특정 모델 회사 안으로 들어가면, MCP가 표준으로 열려 있더라도 reference workflow와 optimization target이 Claude 중심으로 기울 수 있습니다.

이것이 이번 인수의 숨은 권력입니다. 표준 문서의 문장보다 구현 tooling의 기본값이 더 큰 영향을 줄 때가 많습니다. 어떤 SDK structure가 기본인지, error object를 어떻게 표현하는지, docs chunk를 어떻게 나누는지, MCP server가 endpoint tools를 노출할지 code execution mode를 노출할지, eval을 어떤 task로 돌릴지에 따라 생태계의 관성이 생깁니다. Anthropic은 MCP를 만들었고, 이제 그 MCP를 production API에 붙이는 생성 도구 회사까지 가져갔습니다.

API 팀에게 생긴 즉시 과제

이번 발표로 모든 API 팀이 당장 Claude Platform으로 이동해야 한다는 뜻은 아닙니다. 오히려 반대입니다. 특정 vendor 발표를 계기로 자신들의 API 연결 전략을 더 명시적으로 점검할 필요가 생겼습니다. 에이전트가 주요 integration consumer가 된다면 SDK, docs, MCP 서버는 marketing checklist가 아니라 production surface입니다.

첫째, SDK 생성 파이프라인의 소유권을 확인해야 합니다. Stainless는 기존에 생성한 SDK를 고객이 소유하고 수정 및 확장할 수 있다고 밝혔습니다. 그러나 매 릴리스마다 hosted generator에 의존했다면 앞으로는 대체 경로가 필요합니다. Speakeasy, Fern, OpenAPI Generator 같은 대체 도구를 검토할 수도 있고, 이미 생성된 SDK를 fork해 내부 build pipeline으로 옮길 수도 있습니다. 중요한 것은 API spec 변경이 SDK와 docs와 MCP 서버에 어떻게 반영되는지 추적하는 것입니다.

둘째, agent-facing docs를 따로 생각해야 합니다. 사람에게 좋은 문서는 배경 설명과 예시가 풍부합니다. 에이전트에게 좋은 문서는 정확한 함수명, 제한 조건, 입력 형식, 실패 조건, idempotency, rate limit, 권한 scope가 명확합니다. 이 둘은 겹치지만 완전히 같지 않습니다. Stainless가 docs platform for agents를 이야기한 이유도 여기에 있습니다. AI가 API를 쓰기 시작하면 docs의 독자는 브라우저를 연 사람뿐 아니라 planner와 code generator가 됩니다.

셋째, MCP 서버를 단순히 "있다"로 끝내면 안 됩니다. MCP 서버가 endpoint를 많이 노출할수록 좋아지는 것은 아닙니다. 어떤 tool을 노출할지, 어떤 tool은 code execution 뒤로 숨길지, destructive action에는 어떤 confirmation을 요구할지, audit log와 trace를 어떻게 남길지 설계해야 합니다. agent가 API를 잘못 호출했을 때 되돌릴 수 있는지, retry가 안전한지, test account와 production account를 어떻게 나눌지도 중요합니다.

넷째, vendor 중립성을 기술과 운영으로 나눠 봐야 합니다. MCP 자체가 열린 표준이어도, 생성 도구와 eval harness와 docs workflow가 한 vendor의 최적화 방향을 따라가면 실제 운영은 묶일 수 있습니다. 반대로 모든 것을 내부에서 직접 만들면 유지보수 비용이 커집니다. API 팀이 선택해야 하는 것은 추상적인 중립성이 아니라, 장애와 가격 변경과 acquisition 이후에도 SDK와 MCP 서버를 재생성할 수 있는 능력입니다.

커뮤니티의 우려는 과장이지만 무시할 수 없습니다

Reddit의 Anthropic과 Claude 관련 토론에서는 Stainless 인수를 긍정적으로 보는 반응과 집중 리스크를 걱정하는 반응이 동시에 나왔습니다. 긍정 쪽은 Anthropic이 Claude agent의 tool-use 품질을 끌어올릴 수 있고, MCP 서버 생태계에 더 많은 투자가 들어갈 것이라고 봅니다. 우려 쪽은 Stainless가 OpenAI, Google, Cloudflare 같은 여러 API 회사의 tooling과 연결돼 있었다는 점을 들어, 표준의 실제 구현 관성이 한 회사로 기울 수 있다고 봅니다.

Backend 쪽 반응에서는 더 실무적인 목소리가 보였습니다. hosted generator가 종료되면 SDK 생성 파이프라인을 다시 세워야 하고, spec과 실제 서버 동작의 차이를 잡는 contract test가 중요해진다는 주장입니다. 이 반응은 설령 일부 표현이 과장되어 있더라도 핵심은 맞습니다. AI agent 시대에 API tooling은 한 번 만들고 잊는 부속물이 아닙니다. 모델, API, docs, SDK, MCP server가 함께 변하므로 지속적인 검증이 필요합니다.

여기서 조심할 점도 있습니다. 검색 결과에는 인수 가격, 경쟁사 차단, 고객 이탈 같은 강한 주장이 여럿 보이지만, 공식 출처가 확인한 내용은 제한적입니다. Anthropic과 Stainless가 공개적으로 확인한 사실은 인수, Stainless의 Anthropic 합류, hosted Stainless products와 SDK generator 종료, 기존 생성 SDK에 대한 고객 권리, Anthropic 공식 SDK와 Stainless의 관계입니다. 따라서 이 글에서는 가격이나 경쟁사 접근 차단을 사실처럼 다루지 않습니다.

Anthropic의 전략은 모델 바깥을 사는 쪽으로 넓어집니다

Anthropic은 Claude 모델만 파는 회사에서 Claude가 일하는 환경을 통제하는 회사로 이동하고 있습니다. Claude Code는 repository와 shell과 browser 검증에 가까워지고, Claude Platform은 tool use와 enterprise deployment를 다룹니다. MCP는 외부 시스템 연결의 표준 언어가 되고 있습니다. Stainless는 그 표준 언어를 API 회사가 실제 제품에 붙일 때 필요한 생성, 문서, SDK, MCP 서버 층입니다.

이 전략은 OpenAI, Google, Microsoft와의 경쟁에서도 중요합니다. 모든 frontier lab은 모델 성능 경쟁만으로 차별화하기 어려운 시점에 도달하고 있습니다. 비슷한 reasoning, 비슷한 coding benchmark, 비슷한 context window가 반복되면 기업 고객은 "우리 시스템에서 얼마나 잘 작동하는가"를 봅니다. 그러면 승부는 connector, security boundary, audit, SDK, docs, runtime, sandbox, deployment로 이동합니다.

Anthropic이 Stainless를 산 것은 그 이동을 보여주는 작은 지도입니다. API가 에이전트에게 잘 읽히고 잘 실행되는 회사는 Claude 생태계에서 더 쉽게 작동할 수 있습니다. 반대로 Anthropic은 SDK와 MCP 서버 생성 과정에서 생기는 반복 문제를 직접 볼 수 있습니다. 어떤 API가 에이전트에게 어려운지, 어떤 문서 구조가 실패를 줄이는지, 어떤 SDK idiom이 모델의 코딩 오류를 줄이는지가 Claude Platform의 제품 개선 데이터가 될 수 있습니다.

이 지점에서 API 회사와 개발자 도구 회사는 더 냉정해져야 합니다. 에이전트 친화적인 API가 된다는 것은 "MCP 서버 하나 추가"가 아닙니다. OpenAPI spec의 정확도, SDK release cadence, docs 검색 품질, code examples, permission scopes, sandbox 실행, destructive action confirmation, eval dataset이 함께 필요합니다. Stainless가 Anthropic 안으로 들어간 것은 이런 작업이 이제 주변부가 아니라 frontier AI platform의 핵심으로 올라왔다는 뜻입니다.

결론: 에이전트의 힘은 연결층에서 결정됩니다

Anthropic의 Stainless 인수는 화려한 모델 출시가 아닙니다. 하지만 AI 개발자에게는 모델 출시만큼 중요할 수 있습니다. 실제 제품에서 에이전트는 API를 호출하고, SDK를 사용하고, 문서를 검색하고, 실패를 복구하고, 권한 경계를 지켜야 합니다. 이 과정이 흔들리면 모델 성능은 사용자에게 도달하지 못합니다.

Stainless는 그 연결층을 자동화하던 회사였습니다. Anthropic은 MCP를 만든 회사입니다. 둘이 합쳐지면 Claude가 외부 시스템을 다루는 방식은 더 촘촘해질 수 있습니다. 동시에 vendor-neutral tooling에 기대던 API 팀은 새로운 전환 비용과 집중 리스크를 보게 됩니다. 그래서 이번 뉴스는 "Anthropic이 Stainless를 샀다"보다 "SDK 공장이 Claude로 간다"에 가깝습니다.

앞으로 API 팀이 봐야 할 질문은 단순합니다. 우리 API는 사람 개발자에게만 친절한가, 아니면 에이전트가 안전하게 사용할 수 있는가. 우리 SDK와 docs는 제품 부속물인가, 아니면 agent execution layer인가. 우리 MCP 서버는 demo checklist인가, 아니면 production integration surface인가. Stainless 인수는 이 질문을 더 미룰 수 없게 만든 신호입니다.