DocRaptor는 유능한 제품입니다. Prince — HTML-to-PDF의 골드 스탠다드 엔진 — 를 호스팅된 REST API로 감싸고, 재시도, 비동기 작업, 적절한 문서를 갖추고 있습니다. 10년 넘게 존재하며, 많은 팀에게 「Prince를 직접 운영하고 싶지 않다」는 명백한 선택입니다.

우리는 다른 형태의 도구입니다. gPdf는 HTML을 전혀 받지 않습니다. 구조화된 JSON을 받아 Cloudflare 엣지에서 직접 PDF로 렌더링합니다. 월 100K 페이지에서의 정가 차이: $5/월 (gPdf Basic) vs $89/월 (DocRaptor Basic) — 약 18배. 이 격차는 오프닝 프로모션이 아닙니다. 구조적입니다. 이 글은 왜 구조가 그 가격을 만드는지, 각 도구가 실제로 어디에 적합한지 설명합니다.

두 아키텍처를 나란히

레이어	DocRaptor (HTML → PDF)	gPdf (JSON → PDF)
입력	HTML + CSS (Prince paged-media 확장 포함)	JSON `DocumentRequest`
렌더러	Prince (컴파일된 C++ 엔진)	자체 Rust 엔진, WebAssembly로 컴파일
호스팅	DocRaptor 중앙화 서버 (US 데이터센터)	Cloudflare Workers, 모든 CF colo (300+ 도시)
콜드 스타트	서버 측 워커 풀	V8 isolate 부팅, 한 자리 ms
렌더당 컴퓨트	HTML/CSS의 레이아웃 패스, 그 후 Prince가 페이지네이션	직접 조판, 레이아웃 해석 패스 없음
렌더당 p50	~250–800 ms wall-clock (네트워크 + 렌더)	~3–8 ms (네트워크 + 렌더)
출력 결정론성	높음 (Prince는 성숙)	바이트 동일 (같은 JSON → 같은 바이트)

이 두 컬럼을 「범용 HTML 프린터」 vs 「목적 빌드 문서 렌더러」로 읽으면, 이미 아키텍처 결정을 이해한 것입니다. 다른 모든 것 (지연시간, 비용, 기능 목록까지)은 이 한 가지 선택의 하류입니다.

Prince 세금

Prince는 좋습니다. 또한 대부분의 인보이스/영수증/라벨 워크플로우가 필요로 하지 않는 일을 합니다: 사용자가 던질 수 있는 임의의 HTML에 대해 CSS Paged Media — 페이지 나누기 규칙, running header, 각주, 상호 참조, 생성된 콘텐츠 — 를 구현합니다.

그 일반성에는 런타임 비용이 있습니다. 임의의 HTML을 페이지네이션하려면 엔진은:

HTML 파싱 및 검증
CSS 캐스케이드 해결 (잠재적으로 Prince 자체 확장 포함)
렌더 트리 구축
멀티패스 레이아웃 실행 (특히 페이지를 가로지르는 테이블, 균형 잡는 컬럼)
페이지 간 상호 참조 해결
PDF 객체 발행

이러한 패스 대부분은 HTML을 입력으로 받는 비용입니다. 입력이 이미 구조화된 데이터라면 (거의 항상 그렇다 — 인보이스는 HTML로 감싸기 전에 JSON 객체로 존재한다), 매번 렌더에서 컴퓨트와 지연시간으로 그 패스를 지불하며 출력에 가치를 더하지 않습니다.

gPdf는 레이아웃 해석 단계를 완전히 건너뜁니다. JSON DocumentRequest는 페이지 레이아웃을 이미 구조적으로 명시 — { pages: [{ size, elements: [...] }] }. 렌더러는 요소를 조판하고, 테이블/리스트를 결정론적으로 페이지네이션하고, PDF를 발행합니다. 해결할 CSS 캐스케이드 없음, 계산할 플로트 레이아웃 없음, 상호 참조 해결 패스 없음.

