GDPR 테스트 데이터라는 말은 개발과 시험 단계에서 개인정보를 어떻게 다루어야 하는지를 묻는 자리에서 자주 나옵니다. 이름과 신원 번호, 생년월일, 주소, 전화번호는 모두 개인을 알아볼 수 있게 하는 정보이고, 운영 환경에 있던 값을 그대로 시험 환경으로 옮기면 그 순간 같은 정보가 두 곳에 생깁니다. 이 글에서는 무엇이 위험한지, 어떤 원칙을 지켜야 하는지, 그리고 마스킹이 왜 만능이 아닌지 살펴봅니다.
어떤 값이 개인정보에 해당하나요?
이름, 신원 번호, 생년월일, 주소, 전화번호, 이메일 주소는 사람을 알아볼 수 있게 하는 값입니다. 하나만으로는 특정되지 않더라도 여러 개가 함께 있으면 특정될 수 있습니다. 그래서 어떤 항목을 지워야 안전한지 항목 하나씩 따로 판단하면 답을 놓칩니다.
값 자체뿐 아니라 그 값이 언제 어디서 만들어졌는지도 함께 봐야 합니다. 운영 환경에서 내려받은 자료에는 값과 함께 시각과 식별자가 붙어 있고, 이 조합이 다시 사람을 가리킵니다. 시험 환경에 필요한 것은 분포와 형식이지 실제 사람의 기록이 아닙니다.
항목 이름만 보고 판단하기 어려운 값도 있습니다. 상담 메모에는 이름이 없어도 사람을 알아볼 단서가 들어 있을 수 있고, 고객 번호처럼 식별자로만 보이는 값도 다른 자료와 붙으면 특정으로 이어집니다. 시험 자료를 정리할 때는 항목 목록만 훑지 말고 어떤 값이 함께 놓이는지를 봐야 합니다.
운영 데이터를 그대로 복사하면 무엇이 문제인가요?
가장 흔한 경로는 운영 데이터베이스를 시험 서버로 복제하는 일입니다. 편하고 빠르고 실제와 똑같이 동작한다는 점 때문에 반복해서 선택됩니다. 대신 같은 개인정보가 두 곳에 존재하게 되고, 시험 서버는 보통 접근 통제가 느슨합니다.
문제는 시험 환경의 사고가 알려지지 않는다는 점입니다. 로그에 값이 찍히고, 화면 캡처가 문서에 첨부되고, 개발자 노트북에 내려받은 파일이 남습니다. 원래 목적과 다른 사용이 이렇게 조용히 쌓입니다.
왜 시험 환경에서는 실제 데이터가 필요 없나요?
시험에서 확인하려는 것은 어떤 값이 통과하고 어떤 값이 거절되는지, 화면이 어떻게 보이는지, 저장이 어떻게 되는지입니다. 이 목적에는 형식과 분포만 있으면 충분하고, 실제 사람의 이름이나 번호가 있어야만 가능한 검사는 거의 없습니다.
오히려 실제 값은 시험을 흐립니다. 값 자체가 익숙해서 검사가 통과한 건지 로직이 맞아서 통과한 건지 구분되지 않습니다. 합성한 값과 경계값을 쓰면 무엇을 확인했는지 분명해집니다.
시험에 실제 값을 쓰면 시나리오를 좁히기도 어렵습니다. 경계값을 만들려면 값을 고쳐야 하는데, 실제 값은 고치는 순간 원본과 달라지고 다시 원본을 불러와야 합니다. 합성한 값은 처음부터 원하는 조건으로 만들 수 있습니다.
마스킹만 하면 안전해지나요?
이름을 지우고 번호 일부를 가리는 처리는 위험을 낮추지만 사라지게 하지는 않습니다. 남은 조각들이 서로를 설명하기 때문입니다. 생년월일과 우편번호와 성별이 함께 남아 있으면 그 조합만으로 한 사람이 특정될 수 있습니다.
가린 부분을 되돌릴 수 있는 상태라면 그것은 익명화가 아니라 가명 처리입니다. 원래 값으로 되돌릴 수 있다면 그 자료는 여전히 개인정보로 다뤄야 합니다. 이름을 지웠다는 사실만으로 안전하다고 결론 내리면 안 됩니다.
어떤 부분을 가렸고 어떤 부분을 남겼는지도 기록해 두어야 합니다. 가린 값과 남긴 값을 구분하지 못하면 그 자료가 개인정보인지 판단할 수 없고, 정리 대상에서 빠지기 쉽습니다.
신원 생성기로 실제 데이터를 대신하기
신원 생성기에서 만든 기록은 처음부터 합성한 값이라 되돌릴 원본이 없습니다. 국가와 성별을 고르고 필요한 개수만큼 만들면 되므로, 운영 데이터를 복제할 이유 자체가 줄어듭니다. 시험에 필요한 지역이나 나이대를 지정해 뽑을 수 있다는 점도 실제 자료를 쓰지 않게 하는 데 도움이 됩니다.
여기서 만들어지는 값은 테스트 전용이며 실존 인물과 무관합니다. 실제 인물을 사칭하거나 본인 확인을 통과하는 데 사용해서는 안 됩니다.
시험 환경에도 지켜야 할 기준이 있나요?
환경이 다르다고 원칙이 사라지지는 않습니다. 목적을 좁히고 필요한 만큼만 모으고, 쓸 이유가 없어지면 지우는 흐름은 시험 환경에서도 같습니다. 시험이라는 이유로 예외를 두기 시작하면 어떤 자료가 어디에 있는지 아무도 모르게 됩니다.
접근 권한도 같은 관점에서 봐야 합니다. 운영 환경보다 시험 환경이 더 많은 사람에게 열려 있는 경우가 많으므로, 여기에 실제 개인정보를 두면 노출 범위가 오히려 넓어집니다. 필요한 사람에게 필요한 범위만 열어 두는 편이 안전합니다.
개발자를 위한 메모: 환경을 분리하고 최소한만 남겨라
- 시험 환경에는 운영 개인정보를 넣지 않는다는 규칙을 저장소 수준에서 정합니다. 예외는 문서로 남기고 기한을 둡니다.
- 목적을 좁힙니다. 왜 이 값이 필요한지, 언제까지 두는지 적어 두면 남은 자료를 정리할 기준이 생깁니다.
- 최소화를 기본값으로 삼습니다. 필요하지 않은 항목은 만들지도, 받지도 않습니다.
- 가명 처리와 익명화를 구분해 문서에 적습니다. 되돌릴 수 있는지 여부가 두 경우를 가릅니다.
- 로그와 화면 캡처를 개인정보가 새는 경로로 취급합니다. 요청 본문을 통째로 남기는 로그는 시험 환경에서도 같은 위험을 만듭니다.
- 정확성과 보관 기간을 함께 봅니다. 오래된 시험 자료는 더 이상 맞지 않을뿐더러 남길 이유도 없습니다.
- 시험 환경의 자료 목록을 유지합니다. 어디에 무엇이 있는지 모르면 지울 대상도 정할 수 없습니다.
- 개인정보가 들어올 수 있는 새 경로를 배포 전에 확인합니다. 로그, 화면 캡처, 내려받기 파일이 대표적인 경로입니다.
- 이 글은 일반적인 원칙을 정리한 것이며 특정 법령의 해석이나 준수를 보장하지 않습니다. 실제 판단은 조직의 담당자와 확인해야 합니다.
다음 단계
시험 환경에서 실제 개인정보를 걷어내기로 했다면 신원 생성기에서 필요한 형태의 기록을 미리 만들어 두고, 그 기록으로 시나리오를 다시 구성해 보세요. 합성과 익명화, 가명 처리가 어떻게 다른지는 합성 데이터와 익명화의 차이에서 이어서 정리했습니다.