문서 변환 중 변경 추적 및 개정 이력 보존

문서가 한 형식에서 다른 형식으로 이동할 때, 눈에 보이는 텍스트는 그대로 유지되지만 그 뒤에 숨겨진 이야기—누가 언제 왜 편집했는가—는 사라질 수 있습니다. 감사 추적에 의존하는 법무팀, 검토자 및 모든 협업 환경에 있어 변경 추적과 개정 이력을 유지하는 것은 필수적입니다. 추적된 편집이 포함된 Word .docx를 PDF, ODT, 혹은 일반 텍스트 버전으로 변환한다고 해서 파일의 권한을 부여하는 출처 데이터가 사라져서는 안 됩니다.

아래는 가장 일반적인 변환 경로에서 편집 메타데이터를 보존하기 위해 필요한 기술적 고려 사항, 워크플로 패턴 및 도구별 설정을 단계별로 안내하는 심층 가이드입니다. 이 조언은 convertise.app과 같은 프라이버시 우선 클라우드 기반 변환기를 사용한다고 가정하지만, 원칙은 온프레미스 스크립트와 데스크톱 유틸리티에도 동일하게 적용됩니다.

개정 데이터가 중요한 이유

변경 추적은 단순히 시각적인 마크업을 넘어 책임 계약을 구현합니다. 계약을 검토할 때 각 삽입, 삭제, 주석은 특정 검토자, 타임스탬프 및 근거와 연결될 수 있습니다. 변환 과정에서 이 레이어를 제거하면 최종 내용은 보이지만 의사 결정 과정이 불투명해지는 “블랙 박스” 문서가 됩니다. 규제가 강한 분야—법률, 금융, 의료—에서는 이러한 손실이 컴플라이언스를 위협하고 증거 가치를 약화시킬 수 있습니다.

컴플라이언스를 넘어, 개정 이력은 지식 전수에도 도움이 됩니다. 새로운 팀원이 문장이 왜 바뀌었는지 이해함으로써 회귀 오류를 방지하고 의도를 명확히 할 수 있습니다. 따라서 변환 중 이 컨텍스트를 보존하는 것은 위험 완화 전략이자 생산성 향상 수단입니다.

변환 시 주요 과제

1. 형식별 지원 차이 – 모든 형식이 트랙 변경을 위한 고유 표현을 갖고 있지는 않습니다. Word의 XML 스키마(docx)에는 <w:ins>와 <w:del> 요소가 있지만, PDF에는 표준화된 대응 요소가 없으며 대신 주석이나 선택적 레이어에 의존합니다.
2. 손실성 렌더링 파이프라인 – 많은 변환 도구가 문서를 최종 모습으로 평탄화하면서 마크업을 제거합니다.
3. 메타데이터 매핑 – 대상 형식이 편집 메타데이터를 지원하더라도(예: ODT) 변환 엔진이 Word 고유 속성(작성자, 날짜, 주석 ID)을 해당 ODF 필드에 매핑해야 합니다.
4. 프라이버시 문제 – 개정 데이터에는 민감한 개인 정보가 포함될 수 있습니다. 변환 워크플로는 보존과 필요한 경우의 적절한 삭제(레드랙션) 사이에서 균형을 맞춰야 합니다.

이러한 제약을 이해함으로써 변환 전략을 선택할 수 있습니다.

적절한 대상 형식 선택

편집 흔적을 그대로 활용해야 한다면 ODT와 PDF/A‑3가 가장 신뢰할 수 있는 대상입니다. 읽기 전용 스냅샷만 필요하다면 표준 PDF에 마크업을 “보여 줌(Show Markup)” 형태로 구워 넣는 방식으로 충분합니다.

무손실 보존을 위한 워크플로 청사진

1. 소스 문서 감사

먼저 소스에 실제로 트랙 변경이 포함되어 있는지 확인합니다. Microsoft Word에서 검토 탭을 열어 변경 내용 추적 상태를 확인합니다. 검토자 목록을 내보내려면(파일 → 정보 → 문제 확인 → 문서 검사) 개인 정보가 숨겨져 있는지 확인하고, 변환 전에 레드랙션이 필요한지 판단합니다.

2. 원하는 가시성 결정

• 보이는 마크업 – 변환된 파일이 Word에서 보는 그대로 삽입·삭제·주석을 표시합니다.
• 숨김 마크업 – 변경 내용은 저장되지만 기본 보기에서는 표시되지 않으며, 지원 뷰어에서 토글할 수 있습니다.

