비교

배송 라벨에서 gPdf vs iText: 무엇을 고를까

iText는 PDF 업계의 표준 SDK이고, gPdf는 호스팅형 PDF 생성 서비스입니다. 월 10만~1,000만 페이지 규모의 4×6 열전사 배송 라벨에서 사용 비용, 연동 난이도, 유지보수 부담, Edge 배포를 비교합니다.

2026년 5월 18일 분류: PDF SDK(Java / .NET)

핵심 요약

iText는 성숙하고 라이선스 체계가 갖춰진 PDF SDK이며, 비용을 지불할 가치가 있습니다. 물류 팀이 물어야 할 것은 무엇을 사는가입니다. iText는 SDK를 판매하고, 그 주변의 라벨 생성 서비스 구축·배포·확장·유지보수는 팀이 맡습니다. gPdf는 서비스를 판매합니다. 라벨 JSON을 POST하면 Edge에서 약 4 ms 안에 스캔 가능한 열전사 라벨 PDF가 돌아오며, JVM도, 워밍업 풀도, 운송사 사양 변경 때문에 한밤중에 패치하는 일도 없습니다.

항목별 비교

비교 항목	gPdf	iText	우위
프로덕션에 쓸 첫 4×6 열전사 배송 라벨	약 5분. JSON 샘플을 복사하고 curl로 호출한 뒤 Zebra 프린터에서 스캔 확인.	2~5 엔지니어-일. Maven / NuGet 의존성 추가, Java 클래스 작성, Barcode128 설정, 폰트 튜닝, 스캔율 테스트, 배포.	gPdf
연동 방식	어떤 언어에서도 HTTPS POST(Node, Python, Go, .NET, Ruby, PHP, Java).	Java 또는 .NET 중심. 운영 스택에 JVM/CLR을 넣어야 함.	gPdf
렌더 p50(4×6 라벨 1장) iText의 프로세스 내 렌더링 자체는 빠릅니다. 대가는 JVM을 직접 운영해야 한다는 것입니다. gPdf는 창고에 가장 가까운 Edge PoP에서 렌더링하므로 네트워크 홉이 전체 예산에서 작아집니다.	가장 가까운 Cloudflare PoP(전 세계 300개 이상)에서 약 4 ms.	JVM 내부 정상 상태에서는 약 2 ms. 단 JVM이 창고와 다른 리전에 있으면 네트워크 100~250 ms가 추가.	gPdf
월 10만 장 비용	5달러(Basic 티어; 1,000페이지당 0.050달러).	AGPL 준수 경로 또는 견적 기반 상용 라이선스 + 서버 + 온콜.	gPdf
월 100만 장 비용	공개 Basic 페이지 단가 기준 50달러; 엔터프라이즈 견적은 다를 수 있음.	같은 라이선스 + 더 큰 고가용성 구성 + 매월 더 많은 엔지니어링 시간.	gPdf
월 1,000만 장 비용 라이선스, 인프라, 엔지니어링 시간, 유지보수를 포함한 전체 TCO는 문서 하단의 장문 분석에 정리되어 있습니다.	공개 Basic 페이지 단가 기준 500달러; 엔터프라이즈 견적은 다를 수 있음.	멀티 리전 HA + 온콜 로테이션 + 운송사 사양 유지보수가 볼륨에 비례해 증가.	gPdf
운송사 사양이 바뀔 때(UPS SSCC, FedEx 추적번호, SF Express 체크 디지트)	JSON 템플릿만 수정. 실행 환경은 건드리지 않음. 처리 시간: 수 시간.	Java 수정 → 단위 테스트 → 통합 테스트 → JAR 빌드 → 스테이징 배포 → 프로덕션 멀티 리전 롤링. 처리 시간: 2~10 엔지니어-일.	gPdf
GS1-128과 응용 식별자(AI)	단일 `barcode` 요소, `format: "gs1_128"`, 응용 식별자(AI) 문자열을 `content`에 그대로 입력.	Barcode128 프리미티브 + Java에서 수동 응용 식별자(AI) 인코딩 + FNC1 연결.	gPdf
시각 템플릿 편집기	https://studio.gpdf.com — 프로덕션에서 실행되는 동일 JSON을 디자인. 공개 제공, 제품에 포함.	iText DITO. iText 상용 제품 생태계의 일부.	동등
오프라인 / 망 분리 환경	엔터프라이즈 프라이빗 배포로 가능(별도 협의).	기본 지원. JVM만 있으면 동작하며 외부 네트워크가 필요 없음.	iText
PDF 고급 조작(서명, 폼, 분할, 편집)	범위 밖 - gPdf는 JSON에서 새 PDF를 생성하며, 기존 PDF는 다루지 않음.	강함. iText의 본 영역이며 SDK가 라이선스 가치를 실제로 증명하는 지점.	iText
성숙도	2025년 공개.	1998년부터.	iText

