Open Agents : Vercel의 자율 에이전트 SDK

최근 AI 코딩 에이전트는 빠르게 늘어났지만, 실무에서 써보면 금방 한계가 드러납니다. 로컬에서 터미널을 켜 두고 지켜봐야 하고, 중간에 끊기면 다시 상태를 맞춰야 하며, 긴 작업은 요청-응답 수명 안에 가두기 어렵기 때문입니다. (GitHub)

Open Agents는 이 문제를 “에이전트를 오래 실행되게 만드는 방법”의 관점에서 다시 설계한 프로젝트입니다. 웹 UI, 워크플로우 기반의 에이전트 실행, 샌드박스 VM, 그리고 GitHub 연동을 한 구조로 묶어, 프롬프트에서 코드 변경과 푸시, PR 생성까지 이어지는 흐름을 만들었습니다. (GitHub)

이 글을 끝까지 읽으면 세 가지가 분명해집니다. 왜 기존 AI 코딩 에이전트가 실무에서 피로했는지, Open Agents가 그 문제를 어떤 아키텍처로 풀었는지, 그리고 이것이 단순한 데모가 아니라 기업용 AI 소프트웨어 팩토리의 뼈대로 왜 주목받는지입니다. (GitHub)

에이전트는 샌드박스와 워크플로우 기능을 활용해 시간 제한이나 타임아웃 없이 수많은 에이전트를 동시에 띄울 수 있고, 수 시간 동안 알아서 작업을 수행하며, 완료되면 깃허브에 코드를 저장하고 푸시까지 끝마칩니다.

open-agents/README.md at main · vercel-labs/open-agents

 

왜 이 문제가 중요한가

AI 코딩 에이전트를 실제 개발 흐름에 넣으려면, 단순히 “코드를 잘 쓰는 모델”만으로는 부족합니다. 중요한 것은 긴 작업을 끊기지 않게 이어가고, 작업 상태를 보존하고, 결과를 실제 저장소 작업으로 연결하는 실행 구조입니다. (GitHub)

기존 방식은 비용 문제부터 드러납니다. 에이전트가 한 번의 대화 요청 안에서 모든 것을 처리하려고 하면, 컨텍스트를 계속 크게 들고 가야 하고, 실패했을 때 같은 맥락을 다시 불러오며 불필요한 모델 호출이 늘어납니다. 긴 작업일수록 이 비용은 더 커집니다. 이런 문제는 최근 에이전트 설계 논의에서도 반복해서 지적됩니다. (GitHub)

성능 문제도 큽니다. 요청 하나에 에이전트 실행을 몰아넣으면, 네트워크 지연이나 세션 종료, 브라우저 연결 해제 같은 외부 요인에 전체 실행이 흔들립니다. 작업이 길어질수록 “모델이 못해서”가 아니라 “실행 구조가 버티지 못해서” 실패하는 경우가 많아집니다. (GitHub)

유지보수 측면에서는 더 복잡합니다. 에이전트, 파일시스템, 셸 실행, Git 작업, 미리보기 서버가 한 덩어리처럼 얽히면 어디서 문제가 났는지 분리해서 보기 어렵습니다. 구조가 커질수록 디버깅 포인트도 늘어나고, 특정 모델이나 특정 실행 환경에 묶이는 순간 교체 비용도 커집니다. (GitHub)

개발 경험도 좋지 않습니다. 터미널을 계속 켜 두고 진행 상황을 지켜봐야 하고, 멈추면 수동으로 복구해야 하며, 여러 작업을 동시에 돌리기도 어렵습니다. 결국 “에이전트가 알아서 일한다”기보다 “사람이 에이전트를 계속 감시한다”에 가까워집니다. Open Agents는 바로 이 불편을 구조적으로 줄이려는 시도입니다. (GitHub)

Open Agents란 무엇인가

Open Agents는 백그라운드에서 오래 실행되는 코딩 에이전트를 만들기 위한 오픈소스 레퍼런스 앱입니다. 더 정확히 말하면, 웹 UI와 에이전트 런타임, 워크플로우, 샌드박스, GitHub 연동을 한 번에 묶어 놓은 “구조 예제”에 가깝습니다. (GitHub)

