개인정보 보호

사람에 관한 정보를 적어 두는 일은 오래됐지만, 종이 장부 시절에는 그 정보가 한곳에 묶여 있었습니다. 명부를 남에게 넘기려면 물리적으로 옮겨야 했고, 옮긴 만큼 원본 쪽에서는 사라졌습니다. 전산으로 옮겨 적으면서 이 성질이 뒤집혔습니다. 복사 비용이 사실상 0이 되면서 같은 명부가 열 군데에 동시에 존재하게 됐고, 한 번 밖으로 나간 파일은 회수할 방법이 없어졌습니다.

이 상태에서 사람들이 겪은 일은 대개 이런 모양이었습니다. 어느 날부터 모르는 번호로 대출 광고 문자가 오는데, 그 번호를 어느 회사에 줬는지 본인이 기억하지 못합니다. 몇 해 동안 가입한 서비스가 수십 개인 데다 가입할 때 무엇에 체크했는지도 남아 있지 않습니다. 정보가 어디에 얼마나 퍼졌는지를 정작 그 정보의 주인만 모르는 상황이 만들어진 것입니다.

정보를 모으는 쪽에 악의가 있었던 것도 아닙니다. 가입 화면을 만들 때 생년월일 칸을 넣어 두면 나중에 연령대별 분석에 쓸 수 있을 것 같고, 로그에 이메일을 그대로 찍어 두면 장애가 났을 때 추적이 편합니다. 마케터는 이미 받아 둔 주소가 있으니 새 기능 안내를 보내자고 하고, 개발자는 지운 데이터를 나중에 찾는 일이 생길까 봐 지우는 코드를 끝내 넣지 않습니다. 각각은 합리적인 판단인데 모아 놓으면 필요를 확인한 적 없는 정보가 목적 없이 쌓여 기한 없이 남습니다.

그래서 규칙은 자리를 한 번 바꾸는 데서 시작합니다. 회사가 수집한 정보를 회사의 소유물로 보지 않고, 정보의 주인은 그 사람이며 회사는 필요한 동안 빌려 쓰는 쪽이라고 봅니다. 빌린 것이라면 따라붙는 질문이 정해집니다. 무엇에 쓰려고 빌렸는지 미리 말했는지, 말한 용도 밖으로 쓰고 있지는 않은지, 다 쓴 다음에도 계속 쥐고 있지는 않은지입니다. 실무에서 자주 걸리는 것은 첫 번째와 세 번째입니다. 탈퇴한 계정의 기록을 3년째 갖고 있다면 왜 3년인지 답할 수 있어야 합니다.

이 규칙이 각 나라의 법으로 자리 잡으면서 어기는 쪽에 값이 매겨졌습니다. 유럽은 2018년부터 전 세계 매출을 기준으로 과징금을 매기기 시작했고, 한국도 매출 기준 과징금과 유출 시 신고 의무를 법에 넣었습니다. 지우는 일이 만드는 쪽 눈에는 기능이 아니라 손실로 보이기 때문에, 이 값이 붙기 전까지는 대부분의 회사에서 우선순위가 오르지 않았습니다.

개인정보 보호 아래 묶인 용어는 일곱 갈래입니다. 누가 등장하는지(주체), 무엇을 공개해 두는지(문서), 무슨 자격으로 정보를 다루는지(근거), 다루는 동안 지킬 선이 무엇인지(원칙), 정보의 주인이 무엇을 요구할 수 있는지(권리), 정보가 회사 밖으로 나갈 때 무엇이 필요한지(이전), 새어 나갔을 때 무엇을 해야 하는지(사고)입니다.

주체는 이 관계에 등장하는 세 자리를 가르는 갈래입니다. 나뉘는 기준은 누가 목적을 정하느냐입니다.

1. 정보주체 — 그 정보의 주인이 되는 사람입니다. 페이지덱에 가입한 사용자 한 명 한 명이 여기에 해당합니다. 뒤에 나오는 권리는 전부 이 자리에 붙습니다.
2. 개인정보처리자 — 무엇을 왜 모으고 어디에 쓸지 정하는 쪽입니다. 직접 만지느냐가 아니라 결정하느냐가 기준이라, 실제 서버를 남이 굴려 줘도 목적을 정한 회사가 이 자리에 섭니다.
3. 수탁자 — 위탁을 받아 대신 처리하는 쪽입니다. 메일을 대신 보내 주는 업체나 고객 문의를 대신 받는 상담 대행사가 그렇습니다. 목적을 정하지 않고 시키는 범위 안에서만 처리하며, 사고가 나도 정보주체에 대한 책임은 위탁한 쪽에 남습니다.

