.jpg)
1. 힐링페이퍼 한종훈 엔지니어의 ‘LLM 기반 보안 스캐너’ 개발 심층 리포트
2. 문맥(Context) 못 읽는 SAST의 한계, “SQL 인젝션 오탐 잡으려다 ‘원 샷’ 전략 발견”
3. ‘이론적 완벽함’ 버리고, ‘정규식+단일 프롬프트’ 실용주의 택해
[보안뉴스 조재호 기자] “보안 도구가 뱉어내는 경보의 절반은 잘못된 탐지(오탐·False Positive)입니다. 보안팀은 지치고, 개발팀 신뢰는 떨어지죠. 우리는 이 고질적 문제를 풀기 위해 화려한 ‘멀티 에이전트’ 대신 가장 단순한 ‘원 프롬프트’를 택했습니다.”
미용 의료 플랫폼 ‘강남언니’ 운영사 힐링페이퍼의 한종훈 보안 엔지니어는 최근 OWASP 서울 챕터 세미나에서 ‘LLM 기반 SAST 스캐너 구축기’를 공개하며 이같이 말했다. 그는 기존 정적 애플리케이션 보안 테스트(SAST·Static Application Security Testing)의 기술적 한계를 분석하고, 이를 인공지능(AI)으로 보완하는 과정에서 겪은 시행착오와 해법을 공유했다.
SAST의 태생적 한계: 모양(Syntax)은 보지만 의미(Semantics)는 모른다
한 엔지니어는 먼저 SAST의 작동 원리와 한계를 짚었다. SAST는 소스코드를 실행하지 않고 분석하는 도구로 △구문 분석을 통한 코드 구조 파악 AST △사전 정의된 위험 패턴을 찾는 패턴 매칭 △데이터의 흐름을 추적하는 분석 엔진 등 3단계로 작동한다.
문제는 SAST가 ‘코드의 문맥(Context)’을 이해하지 못한다는 점이다. 구체적 실패 사례로 ‘SQL 인젝션 오탐’을 들었다.
한 엔지니어는 “예를 들어 개발자가 DatabaseService라는 자체 헬퍼 클래스를 만들어 내부적으로 안전한 PreparedStatement 처리를 해뒀다고 치면, SAST는 내부 로직을 모른 채 겉보기에 파라미터가 바인딩되지 않은 쿼리가 호출됐다는 이유로 취약점이라고 판단해 경보를 울린다”고 말했다.
이어 “권한 검증 로직도 마찬가진”라며 “Spring Security 필터 같은 상위 레벨에서 인증을 거쳤음에도 SAST는 이 함수 내에 권한 검수 코드가 없다는 이유로 민감 정보에 무단 접근했다고 판단한다”고 말했다.
이러한 오탐이 쌓이면 개발자는 보안 경보를 ‘노이즈’로 취급해 무시하고, 진짜 취약점까지 놓치는 보안 공백이 발생할 수 있다.
화려한 실패: “많으면 더 똑똑할 줄 알았던 멀티 에이전트”
SAST의 문맥 문제를 해결하기 위해 초기에는 최신 트렌드였던 ‘멀티 에이전트’(Multi-Agent) 시스템을 도입했다. 랭체인(LangChain)을 활용해 △코드를 파싱하는 AST 에이전트 △데이터 흐름을 추적하는 ‘Dataflow 에이전트’ △취약점을 판단하는 ‘Findings 에이전트’ △결과를 정리하는 ‘Result 에이전트’ 등 4단계로 역할을 쪼개 협업하는 구조였다.
이론적으로 완벽했지만, 실전에서는 ‘실패’였다. 한 엔지니어는 “에이전트끼리 데이터를 주고받는 과정에서 복잡도가 커졌고, 에이전트마다 취약점 등급을 다르게 판단해 일관성이 깨졌다”고 말했다. 4단계를 거치다 보니 스캔 시간도 늘어났고, 불필요한 호출로 비용도 치솟았다. 심지어 LLM이 코드 라인 번호를 헷갈려 엉뚱한 곳을 지적하는 문제도 빈번했다.
복잡함 버리고 ‘원샷’ 전략으로
앞선 실패를 계기로 복잡한 에이전트를 모두 폐기하고 ‘원샷 컨텍스트’ 전략으로 선회했다. 복잡한 추론 과정을 하나의 ‘골든 프롬프트’(Golden Prompt)에 담아 LLM에 한 번에 묻는 방식이다.
이 전략의 핵심은 ‘정규식(Regex)을 이용한 팩트 주입’이었다. 한 엔지니어는 “LLM에 코드 분석을 통째로 맡기면 환각(Hallucination)이 발생한다”며 “함수의 시작과 끝, Import 관계, 클래스 구조 등 ‘팩트’(Fact) 데이터는 정규식으로 미리 파싱해서 프롬프트에 강제로 주입했다”고 설명했다.
LLM은 창의적 추론만 담당하고, 구조 분석은 정확한 알고리즘(정규식)이 담당하는 하이브리드 접근법이다. 또 프롬프트 내 △보안 전문가 정체성 부여 △취약점 등급 기준 명시 △실행 가능한 수정 코드(Code Snippet) 포함 등 구체적 지시시항을 통합해 LLM의 추론 능력을 극대화했다.
비용 1/3 절감, 개발자가 먼저 찾는 보안 도구화
전략 수정 후 성과는 극적이었다. 스캔 시간은 평균 5분에서 2.5분으로 절반 단축됐고, LLM 호출 횟수가 줄어 비용이 3분의 1 수준으로 내려갔다.
가장 큰 변화는 개발자들 반응이다. 한 엔지니어는 “기존 SAST가 ‘이거 위험해!’라고 소리만 질렀다면, LLM 스캐너는 ‘이 코드는 A 파일의 B 함수와 연결돼 위험하니, 이렇게 수정하세요’라고 친절하게 설명해줬다”며 “개발자들이 먼저 피드백을 주고 자발적으로 코드를 수정하는 선순환이 일어났다”고 말했다.
보안 실무자를 위한 조언: 작게(Small Start) 시작하라
한 엔지니어는 보안 자동화를 꿈꾸는 실무자들에게 “완벽한 시스템을 상상하기 보다는 작게 시작하라(Small Start)”고 조언했다. 그는 봇 계정이 생성한 PR은 스캔에서 제외해 비용을 아낀다거나 사내 아키텍처 문서를 프롬프트에 녹여 문맥 이해도를 높이는 등의 실질적 팁을 공유했다.
향후 계획에 대해선 “현재 정규식으로 처리하는 파식 로직을 ‘Tree-sitter’ 기반의 AST 파싱으로 고도화하고, 스캔 결과를 DB화해 대시보드로 관리할 예정”이라며 “개발자 피드백을 다시 학습에 반영하는 ‘휴먼 인 더 루프’(인간개입·Human in the loop) 체계를 완성해 상호작용 과정을 완성하는 것이 목표”라고 말했다.
이날 세미나는 OWASP 서울 지부의 월례 행사로 열렸다. DevSecOps를 단순한 도구 도입이 아닌 실질적으로 작동하는 자동화 시스템과 지속 가능한 보안 문화로 구현한 사례를 공유했다.
[조재호 기자(sw@boannews.com)]
2. 문맥(Context) 못 읽는 SAST의 한계, “SQL 인젝션 오탐 잡으려다 ‘원 샷’ 전략 발견”
3. ‘이론적 완벽함’ 버리고, ‘정규식+단일 프롬프트’ 실용주의 택해
[보안뉴스 조재호 기자] “보안 도구가 뱉어내는 경보의 절반은 잘못된 탐지(오탐·False Positive)입니다. 보안팀은 지치고, 개발팀 신뢰는 떨어지죠. 우리는 이 고질적 문제를 풀기 위해 화려한 ‘멀티 에이전트’ 대신 가장 단순한 ‘원 프롬프트’를 택했습니다.”
[자료: 생성형 AI 이미지]
미용 의료 플랫폼 ‘강남언니’ 운영사 힐링페이퍼의 한종훈 보안 엔지니어는 최근 OWASP 서울 챕터 세미나에서 ‘LLM 기반 SAST 스캐너 구축기’를 공개하며 이같이 말했다. 그는 기존 정적 애플리케이션 보안 테스트(SAST·Static Application Security Testing)의 기술적 한계를 분석하고, 이를 인공지능(AI)으로 보완하는 과정에서 겪은 시행착오와 해법을 공유했다.
SAST의 태생적 한계: 모양(Syntax)은 보지만 의미(Semantics)는 모른다
한 엔지니어는 먼저 SAST의 작동 원리와 한계를 짚었다. SAST는 소스코드를 실행하지 않고 분석하는 도구로 △구문 분석을 통한 코드 구조 파악 AST △사전 정의된 위험 패턴을 찾는 패턴 매칭 △데이터의 흐름을 추적하는 분석 엔진 등 3단계로 작동한다.
문제는 SAST가 ‘코드의 문맥(Context)’을 이해하지 못한다는 점이다. 구체적 실패 사례로 ‘SQL 인젝션 오탐’을 들었다.
한 엔지니어는 “예를 들어 개발자가 DatabaseService라는 자체 헬퍼 클래스를 만들어 내부적으로 안전한 PreparedStatement 처리를 해뒀다고 치면, SAST는 내부 로직을 모른 채 겉보기에 파라미터가 바인딩되지 않은 쿼리가 호출됐다는 이유로 취약점이라고 판단해 경보를 울린다”고 말했다.
이어 “권한 검증 로직도 마찬가진”라며 “Spring Security 필터 같은 상위 레벨에서 인증을 거쳤음에도 SAST는 이 함수 내에 권한 검수 코드가 없다는 이유로 민감 정보에 무단 접근했다고 판단한다”고 말했다.
이러한 오탐이 쌓이면 개발자는 보안 경보를 ‘노이즈’로 취급해 무시하고, 진짜 취약점까지 놓치는 보안 공백이 발생할 수 있다.
화려한 실패: “많으면 더 똑똑할 줄 알았던 멀티 에이전트”
SAST의 문맥 문제를 해결하기 위해 초기에는 최신 트렌드였던 ‘멀티 에이전트’(Multi-Agent) 시스템을 도입했다. 랭체인(LangChain)을 활용해 △코드를 파싱하는 AST 에이전트 △데이터 흐름을 추적하는 ‘Dataflow 에이전트’ △취약점을 판단하는 ‘Findings 에이전트’ △결과를 정리하는 ‘Result 에이전트’ 등 4단계로 역할을 쪼개 협업하는 구조였다.
이론적으로 완벽했지만, 실전에서는 ‘실패’였다. 한 엔지니어는 “에이전트끼리 데이터를 주고받는 과정에서 복잡도가 커졌고, 에이전트마다 취약점 등급을 다르게 판단해 일관성이 깨졌다”고 말했다. 4단계를 거치다 보니 스캔 시간도 늘어났고, 불필요한 호출로 비용도 치솟았다. 심지어 LLM이 코드 라인 번호를 헷갈려 엉뚱한 곳을 지적하는 문제도 빈번했다.
복잡함 버리고 ‘원샷’ 전략으로
앞선 실패를 계기로 복잡한 에이전트를 모두 폐기하고 ‘원샷 컨텍스트’ 전략으로 선회했다. 복잡한 추론 과정을 하나의 ‘골든 프롬프트’(Golden Prompt)에 담아 LLM에 한 번에 묻는 방식이다.
이 전략의 핵심은 ‘정규식(Regex)을 이용한 팩트 주입’이었다. 한 엔지니어는 “LLM에 코드 분석을 통째로 맡기면 환각(Hallucination)이 발생한다”며 “함수의 시작과 끝, Import 관계, 클래스 구조 등 ‘팩트’(Fact) 데이터는 정규식으로 미리 파싱해서 프롬프트에 강제로 주입했다”고 설명했다.
LLM은 창의적 추론만 담당하고, 구조 분석은 정확한 알고리즘(정규식)이 담당하는 하이브리드 접근법이다. 또 프롬프트 내 △보안 전문가 정체성 부여 △취약점 등급 기준 명시 △실행 가능한 수정 코드(Code Snippet) 포함 등 구체적 지시시항을 통합해 LLM의 추론 능력을 극대화했다.
비용 1/3 절감, 개발자가 먼저 찾는 보안 도구화
전략 수정 후 성과는 극적이었다. 스캔 시간은 평균 5분에서 2.5분으로 절반 단축됐고, LLM 호출 횟수가 줄어 비용이 3분의 1 수준으로 내려갔다.
가장 큰 변화는 개발자들 반응이다. 한 엔지니어는 “기존 SAST가 ‘이거 위험해!’라고 소리만 질렀다면, LLM 스캐너는 ‘이 코드는 A 파일의 B 함수와 연결돼 위험하니, 이렇게 수정하세요’라고 친절하게 설명해줬다”며 “개발자들이 먼저 피드백을 주고 자발적으로 코드를 수정하는 선순환이 일어났다”고 말했다.
보안 실무자를 위한 조언: 작게(Small Start) 시작하라
한 엔지니어는 보안 자동화를 꿈꾸는 실무자들에게 “완벽한 시스템을 상상하기 보다는 작게 시작하라(Small Start)”고 조언했다. 그는 봇 계정이 생성한 PR은 스캔에서 제외해 비용을 아낀다거나 사내 아키텍처 문서를 프롬프트에 녹여 문맥 이해도를 높이는 등의 실질적 팁을 공유했다.
향후 계획에 대해선 “현재 정규식으로 처리하는 파식 로직을 ‘Tree-sitter’ 기반의 AST 파싱으로 고도화하고, 스캔 결과를 DB화해 대시보드로 관리할 예정”이라며 “개발자 피드백을 다시 학습에 반영하는 ‘휴먼 인 더 루프’(인간개입·Human in the loop) 체계를 완성해 상호작용 과정을 완성하는 것이 목표”라고 말했다.
이날 세미나는 OWASP 서울 지부의 월례 행사로 열렸다. DevSecOps를 단순한 도구 도입이 아닌 실질적으로 작동하는 자동화 시스템과 지속 가능한 보안 문화로 구현한 사례를 공유했다.
[조재호 기자(sw@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
조재호기자 기사보기
