Quality Assurance of LLM-generated Code: Addressing Non-Functional Quality Characteristics

이 논문은 ISO/IEC 25010 품질 모델을 기반으로 문헌 검토, 산업계 워크숍, 실증 분석을 수행하여 생성된 코드의 비기능적 품질 (보안, 유지보수성, 성능 등) 에 대한 학술적 관심과 산업계의 우선순위 및 실제 모델 행동 간의 불일치를 드러내고, LLM 기반 코드 생성 파이프라인에 품질 보증 메커니즘을 통합할 필요성을 강조합니다.

핵심

이 논문은 **"인공지능 (LLM) 이 코드를 짜주는데, 그 코드가 정말 '잘' 짜졌는지 확인하는 방법"**에 대한 연구입니다.

기존에는 AI 가 코드를 잘 짜는지 '기능이 작동하는지 (예: 버튼 누르면 창이 뜨는가?)"만 확인했습니다. 하지만 이 논문은 "그 코드가 안전하고, 나중에 수정하기 쉬운지, 그리고 빠르냐" 같은 숨은 품질 (비기능적 품질) 에 집중합니다.

이 복잡한 연구를 일상적인 비유로 쉽게 설명해 드릴게요.

---

🏠 비유: "AI 건축가"와 "집 짓기"

상상해 보세요. 여러분이 **AI 건축가 (LLM)**를 고용해서 집을 짓게 했습니다.

1. 기존 연구의 한계 (기능만 확인):

   • 예전 연구자들은 "문이 열리나요?", "전등이 켜지나요?"만 확인했습니다.
   • 문제는, 문이 열리더라도 벽이 너무 약해서 (보안 취약점), 수리하기 너무 어렵게 (유지보수성 나쁨), 에어컨이 너무 많이 먹어서 (성능 저하) 집을 지을 수도 있다는 것입니다.

2. 이 연구의 목적:

   • "문만 열리면 되는 게 아니라, 집이 튼튼하고, 나중에 고치기 편하며, 전기세도 적게 나오는 집을 지을 수 있을까?"를 확인하려는 것입니다.

---

🔍 연구의 3 단계 과정 (이 논문이 한 일)

이 연구는 세 가지 방법을 섞어서 문제를 파헤쳤습니다.

1. 책 읽기 (문헌 검토): "전문가들은 뭐라고 할까?"

• 상황: 학계에서 AI 코드를 분석한 논문 109 편을 모두 뒤져봤습니다.
• 발견: 학자들은 주로 **"보안 (도둑이 들지 않는가?)"**과 **"속도 (빠른가?)"**에 너무 집중하고 있었습니다.
• 비유: 학자들은 "이 집이 도둑맞지 않고, 에어컨이 빨리 시원해지는가?"만 따졌습니다. 하지만 "이 벽을 나중에 고치기 편한가?" 같은 건 상대적으로 덜 중요하게 생각했죠.

2. 현장 인터뷰 (워크숍): "현업 개발자들은 뭐라고 할까?"

• 상황: 실제 회사에서 일하는 개발자 15 명을 모시고 토론회를 열었습니다.
• 발견: 개발자들은 **"유지보수성 (나중에 고치기 쉬운가?)"**과 **"가독성 (코드가 읽기 쉬운가?)"**을 가장 걱정했습니다.
• 비유: 개발자들은 "도둑이 안 들어와도, 나중에 배관 고칠 때 벽을 부수지 않고 수리할 수 있어야 해. 그렇지 않으면 나중에 **'기술 부채 (Technical Debt)'**가 쌓여서 회사가 망해!"라고 경고했습니다.
  • 기술 부채 비유: 지금 급하게 지어서 나중에 고치기 힘들어지면, 나중에 더 많은 돈과 시간을 써야 한다는 뜻입니다.

3. 실험실 테스트 (실제 실험): "AI 에게 시켜서 직접 확인"

• 상황: 실제 소프트웨어 문제 (SWE-bench) 를 AI 에게 해결하게 했습니다. 그리고 "보안을 지켜줘", "속도를 높여줘"라고 지시하며 다시 코드를 짜게 했습니다.
• 결과 (가장 중요한 부분):
  • 불안정성: "보안을 지켜줘"라고 하면 보안은 좋아졌지만, 오히려 코드가 느려지거나 (성능 저하), 아예 작동하지 않는 경우가 많았습니다.
  • 비유: "이 집은 도둑이 들지 않게 문에 자물쇠를 더 많이 걸어줘"라고 했더니, AI 가 문 자체를 못 열게 자물쇠를 너무 많이 달아버린 셈입니다.
  • 상충 관계 (Trade-off): 한 가지 품질을 좋게 하려고 하면, 다른 품질이 나빠지는 경우가 많았습니다. (예: 속도 올림 → 메모리 사용량 폭증)

---

