버그 있는 코드가 LLM 유닛 테스트를 오도하는 효과 평가와 완화

Who Should Read

LLM으로 유닛 테스트를 자동 생성하는데 버그를 못 잡아 고민인 백엔드·QA 개발자

Core Mechanics

• 버그 코드를 주면 버그를 정답으로 믿는다
  • LLM이 버그 있는 코드의 잘못된 동작을 의도된 기능으로 보고 그걸 검증하는 테스트를 쓴다.
  • 논문은 이런 테스트를 'misguided test'(버그 버전은 통과, 수정 버전은 실패)라고 부른다.
• 버그를 잡는 테스트도 같이 줄어든다
  • 버그 코드 입력 시 effective test(버그 버전 실패, 수정 버전 통과)는 평균 2.98%다.
  • 수정된 코드를 줬을 때는 8.51%로 거의 3배다.
• 코드는 빼고 docstring만 줘야 한다
  • LLM이 코드에서 의도를 뽑아 docstring(명세)을 만들고, 테스트 생성 프롬프트에서는 원본 코드를 제거한다.
  • 코드 옆에 docstring을 같이 붙이는 방식은 효과가 작았다.
• 코드도 docstring도 없으면 오히려 불안정하다
  • 둘 다 빼면 misguided도 줄지만 effective도 같이 줄었다.
  • 행동 정보가 없어 어느 버전에도 안 맞는 테스트가 많아진다.
• docstring 만들 때 버그부터 감사하게 하면 더 낫다
  • 논리 실수와 null 체크 같은 견고성 누락을 먼저 분석한 뒤 수정된 동작 기준으로 docstring을 쓰게 한다.
  • 단점은 환각 동작을 검증하는 테스트 비율이 약 16%에서 약 18%로 살짝 오른다는 것이다.

Evidence

• misguided 테스트는 버그 입력에서 3.84%다
  • Defects4J 318개 focal method, 13개 모델 평균 기준이다.
  • 수정된 코드 입력의 0.46%(평균 16.46개)와 비교하면 137.69개로 많다.
• effective 테스트는 docstring만 줬을 때 늘었다
  • 코드만 준 경우 평균 104.15개에서 docstring만 준 경우 186.77개로 늘었다.
  • misguided는 137.69개에서 113.00개로 줄었다.
• Advanced Docstring Prompt가 더 좋았다
  • Base Docstring Prompt 대비 평균 effective는 186.77개에서 230.23개로 늘었다.
  • misguided는 113.00개에서 87.38개로 줄었다.
• 3라운드 피드백 반복에서도 격차가 컸다
  • 평균 effective 증가는 docstring 입력 35.69개, 버그 코드 입력 17.62개다.
  • misguided 증가는 docstring 입력 18.08개, 버그 코드 입력 31.77개다.

How to Apply

• 테스트 생성 프롬프트에서 구현 코드 빼기
  • 오늘 쓰는 테스트 생성 파이프라인에서 LLM 호출을 두 단계로 나눈다.
  • 먼저 함수 시그니처와 주변 클래스 맥락만 남기고 코드로 docstring을 만들게 한다.
  • 이후 테스트 생성 프롬프트에는 원본 본문 대신 그 docstring을 넣는다.
• docstring 생성에 버그 감사 지시 넣기
  • 논리 실수와 null 체크·경계 조건·에러 처리 누락을 먼저 분석하게 한다.
  • 수정이 적용된 올바른 동작 기준으로 docstring을 쓰도록 요청한다.
• base 모델은 분석을 3단계로 출력시키기
  • 비추론 모델은 '발견한 문제, 필요한 수정, 최종 docstring' 순서로 쓰게 한다.
  • 추론 모델은 분석 지시만 줘도 충분했다.
• 생성된 docstring 사람이 샘플 검수하기
  • 환각 동작이 테스트로 굳는 것을 막기 위해 docstring을 훑어본다.
  • 프로젝트 도메인 지식이 필요한 함수는 사람이 명세를 보강한다.

Try It

# Claude/ChatGPT에 붙여넣기 (논문 방법의 간이 버전: 1단계 docstring 생성)

You are a professional Java developer. Please help identify the intention and functionality of the method detailed below:

{{메서드 코드와 주변 클래스 정보}}

Please provide a formal docstring that identifies the functionality and intended specification of the given method. To do this, first perform a critical analysis from the perspective of an expert software engineer auditing for quality and correctness. Identify (1) Logical Mistakes and (2) Robustness Omissions (input validation, null checks, boundary conditions, error handling, sanitization).

Your output should come in three parts.
Part 1: Critical Analysis. If no issues are found, state: "No issues found."
Part 2: Fixes Required. If none, state: "No fixes required."
Part 3: Final Specification Docstring describing the corrected behavior with all fixes applied. Avoid directly quoting the method code, as it might be buggy. Output it in a fenced java block wrapped between /** and */.

# 2단계: 새 대화에서 위 Part 3의 docstring만 넣고 아래를 요청

You are a professional who writes Java test methods. Details:

{{시그니처, 생성자, 필드 등 맥락}}
{{Part 3 docstring}}

Please write some unit tests in Java 11 and Junit 4 maximizing branch and line coverage. Output in Markdown, no explanations.

이어서 해 볼 것: 같은 함수를 원본 코드로도 테스트 생성해서 어떤 쪽이 버그를 더 잡는지 비교해 보자.

Terminology

관련 논문

• AI는 도구다, 잘 쓰려면 기술이 필요하다

  Hickey의 'AI는 도구가 아니다'에 맞서, LLM도 쓰는 사람의 기술이 결과를 가른다고 반박

• 딥리서치 에이전트의 Reflective Prompt Optimization: 토픽 분리·멀티 시드로 본 진짜 성능 향상과 프롬프트 과적합

  GEPA로 프롬프트를 최적화했더니 held-out 인용 보상 0.702→0.781

• GPT-6와 Intelligent UI: 채팅 안에서 시각·인터랙티브 응답 만들기

  OpenAI가 GPT-6로 채팅 응답에 UI를 넣는다는데 원문이 없어 댓글 반응만 확인된다

• Base 모델도 첫 토큰 단서(cue) 하나로 추론한다: 학습 데이터가 만든 연상

  응답 첫 두 토큰만 고정했더니 Olmo-3-7B의 MATH-500 정답률이 42%에서 78%로 올랐다

• Jev식 Typed Decision Model에서는 정의보다 라벨이 이긴다

  옵션 이름을 A, B로 바꿨더니 정확도가 +0.1511 올랐다

• 프롬프트는 얼마나 필요한가? Few-shot 예시를 블랙박스로 최소화하는 DD-FSM

  Delta debugging으로 few-shot 예시를 평균 65.3% 줄여도 출력은 그대로

• 언어모델은 "불안정한(Insecure)" 보고자다: 결함을 숨기는 LLM 리포트

  "Be honest" 한 줄을 붙였더니 GPT-5.5의 부정 결과 공개가 2/200에서 190/200으로 늘었다

Related Resources

• https://github.com/drixs2050/EvalAndMitigate
• https://doi.org/10.5281/zenodo.21428153