Devlery
Blog/AI

Stainless 인수, Claude가 손에 넣은 API 접속층

Anthropic의 Stainless 인수는 AI 에이전트 경쟁이 모델 성능에서 SDK, CLI, MCP 서버를 만드는 접속 인프라로 이동했음을 보여줍니다.

Stainless 인수, Claude가 손에 넣은 API 접속층
AI 요약
  • 무슨 일: Anthropic이 SDK와 MCP 서버 생성 도구 회사 Stainless를 인수했습니다.
    • Stainless는 Anthropic 공식 SDK뿐 아니라 OpenAI, Cloudflare, Replicate 같은 API 기업의 개발자 접속면에도 관여해 온 회사입니다.
  • 의미: 에이전트 경쟁의 병목이 모델 답변에서 API spec - SDK - CLI - MCP server 접속층으로 이동하고 있습니다.
  • 주의점: Anthropic은 거래 조건을 공개하지 않았고, 기존 Stainless 고객의 전환·유지 조건은 아직 완전히 드러나지 않았습니다.
    • TechCrunch는 hosted Stainless 제품 종료와 기존 생성 SDK의 소유·수정 권리 보장을 보도했습니다.

Anthropic이 2026년 5월 18일 Stainless를 인수한다고 발표했습니다. 겉으로 보면 AI 회사가 개발자 도구 회사를 산 흔한 이야기처럼 보입니다. 하지만 이번 인수의 중심에는 모델 자체가 아니라, 모델이 실제 시스템에 닿는 방식이 있습니다. Stainless는 API 스펙을 읽고 TypeScript, Python, Go, Java, Kotlin 같은 언어별 SDK와 CLI, MCP 서버를 생성하는 회사입니다. 말하자면 에이전트가 외부 서비스를 부를 때 지나가는 접속면을 만드는 회사입니다.

Anthropic은 발표문에서 AI의 전선이 "답하는 모델"에서 "행동하는 에이전트"로 이동하고 있다고 설명했습니다. 그리고 에이전트는 연결할 수 있는 시스템만큼만 유용하다고 말했습니다. 이 문장은 이번 인수의 핵심입니다. Claude가 더 똑똑해지는 것만으로는 충분하지 않습니다. Claude가 기업 데이터베이스, 결제 API, 배포 시스템, 이슈 트래커, 문서 저장소, 사내 업무 도구에 안정적으로 접근해야 실제 업무를 수행할 수 있습니다. 그 접근을 매번 손으로 붙이면 확장성이 떨어집니다. API 스펙에서 SDK와 MCP 서버를 일관되게 뽑아내는 계층이 중요해지는 이유입니다.

Stainless 홈페이지는 SDK, 문서, MCP 서버를 API 스펙에서 만드는 접속 계층을 전면에 둡니다.

이번 뉴스가 흥미로운 지점은 Stainless가 Anthropic 내부 도구만 만들던 회사가 아니었다는 점입니다. Stainless 홈페이지는 OpenAI, Cloudflare, Replicate, Weights & Biases 같은 고객 사례를 내세웁니다. OpenAI 고객 사례 페이지에는 OpenAI가 자체 Python SDK와 openapi-generator 기반 Node SDK에서 겪은 문제를 해결하기 위해 Stainless를 썼고, SDK들이 Stainless로 생성된다는 설명도 등장합니다. Anthropic 발표 역시 Stainless가 초기 Claude API 시절부터 모든 공식 Anthropic SDK 생성을 지원했다고 말합니다.

즉 Anthropic은 단순히 자사 SDK 품질을 높이기 위한 팀을 영입한 것이 아닙니다. AI API 생태계 여러 회사가 의존하던 조용한 인프라 회사를 자사 플랫폼 안으로 끌어들였습니다. 이 때문에 개발자 커뮤니티의 반응도 양면적입니다. 한쪽에서는 Claude SDK와 MCP 서버 품질이 좋아질 수 있다고 봅니다. 다른 쪽에서는 모델 회사가 SDK, 런타임, 커넥터 계층을 함께 소유할 때 생기는 벤더 의존성을 걱정합니다.

Stainless가 실제로 만드는 것

