전자동의 기록 보관 방법 — ISMS-P 가 보는 항목과, '고객이 본 문구'까지 남기는 스냅샷 설계

동의 기록 보관의 기준선은 ISMS-P 인증기준 안내서에 나와 있습니다. 동의 일시, 동의 항목, 동의자, 동의 방법을 남기고, 그 개인정보를 파기할 때까지 보존하는 것입니다. 여기에 업종 법령이 정한 보존기간이 더해집니다. 다만 필자는 이 기준선만으로는 부족하다고 봅니다. "언제 동의했는지"는 남아도 "무엇을 보고 동의했는지"는 남지 않기 때문입니다. 그래서 화면에 그려진 동의 문구를 그대로 복사해 해시와 함께 쌓는 스냅샷 방식이 가장 확실하다고 생각합니다.

이 글은 순서대로 다음을 정리합니다. 먼저 법과 ISMS-P 가 동의 기록에 무엇을 요구하는지, 심사에서 무엇을 보는지, 보존기간은 어떻게 정하는지를 봅니다. 그다음 동의 결과만 저장하는 흔한 구조에 어떤 빈틈이 있는지, 전자동의를 스냅샷으로 남기려면 어떻게 설계하는지를 다룹니다. 뒤쪽은 실제로 결과 저장에서 스냅샷 저장으로 옮겨 가며 겪은 일입니다. 특정 시스템의 이야기가 아니라, 전자동의를 받는 곳이라면 대부분 비슷하게 만나는 구조의 이야기입니다.

동의 기록 보관, ISMS-P 와 법은 무엇을 요구하나

아래 내용은 국가법령정보센터의 조문과 「정보보호 및 개인정보보호 관리체계(ISMS-P) 인증기준 안내서」(2023.11.)에서 확인한 것입니다. 이 인증기준이 어떤 구조인지는 ISMS 와 ISMS-P 차이를 정리한 글에서 다뤘습니다.

남겨야 할 항목과 보존기간 — 인증기준 3.1.1

ISMS-P 인증기준 3.1.1(개인정보 수집·이용)의 주요 확인사항에는 "정보주체 및 법정대리인에게 동의를 받은 기록을 보관하고 있는가?"가 있습니다. 세부 설명은 "개인정보 수집·이용 동의에 따른 적법 근거를 입증할 수 있도록" 동의 기록을 남기고 보존하라고 하면서, 남길 것과 기간을 이렇게 적습니다.

구분	안내서가 적은 것
기록으로 남길 사항	동의 일시, 동의 항목, 동의자(법정대리인이 동의한 경우 법정대리인 정보), 동의 방법 등
보존기간	회원탈퇴 등으로 인하여 해당 개인정보를 파기할 때까지

심사에서 보는 증거자료와 결함사례

같은 항목에서 안내서가 증거자료 예시로 드는 것은 다음과 같습니다.

• 온라인 개인정보 수집 양식(홈페이지·모바일앱 회원가입 화면, 이벤트 참여 등)
• 오프라인 개인정보 수집 양식(회원가입신청서 등)
• 개인정보 수집 동의 기록(회원 데이터베이스 등)
• 법정대리인 동의 기록
• 개인정보 처리방침

눈여겨볼 점은 동의 기록과 수집 양식(화면)을 함께 본다는 것입니다. 결함사례에도 이 두 축이 다 나옵니다. 동의를 받을 때 "동의 거부 권리 및 동의 거부에 따른 불이익 내용"을 고지 사항에서 빠뜨린 경우, 수집 항목을 "~ 등"처럼 포괄적으로 안내한 경우는 화면 문구의 결함입니다. 법정대리인 동의 기록을 보존하지 않아 법정대리인 이름, 동의 일시 등을 확인할 수 없는 경우는 기록의 결함입니다.

여기서부터는 필자의 해석입니다. 지금 화면은 언제든 보여 줄 수 있습니다. 하지만 3년 전 그 고객이 본 화면에 거부 권리 문구가 있었는지는, 그때의 문구가 남아 있지 않으면 보여 줄 방법이 없습니다.

법이 정한 동의 방법과 입증책임

