한국의 개인정보보호법은 두 가지 극단 사이에서 균형을 잃었다. 무엇이 개인정보인지는 해석에 따라 거의 모든 정보가 포함될 수 있을 만큼 넓게 정의하면서, 그 정보를 어떻게 다뤄야 하는지는 구체적인 기술 명세로 경직되게 통제한다. 보호해야 할 대상의 경계는 흐릿한데 보호 방법은 구체적인 체크리스트로 고정되어 있다. 이 구조적 모순이 실무에서 어떤 문제를 만드는지, 전 세계 주요 개인정보보호 규제들과 비교하며 파헤쳐보자.

정보의 세 가지 층위: 식별자, 개인정보, 프라이버시

개인정보 규제를 논하기 전에 정보의 성격을 구분해야 한다. 모든 정보가 같은 수준의 보호를 필요로 하지 않는다. 이걸 구분하지 못하면 규제는 비효율적이 되고, 정작 보호해야 할 정보는 소홀해진다.

첫 번째 층위는 식별자다. 이메일 주소, 전화번호, 쿠키 ID, IP 주소, 디바이스 핑거프린트 같은 것들이다. 이건 누군가에게 연락하거나 시스템에서 특정 사용자를 구분하기 위한 기술적 수단이다. user8472@gmail.com이라는 문자열, 010-1234-5678이라는 숫자 조합, 192.168.1.1이라는 IP 주소. 이것들만으로는 그 사람이 누구인지 알 수 없다. 이름도, 나이도, 어디 사는지도, 무슨 일을 하는지도 모른다. 단지 “어떤 사람”과 연결된 접점일 뿐이다.

두 번째 층위는 개인정보다. 이름, 생년월일, 주소, 직장, 학력처럼 특정 개인을 식별하고 그 사람에 대해 알 수 있게 하는 정보다. 홍길동, 1985년 3월 15일생, 서울특별시 강남구 테헤란로 123, 크리밋 대표. 이 정도면 그 사람이 누구인지 상당 부분 특정되고, 사회적 맥락에서 그 사람을 이해할 수 있다.

세 번째 층위는 프라이버시 영역이다. 건강 상태, 의료 기록, 성적 지향, 정치적 견해, 종교적 신념, 금융 거래 내역, 범죄 경력, 생체 정보. 이건 단순히 누구인지를 넘어서 그 사람의 내밀한 영역에 해당한다. 노출됐을 때 차별, 불이익, 정신적 피해로 이어질 수 있다. 보호의 필요성이 질적으로 다르다.

합리적인 규제 체계라면 이 세 층위를 명확히 구분하고 각각에 비례하는 보호 수준을 적용해야 한다. 식별자는 기본적인 보안 조치와 투명성 요구 정도로, 개인정보는 수집 목적 제한과 적절한 동의 절차로, 프라이버시 영역은 엄격한 동의와 최소 수집 원칙으로. 위험 수준에 따른 차등 규제가 원칙이다.

글로벌 규제들은 어떻게 구분하는가

세계 주요 개인정보보호 규제들은 저마다 방식은 다르지만, 정보의 민감도에 따른 차등 규제라는 원칙은 공유한다.

GDPR은 일반 개인정보와 특별 범주 개인정보를 명확히 나눈다. 특별 범주에는 인종, 민족, 정치적 견해, 종교, 노동조합 가입 여부, 유전자 정보, 생체 정보, 건강 정보, 성생활, 성적 지향이 포함된다. 이 정보들은 원칙적으로 처리가 금지되고, 예외적인 상황에서만 엄격한 요건 하에 처리할 수 있다. 반면 일반 개인정보는 6가지 적법 처리 근거 중 하나만 충족하면 된다. 동의, 계약 이행, 법적 의무, 중대한 이익, 공익, 정당한 이익. 특히 정당한 이익 조항은 B2B 환경에서 합리적인 영업 활동을 가능하게 한다.

미국은 연방 차원의 포괄적 개인정보보호법이 없다. 대신 주별로 규제가 발전하고 있고, 캘리포니아가 선두에 있다. CCPA와 CPRA는 개인정보의 정의를 넓게 잡으면서도 민감 정보를 별도로 규정해 차등 규제한다. 민감 정보에는 사회보장번호, 운전면허번호, 금융계좌 정보, 정밀 위치정보, 인종, 민족, 종교, 유전자 정보, 생체 정보, 건강 정보, 성생활, 성적 지향이 포함된다. 일반 개인정보에 대해서는 소비자에게 opt-out 권리를 주고, 민감 정보에 대해서만 opt-in 동의를 요구한다.