Stainless의 제품 설명은 매우 직접적입니다. 훌륭한 에이전트 경험은 훌륭한 개발자 경험 위에 만들어진다는 것입니다. 그 개발자 경험은 API 문서를 보기 좋게 만드는 수준에서 끝나지 않습니다. API 스펙이 바뀔 때 SDK가 따라 바뀌고, 언어별 타입과 오류 처리가 자연스러워야 하며, 사용자가 CLI로 호출할 수 있어야 하고, 이제는 에이전트가 MCP 서버를 통해 같은 API를 도구처럼 사용할 수 있어야 합니다.

이것은 프롬프트 엔지니어링과 다른 문제입니다. OpenAPI 스펙 하나를 입력으로 받아도 실제 개발자용 SDK를 만들려면 여러 층의 판단이 필요합니다. 어떤 엔드포인트를 어떤 객체 모델로 노출할지, 페이지네이션과 스트리밍을 어떻게 감쌀지, API가 바뀌었을 때 breaking change를 어떻게 분류할지, 특정 언어의 관용적 사용법을 어떻게 반영할지 결정해야 합니다. MCP 서버도 마찬가지입니다. 모든 API 엔드포인트를 그대로 도구로 노출하면 에이전트가 쓰기 어렵습니다. 도구 이름, 설명, 입력 스키마, 인증 방식, 실패 처리까지 설계해야 합니다.

계층사람 개발자에게 보이는 형태AI 에이전트에게 보이는 형태Stainless의 의미
API 스펙문서와 타입의 원천도구 스키마의 원천OpenAPI를 실행 가능한 인터페이스로 변환
SDKTypeScript, Python, Go 등 언어별 라이브러리에이전트 코드가 호출하는 안정적 클라이언트API 변경을 언어별 개발 경험으로 흡수
CLI터미널에서 호출하는 운영 인터페이스샌드박스·자동화 작업의 실행 표면사람과 에이전트가 같은 동작을 재현 가능하게 호출
MCP 서버도구 연결 설정LLM이 발견하고 호출하는 도구 목록API를 에이전트용 도구 계약으로 재포장

이 표를 놓고 보면 Anthropic이 왜 Stainless를 원했는지 더 선명해집니다. 모델 회사는 추론 능력을 팔지만, 고객은 결과물을 원합니다. 결과물은 대개 외부 시스템을 읽고 쓰는 행위로 완성됩니다. 코드 에이전트는 저장소와 CI를 읽어야 하고, 세일즈 에이전트는 CRM을 업데이트해야 하며, 재무 에이전트는 결제·정산 API와 연결되어야 합니다. 이때 SDK와 MCP 서버는 모델의 부속품이 아니라 에이전트 제품의 실행 인프라가 됩니다.

MCP 이후의 자연스러운 다음 수

Anthropic은 2024년 11월 MCP를 공개하면서 AI 시스템과 데이터 소스를 연결하는 개방 표준을 만들겠다고 했습니다. 당시 설명은 정보 사일로를 줄이고, 각 데이터 소스마다 별도 커넥터를 만드는 방식을 표준 프로토콜로 바꾸자는 것이었습니다. MCP의 기본 구조는 단순합니다. 개발자는 데이터나 도구를 MCP 서버로 노출하고, AI 애플리케이션은 MCP 클라이언트로 그 서버에 연결합니다.

이 아이디어가 커지면 다음 병목은 "누가 MCP 서버를 잘 만들 것인가"가 됩니다. 표준이 있어도 구현이 엉성하면 에이전트는 도구를 제대로 쓰지 못합니다. 도구 설명이 모호하면 모델이 잘못 호출합니다. 입력 스키마가 과하게 넓으면 실패율이 올라갑니다. 인증과 권한 경계가 흐리면 보안 문제가 생깁니다. API 스펙이 바뀌었는데 MCP 서버가 뒤처지면 에이전트는 낡은 계약을 믿고 실행합니다.

Stainless MCP 포털은 이 지점을 노립니다. OpenAPI 스펙에서 MCP 서버로 가는 실무 가이드, 복잡한 스펙 변환 사례, OpenAI·Anthropic·Stainless가 함께한 MCP 관련 세션, Scorecard와 Modern Treasury 같은 MCP 서버 사례를 모아 보여줍니다. 이는 MCP가 단순한 프로토콜 발표를 넘어 API 기업의 제품 표면으로 들어가고 있음을 뜻합니다.

