Large-scale, Independent and Comprehensive study of the power of LLMs for test case generation

본 논문은 21 만 개 이상의 테스트 케이스를 대상으로 4 가지 대형 언어 모델 (LLM) 과 EvoSuite 를 비교 분석한 대규모 실증 연구를 통해, 추론 기반 프롬프트가 테스트 생성의 신뢰성을 향상시키지만 여전히 높은 컴파일 실패율과 유지보수성 문제를 안고 있어 자동화된 검증 및 검색 기반 정제와 결합된 하이브리드 접근법이 필요함을 규명했습니다.

핵심

🍳 배경: 왜 이 연구가 필요한가요?

소프트웨어를 만들 때, 요리사 (개발자) 는 요리를 맛있게 만들고 싶지만, **'맛보기 (테스트)'**를 직접 해보는 것은 매우 귀찮고 시간이 많이 걸립니다.

• 기존 방식 (EvoSuite): 로봇이 자동으로 맛보기를 해줍니다. 하지만 로봇이 만든 맛보기는 맛은 정확하지만, 설명이 너무 어렵고 읽기 힘든 경우가 많습니다. (예: "이 소스 3 방울 떨어뜨리고 5 초 뒤 저기서 2 번 저어보세요"라고만 적혀 있음)
• 새로운 방식 (LLM): 최신 AI 가 요리를 해줍니다. AI 는 사람이 읽기 쉽게, 자연스러운 설명을 곁들여 맛보기를 작성해 줍니다. 하지만 AI 가 **잘못된 재료를 쓰거나, 존재하지 않는 조리법을 invented(환각)**하는 문제가 있습니다.

이 연구는 **"AI 가 만든 맛보기 (테스트 코드) 가 실제로 쓸모가 있을까? 그리고 어떻게 하면 더 잘 만들 수 있을까?"**를 검증했습니다.

---

🔍 실험 내용: 무엇을 비교했나요?

연구팀은 AI 를 4 가지 종류 (GPT-3.5, GPT-4, Mistral, Mixtral) 로 준비하고, AI 에게 명령을 내리는 **5 가지 방식 (프롬프트 엔지니어링)**을 실험했습니다.

1. 지시만 내리기 (Zero-Shot): "이 요리를 테스트해 줘." (가장 단순)
2. 예시 보여주기 (Few-Shot): "이런 식으로 테스트해 줘. 예를 들어..."
3. 단계별 생각하기 (Chain-of-Thought): "먼저 재료를 확인하고, 다음에 조리법을 보고, 그다음 테스트해 줘." (생각의 과정을 거침)
4. 여러 가지 길 탐색하기 (Tree-of-Thought): "세 명의 요리사가 각자 다른 방법을 생각해 보고, 가장 좋은 걸 고르자."
5. 가이드된 협업 (GToT): "세 명의 요리사가 서로 의견을 주고받으며, 단계별로 생각한 뒤 최종 테스트를 만들어라." (가장 정교한 방식)

이들을 **실제 요리 책 (Defects4J, SF110 등)**에 적용해 보았습니다.

---

📊 주요 발견 (결과)

1. AI 는 말은 잘하지만, 요리가 망가질 수 있음 (할루시네이션)

• 현상: AI 가 작성한 테스트 코드는 읽기 매우 편하고 사람처럼 자연스러웠습니다. 하지만 실행해보면 **"존재하지 않는 재료를 참조했다"**거나 **"없는 조리기구를 사용했다"**는 오류가 자주 발생했습니다.
• 비유: AI 가 "맛있는 스테이크를 만들어줘"라고 하면, "소금과 후추를 뿌려주세요"라고 쓰지만, 실제 소금통이 부엌에 없는 상황을 간과하고 작성하는 것입니다.
• 결과: 작성된 코드가 실행 가능한 상태로 컴파일되는 비율은 10% 미만으로 매우 낮았습니다. (기존 로봇 방식인 EvoSuite 는 거의 100% 성공)

2. 생각하게 하면 더 잘함 (프롬프트의 힘)