쉽게 비유하면 이렇습니다. 기존 방식이 “노트북 안에서 직접 일하는 1인 개발자”라면, Open Agents는 “지시를 받으면 별도 작업실로 가서 일하고, 끝나면 저장소에 반영까지 하고 돌아오는 비동기 팀원”에 가깝습니다.

기술적으로 중요한 정의는 따로 있습니다. 이 프로젝트는 에이전트를 샌드박스 안에 넣지 않습니다. 에이전트는 샌드박스 바깥에서 워크플로우로 실행되고, 샌드박스는 파일시스템·셸·Git·개발 서버를 제공하는 실행 환경으로 남습니다. 즉, “에이전트의 제어 평면”과 “코드가 실제로 돌아가는 실행 평면”을 분리한 구조입니다. (GitHub)

이 점이 기존 방식과 가장 다릅니다. 보통은 VM 안에서 에이전트가 직접 모든 걸 처리하게 만들기 쉽습니다. 하지만 Open Agents는 에이전트 수명주기와 샌드박스 수명주기를 분리해, 워크플로우는 오래 살아남고, 샌드박스는 필요할 때 깨우고 쉬게 만드는 철학을 택했습니다. 모델이나 제공자 교체도 이 분리 덕분에 상대적으로 쉬워집니다. (GitHub)

핵심 특징

• 웹 → 워크플로우 → 샌드박스의 3계층 구조
  UI, 제어 로직, 실행 환경을 분리했습니다. 그래서 화면이 끊겨도 작업 상태와 실행 흐름을 독립적으로 이어가기 좋습니다. (GitHub)
• 에이전트가 요청 안에서 즉시 끝나지 않는 내구성 있는 실행
  채팅 요청이 에이전트를 인라인으로 돌리는 것이 아니라 워크플로우 실행을 시작합니다. 각 턴이 여러 지속 단계로 이어질 수 있어 긴 작업에 유리합니다. (GitHub)
• 샌드박스 스냅샷 기반 재개
  샌드박스는 스냅샷 기반으로 재개할 수 있고, 비활성 시 하이버네이트됩니다. 긴 작업을 전부 새로 시작하지 않고 상태를 이어가기 좋은 설계입니다. (GitHub)
• GitHub 저장소 작업 자동화
  저장소 클론, 브랜치 작업, 선택적 자동 커밋, 푸시, PR 생성까지 지원합니다. 즉 “코드를 제안하는 도구”를 넘어 “저장소 변경까지 연결되는 도구”로 확장됩니다. (GitHub)
• 모델·제공자와 실행 환경의 결합도 축소
  공식 설명에서도 모델/프로바이더 선택과 샌드박스 구현을 따로 진화시킬 수 있다고 밝힙니다. 특정 모델 종속을 줄이려는 팀에게 중요한 포인트입니다. (GitHub)
• 포크해서 바꾸는 것을 전제로 한 레퍼런스 앱
  이 저장소는 블랙박스로 쓰라고 만든 것이 아니라, 포크하고 내부 프로세스에 맞게 바꾸라고 만든 구조입니다. 기업이 자체 AI 개발 자동화 체계를 구축할 때 특히 의미가 있습니다. (GitHub)

실제로 어떤 효과가 있는가

공개된 자료 기준으로 보면, Open Agents의 가장 큰 효과는 “사람이 에이전트 실행을 계속 붙들고 있지 않아도 된다”는 점입니다. 작업 요청은 워크플로우로 넘어가고, 실제 파일 조작과 셸 실행은 샌드박스에서 처리되며, 완료 후에는 GitHub 반영까지 이어질 수 있습니다. (GitHub)

전과 후를 비교하면 차이가 분명합니다. 전에는 로컬 터미널 세션 중심으로 에이전트를 돌리며, 세션 유지와 상태 감시를 사람이 맡았습니다. 이후에는 웹 UI에서 작업을 던지고, 지속 가능한 워크플로우가 상태를 이어가며, 샌드박스가 실제 실행을 담당합니다. 인간은 실행자가 아니라 감독자에 가까워집니다. (GitHub)

