하루에 PDF 몇백 건을 단일 백엔드 Lambda나 작은 Kubernetes pod에서 생성한다면 아키텍처 차이는 크게 중요하지 않습니다. 어떤 방식이든 동작하고, 어떤 방식이든 충분히 빠릅니다.

규모가 커지면 달라집니다. 하루 수만 건의 문서를 내보내는 순간, 즉 어느 정도 견인력을 가진 이커머스 플랫폼, 물류 운송사, BNPL 서비스, 급여 서비스, 인보이스 플랫폼이라면 세 가지 숫자가 아프기 시작합니다.

콜드 스타트 지연 시간, 어딘가에는 항상 콜드 상태가 있기 때문입니다.
지역 지연 시간, 고객은 오리진 바로 옆에 있지 않기 때문입니다.
렌더링당 컴퓨트, 하루 수만 번씩 같은 비용을 내기 때문입니다.

이 글은 하루 약 1만 건의 렌더링을 넘어서면 이 세 가지가 어떻게 달라지는지, 그리고 gPdf 같은 Edge 배포 렌더러가 “같은 것을 조금 더 빠르게 만든 것“이 아니라 사실상 다른 범주의 해결책인 이유를 설명합니다.

1. 콜드 스타트 비용은 동시성과 함께 누적됩니다

콜드 스타트는 단순한 불편이 아닙니다. 동시성 곡선의 함수입니다. 보통은 이렇게 전개됩니다.

평균 트래픽 기준으로 N=10개의 warm container를 준비합니다.
트래픽이 3배로 튑니다(Black Friday, 급여일, 분기 말).
새 container 20개가 피크를 흡수하려고 콜드 스타트합니다. 각 container는 Chromium / Prince / 자체 실행 환경을 띄우는 데 1.5-2.5초가 걸립니다.
그 30초 동안 새 container들은 p99 = 2초 수준으로 응답하고, 전체 p99를 함께 끌어올립니다.
주문 처리 전체에 5-10초 정도로 잡아 둔 하위 처리 제한 시간이 PDF 생성에 먹힙니다.

트래픽이 평평하면 괜찮습니다. 피크가 크면 혹독합니다. PDF 트래픽은 항상 피크가 있습니다. 인보이스는 청구 주기 경계에 몰리고, 배송 라벨은 운송사가 집하할 때 몰리고, 명세서는 월말에 몰립니다.

Edge 대안: Cloudflare Worker isolate는 1.5-2.5초가 아니라 5-20 ms 안에 콜드 스타트합니다. 띄울 container가 없고, 초기화할 JVM/V8도 없고, 부팅할 브라우저도 없습니다. WASM 모듈은 이미 살아 있는 프로세스 안으로 로드됩니다. 콜드 스타트는 더 이상 아키텍처를 설계할 때 중심에 둘 문제가 아닙니다.

gPdf의 경우 벤치마크에서 관측한 최악의 콜드 스타트는 약 12 ms입니다. 그것도 새로 배정된 isolate의 첫 요청에만 해당합니다. 같은 isolate의 이후 요청은 그 비용마저 건너뜁니다.

2. “빠른” 요청에도 지역 지연 시간은 실제로 남습니다

Sydney에서 us-east-1 오리진까지 왕복하면 코드가 아무 일도 하기 전에 200 ms가 듭니다. São Paulo에서 eu-west-1까지는 약 190 ms입니다. Mumbai에서 us-east까지는 약 220 ms입니다.

그것도 각 방향입니다. 중앙 집중형 PDF API가 서버 쪽에서 300 ms 렌더링을 한다면, Sydney 고객이 보는 시간은 이렇게 됩니다.

client → us-east  : 200 ms
us-east render    : 300 ms
us-east → client  : 200 ms
total wall-clock  : 700 ms

인터랙티브 흐름(“보내기 전에 인보이스 미리 보기”)에서는 고통스럽습니다. 대량 백엔드 작업이라면 크게 눈에 띄지 않습니다.

Edge 대안: Cloudflare는 300개 이상의 도시에서 실행됩니다. Sydney 고객에게 가장 가까운 colo는 대략 5 ms 거리입니다. 같은 렌더링은 이렇게 바뀝니다.

client → SYD colo : 5 ms
SYD render        : 4 ms
SYD → client      : 5 ms
total wall-clock  : 14 ms

인터랙티브 흐름에서는 50배 개선입니다. 백엔드 작업에서는 큰 차이가 없을 수 있지만, 인터랙티브 PDF 미리 보기(“보내기 전에 어떻게 보이는지 보여줘”)는 버벅이는 기능이 아니라 거의 공짜에 가까운 기능이 됩니다.

숨은 2차 이점도 있습니다. PDF API가 Edge에서 실행되면 주변 로직도 그쪽으로 옮길 수 있습니다. 결제 전 PDF 미리 보기, rate limit, 인증 확인 같은 것들입니다. Edge로 밀어 넣는 조각마다 핵심 처리 경로에서 왕복 하나가 사라집니다.

3. 렌더링당 컴퓨트는 조용히 누적되는 청구서입니다

하루 10만 건을 렌더링할 때 Lambda식 계산은 이렇습니다.

