PDF/A는 PDF의 보관용 형식입니다. 2026년에 보이는 문서가 2050년에도 같은 방식으로 표시된다는 보장을 위한 형식입니다. 주요 프로파일은 PDF/A-1, 2, 3, 4이고 각각 하위 준수 수준을 갖습니다. 그중 PDF/A-3는 EU 전자 인보이스를 조용히 떠받치는 프로파일이며, 널리 쓰이는 PDF/A 중 보관 래퍼 안에 임의의 파일 첨부를 허용하는 유일한 프로파일입니다.

인보이스, 규제 제출 문서, 또는 “PDF + 구조화 데이터” 처리 흐름을 다룬다면 PDF/A-3를 만나게 됩니다. 여기서는 PDF/A-3가 무엇인지, 다른 PDF/A 프로파일과 어떻게 다른지, 파일이 실제로 준수되는지 검증하는 방법을 설명합니다.

PDF/A 계열을 한 단락으로

프로파일	ISO 파트	연도	핵심 특징
PDF/A-1	19005-1	2005	최초 보관 프로파일. 투명도와 JavaScript 없음, 폰트 포함.
PDF/A-2	19005-2	2011	JPEG2000, 투명도, 레이어 지원 추가. 인쇄 충실도 향상.
PDF/A-3	19005-3	2012	내장 파일 첨부 추가. Factur-X / ZUGFeRD를 담는 래퍼.
PDF/A-4	19005-4	2020	현대적 개정판. 더 깔끔한 준수 모델, `b`와 `a` 구분 없음.

각 프로파일에는 하위 수준이 있습니다.

b (basic): 시각적 재현성을 보존합니다. 누구나 읽을 수 있지만 의미 콘텐츠 보장은 없습니다.
a (accessible): 구조 태그와 유니코드 매핑을 포함합니다. 스크린 리더가 올바른 순서로 텍스트를 추출할 수 있습니다.
u (Unicode): 유니코드 매핑은 있지만 전체 구조 태그는 없습니다. 중간 수준입니다.
e / f(PDF/A-4 전용): 엔지니어링 3D 콘텐츠와 전체 폼을 추가합니다.

따라서 “PDF/A-3b“는 보관 프로파일 3(첨부 파일 허용)과 basic 수준(접근성 태그 필수 아님)을 뜻합니다. 인보이스에서 가장 흔한 변형입니다.

PDF/A-3의 특별한 점

PDF/A-1과 PDF/A-2는 임의의 내장 파일을 금지합니다. 이유는 보관용 PDF가 자기완결적이어야 하기 때문입니다. 내장된 data.xlsx가 PDF와 별개로 훼손되면 보관 보장이 깨질 수 있습니다.

PDF/A-3는 엄격하게 제한된 조건에서 이 규칙을 명시적으로 완화합니다. 모든 내장 파일은 사람이 보는 PDF 내용과 어떤 관계인지 설명하는 AFRelationship 속성을 선언해야 합니다. 유효한 값은 Source, Data, Alternative, Supplement, Unspecified입니다. PDF 선언은 첨부 파일을 /AF 배열에도 나열해야 하고, 첨부 파일을 설명하는 XMP 메타데이터도 내보내야 합니다.

다시 말해 PDF/A-3는 *“첨부는 가능하지만, 그것이 정확히 무엇이고 사람이 보는 내용과 어떤 관계인지 선언해야 한다”*고 말합니다. 이 선언 덕분에 PDF/A-3가 전자 인보이스의 운반체가 되었습니다. 사람이 읽는 인보이스는 PDF에 들어가고, 기계가 읽는 EN 16931 CII XML은 첨부 파일에 들어가며, AFRelationship="Alternative"는 둘이 같은 인보이스의 대체 표현임을 선언합니다.

운영 환경에서 PDF/A-3가 쓰이는 곳

Factur-X(프랑스, 2026년부터 B2B 의무화): PDF/A-3 + CII XML, XMP 네임스페이스 urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#.
ZUGFeRD 2.x(독일, 2025년부터 수신 의무): PDF/A-3 + CII XML, XMP 네임스페이스 urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#.
엔지니어링 CAD 보관: 네이티브 CAD 파일을 첨부한 PDF/A-3. PDF는 표시 결과이고 CAD는 원본입니다.
규제 제출: XML 데이터를 첨부한 PDF/A-3(FDA 제출, EU 상장사의 ESEF 재무 보고서).

