PDF 및 문서 변환 중 채우기 가능한 양식 보존

문서에 인터랙티브한 양식 필드가 포함된 경우, 변환 과정은 단순히 컨테이너를 바꾸는 것을 넘어섭니다. 필드에는 시각적 자리표시자뿐 아니라 데이터 구조, 검증 규칙, 때로는 양식을 사용할 수 있게 하는 스크립트가 포함됩니다. 변환 중 이러한 요소가 하나라도 손실되면 사용자 경험이 깨지거나 데이터 수집이 무효화되며, 비용이 많이 드는 수동 재구축을 강요할 수 있습니다. 이 가이드는 채워지는 양식의 구조, 대상 형식에 대한 결정 사항, 그리고 변환 중에도 인터랙티브성을 유지하면서 변환 이점을 누릴 수 있는 구체적인 단계들을 살펴봅니다—단일 계약서를 준비하든 수천 개의 온보딩 설문지를 처리하든 마찬가지입니다.

양식 요소 이해하기

채우기 가능한 양식은 필드 객체들의 집합이며, 뷰어가 이를 편집 가능한 위젯으로 렌더링합니다. PDF 용어에서는 가장 일반적인 구현이 AcroForm이며, 이는 필드 사전들의 모음으로 필드 유형(텍스트, 체크박스, 라디오 버튼, 리스트, 버튼), 외형, 기본값, 그리고 선택적으로 검증이나 계산을 위한 JavaScript 동작을 기술합니다. 최신 PDF에서는 XFA(XML Forms Architecture)를 삽입할 수 있는데, 이는 양식 레이아웃과 로직을 XML 패킷으로 외부화합니다. Office 문서는 다른 패러다임을 사용합니다: Word와 Excel은 OOXML 패키지의 일부로 양식 컨트롤을 저장하며, 각 컨트롤은 속성, 바인딩 및 데이터 검증 규칙을 설명하는 자체 XML 파트를 가집니다.

변환 시 고려해야 할 핵심 속성:

필드 유형 – 텍스트, 숫자, 날짜, 드롭다운, 체크박스, 라디오, 서명, 버튼.
기본/값 데이터 – 자리표시자 또는 사전 입력된 내용.
검증 로직 – 정규식, 범위 검사, 필수 플래그.
계산된 필드 – 다른 필드를 업데이트하는 수식이나 JavaScript.
외형 설정 – 글꼴, 색상, 테두리, 탭 순서.
내장 리소스 – 양식이 참조하는 글꼴, 이미지 또는 JavaScript 파일.

이 구성 요소 중 하나라도 제거되면, 결과 파일은 겉보기엔 정상이라도 양식으로서 기능을 상실합니다.

인터랙티비티를 지원하는 대상 형식 선택하기

모든 형식이 채우기 가능한 PDF의 풍부함을 전달할 수 있는 것은 아닙니다. 대상 형식의 기능을 이해하면 현실적인 기대치를 설정하는 데 도움이 됩니다.

대상 형식	인터랙티브 필드 지원 여부	비고
PDF (AcroForm)	예 (동일 사양)	교체용으로 이상적. 기능 손실을 방지하려면 버전(PDF 1.7 이상)을 유지하세요.
PDF (XFA)	예 (단, 뷰어 지원 제한)	Adobe Acrobat 및 일부 엔터프라이즈 뷰어만 XFA를 완전히 렌더링합니다.
HTML	예 (`<input>`, `<select>`, `<textarea>` 활용)	PDF 필드 정의를 HTML 컨트롤에 매핑해야 함; 웹 기반 데이터 수집에 유용.
DOCX / DOC	예 (콘텐츠 컨트롤)	Word의 콘텐츠 컨트롤이 PDF 필드를 흉내냅니다; 복잡한 계산은 손실될 수 있음.
XLSX / XLS	예 (폼 컨트롤)	Excel은 드롭다운, 체크박스, 수식을 지원하지만 PDF 필드를 스프레드시트 셀에 매핑하는 과정이 복잡함.
EPUB	제한적 – 대부분 정적	일부 리더가 폼 위젯을 지원하지만 일관되지 않음.
Plain Text / CSV	아니오 – 데이터 전용	양식 UI 보존이 아니라 제출된 데이터를 내보내는 용도.

양식이 온라인으로 채워질지, 인쇄 후 손으로 입력될지, 자동으로 처리될지 등 하위 사용 모델을 알면 가장 호환성이 높은 대상을 선택할 수 있습니다.

변환 전에 소스 파일 준비하기

