콘텐츠로 이동
getnextpdf.com

팀이 NextPDF를 선택하는 이유

Spec: ISO 32000-2Spec: ETSI EN 319 142-1

PDF 엔진을 고르는 일은 작은 결정처럼 보이지만, 이후의 수많은 결정을 조용히 정해 버립니다. 이 페이지는 NextPDF를 선택하는 근거를, 팀이 실제로 내리는 결정의 형태로 풀어냅니다. PHP 안에 머무를 것인가 사이드카를 운영할 것인가, 코드를 직접 소유할 것인가 블랙박스를 빌릴 것인가, 진짜 서명을 만들 것인가 체크박스를 만들 것인가, 운영 환경에서 살아남는 프로토타입을 출시할 것인가 거기까지 가려면 다시 작성해야 하는 것을 출시할 것인가.

여러분이 생성하는 PDF는 좀처럼 이야기의 끝이 아닙니다. 그것은 서명되고, 보관되고, 규제 기관에 이메일로 보내지고, 여러분이 코드를 작성할 때 그 자리에 없던 누군가에 의해 몇 년 뒤에 열립니다. 그래서 PDF 엔진은 유틸리티 호출이 아니라 인프라 선택입니다. 잘못된 선택은 나중에야 드러납니다. 검증기가 거부하는 서명으로, 검사기가 실패시키는 아카이브로, 또는 여러분의 문서가 그들의 서비스를 통해서만 렌더링되기 때문에 벗어날 수 없는 벤더 청구서로.

팀은 보통 이 결정을 다시 따져 볼 기회를 얻지 못합니다. 첫 주에 고른 엔진이 3년 차에 중요 경로 위에 있는 바로 그 엔진입니다. 그러므로 정직하게 답할 가치가 있는 질문은 “PDF를 만들 수 있는가”가 — 거의 무엇이든 만들 수 있습니다 — 아니라 “문서가 법적 또는 보관용 산출물이 될 때 이것이 버틸 것인가”입니다.

팀이 NextPDF를 선택하는 이유는 네 가지 별개의 위험을 한꺼번에 제거하기 때문입니다.

  • PHP 네이티브입니다. 여러분이 앱 옆에서 운영하고, 확장하고, 보안을 유지해야 하는 별도 런타임이 아니라, 여러분의 프로세스 안에서 실행되는 PDF 2.0 엔진입니다.
  • 기본적으로 개방되어 있습니다. 코어는 Apache-2.0입니다 — 읽을 수 있고, 포크할 수 있고, 벤더링할 수 있습니다. 고급 에디션은 역량을 더할 뿐, 결코 여러분의 문서를 인질로 잡지 않습니다.
  • 서명이 표준 수준입니다. 유럽의 검증기가 한 번도 본 적 없는 자체 제작 서명 방식이 아니라, PAdES 베이스라인 프로파일 (Spec: ETSI EN 319 142-1, §6)입니다.
  • 같은 코드로 확장됩니다. 첫날 작성한 프로토타입이 곧 운영 환경의 코드 경로입니다. “이제 진짜 엔진으로 포팅하라”는 단계는 없습니다.

이 네 가지 주장 각각은 구체적인 속성으로 이어지며, 각각은 믿음으로 받아들이는 것이 아니라 리뷰어가 직접 확인할 수 있는 것입니다.

PHP 네이티브라는 것은 두 번째 런타임이 없다는 뜻입니다. NextPDF는 이 포맷의 기준 판본(Spec: ISO 32000-2, §6)에 정의된 대로 PDF 2.0을 대상으로 하며, 그것을 여러분의 PHP 프로세스 안에서 수행합니다. 살려 둬야 할 헤드리스 브라우저도, 배포해야 할 마이크로서비스도, 가로질러 마샬링해야 할 언어 경계도 없습니다. 스택이 이미 PHP인 팀에게는 운영 표면이 정확히 이전과 똑같이 유지됩니다. 브라우저 수준의 렌더러가 정말로 올바른 도구일 때는 NextPDF가 그것을 구동할 수 있습니다 — 하지만 그것은 여러분이 물려받는 의존성이 아니라 직접 내리는 선택입니다. 그 절충은 통합 결정 가이드의 주제입니다.

