LLM을 이용한 서비스 취약점 분석 자동화 1편을 읽고나서

오늘은 토스 Security Researcher 표상영님의 LLM을 이용한 서비스 취약점 분석 자동화 1편을 읽었다. 요즘 인공지능이 보안 영역까지 이렇게 깊숙하게 들어왔다는 것이 신기하기도 하고, 솔직히 엄청 실용적인 방향이라고 느꼈다.

LLM + 보안

평소에도 LLM이 드라마 대본 요약이나 코드 리뷰, 문서 자동화 등엔 많이 쓰인다고 생각했었다. 근데 취약점 분석 자동화까지 바로 실전 적용하는 건 실제론 쉽지 않을 것이라고 생각했다. 보안 업무는 조금 실수해도 바로 위험이 커지는 분야라서, 자동화에 대한 신뢰를 얻기가 생각보다 어렵다는 걸 잘 집어냈다. ‘정말 가능할까?’에서 ‘진짜 가능하구나!’로 ai를 대하는 태도가 바뀐 시대다.

대용량 소스코드 입력의 한계와 MCP

개발하는 입장에서 대규모 코드의 처리는 항상 골치 아픈 문제고, LLM은 아무리 좋아도 입력 토큰 한계가 있기 마련이다. 코드를 RAG로 벡터화하거나, Repomix로 압축해도 결국 토큰을 넘길 수 없다는 한계가 아닐까?

그런데 tree-sitter, ctags, ripgrep 등으로 MCP을 만들어서 LLM의 소스코드 접근성을 올렸다는 건 정말 똑똑한 해결책 같다. LLM이 소스코드 전체가 아니라 필요한 부분만 찾아볼 수 있게 해준다는 게 앞으로 모든 대형 프로젝트에 적용될 수 있는 패턴이 아닌가라는 생각이 든다.

정확도, 일관성 문제

나는 LLM이 매번 동일 조건에서 일관된 답을 내놓지 못한다는 게 꽤 큰 리스크라고 생각한다. 이번 글에서도 10개 취약점 중 8개, 10개, 7개 들쭉날쭉하게 찾는다는 게 확실히 현업에선 치명적일 수 있으니까. 그래서 SAST로 입력→함수 경로를 최대한 뽑아내고 이걸 LLM에게 다시 분석시키는 구조가 꽤 괜찮은 방법론이라고 생각한다. LLM은 인간스러운 통합적 검토를 하고 세미정적 분석 도구는 커버리지와 일관성을 담당하는 식으로 상호보완하는 이 구조가 앞으로 더 널리 사용되지 않을까?

특히 CodeQL이 강력하지만 현실적으로 비용이나 빌드 필요성, 라이선스 문제까지 고민한다는 점에서 "조직 내 자원의 현실"을 정말 솔직하게 드러낸 포스트 같았다.

비용 절감, 지속가능성

운영 비용, 클라우드 요금, 자원 스케일업 등은 스타트업이든 대기업이든 결국 맞닥뜨리게 되는 문제일텐데, LLM 한 번에 300원씩 나가면 당장은 시범 서비스라도 규모 커지면 남는 게 없는 구조라는 실제 계산이 드러나 현실적이었다.

그래서 Open Model(Qwen3:30B 등)로 옮기고 직접 호스팅해서 토큰 비용을 줄이려 했다는 결론이 꽤 논리적이었다. 그 과정에서 여러 오픈모델 테스트하면서 정확도와 커버리지, 토큰 수를 정량적으로 비교한 부분이 특히나 인상 깊었다. GPT의 성능을 추종하는 오픈모델들이 실제 업무에서는 어느 정도까지 쓸모가 있는지 계속 실험해본다는 점은 앞으로 인프라 운영이나 내부 보안 자동화 솔루션 만들 때 참고할 만한 실제 사례라고 느꼈다.

궁금한 점

• 아무리 MCP, Multi-Agent 시스템, Open Model 등을 도입해도 결국 "판단의 최종 책임"은 누구에게 있을까? LLM이 취약점을 제대로 찾았다 해도 잘못된 분석이나 놓친 것에 대한 의사결정은 사람이 해야 하니까. 어느 단계까지 자동화의 신뢰도를 올릴 수 있을지 궁금했다.
• 기존 SAST만으로 탐지율 95% 이상 나올 때 LLM이 추가로 찾아내는 "실전적 취약점"이나 휴먼라이크 오류를 얼마나 더 잡아내는지 정량 지표가 있었으면 좋겠다는 생각도 들었다.
• 정확도 95%라고 해도 서비스 환경이 변화하거나 신규 취약점 유형이 등장할 때 얼마나 민첩하게 시그니처 + LLM 프롬프트를 조정할 수 있을지 실무 경험이 좀 더 궁금해졌다.

참고 문헌

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