깨끗한 소스가 깨끗한 변환을 만든다. 다음 준비 단계를 따르세요:

양식 감시 – PDF(또는 Office 파일)를 원본 편집기에서 열고 모든 필드를 목록화합니다. 사용자 지정 스크립트, 내장 글꼴, 외부 리소스가 있는지 기록합니다. Adobe Acrobat의 Prepare Form 패널이나 Word/Excel용 OpenXML SDK와 같은 도구가 메타데이터를 추출할 수 있습니다.
비핵심 레이어 플래튼 – 배경 이미지나 워터마크가 순수 장식용이라면 이를 래스터 레이어로 플래튼합니다. 이렇게 하면 변환 엔진이 이를 양식 객체로 오인할 가능성이 줄어듭니다.
글꼴 임베딩 정규화 – 필드 외형에 사용된 모든 글꼴이 임베드돼 있는지 확인합니다. 글꼴이 누락되면 대부분의 변환기가 대체 글꼴을 사용해 레이아웃이 바뀌고 탭 순서가 깨질 수 있습니다.
스크립트 백업 – JavaScript 검증은 일반 변환기에서 자주 삭제됩니다. 스크립트를 별도 파일로 내보내 두면 필요 시 수동으로 재삽입할 수 있습니다.
일관된 버전 지정 – PDF는 1.4, 1.5, 1.7 등으로 저장될 수 있습니다. 버전을 일정하게 유지하면 디지털 서명 같은 기능이 우연히 손실되는 것을 방지합니다.

이 작업을 한 번 해두면 특히 배치 처리 시 시간을 크게 절약할 수 있습니다.

양식 무결성을 유지하는 변환 전략

아래는 가장 흔한 변환 경로와 실용적인 레시피입니다.

1. PDF → PDF (AcroForm 유지)

대상이 여전히 PDF인 경우, 가장 안전한 방법은 PDF 버전을 그대로 유지하는 직접 복사입니다. 대부분의 클라우드 변환기에는 “원본 양식 필드 유지” 옵션이 있습니다. convertise.app을 사용하면 원본 PDF를 업로드하고 출력 형식을 PDF로 선택한 뒤 Preserve Form 토글을 명시적으로 켤 수 있습니다. 엔진은 필드 사전을 그대로 스트리밍하고, 필요 시 크기 감소를 위해 스트림만 재압축합니다. 변환 후 Acrobat에서 Fields 패널을 열어 모든 필드가 원래 이름과 속성을 그대로 가지고 있는지 확인하세요.

2. PDF → HTML (웹 양식 재작성)

웹 배포가 자주 요구됩니다. 변환 흐름은 다음과 같습니다:

필드 정의 추출 – PDF 라이브러리(PDFBox, iText 등)를 사용해 AcroForm 사전을 읽고 각 필드를 설명하는 JSON 스키마를 내보냅니다.
PDF 타입을 HTML 입력에 매핑 – 텍스트 필드는 <input type="text">, 체크박스는 <input type="checkbox">, 드롭다운은 <select> 로 변환합니다. PDF의 name 속성을 그대로 유지해 일관된 데이터 계약을 보장합니다.
외형 전송 – 필드의 appearance 스트림에서 글꼴, 크기, 색상 정보를 추출해 동등한 CSS 규칙을 적용합니다. 선택 사항이지만 WYSIWYG 결과를 얻을 수 있습니다.
검증 로직 포팅 – 간단한 정규식이나 범위 검사는 HTML5 검증 속성(pattern, min, max)으로 변환합니다. 복잡한 JavaScript는 앞서 백업한 스크립트를 수동으로 복사합니다.
정적 콘텐츠 렌더링 – PDF 페이지를 이미지로 변환하거나 pdf2htmlEX와 같이 시각적 렌더링을 수행하면서 폼 오버레이는 그대로 두는 라이브러리를 사용합니다.

많은 상용 변환기가 1‑3 단계를 자동화하지만 검증 스크립트는 직접 삽입해야 할 경우가 많습니다. 여러 브라우저에서 생성된 HTML을 테스트해 탭 순서와 포커스 처리 방식이 원본 PDF와 유사한지 확인하세요.

3. PDF → DOCX (Word 콘텐츠 컨트롤)

Word의 콘텐츠 컨트롤은 텍스트, 날짜, 드롭다운, 체크박스를 저장할 수 있습니다. 변환 경로는 다음과 같습니다:

