효과적인 코드 리뷰를 향한 여정 (ft. aws codecommit, space)

 

 

현재 제가 몸담고있는 개발팀에서는 space라는 리뷰툴을 활용해 코드리뷰 진행 검토를 진행중입니다.

space 라는 툴이 선택되기까지 정말 많은 과정이 있었고, 그럼에도 불구하고 아직 개선하고 정해야할 프로세스도 많습니다.

제가 저희 조직에 도입하기 위해 거쳐온 이 경험들이 얕은 경험에 불과할 수도 있겠지만,

아직 코드 리뷰를 정착하지 않은 팀이나 조직이 있다면 중간 공유가 인사이트가 될 수도 있을 것 같아 사용 후기를 공유합니다.

 

---

왜 space 를 쓰게 되었나

처음엔 flow task로 pull request 시작.

작년 이맘때쯤까지 저희 팀에서는 플로우 협업툴 업무 게시글을 활용한 pull request 를 진행했었습니다.

하지만 당시에는 아래와 같은 문제로 인해 자~연 스럽게 역사속으로 사라졌습니다.

• 요청자가 브랜치와 커밋메시지 등을 다시 복사해서 직접 타이핑 해야한다는 번거로움
• 요청받은 사람이 브랜치 병합까지 책임지고 해줘야한다는 점
• 그 요청자도 다른 개발을 병행하고 있다는 점
• 그럼에도 불구하고 그 사람이 병합해줄때까지 요청자는 대기해야 한다는 점

물론, 자동화된 병합 과정이 없었던 점도 있지만 이때는 코드리뷰에 대한 그라운드 룰이나 규칙도 없었기 때문에 더 번거롭게 느껴졌던 것도 있던 것 같습니다.

 

그라운드 룰 및 규칙 정의

그래서 그 이후에는 그라운드 룰을 먼저 만들어 구성원들에게 전파하는 것을 시도해봤습니다.

코드리뷰에 대한 필요성을 인지하고있던 팀원들과 모여 논의한 내용을 바탕으로 작성했고, 대면으로 모여 리뷰를 받는 방법을 시도했던 것 같습니다. 하지만 이또한 역사속으로 사라졌습니다.

• 대면으로 진행하니 생각보다 말이 길어지면 한 명의 리뷰에 많은 시간이 소요된다.
• 개개인의 의견을 모두 발언하게되어 공개적으로 공격당하는 기분을 느끼게 한다.
• 작은 단위의 코드리뷰보다는 큰 기능 단위의 코드리뷰만 진행하게 되고, 설계에 대한 피드백만 하게 된다.

 

AWS Codecommit 시작

업무 게시글로 개발내용을 옮기는 작업은 ‘업무를 위한 업무’를 늘리는 과정일 수도 있을 것 같고,

대면으로 진행하는 것 또한 '회의'를 늘리는 것 같다는 생각이 들어

그 다음에는 우리의 소스저장소인 codecommit 에서 제공하는 풀 요청 기능을 사용하기 시작했습니다.

이전과는 달리 요청받는 즉시 소스를 직접 확인할 수도 있었고, 인프라팀의 지원으로 풀리퀘 요청시 플로우 게시글로 모니터링봇이 알림을 울려주도록 작업해서 어느정도 개선된 코드리뷰가 가능해졌습니다.

 

하지만

• 항상 aws codecommit 에 로그인해야한다. (2 factor 인증 필요)
• 수정 부분에 대한 구체적인 개선 제안이나 실시간 소통이 불가하다.
• 긴 파일의 경우엔 전체를 다 못보여주고 수정부분만 보여줘서 흐름 파악이 어려운 경우도 있다.

 

결국 채팅을 활용하기 시작

번거롭고 불편한 과정에 못이긴 우리는 그렇게 돌고 돌아….

요청하기는 쉽지만 들어주기는 힘들다는 ‘채팅으로 물어보기’ 방법을 선택하게 되었죠 ㅠㅠ

 

 

그렇게, space 도입!

