[비정기 태블릿 챕터] 300/500 규칙, 빠르고 잘하는 개발 조직이 될 수 있을 지도 모를 비결

안녕하세요 슬링 태블릿 챕터 김필권입니다!

지난 글에선 서비스를 운영하는 회사에겐 없어선 안되지만 귀찮은 존재인 배포에 대한 얘기를 했는데요, 오늘 얘기할 주제는 누군가에겐 배포보다 더 귀찮고 비효율적인 행위일 수 있습니다.

바로 코드 리뷰인데요, 오늘은 저희 태블릿 챕터를 넘어 슬링의 모든 개발자가 코드 리뷰할 때 쓰는 300/500 규칙을 설명드리고, 이 규칙으로 어떻게 챕터 모두가 빠르게, 잘 움직일 수 있는지에 대해서 말씀드리려 합니다 🏃

코드 리뷰란 자신이 작성한 코드가 챕터에서 정한 스타일에 맞는지 확인하는 기본적인 것부터 복잡한 비즈니스 로직의 정합성을 확인하는 것까지 말 그대로 내가 짠 코드를 챕터원들과 함께 검토하는 것입니다.

코드 리뷰를 거친 코드는 혹시나 유저에게 전달될지도 모를 부정적 가치(ex. 충돌, 오류, 의도하지 않은 작동)를 미연에 방지할 수 있습니다.

코드 리뷰는 정말 필요할까요?

코드 리뷰는 상황에 따라 정말 많은 비용이 들기 때문에 어떤 조직에선 하지 않기도 하는데요, 운이 좋게도 코드 리뷰를 거의 하지 않는 팀에 있어봤기 때문에 어떻게 돌아가는지 말씀드릴 수 있을 것 같습니다.

제가 경험한 조직에선 주어진 일정에 맞게 최대한 빨리 요구사항에 최적화된 코드를 작성해야 했습니다. 코드 리뷰는 기능이 완성된 후 마지막에 한꺼번에 하나의 PR로 진행했으며, 보통 천 줄 내외이고 많으면 3천 줄 정도 됐습니다.

천 줄이 넘는 코드를 한 줄 한 줄 제대로 리뷰한다는 것은 불가능에 가깝기 때문에 “기능이 잘 작동하네요”, “좋은 것 같습니다 🙏” 같은 대화가 자주 오고 갔습니다.

이렇게 되면 시스템적으로 개발 단계에서 부정적 가치가 생산되는 것을 막기 어렵기 때문에 QA나 핫픽스 같은 부정적 가치를 제거할 수 있는 다른 방법을 사용해야 합니다.

조금 부정적이게 쓴 느낌은 있지만, 저는 이게 나쁜 방법이라고 생각하진 않습니다. 이상적인 코드 리뷰 문화란 존재하기 어려우며, 조직의 상황에 맞게 합리적으로 선택해야 한다고 생각하기 때문입니다.

슬링의 코드 리뷰 300/500 규칙

그래도 유저에게 긍정적 가치를 전달하기 위해 개발하는데 이왕이면 부정적 가치는 미리 방지하는 것이 좋겠죠?

슬링에는 코드 리뷰를 위한 풀 리퀘스트(PR) 작성 시 추가된 코드 수 기준으로 300줄이 넘을 시 경고, 500줄이 넘으면 오류를 뱉는 깃헙 액션이 있습니다.

이 규칙은 회사 설립일부터 존재했으며, 지금까지 2년 넘게 유지되고 있는 규칙입니다.

처음 들었을 땐 “300줄도 안되는 PR을 작성하면 작업하는 사람도, 리뷰하는 사람도 모두 더 귀찮아지기만 하는 것 아닌가?” 라는 생각을 했습니다. 아마도 이 글을 읽는 여러분도 그렇게 생각하실 것 같습니다.

2년 넘게 지켜오면서 적응한 입장에서 말씀드리자면, 잃는 것보다 얻는 것이 더 많다고 생각합니다.

사실 이젠 이 규칙이 없는 코드 리뷰를 생각하면 막막하고 답답한 기분이 들 정도 입니다.

장점

이 규칙이 무슨 장점이 있길래 그정도인지 궁금하실 겁니다. 바로 장점 설명 들어가겠습니다.

• 기본적으로 300줄 안으로 끝나야 하기 때문에 PR은 보통 하나의 맥락만 가지는 편입니다.
• 맥락이 하나이다보니 코드 리뷰를 요청하는 입장(코드 작성자)에서 설명해야 할 것들이 줄어듭니다. (편리함)
• 맥락이 하나이니 코드를 리뷰하는 입장(다른 개발자)에서도 이해하기가 쉽고 확인해야 할 것이 명확해져서 빠른 코드 리뷰가 가능합니다. (리뷰 부담감 하락)
• 맥락이 하나니까 하나의 주제에 대해서 깊이 얘기해도 맥락을 놓칠 일이 없습니다. (커뮤니케이션 비용 감소)
• 코드 리뷰가 원활해지니 최종 유저에게 전달되기 까지의 전체적인 속도도 줄어듭니다. (개발 속도 증가)

단점

당연히 장점만 있을 수는 없겠죠? 이 규칙의 단점 말씀드리겠습니다.

• 원래 3000줄짜리 PR 하나로 퉁칠 수 있었을 작업을 굳이 여러 개의 PR로 나눠야 하는 부분이 누군가에겐 부담이고 불편함이 될 수 있다고 생각합니다.
• 이런 문화가 흔하지 않기 때문에 새로 오신 분들이 적응하기 어려운 경우도 분명히 존재할 것 같습니다.

그래서 충분히 검토 후에 조직의 상황에 맞는 전략과 규칙을 선택하는 것이 중요하다고 생각합니다.

예를 들어, 개발자가 한 명이라면 코드 리뷰나 PR 작성이 의미가 없다 판단하고 하지 않을 수 있을텐데요, 그것도 충분히 합리적이라 생각합니다.

종합하자면,

분명히 단점이 존재하지만, 말씀드린 장점들은 억지가 아닙니다.
이 규칙이 없었다면 태블릿 챕터가 2년 넘게 매주 정기배포를 진행할 수도 없었을 거라 생각합니다.

그리고 이 규칙에 더해서 1) 빌드 오류는 없는지 체크하는 액션, 2) 같이 정한 코드 스타일에 어긋난 코드는 없는지 체크하는 액션 등 코드 리뷰할 때 더 중요한 일에 집중하기 위해 사람이 하지 않아도 될 일을 줄이는 자동화도 꾸준히 하고 있습니다.

이렇게 쓰고 보니 코드 리뷰에 진심인 것 같은데요, 그렇게 까지 진지하진 않고 급하게 나가야 할 때는 구두로 처리하기도 하고 코드 리뷰 하지 않기도 하니 너무 겁먹진 않으셔도 됩니다 🤪

마치며

오늘은 태블릿 챕터뿐만 아니라 슬링의 개발자라면 익숙한 규칙인 300/500 규칙에 대해 알아보았습니다.

지난 글을 작성하고 난 뒤, 너무 기술적이고 관심있을 것 같은 사람이 적은 글을 쓰기 전에 더 많은 분들이 관심을 가질 수 있을 만한 가벼운 글을 써보려고 이번 글을 써봤는데요, 혹시 의견 있으시다면 얼마든지 연락주세요.

읽어주셔서 감사합니다. 슬링 태블릿 챕터 김필권이었습니다.