무엇이 AI로 들어가는지를 다룹니다. 시리즈의 다른 글 보기
안녕하세요. 오픈소프트랩에서 생성형 AI 거버넌스 제품을 만드는 개발팀입니다.
앞선 시리즈들에서는 사람이 만든 업무와 장비가 쏟아낸 이벤트를 다뤘습니다. (업무 시스템 다시 만들기, 보안 포탈 설계) 이번 시리즈부터는 AI가 만들어내는 것을 다룹니다. 앞의 두 가지와 무엇이 다른지가 이 시리즈의 축입니다.
직원이 외부 AI에 회사 정보를 흘리지 않게 막는 기능을 설계할 때, 저희가 처음 세운 그림은 단순했습니다.
입력창에 들어오는 글자를 검사한다. 주민등록번호, 계좌번호, 전화번호, API 키 같은 패턴이 보이면 막거나 가린다.
틀린 접근은 아니었습니다. 지금도 이게 가장 먼저 필요한 통제입니다. 다만 이 전제는 사용자가 글자만 보낸다는 것을 깔고 있었고, 그 전제가 생각보다 빨리 깨졌습니다.
사용자는 글자를 보내지 않았습니다
시나리오를 넓혀보자마자 이런 장면들이 나왔습니다.
장면 1
상담 이력을 PDF로 내려받아 올리고 — "핵심 이슈만 요약해줘"
장면 2
사내 시스템 화면을 캡처해서 붙여넣고 — "이 포트폴리오 위험도 좀 봐줘"
장면 3
고객 명단 엑셀을 첨부하고 — "여기서 이탈 가능성 높은 고객 뽑아줘"
세 장면 모두 프롬프트 자체에는 민감정보가 한 글자도 없습니다. 핵심 이슈만 요약해줘에서 걸러낼 것은 아무것도 없습니다.
그런데 첨부된 것 안에는 다 들어 있습니다.
장면 2를 열어보면 이렇습니다.
[화면 캡처에서 읽어낸 것]
고객명 홍길동
계좌번호 123-45-67890
총자산 1,520,300,000원
보유종목 A전자 15,000주 / B화학 3,000주예시 화면입니다. 실제 고객 데이터가 아닙니다.
입력창만 보는 검사는 이 요청을 아무 문제 없는 요청으로 판정합니다. 글자에는 정말로 아무것도 없으니까요.
이때부터 질문이 바뀌었습니다.
~~프롬프트에 민감정보가 있는가~~
AI로 들어가는 것 안에 무엇이 들어 있는가
그럼 기존 DLP를 앞에 세우면 되지 않나
회사에는 이미 DLP(Data Loss Prevention, 정보 유출 방지)가 있습니다. 파일 반출 통제도 있고 방화벽도 있습니다. AI 앞단에 그대로 붙이면 되는 것 아닌가 — 저희도 먼저 이 생각을 했습니다.
붙여놓고 보니 되는 게 있고 안 되는 게 있었습니다.
| 기존 통제가 잘하는 것 | AI 사용에서 새로 생기는 것 | |
|---|---|---|
| 텍스트 | 정해진 형식의 개인정보 탐지 | 형식은 없는데 내용이 기밀인 문장 |
| 문서 | 파일명·확장자·반출 정책 | 본문에 실제로 뭐가 적혀 있는가 |
| 이미지 | 파일 자체의 전송 통제 | 그림 안에 글자로 들어 있는 정보 |
| 표 | 파일 단위 검사 | 셀과 열의 구조를 봐야 판정되는 값 |
| 응답 | (대상 아님) | 모델이 돌려준 내용 |
가장 큰 차이는 마지막 줄입니다. 기존 통제는 나가는 것을 봅니다. AI는 받아오는 것도 문제가 됩니다.
그리고 하나 더 있습니다. 기존 통제의 판정은 대체로 둘 중 하나입니다. 막거나, 통과시킵니다. 그런데 AI 사용을 막기만 하면 업무가 멈추고, 직원은 개인 계정으로 넘어갑니다. 통제하려다 회사가 볼 수 없는 경로로 밀어내는 셈이 됩니다.
확인 1 — 문서는 한 덩어리가 아니었습니다
PDF 하나를 열어보면 개인정보가 한 군데 모여 있지 않습니다.
2026_투자검토보고서.pdf
1p 회사 개요 · 공개된 재무정보
3p [표] 검토 금액 · 조건
8p 담당자 연락처
12p 스캔해서 붙인 서명 페이지예시입니다.
8페이지의 연락처는 형식이 뚜렷해서 잡기 쉽습니다. 문제는 나머지입니다.
3페이지의 표는 문장으로 이어 붙여 읽으면 값이 서로 붙습니다. 1,200 억원 미공개 같은 식으로 셀 경계가 사라지면 형식 검사가 어긋납니다. 셀 구조를 그대로 살려서 열 이름과 값을 함께 봐야 합니다.
12페이지의 스캔 이미지는 더 분명합니다. 그건 글자가 아니라 그림입니다. 문서에서 텍스트를 뽑으면 이 페이지는 아무것도 없는 페이지로 나옵니다. 검사기는 문제가 없다고 답하고, 실제로는 서명과 도장이 그대로 올라갑니다.
그래서 문서를 한 덩어리로 다루지 않고 본문·표·이미지를 나눠서 각각 다루기로 했습니다. 같은 문서 안에서도 영역마다 읽는 방법이 달라야 했기 때문입니다.
확인 2 — 이미지 속 숫자는 그냥 숫자였습니다
이미지는 글자로 바꾸면 되겠다고 생각했습니다. 그림에서 글자를 읽어내고, 그 글자를 텍스트와 같은 기준으로 검사하면 된다고요.
절반은 맞았습니다.
읽어낸 결과가 이렇게 나왔습니다.
1234567890이게 계좌번호인지, 전화번호인지, 주문번호인지, 사번인지 구분할 방법이 없었습니다. 숫자만 놓고 보면 전부 그럴듯합니다.
사람은 어떻게 아느냐 하면, 옆에 뭐라고 적혀 있는지를 봅니다.
계좌번호 1234567890 ← 계좌번호
주문번호 1234567890 ← 주문번호글자만 순서대로 뽑아내면 이 관계가 사라집니다. 어느 라벨 옆에 있던 값인지가 남아야 판정이 됩니다.
여기서 얻은 게 하나 더 있었습니다. 위치를 알면 그 부분만 가릴 수 있습니다. 이미지 전체를 차단하지 않고 계좌번호 영역만 덮은 뒤 나머지 차트와 종목 정보는 그대로 보낼 수 있습니다. 업무는 진행되고 식별자만 빠집니다.
막는 것보다 이게 훨씬 자주 쓰이는 선택지가 됐습니다.
그래서 무엇이 달라졌나
정리하면 세 가지가 바뀌었습니다.
검사 대상 — 입력창의 문자열에서, AI로 들어가는 콘텐츠 전체로 넓혔습니다.
검사 방식 — 형식으로 판정하는 것과 의미로 판정하는 것을 따로 두었습니다. 주민등록번호는 형식으로 잡히지만, 아직 외부에 공개되지 않은 검토 의견은 형식이 없습니다.
판정 결과 — 막거나 통과시키는 두 칸 사이에 칸을 더 넣었습니다. 가리고 보내기, 사내 모델로 돌리기, 승인 후 처리하기 같은 것들입니다. 이 이야기는 분량이 있어서 다음 편에서 따로 쓰겠습니다.
다음 범위로 넘긴 두 가지
여기까지가 지금 돌아가는 부분입니다. 두 가지는 이번에 범위를 정해두고 다음으로 넘겼습니다.
첫째, 어디까지 기다리게 할 것인가.
스캔 문서는 글자로 바꾸는 데 시간이 걸립니다. 페이지가 많으면 사용자는 그동안 기다립니다.
지금은 상한을 조직이 정하게 열어뒀습니다. 넘으면 차단할지 뒤로 돌릴지도 같이 고릅니다. 저희가 하나로 못 박지 않은 이유는, 170페이지 계약서를 다루는 곳과 한 장짜리 상담 메모를 다루는 곳의 답이 다르기 때문입니다.
대신 초기값을 뭘로 줄지가 남았습니다. 처음 도입하는 곳은 판단할 데이터가 없으니까요. 지금은 운영 데이터를 모으고 있고, 업종별로 쓸 만한 기본값이 나오면 그걸 제공할 생각입니다.
둘째, 의미로 판정하는 검사를 얼마나 믿을 것인가.
형식이 없는 기밀을 잡으려면 모델 판단이 필요합니다. 그런데 그 판단을 그대로 차단 근거로 쓰면 오탐이 곧 업무 중단이 됩니다. 정상적인 업무 요청이 막히는 경험이 반복되면 사용자는 우회 경로를 찾고, 결국 처음 문제로 돌아갑니다.
지금은 위험도가 높은 건에 대해서만 형식 기반 결과나 사용자 권한과 함께 보도록 조합해 두었습니다. 안전한 쪽이긴 한데, 그만큼 모델 판단만으로 잡을 수 있었던 건을 놓치고 있을 겁니다. 이 균형점은 운영 데이터가 더 쌓여야 답이 나올 것 같습니다.
다음 편에서는 찾아낸 것을 어떻게 판정할지 다룹니다.
오픈소프트랩 개발팀이 작성합니다. 생성형 AI 사용 통제와 AI 에이전트의 도구 실행 통제를 만들고 있습니다.