플랫폼 아키텍처
Vercel 위에서 엔터프라이즈 AI 제품의 제어면과 실행면을 어떻게 분리할지 정리합니다.
핵심 요약
- 사용자 응답·모델 정책·장기 실행·툴 실행·거버넌스를 App/Control/Execution/Governance 계층으로 분리해 각 레이어의 실패 반경을 작게 유지합니다.
- 앱 서버 하나에 모델 호출·장기 작업·툴 실행·승인 흐름을 모두 욱여넣는 것이 불안정의 가장 흔한 원인입니다.
- 승인·이벤트 대기·재개가 필요한 작업은 Workflow로, untrusted 파일·코드·셸 실행은 Sandbox로 분리합니다.
- 모델 전환 논의 전에 Gateway 기준 key·project·budget 태깅을 먼저 고정합니다.
- 프레임워크는 승인된 최신 patch와 설치 버전의 문서를 기준으로 검증하며 16.2의 과거 최소 patch를 현재 보안 기준선으로 쓰지 않습니다.
현재 실행 계약: Node.js·Fluid Compute
Vercel의 신규 Node.js 프로젝트 기본 major는 24.x, 지원 목록은 24.x·22.x입니다. streaming·SSE는 기본 Node.js runtime에서 사용할 수 있습니다. Edge 전용으로 설계하지 않으며 Next.js 16.3+의 route·page는 runtime = 'edge'를 지원하지 않습니다.
| 항목 | Fluid Compute 기준 |
|---|---|
| 함수 시간 | 기본 300초; Hobby 최대 300초; Pro·Enterprise 일반 최대 800초 |
| 긴 실행 | Pro·Enterprise의 1,800초 확장은 Beta·별도 요건 확인 |
| 큰 번들 | 5 GB 지원은 Beta·opt-in 조건 확인; 일반 기본 한도와 구분 |
| 요청·응답 body | 4.5 MB; 큰 업로드는 직접 Blob upload 경로 등으로 분리 |
| Workflow 선택 | 승인·이벤트 대기·장애 후 재개·step retry 필요 여부로 결정 |
“10초 넘으면 Workflow 필수”라는 임의 규칙을 적용하지 않습니다. 한 요청 안에서 끝나는 streaming과 영속화가 필요한 orchestration을 요구사항으로 나눕니다. 함수 최대 시간을 늘리는 것만으로 승인 대기·중복 side effect·복구가 해결되지는 않습니다.
Node.js versions · Edge→Node.js · Functions limits.
엔터프라이즈 AI 제품이 불안정해지는 가장 흔한 이유는 앱 서버 하나에 모델 호출, 장기 작업, 툴 실행, 승인 흐름을 모두 욱여넣기 때문입니다.
Vercel 조합의 강점은 이 책임들을 레이어별로 나눠 각 레이어의 실패 반경을 작게 유지한다는 데 있습니다.
Next.js 16.2 — Experience Plane 강화
2026-10-23 npm latest는 Next.js 16.4.2입니다. 이 저장소의 설치 버전과 새 프로젝트·다른 제품의 버전을 혼동하지 않습니다. 실제 앱은 migration guide·호환 React·회귀 결과를 함께 검토합니다.
| 기능 | 현재 운영 기준 |
|---|---|
| 버전별 로컬 문서 | node_modules/next/dist/docs/에서 설치 버전의 API 확인 |
| 관리 agent 지침 | 16.3+의 AGENTS.md 관리 구간 유지 |
| 런타임 관측 | 실행 중인 dev server·MCP·브라우저 상태를 함께 검증 |
| Runtime | 16.3+ route·page는 Node.js; Edge 설정 제거 검토 |
| 보안 업데이트 | 지원 중인 release line의 최신 보안 공지·patch를 확인 |
Next.js AI agents · Upgrading.
CDN as Universal Proxy
Vercel은 모든 앱 앞에 CDN을 Universal Proxy로 두는 방향을 확립했습니다. 엔터프라이즈 아키텍처에서는 다음을 뜻합니다.
| 측면 | 영향 |
|---|---|
| 캐싱 | 정적/동적 응답 모두 CDN 레이어에서 일관된 캐싱 전략 적용 |
| 보안 | WAF, BotID, DDoS 방어가 CDN에서 통합 처리 |
| 라우팅 | 앱, API, AI Gateway 트래픽이 하나의 진입점으로 통합 |
| 관측성 | 엣지 레이어에서 요청 메트릭 수집 가능 |
계층 분리 원칙
| 계층 | 배치 대상 | 핵심 질문 | 기본 선택 |
|---|---|---|---|
| App Layer | Next.js Route Handler, Server Action, UI | 사용자 요청을 어떻게 받고 응답을 스트리밍할 것인가 | AI SDK로 thin runtime 유지 |
| Model Control Layer | Gateway | 어떤 모델을 어떤 정책으로 호출할 것인가 | Gateway에 라우팅 정책 집중 |
| Orchestration Layer | Workflow | 재개·대기·재시도가 필요한 작업을 어떻게 지속할 것인가 | 재시도/재개 가능한 step 단위 |
| Tool Execution Layer | Sandbox | 툴이 시스템에 어떤 권한으로 접근하는가 | untrusted 실행은 격리 |
| Governance Layer | Observability, Security | 누가 무엇을 호출했고 비용/리스크는 얼마인가 | trace + key + project로 추적 |
권장 구성
왜 이렇게 나누는가
| 구성 요소 | 분리 이유 | 앱 서버에 넣었을 때의 문제 |
|---|---|---|
| AI Gateway | 모델 정책, usage, provider abstraction을 중앙화 | 서비스별로 모델 string과 key 정책이 흩어짐 |
| Workflow | sleep, wait, external event, approval 등 durable 실행 | request timeout, 상태 복구 난이도 상승 |
| Sandbox | 파일/쉘/코드 실행 격리 | prompt injection이 인프라 침해로 확장 |
| Observability | 앱/모델/작업 trace 통합 | 장애 원인 추적이 계층별로 끊김 |
실무 해석
Vercel의 제품 구분은 기능을 쪼개는 게 아니라 실패 반경을 쪼개는 쪽에 가깝습니다. 엔터프라이즈 설계에서 진짜 질문은 "무엇을 더 넣을까"가 아니라 "어디에서 실패를 멈출까"입니다.
멀티테넌시와 환경 경계
| 구분 | 권장 경계 | 이유 |
|---|---|---|
| 개발/스테이징/프로덕션 | Project 또는 Environment 분리 | 모델 정책과 secret 노출 경계 분리 |
| 내부 운영자와 일반 사용자 | API key / auth scope 분리 | 감사와 비용 분리 |
| 고객 테넌트 | 애플리케이션 계층 tenant context + Gateway usage tagging | 고객별 비용/품질 분석 가능 |
| 고위험 툴 | Sandbox template 분리 | 최소 권한과 network allowlist 유지 |
아키텍처 체크리스트
- 승인·이벤트 대기·장애 후 재개가 필요한 요청을 Workflow로 분리합니다.
- 파일·코드·브라우저·셸이 등장하면 Sandbox를 기본값으로 둡니다.
- 모델 전환을 논의하기 전에 Gateway 기준 key, project, budget 태깅부터 고정합니다.
- 승인이나 외부 이벤트가 끼면 request/response가 아니라 workflow state machine으로 모델링합니다.
ADR 스타일 결론
Decision
사용자 응답, 모델 정책, 장기 실행, 툴 실행, 거버넌스를 서로 다른 계층으로 분리합니다. 앱 서버는 진입점만 담당하고, 장시간 실행과 고위험 실행은 별도 런타임으로 이동합니다.
실무 체크리스트
- App layer에 workflow state를 직접 저장하지 않았는가
- Gateway를 거치지 않는 모델 호출이 남아 있지 않은가
- Sandbox 없이 실행되는 code/file/shell tool이 없는가
- project, tenant, operator 경계가 로그와 비용 태그에 반영되는가
추천 구현 순서
| 단계 | 구현 | 목적 |
|---|---|---|
| 1 | AI SDK + Gateway | 모델 호출과 애플리케이션 로직 분리 |
| 2 | Workflow | 긴 작업과 승인 흐름 분리 |
| 3 | Sandbox | 툴 실행 피해 반경 축소 |
| 4 | Observability / Security | 운영과 감사 체계 확립 |