도입
워드 계약서에 전자서명을 받기 전에 먼저 해결해야 할 문제는 서명란의 모양이 아니라 문서 버전입니다. 편집 가능한 Word 파일을 여러 사람이 주고받으면 각자 다른 수정본을 열거나, 서명 요청 이후에도 내용이 바뀔 수 있습니다.
매매 계약서를 기준으로 하면 내용 확정 → 고정본 생성과 검수 → 서명자·순서 설정 → 발송과 완료본 확인 순서가 명확합니다. 서명 대상은 승인된 한 버전이어야 하며, 완료된 문서와 서명 이벤트는 나중에 다시 찾을 수 있게 연결해 보관합니다.
Nota Sign은 확정된 계약서를 전자서명 워크플로로 보내고 다수 서명자의 순서와 완료 상태를 관리하는 데 활용할 수 있습니다. 다만 계약의 효력이나 요구되는 서명 방식은 문서 내용, 당사자, 준거법과 별도의 형식 요건을 검토해 판단해야 합니다.
계약서 내용을 확정한다
초안 단계에서는 변경 추적과 코멘트를 활용하되, 서명 전에 모든 검토 의견의 처리 여부를 확인합니다. 계약 당사자, 목적물, 금액, 지급 조건, 이행일, 해지 조건, 첨부 목록과 서명 권한자를 승인 기록과 대조합니다.
숨겨진 변경 내용이나 빈 입력란이 남아 있으면 서명 요청을 시작하지 않습니다. 확정본에는 계약 식별자, 버전, 승인자와 승인일을 연결하고, 수정이 생기면 기존 파일을 덮어쓰지 말고 새 버전으로 관리합니다.
고정본 결과물을 만든다
승인된 Word 파일을 PDF 등 표시가 고정되는 형식으로 내보냅니다. 변환 뒤에는 페이지 수, 줄바꿈, 표, 각주, 번호 매기기와 첨부 순서가 원본과 같은지 확인합니다.
특히 자동 목차, 교차 참조, 필드 값은 내보내기 전에 갱신해야 합니다. 표가 페이지 사이에서 잘리거나 서명란이 다음 페이지로 이동하면 당사자가 보는 문맥이 달라질 수 있습니다.
고정본의 해시값을 기록하면 어떤 파일을 발송했는지 식별하는 데 도움이 됩니다. 해시는 내부 통제 수단이며, 그 자체가 계약의 법적 효력을 결정하는 것은 아닙니다.
서명란과 순서를 설정한다
각 서명자의 이름, 역할, 소속과 연락처를 승인된 명단과 대조합니다. 대표자나 대리인이 서명하는 경우 내부적으로 확인한 권한 근거도 계약 기록에 연결합니다.
서명란과 날짜란은 담당자를 명확히 지정하고 조항을 가리지 않도록 배치합니다. 여러 명이 서명한다면 순차 서명과 병렬 서명 중 어떤 방식이 업무 요건에 맞는지 정한 뒤, 미리보기에서 각 수신자가 입력할 필드를 확인합니다.
수신자나 서명 순서를 바꿔야 한다면 변경 이유를 남깁니다. 계약 내용까지 달라졌다면 기존 요청을 계속 사용하지 말고 새 버전으로 다시 발송합니다.
송신과 전달을 점검한다
발송 직전 문서 버전, 수신자, 서명 순서와 완료본의 저장 위치를 한 번 더 확인합니다. 발송 후에는 각 참여자의 상태를 추적하되, 단순한 미열람과 인증 실패 또는 수신처 오류를 구분해 처리합니다.
모든 서명이 완료되면 최종 PDF를 열어 서명 상태와 문서 내용을 확인합니다. 승인된 고정본, 서명 완료본, 서명자·처리 시각·인증 결과 등 감사 기록을 같은 계약 식별자로 연결해 보관합니다.
서명 완료 파일은 Word 원본을 대체하지 않습니다. 두 파일은 서로 다른 역할을 가지므로 같은 파일명으로 덮어쓰지 않고, 수정이 필요하면 새 버전의 승인과 서명을 다시 진행합니다.





