Automating Detection and Root-Cause Analysis of Flaky Tests in Quantum Software

이 논문은 양자 소프트웨어의 비결정적 특성으로 인한 '플래키 테스트'를 탐지하고 근본 원인을 분석하기 위해 대규모 언어 모델 (LLM) 을 활용한 자동화 파이프라인을 제안하며, 이를 통해 기존 데이터셋을 54% 확장하고 플래키 테스트 분류 및 원인 규명에서 높은 정확도를 입증했습니다.

핵심

🍳 1. 배경: 왜 양자 소프트웨어는 '요리'가 어려울까?

전통적인 소프트웨어는 레시피대로 만들면 항상 같은 맛이 납니다. 하지만 양자 소프트웨어는 다릅니다. 양자 컴퓨터는 확률 (우연) 에 기반하기 때문에, 같은 레시피로 같은 재료를 써도 오늘은 맛있는 요리를 만들고, 내일은 갑자기 맛이 변할 수 있습니다.

개발자들은 이 요리를 테스트할 때, "이 레시피가 잘못됐나?"라고 의심하게 됩니다. 하지만 실제로는 레시피 (코드) 에 문제가 없는데, 양자 컴퓨터의 특성상 결과가 들쑥날쑥한 것일 뿐입니다. 이를 **'요동치는 테스트 (Flaky Test)'**라고 부릅니다.

• 문제점: 개발자는 "아, 또 실패했네. 레시피를 고쳐야지!"라고 생각하며 시간을 낭비합니다. 하지만 실제로는 레시피가 완벽할 수도 있습니다. 이렇게 불필요한 수리 작업이 쌓이면 개발 속도가 느려지고, 진짜 버그 (실수) 가 숨어있을 때 발견하지 못하게 됩니다.

🔍 2. 연구의 목표: AI 가 '요리 실수'를 찾아내다

이 논문은 **"인간이 일일이 찾아다니지 않아도, AI 가 자동으로 요동치는 테스트를 찾아내고, 왜 그런지 이유를 알려주는 시스템"**을 만들었습니다.

저자들은 다음과 같은 일을 했습니다:

1. 데이터 확장: 기존에 사람이 일일이 찾아낸 '요동치는 테스트' 목록 (46 개) 에, 새로운 25 개를 더 찾아서 총 71 개로 늘렸습니다. (약 54% 증가!)
2. AI 학습: 최신 거대 언어 모델 (LLM, 예: Google Gemini, OpenAI GPT 등) 에게 이 데이터를 보여주고, "이 테스트가 요동치는 거야, 아니면 진짜 버그야?"라고 물어보게 했습니다.
3. 원인 분석: 만약 요동치는 테스트라면, "왜 그런 거야?"라고 물어봐서 원인을 찾아냈습니다.

🛠️ 3. 해결책: AI 가 어떻게 도와줄까?

연구팀은 GitHub라는 개발자들이 코드를 공유하는 곳에 올라온 '버그 리포트 (Issue)'와 '수정 제안 (Pull Request)'을 분석했습니다.

• 비유: 마치 **수석 셰프 (AI)**가 주방의 기록장 (GitHub) 을 훑어보며, "어? 이 요리는 오늘만 실패했네? 아, 재료가 흔들려서 그런가? 아니면 오븐 온도가 불안정한가?"라고 추리하는 것과 같습니다.

연구팀은 AI 에게 두 가지 정보를 주었습니다:

1. 글자 (텍스트): 개발자가 쓴 "이게 왜 안 돼?"라는 설명.
2. 코드 (Recipe): 실제로 작성된 요리 레시피 (소스 코드).

그 결과, Google Gemini 2.5 Flash라는 AI 모델이 가장 잘 작동했습니다. 요동치는 테스트를 찾아내는 정확도가 94% 이상, 원인을 찾는 정확도가 96% 이상으로 매우 뛰어났습니다.

🧩 4. 요동치는 테스트의 주요 원인 (8 가지 유형)

AI 가 찾아낸 원인은 크게 8 가지로 분류됩니다. 일상적인 비유로 설명하면 다음과 같습니다:

1. 무작위성 (Randomness): 가장 흔한 원인입니다. 주사위를 굴려서 결과를 정하는데, 주사위를 굴리는 방식이 매번 달라서 결과가 일정하지 않습니다.
   • 해결: 주사위를 굴리는 '시작 숫자 (Seed)'를 고정합니다.
