LLM을 이용한 서비스 취약점 분석 자동화 #1

Context

LLM으로 서비스 취약점을 자동으로 분석하려 했으나, 대용량 소스코드의 토큰 한계와 Hallucination, 결과의 일관성 부족, 그리고 고비용이 순차적으로 발목을 잡았다. 토스의 수백 개 프로젝트에서 하루 3회 분석 시 일 27만원(월 810만원) 수준의 비용이 발생해 지속 가능성을 위협했다.

Technical Solution

• 대용량 코드 처리: tree-sitter + ctags + ripgrep으로 소스코드를 사전 인덱싱하고, MCP를 통해 LLM이 필요한 부분만 Tool Calling으로 참조하도록 변경
• 일관성 보강: SAST 도구(Semgrep)로 모든 Source→Sink 경로를 자동 수집하고, 수집된 경로를 LLM이 빠짐없이 분석하도록 구조화
• 비용 최적화: Multi-Agent 시스템을 도입해 Supervisor가 지시, Discovery 에이전트가 취약점 가능성 높은 경로만 선별, Analysis 에이전트가 실제 분석 수행
• 모델 선정: Claude-Sonnet-4에서 오픈 모델로 전환하기 위해 Qwen3:30B, gpt-oss:20B, llama3.1:8B을 비교평가 후 Qwen3:30B 선택(분석률 100%, 정탐률 100%, 오탐률 35.7%)
• 성능 보완: 오픈 모델의 성능 저하를 보정하기 위해 시스템 프롬프트 강화, 작은 task 단위로 분할 처리, 예외 상황 처리 로직 강화

Impact

• 최종 취약점 분석 정확도: 95% 이상
• 비용 기준: gpt-oss:20B 대비 Input 토큰 60%, Output 토큰 41% 수준으로 감소(Qwen3:30B 기준)
• IDOR 취약점 테스트 결과: 14개 경로 중 14개 분석(100%), 실제 취약점 3개 모두 발견(100% 정탐률)

Key Takeaway

LLM 기술적으로 가능한 것과 실제 운영 가능한 것 사이의 간극을 무시하면 안 된다. 비용, 성능, 안정성, 지속 가능성을 종합적으로 고려한 아키텍처 설계가 Cloud Model의 성능 대비 Open Model의 낮은 정확도를 보완할 수 있다.