표준 지형

Spec: ISO 32000-2 Spec: ETSI EN 319 142-1 Spec: RFC 3161 Spec: WCAG 2.2 Evidence: Standard-backed

한눈에 보기

PDF 엔진은 하나의 문서만 따르지 않습니다. 서로 다른 기관이 작성하고 서로를 참조하는 작은 표준 연합체에 응답합니다. 이 페이지는 NextPDF가 추적하는 그 연합체의 지도입니다. 또한 하나의 조항이 “표준이 그렇게 정한다”에서 “엔진이 그렇게 동작하며, 테스트가 그것을 증명한다”로 이어지는 경로를 보여 줍니다.

이 글은 어떤 동작을 어느 문서가 규율하는지 알아야 NextPDF의 해석을 자신 있게 옹호할 수 있는지 판단할 수 있는 시니어 엔지니어를 위해 작성되었습니다.

왜 중요한가

“PDF 지원”은 하나의 질문을 가리는 주장입니다. 정확히 무엇을 지원하느냐입니다. 핵심 구문은 ISO 32000-2가 규율합니다. 서명은 ETSI를 경유합니다. 타임스탬프는 IETF 프로토콜입니다. 엔진이 렌더링하는 HTML과 CSS는 W3C가 규율합니다. 그 아래의 암호화는 NIST가 담당합니다. 출력물 접근성은 다시 W3C가 담당합니다.

라이브러리가 이것들을 구분되지 않은 하나의 덩어리로 취급한다면 실패를 추론할 수 없습니다. 검증기가 서명된 인보이스를 거부할 때 가장 먼저 던져야 할 유용한 질문은 “PDF가 깨졌는가”가 아닙니다. “어느 표준의 어느 조항이 충족되지 않았으며, 어느 쪽에서 발생했는가”입니다. 그 질문을 던지려면 기관 이름을 명시한 지도와, 조항이 어떻게 동작으로 바뀌는지에 대한 정직한 설명이 필요합니다.

요약

NextPDF는 다섯 개의 표준 기관을 추적합니다. ISO는 형식을 소유합니다. ETSI는 유럽 서명 프로파일을 소유합니다. IETF는 와이어 프로토콜(타임스탬프 및 참조로 끌어오는 암호화 기본 요소)을 소유합니다. W3C는 HTML, CSS 및 접근성 기준을 소유합니다. NIST는 승인된 암호화 알고리즘을 소유합니다.
이 문서들은 단순한 목록이 아니라 자취를 이룹니다. 하나의 서명된 PDF 기능은 ISO → ETSI → IETF → NIST를 거치며, 각 계층이 다음 계층을 규범적으로 참조합니다.
조항은 읽힌다고 해서 곧바로 동작이 되지 않습니다. 조항은 풀어 쓰고 인용되며, 요구사항에 매핑되고, 구현되며, 테스트로 고정될 때 동작이 됩니다. 그 동작을 기술하는 페이지는 자신의 근거 수준으로 그것을 명시합니다.
필수 조항에는 규범 키워드(shall, must)가 따라옵니다. NextPDF는 그 키워드들을 계약으로 취급합니다. should는 보장이 아니라 권고로 문서화되는 권장 사항입니다.

NextPDF 의 접근 방식

덩어리가 아닌 연합체

ISO 32000-2가 중심입니다. 이 표준은 적합한 파일이 무엇인지 정의합니다. 적합한 파일은 문서의 모든 요구사항을 준수해야 하며, 문서가 명시적으로 요구하지 않는 기능은 자유롭게 생략할 수 있습니다 Spec: ISO 32000-2, §6 . 또한 작성자에게도 의무를 부여합니다. NextPDF가 파일에서 생성하거나 수정하는 모든 것은 형식에 적합해야 하며, 이미 존재하는 요소들과 일관성을 유지해야 합니다 Spec: ISO 32000-2, §6 . 바로 그 단일 조항이 엔진이 구조적으로 일관성 없는 증분 업데이트를 내보내기를 거부하는 이유입니다. 이것은 NextPDF의 선호가 아닙니다. 형식 자체의 규칙입니다.

그 중심에서 ISO 32000-2는 외부를 가리킵니다. PAdES에 대한 서명 처리는 ETSI EN 319 142 시리즈를 “참조하는 방식으로” 정의됩니다. ETSI는 다시 타임스탬프 토큰에 대해 IETF RFC 3161을, 해시 및 서명 알고리즘에 대해 NIST FIPS 시리즈를 참조합니다. 따라서 하나의 기능은 여러 문서를 거치는 경로이며, 각 문서는 자신의 계층에 대해 규범적입니다.

Step 1 of 5: ISO 32000-2 §12.8 signatures
Step 2 of 5: ETSI EN 319 142-1 PAdES baseline
Step 3 of 5: RFC 3161 timestamp token
Step 4 of 5: NIST FIPS 180-4 hash strength
Step 5 of 5: WCAG 2.2 tagged output

