구글조차 SDK 생성기를 오픈소스로 푼 이유 — OpenAPI 코드젠의 판이 바뀐다

왜 SDK 생성기가 갑자기 화두일까

AI 에이전트 생태계에서 SDK는 '부가 기능'이 아니라 인터페이스 그 자체예요. Interactions, Agents, Webhooks처럼 스트리밍 프로토콜과 엄격한 에러 계층, 복잡한 타입 유니온을 다루는 API를 손으로 감싸는 건 사실상 불가능하죠. 그래서 대부분의 빅테크는 OpenAPI 스펙을 코드로 컴파일하는 전용 생성기를 씁니다.

문제는 이 생성기가 폐쇄형(proprietary) 이라는 점이었어요. 실제로 2026년 5월, 구글이 Google I/O와 Interactions API 정식 출시(GA)를 준비하던 시점에, 사용하던 SDK 생성 업체가 인수 후 갑작스럽게 서비스 종료를 선언합니다. 파이프라인이 통째로 흔들린 거예요. 이 사건이 던진 교훈은 명확합니다.

"OpenAPI로 인터페이스를 정의한다면, 그 인터페이스를 클라이언트 라이브러리·CLI·에이전트 도구로 컴파일하는 툴체인도 오픈 인프라여야 한다."

근거자료: Google Developers Blog — Why client SDK generation belongs in the open

이 글에서는 (1) 구글이 실제로 어떻게 마이그레이션했는지, (2) AGPLv3 라이선스가 실무에 어떤 의미인지, (3) 국내 팀이 이걸 어떻게 써먹을 수 있는지를 정리해볼게요.

실제 파이프라인은 어떻게 생겼나

구글은 Speakeasy와 협업해 클라이언트 라이브러리를 in-place 마이그레이션했어요. 핵심 원칙은 '개발자 혼란 최소화 + 브레이킹 체인지 회피'. 마이그레이션 과정에서 정리한 엔지니어링 포인트는 이렇습니다.

• 모든 타깃 언어의 타입 정의 정렬 (언어별 타입 매핑 일관성)
• 엄격한 에러 계층 구조 유지
• 스트리밍 동작 보존 (SSE, 청크 처리)
• 생성기를 사내 모노레포 및 빌드 시스템에 직접 통합

여기서 중요한 설계 철학이 나옵니다. 구글 딥마인드는 결정론적(deterministic) 생성기를 코어에 두고, 커스텀 파트만 AI 에이전트로 가속하는 하이브리드 구조를 택했어요. 이유는 단순합니다. "공식 API 스펙 → 다국어 SDK" 변환은 창의성이 아니라 타입 안전성과 재현성이 생명이거든요.

# 생성된 SDK 사용 예시 (Gemini Interactions API)
from google import genai

client = genai.Client()
interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input="Analyze this commit log and find regressions.",
)
# 생성된 클라이언트는 스트리밍/에러 타입까지 스펙과 1:1로 대응됨
print(interaction.output_text)

결과적으로 이전에는 여러 엔지니어가 손수 관리하던 생성기를, 지금은 엔지니어 약 1명으로 6개 타깃(3개 출시, 나머지 순차 롤아웃)을 커버하는 파이프라인으로 운영 중이라고 합니다. 유지보수 인력이 1/3 이하로 줄어든 셈이죠.

AGPLv3, 실무에서 뭐가 달라지나

가장 많이 헷갈리는 부분이라 표로 정리했어요.

핵심은 "생성기 ≠ 생성물" 이라는 분리예요. 생성기를 수정하지 않고 그대로 돌려서 나온 SDK는 여러분 라이선스로 자유롭게 배포할 수 있습니다. 반면 생성기 컴파일러 자체를 고치면 그 개선분은 AGPL에 따라 커뮤니티에 환원해야 하죠.

주의할 점 (비판적 시점)

• AGPL 전파 범위: 생성기를 SaaS 형태로 감싸서 외부에 노출하는 경우 AGPL 해석 이슈가 생길 수 있어요. 사내망 내부 사용은 안전하지만, 외부 서비스화는 법무 검토가 필요합니다.
• 결정론 vs AI 하이브리드: AI 에이전트로 커스텀 파트를 가속하는 구조는 편리하지만, 재현성 검증(생성 결과 diff)을 CI에 반드시 넣어야 해요. 안 그러면 '어제는 되던 SDK가 오늘 안 되는' 상황이 생깁니다.
• 스펙 드리프트: OpenAPI 스펙이 급변하는 초기 단계 API라면, 생성기 버전과 스펙 버전을 함께 고정(pin)하는 게 안전합니다.

한국 개발 생태계에서의 적용 맥락

국내 SI·B2B 환경에서는 사내 API 게이트웨이 → 다국어 SDK 자동 생성 파이프라인에 이 구조를 그대로 이식할 수 있어요. 특히 여러 파트너사에 SDK를 배포해야 하는 플랫폼 사업자라면, 폐쇄형 코드젠 업체 의존이 곧 '파트너사 납품 지연' 리스크로 직결됩니다. 오픈소스 생성기 + 자체 CI 통합은 이런 공급망 리스크를 크게 줄여줍니다. 다만 AGPL 검토는 반드시 사내 법무와 선행하세요.

정리: 지금 팀이 취할 액션

1. OpenAPI 스펙이 이미 있다면 → Speakeasy 생성기를 로컬에서 돌려보고, 기존 수제 SDK와 출력 diff를 비교해보세요. 마이그레이션 비용이 생각보다 낮을 수 있습니다.
2. 스펙이 없다면 → 이 기회에 API를 OpenAPI로 문서화하는 게 먼저예요. 코드젠의 전제 조건입니다.
3. CI 통합 → 생성 결과의 결정론을 검증하는 job을 파이프라인에 추가하세요.

한 줄 요약: "SDK 생성기는 이제 사내 인프라로 취급해야 할 시점" 입니다. 폐쇄형 생성기에 목숨 걸지 마세요.

다음 단계 학습 방향

• OpenAPI 3.1 스펙 작성법과 oneOf/anyOf 유니온 타입 설계
• 결정론적 코드젠 파이프라인과 스냅샷 테스트
• MCP 서버 자동 생성 (같은 스펙에서 파생되는 또 다른 산출물)

함께 보면 좋은 글

• "MLPerf 6.0 전 부문 석권한 NVIDIA, DeepSeek-V3 671B를 단 2분에 학습시킨 비결"
• "A2UI v0.9 정식 출시 AI 에이전트가 실시간으로 UI를 생성하는 새로운 표준"