로컬 LLM으로 민감정보 걸러보니, 재현율 92%였어요

핵심 요약 — 코드나 오류 로그를 클라우드 AI에 붙여넣을 때 API 키처럼 형식이 일정한 정보는 규칙으로 잡히지만, “프로젝트 오로라를 금요일 자정에 전환한다” 같은 문맥적 정보는 규칙만으로 못 잡아요. 요즘IT에 실린 한 실험은 로컬 LLM(내 컴퓨터에서 직접 돌리는 거대 언어모델)을 더해 재현율을 80%에서 92%로 끌어올렸어요. 다만 오탐도 함께 늘어서, 저자도 이걸 보안 도구가 아니라 전송 전 체크리스트로 정리했어요.

📰 2026년 8월 29일 기준 최신 소식 | 이 글은 특정 시점의 뉴스를 다루고 있어요.

“이 코드, ChatGPT에 붙여넣어도 될까요?” 요즘 개발팀에서 흔히 나오는 질문이에요. 오류를 빨리 풀고 싶어서 로그를 통째로 붙여넣다 보면, 그 안에 뭐가 섞여 있는지 놓치기 쉽거든요.

---

1. 무슨 실험이었나요

코드 자동완성을 넘어 커밋과 배포 로그까지 다루는 AI 에이전트 도입이 늘면서 개발팀이 클라우드 AI에 붙여넣는 텍스트 양도 함께 늘고 있어요. 요즘IT에 실린 한 실험은 이 지점을 파고들었어요. 로컬 LLM으로 코드·오류 로그·문서 속 민감정보를 미리 걸러낼 수 있는지 직접 시험해본 거예요.

2. 형식이 일정한 정보는 규칙만으로도 잡혀요

API 키, 사내망 IP 주소, 사용자 이름이 들어간 로컬 경로, 이메일 주소처럼 형식이 일정한 값은 정규표현식(패턴을 정해 문자열을 찾는 규칙)만으로도 상당수 걸러져요. 코드 15개·오류 로그 20개·문서 15개, 총 50개의 합성 데이터로 시험한 결과 규칙만 썼을 때 재현율(있어야 할 걸 놓치지 않은 비율) 80.0%가 나왔어요. 처리 속도도 0.003밀리초로 사실상 즉시고요.

3. 문제는 문맥에 숨은 정보예요

규칙이 못 잡는 건 형식이 없는 정보예요. 실험에는 “프로젝트 오로라를 금요일 자정에 전환한다”라는 문장이 예시로 나왔어요. ‘오로라’라는 단어 자체는 평범해 보이지만, 그게 비공개 프로젝트명이라면 얘기가 달라져요. 정규식은 이런 문장을 걸러낼 방법이 없어요. 배경을 아는 사람만 알아챌 수 있는 정보라서요.

4. 로컬 LLM을 더하니 재현율이 92%로 올라갔어요

실험은 애플 M5 Pro·메모리 48GB 환경에서 Ollama(로컬 환경에서 LLM을 실행하는 도구) 0.32.7로 gpt-oss 20B·Qwen 27B·Gemma 26B 세 모델을 돌렸어요. 규칙에 로컬 모델을 더하자 미탐(놓친 항목)이 10개에서 4개로 줄고 재현율은 92.0%까지 올라갔어요. 그 대신 오탐(아닌데 잡힌 항목)도 5개 나왔고, 처리 시간은 0.87초로 늘었어요. 세 모델 중에는 Gemma 26B가 대표 모델로 뽑혔어요.

조건	미탐	재현율	처리 시간
규칙만	10개	80.0%	0.003ms
규칙 + 로컬 LLM(Gemma 26B)	4개	92.0%	0.87초

5. 그래도 보안 도구라고 부르긴 일러요

저자도 선을 그었어요. 같은 프롬프트를 넣어도 모델마다 결과가 달랐고 반복 실행에서조차 편차가 났어요. 표본도 50개뿐이니 일반화는 무리고요. 마스킹을 과하게 걸면 클라우드 AI가 맥락을 놓쳐 답변 품질이 떨어지는 부작용까지 생겼어요. 로컬 LLM이 하는 일은 결국 ‘허가’가 아니라 ‘의심할 위치를 짚어주는 것’에 가까웠어요. 최종 판단은 여전히 사람 몫이라는 뜻이에요. 그래서 저자는 이 실험을 보안 도구가 아니라 전송 전 체크리스트로 불렀고, 민감도가 높은 자료는 애초에 클라우드 AI에 올리지 않는 편이 낫다고 못 박았어요.

