On the Flakiness of LLM-Generated Tests for Industrial and Open-Source Database Management Systems

기술 요약: 산업용 및 오픈 소스 데이터베이스 관리 시스템(DBMS)을 위한 LLM 생성 테스트의 플래키성(Flakiness)에 대하여

문제 정의
동일한 코드 상태에서 여러 번 실행했을 때 일관되지 않은 결과를 생성하는 플래키 테스트(Flaky tests)는 산업용 소프트웨어 테스트에서 중요한 과제로, 개발자의 신뢰를 떨어뜨리고 효율성을 저해한다. 최근 연구들은 LLM이 생성한 테스트에서도 플래키성이 잠재적인 문제임을 식별했으나, 이러한 맥туа의 발생 빈도, 근본 원인, 그리고 플래키성 전이(flakiness transfer)의 메커니즘은 여전히 불분명하다. 본 연구는 비즈니스 운영에서 테스트 신뢰성이 매우 중요한 데이터베이스 관리 시스템(DBMS) 맥락 내에서, LLM 생성 테스트의 플래키성에 관한 전용 연구의 공백을 다룬다.

연구 방법론
저자들은 폐쇄형 소스 산업용 시스템인 SAP HANA와 세 가지 오픈 소스 시스템(MySQL, DuckDB, SQLite)을 포함한 네 가지 DBMS를 대상으로 실증 연구를 수행했다. 연구는 두 가지 테스트 유형, 즉 네이티브 C++ 유닛 테스트와 SQL 시스템 테스트에 집중했다.

• 테스트 생성 접근 방식: 연구진은 기존 테스트 파일의 확장 버전을 생성하여 추가적인 코너 케이스(corner cases)를 커버하도록 LLM에 프롬프팅하는, Alshahwan 등[5]의 연구에서 영감을 받은 테스트 증폭(test amplification) 전략을 채택했다.
• 모델: 두 가지 LLM을 평가했다: GPT-4o(높은 성능과 내부 SAP HANA 코드 처리 능력을 고려하여 선정)와 Mistral-Large-Instruct-2407(재현성을 위한 오픈 소스 대안으로 선정). 두 모델 모두 컴파일 성공률을 극대화하기 위해 온도를 0으로 설정하여 실행되었다.
• 실행 환경: 생성된 코드 자체로 인한 플래키성과 환경적 노이즈를 분리하기 위해, 테스트는 격리된 Docker 컨테이너 내에서 각각 30회씩 실행되었다. C++ 테스트는 개별적으로 실행되었고, SQL 테스트는 해당 테스트 프레임워크의 설계를 준수하기 위해 파일 순서대로 실행되었다.
• 플래키성 탐지: 테스트가 30회의 실행 과정에서 통과(pass)와 실패(fail) 결과를 모두 생성할 경우 플래키한 것으로 분류되었다.
• 플래키성 전이 실험: 플래키성 전이에 대한 취약성을 평가하기 위해, 저자들은 새로운 테스트를 생성하도록 LLM에 프롬프팅하기 전, 기존 테스트 파일에 비결정론적 단언문(50% 확률로 실패하는 형태)을 주입했다.

주요 기여

1. 발생 빈도 분석: 네 가지 DBMS에 걸쳐 LLM이 생성한 코드와 기존 인간 작성 테스트 간의 플래키 테스트 비율에 대한 정량적 평가를 수행했다.
2. 근본 원인 식별: 생성 과정에서 발생하는 문제와 컨텍스트로부터 전이된 문제를 구분하여, LLM 생성 테스트의 플래키성에 대한 근본 원인을 수동 검사 및 범주화했다.
3. 플래키성 전이 벤치마크: 제공된 인컨텍스트(in-context) 예시로부터 LLated 패턴이 새로 생성된 코드에 전달되는 정도를 평가하기 위해, 폐쇄형(SAP HANA)과 오픈 소스(MySQL) 맥락 간의 성능을 비교하며 실험적 평가를 수행했다.

결과

