코드 리뷰를 대하는 개발자의 자세

2020.11.12

코드 리뷰는 개발자간의 협업 방법 중 하나로, 다른 사람의 코드를 검토하는 작업을 말합니다. 코드 리뷰의 장단점과 도입 후 변화에 관한 글들이 많이 나오고 있는 것으로 보아, 기술 회사에서 코드 리뷰가 차지하는 중요도를 가늠할 수 있습니다.

라인웍스에서도 대부분의 프로젝트에서 코드 리뷰를 진행하고 있습니다. 2017년, 초기 시니어 개발자간의 리뷰로 시작해, 개발 인력이 2배 이상 늘어난 현재까지도 유지되고 있습니다. 

회사가 성장함에 따라 개발자가 늘어나고, 시니어 개발자들의 역할이 나누어지게 되면서, 신입 개발자와 경력이 적고 코드 리뷰 경험이 부족한 개발자들과 협업을 하는 일이 늘어났습니다. 이런 신입 개발자들에게는 종종 코드 리뷰가 오히려 일정을 늦추고 코드 퀄리티를 낮추게하는 경우가 발생하기도 하였습니다.

저의 코드 리뷰 시작도 2017년 라인웍스의 시작과 함께 했습니다.(그 이전엔 대부분 혼자 개발을 진행…)

처음에 코드 리뷰를 시작할 때는 코드 리뷰가 오히려 개발에 방해 요소로 작용한다고 생각했습니다. 하지만, 코드 리뷰를 대하는 방법을 바꾸면서 점점 도움이 되었습니다. 코드 리뷰를 통해 몰랐던 새로운 정보를 얻고, 다른 개발자가 어떤 생각을 하는지 공유받으며 코드를 보는 시각을 점점 더 넓힐 수 있었습니다.

이번 글에서는, 코드 리뷰를 시작하는 분들이 가졌으면 하는 마음가짐에 대해서 리뷰를 받을 때와 할 때로 나누어 이야기해보려고 합니다.

리뷰 받을 때

리뷰가 많아도 당황하지마라

개발팀에 따라 코드 컨벤션과 네이밍 규칙은 다릅니다. 새로 합류한 팀이 내가 익숙한 코드 스타일을 사용하지 않는다면 이런 코드 스타일에 관련된 리뷰가 쏟아지는 것은 당연합니다. 당황하지 말고, 하나씩 해결해나가면 됩니다. 다만, 똑같은 것을 지적하는 리뷰가 새로운 PR에서도 반복된다면 문제가 되겠죠. 

우선 순위를 파악하라

다양한 유형의 리뷰가 달릴 수 있습니다. 이 중, 우선적으로 처리되어야하는 것을 골라내야합니다. 가장 먼저 고쳐야하는 것은 버그 관련 리뷰입니다. 코드 스타일에 관한 것은 단순한 실수나 부주의함으로 받아들여질 수 있지만, 코드로도 보이는 버그를 잡아내지 못했다는 것은 개발자로서 부끄러워해야할 리뷰입니다. 이런 버그에 관련된 리뷰를 우선적으로 처리하도록 합니다.

프로젝트 일정을 생각하라

코드 퀄리티를 유지하는 것도 당연히 중요하지만, 당장 배포 일정을 앞두고 있거나, 내 일이 끝나길 기다리는 사람들이 많다면, 코드 리뷰를 해결하기 위해 시간을 더 쓰는 것은 프로젝트를 좋지 않은 방향으로 이끌 가능성이 있습니다. 버그 관련 리뷰라면 당연히 해결해야겠지만, 코드 스타일에 관한 리뷰들은 일정이 중요함을 설명하고 나중에 추후 다른 이슈로 처리하겠다고 이야기(허락을 받거나)하는 것이 좋습니다. 일정에 대해 설명해도 막무가내로 코드 스타일 리뷰 해결을 고집하는 사람이 상사라면… 탈출하세요.

리뷰어는 QA가 아니다

