테스트 코드 파워리프팅
왕관을 쓰려는 자, 그 무게를 견뎌라아름다운 코드와 즐거운 개발을 위한 테스트 주도 개발
켄트 벡의 테스트 주도 개발(Test-Driven Development : By Example) 책의 뒤표지에 적혀있는 문구이다.
정말 운이 좋게도 직장생활에서 테스트 커버리지 100% 인 개발환경을 경험할 수 있었다. 켄트 백(또는 역자)의 말처럼 나에게 해당 시기는 조금 더 아름다운 코드와 조금 더 즐거운 개발을 경험하게 해 준 시기였다. [1]
제목에 이미 나와있지만 내가 생각하기에 테스트 커버리지 100% 환경은 마치 여러 운동 중 엄청난 고중량 무게를 드는 파워리프팅과 통하는 지점이 많다고 생각한다. 과거의 나의 경험을 회고해 보면서 왜 그런 생각을 가지게 되었는지 좀 더 상세히 설명해 보겠다.
서버 개발자로 턴어라운드 하고 팀에서 온보딩을 받는 중 우리 팀의 테스트 코드 커버리지가 100% 로 관리되고 있다는 사실을 알게 되었을 때의 첫 느낌은 마치 힘 좀 꽤나 쓰는 일반인이 파워리프팅 선수를 처음 보았을 때 '사람의 몸으로 저 정도의 무게를 지탱하는 게 가능한 걸까?'라고 생각한 부분과 가장 유사했던 것 같다. 내가 팀을 조인하던 시점에는 서비스 오픈을 위한 많은 부분이 개발되어 있지 않았음에도 불구하고 테스트의 개수는 무려 1500개에 육박했고 이를 유지하기 위해 테스트 수행 속도등을 늘리기 위한 여러 방법들이 이미 적용되어 있었다. [2]
팀에 적응해 개발을 진행하고 그에 따른 테스트를 작성하기 시작하면서 때로는 '이렇게 까지 해야 하나?' 싶은 지점들도 분명 존재하였다. 재미있었던 점은 마치 운동할 때 같은 자세를 하더라도 서로 다른 부분에 어려움을 느끼는 것처럼 테스트 코드 작성에서도 팀원들 개개인이 어려움이나 불편함을 느끼는 지점이 전부 달랐다는 점이다. 그럼에도 불구하고 팀에서 테스트를 계속 잘 관리할 수 있었던 비결은 팀원들 개개인이 느낀 문제들을 지나치지 않고 다른 팀원들과 공유하며 테스트와 관련된 팀 내부의 컨센서스를 주도적으로 만들어 갔기 때문이라고 생각한다.
그중에서도 내가 느꼈던 가장 어려운 점 중 하나는 테스트 코드 유지보수에 대한 부분이었다. 높은 수준의 테스트 커버리지를 관리하다 보니 유사한 테스트 수트들이 생겨나고 같은 비즈니스 로직에 대한 테스트가 중복적으로 생기는 것을 막기 어려웠다. 그렇다고 테스트 코드에서의 중복을 제거하기 위해 더 작은 컴포넌트 단위로 테스트를 작성하면 리팩토링 내성이 떨어지는 문제점에 직면하였다.
위와 같은 경험을 통해 나는 테스트 코드 또한 비즈니스를 관리하는 코드라는 생각을 하게 되었다. 그렇기 때문에 테스트 코드를 작성할 때도 비즈니스 코드를 작성할 때처럼 적절한 경계 설정과 일련의 원칙들을 지키면서 작성해야 한다는 신념도 가질 수 있게 되었다. [3]
시간이 조금 더 지나 서비스 오픈 직전에는 테스트가 3천 개 정도로 증가하였다. 고중량을 들수록 운동량이 커지는 상관관계처럼 테스트 코드는 팀에서 관여하고 있는 비즈니스 로직이 많고 복잡함을 의미하는 하나의 지표가 되어주기도 하였다.
서비스 오픈 이후에는 급격히 밀려들어오는 CS와 촉각을 다투는 버그 수정으로 인해 눈코 뜰 새 없이 바쁜 나날들의 연속이었다. 그래도 촘촘히 작성된 테스트 덕분에 본인이 작성하지 않은 비즈니스 코드도 비교적 빠르게 이해하고 대응할 수 있었던 점이 큰 다행이었다. 또한 타인의 코드를 수정하면서도 높은 커버리지로 인한 배포 자신감은 나에게 심적으로 특히 큰 도움이 되었다.
하지만 그 무렵 높은 커버리지로도 해결하기 어려운 지점들을 많이 발견하기도 하였다. 요구사항과 다르게 작성된 비즈니스/테스트 코드라던지 시스템에서 간헐적으로 발생하는 문제나 현실적으로 테스트하기 굉장히 어려운 지점 등이 그중 일부였다.
다행히도 팀은 해당 문제점에 단순히 순응하지 않고 새로운 정답들을 찾아나가기 시작했다. 마치 정상급 파워리프팅 선수들이 단순히 고중량의 운동만을 고집하지 않고 다른 기능성 운동들과 해부학적 지식을 습득하는 것과 유사하게 여러 컴포넌트들을 관통하면서 시나리오가 잘 작동하는지 확인하기 위한 e2e 테스트 환경을 구축하기도 하고 테스트하기 어려운 코드 등을 해소하기 위한 방법들이 새롭게 서버에 적용되었다.
오픈 직후 바쁜 시점을 갓 넘길 때쯤 회사의 성장에 따라서 새로운 팀원들이 팀에 더 많이 합류하기 시작했고 기존의 팀원들 중 많은 인원들이 새로운 일들을 하기 위해 다른 팀으로 이동하게 되었다. 자연스럽게 내가 남은 팀원들 중에서는 히스토리를 가장 잘 아는 팀원이 되어버린 까닭에 그 시점부터는 테스트 이외에도 더 많이 비즈니스의 많은 측면에 관여하게 되어 현실적으로 테스트의 전체적인 구조를 크게 개선하지는 못했던 것 같다.
그래도 다행인 점은 당시 서버를 더 작은 도메인의 서버로 분리하는 과정을 경험했음에도 커버리지 100% 환경을 유지할 수 있었다는 점이었다. 지금 생각해 보면 커버리지 100% 환경이 있었기 때문에 더 작은 도메인의 서버로 분리하는 과정을 빠르게 수행할 수 있었다고 생각한다.
테스트 커버리지 100% 환경에 대한 경험이 어느 정도 좋았던 만큼 새로운 환경에 놓인다면 내 손으로 테스트 커버리지 100% 환경을 다시 구축해보고 싶은 생각도 있다. 다른 훌륭한 동료분들께 도움을 많이 받은 만큼 이번에는 내 힘으로 다른 구성원들에게 도움을 줄 수 있기를 기대해본다.
[1] 테스트 코드의 이점을 알고 있었음에도 불구하고 직장생활 중의 일부는 테스트 코드와 많이 멀어져 있던 적도 있었다. 당연히 해당 결정을 내리게 된 이유가 있었지만 지금 와서 돌이켜 보면 그리 좋은 선택은 아니었던 것 같다.
[2] 필자를 힘 좀 꽤나 쓰는 일반인 정도로 표현하였지만 지금 생각해 보면 사실 그냥 일반인 정도의 수준이지 않았을까 생각한다. 당시에는 테스트를 많이 작성해보지도 않았고 특히 프로젝트의 전체 테스트 수준을 관리해 본 적은 아예 없었기 때문이다. 그럼에도 불구하고 위와 같이 표현한 이유는 해당시점에 쓸데없는 근자감이 조금은 있었던 것 같은 기억이 어렴풋이 남아있기 때문이다.
[3] 비즈니스 로직을 구현하는 구현부와 테스트하는 테스트부는 서로 적절하게 격리되어야 한다고 생각하는 사람들도 많이 있다. 해당 의견의 근거들도 굉장히 타당하고 생각한다. 하지만 필자는 테스트와 비즈니스 로직 간의 상호작용을 통해서 문제 지점을 발견하고 해소하는 방향을 지향하는 편이라서 위와 같이 서술하였다.