PDF는 대부분의 리더가 인터랙티브한 “변경 추적” 모드를 제공하지 않으므로 보통 보이는 마크업을 선택합니다. ODT는 LibreOffice와 OpenOffice가 변경 레이어를 인식하므로 숨김 마크업도 보존할 수 있습니다.

3. 변환기 설정

convertise.app 같은 클라우드 서비스를 사용할 경우 고급 옵션(노출된 경우)에서 마크업 처리 방식을 제어합니다.

• "Preserve markup" – 삽입·삭제 하이라이트를 PDF에 오버레이 그래픽으로 렌더링합니다.
• "Embed original file" – PDF/A‑3 컨테이너에 원본 docx를 저장해 전체 변경 세트를 복구 가능하게 합니다.
• "Include comments as annotations" – Word 주석을 PDF 주석으로 매핑합니다.

UI에 해당 토글이 없을 경우 API 요청에 쿼리 파라미터를 추가합니다(예: ?preserveMarkup=true&embedSource=docx). 서비스 문서에서 정확한 플래그명을 확인하세요.

4. 테스트 변환 실행

다음 요소를 모두 포함한 작은 샘플을 변환합니다.

• 작성자 A가 삽입한 문단
• 작성자 B가 삭제한 문장
• 다중 작성자 주석

대상 애플리케이션에서 결과를 확인합니다.

• PDF – 삽입은 대비색으로, 삭제는 취소선으로 표시되는지 확인하고, 주석 패널에 원본 메모가 나타나는지 검증합니다.
• ODT – LibreOffice에서 변경 내용 추적을 켜고 끄면서 숨김 편집이 존재하는지 확인합니다.
• PDF/A‑3 – 오른쪽 클릭 → 첨부 파일 보기 로 임베드된 docx를 추출하고, 변경 데이터가 온전한지 확인합니다.

5. 무결성 검사 자동화

대량 변환 시에는 검증 스크립트를 작성해 임베드된 소스와 가시적 마크업을 비교합니다. 예시 Python 코드:

import subprocess, hashlib, pathlib

def file_hash(path):
    return hashlib.sha256(path.read_bytes()).hexdigest()

def validate(source, pdf):
    # qpdf 또는 pdfdetach 로 임베드된 docx 추출
    extracted = pathlib.Path('tmp.docx')
    subprocess.run(['pdfdetach', '-save', '1', '-o', str(extracted), str(pdf)])
    assert file_hash(source) == file_hash(extracted), "Embedded source mismatch"
    # 선택사항: pandoc 으로 평문 diff 생성 후 비교

CI/CD 파이프라인에 이 스크립트를 포함하면 모든 배치 변환이 보존 계약을 충족함을 보장할 수 있습니다.

6. 필요 시 레드랙션 적용

개정 이력에 공개해서는 안 되는 개인 식별자가 포함된 경우, 변환 전에 이를 제거합니다.

• Word의 문서 검사 도구로 작성자 이름 삭제
• 주석을 일반적인 플레이스홀더(예: “프라이버시 보호를 위해 주석 삭제”) 로 교체
• PDF에서는 주석 메타데이터를 대상으로 레드랙션 툴 사용

정화 작업이 끝난 뒤에만 원본 파일을 임베드하면, 컴플라이언스를 유지하면서도 이후 감사를 위한 기록을 남길 수 있습니다.

도구별 가이드

Microsoft Word → PDF (Office 내보내기)

Word 내장 PDF로 저장 기능에는 Publish What 드롭다운이 있습니다. 문서 표시 마크업을 선택하면 보이는 변경 사항이 포함됩니다. 하지만 이 PDF는 편집 가능 변경 세트를 포함하지 않으며 시각적 표현만 제공합니다. 전체 출처를 보존하려면 서드파티 플러그인(예: PDF/A 애드인)을 이용해 PDF/A‑3 로 내보내고 원본 docx를 임베드하도록 해야 합니다.

LibreOffice / OpenOffice → ODT → PDF/A‑3

LibreOffice에서는 PDF/A‑3 로 내보내기 시 “ODF 문서 포함” 옵션을 선택하면 소스 ODT 파일이 PDF와 함께 패키징됩니다. ODT 자체가 변경 추적을 네이티브하게 지원하므로 임베드된 파일은 정확한 기록을 유지합니다.

Convertise.app API

서비스는 멀티파트 업로드와 옵션용 쿼리 플래그를 받습니다. 일반적인 CURL 요청 예시는 다음과 같습니다.

curl -X POST "https://api.convertise.app/convert?target=pdfa3&preserveMarkup=true&embedSource=docx" \
  -F "file=@contract.docx" \
  -o "contract_converted.pdf"

