Delphi는 Vercel 위에서 디지털 마인드를 구축하는 서비스입니다. 10명 규모의 팀이 Python 백엔드를 AWS에서 Vercel로 이전하고, 피처 플래그(feature flags)를 활용해 하루 100회 이상 배포하며, 전용 인프라 없이 지속형 에이전트와 큐, AI Gateway를 운영하는 방식을 소개합니다.
전담 인프라 담당자 없이 운영하는 10명 규모의 팀
프로덕트·디자인 팀도 직접 코드를 배포
피처 플래그 뒤에서 하루 100회 이상 프로덕션 배포
Delphi는 디지털 마인드를 구축하는 서비스입니다. 누군가가 쓰고, 녹음하고, 가르친 것들을 모아 누구든 그 전문 지식에 언제든 접근할 수 있게 합니다. 창립 엔지니어 Spencer Schoeben은 Delphi를 "흥미로운 마인드를 찾고 그들과 소통할 수 있는 공간"이라고 표현합니다.
디지털 마인드 네트워크는 전례 없는 시도인 만큼, Delphi는 기능을 출시하고 사용자 행동을 관찰하며 무엇을 만들어야 할지 파악합니다. 이런 방식은 제품을 빠르게 바꿀 수 있어야만 가능합니다. Spencer는 이렇게 말합니다. "우리가 이기려면 탁월한 개발자 경험과 에이전트 경험이 필요합니다. 그렇지 않으면 사용자 요구가 변하는 속도에 맞춰 적응할 수 없으니까요."
Delphi의 프론트엔드는 처음부터 Vercel 위에서 운영되었습니다. "프론트엔드는 언제나 쉬웠어요"라고 Spencer는 말합니다. "하지만 백엔드는 악몽이었습니다." 6개월 전, 팀은 Python 백엔드도 Vercel로 전환했습니다. 이제 팀 전체가 하루 100회 이상 프로덕션에 배포합니다.
Delphi의 백엔드는 이전에 ECS, Docker Desktop, 로컬 데이터베이스를 갖춘 AWS 환경에서 운영되었습니다. 초창기에는 팀 규모가 작고 많은 맥락이 사람들 머릿속에 있었기 때문에 이 구성이 잘 작동했습니다. Delphi가 성장하면서 온보딩은 팀이 원하는 것보다 훨씬 느려졌고, 새 엔지니어가 첫 번째 배포를 하려면 하루 종일 환경 설정에 시간을 써야 했습니다.
AWS를 떠나지 않고도 이 문제를 해결할 수는 있었습니다. 하지만 제대로 고치려면 인프라를 직접 설계하고 관리해야 했고, 팀은 인프라를 직접 운영하고 싶지 않았습니다. "그건 지금 우리 회사의 목표가 아닙니다"라고 Spencer는 말합니다. 백엔드를 Vercel로 옮긴 이후, 새 엔지니어들은 나머지 팀원들이 매일 사용하는 것과 동일한 배포 워크플로우로 훨씬 빠르게 프로덕션까지 도달할 수 있게 되었습니다.
Delphi가 창업할 당시, Vercel Workflows와 Vercel Queues는 존재하지 않았습니다. Spencer에 따르면, 이 두 기능이 없었다면 이전은 훨씬 어려웠을 것이고, 어쩌면 불가능했을 수도 있습니다.
Delphi의 백엔드는 장시간 실행되는 작업과 큐에 담긴 백그라운드 잡에 의존합니다. 디지털 마인드는 콘텐츠를 미리 생성하는 지속형 에이전트와, 개인의 책과 강연을 지식 그래프로 변환하는 수집 파이프라인을 필요로 합니다.
Workflows는 장시간 실행 작업을, Queues는 백그라운드 잡을 처리합니다. 두 기능 모두 별도의 설정이 필요 없습니다. 개발자가 코드베이스 안에 워크플로우나 큐 핸들러를 함수로 작성하면, Vercel이 배포 시 실행에 필요한 환경을 자동으로 프로비저닝합니다.
백엔드를 Vercel로 옮기면서 Delphi는 백엔드 변경을 무거운 릴리스처럼 다루는 방식에서 벗어나, 일상적인 프로덕트 작업처럼 배포할 수 있게 되었습니다. 이전에는 스테이징을 거쳐 프로덕션으로 배포했지만, 이제는 중간 단계를 건너뛰고 피처 플래그를 활용해 하루 100회 이상 배포하며, 변경 사항을 묶어 릴리스하는 대신 A/B 테스트를 직접 운영합니다.
Vercel Agent의 이상 감지 기능이 이 속도에 맞춰 프로덕션을 모니터링하며, 문제가 발생하면 무엇이 오작동하는지와 그 원인을 함께 알려줍니다. Spencer는 이전에는 이런 문제를 알아채지 못하는 경우가 많았다고 말합니다.
빠른 배포 덕분에 우선순위 목록에조차 오르지 못하던 소규모 실험들의 백로그도 해소할 수 있었습니다. 이러한 실험 중 상당수는 방문자를 오너, 즉 마인드와 대화하러 왔다가 자신만의 마인드를 만들고 떠나는 사람으로 전환하는 방법을 테스트합니다.
배포는 엔지니어만의 영역이 아닙니다. Delphi의 CPO와 그로스 팀도 대시보드, 프로토타입, 실험을 직접 빌드하고 배포합니다. Spencer에 따르면 이는 기존 환경에서는 불가능한 일이었습니다.
Delphi의 엔지니어들은 문제를 클라우드 에이전트에 맡기며, 로컬에서 직접 개발하는 경우는 거의 없습니다. 에이전트가 무엇을 만들었는지 처음 확인하는 곳이 바로 프리뷰 배포입니다. Vercel 프리뷰 배포는 매 푸시마다 고유한 라이브 URL을 생성하기 때문에, 브랜치를 직접 받지 않아도 휴대폰이나 Slack 스레드에서 바로 결과를 확인할 수 있습니다.
에이전트가 실패하는 건 대부분 필요한 정보에 접근하지 못했기 때문입니다. Vercel은 SDK, MCP, CLI를 통해 에이전트가 필요한 데이터와 제어 수단을 제공합니다. 에이전트는 자신이 사용하는 인터페이스로 로그를 읽고, 배포 상태를 확인하고, 환경 변수를 변경할 수 있습니다. Delphi에서 에이전트는 이러한 도구들의 주된 사용자가 되었기 때문에, 플랫폼은 사람에게만큼이나 에이전트에게도 편리해야 합니다.
Delphi의 자체 에이전트도 Vercel 위에서 운영됩니다. 그중 하나는 Vercel Sandbox에서 실행되는 내부 에이전트로, 회사 코드베이스 관련 작업을 간소화합니다. 고객 성공팀은 Slack에서 이 에이전트에게 보고된 이슈를 물어보고, 원인을 파악한 뒤, 엔지니어에게 근본 원인과 수정안을 전달합니다.
예전에는 엣지 케이스들이 그냥 지나치는 경우가 많았습니다. "이전에는 모든 것을 처리하지 못하거나, 가용한 시간보다 훨씬 많은 시간을 써야 했습니다"라고 Spencer는 말합니다. "이제는 Slack에서 바로 물어볼 수 있는 에이전트가 생겼습니다."
Vercel Sandbox는 에이전트에게 파일 시스템이 갖춰진 격리 환경을 제공하며, 에이전트는 그 안에서 코드베이스를 체크아웃하고 실행하며 질문에 필요한 데이터를 불러올 수 있습니다. 에이전트 자체는 Vercel의 에이전트 프레임워크인 eve로 구축되었습니다. Delphi의 첫 번째 버전은 호스팅 에이전트 플랫폼 위에서 운영되었기 때문에 그 플랫폼이 제공하는 연동 기능만 쓸 수 있었지만, eve에서는 도구가 Delphi가 직접 작성하는 코드이기 때문에 필요한 도구가 없으면 팀이 직접 추가하면 됩니다.
Delphi의 채팅 트래픽은 AI Gateway를 통해 처리됩니다. 디지털 마인드는 저마다 특성이 다르고, 어떤 마인드는 특정 모델에서 더 좋은 결과를 냅니다. 그래서 Delphi는 고객별로 모델을 선택하고, 자체 평가(eval) 결과가 바뀌면 그에 맞게 조정합니다. 새 모델이 출시되면 오픈소스 여부와 관계없이 당일 바로 라우팅할 수 있습니다.
AI Gateway는 장애 조치(failover)도 담당합니다. 이전에는 모델 제공업체와 직접 협력해 다른 클라우드에 폴백 용량을 마련해야 했는데, 이 과정이 쉽지 않았습니다. "AI Gateway를 쓰면서부터는 폴백이 존재하는 한 반드시 적용된다는 걸 알 수 있습니다"라고 Spencer는 말합니다.
Delphi의 첫 번째 챕터는 디지털 마인드를 학습시키고 사람들이 그 마인드와 대화할 수 있게 하는 것이었습니다. 이제는 채팅을 넘어선 인터페이스를 구축하고 있습니다. Spencer가 구상하는 것은 사용자가 질문을 가져오면 여러 마인드의 관점을 동시에 보여주고, 사용자에 맞게 페이지가 조정되는 검색 페이지입니다.
이 작업은 Workflows 위에서 장시간 실행되는 에이전트로 동작하며, AI Gateway가 각 실험에 필요한 모델을 공급합니다.
소개 Delphi: Delphi는 개인의 지식, 사고 방식, 목소리를 디지털 마인드로 전환하는 플랫폼입니다. 누구든 자신만의 Delphi를 만들어 전문 지식을 발견하고 접근할 수 있게 하며, 사람들이 찾아와 배우고 대화할 수 있는 마인드 네트워크의 일원이 됩니다.
