PDF 파일 내부 구조 분석｜Header·xref·Trailer와 구조 검증 원리

디지털 파일 검증 연구소 2026년 10월 27일 읽는 시간 약 26분

PDF 파일은 문서의 글자와 이미지만 저장하는 단순한 형식이 아니다.

PDF(Portable Document Format)는 페이지, 글꼴, 이미지, 그래픽, 문서 정보 등을 객체(Object)로 표현하고, 이러한 객체 사이의 참조 관계를 통해 문서를 구성하는 파일 형식이다.

일반적으로 PDF 파일을 열면 완성된 문서 화면이 표시된다. 그러나 파일 내부에는 객체를 식별하는 번호, 데이터 스트림, 객체 위치를 찾기 위한 교차 참조 정보, 문서의 시작점을 지정하는 구조 등이 포함되어 있다.

이러한 구조를 이해하면 PDF 파일이 정상적으로 구성되어 있는지 확인하고, 일부 손상이나 구조적 이상을 분석하는 데 도움이 된다.

이번 글에서는 PDF 파일 구조 분석을 중심으로 Header, Body, xref, Trailer, startxref, %%EOF의 역할을 살펴보고, Windows PowerShell을 이용해 파일의 기본 구조를 확인하는 방법을 설명한다.

또한 PDF 1.5 이후의 xref stream, 증분 업데이트, 구조 검증과 SHA-256 무결성 검증의 차이까지 정리한다.

1. PDF 파일 구조 분석이 필요한 이유

PDF는 운영체제와 프로그램 환경이 달라도 문서의 레이아웃을 비교적 일관되게 표현하기 위해 널리 사용되는 형식이다.

그러나 확장자가 .pdf라고 해서 모든 파일이 정상적인 PDF 구조를 갖추고 있는 것은 아니다.

다음과 같은 상황에서는 PDF의 내부 구조를 확인할 필요가 있다.

PDF 파일이 열리지 않거나 오류 메시지가 표시되는 경우
문서의 일부 페이지만 정상적으로 표시되는 경우
파일 전송 후 손상이 의심되는 경우
PDF 확장자를 가진 파일의 실제 형식을 확인하려는 경우
파일 내부 객체와 참조 관계를 분석하려는 경우
문서가 여러 차례 수정되었을 가능성을 조사하는 경우

PDF 구조 분석은 파일의 내부 구성 요소를 확인하는 작업이다.

반면 파일의 SHA-256 해시값을 비교하는 작업은 파일의 바이트 단위 동일성을 확인하는 작업이다.

두 방법은 목적이 다르며, PDF 구조가 정상이라고 해서 파일이 변경되지 않았다는 사실까지 증명되는 것은 아니다.

2. PDF 파일의 기본 구성 요소

전통적인 PDF 파일 구조는 크게 네 부분으로 설명할 수 있다.

구성 요소	주요 역할
Header	PDF 형식과 버전 식별
Body	페이지와 문서 구성에 필요한 객체 저장
Cross-reference	객체의 위치를 찾기 위한 참조 정보
Trailer	문서의 주요 객체와 교차 참조 구조를 찾기 위한 정보

이 네 부분은 PDF의 기본 구조를 이해하기 위한 개념적 구분이다.

실제 PDF에서는 교차 참조 테이블 대신 xref stream을 사용하거나, 수정 내용을 파일 끝에 추가하는 방식으로 여러 교차 참조 구간이 존재할 수 있다.

PDF 구조의 개념적 흐름

PDF Header
    |
    v
PDF Body
    |-- Catalog Object
    |-- Pages Object
    |-- Page Object
    |-- Content Stream
    |-- Font / Image Objects
    |
    v
Cross-reference Information
    |
    v
Trailer Information
    |
    v
startxref
    |
    v
%%EOF

이 구조는 이해를 위한 단순화된 예시다.

실제 PDF 객체의 저장 순서가 위 도식과 반드시 일치하는 것은 아니며, 모든 PDF가 텍스트 형태의 xref와 trailer 키워드를 갖는 것도 아니다.

