AI SDK 7: 에이전트 앱은 이제 “실행 계약”부터 설계해야 한다

AI 에이전트 앱은 이제 “모델을 한 번 호출하고 결과를 보여주는 UI”가 아니다. 파일을 읽고, MCP 도구를 붙이고, 사람 승인을 기다리고, 여러 단계로 재시도하며, 때로는 외부 코딩 하네스까지 실행한다. Vercel이 2026년 6월 25일 공개한 AI SDK 7은 이 변화를 정면으로 받아들인다. 실무자가 봐야 할 포인트는 신기한 데모 기능이 아니라, 에이전트 실행을 운영 가능한 계약으로 나누는 방식이다.

무슨 일이 있었나

Vercel은 AI SDK 7을 공개하면서 에이전트 개발, 실행, 하네스 통합, 관측, 멀티모달 영역을 한 번에 확장했다. 공식 글은 reasoning control, tool/runtime context, provider file/skill upload, MCP Apps, terminal UI, tool approvals, WorkflowAgent, timeout, sandbox, HarnessAgent, telemetry 등을 핵심 변화로 제시한다.

이 업데이트가 중요한 이유는 단순히 API가 늘었기 때문이 아니다. AI 앱의 실패 지점이 “모델이 답을 틀림”에서 “도구가 과한 권한을 가짐”, “승인 상태가 위조되거나 재사용됨”, “배포 중 장기 실행 작업이 사라짐”, “컨텍스트가 프롬프트와 telemetry에 섞임”, “MCP UI와 모델-visible 도구가 구분되지 않음”으로 이동했기 때문이다.

AI SDK 7은 이 지점을 각각 별도 표면으로 만든다. reasoning은 provider별 옵션을 한 줄의 추상화로 맞추고, tool context는 도구별 schema로 제한하며, runtime context는 loop 전체 상태로 다룬다. file과 skill은 매 요청마다 inline으로 보내는 대신 provider reference로 재사용할 수 있게 하고, MCP Apps는 도구 호출 결과가 텍스트만이 아니라 sandboxed iframe UI가 될 수 있게 한다.

왜 실무 개발자에게 중요한가

첫 번째 변화는 “컨텍스트를 프롬프트에 넣지 않는 습관”이다. Vercel의 context 가이드는 tenant 정보, feature flag, session data, request ID, credential, access token 같은 서버 상태를 prompt가 아니라 runtimeContext, toolsContext, contextSchema로 전달하라고 설명한다. 이 구분은 보안뿐 아니라 디버깅에도 중요하다. 모델이 추론해야 할 정보와 코드가 실행에만 써야 할 값은 다르다.

두 번째 변화는 tool approval이 애플리케이션 레벨 정책이 된다는 점이다. AI SDK 7은 도구별 사용자 승인, 승인 함수, catch-all 승인 함수를 지원하고, 고위험 흐름에서는 HMAC-signed approval과 replay hardening까지 언급한다. 즉 “도구 실행 전에 confirm 창 하나 띄움”이 아니라, 어떤 입력과 어떤 사용자 상태에서 어떤 도구가 실행 가능한지 재검증하는 흐름이 필요해진다.

세 번째 변화는 장기 실행이다. WorkflowAgent는 사람 승인을 기다리거나 여러 단계로 이어지는 에이전트 실행이 process restart, deploy, interruption을 지나 재개될 수 있도록 설계됐다. 서버리스나 Fluid Compute 환경에서 에이전트를 운영하려면, 한 HTTP request의 생명주기에 모든 사고를 묶는 방식은 점점 부족해진다.

네 번째 변화는 UI다. MCP Apps는 MCP 도구가 ui:// resource를 통해 interactive UI를 제공하고, host 앱이 이를 sandboxed iframe으로 렌더링하는 모델을 제안한다. 이는 agent chat 화면이 단순 로그가 아니라 검토, 설정, 승인, 결과 비교를 담는 제품 화면으로 바뀐다는 뜻이다.

커뮤니티 신호

Vercel Community의 최근 AI SDK 카테고리를 보면 cost 계산, streaming tool output, BYOK 403, reasoning trace 저장, Bedrock Guardrails, multi-agent workflow 같은 질문이 이어진다. 이 글들을 사실 근거로 삼지는 않겠다. 다만 개발자가 어디서 막히는지는 선명하다. 사람들은 “채팅 UI 만들기”보다 비용, 권한, context, provider 차이, stream 복구, multi-agent orchestration에서 시간을 쓴다.

Reddit과 Hacker News 쪽의 오래된 AI SDK 논의도 비슷한 신호를 준다. SDK 추상화는 빠른 시작에는 강하지만, 실제 제품에서는 provider-specific behavior, hook performance, observability, custom tool contract를 결국 이해해야 한다는 반응이 반복된다. AI SDK 7의 방향은 이 비판을 피하는 것이 아니라, 운영 질문을 더 명시적인 API 표면으로 끌어올리는 쪽에 가깝다.

