도입
사내에 생성형 AI 챗봇이 들어오면 가장 자주 생기는 일은 직원이 업무를 빨리 끝내려고 고객 명단, 상담 기록, 소스코드를 그대로 붙여 넣는 것입니다. 요약만 시키려는 의도였더라도 입력된 텍스트는 모델이 호스팅된 곳으로 전송되고, 대화 로그로 남을 수 있습니다. 보안 담당자는 사고가 난 뒤에야 알게 되는 경우가 많습니다.
이 글에서는 입력 단계에서 마스킹과 차단 규칙을 어떻게 설계할지, 대화 로그의 보관 기간과 접근 권한을 ISMS-P 관점에서 어떻게 점검할지 순서대로 정리합니다. 특정 제품을 추천하지 않고, 개발자와 보안 담당자가 지금 쓰는 환경에 바로 대입해 볼 수 있는 기준과 질문에 집중합니다.
직원이 AI에 붙여 넣는 흐름
점검은 실제로 어떤 데이터가 어디를 거쳐 가는지 그리는 데서 시작합니다. 흐름은 보통 입력창, 전처리, 모델 호출, 응답 저장, 로그 적재, 관리자 조회의 여섯 단계로 나뉩니다. 각 단계에서 원문이 남는지, 복제되는지, 누가 볼 수 있는지를 표시해 보세요.
가상의 사례: 개발팀 직원이 장애 원인을 찾으려고 운영 DB 접속 설정이 들어 있는 설정 파일 전체를 붙여 넣었습니다. 입력 단계에는 검사가 없었고, 프롬프트는 외부 API로 전송되어 대화 기록에 접속 정보가 그대로 남았습니다. 로그 조회 권한은 개발팀 전원에게 열려 있었습니다.
이 사례에서 문제는 한 사람의 실수 하나가 아니었습니다. 입력을 막는 장치가 없었고, 저장된 기록을 볼 사람이 너무 많았습니다. 그래서 점검은 직원 교육보다 먼저 경로와 권한을 확인하는 쪽이 효과적입니다.
입력 단계에서 막는 법
마스킹은 무엇을 가릴지부터 정하기
마스킹은 주민등록번호, 휴대전화번호, 이메일, 계좌번호처럼 형식이 정해진 값을 정규식이나 탐지 도구로 찾아 가리는 방식입니다. 이름이나 주소처럼 형식이 없는 값은 탐지 정확도가 떨어지므로, 탐지 결과를 샘플로 확인해 오탐과 미탐을 따로 기록해야 합니다.
소스코드는 별도로 봐야 합니다. API 키나 비밀번호처럼 형식이 있는 값은 잡기 쉽지만, 내부 시스템 구조나 비즈니스 로직은 패턴으로 잡히지 않습니다. 그래서 코드 입력은 저장소 단위가 아니라 허용된 디렉터리나 파일 단위로 제한하는 편이 현실적입니다.
차단 규칙은 보내지 않을 조합으로 설계하기
단일 값만 가리면 "고객 이름 + 진료 기록 + 날짜" 같은 조합이 빠져나갑니다. 차단 규칙은 개별 패턴이 아니라 조합 조건으로 두어야 합니다. 예를 들어 한 번의 입력에서 개인정보 탐지 항목이 기준 이상으로 겹치면 전송을 멈추고 안내 문구를 띄우는 방식입니다.
차단 메시지에는 어떤 항목 때문에 막혔는지, 대신 어떻게 쓰면 되는지, 예외가 필요하면 누구에게 문의하는지가 함께 나와야 합니다. 안내가 없으면 직원은 우회 방법을 찾게 되고, 그 우회 방법이 가장 큰 구멍이 됩니다.
통제 수단별 비교
입력 통제는 한 가지 장치로 끝나지 않습니다. 각 수단이 무엇을 줄이는지 구분해 두면, 빈 곳이 어디인지 보입니다. 아래 표는 점검할 때 참고할 기준입니다.
| 통제 수단 | 잘 막는 것 | 놓치기 쉬운 것 | 점검 질문 |
|---|---|---|---|
| 입력 마스킹 | 형식이 있는 개인정보 | 이름·주소 같은 자유 텍스트 | 오탐과 미탐을 샘플로 확인한 기록이 있는가 |
| 차단 규칙 | 고위험 조합의 전송 | 규칙에 없는 새 패턴 | 차단 기준과 예외 승인 절차가 문서화되어 있는가 |
| 파일·경로 제한 | 대량 소스코드 유입 | 짧은 코드 조각 복사 | 허용 저장소와 디렉터리 목록이 있는가 |
| 교육과 동의 문구 | 의도하지 않은 입력 습관 | 교육 후 실제 행동 변화 | 위반 사례가 다시 교육에 반영되는가 |
대화 로그의 보관과 접근
보관 기간은 목적에 맞춰 정하기
대화 로그는 장애 분석, 오남용 감사, 품질 개선 같은 목적으로 남기는 경우가 많습니다. 로그에 개인정보가 들어 있다면 목적이 끝난 뒤 파기 대상이 됩니다. 보관 기간은 분석에 실제로 필요한 기간과 내부 규정을 비교해 정하고, 왜 그 기간을 택했는지 문서로 남겨야 합니다.
구체적인 기간이나 법적 요건은 소속 기관의 개인정보 보호책임자, 법무 부서, 관련 법령 원문에서 확인하세요. 이 글에서 특정 기간을 제시하지 않는 이유도 여기에 있습니다. 로그 자체도 점검 대상입니다. 원문 대신 마스킹된 로그를 저장하는지, 백업본에도 같은 기간이 적용되는지 확인해야 합니다. 백업에 원문이 오래 남아 있으면 운영 로그의 보관 기간을 줄여도 실질 위험은 그대로입니다.
접근 권한은 볼 이유가 있는 사람만
로그 조회 권한이 개발팀 전체나 관리자 전원에게 열려 있으면 입력 통제가 아무리 촘촘해도 의미가 줄어듭니다. 조회는 사고 대응이나 감사 요청처럼 사유가 있을 때만 승인받고, 조회 행위 자체도 다시 기록되어야 합니다.
공용 관리자 계정이 있는지, 퇴사자 계정이 남아 있는지도 함께 봅니다. 권한 목록을 뽑아 보면 "왜 이 사람이 볼 수 있는가"에 답하지 못하는 계정이 의외로 많이 나옵니다.
ISMS-P 관점에서 점검할 항목
ISMS-P 심사는 정책과 절차가 있는지, 그대로 운영되는지를 함께 봅니다. 그래서 점검표는 "생성형 AI 사용 정책이 있는가"보다 "정책대로 입력이 통제되고, 그 증적이 남는가"를 묻는 형태가 좋습니다. 세부 인증기준의 항목 번호와 문구는 개정될 수 있으므로, 현재 적용 중인 고시본과 인증기관 안내를 기준으로 맞춰 보세요.
실무에서 증적으로 남겨야 할 것은 네 가지입니다. 첫째, 허용 데이터와 금지 데이터를 구분한 사용 기준입니다. 둘째, 마스킹과 차단 규칙의 변경 이력과 테스트 결과입니다. 셋째, 로그 조회 승인 기록입니다. 넷째, 보관 기간이 지난 뒤 파기했다는 기록입니다. 이 네 가지가 있으면 심사 설명이 쉬워지고, 사고 때 원인 추적도 빨라집니다.
바로 해 볼 순서
- 현재 AI 도구의 입력 경로를 그리고, 전송되는 곳이 사내 구축 모델인지 외부 API인지 표시합니다.
- 최근 한 달의 대화 로그를 샘플링해 개인정보와 소스코드가 원문으로 남았는지 확인합니다.
- 형식이 있는 값(주민등록번호 형식, 전화번호, API 키 패턴)을 골라 테스트 입력을 만들고 탐지 결과를 기록합니다.
- 로그 조회 권한 목록을 뽑아 사유 없이 열린 계정과 퇴사자 계정을 정리합니다.
- 보관 기간과 파기 방식을 문서로 정하고, 담당자와 다음 점검일을 정합니다.
자주 묻는 질문
마스킹만 해도 충분한가요?
충분하지 않습니다. 마스킹은 형식이 있는 값에 강하지만, 이름이나 사건 맥락처럼 조합으로 식별되는 정보는 잘 잡지 못합니다. 마스킹에 차단 규칙과 접근 통제, 로그 관리를 함께 두어야 합니다.
직원이 이미 민감한 정보를 넣었다면 어떻게 하나요?
먼저 해당 대화에 대한 접근을 제한하고, 내부 보고 절차에 따라 개인정보 보호책임자에게 알립니다. 이후 원인을 분석해 규칙을 보완합니다. 외부 서비스로 전송된 경우에는 서비스 제공자의 데이터 처리 정책과 계약 조건을 확인하고, 필요하면 공식 고객센터에 문의하세요.
사내 구축형 모델이면 점검이 필요 없나요?
그렇지 않습니다. 외부 전송 위험은 줄어들지만 대화 로그, 백업, 관리자 접근 권한은 여전히 점검 대상입니다. 사내에 있다는 사실이 로그 보관 기간이나 조회 권한 문제를 해결해 주지는 않습니다.
정리
- 입력 경로를 그리고, 마스킹과 조합 차단 규칙으로 원문 전송을 줄입니다.
- 로그는 원문 대신 마스킹된 형태로 남기고, 보관 기간과 파기 기록을 문서로 남깁니다.
- 로그 조회는 사유가 있는 사람만 하고, 조회 기록도 다시 남깁니다.
오늘 할 일: 로그 조회 권한 목록을 뽑아, 지금 볼 이유를 말할 수 없는 계정부터 정리해 보세요.
댓글