💡 핵심 결론: "작동하는 것"과 "좋은 것"은 다릅니다

이 논문의 결론은 매우 명확합니다.

1. 현재의 문제: AI 는 "작동하는 코드 (Test Pass)"를 만드는 데는 능숙하지만, **"좋은 품질의 코드 (Quality Pass)"**를 만드는 데는 아직 서툴러요.
2. 학계 vs 현장: 학자들은 '보안'과 '속도'를 중요하게 여기지만, 실제 개발자들은 '나중에 고치기 쉬운지'를 더 중요하게 생각합니다.
3. 경고: AI 가 짜준 코드를 검증 없이 바로 쓰면, 나중에 고치기 힘든 '기술 부채'가 쌓여 프로젝트가 망할 수 있습니다.

🚀 앞으로의 방향 (해결책)

이 논문은 앞으로 AI 코딩 도구를 쓸 때, 단순히 "작동하는지"만 확인하는 게 아니라, "보안, 속도, 유지보수성"을 동시에 체크하는 자동화된 시스템이 필요하다고 말합니다.

마무리 비유:
지금까지 우리는 AI 건축가에게 "문만 열리면 돼"라고 했다면, 이제는 **"문도 열리고, 도둑도 못 들어오며, 나중에 고치기 편하고, 전기세도 적게 드는 집을 지어줘"**라고 명확히 지시하고, 그 결과를 꼼꼼히 검사하는 시스템이 필요하다는 것입니다.

이 연구는 바로 그 **'검증 시스템'**이 왜 필요한지, 그리고 현재 AI 가 어디까지 왔는지, 어디가 부족한지를 명확히 보여준 것입니다.

기술 요약

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

최근 대규모 언어 모델 (LLM) 이 소프트웨어 공학 워크플로우에 광범위하게 통합되면서 코드 생성 작업이 가속화되고 있습니다. 그러나 기존 평가 체계는 주로 기능적 정확성 (Functional Correctness) 에 집중되어 있으며, 생성된 코드의 비기능적 품질 특성 (Non-Functional Quality Characteristics, NFQCs) 에 대한 이해는 매우 제한적입니다.

• 핵심 문제: ISO/IEC 25010 품질 모델에 따르면 소프트웨어 품질은 기능적 정확성뿐만 아니라 보안, 유지보수성, 성능 효율성 등 다양한 NFQCs 를 포함합니다.
• 현황: 현재 LLM 은 기능적으로 올바른 코드를 생성할 수 있지만, 보안 취약점을 포함하거나 유지보수가 어렵고 비효율적인 코드를 생성할 위험이 있습니다.
• 연구 목표: 학술계와 산업계의 관점 차이를 규명하고, 실제 소프트웨어 엔지니어링 환경에서 생성된 코드의 NFQCs 를 평가하여 모델 행동과 품질 보증 간의 불일치를 해결하는 것입니다.

2. 연구 방법론 (Methodology)

이 연구는 ISO/IEC 25010 품질 모델을 공통 기준으로 삼아 다중 방법론 (Multi-methods) 접근법을 사용했습니다. 세 가지 보완적인 요소로 구성됩니다.

1. 문헌 검토 (Literature Review):

   • 2022 년부터 2025 년까지 발표된 109 편의 논문을 분석했습니다.
   • 검색 전략: Scopus 데이터베이스를 활용하여 'LLM', '코드 생성', '품질' 관련 키워드로 검색하고, 눈덩이 표본추출 (Snowballing) 기법을 적용했습니다.
   • 분석 대상: 연구 트렌드, 평가된 NFQCs 의 분포, 평가 도구 및 방법론의 한계.

2. 산업 워크숍 (Industry Workshops):

   • 7 개 조직의 15 명의 실무자 (소프트웨어 엔지니어, QA 전문가 등) 와 2 회 워크숍을 진행했습니다.
   • 목적: 학술적 연구와 산업계의 실제 요구사항 및 우려 사항 (Pain points) 간의 정렬 (Alignment) 여부 확인.
   • 주요 논의: 생성 코드의 유지보수성, 가독성, 기술 부채 (Technical Debt) 축적 위험, 그리고 코드 수준과 시스템 수준 평가의 차이.

3. 실증 분석 (Empirical Analysis):

   • 데이터셋: 실제 GitHub 이슈를 해결하는 벤치마크인 SWE-bench Lite (300 개 인스턴스, 11 개 Python 리포지토리) 사용.
   • 모델: Claude 4 Sonnet, DeepSeek-Reasoner, GPT-4o 등 3 개의 LLM 선택.
   • 실험 설계 (3 단계):
     1. 기선 평가 (Baseline): SWE-agent 를 사용하여 패치 생성 및 기능적 정확성, 보안, 유지보수성, 성능 (실행 시간, 메모리) 평가.
     2. 필터 및 프롬프트 설계: 세 모델 모두에서 성공적으로 해결된 17 개 인스턴스만 선별. CodeQL 정적 분석 결과를 피드백으로 포함하여 NFQCs 최적화 프롬프트 설계.
     3. 재생성 및 평가: 최적화 프롬프트로 패치를 재생성하고, 기존 결과와 비교하여 개선 효과 및 NFQCs 간 트레이드오프 분석.
   • 평가 도구: Docker(격리 환경), CodeQL(보안 및 유지보수성 정적 분석), 단위 테스트.

