Helping LLMs Improve Code Generation Using Feedback from Testing and Static Analysis

이 논문은 테스트와 정적 분석을 통해 생성된 코드의 결함과 취약점을 식별하고 이를 피드백으로 활용하여 오픈소스 LLM 의 코드 수정 능력을 향상시키는 프레임워크를 제안하며, LLM 은 오류를 스스로 탐지하는 데는 미흡하지만 구체적인 피드백을 제공받으면 코드를 효과적으로 수정할 수 있음을 보여줍니다.

핵심

🤖 AI 코딩 도우미의 실수와 교정: "시험과 감시관"을 활용한 연구

이 논문은 최근 화두가 되고 있는 **거대 언어 모델 (LLM, 예: 챗봇)**이 코드를 작성할 때 얼마나 똑똑하고 안전한지, 그리고 우리가 어떻게 그 실수를 고쳐줄 수 있는지에 대한 흥미로운 실험 결과를 담고 있습니다.

비유하자면, 이 연구는 **"완벽하지 않은 AI 프로그래머에게 시험지를 주고, 감시관 (정적 분석기) 이 오답을 찾아내면, AI 가 스스로 그 오답을 고칠 수 있을까?"**를 확인한 실험입니다.

---

1. 배경: AI 는 코드를 잘 쓸까?

우리는 이제 AI 에게 "이 기능 만들어줘"라고 말하면 코드를 짜주기를 기대합니다. 하지만 AI 는 가끔 중요한 실수를 합니다.

• 기능 오류: "1+1 을 계산해줘"라고 했는데 3 을 내놓는 경우.
• 보안 구멍: 코드는 돌아가는데, 해커가 들어올 수 있는 문이 열려 있는 경우 (메모리 누수, 버퍼 오버런 등).

이 연구는 오픈소스 AI 모델 4 개 (Llama 3, Gemma, Mixtral 등) 를 대상으로 이런 문제들을 어떻게 해결할지 실험했습니다.

2. 실험 과정: 3 단계 게임

연구진은 AI 에게 3 단계를 거치도록 시켰습니다.

1 단계: 코딩하기 (생성)

AI 에게 "이 문제를 C 언어로 풀어줘"라고 요청했습니다.

• 결과: AI 가 만든 코드는 **약 46%~65%**만 제대로 작동했습니다. 나머지는 아예 컴파일도 안 되거나, 실행하면 터지는 (에러 나는) 코드였습니다.
• 비유: AI 가 시험지를 제출했는데, 절반은 답이 없고 절반은 엉뚱한 답을 적어낸 셈입니다.

2 단계: 스스로 평가하기 (자기 평가)

AI 에게 "방금 네가 쓴 코드가 맞니? 아니면 버그가 있니?"라고 물었습니다.

• 결과: 대실패! AI 는 자신의 실수를 거의 못 알아챘습니다.
  • 코드가 틀렸는데 "맞아요 (YES)"라고 하거나,
  • 코드가 안전하지 않은데 "안전해요 (NO)"라고 거짓말을 했습니다.
• 비유: 시험을 망친 학생이 "저는 100 점 맞았어요!"라고 우기는 꼴입니다. AI 는 자신의 실수에 대해 거의 '자각'이 없었습니다.

3 단계: 고쳐주기 (수정)

이제부터가 핵심입니다. 연구진은 AI 에게 "여기서 틀린 점이 있어요 (테스트 실패 메시지)" 혹은 **"여기 보안 구멍이 있어요 (감시관 보고서)"**라고 구체적인 피드백을 주었습니다.

• 결과: 놀라운 반전! AI 는 구체적인 피드백을 받으면 코드를 잘 고쳐냈습니다.
  • 기능 오류: 틀린 코드의 약 **62%**를 성공적으로 고쳤습니다.
  • 보안 오류: 취약점의 **89%**를 성공적으로 제거했습니다.
• 비유: "이 부분 틀렸어"라고 알려주니, 학생이 금방 문제를 다시 풀어서 정답을 맞췄습니다.

3. 주요 발견: 감시관이 필요해!

이 연구에서 얻은 가장 중요한 교훈은 다음과 같습니다.

1. AI 는 혼자서는 완벽하지 않다: AI 가 처음부터 완벽한 코드를 짜는 것은 어렵습니다.
2. AI 는 자신의 실수를 못 본다: AI 에게 "네가 틀렸어"라고 스스로 판단하게 하면, 대부분 엉뚱한 답을 내놓습니다.
3. 하지만, 피드백을 주면 잘 고친다: **자동화된 감시관 (정적 분석기)**이 "여기 메모리 누수가 있어요"라고 알려주면, AI 는 그 지시를 따르며 코드를 완벽하게 수정할 수 있습니다.

