gPdf
블로그

PDF 속성에는 남의 도구가 아니라 자사 브랜드가 찍혀야 합니다

대부분의 화이트 라벨 PDF 시스템은 페이지는 브랜드에 맞게 생성하면서도 Producer 필드에는 슬그머니 제삼자 도구 이름을 새깁니다. 고객을 대신해 PDF를 발행하는 B2B SaaS에게 이 격차는 중요합니다. 이유와 해법을 정리합니다.

gPdf Engineering
#pdf-metadata#white-label#branding#saas

업무상 중요한 PDF —— 청구서, 배송 라벨, 월간 명세서 —— 를 하나 열어 문서 속성을 확인해 봅니다(macOS Preview는 Cmd+D, Adobe Reader는 Ctrl+D, 대다수 데스크톱 뷰어는 “파일 → 속성”). 그리고 Producer 필드를 봅니다.

해당 PDF가 헤드리스 브라우저를 쓰는 SaaS 플랫폼에서 생성되었다면 보통 다음과 같은 표시를 보게 됩니다.

$ pdfinfo invoice.pdf
Title:           invoice-20260318.pdf
Subject:
Author:
Creator:         Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (...) Chrome/120.0.0.0
Producer:        Skia/PDF m120
Language:

페이지는 그 SaaS 벤더의 브랜드처럼 보입니다. 그런데 파일 속성에는 그 벤더와도, 그 벤더가 대신 발행해 주는 고객과도 무관한 브라우저 엔진 이름이 찍혀 있습니다.

이 글은 그 어긋남에 관한 이야기입니다.

페이지는 브랜드화되어 있는데 파일은 그렇지 않다

B2B SaaS에서 화이트 라벨 PDF 생성은 익숙한 요구사항입니다. 벤더가 고객에게 로고를 올리게 하고, 브랜드 컬러를 고르게 하고, 템플릿을 구성하게 합니다. 내보낸 PDF는 시각적으로 벤더가 아니라 고객의 브랜드처럼 보입니다.

대부분의 플랫폼은 거기서 멈춥니다. 보이는 레이어만 해결하고 파일 속성 레이어는 그대로 둡니다. 결과적으로 모든 페이지에 “Acme Logistics“가 적혀 있는데, 누군가 마우스 우클릭 → 속성을 여는 순간 문서는 스스로를 “Skia/PDF m120“이라고 소개합니다.

일회성 B2C 다운로드 —— 개인 영수증, 영화 티켓 —— 라면 파일 속성은 대체로 장식에 가깝습니다. 그러나 B2B 문서, 또는 규제 대상 B2C 출력(의료 보고서, 재무제표, 법적 공시, 규제 보험 양식)에서는 파일 속성도 문서의 일부입니다. 다음 곳에 모두 등장합니다.

  • Adobe Reader, Preview, Foxit 등 모든 데스크톱 PDF 뷰어
  • 문서 관리 시스템(SharePoint, M-Files, NetSuite Files)
  • 메일 서버의 PDF 프리뷰어
  • 검색 인덱스(Spotlight, Outlook, 사내 DMS 검색)
  • 아카이브 시스템(PDF/A 장기 보존)
  • 파이프라인에서 pdfinfo나 pdftk dump_data를 호출하는 모든 단계

페이지에는 “Acme“가, Producer 필드에는 “Chromium“이 적힌 문서는 이런 시스템에는 “Chromium이 Acme라는 누군가를 위해 생성한 것“으로 읽힙니다 —— “Acme가 생성한 것“이 아니라요. 기업 조달과 컴플라이언스의 시선에서 이 차이는 분명히 체감됩니다.

왜 이 문제가 직접 사용자보다 SaaS 벤더에게 더 안 좋은가

자기가 자기 자신을 위해 PDF를 만든다면 Producer 필드의 “Chromium“은 본인 문제일 뿐입니다.

SaaS 벤더이고 고객이 플랫폼을 통해 PDF를 만든다면 사슬이 길어집니다.

  • 여러분이 PDF 생성 스택을 골랐고,
  • 여러분의 고객이 그 PDF를 자신의 고객에게 보내며,
  • 최종 수신자 —— 조달팀, 운송사, 세무서, 재무 부서 —— 가 보는 Producer 필드에는 여러분의 이름도 고객의 이름도 없이, 여러분이 마침 쓴 상위 PDF 생성기 이름이 적혀 있습니다.

페이지에는 고객의 브랜드, 파일에는 낯선 도구 이름. 수신자 입장에서는 뭔가 말로 표현하기 어렵게 어긋난 문서로 비치고, 고객 입장에서는 화이트 라벨이라는 약속이 끝까지 지켜지지 않은 셈입니다.

이 지점은 대부분의 플랫폼이 투자가 부족한 영역입니다. 수정의 성과가 홈페이지에서 보이지 않으니까요. 그러나 고객이 “화이트 라벨 PDF” 기능의 출력에 pdfinfo만 한 번 돌려보면 곧장 알아차립니다.