3. PDF Header 구조와 버전 식별

PDF Header는 파일 형식과 버전을 식별하기 위한 정보다.

일반적인 PDF 헤더의 예시는 다음과 같다.

%PDF-1.7

%PDF-는 PDF 형식을 나타내는 특징적인 문자열이며, 뒤의 숫자는 헤더에 선언된 PDF 버전을 의미한다.

대표적인 헤더 예시는 다음과 같다.

헤더 문자열	의미
`%PDF-1.4`	PDF 1.4 형식 선언
`%PDF-1.5`	PDF 1.5 형식 선언
`%PDF-1.7`	PDF 1.7 형식 선언
`%PDF-2.0`	PDF 2.0 형식 선언

PDF 헤더의 16진수 표현

%PDF- 문자열은 ASCII 기준으로 다음 바이트에 해당한다.

25 50 44 46 2D

각 바이트는 다음 문자를 나타낸다.

16진수	ASCII 문자
`25`	`%`
`50`	`P`
`44`	`D`
`46`	`F`
`2D`	`-`

헤더 확인만으로 충분하지 않은 이유

PDF 헤더가 존재한다는 사실은 PDF 형식의 가능성을 판단하는 출발점이다.

그러나 파일 시작 부분에 %PDF-1.7이라는 문자열이 있다는 이유만으로 파일 전체가 정상이라고 판단할 수는 없다.

실제 검증에서는 객체 구조, 교차 참조 정보, 문서 카탈로그, 스트림 데이터 등을 추가로 확인해야 한다.

또한 헤더에 선언된 버전과 실제 문서에서 사용하는 기능의 관계도 고려해야 한다.

따라서 헤더 확인은 파일 형식 식별의 첫 단계이지, 완전한 구조 검증 절차는 아니다.

4. PDF Body와 간접 객체의 구조

PDF Body에는 문서를 구성하는 여러 객체가 저장된다.

PDF에서는 숫자, 문자열, 배열, 딕셔너리, 스트림 등의 데이터 유형을 사용한다.

특히 간접 객체(Indirect Object)는 객체 번호와 세대 번호를 통해 다른 객체에서 참조할 수 있다.

간접 객체의 기본 형태

1 0 obj
<<
  /Type /Catalog
  /Pages 2 0 R
>>
endobj

위 예시의 의미는 다음과 같다.

구성	의미
`1`	객체 번호
`0`	세대 번호
`obj`	간접 객체 시작
`/Type /Catalog`	문서 카탈로그 객체임을 표시
`/Pages 2 0 R`	다른 간접 객체에 대한 참조
`endobj`	객체 종료

2 0 R은 객체 번호 2, 세대 번호 0인 간접 객체를 참조한다는 의미다.

이러한 참조 관계를 이용해 PDF 문서의 페이지 트리와 다양한 리소스가 연결된다.

Catalog 객체의 역할

Catalog는 PDF 문서 구조의 최상위 진입점 역할을 하는 객체다.

문서의 페이지 트리 등 주요 구성 요소에 대한 참조 정보를 제공한다.

교차 참조 구조에서 Catalog 객체를 찾을 수 있어야 PDF 처리 프로그램이 문서의 주요 구조를 해석하는 데 도움이 된다.

Page와 Pages 객체의 차이

PDF에서는 개별 페이지를 나타내는 Page 객체와 여러 페이지를 계층적으로 관리하는 Pages 객체를 구분한다.

Pages 객체는 페이지 트리를 구성하며, Page 객체는 개별 페이지의 내용과 리소스 등을 참조한다.

따라서 PDF 내부에 페이지 관련 객체가 여러 개 존재하는 것은 일반적인 구조다.

5. PDF Stream 객체와 데이터 저장 방식

PDF는 문서 내용을 저장할 때 스트림(Stream) 객체를 사용한다.

스트림은 페이지 내용, 이미지 데이터, 글꼴 관련 데이터 등을 저장하는 데 활용될 수 있다.