• 고지할 것. 개인정보 보호법 제15조 제2항은 동의를 받을 때 알릴 사항으로 수집·이용 목적, 수집 항목, 보유 및 이용기간, 동의를 거부할 권리와 거부에 따른 불이익을 정합니다.
• 구분해서 받을 것. 제22조 제1항은 "각각의 동의 사항을 구분하여 정보주체가 이를 명확하게 인지할 수 있도록" 알리고 각각 동의를 받으라고 정합니다.
• 전자적 방법은 "내용을 게재"하는 방식. 시행령 제17조 제2항 제4호는 동의 방법 중 하나로 "인터넷 홈페이지 등에 동의 내용을 게재하고 정보주체가 동의 여부를 표시하도록 하는 방법"을 듭니다.
• 동의의 조건. 시행령 제17조 제1항은 자유로운 의사에 따른 결정, 구체적이고 명확한 내용, 쉽게 읽고 이해할 수 있는 문구, 동의 여부를 명확히 표시할 방법이라는 네 조건을 모두 갖추라고 정합니다. 이 규정은 2024년 9월 15일부터 시행됐고, 개인정보보호위원회는 그 직전인 9월 12일 "개인정보 필수동의 관행 개선한다"는 보도자료를 냈습니다.
• 동의 없이 처리할 수 있는 경우. 2023년 3월 공포되어 9월 15일 시행된 개정법에서 제15조 제1항 제4호는 "정보주체와 체결한 계약을 이행하거나 계약을 체결하는 과정에서 정보주체의 요청에 따른 조치를 이행하기 위하여 필요한 경우"입니다. 계약에 필요한 정보는 동의 없이 처리할 수 있습니다.

입증책임은 법에 두 군데 명시돼 있습니다. 제16조 제1항은 "최소한의 개인정보 수집이라는 입증책임"을, 제22조 제3항은 "동의 없이 처리할 수 있는 개인정보라는 입증책임"을 개인정보처리자에게 지웁니다. 제22조 제3항은 동의 없이 처리하는 개인정보를 동의받아 처리하는 개인정보와 구분해 처리방침 등으로 공개하라고도 정합니다. 동의를 근거로 처리하는 부분은 앞에서 본 대로, 안내서가 적법 근거를 입증할 수 있게 기록을 남기라고 적고 있습니다.

동의 기록은 얼마나 보관하나 — 보존기간 정하는 법

보존기간은 세 가지를 겹쳐 보고 정합니다.

1. 인증기준의 기본값: 해당 개인정보를 파기할 때까지. 동의 기록은 그 개인정보를 처리하는 근거이니, 개인정보가 남아 있는 동안은 근거도 남아 있어야 합니다.
2. 업종 법령: 금융거래 성격이 있는 업종이라면 특정금융정보법상 거래 종료 후 5년이 기준이 됩니다. 업종마다 별도 보존 의무가 있는지 확인해야 합니다.
3. 동의 때 알린 기간: 제15조 제2항에 따라 동의를 받을 때 보유 및 이용기간을 알립니다. 실제로 보관하는 기간이 알린 기간, 그리고 처리방침에 적은 기간과 맞아야 합니다. 보관 기간을 시스템에서 바꿨다면 처리방침도 같이 고쳐야 합니다.

처리방침 쪽 기준도 계속 움직입니다. 개인정보보호위원회는 개인정보 처리방침 작성지침을 2025년 4월에 개정해 공개했고, 2026년 4월에 다시 개정본을 냈습니다. 보존기간과 동의 근거를 처리방침에 어떻게 적는지는 최신 지침을 기준으로 다시 확인하는 것이 좋습니다.

동의 결과만 저장하면 생기는 빈틈

많은 전자동의 시스템은 동의의 결과만 저장합니다. 동의 여부 플래그, 서명 이미지, IP, 동의 일시입니다. 안내서의 기록 항목은 대부분 채워집니다. "무엇에 동의했나"는 지금의 템플릿을 열어 거꾸로 맞춰 봅니다. 처음 만들 때는 이게 자연스럽습니다. 템플릿은 하나이고, 고객은 그 템플릿에 동의했으니 템플릿을 가리키기만 하면 될 것 같기 때문입니다.

문제는 시간이 지나 템플릿이 바뀌면서 생깁니다. 이 구조에서 생기기 쉬운 일은 이렇습니다.