AcroForm 사전 추출 – HTML 경로와 동일하게 수행합니다.
DOCX 패키지 생성 – 각 필드를 <w:sdt> 요소로 변환합니다. docx4j 같은 라이브러리를 사용하면 프로그래밍적으로 요소를 만들 수 있습니다.
기본값 삽입 – <w:sdtContent> 안에 필드의 기본값을 넣습니다.
레이아웃 보존 – 원본 PDF의 좌표 그리드를 유지하려면 투명 테두리의 표를 삽입하고 각 셀에 콘텐츠 컨트롤을 위치시켜 시각적 배치를 재현합니다.
스크립트 재삽입 – Word는 JavaScript를 지원하지 않으므로 콘텐츠 컨트롤 속성 제한이나 VBA 매크로로 검증을 근사할 수 있지만 선택 사항입니다.

코드 없이 진행하고 싶다면 많은 클라우드 변환기가 PDF → DOCX (양식 보존) 모드를 제공합니다. 변환 후 Word에서 Developer 탭을 활성화하면 인터랙티브한 컨트롤이 데이터 입력 준비 상태임을 확인할 수 있습니다.

4. Office 양식 → PDF (채우기 가능한 형태 유지)

Word·Excel 양식을 배포용 채우기 가능한 PDF로 변환하는 경우가 흔합니다. 절차는 앞선 흐름을 역전시킵니다:

콘텐츠 컨트롤 식별 – Word에서는 Developer 탭의 Design Mode에서, Excel에서는 Form Controls에서 확인합니다.
컨트롤 메타데이터를 XML로 내보내기 – OpenXML SDK가 각 <w:sdt> 또는 <x:checkbox> 요소를 열거해 구조화된 XML 파일을 생성합니다.
AcroForm 생성 – PDF 라이브러리를 이용해 새 PDF를 만든 뒤, XML 스키마를 필드로 가져옵니다. 각각의 컨트롤 위치는 Office 파일에 저장된 페이지 레이아웃 정보(wp:anchor 등)에서 얻습니다.
시각 스타일 적용 – Office 문서 테마에서 글꼴·색상 설정을 추출해 PDF 필드 appearance 스트림에 임베드합니다.
선택적 JavaScript 추가 – Office 양식에 데이터 검증 수식이 있으면 이를 PDF JavaScript(예: event.value = util.printf("%02d", event.value);)로 변환합니다.

클라우드 서비스 이용 시 Export as Fillable PDF 옵션을 켜세요. 변환 후 Acrobat Reader에서 Forms 패널을 열면 모든 필드가 나열되고, 필드를 평평하게 만들지 않고 저장할 수 있음을 확인할 수 있습니다.

변환된 양식 검증하기

“보기에 괜찮다”는 충분하지 않습니다. 체계적인 검증을 통해 양식이 기대대로 동작하는지 확인해야 합니다.

구조 검사 – pdfinfo, iText 등 PDF 파서를 사용해 필드 이름·유형을 열거하고 원본 리스트와 비교합니다.
외형 검증 – 원본과 변환 파일을 나란히 열어 글꼴, 정렬, 간격이 일치하는지 확인합니다. ImageMagick compare 같은 픽셀‑단위 비교 도구로 차이를 수치화할 수 있습니다.
기능 테스트 – 각 필드에 샘플 데이터를 입력하고, JavaScript 동작이 있는 경우 Submit 등을 클릭해 오류 메시지가 올바르게 표시되는지 확인합니다.
데이터 라운드‑트립 – 채워진 양식을 FDF 또는 XFDF로 내보낸 뒤 다시 같은 문서에 가져옵니다. 데이터가 그대로 유지되어야 합니다.
다중 뷰어 테스트 – Adobe Acrobat Reader, Foxit, Chrome PDF Viewer 등 최소 두 가지 뷰어에서 파일을 열어 봅니다. 뷰어마다 사양 구현이 다를 수 있으므로 모든 예상 사용자 환경에서 필드가 편집 가능한지 확인합니다.

1‑3 단계는 PDF 라이브러리 API를 호출하는 스크립트로 자동화할 수 있어 배치 검증을 빠르고 반복 가능하게 합니다.

흔히 발생하는 함정과 방지 방법

