플랫폼 아키텍처
Vercel 위에서 엔터프라이즈 AI 제품의 제어면과 실행면을 어떻게 분리할지 정리합니다.
핵심 요약
- 사용자 응답·모델 정책·장기 실행·툴 실행·거버넌스를 App/Control/Execution/Governance 계층으로 분리해 각 레이어의 실패 반경을 작게 유지합니다.
- 앱 서버 하나에 모델 호출·장기 작업·툴 실행·승인 흐름을 모두 욱여넣는 것이 불안정의 가장 흔한 원인입니다.
- 10초 넘게 길어질 요청은 Workflow로, 파일·코드·셸 실행은 Sandbox로 옮기는 것이 기본값입니다.
- 모델 전환 논의 전에 Gateway 기준 key·project·budget 태깅을 먼저 고정합니다.
- Next.js 16.2는 dev 시작 ~400% 가속·Server Fast Refresh·SRI를 제공하며, 16.2 계열 운영 기준선은 CVE-2026-23869가 패치된 16.2.3 이상입니다.
엔터프라이즈 AI 제품이 불안정해지는 가장 흔한 이유는 앱 서버 하나에 모델 호출, 장기 작업, 툴 실행, 승인 흐름을 모두 욱여넣기 때문입니다.
Vercel 조합의 강점은 이 책임들을 레이어별로 나눠 각 레이어의 실패 반경을 작게 유지한다는 데 있습니다.
Next.js 16.2 — Experience Plane 강화
Next.js 16.2.0(2026-03-18)은 Experience Plane의 개발과 운영 양쪽을 크게 끌어올렸습니다. 16.2 계열 운영 기준선은 보안 패치를 포함한 16.2.3 이상으로 둡니다.
| 기능 | 운영 영향 |
|---|---|
| ~400% 빠른 dev 시작 | 로컬 개발 피드백 루프 단축 |
| Server Fast Refresh | 서버 컴포넌트 변경 시 전체 리로드 없이 반영 |
| Strict Route Types | 라우트 간 타입 안전성 강화, 런타임 오류 사전 차단 |
| 에이전트 DevTools (next-browser) | AI 에이전트가 브라우저를 시각적으로 검사할 수 있는 디버깅 도구 |
| AGENTS.md in create-next-app | 새 프로젝트에 에이전트 지침 파일이 기본 포함 |
| next-devtools-mcp | DevTools를 MCP 서버로 노출해 AI 에이전트가 개발 환경을 직접 조작 |
| Subresource Integrity (SRI) | 스크립트 무결성 검증으로 공급망 공격 방어 |
16.2.x 운영 기준
2026년 4월 공개된 React Server Components DoS 취약점(CVE-2026-23869)은 Next.js 16.2.3에서 패치되었습니다. 16.2 계열을 운영 중이라면 16.2.3 이상을 기준선으로 두세요.
CDN as Universal Proxy
Vercel은 모든 앱 앞에 CDN을 Universal Proxy로 두는 방향을 확립했습니다. 엔터프라이즈 아키텍처에서는 다음을 뜻합니다.
| 측면 | 영향 |
|---|---|
| 캐싱 | 정적/동적 응답 모두 CDN 레이어에서 일관된 캐싱 전략 적용 |
| 보안 | WAF, BotID, DDoS 방어가 CDN에서 통합 처리 |
| 라우팅 | 앱, API, AI Gateway 트래픽이 하나의 진입점으로 통합 |
| 관측성 | 엣지 레이어에서 요청 메트릭 수집 가능 |
계층 분리 원칙
| 계층 | 배치 대상 | 핵심 질문 | 기본 선택 |
|---|---|---|---|
| App Layer | Next.js Route Handler, Server Action, Edge/UI | 사용자 요청을 어떻게 받고 응답을 스트리밍할 것인가 | AI SDK로 thin runtime 유지 |
| Model Control Layer | Gateway | 어떤 모델을 어떤 정책으로 호출할 것인가 | Gateway에 라우팅 정책 집중 |
| Orchestration Layer | Workflow | 30초 이상 걸리는 작업을 어떻게 지속할 것인가 | 재시도/재개 가능한 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 유지 |
아키텍처 체크리스트
- 사용자-facing 요청이 10초 넘게 길어질 수 있으면 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 | 운영과 감사 체계 확립 |