Vercel 상의 Factory

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

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

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

Observability 및 WAF가 네트워크 수준에서 보호를 담당함

• 일일 수천만 건의 백엔드 API 요청 처리

• 350ms p95 응답 시간

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

• API routes가 고객용 API를 처리하며, 이는 Next.js 앱의 별도 섹션에서 출시됨

• Middleware가 모든 접점에서 인증 및 라우팅 로직을 관리함

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

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

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

• 일회성 내부 워크플로우를 위한 커스텀 유틸리티

---

---

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

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

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

Factory가 급격히 성장함에 따라, 동일한 백엔드가 모든 새로운 워크로드 (workload)를 흡수했습니다. 이 과정에서 별도의 인프라를 구축하거나 새로운 벤더 (vendor)를 결정할 필요가 전혀 없었습니다. 조정이 필요했던 유일한 영역은 메모리 제한 (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 데스크톱 앱 (Factory Desktop App)이나 CLI에서 자신들만의 Droids를 사용하여 필요한 것을 구축하고 Vercel에 직접 배포합니다. Droids는 프로그래밍 방식으로 Vercel에 접속하여 구성 (configuration), 빌드 (builds), 배포 (deployments)를 엔드 투 엔드 (end-to-end)로 처리합니다. 엔지니어들은 가드레일 (guardrails)을 설정하고 중요한 결정을 검토하며, 나머지 모든 것은 Droids가 처리합니다. 이러한 워크플로 (workflow)를 통해 팀 전체에서 하루에 수십 건의 배포가 이루어지고 있으며, 내부 도구 라이브러리도 계속 성장하고 있습니다:

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

Vercel Observability는 팀에게 무엇이 API를 타격하고 있는지에 대한 가시성(visibility)을 제공하여, 트래픽 패턴과 문제가 되는 IP가 나타나는 즉시 표면화합니다. Web Application Firewall은 집행(enforcement)을 담당합니다. 팀은 경로 수준의 규칙(route-level rules)으로 악성 행위자를 차단하며, 그 이면에서는 속도 제한(rate limiting)과 DDoS 방어가 지속적으로 실행됩니다.

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

Factory는 대규모 자율 소프트웨어 공장(autonomous software factories)을 향한 선구적인 비전을 계속해서 구현하고 확장함에 따라, 향후 1년 동안 급격히 성장할 것으로 예상합니다.

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

더 읽어보기

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

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

최소한의 보안 오버헤드로 소비자 대상 제품 보안 강화하기

다음 단계