클라우드 AI에 코드 붙여넣기 전, 민감정보를 거르는 현실적인 방법

한줄 요약

클라우드 AI에 코드 붙여넣기 전, 로컬 LLM+규칙 필터로 민감정보 후보를 먼저 걸러내는 방법.

본문

개발팀이 클라우드 AI를 보조 도구로 쓰는 건 이제 일상이 됐다. 오류 로그를 던지면 원인을 짚어주고, 코드 스니펫을 넣으면 리팩터링 방향까지 제안한다. 그런데 외주 개발 프로젝트에서는 이 편리함이 곧 리스크가 된다. 클라이언트 데이터, 내부 API 키, 아직 발표하지 않은 서비스명이 그대로 외부 서버로 날아갈 수 있기 때문이다.

"붙여넣기 전에 직접 확인하면 되는 거 아닌가?"라고 생각할 수 있다. 실제로는 그 확인이 생각보다 어렵다. 형식이 뚜렷한 값—키 문자열, IP 주소, 이메일—은 눈에 띄지만, "베타 오픈은 목요일 오전 10시로 확정" 같은 문장 안에 녹아 있는 미공개 정보는 훑어보는 것만으로는 놓치기 쉽다.

왜 개발 외주 현장에서 이 문제가 더 심각한가

사내 개발팀은 정보 보안 정책이 있고, 어떤 도구를 쓸 수 있는지 명확한 가이드가 있는 경우가 많다. 반면 외주 개발 환경에서는 클라이언트 측 정보 보안 정책과 개발사 내부 도구 사용 기준이 충돌하거나 아예 정의되지 않은 채로 프로젝트가 시작된다.

개발사 입장에서는 빠른 디버깅을 위해 AI를 쓰고 싶고, 클라이언트 입장에서는 자사 정보가 AI 학습에 활용될까 봐 불안하다. 이 간극을 메우는 현실적인 방법 중 하나가 전송 전 필터를 로컬에서 돌리는 구조다. 외부로 나가기 전에 걸러낸다는 사실을 기록으로 남길 수 있고, 클라이언트에게도 납득 가능한 프로세스로 설명할 수 있다.

규칙 기반 필터와 로컬 LLM, 역할이 다르다

두 가지를 동시에 쓰는 이유는 각자 잘하는 영역이 다르기 때문이다.

규칙 기반 필터는 형식이 정해진 값을 빠르게 찾는다. 이메일 패턴, 사설 IP 대역, 환경 변수 형태의 키 문자열, 사용자 홈 경로 같은 것들이다. 정규표현식으로 처리하면 문장당 처리 시간이 밀리초 단위도 안 된다. 오탐 없이 찾아낸다는 것도 장점이다. 단, 형식이 없는 정보—미공개 프로젝트명이나 구체적인 배포 일정—는 규칙으로 잡기 어렵다.

로컬 LLM은 그 문맥 판단을 보완한다. "다음 달 첫째 주 론칭 예정인 ○○ 서비스" 같은 표현이 내부 정보인지 공개 정보인지 구분하는 데 언어 모델이 유용하다. 단, 이 모델의 역할을 명확하게 제한해야 한다. "이 문서는 안전하다"고 판정하게 하면 안 된다. 모델은 의심스러운 후보 목록과 판단 근거만 돌려주고, 최종 결정은 사람이 한다.

이 조합이 만드는 흐름은 단순하다. 규칙 필터가 형식 기반 값을 표식으로 치환하고, 로컬 모델이 나머지 문맥 후보를 리스트로 올린다. 개발자는 원문과 후보 목록을 나란히 보고 어떤 내용을 전송할지 직접 결정한다.

로컬 모델을 실제로 써보면 어디서 틀리는가

로컬 LLM을 이 용도로 써보면 금방 한계가 보인다. 우선 모델마다 같은 입력에 다른 결과를 낸다. 어떤 모델은 문맥 민감정보는 잘 잡지만 구조화된 응답(JSON 형식 등)이 불안정하다. 어떤 모델은 응답은 일관되지만 대조 입력—공개 정보인데도 내부 정보로 판단하는 경우—을 자주 낸다.

재현율(민감정보를 빠뜨리지 않는 비율)과 오탐율(멀쩡한 내용을 문제로 보는 비율) 사이의 트레이드오프는 어느 모델이든 존재한다. 이 때문에 필터가 "아무것도 없다"고 응답해도 검토를 생략하면 안 된다. 필터는 검토할 위치를 좁혀주는 도구지, 통과 허가를 내주는 게이트가 아니다.

---

실제 외주 개발 프로젝트에 이 구조를 적용하면 클라이언트에게 제시할 수 있는 프로세스가 생긴다. 어떤 정보를 어떤 방식으로 처리했는지 설명하기 위한 최소한의 장치다. 완벽한 보안 솔루션이 아니라, 전송 전 체크리스트를 자동화한 보조 도구로 보는 것이 맞다.

개발 외주 프로젝트에 적용할 때 현실적인 출발점

도입 장벽이 낮은 순서로 정리하면 이렇다.

첫째, 환경 변수와 시크릿 관리 도구를 먼저 정비한다. AI 필터를 쓰기 전에 코드 자체에 민감 정보가 하드코딩되지 않는 구조를 만드는 게 우선이다.

둘째, AI에 넘기는 범위를 처음부터 좁힌다. 전체 파일이 아니라 문제가 되는 함수, 특정 로그 블록만 복사한다.

셋째, 규칙 필터를 로컬 스크립트로 먼저 만든다. 복잡한 모델 없이도 이메일, IP, 키 패턴만 걸러내는 것만으로도 상당수 케이스를 커버한다.

넷째, 로컬 LLM은 문맥 판단 보조로 선택적으로 추가한다. 미공개 기획 내용이 포함될 가능성이 있는 문서, 업무 메모, 회의 요약본 등이 AI에 넘어갈 때 추가 레이어로 쓰는 식이다.

민감도가 높은 프로젝트라면 처음부터 클라우드 AI 사용 자체를 배제하는 판단이 더 단순하고 명확하다. 로컬 필터는 그 판단을 내리기 애매한 중간 영역을 다룰 때 쓸 수 있는 도구다.