기본적으로 개방되어 있다는 것은 락인이 없다는 뜻입니다. 코어 엔진은 Apache-2.0입니다. 여러분의 바이트를 건드리는 모든 줄을 읽을 수 있고, 비공개 미러로 벤더링할 수 있고, 어떤 릴리스가 따라갈 수 없는 방향으로 가더라도 포크해서 계속 출시할 수 있습니다. 코어가 생성한 문서는 적합한 모든 리더가 여는 표준 PDF입니다 — 단 하나의 벤더 서비스를 통해서만 왕복하는 독점 컨테이너가 아닙니다. 상용 에디션은 부가적입니다. 하드웨어 기반 서명이나 대량 처리 기능 같은 역량을 풀어 주지만, 그것들이 생성하는 문서는 여전히 여러분이 온전히 소유하는, 평범하고 표준에 적합한 PDF로 남습니다.

표준 수준의 서명이라는 것은 검토를 견디는 서명이라는 뜻입니다. 바로 여기서 “그럭저럭 괜찮은” PDF 라이브러리가 조용히 부채가 됩니다. 검증기가 인식하지 못하는 서명은, 그것이 중요했던 목적에 비추어 보면 서명이 아닙니다. NextPDF는 ETSI가 정의한 PAdES 베이스라인 진행 — B-B, B-T, B-LT, B-LTA — 을 대상으로 하며, 이는 유럽의 검증기와 감사관이 보기를 기대하는 레벨입니다. 그 경계는 계층적입니다. Apache-2.0 코어는 로컬 또는 제공된 키를 사용하여 B-B 및 B-T 레벨을 위한 소프트웨어 CMS/PAdES 서명자를 제공하며, 장기 검증 레벨(B-LT, B-LTA)과 HSM 또는 클라우드 KMS 기반 키는 고급 에디션 역량입니다. PAdES는 PDF를 위한 ETSI 서명 프로파일이고, eIDAS — EU 규정 (Spec: Regulation (EU) No 910/2014 (eIDAS), Art. 25) — 은 전자 서명에 법적 효력을 부여하는 것이며, PAdES는 eIDAS 의무가 귀착되는 PDF 구현입니다. 이것이 바로 엔진이 근사치가 아니라 그 프로파일 계열을 대상으로 하는 이유입니다. PAdES 베이스라인 프로파일 페이지는 그 진행과, 여러분의 의무가 실제로 필요로 하는 레벨을 고르는 방법을 안내합니다.

  1. 여러분의 스택 안에 머무르기PHP 네이티브 PDF 2.0 엔진은 프로세스 내에서 실행됩니다 — 배포하고, 확장하고, 보안을 유지할 두 번째 런타임이 없습니다.
  2. 출시하는 것을 소유하기Apache-2.0 코어: 읽을 수 있고, 포크할 수 있고, 벤더링할 수 있습니다. 문서는 독점 컨테이너가 아니라 여러분이 보유하는 표준 PDF입니다.
  3. 진짜로 서명하기PAdES 베이스라인 프로파일(ETSI EN 319 142-1), 검증기와 감사관이 인식하는 레벨입니다 — 자체 제작 방식이 아닙니다.
  4. 다시 작성하지 않고 성장하기프로토타입이 곧 운영 경로입니다. 빠르게 실패하는 타입 지정 입력은 실수를 개발 단계에서, 비용이 저렴한 곳에서 잡아냅니다.
팀이 PDF 엔진을 도입할 때 마주하는 결정과, 각 단계를 풀어내는 NextPDF 속성: 사이드카를 운영하기보다 네이티브로 머무른다; 블랙박스를 빌리기보다 Apache-2.0 아래에서 코드를 소유한다; 맞춤형 서명이 아니라 인식되는 PAdES 프로파일을 내보낸다; 그리고 프로토타입에서 운영까지 같은 코드 경로를 유지한다.

