룰베이스 다음의 LLM과 지자체 참가자의 AI DLP 수요

토요일 오후 3시, 공공AX 방에서 LLM(대규모 언어 모델)을 어디에 쓸지를 두고 현장의 감각이 모였다. 이 주제에는 105건의 발화가 쌓였다. 시작은 용량 이야기였다. 3시 3분 한 지자체 쪽 참가자가 윈도우 앱은 용량이 커서 HTML과 JS 파일로 만들어 배포하고 있다고 말했다.

3시 6분 같은 참가자가 이를 한 줄로 정리했다.

llm은 정말 룰베이스 따다가 안 되면 최후의 보루 같은 느낌입니다.

룰베이스는 사람이 정한 규칙으로 처리하는 방식을 가리킨다. 이 말은 모델을 먼저 쓰자는 흐름과 반대편에서, 규칙으로 되는 일은 규칙으로 하자는 순서를 제안한 것으로 읽힌다. 같은 참가자는 앞서 3시 정각에 RAG(문서를 찾아 답하게 하는 방식)는 답이 정해진 영역에서만 쓰는 편이 낫겠다고 말했다.

룰베이스 위에 모델을 얹는 설계

3시 7분에는 한 참가자가 자기 쪽 SDK도 기본적인 룰베이스와 모델을 섞어 쓴다고 했다. 이 참가자는 모델을 엣지 케이스, 곧 규칙이 놓치는 예외를 찾는 데 쓴다고 덧붙였다. 3시 8분에는 OCR 모델의 허깅페이스 주소를, 3시 18분에는 한국어 개인정보 탐지 모델의 주소를 따로 올렸다. 이 모델들의 성능은 이 대화에서 검증되지 않았고, 소개 수준에 머문다.

3시 7분, SDK 발언에 앞서 지자체 쪽 참가자는 개인정보를 룰베이스로 먼저 걸러 내고 마지막에 모델로 한 번 더 확인하는 방식을 예로 들었다. 이어서 소형 모델이 나오면 내부에서 쓰기에 실제로 필요하다는 말도 했다. 규칙이 먼저 거르고 모델이 마지막에 확인하는 두 단 구조가 이 대화에서 가장 구체적으로 그려진 설계였다.

지자체가 말한 AI DLP 수요

3시 14분 같은 참가자가 AI DLP, 곧 AI 서비스로 나가는 정보를 막는 도구의 개발 계획이 없는지 물었다. 찾아본 제품은 금액이 부담되고 원하는 기능이 없었다는 설명이 붙었다. 1분 뒤에는 이유가 나왔다.

웹 형태 챗지나 클로드나 이런 건 보안이 전혀 안 되고 있어서

이 참가자는 자신이 보기에 지자체 대부분이 그런 상태라 필요하다고 했고, 개인정보를 잡아내는 일에는 문맥 탐지와 로그가 요구 조건으로 따른다고 설명했다. 3시 16분 또 다른 참가자는 개인정보 탐지 필터링에 sLLM(작은 언어 모델)을 쓰는 방안이 필요하다는 이야기를 매번 해 왔다고 했다. 같은 참가자는 형태소 분석 도구만으로도 어느 정도는 된다고 했으나 인프라에 따라 결과가 크게 달라질 것이라고 덧붙였다.

읽어 보면

이 대화는 새 모델을 소개하는 자리가 아니었다. 룰베이스로 먼저 걸러 내고 모델은 모호한 곳에만 쓴다는 순서를 두 참가자가 각자의 사용 방식으로 설명했다는 점이 눈에 띈다. 지자체에서는 웹 AI 서비스로 나가는 정보를 걸러 줄 도구가 필요하다는 말이 나온 것으로 보인다. 다만 이는 지자체 참가자 한 명의 전언이어서, 지자체 전반의 실태로 읽을 수는 없다.