팀에 맞는 코드 리뷰 최적화를 시도해보자
1주차에 10개의 PR을 검토했고, 한 PR당 최소 2시간에서 최대 4시간이 걸렸다. 프로젝트 시작 전부터 코드 리뷰를 중요하게 생각했지만, 실제로 기능 구현 못지않게 많은 시간이 필요했다. 그래서 최근 팀의 코드 리뷰 방식에 대해 고민이 많았다. 리뷰가 효율적으로 이뤄지고 있는지, 정말 중요한 부분에 집중하고 있는지 궁금했다.
팀원들도 더 생산적인 코드 리뷰의 필요성에 공감했다. 이렇게 고민하고 주변에 의견을 구하거나, 구글링을 하면서 얻은 인사이트들도 있었다. 그래서 개선점을 나누고 바로 적용해보기로 했다. 단지 시간이 오래 걸리는 것를 문제라 보기 어려워서, 원인을 먼저 보려고 했다.
코드의 일관성을 지키고 최대한 많은 버그를 사전에 잡아내는 것이 초기 목표였다. 변수명 네이밍에 대해 치열하게 토론하고, 모든 에러 케이스를 꼼꼼히 확인했다. 코드 레벨에서는 공식 문서를 근거로 제시하고, 구체적인 코드를 제안할 때는 직접 동작을 검증했다. 리뷰어로서 충분한 검증 없이는 코멘트를 남기지 않으려 했다. 특히 백엔드 코드는 처음이라 학습도 병행해야 했다. ‘한 치의 오류도 흘려보내지 않겠다’는 마음가짐으로 시작했지만, 리뷰어에게 큰 부담이 되었고 시간이 오래 걸릴 수밖에 없었다.
팀과 논의 끝에 큰 방향성 위주로 보는 것이 더 필요하다는 데 의견이 모아졌다. 변수명이나 사소한 부분에 매몰되어 있진 않은지 돌아보게 되었다. 네이밍이나 컨벤션은 가장 쉽게 할 수 있는 리뷰 중 하나지만, 이런 부분에 지나치게 사로잡히지 않는 것이 중요했다.
코드를 line by line으로 보는 것도 의미가 있지만, 이것이 항상 최선은 아니라는 것을 깨달았다. 동료 간 신뢰를 바탕으로 한 커뮤니케이션이 중요한데, 때로는 이런 세세한 리뷰가 마이크로 매니징으로 받아들여질 수 있다는 점도 배웠다. 가장 중요한 건 본인이 꼼꼼히 점검하고 PR을 요청하는 것이라는 점도 확실하게 했다. 또한 일부 문제들은 QA 단계에서 발견할 수 있다는 것을 인정하고, 각 단계의 목적에 맞게 역할을 분리하기로 했다.
이러한 레슨으로 가장 먼저 실행해본 것이 팀 내 변수명 컨벤션을 정하는 일이었다. 기본적인 사항이지만, 우리는 이 컨벤션의 중요성을 경험을 통해 깨닫게 되었다. 반복되는 코드 리뷰 코멘트를 줄이고, 더 중요한 부분에 집중하기 위함이었다.
팀원들과 함께 변수명 기준을 하나씩 정했고, 나부터 이 기준들을 적극적으로 활용하고 있다. 코드를 작성할 때 고민하는 시간도 줄었다. 프로젝트가 끝나면 컨벤션 관련 리뷰 수가 얼마나 감소했는지 측정해볼 계획이다. 이를 통해 우리의 개선이 실제로 효과가 있었는지 확인할 수 있을 것이다.
팀 작업에서 리뷰 지연은 전체 일정에 부정적인 영향을 미친다. 처음에는 구현에 몰입하느라 리뷰를 뒤로 미루고, 늦은 밤이나 새벽에 하려다 보니 무기한 지연되는 경우가 있었다. 이 문제를 개선하기 위해, 우리만의 PR 리뷰 마감 요청시간 제도를 시도했다.
예측 가능성을 높이기 위해 PR에 리뷰 가능 시간과 희망 완료 시간을 명시하도록 규칙을 정했다. 이렇게 서로의 기대치를 최대한 일치시키려 노력했다. 여유가 있을 때는 PR이 올라오기 전에 해당 기능의 로직을 미리 구상해보기도 했는데, 마치 알고리즘 문제를 풀 때처럼 다양한 해결 방법을 고민해볼 수 있었다.👍
처음으로 다른 사람의 코드를 리뷰하면서 서툰 부분도 많았지만, 시행착오를 거치며 내게 맞는 몇 가지 방법들을 발견하게 되었다.
PR 규모가 가급적 작으면 좋지만, 현실에서 지켜지기란 쉽지 않았다. 그래서 변동사항이 있는 여러 파일 중 어떤 파일 부터 보는게 좋을지 고민이 많이 되었다. 현재까지 경험으로는 어중간한 위계의 파일을 보면, 해당 PR의 목적이나 전체 흐름을 보기 어려웠다. 가장 상위 파일 혹은 가장 작은 파일부터 보는 것이 전체 흐름을 파악하는 데 효과적인 경우가 있었다.
상위 파일부터 보면 이러한 장점이 있었다. 상위 파일은 주요 컴포넌트를 포함할 가능성이 높으므로 전체 구조 변경을 한눈에 파악하기 쉽다. 또 하위 파일 및 컴포넌트들의 역할을 문맥상 이해하는데 도움을 주었다. (특히 상태 끌어올리기 등 컴포넌트간 데이터가 공유된 경우에 더욱 유용하다)
작은 파일부터 보는 것도 때로는 유용했다. 작은 단위 컴포넌트의 역할이 무엇인지 먼저 확인이 필요할 때 주로 이 방식을 택했다. 특히 독립적인 기능 단위로 빠르게 리뷰가 필요하거나, 큰 틀에서 변화가 없는 경우에는 이렇게 접근했다. 작은 단위부터 이해하고 큰 그림으로 확장해나가는 식이다.
찾아보니 이미 많은 개발자들이 사용하는 방법이었지만, 나는 혼자 고민하다 운 좋게 발견했다. 처음에는 PR 제목과 설명만 보고 바로 코드를 검토했는데, 커밋 히스토리를 먼저 보는 것이 더 효과적이었다. PR 리뷰의 본질은 변동사항을 검토하는 것인데, 커밋은 이러한 변동사항을 추상화해서 보여주기 때문이다.
As-is
코드 변경사항 (복잡) ──> PR 설명
ProductDetail/index.tsx
useInfiniteScroll.ts 신규 작성
ProductInfo/index.tsx 수정
// 100줄 이상의 코드++...To-be 코드 변경사항 (복잡) ──> 커밋 메시지 (추상화) ──> PR 설명
1. feat: 무한 스크롤 로직 구현
2. feat: 상품 목록 컴포넌트에 무한 스크롤 적용
3. refactor: 상품 정보 컴포넌트 분리이 방식은 코드의 맥락을 빠르게 파악하게 해주었고, 다른 구조나 로직으로도 구현할 수 있을지 고민하는 데 도움이 되었다. 내가 커밋을 작성할 때도 영향을 미쳤는데, 한 문장으로 코드의 맥락을 전달할 수 있는 커밋 메시지의 중요성을 깨닫게 했다. 제3자도 커밋 메시지 한 줄로 코드의 맥락을 이해할 수 있게 하는 것, 이것도 중요한 능력이다.
스스로 무엇 부터 리뷰할지 우선순위를 정하는 것이 중요했다. 그렇지 않으면 구조를 검토했다가, 가독성 측면에서 검토할 부분이 보이면 몰입이 깨지기 쉽다. 결국 “구조 > 로직 > 가독성/문법” 순으로 검토하기로 했고, 특히 컴포넌트 간의 관계를 먼저 파악한 뒤 상태 관리나 렌더링 관련 부분을 중점적으로 보는 패턴을 만들었다. 이 과정에서 JavaScript의 얕은 비교 등 기본 개념들이 정확한 리뷰를 위해 꼭 필요하다는 것도 알게 되었다. (평소에 더 제대로 알아둬야 함)
아직 갈 길이 멀다. 다음 팀 프로젝트를 한다면 내가 어떻게 기여할 수 있을지 기대가 된다. 또 새로운 팀원과 협업하면서 배울 수 있는 점들도… 이번 기회로 낯선 코드, 패턴과 새로운 사고방식을 고민하게 해준 두 팀원에게 감사하다!
#팀프로젝트 #코드리뷰 #프론트엔드