들어가며

안녕하세요. 트렌비 스토어 팀에서 일하고 있는 티라노입니다.

저희팀에서는 최근 코드리뷰를 좀 더 잘할 수 있는 방법에 대해 생각을 해보고 있는데요. 이런 과정에서 코드리뷰에 관한 좋은 글을 발견하였습니다. BBC 코드 리뷰 가이드라인에 올라온 내용입니다. 오픈소스에서 저장소에 대한 권한을 가지고 리뷰를 하는 내용이기 때문에 정확히 트렌비가 가고자 하는 방향과 일치하진 않겠지만 많은 부분 참고할 수 있을 것 같습니다.

3줄 요약

• 코드리뷰는 커뮤니케이션 도구다. 리뷰어도, 코드 작성자도 상대방을 배려해야 한다.

• 주니어도 시니어의 코드리뷰를 하며 왜 그렇게 했는지 물어볼 수도 있고 물론 승인도 할 수 있으며, 생각보다 잘못된 코드를 정확히 지적하기도 한다.

• 코드리뷰에서 승인한다는 것이 모든 것을 책임진다는 것은 아니기 때문에 부담가지지 않아도 된다.

그럼 한 번 읽어볼까요? 고고고

Code Review

이 문서는 우리가 코드 리뷰를 어떻게, 그리고 왜 해야 하는지 뿐만 아니라 누구나 다 즐길 수 있고 더 효과적인 코드리뷰를 하기 위해 유용한 방법들을 설명하고자 합니다.

물론 이 가이드에 따라 철저하게 코드 리뷰를 진행해야 한다는 것은 아닙니다. 이미 이러한 분야에 대해 많은 자료들이 있습니다. 이 문서는 그런 자료들의 내용을 일부 포함하고 있습니다만(특히 Gergely Orosz의 Good Code Reviews, Better Code Reviews) 우리팀을 위해 중요한 몇 가지는 좀 더 세분화였습니다.

왜 코드리뷰를 하는가.

코드리뷰 개발단계에서 더 빨리 버그를 잡도록 도와줍니다. 즉, 더 싼 비용으로 버그 수정할 가능성이 있습니다. 그렇다고 하더라고 이 방법으로 대부분의 오류가 잡힐 것을 기대하는 것은 아닙니다. 보통의 경우 분산된 조직에서 코드리뷰의 주된 목적은 커뮤니케이션입니다. 코드리뷰는 조직들간에 지식과 생각들을 퍼트리는데 필수적인 도구입니다. 마이크로소프트의 2013연구에서 보면 “결함을 찾는 것”이 코드리뷰를 하는 가장 주된 이유였던 반면 가장 실질적인 결과는 코드를 개선하기 위한 여러 방법들을 제안하고 여기에 대해 서로 이해를 공유하는 것이었습니다. FYI, 새로운 접근법, Best practices를 소개하는 것, 문서와 code readability를 개선하는 것(미래의 개발자들과 소통) 같이 코드리뷰에서는 다양한 형태의 소통이 발생하게 됩니다.

즉, 코드리뷰에서 우리의 주된 목표는 서로 서로를 통해 학습하며 우리가 책임지고 있는 코드 베이스와 우리가 사용하고 있는 기술에 대한 이해도를 높이고자 하는 것입니다.

누가 리뷰하는가?

경험의 정도와 관계없이 우리팀에 있는 모든 개발자들은 그들의 일과업무 중 하나로 코드리뷰를 주고 받고 있습니다. 일반적으로, 주니어 개발자들에게 코드리뷰는 질문을 하고 배울 수 있는 기회가 됩니다. 또한 시니어 개발자들은 다른 개발자들을 격려하고 코칭할 수 있는 도구 중 하나로 사용할 수 있습니다. 다만 이러한 롤이 딱 정해진 것은 아닙니다. 신기하게도 많은 경험을 가진 개발자들이 이슈를 만들기도 하며 아주 좋은 눈을 가진 신입이 이런 문제점을 지적하기도 합니다. 누구나가 다 무엇이든 기여할 수 있습니다.

우리는 코드리뷰를 효율적으로 할 수 있는 것이 코드를 작성하는 것 만큼 중요한 소프트웨어 엔지니어 기술 중 필수적인 부분이라 믿고 있습니다.

