PR 리뷰에 혼을 담아

내가 백엔드 개발자로 일하는 회사는 200명 내외의 핀테크 스타트업이다.

지난 프로젝트 회고에서 PR 리뷰를 무겁게 하자는 의견이 있었다. KPT 회고 방식에서 Problem에 해당되는 말이었다. 실제로 PR 리뷰를 무겁게 하지 않았었던 나는 이 의견을 무겁게 받아들였다. 당시 프로젝트는 요구사항 projection이 명확하지 못한 상태에서 일정에 쫓기며 진행되었고, PR 리뷰를 빨리 하지 않으면 일정에 바로 걸림돌이 되었다. 런칭은 지켰지만 팀적인 실수는 꽤 있었다.

그 와중에 프로젝트에 한 분이 더 합류하셨는데, 그분은 PR 리뷰를 세세하게 해주셨다. 이 로직에서 이게 왜 필요한지, 여기는 트랜잭션을 걸어야 하지 않는지, 또는 이런저런 문법을 쓰면 가독성이 좋아질 것 같다던지, 다양한 의견을 남겨주셨다. 그동안 PR 리뷰어가 되어도 사실상 거수기 역할만 해왔던 나로서는 신선하게 다가왔다. 막상 내 PR에 코멘트가 달리자 조금 번거롭게 느껴지기도 했지만 그분의 코멘트는 단 하나도 도움되지 않은 것이 없었다. 다만 그분조차도 온지 며칠 안 되어 내게 "여긴 PR 승인을 빨리 누르지 않으면 안 되는 곳"이라며 유머에 자조를 담았고 나도 같이 웃었다.

PR 리뷰에는 리뷰어의 혼이 담겨있다. 작게는 우리가 공동으로 관리하는 곳을 청소하는 일과 같아서 어느 한 명이 그걸 소홀히 하면 피해는 모두에게 돌아온다. 다만 그 피해는 단기간에 직접 드러나는 일이 아니어서, 재직 기간이 타 직군에 비해 비교적 짧은 걸 고려하면 PR 리뷰는 선한 영향력으로도 볼 수 있다. 자신의 철학, 적어도 원칙에 비추어보아 어긋난 점이 있다면 얼마든지 이의를 제기하고, 더 나은 방법을 알려주는 것이 PR 리뷰다. 하물며 내가 리뷰에서 이 오타를 발견하지 못했다면 다른 이슈에서 별도로 이걸 바꿔야하는 일이 생길 것이다.

PR 리뷰에 혼을 담기 위해 내가 택한 방법은 원격 브랜치 체크아웃이다. 변경을 제출하려는 브랜치에서 빌드해보고 PR diff와 코드 모두를 보는 것이다. IDE에서 코드를 보면 궁금한 부분의 정의로 바로 이동하며 영향 범위를 파악할 수 있고 여기서 질문이 생길 때가 많다. 코드 외적으로도 도움이 된다. 예를 들면 방금 추가된 환경변수가 우리가 공동으로 관리하는 환경변수 파일에 업데이트 되었는지, 추가된 에러코드가 공통 문서에도 업데이트 되었는지까지 보는 것이다. 이렇듯 휴먼 에러를 줄일 수 있는 데까지 기여할 수 있다.

PR 리뷰에 혼을 담다 보면 결국 이 코드 변경은 무엇을 위한 것인가까지 생각이 닿게 된다. 역으로 말하면 목적이 없거나 사전에 동의하지 않는 커밋에 대해서는 조금 더 깐깐하게 볼 여지가 생긴다. 코드 변경의 원래 목적을 보기 위해 연결된 Jira 티켓이나 문서를 보기도 한다. 이런 과정에서 내가 속한 서비스의 비즈니스 로직을 더 잘 이해할 수 있고 그게 또 코드 가독성을 향상시킨다. 소프트웨어에서 잘못된 선택의 파급력이 얼마나 큰지 아는 사람은 저절로 책임감이 생긴다. PR 리뷰에 혼을 담는 건, 결국 그 책임감의 표현이다.