AI SDK 7 HarnessAgent: 코딩 에이전트도 이제 교체 가능한 런타임이 된다

테크

AI 앱 개발에서 지난 몇 년간 가장 익숙한 추상화는 “모델을 바꿔도 코드는 크게 바꾸지 않는다”였다. OpenAI에서 Anthropic으로, 다시 사내 게이트웨이로 옮겨도 호출부가 버티도록 만드는 일이 핵심이었다. 그런데 코딩 에이전트가 실제 파일을 고치고, 터미널을 실행하고, 샌드박스 안에서 오래 작업하기 시작하면 추상화의 중심이 모델 호출만으로는 부족해진다.

2026년 6월 12일 Vercel은 AI SDK 7의 HarnessAgent를 공개했다. Claude Code, Codex, Pi 같은 코딩 에이전트 하네스를 하나의 API 뒤에서 실행하려는 실험적 기능이다. 이 발표가 중요한 이유는 “어떤 모델을 쓸까”보다 “어떤 실행 하네스에 권한과 상태를 맡길까”가 개발 플랫폼의 결정 포인트가 되고 있음을 보여주기 때문이다.

HarnessAgent architecture diagram showing product code, AI SDK HarnessAgent, harness adapters, sandbox, tools, permissions, sessions, and verification
HarnessAgent는 모델 호출보다 위에 있는 하네스 계층, 즉 세션·권한·샌드박스·도구·검증 경계를 통합 API로 다루려는 흐름을 보여준다.

무슨 일이 있었나

Vercel changelog에 따르면 AI SDK 7은 @ai-sdk/harness/agent의 HarnessAgent를 통해 Claude Code, Codex, Pi의 초기 하네스 어댑터를 제공한다. Vercel은 하네스가 모델 호출 위의 구성 요소, 예를 들면 skills, sandboxes, sessions, permission flows, compaction, runtime configuration, sub-agents를 관리한다고 설명한다. 즉 이 기능은 “LLM provider abstraction”이 아니라 “agent runtime abstraction”에 가깝다.

AI SDK 자체는 이미 TypeScript 생태계에서 provider-agnostic 도구 호출, 스트리밍, UI 통합을 제공해 왔다. 이번 변화는 그 위에 놓인 코딩 에이전트 실행 환경까지 SDK의 설계 대상으로 끌어오는 방향이다. 아직 canary/experimental 성격이 강하므로 곧바로 표준화해야 한다는 신호는 아니지만, 팀이 어떤 인터페이스를 사내 개발 플랫폼의 경계로 삼을지 논의할 충분한 계기다.

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

코딩 에이전트는 단순한 챗봇보다 더 넓은 권한을 요구한다. 저장소를 읽고, 파일을 수정하고, 패키지를 설치하고, 테스트를 돌리고, 때로는 브라우저나 배포 플랫폼까지 만진다. 이런 작업을 여러 제품 팀에 배포하려면 “사용자가 어떤 에이전트를 선호하느냐”보다 “조직이 어떤 실행 정책을 보장할 수 있느냐”가 더 중요해진다.

HarnessAgent식 추상화가 성숙하면 제품 코드는 특정 하네스의 세부 이벤트 형식에 덜 묶일 수 있다. 예를 들어 내부 도구는 동일한 승인 UI, 감사 로그, 작업 큐, 결과 검증 파이프라인을 유지하면서 Claude Code와 Codex를 다른 백엔드 런타임처럼 교체할 수 있다. 물론 실제 호환성은 각 하네스 어댑터가 어디까지 기능을 노출하느냐에 달려 있다.

결정 지점모델 추상화하네스 추상화
교체 대상OpenAI, Anthropic, Google 등 모델 제공자Claude Code, Codex, Pi 같은 코딩 에이전트 실행 환경
주요 관심사입출력 스키마, 스트리밍, 비용, latency세션, 파일시스템, 터미널, 권한 승인, 샌드박스, 컨텍스트 압축
운영 리스크모델별 응답 품질과 비용 변동에이전트가 실제 변경을 수행할 때의 보안·감사·복구 경계
검증 방식프롬프트/평가셋/응답 샘플테스트 실행, diff 리뷰, secret scan, dependency check, 정책 로그

커뮤니티 신호

이번 발표 전에도 개발자 커뮤니티에서는 AI SDK 위에 Claude Code 스타일의 agent harness를 만들려는 시도가 나타났다. Vercel Community의 OpenHarness 토론은 AGENTS.md, agent skills, MCP servers, subagents, session handling을 하나의 composable SDK로 묶으려는 요구가 이미 있었다는 신호다. 이 글에서는 그 토론을 사실 출처가 아니라 관심사의 방향을 보여주는 커뮤니티 신호로만 본다.

