로컬 LLM으로 민감정보를 걸러봤습니다

코드나 오류 로그를 ChatGPT, Claude 같은 클라우드 AI에 붙여 넣으면 문제를 빠르게 정리할 수 있습니다. 하지만 전송 버튼을 누르기 전에는 API 키, 내부 서버 주소, 사용자 이메일, 로컬 경로가 남아 있지 않은지 직접 확인해야 합니다.

형식이 일정한 값은 검색으로 찾기 쉽습니다. 반면 “프로젝트 오로라를 금요일 자정에 전환한다” 같은 문장에서는 ‘오로라’가 공개 제품인지 아직 발표하지 않은 내부 프로젝트인지 문맥을 봐야 합니다. 이 확인 작업을 줄이기 위해 정규표현식과 세 종류의 로컬 LLM을 결합한 작은 필터를 만들고, 실제로 어디까지 도움이 되는지 합성 데이터로 측정했습니다.

이 필터의 목표는 보안을 자동화하는 것이 아닙니다. 사용자가 마지막으로 확인해야 할 위치를 먼저 보여주는 보조 장치가 실제로 쓸 만한지 확인하는 실험입니다.

무엇을 민감정보로 봤나

이번 실험의 대상은 다섯 종류입니다.

• API 키와 접근 토큰
• 이메일 주소
• 내부 서버 주소와 사설 IP
• 사용자명과 폴더 구조가 드러나는 로컬 경로
• 문맥을 봐야 알 수 있는 비공개 프로젝트명과 구체적인 출시·전환 일정

실제 회사 정보나 유효한 키는 사용하지 않았습니다. .invalid 이메일, RFC 1918 사설 IP, 인증에 사용할 수 없는 합성 키와 가짜 프로젝트명만 넣었습니다. 공개 제품명, 문서용 예약 IP, 버전 번호, 공용 시스템 경로처럼 가리면 안 되는 대조 입력도 포함했습니다.

규칙과 로컬 모델의 역할을 나눴다

첫 단계의 규칙 필터는 이메일, 사설 IP, 사용자 홈 경로, 키·토큰 형태를 자동으로 찾아 [EMAIL_1], [PRIVATE_IP_1] 같은 표식으로 바꿉니다. 같은 값에는 같은 표식을 사용해 문장 안의 관계를 보존했습니다.

두 번째 단계에서는 원문과 규칙 탐지 결과를 로컬 모델에 전달했습니다. 모델에는 문장을 다시 쓰거나 “안전하다”고 선언하는 권한을 주지 않고, 후보 문자열·분류·판단 이유만 JSON으로 반환하게 했습니다. 후보는 자동 마스킹하지 않고 검토 목록에 올렸습니다.

실험 환경은 Apple M5 Pro, 메모리 48GB, Ollama 0.32.7입니다. 비교한 모델은 gpt-oss:20b 20.9B MXFP4 13.8 GB, qwen3.6:27b 27.8B Q4_K_M 17.4 GB, gemma4:26b 25.8B Q4_K_M 18.0 GB입니다. Qwen은 기존 파일에서 실사용 프롬프트가 빈 응답을 냈지만, Ollama를 업그레이드하고 모델 무결성을 다시 확인한 뒤 정상화됐습니다.

50개 입력으로 조건을 비교했다

데이터는 총 50개입니다. 코드 15개, 오류 로그 20개, 업무 문서와 메모 15개로 구성했습니다. 민감정보가 있는 입력은 35개, 없는 대조 입력은 15개입니다. 정답 민감정보는 총 50개이며 다섯 유형을 각각 10개씩 넣었습니다.

전체 50개 입력은 모델별로 한 번 처리하고, 문맥 판단이 어려운 10개는 총 5회 반복했습니다. 규칙은 전체 데이터를 100회 처리해 문장당 중앙값을 구했습니다. 모델 시간은 완전히 내린 뒤의 최초 실행 3회와 예열 후 10회를 분리했습니다.

조건별 결과 요약

• 규칙만: 미탐 10, 오탐 0, 정밀도 100.0%, 재현율 80.0%
• 규칙 + GPT-OSS 20B: 미탐 6, 오탐 6, 정밀도 88.0%, 재현율 88.0%, 최초 16.95초, 예열 후 9.83초
• 규칙 + Qwen 3.6 27B: 미탐 5, 오탐 5, 정밀도 90.0%, 재현율 90.0%, 최초 10.54초, 예열 후 5.56초
• 규칙 + Gemma 4 26B: 미탐 4, 오탐 5, 정밀도 90.2%, 재현율 92.0%, 최초 2.90초, 예열 후 0.87초
• 대표 모델 + 사람 확인: 미탐 0, 오탐 0, 정밀도 100.0%, 재현율 100.0%

규칙 처리 시간의 문장당 중앙값은 0.003밀리초였습니다. 모델별 결과는 다음과 같습니다.

• gpt-oss:20b: 미탐 6개, 오탐 6개, 재현율 88.0%, 예열 후 중앙값 9.83초, JSON 실패 5회
• qwen3.6:27b: 미탐 5개, 오탐 5개, 재현율 90.0%, 예열 후 중앙값 5.56초, JSON 실패 0회
• gemma4:26b: 미탐 4개, 오탐 5개, 재현율 92.0%, 예열 후 중앙값 0.87초, JSON 실패 19회

실험 기준에 따라 대표 모델은 gemma4:26b로 결정됐습니다. 우선순위는 재현율, 낮은 오탐, JSON 실패율, 예열 후 처리 시간이었습니다.

