개념
"자동화 테스트가 많을수록 좋다"는 틀린 말이다
자동화 테스트 개수 자체를 목표로 삼으면, 모듈 6(레슨 5)에서 배운 "지표를 목표로 삼을 때의 왜곡"이 그대로 재현된다. 자동화 테스트도 결국 코드다 — 코드가 늘어날수록 유지보수해야 할 대상도 늘어난다. 이 유지보수 비용이 자동화가 주는 가치를 넘어서는 순간, 자동화는 자산이 아니라 부채가 된다.
자동화 부채의 신호
1. 실패해도 아무도 원인을 안 본다
"어차피 그 테스트는 원래 가끔 실패해요"라는 말이 팀 안에서 당연하게 받아들여진다면, 모듈 7(레슨 3)에서 배운 플래키 테스트가 누적되어 팀이 자동화 결과 자체를 신뢰하지 않게 된 것이다. 이 상태가 되면 자동화는 안전망 역할을 완전히 상실한다.
2. 기능 하나를 바꿀 때마다 테스트 10개가 깨진다
모듈 10(레슨 6)에서 배운 컴포넌트 테스트 원칙(사용자 관점 vs 구현 세부사항)을 어기고 내부 구현에 강하게 의존한 테스트가 많으면, 아주 작은 변경에도 관련 없는 테스트가 무더기로 깨진다. 이러면 개발자가 "테스트 통과시키기"에 더 많은 시간을 쓰게 되어, 자동화가 개발 속도를 오히려 늦춘다.
3. 전체 실행 시간이 너무 길어져 아무도 로컬에서 안 돌린다
자동화 스위트 실행에 1시간 넘게 걸리면, 개발자들은 로컬에서 돌려보지 않고 그냥 커밋해버린다. 결국 문제를 CI에서야(모듈 14에서 다룬다), 그것도 다른 사람이 이미 그 위에 코드를 더 쌓은 뒤에야 발견하게 된다.
4. 아무도 그 테스트가 왜 있는지 모른다
작성한 사람이 퇴사하거나 오래돼서, "이 테스트가 지금도 유효한 검증을 하고 있는지" 아무도 확신하지 못하는 테스트가 쌓이면, 그냥 "지우면 뭔가 잘못될까 봐" 냅두는 죽은 코드가 된다.
부채를 줄이는 방향
- 정기적으로 가지치기(Pruning)한다: 더 이상 의미 없는 테스트, 중복된 테스트를 주기적으로 찾아 삭제한다
- 플래키 테스트를 방치하지 않는다: 모듈 10(레슨 4)에서 배운 비결정적 요소 통제 원칙을 적용해 원인을 고치거나, 못 고치면 과감히 삭제한다
- 사용자 관점 테스트 원칙(모듈 10 레슨 6)을 지킨다: 구현 세부사항에 의존하지 않으면, 리팩터링해도 불필요하게 깨지지 않는다
- 자동화 피라미드(레슨 1)를 지킨다: 상위 계층(E2E)에 과도하게 쏠리지 않게 관리한다
자산과 부채는 계속 바뀐다
레슨 3에서 계산한 ROI가 처음엔 양수였더라도, 시간이 지나 기능이 크게 바뀌거나 팀 구성이 바뀌면 그 자동화 테스트의 가치가 달라질 수 있다. 자동화는 "한 번 만들면 끝"이 아니라, 꾸준히 관리해야 자산으로 유지되는 대상이라는 인식이 필요하다.
실무에서 왜 필요한가
"우리 팀은 자동화 테스트가 500개나 있어요"라는 말이 곧 좋은 신호는 아니다. QA가 자동화 부채의 신호를 알아볼 수 있으면, 팀에 "테스트 개수를 더 늘리기 전에, 지금 있는 것부터 정리하자"는 건설적인 제안을 할 수 있다. 이건 모듈 7(레슨 6)에서 배운 프로세스 개선 관점을, 자동화 자산 관리라는 구체적인 영역에 적용하는 것이다.
실습 과제
과제 1 — 부채 신호 진단하기 (10분)
다음 상황이 자동화 부채의 어떤 신호에 해당하는지 짚어본다.
"이번 스프린트에 버튼 하나의 CSS 클래스 이름을 바꿨을 뿐인데, 자동화 테스트 15개가 한꺼번에 실패했다. 알고 보니 그 클래스 이름으로 요소를 찾는 테스트가 여러 개였다."
과제 2 — 개선 제안하기 (10분)
과제 1의 상황을 개선하려면 어떤 조치를 제안할 수 있을지, 이 레슨에서 배운 "부채를 줄이는 방향" 중 관련된 것을 골라 구체적으로 적는다.
자가 체크리스트
- 자동화 테스트 개수 자체가 목표가 되면 안 되는 이유를 설명할 수 있다
- 자동화 부채의 네 가지 신호를 설명할 수 있다
- 자동화 부채를 줄이는 방향을 제안할 수 있다
- 자동화의 가치가 시간이 지나며 바뀔 수 있다는 것을 이해한다
흔한 실수
- 자동화 테스트 개수를 늘리는 것 자체를 성과로 여긴다. 유지보수 비용까지 고려하지 않은 개수는 의미가 제한적이다.
- 플래키 테스트를 "원래 그런 것"으로 방치한다. 방치할수록 팀이 자동화 결과 자체를 신뢰하지 않게 되는 악순환이 시작된다.
- 오래된 테스트를 삭제하는 것을 두려워한다. 더 이상 의미 없는 테스트를 남겨두는 것도 관리 비용을 계속 발생시킨다.
참고 자료
- Martin Fowler — Test Coverage, Eradicating Non-Determinism in Tests — 자동화 부채와 관련된 대표 아티클
- Gojko Adzic, Specification by Example — 유지보수 가능한 자동화 테스트 설계 원칙을 다룬 저서