버지니아 VCDPA, 콜로라도 CPA, 코네티컷 CTDPA, 유타 UCPA, 텍사스 TDPSA 등 다른 주 법률들도 대체로 이 틀을 따른다. 민감 정보의 범위에 약간씩 차이가 있지만, 일반 정보와 민감 정보를 구분한다는 원칙은 동일하다.

브라질 LGPD는 10가지 적법 처리 근거를 두고 있어서 동의 외에도 다양한 방법으로 처리 정당성을 확보할 수 있다. 캐나다 PIPEDA는 민감 정보를 맥락에 따라 판단하도록 하고 묵시적 동의를 넓게 인정한다. 호주 Privacy Act는 민감 정보 수집에만 동의를 요구하고 일반 정보는 합리적 필요성으로 수집할 수 있다. 일본 APPI는 요배려개인정보 개념으로 차별이나 편견을 야기할 수 있는 정보만 별도 동의를 요구한다. 싱가포르 PDPA는 동의 예외가 가장 잘 정비되어 있고 2021년 개정으로 정당한 이익 예외도 도입됐다.

이 모든 규제들에 공통점이 있다. 정보의 성격에 따라 규제 강도를 다르게 적용한다는 것이다. 민감 정보는 엄격하게, 일반 정보는 상대적으로 유연하게. 식별자 수준의 정보를 민감 정보와 동일하게 취급하는 규제는 없다.

한국법의 결합정보 문제: 이론과 현실의 괴리

한국 개인정보보호법 제2조를 보자. 개인정보란 살아 있는 개인에 관한 정보로서 성명, 주민등록번호 및 영상 등을 통하여 개인을 알아볼 수 있는 정보, 해당 정보만으로는 특정 개인을 알아볼 수 없더라도 다른 정보와 쉽게 결합하여 알아볼 수 있는 정보를 포함한다.

이 “쉽게 결합하여”라는 문구가 모든 문제의 근원이다.

이론적으로 결합 가능한 정보는 거의 모든 정보다. 이메일 주소 user8472@gmail.com을 보자. 이 문자열만으로는 누군지 모른다. 하지만 이 이메일로 가입한 서비스가 있을 것이다. 그 서비스의 데이터베이스에는 이름, 연락처, 결제 정보가 있을 수 있다. 이론적으로 결합 가능하다. 그러니 개인정보다.

IP 주소 203.247.xxx.xxx를 보자. 이것만으로는 특정 개인을 알 수 없다. 하지만 ISP는 이 IP가 어느 가입자에게 할당됐는지 기록이 있다. 결합하면 알 수 있다. 그러니 개인정보다.

이 논리를 끝까지 밀어붙이면 디지털 환경에서 수집되는 거의 모든 데이터가 개인정보가 된다. 어딘가에, 누군가가, 어떤 방법으로든 다른 정보와 연결할 수 있는 가능성이 존재하기 때문이다.

문제는 이 “결합”이 현실에서 얼마나 가능한가다.

user8472@gmail.com의 실제 소유자를 알아내려면 어떤 과정이 필요한지 생각해보자. 먼저 이 이메일로 가입된 서비스를 찾아야 한다. 구글, 네이버, 수천 개의 웹사이트 중 어디에 가입했는지 알 방법이 없다. 설령 특정 서비스를 알아냈다고 해도, 그 서비스가 해당 정보를 제공할 이유가 없다. 법적 절차 없이 타사 고객 정보를 달라고 하면 어떤 회사가 주겠는가. 법원의 영장이나 수사기관의 정식 요청이 필요하다. 그 과정에는 시간과 비용과 정당한 사유가 필요하다.

실제로 결합을 수행하려면 다음 조건들이 모두 충족되어야 한다. 결합 대상 데이터에 대한 접근 권한, 결합을 수행할 기술적 역량, 결합에 소요되는 시간과 비용, 결합을 정당화할 법적 근거, 상대방 조직의 협조. 이 조건들을 모두 갖춘 주체가 몇이나 될까. 수사기관, 그것도 영장을 발부받은 수사기관 정도다. 일반 기업이나 개인이 타인의 이메일 주소 하나로 그 사람을 특정할 수 있는 현실적 경로는 거의 없다.

