오케스트레이션의 붕괴가 시작되었습니다
Google이 AI 에이전트 구축의 규칙을 방금 바꾸었습니다.
Gemini 모델을 위한 새로운 Interactions API가 출시되었습니다. 이는 단순한 업데이트가 아닙니다. 기존의 많은 프레임워크를 불필요하게 만드는 구조적 변화입니다.
수년 동안 개발자들은 AI를 관리하기 위해 거대한 미들웨어 계층을 구축해 왔습니다. 세션 데이터베이스, 컨텍스트 프루닝(context pruning) 서비스, 메모리 관리 도구를 직접 구축해야 했습니다. Gemini를 위해 LangGraph나 AutoGen을 사용했다면, 이러한 "배관 작업(plumbing)"을 관리하는 데 수개월을 보냈을 것입니다.
Interactions API가 이 모든 것을 흡수합니다.
무엇이 바뀌었나?
• 서버 측 상태(Server-side state): 이제 Google이 자체 인프라에서 대화 기록과 메모리를 관리합니다. 사용자가 말한 내용을 기억하기 위해 더 이상 Redis 저장소가 필요하지 않습니다. • 백그라운드 실행(Background execution): 단일 플래그 설정만으로 장시간 실행되는 작업을 수행할 수 있습니다. 더 이상 커스텀 작업 큐나 Celery 클러스터가 필요하지 않습니다. • 관리형 에이전트(Managed Agents): Google은 보안이 강화된 Linux 샌드박스를 제공합니다. 이제 에이전트가 코드를 실행하고, 웹을 탐색하며, 파일을 네이티브하게 관리할 수 있습니다. • 통합 엔드포인트(Unified Endpoint): 이제 하나의 URL이 파편화되어 있던 Chat 및 Generate Content API를 대체합니다.
제가 직접 테스트해 보았습니다. LangGraph 워크플로우를 Interactions API로 옮겨 보았는데, 세션 상태(session-state) 코드가 400줄에서 단 하나의 파라미터로 줄어들었습니다.
이것이 바로 '오케스트레이션의 붕괴(Orchestration Collapse)'입니다. 벤더가 상태(state), 도구, 비동기 실행을 네이티브로 제공하게 되면, 커스텀 프레임워크는 필수 요소가 아닌 선택 사항이 됩니다.
마이그레이션해야 할까요?
다음의 경우 마이그레이션하세요:
- 워크플로우가 Gemini에서만 실행되는 경우.
- 세션 상태나 데이터베이스를 관리하는 데 너무 많은 시간을 소비하는 경우.
- 엔지니어링 오버헤드를 줄이고 싶은 경우.
다음의 경우 현재 프레임워크를 유지하세요:
- 교차 모델 오케스트레이션(예: Claude와 GPT를 모두 사용)이 필요한 경우.
- 복잡한 human-in-the-loop 승인 워크플로우가 필요한 경우.
엔지니어링 작업이 여러분의 인프라에서 Google의 인프라로 이동하고 있습니다. 이를 통해 커스텀 미들웨어 엔지니어링 작업을 40%에서 60%까지 줄일 수 있습니다.
트레이드오프(trade-off)는 락인(lock-in)입니다. 이제 상태 데이터가 Google의 서버에 저장됩니다. 나중에 다른 제공업체로 옮기려면 재구축이 필요합니다. 하지만 대부분의 팀에게는 속도와 비용 절감 효과가 이 트레이드오프를 충분히 가치 있게 만듭니다.
Optional learning community: https://t.me/GyaanSetuAi