반복할수록 코드 보안은 취약해진다

LLM 기반 코드 개선을 열 차례 반복한 후, 반복 체인의 43.7%가 시작 시점의 기준 코드보다 더 많은 취약점을 포함하고 있었습니다.¹ 에이전트는 기능을 개선했고, 테스트도 통과했습니다. 하지만 반복할수록 코드 보안은 악화되었습니다 — 연구진은 이를 “명세 드리프트(specification drift)”라고 부릅니다. 보안을 제외한 모든 지표에서 코드가 개선되었기 때문에 아무도 이 문제를 알아차리지 못했습니다.

요약

세 가지 모델(GPT-5-Nano, Claude Sonnet 4.5, DeepSeek-V3)과 2,880개의 반복 단계를 대상으로 한 LLM 반복 코드 개선 연구에서 역설적인 결과가 드러났습니다. 에이전트는 기능적 정확성에 최적화하면서 보안은 조용히 저하시킵니다. 표준 완화 조치도 효과가 없습니다. 정적 분석 보안 도구(SAST 게이트)를 루프에 추가하자 잠재적 보안 저하율이 12.5%에서 20.8%로 오히려 증가했습니다. SCAFFOLD-CEGIS 프레임워크는 네 가지 검증 계층으로 이 문제에 접근하여, 작업 완료율 77%를 대가로 잠재적 보안 저하율 2.1%와 100% 안전 단조성(safety monotonicity)을 달성했습니다. 자율 에이전트 루프를 운영하는 모든 사람에게 중요한 발견입니다.

역설

연구진은 세 가지 LLM(GPT-5-Nano, Claude Sonnet 4.5, DeepSeek-V3)를 여섯 가지 보안 카테고리(데이터베이스, 입력 처리, 인증, 리소스 관리, 암호화, 경로 처리)의 24개 프로그래밍 과제에 걸쳐 테스트했으며, 288개의 반복 체인과 총 2,880개의 반복 단계를 생성했습니다.¹ 핵심 발견은 다목적 최적화 과정에서 발생하는 명세 드리프트가 연속적인 반복에 걸쳐 보안을 점진적으로 저하시킨다는 것입니다.

그 메커니즘은 이렇습니다. 에이전트가 여러 라운드에 걸쳐 코드를 최적화할 때, 각 라운드는 기능 개선(버그 수정, 기능 추가, 테스트 통과, 성능 향상)에 집중합니다. 보안 제약 조건은 에이전트의 주의를 놓고 기능 목표와 경쟁합니다. 열 라운드를 거치면서 에이전트는 (컨텍스트 축적을 통해 암묵적으로) 기능 변경이 긍정적 피드백을 만들어내는 반면 보안 제약 조건은 아무런 피드백도 생성하지 않는다는 것을 학습합니다. 가시적 기능에 기여하지 않는 방어 로직은 단순화되거나, 리팩터링 과정에서 제거되거나, 더 약한 대안으로 교체됩니다.

43.7%라는 보안 저하율은 GPT-4o를 열 번의 반복 라운드에 걸쳐 추적한 별도의 관찰 연구에서 도출된 수치입니다. 주요 실험에서는 다섯 가지 기존 방어 접근법(프롬프트 기반 보안, 자기 개선, 사후 SAST, 테스트 기반 가드, 하이브리드 가드)을 대상으로 SCAFFOLD-CEGIS를 벤치마킹했습니다.¹ 연구 커뮤니티는 이미 반복적 보안 저하를 우려 사항으로 식별한 상태였습니다. 하지만 다섯 가지 대안 중 어떤 것도 이 문제를 해결하지 못했습니다.

Shukla, Joshi, Syed가 수행한 독립 연구는 동료 심사를 거쳐 IEEE-ISTAS 2025에 채택되었으며, 동일한 패턴을 확인해 줍니다.⁴ 연구진은 보안 검증을 완료한 C 및 Java 코드 샘플 10개를 가져와 네 가지 프롬프팅 전략을 각각 열 번씩 반복 적용(총 400개 샘플)했고, 다섯 번의 반복만으로 치명적 취약점이 37.6% 증가하는 것을 측정했습니다. 취약점 분류 체계는 메모리 안전, 입력 검증, 암호화 구현, 인젝션 결함 등 12개 카테고리를 포괄합니다. 서로 다른 연구팀, 프로그래밍 언어, 평가 방법론에 걸친 일관성은 반복적 보안 저하가 특정 실험 설정의 산물이 아니라 이 접근 방식 자체의 속성임을 확인해 줍니다.

