LLM-Based Automated Diagnosis Of Integration Test Failures At Google

1. 문제 정의 (Problem)

소프트웨어 개발 생명주기에서 통합 테스트 (Integration Testing) 는 복잡한 분산 시스템의 품질과 신뢰성을 보장하는 핵심 단계입니다. 그러나 통합 테스트 실패를 진단하는 과정은 개발자들에게 다음과 같은 심각한 어려움을 초래합니다.

• 방대한 로그 양과 비정형 데이터: 통합 테스트는 테스트 드라이버 (Test Driver) 와 시스템 under test (SUT) 의 여러 구성 요소에서 생성된 수많은 로그 파일 (평균 26 개, 중앙값 16 개) 을 생성합니다.
• 낮은 신호 대 잡음비 (Low Signal-to-Noise Ratio): 로그에는 실제 오류와 무관한 경고나 복구 가능한 에러가 혼재되어 있어, 실제 실패 원인을 찾기 어렵습니다.
• 높은 인지 부하: 개발자는 수동으로 다양한 로그 파일을 탐색하고, 서로 다른 포맷을 해석하며, 시간 순서대로 이벤트를 연결해야 합니다.
• 시간 소모: 구글 내부 조사에 따르면, 개발자들은 통합 테스트 실패 진단에 단위 테스트 (Unit Test) 진단보다 훨씬 많은 시간 (보통 1 시간 이상, 심하면 1 일 이상) 을 소비하며, 이는 개발자 만족도 (EngSat) 조사에서 상위 5 가지 불만 사항 중 하나로 꼽혔습니다.

기존의 통계적 디버깅이나 스펙트럼 기반 분석 기법들은 주로 단위 테스트나 소규모 디버깅에 집중되어 있어, 복잡한 환경 설정과 대규모 분산 로그를 다루는 통합 테스트의 고유한 과제를 해결하지 못했습니다.

2. 방법론 (Methodology): Auto-Diagnose

저자들은 이러한 문제를 해결하기 위해 Auto-Diagnose라는 새로운 진단 도구를 제안했습니다. 이 도구는 대규모 언어 모델 (LLM) 을 활용하여 통합 테스트 실패 로그를 분석하고 근본 원인 (Root Cause) 을 진단합니다.

• 시스템 아키텍처:

  1. 로그 수집 및 전처리: 테스트 실패 시, 테스트 드라이버와 SUT 구성 요소의 INFO 이상 레벨의 로그를 수집합니다. 이 로그들은 데이터 센터, 프로세스, 스레드, 로그 레벨을 초월하여 타임스탬프 기준으로 정렬된 단일 로그 스트림으로 결합됩니다.
  2. 프롬프트 엔지니어링: 수집된 로그와 SUT 구성 요소 메타데이터를 LLM (Gemini 2.5 Flash) 에게 전달하기 위해精心하게 설계된 프롬프트 템플릿을 사용합니다.
     • 단계적 추론 (Step-by-step Reasoning): LLM 이 로그를 스캔하고, 테스트 실패 섹션을 식별하며, 오류를 요약하고, 명령줄 인자와의 연관성을 분석하도록 지시합니다.
     • 강제적 제약 (Strict Constraints): LLM 이 추측하거나 관련 없는 결론을 내리는 것을 방지하기 위해 "로그에 명시적으로 언급된 구성 요소의 로그만 사용해야 함", "정보가 부족하면 결론을 내리지 말아야 함" 등의 엄격한 규칙을 적용합니다.
  3. 출력 및 통합: LLM 의 응답을 마크다운 형식으로 후처리하여, 결론, 조사 단계, 그리고 가장 관련 있는 로그 라인 (링크 포함) 을 포함하는 요약본을 생성합니다. 이 결과는 구글의 내부 코드 리뷰 시스템인 Critique에 자동으로 게시되어 개발자에게 컨텍스트 기반의 실시간 도움을 제공합니다.