그래서 이번 릴리스를 “Vercel이 에이전트 기능을 더 넣었다”로만 읽으면 반쪽이다. 현장의 질문은 이미 “어떤 도구를 붙일 수 있나”가 아니라 “이 도구가 어느 tenant state와 credential을 볼 수 있으며, 누가 승인했고, 실패하면 어디서 재개되며, 비용과 trace는 어디에 남는가”로 바뀌었다.

개발·운영 영향

권한 모델부터 바뀐다. 모든 도구가 하나의 runtime object를 공유하면 구현은 쉽지만, third-party tool이나 MCP server가 필요 이상으로 많은 상태를 볼 수 있다. AI SDK 7의 tool-scoped context는 도구별 least privilege를 구현하는 쪽으로 개발 습관을 밀어준다.

배포 모델도 바뀐다. 장기 실행 agent는 timeout budget, resumable workflow, callback data, invalid tool call preservation이 필요하다. 이것이 없으면 승인 대기 중 deploy가 나갔을 때 작업이 유실되거나, tool input이 바뀐 뒤에도 오래된 승인으로 실행될 수 있다.

프론트엔드 영향도 크다. MCP Apps와 TUI는 에이전트 결과를 “assistant message” 하나로 끝내지 않는다. 사용자는 tool UI를 보고, 일부 tool은 app-only로 숨기고, 일부 interaction은 model-visible 도구와 구분해야 한다. chat 컴포넌트는 이제 메시지 렌더러이면서 권한 게이트다.

관측성은 선택 사항이 아니다. 공식 글은 OpenTelemetry 등록, Node.js tracing channel, lifecycle events, tool executions, usage, errors, selected context capture를 강조한다. 팀이 비용이나 품질 이슈를 조사하려면 모델 호출 하나의 trace만으로는 부족하고, step, tool, approval, timeout, sandbox session까지 한 흐름으로 봐야 한다.

지금 팀이 할 수 있는 체크리스트

1. 에이전트가 접근하는 서버 상태를 prompt, runtimeContext, toolsContext 세 그룹으로 나누고, credential은 prompt와 일반 telemetry에 들어가지 않게 한다.

2. 도구별 contextSchema를 만들고, third-party tool이나 MCP tool에는 필요한 값만 전달한다.

3. destructive action, billing action, external write, shell/file operation에는 tool approval 정책을 붙이고 승인 입력을 재검증한다.

4. 사람 승인을 기다리거나 여러 step을 넘는 작업은 WorkflowAgent 같은 durable execution으로 분리할 수 있는지 검토한다.

5. total, per-step, per-chunk, per-tool timeout 예산을 별도로 정한다. “응답 없음”과 “도구 hang”은 다른 장애다.

6. MCP Apps를 붙일 때 model-visible tool, app-only tool, iframe sandbox, allowed tool bridge를 문서화한다.

7. OpenTelemetry 또는 기존 APM으로 model call, step, tool execution, approval, runtime context key, 비용 지표를 한 trace에서 볼 수 있게 한다.

8. AI SDK 6에서 올라간다면 codemod만 믿지 말고 runtime/tool context migration, approval policy, provider-specific file/skill reference를 별도 PR로 검토한다.

리스크와 반론

첫 번째 리스크는 추상화 비용이다. AI SDK 7은 provider 차이를 감추려 하지만, reasoning effort, file upload, skill upload, sandbox, guardrail은 여전히 provider별 제약을 가진다. “한 번 감싸면 모든 모델이 같아진다”가 아니라, 공통면을 만들고 차이는 명시적으로 남기는 전략이 맞다.

두 번째 리스크는 권한 설계의 과소평가다. MCP Apps와 external tools가 붙으면 UI와 tool call 사이에 새로운 trust boundary가 생긴다. iframe sandbox, allowed tools, OAuth header, redirect policy, SSRF 방지, credential scoping을 제품 요구사항으로 다뤄야 한다.

세 번째 반론은 “간단한 챗봇에는 과하다”는 것이다. 맞다. FAQ bot이나 짧은 summarizer라면 모든 기능을 쓸 필요가 없다. 하지만 파일, 외부 API, 승인, 재시도, 장기 실행, 다중 provider가 들어오는 순간부터는 작은 추상화보다 실행 계약이 더 싸다. 나중에 사고를 수습하는 비용이 더 크기 때문이다.

Runtime contract map

출처

• Vercel Blog: AI SDK 7
• Vercel Changelog: AI SDK 7 is now available
• AI SDK Docs: Migrate AI SDK 6.x to 7.0
• Vercel KB: Pass state to AI SDK tools and agents with context
• AI SDK Docs: Model Context Protocol tools
• AI SDK Docs: MCP Apps
• AI SDK Docs: Getting started with coding agents
• Vercel Community: AI SDK topics