AI SDK 7: 에이전트 개발의 표준화

이번 주의 테마는 통합(consolidation)입니다. AI SDK 7은 프로덕션 에이전트를 위한 프로바이더 불가지론적(provider-agnostic) 기반을 출시하며, LangSmith는 전용 데이터베이스와 온콜 트리아지(on-call triage) 자동화를 통해 관측성(observability)의 루프를 완성했고, Deno 2.9는 더 무거운 런타임(runtime)을 사용할 이유를 두 가지 더 조용히 제거했습니다. 만약 여러분이 커스텀 어댑터와 흩어진 오케스트레이션(orchestration) 로직으로 에이전트 워크플로우를 임시방편으로 이어 붙여왔다면, 이제 도구들이 마침내 그 속도를 따라잡고 있습니다.

AI SDK 7, 프로바이더 전반에 걸친 에이전트 개발 표준화

AI SDK 7은 프로덕션 에이전트 코드베이스에 쌓여온 프로바이더별 보일러플레이트(boilerplate)를 제거하는 네 가지 프리미티브(primitives)를 도입합니다: 타입이 지정된 도구 컨텍스트(typed tool context), 런타임 컨텍스트(runtime context), 파일/기술 업로드(file/skill uploads), 그리고 MCP Apps입니다. 타입이 지정된 도구 컨텍스트는 모든 핸들러에 전역 변수를 전달할 필요 없이, 도구가 스코프가 지정된 타입화된 상태를 가질 수 있음을 의미합니다. 런타임 컨텍스트를 사용하면 도구를 요청 인프라(request infrastructure)에 결합하지 않고도 실행 스코프 데이터(execution-scoped data)를 호출 스택 아래로 전달할 수 있습니다. 파일 및 기술 업로드는 에이전트가 프로바이더 전반에 걸쳐 바이너리 입력과 재사용 가능한 기능을 전달할 수 있는 네이티브 패턴을 제공합니다. MCP Apps는 이미 Model Context Protocol(MCP)을 기반으로 구축하고 있다면 이를 더욱 확장해 줍니다.

실질적인 이점은 프로바이더를 교체하거나 멀티 도구 워크플로우를 확장할 때 발생하는 컨텍스트 스위칭(context-switching) 오버헤드를 줄이는 것입니다. 새로운 모델이 나올 때마다 어댑터 로직을 다시 작성하는 대신, SDK 프리미티브를 대상으로 한 번만 작성하면 됩니다.

판결: 출시하십시오(Ship). v6에서 v7로의 마이그레이션을 위해 npx @ai-sdk/codemod v7을 실행하세요. 이 명령어가 중대한 변경 사항(breaking changes)을 기계적으로 처리해 줍니다. 추론 제어(reasoning control)와 도구 컨텍스트부터 시작하십시오. 파일/기술 업로드는 다단계 추론(multi-step inference)에서 즉각적인 효과를 발휘합니다. MCP Apps는 이미 MCP 네이티브라면 투자할 가치가 있지만, 이 기능 때문에 업그레이드를 미루지는 마십시오.

AI SDK 7, 프로덕션 에이전트 플랫폼 출시

API 표면(surface)의 변경 사항을 넘어, SDK 7은 실제로 프로덕션(production) 환경에서 에이전트를 운영하는 데 필요한 런타임 인프라를 제공합니다: 내구성이 있는 실행(durable execution), 도구 승인 게이트(tool approval gates), 멀티모달(multimodal) 지원, 그리고 제공자 중립적인 추론 제어(provider-agnostic reasoning control)가 이에 해당합니다. 이는 기존 패턴을 단순히 추상화한 것이 아니라, 대부분의 팀이 직접 유지 관리해 온 커스텀 오케스트레이션(orchestration) 보일러플레이트(boilerplate)를 대체합니다. 특히 승인 게이트(approval gates)는 이제 사후에 덧붙여진 미들웨어 패턴이 아닌, 일급 시민 프리미티브(first-class primitive)로 제공됩니다.