문서는 이 관계를 밖에 밝혀 두는 갈래입니다. 개인정보처리방침은 무엇을 어떤 목적으로 모으고, 얼마나 보관하고, 누구에게 맡기거나 넘기는지를 적어 공개하는 문서입니다. 법이 담을 항목을 정해 둬 형식이 고정돼 있고, 사용자가 언제든 찾을 수 있는 자리에 놓아야 합니다. 기능이 바뀌면 이 문서도 함께 바뀌어야 하는데, 새 분석 도구를 붙이고 방침은 2년 전 문장 그대로 두는 일이 자주 생깁니다.

근거는 무슨 자격으로 정보를 다루느냐를 가르는 갈래입니다. 둘이 있습니다. 동의는 정보주체에게 미리 허락을 받아 두는 근거입니다. 무엇을 어떤 목적으로 얼마나 보관할지 알린 뒤 받아야 하고, 서비스에 꼭 필요한 항목과 그렇지 않은 항목을 갈라 선택할 수 있게 해야 합니다. 마케팅 수신 동의를 안 하면 가입이 막히는 화면이 문제가 되는 것이 이 지점입니다. 정당한 이익은 동의를 받지 않아도 처리가 인정되는 근거입니다. 부정 가입을 막으려고 접속 기록을 확인하는 경우처럼, 회사에 필요한 정도가 정보주체가 입는 불이익보다 크다고 볼 수 있을 때에 한합니다. 유럽 쪽에서 폭넓게 쓰이고 한국은 인정 범위가 더 좁은 편이라, 같은 처리가 나라에 따라 다르게 판정될 수 있습니다.

원칙은 다루는 동안 지킬 선을 정한 갈래입니다. 셋이 있고, 수집하는 순간과 쓰는 순간과 버리는 순간에 각각 걸립니다.

1. 최소 수집 — 목적에 필요한 만큼만 모읍니다. 문서 협업 도구에 회원가입을 받으면서 성별과 생년월일을 받을 이유는 대개 없습니다. 나중에 쓸지도 모른다는 것은 이유로 인정되지 않습니다.
2. 목적 제한 — 밝힌 목적 밖으로 쓰지 않습니다. 결제를 위해 받은 연락처를 신규 기능 홍보에 쓰는 것이 전형적인 위반입니다. 같은 정보를 다른 데 쓰려면 그 목적으로 다시 근거를 세워야 합니다.
3. 보유 기간 — 보관할 수 있는 기간의 한도입니다. 항목마다 따로 잡습니다. 결제 기록처럼 법이 몇 년간 보관하라고 정해 둔 것이 있고, 접속 로그처럼 회사가 필요한 만큼만 정하면 되는 것이 있습니다. 기한을 정해 두고도 지우는 작업이 자동으로 돌지 않으면 문서에만 적힌 기한이 됩니다.

권리는 정보주체가 회사에 요구할 수 있는 것을 모은 갈래입니다. 둘이 대표적입니다. 삭제 요구권은 자기 정보를 지워 달라고 요구할 권리이고, 열람 요구권은 어떤 정보가 어떻게 쓰이고 있는지 확인할 권리입니다. 둘 다 법이 정한 기한 안에 처리해야 하므로 요청을 받아 줄 창구와 처리 절차가 미리 있어야 합니다. 여기서 제품이 걸리는 대목은 지우는 범위입니다. 회원 표에서 한 줄을 지워도 결제 기록, 문의 내역, 분석 도구로 보낸 이벤트, 백업본에 같은 사람의 정보가 흩어져 있습니다. 어디까지 지우고 무엇은 법에 따라 남기는지를 정해 두지 않으면 요청을 받은 날 결정할 수 없습니다.

이전은 정보가 회사 밖으로 나갈 때를 다루는 갈래입니다. 국외 이전은 개인정보를 해외에서 처리하는 경우입니다. 해외 클라우드에 데이터를 두거나 외국 분석 서비스를 쓰는 것이 여기에 해당하므로, 국내 서비스만 만든다고 생각해도 대부분 걸립니다. 어느 나라로 가는지와 누가 받는지를 알리고 근거를 갖춰야 합니다. 처리 위탁 계약은 대신 처리해 주는 업체와 맺는 계약입니다. 시킨 범위를 벗어나 쓰지 않을 것, 재위탁을 마음대로 하지 않을 것, 사고가 나면 즉시 알릴 것 같은 조항이 들어갑니다.