효과가 가장 큰 상황도 뚜렷합니다. 코드 수정이 한두 파일에 그치지 않고, 저장소 전체 검색·셸 명령·브랜치 작업·미리보기 확인 같은 다단계 흐름이 필요한 경우입니다. 특히 “오래 걸리는 작업을 요청 수명주기에서 떼어내고 싶다”는 팀에서 체감이 큽니다. (GitHub)

어떤 팀에 특히 유리한지도 명확합니다. 내부 도구 팀, 플랫폼 엔지니어링 팀, AI 코딩 자동화 실험을 하는 조직, 여러 모델을 바꿔가며 자체 프로세스에 맞는 에이전트를 만들려는 기업에 잘 맞습니다. 단순 챗봇이 아니라 “AI 소프트웨어 팩토리”의 실행 계층을 직접 만들려는 조직일수록 가치가 커집니다. 이는 최근 Vercel이 강조하는 에이전트 인프라 방향성과도 맞닿아 있습니다. (Vercel)

다만 공개된 자료에는 “몇 배 빠르다” 같은 범용 정량 수치가 중심으로 제시되지는 않습니다. 그래서 이 도구의 가치는 벤치마크 숫자보다, 긴 실행·상태 보존·샌드박스 격리·GitHub 연계라는 운영 구조에서 판단하는 편이 더 정확합니다. (GitHub)

동작 원리 / 구조

1. 사용자가 웹 UI에서 작업을 요청합니다.
   이 계층은 인증, 세션, 채팅, 스트리밍 UI를 담당합니다. 중요한 점은 여기서 모든 일을 끝내지 않는다는 것입니다. 화면은 입력과 상태 표시를 맡고, 실제 장기 실행은 아래 계층으로 넘깁니다. (GitHub)
2. 요청은 에이전트 워크플로우 실행으로 변환됩니다.
   채팅 요청이 곧바로 에이전트 실행 본체가 되는 것이 아니라, 워크플로우 런이 시작됩니다. 이 설계 덕분에 실행은 단일 HTTP 요청에 묶이지 않고, 여러 지속 단계로 이어질 수 있습니다. (GitHub)
3. 에이전트는 샌드박스 바깥에서 도구를 통해 샌드박스를 조작합니다.
   파일 읽기, 수정, 검색, 셸 명령 같은 도구 호출을 통해 샌드박스와 상호작용합니다. 이때 샌드박스는 실행 환경일 뿐, 에이전트의 제어 평면이 아닙니다. 그래서 둘의 책임이 섞이지 않습니다. (GitHub)
4. 샌드박스는 실제 코드 작업을 수행합니다.
   파일시스템, 셸, Git, 개발 서버, 프리뷰 포트를 제공하고, 필요 시 하이버네이트 후 재개합니다. 이 구조는 “실행 중인 작업 공간”을 에이전트 논리와 분리해 재사용하고 관리하기 쉽게 만듭니다. (GitHub)
5. 완료 후 결과를 저장소 흐름으로 연결합니다.
   저장소 클론, 브랜치 작업, 자동 커밋, 푸시, PR 생성은 선택적으로 이어질 수 있습니다. 즉, 결과가 채팅 응답으로만 끝나지 않고 실제 코드 변경 이력으로 남습니다. (GitHub)
6. 사용자는 다시 접속해 기존 실행을 이어서 볼 수 있습니다.
   활성 실행은 기존 워크플로우 스트림에 다시 연결해 재개할 수 있습니다. 이것이 “에이전트를 오래 돌리는 구조”에서 매우 중요합니다. 브라우저 세션이나 탭 상태가 작업의 생존 조건이 아니기 때문입니다. (GitHub)

이 구조가 중요한 이유는 분명합니다. 에이전트는 판단과 제어를 맡고, 샌드박스는 실행과 격리를 맡으며, 웹은 상호작용을 맡습니다. 이 세 층이 섞이지 않아야 장기 실행, 장애 복구, 모델 교체, 운영 정책 분리가 쉬워집니다. Open Agents의 핵심은 기능보다 이 분리 원칙에 있습니다. (GitHub)

설치 / 사용 방법