스트림 구조의 예시

5 0 obj
<<
  /Length 12
>>
stream
Hello World!
endstream
endobj

위 예시는 스트림의 구조를 설명하기 위한 단순화된 형태다.

/Length는 스트림 데이터의 바이트 길이를 나타내며, 실제 값은 스트림의 인코딩과 바이트 구성에 맞아야 한다.

스트림과 압축

PDF 스트림에는 압축 또는 인코딩 필터가 적용될 수 있다.

예를 들어 /FlateDecode는 PDF에서 사용되는 대표적인 압축 해제 필터다.

압축된 스트림은 일반 텍스트 편집기에서 내용을 바로 읽기 어려울 수 있다.

따라서 PDF를 텍스트로 열었을 때 의미를 알 수 없는 문자나 데이터가 보인다고 해서 파일이 손상되었다고 단정해서는 안 된다.

스트림 분석 시 주의사항

스트림을 검증할 때는 다음 요소를 고려해야 한다.

스트림 딕셔너리의 속성
/Length 값과 실제 데이터 범위
적용된 필터
객체 참조 관계
데이터의 압축 및 인코딩 방식

이러한 요소를 종합적으로 해석해야 스트림 구조의 정상 여부를 판단할 수 있다.

6. PDF xref 테이블의 역할

xref는 Cross-reference의 약어로, PDF 내부 객체의 위치를 찾는 데 사용되는 교차 참조 정보다.

전통적인 PDF 구조에서는 xref 키워드로 시작하는 교차 참조 테이블이 사용된다.

xref 테이블 예시

xref
0 3
0000000000 65535 f
0000000015 00000 n
0000000089 00000 n

이 예시는 교차 참조 테이블의 형식을 보여주기 위한 것이다.

실제 파일에서는 각 바이트 오프셋이 해당 객체의 정확한 위치를 가리켜야 한다.

xref 항목의 의미

구성	의미
`xref`	교차 참조 테이블 시작
`0 3`	객체 번호 0부터 3개 항목을 기술
첫 번째 숫자 필드	객체 위치 또는 자유 항목 관련 정보
두 번째 숫자 필드	세대 번호
`n`	사용 중인 객체 항목
`f`	자유 항목

일반적인 사용 중 객체 항목의 첫 번째 숫자 필드는 파일 시작점에서 해당 간접 객체까지의 바이트 오프셋을 나타낸다.

xref 정보가 중요한 이유

PDF 처리 프로그램은 교차 참조 정보를 이용해 필요한 객체를 효율적으로 찾을 수 있다.

교차 참조 정보가 잘못되면 객체를 찾지 못하거나 문서 해석에 문제가 발생할 수 있다.

다만 일부 PDF 프로그램은 손상된 교차 참조 정보를 복구하거나 재구성해 문서를 열기도 한다.

따라서 PDF가 열리는지 여부만으로 교차 참조 정보가 완전히 정상이라고 판단해서는 안 된다.

7. PDF Trailer와 startxref 구조

전통적인 PDF 파일의 Trailer는 문서의 주요 객체를 찾는 데 필요한 정보를 제공한다.

대표적으로 /Root와 /Size 등의 항목이 사용된다.

Trailer 구조 예시

trailer
<<
  /Size 3
  /Root 1 0 R
>>
startxref
125
%%EOF

위 코드는 구조 설명을 위한 예시이며, 실제 파일에서는 125가 교차 참조 정보의 정확한 시작 바이트 위치여야 한다.

주요 항목의 의미

항목	역할
`trailer`	전통적인 Trailer 딕셔너리 시작
`/Size`	교차 참조 항목의 번호 범위에 관한 정보
`/Root`	문서 Catalog 객체 참조
`startxref`	교차 참조 정보의 시작 위치 지정
`%%EOF`	PDF 파일의 종료를 나타내는 마커

startxref의 역할

