[강연 및 세미나] : 한번 듣고 평생 써먹는 코드 리뷰 노하우 후기

코드 리뷰 : 지속 가능한 SW 개발

참석일 : 21.01.18

유형 : 실시간 온라인 강연

주제 : 코드리뷰 : 지속 가능한 SW 개발 | 한번 듣고 평생 써먹는 코드 리뷰 노하우

발표자 : 백명석 님

참고 링크 : https://okky.kr/article/1135478

---

월 마다 있는 OKKY 커뮤니티의 세미나에 참석했다. 비용은 만원인데 강연의 내용은 분명 그 이상의 가치를 가지고 있다고 확신한다. 아직 이런 세미나는 2번 밖에 참여를 못 해 봤는데 지금까지의 두 강연은 너무 좋았다. 특히 이번에 백명석님이 강연하신 코드 리뷰에 관한 주제는 나에게 더욱 좋은 주제였다. 나는 아직 현직에서 일을 해 본 경험은 없는데 서로 성장하는 방법에 관심이 많다. 나는 이것을 "지식 나누기"라고 말을 하고 있는데 지식 나누기를 위해 코딩 스터디를 만들어 진행하고 있을 정도이다.

 

2022.01.03 - [발전소/동아리 및 스터디] - [동아리 및 스터디] : [코딩&리뷰] : 소개

관련 스터디는 이 글을 참고하면 된다.

지금 내가 주도해서 이끌어가고 있는 스터디는 한 주간 코딩한 내용을 정리해서 공유하고 그 내용을 토대로 발표하고 목표에 대해 공유하며 코딩이 끝나고 코드를 리뷰한다. 그리고 마지막으로 달 마다 회고를 작성하는 방법으로 지식 나누기를 진행하고 있는데 이 중 나에게 가장 어려운 부분은 코드 리뷰이다.

 

왜 코드 리뷰가 어렵냐면 일단 나는 개발자로서 현장에서 일을 해 본 경험이 없다. 팀 프로젝트를 진행하긴 했지만 딱히 코드 리뷰를 해본 적은 없다. 하지만 뭔가 남들이 주니어 개발자 중 성장을 원하는 사람들이라면 무조건 추천하는 그 코드 리뷰의 정석을 경험해 보고 싶은 꿈(?)이 있다. 이번 백명석님의 코드 리뷰 강연은 내 꿈을(?) 간접적으로 이룰 수 있는 매개체 같은 역할이었다. 

 

강연 도중에 예시 코드들도 보여주셨는데 너무 도움이 되었다. 또, 어떤 형식으로 코드 리뷰를 진행했고 어떤 방식, 코드의 양이나 질적으로 어떻게 하면 좋을지 힌트를 너무 많이 얻어가서 매우 만족스럽다. 

 

우선 강연에서 코드 리뷰의 목적으로는 품질 문제 검수 즉, 버그와 장애를 잡는 것과 더 나은 코드 품질 결국 코드의 품질을 높이기 위해서 코드 리뷰가 필요하다고 했다. 그 뿐만이 아니라 학습 및 지식 전달과 상호 책임감 증대, 개발 문화 개선과 설계 개선 제안 등 여러 목적과 이점을 가지고 있는 이 코드 리뷰라는 문화의 중요성을 말해주었다.

 

여기서 말하는 목적과 이점 하나하나가 다 이해가 갔다. 지식이 낮은 사람이 지식이 많은 사람에게 역으로 " ~것은 왜 이렇게 된 것인가요?"라는 질문을 통해 서로 공부할 수 있다는 점과 리뷰어와 저자 둘 다 배워가는 것, 그리고 공동체를 더 끈끈한 조직으로 만들어 공동 책임감을 갖게 한다는 게 어떤 말인지 알 것 같다. 내가 작성한 코드는 그냥 나의 코드지만 다 같이 살펴본 코드는 우리의 코드가 된다. 같이 봤으니 그 부분에 대해서 나도 책임감이 생기게 되는 것이다. 강연에서 이런 부분에 대해 중요하게 설명하고 있다고 나는 느꼈다. 

 

정확하고 질 높은 코드 리뷰를 위해서 누가 잘 해야 할까에 대한 답도 얻어갈 수 있었다. 코드를 검사 받는 사람을 저자라고 하고 코드를 검사, 리뷰해 주는 사람을 리뷰어라고 할 때 저자의 역할이 중요하다. 저자가 고생해서 리뷰어의 시간을 아껴줘야 하고 commit 코멘트나 리뷰 PR을 잘 올려줘야 한다고 했다. 또, 커밋은 작은 단위로 쪼개어 올려주는 게 좋다고 말하고 있었다.

 

