플래키 테스트가 CI를 망치고 있습니다 – 통과율 대신 실패 신뢰 지표로 전환하세요

테스트 스위트가 아무도 실패 결과를 신뢰하지 않는다면 무용지물입니다. 팀들은 더 많은 테스트, 더 화려한 대시보드, 혹은 병렬 실행을 추가하지만, 개발자들은 여전히 빨간색 박스가 사라지기를 바라며 파이프라인을 재실행합니다. 이러한 습관은 잠재적으로 가치 있는 신호를 비용만 많이 드는 소음으로 변질시킵니다.

진짜 문제는 커버리지가 아니라 신뢰입니다

대부분의 엔지니어링 그룹은 테스트 부족이나 브라우저 커버리지 미흡을 탓합니다. 하지만 실제로는 실패를 소음으로 취급합니다. 대시보드에 표시된 96%의 통과율은 인상적으로 보일 수 있지만, 나머지 4%의 실패가 실제 결함을 잡아낸 것인지, 아니면 단순히 여러 번 재시도해야 겨우 통과된 것인지에 대해서는 아무것도 알려주지 않습니다. 개발자가 실패를 무시할 때, 테스트 스위트는 의사결정에 아무런 영향을 주지 못한 채 시간과 컴퓨팅 리소스만 소비하게 됩니다.

통과율(pass rates)이 오해를 불러일으킬 수 있는 이유

통과율 지표는 모든 결과를 하나의 숫자로 압축하여 다음과 같은 두 가지 중요한 질문을 가립니다.

• 실패가 실제 결함을 드러냈는가? 버그를 전혀 잡지 못하는 불안정한(flaky) 테스트는 아무런 가치가 없습니다.
• 몇 번의 재시도가 필요했는가? 최종 통과율이 높더라도 세 번의 자동 재시도 끝에 통과되는 테스트 스위트는 신뢰할 수 없습니다.

99%의 성공률을 보고하면서 결제 실패를 반복적으로 놓치는 테스트 스위트는, 통과율은 92%에 불과하더라도 수익에 영향을 미치는 모든 버그를 잡아내는 스위트보다 훨씬 나쁩니다. 목표는 높은 수치를 달성하는 것이 아니라, 리스크에 대해 더 나은 판단을 내리는 것입니다.

중요한 지표들

통과율 중심의 사고에서 벗어나 테스트 스위트의 유용성을 반영하는 측정 지표로 전환하십시오.

• 실패 재발률(Failure recurrence) – 동일한 테스트가 연속된 실행에서 얼마나 자주 실패하는지.
• 결함 탐지율(Defect detection rate) – 실패 중 실제 확인된 버그로 이어진 비율.
• 진단 시간(Time to diagnosis) – 실패한 테스트를 얼마나 빨리 이해하고 조치를 취할 수 있는지.
• 재시도 의존도(Retry dependence) – 통과를 위해 자동 재실행이 필요한 테스트의 빈도.
• 누락된 회귀 결함(Escaped regressions) – 테스트 스위트가 있음에도 불구하고 놓친 결함.

이러한 신호들을 추적하면 현재의 실패가 조치를 취할 수 있는 경고인지, 아니면 단순한 노이즈(flake)인지 알 수 있습니다.

유지보수의 숨겨진 비용

작성하는 데 10분이 걸리지만 수정하는 데 한 달에 3시간이 드는 테스트는 나쁜 투자입니다. 테스트가 취약하거나, 지속적인 데이터 업데이트가 필요하거나, 깨지기 쉬운 UI 셀렉터에 의존할 때 유지보수 비용은 급증합니다. AI가 테스트를 생성할 때 이러한 비용 문제는 더욱 극명해집니다. 생성된 테스트가 UI가 바뀔 때마다 깨진다면 생성 속도는 아무런 의미가 없습니다.

AI가 생성한 테스트를 평가할 때는 다음을 질문하십시오.

• 테스트를 수동으로 수정해야 하는 빈도는 어느 정도인가?
• 실패 원인을 얼마나 명확하게 설명하는가?
• 사람이 실패를 수정하기 위해 얼마나 많은 문맥(context) 정보가 필요한가?

만약 답변이 빈번한 인간의 개입을 가리킨다면, 자동화의 이점은 사라집니다.

관찰 가능성(Observability): 실패를 실행 가능한 정보로 만들기

분석하는 데 40분이 걸리는 4,000줄짜리 로그는 로그가 없는 것만큼이나 무용지물입니다. 훌륭한 관찰 가능성은 다음 세 가지 질문에 빠르게 답할 수 있게 해줍니다.

• 테스트가 기대한 결과는 무엇인가?
• 실제로 어떤 일이 일어났는가?
• 근본 원인이 제품 버그인가, 데이터 문제인가, 아니면 인프라 문제인가?

AI 에이전트 테스트에는 더 심층적인 검증이 필요합니다

테스트 대상이 AI 기반 에이전트인 경우, 테스트 통과가 내부 프로세스의 결함을 가릴 수 있습니다. 에이전트가 잘못된 지름길을 택하거나, 잘못된 도구를 선택하거나, 메모리를 제대로 업데이트하지 않고도 정답에 도달할 수 있기 때문입니다. 따라서 신뢰할 수 있는 테스트는 다음 사항을 검증해야 합니다.

• 도구 선택 로직
• 메모리 업데이트 동작
• 오류 발생 후 복구 메커니즘

에이전트가 실패 시나리오에서도 예측 가능한 방식으로 동작할 때에만 그 출력을 신뢰할 수 있습니다.

테스트 유지보수를 제품 개발 작업처럼 다루십시오

불안정한 테스트는 다른 코드와 동일한 엄격함으로 다루십시오.

• 더 이상 비즈니스 가치를 반영하지 않는 테스트는 제거하십시오.
• 빈번한 재시도가 필요한 테스트를 검토하고 리팩터링하십시오.
• 데이터가 깨지기 전에 선제적으로 테스트 데이터를 업데이트하십시오.
• 불안정하거나 리스크가 높은 영역에 대해 명확한 담당자를 지정하십시오.

앞으로 주목해야 할 점

AI 생성 테스트 도구를 주목하십시오. 그 가치는 테스트의 양이 아니라, 수동 수정의 감소와 명확한 실패 설명 능력에 의해 결정될 것입니다.

핵심 요약

테스트 스위트는 유용한 실패를 하나씩 쌓아가며 신뢰를 얻습니다. 실패가 더 이상 유용하지 않게 되면, 테스트를 추가하는 것은 문제를 악화시킬 뿐입니다. 화려한 통과율 수치에서 벗어나 구체적인 리스크 중심 지표로 초점을 옮기고, 관찰 가능성에 투자하며, 테스트 유지보수를 핵심 제품 활동으로 다루십시오. 그 결과, 팀을 소음 속에 빠뜨리는 대신 실제로 의사결정을 가이드하는 더 가볍고 신뢰할 수 있는 자동화 계층을 구축할 수 있습니다.