• 컴파일 및 성공률: LLM은 특정 코드베이스에 대한 학습 데이터 부족으로 인해 폐쇄형 소스인 SAP HANA 프로젝트에 대한 컴파일 가능한 C++ 코드를 생성하는 데 상당한 어려움을 겪었다(컴파일 성공률 약 40-46%). 반면, SQL 테스트 생성은 높은 통과율(81-95%)을 보였다.
• 플래키성 발생 빈도: LLM 생성 코드의 플래키 테스트 비율은 일반적으로 기존 테스트보다 약간 높았다.
  • C++ 테스트의 경우, GPT-4o는 SAP HANA에 대해 0.29%, MySQL에 대해 0.18%의 플래키 테스트를 생성했으며, Mistral은 각각 0.39%와 0.71%로 약간 더 높은 비율을 생성했다.
  • SQL 테스트의 경우, 기존 테스트 스위트에서 플래키한 테스트가 발견되지 않았음에도 불구하고, LLM은 총 96개의 플래키 테스트를 생성했다(GPT-4o 43개, Mistral 53개).
• 근본 원인: LLM 생성 테스트에서 가장 빈번한 플래키 원인은 "정렬되지 않은 컬렉션(Unordered Collection)"(115개 중 63%)이었다. 이는 LLM이 ORDER BY를 사용하지 않고 특정 결과 순서를 가정하여 SQL 쿼리를 생성할 때 발생하며, 이로 인해 간헐적인 실패가 초래되었다.
  • NIO (Non-Idempotent Outcome, 비멱등적 결과) 플래키성이 두 번째로 흔한 원인(10%)이었으며, 이는 주로 LLM이 실행 환경을 오염시키는 기존 테스트를 모방할 때 발생했다.
  • 동시성(Concurrency) 문제는 주로 Mistral에 의해 생성된 테스트에서 관찰되었다.
• 플래키성 전이: 두 LLM 모두 프롬프트 컨텍스트로부터 주입된 플래키성을 생성된 테스트로 전이하는 취약성을 보였다.
  • SAP HANA 맥락(폐쇄형 소스, 학습 데이터 없음)에서는 전이율이 더 높았다(~생성된 테스트의 69-78%가 주입된 플래키 단언문을 포함함).
  • MySQL 맥락(오픈 소스, 학습 데이터에 존재할 가능성 높음)에서는 전이율이 더 낮았다(~41-58%).
  • 이는 LLM이 시스템에 대한 사전 지식이 부족할 때 제공된 컨텍스트에 더 많이 의존하며, 부적절한 상관관계(예: 플래키한 단언문)를 유효한 코딩 패턴으로 채택할 수 있음을 시사한다.

의의 및 주장
본 논문은 데이터베이스 시스템을 위한 LLM 생성 테스트의 플래키성에 대한 첫 번째 전용 통찰을 제공한다고 주장한다. 저자들은 LLM이 자연스러운 테스트 코드를 생성할 수는 있지만, 특히 정렬되지 않은 데이터 구조나 기존 결함의 전이와 관련하여 특정한 플래키 위험을 도입한다는 결론을 내렸다.

본 연구는 플래키성 전이가 특히 모델이 학습 데이터가 부족하여 인컨텍스트 러닝에 크게 의존해야 하는 폐쇄형 환경에서 크리티컬한 문제임을 강조한다. 따라서 저자들은 LLM 기반 생성 방식을 적용하기 전에 기존의 플래키한 테스트를 먼저 수정할 것을 권고하며, "정렬되지 않은 컬렉션" 가정과 같은 근본 원인을 완화하기 위해 LLM에 맞춤형 컨텍스트를 제공하는 것이 필수적이라고 조언한다. 또한 현재의 컨텍스트 윈도우가 SAP HANA와 같은 대규모 시스템에는 불충분할 수 있음을 언급했다. 본 연구의 결과는 자동화된 테스트 파이프라인에 LLM을 통합하려는 개발자와 연구자들에게 주의 깊은 기준점(cautionary baseline)을 제공한다.