우리는 늘 레거시 코드를 짜고 있다.
테스트 코드를 짜야하는 진짜 이유, 코드없는 개발이야기 #3
개발자인 우리는 코딩의 세계에서 일과 밤을 지낸다. 수많은 코드 라인을 짜고, 수많은 기능을 구현하고 문제들을 해결해 나간다. 그 과정에서 코드품질에 대해 한번 깊게 생각해 보는 시간을 가져보자.
레거시 코드. 많은 개발자들이 그 이름만 듣고도 혀를 차고, 인상을 찌푸리게된다. 무엇이 이렇게 '레거시'라고 하는 단어에 부정적인 느낌을 씌어주었을까? (레거시 입장에서는 매우 억울하다.)
한 일화를 들어보자.
어느 날, 프로젝트를 진행하던 중 JIRA에 버그 티켓이 울리고, 나에게 이슈할당이 되기 시작했다. JIRA 티켓을 살펴보니 기존에 잘 동작하던 한 모듈에서 null pointer exception 문제가 발생한 것이었다.
코드를 열어보니, 한 메서드가 수백 라인에 이르고 수많은 분기가 있다. 우리가 흔히 말하는 "레거시"에서 문제가 발생한 것이었다. 다른 코드는 보기 싫고 우선 null pointer exception 이 나는 부분을 이렇게 고쳐본다.
if user is not null :
return "ok"
그리고 "누가 이런 레거시 코드를 작성했지??"라고 마음속으로 내심 타인을 탓하며 git blame을 해보니, 낯익은 이름이 나왔다. 본인 이름, "어라? 내 가짠 코드네?"
자 이제 한번 생각해 보자. 당신은 정말 지금 이 순간에 당신이 작성하는 코드가 "레거시"가 아니라고 단언할 수 있는가? 적어도 필자도 똑같은 상황이라면, 똑같이 "레거시"를 양산하고 있었을 것 같다.
우리는 코딩의 세계에서 아주 흔하게 이런 일을 마주한다. 그리고 그저 레거시를 비난하고 레거시에게 부정적인 기운을 다 몰아주게 된다.
우리는 문제를 해결하는 사람들이다. 이 것 또한 하나의 문제이며, 이 문제를 현명하게 대처해야 하는 의무가 있다. 이제 문제를 한 번 해결해보자.
문제를 해결하기 위해선, 먼저 정의를 해야 한다. 레거시 코드란 무엇인가?
마지막 배포가 일 년 이상 된 것? 다른 사람이 짠 코드?
앞의 상황을 보자. 버그가 시간이 오래돼서 발견된 것인가? 다른 사람이 짰던 코드인가? 모두 아니다. 내가 짠 코드이며 (개발 세상에선, 고작 2주 전의 내가 짠 코드도 나는 다른 사람이 짠 코드라고 정의한다.) 그저 코드를 처음 짜던 당시에 운이 좋아 버그가 발견되지 않았을 뿐이다.
필자는 레거시코드란 테스트코드가 없는 코드는 모두 레거시코드라고 정의하고있다. 테스트 코드가 없는 것이 레거시 코드라고 정의하고나면, 이 레거시 문제를 해결하는건 간단하다. 당연하게도, 레거시코드를 작성하지 않으면 된다. 테스트 코드를 작성하면 된다.
이 말의 의미가 무엇인지 더 이야기해보자.
레거시 코드를 해결하기 위해, 사람들을 여러 가지 이야기를 한다. 주석을 열심히 달아야 한다. 혹은 문서화를 열심히 해야 한다. 객체지향 생활체조원칙을 지켜야 한다. 등등. 아쉽지만 이또한 모두 아니다.
주석이 실제 코드와 달라서 당황했던 적이 한 번도 없는가? 문서가 실제 코드와 달라서 당황했던 적이 한 번도 없는가? 객체지향 생활 체조 원칙을 몰라서 if 문을 썼던가?
코드는 비즈니스에 맞춰서 변화한다. 주석은 절대 코드를 대변할 수 없다. 주석은 강력한 거짓말쟁이다. 문서 또한 마찬가지다. 비즈니스에 따라 시시각각 변하는 코드에 맞춰 매번 문서를 갱신할 수 있는가?
이 문제의 진정한 해결책은 테스트 코드에 있다.
테스트 코드는 코드의 기능과 의도를 명확하게 문서화하는 동시에, 코드가 예상대로 작동할지 검증하는 방법이다. 또한 다른 사람들에게, 이 코드가 안전하다는 것에 대한 확신을 줄 수 있다.
테스트 코드를 작성함으로써, 나중에 코드를 수정하거나 리팩토링 할 때, 그 코드가 여전히 잘 동작하는지를 쉽게 확인할 수 있다. 테스트 코드는 가장 신뢰할 수 있는, 실시간으로 갱신되는 문서이다.
내가 작성한 코드가 잘 동작하는지 검증하라. 라는 이야기가 아니다. 내가 작성할 코드가 잘 동작할지 문서화하라는 이야기다.
따라서 미래의 내가 레거시를 만나지 않게 하기위해, 테스트 코드는 필수적이다.
