리뷰 난이도는 어떻게 결정해야 할까? 변경 사항이 건드리는 부분을 질문하라.

풀 리퀘스트(pull request)가 올라왔고 에이전트(agent)의 도움을 받아 작성된 경우, 많은 리뷰어들이 가장 먼저 던지는 질문은 '이것을 에이전트가 작성했는가?'입니다.

그렇게 생각하는 이유를 이해합니다. 우리는 코드 작성자가 누구인지에 기반하여 많은 리뷰 습관을 구축해 왔습니다. 시니어 엔지니어의 변경 사항에는 가벼운 검토가 이루어졌고, 신입 사원의 변경 사항에는 더 면밀한 검토가 이루어졌습니다. 또한 두 사람이 페어 프로그래밍(pairing)으로 작업한 코드는 종종 가벼운 리뷰를 받기도 했는데, 이는 페어링을 통해 실적이 쌓였기 때문입니다. 누가 작성했는지는 위험도를 추측하는 빠른 방법이었고, 오랫동안 충분히 효과적이었습니다.

하지만 이제는 그것이 잘못된 첫 질문이라고 생각합니다. 이 글은 대신 제가 가장 먼저 물어볼 것들에 대해 다룹니다.

지난 게시물에서 멈춘 부분

지난 8월에 저는 왜 페어 프로그래밍으로 작성된 코드가 가벼운 리뷰를 받는지, 그리고 왜 개발자-플러스-에이전트(developer-plus-agent)로 작성된 코드는 아직 그런 혜택을 받지 못하는지에 대해 글을 썼습니다. 한 독자가 댓글에서 이 논의를 한 단계 더 발전시켰는데... 에이전트가 작성한 코드에 할인이 적용되지 않는다면, 병합(merge)되기 전에 더 많은 증거가 필요해야 한다는 것입니다.

저는 그것을 출발점으로 삼는 것에 동의하지 않습니다. 계속 따라가다 보면, 모든 에이전트 작성 변경 사항은 무거운 검토를 받게 됩니다. 여기에는 한 줄 복사 수정이나 일상적인 의존성(dependency) 증가도 포함됩니다. 에이전트가 점점 더 많은 코드를 작성함에 따라, 리뷰어의 관심이 결코 아무에게도 피해를 주지 않았을 변경 사항들에 너무 많이 쏠리게 됩니다.

변경 사항이 건드리는 부분부터 시작하라

제가 만난 여러 팀들 중 상당수는 모든 변경 사항에 대해 비슷한 수준의 리뷰를 적용합니다. 단순한 UI 업데이트와 돈이 움직이는 방식의 변경 사항이 거의 같은 검토를 받습니다. 에이전트가 코드를 더 많이 작성하게 되면서, 이는 더 위험해집니다. 실수를 발견하기 어려워지고, 살펴봐야 할 변경 사항은 훨씬 많아지기 때문입니다.

그래서 저는 다른 곳부터 시작할 것입니다. diff(차이점)를 열어보기 전에, 그 변경 사항이 무엇을 건드리는지 살펴보세요. 청구(Billing)? 인증(Auth)? 데이터베이스 마이그레이션(database migration)? 이전에 문제가 있었던 영역인가요? 그런 다음 얼마나 깊게 살펴볼지 결정하세요.

이것이 AI가 무언가를 놓쳤더라도 괜찮은 낮은 위험 영역인가요? 아니면 비즈니스가 필요로 하는 핵심 기능이라서 훨씬 더 많은 심층 검토가 필요한 곳인가요?

저작권(Authorship) 역시 중요합니다... 저는 위험 수준이 결정된 후에 조정 사항으로 간주할 뿐입니다.

제가 생각하기로는 에이전트가 작성한 코드가 단순히 에이전트가 작성했다는 이유만으로 추가적인 검토를 받는 것은 아닙니다. 저는 그 변경 사항이 무엇을 건드리는지를 보고 판단합니다. 위험도가 낮은 작업은 사람이 만들었든, 에이전트가 만들었든, 혹은 둘 다 만들었든 가벼운 검토를 받습니다. 반면, 위험도가 높은 작업은 어느 쪽이든 제 전적인 집중과 주의를 받습니다.

