Proven by Intelligence
보이지 않는 안전을 인텔리전스로 증명하다.
기술 인사이트를 만나보세요.
어제는 실패했는데 오늘은 성공했다? 우리가 무심코 지나치는 Flaky Test 이야기
CI 파이프라인의 빌드 결과를 확인하던 어느 날, 테스트 하나가 실패했습니다.
개발자는 로그를 열어보고 최근 변경 사항을 확인합니다. 코드를 다시 살펴보고, 재현을 위해 테스트를 한 번 더 실행해 봅니다.
그런데 이번에는 PASS.
'방금은 왜 실패한 거지?'
'일시적인 문제였나?'
'환경이 잠깐 안 좋았던 건가?'
결국 명확한 원인을 찾지 못한 채 넘어가는 경우가 많습니다. 아마 많은 개발자와 테스트 엔지니어들이 한 번쯤은 이런 경험을 해보셨을 것입니다.
재실행하면 통과하는 테스트
다음과 같은 테스트 결과를 생각해 봅시다.
Build #101 : PASS
Build #102 : FAIL
Build #103 : PASS
Build #104 : PASS
Build #105 : FAIL
동일한 코드인데 어떤 날은 성공하고, 어떤 날은 실패합니다. 심지어 같은 코드를 바로 다시 실행했는데 결과가 바뀌기도 합니다.
이런 상황이 반복되면 개발자는 점점 테스트 결과를 신뢰하지 않게 됩니다. 그리고 어느 순간부터 팀에는 'FAIL 떴네? 한 번 더 돌려보자.'라는 문화가 자리 잡기 시작합니다.
이런 테스트에는 이름이 있다
소프트웨어 테스트 분야에서는 이러한 현상을 Flaky Test라고 부릅니다.
Flaky Test는 일반적으로 '동일한 코드와 동일한 환경에서 실행했음에도 테스트 결과가 PASS와 FAIL 사이를 오가는 테스트'로 정의됩니다.
테스트 결과가 결정적이지 않고 실행할 때마다 달라지기 때문에, 개발자는 무엇이 진짜 문제인지 판단하기 어려워집니다.
단순히 귀찮은 문제일까?
처음에는 단순히 '가끔 실패하는 테스트' 정도로 생각할 수 있습니다. 하지만 Flaky Test는 생각보다 큰 비용을 발생시킵니다.
• 원인을 찾기 위한 불필요한 디버깅 시간
• CI 결과에 대한 신뢰 저하
• 개발자의 집중력 저하
• 테스트 실패에 대한 무감각
무엇보다 위험한 점은, 실제 결함이 발생했는데도 '또 그 테스트가 가끔 실패하는 거겠지.'라고 생각하며 지나칠 수 있다는 것입니다.
테스트가 신뢰를 잃기 시작하면, 테스트는 더 이상 품질을 보장하는 안전망 역할을 하기 어려워집니다.
그래서 업계도 Flaky Test를 주목하기 시작했다
최근에는 대규모 CI/CD 환경을 운영하는 많은 기업들이 Flaky Test를 중요한 품질 문제로 인식하고 있습니다.
테스트가 수천, 수만 개에 이르는 환경에서는 작은 비율의 Flaky Test만 존재하더라도 개발 생산성과 릴리즈 품질에 상당한 영향을 미칩니다. 개발자는 실제 결함을 분석하는 시간보다 테스트의 신뢰성을 판단하는 데 더 많은 시간을 사용하게 되며, 잦은 오탐(False Positive)은 CI 시스템에 대한 신뢰를 떨어뜨립니다.
실제로 학계와 산업계에서는 Flaky Test를 탐지하고 관리하기 위한 다양한 연구와 기법들이 제안되고 있으며, 이를 소프트웨어 품질을 저해하는 중요한 요소 중 하나로 보고 있습니다.
다음 글에서는…
이번 글에서는 '재실행하면 통과하는 테스트'라는 익숙한 현상과, 이를 Flaky Test라고 부른다는 사실을 간단히 소개했습니다.
그렇다면 이런 테스트는 왜 발생하는 걸까요?
단순히 환경 문제일까요? 아니면 우리 코드 어딘가에 숨어 있는 버그의 신호일까요?
다음 글에서는 Flaky Test가 발생하는 대표적인 원인과 실제 사례를 살펴보며, 왜 많은 기업들이 이 문제를 중요하게 다루는지 조금 더 자세히 알아보겠습니다.
MDS인텔리전스는 다양한 산업군에서의 오랜 경험을 바탕으로 검증된 솔루션과 소프트웨어 검증 서비스를 제공하고 있습니다.
검증 도구 도입 또는 컨설팅이 필요하다면 아래로 문의해 주시기 바랍니다.
📧 swtest@mdsit.co.kr ✍️ 문의남기기