• 현상: 단순히 "만들어줘"라고 하는 것보다, **"단계별로 생각해보고, 여러 각도에서 검토해보라"**고 지시하면 (CoT, GToT 방식), 오류가 줄어들고 코드 구조가 더 깔끔해졌습니다.
• 비유: 요리사에게 "서두르지 말고, 재료를 하나하나 확인하며 조리법을 적어봐"라고 말해주면, 실수가 훨씬 줄어듭니다.
• 결과: GToT(가이드된 협업) 방식이 가장 좋은 결과를 냈습니다.

3. 로봇은 '양'을, AI 는 '질'을 잘함

• EvoSuite (로봇): 코드가 실행되는지, 모든 부분을 다 테스트했는지 (커버리지) 는 매우 훌륭했습니다. 하지만 코드가 너무 복잡하고 읽기 어려워서 유지보수가 힘들었습니다.
• LLM (AI): 코드 커버리지는 로봇보다 낮았지만, 코드가 매우 깔끔하고 읽기 쉬웠습니다. 개발자가 나중에 수정할 때 훨씬 편했습니다.
• 결론: 로봇은 "다 찍어보자"고 하고, AI 는 "이게 왜 중요한지 설명하며 작성"합니다.

4. 여전히 해결되지 않은 문제 (테스트 냄새)

• AI 가 만든 코드에도 **'마법 숫자 (Magic Number)'**라는 문제가 있었습니다.
• 비유: "소금 3g, 설탕 15g"이라고 적는 대신, **"소금 3g, 설탕 15g"**이라고 숫자만 적어놓고, 왜 15g 인지 설명을 안 하는 경우입니다. 나중에 수정할 때 "15g 이 왜 15g 이지?"라고 고민하게 만듭니다. AI 는 이 문제를 아직 완벽히 해결하지 못했습니다.

---

💡 결론: 우리는 무엇을 배웠나요?

1. AI 는 완벽한 요리사가 아닙니다. AI 가 만든 테스트 코드는 읽기 편하고 유지보수가 쉽지만, 실행 오류가 많아서 바로 쓰기엔 위험합니다.
2. 명령을 잘 내리면 도움이 됩니다. AI 에게 "생각하고, 검토하고, 단계별로 작성하라"고 지시하면 훨씬 더 신뢰할 수 있는 코드를 만들어냅니다.
3. 혼합 전략이 정답입니다.
   • **로봇 (EvoSuite)**이 모든 부분을 꼼꼼히 체크하고 (커버리지 확보),
   • **AI (LLM)**가 그 코드를 사람이 읽기 쉽게 다듬고 설명을 추가하는 (가독성 확보)
   • **이 두 가지가 합쳐진 '하이브리드 방식'**이 가장 이상적인 미래입니다.

🚀 요약

이 논문은 **"AI 가 테스트 코드를 작성하는 것은 유망하지만, 아직 혼자서 믿고 맡기기엔 부족하다"**는 결론을 내렸습니다. 하지만 **올바른 지시 (프롬프트)**를 주고, 로봇의 꼼꼼함과 AI 의 창의성을 섞는다면, 소프트웨어 품질을 높이는 강력한 도구가 될 수 있다고 말합니다.

한 줄 요약: "AI 는 요리 설명서를 아주 잘 쓰지만, 실제 요리를 완벽하게 하지는 못합니다. 로봇의 꼼꼼함과 AI 의 깔끔함을 섞으면 최고의 요리를 만들 수 있습니다."

기술 요약

논문 개요

이 연구는 대규모 언어 모델 (LLM) 을 활용한 자동화된 유닛 테스트 생성의 효율성과 한계를 체계적으로 평가한 실증 연구입니다. 기존 검색 기반 소프트웨어 테스트 (SBST) 도구인 EvoSuite 와 비교하여, 다양한 프롬프트 엔지니어링 기법이 LLM 이 생성한 테스트 코드의 정확성, 컴파일 가능성, 가독성, 유지보수성 및 코드 커버리지에 미치는 영향을 216,300 개의 생성된 테스트 케이스를 대상으로 분석했습니다.

1. 연구 배경 및 문제 제기