현재 공개된 저장소 기준으로 로컬 실행 흐름은 비교적 단순합니다. 다만 “그냥 바로 실행되는 예제”라기보다, 데이터베이스와 시크릿, 인증 연동을 이해하고 설정해야 하는 레퍼런스 앱에 가깝습니다. 최소 런타임에는 PostgreSQL 연결 문자열과 JWE 시크릿이 필요하고, 실제 로그인 사용에는 추가 환경 변수가 필요합니다. (GitHub)

설치 명령어

git clone <open-agents 저장소>
cd open-agents
bun install
cp apps/web/.env.example apps/web/.env

최소 실행 흐름

# apps/web/.env에 필수 값 입력
POSTGRES_URL=...
JWE_SECRET=...

# 필요 시 로그인/연동 관련 값 추가
ENCRYPTION_KEY=...
NEXT_PUBLIC_VERCEL_APP_CLIENT_ID=...
VERCEL_APP_CLIENT_SECRET=...

# 실행
bun run web

로컬 개발에서 GitHub 저장소 접근, 푸시, PR 생성까지 사용하려면 GitHub App 관련 값도 추가로 필요합니다. 즉, 설치 자체보다 “권한과 연동을 어떻게 설계할 것인가”가 더 중요한 프로젝트입니다. (GitHub)

자주 쓰는 명령

bun run web
bun run check
bun run typecheck
bun run ci
bun run sandbox:snapshot-base

저장소 구조

apps/web         # Next.js 앱, 워크플로우, 인증, 채팅 UI
packages/agent   # 에이전트 구현, 도구, 서브에이전트, 스킬
packages/sandbox # 샌드박스 추상화와 Vercel Sandbox 연동
packages/shared  # 공통 유틸리티

이 구조만 봐도 의도가 드러납니다. UI, 에이전트 로직, 샌드박스 추상화가 나뉘어 있어서, 팀이 특정 부분만 교체하거나 내부 정책에 맞게 확장하기 좋습니다. (GitHub)

자주 쓰는 예시 / 활용 시나리오

1. 코드베이스 분석 자동화

플랫폼 팀이나 시니어 개발자가 대형 저장소를 한 번에 파악해야 할 때 유용합니다. 에이전트가 검색, 파일 읽기, 셸 실행을 이어가며 구조를 조사하고, 결과를 변경안이나 작업 브랜치로 연결할 수 있습니다. (GitHub)

2. 장시간 리팩터링 작업

여러 파일에 걸친 타입 수정, API 마이그레이션, 폴더 구조 정리처럼 오래 걸리는 작업에서 가치가 큽니다. 로컬 터미널 세션보다 워크플로우 기반 지속 실행이 유리하기 때문입니다. (GitHub)

3. 내부 개발 자동화 파이프라인

기업이 코드 생성, 수정, 검증, 커밋, PR 생성까지 하나의 자동 흐름으로 묶고 싶을 때 좋은 출발점이 됩니다. 특히 사내 정책에 맞춘 인증, 권한, 승인 흐름을 덧붙여 자체 플랫폼으로 확장하기 좋습니다. (GitHub)

4. 모델 비종속형 에이전트 플랫폼 실험

특정 모델 하나에 종속되지 않고, 모델 제공자나 실행 인프라를 바꿔가며 아키텍처를 검증하려는 팀에 적합합니다. 이 프로젝트는 저장소 자체가 그런 분리를 염두에 두고 설계되어 있습니다. (GitHub)

5. AI 소프트웨어 팩토리의 뼈대 구축

단순히 “채팅으로 코드 생성”을 넘어서, 요청 접수부터 작업 공간 준비, 실행, 결과 반영, 저장소 기록까지 이어지는 시스템을 만들고 싶다면 좋은 토대가 됩니다. 특히 여러 에이전트를 역할별로 나누는 구조로 확장하기 쉽습니다. (GitHub)

한계 / 주의할 점

첫째, 이것은 완제품보다 레퍼런스 앱에 가깝습니다. 문서상 확인되는 범위에서, 저장소도 블랙박스로 쓰기보다 포크해서 바꾸는 방식을 전제로 합니다. 즉, 바로 도입해 끝나는 제품이 아니라 내부 요구사항에 맞춰 조정해야 하는 베이스입니다. (GitHub)