어느 쪽을 고를까

gPdf 가 적합한 경우

하루 5천~500만 장까지 어떤 물량이든 물류 라벨을 생성하고, PDF 생성이 비즈니스 자체가 아니라 비즈니스 인프라일 때.
스택이 다언어(Node, Python, Go, .NET, Ruby)이고 라벨 렌더링만 위해 Java 서비스를 운영하고 싶지 않을 때.
운송사 사양 변경을 JSON 템플릿 수정으로 흡수하고 JVM 재배포로 처리하고 싶지 않을 때.
창고가 여러 국가에 분포해 있고, 자체적으로 4개 AWS 리전에 라벨 서비스를 운영하고 싶지 않을 때.
연간 라이선스와 인프라 프로젝트가 아니라 공개 진입 가격과 예측 가능한 페이지 과금을 원할 때.

iText 이 적합한 경우

이미 있는 PDF를 조작하는 작업(서명, 폼 작성, 분할, 심화 편집)이 주업무인 경우(단순 생성이 아닌).
스택이 이미 Java / .NET 우선이고, 외부 HTTP 의존을 추가하는 것이 오히려 후퇴인 경우.
망 분리 또는 엄격한 오프라인 환경에서 모든 외부 HTTPS가 금지된 경우.
PDF 도구 자체가 제품인 경우(PDF 벤더, 전자서명 플랫폼, 법무 문서 아카이브)이고 SDK를 직접 갖는 것이 맞는 통제 수준일 때.
gPdf가 지원하지 않는 PDF 고급 기능(XFA 폼, 고급 디지털 서명 처리, 특정 인증 프로파일)이 필요한 경우.

기능

gPdf는 대량 인보이스, 문서, 배송 라벨, 바코드, PDF/A, 전자 인보이스를 위해 설계된 엣지 네이티브 JSON-PDF 생성 API입니다. 글로벌 엣지 규모의 밀리초급 PDF 생성 — 예측 가능한 산업 등급 문서 생성을 위해 최적화되어 있습니다. 직접 PDF 인프라를 구축하고 운영하는 비용을 대체할 만큼 낮은 인프라 수준의 가격입니다.

기능

제품에 PDF SDK가 필요한 경우 iText는 훌륭합니다

iText는 성숙한 PDF SDK입니다. 이 점은 중요합니다. 기존 PDF 조작, 문서 서명, 폼 채우기, 파일 병합, 특수 PDF 처리 흐름 구현, 저수준 PDF 객체에 대한 Java/.NET 제어가 제품의 핵심이라면 iText가 맞는 통제 수준인 경우가 많습니다.

물류 팀의 질문은 다릅니다. PDF SDK가 필요한가, 아니면 배송 라벨, 인보이스, 영수증, 운영 문서를 매일 안정적으로 생성해야 하는가입니다. 구조화 문서 생성에서는 라이브러리를 도입하거나 구매하는 것이 첫 비용 항목일 뿐입니다. 그 주변 서비스는 여전히 직접 만들어야 합니다.

같은 문서군, 다른 제품 경계

