![[Prompture]Toml과 LLM을 활용한 DLP 솔루션3__#0dbcfe_#7d44fe.png](https://oopy.lazyrockets.com/api/v2/notion/fileUrl?src=attachment%3A0afb13c1-5de6-4f8f-910b-e952ba75c0be%3APromptureToml%EA%B3%BC_LLM%EC%9D%84_%ED%99%9C%EC%9A%A9%ED%95%9C_DLP_%EC%86%94%EB%A3%A8%EC%85%983__0dbcfe_7d44fe.png&blockId=22b4e699-7fb0-8091-a52f-e845d807baf0)
1. 배경(Problem)
왜 Prompture를 만들게 되었나요?
•
최근 ChatGPT, Slack GPT, Notion AI 등 다양한 LLM 기반 서비스가 일상화되며, 사용자 입력값에 민감 정보가 노출되는 사례가 증가하고 있습니다.
•
특히 MCP(Multi-Channel Prompt) 툴 시장이 급성장하고 있음에도, 실시간으로 입력값을 점검하고 위험을 차단하는 기능은 부족합니다.
•
기존 API Gateway 방식은 ▲비용 증가 ▲병목 현상 ▲단일 실패지점 등의 한계가 있습니다.
•
따라서 Prompture는 브라우저 단에서 실시간 입력을 감지하고, AI 보안 위협을 사전 차단하는 경량 솔루션으로 기획되었습니다.
2. 서비스 소개(Solution)
Prompture는 사용자의 입력값을 실시간으로 감지하고 위험을 탐지하는 Chrome 확장 프로그램입니다.
•
탐지 대상
◦
민감 정보 (전화번호, 계좌번호 등)
◦
Jailbreak Prompt
◦
Prompt Injection
•
탐지 방식
◦
TOML 기반 룰셋 + 알고리즘 탐지
◦
탐지 점수 기반 UI 알림
◦
위험 임계값 초과 시 입력 자동 제거 및 이력 저장
•
사용자 인터페이스
◦
입력창 자동 훅킹
◦
토스트 알림, 위험 점수 색상 표시
◦
탐지 이력 보기 탭 포함
시연 영상
3. 아키텍처 및 핵심 기능
Prompture Chrome 확장 프로그램의 입력값 처리 흐름을 시각화한 구조입니다.
전체 흐름 요약
1.
사용자 입력 감지
•
사용자의 LLM 입력값을 확장 프로그램이 실시간으로 **후킹(hooking)**합니다.
2.
탐지 및 필터링
•
입력값에 TOML 기반 필터를 적용하여 위험도를 점수화합니다.
•
점수 구간에 따라 분기 처리됩니다:
◦
70점 이상: 차단◦
30~69점: 위험 알림 및 LLM 분별◦
1~29점: 일반 입력 처리3.
결과 처리 및 저장
•
모든 필터링 결과는 로그 페이지에 저장되며, 필요 시 차단 통계로 집계됩니다.
4.
대시보드 및 필터 선택
•
사용자는 대시보드를 통해 탐지 결과를 시각적으로 확인하고, 필터 조건을 선택할 수 있습니다.
핵심 기능
•
입력 실시간 감시: textarea, input 등 자동 감지 및 텍스트 수집
•
TOML 탐지 룰셋 적용: 규칙 기반 필터링
•
알고리즘 점수 탐지: 민감도 계산 및 보정
•
위험도 시각화: // 색상으로 위험도 표시
// 색상으로 위험도 표시•
입력 자동 제거: 임계값 초과 시 입력값 삭제
•
탐지 이력 저장: popup.js에서 탐지 내역 확인 가능
4. 활용 라이브러리 및 개발 환경
경량성과 확장성을 동시에 고려한 기술 스택을 선택했습니다.
개발 환경
•
개발 도구: Visual Studio Code, GitHub
기술 스택
Prompture 프로젝트에서 활용된 주요 기술과 도구들을 아래와 같이 정리했습니다.
기술/도구 | 활용 용도 | 선택 이유 및 특징 |
JavaScript | 메인 프로그래밍 언어 | 크롬 확장 프로그램 개발에 최적화되어 있음 |
Chrome Extension API | 콘텐츠 스크립트, background 통신 | 브라우저 내 실시간 입력값 후킹 및 인터페이스 구현 가능 |
TOML | 룰셋 정의 및 정책 기반 탐지 | 가독성, 유지보수, 확장성이 뛰어남 |
Discord | 팀원 간 커뮤니케이션 및 자료 공유 | 회의, 실시간 피드백, 파일 공유 등 협업 중심 도구 |
Google Chrome | 실행 플랫폼 | 보안 실험용 확장 프로그램 테스트에 사용 |
Llama 3.1 Base (Web LLM) | 맥락성, 의도성 탐지 고도화 | 자연어 기반의 미묘한 우회 패턴(Jailbreak 등)을 탐지하기 위해 탑재 |
ChatGPT 4 | LLM 시나리오 생성 및 테스트 | 탐지 규칙 테스트용 문장 자동 생성 |
Notion | 문서 협업 및 회의록 정리 | 팀 내 지식 공유 및 업무 분담 관리에 활용 |
Github | 소스코드 버전 관리 | 팀 협업 및 히스토리 추적을 위한 Git 기반 플랫폼 |
VS Code | 개발 환경 | 확장 개발 및 TOML 테스트를 위한 가벼운 IDE |
LLM Prompt Filter Algorithm | 입력값을 점수화하여 위험 탐지 | 단순 룰 탐지에서 벗어나 정확도 향상을 위해 도입 |
Zep | 팀원 간 커뮤니케이션 | 회의, 실시간 피드백 등 협업 중심 도구 |
포인트
•
TOML 룰셋 + 알고리즘 점수화 + Web LLM이 결합된 하이브리드 탐지 구조로, 민감정보부터 jailbreak까지 폭넓은 위협을 탐지합니다.
•
Discord + Notion을 함께 사용하여 협업 및 의사결정 흐름을 체계적으로 운영했습니다.
•
Llama 3.1 Base를 로컬 탑재한 Web LLM 구조를 통해 의도성 탐지 성능을 강화했습니다.
5. 트러블 슈팅
Rule-based 기반의 규칙 필터링에 대해서 필요한 양식을 어떻게 프로그램에 전달할 지에 대한 양식이 필요했습니다.
JSON/YAML/TOML 양식이 후보군으로 선정되어 기술 선정을 비교하였습니다.
•
JSON -> 편리한 사용, 프로그램처리 최적 / 주석불가능, 낮은 가독성
•
YAML -> 높은 가독성, 주석가능 / 프로그램처리 복잡, 들여쓰기로 인한 비교적 높은 오류율, 강제된 방식
•
TOML -> 높은 가독성, 주석가능, 프로그램처리 복잡도 중간 / 인지도 낮은 형식, 높은 자유도로 인한 형식에러
이중 저희는 TOML파일이 높은 가독성과 프로그램처리가 가능하며, 주석이 가능하고, 높은 자유도 덕분에 에러를 내더라도 테스트용도로 적합하게 처리가능할 것으로 판단하여, TOML로 선정하였습니다.
LLM을 어떻게 Extension에 넣을 것인가?
특히, LLM은 성능을 매우 많이 필요하여, 단순 확장자용으로 쓰기에는 너무 높은 수준의 성능을 요구하고, Python을 통해 외부 데스크톱 APP과의 연동은 불필요하다고 판단하여 Transformers.js를 사용하기로 하였습니다.LLM은 기본적으로 높은 성능을 요구하므로 4bit 양자화된 모델을 사용하여 메모리 사용률을 낮추었습니다.
1bit-LLM기술은 아직 Web과 연계되지 않았으므로, 현재 사용가능한 4bit 양자화 모델을 사용하였습니다.
•
4bit 양자화 - 높은 기술성숙도, 소스 다양, 완성된 기술존재 / 아직 높은 메모리 사용률, 높은 리소스
•
1bit LLM - 매우 적은 리소스(1/16) , 빠른 추론속도 / 낮은 기술성숙도, 소스부족, 파이썬필요
TinyLLM VS LLAMA 3.1
TinyLLM과 Llama3.1기반의 모델을 두가지 모두 사용해본 결과 한국어가 가능한 모델로 사용하여야 하여 라마기반의 모델을 탑재하였습니다.
webllm.js를 사용하여 기존에 배포되어있는 CDN을 활용하여 누구나 쉽게 extension을 설치하면 자동으로 다운로드와 모델이 설치되고 이를 바탕으로 LLM을 활용이 가능한 환경을 구축합니다.
성능 문제
WebLLM이 사용가능한 환경을 위하여 크롬브라우저에 GPU가속과 4bit 양자화를 하였더라도 너무 높은 성능요구로 모든 프롬프트를 LLM으로 필터링하는 것보단, 최적의 사용성을 위하여 Rule-based와 결합하여, Rule기반의 필터에서 의심되는 프롬프트의 경우에는 LLM을 활용한 필터링을 진행하였습니다. 이를 통해 이전보다 높은 사용성과, 모든 프롬프트를 LLM으로 필터링 하였을때 5번 기준 200~300초걸리던 실행시간이 5번기준 2번의 의심프롬프트를 탐지하여 40초 이내의 필터링시간을 요구하여 사용성을 대폭 개선하였습니다.
가장 문제가 된 코드는, TOML 형식에 대해 모두 처음 다뤄본 방식이라 기존 JSON이나 YAML과 다르고 이를 파싱하는 코드를 직접 다룬 결과 TOML 형식에 \n (줄바꿈)이 들어가 파싱에러가 나오는 것을 찾기까지 오래 걸렸습니다. 이로 인해 TOML 테스트와 Rule-based를 짜는게 Webllm을 구축하는것의 10배이상의 시간이 걸렸습니다.
키워드 기반의 필터링은 빠른 실행시간을 가졌지만, 높은 구축시간과 낮은 정확도로 추가적으로 더욱 많은 테스트를 진행하여 키워드기반에 대한 필터로 점수대만 잘 구축하여 LLM을 활용한다면 높은 탐지율을 보일 수 있을것으로 기대하고 진행하였습니다.
6. 팀 소개
우리는 도롱뇽의 사냥 속도처럼 민감한 입력을 빠르게 감지하고 보호합니다.
팀명: 도롱뇽
이름 | 역할 | 한 줄 소개 |
박민용 | 팀장 | 확장프로그램 초석 개발 및 입력값 후킹 구현 |
이재석 | 팀원 | 웹 LLM 연동 및 .Toml 파일 정제 |
이창재 | 팀원 | .Toml 파일 작성 및 .Toml Rule 신뢰도 검증 |
이솔 | 팀원 | 검증 분류기 구현 및 테스트용 데이터셋 생성 |
안지선 | 팀원 | .Toml 파일 통합 및 프로젝트 관련 법규 수집 |
팀워크 포인트: 정기 스크럼, 역할 분담, 코드 리뷰를 통해 협업 시너지를 극대화했습니다.