💻 computer science

Does Fixing Break Security? An Empirical Study of Security Degradation in Iterative LLM-Driven Infrastructure-as-Code Repair

이 경험적 연구는 5,968건의 반복적인 LLM 기반 IaC(Infrastructure-as-Code) 복구 시나리오를 분석하여, 표준 탐지 하에서는 보안 회귀가 최대 13.8%의 사례에서 발생하지만, 더 보수적인 엄격 모드(strict-mode) 분석을 적용하면 주로 리소스 재구조화에 의해 유발되는 방어 가능한 수준인 3.3%의 저하율을 보이며, 3회 반복 후 복구를 중단함으로써 이를 완화할 수 있음을 밝혀냈다.

원저자: Benjamin Agyekum, Fabio Santos

게시일 2026-08-14

📖 5 분 읽기🧠 심층 분석

CC BY 4.0

원저자: Benjamin Agyekum, Fabio Santos

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

당신이 디지털 블록으로 거대하고 정교한 성을 짓고 있다고 상상해 보세요. 이것은 단순한 성이 아닙니다. 인터넷, 당신이 즐겨 사용하는 앱, 그리고 클라우드 서비스를 실행하는 인프라입니다. 소프트웨어 공학의 세계에서 이를 **코드형 인프라(Infrastructure-as-Code, IaC)**라고 부릅니다. 메뉴에서 버튼을 클릭하는 대신, 엔지니어들은 컴퓨터에게 이 디지털 성을 어떻게 지을지 정확히 알려주는 텍스트 파일(코드)을 작성합니다. 최근에는 우리는 LLM(대규모 언어 모델)이라고 불리는 초지능형 AI 비서를 사용하여 우리 대신 이 코드를 작성하기 시작했습니다. 이는 마치 몇 초 만에 설계도를 그려내는 로봇 건축가를 고용하는 것과 같습니다.

하지만 여기 함정이 있습니다. 로봇은 실수를 합니다. 때때로 로봇이 그린 설계도에는 보안 구멍이 있을 수 있습니다. 예를 들어 앞문을 활짝 열어두거나 보물 상자의 잠금장치를 잊어버리는 식이죠. 이를 해결하기 위해 우리는 '피드백 루프'를 사용합니다. 우리는 보안 스캐너(디지털 검사관)를 실행하여 로봇의 작업물을 점검하고, 실수를 지적하며, 나쁜 소식을 로봇에게 다시 전달합니다. 그러면 로봇은 코드를 수정하여 다시 검사를 받습니다. 이 성이 매 라운드마다 더 안전해지기를 바라며 이 사이클은 반복됩니다. 여기서 핵심적인 질문은 다음과 같습니다: 하나의 문제를 고치는 과정에서 이미 안전했던 다른 무언가를 실수로 망가뜨리지는 않을까? 이것은 마치 배에 난 구멍을 때우려다가 실수로 선체에 구멍을 내는 것과 같습니다. 이 논문은 우리의 AI 조력자들이 실제로 상황을 더 안전하게 만들고 있는지, 아니면 그저 엉망진창으로 만들고 있는지를 확인하기 위해 바로 이 시나리오를 깊이 있게 파고듭니다.

로봇 건축가의 딜레마: 수정이 수정을 망칠 때

이 연구에서 연구자 Benjamin Agyekum과 Fabio Santos는 이러한 AI의 코드 수정 시도를 추적하기 위해 방대한 데이터셋을 가지고 탐정 놀이를 하기로 했습니다. 그들은 AI가 클라우드 인프라 코드를 구축하거나 수정하려고 시도한 거의 6,000개의 서로 다른 시나리오를 살펴보았습니다. 그들은 5번의 수정 라운드 동안 어떤 일이 일어나는지 관찰했으며, 30가지의 특정 보안 체크 항목(예: "데이터가 암호화되었는가?" 또는 "액세스가 차단되었는가?")을 추적했습니다.

그들의 주요 발견은 약간의 반전이 있습니다: 그렇습니다, 무언가를 고치는 것이 보안을 망가뜨릴 수 있지만, 처음 생각만큼 무서운 일은 아닙니다.

