Vercel 기반의 Factory

비기술 팀들이 엔지니어링 부서의 병목 현상을 겪음

Droids가 자율적으로 빌드 및 배포하기 위해 Vercel의 API를 호출함

셀프 서비스(Self-serve) 도입으로 인해 Factory의 백엔드가 새로운 범주의 위협에 노출됨

관측성 (Observability) 및 WAF가 네트워크 수준에서 보호를 담당함

• 매일 10억 건의 백엔드 API 요청 처리

• 350ms p95 응답 시간

• 전담 인프라 팀 없이 백엔드, 내부 도구 및 보안 확장

• API 라우트 (API routes)가 고객용 API를 처리하며, 이는 Next.js 앱의 별도 섹션으로 출시됨

• 미들웨어 (Middleware)가 모든 접점에서 인증 및 라우팅 로직을 관리함

• 웹훅 핸들러 (Webhook handlers) 및 로그 드레인 파이프라인 (Log drain pipelines)이 웹 플랫폼과 함께 실행되어 다운스트림으로 분석 데이터를 전달함

• Factory의 분석 데이터베이스 및 소프트웨어 도구에서 직접 데이터를 가져오는 내부 분석 대시보드

• 솔루션 엔지니어가 몇 분 안에 구축하고 배포할 수 있는 고객 맞춤형 데모

• 일회성 내부 워크플로우를 위한 맞춤형 유틸리티

---

---

우리의 미션은 신호(signals)부터 프로덕션(production)에 이르기까지 소프트웨어 개발 생명주기(Software Development Lifecycle)의 모든 단계에 자율성을 부여하는 것입니다. 이는 엔지니어링적 판단을 대체하려는 것이 아니라, 그 주변의 반복적인 작업을 자동화하여 엔지니어가 가장 중요한 결정에 더 집중할 수 있는 시간을 확보해 주는 것입니다. 이러한 엔지터프라이즈급 플랫폼을 제공하기 위해, Factory는 내부적으로 이상적인 운영 모델을 채택했습니다. 즉, 일상적인 워크로드를 관리하기 위해 Droids를 배포함으로써 가볍고 민첩한 상태를 유지하고, 엔지니어들이 오직 제품을 구축하는 데에만 집중할 수 있도록 했습니다. Factory

Factory가 단순한 웹 앱에서 개인 개발자부터 수만 명의 엔지니어를 보유한 기업에 이르기까지 모든 사용자에게 서비스를 제공하는 멀티 서피스 플랫폼 (multi-surface platform)으로 확장됨에 따라, 그들의 백엔드 또한 함께 확장되었습니다. 오늘날 Vercel 상의 단일 백엔드는 별도의 엔지니어링 프로젝트를 만들지 않고도 API 라우트 (API routes), 미들웨어 (middleware), 웹훅 핸들러 (webhook handlers) 전반에 걸쳐 일일 10억 건의 요청을 처리하며 모든 서피스에 동력을 공급하고 있습니다. Next.js

대부분의 팀은 Next.js를 프론트엔드 프레임워크 (frontend framework)로 생각합니다. 하지만 Factory는 전체 클라우드 백엔드를 그 위에서 실행합니다:

Factory가 급격히 성장함에 따라, 동일한 백엔드가 모든 새로운 워크로드 (workload)를 흡수했습니다. 이 과정에서 별도의 인프라를 구축하거나 새로운 벤더 (vendor) 결정을 내릴 필요가 전혀 없었습니다. 튜닝 (tuning)이 필요했던 유일한 영역은 메모리 제한 (memory limits)과 함수 실행 시간 (function duration)뿐이었으며, 두 가지 모두 문제없이 확장되었습니다. Fluid compute는 요청 간에 함수를 따뜻하게 유지 (keeps functions warm)하여, 지연 시간 (latency)에 민감한 워크로드에서 전통적인 서버리스 (serverless)를 취약점으로 만드는 콜드 스타트 (cold start) 페널티를 제거합니다. 그 결과 p95 응답 시간은 350ms 이하를 기록하고 있습니다.