iText에서는 애플리케이션이 SDK 연동을 직접 맡습니다. 보통 Java 또는 .NET 서비스, 폰트 설정, 바코드 설정, PDF/A 설정, 배포, 모니터링, 용량 계획, 렌더링 장애 대응 경로까지 함께 담당한다는 뜻입니다.

gPdf에서는 애플리케이션이 HTTPS로 JSON 또는 template_id + data를 보냅니다. 렌더러, Edge 배포, 번들 폰트, 바코드 요소, 비밀번호 보호 출력, 메타데이터 제어, PDF/A 프로필, Factur-X/ZUGFeRD 패키징, 시각 디자인 작업 흐름이 서비스 경계 안에 들어갑니다.

제품 적합성: 저수준 PDF 제어 vs 생성되는 업무 문서

PDF 레이어가 제품의 핵심이라면 iText를 고르세요. 법무 기술 아카이브, 전자서명 플랫폼, 문서 관리 시스템, PDF 복구/조작 도구, 외부 API를 호출할 수 없는 임베디드 Java/.NET 시스템이 여기에 해당합니다.

제품이 PDF 편집기가 아니라면 gPdf를 고르세요. 물류, 이커머스, ERP, 핀테크, 티켓팅, 백오피스 시스템은 보통 정형 데이터에서 예측 가능한 PDF가 필요합니다. 이런 경우 최고의 제품은 가장 프로그래밍 가능한 SDK가 아니라, 데이터에서 완성 문서까지 가는 가장 짧고 믿을 수 있는 경로인 경우가 많습니다.

개발 시간: SDK 구현 vs API 템플릿

“제로에서 시작해 Zebra ZT411에서 깨끗하게 스캔되는 열전사 배송 라벨이 나올 때까지”의 전형적인 시간:

iText 경로 — 간소화된 Java. 실제 코드는 빌드 설정, 폰트 등록, 스캔율 테스트 하니스, CI 파이프라인까지 더 필요합니다:

PdfWriter writer = new PdfWriter("label.pdf");
PdfDocument pdf = new PdfDocument(writer);
PageSize labelSize = new PageSize(288, 432);     // 4×6 인치 @ 72 dpi
Document doc = new Document(pdf, labelSize);
// Address block, sender block, carton ID, service code...
// (15-25 more lines positioning text and configuring Barcode128 with
// GS1 Application Identifiers, fonts, FNC1 framing, then a JUnit test
// that loads the PDF and validates the barcode renders at 203 dpi)
Barcode128 code = new Barcode128(pdf);
code.setCode("(01)00012345678905(21)SN12345");
code.setCodeType(Barcode128.CODE128);
// ... position, sizing, human-readable interpretation line ...
doc.close();

mvn init부터 깨끗하게 스캔되는 라벨까지: 전형적으로 2~5 엔지니어-일.

gPdf 경로 — 언어를 가리지 않음. 아래는 curl 예시:

curl -X POST https://api.gpdf.com/api/v1/pdf/render \
  -H "Authorization: Bearer $GPDF_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "pages": [{
      "size": "label_4_6_in",
      "elements": [
        { "type": "text", "x": 4, "y": 12,
          "content": "Acme Distribution Centre\n1200 Logistics Pkwy\nMemphis TN 38116" },
        { "type": "barcode", "format": "gs1_128",
          "content": "(01)00012345678905(21)SN12345",
          "x": 4, "y": 60, "width": 92, "height": 22,
          "barcode_text": { "enabled": true, "position": "bottom" }
        }
      ]
    }]
  }' -o label.pdf

전형적으로 약 5분입니다. JSON 샘플을 읽고 같은 Zebra ZT411에서 실제 출력해 보는 시간을 포함합니다.

차이는 엔지니어 실력이 아닙니다. 제품 경계가 어디에 있느냐입니다. iText에서는 팀이 라벨 서비스를 만들고, gPdf에서는 라벨 서비스가 호출하는 제품입니다.

Studio와 템플릿 변경

물류는 흔치 않게 문서 사양이 팀 외부에서 바뀌는 영역입니다. UPS가 SSCC 인코딩 규칙을 개정합니다. SF Express가 체크 디지트를 하나 추가합니다. FedEx가 새로운 위험물 블록 레이아웃을 공개합니다. 어떤 렌더링 스택을 선택했든 이 변화를 흡수해야 합니다.

