디스코드 채널에 썼던 글:
저는 PR 형태의 코드리뷰는 별로 좋지 않은 것 같아요. GitHub이 유행하면서 PR이 많이 확산되었는데, 저는 뭐랄까, 앵커링의 오류라고 해야할까, 효과적인 방식이어서가 아니라 도구가 그렇게 생겨서 행동이 도구를 따라가게 된게 아닐까 싶어요. 이를테면, Jira 같은 이슈트래커에 미리 정의된 필드가 있으면 필요 없는 것인데도 막 채우고 싶어지는 것처럼요. GitHub이 유명해졌고, 거기 PR 기능이 달려있었고, 나름 적당히 동작하니, 큰 고민 없이 de facto가 되어버린게 아닐지.
전에 kent beck이 retweet했던 글 중에 인상깊었던 글이 있었어요.
그 글에서는, GitHub은 출발이 오픈소스를 개발하는 플랫폼이었고, 오픈소스는 기본적으로 patch를 보내오는 기여자를 신뢰하지 않는 구조라고해요. contributer는 믿을 수 있겠지만, PR이라는 것이 익명의 다수가 자신이 patch한 것을 제출하기 위한 장치였고, 많은 오픈소스에서는 그 patch를 신뢰하지 않고 maintainer가 일종의 문지기 역할을 하면서 일일이 검사하고, 승인된 코드만 통과시키는 모델이라는거죠. 그리고, 이러한 방식이 과연 in-house 개발에서도 적절하게 동작할까라는 의문을 제기해요.
제 생각에는 오히려 in-house 개발에서는, synchronous하게 같이 라이브로 코드 보면서, 긴밀하게 논의하는 형태가 더 좋은 것 같아요. 저도 코드 리뷰를 한동안 하면서, 코드 자체는 알겠는데, 애초에 이 코드는 왜 작성한건지, 그 원래의 업무는 뭐였는지, 이 솔루션보다 애초에 더 나은 방법이 있진 않을지 알려면 훨씬 더 풍부한 컨텍스트 정보가 필요한데, async한 comment로는 그걸 다 물어보기도 제한적이기도 하고 채널의 한계 때문에 물어보기도 부담스럽기도 하더라고요. 그리고 그런 컨텍스트 없이는 제대로 된 리뷰를 하기도 어려웠고요. 그래서 좀 표면적인 이슈들만 코멘트하게 되더라고요. 또 이미 방향이 많이 결정되어 구현된 상태기 때문에, '이 방향보단 다른 방향으로 접근하는게 좋겠다' 같은 원론적인 질문을 제기하기에는 이미 늦은 시점이고요. 그 PR을 통째로 날리고 새로 짜라고 하는건 만만치 않은 일이니까요.
그리고, 제가 직접 짰더라면 하지 않았을 실수들이 나중에 많이 발견되기도 했는데, 리뷰하면서 완성된 코드를 보면서는 그게 잘 포착되지 않더라고요. 뭐랄까, 머슬 메모리랄까, 내가 코드를 작성하면서 지키는 일련의 순서, 규칙 같은 것들이 있는데, 그게 암묵지나 직관이다보니, 그 과정의, 타이핑하는 감각을 거치면서는 '어라? 뭔가 이상한데?'라는 느낌이 포착되지만, 완성된 코드에서는 그게 잘 안보이고 안느껴지는 경우가 많았어요.
그런 면에서, 완성된 단위로서 PR을 발행하고 그 완성품에 대해 리뷰를 하는 것보다는, 중간 과정에서 자주 논의하는게 좋은 것 같아요.
저도 13년쯤 전에 첫 회사에서 개발했던걸 기억해보면, 개발하다가 도중에 막히는 것 있으면 옆 동료한테, '이것 좀 잠깐 봐줘봐. 여기서 이게 안되는데 말이야...'라거나, '후... 이거 돌아가긴 하는데 썩 마음에 안드는데 뭐 좋은 방법 없을까?'라며 중간중간 작게 논의를 했던 기억이 나요. 그러면 옆자리에 가서, '코드 좀 봐봐' 하고, '내 생각에는 여기 이걸 이렇게 바꾸는게 좋을 것 같은데?' '그래? 무슨 얘기인지 잘 감이 안오는데?' '음. 그럼 잠깐 내가 코드로 어떤 느낌인지 보여줄께' 라며 30~60분 정도의 작은 페어 세션이 열리고, 또 다른 옆사람도 기웃 하면서 '무슨 일인데?'라며 참견하고, 그랬던 기억이 나요. 그게 가능했던게, 다들 병특하는 또래였어서, 서로 부담이 없고 친해서 그랬던 것 같고요.