엔지니어이고 「인보이스가 다음 분기까지 PDF/A-3와 Factur-X여야 한다」는 말을 막 들었으며, 유일한 컨텍스트가 법무 부서의 누군가가 그 말을 한 것이라면, 이 글은 당신을 위한 것입니다.

표준화 문서 톤을 잘라내고 이 프로파일이 실제로 무엇을 제약하는지, 왜 정부가 의무화를 시작했는지, 구조화 데이터 렌더러에서 컴플라이언트 PDF를 발행하기 위한 가장 작은 실용 파이프라인을 설명합니다.

PDF/A를 두 단락으로

PDF는 유연한 형식입니다. 너무 유연 — 같은 PDF 사양으로 JavaScript 임베딩, 50년 후에는 존재하지 않을 외부 리소스 링킹, 가역 암호화로 콘텐츠 암호화, 외부 폰트 참조, 그리고 문서를 자체 포함되지 않게 하는 백 가지 다른 일을 할 수 있습니다.

PDF/A (「A」는 Archival)는 50년 후에도 동일하게 렌더링되는 것을 막는 부분을 금지하는 PDF의 프로파일입니다. 고수준 규칙:

모든 폰트가 임베디드되어야 함.
JavaScript 없음, 외부 링크 없음, 오디오/비디오 없음.
암호화 없음.
모든 투명도가 평탄화되거나 프로파일 버전에서 지원되어야 함.
색상은 디바이스 독립적이어야 함 (ICC 프로파일 필요).
모든 콘텐츠가 파일 안에 — 네트워크 의존 참조 없음.

여러 버전이 있으며, 각각 새 기능에 대한 허용 추가:

프로파일	연도	추가 사항
PDF/A-1b	2005	원본 베이스라인 — 가장 엄격
PDF/A-2b	2011	JPEG2000, 투명도, 레이어 허용
PDF/A-3b	2012	임의의 파일 첨부 허용 (Factur-X의 기반)
PDF/A-4	2020	ISO 32000-2 (PDF 2.0) 베이스, 단순화된 컴플라이언스 레벨

「b」 접미사는 「basic」 컴플라이언스 (시각적 충실도)를 의미합니다. 「u」 (유니코드 매핑) 및 「a」 (접근성 태그) 변형도 있지만, 대부분의 인보이스/영수증 워크플로우에서는 「b」가 원하는 것입니다. 세무 보존은 시각적 재현성을 신경 쓰며, 스크린 리더 시맨틱은 신경 쓰지 않습니다.

실용적 결론: 렌더러가 PDF/A-3b를 지원한다고 말하면, 그것은 단일 설정 플래그 ({ profile: "PDF/A-3b" } 또는 동등)이어야 합니다. 이후 변환을 위해 두 번째 도구 (Ghostscript, qpdf, Acrobat)를 실행해야 한다면, 그것은 ops에 고려할 워크플로우 갭입니다.

왜 PDF/A-3가 특히 중요한가: 전자세금계산서의 운반자이기 때문

PDF/A-3는 세계를 바꾸는 한 가지 기능을 추가했습니다: PDF 내의 임의의 파일 첨부.

지루하게 들립니다. 그렇지 않습니다. 그것은 지금 유럽에서 전개되는 전자세금계산서 의무의 전체 기술 기반입니다.

아키텍처: 둘 다인 단일 PDF 파일

사람이 읽을 수 있는 인보이스 (시각 레이아웃, 합계, 브랜딩) — 사람이 읽는 부분.
기계가 읽을 수 있는 XML 인보이스 — 세무 당국 소프트웨어가 파싱하는 부분.

둘 다 한 파일 안에, 둘 다 같은 인보이스를 표현하며, PDF/A-3 래퍼는 파일이 수십 년 동안 파싱 가능하게 유지되도록 보장합니다.

두 가지 주요 XML 형식:

Factur-X (프랑스) — UN/CEFACT Cross Industry Invoice 기반 XML 프로파일
ZUGFeRD (독일) — Factur-X와 실질적으로 동일 (두 표준은 2018년에 기술적으로 통합)
EN 16931 — 두 구현이 따르는 유럽 규범

대부분의 워크플로우에서 「Factur-X」와 「ZUGFeRD」는 호환 가능한 용어입니다 — 스키마 공유, 임베딩 메커니즘 공유, 한쪽에 컴플라이언트한 단일 PDF는 일반적으로 다른 쪽에도 컴플라이언트합니다.

의무 사항, 어디서, 언제

2026 Q2/Q3 롤아웃을 계획하는 엔지니어를 위한 비포괄적 스냅샷:

국가	상태	필수 형식
독일	B2B 수신 의무 2025-01-01부터; 2027년부터 발행도	EN 16931 (ZUGFeRD / Factur-X / XRechnung)
프랑스	대기업 발행 의무 2026-09; 중소기업 2027-09	Chorus Pro 경유 Factur-X
이탈리아	2019년부터 B2B 의무	SDI 경유 FatturaPA
폴란드	2024-07부터 의무	KSeF
스페인	2026년부터 의무 (B2B)	FACe 경유 Facturae
벨기에	2026-01부터 의무	Peppol BIS 3

패턴: 모든 EU 회원국이 2024–2027 타임라인에서 EN 16931 컴플라이언트 전자세금계산서의 어떤 변형을 구현하고 있습니다. 고객이 이 시장 중 어느 곳에서든 운영한다면, PDF 생성기는 시각 인보이스와 함께 첨부된 XML을 발행해야 합니다.