1. 템플릿을 고치면 원본이 덮어써집니다. 당시 고객이 본 문구를 다시 꺼낼 방법이 없습니다.
2. 동의 플래그가 "어떤 항목"에 대한 것인지 느슨하게 연결됩니다. 항목 순서가 바뀌거나 하나가 추가되면 연결이 어긋날 수 있습니다.
3. 선택 항목에서 "거부했다"와 "애초에 안내되지 않았다"가 구분되지 않습니다. 둘 다 "동의 안 함"으로 남기 때문입니다.
4. 이미지로 된 약관을 교체하면 과거본이 사라집니다. 파일을 덮어쓰는 순간 끝입니다.

정리하면 "언제 동의했나"는 남지만 "무엇을 보고 동의했나"는 증명하기 어렵습니다.

"동의 항목"을 어디까지 남길 것인가

안내서는 "동의 항목"을 남기라고 할 뿐, 그 항목의 문구까지 남기라고 적지는 않습니다. 하지만 항목 이름만 남긴 기록은 문구가 바뀌는 순간 힘을 잃습니다. "마케팅 정보 수신 동의"라는 이름은 그대로인데 본문이 세 번 바뀌었다면, 이름만으로는 그 고객이 어느 판에 동의했는지 말할 수 없습니다. 입증할 수 있게 남기라는 취지를 따르면, 필자는 결국 문구가 남아야 한다고 봅니다.

전자동의 기록 보관 방법 — 스냅샷 설계

기록을 세 지점으로 나눈다 — 그릴 때 쓰고, 동의할 때 확정하고, 마무리 때 보정한다

한 번의 요청에 모든 기록을 걸면, 그 요청이 실패했을 때 아무것도 남지 않습니다. 그래서 기록을 세 지점으로 나눴습니다. 어느 하나가 실패해도 계약은 가고, 뒤 지점이 앞 지점을 메웁니다.

지점	무엇을 하나	의미
렌더	화면에 그려진 항목 전부를 "미응답" 상태로 기록	스냅샷은 여기서 확정됩니다. 고객이 본 것이 서명 전에 남습니다
동의	정상 처리되면 각 항목의 동의/거부와 시각을 확정	"거부"와 "미응답"이 구분됩니다
보정	동의 확정이 비어 있으면 결과값으로 채움	그 사이 템플릿이 바뀌지 않았다는 것이 확인될 때만 채웁니다. 아니면 추정 사본을 만들지 않고 "불완전"으로 표시합니다

핵심은 스냅샷을 동의 시점이 아니라 렌더 시점에 찍는다는 것입니다. 고객이 버튼을 누르기 전에 이미 "이 고객에게 이 문구가 보였다"가 남습니다. 동의 단계는 그 위에 응답을 얹을 뿐입니다.

보정 단계의 조건도 중요합니다. 결과값으로 빈칸을 채우는 것은 편하지만, 템플릿이 그 사이 바뀌었다면 채운 기록은 사실이 아니게 됩니다. 확인되지 않으면 채우지 않고 "불완전"이라고 남기는 쪽을 택했습니다.

한 행에 남기는 것

항목 하나가 한 행입니다. 안내서의 기록 항목(일시·항목·동의자·방법)에 문구와 해시를 더한 구성입니다.

• 항목의 제목과 본문 사본
• 필수 여부, 실제로 적용된 분기 조건
• 내용 해시(SHA-256)
• 동의 여부, 동의 시각, 렌더 시각
• 접속 정보, 렌더 회차
• 철회 정보를 담을 칸

여기에 두 가지 원칙을 더했습니다. 첫째, 렌더된 것만 기록합니다. 주문마다 붙는 추가 동의가 달라도, 화면에 그려진 것을 그대로 받아 적으니 같은 구조로 흡수됩니다. 앞으로 동의 유형이 늘어나도 구조를 바꿀 필요가 없습니다. 둘째, 새로고침으로 여러 번 렌더된 회차도 지우지 않습니다. 그 회차는 "안내는 됐지만 동의하지 않은 회차"로 남습니다.

사본을 저장할 때는 파라미터 쿼리를 씁니다. 약관 문구 속 특수문자가 SQL 처리 과정에서 변형되는 일을 막기 위해서입니다. 증적이 저장 단계에서 바뀌면 의미가 없습니다.

