인프콘 2022 - 코드 리뷰의 또 다른 접근 방법: Pull Requests vs Stacked Changes

🧀 코드 리뷰의 또 다른 접근 방법: Pull Requests vs. Stacked Changes - 치즈(서지연)님

Graphite를 이용한 Stacked Changes 형상관리 방법 소개와, Stacked Changes 가 현업에서 잘 어울리는 이유에 대한 이야기.

🧀 코드 리뷰를 잘 한다는 것?

코드리뷰는 꼭 해야한다. 요즘 개발자들 사이에서 ‘코드리뷰를 왜 해야하는지’ 설명은 필요없다. 당연히 해야한다는 걸 모두가 공감하고 있다. 그렇다면 ‘코드 리뷰를 잘 한다’는 건 무엇일까? 잘 되는(좋은) 코드 리뷰의 특징들은 아래와 같다.

• 적당한 크기의 코드 변경 : 코드 변경이 작을 수록 작업이 명확하게 파악된다.
• 작업 명확성 : 작업이 명확할수록 리뷰어도 리뷰하기 쉽다.
• 빠른 속도 : 그럴 수록 모두의 작업 속도가 빨리진다.

코드 리뷰를 잘 한다는 건, 리뷰어가 리뷰를 잘 하는 것 뿐만 아니라 리뷰이가 리뷰를 잘 받을 준비까지 하는 것. 리뷰어와 리뷰이를 다르게 생각하지 않고 하나로 묶어 생각하는 것. 아하. 코드리뷰를 잘 해줄 생각만 했지, 잘 받아볼 생각은 못한거 같다.

여기까지도 충분히 알 수 있다! 그런데 현업에서는 왜 실천하기 어려운걸까?

🧀 Pull Request 관점에서의 코드 리뷰 (PR의 아쉬운점)

“댓글 기능을 만들어주세요” 라는 요구사항이 전달되었다고 가정해보자.

1. 댓글 생성 API endpoint 추가
2. 백엔드 로직 추가
3. 프론트엔드 댓글 컴포넌트 추가

여러가지 작업을 거치면서 작업 내용을 커밋하고, PR을 올려보면 오른쪽 상단에 +1500/-200 라인 수를 확인할 수 있을 것이다. 리뷰이는 눈치가 보이지만 작업 내용을 반영해야하므로 PR을 올린 채 하염없이 기다리고, 리뷰어는 거대한 라인 수에 당황하여 리뷰를 미룬다.

• 리뷰이: “도대체 언제 리뷰해주는거야…”
• 리뷰어: “도대체 어디부터 봐야하는거야…”

결국 PR에 남는 리뷰는 “LGTM”. 10줄의 작업엔 많은 리뷰가 달리지만, 500줄의 작업엔 LGTM 만 달린다.

우리가 개발을 진행할 땐 수 많은 고민들과 커밋들이 녹아 들어간다. 그러나 실질적으로 리뷰어가 만나는 건 PR 이름과 file changed 뿐. 실제로 commit 명을 읽지 않고 곧바로 file changed에 달려들어 집중하는 리뷰어들이 많다.

헉! 내 모습이 아닌가? 😳

작업 단위가 커지면 리뷰가 느려지고, 다른 작업과의 충돌 가능성이 높아지고 코드 롤백시 모든 작업이 함께 롤백된다. 심적 부담감도 증가하고, 점점 하기가 싫어진다… 뾰족한 해결책이 없을까?

🧀 Stacked Changes 관점에서의 코드리뷰

“댓글 기능을 만들어주세요” 라는 요구사항을 다시 처음부터 생각해보자.

커밋 흐름을 좌에서 우가 아닌 상에서 하로 바꿔보자.

작업 위에 다른 작업. 그 위에 다른 작업. 바로 Stack Diff 방식이다.

각각을 커밋이 아닌 작업 단위로 보기 때문에 PR을 올렸을 때 보이는 코드 변경의 크기가 작아진다. 코드 변경 크기가 작아지면? 작업의 명확성이 높아지고, 리뷰 속도가 빨라진다. 각 커밋(작업)마다 변경을 한 눈에 살펴볼 수 있기 때문에!

이 좋은 Stack Diff를 활용해볼 수 있는 툴들이 여러가지 존재한다. 구글의 Gerrit, 메타의 phabricator. 그러나 phabricator는 작년 중순부터 관리가 멈췄다. 그리고 Gerrit, phabricator 모두 Github과 그리 친화적이지 않다. 어차피 나를 제외한 모든 팀원들은 Github이 익숙하고, Github 만을 사용할텐데… 현업에서 Stack Diff를 써볼 순 없을까?

🧀 Graphite

그런 당신을 위해 준비했습니다! open-course CLI and code review dashboard. Graphite! 무려 Github과 친화적인 프로그램이다. PR을 올릴 때 각 Stack 별 변경사항(작업) 단위로 나누어 PR을 생성한다. 커밋이 4개일 경우 Github PR이 4개로 나뉘어 올라가는 것이다.

지금까지의 설명을 보면 Stack diff 방식은 익숙하지 않을 뿐, 장점만 가지고 있는 것 같다. 그럼 Github은 이 좋은 Stack diff 방식을 왜 채택하지 않는 걸까? 바로 커뮤니티 성격 때문이다.

• Github : 오픈소스 중심, 전 세계를 아우르는 커뮤니티 오픈소스의 규모가 커질수록 기민한 활동이 어려우므로.
• Grahite : 팀 내과 내 동료, 내 옆자리 사람들과의 커뮤니티. 팀원들 사이에서는 기민한 활동이 가능하므로.

결국 현업에서 1,000줄의 변경을 1번에 리뷰할 것인지, 100줄의 변경을 10번 리뷰할 것인지, 선택은 나의 몫이다. 가장 중요한건 코드리뷰는 함께하는 것, 중요한건 공감이다.

🧀 후기

치즈님의 발표를 듣고 당장 Graphite를 적용해보고자 생각했지만(팀원을 설득할 필요 없이 나만 쓸 수 있으므로), 2가지 이유로 결국 적용을 미루고 있다.

1. 리뷰어들이 꼭 작업 순서대로 PR을 리뷰해준다는 법이 없다.
2. 하나의 작업 단위당 많은 코드 변경이 부담된다면, 작업 단위를 더 잘게 쪼개는 연습을 해야할거 같다.

Graphite 가 더 기민하고 명확한 코드리뷰를 도와주는 툴은 맞지만, 근본적으로 작업 단위를 더 작게 가져간다면 꼭 Graphite를 이용하지 않아도 될 것 같았다. 작업단위를 작게 잘 쪼갠 후 Jira 티켓을 만들면 팀원들도 내가 어떤 작업을 하고 있는지 파악하기 쉽고… 조금 더 두고 본 후 사용해봐야겠다.