강연을 들으면서 코드 리뷰를 왜 어려워 하는지에 대해서도 듣게 되었다. 그리고 코드 리뷰를 하면서 조심해야 하는 점에서도 느낀 게 있는데 결국 저자나 리뷰어 모두 사람이다. 코드는 사람은 아니지만 코드를 다루는 건 결국 사람이다. 사람은 코드에 집중해야지 코드를 짠 사람에 집중을 하면 안 되는 점이다.

 

또, 강연에서 겸손해야 한다고 말하고 있었다. 코드에 대한 주제지만 나는 사람이 겸손해야 한다고 말하고 있다고 느꼈다. 사람이 겸손해야 코드도 겸손해 지는 것 같다. 내 코드가 제일 뛰어난 코드다. 내가 알려주는 코드가 무조건 옳은 코드다. 라고 말을 하는 사람과 관계는 정말 조심해야겠다는 생각이 들었던 부분이었다.

 

강연에서 말하던 내용에서 '맞지 이거지!'라는 생각이 들었던 부분도 있다. 코드 리뷰의 본질이라고 해야 하나.. 이것을 통해 조심해야 하는 점을 자세히 알려주었는데 코드 리뷰 자체는 지식, 공학적 결정을 공유하는 기회이며 공유를 통해 서로의 지식이나 경험을 나누며 상호 학습을 통한 역량 증대 수단이라고 했다. 맞는 말이다. 이어서 코드 리뷰를 개인적인 공격으로 받아들이면 이런 지식을 나누는 행동들이 그 의미를 잃는다고 강연은 내게 알려주고 있었다. 정말 옳은 말이다. 위에서 말 한 것과 같은 맥락이지만 사람과 사람이 코드라는 것에 집중을 해야 하는데 코드가 아닌 서로에게 신경을 쓰게 되면 불화가 발생할 것이고 불화는 결국 협업에 지장이 생겨 코드 품질이 나빠지게 된다. 코드 품질이 나빠지게 되면 추후에 유지 보수할 때 비용이 더 들어가게 되고 이것은 결국 개발 문화 선도로 얻을 수 있는 좋은 면의 네거티브를 경험하게 되는 순간이 되는 것이 된다.

 

사실 코드 리뷰로 이렇게 깊게 생각을 해 본 적은 없다. 코드 리뷰는 그냥 단순하게 나를 기준으로 내가 남에게 내 코드를 설명하고 남은 그것에 대한 피드백을 주는 것, 그로 인해 남은 피드백을 하면서 스스로 공부를 하게 되고 나는 내 코드를 남에게 설명하기 위해 공부를 하는 것과 남이 준 피드백을 통해 공부를 하는 것, 결국 서로 발전하게 되는 일련의 좋은 활동으로만 생각했는데 그 속의 복잡한 이해 관계와 단점, 주의점들을 세세하게 짚어보는 시간이 되어서 너무 좋았다.

 

강연에서 효율적인 PR 방법에 대해서도 알려줬지만 이 부분은 아직 내가 공부해야 할 과제이다. 나는 이 코드 리뷰 활동의 전반적인 시스템에서 내가 놓치는 부분을 캐치해 가는 것만으로도 너무 만족스러운 강연이라고 생각한다. 물론 이 외 과정에 대한 지식을 한 귀로 흘리고 가겠다는 말은 아니다.

 

효율적인 방법에 대해 간단하게 얻은 것을 말 하자면 괴로우면 더 자주 하라는 것과 리뷰는 즉시 시작하자는 것, 예제 코드를 제공해 주되 너무 자주는 말고 적당히 주고 태그를 사용하며 코드 리뷰를 선순환 시키는 방법에 대해 공부를 하게 되었고 메모를 해 두었다.

 

사실 이런 코드 리뷰들이 되기 위해 사람대 사람으로 배려해야 한다고 하지만 사실 사회는 수평적이 아니라 수직 관계의 사회가 대부분이다. 이게 아마 좋은 코드 리뷰 문화에 가장 방해가 되는 부분이라고 생각되는데 이런 점에 대해서는 높은 분이 자세를 낮춰주는 게 필요하고 낮은 분은 감사할 줄 알아야 하는 부분이 있어야 한다고 생각된다.(높은 분은 상급자, 리뷰어를 뜻하고 낮은 분은 저자, 후배 개발자라고 생각한다.) 물론 이런 생각도 강연에서 얻은 힌트를 기반으로 떠올린 나만의 정리에 불과하다.

 