• 문제점: 수동 테스트 작성은 시간 소모가 크고 종종 소홀히 여겨집니다. 기존 SBST 도구 (예: EvoSuite) 는 코드 커버리지를 최적화하지만, 생성된 테스트 코드의 가독성이 낮고 유지보수가 어렵다는 한계가 있습니다.
• LLM 의 잠재력과 한계: LLM 은 자연스러운 네이밍과 가독성 높은 테스트를 생성할 수 있지만, 기존 연구들은 실행 기반 평가, 추론 기반 프롬프팅의 체계적 분석, 그리고 실제 테스트 시나리오에서의 광범위한 평가를 부족하게 다루고 있습니다. 특히 LLM 이 생성한 코드가 실제 프로젝트 파이프라인에 바로 통합될 수 있는 구조적 유효성 (Structural Validity) 과 컴파일 가능성에 대한 심층 분석이 필요했습니다.

2. 연구 방법론 (Methodology)

이 연구는 다음과 같은 실험 설계를 통해 대규모 평가를 수행했습니다.

• 데이터셋:
  • Defects4J: 실제 버그가 포함된 오픈소스 프로젝트.
  • SF110: 기존 테스트 케이스가 포함된 자바 프로그램.
  • CMD (Custom Mini Dataset): 2023 년 5 월 이후 커밋된 프로젝트 (OceanBase, Conductor OSS) 로, LLM 의 학습 데이터 누출 (Data Leakage) 을 방지하기 위해 구성됨.
• 모델: 4 가지 최신 LLM (GPT-3.5-turbo, GPT-4, Mistral 7B, Mixtral 8x7B) 사용.
• 프롬프트 엔지니어링 기법 (5 가지):
  • Zero-Shot Learning (ZSL)
  • Few-Shot Learning (FSL)
  • Chain-of-Thought (CoT)
  • Tree-of-Thought (ToT)
  • Guided Tree-of-Thought (GToT): 저자가 제안한 새로운 기법으로, 3 명의 '테스터'가 협력하여 테스트를 점진적으로 정제하는 구조.
• 비교 대상: 검색 기반 테스트 도구인 EvoSuite (SBST 기준).
• 평가 지표:
  • 구조적 유효성: Match Success Rate (MSR), Code Extraction Success Rate (CSR).
  • 구문 및 컴파일: 문법 오류, 컴파일 실패 원인 (Hallucination 분석).
  • 품질: 가독성 (Scalabrino 모델), 복잡도 (PMD), 정적 분석 (SpotBugs), 테스트 냄새 (TsDetect).
  • 커버리지: 라인, 명령어, 메서드 커버리지 (JaCoCo).

3. 주요 기여 (Key Contributions)

1. 체계적인 프롬프트 엔지니어링 조사: 기존 연구가 단순한 프롬프트에 그쳤다면, 본 연구는 5 가지 구조화된 프롬프트 기법 (특히 GToT) 이 테스트 생성 품질에 미치는 영향을 클래스 레벨 (Class-level) 에서 처음으로 광범위하게 평가했습니다.
2. 구조적 정확성 및 추출성 분석: LLM 출력물에서 테스트 코드를 얼마나 정확하게 추출할 수 있는지 (MSR/CSR) 를 정량화하여, 실제 파이프라인 통합 가능성을 평가했습니다.
3. 가독성과 유지보수성의 분리 평가: 가독성이 높다고 해서 유지보수가 용이한 것은 아님을 입증하고, 테스트 냄새 (Test Smells) 와 정적 분석을 통해 유지보수성 문제를 구체적으로 규명했습니다.
4. 다양한 데이터셋과 모델을 통한 일반화 검증: 학습 데이터 누출을 고려한 CMD 데이터셋을 포함하여, LLM 의 일반화 능력을 검증했습니다.
5. 공개된 벤치마크: 690 개의 자바 클래스에 대한 216,300 개의 테스트 생성 데이터와 평가 스크립트를 공개했습니다.

4. 주요 결과 (Key Results)

A. 생성 능력 및 추출성 (RQ0-RQ1)