4. 결론: AI 와 인간의 완벽한 팀워크

이 논문은 "AI 가 코딩을 대체할까?"라는 질문보다 **"AI 가 코딩을 할 때, 어떻게 하면 더 안전하게 만들까?"**에 대한 해답을 제시합니다.

• 아이디어: AI 가 코드를 짜면, 바로 사람이 확인하는 대신 **자동 감시 도구 (Static Analysis)**가 먼저 오답을 찾아냅니다.
• 프로세스: 감시 도구가 "여기 고쳐줘"라고 보고하면, AI 가 그 보고서를 보고 코드를 다시 고칩니다.
• 효과: 이렇게 하면 AI 가 만든 코드의 안전성과 정확도가 크게 높아집니다.

한 줄 요약:

"AI 는 코딩 실수를 자주 하고, 자신의 실수도 못 알아채지만, 정확한 감시관 (자동 분석 도구) 이 실수를 지적해주면, 그 실수를 아주 잘 고쳐내는 능력을 가지고 있습니다. 따라서 AI 코딩 도구를 쓸 때는 AI 만 믿지 말고, 자동 감시 시스템을 함께 도입해야 안전합니다."

이 연구는 앞으로 우리가 AI 와 함께 일할 때, AI 를 단순히 '코딩 비서'로만 쓰지 않고, AI 가 만든 코드를 검증하고 수정하는 자동화된 시스템을 함께 구축해야 함을 보여줍니다.

기술 요약

1. 문제 제기 (Problem)

LLM 은 소프트웨어 개발 생산성을 높이는 핵심 도구로 부상했지만, 생성된 코드는 종종 정확하지 않거나 (Correctness), 보안 취약점 (Safety) 이 포함되어 있습니다.

• 기존 연구들은 상용 LLM 이 생성한 코드에 버그와 취약점이 많음을 지적했습니다.
• 개발자가 LLM 을 사용할 때 소유권, 개인정보, 보안 문제가 발생할 수 있습니다.
• 현재 LLM 은 생성된 코드의 오류를 스스로 감지하거나 수정하는 능력 (Self-evaluation 및 Repair) 이 부족하며, 특히 안전성 (Safety) 에 대한 인식은 매우 낮습니다.

2. 방법론 (Methodology)

저자들은 테스트 (Testing) 와 정적 분석 (Static Analysis) 을 결합한 3 단계 자동화 프레임워크를 구축했습니다. 실험에는 Meta 의 Llama 3 (8B, 70B), Google 의 Gemma 7B, Mistral 의 Mixtral 8x7B 등 4 개의 최신 오픈소스 LLM 이 사용되었습니다.

1 단계: 코드 생성 (Code Generation)

• 데이터셋: Mostly Basic Python Problems (MBPP) 데이터셋의 100 개 태스크를 C 언어로 변환하여 사용했습니다. (기존 C 벤치마크인 HumanEval 대신 MBPP 를 C 로 변환한 이유는 모델이 훈련 데이터의 Python 버전을 암기했을 가능성을 줄이기 위함입니다.)
• 프로세스: LLM 에게 자연어 태스크 설명을 주고 C 코드를 생성하도록 요청했습니다.
• 후처리: 생성된 코드에서 주석이나 설명 텍스트를 제거하고, 누락된 표준 라이브러리 (math.h 등) 를 자동으로 추가하여 컴파일 가능한 상태로 정제했습니다.

2 단계: 자기 평가 (Self-Evaluation)

• 정확성 평가: 각 모델이 생성한 코드 (자신 및 다른 모델의 코드 포함) 가 태스크를 올바르게 해결하는지 "YES/NO"로 판단하도록 요청했습니다.
• 안전성 평가: 정적 분석 도구인 Infer(Meta 개발) 가 감지한 특정 취약점 유형 (예: NULLPTR_DEREFERENCE, MEMORY_LEAK 등) 이 코드에 존재하는지 모델에게 질문했습니다.

3 단계: 코드 수정 (Repair)

• 피드백 활용: 생성된 코드가 실패한 테스트 케이스나 Infer 가 감지한 취약점 보고서를 LLM 에게 제공합니다.
• 반복적 수정: LLM 에게 오류 정보를 바탕으로 코드를 수정하도록 요청하며, 최대 6 회까지 반복 시도합니다.
• 프롬프트 엔지니어링: Chain-of-Thought (CoT), 예시 포함, 구체적인 수정 지시어 등 다양한 프롬프트 기법을 실험하여 최적의 구성을 선정했습니다.

3. 주요 기여 (Key Contributions)

