채용 면접을 하면서 많이 받는 질문 중 하나가, ‘개발 문화가 어떻게 되나요?’입니다. 더 자세하게 말해달라고 하면, ‘코드 리뷰는 하는지, TDD나 테스트케이스는 작성하는지’를 궁금해하십니다. 그리고 더 대화를 나눠보면, 많은 분들이 좋은 개발 실천법에 대한 동경이나 환상, 그리고 본인이 그것을 실천하고 있지 못하는 데에 대한 죄책감이나 부담감을 가지고 있는 것을 느낍니다. 아무래도 저희 포지션에 지원하시는 2~4년차 사이의 분들이 겪는 과정인 것 같습니다.

오늘은 지난번에 다뤘던 TDD 못지 않게 많이 질문하시는, 코드 리뷰에 대한 이야기를 해볼까 합니다.

오늘날 소위 코드 리뷰라고 하면 떠올리는 모습은 이럴겁니다. 기능 브랜치를 따서 개발을 진행하다가, 개발이 완료되면 GitHub의 Pull Request (PR)를 발행합니다. 리뷰어들이 PR에 댓글을 달면서 논의를 진행하다가 합의에 이르면 merge하여 본 브랜치에 병합합니다.

하지만 현실에서도 이렇게 단순하게 잘 작동할까요?

현실에서의 PR 리뷰

면접자분들과 이야기를 나누며 서로 많이 공감하던 현실의 PR 리뷰의 모습은 이렇습니다.

자신이 맡은 개발 부분이 완료되면 PR 리뷰를 발행합니다. 주로 시니어 개발자분들이 PR 리뷰의 역할을 담당하곤 합니다. 물론 다른 동료분들도 리뷰를 하긴 하지만, 최종 승인은 중급 내지는 시니어 개발자분들이 하곤 합니다. 그리고 그 수는 상대적으로 적습니다. 때문에 리뷰를 제출하고 코드가 머지되기까지는 시간이 좀 걸립니다. 며칠씩 걸리기도 합니다. 너무 오래 걸리는 경우에는 리뷰 요청을 재차 하기도 합니다.

반대로 리뷰를 하는 사람은 어떨까요? 본인이 맡은 일도 있는데 리뷰는 몰려들고 쌓여갑니다. 좋아요. 마음 먹고 리뷰를 해보려고 PR 내용을 열어봤습니다. 코드 자체는 알겠는데, 애초에 이 코드는 왜 작성한건지, 그 원래의 업무는 뭐였는지, 이 솔루션보다 애초에 더 나은 방법이 있진 않을지 알려면 훨씬 더 풍부한 컨텍스트 정보가 필요한데, 비동기적인 댓글로는 그걸 다 물어보기도 제한적이기도 하고, 채널의 한계 때문에 물어보기도 부담습니다. 그리고 그런 컨텍스트 없이는 제대로 된 리뷰를 하기도 어렵고요.

Code review with many PRs

기획 내용을 간략히 파악합니다. 좋아, 어떤 배경에서 작성된 코드인지는 개략적으로 이해가 됐습니다. 하지만 이미 이 구조를 선택해서 구현이 완료되어버린 지금 시점에서 근본적인 질문을 하기란 부담이 됩니다. 처음부터 다시 작성하라고 하는 셈이 될 수도 있으니까요. 그래서, 네이밍 같은 아주 표면적인 코드 내용 정도만 리뷰하게 됩니다. 처음에는 용기와 사명감을 가지고 적극적으로 리뷰를 했더라도, 미묘한 신경전을 몇 번 겪고, 검토해야 할 PR 요청건들이 쌓여가면 점점 소극적이 되기 십상입니다.

게다가, 코드는 의외로 눈으로 보아서는 잘 발견되지 않기도 합니다. 코드를 작성하는 과정에는 생각보다 몸 전체로 느껴지는 직관이 많이 영향을 줍니다. 내가 직접 코드를 작성하면서는 뭔가 오타가 났거나 코드에 문제가 있을때 이상한 느낌을 느끼곤 합니다. 그러나 다른 사람이 작성해둔 완성된 코드를 볼 때는 그런 느낌이 동작하지 않는 경우도 많습니다.

개발을 한 사람도 이러한 사정을 이해하기도 하지만, 본인이 작성한 코드가 실제로 제품에 통합되어 개발의 결과를 경험하기까지는 시간이 걸립니다. 무작정 기다리고 있을 수는 없으니 다음 작업을 시작합니다. 그러다가 리뷰가 오면 대응을 합니다.

전반적으로 PR 리뷰는 걸림돌이 되어가고, 개발 속도가 느려지고 리듬감이 줄어듭니다. 여러분은 어떤가요? 이런 상황들을 경험하셨나요?

PR 리뷰의 대안

Kent Beck이 PR에 관한 트윗 하나를 올린 적이 있습니다.

“Pull requests are an improvement on working alone but not on working together”

그는 위와 같은 인용과 함께 Those pesky pull request reviews라는 글을 링크했습니다. 저는 이때부터 본격적으로 PR 리뷰에 대해 다시 생각해보게 되었습니다.

