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

대용량 소스코드를 효율적으로 전달하기 위해 SourceCode Browse MCP를 만들고, ctags로 심볼을 사전 인덱싱한 뒤 tree-sitter로 함수 범위를 파싱했다. 도구는 find_references(), read_definition(), read_source(), get_project_structure()의 4가지로 구성해, AI가 IDE처럼 정의와 참조를 정확히 찾도록 했다.

분석 일관성을 높이기 위해 SAST를 취약점 탐지 도구가 아니라 모든 입력 경로 후보를 추출하는 장치로 바꿨다. semgrep의 taint rule로 untrusted input source와 sink를 모두 뽑아 SARIF로 받고, 필요한 정보만 남겨 JSONL로 다이어트시킨 뒤 연속된 라인은 합쳐 토큰 낭비를 줄였다.

비용과 효율 문제는 Multi-Agent 구조로 풀었다. Discovery 에이전트가 주어진 스니펫만 보고 취약 가능성이 높은 경로를 고르고, Analysis 에이전트가 그 경로를 검증하는 방식으로 바꿨다. 이때 지나치게 엄격하게 걸러내지 않도록 System Prompt에서 "MCP를 가능한 쓰지 말 것", "조금이라도 가능성이 있으면 포함할 것"이라는 trade-off를 명시했고, 그 결과 286개 경로 중 144개를 선별해 27개 취약점을 찾는 데 성공했다.

마지막 벽은 지속 가능성이었다. Cloud Model만으로는 수백 개 서비스에 대한 일일 분석 비용을 감당하기 어려워서, Open Model 후보인 Qwen3:30B, gpt-oss:20B, llama3.1:8B를 비교했다. 샘플 웹 프로젝트로 XSS, IDOR, Deserialize, Path Traversal을 넣은 뒤 정탐률·오탐률·분석률을 측정하고, MCP Tool calling 안정성과 토큰 효율까지 함께 평가해 Qwen3:30B를 선택했다.

Open Model의 불안정한 응답 포맷은 Pydantic과 Instructor로 보완했다. 타입 힌트와 검증으로 출력 스키마를 강제하고, 잘못된 응답은 자동 보정하도록 유도해 비결정성을 줄였다. 결국 핵심은 더 똑똑한 한 번의 추론이 아니라, 정확한 코드 탐색, 후보군 축소, 에이전트 분업, 모델 검증을 조합해 실전에서 계속 돌릴 수 있는 분석 체계를 만드는 데 있었다.