Grok Build용 Vercel AI SDK 어댑터 핵심 해설

2026년 8월 13일 Vercel은 Grok Build를 AI SDK 7의 HarnessAgent에 공식 연결할 수 있는 길을 열었습니다. 이제 제품은 각 코딩 하네스에 맞춰 오케스트레이션 계층을 새로 만들지 않고도, Vercel이 지원 대상으로 제시한 9개 코딩 하네스와 동일한 애플리케이션 인터페이스에서 Grok Build를 실행할 수 있습니다.

Vercel이 Grok Build용으로 실제 출시한 것

이번 출시는 새 Grok 모델이 아니라 어댑터입니다.

구조를 계층별로 나누면 이해하기 쉽습니다. 모델은 응답을 생성합니다. 코딩 하네스는 파일, 툴, 세션, 권한, 그리고 작업을 계속 진행시키는 실행 루프를 관리해 모델을 실제 작업자로 만듭니다. Agent Client Protocol, 즉 ACP는 클라이언트와 호환 하네스가 통신하는 공통 언어입니다. 어댑터는 이 프로토콜을 애플리케이션이 이미 이해하는 인터페이스로 변환합니다.

Vercel의 새 패키지는 @ai-sdk/harness-grok-build입니다. 이 패키지는 ACP를 통해 HarnessAgent와 Grok Build CLI를 연결하며, 내부적으로 하위 계층의 @ai-sdk/harness-acp 패키지를 사용합니다.

전체 경로는 다음과 같습니다.

애플리케이션 → HarnessAgent → Grok Build 어댑터 → 샌드박스 내부의 Grok Build CLI

범용 ACP 계층은 기반 통신을 맡는 배관 역할을 합니다. 실제 연결을 완성하는 Grok Build 어댑터에는 패키지, 실행 파일, 인증 매핑, 시작 명령, 툴 매핑이 이미 정의돼 있습니다. 프로토콜의 작동 원리를 더 깊이 알고 싶다면 AI SDK ACP 하네스 어댑터 해설을 참고하십시오. 이 글에서는 실제로 사용할 수 있는 Grok Build 경로에 집중합니다.

이 출시 전에는 ACP 런타임을 추가할 때 해당 런타임 프로필을 직접 정의해야 했습니다. 8월 13일 Grok Build 출시로 공식 어댑터가 생겼고, Claude Code, Codex, Deep Agents, OpenCode, Pi와 동일한 HarnessAgent 세션 흐름에 합류했습니다. 당시 지원 목록은 6개 하네스로 늘었습니다.

2026년 8월 31일부터는 Vercel의 fx 추가로 지원 목록이 9개 하네스까지 확대됐습니다. Claude Code, Cline, Codex, Cursor, Deep Agents, fx, Grok Build, OpenCode, Pi가 그 대상입니다. fx 어댑터는 선택지를 넓혔을 뿐, Grok Build 어댑터의 작동 방식을 바꾸지는 않습니다.

여기서 중요한 표현은 “같은 에이전트”가 아니라 “같은 인터페이스”입니다. 애플리케이션 계약은 유지할 수 있지만, 지원되는 9개 하네스의 툴 동작, 권한, 관측 가능성, 모델 출력까지 동일해지는 것은 아닙니다.

이 어댑터가 중요한 이유

달라진 것은 통합에 드는 작업 부담입니다.

HarnessAgent.generate()와 HarnessAgent.stream()은 AI SDK 호환 결과를 반환합니다. 제품에 이미 AI SDK 기반 채팅 또는 작업 인터페이스가 있다면, Grok Build도 기존 결과 흐름에 연결할 수 있습니다. 서버 측 하네스만 교체하면 되므로, 작업자가 바뀌었다고 해서 사용자 인터페이스에 새 응답 형식을 추가할 필요는 없습니다.

플랫폼 팀은 이 구조로 여러 런타임을 더 깔끔하게 비교하거나 작업별로 적합한 런타임을 선택할 수 있습니다. 공통 세션 수명 주기와 스트림 형식은 그대로 유지하면서 작업 성격에 맞는 하네스를 고르면 됩니다.

이번 출시가 Grok Build를 더 빠르거나 저렴하거나 정확하게 만드는 것은 아닙니다. 추가된 것은 공식 지원 연결 경로입니다. Grok Build 자체 CLI만 사용하는 경우에도 별다른 이점이 없습니다. 이 어댑터는 AI 코딩 에이전트를 기반으로 제품이나 내부 시스템을 구축하는 팀을 위한 도구입니다.

누가 당장 활용할 수 있나

런타임을 하나 더 추가하려는 개발자 도구 창업자

AI SDK 기반의 AI 코드 리뷰 또는 저장소 복구 제품을 판매한다고 가정해 보겠습니다. Grok Build를 위한 별도의 세션 API와 스트리밍 계약을 만들지 않고도, 이를 서버 측 하네스 선택지로 추가할 수 있습니다.

