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

 

시작하며

LLM이 다양한 분야에서 활용되고 있는 요즘, 토스에서도 LLM을 업무에 접목해 효율성을 높이고 있다. 그 중 LLM을 이용해 서비스 취약점 분석을 자동화한 경험을 살펴보도록 하겠다.

 

Google의 Project Naptime

구글에는 LLM을 이용해 취약점 분석을 자동화하고 낮잠 시간을 만들자는 Naptime 프로젝트가 있다. 분석가들의 상상속에서만 이뤄지던 것이 실제로 유의미한 결과를 도출할 수 있게 된 것이다. 이를 바탕으로 토스 팀은 개발 여정을 시작하게 된다.

 

첫번째 벽: 대용량 소스코드

대용량 소스코드를 LLM에 넣는 것이 첫번째 문제였다. 토스의 서비스들은 이미 상당한 규모의 소스코드를 가지고 있는데, 이 모든 코드를 LLM의 토큰 한계에 맞추는 것 부터가 쉽지 않았다. 처음에는 RAG(코드를 벡터로 임베딩해서 필요한 부분만 가져오는 방식)를 시도했으나, 코드 간 연관관계를 파악하기 어려워서 Repomix 툴로 전체코드를 압축하는 것도 시도했지만 모든 시도가 토큰 문제로 실패했다. 토큰 문제를 해결한다 해도 Hallucination 문제로 인하여 LLM이 없는 취약점을 만들어낼 수도 있었다.

 

해결책: MCP

LLM Agent가 자유롭게 소스코드를 참조할 수 있는 MCP를 만들면 이를 해결할 수 있었다. 소스코드를 사전에 인덱싱 해두면 LLM이 필요할 때 마다 MCP Tool Calling을 통해 정보를 효율적으로 참조할 수 있다.

이를 위해 개발한 SourceCode Browse MCP는 다음 구조로 동작한다.

- tree-sitter: 소스코드 구문 트리 분석

- ctags: 함수, 변수 정의 위치 인덱싱

- ripgrep: 고속 텍스트 검색

 

두번째 벽: 일관성 없는 결과와 정확도

정확도 문제가 두번째 어려움이었다. 취약점을 잘 찾긴 하나 일관성이 없었다. 이는 LLM을 신뢰할 수 없는 문제로 이어진다.

 

해결책: SAST 도구 - CodeQL, Semgrep

대표적 오픈소스 SAST도구에는 CodeQL, Semgrep가 있다. 

CodeQL의 경우 '프로젝트 빌드 과정 필요, 빌드가 성공되는 Reliable한 DevOps 환경 구축 필요, 빌드 과정에서 상당한 비용 발생, 라이선스 문제' 라는 한계가 있다.

그에 비해 Semgrep의 경우 '빌드 과정 불필요, 적은 비용' 의 특징을 가져 훨씬 효율적이었다.

 

또한 취약점 발견 누락을 방지하기 위해

'SAST로 모든 입력에서 함수로 도달하는 경로를 수집 -> 수집된 경로를 LLM이 전부 분석하는 과정'을 거치게 했더니 일관성 문제를 해결할 수 있었다.

 

세번째 벽: 비용

위에서 모든 경로를 분석하게 했더니 쓸데없는 토큰이 너무 많이 소모되는 문제가 또 생겼다. 

 

해결책: Multi-Agent

비용 문제는 Multi-Agent 시스템으로 해결할 수 있었다. 에이전트 구성은 다음과 같다.

- Supervisor

- Discovery

- Analysis

이렇게하니 Discovery 에이전트가 거름망 역할을 해주어 실질적으로 취약점 분석이 필요한 경로만 Analysis 에이전트가 처리함으로서 비용이 줄었다.

 

네번째 벽: 지속 가능성

이 분석을 하루에 3번 수행하게 되면 한달에 810만원이라는 큰 비용이 들게된다. 이는 결코 지속가능한 비용이 아니다.

 

해결책: Open Model로 전환

Cloud Model이 아니라 Open Model을 사용하고, 성능과 안정성을 위한 추가 노력을 더하여 LLM 비용을 발생하지 않도록 한다.

시스템 프롬프트와 Human Message를 더 엄격하고 체계적으로 개선하고, 더 작은 task 단위로 분할하여 처리하며 다양한 예외 상황에 대한 처리 로직을 강화한다.

 

후보 모델 선별과 ROI 비교

취약점 분석에 적합하고 MCP 사용이 가능한 모델을 찾아보 결과 3개 모델이 나왔다.

- Qwen3:30B

- gpt-oss:20B

- llama3.1:8B

분석 테스트를 진행했더니 결과는 다음과 같았다.

비용과 정확도를 종합적으로 고려했을 때 Qwen3:30B가 가장 준수한 성능을 보였다.

 

마치며

결과적으로 정확도 95%이상의 LLM 취약점 분석 자동화를 구현할 수 있었다. 토스 팀은 이 프로젝트를 통해 '기술적으로 가능한 것'과 '실제로 운영 가능한 것' 사이에는 큰 차이가 있으며 실제 서비스에 적용하기 위해 비용, 성능, 안정성, 지속 가능성을 모두 고려한 종합적인 설계가 필요하다는 것을 배웠다. 토스는 이런 실용적인 AI 활용 사례들을 많이 만들어나가며, 도움이 되는 기술을 만드는 데 집중하겠다는 포부를 밝혔다.

 

 

[출처]

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

https://toss.tech/article/43381