대표 화면에 사용한 입력은 sohee@example.invalid에게 12월 3일 새벽 1시 출시 계획을 공유했습니다.입니다. GPT-OSS는 ‘sohee@example.invalid’, ‘12월 3일 새벽 1시’, Qwen은 ‘sohee@example.invalid’, ‘12월 3일 새벽 1시 출시 계획’, Gemma는 ‘sohee@example.invalid’, ‘12월 3일 새벽 1시 출시 계획’을 후보로 냈습니다. 설명이 자연스럽더라도 실제 후보가 빠질 수 있어 사람이 원문과 함께 확인해야 했습니다.

규칙은 빠르지만 문맥 앞에서 멈췄다

규칙만 사용한 조건은 미탐 10개, 오탐 0개였습니다. 형식이 일정한 이메일·RFC 1918 사설 IP·키·사용자 경로 40개는 모두 찾았지만, 프로젝트명과 일정 10개는 설계상 그대로 남았습니다. 문서용 예약 IP와 일반 시스템 경로는 가리지 않았습니다.

규칙을 계속 늘리면 특정 사례는 잡을 수 있지만, 프로젝트명과 일정이 바뀔 때마다 금칙어 목록을 관리해야 합니다. 예상하지 못한 문맥 표현을 찾는 역할은 모델 후보가 보완했습니다.

로컬 모델은 후보를 보완했지만 서로 다르게 틀렸다

세 모델은 같은 프롬프트와 합성 입력을 받았지만 결과가 같지 않았습니다. GPT-OSS는 안정적인 JSON을 위해 thinking 모드가 필요했고, 예비 검사에서는 이메일과 IP만 잡고 프로젝트명과 일정을 놓쳤습니다. Qwen과 Gemma도 문맥 후보를 더 찾는 대신 대조 문장을 내부 정보로 과하게 판단하는 경우가 있었습니다.

반복 실행의 후보 집합 일치율은 GPT-OSS 91.1%, Qwen 100.0%, Gemma 100.0%였습니다. 결과가 매번 같더라도 정확하다는 뜻은 아니며, 반대로 후보가 흔들리면 자동 승인에 쓰기 더 어렵습니다.

이 작은 표본에서는 마스킹 방식보다 응답 변동이 컸다

대표 오류 로그 5개를 원문, 후보를 모두 승인한 과도한 마스킹, 식별값만 가리고 관계를 보존한 마스킹으로 나눠 동일한 클라우드 모델에 보냈습니다. 오류 원인, 실행 가능한 해결책, 잘못된 가정, 추가 원문 없이 이해 가능한지를 각 0~2점으로 평가했습니다.

• 원문 평균: 8.0/8점
• 과도한 마스킹 평균: 8.0/8점
• 관계 보존 마스킹 평균: 7.2/8점

후보 전부 승인 조건은 이메일이 아닌 user@example까지 가렸지만 5개 평균은 원문과 같은 8.0점이었습니다. 오히려 Q1에서는 후보 전부 승인과 관계 보존 입력이 같았는데도 독립 응답 점수가 8점과 4점으로 갈렸습니다. 5개뿐인 이번 결과로 관계 보존 마스킹이 항상 더 좋은 답변을 만든다고 결론낼 수는 없습니다. 다만 식별값 대신 일관된 표식을 사용하면 문장 안의 관계를 유지하면서 전송 범위를 줄일 수 있다는 설계상의 장점은 남았습니다.

로컬 실행도 따로 확인했다

Ollama API는 127.0.0.1:11434에 바인딩돼 있었습니다. 대표 추론 전·중·후 프로세스 연결을 211초 동안 360회 관찰했습니다. 네트워크 결과 문구는 “관찰 구간에서 Ollama 외부 연결을 확인하지 못했다.”로 제한했습니다. 로그와 데이터 경로의 canary 검사도 “확인한 경로에서는 평문 canary를 찾지 못했다.”라고만 기록했습니다.

이 결과는 시스템 전체에서 외부 전송이 절대 없었다는 증명이 아닙니다. 확인한 프로세스와 시간, 경로 안에서 관찰된 사실입니다. 로컬 실행 여부, 외부 연결, 프롬프트 저장 여부는 서로 다른 주장으로 분리해야 합니다.

마치며: 보안 도구가 아니라 전송 전 체크리스트에 가까웠다

실제 사용 흐름은 다음과 같이 정리됐습니다. 먼저 비밀정보가 코드와 로그에 남지 않도록 환경 변수와 비밀정보 관리 도구를 사용합니다. AI에는 필요한 부분만 복사합니다. 규칙 필터가 형식이 분명한 값을 마스킹하고, 로컬 모델은 문맥 후보를 보여줍니다. 마지막으로 사람이 원문과 결과를 나란히 확인한 뒤 전송합니다. 필터가 아무것도 찾지 못해도 검토를 생략하지 않습니다.

이번 결과는 직접 만든 50개 합성 데이터에 대한 소규모 실험입니다. 일반적인 보안 성능을 증명하지 않으며, 민감도가 높은 자료에는 애초에 클라우드 AI를 사용하지 않는 판단이 우선입니다. 로컬 LLM의 역할은 “이 문서는 안전하다”고 허가하는 것이 아니라, 전송 전에 한 번 더 의심할 위치를 보여주는 데 있었습니다.

<참고>

• Ollama API 소개
• Ollama 처리 시간 항목
• Ollama 클라우드 및 로컬 전용 모드
• OpenAI API 키 안전 수칙
• OWASP 비밀정보 관리 지침

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.