강연에서 코드 리뷰의 핵심도 알려주었다. 핵심은 강력하게 와닿는다. " 리뷰의 핵심은 무엇이 코드를 나아지게 하는가?에 대한 것이지 누가 그런 아이디어를 냈지? 이런 역정내는 것이 아니다. " 저자의 방어를 유발하는 방법은 최소화 해야 하고 비판의 대상은 저자가 아닌 코드임을 항상 인지해야 한다. 그러기 위해서 "너"라는 못 된 호칭(?)부터 뺴야한다고 한다. 그리고 언어를 순화해서 말할 수 있어야 한다. 예를 들어보자 "너 이거 봐바, 여기를 이렇게 바꾸면 더 좋잖아 이렇게 하라고" 이런 말을 하는 사람과 "~씨 이 쪽을 이렇게 하는 게 어떨까요?"하는 사람 와.. 이런 말을 적으면서도 분위기와 편안함 그 감정이 너무 차이가 난다. 전자의 경우 분명 깐깐하고 속 좁아 터진 밴댕이 같은 인간일 것이란 생각과 오늘만 참자라는 생각으로 회사를 다녀야 할 것 같은 느낌이다. 하지만 후자인 경우? 너무 가고싶다. 내가 가고싶은 코드 리뷰하는 회사란 저런 회사 분위기를 가진 서로 발전을 위해 서로 배려할 줄 아는 회사이다.

 

결국 코드 리뷰를 하려면 서로를 배려해야 하는데 만약 동료이면 어떨까? 강연에서는 정말 디테일하게도 동료들의 부분에 대해서도 다뤄줬다. 군대를 생각해 보자 군대에서 나는 동기가 있었는데 동기가 있으면 같이 낯선 사회를 경험하니까 너무 좋다. 둘이 있으면 편하다. 하지만 경쟁자라는 의식이 분명하게 존재한다. 왜냐면 동기니까.. 한 명이 아니라 둘이니까 분명 서로는 비교당할 것이고 이런 것에서 살아남으려면 내가 다른 사람보다 더 잘 해야 한다. 이런 경쟁은 배려를 하지 않는 게 아니라 위험한 줄타기를 하는 것과 같다. 이런 부분에 대해서 강연에서 꼬집어 주었다. 동료간 코드 리뷰에서는 경쟁을 유발하면 안 된다고 한다. 경쟁을 유발하기 보다는 서로 코드에 집중하여 생산성을 높이는 것이 더 현명하다고 한다. 자신의 코드가 불안전해서 피드백을 받았다 하더라도 그것을 나에대한 비판이나 비난으로 받아들이면 안 된다. 학습 과정으로 받아들이고 실수를 배우고 역량을 증대시켜 서로 동기부여함과 동시에 프로젝트 성공에 기여하는 것이 옳다고 한다. 근데 이런 경우도 있을 것이다. 뭔가 말을 해야 겠는데 그것에 대한 아쉬운 점만 이야기 해야 하는 상황이라고 해야 하나 강연에서는 단순 건설적인 피드백이라고 칭하긴 했는데 나는 그냥 아쉬운 소리를 할 바엔 차라리 안 하는 게 낫다고 받아들였다. 그래 그냥 뭔가 찝찝하다고 생각하면 차라리 동료와 조금 더 친하게 지내는 것을 더 중요하게 생각하는 편이 낫다. 물론 심각하지 않은 사항에 한해서다.

 

나는 어렸을 때 부터 흔히 말하는 알바를 많이 했는데 알바를 하면서 작은 사회를 수년간 경험하며 느낀 게 있는데 칭찬이다. 칭찬도 잘 하는 사람이 있다. 칭찬인데 뭘 잘하고 못 하고가 있어?.. 아니다. 칭찬도 잘 하는 사람이 있다. 가식적인 칭찬은 칭찬이 아니다. 잡담이다. 진정성 있는 칭찬은 아무나 하기 힘들다. 이번 강연에서는 이런 진정성 있는 칭찬을 장려하고 있다. 사람들은 대부분 잘 못 된 부분에만 집중을 한다고 말했다. 맞는 말이다. 원래 네거티브가 더 똑똑해 보이고 잘나 보이긴 하니까.. 뭔가 아니까 부정하겠지.. 이런 느낌이다. 하지만 아쉬운 점을 더 꼬집기 보다는 살짝 잘 한 부분을 적당히 더 띄워주면 좋은 영향이 있을 수 있다고 한다. 하지만 이런 칭찬이던 아쉬운 점이던 정확한 원칙에 기반한 피드백이 중요하다고 강연에서 말하고 있다. 

 

피드백이 중요하지만 피드백에서 또한 주의할 점이 있다. 반복적인 패턴에 대해서는 피드백을 제한하는 게 좋다고 한다. 저자의 실수가 동일한 패턴인 경우 모든 경우를 언급하는 것 보다는 2,3개 정도를 언급하는 게 좋다고 한다. 그리고 온라인으로 피드백을 진행하는 것에는 한계가 있다. 때문에 교착 상태가 나타나게 된다면 오프라인으로 만나서 해결하는 것이 더 좋다. 무조건 오프라인 보다는 강연에서 온라인으로 하다 오프라인으로 몇 번하는 것을 추천한다고 했다.

 