응답으로 변환된 PDF/A‑3 파일이 반환됩니다. 앞서 소개한 pdfdetach 유틸리티를 사용해 첨부된 소스를 다운로드하고 검증할 수 있습니다.

텍스트 기반 워크플로를 위한 Pandoc

Pandoc은 docx → markdown 변환 시 --extract-media 플래그를 이용해 주석을 각주 형태로 보존할 수 있습니다. 마크다운 자체는 변경 추적 모델을 갖고 있지 않으므로, 별도의 JSON 파일에 diff 정보를 직렬화해 두면 downstream 도구가 필요 시 개정 이력을 재구성할 수 있습니다.

pandoc contract.docx -t markdown -o contract.md --extract-media=media
pandoc --metadata=changes.json -f docx -t json contract.docx > changes.json

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

1. PDF가 숨김 마크업을 유지한다고 착각 – 표준 PDF는 변경 레이어를 삭제합니다. 도구가 시각적 마크업을 “굽는”(bake in) 것인지, 실제로 소스를 임베드하는지 반드시 확인하세요.
2. 작성자 메타데이터 방치 – 눈에 보이는 작성자 이름을 제거해도 Word XML에 작성자 정보는 남아 있습니다. 프라이버시가 필요하면 문서 검사를 통해 제거하십시오.
3. 기본 변환 설정에 의존 – 많은 클라우드 서비스가 파일 크기 감소를 위해 기본적으로 평탄화 모드로 동작합니다. 보존 플래그를 명시적으로 활성화하세요.
4. 임베드된 소스 과도 압축 – PDF/A‑3 은 원본 파일을 재압축 없이 삽입할 수 있습니다. 과도한 압축을 적용하면 docx 가 손상되어 추후 추출이 실패할 수 있습니다.
5. 변환 후 검증 생략 – 수동 검증은 수천 파일을 다룰 때 미세한 마크업 손실을 놓치기 쉽습니다. 자동화된 검증으로 위험을 최소화하세요.

엔터프라이즈 규모 적용 방안

법무 부서가 매월 수천 건의 계약서를 변환해야 하는 경우, 수작업은 현실적이지 않습니다. 확장 가능한 아키텍처는 일반적으로 다음과 같이 구성됩니다.

• 메시지 큐 – RabbitMQ 등에서 변환 요청(IP, 원하는 대상, 프라이버시 플래그)을 받아들입니다.
• 워커 서비스 – 무상태 마이크로서비스가 파일을 가져와 적절한 쿼리 파라미터와 함께 Convertise API를 호출하고, 결과를 안전한 객체 저장소에 저장합니다.
• 감사 로그 – 각 변환에 대해 소스 체크섬, 대상 체크섬, 보존 플래그 등을 기록하고, 불변성을 보장하며 컴플라이언스 감사를 위해 검색 가능하게 보관합니다.
• 알림 훅 – 변환이 성공하면 이벤트를 발생시켜 문서 관리 시스템으로 넘기거나, 법률 검토자가 임베드된 소스에 접근하도록 합니다.

보존 모드를 명시적으로 태깅하고 변환 단계를 분리함으로써 성능과 책임성을 동시에 확보할 수 있습니다.

요약 체크리스트

• 보존할 개정 데이터 식별 (변경 추적, 주석, 작성자 정보 등)
• 보존 수준에 맞는 대상 형식 선택 (전체 편집 레이어가 필요하면 ODT, 아카이브와 원본 접근을 동시에 원하면 PDF/A‑3)
• 가능하면 마크업을 보존하고 원본 파일을 임베드하도록 변환 도구 구성
• 대표 샘플로 테스트하고 시각·숨김 레이어 모두 검증
• 체크섬 검증 및 소스 추출 자동화
• 프라이버시 요구사항이 있으면 변환 전 민감 정보 레드랙션
• 워크플로와 로그를 문서화하여 컴플라이언스 확보

변경 추적과 개정 이력을 보존하는 일은 번거로운 사후 작업이 아닙니다. 편집 메타데이터를 일류 콘텐츠로 다루고, 올바른 형식을 선택해 변환기를 정확히 설정한 뒤 결과를 검증한다면, 문서를 플랫폼 간에 이동시켜도 그 문서에 부여된 권위와 이야기를 지울 필요가 없습니다. 이는 법적 방어력을 강화하고 투명한 협업을 지원하며, convertise.app과 같은 프라이버시 중심 서비스의 철학과도 일치합니다.