개발 조직 문화 - 코드리뷰 문화 만들기

Oh, my god.

Your roommates are right.

You really hate space.

코드 리뷰 문화는 글로벌 기업인 애플, 구글, 페이스북이나 국내 1티어 IT 기업으로 불리는 ‘네카라쿠배당토’ 등 소위 말하는 잘나가는 조직만의 전유물이 아닙니다. 평생을 공부에 시간을 쏟아야 한다는 개발자들이라면 코드 리뷰의 정착은 자연스러운 현상이죠. 그러나 아직도 코드 리뷰와 어색한 사이(?)로 지내는 개발조직이 많다는 것도 사실입니다. 오늘은 코드 리뷰의 중요성부터 코드 리뷰 잘하는 법까지 A TO Z를 살펴볼까 합니다.

왜 해야 하나요?

지속 가능한 개발을 위한 조직문화

코드 리뷰(Code Review)란 말 그대로 코드를 리뷰하는 행위입니다. 한 명 또는 여러 명의 개발자가 본인이 작업하지 않은 코드를 점검하고, 또 피드백을 나누는 과정을 뜻하죠. 작업 과정에서 미처 발견하지 못했던 오류를 객관적 시각, 집단지성의 힘으로 해결하는 것입니다.

​

공부에도 예습과 복습이 제일 중요하다고 하죠. 코드 리뷰의 목적은 아주 간단합니다. 구성원들의 성장을 도모하기 위함이죠. ‘좋은 코드’란 무엇이냐에 대해 의견은 분분할지언정 그것을 지향하는 개발자들의 의지는 모두 한 마음입니다. 더 나은 작업물을 만들 수 있도록 서로의 시간을 할애하는 일종의 컨퍼런스인 셈이죠.

​

하지만 본인이 코드 리뷰에 익숙하지 않은 사회 초년생이거나, 개발 인원이 비교적 적은 중소기업의 경우 코드리뷰 문화가 자리 잡지 못하는 경우가 많습니다. 코드 리뷰는 받는 사람도, 하는 사람도 성장할 수 있는 아주 효과적인 개발자 간 커뮤니케이션이지만 과중한 업무로 인해 시간을 내기 어렵다는 사람도 많죠.

​

오픈서베이의 2021 개발자 트렌드 리포트에 따르면, 개발자들은 취업과 이직 시 개인의 성장 가능성을 중요하게 생각한다는 답변을 남겼습니다. 특히 경력 3년 미만의 낮은 연차를 가진 개발자들은 더더욱 그러했죠.

​

만약 조직이 주기적으로 코드 리뷰를 반드시 할 수는 없는 상황이라면, 프리 커밋 리뷰 (Pre-commit Review) 제도를 추천합니다. 실제 코딩 작업에 들어가기 전에 방향성을 토론하고, 작업 진행 일정을 공유하며 의견을 나눠보는 것이죠. 완성된 코드를 리뷰 받아 수정하는 것이 부담스럽거나 인원이 적은 조직에서도 효율적이랍니다.

​

이렇게는 안 돼요

남들 하니까 우리도 한다는 코드 리뷰, 오히려 독이 된다는 사실!

아무리 몸에 좋은 약이라도 쓰는 법을 모르면 독이 될 수도 있는 법. 코드 리뷰는 성장과 동기 부여에 매우 효과적이지만 때로는 양날의 검입니다. 개발자는 결과물로 말한다지만, 모니터 뒷편에 사람이 있다는 사실을 잊어선 안 되겠죠.

​

먼저 숙제 검사받는 분위기는 지양해야 합니다. 서로 놓친 부분이 없는지 확인하고 보완하는 과정이지만 자칫하면 ‘범인 찾기’가 될 수도 있습니다. “하나만 걸려라”라는 마음으로 접근하는 리뷰어와 소통하고 싶은 개발자는 아무도 없겠죠.

​

