“사람이 할 수 있는 보안에는 한계가 있습니다”
“우리가 직접 점검하고 있으니 안전합니다.”
많은 기업들이 개인정보 보호 대책을 설명할 때 이렇게 말합니다.
“우리는 모든 로그를 정기적으로 확인하고 있습니다.”
“출력 결과는 사람이 검토하고 있습니다.”
이러한 수작업 대응 방식은 전통적으로 유효한 접근이었으며,
소규모 시스템에서는 지금도 효과를 발휘할 수 있습니다.
하지만,
LLM 기반의 대화형 시스템에서 초당 수백 건의 입력을 처리하고,
매일 수천 줄의 로그가 쌓이는 현실 속에서,
이러한 ‘사람 중심 점검’ 방식이 과연 오늘날 AI 시스템 운영 환경에서 유효하다고 볼 수 있을까요?
수작업 점검의 세 가지 한계
1. 데이터 양 자체가 감당되지 않는다.
하루에도 수천 건의 상담 대화, 수만 건의 프롬프트 로그가 쌓입니다.
보안 담당자가 모든 로그를 일일이 확인하는 것은 물리적으로 불가능합니다.
📝 사람은 피로, 집중력 저하, 반복 작업에 대한 익숙함 등으로 인해
일관된 품질의 점검을 유지하기 어렵습니다.
특히 단조롭고 반복적인 점검 업무는 주의력 저하와 실수를 유발할 가능성이 높습니다.
결과적으로, 사람 중심의 점검 체계는 민감정보 유출을 사전에 막기에는 한계가 분명합니다.
2. 놓치기 쉬운 ‘문맥 기반 유출’
예를 들어 “우리 아이는 OO초에 다녀요” 같은 문장은
표면적으로는 민감해 보이지 않지만,
위치 + 아동정보 + 생활패턴이 결합될 경우 민감정보로 분류될 수 있습니다.
📝 사람이 매번 이런 복합 정보를 정확히 판단하긴 어렵습니다.
특히 상담 대화나 자연어 프롬프트에서는 표현 방식이 다양하고,
같은 의미라도 맥락에 따라 해석이 달라질 수 있습니다.
단순 키워드 필터로는 걸러지지 않고, 수작업 점검으로는 일관되게 감지하기 어려운 대표적인 영역입니다.
3. ‘사고는 실수에서 시작된다’
많은 유출 사고는 ‘의도적 공격’보다 ‘내부자의 실수’에서 발생합니다.
개발자 테스트 중 실제 이름을 사용하거나, 운영자가 로그를 잘못 저장하는 상황은 흔합니다.
사람의 실수를 전제로 하는 시스템은 언제든 취약해질 수 있습니다.
📝 실수는 방심과 반복된 습관에서 시작됩니다.
내부자는 시스템에 대한 높은 접근권한과 익숙함을 동시에 갖고 있어,
작은 실수라도 큰 유출로 이어질 가능성이 큽니다.
특히 테스트 환경에서의 방심은 민감정보 유입의 주요 경로이며,
로그 자동저장 구조와 결합되면 사고는 시간문제일 뿐입니다.
기술이 아닌 방식의 한계
수작업 점검 체계의 가장 큰 문제는 ‘시간차’입니다.
- 이미 로그에 저장된 후에 발견
- 이미 고객에게 응답이 나간 후에 감지
- 이미 협력사에 전달된 문서를 뒤늦게 검토
이처럼 “사고 이후에 대응하는 구조”는,
문제가 발생한 뒤에야 조치가 가능하다는 점에서
민감정보 유출을 실시간으로 차단하지 못하는 치명적인 한계를 갖습니다.
그 사이 유출된 정보는 외부로 퍼질 수 있고,
이는 곧 기업의 신뢰도 하락, 고객 불만, 법적 책임 강화로 이어질 수 있습니다.
결국, 책임은 커지고 조치는 늦어지는 보안에서 가장 위험한 구조입니다.
실제 발생 가능한 점검 실패 시나리오
예시 1 : 정기 점검 후 뒤늦게 발견된 주민번호
📌 고객 : “제 주민번호는 800101-1234567이에요. 해지 요청하려면 필요하다길래요.”
→ 해당 대화는 챗봇 응답 기록에 저장 되었고, 실시간 필터링은 없었습니다.
→ 보안팀은 분기별 로그 점검 중에 이 데이터를 뒤늦게 확인했고, 해당 대화 기록은 이미 외부 공유용 CSV로 추출된 뒤였습니다.
예시 2 : 개발자 테스트 중 실제 정보 입력
📌 개발자 : “홍길동 / 010-2345-6789”
→ 테스트 로그가 자동 저장되고, 삭제 정책 없이 남아 있었습니다.
→ 보안팀은 이 로그가 외부 감사자료로 포함된 이후에야 민감정보가 들어 있었음을 인지했습니다.
예시 3 : 상담 후 기록에서 찾은 건강정보
📌 고객 : “제가 정신과 진료를 받았었는데요, 약 처방 관련해서 문의드려요.”
→ 상담원은 별도로 조치하지 않았고, 로그는 자동 저장됨.
→ 이후 LLM 튜닝용 학습 데이터로 추출될 뻔했으나, 최종 검토 과정에서 필터링이 이루어짐.
→ 보안팀은 수작업 검토만으로는 놓쳤을 가능성이 매우 높았다고 평가.
이 세 가지 점검 실패 시나리오의 공통점은 모두,
“민감정보가 저장된 후에야” 대응을 시도했다는 것입니다.
이미 저장된 이후에는, 점검도 어렵고 책임도 더 무거워집니다.
왜 지금, ‘입력단에서 차단하는 구조’가 필요할까?
많은 보안체계는 여전히 저장된 로그를 정기적으로 점검하거나,
응답 결과를 검토하는 방식에 머무르고 있습니다.
하지만 LLM은 “입력된 데이터를 학습하거나, 그 데이터를 기반으로 응답을 생성” 합니다.
이미 입력된 민감정보는
LLM 응답을 통해 제3자에게 노출되거나,
서버 로그에 저장되어 추후 유출될 수 있으며,
시스템 외부로 연동되어 복제될 수도 있습니다.
즉, 유출은 출력이 아니라 ‘입력 순간’에 시작됩니다.
이제는 “입력 자체를 통제하는 구조” 가 필요합니다.
입력단에서 차단하면, 무엇이 달라질까?
‘입력 전에 감지하고 차단한다’는 것은 단순한 기술적 변화가 아닙니다.
이는 AI 시스템 전체 흐름의 보안 기준을 재정의하는 일입니다.
✔️ 민감정보 유입 자체가 차단됩니다.
– 더 이상 LLM이 민감정보를 학습하거나, 응답에 포함시키는 일이 발생하지 않습니다.
✔️ 민감정보가 로그에 저장되지 않습니다.
– 실수든 악의적 입력이든, 기록 자체가 차단되므로 유출 원천 봉쇄가 가능합니다.
✔️ 실무자의 검토 부담이 줄어듭니다.
– 출력 검토, 로그 점검에 들어가던 리소스를 줄이고, 사후 대응보다 사전 예방에 집중할 수 있습니다.
✔️ 보안 책임이 명확해집니다.
– 입력된 민감정보가 차단되었는지만 확인해도, 보안 수준과 책임 범위를 명확히 판단할 수 있습니다.
기업이 지금 바로 해야 할 것
✅ 민감정보 점검이 실제로 어떻게 이뤄지고 있는지, 사람 기준인지 시스템 기준인지 확인하세요.
✅ 수작업 점검이 어떤 시점(입력/저장/출력)에 수행되는지를 흐름도로 정리해 보세요.
✅ 사람이 판단하기 어려운 문맥상 유출 가능성에 대해, 사전 차단 체계가 있는지 점검하세요.
✅ 정기 점검이 아닌 “실시간 대응 구조”가 기술적으로 가능한지 검토해야 합니다.
✅ 내부 실수 기반 유출 시나리오를 기반으로, 점검 포인트를 재설계하세요.
다음 예고
이제 보안 점검은 ‘저장 후 확인’이 아니라, ‘입력 전 차단’이 기준이 되어야 합니다.
수작업 점검의 한계는 이미 드러났습니다.
이제는 사람보다 먼저 감지하고, 기록보다 먼저 차단하는 구조로 옮겨가야 합니다.
이것이 지금 AI 보안이 직면한 가장 현실적인 변화의 요구입니다.
다음 편 “업종마다 다른 민감정보, 어떻게 대응해야 할까?”에서는
LLM 보안을 도입하려는 다양한 기관들이 있지만,
적용해야 할 정책의 범위와 기준은 모두 다를 수 있습니다.
금융권에서는 민감하게 분류되는 정보가,
공공기관에서는 오히려 마스킹 없이 정확히 전달돼야 할 업무상 필수 정보일 수 있습니다.
이처럼 병원, 교육기관, 금융회사 등 각 산업군이 요구하는
탐지 기준과 보안 정책의 차이를 실제 사례 중심으로 살펴보며,
맞춤형 보안 전략 수립의 방향을 제안드립니다.
본 포스팅은 아래 자료를 기반으로 분석 및 재구성하였습니다.
해당 내용의 해석은 보안 정책 적용 사례 및 공개 문헌 기준에 따라 작성자의 판단을 반영하여 정리하였습니다.
[Samsung SDS] LLM에서 자주 발생하는 10가지 주요 취약점
[AWS] OWASP Top 10 for LLMs 기반 생성형 AI 보안 설계
[보안뉴스] 개인정보위 ‘자동화된 결정에 대한 정보주체의 권리 안내서’
[SKCC] LLM에서 최적화된 AI 모델로 진화하는 인공지능
[SINSIWAY] 인공지능(AI)시대, 개인정보 안전장치 시행
[SAPiEN] LLM의 안전 및 보안을 위한 설명 가능한 신경 생성 및 벤치마킹