테스트 자동화로 밤샘 배포를 끝낸 방법: CI 파이프라인 실전 경험

1. 왜 테스트 자동화를 시작했나

매주 배포가 있던 프로젝트였습니다. 배포 전날 밤마다 수동 테스트 체크리스트를 돌렸고, 이메일로 결과를 공유했습니다. 문제는 같은 실수가 반복된다는 점이었습니다. 이전에 고쳤던 버그가 배포 직후 다시 나타나기도 했고, 수동 테스트는 두 시간 이상 걸리면서도 꼼꼼함을 보장하지 못했습니다. 어느 날 배포 후 장애가 발생했는데, 원인은 체크리스트에 빠져 있던 케이스였습니다. 그날 이후 저는 테스트 자동화를 본격적으로 시작했습니다.

2. 첫 단계: 핵심 로직부터 단위 테스트

처음에는 모든 코드를 테스트하려 했습니다. 하지만 레거시 코드는 테스트가 어려웠고, 시간 대비 효과가 떨어졌습니다. 전략을 바꿔 핵심 비즈니스 로직부터 테스트를 작성했습니다. 주문 계산, 할인 정책, 상태 전환처럼 자주 바뀌면서 장애 영향이 큰 부분을 우선순위로 삼았습니다. 범위를 좁히니 일주일 만에 커버리지가 의미 있는 수준에 도달했습니다. 모든 것을 테스트하는 것이 아니라, 실패했을 때 치명적인 것을 테스트하는 것이 핵심이었습니다. 이 우선순위를 정하는 기준을 팀과 공유하면서, "어디부터 손댈지"에 대한 논쟁도 줄어들었습니다.

테스트를 작성할 때는 Given-When-Then 구조를 따랐습니다. 어떤 조건에서 어떤 행동이 일어나고 어떤 결과가 나오는지를 명확히 적으니, 실패했을 때 어느 지점에서 어긋났는지 바로 보였습니다. 테스트 이름도 한국어로 동작을 서술하듯 지었는데, 시간이 지나면서 이 테스트들이 코드 문서 역할을 톡톡히 해냈습니다. 새로 합류한 개발자가 "이 기능은 어떻게 동작하나요?"라고 물어볼 때마다 테스트 코드를 보여주면 설명이 끝났습니다.

3. CI 파이프라인에 테스트 통합

단위 테스트가 준비되자 CI 파이프라인에 연결했습니다. 풀 리퀘스트가 생성될 때마다 테스트가 자동 실행되도록 설정했습니다. 처음에는 실행 시간이 길어 개발자들의 불만이 있었습니다. 테스트를 병렬로 실행하고, 변경된 모듈과 관련된 테스트를 먼저 돌리는 방식으로 최적화했습니다. 그 결과 테스트 시간이 12분에서 4분으로 줄었고, 개발자들이 로컬에서 테스트를 먼저 돌리는 습관도 생겼습니다. 통합 과정에서 빌드 환경이 로컬과 달라 발생하는 문제도 겪었는데, 컨테이너로 빌드 환경을 통일해 해결했습니다.

4. 실패하는 테스트를 대하는 태도

자동화 초기에는 테스트가 자주 실패했습니다. 그런데 원인을 살펴보면 대부분 코드 문제가 아니라 테스트 자체의 문제였습니다. 특정 환경에 의존하는 테스트, 실행 순서에 영향을 받는 테스트, 날짜에 민감한 테스트가 문제였습니다. 이런 테스트들을 격리하고 의존성을 제거하는 작업을 거쳐 안정적인 테스트 집합을 만들었습니다. 테스트가 안정적으로 돌아가야 개발자들이 테스트를 믿고 유지한다는 것을 배웠습니다. 실패하는 테스트를 무작정 통과시키기보다, 왜 실패했는지 근본 원인을 찾는 시간을 아끼지 않았습니다.

불안정한 테스트가 팀의 신뢰를 얼마나 무너뜨리는지도 직접 겪었습니다. 한 번은 CI에서만 실패하고 로컬에서는 통과하는 테스트 때문에 이틀을 소비했습니다. 원인은 테스트 데이터가 다른 테스트와 공유되면서 생긴 순서 의존성이었습니다. 이후에는 각 테스트가 독립적인 데이터를 쓰도록 강제했고, 실행 순서가 바뀌어도 결과가 같게 만들었습니다. 이 경험을 계기로 '테스트가 실패하면 그것이 곧 버그라고 단정하지 말고, 먼저 테스트 자신부터 의심하라'는 규칙이 팀 안에 생겼습니다.

5. 배포까지 이어진 자동화

테스트가 안정적으로 돌아가자 배포 단계까지 자동화를 확장했습니다. 테스트 통과 시 자동으로 빌드하고 스테이징 서버에 배포하는 흐름을 만들었습니다. 배포 후 스모크 테스트를 실행해 주요 기능이 정상인지 확인했습니다. 이 과정이 자리 잡은 뒤 배포 전날 밤샘 작업이 사라졌습니다. 배포는 평일 오전에 안전하게 진행되었고, 문제가 생기면 자동으로 이전 버전으로 롤백하는 절차도 추가했습니다. 자동화 범위를 늘릴 때마다 한 번에 크게 바꾸지 않고, 확인한 단계를 하나씩 추가해나갔습니다.

6. 마무리: 자동화가 바꾼 개발 문화

테스트 자동화는 단순히 버그를 줄이는 도구가 아니라 개발 문화를 바꿨습니다. 코드를 변경할 때 두려움이 줄었고, 리팩토링이 더 자유로워졌습니다. 신규 개발자가 합류해도 테스트가 안전망 역할을 해 주었습니다. 가장 큰 변화는 신뢰였습니다. 자동화된 테스트가 통과했다는 사실이 배포 결정의 기준이 되었고, 팀은 수동 확인 대신 시스템에 의존하게 되었습니다. 테스트 자동화에 투자한 시간은 결국 더 많은 시간을 돌려받는 투자였습니다.