- Published on
Vercel Open Agents: 클라우드 코딩 에이전트가 제품 런타임이 되는 순간
- Authors
- Name
- Kyunghyun Park
- @devkhpark
Vercel Open Agents · Cloud Coding Agents · AI SDK · Sandbox · Workflow SDK
Vercel Labs의 Open Agents는 "코딩 에이전트를 웹앱으로 감싼 예제" 정도로 보면 핵심을 놓친다. 이 프로젝트가 흥미로운 이유는 모델 성능이 아니라 코딩 에이전트를 클라우드 제품으로 운영하기 위한 런타임 경계를 꽤 선명하게 보여주기 때문이다.
2026년 5월 8일 기준 GitHub Trending에서도 vercel-labs/open-agents는 다시 강하게 보였다. GitHub API 기준 저장소 설명은 "An open source template for building cloud agents"이고, 토픽도 agent, agents, ai, background-agents로 잡혀 있다. 단순 샘플 앱이 아니라 background coding agent를 Vercel 위에서 어떻게 배포 가능한 제품으로 만들 것인가에 대한 레퍼런스라는 뜻이다.
이 글은 Open Agents README, 공식 데모 사이트, Vercel의 Sandbox/Workflow/AI SDK 문서를 함께 읽고, 한국 개발자와 빌더 입장에서 이 프로젝트가 왜 중요한지 정리한 것이다.
검색 의도: 사람들은 "코딩 에이전트"보다 "어디서 돌릴 것인가"를 묻기 시작했다
요즘 AI 코딩 도구 검색 의도는 예전과 조금 다르다. 예전에는 "Cursor vs Claude Code", "Codex CLI 사용법", "AI가 코드를 얼마나 잘 짜나" 같은 모델/도구 중심 질문이 많았다. 이제는 다음 질문이 늘어난다.
- 코딩 에이전트를 내 노트북이 아니라 클라우드에서 계속 돌릴 수 있나?
- 사용자가 브라우저에서 요청하면 백그라운드 에이전트가 브랜치를 만들고 PR까지 올릴 수 있나?
- sandbox, workflow, GitHub App, 비용 추적, diff 캐시, 권한 관리를 어디에 둘 것인가?
- 사내 도구나 고객용 SaaS 안에 코딩 에이전트를 넣으려면 어떤 구조가 필요한가?
Open Agents가 잡은 키워드는 바로 여기다. "AI coding agent"라는 기능 키워드보다 cloud coding agent runtime이라는 운영 키워드에 더 가깝다.
Open Agents의 핵심 구조: Web → Agent Workflow → Sandbox VM
README는 Open Agents를 세 계층으로 설명한다.
Web -> Agent workflow -> Sandbox VM
- 웹 앱은 인증, 세션, 채팅, 스트리밍 UI를 담당한다.
- 에이전트는 Vercel의 durable workflow 위에서 실행된다.
- sandbox는 파일시스템, 셸, git, 개발 서버, preview port를 가진 실행 환경이다.
이 구성이 중요한 이유는 단순하다. 코딩 에이전트는 일반 챗봇보다 훨씬 오래 산다. 파일을 읽고, 코드를 고치고, 테스트를 돌리고, 실패하면 다시 수정하고, 브랜치를 만들고, 사용자가 재접속하면 진행 상태를 보여줘야 한다. 이 작업을 일반 HTTP request lifecycle 안에 억지로 넣으면 곧바로 문제가 생긴다.
Open Agents는 그래서 에이전트 루프를 웹 요청에서 떼어낸다. 사용자는 브라우저에서 프롬프트를 던지지만, 실제 실행은 durable workflow로 이어지고, 코드는 별도의 sandbox에서 바뀐다. UI, 제어 루프, 실행 환경을 분리한 것이다.
가장 중요한 설계 결정: 에이전트는 sandbox 안에서 돌지 않는다
README에서 가장 눈에 띄는 문장은 이것이다. The agent is not the sandbox.
에이전트가 VM 안에서 직접 돌아가는 것이 아니라, VM 밖의 제어 평면에서 실행되고 sandbox에는 도구 호출을 통해 접근한다. 파일 읽기, 수정, 검색, 셸 명령, git 조작 같은 행위가 tool boundary를 통해 들어간다.
이 분리가 실무적으로 주는 장점은 크다.
1) 요청 수명과 작업 수명이 달라진다
코딩 에이전트 작업은 몇 초짜리 응답이 아니다. bun run typecheck가 길어질 수 있고, dependency 설치가 필요할 수 있고, 테스트 실패 후 재시도가 반복될 수 있다. 에이전트가 request에 묶여 있으면 중간 실패와 재접속 처리가 지저분해진다.
Workflow 기반으로 빼면 작업 수명은 더 길게 설계할 수 있다. 사용자가 탭을 닫아도 루프는 이어지고, 다시 접속했을 때 상태를 읽을 수 있다.
2) sandbox는 실행 환경으로만 남는다
VM은 파일시스템, 네트워크, 런타임, preview port를 가진 실행 박스다. 여기에 에이전트 제어 로직까지 넣으면 배포, 관측, 모델 교체, 권한 분리가 어려워진다.
Open Agents 방식에서는 sandbox가 "코드가 실제로 바뀌는 곳"이고, 에이전트는 "무엇을 할지 결정하는 제어 평면"이다. 이 경계가 명확할수록 제품화가 쉬워진다.
3) 모델과 실행 인프라를 따로 바꿀 수 있다
공식 데모 사이트는 AI SDK, AI Gateway, Sandbox, Workflow SDK를 기반 프리미티브로 내세운다. 이 조합의 의미는 모델 공급자, 라우팅, fallback, sandbox 구현, workflow orchestration을 한 덩어리로 묶지 않는다는 데 있다.
모델이 바뀌어도 sandbox가 꼭 바뀔 필요는 없다. sandbox 수명 정책이 바뀌어도 UI와 agent loop 전체를 다시 짜지 않아도 된다. 이것이 데모와 제품 런타임의 차이다.
현재 기능을 보면 "에이전트 앱"보다 "운영 템플릿"에 가깝다
Open Agents README의 current capabilities는 꽤 실무적이다.
- file, search, shell, task, skill, web tool을 가진 chat-driven coding agent
- Workflow SDK 기반의 durable multi-step execution, streaming, cancellation
- snapshot-based resume를 지원하는 isolated Vercel sandbox
- sandbox 내부 repo cloning과 branch 작업
- 성공 후 auto-commit, push, PR creation
- read-only link 기반 세션 공유
- ElevenLabs transcription을 통한 선택적 voice input
이 목록에서 중요한 것은 모델 이름이 아니다. 실제 제품에서 필요한 주변 장치가 이미 열거돼 있다는 점이다. 특히 auto-commit, push, PR creation은 에이전트가 "답변"에서 끝나지 않고 소프트웨어 변경의 라이프사이클에 들어간다는 신호다.
데모 사이트도 같은 방향을 보여준다. "Agents that ship real code"라는 문구 아래에서 file ops, search, shell, task delegation, explorer/executor subagents, AI Gateway 기반 multi-model support를 강조한다. 또 "Cloud sandboxes, not local machines" 섹션에서는 세션마다 격리된 Vercel sandbox와 branch를 갖고, 자동 hibernate와 restore, snapshot/restore를 제공한다고 설명한다.
Vercel 입장에서 보면 이것은 AI Cloud의 조립 예제다
Open Agents를 Vercel의 더 큰 제품 맥락에서 보면 더 선명해진다. Vercel docs의 AI SDK 페이지는 AI Cloud 메뉴 안에서 AI Gateway, Sandbox, Vercel Agent, AI SDK, v0를 같이 배치한다. Workflow와 Fluid Compute 같은 core platform primitives도 같은 내비게이션 안에 있다.
즉 Open Agents는 우연히 Vercel에서 돌아가는 오픈소스 앱이 아니라, Vercel이 밀고 있는 AI Cloud 구성요소를 실제 coding agent 제품 형태로 조립한 reference app에 가깝다.
이 포지션은 꽤 영리하다. Vercel은 모델 회사가 아니다. 하지만 AI 앱이 늘어날수록 사람들이 필요로 하는 것은 모델 하나보다 모델 호출 주변의 배포/격리/관측/수명주기 인프라다. Open Agents는 그 지점을 정확히 건드린다.
한국 개발자에게 실무적으로 중요한 체크리스트
Open Agents를 그대로 쓰든, 내부 제품의 레퍼런스로 삼든, 아래 질문은 반드시 봐야 한다.
1) 사용자 인증과 GitHub 권한은 어디까지 줄 것인가
README의 Deploy with Vercel 버튼이 요구하는 환경변수를 보면 NEXT_PUBLIC_VERCEL_APP_CLIENT_ID, VERCEL_APP_CLIENT_SECRET, GitHub OAuth client, GitHub App ID, private key, webhook secret 등이 나온다. 이것은 단순 API key 하나 넣는 앱이 아니다.
코딩 에이전트가 repo를 clone하고 branch를 만들고 push/PR까지 하려면 권한 설계가 제품의 핵심이 된다. 개인용 toy app은 넓은 권한으로도 돌아가지만, 팀용 SaaS나 사내 도구에서는 repo scope, org policy, audit log, webhook 검증이 필수다.
2) sandbox 비용과 수명 정책을 제품 UX로 다뤄야 한다
데모 사이트는 sandbox cost를 분 단위로 보여주는 UI를 암시한다. 이것은 장식이 아니다. 코딩 에이전트는 테스트와 빌드를 반복하기 때문에 토큰 비용뿐 아니라 compute 비용도 쌓인다.
따라서 cloud agent 제품은 "모델 호출 비용"만 보면 안 된다. sandbox provisioning, idle hibernate, snapshot restore, preview server 유지, dependency cache 전략까지 비용 모델에 들어가야 한다.
3) 실패한 작업의 재개와 취소가 기본 기능이어야 한다
Workflow SDK 기반 durable execution, streaming, cancellation은 Open Agents의 핵심 capability로 적혀 있다. 코딩 에이전트는 실패한다. 타입체크가 깨지고, 테스트가 flaky하고, 의존성 설치가 막히고, 외부 API가 실패한다.
실무 제품에서는 실패 자체보다 실패 후 UX가 중요하다. 사용자가 어디서 멈췄는지 보고, 로그를 확인하고, 프롬프트로 방향을 바꾸고, 필요한 경우 취소할 수 있어야 한다. 이 부분이 없으면 에이전트는 "가끔 신기한 데모"에서 벗어나기 어렵다.
4) 자동 커밋은 편하지만 위험하다
Open Agents는 성공한 run 이후 auto-commit, push, PR creation을 capability로 제시한다. 이것은 생산성을 크게 올리지만, 동시에 품질 게이트가 필요하다는 뜻이다.
최소한 다음이 있어야 한다.
- 빌드/테스트 통과 여부
- 변경 파일 범위 확인
- secret 유출 검사
- PR description과 재현 가능한 로그
- 사람이 review할 수 있는 diff cache
에이전트가 코드를 바꿀 수 있다는 것은, 에이전트가 실수도 commit할 수 있다는 뜻이다. 운영자는 자동화를 좋아하되, merge 권한까지 쉽게 넘기면 안 된다.
Open Agents가 잘 보여주는 시장 방향
Open Agents의 의미는 "Vercel이 코딩 에이전트를 만들었다"가 아니다. 더 중요한 메시지는 이것이다.
코딩 에이전트 경쟁은 모델 UI에서 끝나지 않고, 이제 cloud runtime, sandbox lifecycle, workflow durability, GitHub integration, observability 경쟁으로 내려가고 있다.
이 방향은 이미 여러 곳에서 보인다. 로컬 CLI 에이전트는 빠르게 좋아지고 있지만, 팀/제품 환경에서는 로컬 노트북이 병목이 된다. 반대로 완전 관리형 SaaS는 편하지만 내부 정책과 repo 권한, 비용 통제에 맞추기 어렵다. 그래서 중간 지대가 필요하다. Open Agents 같은 오픈소스 reference app은 그 중간 지대를 공략한다.
개발자 입장에서 이 프로젝트는 "그대로 배포하면 끝"이라기보다, 자기 조직의 에이전트 운영 모델을 설계할 때 참고할 skeleton으로 보는 편이 맞다.
실전 적용 판단: 언제 써볼 만한가
Open Agents 류의 구조는 모든 팀에 필요하지 않다. 작은 개인 프로젝트라면 Claude Code, Codex CLI, Cursor 같은 로컬/IDE 도구가 훨씬 빠르다. 하지만 아래 조건이라면 검토할 가치가 있다.
- 여러 사용자가 브라우저에서 agent session을 만들고 공유해야 한다.
- repo 변경을 자동으로 branch/PR 흐름에 태워야 한다.
- 장시간 실행, 재시도, 취소, 재접속이 중요하다.
- sandbox 격리와 권한 통제가 로컬 실행보다 중요하다.
- 사내 플랫폼이나 고객용 제품 안에 coding agent 기능을 넣고 싶다.
반대로 모델 품질만 실험하고 싶다면 너무 무겁다. Open Agents는 prompt playground가 아니라 운영 템플릿이다.
한 줄 결론
Vercel Open Agents는 코딩 에이전트의 다음 경쟁 지점이 "얼마나 똑똑한가"에서 "어디서, 얼마나 오래, 얼마나 안전하게 실행되는가"로 이동하고 있음을 보여준다. 한국 개발자와 빌더에게 중요한 포인트도 여기에 있다. 이제 AI 코딩 도구를 제품에 넣으려면 모델 선택만이 아니라 workflow, sandbox, 권한, 비용, PR 라이프사이클까지 포함한 런타임 설계를 봐야 한다.