1. 왜 테스트 자동화를 시작했나
매주 배포가 있던 프로젝트였습니다. 배포 전날 밤마다 수동 테스트 체크리스트를 돌렸고, 이메일로 결과를 공유했습니다. 문제는 같은 실수가 반복된다는 점이었습니다. 이전에 고쳤던 버그가 배포 직후 다시 나타나기도 했고, 수동 테스트는 두 시간 이상 걸리면서도 꼼꼼함을 보장하지 못했습니다. 어느 날 배포 후 장애가 발생했는데, 원인은 체크리스트에 빠져 있던 케이스였습니다. 그날 이후 저는 테스트 자동화를 본격적으로 시작했습니다.
2. 첫 단계: 핵심 로직부터 단위 테스트
처음에는 모든 코드를 테스트하려 했습니다. 하지만 레거시 코드는 테스트가 어려웠고, 시간 대비 효과가 떨어졌습니다. 전략을 바꿔 핵심 비즈니스 로직부터 테스트를 작성했습니다. 주문 계산, 할인 정책, 상태 전환처럼 자주 바뀌면서 장애 영향이 큰 부분을 우선순위로 삼았습니다. 범위를 좁히니 일주일 만에 커버리지가 의미 있는 수준에 도달했습니다. 모든 것을 테스트하는 것이 아니라, 실패했을 때 치명적인 것을 테스트하는 것이 핵심이었습니다.
3. CI 파이프라인에 테스트 통합
단위 테스트가 준비되자 CI 파이프라인에 연결했습니다. 풀 리퀘스트가 생성될 때마다 테스트가 자동 실행되도록 설정했습니다. 처음에는 실행 시간이 길어 개발자들의 불만이 있었습니다. 테스트를 병렬로 실행하고, 변경된 모듈과 관련된 테스트를 먼저 돌리는 방식으로 최적화했습니다. 그 결과 테스트 시간이 12분에서 4분으로 줄었고, 개발자들이 로컬에서 테스트를 먼저 돌리는 습관도 생겼습니다. 통합 과정에서 빌드 환경이 로컬과 달라 발생하는 문제도 겪었는데, 컨테이너로 빌드 환경을 통일해 해결했습니다.
4. 실패하는 테스트를 대하는 태도
자동화 초기에는 테스트가 자주 실패했습니다. 그런데 원인을 살펴보면 대부분 코드 문제가 아니라 테스트 자체의 문제였습니다. 특정 환경에 의존하는 테스트, 실행 순서에 영향을 받는 테스트, 날짜에 민감한 테스트가 문제였습니다. 이런 테스트들을 격리하고 의존성을 제거하는 작업을 거쳐 안정적인 테스트 집합을 만들었습니다. 테스트가 안정적으로 돌아가야 개발자들이 테스트를 믿고 유지한다는 것을 배웠습니다.
5. 배포까지 이어진 자동화
테스트가 안정적으로 돌아가자 배포 단계까지 자동화를 확장했습니다. 테스트 통과 시 자동으로 빌드하고 스테이징 서버에 배포하는 흐름을 만들었습니다. 배포 후 스모크 테스트를 실행해 주요 기능이 정상인지 확인했습니다. 이 과정이 자리 잡은 뒤 배포 전날 밤샘 작업이 사라졌습니다. 배포는 평일 오전에 안전하게 진행되었고, 문제가 생기면 자동으로 이전 버전으로 롤백하는 절차도 추가했습니다.
6. 마무리: 자동화가 바꾼 개발 문화
테스트 자동화는 단순히 버그를 줄이는 도구가 아니라 개발 문화를 바꿨습니다. 코드를 변경할 때 두려움이 줄었고, 리팩토링이 더 자유로워졌습니다. 신규 개발자가 합류해도 테스트가 안전망 역할을 해 주었습니다. 가장 큰 변화는 신뢰였습니다. 자동화된 테스트가 통과했다는 사실이 배포 결정의 기준이 되었고, 팀은 수동 확인 대신 시스템에 의존하게 되었습니다. 테스트 자동화에 투자한 시간은 결국 더 많은 시간을 돌려받는 투자였습니다.