GDPR도 결합 가능성을 인정한다. 하지만 핵심적인 차이가 있다. Recital 26에서 “개인을 식별하는 데 합리적으로 사용될 가능성이 있는 모든 수단”을 고려하되, “식별에 필요한 비용과 시간, 처리 당시 이용 가능한 기술과 기술 발전”을 함께 고려하라고 명시한다. 즉, 이론적 가능성이 아니라 현실적 가능성을 따진다. 천문학적 비용이 들거나 현재 기술로 불가능한 결합은 고려 대상이 아니다.

한국법에는 이런 합리성 기준이 없다. “쉽게 결합하여”라는 표현이 있지만, 무엇이 쉬운 결합이고 무엇이 어려운 결합인지 기준이 모호하다. 실무에서는 안전하게 가기 위해 결합 가능성이 조금이라도 있으면 개인정보로 취급하는 경향이 생긴다. 결과적으로 식별자와 개인정보의 경계가 사라지고, 모든 정보가 개인정보가 되는 상황이 벌어진다.

B2B SaaS에서 겪는 현실: 크리밋의 사례

이론적인 논의를 넘어 실제 사례를 보자. 크리밋은 NHI(Non-Human Identity) 보안 플랫폼을 운영하는 B2B SaaS 기업이다. 기업 고객의 GitHub, GitLab, Slack 등에서 노출된 크리덴셜을 탐지하고 알려주는 서비스다. 이 사업을 하면서 한국 개인정보보호법의 모순을 매일 체감한다.

첫 번째 상황. 고객사 보안 담당자의 이메일 주소. 우리는 고객사와 계약을 맺고, 해당 기업의 보안 담당자에게 알림을 보낸다. security@customer.com 또는 john.kim@customer.com 같은 주소다. 이건 업무용 이메일이다. 그 사람이 그 회사에서 보안 업무를 담당한다는 정보 외에 개인적인 정보는 전혀 없다. 하지만 한국법 해석에 따르면 이것도 개인정보다. 다른 정보와 결합하면 그 사람이 누군지 알 수 있기 때문이다. 결과적으로 우리는 계약 관계에 있는 기업의 업무 담당자 이메일을 저장하는 것만으로도 개인정보 처리에 해당하는 모든 의무를 져야 한다.

같은 상황을 GDPR 하에서 보자. 이건 정당한 이익에 해당한다. 계약 이행을 위해 계약 상대방의 연락처를 보유하는 건 당연히 허용된다. 별도 동의가 필요 없다. 상식적이다.

두 번째 상황. 잠재 고객 발굴. B2B 영업에서 아웃바운드는 기본이다. 컨퍼런스에서 명함을 교환하고, 링크드인에서 타겟 기업의 CISO를 찾고, 웹사이트에 공개된 보안팀 연락처로 제안서를 보낸다. GDPR 하에서는 정당한 이익으로 이 모든 게 가능하다. 수신 거부 옵션만 제공하면 된다.

한국에서는 다르다. 명함을 받았어도 그 명함의 이메일로 마케팅 메일을 보내려면 별도 동의가 필요하다는 해석이 있다. 링크드인에서 찾은 연락처는 더 문제다. 본인이 공개적으로 게시한 정보인데도 이걸 수집해서 연락하는 게 개인정보 무단 수집에 해당할 수 있다. 결과적으로 한국 스타트업은 해외 경쟁사 대비 영업 활동에 심각한 제약을 받는다.

세 번째 상황. 크리덴셜 탐지 과정에서 마주치는 정보. 우리 서비스는 GitHub 커밋에서 실수로 노출된 API 키, 데이터베이스 비밀번호, 클라우드 크리덴셜을 찾아낸다. 이 과정에서 커밋한 개발자의 이메일을 보게 된다. 이 이메일 주소는 탐지 결과를 해당 담당자에게 전달하기 위해 필요하다. 보안 사고를 막기 위한 선의의 목적이다.

