계좌번호를 본 다음

한 줄 요약

조사에 필요해서 본 것과 보고서에 남겨도 되는 것은 다르고, 필요하지 않은 개인정보를 문서에 남기는 것 자체가 사고다.

왜 이게 필요했나

은행 데이터를 조회하면 개인정보가 눈에 들어옵니다. 계좌번호, 이름, 주민등록번호, 전화번호, 거래 내역. 조사에는 그게 필요합니다 — 특정 고객의 이체 한 건을 추적하려면 그 계좌를 봐야 합니다.

문제는 그다음입니다. 조사가 끝나고 보고서를 쓸 때, 조회 화면에 있던 값을 그대로 옮겨 붙이는 순간 그 문서는 개인정보를 담은 문서가 됩니다. 그 문서는 메일로 오가고, 슬랙에 붙고, 위키에 올라가고, 몇 년 뒤에도 검색됩니다. 원본 데이터베이스에는 접근 통제와 로그가 걸려 있지만 우리가 만든 문서에는 아무것도 걸려 있지 않습니다.

어떻게 동작하나

기준은 하나입니다. 이 문서의 독자가 이 값을 알아야 하는가.

전문 번호 MSG-20260825-0104   필요하다. 고객사가 그 건을 다시 찾아야 한다.계좌번호 110-4378-567278      전체는 필요 없다. 뒤 4자리면 대조가 된다.고객 이름 정하윤              필요 없다. 전문 번호로 특정된다.주민등록번호 711455-2930474   어떤 경우에도 필요 없다.

계좌번호를 마스킹할 때 뒤 4자리를 남기는 것은 인심이 아니라 대조 가능성 때문입니다. 고객사 담당자가 자기 시스템에서 그 건을 찾아 우리 보고서와 맞춰 봐야 하는데, 전부 가려 버리면 그게 안 됩니다. 필요한 최소한을 남기고 나머지를 가리는 것이 마스킹입니다.

110-4378-567278  →  110-****-**7278

주민등록번호는 다릅니다. 뒷자리를 가려도 앞 6자리가 생년월일이고, 뒷자리 첫 숫자는 성별과 출생 세기입니다. 즉 앞 6자리만으로도 상당한 식별력이 있습니다. 그래서 마스킹해서 적는 것이 아니라 아예 적지 않습니다. 조사에 주민등록번호가 필요했다면 그 사실만 적고 값은 남기지 않습니다.

현장에서 만나는 모습

첫째, 스크린샷이 가장 흔한 유출 경로입니다. 조회 화면을 캡처해서 붙이면 우리가 보려던 한 칸만 나오는 게 아니라 그 화면의 모든 칸이 함께 나옵니다. 은행 현장에서 화면 촬영과 캡처를 막는 이유가 이것입니다. 표를 옮겨야 한다면 필요한 열만 골라 텍스트로 다시 쓰는 것이 원칙입니다.

둘째, 중간 산출물도 문서입니다. 조사하면서 만든 CSV, 임시 SQL 결과, 붙여 넣은 슬랙 메시지가 전부 같은 기준을 받습니다. "정식 보고서만 조심하면 된다" 는 생각이 사고를 만듭니다. 실제로 유출은 정식 보고서보다 중간 산출물에서 훨씬 자주 납니다.

셋째, 가렸다고 끝이 아니라 가렸다는 사실을 적어야 합니다. 보고서에 마스킹된 값만 있으면 읽는 사람은 "원본을 못 본 건가" 와 "보고 가린 건가" 를 구별할 수 없습니다. 개인정보 취급을 한 절로 따로 두고 무엇을 어떻게 가렸는지, 왜 뒤 4자리를 남겼는지를 적으면 그 문서 자체가 절차를 지켰다는 증거가 됩니다.

넷째, 조회한 사실 자체가 기록에 남습니다. 우리가 어떤 계좌를 조회했는지는 고객사 접근 로그에 남고, 나중에 감사에서 "왜 이 계좌를 봤는가" 를 묻습니다. 그때 답할 근거는 우리가 쓴 조사 기록뿐입니다. 그래서 조회 범위를 필요한 만큼으로 좁히고, 왜 그 범위가 필요했는지를 적어 두는 것이 자기 보호이기도 합니다.

다음 퀴즈에서 확인할 것

마스킹의 기준, 주민등록번호를 마스킹조차 하지 않는 이유, 중간 산출물의 취급, 그리고 망분리 환경에서 조사를 어떤 방향으로 설계해야 하는지를 확인합니다.