승인 깃헙은 “approvals” 컨셉을 제공하고 있습니다. 우리 저장소는 일반적으로 GitHub에 변경사항을 머지하기 전에 두 개의 승인된 리뷰가 필요합니다. 승인은 코드 변경에 직접 참여하지 않았던 사람이 보통하도록 하고 있습니다

• 상급자이냐 아니냐, 경험이 많으냐 적으냐와 관계없이 누구나 PR을 승인할 수 있습니다.

• PR을 승인했다는 것이 어떤 식으로든 개선할 부분이 없다는 것을 뜻하진 않습니다. 즉, PR을 승인했다고 하더라도 코드에서 개선할 부분이 존재할 수 있습니다.

• 비슷하게 여러분이 PR을 승인했다고 해도, 이에 대해 개인적으로 책임 진다는 것을 의미하지는 않습니다.

• 만약 나중에 문제가 발생한다면, 우리는 무엇이 잘못되었는지 파악하고 함께 수정하고 다음에 더 잘 할 수 있도록 노력할 겁니다.

코드 리뷰에 대한 우리의 접근 방식

코드리뷰는 작성자보다 리뷰어가 더 많이 알고 있다는 것을 보여주는 것도 아니고 점수를 매기려는 것도 아닙니다. 코드리뷰는 우리가 할 수 있는 더 나은 결과물을 만들기 위해 서로 도우려는 것입니다. 이상적으로는 작성자와 리뷰어가 이 과정을 통해 배우고 결과물에 대해 긍정적으로 기여한 후 마무리하는 것입니다.

소프트웨어 개발은 협업의 과정입니다. 코드베이스는 우리 팀 모두의 소유입니다. 누구도 어떤 특정 부분에 대해 특별한 책임과 권한을 가지고 있지 않습니다. 코드에 대한 피드백은 절대 개인적인 감정으로 느껴서는 안되며, 항상 우리가 어떻게 함께 일하며 우리의 솔루션을 개선시킬 수 있는지에 대한 방향으로 맞춰져야 합니다.

코드를 보고 의논하면서 찾은 문제가 무엇이든, 불평하는 것 보다는 더 나아질 수 있는 구체적인 방법을 제안해야 합니다.

어느 정도의 시간을 들여야 하는가?

앞서 제시한 이유들을 근거로 코드리뷰에 대해 아주 높게 평가하고 있지만 우리는 시간도 없고 인력도 충분치 않으며 끝마쳐야할 많은 일들이 있습니다. 코드리뷰에 쓰는 시간은 UX 리뷰, 접근성 , 테스트를 포함한 개발 라이프 싸이클의 다른 단계와 적절한 비율로 사용되어야 합니다. 코드리뷰하는 시간은 각 태스크마다 달라질 수 있을 것입니다. 그러나 그 동안 경험에 비춰보자면 PR이 코드리뷰로 있는 상태가 초기 개발 시간보다 길어진다면 그건 너무 길다고 볼 수 있습니다. 작성자와 리뷰어 둘 다 책임감을 가지고 시기 적절하게 코드리뷰를 완료할 수 있도록 해야 합니다. 우리는 양질의 코드를 위해 노력하고 있지만 완벽을 목표로 하진 않습니다.(“완벽한”코드는 없다구요)

코드리뷰에 들이는 노력을 줄이기

코드 구현 단계에서 페어 프로그래밍이나 모빙(단체 프로그래밍)을 하게 되면 나중에 기나긴 시간동안 하나 하나 코드리뷰를 해야 하는 시간을 단축시킬 수 있습니다. 이는 대부분 필요한 이야기를 이미 끝냈기 때문입니다. 일찌기 협업하는 것을 통해 어떤 종류의 이슈인지 이미 서로 알고 있는 상태이므로 코드 리뷰 과정에서 서로 얼라인이 맞지 않아 오락가락하게 되는 상황을 최소화 할 수 있습니다. 이런 협업 방식은 팀에서 각 팀원들이 코드베이스나 기술에 익숙치 않은 상황에서 아주 유용한 방법이 될 수 있습니다.

코드리뷰를 받는다면,

코드리뷰가 처음이라면 돈 워리. 다른 사람들이 여러분이 작업한 것을 보는 것에 익숙해지는 것이 중요합니다. 약간의 질문과 수정 요청들이 생길 수도 있으나 그것이 개인적인 감정을 나타내는 것은 아닙니다. 불확실한 부분을 설명함으로써 일을 잘 할 수 있도록 도우려는 팀원들을 행복하게 해줄 수 있습니다.

