2026-08-02

파일을 암호화하면 정말 데이터 유출 통지 의무에서 면제될까? GDPR·HIPAA·미국 주법 비교

무언가가 유출된 뒤 변호사나 컴플라이언스 담당자가 가장 먼저 확인하고 싶어 하는 것 중 하나가 "그 파일, 암호화되어 있었나요?"입니다. 몇몇 실제 법률에서는 이 사실 하나가 피해자 전원에게 통지할 법적 의무가 있는지 자체를 바꿔놓기 때문입니다. 흔히 "세이프하버(safe harbor)"나 "면제"라고 표현되고, 얼핏 들으면 통째로 면제받는 것처럼 들립니다. 실제로는 그렇지 않습니다. GDPR, HIPAA, 미국 주(州)법이라는 세 가지 서로 다른 법 체계가 각각 이 방향으로 무언가를 인정해주긴 하지만, 저마다 "암호화했다"는 사실 하나만으로는 자동으로 충족되지 않는 구체적인 기술적 조건을 달아놓았습니다.

GDPR에는 사실 두 개의 통지 의무가 있고, 암호화는 그중 하나만 면제해준다

GDPR의 유출 관련 규정은 서로 다른 기준을 가진 두 가지 별개 의무로 나뉩니다. 제33조는 감독기관에 대한 통지를 다루며, 조문 자체가 "부당한 지체 없이, 가능하다면 인지 후 72시간 이내에" 통지해야 한다고 규정하면서도, 개인정보 유출이 자연인의 권리와 자유에 위험을 초래할 가능성이 낮은 경우는 예외라고 명시합니다 — 상대적으로 넘기 쉬운 기준입니다. 제34조는 더 큰 것을 다룹니다: 피해 당사자 본인에게 직접 알리는 것으로, "개인정보 유출이 자연인의 권리와 자유에 높은 위험을 초래할 가능성이 있을 때"에만 발동됩니다 — 더 높은 기준입니다. 이름이 붙은 암호화 면제 조항이 들어 있는 것은 바로 이 제34조입니다: 관리자가 "적절한 기술적·조직적 보호 조치를 이행했고, 그 조치가 유출된 개인정보에 실제로 적용되었으며, 특히 그 조치가 개인정보를 승인받지 않은 사람이 알아볼 수 없게 만드는 것 — 이를테면 암호화 — 이었다면" 당사자 통지가 필요하지 않습니다. 실재하는 면제 조항이지만, 개인 통지 의무에만 한정된 것입니다. 규제기관에 대한 제33조의 별개이면서 더 낮은 기준을 가진 의무를 자동으로 없애주지는 않습니다 — 견고한 암호화는 실제 위험 자체를 낮추므로 그 기준을 넘는 데도 도움이 될 수는 있지만, 이는 같은 체크박스를 두 번 체크하는 것이 아니라 별개의, 독립적인 판단입니다.

HIPAA 버전은 더 좁고 더 문자 그대로다: 암호화가 PHI를 "안전(secured)"하게 만드는 방법이다

HIPAA의 유출 통지 규칙(Breach Notification Rule)은 보호대상건강정보(PHI)가 "안전하지 않음 (unsecured)"이 아니라 "안전함(secured)"으로 분류되는 순간 아예 적용되지 않습니다 — 그리고 암호화는, 특정한 방식으로 이루어졌을 때, HHS 가이드가 그 전환을 인정하는 두 가지 방법 중 하나입니다 (다른 하나는 파기입니다). HHS 가이드는 저장 데이터(data at rest)의 경우 NIST 특별간행물 800-111에 부합하게 암호화되었을 때 "안전"하다고 보고, 전송 데이터(data in transit)의 경우 암호화 프로세스가 FIPS 140-2 검증을 받았을 때 "안전"하다고 봅니다 — "비밀번호를 걸었다" 수준이 아니라 구체적으로 명명된 표준에 결부된 기술적 기준입니다. 그 기준을 충족했다고 해서 자동으로 면제되는 것도 아닙니다. HIPAA Journal의 요약에 따르면, 이 면제는 "암호화된 데이터처럼 안전하게 보호된 보호대상건강정보의 유출 중, 그 암호를 풀 키를 획득당하지 않은 경우"를 가리킵니다. GDPR의 조건과 모양은 같고 표현만 다릅니다: 데이터가 암호화되었다는 사실은, 그 데이터를 손에 넣은 사람이 그것을 풀 열쇠까지 함께 손에 넣지 않았을 때에만 의미가 있습니다.

미국 주법: 실재하는 세이프하버지만, 기준이 하나로 통일되어 있지는 않다