• 생성 능력: LLM 은 EvoSuite 보다 높은 비율로 테스트 코드를 생성했습니다 (EvoSuite 는 일부 클래스에서 생성 실패, LLM 은 대부분 생성).
• 추출성: GToT 프롬프트가 구조적 준수 (MSR) 와 코드 추출 성공률 (CSR) 을 가장 높였습니다. 그러나 모든 모델이 명시적인 구분자 (delimiter) 를 따르는 데 실패하는 경우가 많아 자동 추출이 여전히 어렵습니다.

B. 구문 정확성 및 컴파일 가능성 (RQ2)

• 컴파일 실패율: LLM 이 생성한 코드 중 약 90% 는 문법적으로 정확했으나, 실제 컴파일 성공률은 10% 미만이었습니다.
• 주요 오류: 'Symbol not found' (존재하지 않는 심볼 참조), 'Package does not exist' (잘못된 임포트) 등 **할루시네이션 (Hallucination)**이 주된 원인입니다.
• 비교: EvoSuite 는 생성된 모든 테스트가 문법적으로 정확하며, 컴파일 실패율이 약 1.9% 에 불과해 LLM 보다 훨씬 안정적입니다.
• 프롬프트 영향: CoT 와 GToT 와 같은 추론 기반 프롬프트가 오류를 일부 감소시켰으나, 근본적인 의존성 해결 문제를 완전히 해결하지는 못했습니다.

C. 가독성 및 유지보수성 (RQ3-RQ4)

• 가독성: LLM 이 생성한 테스트는 EvoSuite 보다 가독성이 21~40% 더 높았습니다. 특히 GToT 와 CoT 를 사용한 경우 개발자 기대에 부합하는 명확한 구조를 보였습니다.
• 테스트 냄새:
  • Magic Number Test: 모든 모델과 프롬프트에서 거의 100% 발생하여 여전히 해결되지 않은 문제입니다.
  • Assertion Roulette: GToT 와 CoT 를 사용하면 FSL 나 EvoSuite 에 비해 현저히 감소했습니다.
  • 결론: LLM 은 가독성이 좋지만, 마법 숫자 (Magic Number) 나 잘못된 어설션 등 유지보수를 방해하는 냄새가 여전히 존재합니다.

D. 코드 커버리지 (RQ5)

• 커버리지 격차: EvoSuite 는 라인 커버리지 94% 이상을 달성한 반면, LLM 은 평균 30~50% 수준으로 SBST 에 비해 현저히 낮았습니다.
• 프롬프트 효과: CoT, ToT, GToT 와 같은 추론 기반 프롬프트가 커버리지를 향상시켰으나, EvoSuite 의 체계적인 탐색 능력을 완전히 대체하지는 못했습니다.

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

• LLM 의 역할: LLM 은 현재 단독으로 신뢰할 수 있는 테스트를 생성하는 도구라기보다는, **가독성 높고 유지보수 가능한 테스트 스템플 (Scaffold) 을 생성하는 '보조 도구'**로 적합합니다.
• 하이브리드 접근의 필요성: LLM 의 가독성 장점과 SBST 의 높은 커버리지/정확도 장점을 결합한 하이브리드 접근법 (LLM 생성 + 자동 검증 + SBST 정제) 이 실제 생산 환경에 적용되기 위한 필수 조건임을 강조합니다.
• 프롬프트 엔지니어링의 중요성: 단순한 프롬프트보다 GToT 와 같은 구조화된 추론 프롬프트가 테스트의 구조적 정확성, 컴파일 가능성, 가독성을 크게 개선한다는 사실을 입증했습니다.
• 한계와 향후 과제: 할루시네이션으로 인한 컴파일 실패, 마법 숫자 냄새, 낮은 커버리지 등의 한계가 존재합니다. 향후 연구에서는 자동화된 유효성 검증, 의존성 해결, 그리고 mutation testing 을 통한 결함 탐지 능력 향상이 필요합니다.

이 연구는 LLM 기반 테스트 생성 기술이 성숙단계에 도달하기 위해서는 단순한 코드 생성을 넘어, 구조적 유효성과 유지보수성을 동시에 고려한 체계적인 접근이 필요함을 시사합니다.