OpenAPI 스펙: 엔드포인트, 타입, 인증, 오류 계약

Stainless 변환 계층: SDK, CLI, 문서, MCP 서버 생성

사람 개발자: 언어별 SDK와 CLI로 호출

AI 에이전트: MCP 도구로 발견·호출

따라서 이번 인수는 MCP 전략의 후속 조치로 볼 수 있습니다. Anthropic이 표준을 제안했다면, Stainless는 그 표준을 실제 API 기업들이 채택할 수 있는 생산 라인으로 바꾸는 회사입니다. 표준은 생태계의 언어를 만들고, 생성 도구는 그 언어를 매일 쓰는 비용을 낮춥니다. AI 에이전트 플랫폼을 운영하는 회사라면 이 비용 구조를 직접 통제하고 싶을 수밖에 없습니다.

경쟁사 SDK를 만든 회사를 산다는 것

이번 인수에서 가장 민감한 부분은 Stainless의 고객 기반입니다. Anthropic 발표문은 "수백 개 회사"가 Stainless로 SDK, CLI, MCP 서버를 생성한다고 설명합니다. Stainless 사이트의 고객 목록에는 OpenAI와 Cloudflare 같은 이름이 보입니다. TechCrunch는 Anthropic이 Stainless의 hosted 제품을 종료할 예정이며, 기존 고객은 지금까지 생성한 SDK를 계속 소유하고 수정할 수 있다는 설명을 들었다고 보도했습니다.

여기서 두 가지를 구분해야 합니다. 첫째, 이미 생성된 SDK가 갑자기 사라지는 것은 아닙니다. 보도에 따르면 기존 고객은 생성된 결과물에 대한 권리를 유지합니다. 둘째, 앞으로의 자동 생성·업데이트 파이프라인은 별도 문제입니다. API는 계속 변합니다. 모델 API는 특히 빠르게 변합니다. 새 파라미터, 새 응답 형식, 새 스트리밍 이벤트, 새 오류 코드, 새 인증 흐름이 계속 들어옵니다. SDK 생성기가 한 번의 결과물이 아니라 지속적 유지 보수 체계인 이유입니다.

개발자 입장에서 위험은 "오늘 import가 깨진다"가 아닐 가능성이 큽니다. 더 현실적인 위험은 다음 API 변경 때부터 운영 비용이 올라가는 것입니다. 내부 생성기로 이전해야 할지, 다른 공급자를 찾아야 할지, 기존 SDK를 포크해 직접 유지해야 할지 판단해야 합니다. 특히 여러 언어 SDK를 동시에 제공하는 API 기업은 이 문제가 작지 않습니다. Python 하나만 유지하는 것과 TypeScript, Python, Java, Go, Kotlin, Ruby, PHP, C#을 함께 유지하는 것은 전혀 다른 일입니다.

커뮤니티 반응도 이 지점에 모입니다. Reddit의 AI 에이전트 커뮤니티에서는 "Claude 사용자에게는 좋은 소식"이라는 해석과 "AI 앱 하부 스택이 한 벤더로 모이는 신호"라는 해석이 함께 나왔습니다. Backend 커뮤니티의 한 글은 Stainless hosted generator 종료에 대응해 대체 SDK/MCP generator를 만들었다고 주장했고, 댓글에서는 실제 어려운 부분이 spec drift, breaking change 분류, semver, codemod 힌트, contract testing이라는 지적이 나왔습니다.

이 반응은 과장된 공포만은 아닙니다. SDK 생성은 단순히 템플릿을 돌리는 일이 아닙니다. API 계약이 바뀌었을 때 무엇이 깨지는 변경인지 자동으로 분류하고, 기존 사용자의 코드를 덜 깨뜨리며, 문서와 타입을 함께 업데이트해야 합니다. 에이전트 시대에는 이 작업이 MCP 도구 계약까지 확장됩니다. 잘못 생성된 도구는 사람이 읽는 문서보다 더 위험할 수 있습니다. 사람은 문서를 의심하지만, 에이전트는 스키마를 실행 계약처럼 받아들이기 때문입니다.

