Anthropic의 Stainless 인수와 MCP SDK 자동 생성 전략

2026년 5월 18일 Anthropic이 API SDK 자동 생성 스타트업 Stainless를 인수했다. MCP(Model Context Protocol)가 공개된 뒤 18개월 만에 등록 서버가 10,000개를 넘어선 상황에서, 이번 인수의 초점은 단순한 인력 확충보다 SDK 표준화와 Claude API 개발 경험의 재설계에 가깝다.

Stainless가 구축해 온 OpenAPI 기반 다중 언어 코드 생성 기술을 Anthropic의 플랫폼에 결합하면 API 인터페이스를 만들고 배포하는 방식 자체가 달라진다.

빠르게 커진 MCP 생태계가 만든 유지보수 문제

MCP는 2024년 말 공개됐고, 이후 등록 서버가 10,000개를 초과했다. 서버 수가 늘어날수록 언어별 클라이언트 SDK를 일관되게 제공하는 일도 어려워진다. API가 빠르게 바뀌는 환경에서 각 SDK를 사람이 별도로 수정하고 배포하는 방식은 유지하기 어렵다.

Stainless는 OpenAPI 스펙 하나로 Python, TypeScript, Go, Ruby, Java 등 여러 언어의 SDK를 생성하는 파이프라인을 운영해 왔다. Stripe, OpenAI, Cloudflare 같은 API 사업자를 고객으로 확보했으며, Anthropic의 기존 Claude SDK 역시 Stainless 툴링을 기반으로 생성됐다. Anthropic으로서는 이미 사용하던 외부 기술을 내부 역량으로 전환하면서 SDK에 대한 기술 주도권까지 확보한 셈이다.

개발자 경험에서는 OpenAI SDK가 오랫동안 기준점 역할을 했다. 일관된 오류 메시지와 자동 재시도, 스트리밍 추상화, 타입 안전성은 SDK 채택에 직접 영향을 준다. Stainless를 내재화한 Anthropic은 API 스펙 변경과 SDK 릴리스 사이의 간격을 줄일 수 있다.

⤢✕

OpenAPI 스펙에서 언어별 SDK가 나오기까지

SDK 자동 생성은 OpenAPI 3.x 스펙을 중간 표현(IR, Intermediate Representation)으로 바꾸는 작업에서 출발한다. Stainless의 접근법은 템플릿의 문자열만 교체하는 방식이 아니다. 언어별 관용구를 반영해 AST 수준에서 코드를 만든다.

Python에서는 Pydantic 모델로 응답 타입을 정의하고, TypeScript에서는 Zod 스키마나 인터페이스를 이용해 타입을 선언한다. Go 코드는 구조체와 포인터 시맨틱을 반영한다. null, 열거형(enum), 옵셔널 필드도 각 언어가 일반적으로 다루는 형태에 맞춰 표현된다.

⤢✕

MCP 서버용 SDK를 만들 때는 프로토콜 특성을 반영하는 계층이 더 필요하다. MCP는 JSON-RPC를 기반으로 하므로 도구(tool), 리소스(resource), 프롬프트(prompt)의 핸들러 패턴을 언어별 코드로 올바르게 풀어내야 한다. Stainless 기술이 이 영역에 적용되면 MCP 서버 개발자는 하나의 스펙 파일에서 여러 언어의 서버 뼈대를 얻을 수 있다.

타입 변경을 릴리스까지 연결하는 방식

자동 생성 SDK에서 타입 안전성은 컴파일 오류를 줄이는 데만 쓰이지 않는다. API 업그레이드 과정에서 발생한 브레이킹 체인지를 개발자가 코드 수준에서 바로 발견하게 해준다.

Stainless 파이프라인은 OpenAPI 스펙의 diff를 분석해 deprecated 필드, 새 필수 파라미터, 타입 변경을 SDK 타입 시스템에 반영한다. 스펙 변경의 성격에 따라 semver 전략도 자동으로 결정된다. 응답 필드가 추가되면 마이너 버전으로, 필드가 제거되거나 타입이 바뀌면 메이저 버전으로 분류하며 CHANGELOG와 마이그레이션 가이드도 함께 생성한다.

테스트와 문서 역시 같은 스펙에서 파생된다. 각 엔드포인트의 성공 응답 픽스처, 오류 응답 픽스처, 파라미터 검증 케이스를 생성해 API 변경에 대한 회귀 테스트 범위를 확보한다.