코드리뷰를 요청할 때 다른 팀원들이 좀 더 쉽게 리뷰할 수 있도록 준비할 수 있는 몇가지 간단한 팁들이 있습니다.

• 현재 해결하고자 하는 이슈나 구현하고자 하는 기능이 무엇인지를 설명할 수 있는 깃헙이슈 링크를 걸어 놓으셨나요? 링크를 걸어 놓지 않았다면 만들어 봅시다. 가끔 요구사항이 무엇인지를 파악하는데 몇 분이 소요되기도 하며, “Definition of Done” 는 구현 단계에서 실수를 줄일 수 있습니다.

• 링크를 만들 수 없거나 혹은 변경사항이 너무 사소해서 굳이 이슈를 만들 필요가 없다면 “no issue” 라고 합니다.(그렇더라도 PR에 요구사항에 대해 확실하게 설명해야 합니다.)

• 변경사항을 더 적은 양의 PR로 분리해서 동시에 리뷰를 진행하거나 혹은 각각 리뷰할 수 있도록 해 줄 수 있을까요? 일반적으로 리뷰어들이 수백라인의 코드 변경사항이 있는 PR을 마주하게 되면 “야. 이거 너무 많은데. 나중에 시간 있을 때 해야겠다” 라고 하게 됩니다. 그리고 이런 반응은 꽤 합리적이라고 볼 수 있습니다. PR이 간단할수록 이해하기 더 쉽고 그래서 더 쉽게 리뷰할 수 있기 때문에 더 눈에 띌수 있습니다.

• PR의 제목은 간단명료한가요? 간단명료한 제목은 사람들이 PR 리스트를 봤을 때, 변경사항이 무엇을 하고자 하는지 빠르게 이해시킬 수 있습니다.

• 코드 읽는 사람들을 위해 추가적은 컨텍스트와 함께 왜 이러한 변경사항이 필요했는지에 대해 좀 더 자세한 내용을 남기셨나요? 리뷰어가 가능한 더 쉬운 삶을 살아가도록 하는 방법은 PR이 더 빠른 시간내에 리뷰가 되는 것일 겁니다. 다음 사항들을 포함했는 생각해봅시다.

• 유용한 링크들(테스트 URL, API 문서 중에서 관련된 부분에 대한 링크)

• 연관된 PR 혹은 비교해볼만한 다른 업무

• 스크린샷(천마디 말을 대신할 수 있음)

• PR 체크리스트를 모두 완료하였나요? 아직 확실하지 확실하지 않은 부분이 있다면 그 옆에 코멘트를 남겨 놓도록 하세요. 그러면 리뷰어들이 해당 부분은 신경쓰지 않고 리뷰할 수 있을 것입니다.

댓글에 응답하기 피드백을 받는 것처럼 자신이 작업한 부분에 댓글이 달렸을 때 심적으로 힘들 수 있습니다. 이러한 반응은 누구나 다 마찬가지이지만 자칫하면 개발자에게 있어 커리어 전반에 영향을 줄 수도 있습니다.

코드리뷰 댓글에 응답할 때 다음 내용을 고려해 봅시다.

• 우리 모두는 우리가 작성한 코드와 자신을 동일시하게 생각하기도 합니다. 그러나 이러한 관점에서 한 걸음 떨어져 스스로 작성한 코드에 너무 방어적이지 않도록 해야 합니다.

• 댓글 작성자의 관점으로 한 번 생각해 봅시다. 아마 추가적인 일이 좀 더 있을 수 있겠지만 댓글에 담긴 변경사항이 길게 봤을 때 도움이 되진 않을까요?

• 질문에 대한 답을 달거나 혹은 자신이 어떤 고민을 했고 그 생각의 과정들이 어떠했는지 설명하는데 잠깐 인내심을 가져 봅시다. 리뷰어들은 어떤 컨텍스트를 놓치고 있을 수도 있고 또는 왜 이러한 해결책에 도달했는지 이해하지 못할 수도 있습니다.(역자 주: 질문에 바로 답을 달기보다는 왜 리뷰어들이 이런 질문을 했는지 한 번 생각해보자는 의미인 것 같습니다.)

