▲

pdfly - PDF 파일을 위한 스위스 아미 나이프

 (chezsoi.org)
6P by GN⁺ 12시간전 | ★ favorite | 댓글 2개
  • py-pdf 팀이 만드는 Python 기반의 오픈소스 PDF 파일 조작용 CLI 도구
  • 메타데이터 표시, 페이지 추출 및 병합, 페이지 삭제, 이미지를 PDF로 변환, 문서 압축, 북클릿 제작 등 다양한 PDF 편집 기능 제공
  • PDF에서 이미지 및 주석 텍스트 추출이나 수동 편집 시 손상된 PDF의 xref 복구와 같은 전문 기능도 지원
  • 최근 출시된 0.5.0 버전에서는 PDF 문서 서명 및 검증, 주석이 달린 페이지만 추출, 특정 페이지 회전 등 신규 기능이 추가됨

오픈소스 PDF CLI 도구 pdfly

  • pdfly는 py-pdf 조직의 최신 프로젝트로, Python 환경에서 동작하는 PDF 파일 조작용 명령행 도구
  • fpdf2 및 pypdf 라이브러리 기반으로 개발되었으며, 설치와 사용이 간편하여 다양한 플랫폼에서 활용 가능
  • pdfly의 가장 큰 강점은 경쟁 오픈소스 대비 폭넓은 기능 지원과, 초보 개발자도 쉽게 사용할 수 있는 직관적 인터페이스
  • 다른 프로젝트와 비교했을 때, 한 도구로 PDF 작업의 대부분을 손쉽게 처리할 수 있어 효율성이 뛰어남

주요 기능

  • 메타데이터 표시

    • pdfly meta 및 pdfly pagemeta 명령어를 통해 PDF 메타데이터 표시 지원
    • 파일명, 권한, 크기, 생성/수정/접근 시간 등 운영체제 데이터 제공
    • PDF 버전, 페이지 수, 암호화 여부, 폰트 정보, 첨부파일, 이미지 개수 등 PDF 내부 데이터 표시

  • 문서 조합 및 편집

    • pdfly cat: 특정 페이지 추출 및 문서 병합 기능
    • pdfly rm: 선택적 페이지 삭제 기능
    • pdfly x2pdf: 이미지를 PDF 문서로 변환
    • pdfly compress: 문서 압축 기능
    • pdfly 2-up 및 pdfly booklet: 북릿 제작 기능

  • 콘텐츠 추출

    • pdfly extract-images: PDF에서 이미지 추출
    • pdfly extract-annotated-text: 주석이 달린 텍스트 추출

  • PDF 복구

    • pdfly update-offsets: 텍스트 에디터로 수동 편집한 PDF의 xref 테이블을 수정하여 다시 열 수 있도록 복구
    • xref 테이블은 문서 내 바이트 오프셋 인덱스로, 수동 편집 시 손상될 수 있음

0.5.0 버전 출시 및 신규 기능

  • 2025년 10월 13일 pdfly 0.5.0 버전 출시
  • pdfly sign: PDF 문서에 간편하게 전자서명 추가 가능
  • pdfly check-sign: PDF 문서의 서명 검증 기능
  • pdfly extract-annotated-pages: 주석이 달린 페이지만 선택적으로 추출하여 대용량 문서의 반복적 검토 및 재작업 지원
  • pdfly rotate: 문서의 특정 페이지 회전 기능

향후 계획

  • GitHub의 up-for-grabs 이슈에 다양한 기능 아이디어 가 준비중
  • 신규 기여자를 위한 good first issues 라벨의 이슈들이 준비되어 있어 오픈소스 입문자의 참여도 유도
  • pdfly sign 및 check-sign 등 전자 서명(sign, check-sign) 관련 기능 확장을 중점적으로 발전시킬 계획임
  • 사용자 피드백, 버그 리포트, 기능 제안을 적극 환영함

https://github.com/py-pdf/pdfly

▲
ifmkl 7시간전  [-]

모두의pdf를 쓰다가 개인적으로 활용하기 편하게 일부 기능들(추출, 병합, 제거, 회전, 순서 변경)만 지원하는 pdf 도구 만들어서 사용중입니다. pdf.js /pdf-lib.js 를 활용해서 브라우저로요. 저도 개인도구 만들기전 찾아보니 pdf 관련 도구나 사이트들 어마어마하게 많더라구요.

