온라인 코드 리뷰에 대해서

코드 리뷰.

말만 들어도 시간도 많이 쓰고, 리뷰 중에 삼천포로 빠지기 쉬운 그런 절차. 졸려서 반쯤 잠든 상태에서 동의 하는척하고, 나중에 이 코드 누가짰냐고 리뷰때 건너뛴 코드 아니냐고 말하기 쉬운 절차. 그래서 몇번씩 오프라인 코드 리뷰를 하다가, 바빠지면 건너뛰고 그러다보면 자연스레 흐지부지되곤 하는 바로 그 절차다.

또한 눈에 보이지 않는 효과를 동반하기에, 우선 순위에서도 밀리기 쉽상이다.

이런 심리적 저항들을 이겨낸 뒤 의지를 가지고 시작하지만, 오래 가지 않아 다른 회의에 밀리고, 휴가자 많다고 취소하고, 리뷰 할만한 내용도 없었다고 취소된다.


프로그래머들 사이에서도 여러가지 합의가 필요하다고 생각하는데, 나는 계획(=설계)와 디테일에 대한 장단점에서의 기술 결정, 기획적인 결정에 대한 해석과 같은 것들이다.

그리고 실제 구현된 결과물에 대한 검수라고 할 수 있다.

이 과정들 대부분 온라인으로 인터럽트를 최소화 할 수 있는 방법이 있는데, 그 중에서도 검토 과정인 코드리뷰에 대해서 말해보고자 한다.


내 개인적인 경험상으로만 비춰보자면 웹 개발보다 게임 개발의 경우, 작업량이 좀 더 많았다. 정확히는 업무량의 의미보다도 코드량의 의미에 더 가깝다고도 볼 수 있겠다.

특히 프로젝트 빌드업 단계에서는 코드 변화량이 압도적으로 많았고, 구조에 변경을 가하거나, 대 규모 컨텐츠 작업, 연관성이 깊은 컨텐츠 작업의 개별 진행과 같은 상황들로 인해 더 많기도 했다.

또한 버전 관리 시스템에 추가되는 부산물도 좀 더 많았다.

예를 들어, 마스터데이터, 설정 데이터, 메타 데이터 등으로 불리우는 기획팀의 테이블 데이터라거나, 유니티의 meta 파일, prefab 파일 등이 그렇다.

참고로 당시 회사에서는 gitea를 사용하고있는데, 코드 리뷰 대상에 text 기반 부산물과 같은 파일에는 diff 대상으로 포함되어 코드만 선별해야되는 불편함이 있다.

슬픈 현실이지만, 업무량이 많다보니, 코드리뷰가 강제 될 경우 업무 속도 지연에 대한 불만이 나오곤했다.

또한 많은 부분의 업무가 격리되어 진행되기보다는, 유사한 부분의 코드를 접근해야 하는 일이 많았는데, 브랜치를 강제화 할 경우 다수의 코드 conflrict를 해소하는 일이 쉽지 않다보니, 메인 branch에 잦은 merge를 통한 conflict 최소화를 해야 되는 경우도 많았다.

애초에 git이던 svn이던 같은 문제를 갖고 있는 것이긴 하지만, 많은 충돌을 처리해야 될 만큼 변화량이 많을 경우에는 통합 비용과 사이드 이펙트가 작지 않은데, 이 변화량이 게임이 훨씬 더 많기 때문이라고 볼 수 있다.


github에서는 pull request, gitlab에서는 merge request라 부르는 이 과정은, 메인 브랜치에 허용되지 않은 커밋을 방지함으로써 코드의 안정성을 확보하는 절차라 볼 수 있다. 또한 메인 브랜치를 protect를 거는 것이 좋다고 생각하지만, 변화가 잦은 조직일수록 그렇게 운용하긴 어려운 것 같다.

코드 리뷰를 강제화 한다면 모든 변화를 감지하고, 검수할 수만 있다면 장애나 오류도 미연에 방지할 확률이 높아진다.

또한 큰 기능적으로는 이슈가 없지만, 기존 규칙을 위배한다거나, 오타, 개선이 필요한 작업들을 체크하고, 수정 작업이 완료된 상태에서 들어올 수 있어서, 메인 브랜치가 자칫 깨진 창문이 되는 일을 방지해주기도 한다.


기본적으로 코드 리뷰가 시점마다 다른 피드백이 가게 되어있다.

프로젝트 빌드업 단계

  • 큰 틀을 이해 시키려는 피드백
  • 빠른 구현을 위해 기술 부채를 일부 용인하는 검수

프로젝트 출시 막바지 단계

  • 기능을 수정하는 데에 포커스 맞춘 피드백
  • 만기일을 맞추기 위한 기술 부채를 용인하는 검수

프로젝트 라이브 단계

  • 안정성을 최우선으로 한 피드백
  • 기존 규칙을 깨지 않는 것을 우선으로 하는 피드백
  • 기술 부채를 가급적 줄이려는 검수
  • 기술 부채를 없애려는 일감 진행이라면, 정말 기술 부채가 줄어드는지에 대한 관점에서의 피드백. (과한 코스트 소모 혹은 더 나빠지지 않는지 등)

코드 리뷰는 어떤 수준까지, 어떤 접근으로, 어떤 방식으로 작업 해 나가야 하는지에 대한 피드백이 오가는게 맞다.

어떠한 가치와 철학으로 생각을 맞춰 나가야 하는지에 대한 공감대를 이뤄내지 못한채 코드 리뷰에 돌입하게 되면, 큰 의미 없는 리뷰나 개인의 취향이 묻어나는 리뷰로 인해 불필요한 토론으로 시간 낭비와 감정 소모만 이어지기 쉽다는 점도 염두에 두어야 한다.

기본적으로 코드 리뷰에서의 핵심은 실수를 잡아주고, 접근 방식에 대한 질의 응답, 구현 사항이 충실한지에 대한 검토, 개선 사항 제안 같은 것을 체크하는 과정으로 여겨지는 것이 좋다.


온라인 코드 리뷰를 해보니 확실히 부담이 적고, 내가 원하는 때에 봐도 되니까 오프라인 코드 리뷰에 비해 장점이 많았다.

다만 변경 사항이 빠르게 적용되어야 하는 경우에는 오프라인 리뷰와 다를바 없긴했으나, 기록이 남는다는 점에서의 장점은 있었다.

협업 자체도 브랜치에서 공동으로 이루어져야 하는데, 이는 많은 변경량이 브랜치에서 발생할 수도 있다는 의미이다.

그리고 메인 브랜치나 다른 브랜치에서의 변경 사항이 작업 중인 브랜치에 적용되어야 할 경우 매우 복잡한 머지 과정을 겪어야하기에 큰 혼란을 겪을 여지가 있다.

동시 다발적인 작업 진행이 많을 수록 자연스레 겪는 이슈인데, 이에 대한 해결책이나 작업 규칙 준수, 브랜치 작업 방식의 단순화 등은 온라인 코드 리뷰와 별개로 해소되어야 할 이슈이고, 공동 작업 이슈가 해소되고 난 뒤라면 더더욱 온라인 코드 리뷰가 빛을 발하게 된다.

코드 리뷰를 아직 하지 않고 있다면 코드 리뷰 부터, 오프라인 코드 리뷰만 하고 있다면 온라인 코드 리뷰를 시작하고 그 양을 좀 더 늘려 보는게 어떨까?

온라인 코드 리뷰 중 오프라인 질의 응답이 길어진다면 PR에 설명이 부족한건 아닌지 고민해보자.

Comments

comments powered by Disqus