2. 소프트웨어 환경: 특정 운영체제나 라이브러리 버전 때문에만 실패합니다. (예: 한국인만 먹고 배탈 나는 음식)
3. 멀티스레딩 (동시 작업): 여러 사람이 동시에 요리를 하다가 재료가 섞이거나 충돌이 일어납니다.
4. 부동 소수점 (숫자 오차): 계산할 때 아주 작은 오차가 쌓여서 결과가 달라집니다. (예: 0.1 + 0.2 가 0.3 이 아닌 0.30000000000000004 가 되는 경우)
5. 시각화: 그림을 그릴 때 데이터가 늦게 들어와서 이미지가 깨집니다.
6. 처리되지 않은 예외: 예상치 못한 상황 (예: 재료가 떨어짐) 이 왔을 때 대처법을 안 써서 멈춥니다.
7. 네트워크: 인터넷이 불안정해서 데이터가 늦게 도착합니다.
8. 순서 불명확: 재료 순서가 중요할 때, 순서가 매번 바뀌는 경우입니다.

🚀 5. 결론: 앞으로의 전망

이 연구는 **"양자 소프트웨어 개발의 고통을 줄여주는 자동화 도구"**의 가능성을 보여주었습니다.

• 기존 방식: 개발자가 "왜 실패하지?"라고 수백 번 테스트를 돌려가며 직접 원인을 찾음. (시간과 비용 낭비)
• 새로운 방식: AI 가 "아, 이거 요동치는 테스트야. 원인으로는 '주사위 (랜덤성)' 때문인 것 같아. 이 부분을 고쳐보자."라고 바로 알려줌.

미래 계획:
이제 AI 가 원인을 찾아내는 것뿐만 아니라, **"어떻게 고쳐야 할지 (수리 방법)"**까지 자동으로 제안하고, 실제로 코드를 수정해 주는 단계까지 발전시킬 계획입니다.

💡 한 줄 요약

"양자 소프트웨어의 '요동치는 테스트'라는 귀찮은 문제를, 최신 AI 가 자동으로 찾아내고 원인을 설명해 주어 개발자들이 진짜 버그만 고르게 도와주는 혁신적인 방법입니다."

이 기술이 발전하면 양자 컴퓨터를 이용한 앱이나 서비스도 더 안정적이고 빠르게 개발될 수 있을 것입니다.

기술 요약

1. 문제 정의 (Problem)

• 배경: 고전 소프트웨어와 마찬가지로 양자 소프트웨어도 자동화된 테스트에 의존하지만, 양자 컴퓨팅의 고유한 특성 (확률적 출력, 양자 잡음 등) 으로 인해 **'양자 불안정성 (Quantum Flakiness)'**이 발생합니다. 이는 코드 변경 없이도 테스트가 일관성 없이 통과하거나 실패하는 현상입니다.
• 도전 과제:
  • 근본 원인 차이: 고전 소프트웨어의 불안정성은 주로 동시성 (concurrency) 문제에서 기인하는 반면, 양자 소프트웨어는 **무작위성 (Randomness)**이 주요 원인입니다.
  • 재현 비용: 실제 양자 하드웨어에서 불안정성을 재현하기 위해 테스트를 반복 실행해야 하며, 이는 IBM 양자 플랫폼과 같은 환경에서 시간과 비용 (사용료) 이 매우 많이 듭니다.
  • 도구 부재: 기존 고전 소프트웨어용 탐지 도구는 양자 소프트웨어의 확률적 특성과 데이터 부족 문제를 해결하지 못하며, 체계적인 자동화 도구가 부족합니다.

2. 방법론 (Methodology)

이 연구는 기존 수동 분석 데이터를 기반으로 한 자동화 파이프라인을 구축하고, 대규모 언어 모델 (LLM) 을 활용한 탐지 및 진단을 평가했습니다.

• 데이터 확장 (Dataset Expansion):
  • 기존 14 개 양자 소프트웨어 저장소에서 수동으로 수집된 46 개의 불안정 테스트 사례를 기반으로, 임베딩 (Embedding) 트랜스포머와 **코사인 유사도 (Cosine Similarity)**를 사용하여 새로운 사례를 자동 탐지했습니다.
  • mixedbread-ai/mxbai-embed-large-v1 모델을 사용하여 GitHub 이슈 리포트 (IR) 와 풀 리퀘스트 (PR) 의 텍스트를 벡터화하고, 기존 알려진 불안정 사례와 유사도가 높은 새로운 사례를 선별하여 수동 검증을 거쳤습니다.