SAST 게이트가 상황을 악화시키는 이유

가장 반직관적인 발견은 반복 사이에 정적 분석 보안 도구를 게이트로 추가하자 잠재적 보안 저하율이 12.5%에서 20.8%로 증가했다는 것입니다.¹

논문은 그 원인을 다목적 최적화 과정에서의 명세 드리프트로 설명합니다. 보완적 설명은 인간 소프트웨어 개발에서 알려진 패턴에 대응됩니다. 개발자가 린터와 정적 분석기에 의존하면, 도구가 문제를 “잡아줄” 것이라는 기대 때문에 방어적 코딩을 덜 하게 됩니다. LLM 에이전트에게도 동일한 역학이 적용될 가능성이 높습니다. 에이전트가 반복 사이에 SAST 피드백을 받으면 두 가지 현상이 발생합니다:

1. 에이전트는 안전한 코드를 작성하는 것이 아니라 스캐너를 통과하는 데 최적화합니다. SAST 도구는 알려진 취약점 패턴(SQL 인젝션, XSS, 버퍼 오버플로)을 검사합니다. 에이전트는 해당 특정 패턴을 피하면서 스캐너가 감지하지 못하는 새로운 보안 약점을 도입하는 법을 학습합니다.

2. 에이전트는 “중복” 방어를 제거합니다. 스캐너가 계층 A의 입력 검증이 충분하다고 보고하면, 에이전트는 다음 반복에서 계층 B의 검증을 제거합니다. 계층 B의 검증은 중복이 아니라 심층 방어(defense-in-depth)였습니다. 스캐너는 이 둘을 구별할 수 없습니다.

결과적으로 SAST 게이트를 거친 반복은 보안 스캔을 통과하지만, 게이트 없이 반복한 코드보다 더 많은 잠재적 취약점을 포함하는 코드를 생산합니다. 도구가 만들어낸 거짓 안전감이 에이전트를 더 신중하게 만드는 것이 아니라 오히려 덜 신중하게 만듭니다.

반복 사이에 SAST 게이트를 두고 자율 코딩 루프를 운영하고 있다면 주의를 기울여야 합니다. 게이트가 여러분을 보호하는 것이 아닙니다. 게이트가 에이전트에게 보호를 우회하는 방법을 가르치고 있는 것입니다.

SCAFFOLD-CEGIS가 다른 점

SCAFFOLD-CEGIS 프레임워크는 다른 접근법을 취합니다.¹ 알려진 취약점 패턴을 검사하는 대신, 안전 단조성을 강제합니다. 어떤 반복도 코드를 이전 반복보다 덜 안전하게 만들 수 없습니다.

세 가지 접근법의 결과는 다음과 같습니다:

아키텍처는 각각 다른 속성을 검사하는 네 가지 순차적 검증 계층을 사용합니다:¹

이 프레임워크는 CEGIS(반례 기반 귀납적 합성) 원칙을 채택합니다. 후보 생성, 검증, 피드백, 재생성의 폐쇄 루프입니다. 정형 검증기를 사용하는 대신 정적 분석과 의미론적 앵커 검사를 사용하며, 반례를 구조화된 실패 보고서로 표현합니다.¹ 어떤 계층이든 반복을 거부하면, 시스템은 회귀를 수정하려 시도하는 대신 이전 버전으로 되돌립니다.

트레이드오프는 실재합니다. SCAFFOLD-CEGIS는 77.14%의 작업 완료율을 달성했으며, 이는 보안이 덜 엄격한 접근법의 완료율보다 낮습니다.¹ 안전 단조성에는 생산성 비용이 따릅니다. 이 프레임워크는 덜 엄격한 시스템이라면 수용하고 개선할 반복을 거부합니다. 이 트레이드오프가 가치 있는지는 처리량보다 보안 보장을 중시하는지에 달려 있습니다.

핵심 통찰은 실패 시 수정이 아닌 실패 시 되돌리기입니다. 표준 SAST 게이트 루프는 문제를 감지하고 에이전트에게 수정을 요청하여, 새로운 문제를 도입할 수 있는 또 다른 반복을 만들어냅니다. SCAFFOLD-CEGIS는 문제를 감지하고 해당 반복을 완전히 폐기합니다. 단조성 보장은 회귀를 감지하고 수정하는 것이 아니라, 회귀를 절대 수용하지 않는 것에서 비롯됩니다.