OpenAPI 스펙의 description 필드에서는 엔드포인트 주석과 파라미터 설명, 코드 예시를 추출한다. 추출한 내용은 Python docstring, TypeScript JSDoc, Go godoc처럼 언어별 문서화 방식에 맞춰 삽입된다.

운영 환경에서 드러나는 SDK 품질

Claude API를 프로덕션에서 운영할 때 자주 마주치는 문제는 rate limit(429), 서버 과부하(529), 네트워크 타임아웃이다. Stainless 기반 SDK는 지수 백오프(exponential backoff) 재시도 로직을 내장하고, OpenAPI 스펙에 정의된 응답 코드를 기준으로 재시도 가능한 오류와 즉시 실패해야 하는 오류를 구분한다.

⤢✕

오류 타입도 언어별 예외 구조에 맞춰 생성된다. AuthenticationError, RateLimitError, BadRequestError, InternalServerError 같은 예외 클래스에는 HTTP 상태 코드와 응답 바디, 요청 ID가 구조화된 형태로 담긴다.

Claude API의 스트리밍 응답은 Server-Sent Events(SSE)를 사용한다. 이 동작을 SDK에 노출할 때 Python은 AsyncGenerator, TypeScript는 AsyncIterable, Go는 채널(channel) 패턴을 적용한다. 같은 API라도 개발자가 사용하는 언어에 맞는 방식으로 다룰 수 있도록 추상화하는 것이다.

인증 계층은 API 키뿐 아니라 Workload Identity와 OAuth 2.0 토큰 기반 인증을 확장 가능한 인터페이스로 구성한다. 환경 변수에서 자격증명을 탐지하는 ANTHROPIC_API_KEY, 설정 파일의 우선순위, 런타임 주입 방식도 스펙에 따라 생성된다.

Project Glasswing과 SDK 텔레메트리의 접점

Project Glasswing은 Anthropic이 추진하는 보안 이니셔티브로, API 사용 패턴 모니터링과 이상 탐지를 포함한다. Stainless 기반 SDK가 Glasswing과 연결되면 요청 타임스탬프, 토큰 사용량, 모델 버전, 요청 ID 같은 메타데이터를 SDK에서 구조화해 수집할 수 있다.

이 메타데이터를 Glasswing 텔레메트리 파이프라인으로 전달하는 훅(hook)이 자동 생성 과정에 포함될 것으로 예상된다. 그렇게 되면 개발자는 별도의 모니터링 코드를 작성하지 않고도 API 사용 패턴을 확인할 수 있다.

모델 회사에서 개발자 플랫폼으로

SDK 생성 기술을 내부에 두면 새 API 기능과 언어별 SDK를 함께 배포하기 쉬워진다. 기존에는 Anthropic이 기능을 공개한 뒤 Python, TypeScript, Go SDK가 순차적으로 갱신되는 데 수일에서 수주가 걸리는 경우가 있었다. Stainless 파이프라인이 완전히 통합되면 API와 SDK 업데이트를 사실상 동시에 진행할 수 있다.

MCP 쪽에서는 서버 개발자가 공식 Anthropic 툴링을 이용해 자신의 서버용 클라이언트 SDK를 생성하는 셀프서비스 플랫폼이 만들어질 가능성이 높다. 서버 제공자와 클라이언트 소비자가 맞물리는 MCP 생태계에서 SDK 생성 장벽이 낮아지면 양쪽의 성장이 서로를 끌어올리는 구조가 형성된다.

Anthropic의 주요 SDK는 이미 GitHub에 오픈소스로 공개돼 있다. Stainless 통합 후에는 자동 생성 파이프라인의 일부나 전체를 공개하거나, 커뮤니티가 확장한 OpenAPI 스펙을 검증하는 CI/CD 파이프라인을 공유하는 방향도 예상된다.

Linux Foundation 산하 MCP 거버넌스와 연결되는 과정에서는 Anthropic이 표준 MCP 스펙의 OpenAPI 표현을 정의하고, 이를 이용해 공식 SDK를 생성·배포하는 역할을 맡을 것으로 보인다. 이는 MCP 표준의 레퍼런스 구현체로서 Anthropic의 위치를 강화할 수 있다.

⤢✕

Stainless 인수는 Anthropic이 모델 API만 제공하는 회사에서 개발자 플랫폼의 기반까지 직접 운영하는 회사로 이동하고 있음을 보여준다. MCP 생태계가 계속 확장되려면 언어마다 일관된 품질을 제공하는 SDK 인프라가 필요하다. Anthropic은 자동 생성 파이프라인을 통해 Claude API와 MCP 표준의 개발 경험을 함께 통제할 수 있는 기반을 확보했다.