Security and Quality in LLM-Generated Code: A Multi-Language, Multi-Model Analysis

이 논문은 다양한 프로그래밍 언어와 LLM 모델을 대상으로 생성된 코드의 보안 및 품질을 분석한 결과, 모델들이 최신 보안 기능을 활용하지 못하고 구식 방법을 사용하는 등 언어별 보안 효율성에 차이가 있음을 밝혀냈습니다.

핵심

이 논문은 **"인공지능 (AI) 이 코딩을 도와줄 때, 그 코드가 얼마나 안전하고 잘 만들어졌는지"**를 다양한 언어와 모델로 꼼꼼히 검사한 연구입니다.

마치 **"AI 코딩 도우미 5 명을 고용해서, 4 가지 다른 언어 (Python, Java, C++, C) 로 200 개의 다양한 미션을 수행하게 한 뒤, 그들의 결과물을 심사위원들이 면밀히 검토한 보고서"**라고 생각하시면 쉽습니다.

이 연구의 핵심 내용을 일상적인 비유로 설명해 드릴게요.

---

1. 실험 설정: "다양한 요리사와 다양한 재료"

연구진들은 최신 AI 모델 5 개 (GPT-4o, Claude-3.5, Gemini-1.5 등) 를 초대했습니다. 그리고 이들에게 **4 가지 다른 요리 재료 (프로그래밍 언어)**를 주었습니다.

• 파이썬 (Python) & 자바 (Java): 요리하기 쉽고, 실수가 적어도 바로 알아차리기 힘든 재료들 (자동으로 안전 장치가 있는 냄비).
• C++ & C: 요리하기 까다롭고, 조금만 실수하면 불이 나거나 다칠 수 있는 날카로운 칼과 뜨거운 기름 같은 재료들 (안전 장치가 없어서 요리사가 직접 신경 써야 함).

이들에게 "이런 요리를 만들어줘"라고 200 가지 미션을 주었더니, AI 들이 각자 요리를 만들어냈습니다.

2. 심사 과정: "세 가지 심판 기준"

연구진들은 AI 가 만든 요리를 세 가지 기준으로 평가했습니다.

1. 식당 문 열기 전 (구문 오류 확인): 요리를 다 만들었는데, 냄비가 깨져서 조리할 수 없나요? (컴파일 오류)
2. 맛보기 (기능 확인): 주문한 '불고기'를 시켰는데 '김치찌개'가 나왔나요? 혹은 맛이 너무 짜거나 싱거울까요? (단위 테스트를 통한 기능 정확도)
3. 위생 및 안전 점검 (보안 및 품질): 식중독 위험은 없나요? (보안 취약점), 주방이 너무 지저분하거나 복잡하지는 않나요? (코드 품질)

3. 주요 발견: "언어마다 AI 의 실력이 달랐다"

• 파이썬과 자바는 '상위권'입니다:
  AI 들이 파이썬과 자바로 요리를 할 때는 거의 완벽하게 성공했습니다. 문법이 쉽고 자동 안전 장치가 있어서 AI 가 실수할 여지가 적었기 때문입니다. 특히 Claude-3.5와 GPT-4o가 이 분야에서 가장 잘했습니다.

• C 와 C++ 은 '난이도 최상'입니다:
  반면, C 와 C++ 로 요리할 때는 AI 들이 많이 헷갈렸습니다.

  • 메모리 관리 실수: "이 재료를 다 쓴 뒤에는 쓰레기통에 버려야 하는데, 버리지 않아서 주방이 쓰레기로 가득 찼다" (메모리 누수, 버퍼 오버플로우).
  • 필요 없는 도구: "이 요리에 쓸 필요가 없는 칼을 들고 나왔다" (불필요한 라이브러리 포함).
  • 오래된 레시피: "최신 위생 규정이 있는데, 10 년 전의 위험한 레시피를 그대로 썼다" (구식 암호화 방식 사용).
    특히 C 언어는 AI 가 가장 어려워해서, 코드가 실행되지 않거나 치명적인 보안 구멍이 많이 났습니다.

4. 보안 문제: "보이지 않는 함정"

AI 가 만든 코드는 겉보기엔 완벽해 보이지만, 속에는 보안 지뢰가 숨어있었습니다.

• 비밀번호 노출: "비밀번호를 코드 안에 그대로 적어놨다" (하드코딩).
• 열린 문: "문은 잠갔는데, 창문은 열어놨다" (입력값 검증 누락).
• 낡은 자물쇠: "최신 자물쇠 대신, 쉽게 뚫리는 구식 자물쇠를 썼다" (암호화 오류).