소스 복잡도도 높아지고 사람도 많아지고 바쁘면 바쁠수록 리뷰할거리도 많아지는 이 상황에서,

채팅방식의 리뷰 프로세스는 또 다른 병목을 불러올 수도 있고 분명한 개선의 여지가 있다고 생각되어 space 도입을 제안했습니다.

모든 기능을 소개하는건 크게 의미가 없을테니, 저희 팀이 사용하기에 어땠는지 장단점만 소개해보겠습니다.

 

장점

1. 오프라인으로 봐달라고 하기 애매한 상황에 활용하기 좋다.

아래와 같이 직접 봐달라고 요청하기 애매한 상황들에서는 스페이스에 올려놓고 요청하면 시간이 날 때 봐줄 수 있어 요청하기에 부담이 덜하다는 의견이 있었습니다.

1. 봐달라고 요청하기도 민망한 짧은 코드 (하지만 소스 결합도가 높아서 한줄만 고쳐도 치명적일 수 있는 부분) 한줄 요청하기 
2. 사무실에서 만나기 어려운 사람의 코드
   • ‘이거 A님이 작업하신 것 같은데 어디계세요?’ ⇒ ‘오전 출장이에요~’ ⇒ ‘음.. 네’
3. 누가봐도 바빠보이는 개발자 or 상급자한테 무조건 컨펌을 받아야할것만 같은 코드인 경우
   • “급한 업무 마무리 되시면 스페이스에 올려놨는데 시간날때 봐주세요!”

 

2. 굳이 시간을 맞춰서 회의실을 잡고 준비를 하지 않아도 쉽게 여러명의 의견을 공유할 수 있다.

기능 단위가 크거나 작업이 큰 경우에는 오프라인으로 회의실을 잡고 리뷰를 하곤 하는데, 스페이스에서는 본인이 수정한 의도와 지점을 표기 가능해서 온라인으로도 소통이 가능하다는 장점이 있습니다.

1. 소스와 함께 히스토리를 적어둘 수 있어서 업무인계 or 기능단위 등 큰 작업량도 리뷰하기 좋다.
2. (성격이 급한 개발자라면) 오프라인 리뷰를 듣다보면 ‘음… 자리에 가서 코드로 직접 보고싶다…’ 라는 생각이 들기 마련인데, 이런 부분이 자유롭다.
3. (직접 고쳐보고싶은 개발자라면) 리뷰를 요청한 사람에게 직접 코드를 수정해서 제안 할 수 있다.

 

 

3. intellij 와 연동이 가능하다.

작업하는 과정에서 소스의 어느 부분을 누가 왜 고쳤고 누가 리뷰해줬었는지를 바로 확인할 수 있습니다.

• codecommit 의 단점이 space 에서 보완되는 이유!
  • 몇몇 레거시 파일은 길어서 전체를 다 못보여주고 수정부분만 보여주는데, space 는 intellij 내에서 확인할 수 있으니 바로바로 연관소스를 확인하기 좋다.
  • 리뷰를 보면서 git history를 동시에 볼 수 있다.
  • 알림이 온다.
  • 가독성이 좋다.

4. 모바일이 지원된다.

이 모든 과정이 모바일에서도 가능합니다.

 

5. 승인규칙만 맞춰지면 병합을 자동으로 해준다.

그리고 최종 병합된 브랜치는 리모트에서 자동으로 날려주는 기능이 있습니다.

6. (아직까진) 강제성이 없다. 따라서 도메인 지식을 공유할 수도, 예측가능한 오류를 발견해 줄 수도, 혹은 클린한 코드를 제안해 줄 수도 있다.

아직까진 리뷰 범위에 대한 제한이 없고 강제성도 없기때문에, 자유로운 의견 공유가 가능합니다.

 

단점

1. 유료다.
2. intellij 안에서 모든걸 해결하려면 처음 세팅이 오래걸린다.
   • 일단 git clone 을 다시 받아야하고 프로젝트 세팅을 다시해야합니다.
