Anthropic이 Stainless를 산 이유, 에이전트 연결의 공급망

AI 요약

• 무슨 일: Anthropic이 SDK와 MCP 서버 생성 회사 Stainless를 인수했습니다.
  • 발표일은 2026년 5월 18일이며, 인수 금액은 공식 발표에 공개되지 않았습니다.
• 핵심 의미: 모델 경쟁의 병목이 API 응답에서 에이전트 연결성으로 이동하고 있습니다.
• 실무 영향: SDK, 문서, CLI, MCP 서버가 이제 AI 플랫폼의 배포면이 됩니다.
  • Stainless는 OpenAPI spec에서 SDK와 에이전트용 MCP 서버를 생성하는 계층을 맡아 왔습니다.
• 주의점: Stainless의 MCP 생성 기능은 문서상 experimental이며, 기존 고객 독립성도 지켜봐야 합니다.

Anthropic이 2026년 5월 18일 Stainless 인수를 발표했습니다. 표면적으로는 SDK 생성 도구 회사를 품은 기업 인수 뉴스입니다. 하지만 이 사건을 단순히 "Claude API 개발자 경험이 좋아진다" 정도로만 읽으면 중요한 부분을 놓칩니다. Anthropic이 산 것은 SDK 코드 생성기 하나가 아니라, 에이전트가 외부 API와 만나는 포장 계층입니다.

Anthropic 발표문은 Stainless가 2022년에 설립됐고, Anthropic API 초기부터 공식 Anthropic SDK 생성을 지원해 왔다고 설명합니다. 또한 Stainless가 TypeScript, Python, Go, Java, Kotlin 등 여러 언어의 SDK를 API spec에서 생성하고, 수백 개 회사가 SDK, CLI, MCP 서버 생성을 위해 Stainless를 사용한다고 말합니다. 여기서 눈에 띄는 단어는 SDK보다 MCP입니다. 지금 에이전트 플랫폼의 핵심 문제는 모델이 얼마나 똑똑한가만이 아니라, 모델이 실제 시스템을 얼마나 정확하고 안전하게 호출할 수 있는가입니다.

모델 다음의 전장은 연결성입니다

Anthropic은 2024년 Model Context Protocol을 공개하며 에이전트와 외부 시스템을 연결하는 표준을 밀기 시작했습니다. MCP의 기본 아이디어는 간단합니다. 파일 시스템, 데이터베이스, SaaS, Git 저장소, 브라우저, 내부 API를 각자 다른 방식으로 모델에 설명하는 대신, MCP 서버라는 공통 형태로 노출합니다. Claude Desktop, Claude Code, Cursor 같은 클라이언트는 그 서버를 도구로 발견하고 호출합니다.

이 방식이 커질수록 병목은 "모델이 도구 호출을 지원하는가"에서 "도구가 모델이 쓰기 좋은 형태로 제공되는가"로 옮겨갑니다. 사람이 쓰는 API는 레퍼런스 문서, SDK README, 샘플 코드, 에러 메시지, 타입 정의, changelog를 읽으며 이해합니다. 에이전트도 비슷한 단서가 필요하지만, 사람처럼 웹 문서를 오래 뒤지고 암묵적 관례를 추론하는 데 항상 강하지는 않습니다. API가 에이전트에게 좋은 도구가 되려면 문서, 타입, 인증 방식, 예제, 오류 복구 경로가 함께 포장되어야 합니다.

Stainless는 바로 그 포장 계층을 다룹니다. Stainless 문서는 OpenAPI spec에서 SDK, 문서, CLI, MCP 서버 등을 생성한다고 설명합니다. API spec은 사람이 직접 쓰는 제품 경험이 아닙니다. 하지만 spec을 기반으로 언어별 SDK, 문서, 명령줄 도구, MCP 서버를 일관되게 만들 수 있다면 이야기가 달라집니다. API 회사는 제품을 한 번 설계하고, 사람 개발자와 AI 에이전트가 각각 쓰기 좋은 표면을 자동으로 얻을 수 있습니다.

왜 SDK 회사가 에이전트 회사가 됐나

SDK는 오래된 개발자 인프라입니다. 좋은 SDK는 HTTP 엔드포인트를 언어별 관용구로 바꿉니다. 페이지네이션을 반복문처럼 감싸고, 스트리밍을 언어 런타임에 맞게 제공하고, 인증과 에러 처리를 예측 가능한 방식으로 정리합니다. 그래서 SDK 품질은 API 채택률에 직접 영향을 줍니다. 개발자가 REST 문서를 보며 매번 raw request를 짜야 한다면, API는 제품이 아니라 숙제가 됩니다.