특히 **C++**와 C에서는 메모리 관련 보안 문제가, 자바와 파이썬에서는 암호화나 인증 관련 문제가 더 자주 발견되었습니다.

5. 결론: "AI 는 아직 초보 요리사"

이 연구는 **"AI 가 코딩을 도와줄 수는 있지만, 무조건 믿고 쓰면 안 된다"**는 사실을 보여줍니다.

• 언어 선택이 중요: AI 를 쓸 때는 파이썬이나 자바처럼 안전한 언어를 고르는 것이 C 나 C++ 보다는 훨씬 안전합니다.
• 인간의 검증 필수: AI 가 만들어준 코드는 반드시 사람이 다시 한번 "이게 안전한가?"를 확인해야 합니다. 특히 보안이 중요한 부분에서는 AI 가 최신 보안 기술을 잘 모르는 경우가 많기 때문입니다.
• 향후 과제: AI 개발자들은 이제 "단순히 코드를 잘 짜는 것"을 넘어, "보안과 품질까지 고려한 코딩"을 가르쳐야 합니다.

한 줄 요약:

"AI 코딩 도우미는 파이썬 같은 쉬운 언어에서는 훌륭한 요리사지만, C 같은 까다로운 언어에서는 실수를 많이 하고, 특히 '보안'이라는 위생 기준에서는 아직 인간이 직접 점검해줘야 할 필요가 많습니다."

기술 요약

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

• 배경: 대규모 언어 모델 (LLM) 을 활용한 AI 기반 코드 생성 도구가 소프트웨어 개발 생명주기 전반에 걸쳐 널리 사용되고 있습니다.
• 문제: LLM 이 생성한 코드의 기능적 정확성은 많이 연구되었으나, 보안성과 품질에 대한 체계적인 조사는 부족합니다. 특히 생성된 코드가 다양한 프로그래밍 언어와 모델에 따라 어떻게 다른 보안 취약점과 품질 문제를 보이는지에 대한 비교 분석이 필요합니다.
• 연구 질문:
  1. 프로그래밍 언어의 선택이 LLM 생성 코드의 보안성에 어떤 영향을 미치는가?
  2. 다양한 LLM 은 여러 언어에서 구문적 유효성과 의미적 정확성을 얼마나 잘 달성하는가?
  3. LLM 생성 코드에서 가장 흔한 보안 취약점은 무엇이며, 모델과 언어별로 어떻게 분포하는가?

2. 연구 방법론 (Methodology)

이 연구는 4 가지 프로그래밍 언어와 5 가지 주요 LLM 을 대상으로 한 포괄적인 측정 연구 (Measurement Study) 입니다.

• 데이터셋 구성:
  • 규모: 200 개의 프로그래밍 태스크로 구성된 수동 큐레이션 (Manually Curated) 데이터셋.
  • 범주: 7 가지 기능 및 보안 관련 카테고리 (보안 코딩, 데이터 구조/알고리즘, 파싱/검증, 네트워킹, 수학/논리, 시스템 유틸리티, 동시성/동기화).
  • 특징: 언어 중립적인 명세 (Language-neutral specifications) 를 사용하며, 각 태스크당 10 개의 유닛 테스트 케이스를 포함하여 의미적 정확성을 평가.
• 평가 대상 모델 (5 개):
  • GPT-4o, Claude-3.5, Gemini-1.5, Codestral, Llama-3.
• 평가 대상 언어 (4 개):
  • Python, Java, C++, C.
• 평가 프로세스:
  1. 코드 생성: 각 태스크와 언어 조합에 대해 5 개 모델이 코드를 생성 (총 4,000 개 파일).
  2. 구문 및 컴파일 검증: 정적 분석 및 컴파일 성공 여부 확인.
  3. 의미적 정확성 (Semantic Correctness): 4,000 개의 유닛 테스트 파일을 통해 논리적 정확성 평가.
  4. 품질 및 보안 분석:
     • 자동화 도구: SonarQube (신뢰성, 유지보수성, 코드 냄새), CodeQL (취약점 스캔).
     • 수동 검토: 주요 정적 분석 결과의 20% 를 전문가가 수동 검증하여 오검출 (False Positive) 제거.
  5. 복잡도 분석: 코드 라인 수 (LoC), 순환 복잡도 (CyC), 인지 복잡도 (CoC) 등 측정.

3. 주요 기여 (Key Contributions)

