[개발 일지] PDF 처리 흐름을 내가 4단계로 나눈 이유: 입력부터 렌더링 검증까지

한 줄 요약: 내가 직접 진행한 PDF 작업은 파일을 생성하는 한 단계로 끝나지 않았습니다. 입력 확인, 반영, 생성, 렌더링을 나눠 보아야 문제가 생긴 위치와 다시 확인할 범위를 분명히 할 수 있었습니다.

1. 입력 확인: 무엇을 바꿀지 먼저 분리했습니다

원고, 목차, 자료 화면, 변경 요청을 한데 섞으면 나중에 누락 원인을 찾기 어려웠습니다. 그래서 작업 전에는 무엇이 입력이고 무엇이 수정 조건인지부터 분리해 기록했습니다.

2. 반영과 생성: 수정 기록과 산출 조건은 다릅니다

문장·번호·표·이미지를 바꾸는 일은 반영 단계로, 페이지 수·글꼴·파일 용량 같은 결과 조건은 생성 단계로 나눴습니다. 두 단계를 섞지 않으니 어떤 수정이 결과에 영향을 줬는지 다시 확인하기 쉬웠습니다.

3. 렌더링: 사람이 보는 화면을 마지막에 확인합니다

생성 결과가 있어도 실제 페이지에서 빈 페이지, 줄바꿈, 표·이미지 위치가 달라질 수 있습니다. 나는 최종 화면을 별도 단계로 두고, 이 단계까지 확인하지 않은 항목은 완료로 적지 않기로 했습니다.

이 흐름을 공개한 이유

이 글은 원문 PDF나 실제 작업 파일을 공유하는 글이 아닙니다. 내가 반복 작업에서 사용한 검수 순서를 공개 가능한 형태로 정리한 개발일지입니다. 결과를 과장하지 않고, 확인한 조건과 미확인 범위를 구분하기 위해 남깁니다.

공개 범위: 내부 원고, 고객·계정 정보, 폴더명과 실행 로그는 포함하지 않습니다.

한 덩어리로 보면 생기는 문제

"PDF 처리"를 하나로 묶으면 실패했을 때 어디를 고쳐야 할지 알 수 없습니다. 네 단계로 나누면 실패 지점이 바로 좁혀집니다.

입력 — 원본 파일과 요청 범위가 맞는가.
추출 — 필요한 내용을 꺼냈는가.
변환 — 요청한 수정이 반영됐는가.
렌더링 — 실제 화면에서 정상인가.

단계마다 다른 실패가 나온다

입력 단계 — 파일이 손상됐거나, 암호가 걸렸거나, 요청 범위가 모호한 경우.
추출 단계 — 텍스트가 없는 스캔본이거나, 글꼴이 포함되지 않은 경우.
변환 단계 — 수정은 됐는데 다른 부분이 함께 바뀐 경우.
렌더링 단계 — 데이터는 맞는데 화면이 깨지는 경우.

네 번째가 가장 늦게 발견되고 가장 자주 놓칩니다. 앞의 셋이 다 통과한 뒤라 방심하기 때문입니다.

각 단계에서 남기는 기록

입력한 파일 이름과 요청 항목.
추출된 분량과 실패한 페이지 번호.
반영한 수정 항목의 개수.
최종 파일의 페이지 수와 용량.

이 네 줄만 남겨도 나중에 같은 문제가 생겼을 때 비교할 기준이 생깁니다.

공식 문서로 보는 단계별 한계

네 단계 중 어디에서 문제가 생기기 쉬운지는 PDF를 다루는 공식 문서에도 단서가 있습니다. 아래는 Google 지원 문서, Mozilla의 PDF.js 프로젝트 문서, MDN 문서(2026년 10월 18일 기준)에 적힌 내용입니다. 이 글의 작업 방식이 아니라 각 서비스와 프로젝트가 스스로 밝힌 조건이라는 점을 구분해서 읽어 주세요.

추출 단계: 스캔본은 조건이 맞아야 글자가 나옵니다

Google 드라이브 도움말은 PDF(여러 페이지 포함)와 사진 파일(.jpeg, .png, .gif)을 문서로 변환해 글자를 뽑는 기능을 설명합니다. 파일은 2MB 이하여야 하고, 글자 높이가 최소 10픽셀 이상이어야 하며, 문서가 바로 서 있어야 하고, Arial나 Times New Roman 같은 흔한 글꼴과 선명하고 고르게 밝은 이미지가 정확도에 유리하다고 안내합니다. 그래서 입력 단계에서 “텍스트가 있는 PDF인지, 스캔 이미지인지”를 먼저 가르는 기록이 도움이 됩니다.

변환 단계: 서식은 일부만 따라올 수 있습니다

같은 도움말은 굵게, 기울임, 글자 크기와 글꼴, 줄바꿈은 유지될 가능성이 높지만 목록, 표, 단, 각주와 미주는 감지되지 않을 가능성이 높다고 적고 있습니다. 표나 번호가 많은 문서라면 변환 뒤에 “수정 항목이 몇 개 반영됐는지”뿐 아니라 표와 목록이 그대로인지도 따로 기록해야 하는 이유입니다.

렌더링 단계: 화면에 그리는 일은 별도의 일입니다

PDF.js의 README는 이 프로젝트를 HTML5로 만든 PDF 뷰어이며, PDF를 해석하고 화면에 그리는 범용 플랫폼을 목표로 한다고 소개합니다. 파일을 해석하는 일과 화면에 그리는 일이 같은 프로젝트의 별개 목표로 나열된다는 점은, 이 글이 렌더링 확인을 마지막 단계로 따로 둔 이유와 맞닿아 있습니다. 또 MDN의 일반 미디어 타입 표에는 PDF가 application/pdf로 등록되어 있어, 브라우저가 파일을 PDF로 알아보는 기준이 별도로 존재함을 알 수 있습니다.

단계	공식 문서에서 확인되는 조건	기록해 둘 항목
입력	파일 형식(PDF, 이미지), 2MB 이하 등 서비스별 제한	파일 형식과 용량, 스캔 여부
추출	글자 높이 10픽셀 이상, 똑바른 방향, 선명한 이미지	추출된 분량, 실패한 페이지
변환	표·목록·단·각주는 감지되지 않을 수 있음	반영 개수, 표·목록 유지 여부
렌더링	해석과 화면 그리기는 별개의 목표	페이지 수, 빈 페이지, 표·이미지 위치

위 한계는 서비스마다 다르고 바뀔 수 있으므로, 실제 작업에서는 쓰는 도구의 최신 도움말이 우선입니다.

확인 자료

기준일: 2026-10-18