에이전트 시대에는 이 문제가 더 커집니다. AI 코딩 에이전트가 어떤 API를 통합하려고 할 때, 가장 안정적인 경로는 "HTTP 문서를 읽고 추측해서 호출한다"가 아닙니다. 이미 타입과 관례가 정리된 SDK를 쓰고, 그 SDK의 최신 문서를 검색하고, 작은 코드를 실행해 보며 결과를 확인하는 경로가 더 강합니다. Stainless의 MCP 접근이 흥미로운 이유도 여기에 있습니다.

Stainless MCP 문서는 생성된 MCP 서버가 search_docs와 code execution 중심의 구조를 쓴다고 설명합니다. 전통적인 MCP 서버가 API endpoint마다 도구를 하나씩 노출하면 context window가 도구 정의로 빠르게 가득 찰 수 있습니다. 반면 Stainless는 에이전트가 문서를 검색하고, TypeScript SDK를 사용한 코드를 작성하고, sandboxed environment에서 실행하는 방향을 제시합니다. 즉 API 메서드 300개를 도구 300개로 나열하는 대신, "문서를 찾고 SDK 코드로 실행하라"는 더 압축된 인터페이스를 제공합니다.

이 구조는 개발자 경험과 에이전트 경험이 합쳐지는 지점을 보여줍니다. 지금까지 SDK는 사람이 API를 쉽게 쓰기 위한 물건이었습니다. 이제 SDK는 AI 에이전트가 API를 안전하게 호출하기 위한 중간 언어가 됩니다. 사람에게 좋은 SDK가 에이전트에게도 좋은 이유는, 둘 다 같은 문제를 겪기 때문입니다. API 표면이 크고, 문서가 흩어져 있고, 작은 파라미터 실수가 실행 실패로 이어집니다.

Anthropic이 얻는 것은 Claude의 팔입니다

Anthropic 발표문에서 가장 중요한 문장은 "Agents are only as useful as what they can connect to"에 가깝습니다. 한국어로 옮기면, 에이전트의 유용성은 연결할 수 있는 시스템의 범위에 달려 있다는 뜻입니다. Claude가 아무리 긴 reasoning을 하더라도 실제 업무 시스템에 연결되지 못하면 조언자에 머뭅니다. 반대로 CRM, 결제, 로그, 저장소, 데이터베이스, 사내 API에 연결되면 작업자가 됩니다.

이 전환에서 API 연결은 단순 integration backlog가 아닙니다. 에이전트 플랫폼의 유통망입니다. 앱스토어가 모바일 앱을 배포하는 면이었다면, MCP 서버와 SDK는 에이전트가 기능을 가져오는 면입니다. Anthropic이 Stainless를 품는 것은 Claude의 "팔"을 늘리는 투자로 읽을 수 있습니다. 더 많은 API가 Stainless를 통해 SDK와 MCP 서버를 제공하면, Claude Code와 Claude Platform은 그 API를 더 쉽게 이해하고 사용할 수 있습니다.

물론 이것이 곧바로 Anthropic이 모든 API 연결성을 장악한다는 뜻은 아닙니다. MCP는 open standard로 출발했고, 여러 회사가 각자 서버와 클라이언트를 만들고 있습니다. OpenAI Agents SDK, Google의 agent 개발 도구, LangChain/LlamaIndex 생태계도 각자의 통합 방식을 갖고 있습니다. 하지만 Anthropic은 MCP를 만든 회사이고, 이제 MCP 서버 생성과 SDK 생성을 함께 다뤄 온 회사를 내부로 들였습니다. 표준, 클라이언트, 개발자 플랫폼, 생성 도구가 한 회사 안에서 가까워지는 변화입니다.

OpenAI도 지나간 공급망이라는 점

Stainless가 흥미로운 또 다른 이유는 고객 경계입니다. OpenAI Python SDK README는 이 라이브러리가 OpenAI의 OpenAPI specification에서 Stainless로 생성된다고 밝힙니다. Stainless의 OpenAI 고객 사례도 OpenAI가 SDK 경험을 개선하기 위해 Stainless를 사용했다는 이야기를 전면에 둡니다. Anthropic의 발표문 역시 Stainless가 모든 공식 Anthropic SDK 생성을 지원해 왔다고 말합니다.

