이 값도 개인정보인가요?
본 글은 제도 이해를 돕기 위한 교육용 참고 자료이며, 법률 자문이 아닙니다. 본문의 법령은 최종 수정일 기준으로 요약 및 발췌되었으므로, 이후 개정되거나 해석이 달라질 수 있습니다. 실제 업무에 적용하기 전 반드시 현행 법령(국가법령정보센터)을 직접 확인하고 전문가(세무사·노무사 등)의 자문을 거치시기 바랍니다. 본 글의 정보를 활용해 발생한 어떠한 결과나 법적 문제에 대해서도 작성자는 책임지지 않습니다.
이름과 전화번호를 지우고 사번만 남긴 로그 테이블을 본 적이 있습니다. 만든 사람은 개인정보가 아니라고 했고, 저도 그 말이 그럴듯하게 들렸습니다. 이름이 없으니까요.
그런데 같은 데이터베이스의 옆 테이블에는 사번과 이름이 나란히 있었습니다. 조인 한 번이면 닿는 거리였습니다.
이름이 지워진 데이터는 언제부터 개인정보가 아니게 될까요?
이 글에서는 개인정보 보호법의 정의와 적용 제외 기준을 읽고, 로그에 흔히 담기는 사번·IP 주소·해시값에 적용해 보겠습니다. 개인정보 여부를 먼저 판단해야 수집·이용 근거, 보관과 파기, 유출 대응 등 후속 의무를 확인할 수 있습니다.
개인정보의 정의: 세 개의 목
법은 개인정보를 한 문장으로 정의하지 않습니다. 세 갈래로 나눠 적어 두었습니다.
개인정보 보호법 제2조(정의) 1. "개인정보"란 살아 있는 개인에 관한 정보로서 다음 각 목의 어느 하나에 해당하는 정보를 말한다.
가. 성명, 주민등록번호 및 영상 등을 통하여 개인을 알아볼 수 있는 정보
나. 해당 정보만으로는 특정 개인을 알아볼 수 없더라도 다른 정보와 쉽게 결합하여 알아볼 수 있는 정보. 이 경우 쉽게 결합할 수 있는지 여부는 다른 정보의 입수 가능성 등 개인을 알아보는 데 소요되는 시간, 비용, 기술 등을 합리적으로 고려하여야 한다.
다. 가목 또는 나목을 제1호의2에 따라 가명처리함으로써 원래의 상태로 복원하기 위한 추가 정보의 사용·결합 없이는 특정 개인을 알아볼 수 없는 정보(이하 "가명정보"라 한다)
가목은 직관적입니다. 이름, 주민등록번호, 얼굴이 찍힌 영상. 그 값 하나만 보고도 누구인지 알 수 있는 정보입니다. 개발자가 개인정보라는 말을 들었을 때 머릿속에 떠올리는 것도 대체로 이 목입니다.
판단이 어려운 것은 나목입니다. 그 값만으로는 누구인지 모르는 정보도 개인정보가 될 수 있다는 규정이고, 사번·로그처럼 다른 자료와 연결되는 값을 판단할 때 중요합니다. 그리고 다목은 가명정보를 개인정보의 한 종류로 못 박아 둡니다. 가명처리를 마친 데이터가 개인정보의 정의 바깥으로 나가는 것이 아니라, 정의 안에 남아 다목에 해당한다는 뜻입니다.
결합 용이성: 경계를 옮기는 한 문장
나목의 뒷문장은 개인정보 판단에서 가장 자주 인용되는 문장입니다. 쉽게 결합할 수 있는지는 "다른 정보의 입수 가능성 등 개인을 알아보는 데 소요되는 시간, 비용, 기술 등을 합리적으로 고려"해서 정합니다.
이 문장에 따르면 판단 기준은 데이터 자체에 있지 않습니다. 누가 그 데이터를 들고 있느냐에 따라 같은 값의 성격이 달라집니다. 서두의 사번이 그 예입니다. 사번과 이름을 잇는 인사 테이블을 함께 가진 회사 안에서 그 로그는 개인정보입니다. 외부 업체가 받는 경우에는 그 업체가 입수할 수 있는 다른 정보와 이용 환경도 확인해야 합니다. 다만 회사가 가명처리해 제공한 정보는 매핑을 함께 받지 않았다는 이유만으로 개인정보에서 제외되지는 않습니다. 누가 어떤 환경에서 데이터를 보느냐가 그 성격을 정하므로, 스키마만 보고 답을 내릴 수 없습니다.
또 "쉽게"의 기준은 기술 수준에 따라 달라집니다. 시간·비용·기술을 합리적으로 고려하라는 문장은 10년 전의 답과 지금의 답이 달라도 된다는 말과 같습니다. 재식별에 슈퍼컴퓨터가 필요하던 시절의 판단이 노트북으로 가능해진 시점에 그대로 유지될 이유가 없습니다.
조문은 "다른 정보의 입수 가능성"이라고만 적어 두었습니다. 우리 회사가 가진 다른 테이블로 한정하지 않습니다. 공개된 명부, 이미 유출되어 돌아다니는 데이터셋, 상용 데이터 브로커가 파는 목록까지 입수 가능성 안에 들어옵니다. 사내 조인만 따져 보고 안심하기 어려운 이유입니다.
그래서 이 값들은 어느 쪽인가
실무에서 반복해 마주치는 값들을 위 기준에 넣어 보면 이렇게 정리됩니다.
| 값 | 판단 | 근거 |
|---|---|---|
| 사번, 사내 이메일 | 개인정보 | 인사 정보와 결합이 사실상 자유롭습니다 |
| 개인의 휴대폰 번호 | 개인정보 | 개인에게 연락하거나 다른 정보와 연결하는 식별자로 쓰입니다 |
| IP 주소 | 개인정보에 해당할 수 있음 | 입수 가능한 가입자 정보·접속 로그 등과의 결합 가능성을 봅니다 |
| 쿠키, 광고 식별자 | 개인정보에 해당할 수 있음 | 식별자의 내용과 개인·단말·행태를 연결하는 방식을 봅니다 |
| 휴대폰 번호의 해시값 | 개인정보 | 아래 참고 |
| 개인사업자의 상호, 사업자등록번호 | 개인정보에 해당할 수 있음 | 대표자 개인과 사실상 일대일입니다 |
| 법인의 대표번호, 법인등록번호 | 개인정보 아님 | 살아 있는 개인에 관한 정보가 아닙니다 |
| 사망자의 정보 | 개인정보 아님 | 같은 이유입니다 |
단방향 해시라도 입력 후보가 적으면 원본을 추측할 수 있습니다. 전화번호 후보들을 같은 알고리즘으로 해시한 뒤 결과와 대조하는 방식입니다. 이는 해시 함수를 역산하는 것이 아니라 가능한 입력을 대입해 맞는 값을 찾는 공격입니다. 필요한 시간은 알고리즘과 장비, 후보 범위에 따라 달라지므로 ‘몇 분이면 복원된다’고 일률적으로 말할 수는 없습니다.
솔트(salt) 를 사용하면 미리 계산한 표를 재사용하기 어려워집니다. 하지만 솔트는 비밀 복호화 키가 아닙니다. 솔트를 아는 상대는 각 입력 후보를 다시 해시해 비교할 수 있습니다. 따라서 솔트의 유무만으로 익명·가명 여부를 정하지 않고, 다른 정보와의 결합과 재식별 가능성까지 평가해야 합니다.
가명정보와 익명정보: 되돌릴 수 있느냐의 차이
이름을 지운 데이터는 가명정보가 되거나 익명정보가 될 수 있고, 둘의 법적 지위는 정반대입니다.
가명처리는 추가 정보 없이는 특정 개인을 알아볼 수 없도록 만드는 처리입니다. "추가 정보 없이는"이라는 조건에 주목해야 합니다. 이렇게 처리한 결과물인 가명정보는 제2조 제1호 다목에 따라 여전히 개인정보입니다. 법의 의무도 그대로 적용됩니다.
익명정보는 다릅니다.
개인정보 보호법 제58조의2(적용제외) 이 법은 시간·비용·기술 등을 합리적으로 고려할 때 다른 정보를 사용하여도 더 이상 개인을 알아볼 수 없는 정보에는 적용하지 아니한다.
이 조문은 정의 규정이 아니라 적용 제외 규정입니다. 여기에 해당하면 개인정보 보호법 자체가 적용되지 않습니다. 해당 익명정보에는 이 법의 동의·파기·유출 신고 의무가 적용되지 않습니다. 처리 전의 원본 개인정보나 다른 법령상 의무까지 없어지는 것은 아닙니다. 대신 "다른 정보를 사용하여도" 알아볼 수 없어야 한다는 조건을 충족해야 하고, 이 기준은 결합 용이성보다 훨씬 엄격합니다. 복원 키를 따로 보관하는 방식은 이 기준을 충족하지 못합니다.
실무에서 이 둘을 섞어 부르는 일이 잦습니다. "익명화했습니다"라고 말하지만 실제로는 매핑 테이블을 지우지 않은 가명처리인 경우입니다. 부르는 이름만의 문제가 아닙니다. 어느 쪽이냐에 따라 파기 의무와 정보주체의 권리가 적용되거나 통째로 빠집니다.
정의에서 조용히 빠져 있는 것들
정의의 첫 구절인 "살아 있는 개인에 관한 정보"도 그냥 지나칠 문장이 아닙니다. 이 구절 때문에 정의에서 빠지는 정보가 있습니다.
하나는 사망자의 정보입니다. 개인정보 보호법의 보호 대상이 아닙니다. 다만 사망자와 유족을 잇는 정보라면 그건 유족이라는 살아 있는 개인에 관한 정보가 되므로, 사망 플래그 하나로 전체 레코드가 법 적용에서 빠지지는 않습니다.
다른 하나는 법인의 정보입니다. 법인등록번호나 대표전화는 개인에 관한 정보가 아닙니다. 그래서 기업 고객만 상대하는 서비스라면 개인정보를 다루지 않는다고 생각하기 쉬운데, 실제로는 그 법인의 담당자 이름과 연락처를 함께 다루는 경우가 많습니다. 계정을 만드는 것도, 청구서를 받는 것도 사람이기 때문입니다.
개인사업자는 그 사이에 놓입니다. 상호와 사업자등록번호가 대표자 개인과 사실상 일대일로 붙어 있어서, 사업자 정보라는 이유로 개인정보가 아니라고 단정하기 어렵습니다.
로그 테이블 한 장을 다시 읽기
처음의 로그 테이블로 돌아가 보겠습니다. 컬럼은 이렇습니다.
| 컬럼 | 값의 예 |
|---|---|
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는 접속 기록과 결합하면 개인을 가리킵니다. 셋 중 하나만 있어도 나목에 해당합니다. 이 테이블은 처음부터 끝까지 개인정보 테이블이었고, 이름을 지운 일은 그 사실을 바꾸지 못했습니다.
이 로그를 계속 보관·이용하려면 개인정보로서 적법한 근거와 보호조치를 갖춰야 합니다. 별도 활용이 필요하다면 목적에 맞는 가명처리나 익명처리를 검토할 수 있습니다. 매핑을 지우는 것만으로 충분한지는 시간·비용·기술과 나머지 항목의 결합 가능성까지 평가해야 합니다.
action 컬럼도 그냥 두고 볼 값이 아닙니다. 급여명세서를 언제 열어 봤는지는 그 자체로 한 사람의 행태 기록입니다. 개인정보인지 아닌지를 판단할 때 사람들은 보통 식별자 컬럼만 쳐다보는데, 식별자에 붙어 있는 나머지 컬럼 전부가 그 사람에 관한 정보가 됩니다. 따라서 식별자 컬럼만 따로 보지 말고, 연결된 기록 전체에서 한 개인에 관한 정보가 무엇인지 확인해야 합니다.
References
- 개인정보 보호법: 제2조(정의)·제58조의2(적용제외). 국가법령정보센터
- 개인정보 보호법 제2조: 조문 전문. CaseNote
- 개인정보 보호법 제58조의2: 조문 전문. CaseNote