하지만 엄격히 해석하면 우리는 제3자의 개인정보를 본인 동의 없이 수집하고 있는 셈이다. “타사 직원의 크리덴셜 노출을 알려주기 위해”가 어느 예외에 해당하는지 명확하지 않다. 보안 사고는 골든 타임이 있는데, 동의를 먼저 받으라고 하면 현실적으로 불가능하다.

네 번째 상황. 고객사 환경에서 수집되는 메타데이터. 크리밋 서비스가 고객사의 GitHub를 스캔할 때 레포지토리 이름, 브랜치 이름, 파일 경로, 커밋 메시지를 처리한다. 커밋 메시지에 “John이 리뷰한 코드 반영”이라고 적혀 있으면? 파일 경로가 /users/john.kim/projects/something이면? 이론적으로 결합하면 특정 개인과 연결될 수 있다. 만약 그렇다면 우리 서비스가 처리하는 거의 모든 데이터가 개인정보가 된다.

NHI 보안이라는 분야 자체가 기계 대 기계 인증, 서비스 계정, API 키, 토큰 같은 비인간 주체의 보안을 다룬다. 그런데 그 과정에서 불가피하게 사람의 흔적이 묻어 있는 메타데이터를 처리하게 된다. 비인간 주체의 보안을 위해 만든 서비스가 인간의 개인정보 규제에 발목을 잡힌다. 아이러니하다.

기술적 규제의 경직성: 가이드가 현실을 따라가지 못한다

정보의 정의가 이렇게 넓은데, 정작 기술적 보호 조치는 어떻게 규정되어 있을까. 개인정보의 안전성 확보조치 기준 고시와 관련 가이드라인을 보면, 문제는 단순히 “구식”이라는 게 아니다. 가이드가 개정되더라도 기술 발전 속도를 따라갈 수 없는 구조적 한계가 있다.

비밀번호 저장을 보자. 업계의 합의된 모범 사례는 명확하다. 비밀번호는 bcrypt, scrypt, Argon2 같은 느린 해시 함수로 해싱해야 한다. 이 알고리즘들은 의도적으로 연산 비용을 높게 설계해서 무차별 대입 공격을 현실적으로 불가능하게 만든다. OWASP Password Storage Cheat Sheet, NIST Digital Identity Guidelines, 모든 권위 있는 보안 가이드가 이걸 권장한다.

한국 고시와 가이드는 어떤가. 비밀번호를 저장할 때 일방향 암호화를 적용하라고 하고, SHA-256에 솔트를 적용하는 방식을 안내한다. 솔트를 쓰라고 한 건 다행이다. 하지만 SHA-256 자체가 비밀번호 해싱용으로 설계된 알고리즘이 아니라는 근본적인 문제는 남아 있다.

SHA-256은 범용 암호화 해시 함수다. 빠르게 동작하도록 설계됐다. 파일 무결성 검증, 디지털 서명, 블록체인 작업 증명에 쓰인다. 비밀번호 해싱에서는 빠른 게 단점이 된다. 현대 GPU로 SHA-256 해시를 초당 수십억 개 계산할 수 있다. 솔트가 있어도 무차별 대입 공격의 속도를 근본적으로 늦추지 못한다.

bcrypt는 다르다. 의도적으로 느리게 설계됐고, 비용 인자를 통해 하드웨어가 발전해도 연산 시간을 조절할 수 있다. 2024년 기준으로 bcrypt cost factor 12면 해시 하나 계산하는 데 수백 밀리초가 걸린다. 공격자 입장에서 수십억 배 느려지는 셈이다. 보안적으로 SHA-256+솔트와는 차원이 다르다.

그런데 bcrypt는 한국의 암호 알고리즘 가이드에 공식적으로 포함되어 있지 않다. 가이드에 없는 알고리즘을 쓰면 감사나 인증 과정에서 설명해야 할 부담이 생긴다. 결과적으로 많은 기업들이 보안적으로 더 나은 방식을 알면서도 가이드에 맞추는 쪽을 선택한다.

문제의 핵심은 가이드 개정 속도다. 새로운 알고리즘이 업계 표준으로 자리잡고, 그게 한국의 공식 가이드에 반영되기까지 얼마나 걸릴까. Argon2가 2015년 Password Hashing Competition에서 우승했다. 2024년 현재 글로벌 보안 커뮤니티에서는 Argon2id가 권장 알고리즘이다. 한국 가이드에는 아직 없다. 9년이 지났다.

