기술 요약: DualGauge

문제 정의

대규모 언어 모델(LLM)과 LLM 기반 코딩 에이전트는 자연어 명세로부터 코드를 생성하는 데 점점 더 많이 사용되고 있습니다. 기능적 정확성(functional correctness)이 이러한 시스템을 평가하는 지배적인 기준이 되었지만, 이는 배포 가능한 소프트웨어를 보장하기에는 불충분합니다. 기존 연구에 따르면 AI 코딩 어시스턴트는 종종 보안에 취약한 코드를 생성하며, 개발자들은 이러한 제안을 수용하면서도 그 안전성에 대해 확신을 갖는 경우가 많습니다.

기존의 평가 프레임워크는 두 가지 주요 한계점을 가집니다:

1. 메트릭의 고립: 기능적 벤치마크(예: HumanEval, LiveBench)와 보안 벤치마크(예: SecurityEval, CodeLMSec)는 일반적으로 정확성과 보안을 고립된 상태로 평가하거나 서로 다른 데이터셋에서 평가합니다. 기능 테스트는 통과하지만 취약점을 포함하는 프로그램, 또는 그 반대의 경우,은 유용하지 않습니다.
2. 평가 오라클(Oracle)의 과제: 보안 평가는 단순히 출력값의 일치 여부에만 의존할 수 없습니다. 경로 탐색(path-traversal) 사례에서 알 수 있듯이, 보안이 확보된 구현과 취약한 구현은 적대적 입력에 대해 동일한 출력과 종료 코드를 생성할 수 있습니다. 차이점은 실행 트레이스(예: 체크가 실패하기 전에 파일에 접근했는지 여부)에 있으며, 이는 단순한 출력 비교가 아닌 런타임 동작에 대한 의미론적 추론을 필요로 합니다.
3. 컨텍스트 제한: 대부분의 벤치마크는 코드 완성, 저장소 컨텍스트 또는 프레임워크 스캐폴딩에 의존하며, 모델이 자연어 설명만으로 함수를 구현해야 하는 "명세 전용(specification-only)" 생성을 간과합니다.

방법론: DualGauge 및 DualGauge-Bench

저자들은 명세 전용 코드 생성에서 보안과 기능성을 공동 평가하기 위한 완전 자동화된 프레임워크인 DualGauge를 제시하며, 이를 지원하는 DualGauge-Bench를 함께 선보입니다.

DualGauge-Bench

이는 307개의 코딩 태스크로 구성된 언어 불가지론적(language-agnostic) 벤치마크입니다.

• 태스크 설계: 각 태스크는 코드 스니펫, 함수 시그니처 또는 언어별 제약 조건이 없는 자연어 명세로 구성됩니다.
• 쌍을 이룬 테스트: 모든 명세는 동일한 프롬프트에서 파생된 두 가지 테스트 스위트와 쌍을 이룹니다:
  • 기능 테스트: 행동적 정확성을 검증하기 위해 경계값 분석(boundary value analysis)과 동등 클래스 분할(equivalence-class partitioning)에 의해 유도됩니다.
  • 보안 테스트: 보안하지 않은 동작(예: 입력 검증 실패, 액세스 제어 문제)의 부재를 검증하기 위해 OWASP 및 CERT 원칙에 의해 유도됩니다.
• 커버리지: 벤치마크는 7개의 기능 도메인과 90개의 CWE(Common Weakness Enumeration) 카테고리를 아우르며, 절차 내(intraprocedural) 및 절차 간(interprocedural) 태스크를 모두 포함합니다.
• 구축: 프롬프트는 기존 데이터셋(CodeGuard+, SecurityEval, Purple Llama CyberSecEval)에서 추출하여 순수 명세로 변환되었습니다. 테스트 스위트는 LLM이 후보를 제안하고 인간 평가자가 이를 검증 및 확장하는 인간-LLM 협업 프로세스를 통해 생성되었습니다.

DualGauge 시스템

시스템은 평가 파이프라인을 자동화하기 위해 4단계로 작동합니다:

1. 샘플 생성: 대상 LLM 또는 에이전트가 주어진 명세에 대해 $k$개의 코드 후보를 생성합니다.
2. 에이전트 기반 실행: LLM이 유도하는 실행기가 격리된 환경에서 후보들을 실행합니다. 실행기는 실패를 환경, 스크립트 또는 코드 이슈로 분류합니다. 실행기는 환경 및 스크립트 이슈(예: 누락된 패키지, 호출 오류)를 수정하지만, 후보 코드 자체를 변경하지는 않습니다. 이는 모델의 로직을 인위적으로 수정하지 않으면서 코드가 실행 가능하도록 보장하기 위함입니다.
3. LLM 기반 런타임 평가:
   • 기능 오라클: 예상 출력값에 대한 정확한 출력 매칭을 사용합니다.
   • 보안 오라클: LLM을 사용하여 의미론적 판단을 수행합니다. 이 단계에서는 후보 코드, 실행 출력 및 커버리지 트레이스를 분석하여 예상되는 보안 동작과 대조합니다. 만약 코드가 생소한 라이브러리를 사용하는 경우, 웹 검색 기능이 있는 리졸버(resolver) 모델이 문서를 검색하여 평가를 돕습니다. 이 단계는 코드가 단순히 우연히 실패한 것인지, 아니면 진정한 방어 기제를 구현한 것인지를 결정합니다.
