개인정보 보호책임자

책임자가 정해져 있지 않은 회사에서는 사고가 나기 전까지 아무도 그 질문을 꺼내지 않습니다. 가입 화면에서 무엇을 받을지는 화면을 만드는 사람이 정하고, 그 값이 어느 곳에 얼마나 오래 남는지는 저장하는 사람이 정하고, 그것을 홍보 메일에 쓸지는 또 다른 사람이 정합니다. 각자 자기 몫은 알지만 전체를 아는 사람이 없습니다.

그 공백은 대개 사고가 난 날에 드러납니다. 외부로 나간 파일에 생년월일이 들어 있는 것을 보고 누군가 왜 이 값을 갖고 있었느냐고 묻습니다. 개발 쪽은 홍보 담당이 요청해서 받기 시작했다고 답하고, 홍보 쪽은 연령대별로 메일을 나눠 보내려다 결국 쓰지 않았다고 답합니다. 언제부터 쌓였는지, 지금 몇 명분이 남아 있는지는 아무도 모릅니다. 그러는 사이 기관에 알려야 하는 기한이 지나갑니다.

법은 이 공백을 사람 이름 하나로 메웠습니다. 일정 규모를 넘는 회사는 개인정보를 총괄할 사람을 정해 두고, 그 사람의 직함과 연락처를 개인정보처리방침에 공개하도록 요구합니다. 개인정보처리방침은 무엇을 모아 어디에 쓰고 언제 지우는지를 밖에서 읽을 수 있게 적어 둔 문서입니다. 여기에 이름이 적히면 밖에서는 문의가 들어올 창구가 생기고 안에서는 누구에게 물을지가 정해집니다.

하루는 밖에서 들어온 요청과 안에서 올라온 검토로 채워집니다. 크게 다섯 가지입니다.

1. 정보주체 요청 처리. 내 정보를 어디에 썼는지 알려 달라거나 전부 지워 달라는 요청이 들어옵니다. 답해야 하는 기한이 법으로 정해져 있어서 며칠 안에 회신해야 합니다. 문제는 한 사람의 정보가 회원 데이터베이스에만 있지 않다는 점입니다. 결제 기록과 고객 문의 내역, 분석 도구에도 흩어져 있어서 어디에 무엇이 있는지 평소에 표로 갖고 있지 않으면 기한을 못 지킵니다.
2. 처리 현황 관리. 그 표가 두 번째 업무입니다. 어떤 항목을 왜 받고 어디에 보관하고 언제 지우는지를 적어 두고, 새 기능이 항목을 늘릴 때마다 줄을 더합니다.
3. 신규 기능 검토. 기획이 끝나기 전에 받는 항목이 정말 필요한지, 무엇을 근거로 받는지를 따집니다. 근거 가운데 가장 흔한 것이 동의이고, 동의를 근거로 받으려면 무엇에 쓰는지 알린 뒤 사용자가 스스로 체크해야 합니다. 여기서 자주 막히는 항목은 있으면 좋아 보이는데 쓰는 기능은 없는 값입니다.
4. 사고 대응. 유출이 확인되면 정해진 시간 안에 기관에 신고하고 당사자에게 알립니다. 사고가 난 날에 누구에게 알릴지부터 정하기 시작하면 기한을 못 지키므로 순서는 평소에 짜 둡니다.
5. 점검과 교육. 분기마다 누가 어떤 데이터에 접근할 수 있는지 뽑아 보고 더는 필요 없는 권한을 회수합니다. 개인정보를 개인 계정으로 내려받지 말라는 교육도 여기서 나갑니다.

혼자 판단해서 끝나는 일이 거의 없고, 대개 다른 사람의 일에 조건을 붙이는 방식으로 진행됩니다. 맞붙는 상대는 다섯 쪽입니다.

