최근 금융 관련 공부를 하면서 마침 개인정보와 개인신용정보 보호 내용이 나와 구체적으로 알아보게 됐다. 시스템 보안, 패스키 글에 이어 이번엔 시스템에서 개인정보를 처리할 때 뭘 해야 하는지 정리해보자.

SI 프로젝트의 요구사항 정의서를 보면 아래 같은 항목이 거의 빠지지 않는데 지금 참여 중인 프로젝트에도 포함돼 있다.

  • 개인정보의 안전성 확보 및 암호화
  • 개인정보보호법 준수

더욱이 이번에는 "개인정보처리 위탁계약 체결"까지 들어 있었다. 이 글에서는 일단 앞 두 가지에 대해 개발자로서 알아야 할 내용을 살펴보려고 한다.

개인정보보호 규정

개발자는 법이나 규정에 대해 거리를 두고 싶지만 그래도 근거나 원칙이 필요할 때가 있고 아래를 참고해야 한다.

  • 개인정보 보호법: 모든 개인정보 처리의 기본법이다.
  • 신용정보법: 금융 거래와 관련된 개인신용정보에 적용되며 개인정보 보호법보다 우선한다. 금융권 프로젝트라면 신경써야 한다.
  • 개인정보의 안전성 확보조치 기준: 개인정보보호위원회 고시다. 접근 권한, 암호화, 접속기록, 파기처럼 시스템에서 해야 할 일의 기준 문서이면서 요약 정보라 할 수 있어서 개발자라면 가장 먼저 보길 권한다.

법 조문은 “안전성 확보에 필요한 조치를 하여야 한다” 같이 원칙 위주로 나와 있고 실무적으로 자세히 해설한 내용으로는 개인정보보호위원회에서 내는 안내서가 있다. 영역이 넓고 자료가 많은데 일반적인 개인정보 처리 위주로는 아래 세 가지가 있다.

아래에서는 특히 위 “개인정보 처리 통합 안내서” 위주로 다시 시스템에서 할 일을 추려봤다.

수집, 이용, 제공

개인정보를 수집, 이용하려면 7가지 적법한 기준이 있는데

  • 정보주체의 동의를 받은 경우
  • 법률에 규정이 있거나 공공 업무 수행에 따라 불가피한 경우
  • 정보주체와의 계약을 체결하거나 이행하는 데 필요한 경우
  • 타인 또는 공공의 생명, 재산, 안전 등을 위해 필요한 경우

등이다. 안내서에는 적법하지 않은 예시도 다양하게 나와 있다.

시스템에서는 현실적으로 아래와 같은 구현이 필요하다. 위 안내서에 "동의 받는 방법"이라는 단원이 따로 있으므로 참고.

  • 필수 동의와 선택 동의를 구분해 받는다. 이때 위 적법한 기준에 따라 계약상 필수인 항목은 일일이 "필수 동의"로 받지 않아도 된다.
  • 동의 문구는 버전을 관리하고 사용자별로 어느 버전에 동의했는지 저장한다.
  • 제3자 제공 동의가 필요한 경우 수집·이용 동의와 따로 받는다.
  • 동의 철회도 기능이다. 철회하면 그 목적의 처리를 실제로 멈춰야 한다. 마케팅 동의를 철회한다면 마케팅 문자를 보내지 않아야 한다.

개인신용정보의 경우 신용정보법 제32조에 따라 제공할 때마다 동의 근거가 있어야 하고 제공한 내역도 남겨야 한다.

저장 및 전송

법규상 주민등록번호, 여권번호, 운전면허번호, 외국인등록번호 네 가지는 고유식별정보라고 하는데 별도 동의나 법령 근거가 있어야 처리할 수 있고 특히 주민등록번호는 법령 근거가 없으면 아예 수집할 수 없다.

이러한 식별정보는 수집하면 저장, 전송이 발생하게 되는데 여기에 암호화가 들어가야 한다.

구분 대상 방식
저장 비밀번호 해싱(복호화할 수 없는 일방향 암호화)
저장 주민등록번호 등 고유식별정보, 생체인식정보 복호화 가능한 양방향 암호화, 키는 분리 관리
전송 개인정보, 인증정보를 네트워크로 보낼 때 TLS 등 구간 암호화

실제 프로젝트에서는 복호화가 필요한지에 따라 암호화와 해싱 간에 선택했는데 그러다 보면 서드파티 제품도 종종 사용하곤 했다. 개발자들은 이 과정에서 피곤해진다.

  • 백엔드, 프론트엔드 처리 구간에 따라 암복호화를 계속 신경써야 한다
  • 암호화나 해싱으로 문자열 길이가 길어지므로 테이블 컬럼 길이를 잘 맞춰서 만들어야 한다
  • 서드파티 제품이 계속 연동돼야 하니 로컬에서 개발하기가 불편하다
  • DB 데이터를 바로 조회하지 못하고 복호화 함수를 통해 조회해야 한다

내 경험상 로컬 개발에서는 암복호화 처리를 스텁화하고 서드파티 제품이 없이도 돌아가도록 구현하는 것이 편하다.

화면에 보여줄 때는 마스킹도 필요하다. 암호화는 말하자면 DB나 HTTP 통신이 털렸을 때를 대비한 것이고 마스킹은 정상 사용자가 화면을 볼 때 필요 이상으로 노출하지 않으려는 것이라 목적이 다르다. (당연히 서버 측에서 마스킹하고 화면은 그 결과만 보여줘야 한다.)

