1.4.5 Flaky Test(성공과 실패가 오락가락하는 테스트)의 급증과 CI/CD 신뢰도 하락
소프트웨어 개발 프로세스에서 지속적 통합 및 배포(CI/CD)는 현대적인 엔지니어링의 심장부와 같다. 개발자가 코드를 커밋하는 순간 자동화된 파이프라인이 작동하여 빌드, 테스트, 배포를 수행함으로써 코드의 품질을 보장하고 사용자에게 가치를 전달하는 주기를 단축한다. 그러나 인공지능(AI)과 거대언어모델(LLM)이 소프트웨어의 핵심 로직에 통합되고, 테스트 코드 자체를 생성하는 단계에 이르면서 이 견고했던 신뢰의 사슬에 치명적인 균열이 발생하고 있다. 그 균열의 정체는 바로 ’플래키 테스트(Flaky Test)’의 폭발적인 증가다.
플래키 테스트란 동일한 코드 베이스와 동일한 실행 환경에서 수행되었음에도 불구하고, 어떤 때는 성공하고 어떤 때는 실패하는 비결정론적(Non-deterministic)인 동작을 보이는 테스트를 의미한다. 전통적인 소프트웨어 공학에서도 네트워크 지연, 경합 조건(Race Condition), 혹은 부적절한 테스트 격리 등으로 인해 플래키 테스트가 존재해 왔으나, AI 기반 시스템에서는 비결정성이 시스템의 근본적인 설계 특성에서 기인하기 때문에 그 빈도와 복잡도가 차원을 달리한다. 이러한 현상은 단순히 개발자의 불편함을 넘어, 자동화된 품질 보증 체계 전체에 대한 신뢰를 붕괴시키고 조직의 생산성을 마비시키는 ’소리 없는 살인자’로 작용하고 있다.
1. 비결정성의 기원: 하드웨어와 수학적 정밀도의 한계
AI 기반 소프트웨어에서 플래키 테스트가 급증하는 근본적인 이유는 시스템의 가장 낮은 하부 계층인 하드웨어와 수학적 연산 방식에서부터 비결정성이 내재되어 있기 때문이다. 결정론적 시스템을 지향하는 전통적 소프트웨어와 달리, 확률적 시스템인 LLM은 동일한 입력에 대해서도 미세하게 다른 결과를 출력할 가능성을 상시 내포하고 있다.
첫 번째 원인은 부동 소수점 연산의 비결합성(Non-associativity of Floating-point Arithmetic)이다. 수학적으로 실수의 덧셈은 결합 법칙이 성립하지만, 컴퓨터가 이를 이진수로 표현하고 반올림하는 과정에서는 연산 순서에 따라 결과가 달라진다. 즉, (a + b) + c의 결과가 a + (b + c)와 다를 수 있는 것이다. 현대의 LLM 추론은 수천 개의 코어가 병렬로 작동하는 GPU 환경에서 이루어지는데, 각 스레드가 연산을 완료하고 결과를 합산하는 순서는 하드웨어의 스케줄링 상태와 메모리 병목 현상에 따라 매 실행 시점마다 달라진다. 이 미세한 오차는 신경망의 수많은 층을 거치며 증폭되고, 결국 출력되는 토큰의 확률 분포에 영향을 주어 전혀 다른 단어를 선택하게 만든다.
두 번째 원인은 소프트맥스(Softmax) 함수와 온도(Temperature) 파라미터의 역설적 동작이다. LLM의 출력 확률을 조정하는 소프트맥스 함수는 다음과 같은 수식으로 정의된다.
P(x_i) = \frac{e^{x_i/T}}{\sum_{j=1}^{N} e^{x_j/T}}
이론적으로 온도 T를 0으로 설정하면 가장 높은 확률을 가진 토큰만을 선택하는 그리디 샘플링(Greedy Sampling)이 수행되어 결정론적인 결과가 나와야 한다. 그러나 실제 운영 환경에서는 하드웨어 수준의 노이즈로 인해 두 토큰의 로짓(Logit) 값이 소수점 아주 먼 지점에서 차이가 날 경우, 앞서 언급한 연산 순서의 차이가 승자를 뒤바꾸는 결과를 초래한다. 결국 개발자가 ’확정적인 답변’을 기대하며 T=0 설정을 사용하더라도, 테스트 파이프라인에서는 여전히 오락가락하는 결과를 목격하게 되는 것이다.
| 비결정성의 원인 계층 | 메커니즘 | 테스트에 미치는 영향 |
|---|---|---|
| 하드웨어(GPU/TPU) | 병렬 코어의 실행 순서 변동 및 원자적 가산(Atomic Add)의 비결정성 | 동일 입력에 대한 미세한 수치적 차이 발생 |
| 수치 연산 라이브러리 | 부동 소수점 연산의 비결합성 \vert (a + b) + c \neq a + (b + c) | 연산 경로에 따른 결과값의 불안정성 |
| 모델 추론(Inference) | 소프트맥스 함수 내 온도 파라미터와 타이 브레이킹(Tie-breaking) 문제 | 가장 높은 확률의 토큰이 매번 바뀌는 현상 |
| 인프라 환경 | 연속 배치(Continuous Batching) 및 다중 GPU 샤딩 | 요청 간 간섭 및 인프라 부하에 따른 응답 변동 |
이러한 기술적 근원은 AI 소프트웨어 테스트를 ’가끔 실패하는 골칫거리’가 아닌, ’예측 불가능한 확률 게임’으로 전락시킨다. 이는 CI/CD 파이프라인이 제공해야 하는 가장 핵심적인 가치인 ’재현 가능성(Reproducibility)’을 정면으로 부정하는 결과로 이어진다.
2. LLM 생성 테스트의 구조적 결함: On the Flakiness of LLM-Generated Tests 분석
최근 개발 생산성을 극대화하기 위해 LLM을 활용하여 단위 테스트를 자동 생성하는 시도가 활발해지고 있다. 그러나 이러한 접근법은 테스트 스위트 내에 ’시한폭탄’과 같은 플래키 테스트를 대량으로 심는 결과를 낳고 있다. On the Flakiness of LLM-Generated Tests for Industrial and Open-Source Database Management Systems라는 논문에 따르면, LLM이 생성한 테스트는 인간이 작성한 테스트보다 플래키 현상을 보일 확률이 현저히 높다.
이 연구는 SAP HANA, DuckDB, MySQL, SQLite와 같은 주요 데이터베이스 시스템을 대상으로 GPT-4o와 Mistral-Large-Instruct-2407 모델이 생성한 테스트 케이스를 분석하였다. 연구 결과에 따르면, 생성된 테스트에서 발생한 플래키 현상의 약 63%(115건 중 72건)가 ’정렬되지 않은 컬렉션(Unordered Collection)’에 대한 의존성 때문인 것으로 밝혀졌다.
데이터베이스 쿼리 결과는 명시적인 ORDER BY 구문이 없는 한 행의 출력 순서가 보장되지 않는다. 그러나 LLM은 특정 환경에서 관찰된 결과값의 순서를 정답으로 오인하여, 이를 기반으로 엄격한 순서 비교 단언문(assert(list == expected_list))을 생성하는 경향이 있다. 이 테스트는 로컬 환경에서는 성공할지 모르나, CI 파이프라인의 다른 데이터 상태나 캐시 설정 하에서는 행의 순서가 바뀌며 실패하게 된다. 이는 LLM이 코드의 표면적인 형태는 훌륭하게 모사하지만, 시스템의 비결정적 특성에 대한 심층적인 이해는 부족하다는 점을 명확히 보여준다.
또한, 해당 연구는 ’플래키 전이(Flakiness Transfer)’라는 흥미로운 현상을 지적한다. LLM은 프롬프트에 제공된 기존 테스트 코드의 패턴을 학습하여 새로운 테스트를 생성하는데, 만약 기존 코드에 비결정론적인 요소나 잘못된 관행이 포함되어 있다면 LLM은 이를 비판 없이 복제하여 새로운 플래키 테스트를 양산한다. 특히 소스 코드가 공개되지 않은 폐쇄형 시스템(Closed-source)인 SAP HANA의 경우, 모델이 시스템의 동작 원리를 유추할 데이터가 부족하여 이러한 전이 현상이 더욱 심각하게 나타났다.
| 데이터베이스 시스템 | 연구에 사용된 모델 | 주요 플래키 원인 | 플래키 전이 관찰 여부 |
|---|---|---|---|
| SAP HANA | GPT-4o, Mistral | Unordered Collection, Timeout | 매우 높음 (폐쇄형 시스템 영향) |
| MySQL \vert SQLite | GPT-4o, Mistral | Unordered Collection | 보통 |
| DuckDB | GPT-4o, Mistral | API 종속성 변동 | 낮음 |
이러한 연구 결과는 AI 기반 개발 환경에서 ’자동화된 테스트 생성’이 오히려 ’자동화된 기술 부채 생성’으로 변질될 수 있음을 경고한다. 개발자가 생성된 테스트 코드를 한 줄씩 면밀히 검토하지 않고 CI에 통합하는 순간, 파이프라인의 신뢰도는 급격히 하락하기 시작한다.
3. CI/CD 파이프라인의 신뢰성 지표 하락과 경제적 손실
플래키 테스트가 CI/CD 파이프라인에 미치는 영향은 단순히 ’빨간 불’이 들어오는 것에 그치지 않는다. 이는 파이프라인의 전체적인 신뢰 지표를 왜곡하며, 조직의 배포 속도와 직결되는 수치들을 악화시킨다.
3.1 통계적 관점에서 본 안정성 붕괴
Bitrise Mobile Insights 보고서에 의하면, 모바일 앱 개발 파이프라인에서 플래키 테스트로 인해 워크플로우가 실패할 확률은 2022년 10%에서 2025년 26%로 세 배 가까이 치솟았다. 이는 엔지니어가 수행하는 네 번의 빌드 중 한 번은 코드 결함이 아닌 ’테스트 자체의 변덕’으로 인해 실패한다는 뜻이다. 이로 인해 성공적인 빌드 비율(Build Success Rate)은 급감하고, 실패한 원인을 분석하기 위한 평균 복구 시간(MTTR, Mean Time To Recover)은 비약적으로 증가한다.
| CI/CD 핵심 지표 | 플래키 테스트가 미치는 부정적 영향 | 결과 |
|---|---|---|
| Build Success Rate | 실제 오류가 없음에도 빌드가 실패하여 성공률 하락 | 파이프라인 가시성 저하 |
| MTTR (Mean Time To Recover) | 실패 원인이 플래키인지 실제 버그인지 판별하는 데 시간 소요 | 장애 복구 지연 |
| Lead Time for Changes | 반복적인 재시도로 인해 코드가 배포되기까지의 시간 증가 | 시장 대응 속도 저하 |
| Deployment Frequency | 파이프라인 불안정으로 인해 릴리스 횟수 감소 | 릴리스 주기 연장 |
3.2 경제적 비용과 생산성 저하의 정량화
플래키 테스트는 기업에 막대한 재무적 손실을 입힌다. 구글의 연구에 따르면, 테스트 실패의 약 4.56%가 플래키 테스트이며, 이는 전체 코딩 시간의 약 2%를 소모하게 만든다. 이를 50명의 개발자를 보유한 중견 기업에 적용해 보면, 매년 한 명의 엔지니어가 오직 유령 같은 테스트 실패를 쫓는 데에만 전념하는 비용(약 12만 달러 이상의 인건비)을 낭비하는 셈이다.
CircleCI의 분석에 의하면 대규모 엔지니어링 조직은 플래키 테스트의 재실행(Retry)에만 매일 4,200시간 이상의 생산 시간을 허비하고 있다. 여기에 실패한 테스트를 분석하기 위해 개발자가 수행해야 하는 맥락 전환(Context Switching) 비용까지 고려하면 그 피해는 더욱 막대하다. 개발자가 한 번 흐름이 끊긴 후 다시 몰입 상태(Flow State)로 돌아가는 데 평균 23분이 걸린다는 점을 생각할 때, 파이프라인의 거짓 알람은 단순한 시간 낭비 그 이상의 지적 자산 손실을 의미한다.
4. 심리적 마모: ‘양치기 소년’ 효과와 조직 문화의 부패
기술적, 경제적 피해보다 더 무서운 것은 개발 팀 내부에 퍼지는 심리적인 무력감과 불신이다. 이를 소프트웨어 공학에서는 ‘양치기 소년 효과(Boy Who Cried Wolf Effect)’ 또는 ’거짓 양성의 함정’이라고 부른다.
4.1 알람 피로도와 신뢰의 증발
CI 파이프라인에서 테스트가 실패했을 때, 개발자의 첫 번째 반응은 “내가 무엇을 잘못했는가?“여야 한다. 그러나 플래키 테스트가 상시화된 환경에서 개발자의 첫 번째 반응은 “아, 또 플래키인가? 다시 돌려보자“로 변한다. 실제로 많은 팀에서 테스트 실패 시 원인 분석 없이 ‘Re-run’ 버튼을 누르는 것이 관례가 되어버렸다.
이러한 문화가 정착되면 다음과 같은 파괴적인 현상이 발생한다.
- 진성 버그의 은폐: 플래키하다고 알려진 특정 테스트가 실제 코드의 심각한 결함으로 인해 실패하더라도, 개발자는 이를 단순한 ’노이즈’로 치부하고 배포를 강행한다. 이는 결국 운영 환경에서의 대형 사고로 이어진다.
- 공학적 규율의 붕괴: “테스트가 100% 통과하지 않아도 배포할 수 있다“는 인식이 확산되면, 코드 품질에 대한 책임감이 약화된다. 이는 조직 전체의 기술 부채를 급증시키는 원인이 된다.
- 신규 입사자의 오염: 조직에 새로 합류한 개발자들은 테스트를 신뢰하는 법을 배우기 전에 “실패한 테스트를 무시하고 재실행하는 법“을 먼저 배우게 된다. 이는 팀의 품질 문화를 뿌리째 뒤흔드는 결과를 초래한다.
4.2 엔지니어링 정체와 아키텍처적 불감증
플래키 테스트는 시스템의 근본적인 설계 결함을 감추는 가림막 역할도 한다. 비결정론적인 실패는 종종 경합 조건, 부적절한 자원 해제, 혹은 모호한 API 계약(Contract) 때문에 발생한다. 만약 AI를 사용하여 이러한 실패를 ‘자동으로’ 다시 실행하거나 적당히 통과시키도록 설정한다면, 시스템은 아키텍처적으로 개선될 기회를 영영 잃게 된다. 불안정한 시스템 설계 위에 AI라는 블랙박스가 더해지면서, 전체 시스템은 누구도 제어할 수 없는 ’혼돈의 덩어리’로 변해간다.
5. 결정론적 오라클을 향한 대응 전략
급증하는 플래키 테스트와 CI/CD 신뢰도 하락에 맞서기 위해, 현대적인 AI 소프트웨어 엔지니어링은 ’결정론적 정답지’를 제공하는 오라클 시스템을 구축하는 방향으로 진화해야 한다. 단순히 테스트를 반복 실행하는 것은 근본적인 해결책이 될 수 없으며, 비결정성의 원인을 계층별로 통제하는 전략적 접근이 필요하다.
첫째, ’밀폐된 테스트 환경(Hermetic Test Environment)’의 구축이다. 외부 API, 네트워크 상태, 시스템 시간과 같은 가변적인 요소를 철저히 격리해야 한다. Docker 컨테이너를 활용하여 매 실행마다 깨끗한 상태에서 테스트를 시작하고, 비결정론적인 외부 의존성은 확정적인 응답을 주는 모의 객체(Mock)로 대체하는 것이 기본이다.
둘째, ’의미론적 단언(Semantic Assertion)’으로의 전환이다. AI의 출력 결과가 문자열 수준에서 완벽히 일치할 것을 기대하는 대신, 결과의 구조나 핵심 의미가 일치하는지를 검증해야 한다. JSON Schema를 사용하여 출력 형식을 강제하거나, LLM-as-a-Judge 기법을 도입하여 결과의 타당성을 평가하는 하이브리드 오라클 체계가 그 대안이 될 수 있다.
셋째, ‘플래키 테스트 격리(Quarantine)’ 매커니즘의 도입이다. 불안정한 것으로 판명된 테스트는 즉시 메인 파이프라인에서 분리하여 ’격리 수용소’로 보내야 한다. 이 테스트들은 비차단(Non-blocking) 모드로 실행되어 개발 흐름을 방해하지 않도록 하되, 별도의 대시보드를 통해 지속적으로 모니터링되고 수정되도록 관리해야 한다.
| 전략 | 구체적 실행 방안 | 기대 효과 |
|---|---|---|
| 환경 격리 | 컨테이너화된 테스트 런타임 및 인메모리 DB 사용 | 환경 전이로 인한 플래키 제거 |
| 비결정성 제어 | 난수 생성기 및 모델 시드(Seed) 고정, 타임 스탬프 모킹 | 로직 내부의 확률적 요소 억제 |
| 지능적 대기 | sleep() 대신 명시적 폴링(Explicit Polling) 사용 | 타이밍 및 경쟁 상태 해결 |
| 격리 관리 | 플래키 테스트 점수(Flakiness Score) 도입 및 자동 격리 | 파이프라인 신뢰도 즉시 회복 |
AI가 소프트웨어를 작성하고 검증하는 시대에 플래키 테스트는 더 이상 단순한 기술적 오류가 아니다. 이는 우리가 구축한 자동화된 신뢰 체계가 시험대에 올랐음을 의미한다. 비결정론적인 AI의 특성을 이해하고, 이를 통제할 수 있는 결정론적 오라클을 설계하는 것만이 CI/CD의 가치를 복원하고 지속 가능한 소프트웨어 개발을 가능하게 할 것이다.
6. 참고 자료
- Flaky Tests in Automation: Strategies for Reliable Automated Testing - Ranorex, https://www.ranorex.com/blog/flaky-tests/
- Flaky Tests - How to Get Rid of Them - testRigor AI-Based Automated Testing Tool, https://testrigor.com/blog/flaky-tests/
- Flaky Tests: The Silent Productivity Killer - Viral Patel, https://viral-patel.kit.com/posts/flaky-tests-the-silent-productivity-killer
- Non-determinism in AI: Why answers may vary | Equal Experts, https://www.equalexperts.com/blog/data-ai/non-determinism-in-ai-why-answers-may-vary/
- Why Temperature=0 Doesn’t Guarantee Determinism in LLMs | Michael Brenndoerfer, https://mbrenndoerfer.com/writing/why-llms-are-not-deterministic
- The Challenges of Testing in a Non-Deterministic World - Software Engineering Institute, https://www.sei.cmu.edu/blog/the-challenges-of-testing-in-a-non-deterministic-world/
- Test Flakiness: The Silent Killer of Engineering Trust - DEV Community, https://dev.to/dmytro_huz/test-flakiness-the-silent-killer-of-engineering-trust-5h0l
- Why Does My LLM Have A Temperature? - Nigel Gebodh, https://ngebodh.github.io/projects/Short_dive_posts/LLM_temp/LLM_temp.html
- Defeating Nondeterminism in LLM Inference - Thinking Machines Lab, https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/
- LLM Temperature: How It Works and When You Should Use It - Vellum, https://www.vellum.ai/llm-parameters/temperature
- Temperature and Softmax (LLMs) - Iz’s Morning Notes - Obsidian Publish, https://publish.obsidian.md/iz/Learning/AI/Temperature+and+Softmax+(LLMs)
- Non-Determinism of “Deterministic” LLM System … - ACL Anthology, https://aclanthology.org/2025.eval4nlp-1.12.pdf
- Why AI won’t save your Flaky Tests - The Testing Pirate, https://thetestingpirate.be/posts/2026/2026-01-28_whyaiwontsaveyourflakytests/
- On the Flakiness of LLM-Generated Tests for Industrial and Open-Source Database Management Systems - arXiv, https://arxiv.org/html/2601.08998v1
- On the Flakiness of LLM-Generated Tests for Industrial and Open-Source Database Management Systems - arXiv, https://www.arxiv.org/pdf/2601.08998
- On the Flakiness of LLM-Generated Tests for Industrial and Open-Source Database Management Systems - ResearchGate, https://www.researchgate.net/publication/399776947_On_the_Flakiness_of_LLM-Generated_Tests_for_Industrial_and_Open-Source_Database_Management_Systems
- Do Automatic Test Generation Tools Generate Flaky Tests? | Request PDF - ResearchGate, https://www.researchgate.net/publication/378022252_Do_Automatic_Test_Generation_Tools_Generate_Flaky_Tests
- [Literature Review] Can We Classify Flaky Tests Using Only Test …, https://www.themoonlight.io/review/can-we-classify-flaky-tests-using-only-test-code-an-llm-based-empirical-study
- Why flaky tests are increasing, and what you can do about it - SD Times, https://sdtimes.com/bitrise/why-flaky-tests-are-increasing-and-what-you-can-do-about-it/
- Top 17 CI/CD Metrics Every DevOps Team Should Track - Axify, https://axify.io/blog/ci-cd-metrics-devops
- 27 Continuous Integration Metrics for Software Delivery - TestRail, https://www.testrail.com/blog/continuous-integration-metrics/
- CI/CD Pipeline Metrics — How to Measure the Success of Your Release Process, https://refraction.dev/blog/cicd-pipeline-metrics-measure-success
- The Hidden Costs of Flaky Tests: A Deep Dive into Test Reliability | StickyMinds, https://www.stickyminds.com/article/hidden-costs-flaky-tests-deep-dive-test-reliability-0
- “It’s Just A Flaky Test”: The Most Expensive Lie in Engineering | by …, https://medium.com/@ran.algawi/its-just-a-flaky-test-the-most-expensive-lie-in-engineering-4b18b0207d96
- Flaky Test Detection Mastery: Your CI Pipeline Success Guide, https://blog.mergify.com/flaky-test-detection/
- Best Practices for Identifying and Mitigating Flaky Tests - Semaphore CI, https://semaphore.io/blog/flaky-tests-mitigation
- Strategies for Mitigating Flaky Tests in Automated Environments - ResearchGate, https://www.researchgate.net/publication/378977416_Strategies_for_Mitigating_Flaky_Tests_in_Automated_Environments
- A practical guide to reducing the burden of flaky tests - Rainforest QA Blog, https://www.rainforestqa.com/blog/flaky-tests
- What Is A Flaky Test How To Detect Fix & Avoid Them - Netdata, https://www.netdata.cloud/academy/flaky-tests/
- 8 Effective Strategies for Handling Flaky Tests - Codecov, https://about.codecov.io/blog/effective-strategies-for-handling-flaky-tests/
- Flaky Tests in Software Testing: How to Identify, Fix, and Prevent Them - TestRail, https://www.testrail.com/blog/flaky-tests/
- Test Automation 2030: Rethinking Test-Pyramid Strategies for the AI-Era | Keploy Blog, https://keploy.io/blog/technology/future-of-test-automation-in-ai-era