• LLM 설정:

  • 모델: Gemini 2.5 Flash (속도와 비용 효율성 확보).
  • 파라미터: temperature=0.1 (결정론적 응답을 위한 낮은 온도), top_p=0.8.
  • 학습: 특정 통합 테스트 실패 로그로 미세 조정 (Fine-tuning) 되지 않은 상태의 일반 LLM 을 사용합니다.

3. 주요 기여 (Key Contributions)

1. 통합 테스트 진단을 위한 LLM 적용: 기존 연구가 단위 테스트나 소규모 코드에 집중했던 것과 달리, 복잡한 분산 시스템의 통합 테스트 실패 진단에 LLM 을 성공적으로 적용한 최초의 사례 중 하나입니다.
2. 실무 통합 (Critique Integration): 진단 결과를 개발자의 기존 워크플로우 (코드 리뷰 시스템) 에 자연스럽게 통합하여, 개발자가 컨텍스트를 전환하지 않고도 즉시 피드백을 받을 수 있게 했습니다.
3. 대규모 실증 평가: 71 건의 수동 평가와 구글 전역 52,635 개의 실패 테스트에 대한 실제 배포 데이터를 통해 도구의 효과성을 입증했습니다.

4. 평가 결과 (Results)

• 정확도 (Manual Evaluation): 39 개 팀의 71 건의 실제 통합 테스트 실패를 대상으로 3 명의 전문가가 평가한 결과, **90.14%**의 정확도로 실패의 근본 원인을 진단하고 요약했습니다.
  • 실패한 7 건 중 5 건은 테스트 인프라의 버그 (로그 파일 저장 실패) 로 인한 것이었으며, 이를 통해 인프라 개선에도 기여했습니다.
• 배포 및 사용자 피드백:
  • 2025 년 5 월부터 구글 전역 코드 리포지토리에 배포되어 52,635 개의 실패 테스트를 진단했습니다.
  • 불만족도 (Not Helpful Rate): 전체 피드백 중 "도움이 되지 않음"은 **5.8%**로, 구글의 도구 가이드라인 (10% 미만) 을 충족했습니다.
  • 도움됨 (Helpfulness Rate): "도움됨" 비율은 62.96% 였으며, 이는 370 개의 다른 도구 중 **14 위 (상위 3.78%)**를 기록했습니다.
  • 응답 시간: 진단 결과를 게시하는 데 중위수 (p50) 56 초, 90 백분위수 (p90) 346 초가 소요되어, 개발자가 수동으로 디버깅하는 시간보다 훨씬 빠릅니다.
• 사용자 인터뷰: 개발자들은 자동화된 진단이 로그 탐색 시간을 단축시켜 주며, 워크플로우에 자연스럽게 통합된 점을 높이 평가했습니다. 일부 개발자는 진단을 넘어 자동 수정 (Auto-fix) 기능까지 기대하는 것으로 나타났습니다.

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

• LLM 의 실용적 가치 입증: LLM 이 복잡한 비정형 텍스트 데이터 (로그) 를 처리하고 요약하는 능력이 통합 테스트 진단과 같은 고난이도 엔지니어링 작업에서 매우 효과적임을 증명했습니다.
• 워크플로우 통합의 중요성: AI 기반 도구가 개발자의 일상적인 업무 흐름 (코드 리뷰) 에 자동으로 통합될 때, 개발자들의 수용도가 높아지고 생산성이 향상됨을 보여주었습니다.
• 정확도의 중요성: 도구의 유용성에 대한 개발자의 인식과 채택 여부는 정확도에 크게 의존합니다. 부정적인 피드백 편향 (Negative Bias) 이 존재함에도 불구하고 높은 정확도와 유용성 순위는 도구의 성공적인 도입을 뒷받침합니다.

이 연구는 LLM 기반 자동화 도구가 대규모 분산 시스템의 품질 보증 프로세스를 혁신할 수 있음을 보여주며, 향후 자동 수정 (Auto-repair) 기능으로의 확장을 위한 기반을 마련했습니다.