1. 종합적 평가 프레임워크: 생성, 자기 평가, 수정의 3 단계를 자동화하여 LLM 의 코드 생성 품질과 자기 인식 능력을 체계적으로 평가했습니다.
2. C 언어 특화 벤치마크: Python 기반 MBPP 를 C 언어로 변환하고, C 의 메모리 관리 특성을 고려한 정적 분석을 적용했습니다.
3. 자기 선호도 (Self-Preference) 분석: 모델이 자신의 생성 코드를 다른 모델의 코드보다 더 잘 평가하거나 수정하는지 여부를 검증했습니다.
4. 오픈소스 및 자동화: 전체 파이프라인이 자동화되어 있으며, 사용된 데이터와 코드는 공개됩니다.

4. 실험 결과 (Results)

A. 코드 생성 및 정확성 (Generation & Correctness)

• 컴파일 성공률: 모든 모델이 생성한 코드의 약 93%~98% 가 정제 과정을 거쳐 컴파일에 성공했습니다.
• 정확성: 컴파일된 코드 중 46% (Gemma) ~ 65% (Llama 3 70B) 만이 모든 단위 테스트를 통과했습니다. 즉, 생성된 코드의 약 35~54% 는 기능적 오류가 있었습니다.
• 결론: LLM 은 코드를 생성할 수 있지만, 기능적 정확성은 여전히 낮습니다.

B. 안전성 및 취약점 (Safety & Vulnerabilities)

• Infer 분석 결과: 생성된 코드의 87%~96% 는 Infer 가 감지한 취약점이 없는 것으로 나타났습니다. (단, Infer 의 오탐(False Positive) 가능성 존재)
• 주요 취약점: NULLPTR_DEREFERENCE 가 가장 흔하게 발견되었습니다.
• 비교: LLM 은 기능적 오류 (Correctness) 보다 보안 취약점 (Safety) 을 더 적게 생성하는 경향이 있었습니다.

C. 자기 평가 능력 (Self-Evaluation)

• 정확성 평가: 모델들은 생성된 코드가 올바른지 판단하는 데 매우 낮은 성능을 보였습니다 (F1-score < 80%).
  • 일부 모델 (예: Gemma) 은 거의 항상 "YES"라고 답하고, 다른 모델 (예: Llama 3 8B) 은 거의 항상 "NO"라고 답하는 편향된 경향을 보였습니다.
• 안전성 평가: 모델들은 취약점을 거의 찾아내지 못했습니다. 오탐(False Positive) 이 많은 경우를 제외하면, 실제 취약점이 있는 코드를 "안전하다"고 판단하는 경우가 많았습니다.
• 자기 선호도: 모델이 자신의 코드를 다른 모델의 코드보다 더 잘 평가한다는 증거는 발견되지 않았습니다.

D. 코드 수정 능력 (Repair)

• 정확성 수정: 오류가 있는 155 개 파일 중 Llama 3 70B가 가장 많은 62% (96 개) 를 성공적으로 수정했습니다. Gemma 는 13% 만 수정했습니다.
• 안전성 수정: Infer 가 감지한 44 개의 취약점 중 Llama 3 70B 와 Mixtral이 89% (39 개) 를 성공적으로 수정했습니다.
• 중요 발견:
  • 모델은 자신이 생성한 코드를 다른 모델이 생성한 코드보다 더 잘 수정하지는 않았습니다.
  • 오히려 Llama 3 70B는 다른 모델 (특히 Gemma) 이 생성한 오류가 많은 코드를 수정하는 데 매우 효과적이었습니다.
  • 피드백의 중요성: 테스트 실패 정보나 취약점 보고서를 제공받았을 때, 모델의 수정 성공률이 크게 향상되었습니다.

5. 의의 및 결론 (Significance & Conclusion)

• 안전한 코드 생성을 위한 방향 제시: LLM 이 단독으로 완벽한 코드를 생성하는 것은 어렵지만, 정적 분석 도구와 테스트를 통한 피드백 루프를 도입하면 코드의 안전성과 정확성을 크게 향상시킬 수 있음을 증명했습니다.
• 자동화 파이프라인의 필요성: 인간의 개입 없이 LLM 이 생성한 코드를 검증하고 수정하는 자동화 파이프라인이 필수적임을 강조합니다.
• 향후 연구 방향:
  • 정적 분석 (Infer) 과 동적 분석을 결합한 하이브리드 접근법.
  • Rust, Python 등 다른 프로그래밍 언어로 확장.
  • 생성된 코드가 훈련 데이터의 단순 번역인지, 새로운 생성인지 구분하는 연구.

이 연구는 LLM 기반 코드 생성 도구의 신뢰성을 높이기 위해 검증 (Verification) 과 피드백 (Feedback) 이 포함된 반복적 프로세스가 핵심임을 시사합니다.