국내 스프링 개발자들에게 바이블과 같은 토비의 스프링의 저자이자, 구루로 불리는 이일민(토비) 님의 블로그에 최근 글이 올라왔다. 제목은 클린 스프링 - 인프콘 2024로, 그동안 내가 생각했던 것들에 대한 해답과 가까운 내용이 담겨 있었고, 내가 내렸던 결론과도 비슷한 이야기라 용기를 내어 의견을 적어 본다.

클린코드는 생산성을 저해할까?

나 역시 비슷한 고민을 했고, 실제로 클린코드를 지향할수록 기능 개발 속도가 느려진다는 느낌을 받은 적이 있다. 절차지향적이고 제대로 정리되지 않은, 그저 ‘동작만 하는’ 코드를 작성하고 “리팩토링은 나중에 하겠습니다”라는 멘트와 함께 백로그에 티켓을 남긴 경험도 있다. 하지만 이런 티켓은 대부분 영원히 백로그에서 꺼내지지 않고, 시간이 지나면 리팩토링 하려던 부분이 더 이상 기억나지 않거나 고칠 필요가 없어지기도 한다.

이때 “고칠 필요가 없어졌다”는 말은 무슨 의미일까? 결국 내가 작성한 코드는 이후 누군가에게 걸림돌이 되었을 것이고, 이는 그 팀원의 생산성을 저해했다는 의미가 될 수 있다. 내가 해야 했던 일을 누군가가 대신 해 준 셈이다.

테스트 코드 작성 역시 마찬가지다. 기능 구현이 급할 때 테스트 코드를 작성하지 않고 기능만 먼저 개발한 적이 여러 번 있었다. 이렇게 하면 코드 작성 시간이 줄어들긴 하지만, 기능 개발이 전체적으로 빨라지지는 않는다. 테스트 코드가 없으면 리뷰어가 불충분한 정보를 가지고 코드 리뷰를 해야 하고, 그로 인해 리뷰 속도가 느려질 수 있기 때문이다. 게다가 테스트 코드로 쉽게 발견할 수 있었던 엣지 케이스들을 놓칠 가능성도 커진다.

경험을 통해 깨닫는 것들

최근 프로젝트에서 팀원이 많아지면서 내가 직접 코드를 작성하기보다는 리뷰에 더 많은 시간을 할애하게 되었다. 베트남에 있는 개발자를 포함해 6~8명의 코드를 리뷰하면서, 클린코드의 중요성을 다시금 실감했다.

크게 두 가지 유형의 개발자들이 있었고, 그들의 생산성을 비교하게 되었다.

• PR 개수는 적지만 깔끔하고 유지보수가 쉬운 코드를 작성하는 개발자
• PR 개수는 많지만 가독성이 떨어지는 코드로 인해 리뷰가 지연되는 개발자

결국 메인 브랜치에 머지되는 PR의 개수를 보면 전자의 개발자가 압도적으로 많았고, 리뷰 피로도 또한 적었다. 전자의 개발자는 생산성도 높고, 팀원을 편하게 해주는 개발자라면 후자의 개발자는 그 반대라고 볼 수 있었다.

추가로 이번 프로젝트에서는 PR에 로컬 테스트 결과를 첨부하는 규칙을 정했는데, 테스트 결과를 꼼꼼히 작성하는 개발자와 그렇지 않은 개발자 사이에서도 큰 차이가 있었다. 팀의 생산성을 고려할 때, 어떤 개발자의 기여도가 더 높은지는 너무나도 명확했다.

클린코드는 결국 예의다

클린코드가 생산성을 높인다고 믿지만, 여전히 클린코드가 생산성을 저해한다고 생각하는 사람들도 있다. 이 주제에 대해 논쟁하기 시작하면 끝이 나지 않는 경우가 많다. 가끔은 이런 얘기를 꺼내는 내가 꼰대처럼 느껴지기도 한다. 그래서 나는 클린코드를 지향하는 마음을 개발자의 성향으로 정의하기로 했다. 강요할 수 없는 부분이고, 정답처럼 말하는 것이 언제나 좋은 결과를 가져오는 것도 아니기 때문이다.

그래서 표현을 조금 바꿔보기로 했다. 우리가 클린코드를 지향해야 하는 이유를 팀원을 위한 최소한의 예의라는 관점으로 바라보자는 것이다.

• 칼을 전달할 때 칼날을 내 쪽으로 잡고 건네는 것
• 상대방에게 펜을 줄 때 뚜껑을 열어서 건네는 것
• 명함을 주고받을 때 상대방이 바로 읽을 수 있도록 방향을 돌리는 것

이런 기본적인 에티켓처럼, 클린코드는 내가 조금 더 신경 쓰고 귀찮은 일을 감수하더라도 팀원을 배려하는 마음에서 시작된다고 생각한다.

여담

특히 반가웠던 점은, 토비님의 결론도 나와 비슷하다는 것이다. 토비님은 이를 친절이라는 키워드로 표현하셨는데, 내가 생각한 예의와 통하는 부분이 많다고 느꼈다. 혼자 고민하고 내린 결론이 존경하는 개발자 선배님과 일치한다니, 기분이 너무 좋다. 도파민이 폭발하는 밤이다!