FlawDetector-LLM V1.0: 1,000회 반복시험, 그리고 분산이 말해준 것

평균만 보고하면 벤치마크는 마케팅이 된다

보안 스캐너 벤치마크는 대개 두 숫자로 요약됩니다. 탐지율과 오탐률. 두 숫자 모두 한 번의 실행에서 나온 값이거나, 여러 번 실행한 결과의 평균입니다. 문제는 실무에서 팀이 겪는 고통이 평균이 아니라 편차에서 온다는 점입니다.

월요일 스캔에서 Critical로 뜬 결함이 금요일 스캔에서 사라지면, 그 도구의 탐지율이 94%든 97%든 팀은 결과를 신뢰하지 않게 됩니다. 코드가 바뀌지 않았는데 판정이 바뀌는 경험은 한 번이면 충분합니다. 그래서 V1.0 시험 설계에서 우리가 첫 번째로 정한 것은 '평균을 얼마나 올릴 것인가'가 아니라 '같은 입력에 같은 답을 내는가를 어떻게 측정할 것인가'였습니다.

시험 설계: 무엇을 1,000번 반복했는가

반복시험의 단위는 '전체 벤치마크 1회'가 아니라 '샘플 하나당 판정 1회'입니다. 코퍼스를 고정하고, 샘플링 파라미터를 고정하고, 동일 입력을 반복해 넣은 뒤 판정이 갈리는 비율을 측정했습니다. 여기서 '판정'은 결함 유무, CWE 분류, 심각도 세 가지를 묶은 튜플이며, 셋 중 하나라도 달라지면 불일치로 셉니다.

반복시험 대상은 전체 샘플이 아니라 층화 추출한 1,200개 샘플이었고, 각 샘플을 1,000회 이상 반복했습니다. 총 판정 수는 120만 건을 넘습니다. 이 규모가 필요했던 이유는 단순합니다. 불일치율이 1% 아래로 내려가면, 100회 반복으로는 그 값을 신뢰 구간 안에서 구분할 수 없기 때문입니다.

FlawDetector-LLM V1.0 요약 지표

오탐률 3.2%는 원시 출력값이 아닙니다. 엔진이 내놓은 1차 결과의 오탐률은 5.8%였고, 중복 제거와 도달 가능성 기반 랭킹을 거친 뒤 3.2%가 되었습니다. 두 숫자를 모두 밝히는 이유는, 후처리 이후 값만 공개하면 비교가 불가능해지기 때문입니다.

분산은 어디에 있었나

전체 일관성 99.1%는 결함군에 따라 상당히 다르게 분포했습니다. 아래 표에서 흥미로운 부분은 탐지율과 일관성이 함께 움직인다는 점입니다. 잘 못 찾는 결함군이 곧 판정이 흔들리는 결함군이었습니다.

패턴은 분명했습니다. 판단에 필요한 정보가 한 청크 안에 들어오는가가 거의 모든 것을 갈랐습니다. 인젝션은 쿼리 문자열 조립이 한 함수 안에서 일어나므로 모델이 매번 같은 근거를 봅니다. 반면 인가 결함은 라우터, 미들웨어, 핸들러가 서로 다른 파일에 있고, 청킹 경계가 어디서 잘리느냐에 따라 모델이 보는 근거가 달라졌습니다.

왜 흔들렸는가

불일치 사례 약 1만 건을 표본 추출해 원인을 분류했습니다. 세 가지가 전체의 대부분을 설명했습니다.

1. 01청킹 경계 문제 (54%) — 검증 로직과 사용 지점이 서로 다른 청크로 갈렸을 때. 모델은 자기가 본 절반만으로 판단하게 되고, 어느 절반을 봤는지가 실행마다 미세하게 달라졌습니다.
2. 02컨텍스트 절단 (29%) — 대형 파일에서 앞부분의 import와 설정이 잘려 나가면서, 어떤 라이브러리가 기본 방어를 제공하는지를 모델이 알 수 없게 된 경우입니다. ORM이 파라미터 바인딩을 자동으로 하는데 원시 SQL로 오인하는 오탐이 여기서 나왔습니다.
3. 03순서 민감도 (13%) — 동일한 청크 집합이라도 제시 순서가 바뀌면 판정이 뒤집히는 경우. 특히 심각도 라벨이 한 단계 오르내리는 형태로 나타났습니다.

