Why LLMs Fail: A Failure Analysis and Partial Success Measurement for Automated Security Patch Generation

이 논문은 Vul4J 벤치마크를 통해 LLM 이 생성한 보안 패치의 성공률을 분석한 결과, 문법적 오류는 적으나 의미적 오해로 인해 보안 및 기능적 실패율이 높음을 규명하고 이를 정량화하는 보안 복구 점수 (SRS) 를 제안했습니다.

핵심

🍳 핵심 비유: AI 요리사와 위험한 식재료

상상해 보세요. 여러분은 식당을 운영 중이고, 식재료에 **유독한 버섯 (보안 취약점)**이 섞여 있습니다. 이 버섯을 제거하고 맛있는 요리를 만들어야 합니다. 여러분은 **AI 요리사 (LLM)**에게 "이 버섯을 제거하고 원래 맛은 그대로 유지해"라고 시켰습니다.

하지만 결과는 어떨까요?

1. 결과는 어땠나요? (성공률 25% 미만)

연구진은 AI 가 만든 요리 319 가지를 맛보고 검사했습니다.

• 완벽한 성공 (24.8%): 버섯도 완벽하게 제거되고, 맛도 그대로인 요리.
• 완전한 실패 (51.4%): 버섯은 그대로 남아있는데, 요리 맛까지 망쳐버린 경우. (가장 많음)
• 가장 위험한 실패 (10.3%): 버섯은 여전히 남아있는데, 맛은 완벽하게 유지된 요리.

💡 교훈: AI 는 요리의 '맛 (기능)'을 유지하는 건 잘하지만, '유독한 버섯 (보안 문제)'을 찾아내는 건 매우 서툴러요. 특히 맛은 그대로인데 독만 남아있는 요리가 가장 위험합니다. 왜냐하면 사람들이 "맛있네?" 하고 먹어버렸다가 중독될 수 있기 때문입니다.

2. 왜 실패할까요? (문법 vs 의미)

AI 는 문법 (문장 구조) 은 아주 잘 맞춥니다. 마치 "소금 1 스푼, 설탕 1 스푼"이라는 레시피를 정확히 읽는 것처럼요. 하지만 **의미 (무엇을 해야 하는지)**를 오해합니다.

• 비유: AI 는 "유독 버섯을 제거하라"는 지시를 들었을 때, 버섯을 잘라내는 게 아니라 버섯을 숨기거나, 아예 요리를 통째로 없애버리는 실수를 합니다.
• 연구 결과: 실패한 요리 100 개 중 50 개 이상이 "버섯 제거 방법"을 완전히 잘못 이해해서, 독은 그대로 둔 채 요리를 망친 경우였습니다.

3. 어떤 문제가 가장 어려울까요? (문제 유형에 따른 난이도)

모든 보안 문제가 같은 난이도는 아닙니다.

• 쉬운 문제 (무한 루프): "요리할 때 불을 끄지 않고 계속 돌리는 문제" 같은 건 AI 가 45% 정도 잘 고칩니다. 기계적인 규칙을 따르기 쉽기 때문입니다.
• 아주 어려운 문제 (입력 검증): "손님이 가져온 재료가 안전한지 판단하는 문제"는 AI 가 **0%**도 못 고쳤습니다. 왜냐면 "무엇이 안전한지"는 상황마다 다르고, AI 가 그 '맥락'을 이해하지 못하기 때문입니다.

4. AI 는 조금만 고치면 될까요? (이분법적 성공)

우리는 "AI 가 90% 는 맞췄으니, 조금만 수정하면 되겠지?"라고 생각할 수 있습니다. 하지만 이 연구는 그런 중간 단계는 거의 없다고 말합니다.

• 비유: AI 는 요리가 완벽하거나, 아니면 완전히 망친 상태입니다. "조금만 더 다듬으면 될 것 같은" 중간 단계 (90% 성공) 는 거의 없었습니다.
• 의미: 실패한 요리를 조금만 고쳐서 쓸 수 있게 만들기는 어렵습니다. 처음부터 다시 생각해야 할 가능성이 높습니다.

---

📝 연구자가 남긴 3 가지 중요한 메시지

1. AI 가 만든 보안 수정은 절대 믿지 마세요.
   AI 가 "수정 완료!"라고 해도, 실제로는 독이 남아있을 수 있습니다. 특히 **접근 권한 (누가 들어갈 수 있는지)**이나 입력 검증 (무엇을 받아들이는지) 관련 문제는 AI 가 매우 서툴러서 인간이 반드시 다시 확인해야 합니다.