startxref 다음에 기록되는 숫자는 마지막 교차 참조 구간의 시작 위치를 나타낸다.

전통적인 xref 테이블을 사용하는 파일에서는 일반적으로 xref 키워드의 위치를 가리킨다.

xref stream을 사용하는 파일에서는 해당 교차 참조 스트림 객체의 시작 위치를 가리킨다.

따라서 startxref가 반드시 문자 그대로의 xref 키워드를 가리킨다고 이해하면 안 된다.

%%EOF의 의미

%%EOF는 PDF 파일의 종료를 나타내는 마커다.

정상적인 PDF 구조를 확인할 때 중요한 단서가 되지만, 이 문자열이 존재한다는 사실만으로 파일 전체의 유효성이 보장되지는 않는다.

8. PDF 1.5 이후의 xref stream 구조

PDF 1.5부터는 전통적인 교차 참조 테이블 대신 xref stream을 사용할 수 있다.

xref stream은 교차 참조 정보를 스트림 객체 형태로 저장하는 방식이다.

xref stream의 개념적 예시

12 0 obj
<<
  /Type /XRef
  /Size 13
  /W [1 4 2]
  /Length ...
>>
stream
...
endstream
endobj

이 예시는 필수적인 구조 개념을 보여주기 위한 것으로, 완전한 PDF 파일이나 실행 가능한 샘플은 아니다.

xref stream의 특징

교차 참조 정보를 스트림 형태로 표현할 수 있다.
객체 위치와 상태를 보다 압축된 형태로 저장할 수 있다.
객체 스트림에 저장된 압축 객체를 참조할 수 있다.
전통적인 xref 및 trailer 키워드가 없는 PDF도 존재할 수 있다.

xref stream에서는 Trailer에 해당하는 주요 정보가 스트림 딕셔너리에 포함된다.

따라서 파일 내부에서 xref라는 문자열이 검색되지 않는다고 해서 PDF 구조가 잘못되었다고 단정해서는 안 된다.

9. 증분 업데이트와 PDF 수정 이력

PDF는 기존 파일 내용을 모두 다시 작성하지 않고, 수정된 정보를 파일 끝에 추가하는 증분 업데이트(Incremental Update)를 지원한다.

이 방식에서는 이전 객체와 교차 참조 정보가 파일 내부에 남아 있을 수 있다.

증분 업데이트의 개념

[Original PDF Objects]
[Original xref / Trailer]
[startxref / %%EOF]

[Updated Objects]
[New xref / Trailer]
[New startxref / %%EOF]

위 도식은 전통적인 교차 참조 테이블을 사용하는 증분 업데이트의 단순화된 예시다.

/Prev 항목의 역할

증분 업데이트가 적용된 PDF에서는 이전 교차 참조 구간을 가리키는 /Prev 항목이 사용될 수 있다.

이를 통해 PDF 처리 프로그램은 이전 교차 참조 정보와 새로 추가된 정보를 연결해 해석할 수 있다.

EOF 마커가 여러 개 발견되는 경우

파일 내부에서 %%EOF 문자열이 여러 번 발견될 수 있다.

이는 증분 업데이트의 결과일 가능성이 있다.

그러나 %%EOF 문자열이 여러 개 있다는 사실만으로 실제 수정 횟수나 수정 내용을 확정할 수는 없다.

정확한 분석을 위해서는 교차 참조 구간, 객체 참조 관계, 증분 업데이트 체인 등을 함께 검토해야 한다.

10. Windows PowerShell로 PDF Header 확인하기

이제 Windows에서 PDF 파일의 시작 바이트를 확인해 보자.

이번 실습은 파일 내용을 수정하지 않고 읽기 전용으로 확인하는 방식이다.

① 실습 파일 준비

검사할 PDF 파일을 다음 경로에 준비했다고 가정한다.

C:\FileTest\sample.pdf

실제 실행할 때는 본인 컴퓨터에 존재하는 PDF 파일 경로로 변경해야 한다.

② PowerShell 실행