3년이 지난 지금, 그 궤적은 일반적으로 수반되는 오버헤드 (overhead) 없이 매끄러운 성장을 이어오고 있습니다.

어카운트 이그제큐티브 (account executive)가 내부 분석 대시보드가 필요하거나 솔루션 아키텍트 (solution architect)가 고객 프로토타입을 배포해야 할 때, 그 요청은 엔지니어링 팀으로 향했습니다. 모든 컨텍스트 스위칭 (context switch)은 제품 출시 속도를 늦추는 비용이 되었고, 그들은 이 문제를 해결하기 위해 자신들의 제품 자체를 Vercel로 향하게 했습니다.

이제 Factory의 비기술적 팀들은 Factory 데스크톱 앱 (Desktop App) 또는 CLI 내의 자체 드로이드 (Droids)를 사용하여 필요한 것을 구축하고 Vercel에 직접 배포합니다. 드로이드는 프로그래밍 방식으로 Vercel에 접속하여 구성 (configuration), 빌드 (builds), 배포 (deployments)를 엔드 투 엔드 (end-to-end)로 처리합니다. 엔지니어들은 가드레일 (guardrails)을 설정하고 중요한 결정을 검토하며, 드로이드는 그 외의 모든 것을 처리합니다. 이러한 워크플로 (workflow)를 통해 팀 전체에서 하루 수십 건의 배포가 이루어지고 있으며, 내부 도구 라이브러리도 계속 늘어나고 있습니다:

Factory가 셀프 서비스 가입 (self-serve signups)을 오픈하자, 자동화된 트래픽으로부터의 공격이 뒤따랐습니다. 봇(Bots)들이 사기 계정을 생성했고, 악성 IP로부터 요청이 쏟아져 들어왔습니다. 팀은 네트워크 계층 (network layer)에서 라우트 수준 (route-level)의 보호가 신속하게 필요했습니다.

Vercel Observability는 API에 무엇이 들어오는지에 대한 가시성 (visibility)을 팀에 제공하여, 트래픽 패턴과 문제가 되는 IP가 나타나는 즉시 드러내 줍니다. Web Application Firewall은 집행 (enforcement)을 담당합니다. 팀은 라우트 수준의 규칙 (route-level rules)으로 악성 행위자를 차단하는 한편, 속도 제한 (rate limiting) 및 DDoS 방어 (DDoS protection)가 표면 아래에서 지속적으로 실행됩니다.

Factory는 Factory를 구축하기 위해 그들 자신의 Droids를 사용합니다. 모든 내부 자동화는 향후 제품 기능이 되며, 자체 인프라에서 먼저 스트레스 테스트 (stress-tested)를 거칩니다. 그 루프 (loop)가 이제 다른 규모로 실행되려 하고 있습니다.

Factory는 대규모 자율 소프트웨어 공장 (autonomous software factories)을 향한 선구적인 비전을 계속해서 구현하고 확장함에 따라 빠르게 성장하고 있습니다.

Factory는 기업이 소프트웨어 공장을 구축하고 운영하는 데 사용하는 플랫폼입니다. 즉, 전체 라이프사이클 (lifecycle)에 걸쳐 신호 (signals)를 프로덕션 소프트웨어로 지속적으로 전환하는 24/7 시스템입니다. 이 플랫폼은 모델 불가지론적 (model-agnostic)이며, 클라우드에서 완전한 프라이빗 환경에 이르기까지 어디든 배포할 수 있고, 거버넌스 계층 (governance layer)으로서 엔지니어가 제어권을 유지할 수 있게 합니다. Factory는 2023년 Matan Grinberg와 Eno Reyes에 의해 설립되었으며 샌프란시스코에 본사를 두고 있습니다. 정보 Factory:

더 읽어보기

클라우드 SaaS를 위한 풀스택 백엔드로서의 Next.js: API 라우트, 미들웨어, 그리고 대규모 백엔드 로직

엔지니어를 제품 개발에서 이탈시키지 않고 내부 도구 배포하기

최소한의 보안 오버헤드 (security overhead)로 소비자 대상 제품 보호하기

다음 단계