기술 요약: 코드 생성용 대규모 언어 모델의 보안 캘리브레이션에 관한 경험적 연구

1. 문제 정의

대규모 언어 모델(LLM)은 코드 생성 및 버그 수정과 같은 소프트웨어 개발 워크플로에 점점 더 많이 통합되고 있습니다. 그러나 보안이 중요한 맥락에서 이들의 배포는 근본적인 질문을 제기합니다: 모델이 자신이 생성한 코드가 안전하지 않다는 것을 정확히 알고 있는가?

기존의 벤치마크(예: HumanEval, MBPP, SWE-Bench)는 기능적 정확성을 평가하지만, 보안 속성은 대체로 무시합니다. 최근의 보안 지향적 벤치마크들은 코드에 취약점이 포함되어 있는지 여부는 평가하지만, 모델이 출력물의 보안성을 **자기 평가(self-assess)**할 수 있는지는 측정하지 못합니다. 이러한 격차는 모델이 취약한 코드에 대해 높은 신뢰도를 부여하는 거짓 신뢰(False Trust) 현상으로 이어집니다. 이러한 신뢰 신호에 의존하는 개발자들은 면밀한 검토 없이 보안이 취약한 출력을 수용하여, 결과적으로 프로덕션 시스템에 취약점을 전파하게 됩니다.

선행 연구들은 보안 캘리브레이션(security calibration)—모델이 출력물의 보안성에 대해 명시한 신뢰도와 실제 보안 상태 사이의 정렬 상태—를 체계적으로 측정하지 않았습니다. 또한, 고립된 자립형 프로그램에서 관찰된 캘리브레이션 패턴이 현실적인 다중 파일 저장소(repository) 맥락에서도 일반화될 수 있는지, 혹은 캘리브레이션 신호가 자동화된 취약점 수리에 효과적으로 가이드 역할을 할 수 있는지도 알려져 있지 않습니다.

2. 방법론

저자들은 세 가지 최첨단 모델인 GPT-4o-mini, Gemini-2.0-Flash, Qwen3-Coder-Next를 평가하여 보안 캘리브레이션에 대한 최초의 대규모 경험적 연구를 제시합니다. 본 연구는 두 가지 상호 보완적인 벤치마크와 네 가지 연구 질문(RQ)을 통해 다단계 평가를 수행합니다.

데이터셋 및 맥락

• 자립형 프로그램 (RQ1): 100개의 보안 크리티컬 Python 태스크로 구성된 SALLM 벤치마크를 활용했습니다. 각 태스크는 외부 의존성 없이 입력, 예상 출력, 보안 요구사항을 제공하는 단일 프롬프트를 제공합니다.
• 저장소 수준 맥락 (RQ2): 네 가지 언어(C, Java, PHP, Python)와 29개의 CWE를 특징으로 하는 125개의 프롬프트를 포함하는 AICGSecEval 벤치마크를 활용했습니다. 이 태스크들은 교차 파일 의존성, 빌드 구성, 외부 API를 포함하는 기존의 다중 파일 저장소 내에서 패치를 생성할 것을 요구합니다.

실험 설정

• 모델 및 파라미터: 각 모델은 6개의 온도(temperature) 설정(0.0 ~ 1.0)에 걸쳐 테스트되었으며, 태스크당 20개의 샘플을 생성했습니다.
• 신뢰도 추정: 다음 네 가지 방법을 비교했습니다:
  1. 토큰 확률 집계: GPT/Gemini를 위한 로짓 확률(logit probabilities)에 직접 접근.
  2. 언어화된 신뢰도(Verbalized confidence): 모델이 신뢰 점수(0–1)와 추론 과정을 포함한 JSON을 출력하도록 프롬프트 구성.
  3. 샘플링 기반 일관성: 20개 샘플 중 검증을 통과한 비율로 신뢰도를 추정.
  4. 자기 일관성 프롬프팅(Self-consistency prompting): 신뢰도를 보고하기 전 사고 사슬(Chain-of-Thought, CoT) 추론 수행.
• 검증: 코드는 격리된 Docker 컨테이너에서 실행되었습니다. 보안 레이블은 $y_{sec} = y_{func} \land \neg y_{vuln}$으로 정의되었습니다. 즉, 코드는 모든 기능 테스트를 통과하고 모든 취약점 익스플로잇 테스트를 통과하지 못해야(fail) 보안한 것으로 간주됩니다.
• 지표: 기대 캘리브레이션 오차(ECE), 브라이어 점수(Brier Score), 과잉 신뢰 격차(Overconfidence Gap), 그리고 거짓 신뢰(FT)율(높은 신뢰도를 가졌으나 보안이 취약한 예측).

