직원 연락처, 근무 시설 주소, 부서 정보, 내부 권한 그룹 이름은 각각 따로 보면 흔한 업무 데이터처럼 보일 수 있습니다. 그러나 이 정보가 한데 모이면 조직의 인력 배치, 시설 운영, 내부 시스템 구조, 특정 업무의 담당 범위를 추정할 수 있는 운영 지도가 됩니다.
최근 보도된 미국 국토안보부 관련 데이터 유출 사례에서는 4만1,000명 이상 직원·계약직의 이메일 주소, 전화번호, 사무실 주소와 함께 내부 시스템 및 민감 업무를 암시하는 정보가 포함됐다고 전해졌습니다. 보도에 따르면 일부 권한 그룹 이름은 잠복 업무나 감시 프로그램과 연관된 것으로 보였습니다. 다만 해당 데이터가 특정 인증 서비스에서 유출됐다는 주장에 대해서는 해당 서비스 제공사가 자사 시스템 침해 증거를 확인하지 못했다고 밝혔습니다.
공공기관과 공공사업 운영 조직이 여기서 봐야 할 문제는 특정 제품의 침해 여부가 아닙니다. 직원, 시설, 업무 권한 정보가 외부 SaaS와 AI에 연결될 때 무엇을 함께 보여 주고, 무엇을 서로 분리할지 미리 정하지 않으면 데이터 조합 자체가 위험해진다는 점입니다.
실패는 “한 번에 많이 공개된 것”보다 연결 관계에서 시작된다
대규모 노출 사고는 흔히 계정 탈취나 저장소 공개처럼 보이는 한 사건으로 설명됩니다. 하지만 피해가 커지는 과정은 그보다 앞서 진행됩니다. 업무 편의를 위해 여러 시스템이 직원 식별자, 조직도, 시설 목록, 역할명, 권한 그룹, 티켓 기록을 같은 키로 연결하면서입니다.
예를 들어 외부 협업 도구나 AI 요약 서비스에 직원 이름과 부서, 업무 요청 내용을 보낼 수 있습니다. 여기에 시설 코드, 당직 정보, 시스템 역할, 특수 프로젝트 명칭까지 같은 화면이나 같은 API 응답에 담기면, 개별 필드는 낮은 민감도로 분류됐더라도 결합된 결과는 다르게 평가해야 합니다.
특히 다음 조합은 별도 통제가 필요합니다.
- 개인 연락처 또는 조직 이메일과 상세 부서·직무 정보의 결합
- 시설 위치와 근무자 목록, 출입·당직·장애 대응 역할의 결합
- 권한 그룹 이름과 실제 구성원, 연동 시스템 목록의 결합
- 민감 업무를 암시하는 프로젝트명, 티켓 제목, 채널명과 담당자 정보의 결합
- 계약직·협력사 계정 정보와 내부 시스템 접근 범위의 결합
여기서 중요한 기준은 정보가 개인정보인지 아닌지만이 아닙니다. 그 정보가 다른 데이터와 합쳐졌을 때 특정 인력, 장소, 업무 흐름 또는 통제 수단을 얼마나 구체적으로 드러내는지도 함께 판단해야 합니다.
외부 시스템에는 세 종류의 정보를 다르게 보내야 한다
CTO, 개발 리드, 보안 책임자가 외부 SaaS나 생성형 AI 연동을 검토할 때는 데이터를 “허용”과 “금지” 두 칸으로만 나누기보다 세 층으로 분류하는 편이 낫습니다.
1. 원칙적으로 외부 전송을 차단할 정보
개인과 시설, 민감 업무를 직접 연결하는 정보는 기본값을 차단으로 두는 편이 안전합니다. 잠복·조사·보호·보안 대응처럼 공개 자체가 사람의 안전이나 업무 연속성에 영향을 줄 수 있는 역할 정보도 여기에 포함해 검토해야 합니다.
대표적으로는 개인 전화번호, 상세 근무지, 내부 역할 그룹의 실제 명칭, 특수 업무 대상자 명단, 내부 시스템 구조를 설명하는 설정값이나 로그 원문이 해당할 수 있습니다. AI 프롬프트, 문서 검색 연동, 고객지원 티켓, 외부 분석 도구에 이 정보가 섞여 들어가지 않는지 확인해야 합니다.
차단은 기능을 포기하자는 뜻이 아닙니다. 개인 식별자를 내부 난수 ID로 바꾸고, 상세 시설명을 권역 수준으로 낮추며, 역할 그룹명은 업무 목적에 맞는 일반 분류로 치환할 수 있는지 먼저 검토하자는 뜻입니다.
2. 조건을 붙여 승인할 정보
조직의 일반 부서명, 공개 가능한 대표 연락처, 비민감 업무 문서, 표준 운영 절차처럼 업무상 외부 처리 가치가 있는 정보는 조건부로 승인할 수 있습니다. 다만 승인 조건은 “해당 SaaS가 안전한가”라는 포괄적 질문으로 끝나면 안 됩니다.
승인 문서에는 최소한 다음을 적어 두는 편이 좋습니다.
- 어떤 업무 목적에서 데이터를 보내는가
- 어떤 필드가 전송되며, 어떤 필드는 제거·치환하는가
- 외부 시스템이 데이터를 보관하는지, 보관한다면 누가 삭제를 요청할 수 있는가
- 외부 시스템 안에서 관리자가 볼 수 있는 범위는 어디까지인가
- AI 기능이 답변 생성 외에 검색, 학습, 품질 검토, 로그 분석에 데이터를 쓰는지
- 연동 계정이 읽기만 하는지, 수정·다운로드·재공유도 가능한지
조건부 승인은 한 번의 도입 승인으로 끝나지 않습니다. 데이터 필드나 연동 범위가 바뀔 때마다 다시 확인해야 합니다. 특히 AI 도구는 처음에는 문서 요약만 하다가 이후 검색 연동, 에이전트 실행, 업무 자동화 기능을 추가할 수 있으므로 기능 확대를 별도 변경으로 다뤄야 합니다.
3. 내부 승인자가 있어야만 열 수 있는 접근
사고 대응, 보안 조사, 인사 조치, 중요 인프라 운영처럼 민감도가 높은 업무는 자동 연동보다 사람의 승인을 남기는 접근이 적합합니다. 누군가 “긴급”이라고 표시했다고 곧바로 전체 자료를 외부 도구에 넘기는 흐름은 피해야 합니다.
이 영역에서는 요청자, 승인자, 열람 사유, 열람 대상, 유효 기간을 구분해 기록하는 방식을 검토할 수 있습니다. 승인자가 데이터 내용을 모두 읽어야 한다는 뜻은 아닙니다. 적어도 누가 어떤 목적에서 어느 범위에 접근했는지는 사후에 재구성할 수 있어야 합니다.
NIST의 제로 트러스트 아키텍처는 네트워크 위치나 자산 소유만으로 신뢰를 부여하지 않고, 기업 자원에 연결하기 전에 주체와 기기를 인증하고 권한을 확인하는 원칙을 제시합니다. 외부 SaaS와 AI 연동에도 같은 질문을 적용할 수 있습니다. “사내 계정인가”가 아니라 “이 사용자가 이 기기에서 지금 이 데이터와 이 기능에 접근해도 되는가”를 확인해야 합니다.
조기 신호는 권한 오류보다 ‘설명할 수 없는 연결’에서 나타난다
대형 사고 전에는 권한이 완전히 무너졌다는 경보보다, 데이터와 책임의 연결이 불명확해지는 신호가 먼저 보일 수 있습니다.
첫째, 같은 직원 정보가 인사, 협업, 티켓, 자산, 출입, AI 도구에 반복 저장되는데 어느 시스템이 기준 데이터인지 답하기 어렵습니다. 이 상태에서는 한 시스템에서 삭제하거나 권한을 회수해도 다른 시스템에 남은 복제본을 놓칠 수 있습니다.
둘째, 권한 그룹 이름만 보고도 민감 업무나 시스템 목적을 짐작할 수 있는데, 그 그룹이 외부 연동 목록이나 로그에 그대로 노출됩니다. 그룹명은 관리 편의를 위한 라벨이지만, 조직 구조를 설명하는 메타데이터가 될 수 있습니다.
셋째, 외부 도구의 관리자나 지원 인력이 어떤 데이터를 볼 수 있는지 운영팀이 명확히 답하지 못합니다. 계약서에 보안 조항이 있어도 실제 관리자 콘솔, 감사 로그, 데이터 내보내기 기능의 범위를 확인하지 않으면 접근 경계는 흐려집니다.
넷째, 퇴직자·전보자·계약 종료 인력의 계정은 회수했지만 연결된 API 토큰, 서비스 계정, 공유 링크, 검색 인덱스 권한은 누가 확인하는지 정해져 있지 않습니다. 사람 계정 하나를 끄는 일과 데이터 경로를 끊는 일은 다릅니다.
사고가 의심될 때는 공개 판단보다 범위 확정 순서를 먼저 정한다
외부 시스템과 연동된 데이터 사고에서는 “누가 침해했는가”를 즉시 확정하기 어려울 수 있습니다. 특정 인증 서비스나 SaaS가 원인이라는 주장과, 그 서비스 제공사의 조사 결과가 엇갈릴 수도 있습니다. 이때 조직은 원인 추정만 붙잡기보다 노출 가능 범위를 줄이는 조치를 먼저 정해 두는 편이 낫습니다.
사고 대응 순서는 다음처럼 역할별로 나눌 수 있습니다.
-
운영 책임자는 외부 연동, 공유 링크, API 토큰, 대량 내보내기 권한 중 즉시 중지할 대상을 결정합니다. 전체 서비스를 멈출지, 민감 데이터 경로만 끊을지도 이 단계에서 구분합니다.
-
보안팀과 개발팀은 어떤 데이터 필드가 어느 시스템으로 전달됐는지 확인합니다. 직원 연락처만 포함됐는지, 시설 정보·역할 정보·권한 정보가 함께 있었는지를 따로 봐야 합니다.
-
업무 소관 부서는 노출된 조합이 사람의 안전, 시설 운영, 조사·감사 업무, 대민 서비스에 어떤 영향을 줄 수 있는지 판단합니다. 기술팀만으로 민감도를 확정하기 어려운 이유가 여기에 있습니다.
-
대외 대응 책임자와 법무·개인정보 담당자는 확인된 사실, 아직 확인되지 않은 사항, 대상자 보호 조치를 구분해 대응합니다. 원인이 확정되지 않았더라도 접근 차단, 비밀번호·토큰 교체, 대상자 안내처럼 바로 실행할 조치는 있을 수 있습니다.
이 순서의 핵심은 조사와 조치를 경쟁시키지 않는 데 있습니다. 사실 확인이 진행되는 동안에도 민감한 연결 경로는 줄일 수 있어야 합니다.
다음 보안 검토 회의에서 먼저 물어볼 질문
외부 SaaS나 AI를 이미 운영 중인 조직이라면, 새로운 제품을 더 도입하기 전에 현재 연결부터 한 장의 목록으로 정리하는 것이 출발점입니다. 목록에는 제품명보다 데이터 항목, 접근 주체, 권한 수준, 승인자, 종료 방법을 적는 편이 유용합니다.
회의에서는 다음 질문부터 답해 보십시오.
- 이 연동에서 개인 식별자와 시설·업무·권한 정보가 같은 요청 또는 같은 화면에 함께 나타나는가?
- 외부 시스템으로 보내지 않아도 기능을 유지할 수 있는 필드는 무엇인가?
- 역할 그룹명, 프로젝트명, 티켓 제목처럼 업무 구조를 드러내는 메타데이터를 일반화하거나 분리할 수 있는가?
- 외부 관리자, 협력사, 서비스 계정이 읽을 수 있는 데이터와 내려받을 수 있는 데이터는 같은가?
- 사고가 의심될 때 누가 어떤 연동을 먼저 끄고, 누가 영향 범위를 판정하며, 누가 대상자 보호 조치를 결정하는가?
이 다섯 질문에 시스템별로 답이 나오지 않는다면, 그 연동은 아직 기능 연결만 됐을 뿐 책임 경계까지 설계된 상태는 아닙니다. 다음 분기 보안 과제는 새 솔루션 도입보다, 가장 민감한 데이터 조합 하나를 골라 외부 전송 경로와 승인 절차를 다시 그리는 일에서 시작할 수 있습니다.