암호학은 빠르게 발전한다. 새로운 공격 기법이 발견되고, 새로운 알고리즘이 표준화되고, 기존 알고리즘이 폐기된다. SHA-1은 한때 표준이었지만 2017년에 실질적 충돌 공격이 시연된 후 사용 금지가 됐다. 양자 컴퓨팅이 실용화되면 현재의 공개키 암호화 체계 상당 부분이 위협받는다. NIST가 포스트 양자 암호 표준화를 진행하고 있고, 2024년에 첫 표준이 발표됐다. 이게 한국 규정에 반영되려면 몇 년이 걸릴까.

법률과 고시와 가이드는 개정에 시간이 걸린다. 전문가 검토, 의견 수렴, 행정 절차. 그 사이에 기술은 계속 발전한다. 가이드가 업데이트되더라도 이 구조적 시차는 해결되지 않는다. 기술은 규정을 기다려주지 않는다.

비밀번호 변경 주기도 비슷한 사례다. 최근 개정으로 반기별 변경 의무가 완화됐다. 다행이다. 비밀번호 주기적 변경은 보안 업계에서 이미 폐기된 관행이었다. NIST가 2017년에 정기적 비밀번호 변경 요구를 삭제했고, 마이크로소프트도 2019년에 비밀번호 만료 정책을 제거했다. 주기적 변경을 강제하면 사용자들이 예측 가능한 패턴으로 비밀번호를 만들거나 더 약한 비밀번호를 선택한다는 연구 결과가 축적됐기 때문이다.

한국 규정이 이걸 반영하기까지 몇 년이 걸렸나. NIST 권고가 2017년이다. 그 사이 한국 기업들은 보안적으로 의미 없거나 오히려 해로운 정책을 강제로 시행해야 했다. 6개월마다 전 직원에게 비밀번호 변경을 요구하고, 직원들은 Password202401, Password202407 같은 비밀번호를 설정했다. 규정은 준수했다. 보안은 약해졌다. 규정이 결국 개정됐으니 다행이라고 할 수 있을까. 그 시차가 발생했다는 것 자체가 문제다.

암호화 알고리즘 지정도 같은 문제다. 고시에서 언급하는 알고리즘들을 보면 SEED, ARIA, AES가 있다. SEED와 ARIA는 국산 알고리즘이다. 하지만 글로벌 시장에서 이 알고리즘들은 사실상 쓰이지 않는다. 검증된 사용 사례가 적고, 라이브러리 지원이 제한적이고, 성능 최적화가 덜 되어 있다.

더 근본적인 문제는 알고리즘을 법으로 지정하는 접근 방식 자체다. GDPR의 접근은 다르다. 기술적 조치에 대해 “적절한(appropriate)” 수준을 요구하면서 구체적인 기술은 지정하지 않는다. state of the art, 구현 비용, 처리의 성격과 맥락, 위험의 가능성과 심각성을 고려해서 기업이 판단하도록 한다. 어떤 알고리즘을 쓰라고 법에 적어놓지 않는다. 기술 발전에 따라 유연하게 대응할 수 있다.

불균형이 만드는 실무적 문제

정리하면 이렇다. 한국 개인정보보호법은 개인정보의 범위는 결합 가능성을 근거로 무한히 확장하면서, 보호 방법은 특정 기술과 절차를 구체적으로 지정해서 경직되게 통제한다. 이 불균형이 실무에서 만드는 문제는 심각하다.

첫째, 규제 준수 비용의 역진성. 모든 정보를 개인정보로 취급하고, 거기에 구체적인 기술적 요건을 적용하면 규제 준수 비용이 급격히 올라간다. 대기업은 전담 팀이 있고 규정 준수 비용을 감당할 체력이 있다. 스타트업은 없다. 5명이 제품 만들기도 바쁜데 내부관리계획 수립하고, 접속 기록 보관 시스템 구축하고, 개인정보 영향평가 받아야 한다. 규제가 대기업에 유리하게 작동한다. 진입 장벽이 된다.

둘째, 형식적 준수와 실질적 보안의 괴리. 기업들의 목표가 보안이 아니라 규정 준수가 된다. 체크리스트를 채우는 게 우선이다. 가이드에 있는 방식이 최선이 아니어도 가이드대로 한다. 진짜 중요한 보안 투자에 쓸 자원이 규정 준수에 소모된다.