수리 및 완화 전략 (RQ3 & RQ4)

• 캘리브레이션 가이드 수리: 낮은 캘리브레이션 신뢰도($p_{sec} < 0.5$)를 가진 샘플을 필터링하여 반복 수리를 수행하는 폐쇄 루프 시스템을 적용했습니다. 결과는 취약점 유형에 따라 싱크 교체(Sink Replacement, SR)(API 변경 필요)와 제약 조건 강제(Constraint Enforcement, CE)(검증 로직 필요)로 분류되었습니다.
• 완화 실험:
  1. 실행 게이팅(Execution Gating): 보안 신뢰도를 도출하기 전에 기능적으로 올바르지 않은 코드를 먼저 필터링.
  2. 권한 부여된 파괴적 수리(Authorized-Breaking Repair): 역방향 호환성을 깨뜨리는 것(예: pickle을 json으로 교체)을 명시적으로 허용하여 SR 취약점을 수정.
  3. 퓨샷 프롬프팅(Few-Shot Prompting): 보안 코드를 예시로 제공.
  4. 퓨샷 + CoT: 퓨샷 예시에 추론 단계를 추가.

3. 주요 결과

RQ1: 자립형 생성에서의 캘리브레이션

• 체계적 과잉 신뢰: 모든 모델이 심각한 과잉 신뢰를 보입니다. GPT-4o-mini와 Qwen3-Coder-Next는 높은 ECE(각각 0.46–0.48 및 0.41–0.42)를 보이는 반면, Gemini-2.0-Flash는 더 나은 성능을 보이지만 여전히 과잉 신뢰 상태(ECE 0.25–0.26)입니다.
• 거짓 신뢰: 신뢰도 임계값을 0.8로 설정했을 때, 거짓 신뢰율이 매우 높게 나타납니다 (예: GPT-4o-mini 33.5%, Qwen3-Coder-Next 40.3%). 이는 높은 신뢰도를 가진 출력이 빈번하게 보안에 취약함을 나타냅니다.
• 기능 vs 보안 캘리브레이션: 역설적이게도, 기능적 캘리브레이션이 보안 캘리브레이션보다 일관되게 더 나쁩니다 ($\Delta ECE < 0$). 모델은 보안적 정확성보다 기능적 정확성에 대해 더 많이 오차를 보입니다. 이는 모델이 기능적 정확성보다 보안 결과를 더 신뢰성 있게 추정함을 시사하며, 이는 기능적 정확성이 복잡하고 숨겨진 실행 동작에 의존하기 때문일 수 있습니다.
• 신뢰도 방법론: 토큰 확률 집계는 낮은 캘리브레이션(ECE $\approx$ 0.80)을 보입니다. 샘플링 기반 일관성은 거의 0에 가까운 ECE를 보이지만 샘플별 식별 능력이 부족합니다. 언어화된 신뢰도가 다운스트림 분석을 위한 가장 실용적인 신호입니다.

RQ2: 저장소 수준에서의 저하

• 캘리브레이션 붕괴: 자립형 태스크에서 저장소 수준 맥락으로 이동하면 캘리브레이션이 크게 악화됩니다. ECE가 대략 3~4배 증가합니다 (예: GPT-4o-mini ECE가 0.41에서 0.70으로 상승).
• 거짓 신뢰 급증: 자립형 태스크에서의 거짓 신뢰율(~17%)에 비해 저장소 환경에서는 80% 이상으로 급증합니다.
• 분해 분석: 이러한 저하는 두 가지 요인, 즉 빌드 취약성(코드가 컴파일/실행되지 않음)과 교차 파일 복잡성에 의해 발생합니다. 빌드 취약성이 오류의 큰 부분(GPT의 경우 최대 82%)을 차지하지만, 성공적으로 빌드된 패치에서도 실제 교차 파일 복잡성이 중요한 요인으로 남습니다.

RQ3: 캘리브레이션 가이드 수리

• 제한된 효능: 캘리브레이션 신호를 사용하여 수리를 유도하는 것은 보안 개선 효과가 미미하며, 종종 기능을 저하시킵니다.
• 구조적 장벽: API 교체가 필요한 싱크 교체(SR) 취약점은 모든 모델에서 0%의 수리 성공률을 기록했습니다. 모델은 보안 취약한 API를 교체하지 못하고, 기존 취약점을 유지하거나 피상적인 수정만을 도입합니다.
• 기능적 퇴보: 수리 시도가 기능적 정확성을 자주 깨뜨려(파손율 >60%), 전반적인 보안 성공률을 감소시킵니다. 캘리브레이션은 위험 계층화 신호로서의 역할은 수행할 수 있으나, 구조적 취약점에 대한 효과적인 자동 수리를 이끌어내지는 못합니다.

