개발자를 위한 클린코드 전략

Taesoo Kim·2024년 11월 25일

이 포스트는 인프콘 2024 토비님의 강연을 요약 및 재해석한 포스트임을 알립니다.

클린코드에 대한 오해

요즘에 포트폴리오에 클린코드를 적으면 '주의' 딱지가 붙는단다. 클린코드를 지향하지만, 그것에 매몰되어 생산성을 잃어버리는 일이 종종 일어나기 때문에 붙은 수식어가 아닐까 싶다.

요즘 이 말을 많이 체감하고 있다. 신규 기능을 개발하는데, 모든 기능을 완벽하게 확장성을 고려하며 테스트 코드까지 짜다 보면 일정을 맞추는게 거의 불가능하다. 특히, 생산성이 가장 중요한 스타트업에서 시간을 잡아먹는 일을 하고 있으면, 과연 이게 현실과 맞는건가 생각이 들기도 한다.

나뿐만 아니라, 많은 개발자 분들이 비슷한 생각을 할 것이라 믿는다. 완벽한 코드를, 빠르게. 거의 모든 개발자가 추구하는 방법일 것이다. 하지만, 막상 클린코드를 중심으로 개발을 하다보면 말도 안되는 순간이 오기 마련이다.

주석이 과연 필요 없나?
애초에 클린하면 왜 리팩터링을 해야하나?
클린하면 버그를 잡기 쉬워서 테스트는 안해도 된다.
클린코드가 목표이기에 일정을 맞출 수 없다.
클린코드에 위배되어 리뷰를 할 수 없다.

클린코드를 지향한다면, 모두가 한번은 꼭 지나칠 물음들일 것이다. 특히 일정, 기한과 항상 부딪히는 것이 클린코드이기 때문에, 대부분이 클린코드는 생산성과 대척점에 있다고 생각하기 마련이다.

그런데, 과연 정말 유지보수성(클린코드)와 생산성은 대척점에 있을까? 정말 대척점에 있다면, 왜 오랜 시간동안 패러다임을 유지하면서 살아 남아 있는 것일까? 이 얘기를 하려면 기술부채에 대한 얘기가 나올 수 밖에 없다.

기술 부채

보통 코드를 대충 작성해서 확장성 있게 만들기 힘든 상황에 쓰이는 말로 많이 알고 있다. 하지만, 처음 기술 부채의 비유를 한 사람은 이런 의도로 한 것이 아니라고 한다.

신기능은 빠르게 출시하고, 잦은 리팩토링을 통해서 빚을 갚아나가야 한다는 뜻이다. 그렇기 때문에, 애초에 기술부채는 처음부터 코드를 돌아가게만 짜라는 뜻이 아니고, 확장성이 좋은 방향으로 빠르게 개발해 나가는데 초점이 있는 단어이다.

이런 맥락에서 본다면,

유지보수성이 좋은 코드는 변경가능성이 좋고, 그래서 생산성이 좋다.

라는 말이 충분히 일리 있는 말인 것 같다.

그래서 어떻게?

시작은 항상 빠르고 간단하게 동작하는 코드를 목표로 하자.

익숙한 기술로
핵심 기능이
동작하는
가장 단순한 코드를
리팩터링 하기 좋은 형태로

시작하면 충분히 좋은 시작이다. 절대 기능적으로, 형태적으로 완벽한 코드를 추구하며 시작하지 말자는 뜻이다.

테스트

하지만, 이런 개발론에는 한 가지 전제가 따라온다. '테스트'를 기가 막히게 짜야 잦은 리팩터링으로 큰 스노우볼을 굴릴 수 있다. 리팩터링을 하는데 동작하지 않는다면 아무 쓸모가 없기 때문이다. 또한, 기능이 커져가면 QA로는 감당하지 못하는 부분들이 생긴다. 그렇기 때문에 테스트는 꼭 필수로 진행해야 하는 시점이 온다.

여기에도 또 비슷한 물음이 따라온다.

테스트를 작성하는 시간이 어느 순간부터 개발 시간보다 더 많이 든다.

너무나 당연하다. 현재 회사 히스토리도 테스트를 진행하다 기능개발을 못해서 테스트가 사라진 적도 있다고 한다.

그래서 오히려 개발보다 테스트 작성하는 연습을 추천하고 싶다. 개발은 아는 지식과 프레임워크와 경험 등등 많은 요소가 작용하여 실력이 늘어가지만, 테스트는 빠르게 작성하는 것을 체득하기만 하면 정말 빠르게 찍어 낼 수 있다고 한다. 요즘은 생성형 AI도 좋은 테스트 코드를 짜기 때문에 테스트에 대한 여러 노하우를 쌓아 보는것이 우선이라 생각한다.