Windows에서 PowerShell을 실행한 뒤 다음 코드를 입력한다.

$path = "C:\FileTest\sample.pdf"
$stream = [System.IO.File]::OpenRead($path)

try {
    $buffer = New-Object byte[] 16
    $count = $stream.Read($buffer, 0, $buffer.Length)

    if ($count -gt 0) {
        $bytes = $buffer[0..($count - 1)]
        [BitConverter]::ToString($bytes)
        [System.Text.Encoding]::ASCII.GetString($bytes)
    }
}
finally {
    $stream.Dispose()
}

③ 결과 해석

PDF 1.7 파일의 시작 부분에서는 다음과 같은 바이트가 확인될 수 있다.

25-50-44-46-2D-31-2E-37

ASCII로 해석하면 다음 문자열에 해당한다.

%PDF-1.7

단, 실제 파일의 헤더 버전은 다를 수 있다.

이 실습은 파일 시작 부분의 바이트를 확인하는 것이며, 전체 PDF 구조를 검증하는 절차는 아니다.

11. PDF 파일 끝부분에서 startxref와 EOF 확인하기

PDF의 마지막 교차 참조 정보를 찾기 위해 파일 끝부분을 확인할 수 있다.

다음 예시는 PowerShell에서 PDF 파일의 마지막 최대 4,096바이트를 읽는 방법이다.

① 파일 끝부분 확인 코드

$path = "C:\FileTest\sample.pdf"
$stream = [System.IO.File]::OpenRead($path)

try {
    $length = [Math]::Min(4096, $stream.Length)

    if ($length -gt 0) {
        $stream.Seek(-$length, [System.IO.SeekOrigin]::End) | Out-Null

        $buffer = New-Object byte[] ([int]$length)
        $count = $stream.Read($buffer, 0, $buffer.Length)

        if ($count -gt 0) {
            $text = [System.Text.Encoding]::GetEncoding(28591).GetString(
    $buffer, 0, $count
            )

            $text
        }
    }
}
finally {
    $stream.Dispose()
}

② 확인할 문자열

출력 결과에서 다음 문자열을 확인한다.

startxref
%%EOF

전통적인 PDF 파일에서는 다음과 같은 종료 구조를 확인할 수 있다.

startxref
123456
%%EOF

여기서 123456은 예시 숫자다.

실제 PDF에서는 교차 참조 정보가 시작되는 바이트 위치에 따라 값이 달라진다.

③ 실습 결과의 한계

파일의 마지막 4,096바이트를 확인하는 방법은 구조를 살펴보기 위한 간단한 실습이다.

이 방법만으로 다음 사항을 보장할 수는 없다.

전체 객체의 정상 여부
모든 xref 항목의 정확성
스트림 데이터의 무결성
PDF의 안전성
파일이 과거에 수정되지 않았다는 사실

또한 PDF의 구조가 복잡하거나 특수한 저장 방식이 적용된 경우에는 단순 문자열 확인만으로 정확하게 해석하기 어렵다.

실제 구조 검증에서는 PDF 규격을 이해하는 전용 파서가 필요하다.

12. PDF 구조 검증 시 발견할 수 있는 주요 오류

PDF 구조 분석 과정에서는 다양한 오류나 이상 징후가 발견될 수 있다.

확인 항목	의심할 수 있는 문제
PDF Header 이상	형식 불일치 또는 파일 손상 가능성
객체 시작·종료 구조 이상	객체 구문 오류 가능성
xref 오프셋 불일치	객체 참조 실패 가능성
Trailer 정보 이상	문서 주요 객체 식별 문제
startxref 값 이상	교차 참조 정보 탐색 문제
스트림 길이·필터 이상	스트림 해석 실패 가능성
비정상적인 참조 관계	문서 구성 오류 가능성

이 표는 점검 방향을 설명하기 위한 것이다.

각 항목에 이상이 발견되었다고 해서 반드시 파일이 악의적으로 조작되었다는 의미는 아니다.

