이 글은 Building an Inclusive Code Review Culture를 번역한 글입니다.

모든 개발자는 코드 리뷰에 익숙합니다. 그리고 우리 이전의 많은 사람이 그것을 어떻게 할지에 대한 생각과 제안들을 쌓아왔습니다. 코드 리뷰는 모든 개발자가 매일 매일 수행하는 필수적인 요소기 때문에 팀 문화에 큰 영향을 미칩니다. Plaid에서, 우리는 수용력 있고 상호협력적인 문화에 자부심을 가지고 있고, 그래서 우리는 우리만의 코드 리뷰 가이드라인을 만드는 것이 조직과 함께 우리도 성장하고 그런 문화를 성숙하게 만드는 것에 굉장히 중요하다고 느꼈습니다.

우리의 네 가지 개발 철학 중 하나는 함께 성장하는 것입니다. 이 글은 코드 리뷰 과정을 통해 우리가 그 가치를 실현하는 방법을 보여줍니다.

우리는 두 핵심 목표를 염두에 두고 코드 리뷰에 접근합니다. 모든 조직의 학습과 성장을 고려하고 좋은 코드를 실어 나르자. Plaid의 초기 개발자들은 이미 수용력 있는 코드 리뷰에 숙달했기 때문에 우리는 그것을 처음부터 발전시킬 수 있었습니다. 하지만 팀이 계속 성장하면서, 더 모든 개발자가 다른 개발자들과 서로 긴밀한 관계를 맺을 것이라고 확신할 수 없었습니다. 우리는 특정 스타일과 스타일 가이드를 강제하는 linter를 이용해 코드를 깔끔하게 작성하는 법은 이미 알고 있었지만, 어떻게 코드 리뷰의 방법을 다듬을지는 몰랐습니다. 우리는 Plaid의 코드 리뷰 문화를 기존의 팀과 새로운 직원들을 아우를 수 있는 무언가로 집약시켜야만 했습니다.

우리는 개발팀이라는 본질로 돌아가 현재 Plaid에 어떤 제일 나은 방법들이 있는지 써 내려가는 것부터 시작했습니다. 신입부터 시니어 개발자들까지 많은 개발자를 면담했습니다. 그러고 나서 모든 사람의 생각을 정리해서 몇 가지 권장 사항을 만들었습니다. 우리는 모든 직원이 기여하고 목소리를 낼 수 있도록 각 팀에 이 권장 사항들을 보냈습니다. 모두의 동의를 얻고 그 지지를 확실히 하기 위해 개발 과정에 우리는 다음과 같은 가이드라인을 제시했습니다.

Plaid의 코드 리뷰 가이드라인

코드 리뷰의 목적

올바른 마음가짐으로 코드 리뷰를 시작하는 것은 건설적인 피드백을 주려는 쪽에게나, 받으려는 쪽에게나 굉장히 중요합니다. 대부분 코드 리뷰에서의 우리의 목표는 좋은 코드 기반을 유지하고 무결성을 보장, 작성자와 검토자 양쪽 모두를 학습시키고 성장하게 하기 위함입니다.

작성자를 위해

코드 작성자에게 가장 중요한 규칙은 검토자의 시간을 존중하는 것입니다. 다른 모든 규칙도 이것으로부터 파생됩니다. 이것이 의미하는 바는, 리뷰를 요청할 때 우리는 우리의 코드가 다른 사람이 볼 준비가 되어있다는 확신을 가지고 있어야 한다는 것입니다. 필수적인 테스트를 돌리고 쓸데없는 디버깅 구문들을 삭제, 리뷰 설명에 적당한 문맥적 의미를 적어야 한다는 말입니다. 누가 코드를 보든 간에, 그게 검토자인지 미래의 개발자인지 상관없이 코드의 목적이 무엇이고 그것을 어떻게 달성했는지 이해할 수 있도록 하는 것은 중요합니다.

