테스트를 하지 않아 낭비될 "우리"의 시간

Slack에서 코드 리뷰 요청하는 알림을 확인하고 PR을 열어보았습니다. 제법 많은 양의 코드가 추가되었는데 테스트 코드가 전혀 없더군요. 그래서 저는 PR을 승인하지 않고, 추가한 코드에 대한 테스트 코드를 작성해 달라는 짧은 코멘트를 남겼습니다.

다음 날, 코드 리뷰를 요청했던 개발자가 속한 팀의 stand-up 미팅에 참석했습니다. 그런데 그 친구가 PM(Project Manager)에게 약간 원망조로 얘기를 하더군요. 어제 자기는 빨리 코딩을 하고 팀원들에게 리뷰를 요청했지만, 아무도 승인해주지 않아서 배포를 할 수가 없었다고요. 저 뿐만 아니라 다른 팀원들도 그 PR을 승인하기가 불편했었나 봅니다. 최근에 테스트없는 코드를 배포했다가 옆 팀에서 장애가 있었거든요. 자초지종을 모르는 PM은 우선순위가 높은 티켓이니 오늘까지 꼭 코드 리뷰를 해달라고 팀을 독려하였습니다.

테스트 작성에 대해 꼭 대화를 좀 나누고 싶어서, 그 개발자와 one-on-one 미팅을 잡았습니다. 제가 테스트 코드를 추가하지 않는 이유에 대해 물으니, 테스트를 작성할 시간이 없을 정도로 긴급한 변경 사항이라고 판단해 테스트를 생략했다고 하더군요.

저는 우선 그 친구의 좋은 의도에 대해서 감사하다고 말했습니다. 어찌됐든 팀을 위하는 마음으로 한 일이니까요. 그리고 우리는 테스트 작성에 대해서 본격적인 대화를 시작하였습니다. 저는 우선 질문을 하였습니다.

“How much time do you think YOU have saved on the PR by skipping writing tests?” (테스트 작성을 생략해서 너의 시간을 얼만큼 아꼈다고 생각해?)

그 친구는 조금 머뭇하더니 대답합니다.

“Well… I don’t know. Probably, a couple of hours?” (글쎄… 잘 모르겠는데, 아마도 한 두시간?)

저는 질문을 이어 갔습니다.

“Have you ever thought about how much time WE will waste in the future by choosing not to write tests today?” (혹시 오늘 테스트를 작성하지 않기로 해서, 미래에 우리가 낭비하게 될 시간에 대해서는 생각해봤어?)

그 친구는 제 질문의 의도를 바로 이해하지 못하는 눈치였습니다.

“What? What are you talking about? 🤷”

그래서 아래와 같이 테스트를 작성하지 않음로써 팀이 치뤄야하는 댓가에 대해서 안 되는 영어로 열심히 제 생각을 말해주었습니다.

(다 영어로 써볼려고 하다가 너무 길어서, 여기부터는 그냥 한글로 갈 께요 ㅋㅋ 😂)

“우선 테스트가 없는 코드는 리뷰하는데는 시간이 더 오래 걸리기 마련이야. 해당 코드가 어떤 용도로 작성이 되었는지 파악하기가 힘들고, 리뷰어(reviewer) 입장에서 코드를 눈으로만 읽고 선뜻 승인 버튼을 누르기 어려워. 혹시 문제가 생기면 공동 책임이잖아. 그래서 나처럼 한 번에 승인하지 않고 코멘트를 남기는 사람도 생기고. 이 것은 결국은 PR 작성자와 PR 리뷰어 모두에게 시간적인 손해야.”

“QA 입장에서 생각해볼까? 다른 PR들처럼 자동화된 테스트가 없으니 QA는 코드가 상용 환경에서 잘 동작할 거라는 확신을 갖기 어려워. 결국 다른 PR 보다 매뉴얼 테스팅에 더 신경을 쓰게 될꺼야. QA 시간에도 손해가 일어나네?”

“나중에 다른 팀원이 이 코드를 수정할 일이 생겼다고 생각해보자. 주니어 개발자들은 경험이 많지 않아서 테스트를 보완하지 않고 그냥 코드를 수정하게 될 가능성이 커. 이럴 경우, 새로운 기능은 잘 되는데 기존에 잘 되던 기능에 문제가 생기는 경우가 많지. 만약 상용 환경에서 심각한 버그가 생기면 팀 전체가 하던 일은 멈추고 그 문제를 해결하는데 매달려야할 수도 있어. 당연히 진행 중이던 프로젝트 일정에 차질에 발생하겠지?”

“이런 일을 많이 당해본 나같은 개발자들은 테스트없는 코드 수정하는 게 얼마나 위험한 일인지 알고 있어. 그래서 수정하려는 코드에 테스트가 없다면 우선 테스트를 먼저 작성하지. 알다시피 본인이 작성하지 않은 코드에 대한 테스트를 작성하는 게 그렇게 유쾌한 경험은 아니야. 주어진 일을 제쳐두고 테스트하려는 코드를 먼저 이해해야 하니, 최초 코드 작성자를 원망하게 되는 경우도 많지. 어떤 방향으로든 다른 개발자에게도 피해가 가겠지?”

“자, 정리를 해보면, 테스트를 작성하지 않아서 오늘 너는 한 두시간을 아꼈을지 몰라도, 앞으로 우리 팀은 그 테스트가 없는 코드 때문에 그 보다 몇 배의 시간을 낭비할 수도 있어. 그래서 나는 너가 테스트를 작성하지 않는 이유가 완전히 납득이 가지 않는 건 아니지만, 과연 그 것이 진정 팀을 위한 일인지는 의문이 들어.”

다행이도 그 친구는 금방 설득이 되었고, 저는 짝 프로그래밍(Pair-programming)을 제안하였습니다. 함께 테스트를 작성하면서 우리는 코드에서 몇 가지 아찔한 버그를 찾아서 고칠 수 있었고, 테스트를 작성하기 쉽도록 코드 설계도 조금 개선할 수 있습니다. 실제로 우리가 테스트를 작성하는데 필요한 시간은 30분 남짓이면 족했습니다. 그 친구의 시간 30분, 제 시간 30분, 우리는 오늘 총 1시간을 투자하여 팀차원에서 낭비될 수 있었던 많은 시간을 절약하였다고 생각합니다.

그 친구는 다시 코드 리뷰를 요청하였고, 금방 팀 동료로부터 승인을 받을 수 있었습니다. 얼마 지나지 않아 그 친구가 테스트를 작성해야하는 이유에 대해서 일깨워줘서 고맙다는 메시지를 보내왔습니다. 알고보니 작년에 매니저로 부터 시니어 개발자가 되려면 성과가 더 많아야겠다는 피드백을 받았다네요. 그 이후로 초조해져서 테스트를 작성하는데 소홀해진 것 같다고 하네요. 그 친구가 터놓고 얘기를 해줘서 고마웠습니다. 다음 one-on-one 미팅에서는 quality를 희생하지 않고 speed를 올릴 수 있는 방법에 대해서 대화를 나누기로 했습니다.

여러분도 빡빡한 일정을 핑계로 테스트를 작성하지 않고 코드 리뷰를 요청하는 동료 개발자가 있으신가요? 테스트를 생략함으로써 개인 시간을 당장 얼마나 아낄 수 있는지, 그리고 나중에 다른 팀원들이 얼만큼의 시간을 지불해야하는지에 대해서 한번 꼭 열린 대화를 나누어 보셨으면 좋겠습니다. 😃

• LinkedIn에서 보기