Anthropic이 산 것은 개발자 경험인가, 플랫폼 통제권인가

Anthropic의 공식 논리는 개발자 경험입니다. Stainless 창업자 Alex Rattray는 SDK가 API만큼 세심한 관리를 받을 가치가 있다고 말했습니다. Anthropic의 플랫폼 엔지니어링 리더 Katelyn Lesse는 에이전트가 연결할 수 있는 것만큼 유용하다고 설명했습니다. 이 논리는 충분히 설득력이 있습니다. Claude API를 쓰는 개발자가 더 좋은 SDK와 MCP 서버를 얻게 된다면 제품 품질은 올라갑니다.

하지만 플랫폼 경쟁의 관점에서는 다른 해석도 가능합니다. Anthropic은 Claude 모델, Claude Code, Claude for Work, MCP, 엔터프라이즈 커넥터, 보안·컴플라이언스 제품군을 빠르게 넓히고 있습니다. 여기에 SDK와 MCP 서버 생성 계층이 붙으면 Claude 생태계의 접속 표면을 더 깊게 통제할 수 있습니다. 이것은 나쁜 일이라고 단정할 수는 없습니다. 통합이 잘 되면 개발자는 덜 고생합니다. 문제는 그 통합이 멀티모델·멀티벤더 전략과 얼마나 잘 공존할 수 있느냐입니다.

AI 팀은 이미 모델 선택에서 벤더 분산을 고민합니다. 성능, 비용, 지연 시간, 데이터 정책, 지역 규제, 장애 대응을 고려해 OpenAI, Anthropic, Google, 오픈 모델을 섞습니다. 그런데 에이전트가 외부 시스템에 연결되는 계층까지 특정 모델 회사의 도구에 묶이면 분산 전략이 복잡해집니다. "모델은 바꿀 수 있지만 커넥터 생성 파이프라인은 바꾸기 어렵다"는 상황이 생길 수 있습니다.

이 지점에서 Stainless 인수는 작은 M&A 이상의 의미를 갖습니다. AI 플랫폼 전쟁은 이제 모델 API 엔드포인트만의 경쟁이 아닙니다. 어떤 회사가 개발자가 쓰는 SDK를 만들고, 어떤 회사가 에이전트가 호출하는 MCP 서버를 만들며, 어떤 회사가 API 계약의 변경을 흡수하는지가 중요해지고 있습니다. 사용자는 모델 이름을 기억하지만, 제품의 안정성은 이런 낮은 계층에서 결정됩니다.

개발자와 API 기업이 볼 체크포인트

이번 사건을 보고 당장 모든 팀이 SDK 생성기를 바꿔야 하는 것은 아닙니다. 다만 AI 기능을 API로 제공하거나, 에이전트가 호출할 수 있는 도구를 제공하는 팀이라면 몇 가지 질문을 해야 합니다.

첫째, 현재 SDK와 MCP 서버 생성 파이프라인의 소유권을 확인해야 합니다. 생성 도구가 외부 SaaS라면 소스 스펙, 생성 설정, 커스텀 템플릿, 배포 권한, 이전 가능한 산출물이 어디까지 확보되어 있는지 확인해야 합니다. 이미 생성된 코드만 저장소에 있다고 충분하지 않을 수 있습니다. 다음 API 변경을 반영할 방법이 있어야 합니다.

둘째, OpenAPI 스펙의 품질을 점검해야 합니다. 에이전트 도구 생성은 스펙의 모호함을 그대로 증폭합니다. 파라미터 설명이 빈약하거나 오류 모델이 불명확하거나 인증 스코프가 문서 밖에 있으면 MCP 도구도 불안정해집니다. 사람 개발자는 예제를 보고 눈치껏 맞출 수 있지만, 에이전트는 스키마와 설명을 더 직접적으로 따릅니다.