실제 변경은 간단합니다. 어댑터를 설치하고, 같은 유형의 샌드박스를 연결한 뒤, 고객이나 작업에 필요할 때 Grok Build를 선택하면 됩니다. 별도의 제품 접점을 유지·관리할 필요 없이 런타임 선택지를 하나 더 확보할 수 있습니다.

9개 하네스를 비교하는 플랫폼 엔지니어

플랫폼 팀은 범위가 제한된 동일한 저장소 작업을 Grok Build와 다른 지원 하네스에 각각 실행한 뒤, 하나의 애플리케이션 흐름에서 완료 품질과 실패 양상을 비교할 수 있습니다.

다만 비교 기준은 정확해야 합니다. ACP version 1은 단계별 사용량을 항상 제공하지 않으므로, Grok이 총사용량을 반환하지 않으면 이 어댑터로 토큰 단위 비용을 깔끔하게 비교할 수 없습니다. 결과와 전체 실행 과정은 비교할 수 있지만, 모든 관측 필드가 똑같이 완전하다고 가정해서는 안 됩니다.

저장소를 복구하는 내부 도구 팀

내부 도구 팀은 실패한 테스트를 고치는 작업을 격리된 워크스페이스로 보내고, 에이전트가 생성하는 텍스트를 운영자에게 스트리밍한 뒤, 작업이 끝나면 세션을 폐기할 수 있습니다. 샌드박스 경계가 호스트를 보호하고, 명시적인 수명 주기 관리가 임시 세션이 방치된 인프라로 남는 일을 막습니다.

핵심 이점은 운영 통제력입니다. 코드를 수정하는 작업자는 제한된 환경에서 실행되고, 애플리케이션이 그 환경의 시작과 종료 시점을 직접 관리합니다.

출시를 검토하는 보안·안정성 책임자

이 역할에는 실제로 결정해야 할 사항이 있습니다. 직접 인증은 XAI_API_KEY를 사용하고, AI Gateway 인증은 Gateway 자격 증명을 사용합니다. 기본 auto 모드는 해당 자격 증명이 있으면 AI Gateway를, 그렇지 않으면 직접 xAI 인증을 선택합니다.

또한 실제 툴 경계에서 권한을 테스트해야 합니다. Grok Build는 ACP 세션 모드를 기능으로 공개하지 않으며, 안전한 일부 내장 작업은 ACP 권한 요청 없이 실행될 수 있습니다. 다른 하네스를 기준으로 작성한 정책만으로 Grok Build도 똑같이 동작한다고 단정할 수는 없습니다.

Grok Build용 Vercel AI SDK 어댑터 공식 실행 경로

문서대로 최소 구성으로 시작하려면 Vercel Sandbox와 어댑터 기본 설정을 사용하면 됩니다.

1. 1

   패키지 설치

   공통 하네스 API, Grok Build 어댑터, Vercel Sandbox 구현체를 추가합니다.

   pnpm add @ai-sdk/harness @ai-sdk/harness-grok-build @ai-sdk/sandbox-vercel

2. 2

   샌드박스와 모델 자격 증명 설정

   문서에 나온 Vercel Sandbox 경로를 사용하려면 VERCEL_OIDC_TOKEN을 제공해야 합니다. Grok 직접 인증에는 XAI_API_KEY를 사용합니다. Gateway 경로에는 해당 AI Gateway 자격 증명을 제공하며, 기본 URL을 재정의해야 할 때는 AI_GATEWAY_BASE_URL을 사용할 수 있습니다. 어댑터의 기본 auth: 'auto' 설정이 사용 가능한 경로를 선택합니다.

3. 3

   세션 생성, 실행, 폐기

   현재 Grok Build 하네스 예제를 그대로 따라 실행합니다.

   import { HarnessAgent } from '@ai-sdk/harness/agent';
   import { grokBuild } from '@ai-sdk/harness-grok-build';
   import { createVercelSandbox } from '@ai-sdk/sandbox-vercel';
   
   const agent = new HarnessAgent({
     harness: grokBuild,
     model: 'grok-build-0.1',
     sandbox: createVercelSandbox({
       runtime: 'node24',
       ports: [4000],
     }),
   });
   
   const session = await agent.createSession();
   
   let exitCode = 0;
   try {
     const result = await agent.stream({
       session,
       prompt: 'Check the test failures and fix the production code.',
     });
   
     for await (const part of result.stream) {
       if (part.type === 'text-delta') {
         process.stdout.write(part.text);
       }
     }
   } catch (err) {
     exitCode = 1;
     console.error(err);
   } finally {
     await session.destroy();
     process.exit(exitCode);
   }