사고는 이미 새어 나간 다음을 다루는 갈래입니다. 유출 신고는 개인정보가 밖으로 나갔을 때 감독 기관에 알리고 해당 이용자에게 통지해야 하는 의무입니다. 안 시점부터 72시간을 기준으로 삼는 규정이 많아 실무에서는 사흘 안에 무엇이 얼마나 새어 나갔는지를 파악해 알려야 합니다. 이 시간을 지키려면 어떤 로그가 어디에 남는지와 누가 연락을 맡는지가 사고 전에 정해져 있어야 합니다.

일곱 갈래는 한 줄로 이어집니다. 주체가 누가 책임지는지를 정하고, 근거가 다룰 자격을 세우고, 원칙이 다루는 동안의 선을 긋고, 문서가 그 내용을 밖에 밝히고, 권리가 주인이 확인하고 되돌릴 통로를 열고, 이전이 밖으로 나갈 때의 조건을 달고, 사고가 그 모든 것이 실패했을 때의 절차를 맡습니다. 그래서 방침 문서만 손보고 수집 화면과 지우는 코드를 그대로 두면 이 줄은 첫 칸에서 끊깁니다.

"이 칸 왜 받는 거예요? 이걸 쓰는 기능이 없으면 그냥 빼죠."

수집 항목마다 쓰는 곳이 있어야 한다는 지적입니다.

"그 목록으로 이벤트 메일 보내면 안 됩니다. 받을 때 그 용도로 동의받지 않았어요."

같은 정보라도 밝힌 목적 밖에 쓰려면 근거를 새로 세워야 한다는 뜻입니다.

"로그에 이메일이 그대로 찍히는데요. 보관 기한도 안 걸려 있고요."

당장 사고가 난 것은 아니지만 유출이 나면 피해 범위가 커지는 상태라는 경고입니다.

페이지덱이 이 문제를 처음 들여다본 것은 기업 고객의 보안 질문지 때문이었습니다. 수아가 계약 직전에 받아 온 질문지에는 수집 항목과 보관 기한, 해외로 나가는 데이터의 목록을 적는 칸이 있었는데 답을 아는 사람이 없었습니다. 태오가 코드를 뒤져 보니 가입 화면에서 받는 항목은 여섯 개인데 방침 문서에는 넷만 적혀 있었고, 지운 계정의 문의 내역이 그대로 남아 있었습니다.

정리는 지현이 표 한 장으로 시작했습니다. 항목마다 왜 받는지, 어디에 저장되는지, 언제 지우는지를 적어 내려가다 보니 생년월일 칸은 쓰는 기능이 아예 없었습니다. 현우는 그 표를 보고 메일 발송 목록을 두 개로 나눴습니다. 제품 공지를 받기로 한 사람과 마케팅 수신에 동의한 사람이 섞여 있었기 때문입니다. 규원이 마지막으로 정한 것은 이 표를 누가 관리하느냐였습니다. 기능이 추가될 때 표를 갱신하지 않으면 석 달 뒤에 같은 자리로 돌아온다는 것이 그날의 결론이었습니다.

가장 흔한 오해는 동의만 받아 두면 무엇이든 해도 된다는 생각입니다. 가입 화면에 체크박스가 늘어서 있고 사용자가 표시를 했으니 허락을 받았다고 읽기 쉽습니다. 그러나 동의는 여러 근거 중 하나일 뿐이고, 받았더라도 알린 목적 안에서만 효력이 있습니다. 전부 필수로 묶어 받은 동의나 무엇에 쓰는지 밝히지 않고 받은 동의는 애초에 유효하지 않습니다. 이 오해를 그대로 두면 회사는 동의서 문구를 길게 만드는 데 힘을 쓰고, 정작 필요 없는 항목을 계속 받으며 목적 밖 사용을 줄이지 않습니다. 실제 점검에서 문제가 되는 것도 동의를 받았느냐보다 받은 목적과 쓰는 방식이 맞느냐입니다.

두 번째는 이것이 법무팀 일이라 제품 만드는 사람과 상관없다는 생각입니다. 법과 과징금이 나오는 이야기라 담당 부서가 따로 있는 것처럼 보입니다. 그런데 지켜야 할 것이 실제로 결정되는 자리는 문서가 아니라 화면과 코드입니다. 가입 화면에 어떤 칸을 두는지는 기획이 정하고, 로그에 무엇을 남기고 언제 지우는지는 개발이 정하며, 어떤 목록으로 메일을 보내는지는 마케팅이 정합니다. 법무는 그 결정들을 나중에 문서로 정리할 수 있을 뿐 되돌리지는 못합니다. 이 오해를 그대로 두면 점검은 항상 사후에 시작되고, 이미 2년치가 쌓인 데이터를 어떻게 지울지부터 논의하게 됩니다.