• 다른 사람들이 내 코드 한 줄 한 줄 의심할 수 있도록 해 주세요. 가끔은 텍스트로 쓰여진 제안/의견들이 무뚝뚝하게 느껴질 수 있습니다. 그럴 때 답글에 내용을 남기는 것 보다는 오히려 전화통화와 같은 방법을 제안하는 것이 더 나을 수 있습니다.

깃헙 PR을 사용하고 있다면 댓글 작성자가 “Resolve conversation”을 클릭할 수 있도록 합니다. 이 경우 댓글 작성자가 아직 이 버튼을 클릭하지 않았다면 코드 작성자는 리뷰어와 함께 이 부분을 확인해야 합니다.

다른 사람의 코드를 리뷰 한다면,

다음 팁들이 코드 리뷰를 시작하는데 있어서 좋은 시작점이 될 것입니다.

컨텍스트에 대한 이해* 인수기준(Acceptance Criteria), 완료의 정의(Definition of Done), 혹은 적어도 이 일의 아웃풋이 무엇인지에 대한 설명이 있는 이슈/티켓이 PR에 링크로 연결되어 있는지 확인하세요. 그리고나서 하이레벨 수준에서 해결방법에 대한 이해도를 가지기 위해 코드 변경사항에 대한 요약 부분을 읽어 봅니다. 만약 필요한 정보가 빠져 있다면 코드 작성자에게 요구하도록 합니다.

코드 체크아웃 가능하다면 체크아웃을 하고 코드를 로컬에서 돌려봅니다. 이렇게 하면 코드 변경사항이 어떻게 동작하고 있는지 이해하는데 도움을 줄 수 있습니다. 뿐만 아니라 공식적인 테스트를 하기전에 버그를 찾는데도 도움이 됩니다.

설명 요청 이해하기 어렵거나 PR에서 생각하지 못했던 부분이 있다면 작성자에게 설명을 요청합니다. 코드리뷰 할 때 의견이 일치되지 않는 경우는 대부분 오해로 인해서 발생합니다. 여기서 오해라 함은 작성자가 요구사항을 완벽하게 이해못했을 수도 있고 리뷰어가 작성자의 의도를 파악하지 못했을 수도 있습니다. 이 시점에 수집되는 정보들이 나중에 있을 코드 유지보수에 도움이 된다고 본다면, PR 팔로업 부분에 관한 문서 템플릿을 만들어 두는 것도 고려해야 합니다.

질문하기 이미 언급했듯이 코드리뷰는 일반적으로 코드베이스와 기술에 대해 배울 수 있는 아주 좋은 방법입니다. 멍청한 질문은 없어요. 본인이 궁금하다면 다른 누군가도 궁금해할 수 있습니다. 리뷰어들이 질문을 이용할 수 있는 또다른 방법은 우리 모두가 모든 각도에서 문제점을 고려해야 한다는 것을 확신하는 것입니다. 코드리뷰는 퍼포먼스, 보안, 접근성, 테스트 그리고 그 외에 간과하고 지나쳤을 비기능 요건에 대해 다시 생각해 볼 수 있는 중요한 시점입니다. 예를 들어,

• 이 기능은 모든 사용자가 접근할 수 있는 것인가?

• 이 기능에 대해 퍼포먼스나 로드 테스트를 하는 것이 좋은 생각인가?

• 문서를 추가하거나 업데이트할 계획이 있는가?

• 어떤 추가적인 테스트 커버러지가 필요할까?(엔드 투 엔드 테스트?)

대화하기 깃헙 PR에 댓글 다는 것이 코드리뷰를 하는 기본적인 방법이긴 합니다만, 이것이 항상 가장 효율적인 방법은 아닙니다. 대부분의 경우 우리에게는 더 많은 커뮤니케이션 방법이 있으니까요. PR에 대해 복잡한 질문을 하거나 피드백에 대해 응답하기 위한 가장 빠르고 가정 효율적인 방법은 편한 시간대에 통화를 하는 것입니다.

PR에서 댓글들이 오락가락하고 있다면 일단 멈추고 통화를 제안해야할 시점입니다. PR에 많은 댓글들을 남기고 있는 중이라면 사전에 작성자에게 통화시간을 제안하는 것이 더 좋을 것입니다.

이 코드 변경사항과 연관된 슬랙 채널에 콜링크를 공유하게 되면 다른 팀원들이 함께 의견을 나눌 수도 있습니다. 혹은 그저 듣기만 할수도 있습니다. 원격근무하는 팀에서는 사실 이런 주제의 토론을 들을 기회조차 흔치 않습니다. 그래서 이렇게 콜링크 공유방식이 아주 유용하게 사용됩니다.

