'닷핵 컨퍼런스 2026'에서 키노트 세션을 진행하고 있는 '타일러 나이스완더(Tyler Nighswander) 티오리(Theori) 연구원'. (출처=티오리)

“AI가 취약점 다 찾는다? 아직 아냐”…해커가 본 LLM 보안의 현실

“대규모언어모델(LLM)이 소프트웨어 보안 분야에서 실제 취약점 탐지 도구로 빠르게 존재감을 키우고 있지만, 모델 하나만으로 대형 코드베이스의 모든 취약점을 찾아내는 ‘만능 상자’는 아직 아닙니다.”

7일부터 8일까지 서울 코엑스에서 열린 ‘닷핵 컨퍼런스 2026’의 키노트 연사로 나선 타일러 나이스완더(Tyler Nighswander) 티오리(Theori) 연구원은 “지금 중요한 것은 모델 자체보다, LLM이 흔들리지 않도록 만드는 구조와 절차를 만드는 것”이라고 진단했다.

나이스완더 연구원은 이날 ‘LLMs for Software Security’를 주제로 한 발표에서 “LLM이 이미 실제 소프트웨어 취약점 탐지에 의미 있는 결과를 내고 있다”며 “다만, 코드를 통째로 넣고 모든 버그를 찾아달라고 하는 식으로는 문제가 풀리지 않으며, 여전히 사람의 가이드와 평가, 작업 분해가 필요하다”고 말했다.

LLM만으로는 부족AI 보안 취약점 탐지의 한계

나이스완더 연구원이 먼저 짚은 것은 ‘LLM의 구조적 한계’다. 그는 “대표적인 문제가 컨텍스트 윈도우다. 리눅스 커널 같은 대형 프로젝트는 약 4억2000만 토큰 규모인데, 현재 상위권 모델이 한 번에 다룰 수 있는 범위는 이보다 훨씬 작다”며 “더 큰 문제는 단순히 많이 입력할 수 있느냐가 아니라, 컨텍스트가 길어질수록 성능이 떨어진다는 점”이라고 설명했다. 이어 “특히, 1만 토큰 이상의 특정 작업에서는 성능 저하가 나타난다”고 덧붙였다.

‘에이전트의 불안정성’도 한계로 지목했다. “모든 버그를 찾아라”와 같이 범위가 크고 모호한 지시를 줄수록, 에이전트는 중간에 길을 잃거나 지침을 놓치기 쉽다. 반복적인 멀티턴 환경(LLM과 여러 번 대화를 주고받으며 맥락을 유지하는 상호작용 방식)에서는 컨텍스트가 커지고 불필요한 정보가 쌓이면서 성능이 더 흔들릴 수 있다고 봤다. 여기에 LLM의 고질병인 환각(할루시네이션) 문제도 여전히 남아 있다. 그는 “환각은 단기간에 사라질 문제가 아니라, 전제로 두고 다뤄야 할 숙제에 가깝다”고 설명했다. 이 때문에 지금의 LLM 보안 활용은 완전한 자동화라기보다, 모델의 강점을 살리되 약점을 제어하는 방향으로 진화하고 있다는 게 그의 진단이다.

나이스완더 연구원은 “실제로 현업에서는 한 번에 전체 코드베이스를 맡기기보다, 파일별로 나눠 보게 하고 나온 결과를 다시 사람이 추려보는 방식이 더 현실적인 활용법”이라고 말했다.

‘닷핵 컨퍼런스 2026’에서 키노트 세션을 진행하고 있는 ‘타일러 나이스완더(Tyler Nighswander) 티오리(Theori) 연구원’

해답은 스캐폴딩작업 쪼개고 검증 더하는 구조

나이스완더 연구원은 LLM의 한계를 보완하는 해법으로 ‘스캐폴딩(scaffolding)’을 제시했다. 스캐폴팅은 건축 현장에서 구조물을 임시로 받쳐주는 지지대를 뜻하는 말인데, 여기서는 LLM이 엉뚱한 방향으로 가지 않도록 하기 위한 각종 보조 장치를 가리킨다. 프롬프트, 사용할 도구, 에이전트 구조, 가드레일, 검증 절차 등이 모두 여기에 포함된다.

초기 챗GPT가 사실상 텍스트 입출력만 하는 단순 구조였다면, 지금의 AI 시스템은 검색·계산·쉘·테스트 같은 도구와 각종 점검 장치를 추가하면서 성능을 높이고 있다.

나이스완더 연구원은 “도구는 많을수록 좋지 않다”고 설명했다. 코드 분석을 시키는 상황에서 코드 읽기나 검색 도구는 유용하지만, 맥락과 맞지 않는 도구까지 한꺼번에 쥐여주면 오히려 모델이 혼란을 겪는다는 설명이다. 그는 “필요 없는 도구는 선택지만 늘리고 성능만 깎는다”며 “결국 핵심은 가능한 모든 도구를 제공하는 것이 아니라, 해당 작업에 꼭 필요한 최소 도구만 주는 데 있다”고 강조했다.

그가 제시한 실전형 방식은 ‘파이프라인 구조’다. 먼저 전통적인 정적 분석 도구로 거대한 코드베이스를 작은 단위로 쪼갠다. 이후 LLM이 각 조각을 좁은 범위에서 분석하게 하고, 다음 단계에서 보고서를 다시 검토하도록 한다. 코드를 실행해 검증할 수 있는 환경이라면 마지막에는 개념증명(PoC)까지 작성해 실제 취약점인지 확인한다. 이렇게 하면 확장성과 신뢰성을 동시에 높일 수 있고, 오탐은 뒤 단계에서 걸러내며 탐지되지 않은 부분이 생겼을 때도 어느 구간에서 놓쳤는지 추적하기 쉬워진다.

또 흥미로운 대목은, LLM이 규칙으로 명시되지 않은 보안 맥락까지 이해할 수 있다는 설명이었다. 그는 금융 애플리케이션 사례를 들며, 사용자가 자기 계좌로 송금했을 때 잔액이 오히려 늘어나는 로직 버그를 예로 들었다. 단순히 숫자가 늘어났다는 사실만으로는 문제가 아닐 수 있지만, 그것이 게임 점수가 아니라 은행 잔액이라면 보안상 치명적인 오류가 된다. 이런 문맥적 판단은 전통적 규칙 기반 도구보다 LLM이 상대적으로 강점을 보이는 영역이다.

물론 그는 “아직 오탐과 미탐이 완전히 해결된 단계는 아니다”라고 선을 그었다. 다만 “오탐도 단순한 오류라기보다 실제로는 수정 가치가 있는 근접한 결과로 나오는 경우가 있고, 미탐은 AI 모델과 스캐폴딩이 좋아질수록 줄어들고 있다”고 평가했다.

끝으로 그는 “결국, LLM의 보안 취약점 탐지는 보안 연구자를 대체하는 기술이라기보다, 연구자의 도메인 지식과 기존 보안 도구를 다시 조합하게 만드는 기술”이라고 정리했다.

글. 바이라인네트워크
<곽중희 기자>god8889@byline.network

일간 바이라인 구독하기

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다


The reCAPTCHA verification period has expired. Please reload the page.