하나의 장기 검증 가능한 서명된 PDF 가 거치는 표준 자취입니다. ISO 는 컨테이너를 정의하고 서명 프로파일에 대해 ETSI 를 가리킵니다. ETSI 는 IETF 타임스탬프를 요구합니다. 암호화 기본 요소는 NIST 승인을 받습니다. 렌더링된 출력물은 W3C 접근성을 충족해야 합니다. 각 화살표는 느슨한 연관이 아니라 규범적 참조입니다.

조항이 어떻게 동작으로 바뀌는가

표준 작업에서 위험한 방식은 조항을 읽은 뒤 그 기억에 의존해 코드를 작성하는 것입니다. NextPDF의 경로는 의도적으로 더 깁니다. 그 긴 경로가 곧 감사 가능한 경로이기 때문입니다.

Retrieve The clause is read from the standard, not from memory.
Cite It is paraphrased and pinned with a chunk digest, never quoted.
Classify Its keyword (shall / should / may) sets whether it is a contract or a recommendation.
Map The obligation becomes a concrete engine requirement.
Implement The requirement is built into the pipeline.
Pin A test holds the behaviour against drift.
Tag The page that describes it declares its evidence level.

규범 조항에서 검증된 엔진 동작으로 이어지는 경로입니다. 조항을 가져와 인용하고, 그 규범 키워드로 의무를 분류하며, 엔진 요구사항에 매핑하고, 구현하며, 테스트로 고정하고, 문서화 페이지에 근거 기반을 태그합니다. 테스트 전에 멈춘 조항은 동작이 아니라 주장입니다.

“분류” 단계는 대부분의 모호함을 해소하는 지점입니다. 명세는 요구 수준을 키워드로 인코딩합니다. 잘 알려진 MUST, SHALL, SHOULD, MAY 계열입니다. 그 키워드들의 의미는 IETF 요구 키워드 관례로 고정되어 있으며, 대문자 형태만 규범적임을 명확히 한 갱신을 거쳐 각 명세의 서술적 산문 위에 적용됩니다 Spec: RFC 2119 Spec: RFC 8174 . NextPDF는 shall을 엔진이 넘지 않는 단단한 경계로 읽고, should는 따르되 권고로 문서화할 권장 사항으로 읽습니다 — 결코 약속으로 읽지 않습니다. 그 구별이 정직한 기능 진술과 과장된 주장의 차이입니다.

적합성은 이진이 아니라 단계적입니다

“적합”은 좀처럼 단일 비트가 아닙니다. 서명 표준은 단계로 나뉩니다 — 예를 들어 유럽의 장기-아카이브 프로파일은, 서명이 생성된 지 한참 뒤에도 검증 가능하도록 유지하는 타임스탬프 토큰을 추가하기 위해 특별히 존재합니다 Spec: ETSI EN 319 122-1, §6 . 이것은 단순한 기준선 서명보다 분명히 더 강한 주장입니다. 접근성 표준도 같은 형태입니다. 적합성 수준에는 해당 수준의 모든 성공 기준을 충족해야만 도달할 수 있으며, 주장은 실제로 도달한 수준을 명시합니다 Spec: WCAG 2.2, §5.2.1 . 따라서 NextPDF는 한정 없는 “준수”가 아니라 프로파일과 수준을 명시합니다.

근거가 말하는 것

이 페이지는 Evidence: Standard-backed 입니다. 각 주장은 조항에 고정되고, 풀어 쓰이며, 다음 검토자가 원본과 대조해 재검증할 수 있도록 다이제스트와 함께 인용됩니다.

계층	기관	기준 조항(풀어 쓴 것)	NextPDF에서 규율하는 것
형식	ISO	작성자가 생성하거나 수정한 요소는 적합해야 하며 일관성을 유지해야 합니다 Spec: ISO 32000-2, §6	엔진이 방출하는 PDF
적합성	ISO	적합한 파일은 모든 요구사항을 충족하며, 추가 기능은 선택 사항입니다 Spec: ISO 32000-2, §6	“유효한 출력”의 의미
서명 프로파일	ETSI	장기-아카이브 수준은 추후 검증을 위해 타임스탬프를 추가합니다 Spec: ETSI EN 319 122-1, §6	서명이 목표로 하는 PAdES 프로파일
신뢰할 수 있는 시간	IETF	타임스탬프 서비스는 어떤 데이터가 특정 시간 이전에 존재했음을 증명합니다 Spec: RFC 3161, §2	문서 타임스탬프 토큰
암호화	NIST	승인된 해시는 제공하는 보안 강도가 서로 다릅니다 Spec: NIST FIPS 180-4, §1	서명 아래의 다이제스트 알고리즘
출력 접근성	W3C	적합성 수준은 해당 수준의 모든 기준을 요구합니다 Spec: WCAG 2.2, §5.2.1	렌더링된 PDF에 대한 접근성 주장

인용된 다이제스트는 이 페이지의 citations 프런트매터에 기록됩니다. 여기에는 표준 본문 텍스트가 전혀 재현되지 않습니다. 그 선택을 지배하는 규칙은 별도 페이지로 정리되어 있습니다. 인용 규율을 참고하십시오.

