DocRaptor는 좋은 제품입니다. Prince라는 HTML-PDF 변환 엔진의 표준을 호스팅 REST API로 제공하며, 재시도, 비동기 작업, 준수한 문서까지 갖추고 있습니다. 10년 넘게 운영되어 왔고, 많은 팀에게는 “Prince를 직접 운영하고 싶지 않다”는 문제의 가장 자연스러운 선택지입니다.

gPdf는 형태가 다른 도구입니다. gPdf는 HTML을 받지 않습니다. 구조화된 JSON을 받아 Cloudflare Edge에서 곧바로 PDF를 생성합니다. 월 10만 페이지 기준 정가는 월 5달러(gPdf Basic) vs 월 89달러(DocRaptor Basic), 약 18배 차이입니다. 이 격차는 출시 프로모션이 아니라 구조적인 차이에서 나옵니다. 이 글은 그 구조가 왜 이런 가격을 만드는지, 그리고 두 도구가 실제로 어디에 맞는지 설명합니다.

두 아키텍처를 나란히 보기

계층	DocRaptor (HTML-PDF 변환)	gPdf (JSON-PDF 변환)
입력	HTML + CSS (Prince의 페이징 미디어 확장 포함)	`DocumentRequest` JSON
PDF 생성 엔진	Prince (컴파일된 C++ 엔진)	자체 Rust 엔진, WebAssembly로 컴파일
호스팅	DocRaptor 중앙 서버(미국 데이터센터 리전)	Cloudflare Workers, 모든 CF colo(300개 이상 도시)
콜드 스타트	서버 측 워커 풀	V8 isolate 부팅, 한 자리 ms
1회 생성당 컴퓨팅	HTML/CSS 레이아웃 처리 후 Prince가 페이지네이션	직접 조판, 별도 레이아웃 해석 단계 없음
1회 생성 p50	~250–800 ms wall-clock(네트워크 + PDF 생성)	~3–8 ms(네트워크 + PDF 생성)
출력 결정성	높음(Prince는 성숙한 엔진)	바이트 단위 동일(같은 JSON → 같은 바이트)

이 두 열을 “범용 HTML 출력 서비스”와 “목적 특화 문서 생성 엔진”으로 읽었다면, 핵심 아키텍처 결정은 이미 이해한 셈입니다. 지연 시간, 비용, 기능 목록까지 나머지는 모두 그 선택에서 파생됩니다.

Prince 비용

Prince는 좋습니다. 동시에 대부분의 인보이스/영수증/배송 라벨 처리 흐름에는 필요 없는 일도 합니다. 사용자가 어떤 HTML을 던져도 CSS Paged Media, 즉 페이지 나누기 규칙, 반복 머리말, 각주, 상호 참조, 생성 콘텐츠 박스를 구현해야 합니다.

이 범용성에는 실행 비용이 붙습니다. 임의의 HTML 문서를 페이지로 나누려면 엔진은 다음 단계를 거쳐야 합니다.

HTML을 파싱하고 검증
CSS cascade를 파싱하고 해석(Prince 자체 확장이 포함될 수 있음)
렌더 트리 구성
다중 패스 레이아웃 실행(특히 여러 페이지에 걸치는 테이블이나 균형을 맞춰야 하는 컬럼)
페이지 간 상호 참조 해석
PDF 객체 발행

이 단계 대부분은 HTML을 입력으로 받는 비용입니다. 입력이 이미 구조화된 데이터라면, 실제로는 거의 항상 그렇습니다. 인보이스도 HTML로 감싸기 전 어딘가에는 JSON 객체로 존재합니다. 그러면 매번 PDF를 만들 때마다 컴퓨팅과 지연 시간으로 이 단계를 지불하지만, 출력물에는 별다른 가치를 더하지 못합니다.

gPdf는 레이아웃 해석 단계를 통째로 건너뜁니다. JSON DocumentRequest가 이미 페이지 레이아웃을 구조적으로 지정합니다. 예를 들면 { pages: [{ size, elements: [...] }] }입니다. 엔진은 요소를 조판하고, 테이블과 목록을 결정적으로 페이지네이션한 뒤 PDF를 발행합니다. 해석해야 할 CSS cascade도, 계산해야 할 float 레이아웃도, 다시 풀어야 할 상호 참조 단계도 없습니다.

