서명하는 날에 완료 증명서를 읽는 사람은 없습니다. 증명서는 몇 년 뒤의 하루 이틀을 위해 존재합니다. 퇴사한 직원이 “저건 제 서명이 아닙니다”라고 말하는 날, 상대방이 같은 임대차 계약서의 조금 다른 사본을 들고 나오는 날, 감사인이 이 동의서가 치료 전에 체결되었다는 걸 어떻게 아느냐고 묻는 날 말입니다. 그런 날 증명서는 답변과 논쟁을 가르는 차이가 됩니다.
이 글은 그 문서에 무엇이 담겨야 하는지, 그리고 주요 도구들이 실제로 무엇을 건네주는지에 대한 이야기입니다. 4자 비교의 증거 중심 후속편입니다.
서명된 PDF만으로는 증거가 되지 않는 이유
서명 이미지가 얹힌 PDF는 그 자체로 거의 아무것도 증명하지 못합니다. 그 이미지는 다른 문서에서 붙여 넣었을 수도 있습니다. 파일은 서명 후에 날짜가 바뀌거나 조항이 교체되는 식으로 수정되었을 수도 있고, 눈에 보이는 흔적은 남지 않습니다. 양쪽 당사자가 각자 사본을 갖고 있어도 어느 쪽이 진본인지 가릴 방법이 없습니다. 게다가 파일은 과정에 대해 아무 말도 하지 않습니다. 누가 받았는지, 언제 열었는지, 무엇을 봤는지, 그들이 서명한 버전이 내가 가진 버전과 같은지 말이죠.
전자서명 법제는 바로 이 공백을 염두에 두고 있습니다. 전자서명을 방어 가능하게 만드는 것은 그 구불구불한 선이 아니라 그 주위의 귀속과 의사에 대한 기록입니다. 누가 요청받았고, 어떻게 확인되었고, 무엇을 했고, 언제 했는지 말이죠. 완료 증명서는 바로 그 기록을 담아 냅니다. 다시 말해 증명서는 제품에 딸려 오는 서류가 아니라, 분쟁이 벌어지면 그것이 곧 제품입니다.
좋은 증명서의 구성 요소
업체마다 다른 꾸밈을 걷어 내면, 가질 만한 증명서는 여섯 가지 질문에 답합니다.
| 요소 | 답하는 질문 |
|---|---|
| 영구 참조번호 | 몇 년이 지나도, 수정을 거쳤어도 이것이 어느 문서인지 명확한가? |
| 완료 시각(UTC) | 누구도 이견을 낼 수 없는 시간대로, 체결이 언제 끝났는가? |
| 서명자별 타임라인 | 각 사람이 언제 요청받고, 언제 열람하고, 언제 서명했는가? |
| IP 주소 | 각 서명은 어디에서 이루어졌는가? |
| 서명 이미지 | 입력된 각 서명은 실제로 어떤 모습이었는가? |
| 검증 코드 | 이 종이를 액면 그대로 믿는 대신 원장과 대조해 확인할 수 있는가? |
이 중 둘은 가장 자주 빠지는 항목이라 강조할 만합니다. 참조번호는 영구적일 때에만 쓸모가 있습니다. 문서를 수정해 재서명할 때 식별자가 바뀌면 기록의 흐름이 갈라져 버립니다. 그리고 검증 코드는 문서 이력에서 도출되었을 때에만 의미가 있습니다. 그냥 찍어 넣은 코드와 달리, 전체 감사 추적의 지문인 코드는 위변조를 드러낼 수 있습니다. 단순한 식별자에 불과한 코드는 그럴 수 없습니다.
PandaDoc, SignNow, Adobe는 감사 증거를 어떻게 포장하나
세 경쟁 제품 모두 실질적인 증거를 만들어 냅니다. 이 절은 형식에 관한 이야기인데, 서명과 분쟁 사이의 긴 세월을 무엇이 견뎌 내는지는 형식이 결정하기 때문입니다.
PandaDoc은 서명된 문서와 함께 완료 증명서를 발급하며 예상되는 내용이 담깁니다. 서명자 신원, IP 주소, 시각, 문서 ID가 앱 내 감사 추적의 뒷받침을 받습니다. SignNow의 대응물은 문서 이력입니다. 누가 언제 무엇을 했는지 담은 내려받기 가능한 보고서로, 법정에서 인정받을 수 있다고 홍보되며 서명본과 함께 보관됩니다. 둘 다 유능하고 관례적인 구성입니다. 주된 취약점은 분리 가능성입니다. PDF 옆에 따라다니는 보고서는 함께 따라가지 못할 수도 있는 보고서입니다. 증명서 없이 서명본만 전달하면 받는 사람이 쥐는 것은 증거가 아니라 주장입니다.
Adobe Acrobat Sign이 셋 중 가장 강력하며 이 점은 분명히 말씀드립니다. 감사 보고서를 넘어, 완료된 문서에는 암호학적 봉인이 실리고 인증서 기반 구성에서는 서명 자체가 PDF에 삽입되어 규격을 따르는 어떤 뷰어에서도 오프라인으로, Adobe에 묻지 않고 검증됩니다. EU 적격 서명이나 오프라인 암호 검증이 필요한 환경이라면 Adobe가 가장 깊은 답을 갖고 있습니다. 이견의 여지가 없습니다.
GingerDocs의 증명서는 어떻게 생성되고 검증되나
GingerDocs의 설계 원칙은 증거가 결과물과 분리될 수 없어야 한다는 것입니다. 마지막 서명자가 마치면 완료 증명서가 자동으로 생성되어 서명본 PDF 자체의 마지막 페이지로 덧붙습니다. 잃어버릴 별도의 보고서가 없습니다. 문서를 가진 사람이 곧 증거를 가진 사람입니다.
증명서에는 문서의 영구 참조번호(한 번 부여되면 이후 문서를 수정해 재서명해도 바뀌지 않습니다), UTC 기준 완료 일시, 제목과 페이지 수, 그리고 서명자마다 이름과 이메일, 서명 순서, 최종 상태(서명 완료, 확인 완료, 거절), UTC 기준 요청–열람–서명 전체 타임라인, 각 서명이 이루어진 IP 주소, 그리고 입력된 실제 서명 이미지가 담긴 카드가 들어갑니다.
그리고 이 종이를 대조 가능하게 만드는 부분이 있습니다. 문서의 위변조 감지 감사 추적에서 도출된 16자리 검증 코드로, 일련번호가 아니라 완료 시점에 기록된 전체 이력의 지문입니다. PDF를 가진 사람은 누구나 플랫폼 기록과 대조해 확인할 수 있습니다. 검증 페이지는 계정 없이 참조번호와 문서에 연결된 이메일만 있으면 되고, 문서 소유자는 GingerDocs 안에서 참조번호와 검증 코드를 기록과 맞춰 볼 수 있습니다. 그 뒤에서는 업로드한 원본 파일이 손대지 않은 채로 이전에 서명된 모든 버전과 함께 보존되므로 “이 문서는 전에 어떤 모습이었나?”라는 질문에 언제나 꺼내 볼 수 있는 답이 있습니다.
위변조 감지: 해시 체인 로그와 단순 활동 목록
모든 증명서는 그 밑에 깔린 로그에서 생성되므로, 증명서의 신뢰도는 그 로그가 수정에 얼마나 견디는지를 넘어설 수 없습니다. 기능 목록보다 아키텍처가 도구를 더 크게 갈라놓는 지점이 바로 여기입니다.
일반적인 활동 로그는 애플리케이션이 기록하는, 그리고 원칙적으로는 다시 쓸 수도 있는 데이터베이스 테이블입니다. 남아 있는 행들만 봐서는 어느 것이 변경되었거나 삭제되었는지 알 수 없습니다. 그런 로그에서 생성된 증명서는 그 약점을 그대로 물려받습니다. 생성 시점에 로그가 말한 내용을 증언할 뿐이고, 로그 자체의 무결성은 업체의 보증에 기대게 됩니다.
GingerDocs의 감사 로그는 추가 전용이자 해시 체인입니다. 전송, 열람, 서명, 거절, 리마인더, 완료 등 모든 이벤트가 직전 항목과 이어 주는 SHA-256 해시와 함께 기록됩니다. 과거 항목을 수정하면 조작이 일어난 지점에서 체인이 눈에 띄게 끊어집니다. 이 로그는 믿는 것이 아니라 확인할 수 있는 것입니다. 그리고 증명서의 16자리 검증 코드가 그 체인에서 도출되기 때문에, 종이 위의 코드와 기록 속의 체인이 서로를 보증합니다. 한쪽만 위조하는 일은 티가 나기 마련입니다.
공정한 채점표는 이렇습니다. Adobe는 파일 내부에서 암호학적으로 위변조 감지를 달성하고, GingerDocs는 원장에서 달성한 뒤 그 지문을 증명서에 인쇄합니다. PandaDoc과 SignNow는 관례적인 증명서 뒤에 관례적인 로그를 둡니다.
누군가 이의를 제기할 때 실제로 문서를 검증하는 방법
이론은 접어 두고, 완료된 GingerDocs 문서를 손에 들고 맞이하는 분쟁의 날은 이런 모습입니다.
- 증명서를 펼칩니다. PDF 자체의 마지막 페이지입니다. 참조번호와 16자리 검증 코드를 읽습니다.
- 기록과 대조합니다. 계정이 필요 없는 검증 페이지에서 참조번호와 문서에 연결된 이메일을 입력해 상태를 확인하고 검증본을 내려받거나, 문서 소유자가 GingerDocs 안에서 참조번호와 검증 코드를 기록과 맞춰 봅니다. 증명서와 플랫폼의 체인이 일치하면 그 문서는 확인된 것입니다.
- 타임라인을 따라갑니다. 문제가 된 서명에는 카드가 있습니다. 그 서명자가 언제 요청받았고, 언제 열람했고, 언제 어느 IP에서 서명했으며, 입력된 서명이 어떤 모습이었는지를 상대의 주장과 비교해 보세요.
- “문서가 달랐다”는 주장이라면 보존된 원본과 이전 서명 버전을 꺼내 최종 플래튼본과 나란히 놓고 비교하세요.
- 분쟁이 커지면 그 밑의 감사 로그가 심층 기록입니다. 추가 전용이고, 해시로 연결되어 있으며, 처음부터 끝까지 무결성을 확인할 수 있습니다.
이제 같은 절차를 메일 스레드에서 받은 맨 서명본 PDF로 해 보세요. 참조번호도, 코드도, 타임라인도, 보존된 원본도 없이 서로 다른 이력을 주장하는 두 당사자만 남습니다. 그 간극이야말로 필요해지기 전에 증명서의 내용에 신경 써야 하는 이유 전부입니다.
언제나처럼 5분짜리 테스트가 기능 비교표를 이깁니다. 검토 중인 도구에서 실제 문서를 완료까지 진행해 보고, 나온 결과물을 열어 마지막 페이지에 이렇게 물어보세요. 낯선 사람이 내 말을 전혀 믿지 않고도 이것을 검증할 수 있는가? GingerDocs가 무엇을 건네는지 보시려면 문서 한 건을 전체 흐름에 넣어 보세요.