함정	발생 원인	해결책
필드 플래튼 – 변환기가 페이지를 래스터화해 인터랙티브성이 사라짐	기본 설정이 파일 크기 감소를 우선시	Preserve forms 혹은 Do not flatten 옵션을 찾아 활성화하고, “Reduce file size” 옵션을 비활성화
JavaScript 검증 손실	보안상의 이유로 많은 엔진이 JavaScript를 제거	변환 전 스크립트를 내보내고, 필요 시 PDF 편집기나 포스트‑변환 스크립트를 통해 수동 재첨부
글꼴 불일치	글꼴이 임베드되지 않아 대체 글꼴이 적용, 필드 위치가 이동	모든 글꼴을 소스에 임베드하거나 변환기가 누락 글꼴을 자동 임베드하도록 설정
HTML에서 필드 매핑 오류 – PDF 필드 이름에 공백·특수문자가 포함돼 HTML `id` 로 사용할 수 없음	필드 이름을 HTML 규칙에 맞게 정제하지 않음	공백을 언더스코어 등으로 교체하고, 서버‑사이드 처리를 위한 매핑 테이블을 유지
탭 순서 깨짐	변환 과정에서 문서 흐름에 따라 필드가 재정렬됨	변환 시 TabIndex 속성을 명시하거나, 변환 후 PDF 편집기로 필드 순서를 재배열
계산된 필드 손실	스프레드시트 수식이나 PDF JavaScript가 전이되지 않음	수식을 별도 내보내고 대상 형식(Excel 수식, HTML JS)에서 재구성

이러한 문제를 미리 인지하면 대량 배치 작업 중에 발견하는 대신 사전에 방지할 수 있습니다.

최우수 실천 체크리스트

소스 감시: 모든 필드, 스크립트, 글꼴, 외부 리소스를 목록화
호환 형식 선택: 필요한 필드 유형을 지원하는지 확인
폼 보존 옵션 활성화: 사용 중인 변환 도구에서 해당 옵션을 켜기
모든 글꼴 임베드: 변환 전에 글꼴 누락 방지
스크립트 백업: 필요 시 재삽입을 위해 별도 저장
자동 구조 검사 실행: 필드 수·유형·이름 검증
실제 데이터로 기능 테스트
다중 뷰어에서 검증: 뷰어별 특이점 파악
변환 파라미터 기록: 도구 버전·설정 등을 문서화해 재현성 확보
소스·변환 파일 모두 버전 관리: 백업 및 추적 가능하도록 유지

이 체크리스트를 따르면 사용자 신뢰를 해치는 은밀한 실패를 크게 줄일 수 있습니다.

실제 배치 워크플로 예시

시나리오: 다국적 HR 부서는 태블릿에서 작성된 직원 온보딩 PDF를 수집합니다. 이들은 검색 가능한 PDF로 보관하면서, 급여 처리용 마스터 Excel 스프레드시트도 동시에 생성해야 합니다.

소스 PDF를 클라우드 버킷에 수집
프리플라이트 스크립트 실행 (Python + PyPDF2) – AcroForm 필드 목록을 추출해 각 문서마다 fields.json 파일로 저장
PDF → PDF (양식 유지) 변환을 convertise.app API로 수행, 플래그 preserveForms=true 지정. 반환된 압축 PDF를 바로 보관
채워진 데이터 추출 – 동일 스크립트로 pdf2fdf → xfdf → CSV 로 변환, 모든 직원 응답을 평면화된 형태로 생성
CSV → XLSX – pandas 로 간단히 쓰기, 숫자·날짜 형식 유지
검증 – 원본 PDF와 변환 PDF의 체크섬(sha256)을 비교해 압축 외에 의도치 않은 변경이 없음을 확인
CI/CD 파이프라인에 스케줄링 – GitHub Actions 로 매일 밤 실행, 새로운 제출이 자동으로 처리되도록 구성

핵심은 preserveForms 플래그가 원본 채우기 가능한 필드를 평평하게 만들지 않도록 보장하고, 별도의 데이터 추출 단계가 분석‑친화적인 데이터 세트를 제공한다는 점입니다.

마무리 생각

파일 변환을 단순히 “PDF → JPG” 같은 일방통행길로 생각하기 쉽습니다. 그러나 소스에 인터랙티브 양식 요소가 포함된 경우, 구조·동작·시각적 정확성 사이의 협상이 필요합니다. 채우기 가능한 필드의 해부학을 이해하고, 인터랙티브성을 진정으로 지원하는 대상 형식을 선택하며, 소스를 철저히 준비하고, 결과를 체계적으로 검증한다면 양식 손실 없이 자동화된 변환을 구현할 수 있습니다.

여기에 제시된 전략은 단일 문서뿐 아니라 대규모 배치 파이프라인에도 적용 가능합니다. 프라이버시를 존중하고 완전히 클라우드에서 동작하는 적절한 도구를 활용하면 양식의 기능을 유지하면서 데이터는 안전하게, 워크플로는 효율적으로 유지할 수 있습니다.

PDF 및 문서 변환 시 입력 가능한 양식 유지