답변달기
▲
GN⁺ 12시간전  [-]
Hacker News 의견

  • 10년 전 의견이지만 여전히 유효하다고 생각함. 파이썬 라이브러리만 해도 PDF 관련 기능을 조금씩 겹치게 제공하는 게 엄청 많음. 다른 언어에도 마찬가지로 수많은 라이브러리가 있음. 각 라이브러리들은 결국 비슷한 데이터 구조를 변환하는 여러 기능들을 묶어놓은 형태임. 그래서 복잡한 PDF 작업을 하려면 두세 개의 라이브러리를 조합해야만 되고, 이는 개발자 입장이나 컴퓨팅 자원 측면에서 모두 비효율임. 만약 Rust로 인메모리로 잘 설계된 낮은 수준의 PDF 읽기/쓰기 구조체를 만드는 누군가가 있다면, 전체 생태계가 정말 많이 나아질 거라고 생각함. 어떤 언어나 PDF 라이브러리도 그 구조체를 활용할 수 있고, 도입하면 코드가 줄고 속도나 안전성도 좋아질 가능성이 높음. 그리고 get_structure_pointer()와 set_structure_pointer()만 제공해 주면 라이브러리끼리도 자유롭게 연동이 가능해짐. 이런 구조라면 작은 라이브러리들이 기능을 쉽게 추가하고 빠르게 채택될 수 있음. 현실적으로 누가 이걸 하려고 할지 모르겠지만, 정말 필요하다고 생각함

    • PDF 라이브러리를 만들 때는 사용 목적에 따라 끊임없는 설계 트레이드오프가 존재함. "인메모리" 자체도 이미 큰 선택임. 왜냐하면 PDF 포맷 자체는 전체 PDF를 한꺼번에 메모리에 올리지 않아도 되게 설계되었기 때문임. 그리고 최소 인터페이스를 가진 깊은 모듈을 선호하는 입장에서는, 결코 얕은, 넓은 기능의 모듈을 만드는 것을 답으로 볼 수 없음. 마지막으로 JVM같은 관리형 환경에서는 C 인터페이스로 만든 라이브러리는 추가적인 복잡성과 오버헤드가 생긴다는 점도 고려해야 함. 관련 링크

    • "누군가 Rust로 잘 만든 인메모리 PDF 구조체를 만들어주면 생태계가 혁신될 것"이라는 의견에 공감함. 하지만 지금 있는 모든 라이브러리보다 훨씬 좋은 라이브러리를 만드는 것만 해도 쉽지 않은데, 계속 업데이트하며 버그를 고치고 관리하는 일은 훨씬 더 힘듦. 설령 충분한 자금이 있다 해도, 해마다 계속 열정을 가지고 할 사람을 찾아야 하고, 그 사람이 흥미를 잃으면 새 담당자를 구해야 하며, 그 사이에는 필연적으로 불만도 감내해야 함. 요약하자면, 이걸 평생 만들어서 유지관리할 자원봉사자에 미리 감사 인사를 전하고 싶음

    • "Rust로 만든 뛰어난 인메모리 PDF 구조체가 있으면 좋겠다"는 얘기를 보며, 실제로 존재하는 오픈소스 lopdf를 공유함

    • 지금도 PDF 파싱 문제를 디버깅하다가, 결국 직접 파서를 작성하게 됨. 기존 파서를 이해하기 위해 시도했지만 코드가 엉성해서 최종적으로 직접 구현까지 하게 됨. PDF 포맷은 솔직히 확장 과정에서 갖가지 임시방편과 과도한 기능 추가가 섞이면서 상당히 복잡해진 상태임. 아이디어 자체는 좋지만, PDF에 너무 다양한 객체 타입과 특수한 속성들이 존재해서, 이걸 바인딩할 때마다 결국 FFI의 복잡함이 반복된다고 봄. 차라리 PDF와 JSON 간의 공식적인 매핑을 만들어서 메모리 문제만 없다면 주요 라이브러리들이 데이터를 주고받게 할 수도 있을 것 같음. 객체 모델이 완전히 다르진 않으니까

    • 이 논의 전체를 한 장의 XKCD 만화로 요약할 수 있다고 농담하며, 관련 만화 링크를 공유함

  • Poppler는 공식 홈페이지에는 자세히 나오지 않지만, 실제로는 다양한 도구 모음이 포함된 라이브러리로 리눅스 배포판에서도 쉽게 사용 가능함. 여러 번 잘 썼던 도구임. 관련 위키 링크

    • 이 도구들을 활용해 수십만 개의 PDF 급여명세서를 분석해서 새로운 금융 시스템에 데이터를 올렸음. 10점 만점에 10점 줄 정도로 만족함

    • 평소에도 poppler 도구들을 자주 씀. 정말 훌륭하다고 생각함

  • 저수준 작업에는 qpdf가 꽤 유용함

    • 나도 이 얘기를 하려고 왔음. Qpdf는 커맨드라인에서 PDF 파일을 다룰 때 제일 많이 씀. 암호화, 복호화, 페이지 추출, 병합 등 다양하게 활용 가능함. Apache 라이선스이고 C++로 작성됨

  • pdfcpu.io도 있음. 다만 간단한 PDF 변경만 필요한 경우, 크로스 플랫폼 오픈소스 GUI 앱을 찾는 것은 매우 어려운 일임. 실제로 나도 아직 못 찾았음

    • PDF SAM basic ("split and merge")을 잘 쓴 적이 있음. 사이트 링크 오픈소스이면서 멀티플랫폼이고, 유료에서만 제공되는 추가기능도 있음

    • 직접 호스팅이 가능하다면 Signature PDF도 꽤 괜찮았음. 프로젝트 링크

    • pdf24 tools이 괜찮지 않을까 함. 오프라인 설치도 지원함

    • 'pdfcpu images list'를 써봤는데, 로컬에서 무슨 글꼴을 외부에서 다운로드하기 시작해서 깜짝 놀랐음. 10월이지만 너무 무서워서 패스함

    • 결국 고민하다가 Creative Cloud 유료 라이선스를 쓰기로 함. Acrobat이 그냥 잘 작동해서 어쩔 수 없음. 대안을 정말 원하지만 현실적으로 마땅한 대체제가 없음

  • PDFgear를 소개하고 싶음. 완전 고급은 아니지만, Adobe 대체재 중 중간 수준 PDF 편집에는 거의 유일하게 쓸 만하고, 무료인데다 리눅스만 빼고 다 제공함

    • 리눅스 빼고 다 지원한다고 해서, OpenVMS, Apple II, DEC Alpha 바이너리는 어디 있는지 장난스럽게 물어봄

    • Master PDF도 있고, 이건 리눅스용도 있다며 링크를 공유함

    • 보기엔 괜찮아 보여도 "무료인데 광고도 없고 데이터도 팔지 않고 투명하게 투자금만으로 운영한다"는 논리를 믿기 어렵다고 느낌. 실제 홈페이지 설명을 인용해서, PDFgear가 광고나 데이터 수익 없이 투자금과 기술 최적화로 운영한다고 되어 있음을 보여줌

    • PDFgear에 의심이 좀 듦. 예전에 사용자 모르게 클라우드 업로드를 했었고, 회사가 자기들 서브레딧도 관리하는 정황이 있음

  • 오늘 알게 된 사실: 이미 PDF 파일을 위한 다기능 툴들이 굉장히 많음

  • 자동으로 목차(메타데이터)를 생성해주는 기능이 정말 있었으면 함. 오래된 책 PDF에 이게 없어서 탐색이 너무 불편함. Kybook3에도 버전이 있는데 정확히 작동하지 않음. 요즘 LLM 기술로 이게 가능해지지 않을까 싶음

    • pdf.tocgen을 사용하고 있음. 완전히 자동은 아니지만, 완전 수작업보다는 시간이 엄청 절약됨

  • PDF 서명을 자동화하는 유틸리티가 의미가 있는가 궁금함. 서명의 본질은 사람이 읽고 동의했다는 의미인데, 그걸 자동화한다는 게 맞는지 의문임

    • 기업에서 자신들이 만든 문서에 자동으로 서명하지 않을 이유가 없다고 생각함. 여기서 말하는 서명은 PDF 내 시각적인 서명이 아니라, 누구나 발급자를 검증할 수 있는 암호학적 서명임. 즉, 은행 명세서가 진짜 은행에서 왔는지 사용자가 확인할 수 있게 해주는 기능임

    • CEO는 수많은 직원 계약서에 서명할 시간이 없음. 아날로그 시절에도 비서가 도장을 찍는 역할을 했던 것처럼, 서명 자동화는 현실적으로 의미 있음

    • 은행 계좌 증명서를 필요시 언제든 자동으로 서명 발급해줌. 지점장이 직접 앉아서 모든 신청서를 하나하나 서명하리라 기대하진 않음

    • 예를 들어 25개의 PDF에 서명해야 한다면, 일일이 뷰어에서 수작업하는 대신 화면으로 검토하고 한꺼번에 배치 서명하는 것이 더 편함

  • 위에서 언급된 것 외에도, pdfcpu라는 "Go PDF processor and CLI"가 있음. pdfcpu 깃허브

  • 내가 생각했던 만능 PDF 툴은 Didier Stevens의 PDF 도구 모음임. 프로그램 링크

답변달기