들어가며: 왜 이 통합이 화제인가
LLM 기반 에이전트를 실서비스에 올리려고 하면 늘 같은 벽에 부딪혀요. "에이전트 루프는 누가 돌리지?", "세션 상태는 어디에 저장하지?", "코드 실행은 어디서 시키지?" 이 세 가지를 각각 직접 구현하다 보면 인프라 코드가 본 로직보다 커지는 상황이 생기죠.
이번에 Vercel이 공개한 OpenAI Agents API + Vercel Sandbox 통합은 이 세 가지를 역할 분담으로 정리한 사례예요.
- OpenAI: 에이전트 루프와 세션 상태 관리
- Vercel: 애플리케이션 호스팅 + 세션별 샌드박스 연결
- Vercel Sandbox: 코드 실행 및 파일 접근을 위한 격리 환경
핵심은 **"always-on 워커가 필요 없다"**는 점이에요. 세션이 없으면 0으로 내려가고, 요청이 오면 다시 뜨는 구조라 개인 프로젝트나 사이드 프로젝트에서도 부담 없이 굴릴 수 있습니다.
근거자료: Vercel Changelog - Build with OpenAI Agents API on Vercel
국내에서도 최근 사내 챗봇이나 업무 자동화 에이전트를 붙이는 시도가 많은데, "무한정 떠 있는 워커 비용"이 늘 걸림돌이었죠. 이 아키텍처는 그 지점을 정면으로 건드립니다.
아키텍처 해부: 무엇이 어디로 나뉘었나
1. 에이전트 루프와 세션 상태 (OpenAI 담당)
기존에는 에이전트의 tool-calling 루프를 서버에서 직접 돌리고, 대화 상태를 Redis나 DB에 저장했어요. 이번 통합에서는 이 부분을 OpenAI가 관리합니다. 개발자는 "어떤 툴을 쓸 수 있는지"만 정의하면 되고, 반복 호출·상태 유지·재시도는 플랫폼이 처리하는 구조예요.
2. 샌드박스 생성과 재연결 (Vercel 담당)
여기가 실무적으로 가장 흥미로운 부분입니다.
- signed OpenAI webhook: OpenAI가 세션 이벤트를 Vercel로 안전하게 전달
- Vercel Queues: 이벤트를 큐에 쌓아 안정적으로 처리 (유실/중복 방지)
- Vercel Sandbox: 세션마다 격리된 실행 환경을 띄움
// 예시: 에이전트 세션에서 샌드박스로 코드 실행 요청을 넘기는 흐름 (개념 설명용)
import { Sandbox } from "@vercel/sandbox";
export async function handleAgentToolCall(sessionId: string, code: string) {
// 세션 ID 기준으로 샌드박스 생성 또는 재연결
const sandbox = await Sandbox.create({ id: sessionId });
// 격리된 환경에서 코드 실행
const result = await sandbox.run(code);
// 후속 지시에서도 동일 파일 유지 (persistent workspace)
return result.stdout;
}
3. Persistent Workspace
샌드박스가 세션 단위로 유지되기 때문에, 사용자가 "아까 만든 파일에 이어서 작업해줘"라고 하면 이전 산출물이 그대로 살아 있어요. 이건 데이터 분석 에이전트나 리팩터링 에이전트를 만들 때 체감이 큰 부분입니다.
4. Scale-to-Zero
세션이 없으면 워커가 0으로 내려가요. 즉, 트래픽이 뜸한 개인 봇이나 사내 도구에서도 고정 비용이 거의 발생하지 않는 구조입니다.
장단점 비교: 언제 쓰고 언제 피해야 하나
| 항목 | OpenAI Agents API + Vercel Sandbox | 직접 구현 (자체 워커 + Redis + 컨테이너) |
|---|---|---|
| 에이전트 루프 | 플랫폼 관리 | 직접 구현 및 유지보수 |
| 세션 상태 | OpenAI 관리 | Redis/DB 직접 설계 |
| 코드 실행 격리 | Vercel Sandbox 기본 제공 | Firecracker/gVisor 등 직접 구성 |
| 비용 구조 | Scale-to-zero, 사용량 기반 | always-on 워커 비용 발생 |
| 벤더 종속성 | OpenAI + Vercel 양쪽에 결합 | 상대적으로 자유로움 |
| 커스터마이징 | 플랫폼 제약 내에서만 | 무한 자유 |
| 적합한 팀 | 빠르게 프로토타입~실서비스 전환 | 인프라 팀이 있는 대규모 조직 |
주의사항 (비판적 시각)
- 벤더 락인: 에이전트 루프가 OpenAI에, 실행이 Vercel에 묶여요. 나중에 다른 LLM으로 갈아타거나 온프레미스로 옮길 때 재작업이 필요할 수 있습니다.
- 관찰 가능성(Observability): 루프가 블랙박스에 가까워지면 디버깅이 어려워져요. 로그·트레이스 설계를 처음부터 잡아두는 게 좋습니다.
- 보안 경계: 샌드박스가 격리돼 있다고 해도, 에이전트가 접근 가능한 파일/네트워크 범위는 명시적으로 제한해야 해요.
다음 단계 학습 방향
- Vercel Sandbox의 격리 모델(파일시스템, 네트워크 정책) 문서를 먼저 읽어보세요.
- OpenAI Agents API의 tool 정의 스키마를 익히면, 지금 쓰는 사내 봇에 얹기 쉬워요.
- 관찰 가능성 도구(OpenTelemetry 등)와의 결합 방법을 미리 실험해두면 실서비스 전환이 편합니다.
정리: 지금 시도해볼 만한 이유
이번 통합의 진짜 가치는 "에이전트 인프라를 직접 만들지 않아도 된다"는 선언에 가까워요. 특히 사이드 프로젝트나 소규모 팀에서는 이 차이가 결정적입니다.
다만 프로덕션에 바로 넣기 전에, 벤더 종속성과 관찰 가능성 두 축은 반드시 점검하세요. 이 두 가지가 나중에 발목을 잡는 경우가 정말 많습니다.
함께 보면 좋은 글
에이전트 UX를 설계할 때도 결국 "모달로 띄울까, 별도 화면으로 뺄까" 같은 결정을 계속 하게 되는데, 위 글과 같이 보면 관점이 잡힐 거예요.