3. 위 과정이 번거로워서 space 제공 앱을 활용하게 되고, space 제공 앱은 최신화가 바로바로 안된다.
4. 기존에 개인 브랜치를 따서 작업하는게 습관이 안되어있는 사람은 초반에 번거롭게 느껴질 수 있다.

 

 

향후에 어떻게 활용하면 더 좋을까

아직까지는 제대로 사용한지 1달밖에 되지않아, 정착시키기까지는 모두의 노력이 필요한데요

미리 사용해본 사람들의 의견으로는 향후에 아래의 보완과정이 필요하다고 생각되었습니다.

 

1. 규칙속의 자유가 필요하다.

아직까진 너무 자유롭게 툴을 활용하다보니, 바쁘면 그냥 병합하고, 푸시하는 경우가 더 많은게 현실입니다. 만약 더 철저한 리뷰과정이 필요하다고 느끼는 시기가 온다면 조금의 규칙이라도 더해지면 좋을 것 같습니다.

• 예시
  • release 기간에는 무조건 리뷰요청 올리기
  • 배포 전 3일간 병합되는 모든 소스는 space 에 올리기
  • 2인 이상 승인자로 지정하기
  • 3일 내에 리뷰 못해줄 것 같다면 다른 리뷰어 지정해주기 등

 

2. 컨벤션에 대한 논의의 장으로 쓰이면 좋을 것 같다.

코딩 컨벤션이 없는 상태에서 리뷰를 진행하니, 개인의 의견이 강요가 될까봐 남기기가 꺼려진다는 의견도 있었습니다. 하지만 일단은 자유롭게 의견을 교류하고, 그 교류를 통해 더 나은 컨벤션을 만들어가는 토론의 장으로 스페이스를 활용해도 좋을 것 같습니다!

물론, 당연하지만 가능하면 젠틀하고 완곡하게 의견을 교류해야 생산적인 논의가 이뤄지겠죠 🙂

 

3. 지식의 저주에 빠지면 안된다.

코드리뷰를 하다보면 자신이 알고 있는 지식을 다른사람도 당연히 알고있을 것이라 생각하는 인식적 차이나 오류를 스스로 느끼게 됩니다. 혹은 본인에게만 당연한 지식을 무분별하게 늘어놓으며 자신의 저주를 드러낼 수도 있죠.

또한 이상적으로 클린한 코드, 유지보수하기 편한 코드, 물론 다 좋지만 이상에 사로잡혀 끝도 없이 리뷰하고 수정하다 로컬 브랜치에 잠자는 소스가 생기거나 병합이 늦어지는 경우도 발생할 수 있는데요.

병목이 병목을 만들어내는 상황을 피하기 위해서는 지식에 저주에 빠지지 않도록 스스로의 규칙과 관리가 필요합니다.

• 예시
  • 리뷰 의견 중 부정의견 3개 이상이 포함되면 close 후 코드를 다시 고민해본다.
  • 리뷰를 남길때는 두번 세번 다시 이유를 묻지 않아도 모두가 이해할 수 있도록 남기려고 노력한다.
  • 작업 전에 기능을 위한 필수적인 작업과, 코드 개선을 위한 작업의 목표 비중을 미리 세운다.

 

---

 

사실 코드 리뷰의 이상적인 정착지는 어디인지, 1년 가까이 코드 리뷰 문화를 위해 힘쓰고 있는 저와 팀원들도 아직 물음표인게 사실입니다...ㅠ

그래서 여기에 공유한 경험이 앞으로 저희 팀에 긍정적으로 확대될 수도 아닐 수도 있지만,

적어도 이 노력들이 다른 개발자들의 리뷰과정에서의 시행착오를 줄여주고 더 좋은 개발 문화를 만들어 가는데에 보탬이 되었으면 좋겠는 바람입니다.

 

그리고 이 글을 읽으시는 누군가의 팀에 좋은 영향을 줄 수 있었으면 좋겠네요!

더 좋은 의견이나 방법으로 코드 리뷰 문화를 만들어가고 계신 분들이 있다면 댓글 남겨주시면 큰 도움이 될 것 같습니다.

 

감사합니다.