한 사람을 지정해서 토론에 대한 짧은 요약본을 작성하도록 하고 콜이 끝난 후 도출된 결론이나 인사이트를 보존하기 위해 PR에 추가하도록 합니다.

친절할 것 코드리뷰를 할 때 다른 사람에게 항상 공감할 수 있어야 합니다. 작성자는 대게 많은 노력을 기울여 작업을 했습니다. 긍정적이면서도 건설적인 억양으로 말하게 되면 모든 사람에게 더 나은 리뷰 환경을 만들어 주게 됩니다. 모든 사람들이 같은 경로를 따라 소프트웨어 엔지니어링을 하고 있는 것은 아니라는 사실을 기억해야 합니다. 본인은 기초적이라고 생각하는 부분이 누군가에게는 완전히 새로운 것일 수 있습니다.

코드 작성자가 코드베이스나 우리의 접근 방식에 익숙하지 않은 새로운 컨트리뷰터라면 특별히 배려해야 합니다. 우리는 우리의 높은 기준을 유지하는 것도 필요합니다만 새로운 사람들의 코드에 대해서도 충분히 긍정적인 경험을 할 수 있도록 하는 추가적인 노력이 필요합니다. 그래서 그 분들이 계속해서 좋은 코드를 기여할 수 있도록 해야 합니다.

페어리뷰 또는 단체리뷰(Pair and swarm) 다수의 인원이 함께 할 수 있는 경우 리뷰는 좀 더 쉬워지기도 합니다. 리뷰를 함께 할 다른 개발자를 찾아 보세요. 변경해야 하는 그 코드에 대해 이미 잘 알고 있는 팀원이 될 수도 있겠지만 꼭 그러지 않아도 됩니다. 한 명이 PR에 댓글을 추가하기 전에 각자 리뷰한 내용에 대해 비교하고 의견들을 나누어 보세요.

여러 리뷰어들이 그룹을 만들어서 함께 하게 되는 __단체 리뷰(Swarm reviews)__가 효과적일 때도 있습니다. 특히 작업한 양이 복잡한 경우에는 더 그럴 수 있겠죠. 물론 코드 작성자도 리뷰에 참여해야 합니다. 그래서 리뷰어들이 물어보는 질문에 대해 명확하게 답변할 수 있어야 하며 해당 작업을 진행하기 위해 필요한 컨텍스트와 함께 접근방법에 대해서도 설명해야 합니다.

코드 작성자가 아닌 사람이 단체 리뷰를 진행하는 것 역시도 유용한데요. 그 사람이 PR을 보면서 화면을 공유하고, 작업한 내용을 리뷰하면서 자신이 생각하는 것을 직접 말하도록 합니다. 이 과정은 특히나 단체 리뷰에서 리드 리뷰어들이 코드에 대해 가장 모르는 경우에 아주 유용합니다. 그 분들이 많은 질문을 하기 때문입니다.

자동화 하라! 린팅은 로봇이 하는 일입니다. 자꾸 같은 부분에 대해 언급하고 있는 자신을 발견하게 된다면 린팅 룰에 추가할 수 있는지 혹은 다른 방식으로 자동화 할 수는 없는지 생각해 보아야 합니다. 그래야만 다음에 더 쉽고 더 일관된 리뷰를 계속 할 수 있게 됩니다.

링크와 예제를 제공하라 논란의 여지가 없는 생각이나 기술을 언급하는 경우, 이 부분을 간략히 설명할 수 있는 페이지를 링크해 두세요. 코드 베이스에서 좋은 예제를 찾거나 혹은 다른 익숙한 코드 부분에 대해 링크 거는 방식이 물론 더 좋습니다. 강요하지 않고 대안을 제시해 보세요. 작성자가 이미 고려했었지만 좋은 이유를 찾지 못했을 수도 있습니다.

특정 코드를 변경하도록 제안해야 한다면 작성자가 이해하고 필요한 경우 구현할 수 있도록 충분한 정보를 제공해 주세요. 깃헙 PR에 있는 ‘suggestions’ 기능을 통해 직접 제안하게 되면 코드 작성자 입장에서 좀 더 반갑게 받아들이게 됩니다. 다만 여전히 이러한 변경사항이 왜 필요한지에 대해 작성자에게 설명해주는 것에 대해서도 충분히 고려해 보아야 합니다.

