# 아주 사적인 코드 리뷰 생각
최근 코드 리뷰에 대한 기고문 쓰면서 이에 대한 자료들을 많이 찾아봤다. 평소에 코드 리뷰에 대한 생각이나 공유는 많이 했으니 쉽게 쓰일 거라 생각했는데, 블로그에 쓰는 캐주얼한 글이 아니다 보니 공부도 참 많이 했다. 여러 자료를 읽으며 든 생각은, "모두 다 같은 말이다." 심지어 내가 쓴 글 마저도. 자료나 발표가 뻔하다는 것이 아니라 수많은 자료들은 결국 하나의 결말로 끝난다.
협업과 존중
코드 리뷰라고 해서 특별한 것은 딱히 없다. 협업을 하는 사이라면 모든 리뷰/피드백이 다 상호작용해야 하며, 함께 일하는 사람에 대한 존중이 있다면 너무 당연히 지켜져야 하는 것들이었다. 수직 문화든, 수평 문화든, 리뷰자의 자리 나 그 사람의 직함이 뭐든, 프러덕트 자체의 성장을 목표로 하는 사람들이라면 당연히 갖추어야 하는 자세들이다.
구글링을 계속하다 보니 아직도 많은 커뮤니티에서 "현업에서 코드 리뷰를 꼭 해야 하나요?"라는 질문이 계속 올라오고 있었다. 나는 반드시! 꼭! 코드 리뷰를 해야 한다고 생각하진 않는다. 각자 겪고 있는 환경과 상황에 따라 코드 리뷰 진행될 수 없거나 혹은 하지 않겠다 생각하면 안 해도 된다고 생각한다. 다만, 코드 리뷰의 필요성과 장점에 대하여 아직 경험해 보지 못한 사람이 많다는 점이 아쉬웠다. 진정으로 코드 리뷰의 장점을 몸소 느끼고 나면, 안 하면 못 참는 그런 사람이 돼버린다. 코드 리뷰 못하는 상황이 되면 다시 하고 싶어서 몸이 근질근질하달까.
"현업에서 코드 리뷰를 꼭 해야 하나요?"라는 질문이 나에게는 "장수하려면 운동을 꼭 해야 하나요?" 같은 질문 같다. 타고난 신체적 조건이 좋다면 운동을 하지 않아도 오래 살 수 있다. 혹은 운동을 하더라도 무조건 오래 살 수 있는 것도 아니다. 마찬가지로, 코드리뷰를 한다고 해서 무조건 코드 퀄리티가 좋아지는 것도 아니며, 코드 리뷰 안 한다고 해서 장애가 반드시 자주 발생하는 것은 아니다. 잘못된 자세의 운동이 몸을 더 망치듯, 잘못 자리 잡은 코드 리뷰는 팀 분위기만 더 망칠 수도 있다.
운동을 꼭 건강으로만이 아니라, 재미로, 누군가와 함께하고 싶은 취미로, 대회에서 입상하기 위해, 혹은 돈을 벌기 위해 다양한 이유로 한다. 코드 리뷰 역시 코드의 퀄리티만을 위해서 하는 것은 아니다. 새로 조인한 멤버의 랜딩을 돕기 위해서, 팀워크를 위해, 그냥 회사에서 하라고 해서 등 원하는 필요에 따라 하면 되는 것이고 그렇기에 꼭 지켜야 하는 룰 혹은 강도는 없다. 지금 본인의 환경에 맞춰 이루어지면 된다.
여기는 내 블로그이니!! 코드 리뷰에 대한 아주 개인적인 내 생각을 작성해두려 한다. 국룰도, 베스트 프렉티스도 아닌 그냥 나만의 기준이고, 심지어 나도 꼭꼭 지키는 것들도 아니다. 그저 조금 더 즐겁게 코드 리뷰를 하기 위한 작은 다짐 정도?
# 인생 아니, 코드는 타이밍이다.
더러운 코드보다 나쁜 건 타이밍을 놓친 코드라 생각한다. 여기서 타이밍은 제품 기능 데드라인의 타이밍이기도 하고 사람의 인내력 기한 역시 중요한 타이밍이다. 인내력도 유통기한이 있다. 넘어가면 마음이 상해버린다. 코드 리뷰 요청자 입장에서는 본인도 여러 고민을 해서 만들어낸 결과물이다. 아무리 코드와 내가 동일하지 않더라도, 어쨌든 당연히 눈에 한 번이라도 더 밟히는 게 그 코드 짠 사람 마음이다. 거기다가 이거 끝내고 다음 거해야 하는데 계속 여기에 발목 잡혀있으면 당연히 짜증이 난다.
그러므로 리뷰어도 빨리 확인해야 한다. 진짜 빨리 리뷰하려고 노력해야 한다. 하다 못해 선댓글후리뷰를 해서라도 "제가 바빠서 확인을 계속 못하고 있었네요. 빨리 리뷰 하도록 하겠습니다."로 내가 지금 확인 중이라는 것이라도 미리 알려주자. 무플만큼 상처받는 것도 없다.
# 완벽한 코드는 없고, 우리에게 시간은 많다.
의도한 대로 동작이 되는데 '아...이것보단 저게 더 좋은데' 싶은 것은 approve를 하면서 코멘트로 남겨둔다. 물론 이럴 거면 그냥 approve 안 하고 코멘트만 남길수도 있고, 또 리뷰 요청자도 반드시 모든 리뷰어에게 approve 받아야 하는 것은 아니지만(이건 각 팀의 규칙에 따라) 어쨌든 approve 없이 코멘트가 남겨져 있는데 아무리 "아 꼭 고쳐야 하는건 아닌데요."라고 써놔도 요청자 입장에서는 맘이 찝찝하다. 꼭 이번 리뷰에서 고쳐져야 하는게 아니라면, 그리고 큰 문제가 없다면 approve로. 그다음에 이걸 이번에 적용할지, 다음에 적용할지, 혹은 적용하지 않을지는 작업자의 선택을 전적으로 따른다.
긴가 민가 해도 괜찮다. 그 코드를 앞으로 같이 오랫동안 다 같이 물고 뜯고 즐길 것인데, 정말 별로면 또 고치러 올 것이다.
# 수정 의견에는 why를
느낌적인 필링만으로도 의견을 줄 수도 있지만, 그 느낌적 필링을 타당한 근거로 전달하면 리뷰어에게도, 작업자에게도 큰 공부가 된다. 만약 리팩토링에 대한 것이라면 마틴 파울러의 말을 빌려와도 좋고, 다른 책에서 혹은 스택오버플로에서 본 것들이라면 링크와 함께 그 모습이 반영되면 왜 좋을 것 같은지 나의 언어로 전달해본다.
이게 잘 전달이 안되면, 자칫 딴지 거는 것으로 오해받을 수 있다. 작업자는 리뷰어보다 훨씬 더 많은 고민과 시간을 들여서 짠 코드이다. 짧은 문장은 의도했든 안 했든 오해를 만들 수 있다. 좀 구차해 보여도 나의 의견을 주저리주저리 쓰면서 나도 '그냥 툭 던진 의견이 아닌 저 나름의 고민과 생각을 정리하여 보냅니다'를 팍팍 티내보자. 여기서 예시 코드는 좋지만 코드를 직접 다 고쳐서 보내줄 필요는 없다. 그래도 코드는 작업자가 처음부터 끝까지 직접 고치는 게 좋지 않을까? 하는 개인적인 생각이 있다.
# 리뷰어의 시간은 내 시간이 아니다.
코드 리뷰는 분명 중요한 업무 중 하나지만, 어찌 되었든 다른 사람의 리소스를 사용하는 것이다. 내 리소스가 아니니 정말 소중하게 사용해야 한다. 요청 전, 정말 내가 할 수 있는 최선을 다한 코드인지, 너무 눈에 보이는 개선점은 없는지 보고 또 보고 다시 확인해야 한다. 내 로컬 IDE에서 보고, draft PR로 만들어서 리뷰어 입장에서 내 PR을 또 보고.
작업분에 대한 테스트도 꼼꼼히 진행하고 내가 어떠한 테스트를 했다를 잘 보여주는 것도 중요하다. 테스트 코드를 추가했으면 테스트 코드에 대한 설명과 테스트 통과 내역을 PR 내용에 추가한다. 직접 시나리오 테스트를 했으면 어떤 테스트를 어떻게 했는지, 배포되어있는 곳은 어디인지, 내가 어떤 테스트를 했을 때 어떻게 되었는지 꼼꼼히 정리한다. 리뷰어는 내 작업을 테스트를 해주러 온게 아니라 그야말로 리뷰를 하러 온 것이니, 테스트는 내 선에서 최선을 다 해두도록 한다.
# 가끔은 TMI 남발
이건 좀 취향 탈것 같은데. "오 이런 게 있군요?" 라는 응답이 오면(나에게는 온라인 멍석이다) 신나게 내가 공부한것 들을 털어놓는다. (멍석이 깔린다면 춤춰주는 것이 인지상정!)
나 이만큼 알아!!라는 막간 자랑질이기도 하고 ㅎㅎ 이런 거 정리하면서 나 스스로가 더 공부가 많이 되어서. "엥? 잘난척?"으로 속으로 누군가는 생각할 수 있겠지만 뭐 잘 정리한 지식 숟가락으로 떠먹여 주는데 대놓고 뭐라 할 사람이 있겠나.
# 내 고민을 나눌 수 있는 믿음
위 내용 보면 너무 설렁설렁하는 거 아닌가 하는 생각이 많이 들것 같다. 맞다. 우리가 흔히 코드 리뷰라고 부르는 깃헙 Pull Request는 결국 코드 변화분에 집중하게 되고 여기에는 결국 단편적인 코드 작업에 대해서만 보게 되는 한계점이 있다. 그러니 그 한계선까지만 잘 리뷰되면 되지 않을까 하는 생각이다.
물론 적절한 네이밍과 오타와 같은 것 등 기본적인 뼈대가 잘 잡혀있어야 코드를 더 쌓아가기 좋은 것도, 가독성이 높아지는 것도 모두 동의한다. 예쁜 코드가 보기 좋고, 확장성 고려한 구조가 나중을 위해 좋은거 왜 모르겠는가.
코드 리뷰는 자동화 되지 않는다. (eslint나, CI 이런거 뺴고) 결국 사람들이 직접해야하는 일이다. 코드 뒤에 사람 있어요!! 결국 "다 같이 일 잘해보자! 장애 좀 덜 내서, 밤에 갑자기 콜 받지 말고, 휴가 중에 전화 안받게 잘 해보자!"가 목표 아닌가. (일단 저는 그렇습니다 헤헤 머쓱) 작은 것들에 지적하는 것에 너무 얽혀있으면, 오히려 큰 잘못 혹은 더 툭 터놓고 이야기하고 싶은 것들을 감출 수도 있다. 평소에는 가볍고 경쾌한 리듬으로 코드 리뷰를 하며 믿음을 쌓고, 더 많은 지식과 경험들을 공유하며 진정으로 건강한 코드 나아가고, 궁극적으로는 심적 안정을 줄 수 있는 팀 문화를 만들어 나가는 것이 더 중요한 것 아닐까?
물론 이 믿음의 깊이는 코드 리뷰 도입 기간 혹은 함께 하는 사람과 얼마나 호흡을 맞춰보았는지에 따라 조금씩 달라질 것 같다. 함께 하고 있는 사람들은 모두 코드리뷰를 함께 한지 오래되어서 ping하면 pong하는 사이라면. 구성원들이 자신의 작업에 대해서는 책임감을 가지고 그 결과까지 잘 이끌어 나갈 수 있는 사람들이라면.
위와 같은 안정감 넘치는 환경이 항상 주어지는 것도 아니며, 도메인에 따라 훨씬 보수적으로 해야 하는 곳도 있을 것이다.
(출처: Programmers Dev Survey 2021 (opens new window))
이 설문 보면서 많이 궁금해졌다. 어떠한 상황이 코드 리뷰 도입을 후회하게 만들었을까. 분명 타당한 이유가 있었을 텐데. 혹시 너무 어렵게 시작했던 것은 아닐까. 내가 모든 상황에 대해서 아는 것도 아니면서 기고문에는 정말 꼭 해야 하는 것처럼 너무 쉽게 단정 지어 이야기한 것은 아닐까 하는 여러 가지 복잡한 마음도 들었다.
여전히 내 경험은 너무 단편적이고, 여전히 나는 애송이지만 그냥 다들 재밌게 일했으면 좋겠다. 내가 운이 좋아서 좋은 사람들과 즐거운 일터에서 즐거운 추억을 쌓아나가듯, 모두 그냥 재밌게 가볍게 경쾌하게 함께 일했으면 좋겠다. 나 혼자, 혹은 너 혼자가 아니라 우리가 같이 프러덕트를 위해 고민하고 애쓰고 있다는 거. 우리의 보폭을 함께 맞춰나가는 거. 그게 제일 중요하다 나에겐.