스스로 답해보자 : Lv1 - 자동차 경주 후기

대망의 우테코 첫 번째 미션은 자동자 경주. 이미 프리코스에서 경험해보았기 때문에 호기롭게 들이박았다. well-known 을 외치며 무지성으로 코드를 두들기다보면 어느새 목적을 잃어버리는게 사람이다. 자동차 경주는 엄연히 온보딩 미션. 우테코 생활에 적응해야 할게 한 두가지가 아닐테지만 과제를 임하는 자세만큼은 확실하게 잡고 들어가는 것이 좋겠다.

답해보기?

각 미션에는 #답해보기 라는 항목이 있다. 해당 과제를 통해 얻어가길 바라는 주제들이 적혀있는 것. 아주 적절한 피드백의 기준이 될 것이다. 과제를 끝내고도 질문들에 답을 못한다면 그게 바로 재앙 아닐까.

“내가 단위 테스트를 작성하는 이유는 무엇인가?“

첫 질문부터 쉽지 않다. 사실 개발을 조금만 해보면 테스트 코드라는 말을 듣지 않을 수가 없다. 조금만 검색해봐도 자료는 넘쳐나고 테스트 코드를 작성하지 않는 개발자는 말도 안된다는 이야기도 뭐 심심치 않게 볼 수 있다.

그러다 언제부터일까 테스트라이팅이라도 당했는지 테스트 코드에 집착하게 되었고 지금보면 쓰레기 같은 테스트 코드를 두들긴 흔적도 찾아볼 수 있다. 애석한 것은 질문을 보기 전까지는 테스트 코드가 왜 필요한지 스스로 생각해본 적이 없다는 것.

왜 단위 테스트를 작성하냐는 질문은 얼핏 웃긴 질문이다. 나의 도메인 로직의 안정성을 확보하는 것이 무엇이 나쁜가? 피드백을 빠르게 받음으로 확신을 가지며 개발을 이어가는 것은 당연한 것 아닌가? 그런데 누가 이렇게 물어본다고 치자.

그거 그냥 main 함수에 print 문으로 보여주면 되는 거 아님?

어 그러고 보니 맞는 말이다. 테스트 코드가 아니면 테스트를 못하는게 아니다. 그런데 왜 우리는 ‘테스트 코드’에 집착할까. 왜 꼭 테스트 코드여야만 하나?

돌고 돌아 내린 결론은 이렇다. 질문의 핵심은 ‘왜’가 아니라 ‘내가’ 이다. 테스트 코드는 필수가 아니다. 여기서 필수가 아니라는 것은 테스트가 필요 없다는게 아니라 테스트의 형태가 꼭 테스트 코드일 필요가 없다는 의미. 물론 테스트 코드가 가지는 장점들을 교과서 처럼 대답할 수 있다. 그러나 그게 정말 내가 느낀게 아니라면, 내가 테스트 코드의 필요성을 피력할 수 있을까? 회사에서 테스트 코드에 의문을 품는 후배가 생겼을 때 그를 설득할 수 있을까?

결론적으로 나는 그럼에도 불구하고 테스트 코드를 작성할 것이다. 그리고 누군가 왜 라는 질문을 던진다면 내 대답은 이렇다.

안쓰고 똑같은 일을 두번 세번 하기 싫어서요.

테스트 코드를 작성하지 않던 그때로 돌아가서 생각해보자. 나는 정말 테스트 코드라는 단어를 반복적으로 듣다보니 주입받은 걸까? 그건 아니라고 생각한다. 테스트 코드가 늘상 느끼던 불편함의 해결책이라는 생각이 들어서 내심 너무 반가웠던걸지 모른다.

매번 main 함수를 수정하고, 모든 로직의 테스트 코드가 한 곳에 모이게 되서 보기 불편하고 수정하기 불편하고, print문을 보기 싫으니까 나중에 지우고, 필요해지면 또 쓰던 일들을 반복하는 것은 매우 고통스러운 일이다. 그리고 이걸 나만 겪은 불편함이 아니라는 증거가 테스트코드가 아닐까.

누군가는 이렇게 주장할 것이다. 하지만 주장이 합리적이려면 정말 테스트 코드가 같이 배포되었을 때 생긴 문제를 겪어봤어야 한다고 생각한다. 만약 겪어보지도 않고 어디서 보고 외운 사실을 나에게 주장한다면 나는 받아들이기 어려울 거다. 반대로 내가 그렇게 주장한다면 누구라도 받아들이기 어렵겠지.

“내가 작성한 좋은 단위 테스트는 어떠한 부분에서 좋은 단위 테스트라 느꼈는가?”

솔직히 좋은 단위 테스트인지는 모르겠다. 나보다 코드 잘쓰고 자바 API, JUnit 잘 쓰는 사람이야 널렸을테니까. 하지만 비슷한 결로 대답해본다면 결론적으로 내 테스트는 적어도 나에겐 좋은 테스트가 되어 주었다. 이유라면 당연히 테스트하기 위한 수고가 줄어들었기 때문. 즉, 일을 두번 세번 안해도 되었다. 원래 겪던 문제가 해결되었다면 충분하지 않은가.

코드 퀄리티가 혹시 부족할지는 몰라도 적어도 내가 확인하기 원하는 범위 만큼은 확실하게 검증할 수 있다고는 말할 수 있다. 그리고 이 이상 수고를 들이지 않는 것이 해당 프로그램을 완성하는데는 아주 합리적이라고 말할 수 있다.

“위와 같은 좋은 단위 테스트를 작성하기 위해 어떠한 시도를 해볼 수 있는가?”

이마저도 철저히 ‘나의’ 기준에서 대답해본다면 결국 내가 원하는 것은 테스트하고자 하는 기능이 올바르게 작동하는 것이다. 그리고 로직이 혹시 변하더라도 매번 테스트코드를 수정하는 일은 없었으면 좋겠다. 그래서 나는 도메인 로직을 더 ‘잘’ 쪼갤 수 밖에 없었다.

테스트가 확실하게 작동하는 방법이 꼭 모든 기능을 포괄하는 완벽한 테스트 코드일 필요는 없다. 우리는 객체지향 코드를 작성하고 있고 역할을 적절히 나누는 걸 고민한다. 그리고 잘 나누어진 도메인 코드는 담당하는 하나의 테스트 코드가 할 일을 줄여준다. 그리고 나는 이걸 좋은 ‘단위’의 단위 테스트라고 부르고 싶다. 한 가지의 기능이라도 확실하게 검증할 수 있는 범위가 하나의 작은 단위가 되고 이러한 단위들이 뭉치면 하나의 견고한 프로그램이 될 것이다.

마치며

다 써놓고 보니 이건 뭐 코드 한 줄도 안 적혀있는 미션 후기가 되어버렸다. 그래도 내가 원하는 방향으로 성장했다는 생각이 드는 걸 보니 나름 만족스럽다. 우테코가 끝날 때 즈음에는 설득력있는 사람, 근거있는 사고를 하는 합리적인 개발자가 되고 싶다. 좋은 기술이야 구글이나 챗GPT가 더 잘 알려줄지 모르지만 우테코는 그런 곳은 아니다. 고기를 잡아주지 말고 고기 잡는 법을 가르쳐라는 말이 있다. 우테코에 이보다 더 잘 어울리는 격언이 있을까.