Puppeteer: 약 600 ms wall, 1024 MB 메모리. egress 전 순수 컴퓨트만 월 약 240달러.
DocRaptor: 10만 페이지 티어 89달러. 하루 10만 페이지(월 300만 페이지)라면 월 약 2,670달러.
gPdf: 10만 페이지 티어 5달러. 하루 10만 페이지라면 월 약 150달러. 정확히 월 10만 페이지에 머무른다면 월 약 5달러입니다.

규모가 커져도 비용 격차는 사라지지 않고 더 벌어집니다. 하루 100만 건이라면:

Puppeteer 인프라: 월 약 2,400달러 + 운영 + 온콜
DocRaptor: 월 약 26,700달러
gPdf: 월 1,500달러 고정(공개 가격표에서 볼륨 협상을 한다고 가정하면 10만 건/일 티어의 5배)

흔한 반응은 이렇습니다. “실제로는 절감 폭이 더 작겠죠. 숨은 비용이 있을 텐데요.” 경험상 그렇지 않았습니다. PDF 생성의 비용 동인은 렌더러의 컴퓨트 발자국입니다. 600 MB Chromium 프로세스를 4 MB WASM 모듈로 바꾸면 렌더링당 비용은 대략 100배 줄고, 청구서도 따라 내려갑니다.

이 방식으로도 우리가 적자를 내지 않는 이유는 Cloudflare Workers Bundled의 기반 가격이 요청 100만 건당 약 0.50달러이기 때문입니다. gPdf 렌더러는 호출당 약 1.5 ms CPU를 쓰므로 렌더링당 원가는 실제로 센트 미만입니다. 지속 가능한 사업을 위해 적당히 마진을 붙여도 고객은 여전히 18배 격차를 봅니다.

Edge 배포가 실제로 가져오는 것

마케팅 슬라이드가 아니라 세 가지입니다.

어떤 부하에서도 예측 가능한 지연 시간

요청마다 부팅 비용이 없기 때문에 p50과 p99가 서로 가깝게 유지됩니다. 트래픽 피크 중에도 gPdf는 보통 p99가 p50의 3배 안에 머무릅니다. 반면 Puppeteer는 콜드 스타트 폭풍 때 p99가 p50의 10배까지 벌어질 수 있습니다.

어디서나 같은 배포 산출물 하나

.wasm 모듈은 모든 Cloudflare colo에 동일하게 배포됩니다. “Sydney pool이 warm인가?” 같은 질문이 없습니다. 모든 isolate가 몇 밀리초 안에 같은 모듈을 띄우고 동일하게 응답합니다. 지역별 Lambda 동시성 예약을 유지하는 것보다 운영적으로 훨씬 단순합니다.

내부 실행으로 확장되는 경로

언젠가 고객의 경계 안에서 gPdf를 실행하고 싶을 수 있습니다. 고객 VPC, 격리 클러스터, 망 분리 인트라넷 같은 환경입니다. 같은 WASM 모듈이 그대로 동작합니다. 이는 “우리가 호스팅하는 SaaS“와 “어디서나 실행되는 기술을 제공한다“의 차이입니다.

이 방식이 맞지 않는 경우

Edge가 공짜 마법은 아닙니다. 중앙 집중형 구성이 더 나은 업무도 있습니다.

수 초 이상 걸리는 렌더링. 단일 PDF가 30초 걸린다면(거대한 재무 명세서, 과학 리포트), Edge의 CPU 한도와 싸우기보다 장시간 실행 container와 지속 상태가 있는 쪽이 낫습니다.
다른 데이터베이스가 필요한 렌더링. 렌더링 전에 OLAP 테이블 세 개를 JOIN해야 한다면, 렌더러는 Edge가 아니라 데이터베이스 옆에 있어야 합니다. 해결책은 JOIN을 먼저 끝내고 실제 렌더링용 JSON만 Edge로 보내는 것입니다.
후처리가 필요한 출력. 워터마킹, 서명, 아카이브처럼 렌더링 뒤 처리 흐름이 여러 단계이고 상태를 가진다면, Edge 렌더링의 “무상태” 성질은 기능이 아니라 비용이 됩니다.

그 밖의 대부분, 즉 B2B 인보이스, 배송 라벨, 영수증 트래픽의 압도적 다수에서는 중요한 축마다 Edge가 이깁니다.

현재 구성을 그만 참아야 할 때

간단한 체크리스트입니다. 세 가지에 체크할 수 있다면, 마이그레이션 계산은 이미 기울었습니다.

월 PDF 인프라 비용이 300달러를 넘습니다.
일반 트래픽에서 PDF p99 지연 시간이 800 ms를 넘습니다.
고객에게 영향을 준 콜드 스타트 사고가 있었습니다.
CJK / RTL / emoji 글리프 누락을 디버그하는 데 4시간 넘게 쓴 적이 있습니다.
미리 보기나 화면 내 다운로드처럼 인터랙티브 흐름에서 PDF를 생성합니다.
둘 이상의 지리적 지역에서 운영합니다.

처음 세 항목은 비용도 내고 아픔도 겪고 있다는 뜻입니다. 다음 세 항목은 중앙 집중형 렌더러가 otherwise 가능했을 제품 결정을 적극적으로 제한하고 있다는 뜻입니다.

이 중 하나라도 익숙하다면 Playground가 브라우저에서 샘플 인보이스를 5 ms 미만에 렌더링합니다. 숫자가 스스로 말하게 두세요.