PDF 생성 프로그램의 차이, 파일 전송 오류, 부분 손상, 비표준 구현 등 여러 원인이 있을 수 있다.

PDF가 열린다고 해서 구조가 완전히 정상인 것은 아니다

일부 PDF 뷰어는 오류가 있는 파일도 가능한 범위에서 복구해 표시한다.

따라서 화면에 문서가 정상적으로 보인다는 사실만으로 모든 내부 객체와 참조 정보가 정상이라고 판단해서는 안 된다.

13. PDF 구조 검증과 SHA-256 무결성 검증의 차이

PDF 파일을 검증할 때는 구조 분석과 해시 검증을 구분해야 한다.

구분	PDF 구조 분석	SHA-256 검증
주요 목적	PDF 내부 구성 확인	파일 바이트 동일성 확인
확인 대상	Header, 객체, xref, Trailer 등	파일 전체 바이트
구조 오류 탐지	가능	직접 판단하지 못함
동일 파일 비교	직접적인 목적이 아님	적합
악성 코드 탐지	별도 분석 필요	별도 분석 필요
원본 진위 확인	단독으로 불충분	신뢰할 수 있는 기준값 필요

예시 1. 구조는 정상인데 파일이 변경된 경우

PDF를 정상적으로 수정한 뒤 저장하면 내부 구조가 유효한 상태를 유지할 수 있다.

하지만 파일의 바이트가 변경되었으므로 이전 파일과 SHA-256 해시값이 달라질 수 있다.

예시 2. SHA-256 값이 일치하지만 PDF 구조에 문제가 있는 경우

동일한 손상 파일을 두 위치에 복사하면 두 파일의 SHA-256 해시값은 일치할 수 있다.

그러나 두 파일 모두 같은 구조적 오류를 가지고 있을 수 있다.

예시 3. 기준 해시값이 없는 경우

PDF 파일 하나의 SHA-256 해시값을 계산하는 것만으로는 그 파일이 원본과 동일한지 확인할 수 없다.

검증을 위해서는 신뢰할 수 있는 원본 파일 또는 기준 해시값이 필요하다.

PDF 구조 검증과 SHA-256 검증은 서로 보완적인 검사 방법이다.

14. PDF 분석 시 보안 및 검증 주의사항

① 출처가 불분명한 PDF는 주의해야 한다

PDF는 단순한 정적 문서뿐 아니라 링크, 양식, 주석, 일부 스크립트 기능 등 다양한 요소를 포함할 수 있다.

따라서 출처가 불분명한 PDF는 신뢰할 수 있는 최신 PDF 뷰어와 적절한 보안 환경에서 다뤄야 한다.

② 텍스트 편집기로 파일을 수정하지 않는다

PDF 내부를 확인하기 위해 텍스트 편집기로 파일을 열 수는 있지만, 임의로 내용을 변경해 저장하면 파일 구조가 손상될 수 있다.

원본 파일을 보존하고 별도의 복사본으로 분석하는 것이 좋다.

③ 구조 검증과 디지털 서명 검증은 다르다

PDF의 내부 구조가 정상이라는 사실은 디지털 서명이 유효하다는 의미가 아니다.

전자서명이 포함된 PDF에서는 서명 범위, 인증서, 서명 이후의 변경 여부 등을 별도로 확인해야 한다.

④ 단일 검사 결과로 결론을 내리지 않는다

헤더, xref, Trailer, 해시값, 디지털 서명 등은 각각 다른 정보를 제공한다.

따라서 분석 목적에 맞는 여러 검증 결과를 종합적으로 해석해야 한다.

15. 자주 묻는 질문

Q1. PDF 파일의 시작 바이트는 무엇인가요?

일반적인 PDF 헤더는 %PDF- 문자열로 시작하며, ASCII 기준 16진수 바이트는 25 50 44 46 2D다. 뒤에는 PDF 버전 정보가 이어진다.

Q2. PDF 파일에 xref가 없으면 손상된 파일인가요?