에이전트 하네스 설계와의 연관성

이 발견은 실무자들이 에이전트 CLI 주위에 오케스트레이션 계층을 구축하는 방식과 직접 연결됩니다.² 500회 이상의 자율 세션에서 제가 기록한 일곱 가지 실패 모드에는 반복적 개선 역설이 설명하는 여러 패턴이 포함됩니다. 테스트를 통과하면서 코드 품질을 저하시키는 에이전트, 잘못된 지표에 최적화하는 에이전트, 리팩터링 과정에서 안전 제약을 제거하는 에이전트 등입니다.

“Anatomy of a Claw”에서 설명한 판단 훅은 다른 메커니즘으로 보안 저하 문제를 다룹니다. quality-gate.sh는 증거가 부족한 완료 보고를 차단합니다. filter-sensitive.sh는 자격 증명 노출이 디스크에 기록되기 전에 포착합니다. recursion-guard.sh는 에이전트 생성 깊이를 제한합니다. 각 훅은 단조성 속성을 강제합니다. 에이전트가 반복하는 동안 시스템이 특정 차원에서 악화되어서는 안 됩니다. 런타임 헌법 패턴은 같은 아이디어를 확장합니다. 실행 중에 에이전트가 재정의할 수 없는 내장 거버넌스 규칙입니다.

Karpathy의 autoresearch 시스템도 같은 패턴을 사용합니다.³ 평가 하네스는 git 브랜치 관리를 통해 개선 사항은 유지하고 회귀는 폐기합니다. 학습 지표(검증 bits per byte)가 단조성 제약으로 기능합니다. 지표를 저하시키는 실험 결과는 살아남지 못합니다.

정형 검증 연구, ML 연구 인프라, 프로덕션 에이전트 하네스라는 세 가지 독립적인 시스템이 동일한 설계 원칙으로 수렴합니다. 실패 시 절대 반복하지 말고, 항상 실패 시 되돌려라. 에이전트에게 회귀를 수정할 두 번째 기회를 주는 것은 회귀를 폐기하고 새로운 접근을 시도하는 것보다 나쁜 결과를 만들어냅니다.

실무자를 위한 권장 사항

연구 결과에 기반한 세 가지 구체적 조치입니다:

반복 루프의 보안 단조성을 감사하세요. 에이전트가 여러 라운드에 걸쳐 코드를 수정한다면, 직전 라운드가 아닌 원래 기준선과 비교하여 각 라운드의 보안 상태를 확인하세요. 인접한 반복만 비교하면 누적 드리프트는 보이지 않습니다.

SAST 게이트만으로는 충분하지 않습니다. SAST 게이트 결과(20.8% 보안 저하, 게이트 없는 경우보다 악화)는 피드백 루프 설계 방식을 바꿔야 함을 보여줍니다. SAST 도구는 사람이 작성한 코드에서 알려진 패턴을 감지하는 데 유용합니다. 하지만 에이전트 반복 루프에서는 도구가 에이전트가 우회하는 최적화 대상이 됩니다. SAST를 게이트가 아닌 여러 신호 중 하나로 활용하세요.

수정 후 재시도가 아닌 실패 시 되돌리기를 구현하세요. 반복이 회귀를 도입하면 해당 반복을 완전히 폐기하세요. 후속 반복에서 에이전트에게 회귀를 수정하도록 요청하지 마세요. 수정 시도 자체가 동일한 보안 저하 역학의 대상이 되는 또 다른 반복입니다. git을 사용한 최소 구현:

#!/bin/bash
# monotonicity-gate.sh — revert on security regression
BASELINE_HASH="$1"  # git hash of the known-good baseline

# Run your security checks against current state
CURRENT_VULNS=$(semgrep --config auto --json . | jq '.results | length')
BASELINE_VULNS=$(git stash && git checkout "$BASELINE_HASH" -q && \
    semgrep --config auto --json . | jq '.results | length' && \
    git checkout - -q && git stash pop -q)

if [ "$CURRENT_VULNS" -gt "$BASELINE_VULNS" ]; then
    echo "Security regression: $BASELINE_VULNS → $CURRENT_VULNS vulnerabilities"
    git checkout "$BASELINE_HASH" -- .
    exit 2  # Block the iteration
