이 소식은 무엇인가요?
배경부터 차근차근 살펴보기
Google은 그동안 외부 제공사를 통해 SDK 생성 도구를 제공했는데, 최근 그 제공사가 갑자기 서비스를 중단했습니다. 이를 계기로 Google은 개발 도구 회사 Speakeasy와 협력하여 자신의 OpenAPI 코드 생성 기술을 오픈소스로 공개하기로 결정했습니다.
이 오픈소스 도구는 Python, Go, Java 등 여러 프로그래밍 언어로 SDK를 생성하며, 같은 입력에서 항상 같은 출력을 보장하는 결정론적 생성 방식을 특징으로 합니다. 엄격한 타입 지원과 SSE(Server-Sent Events) 스트리밍 같은 현대적인 API 패턴을 지원하며, AI 에이전트가 직접 사용할 수 있도록 에이전트 네이티브 CLI와 MCP 서버 컴파일 기능도 포함합니다.
AGPLv3 라이선스 아래 공개되어, 생성된 클라이언트 코드는 팀의 필요에 맞게 라이선싱할 수 있습니다. 가장 실질적인 변화는 개발팀이 이 도구를 자신의 CI/CD 파이프라인에 직접 통합할 수 있다는 점입니다. API가 업데이트되면 자동으로 클라이언트 라이브러리가 새로 생성되므로, 수동으로 여러 SDK를 따로 관리할 필요가 사라집니다.
코딩 에이전트를 구축하는 개발자에게는 에이전트가 외부 API와 상호작용할 때 사용할 더 안정적이고 정확한 클라이언트 코드를 얻을 수 있다는 의미입니다. 자동화 엔지니어는 기존 파이프라인에 SDK 생성 단계를 추가하여 배포 자동화를 더 완성도 있게 구성할 수 있게 됩니다.
공식 발표에서 확인된 내용
구체적으로 무엇이 달라졌나
- 01
Google의 이전 SDK 제공자가 갑작스러운 종료로 인해 Google이 독립적인 오픈소스 솔루션을 추진했습니다.
- 02
AGPLv3 라이선스로 공개되어 생성된 클라이언트 코드는 팀의 필요에 맞게 라이선싱할 수 있습니다.
- 03
Python, Go, Java 등 여러 언어로 SDK를 생성하며, 같은 입력에서 항상 같은 출력을 보장하는 결정론적 생성 방식입니다.
- 04
SSE(Server-Sent Events) 스트리밍과 엄격한 타입 지원으로 현대적인 API 패턴을 반영합니다.
- 05
CI 파이프라인에 통합하여 API 업데이트 시 자동으로 클라이언트 라이브러리를 새로 생성할 수 있습니다.
- 06
AI 에이전트가 직접 사용할 수 있도록 에이전트 네이티브 CLI와 MCP 서버 컴파일 기능을 포함합니다.
사용자에게 미치는 영향
누구에게 어떤 의미가 있나
API 관리자와 개발팀 리더
여러 프로젝트를 위해 수동으로 SDK를 작성하고 버전을 관리하는 일에서 벗어날 수 있습니다. 특히 마이크로서비스 아키텍처에서는 각 서비스의 API가 변경될 때마다 클라이언트 코드를 다시 생성하는 번거로움이 크게 줄어듭니다.
코딩 에이전트 구축자
에이전트가 외부 API와 상호작용할 때 사용할 클라이언트 라이브러리의 품질을 높일 수 있습니다. 타입 정보가 정확하고 스트리밍을 지원하는 SDK는 에이전트의 신뢰성을 높입니다.
자동화 엔지니어
기존 CI/CD 파이프라인에 SDK 생성 단계를 추가하여 배포 자동화를 더 완성도 있게 만들 수 있습니다. OpenAPI 스키마 하나로 여러 언어의 클라이언트를 자동 생성하는 워크플로우를 구성할 수 있습니다.
실제 활용 장면
어디에 어떻게 써볼 수 있나
마이크로서비스 환경에서 클라이언트 코드 자동 생성
여러 개의 내부 마이크로서비스가 REST API로 서로 통신할 때, 각 서비스의 OpenAPI 스키마로부터 클라이언트 라이브러리를 자동으로 생성합니다.
- 예를 들면
- 서비스 A의 OpenAPI 스키마를 저장소에 추가하고, CI 파이프라인이 자동으로 서비스 B, C, D에서 사용할 Python/Go SDK를 생성하는 설정을 만듭니다.
- 확인할 결과
- API 변경 시 수동 코드 작성 없이 바로 새 클라이언트 코드가 생성되고, 타입 안전성과 일관성이 보장되는 상황을 기록합니다.
AI 에이전트를 위한 API 통합
AI 코딩 에이전트가 외부 API를 호출할 때 사용할 안정적인 클라이언트 라이브러리를 생성하고, 에이전트 관점에서 최적화된 CLI를 함께 만듭니다.
- 예를 들면
- 공공 데이터 API의 OpenAPI 스키마를 입력하여 에이전트 네이티브 CLI와 Python 클라이언트를 생성한 후, 에이전트가 데이터 조회, 필터링, 스트리밍을 정확히 처리하도록 테스트합니다.
- 확인할 결과
- 에이전트가 타입 오류 없이 API를 호출하고, 스트리밍 응답도 올바르게 처리하는 것을 확인하며, 생성된 코드의 동작 속도를 기록합니다.
조직의 내부 API 플랫폼 구축
조직 전체가 공유하는 여러 개의 내부 API를 관리할 때, 각 팀이 자신의 프로그래밍 언어와 환경에 맞는 클라이언트를 쉽게 얻을 수 있도록 합니다.
- 예를 들면
- 중앙 API 팀이 인증, 결제, 사용자 데이터 API의 OpenAPI 스키마를 저장소에 관리하고, 각 서비스 팀은 CI 파이프라인에서 자신이 필요한 언어의 최신 클라이언트를 자동 다운로드합니다.
- 확인할 결과
- API 변경이 즉시 모든 클라이언트에 반영되고, 버전 충돌이 줄어들며, API 문서와 코드가 항상 일치하는 상태를 유지합니다.
직접 적용해 보기
처음부터 무리하지 말고, 이 순서로 확인하세요
현재 API 관리 방식 진단
팀이 현재 어떻게 클라이언트 라이브러리를 관리하고 있는지 점검합니다. 수동으로 작성하는가, 다른 도구를 쓰는가, 여러 언어를 지원하는가, API 변경에 얼마나 빠르게 대응하는가 등을 확인합니다.
확인: 현재 SDK 관리에서 가장 큰 병목이나 비용이 무엇인지 메모합니다. 예: 매번 10시간 이상 소요, 버전 불일치 오류 빈번, 새 언어 추가 어려움 등.
Speakeasy 오픈소스 도구 확인
GitHub 저장소와 공식 문서를 방문하여 도구의 기능, 지원 언어, 라이선스 조건, 설치 방법을 살펴봅니다.
확인: 자신의 팀이 사용하는 프로그래밍 언어가 지원되는지, AGPLv3 라이선스가 조직의 정책과 맞는지 확인하고 기록합니다.
간단한 API로 SDK 생성 시험
기존의 간단한 내부 API나 공개 API를 선택하여 OpenAPI 스키마를 준비하고, Speakeasy 도구로 클라이언트 코드를 생성해 봅니다.
확인: 생성된 코드가 실제로 API 호출을 하는지, 에러 처리는 제대로 되는지 작은 테스트 스크립트를 작성하여 확인합니다.
CI 파이프라인 통합 설계
Git 저장소의 OpenAPI 스키마가 변경되었을 때 자동으로 SDK를 생성하고 배포하는 GitHub Actions, GitLab CI 또는 Jenkins 파이프라인을 설계합니다.
확인: 스키마 변경 → SDK 생성 → 테스트 → 배포라는 일련의 단계가 수동 개입 없이 작동하는지 검증합니다.
도입 여부 결정 및 계획 수립
시험 결과를 바탕으로 전사 도입 여부를 판단합니다. 도입하기로 결정했다면 기존 SDK 마이그레이션 계획, 팀 교육, 라이선스 검토 등을 일정에 넣습니다.
확인: 결정 근거(시간 절감 예상, 품질 향상, 장기 유지보수성 등)를 문서로 남기고, 도입 시 책임 담당자를 정합니다.
해석할 때 주의할 점
확인된 범위와 아직 모르는 내용을 구분하세요
Google 개발자 블로그의 공식 발표로 확인할 수 있는 사실은 다음과 같습니다: Google이 Speakeasy와 협력하여 OpenAPI 코드 생성 도구를 AGPLv3 라이선스 아래 오픈소스로 공개했으며, 이는 Google의 이전 SDK 제공사의 갑작스러운 중단이 계기가 되었습니다. 도구는 다중 언어 생성, 결정론적 생성, SSE 스트리밍, 엄격한 타입 지원, 에이전트 네이티브 CLI, MCP 서버 컴파일을 지원합니다. 반면 아직 공개되지 않은 내용은 다음과 같습니다: 구체적인 생성 성능 벤치마크, 실제 도입한 조직의 사례와 절감 효과, Google이 내부적으로 사용하면서 발견한 한계점이나 개선 계획, 향후 유지보수 로드맵 등입니다.
- AGPLv3 라이선스는 생성된 코드의 공개를 의무화하는 조건이 있을 수 있으므로, 조직의 라이선스 정책과 반드시 검토하고 법무팀과 상담이 필요할 수 있습니다.
- 공식 발표에는 Speakeasy 도구가 모든 종류의 복잡한 API 패턴을 완벽하게 지원하는지 명시되어 있지 않으므로, 실제로 사용할 API 스키마의 호환성을 직접 테스트해야 합니다.
- 생성된 클라이언트 코드의 유지보수, 버그 수정, 성능 최적화에 대한 책임과 지원 수준이 명확하지 않아 도입 전에 오픈소스 프로젝트의 활동 상황을 확인해야 합니다.
- 기존에 수동으로 작성한 SDK와 자동 생성된 SDK를 섞어 쓸 때 코드 스타일, 에러 처리, 버전 관리 방식의 불일치가 발생할 가능성이 있습니다.
- 조직의 기존 CI/CD 파이프라인이 매우 복잡하거나 특수한 요구사항이 있다면, Speakeasy 통합을 위한 커스터마이징 노력이 필요할 수 있습니다.
출처와 확인일
원문에서 다시 확인하기
이 글은 Google Developers Blog의 공식 발표를 바탕으로 정리했습니다. 기능 범위와 제공 조건은 바뀔 수 있으므로 실제로 적용하기 전에는 원문을 다시 확인해 주세요.
- 마지막 확인
- 2026-09-20
- 다음 검토
- 2026-10-20