파괴적 변경 사항(breaking changes)은 실재합니다: Node.js 22 이상 버전이 필요하며, 패키지는 ESM 전용(ESM-only)입니다. 두 제약 사항 모두 의도적인 것이며 협상의 여지가 없습니다. 코드모드(codemods)가 대부분의 기계적인 마이그레이션을 처리하지만, ESM 전용 방식은 CommonJS 비중이 높은 서비스에서 임포트(import) 문제를 일으킬 수 있습니다.

결론: 프로덕션에서 에이전트 워크플로(workflow)를 실행 중이라면 배포하십시오. 지속성(persistence) 및 관측 가능성(observability) 프리미티브만으로도 마이그레이션 비용을 정당화할 수 있습니다. 프로토타입 단계의 프로젝트는 미뤄도 좋습니다. 한 가지 실제적인 리스크는 제공자별 추론 동작이 여전히 다르다는 점입니다. 특정 워크플로를 단일 모델에 맡기기 전에, 제공자별 추론 비용과 지연 시간(latency)을 벤치마크하십시오.

AI SDK Harness, Deep Agents 및 OpenCode 어댑터 추가

Harness 패키지는 통합된 Vercel Sandbox 인터페이스를 통해 접근 가능한 두 가지 새로운 코딩 에이전트 런타임인 Deep Agents와 OpenCode를 추가합니다. 아키텍처는 간단합니다: @ai-sdk/harness-deepagent를 @ai-sdk/harness-opencode로 교체하기만 하면 애플리케이션 코드는 변경되지 않습니다. 이제 동일한 API 표면 뒤에서 총 5개의 런타임이 지원됩니다.

코딩 에이전트의 기능과 가격 정책이 여전히 빠르게 변하고 있기 때문에 이는 매우 중요합니다. 마이그레이션이 필요할 때 SDK 임포트 계층에서의 벤더 종속(vendor lock-in)은 실제 비용이 됩니다. Harness는 이러한 종속성을 Harness 패키지 자체에 대한 얇은 의존성과 샌드박스 실행을 위한 Vercel 계정으로 대체합니다.

판결: 검토 필요 (Evaluate). 두 패키지 모두 문서와 함께 게시되어 즉시 사용 가능합니다. 현재 LangChain 또는 OpenCode SDK를 직접 임포트(import)하여 사용 중이라면, 스파이크(spike) 테스트를 해볼 가치가 있습니다. 제약 사항: Node 런타임과 Vercel 계정이 필요하며, 둘 중 하나라도 사용할 수 없는 환경이라면 실행이 불가능합니다. 현재 도구 요구 사항(파일/셸 도구 vs 추론 변형 모델)에 맞는 에이전트로 시작하여, 샌드박스(sandbox) 실행 모델이 귀사의 보안 태세(security posture)에 부합하는지 확인하십시오.

LangSmith, 온콜 트리아지(on-call triage) 에이전트 및 컴퓨터 사용(computer use) 기능 추가

LangSmith Fleet은 이제 온콜 트리아지(on-call triage)를 처리하는 사전 구축된 에이전트 템플릿을 제공합니다. 이 템플릿은 프로덕션 경고(production alerts)를 읽고, 관련 트레이스(traces)를 가져오며, 런북(runbooks)을 실행하고, 진단 결과를 제시합니다. 이와 별도로, Fleet은 컴퓨터 사용(computer use) 지원을 추가했습니다. 이제 에이전트는 프로덕션 시스템을 건드리지 않고도 코드 실행 및 인증된 API 호출을 위해 격리된 VM(가상 머신)과 상호작용할 수 있습니다.

온콜 템플릿은 새로운 라이브러리 종속성이 아닙니다. 기존 Fleet 설정에 바로 적용할 수 있는 사전 구축된 워크플로(workflow)입니다. 이미 LangSmith 트레이스(traces)를 통해 계측(instrumented)을 하고 있다면 그 가치는 실질적입니다. 에이전트가 로그 문자열에 대한 패턴 매칭을 수행하는 대신, 트레이스 트리(trace tree)를 실제로 탐색하여 실패 지점을 찾을 수 있기 때문입니다.