2. 기능과 보안은 상충하지 않습니다.
   "보안을 강화하면 기능이 망가질 수밖에 없다"는 생각은 틀렸습니다. AI 가 실패한 이유는 보안을 지키느라 기능을 망친 게 아니라, 보안을 어떻게 지켜야 할지 몰라서 기능을 망친 것입니다.

3. 문제 유형에 따라 전략을 바꿔야 합니다.
   모든 문제를 AI 에게 맡기지 말고, 기계적으로 고칠 수 있는 문제는 AI 에게, 하지만 맥락이 중요한 복잡한 문제는 인간 전문가가 처리하게 하거나, AI 에게 더 구체적인 지시 (예: "이 특정 버섯은 이렇게 제거해") 를 내려야 합니다.

🚀 결론

이 논문은 **"AI 는 코딩 실력은 좋지만, 보안 감각은 아직 초보 수준"**이라고 경고합니다. AI 가 만든 보안 수정 코드를 바로 배포하는 것은, 유독 버섯이 섞인 요리를 맛만 보고 내주는 것과 같다는 뜻입니다. 따라서 AI 의 결과를 사용할 때는 반드시 **인간의 엄격한 검증 (PoV 테스트 등)**이 필수적입니다.

기술 요약

1. 연구 배경 및 문제 제기 (Problem)

• 배경: 대규모 언어 모델 (LLM) 은 기능적 버그 수정 (Automated Program Repair, APR) 에서 Defects4J 나 SWE-bench 와 같은 벤치마크에서 좋은 성과를 보이고 있습니다.
• 문제: 그러나 보안 취약점 수정에 있어 LLM 의 효과는 여전히 불명확하며, 다음과 같은 근본적인 문제가 존재합니다.
  • 기존 개발자 테스트 스위트는 '예상 동작'을 검증할 뿐, '적대적 입력 (Adversarial Input)'에 대한 방어를 검증하지 못함.
  • LLM 이 생성한 코드는 모든 테스트를 통과하더라도 여전히 취약할 수 있음 (보안과 기능성 간의 긴장 관계).
  • 최근 연구에 따르면 LLM 은 인간 개발자보다 약 9 배 더 높은 비율로 취약점을 도입하는 것으로 나타남.
• 연구 목적: LLM 이 생성한 보안 패치가 어떻게 실패하는지 체계적으로 분석하고, 부분적 성공을 정량화하며, 수정 난이도를 예측하는 요인을 규명하는 것.

2. 연구 방법론 (Methodology)

• 데이터셋: Vul4J 벤치마크의 64 개 Java 보안 취약점 사용.
• 모델 및 생성: Gemini 2.0 Flash (Zero-shot 프롬프트) 를 사용하여 각 취약점당 5 개의 패치 생성 (총 320 개 중 319 개 유효 데이터).
• 평가 프로토콜 (3 축 평가):
  1. 컴파일 (Compilation): Maven/Gradle 을 통한 컴파일 성공 여부.
  2. 보안성 (Security): Proof-of-Vulnerability (PoV) 테스트 실행 및 Semgrep(정적 분석) 을 통한 잔여 이슈 확인.
  3. 기능성 (Functionality): 전체 개발자 테스트 스위트 실행.
• 새로운 지표 제안:
  • Security Repair Score (SRS): 컴파일 성공 여부 ($C$), 보안 점수 ($S_{score}$), 기능성 점수 ($F_{score}$) 를 결합한 연속적 지표.
  • $SRS = C \times (0.5 \cdot S_{score} + 0.5 \cdot F_{score})$
  • 이를 통해 패치가 완전히 성공했는지, 아니면 부분적으로 성공했는지 (예: 기능은 유지되나 보안은 실패) 를 정량화.

3. 주요 기여 (Key Contributions)

1. LLM 보안 패치 실패 분류 체계 (Taxonomy): 패치가 실패하는 구체적인 모드 (구문 오류, 전략 오류, 기능 파괴 등) 를 분류.
2. Security Repair Score (SRS) 제안: 이진법 (성공/실패) 이 아닌 연속적인 지표를 통해 부분적 성공을 측정.
3. CWE 별 난이도 패턴 식별: 취약점 유형 (CWE) 이 수정 성공률에 미치는 영향 분석.
4. 실무자 가이드라인: LLM 생성 패치 배포 전 검증의 중요성과 취약점 유형별 주의 사항 제시.

4. 연구 결과 및 발견 (Results & Findings)

RQ1: 패치는 어떻게 실패하는가?

