내가 회사에서 테스트 커버리지를 신경썼던 이유
1 
이번 포스팅에서는 우리가 매일 작성하기 귀찮아하는 테스트 코드의 부재가 비즈니스에 미치는 영향에 대해서 필자가 느끼고 고민한 부분들을 공유해보려고 한다.
테스트보다 데드라인 맞추는게 더 중요해.
“테스트보다 데드라인 맞추는게 더 중요해”, 항상 회사에서 새로운 기능을 개발하거나 고칠 때 했던 생각이다. 회사마다 다르겠지만 빠르게 배포 사이클이 돌아가는 필자의 조직같은 경우엔 위와 같은 생각을 하기 쉽다. 근데 한번 돌이켜 보자. 나중이라고 해서 테스트 코드를 작성할 시간이 주어질까?
회사마다 다르겠지만, 필자 회사의 경우는 태스크를 끝내 놓으면 5분만에 이어서 다른 태스크가 들어왔다. 그렇게 하루하루 테스트가 없는 코드가 쌓이다 보면 나중엔 실제로 비즈니스에 상당한 악영향을 끼치는 코드로 돌아온다.
도대체 어떻게 나중에 악영향을 끼친다는걸까? 한번 알아보도록 하자.
음 왜 의존성 배열이 비어있지?
공감가시는 분들이 계실지 모르겠지만, 흔히 React로 된 코드베이스를 보다보면 은근 흔히 발견할 수 있는 Warning이다. 발견되는 비율에 비해 해당 Warning은 상당히 고치기가 쉽지않다.
useEffect 라는 훅은 말그대로 sideEffect에 대한 처리가 필요할 때 사용하는 훅이기 때문에 로직과 의존성간의 연관성을 확실히 알고 있어야 한다. 따라서 까딱 의존성을 잘못 추가했다가 무한 렌더링를 발생 시키거나, 로직이 오동작하기 쉬운 훅이다.
( 사실 필자는 위와 같은 이유로 react 라이프사이클에 의존해야하는 useEffect 같은 훅을 잘 쓰지 않으려고 한다. )
만약 의존성을 추가하였는데 에러가 발생한다면 이는 해당 코드를 개발하던 개발자가 의도한 부분이라는건데, 해당 코드를 작성했던 개발자가 주석도 달지 않았고, 퇴사자라면 어떨까? 더 나아가서 내가 받은 태스크가 저 코드를 건드려야 한다면 어떨까?
테스트의 부재로 인한 악순환
기존 코드에 대한 컨텍스트도 없이 하나하나 로직을 타고 들어가면서 코드를 건드려 보는데, n번의 디버깅 트라이 만큼 디버깅 시간 + 개발 시간 n만큼 계속 늘어날 것이다.
늘어나는 개발시간 만큼 실제 배포 일정을 계속 수정하게 되면서 배포는 점점 딜레이되고, 고객은 자신이 원하는 시점에 서비스를 제공받지 못함으로써 신뢰에 의심을 품을 수 밖에 없다.
이 신뢰를 계속 잃게 되면 당연히 계약 해지 → 매출 하락, 즉 비즈니스에 직접적인 악영향을 끼칠 수 있게 된다. 이 일련의 과정이 한번만 일어나면 얼마나 좋을까, 위 코드를 건드리게 되는 상황이 다시 오면 또 다시 과정을 반복할 것이다.
테스트가 있었다면?
필자가 좀 원론적이고 극단적인 상황을 예시로 든걸 수도 있지만, 비슷한 맥락으로 테스트 코드의 부재가 주는 악영향을 필자는 꽤 접할 수 있었다. 만약 위 상황에서 테스트 코드가 있었다면 어땠을까?
컨텍스트 파악이 쉬워진다.
테스트가 있게되면 이 코드가 어떤 의도, 어떤 역할로 작성된 코드인지에 대한 맥락 파악이 쉬워진다. 당장 위 useEffect의 예시에서도 왜 의존성을 비워놨을까에 대한 고민이 해소 될 수 있다.
보통 태스크를 맡게되면 맥락부터 파악하게 되는데, 코드를 하나하나 따라가면서 맥락을 파악하는게 아닌, 당시 작업을 했던 사람이 남겨놓은 테스트 코드를 보면서 어떠한 사고로 로직을 작성했는지 정확한 맥락을 파악할 수 있게 되는 것이다.
리팩토링이 쉬워진다.
또 다른면으로는 새로운 구조, 새로운 기술을 적용하여 코드를 수정하려고 할 때 원래 작성해 놓았던 테스트 코드만 지키면 되기 때문에, 더욱 더 안정적으로 코드에 수정을 가할 수 있다.
이렇게 테스트 코드가 존재하는 개발환경이라면 제품을 개발하고 유지보수하는 과정에서 여러 이점들을 챙길 수 있다. 심지어 필자가 올해 7월에 읽었던 소프트웨어 장인이라는 책에서도,
좋은 소프트웨어라면 그 애플리케이션이 얼마나 오래되었든 간에 개발자가 쉽게 이해할 수 있어야 한다. 부작용도 알려져 있어야하고 관리가 가능해야한다. 높은 커버리지에 신뢰할 수 있는 테스트가 가능해야 하고, 명료하고 단순한 디자인과 비즈니스 용어로 잘 기술된 코드여야 한다.
라는 문장이 있는걸 보면 테스트는 지속가능한 소프트웨어 개발의 근간에 포함돼 있음을 알 수 있다.
안정적인 테스트 문화의 랜딩
테스트의 필요성과 이점을 이해했지만 테스트 문화를 도입하기 위해선 부가적으로 고려해야 할 부분이 많다.
조직 구성원들이 해당 방향성에 대한 공감을 하고 있는지부터 어떠한 테스팅 툴이 우리의 조직에 적합한지, 테스트 코드는 모두가 어떻게 작성하고, 개발 프로세스엔 어떻게 녹일건지, 테스트에 대한 OKR은 어느정도로 설정한건지 등등 한걸음씩 의사결정하는 것이 안정적으로 테스트 문화를 조직에 랜딩시키는 방법이지 않을까 싶다.
마치며
필자가 취준을 하던 시절에, 테스트라는 것은 막연히 귀찮고 ROI가 나오지 않는다고 판단되어 중요하지 않다고 생각했었다. 하지만 실제로 현업에서 일해보니 “이럴 때 테스트가 있었다면 이런 문제가 안 일어날 수 있었겠다” 라고 생각되는 상황을 만만치 않게 만날 수 있었다. 이로 인해 위에서 언급했던 것처럼 비즈니스적으로 영향을 끼치는 적도 볼 수 있었고 말이다.
개인적으로 테스트가 없던 조직에서 도입되는 것을 막 경험한 필자의 입장에서 해당 글이 좀 부족할 수도 있다고 생각되지만, 필자가 확실히 말할 수 있는건 경험이 적어도 테스트가 주는 이점은 명확하고 작지않다는걸 체감할 수 있었고, 프로덕트를 운영하기 위해선 필수적으로 존재해야하는 부분이라는걸 알 수 있었다.
따라서 이런 부분을 잊지 않기 위해서 글로 한번 적어보았고 나중에 기회가 된다면 실질적인 테스팅 환경 구성과 과련된 포스팅을 올려보려고 한다.
이상으로 “내가 회사에서 테스트 커버리지를 신경썼던 이유” 에 대한 포스팅을 마쳐본다.