셋째, MCP 서버를 "자동 생성하면 끝"으로 보면 안 됩니다. 어떤 작업은 읽기 전용 도구로만 열어야 하고, 어떤 작업은 사용자 승인이나 별도 권한 확인을 거쳐야 합니다. 결제, 삭제, 배포, 개인정보 접근 같은 동작은 도구 설명뿐 아니라 실행 정책과 감사 로그가 필요합니다. Stainless 같은 생성 도구는 시작점을 낮추지만, 운영 책임을 없애지는 않습니다.

넷째, 벤더 의존성은 기술적 감정이 아니라 운영 비용으로 계산해야 합니다. 특정 공급자가 사라지거나 인수되거나 제품 방향을 바꿨을 때 몇 주 안에 이전할 수 있는지, 생성된 SDK를 직접 유지할 수 있는지, 언어별 릴리스 자동화가 문서화되어 있는지 따져야 합니다. AI 에이전트가 고객 업무 흐름 안으로 깊게 들어갈수록 이 질문은 더 중요해집니다.

한국 개발자에게 더 가까운 이유

한국의 많은 B2B SaaS, 핀테크, 커머스, 업무 자동화 팀도 비슷한 흐름을 맞고 있습니다. AI 에이전트가 내부 업무를 대신하려면 국내 결제, 전자문서, 물류, 세무, CRM, 그룹웨어 API와 연결되어야 합니다. 이 연결을 모두 개별 플러그인으로 만들면 유지 비용이 커집니다. 반대로 API 스펙을 정리하고 SDK와 MCP 서버를 동시에 제공할 수 있다면, 그 API는 사람 개발자와 에이전트 모두에게 더 쓰기 쉬운 제품이 됩니다.

Stainless 인수는 해외 대형 AI 회사의 M&A지만, 메시지는 지역과 무관합니다. 앞으로 API 기업은 문서와 SDK를 개발자 지원 자산으로만 볼 수 없습니다. 그것은 에이전트가 실제 업무를 수행하는 통로입니다. API 스펙이 곧 도구 계약이 되고, SDK 품질이 곧 에이전트 안정성이 됩니다. 이 전환을 먼저 받아들이는 API 회사는 에이전트 생태계에서 더 잘 발견되고 더 안정적으로 호출될 가능성이 큽니다.

동시에 국내 팀은 특정 글로벌 AI 플랫폼의 커넥터 생태계에 완전히 종속되지 않는 전략도 고민해야 합니다. MCP가 넓게 채택되는 것은 좋은 신호지만, MCP 서버 생성과 배포, 인증, 로깅, 정책 집행이 한 회사의 제품에만 묶이면 장기 선택지가 줄어듭니다. 오픈 스펙, 재현 가능한 생성 설정, 테스트 가능한 도구 계약을 남기는 습관이 중요해집니다.

모델 밖 전쟁의 조용한 신호

이번 인수는 화려한 모델 발표가 아닙니다. 벤치마크 숫자도 없고, 새로운 챗봇 UI도 없습니다. 하지만 에이전트가 실제 제품이 되는 과정에서는 이런 뉴스가 더 중요할 수 있습니다. 모델이 아무리 좋아도 외부 시스템을 안전하고 일관되게 호출하지 못하면 업무 자동화는 멈춥니다. 반대로 접속 계층이 잘 정리되면 모델은 더 작은 문맥 낭비로 더 정확하게 행동할 수 있습니다.

Anthropic은 MCP를 제안했고, 이제 MCP 서버와 SDK를 생산하는 Stainless를 품었습니다. 이것은 Claude가 더 많은 시스템에 닿기 위한 투자입니다. 동시에 경쟁사와 API 기업에는 질문을 던집니다. 에이전트 시대의 연결 계층을 직접 소유할 것인가, 독립 공급자에게 맡길 것인가, 오픈소스 생성기로 이전할 것인가, 아니면 각자 내부 플랫폼을 만들 것인가.

개발자에게 남는 결론은 단순합니다. AI 에이전트의 품질을 모델 이름만으로 판단하기 어려워졌습니다. 이제는 그 에이전트가 어떤 SDK와 도구 계약을 통해 세상에 연결되는지 봐야 합니다. Anthropic의 Stainless 인수는 그 기준선을 앞으로 당긴 사건입니다. Claude가 손에 넣은 것은 SDK 회사 하나가 아니라, 에이전트가 API 세계로 들어가는 접속층입니다.

출처