조회는 "이 고객이 무엇을 보고 무엇에 동의했나"라는 질문에 맞춰 주문 단위로 만들었습니다. "이 항목이 언제 바뀌었나"는 템플릿 관점의 다른 질문이라 분리했습니다.

템플릿 수정과 삭제 — "삭제 금지"보다 "삭제해도 증적은 남는 구조"

고객 쪽 기록만큼 중요한 것이 템플릿 쪽 이력입니다. 템플릿을 저장할 때는 바뀐 항목만 수정 전 내용을 이력으로 남깁니다.

삭제는 고민이 컸습니다. "고객이 동의한 항목은 삭제 금지"로 막는 안을 검토했지만 택하지 않았습니다. 막으면 담당자는 더 큰 우회, 예를 들어 템플릿을 통째로 교체하는 방식을 택하게 됩니다. 그래서 택한 것은 삭제는 업무대로 허용하되, 증적은 빠져나가지 못하게 하는 구조입니다.

• 삭제 전 내용을 이력에 남깁니다.
• 고객 동의가 참조하는 자료는 보존합니다.
• 보존이 실패하면 삭제를 멈춥니다.

이미지 약관 교체도 같은 원리입니다. 새 고객에게는 새 자료를 보여 주고, 과거 동의가 참조하는 자료는 보존합니다.

실무에서 해 보니 — 다섯 가지

본 업무를 막지 않아야 현장에 붙는다

컴플라이언스 기능이 계약 진행을 방해하면 현장에 붙지 못합니다. 그래서 스냅샷을 붙일 때 가장 먼저 정한 원칙은 이것이었습니다.

• 기존 동의·계약 흐름은 건드리지 않고, 기록 로직만 추가합니다.
• 기록 로직은 전부 격리합니다. 기록이 실패해도 로그만 남기고 계약은 진행됩니다. 실패가 본 업무로 번지지 않게 하는 생각은 폴백 설계 글에서 다룬 안전망과 같은 방향입니다.
• 문제가 생기면 배포 없이 멈출 수 있는 운영 스위치를 둡니다. 규칙을 코드 밖으로 빼서 운영에서 바꾸는 방식은 폐루프 글에서 설명했습니다.
• 업무시간 이후에 반영하고, 다음 날 동의 결과와 이력 건수를 대조합니다.

동의를 받는 경로가 생각보다 많다

동의는 한 화면에서만 받는 것 같지만, 콜센터를 거치는 경로, 고객이 직접 계약하는 경로, 온라인 신청 경로가 서로 다른 엔진으로 돌아갈 수 있습니다. 한 경로에만 붙이면 나머지 경로의 동의는 여전히 결과만 남습니다. 손대기 전에 동의가 생기는 모든 경로의 코드 지도부터 그려야 빠뜨리지 않습니다. 필자는 같은 기록 로직을 각 경로에 동일하게 붙였습니다.

치환자 — 원문과 고객이 본 문구는 다르다

템플릿에 "#{회사명}" 같은 치환자가 있고 그 치환을 브라우저에서 한다면, 템플릿 원문만 저장해서는 고객이 본 문구와 1:1 이 아닙니다. 고객은 치환자가 아니라 치환된 결과를 봤기 때문입니다. 그래서 원문은 그대로 두고 치환값과 치환된 본문을 따로 남겼습니다. 그리고 서버 쪽에서 치환한 결과가 화면에서 치환한 결과와 같은지 기계적으로 대량 대조한 뒤에 반영했습니다.

해시는 "무엇을" 해시하느냐가 전부다

해시는 내용이 바뀌었는지만 알려 줍니다. 무엇이 바뀌었는지, 누가 바꿨는지는 알려 주지 않습니다. 그래서 해시의 대상이 더 중요합니다. 원문을 해시할지 치환본을 해시할지, 첨부 이미지까지 묶을지에 따라 그 해시가 증명하는 범위가 달라집니다. 첨부 이미지까지 해시로 묶는 것은 파일 위치 문제를 고려하면 다소 머리 아플 수 있습니다. 해시가 무엇을 덮고 무엇을 덮지 못하는지는 문서로 적어 두는 것이 좋습니다.