같은 팀에 프로젝트에 대해 잘 파악하고 코드를 아주 잘 읽는 개발자가 있다면, 내가 미처 생각하지 못한 버그에 대한 리뷰가 많이 달릴 것입니다. 하지만, 절대 이것에 익숙해지면 안됩니다. 어차피 리뷰에서 내 버그가 다 잡힐거라 생각하고 작업을 하면, 코드 퀄리티가 문제가 아니라 제품의 퀄리티가 문제가 생길 수 있습니다. 또한, 위에서도 얘기했듯이, 버그에 대한 리뷰는 부끄러워해야할 리뷰이고, 반드시 개선되어야할 사항입니다. 이 상황이 계속되면 개발자로서의 능력을 의심 받을 것입니다.

리뷰어가 항상 옳지는 않다

갓 입사한 신입 개발자들이 어렵게 생각하는 부분일 것입니다. 선배 개발자들이 리뷰를 많이 해주겠지만, 선배라고, 경험이 몇 년 더 있다고 항상 옳지는 않습니다. 나와 생각이 다른 부분이 있다면 적극적으로 답변을 하는 것이 좋습니다. 내가 다르게 생각하는 이유를 이야기하고, 상대방의 생각을 물어봅시다. 생각한 과정을 들을 수 있기 때문에 상대방의 경험에서 우러나온 노하우를 터득할 수도 있고, 취향의 문제였다면 새로운 규칙을 정하게 되는 계기가 될 수도 있습니다.

리뷰 할 때

적극적으로 의견을 내라

다른 사람의 코드를 보다보면 다른 좋은 방법이 떠오를 때가 있습니다. 위에서 리뷰어가 항상 옳지는 않다라고 이야기했듯 리뷰이(리뷰를 받는 사람)도 항상 옳진 않습니다. 다른 의견이 있다면 적극적으로 제시를 하는 것이 좋습니다. 만약 내가 제시한 방법이 더 좋은 방법이었다면, 실력에 대한 좋은 평가를 들을 수 있고, 틀렸다고 해도 리뷰이가 구현한 방법이 왜 더 좋은 방법인지에 대한 설명을 들을 수 있습니다.

사소한 것이라도 물어라

리뷰이의 코드 스타일이 익숙하지 않은 상태라면 변수 이름이나 줄바꿈, 변수 타입 설정 등 아주 사소한 부분에서도 왜 이렇게 했을까 하는 의문이 드는 부분이 많을 것입니다. 그냥 이 사람은 이렇게 코딩하는구나라고 넘어가지말고 물어보는 것이 좋다고 생각합니다. 경험이 많은 개발자들의 경우, 사소한 것들도 대부분 그 스타일이 자리잡은 이유가 있습니다. 사소한 것처럼 보이는 부분들이 모여서 읽기 좋은 코드를 만듭니다. 무작정 따라하기보다 이유를 알고 따라해야 완전히 내 것으로 만들 수 있습니다.

시간을 너무 쏟지 마라

코드 리뷰에 익숙하지 않은 분들은 리뷰를 요청 받으면 모든 코드를 다 읽고 이해하려고 하는 경우가 있습니다. 물론, 선배 개발자, 실력이 더 좋은 개발자의 코드를 이해하면 내 실력 향상을 기대할 수 있지만, 회사는 코드 리뷰 외에도 다른 중요한 일이 많은 곳입니다. 몇 시간씩 다른 사람의 코드를 리뷰하느라 다른 일을 하지 못한다면 아무리 코드 리뷰를 잘해도 좋은 평가를 받을 수 없습니다. 코드를 다 보지 못하더라도 30분~1시간 정도로 시간 제한을 정해놓고 그 시간만 활용하는 것이 좋습니다. 코드를 자세히 이해해야할 필요가 있다면 코드 작성자에게 설명을 요청하는 것이 시간을 잘 활용하는 방법입니다.

마치며

코드 리뷰를 대하는 개발자의 자세에 대해서 이야기해보았습니다. 제가 글에서 이야기한 내용이 모든 분야, 회사, 팀에 모두 적용된다고 생각하지 않습니다. 각자의 개발 문화에 따라 바뀔 수 있는 부분이고, 그에 따라 적절히 조정하여 받아들여주시면 좋겠습니다. 다만, 이 내용들이 내 실력을 성장 시키고, 주변 개발자들에게 좋은 평가를 받을 수 있는 내용이라고는 자신있게 이야기할 수 있습니다.

이 글이 코드 리뷰를 하는 개발자 분들께 도움이 되었으면 좋겠습니다.

Jungwoo Chae

machine learning engineer

Jungwoo Chae