보안 분석가가 옆자리에서 이렇게 말한다. "이 서브넷에서 SMB 설정 오류를 스캔해줘." 서브넷은 하나의 네트워크를 잘게 나눈 IP 주소 구역이고, SMB는 윈도우 컴퓨터끼리 파일을 주고받을 때 쓰는 통신 규약이다. 사람 분석가에게 이 한마디는 쉽다. 무슨 도구를 쓸지 떠올리고, 손이 알아서 명령어를 친다.
AI에게 시켜 보면 여기서 갈라진다. "어떤 도구를 쓸까"는 곧잘 답한다. 그런데 그 도구를 실제로 돌아가는 Kali Linux 명령어 한 줄로 옮기는 단계에서 자주 넘어진다. Kali는 보안 점검에 쓰는 도구가 2,000개 넘게 깔려 나오는 리눅스다. 이 도구들은 대부분 CLI로 쓴다. CLI는 글자로 명령을 쳐서 프로그램을 돌리는 방식인데, 봐주는 게 없다. 옵션 이름의 철자 하나, 대시(-) 한두 개 차이로 명령 전체가 실행되지 않는다.
그래서 이 문제는 두 가지 다른 능력으로 쪼개진다. 하나는 도구 선택 — 무슨 도구를 쓸지 고르는 일. 다른 하나는 인자 구성 — 고른 도구를 정확히 부르는 일이다. 인자는 명령어 뒤에 붙는 옵션과 값을 말한다. KaliBench는 이 둘을 떼어내 따로 채점한 벤치마크다. 도구 1,642개에 걸친 질의-명령 쌍 8,504개로 모델 구성 24종을 평가했다. 결론부터 말하면, AI가 무너지는 곳은 선택이 아니라 구성 쪽이었다.
지금 나와 있는 'AI 함수 호출' 평가는 꽤 성숙했다. 함수 호출이란 모델이 정해진 도구를 골라 입력값을 채워 넣는 방식이다. 그런데 여기엔 숨은 전제가 하나 있다. 쓸 수 있는 도구와 입력값의 형식이 스키마로 미리 적혀 있다는 것. 스키마는 "이 도구는 이런 입력을 이런 형식으로 받는다"고 정해둔 명세다. 스키마가 있으면 모델은 빈칸만 채우면 된다.
보안 현장은 그렇지 않다. 도구가 수백, 수천 개인데 그 많은 스키마를 프롬프트에 전부 넣는 건 분량상 불가능하다. 모델은 스키마 없이, 알아서 도구를 고르고 인자를 추론해 문법에 맞는 명령어 한 줄을 통째로 써내야 한다. 빈칸 채우기가 아니라 백지에 쓰는 쪽에 가깝다. KaliBench는 바로 이 '스키마 없는 도구 사용'을 정밀하게 겨눈다. 저자들은 이 영역을 이렇게 재는 벤치마크가 처음이라고 밝힌다.
기존 평가가 이 지점을 놓친 이유도 분명하다. 지식을 묻는 평가는 모델이 무엇을 '아는지'까지만 재고 손을 움직이는 능력은 안 본다. 반대로 해킹 챌린지를 끝까지 풀게 하는 평가는 계획·실행·결과 해석·오류 복구를 한꺼번에 뭉쳐 본다. 실패해도 도구를 잘못 골랐는지, 인자를 틀렸는지, 결과를 못 읽었는지 떼어낼 수가 없다. KaliBench는 그 뭉친 덩어리에서 '명령어 한 줄을 정확히 쓰는' 능력만 고립시켜 꺼낸다.
명령어는 <도구명> <인자들> 꼴이다. 인자는 두 종류다. 옵션 인자는 -로 시작하고 순서가 자유로우며 별칭이 허용된다. 위치 인자는 값만 있고 순서가 고정이다.
채점은 완성된 요리의 맛을 보는 대신 조리 과정을 단계별로 뜯어본다. 앞의 "SMB 설정 오류를 스캔해줘"를 예로 들면, 모델이 내놓은 한 줄을 셋으로 분해한다. 스캔 도구를 맞게 골랐는가(도구 정확도). SMB 점검을 켜는 옵션 플래그를 맞게 달았는가(옵션 인자 F1) — 이때 채점은 플래그 이름을 보되 -o와 --output처럼 같은 뜻의 별칭은 한 플래그로 쳐준다. 대상 서브넷 값이 맞게 들어갔는가(위치 인자 F1) — 자리 순서는 따지지 않고 값의 다중집합이 일치하는지만 본다. 여기서 F1은 놓친 것과 잘못 넣은 것을 함께 반영하는 깐깐한 정확도 지표다. 빠뜨려도 깎이고, 쓸데없이 더 넣어도 깎인다. 그리고 '정확 일치'는 이 셋과 별개 지표다. 정규화한 명령의 인자 값과 그 결합까지 그대로 맞아야 1점을 준다. 그래서 세 구성 점수가 모두 만점이라고 정확 일치가 보장되는 것은 아니다.
이렇게 쪼개 두면 명령이 틀렸을 때 셋 중 어디서 틀렸는지가 바로 짚인다. 그리고 결정적으로, 채점은 명령을 실제로 돌리지 않는다. 셸 문법을 파싱해 — 문장을 문법 단위로 쪼개 해석해 — 정답에 미리 기록된 도구명·옵션·위치 인자와 요소별로 비교한다. 이 설계가 뒤에 올 훈련의 열쇠가 된다.
이 벤치마크의 핵심 장치는 '실행 없는 검증 가능 보상'이다. 명령을 돌려보지 않고도 정답과 구조를 대조해 점수를 매길 수 있다는 뜻이다. 이 장치를 쓸 수 있게 만들려고, 처음 만든 데이터의 약 70%를 버리는 고된 공정을 거쳤다.
출발은 Kali 공식 문서(도구 2,372개)였다. 큰 생성 모델에게 이 문서를 근거로 질의-명령 쌍을 2만7천여 개 만들게 했다. 그런데 문서를 쥐여줬는데도 지어내기가 심했다. 초기 점검에서 생성된 명령의 절반 이상이 없는 사실을 꾸며냈거나 틀린 옵션을 달고 있었다.
그래서 거름망을 세 겹으로 쌓았다. 먼저 AI 검증자가 모든 플래그가 문서에 실재하는지, 질의를 충실히 옮겼는지 확인했다(여기서만 절반 넘게 탈락). 다음으로 실제 시스템과 격리된 가상 실험 공간(Docker 샌드박스)에서 명령을 하나씩 돌려, 없는 도구나 틀린 인자로 오류가 나면 버렸다. 마지막으로 가장 센 모델이 문서를 받고도 실패한 케이스는 사람이 직접 들여다봤다. 그런 실패는 모델 탓이라기보다 데이터 결함일 확률이 높기 때문이다. 끝으로 의미가 겹치는 쌍을 묶어 대표만 남겼다.
이 관문을 다 통과한 건 8,504개, 처음 양의 30.7%뿐이다. 이걸 평가용 5,000개(도구 1,642개를 전부 덮는다)와 훈련용 3,504개로 나눴다. 정답 명령이 이미 샌드박스 실행으로 걸러졌고 채점이 기계적이니, 학습할 때 모델 출력을 매번 실행하지 않고도 점수를 매겨 보상을 줄 수 있다. CLI를 돌리지 않고 강화학습을 돌리는 셈이다.
벤치마크의 또 다른 축은 '도구 정보를 얼마나 줄 것인가'를 세 단계로 나눈 데 있다.
U에서 R로 가면 도구 선택이 쉬워진다. R에서 H로 가면 인자 구성이 쉬워진다. 그러니 점수가 어느 구간에서 뛰는지를 보면, 모델이 도구를 못 골라서 틀렸는지 인자를 못 짜서 틀렸는지가 수치로 드러난다. 평가 대상은 일반 목적 14종과 보안 특화 7종을 포함한 24개 구성이다.
| 지표(평균) | U | R | H |
|---|---|---|---|
| 정확 일치 | 22.3% | 28.3% | 73.1% |
| 도구 정확도 | 72.0% | 95.2% | 94.6% |
| 옵션 인자 F1 | 45.1% | 48.7% | 87.8% |
| 위치 인자 F1 | 61.1% | 68.2% | 90.1% |
| 총점 | 59.4% | 70.7% | 90.8% |
표를 두 구간으로 끊어 읽으면 이야기가 선명하다.
U에서 R로. 후보를 20개로 좁혀주자 도구 정확도가 72.0%에서 95.2%로 껑충 뛴다. 도구 고르기는 조금만 거들어도 거의 풀린다는 뜻이다. 그런데 같은 구간에서 옵션 인자는 45.1%에서 48.7%로 찔끔 오르는 데 그친다. 도구를 맞게 골랐다고 인자까지 맞게 짜는 건 전혀 아니다.
변화는 R에서 H로 넘어갈 때 터진다. 문서를 쥐여주니 옵션 F1이 87.8%로, 정확 일치가 73.1%로 뛴다. 무힌트 22.3%에서 세 배가 넘는다. 병목이 어디였는지가 여기서 드러난다. 인자 구성, 그중에서도 옵션 인자다.
왜 옵션 인자가 유독 어려울까. 모델은 문서에서 옵션 이름을 찾기만 하면 되는 게 아니다. -o와 --output이 같은 뜻임을 문맥으로 알아내야 하고, 어떤 도구는 --timeout 30은 받지만 --timeout=30은 거부하는 식의 미묘한 문법 차이를, 문서에 또렷이 적히지도 않은 그 규칙을 예제 코드의 뉘앙스만으로 추론해야 한다. 이건 비정형 문서에서 암묵적 문법 규칙을 뽑아내는 문제다. 자연어 이해를 넘어 코드 생성에 가까운 추론이다. 문서를 통째로 보여줬을 때 비로소 풀렸다는 건, 모델이 이 규칙을 머릿속에 들고 있지 못하다는 증거다.
모델별로 보면 더 와닿는다. 가장 센 축인 GLM-5.2가 무힌트 정확 일치 41.3%, DeepSeek-V3.2가 33.0%다. 어떤 공개 모델도 무힌트에서 42%를 못 넘겼다. 같은 모델들이 후보 20개 중 도구를 고르는 일은 R 모드에서 GLM-5.2 94.2%, DeepSeek-V3.2 98.3%로 해낸다. 고르는 건 되는데, 정확히 부르는 데서 걸린다.
실행 없는 보상이 왜 쓸모 있는지는 훈련에서 드러난다. 저자들은 80억(8B) 파라미터짜리 보안 특화 모델 RedSage를 골랐다. 그리고 모델 전체가 아니라 일부만 가볍게 손보는 LoRA 방식으로, 두 가지 학습을 더했다. 하나는 정답을 그대로 따라 쓰게 가르치는 지도학습(SFT), 다른 하나는 점수가 높은 쪽으로 행동을 조금씩 교정하는 강화학습(GRPO)이다. 이 교정에 쓴 점수가 바로 앞의 실행 없는 보상이다.
손본 결과, 이 80억짜리 모델이 6,850억(685B) 파라미터짜리 거대 모델 DeepSeek-V3.2의 턱밑까지 따라붙었다. 세 모드 평균 총점 79.2%. 손대기 전 71.7%에서 7.5%p 오른 값이고, DeepSeek-V3.2의 80.2%와는 단 1%p 차다. 덩치가 85배 작은데 말이다. 적절한 데이터와 기계적 보상만 있으면 작은 모델도 훨씬 큰 모델 가까이 갈 수 있다.
단, 이 상승을 과장하면 안 된다. 7.5%p는 세 모드 평균이고, 이득은 단서가 적은 U·R에 몰려 있다. 문서를 다 쥐여주는 H에서는 동급이나 더 큰 모델을 꼭 앞서진 않는다. 효과의 정체는 "힌트 없이도 명령을 더 잘 짜게 됐다" 쪽이다.
한계는 한자리에 모아 짚는 게 낫다. 채점이 정답 명령과의 구조적 일치에 기댄 탓에, 같은 목표를 이루는 다른 유효 명령이 부당하게 깎일 여지가 있다. 평가가 명령 한 줄에 집중돼, 파이프로 명령을 엮는 다단계 작업은 범위 밖이다. 샌드박스 검증은 '문법적으로 돌아감'을 확인한 것이지 '실전에서 통함'을 보장하진 않는다. 공격·탐지 도구가 섞인 데이터라 오남용 위험도 따른다.
그래서 남는 질문. 단일 명령의 정확도를 끌어올리는 걸 목표로 삼을 것인가, 아니면 여러 명령을 엮어 문제를 푸는 작전술을 가르칠 것인가. 목표를 아는 것과 그 목표를 정확한 명령으로 옮기는 것은 다른 능력이고, 한 줄을 맞히는 것과 판 전체를 운영하는 것은 또 다른 문제다. '알아서 다 하는 AI 조수'라는 그림이 생각보다 멀다는 걸, 이 연구는 숫자로 보여준다.
이 질문은 우리 일이기도 하다. ONTLE은 고객 프로젝트마다 AI PM을 붙여 요청 접수부터 실행까지 맡긴다. 이 PM도 결국 사람 말을 기계가 실행할 동작으로 옮기는 일을 한다. KaliBench가 겨눈 바로 그 간극이다.
한 장면을 끝까지 따라가 보자. 고객이 PM에게 말한다. "이번 주 리뷰 데이터에서 중복 빼고 공급사별로 집계해줘." PM은 이걸 집계 쿼리나 호출 코드로 옮긴다. 검증은 두 층으로 갈린다.
첫째, 규격은 기계가 본다. PM이 내놓은 쿼리를 실행 전에 파싱해, 쓸 수 있는 함수·인자 형식에 맞는지 기계적으로 대조한다. 집계 함수·날짜 형식·그룹 기준이 규격 안에 있는가를 보는 관문이다. KaliBench의 구조 채점을 그대로 옮긴 셈이다. 여기에 더해, PM이 자유 서술로 쿼리를 짜게 두지 않고 쓸 수 있는 '좁은 액션'의 사용법 문서를 함께 쥐여준다. 문서를 줬을 때 정확도가 세 배로 뛴 그 효과를 노린다.
둘째, 업무 의미는 사람이 본다. 규격이 맞아도 '중복의 정의'나 '공급사를 묶는 기준' 같은 판단은 구조 채점으로 잡히지 않는다. 이 층은 기계 관문과 분리해 따로 확인한다.
여기서 측정할 숫자는 딱 둘로 압축된다. 하나, 좁은 액션 문서를 주기 전과 후로 나눠, 운영 DB에 손대기 전 걸러낸 규격 오류의 비율. 둘, 같은 전후로 PM의 '말과 행동 불일치'가 얼마나 줄었는지. 주의할 점도 하나 분명히 해둔다. 보안 명령에서 문서가 보인 효과가 우리 업무 쿼리에서도 그대로 나오리란 보장은 없다. 그러니 위 두 지표를 실제로 재서 확인하기 전까지는 기대일 뿐이다. 돈·크레딧이 걸려 되돌리기 어려운 작업일수록, 실행 전 관문의 값어치는 커진다.
아닙니다. F1은 정답 명령과 구조가 얼마나 겹치는지를 요소별로 잰 값입니다. 채점이 명령을 실제로 돌리지 않기 때문에, 점수가 높아도 '문법상 정답과 비슷하다'까지만 보장합니다. 반대로 같은 목표를 이루는 다른 유효 명령은 정답과 구조가 달라 점수가 부당하게 깎일 수 있습니다. 이게 구조 채점 방식의 원리적 한계입니다.
이론상으로는요. 하지만 보안 도구는 수백, 수천 개라 그 스키마를 프롬프트에 전부 넣는 게 분량상 비현실적입니다. KaliBench가 '스키마 없는' 상황을 일부러 다루는 이유가 여기 있습니다. 대신 현실적인 절충이 있습니다 — 전체 스키마 대신 관련 도구의 문서만 추려 함께 주는 것이고, 실험에서 그것만으로 정확도가 크게 올랐습니다.
그렇게 보긴 이릅니다. 작은 모델의 이득은 힌트가 적은 상황(U·R)에 몰려 있고, 문서를 다 주는 상황(H)에서는 동급이나 더 큰 모델을 꼭 앞서지 못했습니다. 또 이건 명령어 한 줄 생성이라는 좁은 과제에 특화 훈련을 한 결과입니다. 여러 단계를 엮는 넓은 작업까지 그대로 따라잡는다는 뜻은 아닙니다.