반드시 그렇지는 않다. PDF 1.5 이후에는 xref stream을 사용할 수 있으므로 전통적인 xref 키워드가 없는 정상적인 PDF도 존재할 수 있다.

Q3. startxref는 무엇을 의미하나요?

PDF의 마지막 교차 참조 정보가 시작되는 바이트 위치를 나타낸다. 전통적인 xref 테이블 또는 xref stream을 가리킬 수 있다.

Q4. %%EOF가 여러 개 있으면 비정상인가요?

반드시 그렇지는 않다. PDF의 증분 업데이트로 인해 여러 종료 마커가 존재할 수 있다. 정확한 해석에는 업데이트 구조 확인이 필요하다.

Q5. PDF가 정상적으로 열리면 파일 무결성이 확인된 것인가요?

아니다. PDF 뷰어가 문서를 표시할 수 있다는 사실은 원본과 파일 바이트가 동일하다는 증거가 아니다. 원본과의 동일성 확인에는 적절한 해시값 비교 등이 필요하다.

Q6. PDF 구조를 확인하면 악성 파일인지 알 수 있나요?

구조 분석을 통해 일부 이상 징후를 발견할 수는 있지만, 그것만으로 악성 여부를 확정할 수는 없다. 보안 분석에는 추가적인 검사와 적절한 분석 환경이 필요하다.

마무리

PDF 파일은 Header, 객체, 교차 참조 정보, Trailer 등 여러 구성 요소가 연결되어 동작하는 문서 형식이다.

Header는 파일 형식을 식별하는 출발점이며, Body의 객체들은 실제 문서 내용을 구성한다.

교차 참조 정보는 객체를 찾는 데 사용되고, Trailer와 startxref는 문서의 주요 구조를 해석하는 데 필요한 정보를 제공한다.

다만 PDF 1.5 이후에는 xref stream이 사용될 수 있고, 증분 업데이트로 인해 파일 내부에 여러 교차 참조 구간이 존재할 수 있다.

따라서 PDF 파일 구조 분석은 단순히 헤더와 EOF 문자열을 찾는 작업을 넘어 객체와 참조 관계를 종합적으로 검증하는 과정으로 이해해야 한다.

또한 PDF 구조가 정상이라는 사실과 원본 파일이 변경되지 않았다는 사실은 서로 다르다.

정확한 파일 검증을 위해서는 PDF 구조 분석과 SHA-256 해시 검증, 필요한 경우 디지털 서명 검증 등을 목적에 맞게 함께 활용해야 한다.

핵심 내용 3줄 요약

PDF는 Header, 객체, 교차 참조 정보, Trailer 등을 통해 문서 구조를 관리한다.
PDF 1.5 이후에는 xref stream이 사용될 수 있으며, 증분 업데이트로 여러 교차 참조 구간이 존재할 수 있다.
PDF 구조가 정상이라는 사실만으로 파일 무결성이나 원본 진위가 증명되지는 않는다.

공식 참고자료

Adobe — PDF Reference, Version 1.7
https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/pdfreference1.7old.pdf
PDF Association — PDF Basics Cheat Sheet
https://pdfa.org/download-area/cheat-sheets/Basics.pdf
PDF Association — ISO 32000-2 Syntax Errata
https://pdf-issues.pdfa.org/32000-2-2020/clause07.html

※ 본문의 코드와 구조 예시는 PDF 내부 형식을 이해하기 위한 교육용 자료다. 실제 PDF의 버전, 생성 프로그램, 압축 및 업데이트 방식에 따라 내부 구성은 달라질 수 있다.

디지털 파일 검증 연구소

디지털 파일 검증 연구소는 파일 형식, 확장자, 무결성 확인, 데이터 손상 예방 및 디지털 자료 관리 방법을 다루는 정보 사이트입니다. 파일 오류의 원인과 점검 절차를 이해하기 쉽게 정리하고, 공식 문서와 검증 가능한 자료를 바탕으로 실생활에 도움이 되는 해결 방법을 안내합니다.