6. Creative Soft가 보는 지점 — 도구보다 규칙이 먼저예요

저희도 자체 SaaS 4종을 직접 운영하면서 사내 개발팀이 매일 코드와 로그를 다뤄요. 그래서 이 실험이 남 얘기 같지 않았어요. AI 어시스턴트가 사내 메일·일정에 붙을 때 정할 5가지에서도 짚었듯, AI 도구가 다루는 범위가 넓어질수록 회사가 먼저 정해야 할 건 도구 자체가 아니라 ‘어디까지 넣어도 되는지’를 적어둔 규칙이에요.

개인정보보호위원회가 2025년 8월 낸 생성형 AI 개인정보 처리 안내서도 같은 순서를 요구해요. 목적을 정하고 전략을 세운 뒤, 학습·개발 단계와 시스템 적용 단계를 각각 점검하는 4단계예요. AI 기본법도 2026년 1월 22일부터 시행되고요(다만 첫 1년은 계도기간이라 과태료는 유예돼요). 규칙이 이미 법과 가이드 형태로 나와 있는 셈이라, 회사가 새로 만들기보다는 우리 상황에 맞게 옮겨 적는 쪽이 빨라요.

개발을 외주로 맡기는 경우라면 이 규칙이 계약서에도 들어가야 해요. 저희는 이런 요건을 개발 외주 보안·개인정보 요건, 계약 전에 정할 7가지로 따로 정리해둔 적이 있어요. 실데이터를 넘기지 않고 가짜 데이터로 개발·시험을 진행하는 방식도 클라우드 AI에 붙여넣지 않는 것과 원리가 같아요. 애초에 민감한 정보가 나올 자리를 만들지 않는 거예요.

7. 자주 묻는 질문

클라우드 AI에 코드를 붙여넣을 때 가장 먼저 확인할 건 무엇인가요?

API 키·사설 IP·로컬 경로·이메일처럼 형식이 일정한 값부터 지우고, 프로젝트명이나 일정처럼 문맥에 숨은 정보는 사람이 한 번 더 훑어보는 순서가 안전해요.

로컬 LLM으로 거르면 안전이 보장되나요?

아니요. 이번 실험에서도 규칙만 쓰면 재현율 80%, 로컬 모델을 더해도 92%에 그쳤고 오탐도 함께 늘었어요. 로컬 LLM은 의심되는 곳을 짚어주는 역할이고, 최종 판단은 여전히 사람 몫이에요.

AI 자체 도입과 외주 개발 중 어떤 선택이 맞나요?

지금 필요한 게 사용 규칙이라면 문서로 먼저 정하는 게 순서예요. 반대로 그 규칙을 코드·로그가 쌓이는 사내 파이프라인에 필터로 붙이는 작업이라면, 서버와 모델 운영까지 직접 갖추기보다 외주로 붙이는 편이 더 빨라요.

사내 AI 사용 가이드라인은 꼭 만들어야 하나요?

그러는 편이 안전해요. 개인정보보호위원회가 2025년 8월 낸 생성형 AI 개인정보 처리 안내서도 목적 설정부터 시스템 적용까지 단계별 점검을 요구해요. 무엇을 넣고 넣지 않을지 한 장으로 정리해두는 것만으로도 사고 상당수를 막을 수 있어요.

8. 마무리

로컬 LLM이 민감정보를 빠짐없이 걸러주는 도구는 아니었어요. 그래도 이번 실험은 무엇을 확인해야 하는지를 구체적으로 보여줬어요. 형식이 일정한 값은 규칙으로, 문맥에 숨은 값은 사람이 — 이 두 층을 나눠서 보는 것만으로도 사고를 줄일 수 있어요.

저희는 10년 넘게 자체 SaaS 4종을 직접 운영하면서 이런 판단을 내부에서 늘 내려왔어요. 롯데·캐논 같은 곳과 진행한 프로젝트에서도 데이터를 다루는 범위를 계약 전에 정해두는 쪽이 항상 더 안전했고요. AI 도입이든 개발 외주든 회사 데이터가 어디까지 열리는지부터 정하고 시작하고 싶다면 프로젝트 상담받기 →에서 이야기 나눠요.