[회고] SVN에서 GIT으로 이전 후 코드 리뷰 도입을 돌이켜보며

회사에서 입사하고 난 후 1년도 안되어 2019년도에 SVN 저장소에서 벗어나기 위해 GIT 저장소로 이동하는 작업을 진행했었는데 그 이유는 아래와 같았다.

• 회사 내 개발 직무 협의체에서 장기 목표로 GIT 으로 이전하는 공통 목표가 있었다.
• 반영하기 전 코드를 미리 확인할 수 있는 방법이 없었다. 커밋한 후에야 변경사항만을 다른 사람에게 보여줄 수 있는 정도였다.
• 브랜치를 원격에서 관리하는 것이 아니라 로컬에서 먼저 관리하고 싶었다. 원격에서 항상 관리되다보니 데이터를 가져올 때나 커밋할 때 항상 시간이 걸렸다.
• 저장소 커밋의 이력 관리를 쉽게 보고 싶었고, GIT 을 이용한 다양한 기능들을 사용해보고 싶었다.
• ...

GIT 으로 이전하기 전에는 팀 내부적으로 코드 리뷰 문화나 정해진 컨벤션이 전혀 없었기 때문에 GIT 으로 이전하고 나면 우리 팀에 코드리뷰를 하는 것이 좋을 것 같다고 생각했다. 당시 사내에서 코드리뷰 활동이 늘어나는 추세였기도 했고, 당시 나도 들어온지 얼마 되지 않았기 때문에 이 기회에 다른 사람들이 어떻게 코드를 작성하면서 업무를 해나가는지 서로 공유하며 알 수 있을 것 같았고, 업무 파악에도 미리 파일의 위치라던지, 어떤 서비스 저장소를 참조해야 하는지 등 여러모로 도움이 되는 기회가 많이 생길 것으로 생각했다. 어쨌든 팀 내에서 GIT에 대해 제일 잘 알고 있는 사람이 본인 말고 없었으므로(...) SVN 에서 GIT 으로 이전하는 작업을 직접 맡게 되었었다. GIT 으로 이전하는 작업 전에 팀장님에게 나중에 코드리뷰를 하는 것이 어떤지 물어봤을 때 코드리뷰를 진행하는 것에 긍정적으로 봐주셔서 내심으로 다행이라고 생각했다.

 

GIT 브랜치 전략으로는 master 브랜치를 주요 브랜치로 사용하고, feature 와 hotfix 브랜치로 나누어서 작업하는 방법으로 정했다. 즉, GitHub Flow 와 유사한 방식으로 진행했다. 특히, 빈번하게 서비스 운영실로부터 개선 요청이 왔었기 때문에 기능별로 작업하는 것보다는 버그 수정을 하고 빠르게 배포해야 경우가 상당히 많았다. 그래서 굳이 develop 브랜치를 하나 더 두면서 관리할 필요는 없다고 판단했고 팀원 모두가 공감하였다.

• 위 브랜치 전략으로 Merge Request 를 성격에 따라 feature 또는 hotfix 에서 master 로 병합하는 방식으로 진행했다.
• 코드 리뷰를 해야 할 양이 상당히 많을 때는 브랜치에서 다시 나누어서 MR 을 올리는 방식으로 진행하거나 요청자가 핵심 사항을 적도록 했다. 예를 들면 브랜치 이름이 feature/something 이라면 feature/something-1 이런 식으로 하나 더 나누고 MR 을 할 때는 기존의 feature/something 으로 병합하는 방식으로 진행했다.
  특히, ‘양이 상당히 많을 때’ 의 기준이 코드의 길이나 파일의 개수 등 사람마다 달랐기 때문에 가능하면 작은 기능 단위로 쪼개고, 정 힘들 것 같으면 다른 사람들이 코드 리뷰를 할 때 이런 점을 더 확인했으면 좋겠다는 의미로 핵심사항을 내용에 직접 적을 수 있도록 했다.