프로토타입에서 운영까지라는 것은 다시 작성하지 않는다는 뜻입니다. 네 번째 위험은 가장 조용합니다. 데모는 아름답게 되지만 출시하려면 교체해야 하는 도구입니다. NextPDF는 여러분이 처음 작성하는 프로그램이 곧 여러분이 운영하는 프로그램이 되도록 만들어졌습니다. 입력은 엄격하게 타입이 지정되고 경계에서 검증되므로, 여러분이 운영 환경에서 보게 될 실패 양상은 이미 개발 단계에서 본 것들입니다 — 호출 지점에서, 한 바이트가 쓰이기 전에 이름이 붙은 채로. 그 입장은 설계 철학추측하기를 거부하는 API의 주제입니다. 여기서 그것이 중요한 이유는, 바로 그것이 같은 코드 경로로 팀을 주말 실험에서 규제 대상 워크로드까지 데려가기 때문입니다.

“같은 코드로 프로토타입에서 운영까지”의 형태는 호출 지점에서 가장 보기 쉽습니다. 팀이 엔진을 평가하려고 작성하는 프로그램은, 한 줄 한 줄, 운영 환경에서 실행되는 바로 그 프로그램입니다 — 서명 자료만 바뀝니다.

<?php
declare(strict_types=1);
use NextPDF\Contracts\Orientation;
use NextPDF\Contracts\OutputDestination;
use NextPDF\Core\Document;
use NextPDF\Signature\SignatureLevel;
use NextPDF\ValueObjects\PageSize;
$document = Document::createStandalone();
$document->setTitle('Service Agreement');
// Typed page geometry and an enum orientation — intent is explicit,
// so a typo is a type error in development, not a silent default in production.
$document->addPage(PageSize::a4(), Orientation::Portrait);
$document->setFont('helvetica', 'B', 16);
$document->cell(0, 12, 'Service Agreement', newLine: true);
// The signature level is a recognised PAdES baseline profile, named as an
// enum case — never a string the engine has to interpret. B-T is a core
// software-signing level; the long-term levels (B-LT, B-LTA) are an
// advanced-edition capability selected the same way.
$document->setSignature(certInfo: $certInfo, level: SignatureLevel::PAdES_B_T);
// The output destination is stated, not inferred from whether a filename
// was passed. The same call shape serves a spike and a production endpoint.
$bytes = $document->output(dest: OutputDestination::String);

이 프로그램에서 프로토타입과 배포 사이에 바뀌는 것은 없습니다. 팀은 자리표시자 대신 진짜 서명 자료를 넣고, 출력을 버퍼가 아니라 응답으로 가리키게 합니다. 엔진, API, 그리고 실패 양상은 두 곳에서 동일합니다 — 이것이 핵심 전부입니다.

자주 나오는 반론은 “오픈소스 코어라는 것은 진짜 제품이 유료 장벽 뒤에 있다는 뜻이니, 무료 부분은 미끼다”입니다. 그것은 관계를 거꾸로 이해한 것입니다. 코어는 Apache-2.0 아래의 운영급 PDF 2.0 엔진입니다 — 문서 생성, 표준에 적합한 출력, 그리고 B-B 및 B-T 레벨의 소프트웨어 CMS/PAdES 서명. 팀은 이를 수정 없이 운영 환경에서 실행합니다. 고급 에디션은 특화된 역량을 더합니다 — 장기 검증 서명(B-LT, B-LTA), HSM 및 클라우드 KMS 기반 키, 규모 기능 — 그것이 필요한 팀을 위해서. 그 시험은 단순하고 검증 가능합니다. 코어가 생성한 문서는 적합한 어떤 리더에서도 열리는 표준 PDF이며, 그것을 다시 읽기 위해 NextPDF 서비스에 의존하지 않습니다. 몸값을 치러야 할 인질은 없습니다.