RQ4: 완화 전략

• 실행 게이팅: 가장 효과적인 완화책입니다. 보안 신뢰도를 묻기 전에 기능적으로 잘못된 코드를 먼저 필터링하면 모델 전반에서 ECE가 31–39% 감소합니다. 그러나 이는 46–86%의 샘플을 버려야 한다는 높은 비용을 수반합니다.
• 권한 부여된 파괴적 수리: API 변경을 명시적으로 허용하면 GPT와 Gemini의 취약점 제거율이 향상(35–42%)되지만, 여전히 높은 기능적 파손율과 낮은 엄격한 성공률을 보입니다.
• 프롬프팅 기법: 퓨샷 프롬프팅은 약 61–65%의 취약점을 제거하지만, 구조적 통합 불일치로 인해 엄격한 하네스 평가를 통과하는 경우는 드뭅니다. 사고 사슬(CoT) 추론을 추가하면 캘리브레이션이 저하되고 엄격한 성공률이 0%로 떨어집니다.

4. 주요 기여

1. 최초의 대규모 연구: 세 가지 모델, 여섯 가지 온도, 두 가지 서로 다른 개발 맥락에 걸쳐 36,000개의 샘플을 다룬, LLM 생성 코드의 보안 캘리브레이션에 대한 최초의 경험적 조사입니다.
2. 캘리브레이션 저하 분석: 고립된 함수에서 현실적인 저장소 수준 맥락으로 이동할 때 발생하는 심각한 캘리브레이션 페널티를 정량화하여, 교차 파일 의존성의 위험성을 강조했습니다.
3. 수리의 한계 입증: 캘리브레이션 가이드 수리가 특히 싱크 교체(Sink Replacement) 취약점에 대해 모델이 필수적인 구조적 변환을 수행하지 못하는 "경직성 장벽" 때문에 신뢰할 수 없음을 입증했습니다.
4. 완화 전략 평가: 실행 게이팅(architectural)과 프롬프트 수준(prompt-level) 개입을 체계적으로 평가하여, 실행 게이팅이 거짓 신뢰를 줄이는 데 가장 효과적이지만 높은 거부 비용이 따른다는 점을 확인했습니다.

5. 의의 및 주장

본 논문은 캘리브레이션이 단순한 정확도를 넘어, 보안이 중요한 환경에서 LLM의 핵심 평가 기준으로 삼아야 한다고 주장합니다. 연구 결과는 "보안이 LLM에게 더 어렵다"는 가정을 반박합니다. 대신, 본 연구는 기능적 캘리브레이션이 보안 캘리브레이션보다 더 나쁘다는 점을 밝혀냈으며, 이는 미스캘리브레이션이 보안 지식의 부족보다는 주로 숨겨진 런타임 제약(실행 취약성)에서 기인함을 시사합니다.

저자들의 주장은 다음과 같습니다:

• 자기 보고된 신뢰도는 신뢰할 수 없다: 높은 신뢰도를 가진 출력이 빈번하게 보안에 취약하여 체계적인 거짓 신뢰 위험을 초래합니다.
• 맥락이 중요하다: 자립형 프로그램을 기반으로 한 벤치마크는 저장소 수준 맥락에서 캘리브레이션이 급격히 저하되기 때문에, 실제 배포 시의 위험을 상당히 과소평가합니다.
• 수리는 만능 해결책이 아니다: 캘리브레이션 신호는 인간의 검토를 위한 샘플 우선순위를 정할 수는 있지만, 현재로서는 구조적 취약점에 대한 신뢰할 수 있는 자동 수리를 이끌어낼 수 없습니다.
• 실무자를 위한 가이드: 보안 평가는 반드시 기능 테스트(실행 게이팅) 이후에 이루어져야 하며, 실행 불확실성에 의한 오염을 피하기 위해 보안과 기능에 대한 신뢰도 신호는 별도로 추출해야 합니다.

결론적으로, LLM이 보안을 스스로 평가하는 능력을 어느 정도 보여주기는 하지만, 그들의 과잉 신뢰와 구조적 수리 능력의 부재는 특히 복잡한 다중 파일 개발 환경에서 인간의 감독이 필수적임을 시사합니다.