결과적으로 DocRaptor에서 ~300 ms가 걸리는 같은 한 페이지짜리 인보이스가 gPdf에서는 ~3 ms에 생성됩니다. 우리가 더 빠른 Prince를 만든 것이 아닙니다. Prince가 하는 일의 대부분을 하지 않기 때문에 빠릅니다.

“너무 싸서 믿기 어렵다”는 실제 조달팀 질문

B2B 영업 통화마다 나오는 질문이라 정면으로 다루겠습니다.

“10만 회 생성에 월 5달러라니요. DocRaptor는 89달러입니다. Anvil은 PDF당 0.10달러라 같은 양이면 10,000달러입니다. 뭐가 빠진 건가요?”

이 가격을 받을 수 있는 정직한 이유는 세 가지입니다.

1. 브라우저를 운영하지 않습니다

DocRaptor는 고객 전체에 Prince 인프라 비용을 나눠 부담시킵니다. gPdf는 Cloudflare Worker 하나의 비용을 나눕니다. Workers Bundled 기준으로 대략 백만 요청당 0.50달러 수준입니다. JSON 형태의 입력에서는 gPdf 엔진이 PDF 1회 생성에 약 1.5 ms CPU를 사용합니다. 50% 마진을 더해도 천 회 생성당 몇 센트 수준입니다. 그 산술이 곧 가격입니다.

2. 운영 제어 계층을 운영하지 않습니다

비동기 작업, 콜백, 재시도 큐, 문서 저장소, 미리보기 링크 UI, 멀티테넌트 데이터베이스가 없습니다. PDF 생성은 상태를 저장하지 않는 함수로 한 번 왕복하고 끝납니다. 대부분의 “PDF API” 회사가 예산에 넣는 운영 범위 전체가 사라집니다. 그리고 그 운영 범위가 보통 가격을 정당화하는 부분입니다.

3. 맞지 않는 작업은 모델이 스스로 걸러냅니다

문서가 정말 HTML-PDF 변환을 필요로 한다면, 예를 들어 60페이지짜리 법무 계약서나 복잡한 CSS Grid 보고서라면, 첫 한 시간 안에 JSON 모델이 맞지 않는다는 걸 알게 되고 결국 DocRaptor로 갑니다. 그런 작업에 대비해 방어적으로 가격을 올릴 필요가 없습니다. 그 작업들은 자연스럽게 빠져나갑니다. 우리는 “구조화 데이터에서 문서로” 이어지는 길지만 좁은 작업군에만 가격을 맞추면 됩니다. 그 구간에서는 1회 생성 원가가 실제로 매우 작습니다.

합치면, 10만 페이지당 5달러는 손해를 감수한 미끼 가격이 아니라 실제 매출원가에 마진을 더한 가격입니다. 브라우저를 함께 배포하지 않으면 기본 컴퓨팅 원가가 정말 그만큼 낮기 때문에, 이 가격을 계속 유지할 수 있습니다.

DocRaptor가 맞는 경우

자기에게 유리한 비교만 쓰지 않으려 합니다. DocRaptor가 실제로 이기는 경우는 다음과 같습니다.

입력이 완전히 통제할 수 없는 HTML입니다. 사용자 생성 보고서, 서드파티 템플릿, CMS의 Markdown이 HTML로 변환된 콘텐츠처럼 임의 입력에 JSON 매퍼를 만들고 싶지 않은 경우입니다.
Prince가 지원하는 CSS Paged Media 기능이 필요합니다. 장별 반복 머리말/꼬리말, 복잡한 각주 재흐름, 명명된 페이지 선택자, 자동 생성 목차, 색인 같은 기능입니다. gPdf에도 공통 부분집합에 대한 구조화된 대안이 있지만, @page :left 선택자 안에서 살아야 한다면 Prince가 맞는 도구입니다.
콘텐츠 팀이 JSON이 아니라 HTML/CSS를 작성합니다. 엔지니어가 아닌 팀에 JSON 작성 절차를 강요하지 마세요. 반발만 생깁니다.
비동기 처리 + 콜백 + 서비스형 문서 저장소가 필요합니다. DocRaptor는 생성된 PDF를 저장하고 전달용 서명 URL을 제공합니다. gPdf는 상태를 저장하지 않도록 설계되어 있으며, 결과 저장은 사용자의 코드가 담당합니다.