동시에 GitHub 쪽 흐름도 비슷하다. Copilot cloud/local sandboxes 발표는 에이전트가 명령 실행과 파일 변경을 수행할수록 격리와 정책이 기반 인프라가 된다는 메시지를 담고 있다. VS Code enterprise-managed plugins preview 역시 MCP configuration, hooks, custom agents를 조직 단위로 배포·강제하는 방향을 보여준다. 서로 다른 회사의 발표지만, 공통점은 “에이전트 기능”보다 “에이전트 운영면”이 앞으로의 경쟁력이 된다는 점이다.

개발·운영 영향

첫째, 내부 개발 플랫폼은 에이전트를 단일 제품 기능이 아니라 실행 런타임으로 취급해야 한다. 작업 생성, 권한 승인, 로그 수집, 재시도, 중단, 결과 검증이 별도 도메인 객체가 되어야 한다. 둘째, 하네스를 바꿀 가능성을 고려하면 이벤트 스키마와 UI 상태를 특정 벤더의 원시 stream에 직접 묶는 방식은 피하는 편이 낫다.

셋째, 보안팀과 플랫폼팀의 역할이 커진다. “어떤 모델을 허용할까”만으로는 충분하지 않다. 어떤 repo에서 어떤 명령을 실행할 수 있는지, 네트워크 접근은 어디까지인지, secret이 발견되면 에이전트가 자동 수정할 수 있는지, 사람 리뷰 전에 무엇을 차단할지까지 정책으로 내려와야 한다.

실무 체크리스트

• 하네스 교체 가능성을 전제로 내부 API를 설계한다. runAgentTask, streamAgentEvents, approveToolCall처럼 제품 도메인 언어로 감싼다.

• 파일 변경, 터미널 실행, 네트워크 접근, 외부 배포 권한을 각각 별도 permission으로 나눈다.

• 샌드박스 기본값을 먼저 정한다. 로컬 실행, 클라우드 실행, 네트워크 제한, 영속 볼륨 사용 여부를 작업 유형별로 분리한다.

• 에이전트가 만든 PR에는 테스트 결과, dependency 변화, secret scan, CodeQL 또는 동등한 정적 분석 결과를 요구한다.

• 비용과 품질 평가는 모델뿐 아니라 하네스 단위로 본다. 같은 모델이라도 하네스의 context management와 tool policy가 결과를 바꿀 수 있다.

• experimental/canary API는 제품 핵심 경로에 바로 고정하지 말고 adapter layer 뒤에서 파일럿한다.

리스크와 반론

가장 큰 리스크는 추상화가 너무 일찍 굳는 것이다. 코딩 에이전트 하네스는 아직 표준 이벤트 모델, permission semantics, sandbox capability가 빠르게 바뀌는 영역이다. 지금 HarnessAgent를 도입한다면 “장기 표준”이라기보다 “팀의 요구사항을 검증하는 실험 인터페이스”로 보는 편이 안전하다.

또 하나의 반론은 하네스마다 강점이 너무 다르다는 점이다. 어떤 하네스는 IDE 통합이 강하고, 어떤 하네스는 장시간 비동기 작업이나 cloud sandbox가 강하다. 모든 차이를 공통 API로 덮으면 가장 낮은 공통분모만 남을 수 있다. 따라서 핵심 경로는 공통화하되, 특정 하네스의 고유 기능은 capability flag나 optional extension으로 노출하는 설계가 현실적이다.

지금 할 일

오늘 당장 대규모 마이그레이션을 시작할 필요는 없다. 대신 사내 에이전트 도입 문서를 업데이트해 “모델”, “하네스”, “샌드박스”, “권한”, “검증”을 분리해서 기록하자. 작은 내부 도구 하나를 골라 HarnessAgent나 유사 adapter layer 뒤에서 실험하면, 앞으로 특정 에이전트가 바뀌어도 제품 코드와 운영 정책을 덜 흔들 수 있다.

요약하면 AI SDK 7의 HarnessAgent는 아직 실험적이지만 방향은 선명하다. AI 개발 도구의 다음 추상화 계층은 모델이 아니라, 모델 위에서 실제 작업을 실행하는 하네스다. 개발팀은 이제 “어떤 에이전트를 쓸까”보다 “에이전트 실행을 어떤 운영 계약으로 감쌀까”를 먼저 물어야 한다.

출처

다른 글