VulnHunter, 보안 에이전트가 코드리뷰에 들어온다

금융사가 보안 에이전트를 공개했다는 신호

Capital One은 VulnHunter를 오픈소스 AI 코드 보안 도구이자 agentic reasoning workflow를 쓰는 도구로 소개했다. 금융사는 규제와 보안 요구가 높은 업종이다. 그런 조직이 내부 보안 자동화 경험을 공개한다는 것은 AI 코드 보안이 단순 데모를 지나 개발 프로세스의 일부가 되고 있다는 신호다.

VulnHunter의 의미는 "LLM이 취약점을 찾는다"는 한 줄보다 넓다. 보안팀은 이미 SAST, SCA, 시크릿 스캔, IaC 스캔을 쓴다. 문제는 경고가 너무 많고, 실제 위험과 코드 맥락을 연결하기 어렵다는 점이다. 에이전트형 도구는 이 빈틈을 노린다. 코드베이스를 읽고, 의심 지점을 설명하고, 공격 경로와 수정 방향을 자연어와 코드 근거로 묶는다.

정적 분석과 LLM 분석은 대체가 아니라 조합이다

전통적인 정적 분석은 빠르고 결정적이다. 하지만 비즈니스 로직, 권한 흐름, 여러 파일에 걸친 입력 검증 누락처럼 문맥이 필요한 버그에는 약하다. LLM 에이전트는 이런 문맥을 읽는 데 강점이 있지만, 오탐과 과신 위험이 있다. 따라서 실무 조합은 명확하다. 정적 분석이 넓게 후보를 만들고, 에이전트가 맥락을 설명하며, 인간 리뷰어가 최종 판정한다.

OWASP Top 10과 CISA의 Secure by Design은 보안 책임을 개발 초기로 당기라고 말한다. AI 보안 에이전트는 이 방향과 맞물린다. PR 단계에서 "이 입력이 어디서 오고, 어떤 권한 경계를 넘어가며, 어떤 테스트가 빠졌는지"를 설명할 수 있다면 개발자는 사후 취약점 티켓보다 빨리 고친다.

개발자 경험이 승부처다

보안 도구는 정확해도 개발자가 싫어하면 실패한다. PR마다 긴 자연어 경고를 남기거나, 재현 불가능한 취약점명을 붙이면 팀은 곧 무시한다. 좋은 보안 에이전트는 근거 파일, 입력 경로, 실패 조건, 최소 수정안, 회귀 테스트 제안을 짧게 남겨야 한다. 에이전트 시대 API가 말한 명시적 계약은 보안 리뷰에도 그대로 적용된다.

한국 기업은 특히 망분리, 개인정보, 금융 규제 때문에 외부 코드 전송이 어렵다. 이 때문에 로컬 또는 전용 VPC에서 돌아가는 에이전트 보안 도구 수요가 커질 수 있다. Bonsai 27B 로컬 에이전트와 Rowboat 로컬 우선 AI 동료의 흐름은 보안 코드리뷰에도 중요하다. 코드와 시크릿이 외부로 나가지 않는 구조가 구매의 전제이기 때문이다.

한국 보안 스타트업의 기회

범용 코드 보안 에이전트 시장은 글로벌 플레이어와 경쟁해야 한다. 하지만 한국어 개발 문화, 국내 클라우드, 금융권 내부 표준, 전자금융감독규정, 공공 조달 문서에 맞춘 보안 리뷰 자동화는 지역성이 있다. 예컨대 Spring 기반 백엔드, MyBatis SQL, 국내 본인확인 연동, 개인정보 마스킹 로직처럼 현장 패턴이 뚜렷한 영역은 도메인 특화 에이전트가 더 잘할 수 있다.

OpenVM AI 감사 사례가 보여주듯 고난도 보안에서는 도메인 지식이 성능을 좌우한다. AI 보안 제품은 모델 이름보다 룰셋, 감사 플레이북, 검증 데이터, 개발자 워크플로 연결이 핵심 자산이다.

자주 묻는 질문

Q1: VulnHunter가 기존 보안 도구를 대체하나요?

A: 대체보다 보완에 가깝다. SAST와 SCA가 만든 후보를 에이전트가 맥락화하고, 사람이 최종 판단하는 흐름이 현실적이다.

Q2: LLM 보안 도구의 가장 큰 위험은 무엇인가요?

A: 오탐과 과신이다. 재현 경로와 코드 근거가 없는 경고를 정책 게이트로 쓰면 개발 속도와 신뢰가 모두 떨어진다.

Q3: 금융사는 왜 이런 도구에 관심이 많나요?

A: 코드 규모가 크고 규제 책임이 무겁기 때문이다. 보안 리뷰 병목을 줄이면서 감사 로그를 남길 수 있다면 가치가 크다.

Q4: 한국 기업은 클라우드 LLM을 써도 되나요?

A: 코드와 고객 데이터 성격에 따라 다르다. 민감한 저장소는 로컬 실행, 전용 환경, 데이터 보존 정책 확인이 필요하다.

Q5: 개발팀은 어떤 지표로 평가해야 하나요?

A: 탐지 개수보다 유효 취약점 비율, 재현 가능성, 수정까지 걸린 시간, 개발자 수용률, 회귀 테스트 생성 품질을 봐야 한다.