PDF 검토가 여러 사람을 거치면 파일명은 “최종”, “최종2”, “진짜최종”로 늘어납니다. 문제는 이름이 지저분한 데 있지 않습니다. 누가 어느 시점에 무엇을 표시했고, 어떤 상태에서 다음 검토가 시작됐는지 연결되지 않는 데 있습니다. PDF 버전 관리는 파일 사본을 더 만드는 일이 아니라 검토의 맥락을 보존하는 구조입니다.
PDF 저장과 PDF 버전 관리는 다르다
일반적인 PDF 편집 연동은 현재 편집 상태 하나를 저장하고 다음 저장 때 같은 값을 갱신하는 방식으로 시작합니다. 구현은 단순하지만 이전 상태가 사라지므로 검토 순서, 작성자, 되돌아갈 기준점을 별도로 재구성해야 합니다. 버전 관리가 필요한 업무라면 저장 버튼보다 먼저 “한 번 저장된 검토본을 새 행으로 남길 것인가”를 결정해야 합니다.
| 구분 | 현재 상태 덮어쓰기 | append-only 버전 관리 |
|---|---|---|
| 저장 방식 | 기존 편집 상태를 갱신 | 저장마다 새 버전으로 추가 |
| 과거 상태 | 별도 백업이 없으면 확인 어려움 | 버전 번호·작성자·시각과 함께 조회 |
| 이어서 편집 | 최신 상태 중심 | 선택한 시점을 복원해 새 버전으로 계속 작업 |
| 복수 검토자 | 파일을 나누거나 결과를 병합 | 사용자별 저장본을 레이어로 겹쳐 비교 |
| 운영 책임 | 현재본의 정확성 관리 | 권한·불변성·보존·동시성 정책까지 관리 |
PDF 검토 이력을 남기는 다섯 단계
- 원본 PDF 개정을 식별합니다 — 파일명 대신 문서 ID와 원본 해시 또는 개정 ID를 함께 관리해야 다른 원본에 편집 이력이 잘못 붙는 일을 막을 수 있습니다.
- SDK가 편집 상태를 내보냅니다 — Inko는 펜·형광펜·도형 등 현재 편집 상태를 canvasData 문자열로 반환합니다. 원본 PDF와 편집 데이터는 분리됩니다.
- 호스트 API가 작성자와 권한을 확인합니다 — 사용자 ID는 브라우저 입력을 신뢰하지 않고 인증 세션에서 서버가 확정합니다. 저장할 문서의 접근권한도 이 단계에서 검사합니다.
- 호스트 DB가 새 버전을 INSERT합니다 — 같은 행을 UPDATE하는 대신 문서 개정, 버전 번호, 부모 버전, 작성자, 해시, 멱등키와 canvasData를 새 레코드로 저장합니다.
- 선택한 버전을 다시 주입합니다 — 최신본이나 과거 시점의 canvasData를 편집 캔버스로 불러오면 그 상태에서 이어서 편집할 수 있고, 여러 저장본은 읽기 레이어로 겹쳐 비교할 수 있습니다.
여러 검토자가 같은 PDF를 볼 때 필요한 두 화면
계약서·도면·품질 문서는 한 사람이 끝까지 편집하기보다 법무, 현업, 승인자가 차례로 검토하는 경우가 많습니다. 이때 “현재 편집 캔버스”와 “참고용 검토자 레이어”를 구분하면 작업 중인 내용과 다른 사람의 표시가 섞이지 않습니다.
- 이어서 편집 화면 — 선택한 canvasData를 편집 가능한 상태로 복원합니다. 이후 저장 콜백 결과를 새 버전으로 남길지는 호스트 백엔드가 결정합니다.
- 검토자 레이어 화면 — 사용자별 또는 버전별 저장본을 읽기 레이어로 올리고 항목마다 켜고 끕니다. 여러 사람의 표시를 한 화면에서 비교하되 현재 편집 결과에는 합치지 않습니다.
- 검토본 목록 — Inko는 호스트가 전달한 검토자 이름·식별자·등록 시각을 레이어 목록에 표시합니다. 버전 번호·부모 버전·현재 기준점은 호스트 앱이 관리합니다.
self-hosted PDF SDK를 검토할 때 확인할 운영 항목
| 확인 항목 | 결정해야 할 질문 | 완료 증거 |
|---|---|---|
| 데이터 경로 | PDF와 편집 데이터가 어느 서버를 거치는가? | 네트워크 흐름도와 저장 위치 |
| 버전 불변성 | 저장된 행의 UPDATE·DELETE를 누가 막는가? | DB 권한·보존·백업 정책 |
| 작성자 신뢰 | 작성자 ID를 서버 인증에서 확정하는가? | 인증·인가 테스트 결과 |
| 동시 편집 | 같은 기준 버전에서 두 저장이 오면 어떻게 처리하는가? | 충돌 감지·분기·재시도 규칙 |
| 원본 개정 | PDF 원본이 바뀌면 기존 마크업을 어떻게 구분하는가? | 문서 개정 ID 또는 해시 규칙 |
| 복구 검증 | 선택한 시점이 실제로 동일하게 열리는가? | 대표 문서 복원 테스트 |
self-hosted는 데이터를 자동으로 안전하게 만든다는 뜻이 아닙니다. SDK 번들을 이용자 환경에 직접 배포한다는 뜻이며, 접근권한·암호화·백업·보존·감사 정책은 실제 운영 구성에서 확인해야 합니다. 특히 append-only 편집 이력은 위변조 방지 감사로그나 전자서명과 동일하지 않으므로 규제 요건이 있다면 별도 통제를 설계해야 합니다.
Inko가 맡는 부분과 호스트 앱이 맡는 부분
| Inko SDK | 호스트 애플리케이션·백엔드 |
|---|---|
| PDF뷰어와 PDF 마크업 기능 | 사용자 인증과 문서 접근권한 |
| 편집 상태를 canvasData로 반환·복원 | canvasData와 버전 메타데이터의 영구 저장 |
| 과거 상태부터 이어서 편집 | 버전 번호·부모 버전·충돌 정책 |
| 다중 사용자·다중 버전 레이어 표시 | 보존·백업·삭제 제한·감사 통제 |
| self-hosted 정적 번들과 임베드 API | 배포 서버·네트워크·모니터링 운영 |
자체 적용 전 작은 검증으로 확인할 것
- 대표 PDF 한 건을 열고 두 명의 검토자가 서로 다른 표시를 저장합니다.
- 저장할 때마다 기존 행이 바뀌지 않고 새 버전이 추가되는지 확인합니다.
- 과거 버전을 선택해 동일한 편집 상태가 복원되고 그 지점부터 새 버전으로 이어지는지 확인합니다.
- 두 검토자의 저장본을 레이어로 켜고 끄며 현재 편집 캔버스와 분리되는지 확인합니다.
- 권한이 없는 사용자의 조회·저장, 중복 요청, 원본 개정 불일치가 서버에서 차단되는지 테스트합니다.
이 다섯 가지가 통과하면 “PDF를 편집할 수 있는가”를 넘어 “우리 조직의 검토 이력을 운영할 수 있는가”를 판단할 수 있습니다. 제품 비교표에는 도구 수보다 저장 책임, 버전 불변성, 복수 검토자 표시, 시점 복원과 운영 통제를 함께 적는 편이 정확합니다.