이렇게 해주는 것이 어렵다면 간단하게 슈도 코드(pseudo-code)를 통해 리뷰어의 생각을 표현해주는 것도 좋은 방법입니다.

LGTM은 그만! 간단한 PR을 승인할 때 looks good to me 가 충분하긴 하지만 최고의 리뷰는 단순히 도장을 찍는 것 이상이어야 합니다. 예를 들어, 설명란에 변경사항이 정확한지 검증하기 위해 리뷰어가 어떤 것들을 했는지 적어 줄 수도 있구요.(다시 말하자면 스크린샷 한 장으로 타이핑을 줄 일 수 있습니다.) 아니면 리뷰어가 생각하기에 작성자가 다음 작업에서도 동일하게 진행하는 것이 충분히 가치 있는 일이라는 것을 알 수 있도록 해당 부분에 대해 칭찬을 아끼지 않을 수도 있습니다.

유연하기 때로는 코드리뷰는 진행하는 중 변경사항이 머지가 되기 전에 설명이 필요한 심각한 이슈가 발견되기도 합니다. 물론 대부분은 그렇지 않겠지만요. 이 코드는 댓글에 대한 설명없이 머지해도 될까요? 그렇다고 한다면 나중에 그 부분을 선택해서 진행할 수 있도록 팔로업 태스크를 만들고 PR에 링크를 거세요. 리뷰어가 이런 작업을 하는 것이 더 빠르고 더 효율적이기도 합니다.

주의해서 평가하라 우리는 보통 코드에서 사용되는 레이블들은 주관적으로 작성하고 있는데요. 보편적으로 동의한 의미를 가지고 있지 않습니다. 가끔은 하고 있는 일의 컨텍스트 뿐만 아니라 각 개발자의 배경과 스타일에 대한 취향에 의존적입니다. 아주 사소한 문제라고 해도 두 명의 개발자가 절대 동일한 방식으로 문제를 풀진 않습니다.

누군가는 명백하다고 생각하는 것이 다른 누군가는 장황하다고 생각하기도 합니다. 일관성이 중요하긴 하지만, 너무 과할 수도 있습니다. (Consistency is often prized, but when does it become repetitious?) 무언가를 좀 더 간결하게 하도록 한다는 것이 어쩌면 누군가에게는 읽기 어렵게 만들어 버릴지도 모릅니다. 얼마나 “깔끔”해야 깔끔한 걸까요?

이런 평가가 나름의 용도는 있겠지만 정확히 어떤 의미이며, 이 문제들에 대해 다른 관점이 존재할 수도 있다는 것을 분명히 알고 있어야 합니다. 직접 이야기하는 것이 이 딜레마를 해결하기 위한 가장 빠른 방법일 수 있습니다.

무엇보다도 리뷰어는 막연한 근거나 대안을 제시하지 않으면서 그저 그 방법이 좋지 않다는 식으로 평가하는 것을 피해야 합니다.

누군가를 비난할 수 있는 전문용어를 피하라 누군가는 “코드 스멜”이나 “안티패턴”이라는 용어에 대해 모를 수도 있습니다. 혹은 그 부분에 동의하지 않을수도 있습니다. 이런 용어를 쓰는 대신, 예상하는 문제점이 무엇인지에 대해 객관적으로 잘 표현할 수 있는 방법이 없는지 생각해 봅시다. 그러면 작성자는 리뷰어가 어떤 관점으로 바라보는지 더 잘 이해할 수 있고 그들의 지식 또한 더 나아질 것입니다.

결론

간단히 말해서 코드 리뷰는 우리가 같은 코드베이스에서 함께 일하며 커뮤니케이션 하기 위해 필요합니다. 코드리뷰를 하면서 다른 사람의 관점으로 보게 된다면 모두를 위한 더욱 긍정적인 문화를 만들 수 있을 것입니다. PR 여기저기에 댓글을 남기는 것이 항상 가장 효율적인 대화 방법이 아님을 기억해야 합니다. 그리고 두 명 혹은 그 이상의 팀원들이 구현단계 뿐만 아니라 리뷰할 때도 함께 한다면 이러한 과정을 더욱 쉽게 진행할 수 있도록 도와줄 것입니다.