핵심요약
LLM을 활용한 서비스 취약점 분석 자동화 프로젝트는 대용량 코드 처리, 결과 일관성, 비용 문제 등을 겪었으나, MCP, SAST 연동, Multi-Agent, Open Model 전환 등을 통해 정확도 95% 이상을 달성했습니다.
LLM을 활용한 서비스 취약점 분석 자동화: 문제점과 해결 과정
본 글은 LLM을 활용하여 서비스 취약점 분석을 자동화하는 프로젝트의 경험을 공유합니다. Google의 Project Naptime에서 영감을 받아 시작되었으나, 대용량 소스코드 처리, 일관성 없는 결과, 비용, 지속 가능성 등 여러 현실적인 문제에 직면했습니다. 이러한 문제들을 해결하기 위해 MCP(Model Context Protocol), SAST 도구(Semgrep)와의 연동, Multi-Agent 시스템, 그리고 Open Model(Qwen3:30B) 전환 등의 기술적 접근을 시도했습니다.
주요 문제점 및 해결 과정
1. 대용량 소스코드 처리 문제
- 문제: LLM의 토큰 한계로 인한 대용량 소스코드 입력의 어려움, RAG 및 Repomix 시도 실패, Hallucination 발생.
- 해결책: MCP(Model Context Protocol) 기반의 SourceCode Browse MCP 구현. tree-sitter, ctags, ripgrep을 활용하여 LLM이 소스코드를 효율적으로 참조하도록 함.
2. 결과의 일관성 및 정확도 문제
- 문제: Claude-Sonnet-4 모델 사용 시 취약점 탐색 결과의 일관성 부족 (누락, 오탐).
- 해결책: SAST 도구(Semgrep)와 연동. 모든 Source→Sink 경로를 수집하고 LLM이 분석하도록 하여 취약점 누락 방지.
3. 비용 효율성 문제
- 문제: 모든 입력 경로 분석으로 인한 불필요한 토큰 소모 및 비용 증가.
- 해결책: Multi-Agent 시스템 도입 (Supervisor, Discovery, Analysis). Discovery 에이전트가 취약점 가능성 높은 경로만 선별하여 Analysis 에이전트의 처리 효율 증대.
4. 지속 가능성 문제
- 문제: 높은 운영 비용 (OpenAI Cloud Model 사용 시).
- 해결책: Open Model(Qwen3:30B)로 전환하여 자체 호스팅. 비용 효율성과 성능 사이의 균형을 고려하여 Qwen3:30B 모델을 최종 선택하고, 시스템 프롬프트 개선, Task 분할, 예외 처리 강화 등 성능 보완 작업 수행.
최종 결과 및 교훈
- 달성 성과: 정확도 95% 이상의 LLM 취약점 분석 자동화 구현.
- 핵심 교훈: '기술적으로 가능한 것'과 '실제로 운영 가능한 것' 사이의 차이를 인지하고, 비용, 성능, 안정성, 지속 가능성을 종합적으로 고려한 설계의 중요성 강조.
- 향후 전망: 토스에서는 실용적인 AI 활용 사례를 지속적으로 만들어갈 예정.
- 2편에서는 실제 구현 방법에 대한 상세 내용을 공유할 예정입니다.
