CI/CD 파이프라인이 실패하여 급히 확인했지만, 아무것도 고치지 않고 다시 실행하니 이번엔 성공합니다. 이처럼 코드 변경 없이도 실행할 때마다 성공과 실패를 오가는 변덕스러운 테스트가 바로 ‘플레이키 테스트(Flaky Test)’입니다.
이는 단순히 가끔 실패하는 테스트가 아닙니다. 플레이키 테스트는 ‘테스트 자동화’ 시스템 전체에 대한 팀의 신뢰를 파괴하는, 가장 위험한 적입니다.
Q. ‘플레이키 테스트’, 정확히 무엇인가요?
동일한 코드와 환경에서 실행함에도 불구하고, 어떤 때는 성공하고 어떤 때는 실패하는 ‘비결정론적인’ 테스트를 의미합니다.
Q. 왜 플레이키 테스트가 일반적인 버그보다 더 나쁜가요?
팀의 ‘신뢰’를 무너뜨리기 때문입니다.
- 무시: 개발자들은 “아, 또 플레이키 때문이겠지” 라고 생각하며 테스트 실패 알림을 무시하기 시작합니다.
- 위험: 진짜 심각한 버그가 플레이키 테스트 뒤에 숨어, 아무도 모르게 배포될 수 있습니다.
- 효율 저하: CI/CD 파이프라인의 의미가 퇴색되고, 자동화 테스트가 없는 것만 못한 상태가 됩니다.
Q. [원인 1] 가장 흔한 원인, ‘타이밍 문제’란 무엇인가요?
테스트 코드가 웹페이지의 ‘비동기 로딩’ 속도를 기다려주지 못해 발생하는 문제입니다.
- 비유:
- 성급한 사람이, 팝콘이 다 튀겨지기도 전에 전자레인지 문을 열어버리는 것과 같습니다. 어떨 땐 팝콘 몇 개가 튀겨져 있지만(성공), 어떨 땐 아닐 수 있습니다(실패).
- 상세 설명:
- 현대 웹은 페이지가 표시된 후에도 백그라운드에서 계속 데이터를 불러옵니다. 테스트 코드가 ‘주문하기’ 버튼을 클릭하려는데, 아직 서버에서 가격 정보를 불러오는 중이라 버튼이 비활성화 상태이면 테스트는 실패합니다. 다음 실행에서 네트워크가 조금 더 빠르면, 테스트는 성공할 수 있습니다.
Q. [원인 2] ‘테스트 데이터 오염’이란 무엇인가요?
이전 테스트가 남긴 데이터가 다음 테스트에 영향을 주어 발생하는 문제입니다.
- 상황 예시:
- 테스트 A: ‘user01’ 아이디로 회원가입을 시도한다. (성공)
- 테스트 B: ‘user01’ 아이디로 회원가입을 시도한다. (실패 – 이미 존재하는 아이디)
- 문제점:
- 위 두 테스트를 순서대로 실행하면 B는 항상 실패하지만, B만 단독으로 실행하면 성공합니다. 이처럼 테스트 실행 순서에 따라 결과가 달라지는 것이 ‘데이터 오염’으로 인한 플레이키 테스트입니다.
Q. 그렇다면 ‘플레이키 테스트’는 어떻게 해결해야 하나요?
체계적인 전략이 필요합니다.
- 해결책 1: ‘명시적 대기(Explicit Wait)’ 사용하기 (타이밍 문제 해결)
- 나쁜 방법:
sleep(3)처럼 무작정 3초를 기다리는 코드. 네트워크가 3초보다 느리면 실패합니다. - 좋은 방법: “이 버튼이 ‘클릭 가능한 상태’가 될 때까지, 최대 10초 동안 기다려라” 와 같이 명확한 ‘조건’을 설정하여 기다리는 것입니다.
Selenium과Playwright모두 이 기능을 강력하게 지원합니다.
- 나쁜 방법:
- 해결책 2: ‘테스트 격리(Test Isolation)’ 지키기 (데이터 오염 해결)
- 원칙: 모든 테스트는 실행 전에 필요한 데이터를 스스로 만들고(Setup), 실행 후에는 그 데이터를 깨끗하게 지워야 합니다(Teardown).
- 효과: 이를 통해 각 테스트는 다른 테스트의 영향을 받지 않는 독립적인 섬이 되어, 항상 동일한 조건에서 실행될 수 있습니다.
- 해결책 3: ‘재시도(Retry)’와 ‘격리(Quarantine)’로 관리하기
- 재시도: 네트워크 오류처럼 정말 간헐적인 문제에 대비해, 실패 시 한두 번만 자동으로 재시도하도록 설정합니다. (단, 남용하면 근본적인 문제를 숨길 수 있어 주의해야 합니다.)
- 격리: 원인 분석에 시간이 걸리는 플레이키 테스트는 즉시 메인 파이프라인에서 제외하고(‘격리’ 공간으로 이동), CI/CD 파이프라인의 신뢰도를 먼저 확보한 뒤, 담당자를 배정하여 수정하도록 관리합니다.
결론: 안정적인 테스트가 신뢰를 만든다
플레이키 테스트는 운이 나빠서 발생하는 현상이 아닌, 해결해야 할 명확한 기술적 문제입니다.
타이밍, 데이터, 환경 등 발생 원인을 체계적으로 분석하고, 그에 맞는 해결책을 적용하여 ‘안정적인 테스트’ 환경을 구축하는 것. 이것이야말로 팀원 모두가 신뢰할 수 있는 ‘테스트 자동화’와 건강한 CI/CD 문화를 만드는 가장 중요한 기반입니다.