이 값도 개인정보인가요?
본 글은 제도 이해를 돕기 위한 교육용 참고 자료이며, 법률 자문이 아닙니다. 본문의 법령은 최종 수정일 기준으로 요약 및 발췌되었으므로, 이후 개정되거나 해석이 달라질 수 있습니다. 실제 업무에 적용하기 전 반드시 현행 법령(국가법령정보센터)을 직접 확인하고 전문가(세무사·노무사 등)의 자문을 거치시기 바랍니다. 본 글의 정보를 활용해 발생한 어떠한 결과나 법적 문제에 대해서도 작성자는 책임지지 않습니다.
이름과 전화번호를 지우고 사번만 남긴 로그 테이블을 본 적이 있습니다. 만든 사람은 개인정보가 아니라고 했고, 저도 그 말이 그럴듯하게 들렸습니다. 이름이 없으니까요.
그런데 같은 데이터베이스의 옆 테이블에는 사번과 이름이 나란히 있었습니다. 조인 한 번이면 닿는 거리였습니다.
이름이 지워진 데이터는 언제부터 개인정보가 아니게 될까요?
이 글은 개인정보 도메인의 문을 여는 글입니다. 개인정보 보호법이 다루는 대상이 어디서 시작해 어디서 끝나는지, 그 경계를 정하는 두 개의 문장을 읽습니다. 동의를 받아야 하는지, 파기해야 하는지, 유출됐을 때 신고해야 하는지 같은 뒷단의 질문은 전부 "이게 개인정보인가"에서 갈라져 나오기 때문에, 여기서는 경계선 자체를 먼저 그리겠습니다.
개인정보의 정의: 세 개의 목
법은 개인정보를 한 문장으로 정의하지 않습니다. 세 갈래로 나눠 적어 두었습니다.
개인정보 보호법 제2조(정의) 1. "개인정보"란 살아 있는 개인에 관한 정보로서 다음 각 목의 어느 하나에 해당하는 정보를 말한다.
가. 성명, 주민등록번호 및 영상 등을 통하여 개인을 알아볼 수 있는 정보
나. 해당 정보만으로는 특정 개인을 알아볼 수 없더라도 다른 정보와 쉽게 결합하여 알아볼 수 있는 정보. 이 경우 쉽게 결합할 수 있는지 여부는 다른 정보의 입수 가능성 등 개인을 알아보는 데 소요되는 시간, 비용, 기술 등을 합리적으로 고려하여야 한다.
다. 가목 또는 나목을 제1호의2에 따라 가명처리함으로써 원래의 상태로 복원하기 위한 추가 정보의 사용·결합 없이는 특정 개인을 알아볼 수 없는 정보(이하 "가명정보"라 한다)
가목은 직관적입니다. 이름, 주민등록번호, 얼굴이 찍힌 영상. 그 값 하나만 보고도 누구인지 알 수 있는 정보입니다. 개발자가 개인정보라는 말을 들었을 때 머릿속에 떠올리는 것도 대체로 이 목입니다.
문제는 나목입니다. 그 값만으로는 누구인지 모르는 정보도 개인정보가 될 수 있다는 선언이고, 실무에서 판단이 갈리는 거의 모든 사례가 여기에 걸립니다. 그리고 다목은 가명정보를 개인정보의 한 종류로 못 박아 둡니다. 가명처리를 마친 데이터가 개인정보의 정의 바깥으로 나가는 것이 아니라, 정의 안의 세 번째 칸으로 들어간다는 뜻입니다.
Recap
- 개인정보의 정의는 가목(그 자체로 식별), 나목(결합하면 식별), 다목(가명정보) 세 갈래입니다.
- 실무의 판단이 갈리는 지점은 거의 전부 나목이며, 개발자가 흔히 떠올리는 것은 가목뿐입니다.
- 가명정보는 정의 안에 들어 있으므로 여전히 개인정보입니다.
결합 용이성: 경계를 옮기는 한 문장
나목의 뒷문장이 이 도메인 전체에서 가장 자주 인용되는 문장입니다. 쉽게 결합할 수 있는지는 "다른 정보의 입수 가능성 등 개인을 알아보는 데 소요되는 시간, 비용, 기술 등을 합리적으로 고려"해서 정합니다.
여기서 두 가지가 따라 나옵니다.
첫째, 판단 기준이 데이터 자체에 있지 않습니다. 누가 그 데이터를 들고 있느냐에 따라 같은 값의 성격이 달라집니다. 서두의 사번이 그 예입니다. 사번과 이름을 잇는 인사 테이블을 함께 가진 회사 안에서 그 로그는 개인정보입니다. 그 매핑을 가질 방법이 없는 외부 업체에게 사번만 넘긴다면 같은 값이라도 판단이 달라질 여지가 생깁니다. 데이터의 성격을 결정하는 것이 데이터를 보는 사람의 위치라는 뜻이라, 스키마만 보고 답을 내릴 수 없습니다.
둘째, "쉽게"의 기준이 기술과 함께 움직입니다. 시간·비용·기술을 합리적으로 고려하라는 문장은 10년 전의 답과 지금의 답이 달라도 된다는 말과 같습니다. 재식별에 슈퍼컴퓨터가 필요하던 시절의 판단이 노트북으로 가능해진 시점에 그대로 유지될 이유가 없습니다.
조문은 "다른 정보의 입수 가능성"이라고만 적어 두었습니다. 우리 회사가 가진 다른 테이블로 한정하지 않습니다. 공개된 명부, 이미 유출되어 돌아다니는 데이터셋, 상용 데이터 브로커가 파는 목록까지 입수 가능성 안에 들어옵니다. 사내 조인만 따져 보고 안심하기 어려운 이유입니다.
Recap
- 결합 용이성은 시간·비용·기술과 다른 정보의 입수 가능성을 합쳐서 판단합니다.
- 같은 값이라도 보유자가 누구냐에 따라 개인정보일 수도 아닐 수도 있습니다.
- 결합 상대는 사내 데이터에 한정되지 않고, 기준 자체가 기술 발전에 따라 움직입니다.
그래서 이 값들은 어느 쪽인가
실무에서 반복해 마주치는 값들을 위 기준에 넣어 보면 이렇게 정리됩니다.
| 값 | 판단 | 근거 |
|---|---|---|
| 사번, 사내 이메일 | 개인정보 | 인사 정보와 결합이 사실상 자유롭습니다 |
| 휴대폰 번호 | 개인정보 | 가목에 가깝게 취급됩니다 |
| IP 주소 | 대체로 개인정보 | 통신사 보유 정보나 접속 로그와 결합하면 식별이 가능합니다 |
| 쿠키, 광고 식별자 | 대체로 개인정보 | 단말과 행태를 잇는 키로 기능합니다 |
| 휴대폰 번호의 해시값 | 개인정보 | 아래 참고 |
| 개인사업자의 상호, 사업자등록번호 | 개인정보에 해당할 수 있음 | 대표자 개인과 사실상 일대일입니다 |
| 법인의 대표번호, 법인등록번호 | 개인정보 아님 | 살아 있는 개인에 관한 정보가 아닙니다 |
| 사망자의 정보 | 개인정보 아님 | 같은 이유입니다 |
해시값 줄이 개발자에게 제일 반직관적입니다. 단방향 해시는 되돌릴 수 없다고 배웠으니 통과된 값은 안전하다고 여기기 쉽습니다. 그런데 되돌릴 수 없다는 성질은 원본의 경우의 수가 클 때만 의미가 있습니다. 국내 휴대폰 번호는 자리 수가 고정돼 있어 가능한 조합이 1억 개 남짓입니다. 1억 개를 전부 해싱해 표로 만드는 일은 노트북 한 대로 몇 분이면 끝납니다. 주민등록번호도 생년월일과 성별 자리가 정해져 있어 사정이 다르지 않습니다.
솔트(salt)를 섞으면 그 표를 미리 만들어 둘 수 없으니 사정이 나아집니다. 다만 그 솔트를 같은 시스템이 들고 있다면, 그건 정확히 조문이 말하는 "원래의 상태로 복원하기 위한 추가 정보"입니다. 복원 키를 옆에 둔 채로 값만 바꿔 둔 상태는 익명이 아니라 가명입니다.
Recap
- 사번·IP·쿠키처럼 이름이 없는 값도 결합 가능성 때문에 대체로 개인정보로 다뤄집니다.
- 전화번호 해시는 원본 경우의 수가 작아 전수 대입으로 복원되므로 안전한 처리가 아닙니다.
- 솔트를 같은 시스템이 보관하면 그 솔트가 곧 복원용 추가 정보이므로 익명화가 아닙니다.
가명정보와 익명정보: 되돌릴 수 있느냐의 차이
이름을 지운 데이터가 갈 수 있는 곳은 두 군데입니다. 둘의 법적 지위는 정반대입니다.
가명처리는 추가 정보 없이는 특정 개인을 알아볼 수 없도록 만드는 처리입니다. 핵심은 "추가 정보 없이는"이라는 조건이 붙어 있다는 점입니다. 그 추가 정보가 어딘가에 남아 있다는 전제이므로, 결과물인 가명정보는 제2조 제1호 다목에 따라 여전히 개인정보입니다. 법의 의무가 계속 걸려 있습니다.
익명정보는 다릅니다.
개인정보 보호법 제58조의2(적용제외) 이 법은 시간·비용·기술 등을 합리적으로 고려할 때 다른 정보를 사용하여도 더 이상 개인을 알아볼 수 없는 정보에는 적용하지 아니한다.
이 조문은 정의 규정이 아니라 적용 제외 규정입니다. 여기에 해당하면 개인정보 보호법 자체가 적용되지 않습니다. 동의도, 파기도, 유출 신고도 없습니다. 다만 그 대가로 요구되는 것이 "다른 정보를 사용하여도" 알아볼 수 없어야 한다는 조건이고, 이건 결합 용이성의 문턱보다 훨씬 높습니다. 복원 키를 따로 보관하는 방식은 여기 닿지 못합니다.
실무에서 이 둘을 섞어 부르는 일이 잦습니다. "익명화했습니다"라고 말하지만 실제로는 매핑 테이블을 지우지 않은 가명처리인 경우입니다. 이름만 바뀌면 되는 문제가 아니라, 파기 의무와 정보주체의 권리가 통째로 붙었다 떨어지는 차이입니다.
Recap
- 가명정보는 추가 정보가 있으면 복원되므로 개인정보로 남고, 법의 의무도 그대로 따라옵니다.
- 익명정보는 제58조의2에 따라 법의 적용 자체를 벗어나지만, 그만큼 문턱이 높습니다.
- 매핑 테이블을 남겨 둔 처리는 익명화가 아니라 가명처리입니다.
정의에서 조용히 빠져 있는 것들
정의의 첫 구절인 "살아 있는 개인에 관한 정보"도 그냥 지나칠 문장이 아닙니다. 두 가지를 밖으로 밀어냅니다.
하나는 사망자의 정보입니다. 개인정보 보호법의 보호 대상이 아닙니다. 다만 사망자와 유족을 잇는 정보라면 그건 유족이라는 살아 있는 개인에 관한 정보가 되므로, 사망 플래그 하나로 전체 레코드가 법 밖으로 나가지는 않습니다.
다른 하나는 법인의 정보입니다. 법인등록번호나 대표전화는 개인에 관한 정보가 아닙니다. 그래서 기업 고객만 상대하는 서비스라면 개인정보를 다루지 않는다고 생각하기 쉬운데, 실제로는 그 법인의 담당자 이름과 연락처를 반드시 들고 있게 됩니다. 계정을 만드는 것도, 청구서를 받는 것도 사람이기 때문입니다.
개인사업자는 그 사이에 놓입니다. 상호와 사업자등록번호가 대표자 개인과 사실상 일대일로 붙어 있어서, 사업자 정보라는 이유로 개인정보가 아니라고 단정하기 어렵습니다.
Recap
- 사망자와 법인의 정보는 "살아 있는 개인"에 해당하지 않아 정의에서 빠집니다.
- 사망자 정보라도 유족과의 관계가 드러나면 유족의 개인정보가 됩니다.
- 법인 고객 서비스도 담당자 정보를 반드시 보유하며, 개인사업자 정보는 개인정보로 다뤄질 여지가 큽니다.
로그 테이블 한 장을 다시 읽기
처음의 로그 테이블로 돌아가 보겠습니다. 컬럼은 이렇습니다.
| 컬럼 | 값의 예 |
|---|---|
employee_no | A-20194 |
ip | 211.xx.xx.14 |
phone_hash | 9f2c…(솔트 없는 SHA-256) |
action | payslip.view |
created_at | 2026-08-30T09:12:00+09:00 |
이름도 전화번호도 없습니다. 그런데 employee_no는 옆 테이블에서 이름과 만나고, phone_hash는 전수 대입으로 원본이 나오며, ip는 접속 기록과 결합하면 개인을 가리킵니다. 셋 중 하나만 있어도 나목에 걸립니다. 이 테이블은 처음부터 끝까지 개인정보 테이블이었고, 이름을 지운 일은 그 사실을 바꾸지 못했습니다.
바꾸려면 둘 중 하나를 해야 합니다. 매핑을 완전히 끊고 되돌릴 방법을 남기지 않아 제58조의2로 나가거나, 되돌릴 수 있음을 인정하고 가명정보로서의 의무를 지는 것입니다. 어느 쪽을 골랐는지 말할 수 없는 상태가 가장 나쁩니다. 법의 적용 여부가 정해지지 않은 채로 데이터가 쌓이기 때문입니다.
action 컬럼도 그냥 두고 볼 값이 아닙니다. 급여명세서를 언제 열어 봤는지는 그 자체로 한 사람의 행태 기록입니다. 개인정보인지 아닌지를 판단할 때 사람들은 보통 식별자 컬럼만 쳐다보는데, 식별자에 붙어 있는 나머지 컬럼 전부가 그 사람에 관한 정보가 됩니다. 개인정보의 단위는 컬럼이 아니라 행입니다.
Recap
- 이름을 지워도 결합 가능한 식별자가 하나라도 남으면 그 테이블은 개인정보 테이블입니다.
- 선택지는 되돌릴 수 없게 끊어 익명정보로 내보내거나, 가명정보로서 의무를 지는 것 둘뿐입니다.
- 식별자에 붙은 나머지 컬럼도 함께 개인정보가 되므로, 판단의 단위는 컬럼이 아니라 행입니다.
References
- 개인정보 보호법: 제2조(정의)·제58조의2(적용제외). 국가법령정보센터
- 개인정보 보호법 제2조: 조문 전문. CaseNote
- 개인정보 보호법 제58조의2: 조문 전문. CaseNote