아, 코드 리뷰를 재밌게 하는 방법에 대해서도 알려주었다. 뭔가 되게 자기주도 학습을 시키는 방법으로 예시를 보여주고 내가 공모전에서 배웠던 방법과 비슷해서 되게 좋은 점이라는 것을 느꼈다. 어떤 방법이냐면 PR을 작성한 사람과 짝 프로그래밍을 통해 20분 정도 어떻게 고쳐나가야 좋은지 알려주고 Revert를 해주고 PR을 작성한 사람에게 스스로 다시 해보라고 하는 것이다. 그렇게 되면 잠시 보여줬던 시간보다 오래 걸릴수도 있지만 분명 나아가는 방법임에는 틀림이 없다고 말하고 있고 나 또한 그런 점을 느낀 적이 있어 많이 공감이 되었다.

 

이렇게 코드 리뷰를 마음 먹고 하고 코드 리뷰를 좋아하는 사람이 모두가 될 수가 없다. 그럼 코드 리뷰를 좋아하지 않거나 별로 반가워하지 않는 사람들을 어떻게 참여시키는 게 좋을까? 이 질문은 나는 생각을 해 본 적이 없지만 Q&A나 강연에서나 빠짐 없이 나왔던 부분이라 참고하기 좋았던 것 같다.

 

우선, 온라인으로 하다 오프라인으로 하는 것을 추천하고 저자의 노력이 매우 중요하다고 했다. 그리고 저자가 PR을 잘 작성하면 여러 리뷰어의 시간을 절약할 수 있다고 한다. 이건 단순 계산만 해도 리뷰에 참여하는 리뷰어가 2명일 때 30분씩만 절약해도 1시간이 된다. 인원이 많아지면 더욱 더 시간 절약 부분이 중요해 질 수 있다고 생각한다. 강연에서 발표자는 사실 주로 멋져 보여야 한다고 했다. IDE나 Hotkey 등 눈에 보이는 툴의 기능을 멋지게 활용하여 약간 "~우와 나도 해봐야지"이런 마음을 끌어내는 게 좋다고 했는데 솔직히 나는 이 부분은 그렇게 와닿지 않았다. 눈으로만 현혹되어 코드를 쳐본 적이 없어서 그런 것일 지도 모르지만 아직 나는 그렇게 대단한 코딩 과정을 보지 못 해서 그런건지 이 부분만큼은 잘 이해가 안 되긴 했던 것 같다. 하지만 코드 비난에 대한 두려움을 해소시키는 것이 중요하다는 것과 리더의 관심과 의지가 중요하다는 것 내가 떠올려보지 못 했던 당연한 것들을 떠올릴 수 있게 되어서 이 파트 전체에 대한 내용은 만족스러웠다.

 

마지막으로 여러 책들을 소개시켜주고 Q&A를 진행하며 마무리했다. 책들 또한 기록을 해뒀는데 영문 책도 있는 것 같고 한글로 번역된 책들도 있는 것 같다. 지금 클린 코드를 읽고 있는데 처음엔 쉬워 보였는데 이게 아직은 좀 어려워서 잠시 스탑한 상태이긴 하다. 스프링에 대해 조금 더 디테일하게 공부하고 나서 마저 읽고 강연에서 추천 받은 책들 또한 한 번 읽어 볼 예정이다. 사실 강연에서 추천을 해주기도 했지만 워낙 유명한 책들이라 개발자 책 추천만 검색해도 몇 개는 흔하게 보이는 정도이니 책 내용의 질에 대해서는 의심할 필요도 없이 합격이다.

 

강연에서 Q&A 시간에 코드 리뷰를 해도 버그와 장애가 발생하는데 이것을 완벽하게 잡을 수 없는가?에 대한 질문이 많이 나왔는데 아무리 코드 리뷰를 해도 장애와 버그는 항상 발생할 수 있다고 한다. 가장 좋은 방법은 코드를 건들지 않는 것인데 수정에 따라오는 버그와 장애 해결은 프로그래머의 숙명과 같은 것이라고 하셨고 나는 팀 프로젝트 할 때 이 쪽을 좋게 고쳐보면 다른 쪽이 터져있고 이랬던 기억이 있어서 어느 정도 공감이 갔던 부분이다.

 

이렇게 전체적인 내용에 대해 느낀 점과 배운 점 내가 잘 몰랐던 부분을 상기시키게 된 점에 대해서 적어 봤다.

오늘도 하루 열심히 배워가는 유익한 세미나였다.

다음에 또 들을 마음이 있다.!