즉 Stainless는 특정 모델 회사의 부속 도구가 아니라, 프런티어 AI 회사들이 개발자 경험을 구축할 때 이미 지나간 공급망에 가까웠습니다. Anthropic이 이 회사를 인수했다는 점은 미묘합니다. 한편으로는 Claude 플랫폼에 더 깊이 통합될 수 있습니다. 다른 한편으로는 Stainless의 기존 고객과 잠재 고객이 "Anthropic 소유의 SDK/MCP 생성 계층을 계속 중립 인프라로 볼 수 있는가"라는 질문을 하게 됩니다.

이 질문은 당장 답이 나오기 어렵습니다. Anthropic은 발표문에서 Stainless 팀이 Anthropic에 합류해 Claude의 데이터와 도구 연결 능력을 발전시킨다고 설명했지만, 기존 고객 운영 방식이나 제품 독립성에 대한 세부 조건은 길게 공개하지 않았습니다. 따라서 이 인수의 실무적 의미는 두 갈래로 나뉩니다. Claude 사용자에게는 더 강한 플랫폼 통합 신호입니다. API 회사에게는 agent-friendly surface를 누구에게 맡길지 다시 생각하게 하는 신호입니다.

MCP 서버 생성은 아직 완성된 답이 아닙니다

Stainless의 MCP 메시지는 강합니다. 제품 페이지는 code-mode MCP 서버가 endpoint별 tool 폭증을 줄이고, agentic coding과 context limit에 최적화된다고 주장합니다. 페이지에는 94-97% task accuracy, 3x fewer tool calls, complex tasks에서 100k+ tokens saved 같은 수치도 등장합니다. 이 수치들은 Stainless의 공식 주장으로는 의미가 있지만, 독립적인 범용 벤치마크로 받아들이기에는 조심해야 합니다. API 종류, task 설계, agent runtime, context budget에 따라 결과는 달라질 수 있습니다.

더 중요한 주의점은 Stainless 문서 자체가 MCP server generation을 experimental로 표시한다는 점입니다. 문서는 모든 OpenAPI spec을 아직 처리하지 못할 수 있다고 설명합니다. 이것은 자연스러운 상태입니다. 현실의 API는 깔끔한 CRUD만 있지 않습니다. 스트리밍, 웹훅, 파일 업로드, 장기 실행 작업, 비동기 job polling, OAuth consent, tenant별 권한, idempotency, rate limit, pagination edge case가 있습니다. 이런 세부를 에이전트가 안정적으로 다루려면 단순 spec 변환 이상의 품질 관리가 필요합니다.

또한 code execution tool 구조는 강력하지만, 보안과 관측성 질문을 동반합니다. 에이전트가 SDK 코드를 작성해 sandbox에서 실행한다면, sandbox 경계, credential 전달, 로그 보존, side effect 승인, 사용자 대신 실행하는 권한 범위가 중요해집니다. "도구 수를 줄인다"는 장점이 "한 도구가 너무 많은 일을 할 수 있다"는 위험으로 바뀔 수도 있습니다. 따라서 기업 도입 관점에서는 MCP 서버 생성보다 policy, audit, permission 모델을 함께 봐야 합니다.

API 회사에게 바뀌는 질문

이번 인수가 API를 운영하는 회사에게 던지는 질문은 명확합니다. 앞으로 API 문서는 사람만 읽는 문서입니까, 아니면 에이전트가 호출하는 실행 표면입니까. 지금까지 developer relations 팀은 quickstart, SDK, sample app, docs search, changelog를 사람 개발자 기준으로 설계했습니다. 이제는 LLM이 읽고, 코딩 에이전트가 붙이고, MCP 클라이언트가 호출하는 경로까지 고려해야 합니다.

이 관점에서 OpenAPI spec의 품질은 더 중요해집니다. spec이 부정확하면 생성된 SDK가 흔들리고, 생성된 SDK가 흔들리면 MCP 서버와 에이전트 작업도 흔들립니다. API 설명이 애매하면 사람 개발자는 Stack Overflow나 GitHub issue를 찾아 우회하지만, 에이전트는 잘못된 tool call을 반복할 수 있습니다. 에러 메시지가 사람이 읽기에만 적당하고 기계가 복구하기 어렵다면, 에이전트는 실패를 더 오래 끌고 갑니다.