무엇을 바꿨는가

세 가지 조치를 순차적으로 적용하고 각 단계마다 반복시험을 다시 돌렸습니다.

1. 01

   앵커 청킹 — 경계를 코드 구조에 맞춘다

   고정 토큰 길이로 자르는 대신 함수·클래스·라우트 정의를 앵커로 삼고, 앵커가 참조하는 심볼의 정의를 같은 청크에 강제로 포함시킵니다. 청크 크기는 가변이 되지만 판단 근거가 쪼개지지 않습니다. 일관성 96.4% → 98.0%.

2. 02

   심볼 그래프 프리패스 — 읽기 전에 지도를 만든다

   LLM 호출 전에 정적 파서로 호출 그래프와 데이터 흐름 요약을 만들어 각 청크의 헤더로 붙입니다. 모델은 '이 함수를 호출하는 곳은 세 군데이고 그중 둘은 외부 진입점'이라는 정보를 항상 갖고 판단합니다. 일관성 98.0% → 98.7%.

3. 03

   3회 다수결 — 남은 흔들림을 흡수한다

   심각도 High 이상 후보에 대해서만 청크 제시 순서를 바꿔 3회 판정하고 다수결을 취합니다. 비용은 해당 후보에 한정되어 전체 지연의 9% 증가에 그쳤습니다. 일관성 98.7% → 99.1%.

부수 효과로 오탐률도 함께 내려갔습니다. 프리패스가 프레임워크 기본 방어를 인식하게 되면서, ORM·템플릿 엔진·검증 미들웨어를 쓰는 코드에 대한 오탐이 눈에 띄게 줄었습니다. 1차 출력 오탐률 기준 5.8%에서 4.1%로, 후처리 후 기준으로는 3.2%입니다.

남은 병목과 V1.1

일관성을 올린 대가는 지연입니다. 프리패스가 추가되면서 스캔 시간 구성이 바뀌었습니다.

프리패스는 파일이 바뀌지 않으면 결과가 바뀌지 않습니다. 즉 캐시 가능한 계산인데 V1.0에서는 매번 다시 했습니다. 증분 캐시는 V1.1에서 가장 확실한 개선 항목이고, 반복 스캔이 잦은 CI 환경일수록 효과가 큽니다.

보안 모델 벤치마크를 읽는 다섯 가지 질문

우리 숫자를 포함해 어떤 벤치마크를 보든, 다음 다섯 가지를 확인하면 대부분의 과장은 걸러집니다.

• 반복시험 결과가 있는가. 1회 실행 결과만 있다면 그 숫자의 재현성은 알 수 없습니다.
• 오탐률이 후처리 전후 중 어느 값인가. 랭킹과 중복 제거 이후 값만 공개하는 것은 관행이지만, 비교하려면 원시 값이 필요합니다.
• 정상 코드 대조군의 크기는 얼마인가. 취약 샘플만으로는 오탐률을 측정할 수 없습니다.
• 합성 변이 세트가 포함되어 있는가. 공개 코퍼스만 쓰면 학습 데이터 암기와 실제 탐지 능력을 구분할 수 없습니다.
• 결함군별 분해 값이 있는가. 전체 평균 하나는 어떤 결함군이 취약한지를 감춥니다.

정리

V1.0 시험에서 얻은 가장 실용적인 교훈은 성능이 아니라 진단이었습니다. 분산이 몰려 있는 곳이 곧 다음 버전에서 고칠 곳이고, 그 위치를 알아내려면 평균 대신 분해된 수치를 봐야 합니다. 우리가 반복시험에 120만 건의 판정을 쓴 이유는 좋은 숫자를 얻기 위해서가 아니라, 어디를 고쳐야 할지 알아내기 위해서였습니다.

모든 항목은 자체 시험기준 문서로 관리되며, 코퍼스 구성과 반복 프로토콜을 포함한 상세 리포트는 요청 시 제공합니다.