미국 대부분 주의 유출 통지법은 어떤 형태로든 암호화된 데이터를 예외로 두지만, "암호화"의 정의가 주마다 똑같지는 않습니다. 캘리포니아 주법(민법 §1798.29, §1798.82)은 Davis Wright Tremaine의 요약에 따르면 "암호화 키를 획득했거나 획득했다고 합리적으로 믿을 만한 근거가 없는 한, 암호화된 정보에는 적용되지 않는다"고 규정합니다 — 여기서도 암호화 자체가 아니라 키 유출 여부가 결정적인 조건입니다. 다만 무엇을 "암호화"로 인정하는지에 대한 기술적 기준은 주마다 다릅니다. 매사추세츠와 로드아일랜드는 법 조문의 정의 자체에 "128비트 이상"의 암호화를 명시하고(매사추세츠 일반법 93H장 §1, 로드아일랜드 일반법 §11-49.3-3), 캘리포니아·콜로라도·메인은 구체적인 비트 수를 명시하는 대신 "일반적으로 통용되는(generally accepted)" 암호화 방식을 요구하며, 테네시는 세이프하버를 아예 "현행 버전의 연방정보처리표준(FIPS) 140-2"에 직접 결부시킵니다(테네시 주법 §47-18-2107). 각 주는 이런 조항을 계속 개정하므로, 이는 "주마다 기준이 다르다"는 것을 보여주는 사례로만 받아들여야지, 어느 한 주에 대한 현재 시점의 완전한 체크리스트로 여겨서는 안 됩니다.

이 모든 체계가 공통으로 걸어두는 조건

GDPR, HIPAA, 그리고 위의 주법들을 나란히 놓고 보면, 정확한 법조문이 무엇이든 하나의 패턴이 반복됩니다: 이 면제는 사실 "파일을 암호화했는가"에 관한 것이 아니라, "키가 유출된 대상과 분리된 채로 남아 있었는가"에 관한 것입니다. 암호를 풀 키가 적힌 포스트잇을 뚜껑에 붙인 채로 도난당한 암호화 노트북은, 통지 의무라는 관점에서는 암호화되지 않은 노트북과 사실상 다를 바 없습니다 — 공격자와 읽을 수 있는 데이터 사이를 가로막고 있어야 할 것이 애초에 사라지지 않았기 때문입니다. 그래서 세이프하버가 적용되는지 판단할 때 던져야 할 첫 질문은 "우리가 암호화했는가"가 아니라 "그 키가 결국 어디로 갔고, 데이터와 함께 이동했는가"입니다.

이 글이 아닌 것: 법률 자문도, 인증 주장도 아니다

위의 어떤 체계도 "AES-256"이라는 마케팅 문구 하나만으로 충족되지 않으며, 이 글도 특정 유출 사고를 특정 관할권에서 변호사가 구체적 사실관계를 놓고 검토하는 것을 대신할 수 없습니다. 짚어둘 구분이 하나 더 있습니다: "AES-256 알고리즘을 사용한다"와 "FIPS 140-2 검증을 받았다"는 같은 말이 아닙니다. FIPS 140-2는 이름이 붙은 특정 암호화 소프트웨어 또는 하드웨어 모듈에 대한, 심사와 목록 등재를 거친 공식 인증 절차입니다 — 어떤 도구가 어떤 알고리즘을 쓰는지에 대한 설명과는 다릅니다. 어떤 도구가 실제로 강력하고 표준적인 알고리즘을 쓰면서도 그 특정 인증 절차는 받아본 적이 없을 수 있고, 여기서 확인한 자료 중에서는 테네시 주법만이 FIPS 140-2를 이름 그대로 자기 기준으로 삼고 있습니다.

NearSeal이 여기서 하는 역할

NearSeal의 기본 형식은 브라우저 자체의 SubtleCrypto 구현을 이용해 패스프레이즈로부터 PBKDF2-SHA256을 2²⁰회 반복해 AES-256-GCM 키를 유도합니다 — 일부 주가 요구하는 "128비트 이상"이라는 기준을 훌쩍 넘고, 다른 주들이 이름으로 요구하는 "일반적으로 통용되는" 대칭 암호 알고리즘에 정확히 해당합니다. 옵션인 age-encryption.org 형식은 같은 이유로 scrypt와 ChaCha20-Poly1305를 씁니다 — 어느 쪽에도 ZipCrypto 같은 낡은 방식이 숨어 있지 않은 두 개의 서로 다른 형식입니다. NearSeal이 명확히 주장하지 않는 것은 FIPS 140-2 모듈 인증이나, NearSeal을 쓰면 특정 법률상의 통지 의무 문제가 해결된다는 것입니다 — 그건 구체적인 사실관계를 놓고 변호사가 판단할 문제입니다. NearSeal이 직접 이야기할 수 있는 것은, 위에서 살펴본 모든 체계가 실제로 판단 근거로 삼는 바로 그 조건입니다: 패스프레이즈는 사용자가 직접 입력하고, 그 자리에서 로컬로만 키 유도에 쓰이며, 기기를 벗어나거나 NearSeal이 운영하는 서버에 닿는 일이 전혀 없습니다 — 그러니 나중에 그 암호화된 파일이 있어서는 안 될 곳에 놓이더라도, 적어도 NearSeal이 관리하는 그 어떤 시스템 안에서도 키가 파일 옆에 함께 놓여 있지는 않았다는 뜻입니다. 그 패스프레이즈를 그 이후에 누구에게 알려주는지, 어디에 적어두는지는 여전히 전적으로 사용자의 몫이며, 바로 그 부분이 이 모든 세이프하버가 실제로 신경 쓰는 지점입니다.