1. 개발자. 어떤 값이 어느 곳에 저장되는지 아는 사람이라 요청이 들어올 때마다 함께 찾습니다. 지우는 기능이 제품에 없으면 만들어 달라고 요구하는 것도 이쪽입니다.
2. 프로덕트 매니저. 기능이 만들어진 뒤에 들어가면 화면을 다시 그려야 하므로 기획 단계에서 붙습니다. 받는 항목을 줄이자는 이야기는 이 자리에서 해야 값이 쌉니다.
3. 세일즈와 고객 성공. 기업 고객이 계약 전에 보내는 보안 질문지에 개인정보 항목이 들어 있고, 고객 데이터를 대신 처리한다는 계약서도 이쪽으로 옵니다.
4. 사내 변호사. 검토 결과를 계약서 문장으로 옮기는 일은 이쪽 몫이고, 작은 회사는 한 사람이 두 일을 겸하기도 합니다.
5. 보안과 규정 담당. 최고 정보보호 책임자가 맡는 보안 관리 체계, 즉 권한과 절차를 문서로 정해 두고 그대로 도는지 확인하는 구조 위에서 일합니다. 컴플라이언스 담당자가 현장 점검을 돌릴 때 개인정보 항목을 같이 넣습니다. 보안 인증을 준비할 때도 불려 갑니다.

"이 항목은 개인정보 보호책임자 검토를 받고 붙이죠. 생년월일까지 받을 이유가 있나요?"

기획 단계에서 받는 항목을 줄이자는 제안입니다.

"삭제 요청이 어제 들어왔는데 분석 도구 쪽 데이터가 안 지워져요."

기한 안에 답해야 하는데 시스템 하나가 준비돼 있지 않다는 뜻입니다.

"고객사에서 위탁 계약서 보내 달라는데, 처리방침에 적힌 담당자 연락처 최신 맞나요?"

밖에 공개된 정보가 실제와 맞는지 확인하는 질문입니다.

페이지덱에서는 규원이 이 자리로 지정돼 있고, 실무는 태오와 수아가 나눠 집니다. 구성원이 마흔다섯 명인 단계라 전담으로 한 사람을 두기 어려워 흔히 쓰는 방식입니다. 계약 전에 오는 질문지에 데이터를 어디에 두는지, 누가 열람할 수 있는지를 묻는 항목이 늘면서 그때마다 규원이 답을 모읍니다.

지현이 새 기능을 기획할 때도 이 자리를 거칩니다. 문서를 누가 언제 열어 봤는지 보여 주는 기능을 만들자는 이야기가 나왔을 때, 기록을 얼마나 보관할지와 퇴사자 이름이 언제까지 남는지를 먼저 정한 다음에 화면을 그렸습니다.

서류만 관리하는 자리로 보는 경우가 가장 많습니다. 하는 일이 문서 갱신과 신고로 보이니 제품과는 멀다고 생각하기 쉽습니다. 그런데 실제로 판단이 갈리는 지점은 대부분 제품 안에 있습니다. 어떤 항목을 받을지, 계정을 지우면 남은 기록을 어떻게 할지, 접속 기록을 몇 달 보관할지는 전부 화면과 데이터 구조를 정하는 결정입니다. 문서 담당으로만 두면 결정이 끝난 뒤에 통보만 받게 되고, 고칠 것이 생겨도 이미 만든 것을 뜯어야 합니다.

한 사람을 정해 이름만 올려 두면 끝이라고 보는 것도 흔합니다. 법이 요구하는 것이 지정과 공개이니 그렇게 읽히지만, 이름이 올라간 순간 그 사람은 사고가 났을 때 책임을 지는 자리에 서게 됩니다. 그래서 자기가 만든 것을 자기가 점검하는 구조가 되지 않도록 자리를 고릅니다. 데이터를 가장 많이 쓰는 부서의 책임자가 겸하면 받는 항목을 줄이자고 말할 사람이 사라집니다. 권한과 시간을 주지 않은 채 이름만 올려 두면 점검은 형식만 남고, 그 상태는 사고 조사에서 그대로 드러납니다.