1. 새로운 평가 데이터셋: 200 개의 태스크로 구성된 수동 검증 데이터셋을 공개하여, 다양한 도메인과 보안 시나리오에서 LLM 성능을 평가할 수 있는 기반을 마련했습니다.
2. 다언어/다모델 비교 평가: 단일 언어나 단일 모델에 국한되지 않고, 4 개 언어와 5 개 모델을 동일한 환경에서 비교하여 언어별, 모델별 차이를 명확히 규명했습니다.
3. 심층 보안 분석: LLM 이 생성한 코드에서 발생하는 공통적인 취약점 패턴 (CWE 기반) 을 식별하고, 언어별 취약점 분포 (예: C/C++ 의 메모리 안전성 vs Java/Python 의 암호화 오류) 를 정량화했습니다.

4. 주요 결과 (Key Results)

A. 컴파일 및 의미적 정확성

• 언어별 차이: Python 과 Java 가 가장 높은 컴파일 성공률과 의미적 정확성을 보였습니다. 반면, C 와 C++ 은 상대적으로 낮은 성공률을 기록했습니다.
  • Python: 모든 모델에서 99.5%~100% 의 높은 컴파일 성공률.
  • C++: 가장 낮은 성공률 (77%~89%). 라이브러리 포함 누락 (#include), 타입 처리 오류, 표준 버전 (C++11 vs C++17) 혼란 등이 주된 원인.
  • C: 메모리 관리, 헤더 파일 누락, 비표준 라이브러리 의존성 등으로 인한 오류가 빈번함.
• 모델별 차이: Claude-3.5 와 GPT-4o 가 전반적으로 높은 성능을 보였으며, Llama-3 는 C/C++ 에서 상대적으로 낮은 성능을 보임.

B. 보안 취약점 및 품질

• 언어별 취약점 패턴:
  • C/C++: 메모리 안전성 문제 (버퍼 오버플로우, 잘못된 버퍼 크기 계산), 하드코딩된 비밀 정보, 암호화 오용이 주를 이룸.
  • Java/Python: 암호화 관련 취약점 (RSA 에 OAEP 패딩 미적용 등), 하드코딩된 비밀번호, XML 외부 엔티티 (XXE) 취약점 등이 더 흔함.
• 주요 발견:
  • 많은 모델이 최신 컴파일러 및 툴킷의 보안 기능 (예: Java 17 의 보안 개선 사항) 을 활용하지 못하고 구식 (Outdated) 메서드를 사용하는 경향이 있음.
  • 특히 C++ 에서 메모리 안전성 이슈와 암호화 오용이 빈번하게 발견됨.
  • Gemini-1.5 는 전반적으로 취약점 수가 가장 많았으며, Claude-3.5 와 GPT-4o 는 상대적으로 보안성이 높았으나 여전히 개선이 필요함.

C. 코드 복잡도 및 유지보수성

• 복잡도: Claude-3.5 는 모든 언어에서 가장 많은 코드 라인 수 (LoC) 와 높은 인지 복잡도를 생성하여 가독성과 유지보수성에 부정적 영향을 미칠 수 있음.
• 클린 코드: 모델들은 일관성 (Consistency) 은 잘 유지하지만, **의도성 (Intentionality)**과 적응성 (Adaptability) 측면에서 개선이 필요한 것으로 나타남. 특히 C 언어에서는 모든 모델이 복잡한 코드 구조를 생성하는 경향이 강함.

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

• 언어 의존성: LLM 의 코드 생성 능력과 보안성은 프로그래밍 언어의 특성 (정적/동적 타이핑, 메모리 관리 방식 등) 에 크게 의존합니다. 저수준 언어 (C/C++) 는 고수준 언어 (Python/Java) 에 비해 LLM 이 생성한 코드의 품질과 보안성이 현저히 낮습니다.
• 보안 인식 부족: LLM 은 기능적 정확성은 달성할 수 있으나, 최신 보안 모범 사례 (Secure Coding Practices) 나 언어별 최신 기능 (예: Java 17 의 보안 개선) 을 반영하는 데 한계가 있습니다.
• 향후 방향: LLM 의 보안성을 높이기 위해서는 단순한 기능적 정확성 평가를 넘어, 보안 취약점과 코드 품질을 동시에 고려한 평가 체계가 필요하며, 모델 학습 시 보안 관련 데이터와 최신 언어 표준에 대한 이해도를 강화해야 합니다.

이 연구는 LLM 기반 코드 생성의 현재 상태를 정량적으로 측정하고, 개발자와 연구자가 생성된 코드의 신뢰성을 평가하고 개선 방향을 설정하는 데 중요한 기준점 (Baseline) 을 제공합니다.