전자서명의 효력과 증거력: 유효한 것과 증명되는 것의 차이
전자서명 도입을 검토하면 거의 항상 같은 질문이 먼저 나옵니다. "이거 법적으로 효력 있나요?"
답은 있습니다. 2020년 12월 시행된 개정 전자서명법이 공인인증서 독점을 없앴고, 그 뒤로는 방식을 따지지 않습니다. 그런데 이 답을 듣고 나면 대개 안심하고 검토가 끝납니다. 저는 그 지점이 문제라고 봅니다. 효력을 확인한 것으로 확인해야 할 것을 다 확인했다고 생각하게 되기 때문입니다.
먼저 밝혀 둡니다. 이 글은 법률 자문이 아닙니다. 조문은 확인해 적었지만, 금액이 크거나 다툼이 예상되는 계약은 변호사에게 물어야 합니다.
효력을 묻는 질문이 빗나가는 이유
효력과 증거력은 다른 축입니다. 효력은 "이 서명이 서명으로 인정되는가"이고, 증거력은 "다툼이 났을 때 무엇을 내놓을 수 있는가"입니다.
효력은 법이 이미 정해 두었습니다. 전자서명법 제3조 제1항은 전자서명이 전자적 형태라는 이유만으로 서명이나 기명날인으로서의 효력이 부인되지 아니한다고 정하고 있습니다. 같은 조 제2항은 법령이나 당사자 간의 약정에 따라 전자서명을 선택한 경우 서명·기명날인의 효력을 가진다고 합니다. 전자문서 및 전자거래 기본법 제4조 제1항도 전자문서가 전자적 형태라는 이유로 문서로서의 효력이 부인되지 아니한다고 정합니다.
제2항의 "당사자 간의 약정"이 실무에서 쓸모가 있습니다. 계약서 본문에 전자서명으로 체결한다는 조항을 한 줄 넣어 두면 근거가 한 겹 더 생깁니다.
여기까지는 어느 서비스를 쓰든 같습니다. 효력은 서비스가 만드는 것이 아니라 법이 인정하는 것이라, 이 질문으로는 서비스끼리 구별되지 않습니다. 구별은 다음 질문에서 시작됩니다.
다툼은 늘 같은 모양으로 옵니다
전자서명에서 분쟁이 생기면 상대의 주장은 거의 한 문장입니다. "나 그거 서명 안 했다."
이때 효력이 있다는 사실은 도움이 되지 않습니다. 효력은 서명이 있었다면 그것이 유효하다는 말이지, 서명이 있었다는 말이 아닙니다. 있었다는 것은 따로 증명해야 합니다.
종이 계약에서 도장이 강한 이유가 여기 있습니다. 민사소송법 제357조는 사문서의 진정을 증명하라고 요구하고, 제358조는 본인의 서명이나 날인이 있으면 그 문서를 진정한 것으로 추정한다고 정합니다. 이 추정이 붙으면 다투는 쪽이 뒤집을 책임을 집니다. 인감과 인감증명서가 실무에서 무겁게 쓰이는 것도 이 구조 때문입니다.
전자서명에는 이만큼 단단한 추정 장치가 붙지 않습니다. 그래서 무엇을 얼마나 기록해 두었는지가 그 자리를 대신합니다.
무엇이 증명되고 무엇이 안 되나
전자서명 시스템이 남기는 것을 항목별로 갈라 보면 강한 곳과 약한 곳이 뚜렷하게 나뉩니다. 아래는 문서를 동결하고 해시 체인으로 기록을 잇는 방식을 기준으로 한 것입니다.
| 항목 | 증명력 | 근거 |
|---|---|---|
| 문서 무결성 | 강함 | 요청 시점의 PDF 를 통째로 얼리고 SHA-256 을 박습니다. 봉인본 증명서에 그 해시가 인쇄됩니다 |
| 시간 순서 | 있음 | 열람·코드 입력·서명 시각이 해시 체인으로 이어집니다. 중간을 고치면 이후가 어긋납니다 |
| 접근 사실 | 부분적 | 링크 토큰과 접근코드를 다른 경로로 보냅니다. 링크 하나가 유출돼도 서명이 되지 않습니다 |
| 본인 확인 | 약함 | 휴대폰 본인인증이 아닙니다. "그 메일과 그 번호를 쥔 누군가"까지입니다 |
| 객관적 시각 | 없음 | 서비스 서버의 시계입니다. 제3자가 보증한 시각이 아닙니다 |
무결성이 가장 튼튼하고, 본인 확인이 가장 약합니다. 이 두 줄이 이 방식의 성격을 거의 다 설명합니다. "이 문서가 그때 그 문서다"는 강하게 말할 수 있고, "이 사람이 눌렀다"는 약하게밖에 말하지 못합니다.
본인 확인을 올리려면 휴대폰 본인인증이나 인증서 기반 서명을 붙여야 합니다. 다만 그건 붙이면 되는 부품이 아니라 발급과 보관이라는 다른 문제를 데려옵니다.
보관자가 당사자일 때 생기는 문제
기술과 별개로 구조에서 오는 약점이 하나 있습니다. 서명 기록을 보관하는 쪽이 계약 당사자이기도 할 때입니다.
전문 전자서명 서비스의 값어치 가운데 상당 부분은 암호 기술이 아니라 이해관계가 없는 제3자가 보관한다는 사실에서 나옵니다. 자체 구축한 시스템은 그 자리를 차지하지 못합니다. 상대가 "그쪽이 기록을 손봤다"고 주장하면, 우리 서버의 기록으로 반박하는 일이 자기 말을 자기가 증명하는 모양이 됩니다.
이건 코드를 잘 짜서 없앨 수 있는 문제가 아닙니다. 줄이는 방법은 기술 바깥에 있습니다. 서명이 끝난 봉인본을 상대도 같은 파일로 갖고 있게 하면, 양쪽이 같은 해시의 사본을 쥐게 되어 한쪽이 조용히 고쳤다는 주장이 서기 어려워집니다.
해시 체인이 닿지 않는 곳
기록을 해시 체인으로 잇는 방식은 앞의 기록을 뒤의 기록이 품게 만들어, 중간의 한 줄을 고치면 그 뒤가 전부 어긋나게 합니다.
여기서 정직해야 하는 부분이 있습니다. 체인은 부분 조작을 드러낼 뿐, 전면 조작을 막지 못합니다. 데이터베이스를 통째로 다시 쓸 수 있는 사람은 체인도 함께 다시 계산합니다. 값어치는 "우리도 못 고친다"가 아니라 "고치면 표가 난다"입니다.
실무에서 실제로 벌어지는 조작은 대개 부분 조작이라 이것만으로도 쓸모가 있습니다. 그 이상이 필요하면 외부 시각인증기관의 타임스탬프를 받아야 하고, 그때부터는 제3자가 시각을 보증하는 다른 종류의 증거가 됩니다.
어디에 쓰고 어디에 쓰지 않나
이 방식이 맞는 자리와 맞지 않는 자리가 갈립니다.
맞는 자리는 소송까지 갈 일이 드물고, 가더라도 무결성과 처리 기록이 실제로 도움이 되는 구간입니다. 외주 개발 계약, 유지보수 계약, 견적 승인, 작업 범위 합의가 여기 들어갑니다. 이런 계약에서 실제로 다투어지는 것은 "서명했느냐"보다 "합의한 범위가 무엇이었느냐"인 경우가 많고, 그건 동결된 문서가 답합니다.
맞지 않는 자리도 분명합니다. 금액이 크거나 상대가 미덥지 않은 계약은 종이에 도장을 받거나 제3자 서비스를 쓰는 편이 낫습니다. 법이 특정 방식을 요구하는 영역도 있습니다. 상대가 큰 조직이면 대개 그쪽 시스템을 쓰자고 할 텐데, 굳이 우길 이유가 없습니다. 비용을 아끼려다 계약 자체를 잃는 것이 가장 나쁜 결과입니다.
과장이 서명을 가장 약하게 만듭니다
마지막이 제일 중요하다고 봅니다.
"공인인증서와 같습니다"라거나 "법적으로 완전히 안전합니다"라고 말하고 싶은 유혹이 있습니다. 그 말은 사실이 아니고, 사실이 아닌 설명을 듣고 한 서명이 가장 약합니다. 상대가 나중에 "그렇게 설명받아서 응했다"고 하면 서명의 전제 자체가 흔들립니다.
정확하게 말하는 편이 결국 더 강합니다. 전자서명법 제3조에 따라 서명과 같은 효력을 가지고, 서명한 문서는 그 시점에 고정되어 해시로 봉인되며, 열람과 서명 시각이 기록되어 증명서와 함께 전달된다는 것까지입니다. 본인 확인의 수준과 시각의 출처는 물으면 그대로 답하면 됩니다.
기술이 무엇을 어떻게 고정하는지는 전자서명 구현: 손글씨보다 문서 동결이 먼저인 이유에 따로 적었습니다.
함께 읽기
- 전자서명 구현: 손글씨보다 문서 동결이 먼저인 이유전자서명 서비스를 처음 보면 가장 눈에 띄는 것은 화면에 손가락이나 마우스로 사인을 그리는 부분입니다. 계약이 그 그림으로 성립하는 것처럼 보입니다.
- API 키는 왜 다시 볼 수 없을까: 발급·검증·권한이 갈리는 자리GitHub 에서 토큰을 만들면 화면에 한 번 뜨고 다시는 볼 수 없습니다. Stripe 도 AWS 도 같습니다. 복사를 놓치면 방법이 없고, 새로 만들라는 안내만 나옵니다.
- 개인 액세스 토큰의 한계: 토큰은 권한이 아니라 신원- run: eas build --platform all --non-interactive
- Google Analytics 도입: 코드보다 처리방침에서 먼저 막힌 이유Google Analytics를 붙이는 코드를 다 짜고, 배포 직전에 개인정보 처리방침을 열었습니다. 이 문장이 있었습니다.
- Next.js 보안 헤더와 색인 차단: 새 프로젝트마다 같은 설정을 두는 이유Vercel 로 옮기고 나서 응답 헤더를 다시 봤더니 보안 헤더가 하나도 없었습니다. 예전에는 오리진 앞의 nginx 가 붙여 주고 있었는데, 그 nginx 가 경로에서 빠지면서 전 경로에서 같이 사라진 것입니다. 앱은 그대로였고 오류도 없었습니다. 헤더는 없어져도 화면이 멀쩡해서, 재보기 전에는 모릅니다.