• 자동화 파이프라인 및 LLM 평가:
  • 입력 구성: 텍스트 컨텍스트 (이슈 설명, 댓글) 와 코드 컨텍스트 (수정 전/후 코드, 메서드 단위 또는 전체 코드) 를 결합하여 LLM 에 입력했습니다.
  • 모델 평가: OpenAI(GPT-4o, GPT-4o-mini 등), Meta(Llama-3.1), Google(Gemini-2.5-flash), Anthropic(Claude-4) 등 7 가지 LLM 을 평가했습니다.
  • 연구 질문 (RQ) 수행:
    • RQ3: 주어진 IR/PR 이 불안정 테스트와 관련이 있는지 분류 (Flaky vs Non-flaky).
    • RQ4: 코드 컨텍스트 추가 시 분류 정확도 변화 분석.
    • RQ5: 불안정 테스트의 근본 원인 (무작위성, 부동소수점 연산, 네트워크 등 9 가지 카테고리) 자동 식별.
  • 프롬프트 전략: Zero-shot 및 Few-shot 프롬프팅 (코사인 유사도로 선별된 유사 사례를 예시로 제공) 을 적용하여 성능을 비교했습니다.

3. 주요 기여 (Key Contributions)

1. 확장된 양자 불안정성 데이터셋: 기존 46 개 사례에서 25 개의 새로운 사례를 추가하여 총 71 개 (약 54% 증가) 로 확장했습니다. 이 데이터셋에는 불안정성을 유발하는 버그 코드, 수정 패턴, 그리고 근본 원인이 포함되어 있으며, 공개되어 있습니다.
2. 자동 탐지 파이프라인 개발: 텍스트 (이슈/PR) 와 코드 컨텍스트를 결합하여 LLM 을 활용한 반자동/자동 탐지 프로세스를 제안했습니다.
3. LLM 기반 분류 및 진단 성능 검증: 다양한 LLM 을 사용하여 불안정 테스트 분류 및 근본 원인 식별이 가능함을 입증했습니다. 특히 Google Gemini 2.5 Flash가 가장 우수한 성능을 보였습니다.
4. 근본 원인 및 수정 패턴 분석: 양자 소프트웨어에서 불안정성의 주된 원인이 **무작위성 (PRNG)**임을 재확인하고, 이를 해결하기 위한 '시드 고정 (Fix Seed)'이 가장 일반적인 해결책임을 통계적으로 제시했습니다.

4. 실험 결과 (Results)

• 데이터셋 확장: 12 개 저장소에서 25 개의 새로운 불안정 테스트를 발견하여 데이터셋을 71 개로 확장했습니다. 전체 폐쇄된 이슈 중 불안정 테스트 비율은 약 0.82% 로 관찰되었으나, 실제 비율은 더 높을 것으로 추정됩니다.
• 모델 성능 (F1-Score 기준):
  • 불안정 테스트 분류 (RQ3): Google Gemini 2.5 Flash가 전체 컨텍스트 (텍스트 + 전체 코드) 를 사용할 때 F1-Score 0.9420으로 가장 높은 성능을 기록했습니다.
  • 근본 원인 식별 (RQ5): 동일한 모델 (Gemini 2.5 Flash) 이 F1-Score 0.9643을 기록하여, 텍스트와 코드를 결합한 맥락에서 LLM 이 복잡한 원인 분석도 효과적으로 수행함을 보였습니다.
  • 컨텍스트 영향: 이슈 설명과 댓글을 모두 포함한 전체 텍스트 (Full Text, Rf) 와 메서드 단위 코드 (Partial Code, Cp) 를 함께 사용하는 것이 가장 효과적인 조합 중 하나였습니다.
• 근본 원인 통계: 71 개 사례 중 **무작위성 (Randomness)**이 19.2% 로 가장 많았으며, 이어 소프트웨어 환경 (11.0%), 멀티스레딩 (13.7%) 순이었습니다.

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

• 양자 소프트웨어 공학의 자동화: 이 연구는 데이터 부족과 고비용이라는 양자 소프트웨어의 고유한 제약 속에서 LLM 을 활용한 효율적인 테스트 관리 방안을 제시했습니다.
• 실용적 가치: 개발자가 불안정 테스트 리포트를 우선순위화 (Triaging) 하고, 그 원인을 빠르게 파악하여 수정할 수 있도록 지원함으로써 개발 생산성을 높이고 기술 부채를 줄이는 데 기여합니다.
• 향후 과제: 탐지 파이프라인의 강건성 향상, 실제 테스트 재실행 (동적 분석) 을 통한 검증, 그리고 자동 수정 (Auto-fix) 기능 개발을 위한 연구가 필요하다고 결론지었습니다.

이 논문은 양자 소프트웨어의 신뢰성을 높이기 위해 LLM 기반의 자동화 도구가 필수적임을 입증하고, 이를 위한 구체적인 데이터셋과 방법론을 제공했다는 점에서 중요한 의의를 가집니다.