이게 실제로 문제가 되는 순간

Producer 필드가 가정이 아니라 실제 운영 이슈로 떠오른 상황은 다음과 같습니다.

  • 벤더 보안 질문서. 기업 조달이 벤더 리스크 리뷰를 돌리며 묻습니다. “당사에 전달하는 문서 출력에 등장하는 모든 제삼자 도구를 나열하라.” 고객의 IT 팀이 샘플 문서에 pdfinfo를 돌려 낯선 PDF 생성기 이름을 찾습니다. 화내는 사람은 없습니다 —— 그러나 그 이름은 하위 처리자 목록에 추가되고, 이는 벤더 관리 리뷰와 별도의 컴플라이언스 점검을 줄줄이 끌어옵니다.
  • DMS / 아카이브 검색. 고객의 문서 관리 시스템은 author로 PDF를 인덱싱합니다. 여러분 플랫폼에서 나온 PDF의 Author 필드가 비어 있으면, 몇 달 뒤 고객의 컴플라이언스 팀은 “이 벤더의 문서들“을 쉽게 필터링할 수 없게 됩니다 —— 결국 손으로 태그를 다는데, 본래 그들의 일이 아닙니다.
  • 장기 아카이브 검증. PDF/A 아카이브 시스템은 Producer가 예상 벤더 목록과 일치하지 않는 문서를 표시합니다. 컴플라이언스 팀은 “Skia/PDF m120“과 “wkhtmltopdf“를 알려진 정상 PDF 생성기로 수동 허용 목록에 추가해야 합니다 —— 작지만 계속되는 운영 부담입니다.
  • 브랜드 일관성 감사. 일부 기업 마케팅 팀은 브랜드 거버넌스의 일환으로 외부 발송 문서의 귀속을 감사합니다. 브랜드팀이 들어본 적도 없는 도구로 귀속되어 있는 문서는 그 자체로 지적 사항이 됩니다.

이 중 어느 것도 중대 사건은 아닙니다. 하지만 기업 영업, 고객 온보딩, 운영에 작은 마찰을 계속 더합니다. 월 수천 건의 문서가 쌓이면 영향은 누적됩니다.

파일 속성이 실제로 노출하는 것

PDF 사양은 거의 모든 뷰어가 표면화하는 6개의 표준 메타데이터 필드를 정의합니다.

필드 용도 허술한 스택이 보통 보여주는 것
Title 문서 제목 자동 생성된 파일명, 또는 빈칸
Author 문서를 만든 개인 또는 조직 빈칸, 또는 개발자 본인 이름
Subject 문서 간단 설명 빈칸
Creator 원본 콘텐츠를 생성한 애플리케이션 “Chromium”, “Mozilla/5.0…”, 또는 SaaS 벤더 내부 도구명
Producer PDF 바이트를 생성한 애플리케이션 “Skia/PDF m120”, “wkhtmltopdf 0.12.x”, “iText 7.x.x”
Language BCP-47 언어 태그 빈칸, 또는 잘못된 로케일

각 필드는 짧은 문자열 하나일 뿐입니다. 기술적으로 채우기 어려운 필드는 없습니다. 기본값으로 새는 이유는 PDF 생성 라이브러리가 자기 이름을 Producer에 쓰고(맞습니다 —— 그 필드는 그러라고 있는 겁니다), 대부분의 애플리케이션 코드가 나머지 다섯을 절대 설정하지 않기 때문입니다.

해법은, 문서가 무엇을 위한 것인지 아는 애플리케이션이 매번 생성할 때 의도적으로 채워 보내는 것입니다.

실제 “브랜드화된 메타데이터“는 어떻게 생겼나

gPdf가 만들어내는 동일한 메타데이터 블록입니다. 6개 필드 모두 호출자가 덮어쓸 수 있습니다.

{
  "settings": {
    "metadata": {
      "title":    "Invoice INV-2026-3401",
      "language": "en",
      "author":   "Acme Logistics, Inc.",
      "subject":  "Monthly invoice — 2026-03",
      "creator":  "Acme Billing Platform v7.2",
      "producer": "Acme Billing Platform"
    }
  }
}

생성된 PDF에 같은 pdfinfo를 돌리면:

$ pdfinfo invoice.pdf
Title:           Invoice INV-2026-3401
Subject:         Monthly invoice — 2026-03
Author:          Acme Logistics, Inc.
Creator:         Acme Billing Platform v7.2
Producer:        Acme Billing Platform
Language:        en

페이지는 “Acme Logistics“로 표시되고 —— 파일 속성에도 “Acme Logistics“가 적혀 있습니다. 우클릭 → 속성을 열면 완전히 Acme의 것으로 보이는 문서입니다. 바이트가 약 4 ms 만에 gPdf 엣지에서 생성되었다는 사실은 수신자가 보는 어느 곳에도 드러나지 않습니다.

