하루 100번 배포하는 10명의 팀, Vercel로 백엔드까지 올린 Delphi의 실전기

왜 이 사례를 주목해야 할까요?

Delphi는 창업 엔지니어 Spencer Schoeben을 포함해 10명의 엔지니어로 구성된 팀인데, 인프라 전담 인력이 한 명도 없어요. 그런데도 제품·디자인 직군까지 포함해 모두가 코드를 배포하고, 하루에 100회 이상 프로덕션 배포를 feature flag 뒤에서 돌립니다.

핵심은 "디지털 마인드"라는 새로운 카테고리를 개척하는 회사 특성상, 사용자 요구가 워낙 빠르게 바뀌어서 개발자 경험(DX)과 에이전트 경험(AX)이 곧 생존 조건이라는 점이에요. Spencer의 말을 빌리면 "승리하려면 뛰어난 개발자·에이전트 경험이 필요하고, 그렇지 않으면 사용자 요구 속도를 따라잡을 수 없다"고 합니다.

특히 눈여겨볼 부분은 6개월 전 Python 백엔드까지 Vercel로 이전했다는 것. 프론트는 원래부터 Vercel이었지만, 백엔드는 AWS ECS·Docker Desktop·로컬 DB 조합이라 "악몽" 수준이었다고 해요. 이 글에서는 그 전환에서 얻을 수 있는 실무 교훈을 정리해볼게요.

근거자료: Vercel 공식 블로그 - How Delphi ships 100 times a day

문제는 '인프라 소유'였다

초기에는 팀이 작아서 AWS 기반 셋업이 그럭저럭 돌아갔어요. 문제는 팀이 커지면서 새 엔지니어가 첫 배포까지 가는 데 꼬박 하루가 걸린다는 점이었습니다. 컨텍스트가 사람 머릿속에만 있으니 온보딩이 느려질 수밖에 없죠.

AWS 안에서 이 문제를 고칠 수도 있었지만, 그러려면 인프라를 직접 설계하고 소유해야 했어요. Delphi는 **"인프라는 우리 회사의 목표가 아니다"**라고 선을 그었습니다. 그래서 선택한 게 백엔드의 Vercel 이전이에요. 결과적으로 새 엔지니어가 기존 팀과 동일한 배포 워크플로우로 바로 프로덕션까지 갈 수 있게 됐습니다.

Workflows와 Queues가 이전을 가능하게 했다

Delphi 백엔드는 장기 실행 작업과 큐 기반 백그라운드 잡에 의존해요. 디지털 마인드는 콘텐츠를 미리 생성하는 durable agent가 필요하고, 책·강연을 지식 그래프로 바꾸는 ingestion 파이프라인도 돌려야 하죠.

여기서 Vercel Workflows와 Queues가 결정적이었습니다. 둘 다 별도 셋업이 필요 없어요. 개발자가 코드베이스에 함수 하나로 워크플로우나 큐 핸들러를 작성하면, 배포 시점에 Vercel이 필요한 리소스를 알아서 프로비저닝합니다.

# 예시: Vercel Workflows로 장기 실행 ingestion 작업 정의
# (개념 설명용 의사 코드 - 실제 API는 공식 문서 참고)
from vercel.workflows import workflow, step

@workflow()
def ingest_knowledge_source(source_id: str):
    # 1단계: 원본 데이터 로드
    raw = load_source(source_id)
    # 2단계: 지식 그래프 변환 (오래 걸리는 작업)
    graph = build_knowledge_graph(raw)
    # 3단계: 벡터 인덱싱
    index_graph(graph)
    return {"status": "done", "source_id": source_id}

# 큐 핸들러도 함수 하나로 끝
from vercel.queues import queue_handler

@queue_handler("content-generation")
def generate_content(job):
    mind_id = job["mind_id"]
    draft = run_agent(mind_id)
    save_draft(mind_id, draft)

이 구조의 진짜 장점은 **"인프라를 거의 생각하지 않아도 된다"**는 거예요. Spencer의 표현을 그대로 옮기면 "Vercel에서는 인프라에 대해 거의 생각하지 않는다"고 합니다.