결과: DocRaptor에서 ~300 ms 걸리는 같은 한 페이지 인보이스가 gPdf에서는 ~3 ms. 우리는 더 빠른 Prince를 작성해서 더 빠른 게 아니라, Prince가 하는 일의 대부분을 하지 않기 때문에 더 빠릅니다.

「너무 싸서 사실 같지 않다」는 진짜 조달 이의

직접 다루겠습니다, 모든 B2B 영업 콜에서 나오기 때문입니다.

「100K 렌더에 $5/월. DocRaptor는 $89. Anvil은 $0.10/PDF (즉 같은 볼륨에 $10,000). 너희들 무엇이 잘못됐어?」

이 가격을 청구할 수 있는 세 가지 정직한 이유:

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

DocRaptor는 Prince 인프라를 고객 간에 상각합니다. gPdf는 Cloudflare Worker를 상각하며, Workers Bundled에서 약 $0.50/백만 요청입니다. JSON 형태 입력으로, 렌더러는 렌더당 약 1.5 ms CPU를 사용합니다. 50% 마진을 쌓아도 천 렌더당 센트 범위입니다. 산술이 가격입니다.

2. 컨트롤 플레인을 운영하지 않습니다

비동기 작업 없음, 콜백 없음, 재시도 큐 없음, 문서 저장소 없음, 미리보기 링크 UI 없음, 멀티 테넌트 DB 없음. 각 렌더는 stateless 함수로의 단일 왕복입니다. 이것은 대부분의 「PDF API」 회사가 예산화하는 전체 ops 표면을 제거합니다 — 그것은 또한 그들의 가격을 정당화하는 표면입니다.

3. 모델은 손해 보는 워크로드를 자기 선택 배제

문서가 진짜로 HTML-to-PDF를 필요로 한다면 (60페이지 법률 계약, 복잡한 CSS-Grid 보고서), 첫 시간에 JSON 모델에서 튕겨 나가 결국 DocRaptor로 갑니다. 그 워크로드에 대해 방어적으로 가격을 책정할 필요가 없습니다. 자체 라우팅되기 때문입니다. 「구조화 데이터 → 문서」의 길지만 좁은 꼬리에 대해서만 가격을 책정하면 되며, 거기서 렌더당 비용은 정말 미미합니다.

합쳐서: $5/100K는 손실 리더가 아니라 실제 매출 원가 + 마진입니다. 브라우저를 출시하지 않을 때 기본 컴퓨트가 진짜 그렇게 싸기 때문에 무기한 거기에 유지할 수 있습니다.

DocRaptor가 정답인 곳

자기 이익 비교를 쓰지 않으려고 노력합니다. DocRaptor가 진짜 이기는 경우:

입력이 완전히 통제하지 않는 HTML이다. 사용자 생성 보고서, 서드파티 템플릿, CMS에서 HTML로 렌더링된 Markdown. 임의의 입력에 대해 JSON 매퍼를 작성하고 싶지 않다.
Prince가 지원하는 CSS Paged Media 기능이 필요하다. 챕터별 running header/footer, 복잡한 각주 reflow, 명명된 페이지 셀렉터, 생성된 목차, 색인. gPdf는 공통 부분 집합에 대한 구조화된 등가물을 가지고 있지만, @page :left 셀렉터 안에 살고 있다면 Prince가 친구입니다.
HTML/CSS를 작성하는 콘텐츠 팀이 있고 JSON을 작성하지 않는다. 비엔지니어링 팀에 JSON 작성 워크플로우를 강요하지 마세요. 미움받습니다.
비동기 + 콜백 + 서비스로서의 문서 저장소. DocRaptor는 생성된 PDF를 저장하고 배달용 서명된 URL을 제공합니다. gPdf는 엄격하게 stateless — 코드가 결과를 저장합니다.

이런 버킷 중 하나에 있다면, DocRaptor에 머무르세요. 올바른 도구입니다.

gPdf가 정답인 곳

거울 이미지:

입력이 이미 구조화된 데이터 (DB 행, JSON API 페이로드, 큐 메시지).
지연시간이 중요 — 인터랙티브 체크아웃 흐름, 실시간 라벨 인쇄, 온디맨드 명세서 생성.
테스트/감사 추적/전자세금계산서 보존을 위해 바이트 동일 재현성을 신경 씀.
월 수천 렌더 이상의 어떤 볼륨에도 비용 민감.
바코드 (GS1-128, QR, Data Matrix, PDF417, Aztec, MaxiCode)를 서브밀리 정밀도로 필요.
컴플라이언스를 위해 PDF/A (1b/2b/3b/4) 또는 Factur-X / ZUGFeRD 첨부 필요 — 특히 **한국의 전자세금계산서 의무 (2011년부터 시행)**의 향후 EU 표준화 통합과 관련.
JSON-to-PDF 파이프라인을 실행할 수 있을 때 JSON-to-HTML-to-PDF 파이프라인을 실행하지 않으려 함.

한국 팀을 위한 구체적인 메모

한국의 전자세금계산서 제도 (2011년 의무화) 맥락이라면, 국세청 표준 XML 형식 (e-Tax Invoice)이 필수입니다. EU의 Factur-X / ZUGFeRD만큼 엄격한 PDF/A-3 + XML 두 층 구조는 법적으로 요구되지 않지만, 글로벌 사업 확장을 위해서나 Peppol (한국에서도 2024년부터 추진) 대응을 위해 같은 메커니즘으로 두 형식을 모두 충족할 수 있습니다:

curl -X POST https://gpdf.com/api/v1/e-invoice/render \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "document": { "pages": [{ "size": "a4", "elements": [...] }] },
    "einvoice": {
      "format": "factur-x",
      "profile": "BASIC",
      "xml": "<rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
    }
  }' \
  --output invoice.pdf

Ghostscript 후처리 패스 없음, XML을 첨부하기 위한 두 번째 도구 없음, 단계 간 검증 추첨 없음. 출력 바이트는 엔진 버전 간에 바이트 동일하므로 5년 세무 보존 의무를 위한 보존 해시는 안정적으로 유지될 수 있습니다.

마이그레이션은 기계적이지 전략적이 아닙니다

흔한 우려: 「전환은 모든 템플릿을 다시 작성하는 것을 의미한다」. 보통 그렇지 않습니다. 대부분의 HTML-to-PDF 템플릿은 20%가 레이아웃 (한 번 JSON 구조가 됨)이고 80%가 데이터 보간 (렌더러가 무엇을 받든 정확히 동일)입니다.

실용 경로:

마이그레이션할 하나의 문서 유형을 선택. 가장 큰 볼륨부터 시작 — 가장 큰 절약, 가장 작은 폭발 반경.
HTML 템플릿의 데이터 인터페이스 (보간하는 변수)를 가져와 작은 mapToDocumentRequest(data) 함수를 작성.
출력이 일치할 때까지 Playground에 대해 반복.
프로덕션에서 A/B: 트래픽의 5%를 2주 동안 gPdf로 라우팅. PDF를 diff. 청구서를 비교.
데이터 기반으로 전진 또는 후퇴, 분위기가 아닌.

TL;DR

	DocRaptor	gPdf
최적	임의 콘텐츠의 HTML → PDF	구조화된 문서의 JSON → PDF
가격 (월 100K 페이지)	$89	$5
렌더 p50	250–800 ms	3–8 ms
엣지 배포	❌ 중앙화	✅ 300+ Cloudflare colos
비동기 + 저장소	✅ 포함	❌ 디자인상 stateless
PDF/A + Factur-X / ZUGFeRD	⚠️ Prince 확장 경유	✅ 내장

문서가 렌더러를 위해 HTML로 변장한 구조화된 데이터라면, 존재할 필요 없는 번역 단계에 비용을 지불하고 있습니다. Playground를 시도하세요 — 인보이스 중 하나를 JSON으로 설명하고, 브라우저에서 5 ms 미만으로 렌더링하고, 격차가 직관과 일치하는지 보세요.