두 번째 오해는 “PHP 네이티브”가 “브라우저 엔진보다 능력이 떨어진다”는 뜻이라는 것입니다. 그것은 다르다는 뜻입니다. 그리고 브라우저 수준의 렌더러가 더 잘 맞는 정직한 사례들은 묻혀 있지 않고 NextPDF를 사용하지 말아야 할 때에 정리되어 있습니다.

이 페이지는 도입을 위한 근거이지, 보편적 적합성에 대한 주장이 아닙니다. NextPDF는 PHP 스택에서 프로그래밍적이고 표준 수준인 문서 생성을 위한 올바른 도구입니다. 그것은 웹 브라우저의 픽셀 단위로 완벽한 재구현이 아니며, 모든 문서 문제에 대한 해답도 아닙니다. 그 경계는 NextPDF를 사용하지 말아야 할 때에 명백히 진술되어 있습니다.

Hardware-backed (HSM) signing — edition availability
EditionAvailability
Core이 에디션에는 없습니다 — 소프트웨어 서명만(B-B, B-T).
Pro사용 가능 — HSM 및 적격 디바이스 서명.
Enterprise사용 가능 — HSM 및 적격 디바이스 서명.

두 가지 경계는 강조할 만합니다. 첫째, 서명 역량은 계층적입니다. Apache-2.0 코어는 로컬 또는 제공된 키로 B-B 및 B-T 레벨의 소프트웨어 CMS/PAdES 서명을 제공하며, 장기 검증 레벨(B-LT, B-LTA)과 HSM, 적격 디바이스, 또는 클라우드 KMS를 통한 하드웨어 기반 키는 고급 에디션 역량입니다. 둘째 — 그리고 이것이 모든 적합성 주장에 대한 정직한 한계입니다 — 적합성은 생산자가 아니라 독립 검사기가 판정합니다. PAdES는 PDF를 위한 ETSI 서명 프로파일이고, PDF/A-4 (Spec: ISO 19005-4, §6)는 ISO 19005-4가 정의하는 별개의 보관용 적합성 레벨입니다. NextPDF는 각각을 대상으로 할 수 있지만, 프로파일을 대상으로 하는 것이 적합성을 보장하는 것은 아닙니다. 권위 있는 판정은 파일을 작성한 엔진이 아니라 PDF/A 검증기나 서명 검증기에서 나옵니다. 엔진은 여러분을 “통과해야 한다”로 데려가는 도구로, 검사기는 “통과한다”라고 말하는 도구로 취급하십시오.

  • PDF 2.0 — PDF 포맷의 현재 버전으로, ISO 32000-2에 규정되어 있습니다. NextPDF는 이를 기준 판본으로 대상하므로, 그 출력은 벤더 방언이 아니라 현재 ISO 표준에 비추어 측정됩니다.
  • PAdES — PDF Advanced Electronic Signatures, PDF 서명을 위한 ETSI 프로파일 계열(EN 319 142-1)입니다. 그 베이스라인 레벨 — B-B, B-T, B-LT, B-LTA — 은 유럽의 검증기와 감사관이 보기를 기대하는 것입니다.
  • eIDAS — Regulation (EU) No 910/2014, 전자 서명과 적격 서명에 법적 효력을 부여하는 EU 프레임워크입니다. PAdES는 eIDAS 의무가 귀착되는 PDF 구현입니다.
  • PDF/A — 자체 완결적이고 장기간 읽을 수 있게 유지되어야 하는 문서를 위한 보관용 적합성 계열(여기서는 ISO 19005-4 아래의 PDF/A-4)입니다.
  • Apache-2.0 — NextPDF 코어의 허용적인 오픈소스 라이선스입니다. 여러분은 자신의 애플리케이션을 개방할 의무 없이 엔진을 사용하고, 수정하고, 벤더링하고, 재배포할 수 있습니다.
  • 락인 없음 — 엔진이 생성하는 문서가, 생산자의 서비스에 대한 어떤 의존성도 없이 읽을 수 있는, 여러분이 온전히 소유하는 표준적이고 벤더 중립적인 산출물이 된다는 속성입니다.