PR의 범위를 구체적으로 지정하는 것은 효과적인 코드 리뷰 과정을 갖추는 데 도움이 됩니다. 만약 당신이 리뷰를 위해 수백 줄이 넘는 코드를 제출하는 자기 자신을 본다면, PR의 범위를 지정함으로써 조금 더 꼼꼼해질 수 있습니다. 수백 줄의 코드를 두고 검토자가 모든 변경 사항을 이해하고 효과적으로 검토한다는 것은 굉장히 힘든 일입니다. 변경 사항을 제한함으로써 코드 리뷰 과정을 더욱 빠르게 만들고 당신의 코드를 더 신속하게 반영할 수 있습니다.

마지막으로, 검토자가 당신이 작성한 변경 사항을 적용할 수 있도록 돕기 위해 쏟는 시간을 존중하세요. 그들은 당신에게 피드백을 주기 위해 본인의 주요 프로젝트 업무에서 시간을 떼어온 것입니다. 만약에 그들이 코멘트를 남기면 그것이 무엇이든 응답해주는 것이 중요합니다. 그 응답이 그들 말대로 수정했다고 하는 간단한 것이라고 해도요. 고맙게도, 우리는 그걸 위한 이모지⚡를 가지고 있습니다. 이건 변경 사항을 추적하기 위한 아주 좋은 도구입니다.

jlamb: 다른 케이스들은 철자순으로 되어있는 것 같네요 - 이 케이스는 밑으로 내리는 게 어때요?
jsiegel: ⚡

검토자를 위해

Plaid에서 우리의 코드 리뷰 목표 중 하나는 우리의 코드 기반을 건강하게 유지하는 것입니다. 그렇게 하는 것은 본질적으로 어렵습니다. 많은 경우에, 코드를 보다 읽기 쉽게 작성하고 스타일 가이드라인에 더 잘 맞출 수 있는 방법을 제안하는 것은 의견의 문제로 이어집니다. 따라서 검토자로서는, 무엇이 의견이고 무엇이 사실인 지 명확히 하는 것이 중요합니다. 코드의 버그는 객관적이고, 그래야만 합니다. 변수를 분리하거나 이름을 바꾸는 것에 대한 다른 접근법은 코드를 읽을 수 있게 하는 데 있어 큰 변화를 가져올 수 있지만, 그것은 검토자의 의견이므로 의견으로써 전달되어야 합니다.

Plaid에서는, 우리가 사용하는 언어들을 위한 각각의 스타일 가이드를 가지고 있습니다. 당신이 검토자로서 보고 싶은 코드가 있으면, 예를 들어, 타입스크립트 저장소에서 import 문들을 철자 순으로 배열하는 것이 스타일 가이드에 포함되어야 합니다. 전역적인 변경 사항을 코드에 통합하고 싶으면, 개발자는 그 스타일 가이드를 준수하여 PR을 생성해야 합니다. 그 언어로 작성된 모든 저장소에서 모든 PR을 뒤지고 다닐 게 아니라요. 만약 누군가가 스타일 가이드에 대해 많은 위반을 저질렀다면, 검토자는 특정 위반 사항을 언급하며 스타일 가이드를 가리켜 작성자가 보도록 해야 합니다. 그리고 검토자가 한줄 한줄 읽어 각 위반 사항에 대해 코멘트할 것이 아니라 작성자 스스로 직접 고치도록 해야 합니다.

바꿔 말해, 검토자는 자질구레한 것들에 집중하는 걸 피해야 합니다. 코드 리뷰는 한줄 한줄 읽고 각 줄의 실수를 잡아내는 것이 아닙니다. 코드 리뷰는 코드를 전체적으로 보고 더 큰 체계에 들어맞는지 보는 것입니다. 사소한 코멘트들을 절대 고려하면 안 된다는 것이 아니지만 그것이 코드 리뷰의 초점이 되어서는 안 됩니다.

검토자로서, 당신은 항상 정확함을 염두에 두어야 합니다. 하지만 인간은 컴퓨터만큼 버그를 잡아내는 것에 효과적이지 못할 겁니다. 검토자가 버그를 확인하는 것이 중요한 만큼, 작성자가 새로운 코드에 대해 적절한 테스트를 작성했는지 확인하는 것은 더 중요합니다.

모두를 위해

