작은 조직에서 개발문화를 제안했던 경험과 알아두면 좋을 느낀점

최근에 슬랙에 올라 온 고민글 중에 개발 문화가 없는 조직에서 개발 문화를 어떻게 도입할 수 있을지 고민이라는 글이 있었다. 그 글을 보니 내가 프론트엔드 팀에 제안했던 경험들이 떠올라서 열심히 댓글을 남겼다. 그 경험들을 정리해서 남겨보고자 한다.

테스트 코드를 작성하는 문화

내가 프론트엔드 팀에 제안했던 문화는 테스트 코드를 작성하는 문화였다.

우리 서비스는 유저가 어떤 행동을 하면 gtm(google tag manager) event를 trigger해서 수집한다. 입사 초반에 내가 코드를 수정했다가 이 event가 발동하지 않으면 어쩌지? 하는 걱정에 이 로직들을 테스트 자동화 해놓으면 미리 알아차릴 수 있지 않을까 하는 생각을 했다. 빨리 알아차릴수록 고치는 비용이 작기 때문이다. 그 순간이 테스트 코드에 관심을 가지기 시작한 순간이었고 e2e test tool인 cypress를 설치해서 열심히 뚝딱거렸다. 하지만 내가 생각했던 대로 테스트 환경을 구축하지는 못했다. 시나리오대로 app을 mocking하는 게 쉬운 일은 아니었고, 프론트 앱 뿐만 아니라 이것저것 얽혀 있었기 때문이었다. 그래서 혼자서 만져보기만 하고 팀에 도입하지는 못했다.

시간이 지나고 jest를 이용해 컴포넌트 단위 테스트를 짜보면 어떨까 하는 생각이 들었다. 대상 컴포넌트만 mocking하면 되기 때문에 단위가 작아서 구현이 쉽고 더 효용이 있을 것이라는 생각이 들었다. 하지만 개발하면서 약속한 일정을 맞추다보면 테스트 코드를 항상 같이 짜진 못했다. 대신에 생각보다 빨리 개발하면 개발 후에라도 테스트 코드를 붙이는 경우가 있었다. 또한 사이즈가 작은 업무인 경우 테스트 코드를 먼저 작성해보고 컴포넌트를 개발해 본 경우도 있었다. 이렇게 테스트 코드를 놓지 않고 계속 붙들고 있으니까 아래와 같은 효용을 느낄 수 있었다.

1. 테스트 코드 자체가 컴포넌트의 기능 명세가 된다.
2. 변경으로 인한 예상치 못한 버그를 예방할 수 있다.
3. 테스트 코드를 먼저 작성했을 때는 UI를 뺀 기능구현에 먼저 집중을 하니 오히려 더 빨리 개발하는 경우도 있었다.

그리고 팀원들을 설득했다. 팀 미팅 때마다 테스트 코드가 좋다고 노래를 부르고, 위의 효용을 느꼈다고 했다. 물론 팀원들도 이게 좋은지는 안다. 하지만 내가 얘기를 꺼낸다고 해서 100% 설득되지는 않는다. 좋은지는 알지만 직접 효용을 느끼지 못한다면 설득되지 않는다.

그래서 github action을 통해 PR을 올리면 자동으로 테스트가 돌아가도록 해놓았는데 이거라도 붙여보자고 했다. 이걸 붙인다고 지금부터 당장 테스트 코드를 써야 하는건 아니기 때문에 넣어만 보자는 것이다. 나중에 정말 필요없다고 생각하면 그 때 지워도 되니까. 결국 그렇게 붙인 github action이 빛을 발했다. 팀원이 테스트 코드가 달린 컴포넌트를 수정할 일이 있었는데 수정하고 보니 테스트 코드 통과를 못 한 것이다. 그래서 테스트 코드를 보니 미처 생각하지 못한 부분이 있었음을 깨달으시고 다시 수정했다고 하셨다. 그리고 PR을 올릴때마다 계속 돌아가니, 팀원들도 시간이 날 때 하나씩 테스트 코드를 작성해보기도 했다.

적용해볼만한 느낀점

그 후에도 유용한 툴을 같이 쓰자고 제안하거나 스터디를 같이 하거나 팀에서 여러가지 시도를 했었다. 그러면서 느꼈던 점을 요약해보면 다음과 같다.

1. 팀원들이 쉽게 설득될 것이라는 기대는 버린다.
2. 팀원들이 직접 효용을 느끼게 해야 한다. 좋다고 느끼면 설득하지 않아도 자발적으로 참여할 것이다.
3. 모든 문화가 팀에 맞는 것은 아니다. 해보고 맞지 않는 문화는 과감히 버리는 게 좋을 수도 있다.