이 모든 경우에 래퍼는 단순한 컨테이너가 아닙니다. “이 PDF와 이 첨부 파일은 같은 문서이고, 둘 다 검증을 통과해야 한다“는 명시적 선언입니다.

파일이 PDF/A-3를 준수하는지 검증하는 방법

공식 준수 검증기는 PDF Association이 관리하는 veraPDF(verapdf.org)입니다. veraPDF는 ISO 19005-3 규칙 집합을 구현합니다. veraPDF가 “Pass — PDF/A-3b“라고 보고한다면, 단일 엔진이 줄 수 있는 가장 강한 신호입니다.

하지만 단일 엔진의 “Pass“는 감사 수준의 기준이 아닙니다(Why two PDF/A validators are better than one에서 이유를 설명합니다). 감사 수준의 패턴은 서로 독립적인 두 엔진을 실행하고, 둘 다 통과할 때만 파일을 준수로 보는 것입니다.

전자 인보이스 파일이라면 필요한 엔진이 하나 더 있습니다. Mustang(mustangproject.org)입니다. Mustang은 Factur-X / ZUGFeRD의 사실상 표준 검증기로, 내장된 CII XML을 EN 16931 Schematron에 대해 검증합니다. PDF/A-3 준수만으로는 충분하지 않습니다. 첨부 XML도 유효한 EN 16931이어야 하며, 그렇지 않으면 수신 측 AP 시스템이 인보이스를 거부합니다.

대부분의 팀은 Java를 설치하고, veraPDF CLI를 설정하고, Mustang을 설치한 뒤, 출력을 묶는 셸 스크립트를 작성합니다. 작동은 하지만 번거롭습니다.

validator 는 세 엔진을 모두 브라우저에서 실행합니다.

veraPDF: 공식 레퍼런스, PDF/A-3 준수.
gPdf의 Rust+WASM Edge 엔진: 독립 재구현, 두 번째 확인.
Mustang: 내장 전자 인보이스 데이터를 위한 EN 16931 CII XML Schematron.

파일을 올리면 세 엔진이 병렬로 실행되고, 보고서가 나란히 돌아옵니다. QA 증거로 쓸 JSON도 다운로드할 수 있습니다. 로그인도, 사용량 제한도 없습니다.

PDF/A-3 보고서에서 실제로 봐야 할 것

검증기를 실행했을 때 엔진 중 하나가 오류를 보고하면, 실패는 보통 몇 가지 영역에 모입니다.

내장 파일 메타데이터 누락 — /AF 배열이 없거나 내장 파일이 그 안에 나열되지 않았습니다.
AFRelationship 누락 또는 오류 — 전자 인보이스에서는 Alternative여야 합니다. 많은 PDF 라이브러리는 기본값으로 Source 또는 Data를 사용합니다.
XMP 네임스페이스 누락 또는 오류 — Factur-X와 ZUGFeRD에는 고정 네임스페이스 URI가 있으며, 한 글자 오타만 있어도 검증이 실패합니다.
폰트가 부분 집합으로 포함되지 않았거나 포함되지 않음 — PDF/A는 문서에서 사용한 모든 글리프를 폰트와 함께 포함해야 합니다. 경계 사례로, 선언되었지만 실제로 사용되지 않은 폰트 참조도 실패할 수 있습니다.
출력 의도 누락 — 문서가 순수 흑백 텍스트여도 PDF/A는 색상 의도(sRGB 또는 다른 ICC 프로파일)를 선언해야 합니다.
문서 메타데이터 불완전 — 문서 정보 사전에 /Title, /Producer, /CreationDate가 있어야 합니다.

각 항목에는 검증기 보고서가 가리키는 특정 사양 절이 있습니다. 생성 지점에서 수정해야 합니다. gPdf로 생성한다면 API가 이 항목들을 자동 처리하고, 검증기는 공개 증빙이 됩니다.

TL;DR

PDF/A-3 = PDF/A-2 + 임의의 파일을 합법적으로 내장할 수 있는 기능입니다. 이 기능 덕분에 EU 전자 인보이스가 실무적으로 가능해졌습니다. 사람이 읽는 인보이스와 구조화된 EN 16931 CII XML을 하나의 보관 래퍼에 담을 수 있기 때문입니다. 준수를 위해서는 래퍼가 PDF/A-3를 만족해야 하고, 첨부 XML도 EN 16931을 만족해야 합니다. 발송 전 둘 다 통과해야 합니다.

POST /api/v1/e-invoice/render로 생성하세요. validator에서 검증하세요. 세 엔진(veraPDF + gPdf Edge + Mustang), 한 번의 업로드, 무료입니다.