3. 주요 기여 (Key Contributions)

• 학술적 - 실무적 간극 규명: 기존 연구가 보안과 성능 효율성에 치중하는 반면, 실무자들은 유지보수성 (Maintainability) 과 가독성 (Readability) 을 최우선으로 고려하며, 생성 코드가 기술 부채를 가속화할 수 있음을 경고했습니다.
• NFQCs 간 상호작용 및 트레이드오프 실증: 단일 프롬프트로 특정 NFQC 를 최적화하는 것이 다른 품질 특성에 부정적인 영향을 미치거나, 오히려 목표한 품질을 저하시킬 수 있음을 입증했습니다.
• 품질 보증 메커니즘의 필요성 강조: 기능적 정확성만 통과하는 코드가 아닌, "품질 있게 통과 (Pass with quality)"하는 코드를 보장하기 위한 통합된 품질 보증 파이프라인의 필요성을 제기했습니다.

4. 주요 결과 (Results)

A. 문헌 검토 및 워크숍 결과

• 연구 편향: 기존 연구는 보안 (33.6%), 성능 효율성 (23.3%), 유지보수성 (17.2%) 에 집중되어 있으며, 신뢰성이나 모듈성 등은 소홀히 다루어졌습니다. 이는 정적 분석 도구로 측정 가능한 특성에 편향된 결과입니다.
• 실무자 관점: 실무자는 대규모 레거시 코드베이스에서의 유지보수성과 가독성을 가장 큰 우려 사항으로 꼽았습니다. LLM 이 생성한 코드는 기능은 맞더라도 구조가 복잡하거나 기술 부채를 유발할 수 있다고 지적했습니다.

B. 실증 실험 결과

• 기능적 정확성: 생성된 패치는 인간이 작성한 골드 (Gold) 패치보다 기능적 정확도가 현저히 낮았습니다. (예: GPT-4o 는 적용률은 높았으나 해결률은 16% 에 그침).
• NFQCs 성능:
  • 유지보수성: 생성된 패치는 골드 패치보다 CodeQL 기준 유지보수성 경고 (Recommendation) 를 훨씬 많이 발생시켰습니다. 특히 cyclic-import 같은 문제가 빈번했습니다.
  • 보안: 생성된 패치는 clear-text-storage-sensitive-data 와 같은 보안 취약점을 더 많이 포함했습니다.
  • 성능: 실행 시간과 메모리 사용량 모두 골드 패치보다 일반적으로 더 높았습니다.
• 프롬프트 최적화의 한계 (RQ 5.2, 5.3):
  • 특정 NFQC(예: 보안, 성능) 를 최적화하기 위한 프롬프트를 적용하면, 기능적 정확성이 저하되는 경우가 많았습니다.
  • 트레이드오프: 한 특성을 개선하려다 다른 특성이 악화되는 현상이 관찰되었습니다. (예: 실행 시간을 줄이려다 메모리 사용량이 급증하거나, 보안 최적화 시 기능이 깨짐).
  • 불안정성: 프롬프트 기반 최적화가 일관된 개선을 보장하지 못하며, 오히려 품질을 악화시키는 '부정적 최적화 (Negative Optimization)' 사례도 발견되었습니다.

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

• 현재의 한계: 현재 LLM 기반 코드 생성은 "테스트 통과"를 최우선으로 하여, 구조적 결함이나 기술 부채를 내포한 코드를 생성할 가능성이 높습니다. 모델은 코드 품질에 대한 내재적 비용 함수를 갖지 않아, 단순한 토큰 예측에 의존합니다.
• 향후 방향:
  • 생성 파이프라인에 정적 분석 및 자동화된 검출기를 통합하여 NFQCs 를 실시간으로 모니터링하고 피드백해야 합니다.
  • 기능적 정확성과 비기능적 품질을 동시에 고려하는 다목적 최적화 (Multi-objective optimization) 전략이 필요합니다.
  • 학술적 평가 지표와 산업계의 실제 요구사항 (유지보수성 등) 을 정렬한 새로운 평가 프레임워크가 필요합니다.

이 연구는 LLM 이 생성한 코드가 단순히 작동하는 것을 넘어, 실제 소프트웨어 시스템에 통합될 때 요구되는 신뢰성, 유지보수성, 보안을 보장하기 위한 체계적인 품질 보증 접근법의 필요성을 강력하게 주장합니다.