이 중 하나에 해당한다면 DocRaptor에 머무르세요. 그쪽이 맞는 도구입니다.

gPdf가 맞는 경우

반대쪽은 이렇습니다.

입력이 이미 구조화된 데이터입니다(DB 행, JSON API 요청 데이터, 큐 메시지).
지연 시간이 중요합니다. 인터랙티브 체크아웃 흐름, 실시간 배송 라벨 출력, 온디맨드 명세서 생성 같은 경우입니다.
테스트, 감사 추적, 전자 인보이스 보존을 위해 바이트 단위로 동일한 재현성이 중요합니다.
월 몇 천 회 이상 PDF를 생성하고 비용에 민감합니다.
바코드(GS1-128, QR, Data Matrix, PDF417, Aztec, MaxiCode)를 1 mm 미만 정밀도로 만들어야 합니다. Prince도 기술적으로 SVG 바코드를 지원하지만, HTML/CSS를 거쳐 전체 길이 0.1 mm 수준의 정밀도를 맞추는 일은 간단하지 않습니다.
규정 준수를 위해 PDF/A(1b/2b/3b/4) 또는 Factur-X / ZUGFeRD 첨부가 필요합니다.
JSON을 HTML로 바꾼 뒤 다시 PDF로 만드는 경로보다, JSON에서 바로 PDF로 만드는 경로를 쓰고 싶습니다.

전환은 전략 문제가 아니라 기계적인 작업에 가깝습니다

흔한 걱정은 “전환하려면 모든 템플릿을 다시 작성해야 하는 것 아닌가?”입니다. 보통은 그렇지 않습니다. 대부분의 HTML-PDF 변환 템플릿은 20%가 레이아웃이고, 이 부분은 한 번 JSON 구조가 됩니다. 나머지 80%는 데이터 보간이며, PDF 생성 엔진이 무엇을 받든 동일합니다.

실제 진행 경로는 다음과 같습니다.

전환할 문서 유형을 하나 고릅니다. 가장 복잡한 것이 아니라 가장 많이 생성되는 문서부터 시작하세요. 절감 폭은 크고 폭발 반경은 작습니다.
HTML 템플릿의 데이터 인터페이스, 즉 보간되는 변수를 가져와 작은 mapToDocumentRequest(data) 함수를 작성합니다.
결과가 맞을 때까지 Playground에서 반복합니다.
프로덕션에서 2주 동안 트래픽 5%를 gPdf로 보냅니다. PDF 차이를 비교하고 청구서를 비교합니다.
분위기가 아니라 데이터에 따라 계속 진행하거나 되돌립니다.

팀들이 한 번의 스프린트 안에 이 작업을 끝내고 다음 달 PDF 비용의 90%를 줄이는 것을 봤습니다. 반대로 자신의 작업이 실제로 HTML-PDF 변환에 해당한다는 걸 깨닫고 DocRaptor에 남는 팀도 봤습니다. 그것도 좋은 결정입니다.

TL;DR

	DocRaptor	gPdf
가장 잘하는 일	임의 콘텐츠의 HTML-PDF 변환	구조화된 문서의 JSON-PDF 변환
가격(월 10만 페이지)	$89	$5
p50 생성 시간	250–800 ms	3–8 ms
Edge 배포	❌ 중앙 집중식	✅ Cloudflare colo 300개 이상
비동기 + 저장소	✅ 포함	❌ 설계상 상태 저장 없음
PDF/A + Factur-X	⚠️ Prince 확장을 통해 지원	✅ 내장

문서가 PDF 생성 도구에 넘기기 위해 HTML로 포장한 구조화 데이터라면, 사실 필요 없는 변환 단계에 비용을 지불하고 있는 셈입니다. Playground를 사용해 보세요. 인보이스 하나를 JSON으로 설명하고, 브라우저에서 5 ms 미만으로 PDF를 생성한 뒤, 그 차이가 직감과 맞는지 확인할 수 있습니다.