iText 쪽: 엔지니어가 운송사 공지를 읽고, Java/.NET 코드를 수정하고, 단위 테스트와 통합 테스트를 돌리고, 서비스를 빌드하고, 스테이징과 프로덕션에 배포한 다음, 멀티 리전으로 롤아웃합니다. 롤아웃 창 동안 창고는 여전히 옛 형식을 출력할 수 있습니다.

gPdf 쪽: 코드에서 템플릿 JSON을 수정하거나 gPdf Studio에서 요소를 추가하고 드래그해 레이아웃을 조정합니다. 렌더러 자체는 움직이지 않고 템플릿만 바뀝니다. 운송사 변경이 gPdf가 이미 지원하는 바코드 형식 안에 있다면 프로덕션 연동은 그대로 template_id + data를 유지할 수 있습니다.

가격 모델: 라이선스 경로 vs 인프라형 페이지 과금

iText 가격 판단은 단순히 “라이브러리 비용“이 아닙니다. iText에는 AGPL 경로와 상용 라이선스 경로가 있습니다. AGPL은 호환되는 오픈소스 사용에서는 현금 비용이 낮을 수 있지만 소스 공개 의무가 붙습니다. 상용 라이선스는 그 제약에서 벗어나게 해 주며, 구독과 OEM 옵션은 견적 기반 또는 사용량 기반으로 설명됩니다.

gPdf는 생성 서비스를 직접 가격화합니다. 공개 Basic 요금제는 월 5달러에 10만 페이지를 포함하고, 가격 페이지와 기계가 읽는 가격 엔드포인트 모두 같은 공개 페이지 단가 계산을 사용합니다.

월간 물량	gPdf 공개 가격	라벨 1,000장당 실효 단가
10만 라벨	5달러	0.050달러
100만 라벨	공개 페이지 단가 기준 50달러	0.050달러
1,000만 라벨	공개 페이지 단가 기준 500달러	0.050달러
1억+ 라벨	엔터프라이즈 가격 문의	—

공개 가격은 계산하기 쉬운 부분입니다. 더 어려운 것은 청구서의 나머지입니다. 라이선스/컴플라이언스 경로, 서비스 실행 환경, HA 구성, 엔지니어링 시간, 리전 배포, 운송사 사양 유지보수, 지원까지 함께 봐야 합니다.

물량 구간별 엔지니어 인월 추정, 인프라 비용 범위, SDK 기반 서비스가 규모와 함께 떠안는 운영 비용 곡선까지 포함한 전체 TCO 분석은 아래 장문 글에 있습니다.

→ 물류 라벨 TCO 분석 2026: iText vs gPdf, 월 10만~1억 페이지

Edge 생성과 운영 비용

iText는 프로세스 안에서는 매우 빠를 수 있습니다. 운영 비용은 렌더러가 어디에 배치되는가에서 나옵니다. 유럽 창고가 미국 단일 리전의 라벨 서비스를 호출하면 JVM 안의 렌더링은 빨라도 사용자 관점에서는 느립니다. 멀티 리전 배포는 이를 해결하지만, 각 리전의 배포, 모니터링, 용량, 롤아웃을 팀이 직접 소유해야 합니다.

gPdf는 생성 서비스를 Cloudflare Edge로 옮깁니다. 라벨과 인보이스 워크로드에서 제품 가치는 p50 렌더 시간만이 아닙니다. 창고, 운송사 연동, 리전 백엔드 옆에 PDF 서비스를 계속 운영하지 않아도 된다는 점이 핵심입니다.

컴플라이언스와 문서 품질 비용

iText에는 깊은 PDF 기능이 있고, gPdf가 대체하려 하지 않는 처리 흐름도 있습니다. 저수준 제어가 필요한 팀에게는 이것이 iText의 강점입니다.