• 완전 성공률 낮음: 생성된 319 개 패치 중 24.8% 만 완전히 정확하고 안전한 것으로 확인됨.
• 주된 실패 원인: 의미론적 오해 (Semantic Misunderstanding).
  • 전체의 51.4% 가 보안과 기능성 모두에서 실패 (잘못된 수정 전략 적용).
  • LLM 은 문법적으로 올바른 코드를 생성하지만 (컴파일 성공률 86.8%), 보안 로직을 잘못 이해하여 근본적으로 틀린 수정 전략을 적용함.
• 가장 위험한 실패 모드: 10.3% 의 패치는 기능은 정상 작동하지만 보안 취약점이 남아있는 상태 (Insecure & Functional). 이는 CI/CD 파이프라인을 통과하여 배포될 위험이 가장 큼. 특히 권한 관리 (CWE-264) 취약점에서 이 비율이 35% 로 높게 나타남.

RQ2: 패치는 어느 정도 부분적으로 성공하는가?

• 기능성 vs 보안성 비대칭:
  • 기능성 점수 평균: 0.832 (높음)
  • 보안 점수 평균: 0.251 (매우 낮음)
  • LLM 은 기존 프로그램 동작을 유지하는 능력은 뛰어나지만, 특정 보안 속성을 해결하는 데는 실패함.
• 이분법적 성공 패턴 (Bimodal Distribution):
  • 패치 성과는 '완전 성공 (SRS≈1.0)' 또는 '대부분 실패 (SRS≈0.5)'로 양극화됨.
  • 0.3% 만 '근접 성공 (Near-success, 0.8≤SRS<1.0)' 구간을 차지. 이는 LLM 의 보안 패치 능력이 '전부 아니면 전무 (All-or-nothing)' 특성을 가지며, 프롬프트 미세 조정으로 점진적으로 개선하기 어렵다는 것을 시사함.
• 보안 - 기능성 트레이드오프 부재: 보안 수정이 기능성을 해친다는 상관관계는 통계적으로 유의미하지 않음. 즉, 보안과 기능성을 동시에 달성하는 것이 가능함.

RQ3: 어떤 특성이 수정 난이도를 예측하는가?

• CWE 유형이 결정적: 취약점 유형에 따라 수정 성공률이 크게 다름.
  • 0% 성공: 입력 유효성 검사 (CWE-20). 도메인 지식 필요로 인해 LLM 이 실패.
  • 45% 성공: 무한 루프 (CWE-835). 기계적인 수정이 가능하여 상대적으로 성공率高.
• 패치 크기와 난이도: 인간이 작성한 패치 크기가 클수록 LLM 의 성공률은 낮아짐 (Spearman 상관관계 $\rho = -0.331$).
• 코드 복잡도 무관: 줄 수 (LOC) 나 순환 복잡도 (Cyclomatic Complexity) 는 난이도와 상관관계가 없었음. 이는 문제가 코드 구조의 복잡함이 아니라 무엇을 수정해야 하는지에 대한 의미론적 이해에 있음을 의미.

5. 의의 및 시사점 (Significance & Implications)

• 실무적 시사점:
  • LLM 이 생성한 보안 패치는 배포 전 엄격한 검증 (PoV 테스트 등) 이 필수적임.
  • 특히 입력 유효성 검사 (Input Validation) 와 권한 관리 (Permissions) 관련 패치는 LLM 이 체계적으로 실패하므로 인간 검토가 집중되어야 함.
  • "보안 수정을 위해 기능성을 희생해야 한다"는 가정은 버려야 함.
• 연구적 시사점:
  • 현재 LLM 의 한계는 코드 생성 (구문) 이 아니라 취약점 이해 (의미론) 에 있음.
  • 향후 연구는 취약점별 컨텍스트 (공격 시나리오, CWE 수정 패턴) 를 제공하거나, 취약점 유형에 따라 다른 수정 전략을 라우팅하는 CWE 인지형 접근법이 필요함.
  • 이진법 (Pass/Fail) 평가에서 벗어나 SRS 와 같은 연속적 지표를 활용한 평가가 필요함.

결론

이 연구는 LLM 이 보안 패치 생성에서 문법적 정확성은 확보하지만 의미론적 이해가 부족하여 실패함을 입증했습니다. 특히 기능성은 유지되지만 보안은 실패하는 '위험한 패치'가 상당수 존재하며, 이는 단순한 프롬프트 엔지니어링으로 해결하기 어려운 구조적 문제임을 보여줍니다. 따라서 LLM 을 보안 패치에 활용할 때는 취약점 유형별 특성을 고려한 엄격한 검증 프로세스와 도메인 특화 학습이 필수적입니다.