4. 4

   첫 세션의 네트워크 설치 대비

   ACP 하네스가 고정된 @xai-official/grok@1.0.5 패키지를 샌드박스 내부에 설치하므로 첫 세션에는 외부 네트워크 접근이 필요합니다. 외부 통신이 차단된 샌드박스라면 에이전트가 유용한 작업을 시작하기도 전에 실패합니다.

놓치기 쉬운 세부 사항은 포트입니다. Grok Build에는 ACP 브리지를 위해 최소 1개의 포트가 노출된 네트워크 샌드박스가 필요합니다. 예제는 Node 24와 포트 4000을 사용합니다. 이 네트워크 경로가 없는 샌드박스 객체는 동등한 설정이 아닙니다.

현재 예제는 model: 'grok-build-0.1'을 HarnessAgent에 전달합니다. 어댑터 수준에서 제어해야 한다면 grokBuild 대신 createGrokBuild()를 사용하십시오. 인증 방식, 자격 증명 전달, 추론 강도, MCP 서버, 브리지 포트, 시작 타임아웃, 사용자 정의 브리지 토큰 함수를 선택할 수 있습니다. reasoningEffort를 생략하면 Grok Build에 설정된 기본값을 사용합니다.

운영 전에 알아야 할 현실적인 한계

이 어댑터는 ACP version 1의 한계를 그대로 물려받으며, 프로덕션에서는 이를 가볍게 볼 수 없습니다.

• 사용량 정보가 불완전합니다. ACP는 모델 단계의 경계나 단계별 사용량을 노출하지 않습니다. 어댑터는 경계를 추론하며, Grok이 총사용량을 제공하지 않으면 사용량을 알 수 없음으로 보고합니다.
• 실행 중인 턴을 공통 방식으로 조정할 수 없습니다. ACP에는 하네스 전반에 공통으로 적용되는 턴 중간 조정이나 수동 압축 API가 없습니다.
• 내장 툴 필터링에 제약이 있습니다. 호스트 툴은 필터링할 수 있지만, Grok 내장 툴에 필터를 적용하려 하면 지원되지 않는 기능이라는 오류가 발생합니다.
• 툴 목록이 오래된 상태로 남을 수 있습니다. 호스트 툴 목록이 바뀌면 Grok Build가 ACP MCP 목록을 새로 불러와야 합니다. 이전 목록을 계속 사용하면 해당 턴은 명시적으로 실패합니다.

릴리스 관리 측면의 위험도 있습니다. AI SDK의 하네스 패키지는 실험 단계이므로 릴리스 사이에 호환성을 깨는 변경이 발생할 수 있습니다. Grok 어댑터는 CLI와 ACP 시작 명령을 내부적으로 고정하며, createGrokBuild()로도 이를 재정의할 수 없습니다. 공식 지원 경로는 단순해지지만, 고정된 런타임의 변경 시점은 어댑터 패키지가 결정하게 됩니다.

기본 브리지 자격 증명은 무작위 32-byte 토큰입니다. 토큰 함수를 교체한다면 새 함수 역시 제대로 보호된 비밀값을 반환해야 합니다. 이는 보안 통제 장치이지, 읽기 쉬운 개발용 문자열을 넣는 편의 기능이 아닙니다.

마지막으로 이번 출시는 가격 정책 변경이 아닙니다. Grok 인증 경로와 네트워크 샌드박스에는 여전히 각각의 운영 비용이 발생합니다. 어댑터는 맞춤형 통합 작업을 줄일 뿐, 그 아래의 인프라를 없애지는 않습니다.

지금 무엇을 해야 하는가

이미 AI SDK 7을 사용하고 있고 Grok Build를 선택 가능한 코딩 런타임으로 추가하려면 이번 주부터 도입 검토를 시작하십시오. 범위가 제한된 저장소 작업으로 시작하고, 기본 어댑터를 유지한 채 성공 및 실패 경로를 모두 테스트하며, 세션이 제대로 정리되는지 확인해야 합니다.

제품 뒤에 여러 하네스를 연결해야 한다면 프로덕션 도입 전에 짧게 평가하십시오. 작업 결과, 권한 동작, 실패 복구, 전체 작업 비용을 비교해야 합니다. ACP가 단계별 사용량을 제공하지 않을 수 있으므로 이를 결정 기준으로 삼아서는 안 됩니다.

수동 압축, 턴 중간 조정, 정확한 단계별 계량, 내장 툴 허용 목록이 필수라면 기다리는 편이 낫습니다. 이는 설정 오류가 아니라 프로토콜 자체의 한계입니다.

Grok Build를 직접 사용하거나, 코딩 하네스 없이 Grok 모델을 호출하거나, 애플리케이션에서 에이전트 런타임을 전환할 필요가 없다면 이번 변화의 영향은 없습니다.

팀의 제품 출시 방식을 바꾸는 도구에 관한 실전 해설을 더 받아보고 싶다면 뉴스레터를 구독하십시오.