업무 문서 생성에서 gPdf는 흔한 출력 요구사항을 제품화합니다. CJK 폰트, 벡터 바코드, PDF/A 프로필, Factur-X/ZUGFeRD 패키징, 메타데이터, 비밀번호 보호 출력, 템플릿 기반 생성입니다. 비용 비교에는 이 중 얼마나 많은 것을 자체 서비스 안에서 조립하고 테스트하고 유지할지 포함해야 합니다.

그럼에도 iText가 정답인 경우

자기편만 이기는 비교는 마케팅 글이지 비교가 아닙니다. iText가 여전히 더 나은 선택인 경우:

PDF를 조작하는 경우(생성이 아닌). 서명, 폼 작성, 분할, 페이지 단위 편집은 iText의 본 영역이며, gPdf는 이 경기에 들어가지 않습니다.
스택이 Java / .NET 우선인 경우. 나머지 서비스가 JVM에서 돌아가고 외부 HTTP 의존을 추가하는 것이 오히려 후퇴처럼 느껴진다면 iText가 맞습니다.
망 분리 또는 엄격한 오프라인 환경. 외부 HTTPS는 형태가 맞지 않고, iText는 JVM만 있으면 어디서나 돌아갑니다.
PDF 도구가 곧 제품인 경우. PDF를 파는 입장이라면(PDF 벤더, 전자서명 플랫폼, 법무 문서 아카이브) SDK 레벨의 통제권이 옳습니다. gPdf는 “본업이 물류·청구·커머스이고 PDF는 그 도구“인 팀을 위한 것이지, PDF 자체가 제품인 팀을 위한 것이 아닙니다.
gPdf가 지원하지 않는 PDF 고급 기능(XFA 폼, 고급 디지털 서명 처리, 특정 인증 프로파일)이 필요한 경우.

“소포 100만 개에 각각 스캔되는 라벨을 붙여야 한다”라는 목적에는 gPdf가 마찰이 적은 길입니다. “Java 백엔드에서 기존 법무 PDF를 편집해야 한다”에는 iText가 정답입니다.

FAQ

iText는 무료인가요?

iText에는 호환되는 오픈소스 사용을 위한 AGPL 경로와, AGPL 의무를 따를 수 없거나 원하지 않는 팀을 위한 상용 라이선스가 있습니다.

gPdf가 iText를 대체하나요?

아니요. gPdf는 구조화된 새 문서를 위한 PDF 생성 서비스입니다. 깊은 PDF 조작, 서명, 폼 작성, 분할, 저수준 SDK 제어에서는 iText가 여전히 강합니다.

iText 가격이 견적 기반인데 왜 가격을 비교하나요?

구매자는 여전히 총소유비용 모델이 필요하기 때문입니다. 비교에는 SDK 항목만이 아니라 라이선스/컴플라이언스 경로, 인프라, 엔지니어링 시간, 지원, 리전 운영이 포함되어야 합니다.

마이그레이션 형태

라벨 렌더링을 iText에서 gPdf로 옮기는 팀의 변화는 대략 다음과 같습니다.

- // Before: a Java label-rendering service
- PdfWriter writer = new PdfWriter(out);
- PdfDocument pdf = new PdfDocument(writer);
- Document doc = new Document(pdf, new PageSize(288, 432));
- // 20–40 lines wiring fonts, positions, Barcode128 with GS1 AIs
- doc.close();
+ // After: HTTPS POST the structured DocumentRequest from any language
+ const res = await fetch('https://api.gpdf.com/api/v1/pdf/render', {
+   method: 'POST',
+   headers: { Authorization: `Bearer ${KEY}`, 'Content-Type': 'application/json' },
+   body: JSON.stringify(labelDocumentRequest),
+ });
+ const pdf = Buffer.from(await res.arrayBuffer());

전환이 끝나면 Java 라벨 서비스는 주문을 조율하는 기존 언어에서의 fetch 호출 하나로 줄어듭니다. JVM은 라벨 경로에서 사라지고, 운송사 사양 변경은 배포 이벤트가 아니게 되며, 온콜은 라벨 렌더링 OOM으로 호출받지 않게 됩니다.