테스트 기록도 증적이다

사람이 직접 눌러 보는 테스트는 몇 번 열었는지, 어디서 새로고침했는지가 남지 않습니다. 그래서 테스트 전용 주문에만 동작하는 자동 테스트로 단계별 화면과 저장 결과를 기록으로 남겼습니다.

도입 전에 받은 동의는? — "소급"이 아니라 "복원"

스냅샷은 도입한 날부터 쌓입니다. 그 전에 받은 동의는 소급의 문제가 아니라 복원의 문제입니다. 당시의 화면은 이미 지나갔고, 지금 할 수 있는 것은 근거를 가지고 당시 문구를 다시 맞춰 보는 일입니다.

그래서 근거 수준에 따라 이름을 나눠 구분하는 방향을 검토하고 있습니다.

구분	조건	표시할 것
현행복원	그 동의 이후 템플릿이 바뀌지 않아, 현재본이 곧 당시본임이 확인되는 경우	복원 기록이라는 사실
추정복원	당시본을 정황으로 추정하는 경우	추정이라는 사실과 그 근거

어느 쪽이든 치환값은 당시 값이 아니라 지금 다시 계산한 값이므로, 그 사실도 표시합니다.

원칙은 하나입니다. 추정 사본을 진짜 사본처럼 쌓지 않습니다. 실제로 찍힌 스냅샷과 나중에 복원한 기록이 눈으로 구분되어야 합니다.

스냅샷까지 필요한 경우, 결과 저장으로 버틸 수 있는 경우

모든 곳에 같은 무게가 필요하지는 않습니다.

• 스냅샷까지 필요한 경우: 동의 문구가 자주 바뀌는 경우, 주문이나 상품마다 추가 동의가 달라지는 경우, 치환자로 문구가 사람마다 달라지는 경우, 분쟁이나 인증 심사에서 동의 내용을 보여 줘야 할 가능성이 높은 경우
• 결과 저장으로 버틸 수 있는 경우: 문구가 거의 바뀌지 않고, 바뀔 때마다 판본을 따로 보관하며, 각 동의가 어느 판본에 대한 것인지 정확히 연결되는 경우. 다만 판본 관리가 한 번이라도 어긋나면 그 기간의 증명이 끊깁니다

스냅샷에도 비용은 있습니다. 같은 문구가 고객 수만큼 복사되니 저장량이 늘고, 기록 로직이 붙는 경로마다 검증이 필요합니다. 이 비용과 "당시 무엇을 보여 줬는지 모른다"고 답해야 하는 상황을 놓고 판단하면 됩니다.

정리 — 동의 기록 보관 점검표

동의 기록 보관을 점검할 때 아래 질문으로 시작해 보시기 바랍니다.

1. 동의 일시·항목·동의자·방법이 남는가 (ISMS-P 3.1.1 기준선)
2. 보존기간이 파기 시점, 업종 법령, 동의 때 알린 기간·처리방침과 맞는가
3. 지금 저장하는 것이 결과인가, 고객이 본 화면인가
4. 템플릿을 고치거나 지웠을 때, 과거 동의가 본 문구를 다시 꺼낼 수 있는가
5. 선택 항목에서 "거부"와 "안내되지 않음"이 구분되는가
6. 동의가 생기는 경로를 전부 알고 있는가, 기록이 실패해도 계약은 진행되는가
7. 치환자가 있다면 치환된 본문이 남는가, 해시는 무엇을 덮는가
8. 도입 전 동의를 복원했다면, 실제 기록과 눈으로 구분되는가

이런 일은 중요하지만 급하지 않아서 계속 뒤로 밀리기 쉽습니다. 오늘 계약이 멈추는 문제는 아니기 때문입니다. 하지만 개인정보 관리의 무게는 점점 커지고 있고, 전자동의일수록 동의 기록 보관은 결과에서 스냅샷으로 옮겨 가는 흐름에 있습니다. 의식적으로 일정에 올려 두지 않으면, 필요한 날에야 비어 있는 것을 알게 됩니다.

참고한 공식 자료: ISMS-P 인증기준 안내서(2023.11.) — 개인정보 포털, 개인정보 보호법 — 국가법령정보센터