프로덕트 노트
개인정보를 두는 곳
로그인 문제를 조사하다가 볼 필요가 없는 개인정보까지 보게 되는 일. 이 설계는 운영 현장에서 느끼던 그 불편함에서 시작되었습니다.
문제를 조사하다 보면 신원 정보까지 보입니다
인증 기반을 운영하다 보면 “특정 사용자가 로그인할 수 없습니다”라는 문의를 받습니다. 원인을 찾으려면 고객 환경에 들어가 해당 계정을 찾아야 합니다.
필요한 정보는 구체적입니다. 계정이 잠겼는지, 마지막 시도가 언제 어느 단계에서 실패했는지, 어떤 경로로 로그인했는지, 패스키 등록이 유효한지 확인하면 됩니다.
이 정보를 확인하는 데 그 사람이 누구인지 알 필요는 없습니다. 그런데 계정을 열면 이름, 이메일 주소, 전화번호, 연결된 계정이 한 화면에 나옵니다. 상태를 보려 했는데 신원까지 함께 보입니다.
이미 화면에 표시되는 정보라면
“보지 마세요”라는 지침만으로는 막을 수 없습니다.
누군가 절차를 어긴 것도 아닙니다. 고객이 요청했고, 정해진 절차대로 조사했습니다. 그래도 정보가 보입니다. 시스템 구조가 그렇게 되어 있기 때문입니다.
규칙과 교육만으로 해결하면 담당자의 기억과 주의에 의존하게 됩니다. Authrim이 개인정보를 별도 데이터베이스에 두는 이유는 이 문제를 구조적으로 해결하기 위해서입니다.
처음부터 나눈 두 데이터베이스
개인을 직접 식별하는 정보는 물리적으로 분리된 데이터베이스에 저장합니다. 나중에 덧붙인 구분이 아니라 데이터 접근 계층부터 분리되어 있습니다.
이렇게 나누면 첫 번째 문제를 해결할 수 있습니다. 잠금 상태, 인증 실패, 기기 정보는 왼쪽만으로 확인할 수 있습니다. 오른쪽에 접근할 권한 없이 조사 권한을 부여하므로 담당자가 일부러 눈을 돌릴 필요가 없습니다.
같은 구조는 감사 대응에도 도움이 됩니다. 이름과 이메일이 어디에 있는지, 삭제할 범위가 어디까지인지 설명할 수 있습니다. 운영 문제를 해결한 구조가 설명도 쉽게 만든 것입니다.
개인정보가 PII DB에만 있다는 뜻은 아닙니다
분명히 해야 할 점이 있습니다. 이 분리는 개인정보와 비개인정보를 구분하는 법적 경계가 아닙니다.
Core DB에도 IP 주소, 기기 정보, 세션 이력, 인증 이벤트, 자격 증명 메타데이터, 안정적인 내부 사용자 ID가 들어갑니다. 상황에 따라 이 정보도 개인정보에 해당합니다. 다른 정보와 결합하면 개인을 식별할 수 있기 때문입니다.
Authrim이 구분하는 것은 직접 식별 정보와 운영에 필요한 신원 데이터입니다. 후자만으로 조사할 수 있게 하려는 것이지, 후자를 보호하지 않아도 된다는 뜻이 아닙니다.
따라서 “개인정보는 PII DB에만 있다”는 설명은 정확하지 않습니다. 이름과 이메일 같은 직접 식별 정보를 PII DB에 격리하여, 그 저장소에 접근하지 않고 조사 권한을 부여할 수 있다는 의미입니다.
삭제는 첫 단계일 뿐입니다
계정을 삭제하는 작업 자체는 간단합니다. 그 뒤에 따르는 두 가지 요구가 더 어렵습니다.
하나는 삭제했다는 증명입니다. 언제, 누가, 왜 삭제했는지 나중에도 확인해야 합니다. 다른 하나는 일정 기간 재가입을 막는 것입니다.
두 요구 모두 이미 삭제한 사람을 다시 알아보아야 한다는 모순이 있습니다. 직접 식별 정보를 남기면 삭제의 취지와 충돌합니다.
구현의 원칙도 같습니다. 중복 방지에 필요한 지문만 남기고, 보관 기한이 지나면 삭제합니다. 삭제 시각, 실행자, 이유도 기록합니다.
“복원 불가”가 성립하는 조건
기술적으로 한 가지 덧붙이면, 이메일 주소는 엔트로피가 낮습니다. 단순 해시만 사용하면 사전 공격으로 주소를 찾을 수 있습니다. 복원 불가는 무조건적인 보장이 아닙니다.
Authrim은 비밀 키를 사용하는 HMAC-SHA256 블라인드 인덱스에 키 세대 번호를 기록하여 키 교체를 지원합니다. 키가 없으면 후보 주소의 지문을 다시 계산해 대조할 수 없습니다.
따라서 키의 격리가 이 보호의 전제입니다. 키와 지문을 함께 두면 이 보장은 사라집니다.
조사에 필요한 정보만 볼 수 있도록
로그인 실패 문의로 돌아가 봅시다. 담당자가 알아야 할 것은 인증이 어디서 멈췄는지입니다. 대개 이름이나 전화번호까지 열 필요는 없습니다.
Authrim은 직접 식별 정보를 분리하여 해당 저장소 접근 없이 진단 권한을 줄 수 있도록 합니다. 개인정보가 꼭 필요한 조사에서는 추가 권한을 가진 담당자가 처리합니다.
암호화와 접근 제어로 데이터를 보호하고 감사 로그로 사용을 확인합니다. 그와 함께 담당자가 불필요한 개인정보를 열지 않고 일상적인 조사를 마칠 수 있어야 합니다. 저장소 분리는 이를 매일의 운영에서 출발점으로 삼기 위한 설계입니다.
구현: 저장소와 접근 경계 분리 완료.
검증: 소스 저장소의 자동화 테스트로 지속 확인.
운영 성숙도: 강화 작업 진행 중. Authrim은 pre-1.0 단계입니다.
이 설계는 삭제 절차를 쉽게 해 주지만, 그 자체로 법규 준수를 보장하지는 않습니다. 실제 적합성은 조직의 절차와 계약에도 달려 있습니다.