“고객이 우리가 gPdf 쓰는 걸 알고 싶어 하지 않나요?”

자주 나오는 질문이라 정면으로 답해두는 게 좋겠습니다.

네 —— 고객은 당연히 여러분이 gPdf 위에서 빌드하고 있다는 사실을 알아도 됩니다. 그건 여러분과 고객 사이의 일이고, 보통 엔지니어링 블로그, 변경 로그, 보안 아키텍처 문서, 또는 하위 처리자 목록(DPA와 관련 있다면 gPdf가 거기에 오릅니다)에 들어갈 이야기입니다.

Producer 필드는 그 관계를 다루는 자리가 아닙니다. 다루는 대상은 고객 문서의 최종 수신자 —— 조달 담당자, 운송 디스패처, 세무서 양식 처리 담당자 —— 입니다. 이들은 여러분의 PDF 생성기 선택과 아무런 관계도, 신경 쓸 이유도 없습니다. 그들에게 속성 대화창의 “Skia/PDF m120“은 잡음이고, “Acme Billing Platform“이 신호입니다.

부정직한 구석도 없습니다. PDF 사양은 Producer를 “원본 PDF를 생성한 애플리케이션의 이름“으로 정의합니다. gPdf 위에 PDF 서비스를 만들고 있다면, gPdf가 출고한 바이트를 만든 것은 여러분의 애플리케이션입니다. Producer에 그렇게 쓰는 건 정확한 표기입니다. 정직한 버전은 이렇습니다.

  • gPdf는 PDF 생성 인프라.
  • 여러분의 플랫폼이 producer.
  • 여러분의 고객이 author.

PDF 사양이 의도한 대로 각 계층이 자기 역할에 맞게 표기됩니다.

후속 처리 경로 관련 주석

출력 PDF가 수신자에게 닿기 전에 후처리 단계를 거친다면 —— 메타데이터 보존 플래그를 명시하지 않은 Ghostscript, 기업용 DRM / 워터마킹 도구, “PDF 옵티마이저” 등 —— 그중 일부는 조용히 Producer를 자기 이름으로 다시 쓰며, 방금 설정한 브랜드 메타데이터를 무효로 만듭니다. 원시 gPdf 응답이 아니라 실제 처리 경로에 대해 테스트하십시오.

여기에 없는 것에 대한 메모

정확을 기하면, 위의 6개 표준 필드가 현재 gPdf가 제공하는 전부입니다. 문서 속성을 화이트 라벨화한다 —— 브랜드 정체성 이야기 —— 에는 그것으로 충분합니다.

다만, 임의의 업무 맥락(주문 UUID, 창고 코드, 템플릿 버전)을 PDF에 넣어 후속 시스템이 읽게 하는 데에는 충분치 않습니다. 그건 별개의 보완 능력 —— XMP 사용자 정의 메타데이터 + 임의의 키-값 —— 으로, PDF 사양이 지원하며 개발 계획 항목으로 추적 중입니다. 오늘 당장 필요하다면 ID성 데이터는 PDF 내부보다 자사 플랫폼 DB에 파일명이나 해시를 키로 보관하는 편이 더 신뢰할 수 있습니다. 메타데이터는 문서의 정체성을 위한 것이지, PDF를 전송 계층 삼아 구조화된 업무 데이터를 옮기는 것을 위한 것이 아닙니다.

브랜드화된 메타데이터(오늘) ≠ 숨겨진 업무 데이터 흐름(별개). 자체 기획에서도 분리해 두는 게 좋습니다.

가능한 가장 작은 업그레이드

이미 /api/v1/pdf/render로 POST하고 있고, 현재 호출에 settings.metadata가 없다면, 가장 작은 개선은 이미 보내고 있는 JSON에 세 줄을 추가하는 것입니다.

 {
   "pages": [...],
   "settings": {
+    "metadata": {
+      "author":   "Your customer's organisation",
+      "producer": "Your platform"
+    }
   }
 }

두 필드, 새 키 하나. pdfinfo로 몇 초면 검증할 수 있습니다. 이게 들어간 다음에 시간이 될 때 title, language, subject, creator를 채우면 됩니다.

gPdf API에서 이 이야기가 닿는 지점

settings.metadata 안의 6줄이 전부입니다. 토큰별 정책으로 이 필드들을 제거하거나 기본값을 설정할 수도 있으므로, 멀티 테넌트 SaaS는 “고객이 만드는 모든 PDF가 올바르게 귀속되도록” 모든 API 호출자를 신뢰하지 않고도 강제할 수 있습니다.

보이는 페이지는 브랜드의 절반입니다. 파일 속성이 나머지 절반입니다. 플랫폼이 고객을 대신해 PDF를 출고한다면, 두 쪽 모두에 그들의 이름이 적혀 있어야 합니다.