스테이징을 건너뛰고 바로 프로덕션으로

백엔드를 Vercel로 옮기면서 Delphi는 백엔드 변경을 **"무거운 릴리스"가 아닌 일상적인 제품 작업"**으로 재정의했어요. 예전엔 staging → production 순서였는데, 지금은 중간 단계를 생략하고 feature flag 뒤에서 하루 100회 이상 배포합니다. 변경을 릴리스 단위로 묶는 대신 A/B 테스트로 검증하는 방식이죠.

이 속도를 유지하려면 관측성이 필수인데, **Vercel Agent의 이상 탐지(anomaly detection)**가 프로덕션을 실시간으로 감시하며 뭔가 이상이 생기면 무엇이 왜 잘못됐는지 플래그를 세워줍니다. Spencer는 이전에는 몰랐을 문제도 많았다고 해요.

빠른 배포는 우선순위 목록에 오르지 못했던 작은 실험들을 처리하는 데도 도움이 됐습니다. 방문자를 "owner"(마인드와 대화하러 왔다가 자기 마인드를 만들고 가는 사람)로 전환하는 실험들이 대표적이에요. 배포는 엔지니어 전유물이 아니어서, CPO와 그로스 팀이 직접 대시보드·프로토타입·실험을 만들어 배포한다고 합니다. 예전 셋업에서는 상상도 못 했던 일이죠.

참고로 이런 '스테이징 생략 + feature flag + 관측성' 조합은 릴리스 자동화 대시보드 설계와도 맞닿아 있어요. 함께 보면 좋은 글: 스포티파이 앱 릴리스의 뒷모습 대시보드 설계와 자동화의 교훈

에이전트를 1등 시민으로 만드는 인프라

Delphi의 개발 방식에서 가장 흥미로운 부분은 **"로컬에서 거의 개발하지 않는다"**는 점이에요. 엔지니어는 문제를 클라우드 에이전트에게 넘기고, 에이전트가 뭘 만들었는지는 프리뷰 배포에서 처음 확인합니다.

Vercel 프리뷰 배포는 push마다 고유한 라이브 URL을 발급해요. 그래서 브랜치를 당기지 않고도 폰이나 Slack 스레드에서 결과를 바로 확인할 수 있죠. 이건 사람에게도 편리하지만, 에이전트의 자기 검증 루프를 가능하게 하는 핵심 장치예요.

Spencer의 표현이 인상적이에요. **"예전 인프라로는 AI 속도를 따라갈 수 없었다. 사람이 8시간 걸릴 일이면 에이전트는 포기했을 것"**이라고 합니다. 에이전트가 실패하는 이유는 대개 필요한 정보에 접근하지 못해서인데, Vercel은 SDK·MCP·CLI를 통해 로그 읽기, 배포 검사, 환경변수 변경 같은 제어권을 에이전트에 열어줍니다. 즉 플랫폼이 사람만큼 에이전트에게도 쉬워야 한다는 전제로 설계된 셈이죠.

Sandbox 위의 내부 에이전트

Delphi는 자체 에이전트도 Vercel에서 돌려요. 그중 하나가 Vercel Sandbox 위의 내부 에이전트로, 고객 성공(Customer Success) 팀이 Slack에서 문의하면 코드베이스를 뒤져 근본 원인과 수정 제안을 엔지니어에게 넘겨줍니다. 예전엔 엣지 케이스가 새기 일쑤였는데, 이제는 Slack에서 물어보면 되는 구조예요.

Sandbox는 파일 시스템을 갖춘 격리 환경을 제공해서, 에이전트가 코드베이스를 체크아웃하고 실행하며 필요한 데이터를 끌어올 수 있어요. 에이전트 프레임워크는 Vercel의 eve로 만들었는데, 첫 버전은 호스팅 에이전트 플랫폼이라 그 플랫폼이 제공하는 통합만 쓸 수 있었다고 합니다. eve에서는 도구가 곧 Delphi가 작성하는 코드라서, 없는 도구가 필요하면 팀이 직접 추가하면 됩니다.