저작권이 영향을 미치는 지점은 바로 그 고위험 작업에서 나타납니다. 같은 고위험 변경 사항을 예로 들어보겠습니다. 만약 개발자와 에이전트가 함께 만들었다면, 저는 전적인 관심을 기울일 것입니다. 하지만 두 사람이 쌍으로 작업했다면, 아마도 여전히 조금 더 가볍게 검토할 것 같습니다. '짝 할인(pair discount)'은 사라지지 않았습니다... 단지 적용되지 않을 뿐입니다.

또한 이는 더 이른 단계에서 영향을 미칩니다. 위험한 작업에 대해서는 풀 리퀘스트(pull request)가 되기 전에 계획 단계부터 시니어 레벨의 검토를 받는 것이 좋습니다. 일단 누군가가 나쁜 아이디어를 구현해 버리면, 리뷰로는 많은 것을 할 수 없습니다. 그때 남은 유일한 질문은 그것을 배포할지 말지 여부뿐입니다.

매우 적은 검토만 필요한 변경 사항들

저는 한 단계 더 나아가겠습니다. 가벼운 사람의 손길로도 충분한 PR(Pull Request)들이 있습니다. 심지어 인간의 눈이 전혀 필요 없는 경우도 있을 것입니다. 이는 리뷰 담당자들이 정말 도움이 필요한 변경 사항에 집중할 수 있도록 해줍니다.

그 경계가 어디에 놓일지는 각 팀과 그들이 얼마나 편안함을 느끼는지에 달려 있습니다. 위험도가 낮다고 해서 위험이 없다는 뜻은 아닙니다. 조용한 구석의 작은 변경 사항에도 버그가 있을 수 있습니다. 가벼운 검토란, 만약 무언가가 빠져나가더라도 큰 비용을 치르지 않을 것이라는 베팅입니다. 팀은 그 베팅을 얼마나 감행할지 결정하게 됩니다.

제가 권장하는 것은 의도적으로 그 경계를 긋는 것입니다. 대부분의 팀들은 자신들이 무엇 때문에 리뷰 단축(review shortcuts)을 얻었는지 문서화한 적 없이 물려받았습니다. 에이전트가 작성한 코드와 같은 새로운 종류의 변경 사항이 나타나면, 그것은 이미 존재하는 어떤 바구니에 조용히 분류됩니다.

변경 사항이 무엇을 건드리는지 알려주는 방법

이 중 대부분은 몇 초 만에 알아볼 수 있습니다. 지난 글에서 저는 어떤 리뷰도 신뢰하기 전에 세 가지 확인 과정을 제안했습니다. 변경 사항이 어떤 경로(path)를 건드리나요? 그 경로들의 이력(history)은 무엇인가요? 테스트가 코드와 함께 이동했나요? 여기에서도 같은 세 가지가 통합니다. 이는 누군가가 diff의 한 줄을 읽기 전에 얼마나 깊이 살펴봐야 하는지 감을 잡게 해줍니다.

그래서, 여러분과 팀에게 질문을 드립니다. PR(Pull Request)이 들어왔을 때, 누가 그것을 얼마나 어렵게 검토할지 결정하는 것은 무엇인가요? 그리고 만약 좀 더 가벼운 리뷰 경로가 있다면, 변경 사항이 그 경로에 들어가기 위해 충족되어야 하는 조건은 무엇인가요?

저는 소규모 엔지니어링 팀을 위한 위험 인텔리전스(risk intelligence)인 Merge Lantern을 만들고 있습니다. 이는 병합되기 전에 시니어 개발자의 눈이 가장 많이 필요한 열려 있는 PR들을 짧은 일일 요약본으로 표시해 줍니다. 아직 초기 단계이며, 처음 5명의 디자인 파트너에게는 3개월 무료를 제공합니다. 팀에서 이 문제를 느낀다면 mergelantern.com에서 대기 목록에 가입하세요.