한국 팀을 위한: 한국 전자세금계산서 제도 (2011년 의무화)는 엄격한 PDF/A-3 + XML을 법적으로 요구하지 않지만, 글로벌 확장 시 같은 메커니즘으로 EN 16931 호환 형식을 생성할 수 있다는 것이 강력히 권장됩니다. Peppol도 2024년부터 한국에서 추진되고 있어 향후 B2B 거래에서 구조화된 인보이스 데이터 교환이 일반화될 전망입니다.

가장 작은 실용 파이프라인

표준화 문서가 처방하는 것을 잊으세요. 엔지니어 관점:

   ┌─────────────────────┐
   │  인보이스 데이터       │  (어딘가에 이미 JSON 객체)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ EN 16931 XML 빌드   │  (결정론적 매핑; 검증된 라이브러리 존재)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ PDF/A-3b 렌더링 +   │
   │ XML 첨부             │  (gPdf로의 단일 API 호출 — 또는 다른 곳에서 두 단계)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │  Chorus Pro / SDI / │
   │  Peppol 등으로 전달  │
   └─────────────────────┘

비자명한 두 단계:

단계 1: XML 빌드

이것은 짜증나지만 기계적입니다. 인보이스 데이터 (라인, 세금, 합계, 당사자)를 EN 16931 XML 필드 이름에 매핑합니다. 여러 Java/Node/Python 라이브러리가 이를 수행합니다 — 언어로 「factur-x library」를 검색하세요. XML 스키마 사양을 진정으로 즐기지 않는 한 처음부터 작성하지 마세요.

단계 2: PDF/A-3 렌더링 및 XML 첨부

여기서 렌더러 선택이 중요합니다.

내장 지원 없음: 일반 PDF를 렌더링한 다음 PDF/A-3로 변환하고 XML을 임베디드 파일로 첨부하는 도구로 후처리합니다. 일반적인 스택: Ghostscript + qpdf, 또는 Aspose 같은 유료 도구. 두 단계 추가, 두 실패 지점 추가, 후처리가 시각 레이아웃을 드리프트하지 않도록 해야 합니다.

내장 지원 있음 (gPdf의 접근): 한 번의 호출.

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-with-einvoice.pdf

이것이 전체 파이프라인입니다. 렌더러는 PDF/A-3b를 발행하고, XML을 factur-x.xml (또는 zugferd-invoice.xml, 둘 다 모든 소비자에게 인식됨)로 첨부하고, 바이트를 반환합니다.

일반적인 함정

사람들이 어렵게 배우는 몇 가지:

「PDF/A」와 「PDF/A 컴플라이언트 폰트로」는 같지 않다

PDF/A-3 파일은 사용된 글리프의 완전한 커버리지로 모든 폰트가 임베디드되어야 합니다. 인보이스에 외국 고객 이름이 있고 렌더러가 완전히 임베디드 가능하지 않은 폰트로 폴백하면, 검증 도구가 거부할 것입니다. 렌더러가 PDF/A 모드에서 CJK 폰트를 임베디드하는지 확인하세요 — 많은 것이 기본적으로 그렇지 않습니다.

시각적 + XML이 일치해야 한다

XML 인보이스와 시각적 인보이스는 같은 인보이스를 나타내야 합니다. 세무 감사관은 그것들을 diff할 것입니다. 코드가 total: 119.00으로 XML을 발행하고 시각적 PDF가 합계: 120.00을 표시하면 (반올림 버그나 오래된 템플릿 때문), 파일에 세금 불일치가 있습니다. 둘 다 같은 source-of-truth에서, 이상적으로는 같은 코드 경로에서 생성하세요.

EN 16931의 「프로파일」 레벨

Factur-X에는 프로파일이 있습니다: MINIMUM, BASIC, EN 16931, EXTENDED. XML에 얼마나 많은 데이터가 있는지가 다릅니다. 고객이 구체적으로 더 요구하지 않는 한 BASIC을 사용하세요 — 세금 코드, 라인 항목, 당사자, 합계를 다루며, B2B 인보이스의 ~95%에 충분합니다.

제출 전 검증

항상 생성된 PDF를 PDF/A 검증기 (veraPDF가 오픈 소스 표준)에 대해 검증하고 세무 당국에 제출하기 전에 XML을 EN 16931 스키마에 대해 검증하세요. Chorus Pro / SDI에 대한 실패한 제출은 규제 기관에서의 신뢰성 메트릭에 카운트됩니다.

TL;DR

PDF/A는 자체 포함 문서 프로파일입니다. PDF/A-3는 파일을 첨부할 수 있게 합니다. Factur-X / ZUGFeRD는 「PDF/A-3 안에 첨부된 EN 16931 XML」입니다. EU 전체의 전자세금계산서 의무는 이 조합을 2025–2027년의 사실상 B2B 인보이스 형식으로 만듭니다.

렌더러가 PDF/A-3 + Factur-X를 단일 설정 플래그로 처리한다면, 마이그레이션은 기계적입니다. 그렇지 않다면, 멀티스텝 ops 파이프라인을 구축하는 것입니다. gPdf의 /api/v1/e-invoice/render는 단일 플래그 버전입니다 — API 레퍼런스에 전체 스키마가 있거나, Playground에서 샘플 렌더링을 시도하세요.