파기와 분리보관

개인정보는 보유기간이 끝나거나 목적을 달성하면 지체 없이 파기해야 한다. 개발 입장에서는 탈퇴 시 바로 삭제하고 싶지만 그게 그렇게 단순하지 않다.

  • 다른 법에서 보존을 요구하는 것들이 있다. 전자상거래법의 계약·대금 결제 기록(5년), 소비자 불만 처리 기록(3년) 등 최소 보관 기간이 정해진 것들이 있다. 앞서 말한 안내서 109페이지에 다양한 경우가 나와 있다.
  • 일반 개인정보는 지체 없이(표준 개인정보 보호지침에 따르면 5일 이내) 파기해야 한다.
  • 금융 거래의 개인신용정보는 신용정보법이 우선하므로 기준이 다르다. 거래가 끝난 날부터 최장 5년 이내에 삭제해야 하고 그전에 목적을 달성했다면 3개월 이내에 삭제해야 한다. 예외적으로 보존하는 정보는 현재 거래 중인 고객의 정보와 분리해서 보관해야 한다.
  • 개인정보보호법에서도 법령에 따라 파기하지 않고 보존하는 정보는 다른 개인정보와 분리해서 저장·관리해야 한다고 규정한다.
  • 분리 보관한 정보에 대해서는 개인정보 처리방침 등을 통하여 정보주체가 알 수 있도록 해야 한다.

시스템은 이렇게 만들도록 한다.

  • 정보별 보유기간과 파기 예정일 관리
  • 기간이 지난 데이터를 지우거나 분리 보관 영역으로 옮기는 배치 작업
  • 분리 보관 영역은 별도 DB나 별도 테이블로 두고 접근할 수 있는 계정과 권한을 따로 제한 (표준 개인정보 보호지침 제11조에서 "물리적 또는 기술적 방법으로 분리"하라고 하니 반드시 DB를 나눠야 하는 것은 아님)
  • DB 백업에 남아 있을 수 있으므로 백업 정책 정의
  • 삭제된 사용자를 참조하는 데이터에 대해서는 “탈퇴 회원”, “삭제된 게시물” 등으로 표시하고 외래 키 등 참조 관계 정리

예전에 프로젝트를 할 때는 "휴면 계정 전환"이라는 게 있었다. 일정 기간 서비스를 이용하지 않은 회원의 정보를 파기하거나 분리 보관하는 기능이고 휴면 계정 전환 안내 메일도 보냈는데 2023년 9월 개정법 시행으로 이 의무는 폐지됐다.

지금은 서비스가 정한 보유기간에 따르면 되고 휴면 정책을 유지할지는 각 서비스가 정한다. 혹시 운영 중인 시스템에 아직 이런 기능이 있다면 변경하는 게 좋을지 확인해볼 필요가 있다.

데이터 유출 시 대응

지난 글에서 뚫린 뒤가 더 중요하다고 했는데 법도 아래와 같은 대응을 요구한다.

  • 유출 확정이 아니더라도 유출 가능성을 알게 되면 72시간 이내에 정보주체에게 알려야 한다. 이후 유출이 아닌 것으로 확인돼도 알린다.
  • 1천 명 이상이거나, 민감정보·고유식별정보가 유출됐거나, 해킹 같은 외부 불법 접근으로 유출됐다면 72시간 이내에 개인정보보호위원회나 한국인터넷진흥원에 신고해야 한다.
  • 개인신용정보는 신용정보법에 별도 통지·신고 기준이 있다.

72시간 안에 신고하려면 유출이 의심되는 범위와 영향받는 고객을 신속히 파악할 수 있어야 한다. 여기서 필요한 게 접속기록이다. 안전성 확보조치 기준 제8조는 개인정보처리시스템에 접속한 사람이 언제, 어디서, 누구의 정보를 대상으로, 무엇을 했는지 기록하도록 하고 있다.

  • 최소 1년 보관, 5만 명 이상의 정보를 처리하거나 고유식별정보·민감정보를 처리하는 시스템은 2년 이상
  • 월 1회 이상 점검하고 대량 다운로드 같은 건 사유를 확인
  • 기록 자체가 위·변조되지 않게 보관

단순 시스템 접속 로그와 다르다는 게 포인트다. "어떤 API가 호출됐다"가 아니라 "관리자 A가 고객 B의 정보를 조회했다"가 남아야 한다.

정리

내가 참여 중인 프로젝트 같은 경우 처음의 요구사항 두 줄을 개발 항목으로 바꾸면 대략 이렇다.

단계 시스템에서 할 일
수집·이용·제공 필수/선택 동의 분리, 동의 이력과 문구 버전 저장, 철회 반영, 제공 이력 기록
고유식별정보 수집 근거 확인, 저장 암호화(비밀번호는 단방향), 전송 암호화, 키 관리, 마스킹
파기 보유기간 관리, 파기·분리 보관 배치, 분리 영역 접근 제한, 백업 정책
유출 대응 접속기록 보관·점검, 영향받은 사람과 정보를 바로 추출할 수 있는 구조

개인정보 처리는 개발할 때도 피곤하고 감리 때도 피곤하지만 미리 챙기지 않으면 나중에 더 힘들다. 암호화 컬럼 때문에 조회, 검색 방식을 미리 정의해야 하고 이력 제공 때문에 구간마다 이력을 쌓아야 하며 분리 보관으로 테이블 구조도 잘 설계해야 한다.

나중에 소 잃고 외양간 고치지 말고 미리미리 대비하자.