실제 예시

표준 환경은 실행하는 대상이 아니라, 엔진에 무엇을 요청할지 결정하기 위해 읽는 대상입니다. 구체적으로, 장기 검증 가능한 서명 호출은 자취 위의 어느 지점이 필요한지에 관한 선언입니다.

<?php

declare(strict_types=1);

use NextPDF\Core\Document;
use NextPDF\Security\Signature\CertificateInfo;
use NextPDF\Security\Signature\DigitalSigner;
use NextPDF\Security\Signature\SignatureLevel;

// The signature level is a coordinate on the ISO -> ETSI -> RFC trail.
// PAdES B-B is the ETSI baseline CMS SignedData the Core engine produces;
// B-T adds an RFC 3161 timestamp, and B-LT/B-LTA add the DSS and document
// timestamps that keep a signature validatable after the certificate
// expires. The level you name is the point on the trail you are asking for.
$certInfo = CertificateInfo::fromFiles(
    certPath: 'signer-cert.pem',
    keyPath: 'signer-key.pem',
);

// The functional signing path is the direct two-phase signing engine.
// (Document::setSignature() records intent but its writer seam is not yet
// wired and fail-fasts on output — see the PadesOrchestrator docblock.)
$signer = new DigitalSigner(
    certInfo: $certInfo,
    level: SignatureLevel::PAdES_B_B,
);

$result = $signer->sign(file_get_contents('agreement.pdf'));

printf(
    "PAdES %s CMS: %d bytes, timestamp=%s\n",
    SignatureLevel::PAdES_B_B->value,
    $result->getSize(),
    $result->hasTimestamp() ? 'yes' : 'no',
);

단순한 기준선이 아니라 PAdES_B_LTA를 지정하는 것은 성능 튜닝 옵션이 아닙니다. 이것은 의무가 표준 자취를 얼마나 깊이 따라 내려가는지에 관한 결정입니다. B-LT와 B-LTA는 DSS 및 아카이브-타임스탬프 계층을 끌어들이며, 런타임에 엔터프라이즈 LTV 패키지를 요구합니다. 엔진은 조용히 수준을 낮추는 대신, 낮은 수준이 높은 수준을 제공하는 척하는 것을 거부합니다.

흔한 오해

함정은 “NextPDF는 표준을 준수한다”를 하나의 포괄적 보장으로 읽는 것입니다. 그렇지 않으며, 정직한 엔진이라면 어느 것도 그렇게 말하지 않습니다. 적합성은 표준별, 조항별, 수준별입니다. NextPDF는 PDF 2.0 기준선, 명명된 PAdES 프로파일, 그리고 명시된 접근성 수준을 목표로 합니다 — 각각 범위가 정해져 있고, 각각 인용됩니다. 조항과 수준이 뒷받침되지 않은 주장은 마케팅이며, Insider_는 그것을 게시하지 않습니다.

두 번째이자 더 미묘한 함정은 규범적 should를 약속이라고 가정하는 것입니다. 그것은 권고입니다. NextPDF는 권고를 권고로 문서화합니다. 엔진의 보장은 shall 조항으로 구축되며, 그 차이가 보장의 핵심입니다.

한계와 경계

이 페이지는 영토가 아니라 지도입니다. 이 페이지는 NextPDF가 구현하는 모든 조항을 열거하지 않으며, 적합성 인증서도 아닙니다. 동작별 증거는 그 동작을 다루는 주제 페이지에 해당 페이지의 근거 수준과 함께 제시됩니다 — 예를 들어 형식 변경점에 대해서는 PDF 2.0: 무엇이 바뀌었나입니다.

표준 환경 또한 변화합니다. 새로운 판이 출시됩니다. 참조가 다시 지정됩니다. 여기에 인용된 조항은 이 페이지의 citations에 기록된 코퍼스 스냅샷에 고정됩니다. 상위 표준이 개정되면 인용이 그대로 이어진다고 가정하지 않고 새 조항 기준으로 재검증합니다. 이 페이지가 Premium 등급 기능을 명명하는 경우, 내부 메커니즘 수준이 아니라 어느 표준에 응답하는가라는 수준에서만 그렇게 합니다.

용어집

표준 기관 — 명세를 발행하는 조직(ISO, ETSI, IETF, W3C, NIST)입니다. 각각 PDF 스택의 서로 다른 계층을 소유합니다.
규범 조항 — 키워드로 식별되는 표준의 요구사항입니다(필수에는 shall/must, 권장에는 should, 선택에는 may).
표준 자취 — 하나의 기능이 거치는 명세들의 순서가 있는 사슬로, 각 문서가 다음 문서를 규범적으로 참조합니다.
적합성 수준 — 단계적인 준수 계층(ETSI 기준선 프로파일, WCAG 수준)입니다. 주장은 한정 없는 “준수”가 아니라 실제로 도달한 수준을 명시합니다.
PAdES — PDF 고급 전자서명으로, ISO 32000-2가 PDF 서명에 대해 참조하는 ETSI EN 319 142 계열의 서명 프로파일입니다.