AI Gateway로 마인드별 모델 선택

Delphi의 채팅 트래픽은 AI Gateway를 통과해요. 디지털 마인드마다 특성이 달라서 어떤 모델에서는 더 잘 나오는 경우가 있거든요. 그래서 고객별로 모델을 고르고, 자체 eval 결과에 따라 조정합니다. 새 모델이 나오면(오픈소스든 아니든) 당일 라우팅이 가능해요.

Gateway는 failover도 담당합니다. 예전엔 모델 제공사와 직접 다른 클라우드의 fallback 용량을 협의해야 해서 어려움이 많았는데, 지금은 "fallback이 존재한다면 반드시 받는다"는 확신이 생겼다고 해요.

주의할 점과 한계

이 사례를 그대로 일반화하기는 어려워요. 몇 가지 짚고 넘어갈 부분이 있습니다.

• 워크로드 적합성: Delphi는 장기 실행 에이전트·큐 기반 잡이 핵심이라 Vercel의 관리형 추상화가 잘 맞았어요. 하지만 커스텀 네트워킹, 특수 런타임, 규제상 인프라 소유가 필요한 경우엔 오히려 제약이 될 수 있습니다.
• 벤더 종속: Workflows·Queues·AI Gateway·Sandbox·eve까지 스택이 깊게 결합되면, 이전 비용은 낮아지지만 플랫폼 의존도는 높아져요. 추상화 경계를 코드 레벨에서 관리해두는 게 안전합니다.
• 관측성은 자동이 아니다: 이상 탐지가 도와주긴 하지만, 하루 100회 배포 환경에서는 feature flag 위생, 카나리 전략, 롤백 자동화를 팀 규율로 반드시 갖춰야 해요.
• 에이전트 보안: 에이전트가 로그·환경변수·배포에 접근한다는 건 권한 설계가 곧 보안 경계라는 뜻입니다. Sandbox 격리와 최소 권한 원칙을 초기부터 잡아야 합니다.

정리: "인프라를 안 소유한다"는 전략의 실체

Delphi 사례의 교훈은 단순히 "Vercel 쓰면 빨라진다"가 아니에요. 무엇을 소유하지 않을지 명확히 결정하고, 그 결정을 개발자 경험과 에이전트 경험이라는 두 축으로 검증했다는 점이 핵심입니다.

1. 온보딩 시간을 지표로 삼기: 신규 엔지니어 첫 배포까지 걸리는 시간은 조직 확장성의 선행 지표예요.
2. 스테이징을 관성적으로 유지하지 않기: feature flag와 관측성이 준비됐다면, 배치 릴리스보다 작은 실험의 연속이 더 빠를 수 있습니다.
3. 에이전트를 위해 플랫폼을 설계하기: 프리뷰 URL, CLI, MCP 같은 인터페이스가 에이전트의 자기 검증 루프를 만듭니다.
4. 모델은 고정 자산이 아니다: AI Gateway 같은 라우팅 계층을 두면 모델 교체 비용이 급감해요.

다음 단계 학습 방향

• Vercel Workflows / Queues 공식 문서로 durable execution 패턴을 직접 실습해보세요.
• Feature flag 기반 트렁크 개발과 카나리 배포 전략을 팀 워크플로우에 맞게 설계해보세요.
• MCP(Model Context Protocol) 를 활용해 사내 에이전트에 로그·배포 제어 권한을 안전하게 부여하는 방법을 공부해보세요.
• 에이전트 기반 개발로 넘어가는 흐름을 더 넓게 보고 싶다면, 함께 보면 좋은 글: Conductor, 확장에서 플러그인으로 진화 — Spec-Driven Development의 다음 단계 완전 정리

이 글은 Vercel 공식 블로그의 Delphi 사례를 바탕으로, 국내 개발 환경 관점의 해석과 주의사항을 더해 재구성했습니다.