리뷰를 받는 사람의 마인드 셋 역시 중요합니다. 개발자들 사이에서는 유명한 문장이 있죠. “코드와 나를 동일시하지 마라.” 자신의 결과물에 자부심을 갖는 것도 중요하지만, 피드백에 과몰입한다면 감정싸움으로 이어질 가능성이 높습니다. 리뷰를 남기는 사람의 태도도 중요하지만, 받는 사람이 준비가 안 됐다면 우리가 꿈꾸는 티키타카는 이뤄질 수 없습니다.

​

구성원들의 자세뿐만 아니라 제도적인 흐름에도 눈을 돌려보세요. 코드 리뷰를 주도하는 조직장은 이 시스템의 설계 방향성과 의미에 대해 충분히 설명할 수 있어야 합니다. ‘대기업은 다 한다니까’, ‘성장에 도움이 된다니까’와 같은 두리뭉실한 이유로는 바쁜 사람들 불러다 뜬구름 잡는 소리 하는 연례행사에 지나지 않게 됩니다. 또한 리뷰를 행위 그 자체가 아닌 ‘절차’로 인식한다면 유의미한 리뷰가 이뤄지지 않고 병목현상에 빠질 수 있습니다. 자칫하면 성장은커녕, 프로세스가 꽉 막혀버리는 부작용이 발생할 수 있죠.

​

​

다른 집 사정은 어떨까?

국내외 대기업을 통해 본 코드 리뷰 사례

​

‘구글’은 모든 코드를 리뷰합니다. 잠재적인 결함을 분석하고 코드 정리 시스템을 사용해 효율을 추구하기도 하지만, 기본적으로는 100% 코드 리뷰를 추구합니다. 주요 목적은 구글의 코드 베이스의 전반적인 코드 품질이 개선되고 있다는 사실을 확인하는 데에 중점을 둡니다.

​

여기서 중요한 관점은 “완벽한 코드는 없고 더 나은 코드만 있다”라는 것입니다. 승인권을 가진 리뷰어가 코드 작성자에게 아주 세세한 것까지 완벽을 요구할 필요는 없다는 것이죠. 중요한 것은 지속 가능한 개선이기 때문입니다.

​

‘토스페이먼츠(이하 토스)’는 엔지니어링 데이라는 특수한 행사를 운영합니다. 프런트 앤드의 구성원 모두가 목요일 오후에 라운지에 모여서 엔지니어링에 집중합니다. 챕터 차원에서 논의가 필요한 이슈가 있다면 모두가 발언권을 가지고 함께 토론할 수 있죠.

​

이날에는 평소 구성원들끼리 나누었던 코드 리뷰 중 ‘Good Review’ 라벨을 받은 코드를 함께 보기도 합니다. 미처 리뷰를 하지 못했다고 하더라도 좋은 건 함께 공유하고 러닝 할 수 있도록 마련한 활동이죠.

​

‘우아한형제들’은 어떨까요? 개발자라면 혼자 일하는 모습에 더 익숙할 것 같지만 그들은 서로를 외롭게 두지 않으려 했습니다. 함께 일하는 분위기를 만들기 위해 협업 툴을 만들었죠. 하지만 그것을 또 하나의 업무처럼 만들지 않기 위해 과정을 단순화했습니다.

​

최소 1명의 리뷰 담당자를 지정하되, 리뷰어는 “가벼운 마음으로” 오탈자를 찾거나 질문, 제안 등의 의견을 나눌 수 있는 기회를 설계했습니다. 구성원들은 이를 평소에 안 쓰던 코드 스타일을 살펴보는 계기로 삼거나, 더블 체크의 수단으로 유용히 사용했다고 밝혔죠.

​

글을 마치며...

오늘부터 시작하세요, 코드리뷰

지금까지 우리는 코드 리뷰의 당위성을 확인하고, 시작하기 전 점검해야 할 포인트들을 짚어보았습니다. 또한 세 가지의 사례들을 통해 코드 리뷰의 방향성을 살펴보았는데요. 이미 많은 개발자 커뮤니티들이 진심으로 코드 리뷰에 임하고 있지만 여전히 그 혜택을 받지 못하는 경우도 비일비재합니다. 프리 토크도 좋지만, 오늘은 진지하고 진하게 코드의 세계로 빠져보는 건 어떨까요?

​

​