PR 형태의 리뷰는 GitHub이 널리 사용되면서 소개되고 유행하기 시작했습니다. GitHub은 특히 오픈소스 개발에 특화되어 발달했습니다. 오픈소스는 그 특성상 전 세계의 수많은 개발자들이 코드를 보내옵니다. 그중에는 훌륭한 개발자들도 있지만 초보 개발자도 있을겁니다. 코드를 보내온 사람이 어떤 사람인지 알지 못하는 환경이지요. 그런만큼, 제출된 대다수의 코드 역시 기본적으로는 신뢰할 수 없습니다. 그렇기 때문에 메인테이너가 들어오는 코드들을 검수하고 들여보낼지 말지 판단하는 문지기 역할을 합니다. 어떻게 보면, ‘기본-불신’의 구조라고 할 수 있겠습니다.

Code review as a gatekeeper

하지만 우리가 회사에서 함께 일하는 동료들은, 기본적인 개발 역량이 어느 정도 검증된 사람들입니다. 이런 상황에서, 오픈소스 개발의 기본 가정을 동일하게 적용하는 것이 효과적일까요?

우리가 겪고 있는 몇 가지 현상들을 반대로 생각해봅시다.

  • 전부 개발한 뒤에 리뷰하는 대신에, 개발을 진행하는 과정에서, 또는 그보다 더 나아가서 개발 전부터 논의를 시작하여, 어떤 설계나 접근법이 좋을지까지 논의합니다.
  • 리뷰어가 수문장 역할을 하고 책임을 지는/떠넘기는 대신에, 본인이 작성한 코드의 책임은 기본적으로는 본인이 집니다. 리뷰가 개발의 걸림돌이 되지 않도록, 권장하지만 필수는 아니어도 됩니다.
  • 모든 코드를 검수받듯이 리뷰하기보다는 역량 향상의 기회로 활용합니다. 중요하거나 잘 안풀리는 부분이 있을 때 함께 논의하며 실타래를 풀어가고, 리뷰가 꼭 필요 없다고 판단되는 부분은 본인의 책임 하에 그냥 진행해도 무방합니다.
  • 비동기적으로 댓글을 달며 리뷰하는 것도 좋으나, 온오프라인으로 실시간으로 함께 이야기하는 것도 병행합니다. 댓글은 이야기할 내용들의 단초를 제시하는데 효과적이고, 실시간으로 이야기하면 더 깊은 내용을 이야기할 수 있습니다. 오해도 줄이고요.
  • 완성된 코드를 눈으로 검토하는 것만 하기보다는, 가급적 코드 작성도 함께 합니다.1 작성하는 과정에서 느껴지는 느낌을 적극적으로 활용합니다.

저도 16년쯤 전에 첫 회사에서 개발했던걸 기억해보면, 개발하다가 도중에 막히는 것 있으면 옆 동료한테, ‘이것 좀 잠깐 봐줘봐. 여기서 이게 안되는데 말이야…‘라거나, ‘후… 이거 돌아가긴 하는데 썩 마음에 안드는데 뭐 좋은 방법 없을까?’라며 중간중간 작게 논의를 했던 기억이 납니다.

그러면 옆자리에 가서, ‘코드 좀 봐봐’ 하고, ‘내 생각에는 여기 이걸 이렇게 바꾸는게 좋을 것 같은데?’ ‘그래? 무슨 얘기인지 잘 감이 안오는데?’ ‘음. 그럼 잠깐 내가 코드로 어떤 느낌인지 보여줄께’ 라며 30~60분 정도의 작은 페어 세션이 열리고, 또 다른 옆사람도 기웃 하면서 ‘무슨 일인데?’라며 참견하고, 그랬던 기억이 납니다.

어떤 면에서 보면, 개발하는 과정에서 보여지던 이러한 자연스러운 현상이, GitHub의 Pull Request라는 기능이 생겨나면서 무의식적으로 그에 따라 변질된 것은 아닐까 생각이 듭니다.2 GitHub의 PR을 사용하면 코드 리뷰를 하고 있다고 착각하게 됩니다. 우리는 뭔가 빈칸이 있으면 채우고 싶어지고, 기능이 있으면 꼭 필요하지 않은데도 사용하고 싶은 경향이 있거든요.

웜블러드에서는 개발하는 과정에서 자주 대화를 나눕니다. 개발을 시작할 때나 진행중일 때나 마칠 때를 막론하고 상의합니다. 진행중인 코드를 가지고 이야기하기도 합니다. 서로의 의도나 방향성, 현재 잠시 이렇게 진행하는 이유나 배경도 이해합니다. 물론 비동기적인 댓글을 사용하기도 합니다. 하지만 댓글만으로 이야기하지는 않습니다. 이를 통해서, 가급적, 함께 개발해나가는 느낌을 추구합니다.3

  1. 사고 과정의 전이에 대해서는 짝 프로그래밍으로 함께 자라기 글도 참고해보세요. ↩

  2. 이와 비슷한 현상으로는 GitHub 액션을 사용한 지속적인 통합 기능이 있습니다. GitHub 액션을 써서 테스트를 자동으로 돌리면 지속적인 통합을 실천하고 있는 것으로 착각하게 됩니다. ↩

  3. 이 글을 쓰기 위해서 몇 가지 자료들을 찾아보았는데, 아래 글들도 함께 읽으시면 좋을 것 같습니다. Dragan Stepanović는 From Async Code Reviews to Co-Creation Patterns라는 글에서 비동기라는 특성으로 인한 현상을 상세하게 설명합니다. Jeff Langr는 PRs: Shift Left, Please라는 글에서 PR과 코드 리뷰에 대한 본인의 소견을 밝힙니다. ↩