그들이 '표준적인' 방식으로 숫자를 계산했을 때, AI가 무언가를 고치려고 노력하는 동안 이전에 작동하던 보안 규칙을 깨뜨린 경우가 **13.8%**에 달한다는 것을 발견했습니다. 이는 많게 느껴지죠, 그렇지 않나요? 하지만 연구자들은 자신들의 계산 방식이 다소 까다롭다는 사실을 깨달았습니다. 코드는 종로 종종 여러 부분(건물의 여러 디지털 자물쇠처럼)을 포함하고 있기 때문에, AI가 하나의 자물쇠를 고치면서 실제 보안은 침해되지 않았음에도 불구하고 다른 자물쇠의 상태를 실수로 건드릴 수 있기 때문입니다.

그들이 명확하고 부정할 수 없는 사례, 즉 보안이 실제로 악화된 경우만을 찾아내는 '엄격한' 방식으로 계산 방식을 바꿨을 때, 그 수치는 단 **3.3%**로 급격히 떨어졌습니다. 이는 대부분의 '파손'이 실제 보안 재앙이 아니라, 코드의 복잡성으로 인해 발생한 혼란스러운 측정 오류였음을 시사합니다.

파손의 "이유"와 "방법"

그렇다면 AI가 정말로 실수를 할 때는 어떤 일이 벌어지는 걸까요? 연구자들은 그 원인이 거의 항상 **리소스 구조 재편(resource restructuring)**에 있다는 것을 발견했습니다. 로봇 건축가가 단순히 금을 때우는 대신 벽 전체를 완전히 새로 짓기로 결정했다고 상상해 보세요. 그 과정에서 새로운 벽에 보안 카메라를 다시 설치하는 것을 잊어버릴 수 있습니다. 보안이 실제로 퇴보한 사례의 **79%**에서 이런 일이 발생했습니다.

그들은 또한 AI 모델의 '성격'에 대해 흥적인 점을 발견했습니다. 한 모델(Mistral)은 표준 계산 방식을 사용할 때 다른 모델(Gemini)보다 무언가를 17배 더 자주 망가뜨리는 것으로 나타났습니다. 그러나 엄격한 방식을 사용했을 때, 두 모델 모두 독점적으로 무언가를 망가뜨리지는 않았습니다. 이는 '나쁜' 모델이 실제로 더 위험한 구멍을 만든 것이 아니라, 단지 계산 방식을 혼란스럽게 만드는 더 복적인 코드 구조를 생성했을 뿐이라는 것을 의미합니다.

스위트 스팟(Sweet Spot): 언제 수정을 멈출 것인가

가장 실용적인 발견 중 하나는 언제 멈춰야 하는가에 대한 것입니다. AI는 코드를 개선하기 위해 계속 시도하지만, 과연 멈추기는 할까요? 연구는 3번째 반복(AI가 코드를 수정하려고 시도하는 세 번째 시도)이 가장 적절한 지점(sweet spot)이라고 제안합니다.

3번째 시도까지 코드는 약 **83.1%**의 보안성을 갖춥니다.
만약 4번째나 5번째 시도까지 계속 간다면, 보안성은 거의 늘어나지 않지만(약 0.3% 증가), 무언가를 다시 망가뜨릴 위험은 커지기 시작합니다.

이는 라디오 튜닝과 같습니다: 어느 지점을 넘어서면, 다이얼을 돌려도 더 선명한 방송을 찾는 대신 잡음만 더 심해질 뿐입니다.

한 줄기 빛: 자기 수정

여기에 가장 희망적인 이야기가 있습니다. 연구자들은 AI가 실수로 보안 규칙을 깨뜨렸을 때, 그것이 스스로를 고치는 경우가 많다는 것을 발견했습니다. 약 **36.6%**의 경우, 바로 다음 라운드의 수정 단계에서 AI가 방금 저지른 실수를 바로잡았습니다. 이는 마치 로봇 건축가가 "앗, 문을 잘못 떼어냈네"라고 깨닫고 다음 단계에서 다시 붙여놓는 것과 같습니다.

하지만 그들은 또한 '줄다리기' 효과도 발견했습니다. 약 **28.5%**의 경우, 보안 체크가 통과, 실패, 통과, 실패를 반복하며 마치 멈출 곳을 정하지 못하는 추처럼 왔다 갔다 했습니다. 이는 주로 복잡한 액세스 제어에서 발생하며, AI가 해당 부분을 구축하는 최선의 방법을 여전히 파악하는 중임을 시사합니다.

