개발기초 팀에 단위 테스트 자동화 도입하며 겪은 시행착오 (실제로 정착시킨 방법)

ME개발팀 에서는 기능 개발 이후 QA가 수동으로 전체를 확인하는 방식으로만 검증이 이루어지고 있었습니다. 배포할 때마다 회귀 버그가 반복되면서, 단위 테스트를 도입하기로 했습니다. 도입 자체보다 팀에 정착시키는 과정이 훨씬 어려웠던 경험을 정리해보겠습니다.

상황: 왜 테스트 자동화가 필요했나

결제 로직 을 수정했는데, 관련 없어 보이던 다른 기능이 함께 깨지는 일이 있었습니다. QA가 매번 전체를 다 확인할 수 없다 보니 이런 회귀 버그가 운영 단계에서 발견되는 일이 반복됐습니다.

문제 1: 어디부터 테스트를 짜야 할지 막막했다

기존 코드에는 테스트가 거의 없었고, 코드 자체도 테스트하기 어려운 구조([함수 하나에 여러 책임이 섞여 있는])로 짜여 있었습니다.

해결: 전체 코드에 테스트를 붙이려 하지 않고, 버그가 자주 발생했던 영역 부터 우선순위를 정해 좁혀서 시작했습니다. 테스트하기 어려운 구조의 코드는 테스트를 짜는 과정에서 자연스럽게 함수를 분리하게 됐고, 오히려 코드 구조 개선에도 도움이 됐습니다.

문제 2: 테스트 작성 시간이 부담스럽다는 팀원 반발이 있었다

일정이 빠듯한 상황에서 테스트 코드까지 작성하라고 하니, 팀원들 사이에서 "일정이 더 늘어난다"는 불만이 나왔습니다.

대응: 처음부터 모든 코드에 테스트를 강제하지 않고, 신규로 작성하는 핵심 로직에 한해서만 테스트를 필수로 정했습니다. 또한 테스트 덕분에 회귀 버그를 미리 잡아낸 사례가 생길 때마다 팀에 공유해서, "테스트 때문에 느려진다"가 아니라 "테스트 덕분에 나중에 덜 고생한다"는 인식을 만들어가려고 했습니다.

문제 3: 테스트는 통과하는데 실제로는 의미 없는 테스트였다

일부 테스트 코드를 리뷰하다 보니, 테스트를 통과시키기 위해 형식적으로만 작성된 코드들이 보였습니다. 실제로는 버그를 못 잡는 테스트였습니다.

해결: 테스트 코드도 일반 코드처럼 코드 리뷰 대상에 포함시켜서, "이 테스트가 실제로 어떤 상황을 검증하는지" 리뷰어가 함께 확인하도록 했습니다. 이후로는 형식적인 테스트가 눈에 띄게 줄었습니다.

마무리하며

테스트 자동화를 도입하면서 느낀 건, 테스트 코드는 도구를 도입한다고 저절로 좋아지는 게 아니라, 팀이 테스트의 필요성에 공감하고 습관으로 만들어가는 과정이 핵심이라는 점이었습니다. 처음엔 반발도 있었지만, 실제로 회귀 버그가 줄어드는 걸 팀이 체감하면서 자연스럽게 자리 잡았습니다.

아직 테스트 코드 없이 운영되고 있는 프로젝트를 맡고 계신다면, 전체를 다 커버하려 하지 마시고 가장 자주 문제가 생기는 영역부터 좁혀서 시작해보시는 걸 추천합니다.