• MR 을 만들고 나면 되도록 팀원 전체가 참여하되 적어도 한 명 이상의 Approve 가 있다면 Merge 를 하는 방향으로 진행했다. 특히, GIT 저장소로 설치형 GITLAB 의 무료 버전을 사용했는데 Merge Request 에서 Merge 를 함부로 제한하는 기능이 없어 다른 사람이 Approve 를 하지 않아도 바로 Merge 가 가능했다. 또한, MR 에 너무 묶이지 않되 서비스 개선을 위한 버그 수정과 신규 기능 구현 작업 등 기존 업무를 무리없이 진행하도록 하기 위해서 적어도 최소 한 명이라도 다른 팀원들의 작업 결과물을 확인해야 Merge 할 수 있도록 했다. 긴급 상황일 경우에는 먼저 Merge 하고 이를 팀 내부에 전체 공유하도록 해서 나중에 리뷰를 진행할 수 있도록 했다.
• 말에 감정은 담지 않되 가능하면 합리적이고 객관적인 이유를 들어서 말하도록 했다. 예를 들면, 더 좋은 기술이 있어서 이것을 사용하면 어떤 이유에서 좋고, 기존 코드의 이런 부분을 좀 더 보완할 수 있을 것 같다는 식으로 작성함으로써 감정보다는 근거나 이유를 들어 되도록 가능하면 합리적으로 이야기할 수 있도록 했다.
• 코드 리뷰는 주로 온라인에서 진행하며 MR 확인 요청(Slack 으로 진행)이 오면 바로바로 각자 확인할 수 있도록 했다. 양이 많은 것 같고 업무 시간에 진행하기 힘들면 점섬 시간에 천천히 보도록 정했다. 온라인에서 설명하기 힘든 부분은 따로 회의실을 잡고 개발팀 주간 업무 보고 이후에 오프라인에서 같이 코드 리뷰를 진행하기로 했다.

근데, 회사에서는 PHP4 를 포함해서 정말 방대한 양의 PHP 코드를 다루어야 했다. 특히, 언어적인 한계(try-catch 가 없는 PHP4 나 namespace 를 사용하지 못하는 경우 등)나 프레임워크, 디자인패턴이 전혀 없는 코드(프론트와 벡엔드 코드가 서로 섞인 경우 등)가 많았다. 개선하자는 말은 쉬운데 행동으로는 쉽지가 않아서 이런 경우처럼 기존에 있던 PHP 프로젝트를 진행할 때는 자유롭게 코드를 작성하긴 하되 적어도 다른 사람들이 이해할 수 있도록 주석을 작성하거나 네이밍, 프로세스 흐름에만 신경써서 진행하도록 했다.

 

Java 로 작성된 Spring 신규 프로젝트는 그래도 서로 컨벤션을 만들고 제안하고, 리팩토링하면서 비교적 잘 지켜졌다. 이 외에는 다양한 언어와 기술 스택을 기반으로 작업된 프로젝트들은 없었기 때문에 이 부분에 대한 부담감은 적었다.

 

대부분 GIT 으로 이전하였으나 SVN 을 어쩔 수 없이 사용하는 저장소(사내 공용 저장소)는 Redmine 의 '저장소' 파일 비교로 확인하는 방식으로 이루어졌다. 이런 작업은 잘 없었지만 보통은 커밋 후 배포 전 Slack 으로 확인 요청하도록 진행하였고, 언급할 사항이 있으면 스레드를 만들어서 진행했다.

 

이렇게 코드 리뷰 문화를 만들고 이후에 느낀 점은 아래와 같다.

• 업무 내용을 공유할 수 있는 기회가 많이 생겼다.
  팀원 모두가 방대한 레거시 코드들을 잘 알고 있는 사람이 없었다. 이번에 무엇을 위해 어떤 위치에, 어떤 파일에, 해당 코드를 작성했는지를 미리 서로 알 수 있는 기회가 많아졌다.
  팀원 중에 누군가가 작업했던 코드를 다른 사람이 수정했다면 작성자가 미리 코드를 검토할 수 있게 되었고, 다른 사람 또한 해당 기능의 이해 또한 높일 수 있었다.
• 코드 퀼리티를 조금이나마 높일 수 있었다.
  길게 적은 코드를 짧은 코드로 바꿀 수 있던지, 추상화, 라이브러리, Snippet 등 개발자가 알지 못했던 부분이나 자기가 알고 있는 지식을 서로 의견을 나눔으로써 성장할 수 있는 기회가 이전보다 많아졌다.
• 대소문자, 잘못된 단어 이름, 오타 체크 등을 사전에 다른 사람들이 보고 판단할 수 있는 기회가 생겼다.
  다른 사람들이 미리 코드를 보고 지적하며 실수를 줄이는 경우가 늘었다.
• 서로가 의지를 가지고 있을 때 더 효과적으로 진행된다는 것을 알았다.
  코드리뷰를 통해 얻는 점은 많지만 개개인의 의지에 따라, 리뷰어에 따라서도 리뷰 퀼리티가 달라질 수 있다는 것을 알았다. PHP를 주로 하는 분들은 Java Spring Boot 코드리뷰 작성에 아무래도 한계가 있어보였다. 코드리뷰를 할 때 서로 의지를 갖고 진행하는 사람들이 많으면 상대적으로 더 좋은 결과를 낼 수 있다고 생각했다.