내일배움캠프 121일차 - 최종프로젝트 11일차: PR이 너무 길면 어떻게 해야할까?

PR을 하다보면 생기는 문제: 내용이 너무 길어요

주말, 대체공휴일이 끝난 뒤 팀원으로부터 PR을 받았는데, 주말동안 혼자 작업한 분량이 꽤 많았는지, 무려 56개의 파일에 달하는 어마어마한 분량의 PR을 받게 되었다. 이 팀원은 PR피드백을 받아오면서 피드백이 필요한 부분이 점점 줄어들었지만, 매번 작업하신 분량이 상당하였기에 "피드백 할 부분이 그렇게 많지는 않은데, 코드 전체를 보는 편이 과연 옳은 것인가?" 하는 질문을 스스로 하게 되었다.

팀원이 추가한 56개에 달하는 파일, 분량이 어마어마하다.

그렇다고 팀원에게 작업을 줄여 달라고 하는 것은 불가능하고, PR에 포함시킬 파일을 적당히 나눠서 보내달라고 하기에는 이 수많은 파일이 하나의 기능만을 위해 존재할 수도 있기 때문에 그 경우 반쪽짜리 기능이 되어 에러를 일으킬 가능성도 있다. 때문에 이런 경우에선 차라리 PR을 효율적으로 하는 방법을 내 쪽에서 기르는 것이 좋을 것이라는 생각이 들었다.

PR을 효율적으로 하는 방법: 구현 배경을 먼저 확인하라

Gemini에게 긴 내용의 PR을 효율적으로 하는 방법에 대해 질문하여 다음과 같은 답변을 얻었다. 나는 이전까지 코드리뷰를 할 때, 변경된 파일 내용 전체를 읽으면서 추후 문제가 발생할 법한 부분을 짚어 피드백을 하였다.

하지만 위처럼 긴 내용을 리뷰해야할 때에는 코드 전체를 보기에는 너무 오래 걸린다는 문제가 있었다. 이에 Gemini는 "커밋 단위로 구현배경을 훑어보면서 확인"하는 것을 제안하였다.

Gemini의 답변

확실히 커밋을 할때 작성양식을 지켜야하는 이유가 여기서 나오는 것 같다는 생각이 들었다. 그 팀원은 각 커밋에 어떤 작업을 했는지 내용을 작성했었다. 그 내용들을 확인하면서 핵심이 되는 내용들을 파악하면 될 일이었는데, 커밋의 존재의의를 잊고 있었다는 생각이 들었다.

긴 내용의 코드를 리뷰할때는, 파일 단위로 보기보다는 커밋 단위로 보는 것도 좋을 것 같다는 생각이 든다.

커밋 내용을 누르면 커밋별로 변경된 파일을 확인할 수 있다.

하지만: 결국 코드 전체를 보긴 해야 한다.

앞에서는 커밋단위로 보는 것도 좋다고 하였지만, 사실 커밋 내용을 보는 것은 세부적으로 어떤 것을 구현했는지 미리 둘러보는 정도에 그칠 수밖에 없을 것이다. 왜냐하면 해당 커밋이 이후 커밋에 내용이 덮어 씌워졌는지 확인이 어렵기 때문이다. 또한 강사님의 말로는 코드 전체를 보는 이유가 문법적 오류를 검사하기 위한 것도 포함되어 있기 때문에, 코드 내용을 훑어보는 것을 소홀히 하면 이후 보지 않은 곳에서 문제가 발생할 우려가 있어 코드를 리뷰하는데 하루이틀 정도 걸린다 하더라도 적당히 훑어보더라도 변경된 내용 전체를 검사해봐야 한다고 한다.

그렇기에 결과적으로는 코드리뷰를 하는데 큰 요행을 바라기는 어렵고, 리뷰에 너무 많은 시간을 소비에 다른 업무에 지장이 갈 정도라면 PR방침이나 업무방향 대해 팀에서 논의해야할 부분일 것이다.