調査中に診断コードを見てしまったとき

한 줄 요약

보험 데이터에는 건강 정보가 들어 있고, 그것은 일반 개인정보보다 강한 규제를 받는 민감정보라, 조사에서 보는 것과 문서로 옮기는 것은 완전히 다른 행위다.

왜 이게 필요했나

청구 테이블을 조회합니다. 지급 지연을 조사하려고 소요 시간을 재는 중인데, 화면에 이런 열이 함께 뜹니다.

claim_no  policy_no  accident_date  diagnosis_code  claimed_amount
C0034     P0034      2026-04-05     C34.9           5000000

C34.9 는 KCD 코드입니다. 폐의 악성 신생물, 즉 폐암입니다. 우리가 보려던 것은 소요 시간인데, 그 열 옆에 이 사람이 무슨 병을 앓는지가 같이 있습니다.

여기서 무심코 하는 행동 하나가 사고가 됩니다. 화면을 캡처해서 사내 메신저에 붙이는 것입니다. 원인을 설명하려고 표를 통째로 옮기는 것도 같습니다. 그 순간 폐암 환자 한 명의 진단 정보가 고객사 시스템 밖으로 나갑니다.

어떻게 동작하나

개인정보에는 등급이 있습니다.

일반 개인정보   이름, 연락처, 주소 같은 것
민감정보        건강, 유전, 사상·신념, 노동조합 가입, 성생활, 범죄경력, 생체인식
고유식별정보    주민등록번호, 여권번호, 운전면허번호, 외국인등록번호

건강 정보는 민감정보입니다. 개인정보보호법은 민감정보를 별도로 다루고, 일반 개인정보와 묶어서 받은 동의로는 처리할 수 없습니다. 별도 동의를 받았거나 법령에 근거가 있어야 합니다. 보험사는 그 근거를 갖고 있지만, 그 근거는 보험사의 것이지 우리 것이 아닙니다.

그래서 현장에서 지킬 선이 명확합니다.

조사에 필요해서 화면으로 보는 것        업무 범위 안. 접근 로그가 남는다
결과를 문서·메신저·이메일로 옮기는 것   반출. 별개의 판단이 필요하다

두 번째가 문제입니다. 첫 번째는 대개 통제 아래 있고 로그도 남는데, 두 번째는 아무 저항 없이 일어납니다. 슬랙에 붙인 쿼리 결과 한 줄, 보고서에 넣은 스크린샷 한 장, 디버깅하려고 로컬에 내려받은 CSV 한 개.

그래서 고객사가 로그 반출을 막는 것입니다. 처음 겪으면 "일을 못 하게 한다" 고 느끼지만, 보험사 애플리케이션 로그에는 청구 처리 과정에서 진단 코드와 피보험자 식별자가 섞여 들어가는 경우가 많습니다. 로그 파일 하나가 민감정보 파일입니다. 반출 금지는 방해가 아니라 그쪽이 정상입니다.

보고서를 쓸 때 지킬 규칙은 셋입니다.

사람이 아니라 건으로 지목한다   청구번호·계약번호로 말한다. 이름·식별자는 쓰지 않는다
진단은 쓰지 않는다              사유 코드까지가 한계다. 병명·KCD 코드는 옮기지 않는다
무엇을 안 담았는지 밝힌다        읽는 사람이 조사 범위를 알 수 있어야 한다

세 번째가 낯설 텐데, 이것이 실제로 신뢰를 만듭니다. "진단 정보는 조회했으나 보고서에는 담지 않았습니다" 라는 한 줄이 있으면 고객사 보안 담당자는 우리가 무엇을 알고 무엇을 남겼는지 알 수 있습니다. 그 문장이 없으면 그 사람은 우리가 무엇을 들고 나갔는지 추측해야 합니다.

가명처리와 익명처리도 구분해 둡니다. 가명처리는 다른 정보와 합치면 다시 개인을 알아볼 수 있는 상태라 여전히 개인정보입니다. 익명처리는 복원할 수 없는 상태입니다. "번호로 바꿨으니 괜찮다" 는 대개 가명처리이고, 가명처리된 데이터도 반출에는 절차가 필요합니다.

현장에서 만나는 모습

첫째, 디버깅용 덤프가 가장 흔한 사고 경로입니다. 재현이 안 돼서 운영 데이터 일부를 받아 로컬에서 돌려 보는 것. 악의도 없고 일하려는 것이지만, 그 파일이 노트북에 남고 백업으로 클라우드에 올라갑니다. 재현이 필요하면 고객사 환경 안에서 하거나, 값을 지우고 구조만 받는 방식으로 협의해야 합니다.

둘째, AI 도구에 붙여 넣는 것이 최근 몇 년 사이 새 경로가 됐습니다. 오류 메시지를 붙여 넣었는데 스택 트레이스에 청구 데이터가 들어 있는 경우가 실제로 있습니다. 붙여 넣기 전에 무엇이 들어 있는지 보는 습관이 필요합니다.

셋째, 접근 권한을 받을 때 최소 범위를 요청하는 것이 나중에 자신을 지킵니다. 진단 코드가 있는 테이블에 읽기 권한이 없으면 실수로 볼 일도, 옮길 일도 없습니다. 편의를 위해 넓은 권한을 받아 두면 사고가 났을 때 그 권한이 곧 혐의 범위가 됩니다.

민감정보를 다루는 화면과 질의를 설계할 때

보험 도메인에서 개발자는 병력·진단명·수익자 관계를 보게 된다. 이것은 일반 개인정보보다 한 단계 위이므로, 볼 수 있는 것과 볼 수 없는 것을 코드가 아니라 설계에서 가른다.

화면은 기본이 마스킹이다. 필요한 사람이 필요할 때 펼쳐 보게 하고, 펼친 행위 자체를 기록한다. "누가 무엇을 언제 조회했는가" 가 남지 않으면 사고가 나도 범위를 좁힐 수 없다.

조회 로그는 데이터와 같은 등급으로 지킨다. 조회 기록에 환자 식별자와 진단 코드가 들어가므로, 그 로그가 새면 원본이 샌 것과 다르지 않다.

분석계로 내보낼 때는 목적을 먼저 적는다. 통계를 내는 데 주민등록번호가 필요한 경우는 거의 없다. 나이대·성별·지역으로 충분하고, 연결이 필요하면 되돌릴 수 없는 가명 식별자를 쓴다. 같은 식별자를 여러 데이터셋에서 쓰면 합쳐서 재식별되므로, 데이터셋마다 다른 값으로 만든다.

개발계에는 운영 데이터를 복사하지 않는다. "잠깐만" 이 몇 달 남고, 개발계는 운영보다 통제가 약하다. 필요한 것은 대개 모양이 같은 데이터이므로 합성 데이터를 만든다. 진짜가 꼭 필요하다면 최소 건수만, 기한을 정해, 별도 승인으로.

질의 결과가 화면 밖으로 나가는 경로를 막는다. 엑셀 내려받기, 관리자 도구의 원시 질의, 메신저 붙여넣기가 실제 유출 경로다. 대량 조회에는 건수 상한을 두고, 넘으면 승인을 받게 한다.

보관 기간을 데이터마다 정한다. 계약 관련 서류는 법정 보존 기간이 있고, 조회 로그는 그보다 짧을 수 있다. 정하지 않으면 전부 영원히 남고, 그것이 가장 큰 위험이다.

다음 퀴즈에서 확인할 것

민감정보가 무엇인지, 조회와 반출이 왜 다른 판단인지, 보고서에서 사람을 어떻게 지목해야 하는지, 그리고 가명처리가 왜 안전을 뜻하지 않는지를 확인합니다.