4. 결과 집계: 기능 통과율($PR$), 보안 통과율($SPR$), 그리고 결합 메트릭인 secure-pass@k(단일 샘플이 기능적으로 정확하면서 동시에 보안상 안전할 확률)를 포함한 지표를 계산합니다.

주요 결과

저자들은 Python, C++, JavaScript에 걸쳐 10개의 대표적인 LLM(GPT-5, Claude Opus/Sonnet, Llama, Qwen, Gemma 제품군 포함)과 3개의 에이전틱 코딩 시스템(Codex, OpenHands, Claude Code)을 평가했습니다.

1. 기능적 정확성이 신뢰성을 과대평가함

가장 강력한 모델들도 Python 태스크에서 기능 통과율이 거의 39%에 달했지만, 결합 보안-기능 성공률(secure-pass@1)은 모든 언어에서 15% 미만을 기록했습니다. 이는 기능적 정확성이 안전한 코드 생성을 위한 좋은 대리 지표(proxy)가 아님을 나타냅니다.

2. 모델 측 요인이 결합 성능을 안정적으로 개선하지 못함

연구는 규모(scale), 확장된 사고(extended thinking), 양자화(quantization), 그리고 지시/코드 특화(instruction/code specialization)라는 네 가지 요인을 조사했습니다.

• 규모: 모델 크기를 키우는 것은 기능적 유창성을 향상시켰으나, 보안 커버리지는 가장 큰 사이즈에 도달하기 훨씬 전부터 정체되었습니다.
• 확장된 사고 및 특화: 이러한 요인들은 모델 제품군에 따라 기능 및 보안 메트릭을 다르게 변화시켰으며, 결합 메트릭을 안정적으로 개선하지 못했습니다.
• 결론: 안전하고 정확한 코드 생성은 단순히 더 강력한 코딩 능력에서 발생하는 것이 아니라, 모든 요구사항에 걸쳐 보안 지식을 일관되게 적용하는 능력을 필요로 합니다.

3. 에이전틱 시스템은 이점이 없음

코딩 에이전트(Codex, OpenHands, Claude Code)의 반복적인 스캐폴딩은 명세 전용 태스크에서 직접 생성 방식보다 나은 성과를 보여주지 못했습니다.

• 실패 메커니즘: 에이전트들은 빈 작업 공간에서 신호를 얻을 수 없는 저장소 중심의 오버헤드(예: 디렉토리 목록 나열, 설정 파일 검색)에 상당한 노력을 소비했습니다.
• 피드백 루프: 에이전트들은 그라운드 트루스(ground-truth) 벤치마크보다는 스스로 생성한 테스트에 의존하는 경우가 많았습니다. 에이전트의 내부 체크는 통과했지만 벤치마크의 보안 테스트는 통과하지 못한 부분적 방어(partial defenses)의 경우, 수정되지 않았습니다. 결과적으로 에이전트는 직접 생성 방식과 동일한 실패 모드를 그대로 상속받아 커버리지 격차를 좁히지 못했습니다.

4. 실패 모드

• 기능적 실패: 알고리즘 오류가 아닌 출력 계약 경계(예: 잘못된 JSON 구조, 잘못된 CLI vs 서비스)에 집중되었습니다.
• 보안 실패: 부분적 방어가 특징입니다. 모델은 합리적으로 보이는 가드(regex, 타입 체크 등)를 구현했지만, 특정 공격 벡터를 커버하지 못하거나 잘못된 추상화 수준에서 적용되었습니다.
• 결합 격차: 프로그램이 기능 테스트는 통과하면서 보안은 취약할 수 있고, 일부 보안 테스트는 통과하면서 다른 테스트는 실패할 수도 있습니다. 결합 벤치마킹만이 이러한 "침묵하는" 실패를 확실히 드러낼 수 있습니다.

의의 및 주장

본 논문은 명세 전용 코드 생성에서 보안과 기능을 공동 평가하는 최초의 완전 자동화된 프레임워크를 제시한다고 주장합니다. 그 의의는 다음과 같습니다:

1. 격차 폭로: 현재의 최첨단 모델과 에이전트들이 정확성과 보안을 동시에 만족시키는 데 어려움을 겪고 있으며, 결합 성공률이 여전히 매우 낮음(<15%)을 입증했습니다.
2. 방법론적 전환: 보안 평가는 출력 매칭이 아닌 실행 트레이스에 대한 의미론적 추론이 필요하며, 벤치마크는 동일한 명세에 대해 기능 및 보안 테스트를 쌍으로 구성해야 한다고 주장합니다.
3. 에이전트의 한계: 기존 코드베이스나 테스트 러너가 없어 에이전트를 가이드할 수 없는 상황에서, 멀티 턴 정교화(multi-turn refinement)와 도구 사용이 핵심적인 보안 코드 생성 문제를 자동으로 해결하지 못함을 보여주었습니다.
4. 벤치마크 표준: 코드 완성을 넘어, 모델이 자연어 의도를 보안성이 확보된 정확한 코드로 변환하는 근본적인 능력을 테스트하는 언어 불가지론적이고 재사용 가능한 벤치마크(DualGauge-Bench)를 제공합니다.

저자들은 보안 코드 생성이 요구사항의 전체 공간에 걸쳐 보안 지식을 일관되게 적용하는 것을 필요로 하며, 현재의 모델과 에이전트는 아직 이 능력을 숙달하지 못했다고 결론짓습니다. 또한, 자신들의 결과는 확장 가능한 벤치마크 추정치이며, 여전히 인간의 보안 검토가 필요함을 강조합니다.