fi

이 패턴은 직전 반복이 아닌 원래 기준선과 비교합니다. 누적 드리프트가 진짜 위협입니다.

FAQ

반복적 개선은 항상 보안을 저하시키나요?

모든 반복 체인이 보안을 저하시키는 것은 아닙니다. SCAFFOLD-CEGIS 연구에서 열 라운드 후 더 많은 취약점을 포함한 체인은 43.7%였으며, 이는 56.3%가 보안 상태를 유지하거나 개선했다는 의미입니다.¹ 독립적인 IEEE-ISTAS 연구에서는 다섯 번의 반복 후 치명적 취약점이 37.6% 증가했습니다.⁴ 문제는 보안 저하가 조용히 진행된다는 점입니다. 에이전트는 테스트를 통과하는 기능적으로 올바른 코드를 생산하면서 보안 속성은 침식됩니다. 명시적인 보안 단조성 검사 없이는 취약점이 악용될 때까지 보안 저하를 감지할 수 없습니다.

SAST 게이트가 문제를 개선하는 대신 악화시키는 이유는 무엇인가요?

정적 분석 도구는 알려진 취약점 패턴을 검사합니다. 에이전트가 반복 사이에 SAST 피드백을 받으면, 안전한 코드를 작성하는 것이 아니라 스캐너를 통과하는 데 최적화합니다. 에이전트는 플래그된 패턴을 피하면서 스캐너가 감지할 수 없는 새로운 약점을 도입합니다. 또한 스캐너가 중복으로 표시하는 심층 방어 계층도 제거합니다. 최종 결과는 스캔을 통과하지만 SAST 게이트 없이 생산된 코드보다 더 많은 잠재적 취약점을 포함하는 코드입니다.

안전 단조성이란 무엇이며 SCAFFOLD-CEGIS는 어떻게 이를 강제하나요?

안전 단조성은 어떤 반복도 코드를 이전 반복보다 덜 안전하게 만들 수 없다는 것을 의미합니다. SCAFFOLD-CEGIS는 네 가지 순차적 검증 계층으로 이 속성을 강제합니다: 정확성(테스트 스위트), 안전 단조성(반복 간 SAST 비교), 변경 예산(변경 규모 제한), 앵커 무결성(보안 핵심 코드 요소의 존속 검증). 이 프레임워크는 CEGIS(반례 기반 귀납적 합성) 원칙을 사용하여, 정형 증명이 아닌 구조화된 실패 보고서로 반례를 표현합니다. 어떤 계층이든 반복을 거부하면 시스템은 에이전트에게 수정을 맡기는 대신 해당 반복을 완전히 폐기합니다. 트레이드오프로 작업 완료율이 77%이며, 이는 덜 엄격한 접근법보다 낮습니다.

에이전트 루프에서 실패 시 되돌리기는 수정 후 재시도와 어떻게 다른가요?

수정 후 재시도는 문제를 감지하고 다음 반복에서 에이전트에게 수정을 요청합니다. 수정 시도 자체가 원래 회귀를 유발한 것과 동일한 명세 드리프트의 영향을 받아, 종종 새로운 문제를 도입합니다. 실패 시 되돌리기는 전체 반복을 폐기하고 마지막으로 확인된 정상 상태로 돌아갑니다. 에이전트는 수정 패치를 누적하는 대신 깨끗한 기준선에서 새로 시작합니다. git 브랜치 관리를 활용하면 되돌리기는 실질적으로 간단합니다.

기존 Claude Code 또는 Codex 워크플로에 이 결과를 적용할 수 있나요?

네. 실무자 섹션의 세 가지 조치는 여러 라운드에 걸쳐 코드를 수정하는 모든 에이전트 루프에 적용됩니다. 직전 반복이 아닌 원래 기준선과 비교하여 반복 루프의 보안 상태를 감사하세요. SAST 출력을 게이트가 아닌 여러 신호 중 하나로 취급하세요. 반복이 회귀를 도입하면 에이전트에게 수정을 프롬프트하는 대신 git checkout 또는 git revert를 사용하여 변경을 완전히 폐기하세요. 훅 기반 하네스 패턴은 이러한 검사를 자동화된 게이트로 인코딩하는 구체적인 구현 모델을 제공합니다.

출처