계약서 한 장, 링크 하나로 끝내는 전자계약
본인·위변조 확인
전자계약에서 다투게 되는 건 결국 두 가지입니다.
서명한 사람이 본인인가, 그리고 지금 이 파일이 그때 그 문서인가.
리드싸인은 둘 다 증명할 수 있게 남깁니다.
IDENTITY
수령 확인서에 공동인증서를 요구하면 아무도 서명하지 않습니다.
반대로 큰 계약에 클릭 한 번은 불안합니다.
문서별로 골라 쓰십시오.
요청을 받은 그 번호로만 인증번호가 나갑니다.
다른 번호를 넣으면 발송 자체가 되지 않습니다.
요청을 받은 그 주소로 인증번호를 보냅니다.
사내 결재처럼 메일이 확실한 창구일 때 씁니다.
인증번호를 정해진 횟수 이상 틀리면 그 링크는 잠깁니다.
번호를 하나씩 넣어 보는 방식으로는 열 수 없고, 잠긴 사실도 기록에 남습니다.
마주 앉아 받는 자리라면 확인 절차 없이 바로 서명합니다.
이때도 누가 언제 어디서 서명했는지는 똑같이 남습니다.
어떤 수단을 쓰든 확인 시도 횟수를 넘기면 링크가 잠기고, 그 사실도 기록에 남습니다.
SEALING
문서 위에 찍히는 도장 그림은 사람이 보라고 있는 것입니다.
그 문서가 그때 그대로인지 가려내는 일은 지문이 합니다.
완성본 전체를 SHA-256으로 요약해 64자리 지문을 만듭니다.
한 글자, 점 하나만 달라져도 지문이 통째로 바뀝니다.
이 값과 문서 번호를 함께 보관합니다.
서명이 끝나면 지나온 과정을 한 장으로 굳혀 냅니다.
문서 번호, 지문, 서명자, 그리고 열람·확인·서명 시각이
접속 정보와 함께 적힙니다.
완성본은 원본을 덮어쓰지 않고 새 파일로 냅니다.
올린 원본, 서명 이미지, 완성본 모두 AES-256으로 잠가 보관합니다.
VERIFICATION
"우리를 믿어 달라"가 아니라, 손에 든 파일로 직접 대조해 보는 쪽이 맞습니다.
| 단계 | 하는 일 |
|---|---|
| 1. 문서 번호 확인 | 완성본 아래쪽에 문서 번호가 찍혀 있습니다. 검증 화면에 그 번호를 넣습니다. |
| 2. 파일 올리기 | 손에 든 PDF를 올리면 그 자리에서 지문을 다시 계산합니다. 파일 자체는 검증에만 쓰고 보관하지 않습니다. |
| 3. 대조 | 보관된 지문과 방금 계산한 지문을 맞춰 봅니다. 같으면 그때 그 문서, 다르면 어딘가 손을 탄 문서입니다. |
| 4. 결과 | 일치하면 서명자·서명 시각·문서 이름을 함께 보여 줍니다. 불일치하면 원본과 나란히 놓고 볼 수 있게 안내합니다. |
문서 검증 화면은 로그인 없이 누구나 쓸 수 있게 열어 둡니다 — 계약 상대가 리드싸인 고객이 아니어도 확인할 수 있어야 의미가 있습니다.
AUDIT TRAIL
서명이 완료되면 감사추적인증서가 자동으로 만들어집니다.
요청한 쪽과 서명한 쪽이 같은 기록을 봅니다.
| 남는 항목 | 내용 |
|---|---|
| 문서 | 문서 이름, 문서 번호, 문서 수, 완성본 지문(SHA-256) |
| 당사자 | 서명자 이름, 확인에 쓴 연락처(가운데를 가린 형태), 서명 순서 |
| 안내 | 서명 요청이 나간 시각과 창구(알림톡·이메일), 재발송 이력 |
| 열람 | 링크를 처음 연 시각, 이후 열람 시각 |
| 본인 확인 | 인증번호 발송·확인 시각, 실패 횟수, 잠금 여부 |
| 서명 | 서명한 시각, 서명 거절 시 그 사유 |
| 접속 환경 | IP 주소, 접속 기기·브라우저 종류 |
| 완료 | 완성본이 만들어진 시각, 완성본 지문, 전달 이력 |
감사 기록은 덧붙이기만 되고 지우거나 고칠 수 없는 형태로 쌓입니다.
관리자도 예외가 아닙니다.
인증서는 요청한 쪽만 갖는 것이 아닙니다.
서명을 마친 분도 완료 화면에서
같은 파일을 내려받습니다.
한쪽만 근거를 쥐고 있으면 그건 근거가 아닙니다.