셋째, 혁신 저해. 데이터 기반 서비스를 만들려면 데이터를 처리해야 한다. 한국법 하에서는 이 모든 과정에 동의와 고지와 문서화가 필요하다. 식별자 수준의 정보도 개인정보이기 때문이다. 해외 경쟁사들이 정당한 이익 조항으로 자유롭게 하는 것을 한국 기업은 복잡한 법적 검토와 동의 절차를 거쳐야 한다. 속도에서 지고, 유연성에서 지고, 결국 경쟁력에서 진다.

넷째, 글로벌 정합성 문제. GDPR 준수하면 한국법도 자동으로 준수될 것 같지만 실제로는 다르다. GDPR에서 허용되는 것이 한국에서 금지되는 경우가 있다. 반대로 한국 기준으로 과도하게 동의를 받으면 해외 사용자 경험이 나빠진다.

무엇이 바뀌어야 하는가

개인정보 보호 자체를 부정하는 게 아니다. 방향과 균형이 잘못됐다는 것이다.

정보의 정의는 더 정교해져야 한다. 식별자, 개인정보, 민감 정보를 명확히 구분하고 각각에 비례하는 규제를 적용해야 한다. 결합 가능성 판단에 합리성 기준을 도입해야 한다. GDPR처럼 결합에 필요한 비용, 시간, 기술 수준, 현실적 가능성을 고려해서 판단해야 한다.

기술적 규제는 원칙 기반으로 전환해야 한다. 특정 알고리즘이나 절차를 법에 지정하는 대신, 보안 목표를 제시하고 방법은 기업이 선택하게 해야 한다. “비밀번호는 무차별 대입 공격에 저항할 수 있는 방식으로 저장해야 한다”고 하면 된다. bcrypt를 쓰든 Argon2를 쓰든 목표를 달성하면 된다. 가이드 개정을 몇 년씩 기다릴 필요가 없어진다.

규제의 차등화가 필요하다. 대기업과 스타트업, 민감 정보 처리자와 일반 정보 처리자를 같은 잣대로 규제하면 안 된다. 처리하는 정보의 양과 성격, 기업의 규모, 잠재적 위험 수준에 따라 다른 요건을 적용해야 한다.

정당한 이익 조항을 실효성 있게 만들어야 한다. 동의만이 유일한 적법 처리 근거인 것처럼 운영되는 현실을 바꿔야 한다. B2B 맥락에서 합리적인 영업 활동, 공개된 정보의 활용, 서비스 개선을 위한 분석 같은 것들은 동의 없이도 가능해야 한다.


한국 개인정보보호법이 처음 제정됐을 때의 취지는 이해한다. 개인정보 침해 사고가 빈발하고, 기업들의 무분별한 개인정보 수집이 문제가 되던 시절이었다. 강력한 규제가 필요했을 수 있다.

하지만 규제는 환경 변화에 맞춰 진화해야 한다. 디지털 경제가 고도화되고, 데이터가 핵심 자원이 되고, 글로벌 경쟁이 심화되는 상황에서 과거의 접근 방식은 맞지 않는 옷이다. 보호하려던 가치를 오히려 훼손하고, 키워야 할 산업을 억누르고, 따라가야 할 글로벌 표준과 멀어지게 만든다.

개인정보보호법의 목적이 진정으로 개인을 보호하는 것이라면, 지금의 구조적 모순을 직시해야 한다. 정의는 명확하게, 규제는 유연하게, 부담은 위험에 비례하게. 이게 합리적인 개인정보 규제의 방향이다.


Discover more from Ben DH Kim – Notes from Building Cyber Security Startup

Subscribe to get the latest posts sent to your email.

Leave a comment

Ben DH Kim

CEO of Cremit. Aiming to be the #1 Non-Human Identity Security Platform globally.

Love Hacking, Cybersecurity, Philosophy.

Ex-(not so good) Hacker & Software Engineer. Formerly @ Sendbird, Watcha, Class101.

This is my space to share thoughts on tech, security, business, and philosophical ideas.

Let’s connect

Discover more from Ben DH Kim - Notes from Building Cyber Security Startup

Subscribe now to keep reading and get access to the full archive.

Continue reading