결론

이 논문은 반복적인 AI 수정이 강력한 도구이지만, 그 성공을 측정하는 방식에 주의를 기울여야 한다고 말합니다.

모든 글리치(glitch)에 당황하지 마세요: 대부분의 겉보기 보안 파손은 실제 위험이 아니라 혼란스러운 측정상의 결과물입니다.
대규모 재작성을 경계하세요: AI가 작은 버그를 고치기 위해 코드의 전체 섹션을 허물기 시작한다면, 그때가 보안이 가장 빠지기 쉬운 때입니다.
세 번에서 멈추세요: AI가 코드를 고치도록 세 번 정도 시도하게 한 뒤, 그만두세요. 그 이상 진행하는 것은 보통 보상보다 위험을 더 많이 초래합니다.
올바른 도구를 사용하세요: 만약 매우 안전하게 가고 싶다면, 혼란스러운 다중 부분 오류를 무시하는 '엄격한' 방식을 사용하되, 만약을 대비해 '표준' 경고도 계속 주시하십시오.

요약하자면, AI는 유능한 견습생이지만, 언제 렌치를 놓아야 할지 알 수 있도록 인간 감독자가 필요합니다. 그렇지 않으면 볼트를 너무 세게 조여서 기계 전체를 부러뜨릴 수도 있습니다.

기술 요약: 수리가 보안을 파괴하는가? 반복적인 LLM 기반 IaC 수리에서의 보안 저하에 관한 실증 연구

문제 정의

Checkov 및 terraform validate와 같은 검증기가 에러 신호를 LLM에 다시 전달하여 연속적인 수리 시도를 수행하는 반복적 피드백 루프가 LLM 생성 IaC(Infrastructure-as-Code)를 개선하는 지배적인 패러다임이 되었으나, 기존 연구들은 주로 **누적 최선 지표(cumulative-best metrics)**에 의존해 왔습니다. 이러한 지표는 구성상 단조 증가하는 특성을 가진, 모든 반복 과정 중 달성된 가장 높은 준수 수준을 보고합니다. 결과적으로, IaC 영역에서 개별 반복당 발생하는 가공되지 않은 보안 궤적은 검토된 적이 없습니다.

본 연구는 보안 회귀(security regression) 현상을 다룹니다. 이는 다른 문제를 해결하기 위해 의도된 수리 반복 후에 이전에 통과했던 보안 체크(특히 CIS 벤치마크 컨트롤)가 실패하는 경우를 의미합니다. 명령형 언어와 취약점 수에 초점을 맞춘 일반 목적의 코드 수리 연구(예: Shukla et al. [25], Chen et al. [7])와 달리, 본 연구는 IaC의 독특한 과제를 조사합니다. IaC는 선언적이며, 보안 체크는 리소스 수준의 특정 구성 속성에 매핑됩니다. 결정적인 차이점은 단일 Checkov 체크 ID가 단일 구성 내의 여러 리소스에 적용될 수 있다는 점이며, 이는 특정 체크가 동시에 일부 리소스에서는 통과하고 다른 리소스에서는 실패할 수 있는 다중 리소스 모호성(multi-resource ambiguity) 클래스를 생성합니다. 이러한 모호성은 일반적인 코드와 비교했을 때 IaC에서의 "회귀" 정의를 복잡하게 만듭니다.

방법론

저자들은 IaC-Eval 벤치마크의 5,968개 시나리오 타임라인을 분석하는 대규모 실증 연구를 수행했습니다. 연구 설계는 다음과 같습니다:

구성(Configurations): 두 가지 모델별 RAG(Retrieval-Augmented Generation) 설정(Gemini 및 Mistral)과 아홉 가지 모델 집계 비-RAG 설정(Zero-Shot, Few-Shot, Chain-of-Thought)을 포함하는 15개의 고유한 실험 구성을 세 가지 온도(0.1, 0.4, 0.7)에서 실행했습니다.
프로세스(Process): 각 시나리오는 최대 5회의 수리 반복을 거쳤습니다. 파이프라인은 Terraform 코드를 생성, 검증하고 에러를 LLM에 다시 전달했습니다.
데이터 규모(Data Volume): 분석은 수리 전후 상태 모두에서 Checkov 데이터가 가용했던 4,440개의 반복 전이를 대상으로 했습니다.
추적(Tracking): 6가지 보안 카테고리(암호화, 액세스 제어, 로깅, 네트워킹, 데이터 보호, 기타)에 걸쳐 CIS AWS Foundations Benchmark 컨트롤에 매핑된 30개의 개별 Checkov 체크 ID를 추적했습니다.
탐지 모드(Detection Modes): 다중 리소스 모호성을 해결하기 위해 두 가지 탐지 모드를 정형화했습니다:
- 표준 모드 (Standard/Inclusive): 체크 ID가 반복 $i$ 에서 통과 세트에 존재하고 반복 $i+1$ 에서 실패 세트에 존재하면, 해당 체크가 다른 리소스에 대해 통과 여부와 상관없이 회귀로 간주합니다.
- 엄격 모드 (Strict/Exclusive): 체크 ID가 반복 $i$ 에서 독점적으로 통과(실패 없음)했고 반복 $i+1$ 에서 독점적으로 실패(통과 없음)한 경우에만 회귀로 간주합니다.
근본 원인 분석(Root Cause Analysis): 코드 디프(diff)를 리소스 재구조화(Resource Restructuring), 구성 드리프트(Configuration Drift), 인자 제거(Argument Removal), 미분류(Unclassified)의 네 가지 상호 배타적 범주로 분류했습니다.
통계 분석(Statistical Analysis): 연구에는 Chi-squared test, Mann-Whitney U test, Fisher's exact test 및 Bonferroni 교정을 적용한 효과 크기 측정치(Cramér's V, Cohen's d)가 활용되었습니다.

주요 기여

최초의 대규모 실증 연구: 누적 최선 지표를 넘어 보안 회귀를 탐지하기 위해 반복적인 LLM 기반 IaC 수리의 반복당 보안 궤적을 분석한 최초의 연구입니다.
회귀 분류 체계(Regression Taxonomy): 회귀 근본 원인에 대한 분류 체계를 도출하였으며, **리소스 재구조화(Resource Restructuring)**가 지배적인 원인(표준 모드에서 79.0%)임을 식별했습니다.
탐지 모드 구분: 표준 모드와 엄격 모드의 구분을 정형화하여, 탐지 모드의 선택이 모델 성능 및 위험 분포에 대한 결론을 질적으로 변화시킨다는 점을 입증했습니다.
보안-정확성 트레이드오프 정량화: 코드 변경과 보안 저하 사이의 관계를 정량화하여, 회귀 전이가 유의미하게 더 높은 코드 변동성(churn)과 체크 휘발성을 수반함을 보여주었습니다.
실행 가능한 가이드라인: 반복 횟수 예산과 구성 선택에 대한 구체적인 가이드를 제공하며, 반복 3회를 최적의 중단 시점으로 식별하고 피드백 루프의 자기 수정 능력을 강조했습니다.

주요 결과

RQ1: 회귀 빈도

표준 모드: 13.8%의 시나리오(전이의 24.8%)가 적어도 하나의 보안 회귀를 보였습니다.
엄격 모드: 모호하지 않은 독점적 실패를 필터링했을 때, 회귀율은 3.3%의 시나리오(전이의 5.2%)로 감소합니다.
해석: 표준 모드와 엄격 모드 사이의 격차는 약 76%의 겉보기 회귀가 실제 독점적 실패가 아닌 다중 리소스 측정 아티팩트임을 나타냅니다.

RQ2: 취약한 보안 컨트롤

표준 모드: IAM 관련 체크(예: CKV_AWS_356, CKV_AWS_111)에 의해 **액세스 제어(Access Control)**가 지배적입니다(38.5%).
엄격 모드: 순위가 역전됩니다. 네트워킹(Networking)(42.6%)과 암호화(Encryption)(21.6%)가 주요 위험이 되며, 액세스 제어는 9.2%로 떨어집니다.
시사점: 액세스 제어 회귀는 주로 다중 리소스 모호성의 아티팩트(예: 하나의 IAM 역할은 통과하지만 다른 역할은 실패함)인 반면, 네트워킹과 암호화 회귀는 실제 독점적 실패를 나타냅니다.

RQ3: 구성 요소(Configuration Factors)