둘째, Vercel 중심의 인프라 전제를 이해해야 합니다. 워크플로우, 샌드박스, OAuth, GitHub App, 데이터베이스 설정이 함께 맞물립니다. 그래서 단순히 로컬에서 에이전트를 하나 돌려보는 수준보다, 운영 환경을 설계하는 역량이 더 중요합니다. 현재 기준으로는 개인 취미 프로젝트보다 플랫폼 성격의 팀 프로젝트에 더 잘 맞습니다. (GitHub)

셋째, “모든 코딩 업무를 완전 자동화한다”는 식으로 이해하면 곤란합니다. 자동 커밋, 푸시, PR 생성은 지원되지만 항상 켜지는 강제 동작이 아니라 선택적 기능입니다. 결국 중요한 것은 자동화의 범위를 팀 정책에 맞게 제한하는 일입니다. (GitHub)

넷째, 아직 검증 범위를 과장해서 보면 안 됩니다. 공개된 자료 기준으로는 구조와 실행 방식은 분명하지만, 모든 산업군과 모든 개발 문화에서 동일하게 잘 맞는다고 보기는 어렵습니다. 승인 체계가 강한 조직, 보안 규제가 엄격한 조직, 레거시 저장소가 복잡한 조직은 추가 설계가 필요합니다. (GitHub)

다섯째, “샌드박스가 있으니 안전하다”는 단순한 해석도 위험합니다. 샌드박스는 격리된 실행 환경이지만, 실제 운영에서는 권한 범위, 비밀값 관리, GitHub App 권한, 리뷰 프로세스 설계가 함께 필요합니다. 도구보다 운영 정책이 더 중요해지는 구간입니다. (GitHub)

마무리

Open Agents의 핵심 가치는 AI 코딩 에이전트를 더 똑똑하게 만드는 데만 있지 않습니다. 더 중요한 것은 에이전트를 오래 실행되고, 상태를 이어가고, 실제 저장소 작업으로 연결되는 구조로 바꿨다는 점입니다. (GitHub)

그래서 이 프로젝트는 “AI가 코드를 써준다”는 데모보다 한 단계 더 현실적입니다. 사람의 노트북과 터미널에 묶여 있던 에이전트를, 워크플로우와 샌드박스 위에서 관리 가능한 시스템으로 끌어올리기 때문입니다. (GitHub)

특히 스타트업의 내부 플랫폼 팀, AI 에이전트 개발자, 대규모 코드베이스를 운영하는 조직, 그리고 특정 모델에 종속되지 않는 자체 AI 소프트웨어 팩토리를 고민하는 팀에게 유용합니다. 반대로 단순한 코드 생성 챗봇만 필요하다면, 이 구조는 다소 무겁게 느껴질 수 있습니다. (GitHub)

핵심 요약

• 핵심 개념
  Open Agents는 웹 UI, 내구성 있는 워크플로우 실행, 샌드박스 VM, GitHub 연동을 결합한 백그라운드 코딩 에이전트 레퍼런스 앱입니다. (GitHub)
• 차별점
  에이전트를 샌드박스 안에 넣지 않고, 워크플로우와 샌드박스를 분리해 장기 실행·상태 보존·모델 비종속성·실행 환경 교체 가능성을 확보한 점이 핵심입니다. (GitHub)
• 언제 쓰면 좋은지
  장시간 코딩 작업, 저장소 단위 자동화, 브랜치/PR까지 이어지는 개발 흐름, 기업 내부 AI 소프트웨어 팩토리 구축을 고민할 때 특히 좋습니다. (GitHub)
• 언제 쓰면 안 되는지
  단순한 로컬 코드 생성 보조, 가벼운 개인 실험, 인프라와 권한 설계를 감당하기 어려운 팀에는 과할 수 있습니다. (GitHub)
• 한 줄 요약
  Open Agents는 AI 코딩 에이전트를 “터미널에서 잠깐 돌리는 도구”에서 “오래 실행되고 저장소까지 책임지는 시스템”으로 바꾸는 오픈소스 구조입니다. (GitHub)