컴퓨터 사용(computer use)은 구현 난이도가 다릅니다. 격리된 작업을 VM으로 디스패치(dispatching)하려면, 격리가 필요한 작업과 그렇지 않은 작업을 분리하도록 에이전트 코드를 리팩터링(refactoring)해야 합니다. 중간 정도의 노력이 필요하지만, 인증된 API 호출을 수행하는 에이전트에게 이 기능이 제공하는 보안 경계(security boundary)는 매우 의미가 있습니다.

판결: 프로덕션에서 에이전트를 실행 중이고 기존 트레이스 계측(trace instrumentation)이 갖춰져 있다면 지금 바로 온콜 템플릿을 검토하십시오. 시도하는 데 마찰이 적습니다. 컴퓨터 사용 기능은 격리 경계가 필요한 구체적인 작업이 생길 때까지 보류하십시오. 추측만으로 리팩터링 비용을 감수할 필요는 없습니다.

SmithDB, LangSmith 에이전트 트레이스 워크로드 지원

LangSmith의 관측성 (Observability) 백엔드가 이제 SmithDB에서 실행됩니다. SmithDB는 객체 스토리지(Object storage) 기반의 상태가 없는 (Stateless) 쿼리 및 인제스션 (Ingestion) 서비스를 갖춘 목적 특화형 분산 데이터베이스입니다. 핵심 워크로드에서 12배 더 빠르다고 주장합니다. 아키텍처 측면의 근거는 신뢰할 만합니다. 에이전트 트레이스 (Agent traces)는 깊게 중첩되어 있고, 몇 시간에 걸쳐 순서가 뒤섞인 채 도착하며, 멀티모달 (Multimodal) 페이로드를 포함하는데, 기존의 관측성 저장소들은 이 중 어느 것도 매끄럽게 처리하지 못합니다. SmithDB는 에이전트 실행을 실제로 디버깅하는 방식에 직접 매핑되는 트리 인식 쿼리 (Tree-aware queries) 및 JSON 필터링 기능을 추가합니다.

클라우드 사용자들에게는 별도의 마이그레이션 없이 이미 적용되었습니다. 셀프 호스팅 (Self-hosted) 배포 버전은 곧 출시될 예정입니다.

판결: 클라우드 사용자라면 즉시 사용하십시오. 이미 적용되어 있습니다. 만약 셀프 호스팅 중이며 대규모 트레이스 탐색 시 지연 시간 (Latency) 문제에 부딪히고 있다면, 업데이트가 출시될 때 업그레이드를 우선순위에 두십시오. 직접 LangSmith 배포를 관리하는 경우가 아니라면, 오늘 당장 개발자가 취해야 할 조치는 없습니다.

Deno 2.9, 데스크톱 앱 지원 및 더 빠른 서빙

Deno 2.9는 웹뷰 (Webview) 또는 Chromium 백엔드를 사용하여 웹 프레임워크를 네이티브 바이너리로 컴파일하는 deno desktop을 추가합니다. 콜드 스타트 (Cold startup)가 1.98배 개선되었습니다. Deno.serve의 메모리 사용량 (Memory footprint)은 2.2~3.1배 감소했습니다. npm, pnpm, yarn, Bun으로부터의 직접적인 락파일 (Lockfile) 임포트는 마이그레이션 마찰을 대폭 줄여줍니다. 코드 재작성 없이 기존의 의존성 트리 (Dependency tree)를 그대로 가져올 수 있습니다.

deno desktop은 이미 웹 UI를 작성하고 있으며 보일러플레이트 (Boilerplate) 없이 네이티브 바이너리를 원하는 경우, Electron이나 Tauri 설정을 대체합니다. 단일 명령어로 실행 가능합니다: deno desktop main.ts.

판결: deno desktop의 프로덕션 도입은 기다리십시오. 실험적 단계이며 플랫폼 기능들이 여전히 안정화되는 중입니다. 적합성을 평가하기 위해 새로운 프로젝트 (Greenfield)에서 스파이크 (Spike) 테스트를 실행해 볼 가치는 있습니다. Node.js 호환성 및 락파일 임포트는 오늘 바로 프로덕션에 사용할 수 있는 수준입니다. Deno로의 마이그레이션을 고려 중이라면, 이 두 기능이 가장 흔한 장애물들을 제거해 줄 것입니다.