모델 격차 (RAG 구성): 표준 모드에서 Mistral은 Gemini보다 17배 높은 회귀율을 보였습니다. 그러나 이 격차는 RAG 구성의 엄격 모드에서 완전히 사라지며, RAG+Gemini와 RAG+Mistral 모두 단 하나의 엄격 모드 시나리오 회귀도 발생시키지 않았습니다(각각 0/1,297 및 0/929). 이는 해당 격차가 다중 리소스 모호성에 의한 것임을 확인시켜 줍니다.
RAG 효과: RAG는 비-RAG 전략에 비해 표준 모드에서는 더 높은 회귀율을 보이지만, 엄격 모드에서는 더 낮은(제로) 회귀율을 보입니다. 이는 RAG가 더 포괄적인 다중 리소스 구조를 생성하지만(표준 카운트 증가), 개별 보안 속성에 대해서는 더 나은 근거(grounding)를 제공함(독점적 실패 감소)을 시사합니다.
온도(Temperature): 온도는 통계적으로 유의미했으나 실질적으로는 무시할 만한 수준이었습니다 (Cramér's V = 0.049).

RQ4: 보안-정확성 트레이드오프

코드 변동성(Code Churn): 회귀 전이는 비-회귀 전이에 비해 2.6배 더 많은 코드 변동성(변경 된 라인 수)과 낮은 텍스트 유사성을 보입니다.
체크 휘발성(Check Volatility): 이것이 가장 강력한 예측 변수입니다. 회귀 전이는 4.9배 더 높은 엄격 모드 체크 휘발성(Cohen's d = 1.49)을 보입니다.
구문 수정(Syntax Fixes): 구문 수정 직후의 전이는 표준 모드에서 21% 더 높은 회귀 위험을 수반합니다.
클린 타임라인(Clean Timelines): 역설적으로, 내내 유효한 구문을 유지한("클린") 시나리오는 구문 에러로 고전한 시나리오(12.1%)보다 더 높은 회귀율(20.8%)을 보였습니다.

추가 발견 사항

자기 수정(Self-Correction): 36.6%의 표준 모드 회귀는 평균 1.2회의 반복 내에 스스로 수정되었으며, 이는 피드백 루프가 종종 자신의 실수를 잡아냄을 시사합니다.
진동(Oscillation): 28.5%의 시나리오가 (통과, 실패, 다시 통과와 같은) 체크 진동 현상을 보였으며, 특히 IAM 구성에서 두드러졌습니다.
최적 중단 시점: 반복 3회가 최적의 중단 시점으로 식별되었습니다. 이는 최고 통과율의 83.1%를 확보하면서(피크와 0.3 퍼센트 포인트 차이) 회귀 위험을 관리 가능한 수준으로 유지합니다.

의의 및 주장

본 논문은 반복적인 IaC 수리가 보안 회귀를 도입한다는 최초의 실증적 증거를 제공하며, 그 심각성은 탐지 방법론에 따라 달라진다고 주장합니다. 저자들은 "보수적이고 방어적인 비율"인 실제 독점적 회귀가 약 **3.3%**에 불과하지만, 이 현상은 무시할 수 없으며 기존 연구에서 사용된 누적 최선 지표에 의해 완전히 가려져 있다고 단언합니다.

본 연구는 리소스 재구조화가 프롬프팅 전략이나 온도 자체보다 주요한 저하 동인임을 강조합니다. 연구 결과는 다음과 같은 보안 인식 피드백 루프 설계를 촉구합니다:

다중 리소스 아티팩트와 독점적 실패를 구분할 것.
경미한 수정이 필요한 경우 모델이 전체 리소스 블록을 재생성하지 않도록 "보안 앵커링(security anchoring)"을 구현할 것.
컴플라이언스 이득과 회귀 위험 사이의 균형을 맞추기 위해 약 3회의 반복 예산을 채택할 것.
체크 휘발성을 실시간 신호로 활용하여 수리 루프를 중단하거나 플래그를 지정할 것.

저자들은 반복적인 수리가 전반적인 컴플라이언스를 개선하지만, IaCs의 선언적이고 다중 리소스적인 특성을 고려할 때 새로운 탐지 방법론과 운영적 안전장치가 필요한 특정 유형의 보안 저하를 유발한다고 결론짓습니다.