gPdf
블로그

엔지니어를 위한 PDF/A와 Factur-X 설명(법률 용어 없이)

PDF/A 프로파일이 실제로 무엇을 제약하는지, 왜 EU에서 2026년까지 Factur-X가 의무화되는지, 구조화 데이터 기반 PDF 생성기에서 준수 파일을 만드는 가장 작은 실무 파이프라인입니다.

gPdf 엔지니어링 팀
#pdf-a#factur-x#zugferd#e-invoice#compliance

엔지니어인 당신에게 방금 “다음 분기까지 인보이스가 PDF/A-3와 Factur-X여야 한다“는 요구가 내려왔고, 배경이라고는 법무팀 누군가가 그 말을 했다는 정도뿐이라면 이 글이 출발점입니다.

표준 문서 특유의 딱딱한 표현을 걷어내고, 이 프로파일들이 실제로 무엇을 제한하는지, 정부가 왜 이를 의무화하기 시작했는지, 구조화 데이터 기반 PDF 생성기에서 준수 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 생성기가 PDF/A-3b를 지원한다고 말한다면 단일 설정 플래그({ profile: "PDF/A-3b" } 또는 그에 준하는 설정)로 끝나야 합니다. 이후 변환을 위해 두 번째 도구(Ghostscript, qpdf, Acrobat)를 돌려야 한다면, 운영에서 고려해야 할 공백이 생긴 것입니다.

PDF/A-3가 특히 중요한 이유: 전자 인보이스를 담는 운반체

PDF/A-3는 세상을 바꾼 한 가지 기능을 추가했습니다. PDF 안에 임의의 파일을 첨부할 수 있는 기능입니다.

지루하게 들릴 수 있습니다. 하지만 그렇지 않습니다. 지금 유럽 전역에서 도입되는 전자 인보이스 의무화의 기술적 기반이 바로 이 기능입니다.

구조는 이렇습니다. 하나의 PDF 파일이 동시에

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

둘 다 같은 파일 안에 있고, 둘 다 같은 인보이스를 나타내며, PDF/A-3 래퍼는 그 파일이 수십 년 뒤에도 파싱 가능하도록 보장합니다.

주요 XML 형식은 두 가지입니다.

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

대부분의 처리 흐름에서 “Factur-X“와 “ZUGFeRD“는 서로 바꿔 써도 되는 용어입니다. 같은 스키마를 공유하고, 같은 내장 방식을 사용하며, 한쪽을 준수하는 단일 PDF는 대체로 다른 쪽도 준수합니다.

어디서, 언제, 무엇이 의무인가

2026년 2분기/3분기 출시를 계획하는 엔지니어를 위한 비포괄적 현황입니다.

국가 상태 필수 형식
독일 인보이스 수신은 2025-01-01부터 B2B 의무, 발행은 2027년부터 의무 EN 16931(Factur-X / ZUGFeRD / 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도 내보낼 수 있어야 합니다.

가장 작은 실무 파이프라인

표준 문서가 요구하는 표현은 잠시 잊고, 엔지니어 관점에서 보면 다음과 같습니다.

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

쉽지 않은 단계는 두 가지입니다.

단계 1: XML 생성

성가시지만 기계적인 작업입니다. 인보이스 데이터(라인, 세금, 합계, 거래 당사자)를 EN 16931 XML 필드 이름으로 매핑합니다. Java/Node/Python에는 이 일을 해 주는 라이브러리가 여럿 있습니다. 사용하는 언어에서 “factur-x library“를 검색해 보세요. XML 스키마 사양을 정말 즐기는 사람이 아니라면 처음부터 직접 작성하지 마세요.

단계 2: PDF/A-3 생성과 XML 첨부

여기서 PDF 생성기 선택이 중요합니다.

내장 지원이 없는 경우: 일반 PDF를 생성한 뒤, 후처리 도구로 PDF/A-3로 변환하고 XML을 내장 파일로 첨부해야 합니다. 흔한 조합은 Ghostscript + qpdf 또는 Aspose 같은 유료 도구입니다. 단계가 두 개 늘고, 실패 지점도 두 개 늘며, 후처리 과정에서 시각적 레이아웃이 달라지지 않는지도 확인해야 합니다.

내장 지원이 있는 경우(gPdf 방식): 한 번 호출하면 됩니다.

curl -X POST https://api.gpdf.com/api/v1/e-invoice/render \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "settings": {
      "profile": "pdfa-3b",
      "e_invoice": {
        "standard": "factur_x",
        "profile": "en16931",
        "document_type": "invoice",
        "xml": {
          "format": "cii",
          "encoding": "utf8",
          "content": "<?xml version=\"1.0\"?><rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
        }
      }
    },
    "pages": [{ "size": "a4", "elements": [/* invoice layout */] }]
  }' \
  --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 인보이스와 사람이 보는 인보이스는 같은 인보이스를 나타내야 합니다. 세무 감사자는 둘을 비교합니다. 코드가 XML에는 total: 119.00을 내보내고 시각적 PDF에는 Total: 120.00을 표시한다면(반올림 버그나 오래된 템플릿 때문), 파일에 세무 불일치가 남습니다. 둘 다 같은 기준 데이터에서, 가능하면 같은 코드 경로에서 생성하세요.

EN 16931의 “프로파일” 수준

Factur-X에는 MINIMUM, BASIC, EN 16931, EXTENDED 프로파일이 있습니다. 차이는 XML에 담기는 데이터의 양입니다. 고객이 더 높은 수준을 명시적으로 요구하지 않는다면 BASIC을 사용하세요. 세금 코드, 라인 항목, 거래 당사자, 합계를 포함하므로 B2B 인보이스의 약 95%에는 충분합니다. EN 16931 프로파일은 예외 사례를 위해 더 많은 세부 정보를 추가합니다.

제출 전 검증

세무 당국에 보내기 전에 생성된 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 생성기가 PDF/A-3 + Factur-X를 단일 설정 플래그로 처리한다면 마이그레이션은 기계적인 작업입니다. 그렇지 않다면 여러 단계의 운영 파이프라인을 직접 만들고 있는 것입니다. gPdf의 /api/v1/e-invoice/render는 단일 플래그 방식입니다. 전체 스키마는 API 레퍼런스에서 확인하거나 Playground에서 샘플 생성을 시도할 수 있습니다.