따라서 agent-friendly API는 단순히 MCP 서버 하나를 배포하는 일이 아닙니다. 타입이 정확해야 하고, 예제가 최신이어야 하며, 인증과 권한 오류가 구체적이어야 하고, destructive action에는 idempotency와 dry-run 또는 승인 경로가 있어야 합니다. 문서 검색은 최신 spec과 연결되어야 하고, SDK release는 API 변경과 함께 자동 검증되어야 합니다. Stainless가 다루는 영역은 이 전체 체인의 많은 부분과 맞닿아 있습니다.

Anthropic의 플랫폼 전략으로 보면

Anthropic은 최근 Claude Code, MCP, Agent Skills, 엔터프라이즈 통합을 통해 "모델 API 회사"에서 "에이전트 플랫폼 회사"로 이동하고 있습니다. 이때 개발자 경험은 단순한 포장지가 아닙니다. 에이전트 플랫폼에서 개발자 경험은 실행 안정성입니다. SDK가 좋아야 에이전트가 코드를 덜 틀리고, 문서 검색이 좋아야 불필요한 context를 덜 쓰며, MCP 서버가 좋아야 외부 시스템을 예측 가능하게 다룹니다.

Stainless 인수는 이 전략의 아래쪽을 채웁니다. Claude Code가 개발자의 작업 공간에서 파일을 수정하고 명령을 실행한다면, Stainless는 그 코드가 외부 API를 호출하는 경로를 정리합니다. Claude Platform이 기업 데이터와 도구를 연결하려 한다면, Stainless는 각 API 제공자가 그 연결 표면을 만들도록 돕습니다. 이 둘이 결합하면 Anthropic은 모델, 클라이언트, 프로토콜, SDK/MCP 생성이라는 연결된 스택을 갖게 됩니다.

물론 경쟁사도 가만히 있지 않을 것입니다. OpenAI는 Agents SDK와 Responses API를 중심으로 자체 도구 호출 생태계를 확장하고 있습니다. Google은 Gemini와 개발자 플랫폼, Workspace, Cloud 통합을 함께 밀 수 있습니다. GitHub는 Copilot과 npm, Actions, repos라는 개발자 배포면을 갖고 있습니다. Cursor와 다른 AI IDE는 실제 코드베이스 안에서 에이전트가 어떤 API를 쓰는지 가장 가까운 위치에서 볼 수 있습니다. Stainless 인수는 이 경쟁에서 Anthropic이 "API를 에이전트가 쓰기 좋게 만드는 계층"을 더 직접적으로 소유하겠다는 선택입니다.

지금 개발팀이 볼 체크리스트

개발팀 입장에서 이번 뉴스는 당장 "Stainless를 써야 하나"로 좁혀 볼 필요가 없습니다. 더 좋은 질문은 우리 API와 내부 도구가 에이전트에게 읽히고 실행될 준비가 되어 있는가입니다. 사내 API가 OpenAPI spec을 갖고 있는지, 그 spec이 실제 구현과 일치하는지, SDK와 문서가 같은 진실의 원천에서 만들어지는지부터 봐야 합니다. 내부 MCP 서버를 만들고 있다면 tool description, input schema, side effect, 권한 경계를 코드 리뷰 대상으로 삼아야 합니다.

코딩 에이전트를 쓰는 팀도 같은 질문을 해야 합니다. Claude Code나 Cursor가 외부 API를 통합할 때 어떤 SDK를 선택합니까. 문서 검색은 최신입니까. 에이전트가 실행한 API 호출은 로그로 남습니까. 결제, 삭제, 권한 변경 같은 action은 사람 승인이 필요합니까. MCP 서버를 추가할 때 보안팀은 그 서버가 어떤 credential을 쓰고 어떤 네트워크에 접근하는지 볼 수 있습니까. 이런 질문이 없다면 에이전트 연결성은 생산성 도구가 아니라 새로운 불투명 실행면이 됩니다.

Anthropic의 Stainless 인수는 그래서 작은 인수 뉴스처럼 보이지만, 에이전트 시대의 구조를 잘 보여줍니다. 프런티어 모델은 계속 중요합니다. 그러나 모델이 일을 하려면 도구가 필요하고, 도구를 안정적으로 쓰려면 API가 에이전트 친화적으로 포장되어야 합니다. SDK, 문서, CLI, MCP 서버는 더 이상 개발자 편의 기능만이 아닙니다. AI 플랫폼의 공급망입니다. Anthropic이 Stainless를 산 이유도 그 지점에 있습니다. 에이전트가 실제 일을 하게 되는 순간, 가장 중요한 경쟁력은 답변의 문장력이 아니라 연결된 시스템을 정확히 다루는 능력이기 때문입니다.