Plaid에서, 우리는 "ship it (실어 날라)" 문화를 가지고 있습니다. 지속적인 배포가 일어나고 전 세계에 직원이 있는 환경에서, 실어 나르는 일은 절대 멈추지 않습니다. 10,000개가 넘는 금융 기관을 통합하는 우리 일의 본질은 우리가 인프라의 변화에 끊임없이 반응하고 있다는 것을 의미합니다. 따라서, 코드 리뷰에 촉박함을 느낄 때가 자주 있습니다. 하지만, 모든 PR이 똑같은 긴급성을 가지진 않기 때문에 리뷰를 요청할 때 일정에 대해 미리 잘 알고 있는 것이 중요합니다.

코드 리뷰 과정을 통해 지속적인 성장과 학습을 할 수 있지만, 이건 코드 리뷰의 이러한 측면을 받아들일 때만 가능합니다. 작성자와 검토자 모두 토론에 열려있어야 하고 어떤 것이 왜 그런 방식으로 처리되었는지 물을 의지가 있어야 합니다. 그러나 토론이 언제 삼천포로 빠지는지 알아차리는 것도 물론 중요합니다.

코드 리뷰에서 검토자가 놀랄 만한 일은 없어야 합니다. 중요한 디자인 의사결정에 대해서는 코드가 작성되기 전에 의논하세요. 코드 리뷰는 구현의 세부 사항을 다듬는 시간이지 주요 디자인과 아키텍처 결정을 논하는 시간이 아닙니다. 때때로 코드 리뷰 중에 논쟁 포인트가 될 거라 예상은 못 했지만 중요한 토론이 필요한 문제가 발생하는 경우가 있습니다. 한두 번 정도 훑어본 다음, 오프라인으로 토론을 하고 바로바로 해치워야 합니다. 이는 적절하게 구체화하지 않거나 범위가 지정되지 않은 PR에서 나타날 수 있지만, PR 토론이 왜 꼬였는지에 관계없이 그것이 있음을 인지하고 슬기롭게 해결하는 것이 중요합니다.

가이드라인 만들기

새로운 직원들을 빠르게 적응시키고 우리의 코드 리뷰 권장 사항을 체득시키기 위해서, 우리는 우리가 만든 가이드라인을 훑어보고 GitHub에 들어가 최근 PR들을 살펴보는 코드 리뷰 온보딩^[1] 세션을 만들었습니다. 새로운 직원들을 확실하게 Plaid의 코드 리뷰 문화에 노출함으로써, 그들을 처음부터 그 문화에 기여할 수 있게 만든다고 믿고 있습니다.

어떤 새로운 직원이든, 새로운 조직의 모든 문화 규범을 시도해보고 빠르게 따라오라는 건 겁을 먹을 만한 일입니다. 문화 규범을 익히는 것이 코드 리뷰처럼 비판적인 피드백을 받는 일과 같다면 특히 겁먹을 수 있습니다. 그렇기 때문에, 코드 리뷰 문화에 새로운 직원을 받아들일 땐 가능한 환영하는 것이 중요합니다.

코드 리뷰 온보딩 세션이 끝날 때 LGTM^[2] 이모지를 고르게 되고 이것은 코드 리뷰를 수락하는 데 사용할 개인적인 승인 도장입니다. 내부 개발 README 문서에 이 이모지를 추가하는 건 또 하나의 재미이고 Plaid에서 코드 리뷰어로서 여정을 시작했음을 알리는 상징적인 방법입니다. 우리는 아주 처음부터 새로운 개발자들을 코드 리뷰어로서 환영하는 것이 우리의 코드 리뷰 문화를 강화하는 데 핵심적인 역할을 한다고 믿습니다.

이 가이드라인들은 우리의 개발 조직이 발달하면서 분명히 계속 같이 발달할 것입니다. 팀원들이 가이드라인에 기여하여 그들이 우리의 문화의 대표자가 될 수 있도록 장려하고 있습니다. 이 가이드라인들의 세부 사항이 바뀔 순 있어도, 그 목적은 항상 똑같을 겁니다. 수용력 있고 상호협력적인 개발 문화를 가꿔나가자.

이 글이 재밌었다면, 우리 팀에 합류하는 것을 고려해보세요!