1.4.5 Flaky Test(성공과 실패가 오락가락하는 테스트)의 급증과 CI/CD 신뢰도 하락

지속적 통합 및 배포(CI/CD, Continuous Integration/Continuous Deployment) 파이프라인은 현대 소프트웨어 공학의 심장이다. 하루에도 수십 번씩 코드가 병합(Merge)되는 환경에서, CI/CD의 생명력은 테스트 결과에 대한 개발자의 **‘절대적인 신뢰’**에 기반한다.

테스트가 붉은색(Fail)으로 표시된다면 코드가 망가진 것이고, 녹색(Pass)이라면 코드가 완벽한 것이다. 이 명료한 이분법이 무너지면 파이프라인 전체가 무너지게 되며, AI의 비결정성(Nondeterminism)이 야기하는 가장 파괴적인 결과가 바로 ’플래키 테스트(Flaky Test)’의 창궐이다.

1. 코드 변경 없는 테스트 실패의 당혹감

플래키 테스트란 소스 코드 시스템이나 실행 환경에 어떠한 변경도 일어나지 않았음에도 불구하고, 동일한 테스트 코드가 실행될 때마다 성공과 실패를 무작위로 오가는 현상을 말한다.

• 거대 언어 모델(LLM)을 컴포넌트로 사용하는 시스템에서는, 모델 파라미터(예: Temperature)를 아무리 제어하더라도 샘플링의 연속적인 확률 분포 특성 탓에 출력 텍스트가 미세하게 변형된다.
• 전통적인 정규표현식(Regex)이나 문자열 단위 비교(String Matching)로 작성된 기존의 테스트 스크립트들은, AI가 “예, 취소해 드리겠습니다.“를 “네, 취소 처리 해드릴게요.“라고 미세하게 뉘앙스를 바꾸는 순간 무자비하게 Fail을 격발한다.
• 개발자는 자신이 짠 로직과 아무런 상관이 없는 언어 모델의 ‘기분 변화’ 때문에 실패한 파이프라인을 조사하는 데 막대한 시간을 허비하게 된다.

2. “다시 돌려봐” 신드롬과 테스트 무용론

CI 파이프라인에서 플래키 테스트가 전체 테스트 스위트의 단 5%만 차지해도 그 파괴력은 시스템 전체로 퍼져나간다. 엔지니어들은 테스트가 실패하면 코드를 분석하는 대신, **“재시도(Retry) 버튼을 한 번 더 눌러보라”**는 안일한 대처를 학습하게 된다.

1. 신뢰의 붕괴: 두 번 다시 돌려서 통과되는 테스트라면, 그 테스트는 시스템의 안정성을 대변하는 것이 아니라 단순한 ’확률 게임’에 불과해진다.
2. 진짜 버그의 은폐: 플래키 테스트가 일상화된 파이프라인에서는, 실제 치명적인 비즈니스 로직의 버그가 발생하여 붉은 불이 켜져도 개발자들은 이를 “또 LLM이 이상하게 대답했겠지“라고 치부하며 경고를 무시(Ignore)해 버린다. 마치 양치기 소년의 거짓말처럼, 진짜 위기가 닥쳤을 때 안전망이 작동하지 않게 되는 것이다.

3. 결정론적 오라클(Deterministic Oracle)의 공학적 필연성

이러한 신뢰도의 추락은 AI 시스템 자체를 상용화 불가능하게 만드는 데스 밸리(Death Valley)다. AI 애플리케이션의 테스트 파이프라인에서 플래키 테스트를 박멸하기 위해서는, 근본적으로 테스트의 채점 방식이 바뀌어야 한다.

모델이 내뱉는 수만 가지 확률적 텍스트 표면에 집착하는 단순 문자열 비교 테스트를 모두 폐기하고, 그 내면에 담긴 ’의미(Semantics)’와 ’구조(Structure)’의 참/거짓만을 판별하는 확정적 기준 타워(즉, 오라클)를 굳건히 세워야 한다. AI가 자유롭게 말하도록 내버려 두되, 그 결과물을 채점하는 심판만큼은 기계적이고 자비 없는 수학적 룰로 무장해야만 CI/CD의 녹색불에 잃어버린 신뢰를 되찾을 수 있다.