코드 리뷰가 개발 문화에 미치는 영향

9분

2023.04.04.

언어 장벽을 넘어 ‘개발 문화’를 움직인 코드 리뷰

중국 개발 회사의 개발 문화를 바꾸는 일을 수주하며 회사(베터코드)를 창업했습니다. 두 번째 해부터 CTO가 합류하여 진행한 일 중에 (당시에는 더 중요해 보이는 일들이 많았습니다만) 지나고 보니 가장 중요한 일은 아마도 코드 리뷰가 아니었나 회고합니다. 당시 우리 회사의 CTO가 팝잇Popit 이라는 지식 공유 서비스를 운영하고 있어서 동료들이 그곳에 기록을 남겼습니다. CTO가 직접 작성한 코드 리뷰에 대한 글이 두 개나 남아 있습니다.

당시 옆자리에 앉았기 때문에 구두로 수도 없이 듣던 이야기인데, 이 글을 쓰며 다시 한 번 읽어 보았습니다. 첫 번째 글에서 가장 눈에 띄는 문장은 ‘코드 리뷰 이야기(1)편’에 있는 ‘개발 팀원 되기’였습니다. 중국어로 의사 소통이 어려운 상황에서, 그중 영어로 의사 소통이 가능한 개발자 한 명과 함께 모듈을 직접 개발하며 팀에 녹아들었던 경험을 이야기하는 부분입니다.

이 글에서 그는 이렇게 하기로 결정한 이유에 대해 “개발팀의 상황이 새로운 것을 받아들이거나 관심을 가질 여유가 없어 보였기 때문”이고, “현 상태로 두면 개발자의 개발 역량은 올라가지 않을 뿐더러, 개발팀 전체의 역량도 제자리인 상태로 유지될 것”이었기 때문이라고 합니다. 그래서 “처음부터 무언가를 적극적으로 시작하기 보다는 조금 더 관찰해보기로”한 것이죠. 함께 개발해보며 어떤 반응을 보일지, 잘 따라올 수 있는지를 실험한 것이었다고 합니다. 매우 세련된 접근 방법이라 느껴집니다.

실력이 높다고 알려진 외국인 시니어 개발자의 합류가 중국회사 동료들에게는 배타적이 되거나 저항감을 갖게 하는 상황이 될수 있었습니다. 그런 상황에서 개인에게 별도의 부담을 주지 않으면서 실질적인 도움을 주려는 태도는 그들이 마음을 여는 데 결정적인 열쇠가 되었으리라 믿습니다. 아마도 CTO가 개발자의 내면을 깊이 이해한 것이 국경을 넘어서도 통한 것이 아닐까 싶습니다.

코드 리뷰 이야기(2)에도 비슷한 문장이 눈에 띕니다.

“가장 중요한 것은 코드 리뷰가 지적질이 아닌 본인에게 도움이 된다는 느낌을 주도록 노력 한다.”

2006년 즈음, 이와는 전혀 다른 느낌이 드는 코드 리뷰 경험에 대한 기억이 있습니다. 유명 개발자였던 지인이, 공개적인 자리에서 잘못된 코드를 지적하고 더 나은 방법을 제시했던 일을 무용담처럼 이야기해줬던 일이 있습니다. 당시에는 저도 그것이 나쁜 방법이라고 생각하지 않았습니다. 더 나은 코드를 만들기 위해 감수해야 한다고 생각했죠. 하지만, 지금 제 생각은 매우 다릅니다. 동료들은 그런 지적을 받으면 방어적인 태도를 갖기 쉽습니다. 사람마다 소통 방식이 다를 수는 있지만, 방어적인 태도를 팀 내에 퍼트리는 일은 팀의 생산성에 절대적인 영향을 끼친다고 믿습니다.

올바른 문화는 모방된다

지금 우리 회사에서는 당시 북경에 상주하지 않고 입사 이후에 줄곧 서울에서 원격 근무를 했던 또다른 동료가 코드 리뷰를 이끌고 있습니다. 놀라운 사실은 그 안에서도 북경에서부터 만든 우리의 문화가 담겨 있다는 사실입니다. 바람직한 모습은 팀원들이 자연스럽게 따라하기 때문에 조직 내에 빠르게 번져 나가 생산적인 조직 문화를 만들어 냅니다.

밈(Meme)이라는 개념이 있습니다. 저는 책을 읽고 알게 된 개념인데, 문화요소가 유전적 방법이 아닌 모방을 통해 전달된다는 개념입니다. 쉽게 말해서 우리는 누군가를 모방하기를 좋아한다는 것이죠. 북경에서 일하던 우리에게도 코드 리뷰가 ‘밈’을 통해 문화요소로 퍼져 나가는 장면을 기록을 통해 확인할 수 있었습니다.

2019년 벌어졌던 일화를 소개하겠습니다. CTO 님이 개인 사정이 생겨 서울로 돌아와 원격근무를 하게 되었습니다. 그 뒤 북경 연합군(베터코드와 중국 개발 회사가 한 팀으로 일 하는 상황)의 현장에서 CTO 역할을 맡아서 수행한 또다른 동료의 글이 남아서 이를 전합니다.

“예전에는 코드 리뷰의 중요성을 잘 몰랐다. 개발자 개개인이 잘 짜야 하는 문제라 생각했다. 하지만 MSA처럼 여러 마이크로서비스가 얽혀서 동작할 때는 서로 확인해주는 것이 중요하다. 개개인이 잘 짜야 하는 문제라고 정의했을 때는, 사고가 나도 개인의 책임으로 돌리게 되고, 그 개인은 감추려고 한다. 즉, 서로 감추고 헐뜯고 책임을 전가하는 문화가 만들어져버린다. 서로가 함께 책임을 떠안아야 하는 문제라고 정의했을 때는, 문제를 드러내고 서로 확인해주는 문화가 생긴다. 일단은 나 혼자서라도 코드를 다 보자. 물론 남이 짠 코드는 내 눈에 잘 들어오지 않는다. 업무 지식이 부족할 때는 더더욱 그렇다. 그래도 안 하는 것보다는, 내가 할 수 있는 만큼만 하더라도, 안 하는 것보다는 효과가 훨씬 높다.”

처음으로 개발 리더를 맡으면서 전에는 몰랐던 코드 리뷰의 중요성을 깨달은 당시의 상황에 더하여 그의 감정까지 담아서 잘 표현하고 있습니다. 저도 과거에 똑같은 시행착오를 했다는 사실을 고백합니다. 시행착오 끝에 배운 내용이라 더욱 분명하게 뇌리에 새겨져 있는 믿음입니다.

일상의 반복에서 벌어지는 다자간 소통

앞서 인용한 동료의 글에서도 ‘전체 코드’라는 말에 담긴 부담이 표현되어 있습니다. 개인과 조직의 행동 변화를 시작할 때는 자연스럽게 낯선 일에 대해 걱정이 커집니다. 그렇게 되면 수많은 사람이 장기간 작성한 코드를 짧은 시간에 본다고 상상하기 쉽습니다. 코드 리뷰 경험이 없는 사람은 자신이 코드를 작성할 때처럼 코드 리뷰를 한다고 생각하기 쉬운데 보통 그렇게 되지 않습니다.

처음 시작할 때 필요한 것은 사실 첫 발을 떼는 용기입니다. 코드가 많다고 해도, 중요도에 따라 시간과 노력을 나누어 투자할 수 있습니다. 그렇게 하루하루 적응하다 보면 또 요령이 생기고, 어느새 하루에도 몇 차례씩 나눠서 보는 리듬을 만들게 됩니다. 나중에는 바뀐 부분만 볼 수 있도록 도구 사용에도 익숙해지면 그 부담은 이를 실제로 애초에 걱정한 것처럼 크지 않습니다.

시간을 영리하게 사용하는 방법 중에서 제가 자주 쓰는 방법은 알람으로 설정한 항목만 가볍게 훑어 보며 리뷰를 하다가 관심이 생기는 부분만 “대화를 해 보는 일”입니다. 코드 리뷰를 대화로 생각하면 상대방도 친근감을 느낄 수 있고, 더러는 다자간 대화로 지식이 물 흐르듯 흐르는 효과도 경험하게 됩니다. 최근에 벌어진 사건을 예로 들어 보겠습니다.

아래 이미지에 보는 대화에서 제가 질문한 내용은 ‘sanitizer’라는 단어의 뜻이 아니라 단어의 유래를 개발자가 알고 사용하는지 확인하려는 의도였습니다. 그러나, 아직 주니어 개발자인 동료는 제가 단어 뜻을 물은 것으로 오인하고, 친절하게 손소독제 사진까지 붙여서 설명해 주었습니다. 답변을 보고 미소를 지었던 기억이 있습니다.

짐작한 대로 외부 라이브러리에 대한 배경지식과 당장의 작명 사이의 연관 관계에 관심을 두고 있지 않은 듯했습니다. 그래서 제가 코드를 훑어보고 등장하는 특정 라이브러리 이름과 관련성을 동료에게 묻는 글을 남겼습니다. 아래는 이에 대한 댓글로 동료가 남긴 답변입니다.

몇 시간 후에 우리 둘의 대화를 보던 개발 리더가 대화에 참여했습니다. 그간의 이력이 포함된, 배경지식이 잘 정리된 답변입니다.

저는 이 상황의 의미를 설명하며 질문의 의도가 해소되었다는 점을 동료들에게 분명하게 합니다.

경험이 부족한 개발자들은 당장의 답만 찾는 경우가 많습니다. 코드를 만들어 실행해야 하니까 자연스러운 일입니다. 하지만, 직관적으로 이해할 수 없는 표현이 들어간 경우 소통을 어렵게 할 수 있습니다. 자신은 알고 있으니 무심코 지나갈 수 있지만, 동료가 직관적으로 알 수 없다면 나중에 동료의 도움을 받기가 어려워집니다.

이런 부분을 해소하는 데 코드 리뷰는 굉장한 강점이 있습니다. 사람은 자기가 관여한 경험과 결부된 지식을 쉽게 기억합니다. 똑같은 지식이라도 일방적인 강의나 훈계로 전달하면 효과가 약합니다. 반면에 자신이 작성한 코드에 대해 관심을 보인 후에 이에 대한 배경지식을 알려 주었을 때 지식은 효과적으로 살아 남고 전달될 것이라 믿습니다.

코드 리뷰를 더욱 인간적인 소통으로 바꾸기

소프트웨어 공학을 전공할 때는 동료 검토(peer review) 혹은 워크쓰루(walk through) 등의 방법을 배웠습니다. 대부분 긴 준비 시간과 수행 시간을 요하는 방식으로 진행되었습니다. 코드 품질을 높인다는 목표가 우선시 되면 이런 방법을 채택할 가능성이 높아집니다.

반면에 동료들과 더 나은 코드를 만들기 위해 대화를 늘려야 한다는 목표를 잡아 보면 어떨까요? 목표 자체가 대화의 횟수입니다. 코드를 보면서 대화를 빈번하게 하기 위해서는 깃허브 같은 도구를 쓰는 것이 좋습니다. 그리고, 짝 프로그래밍과 같은 방식이 아니라 비동기 방식으로 진행한다면 대화 횟수도 늘릴 수 있습니다.

마지막으로, 위는 우리 회사의 개발 리더가 주니어 개발자에게 개발 도구에 대해 설명하는 내용을 캡처한 이미지입니다. 선배 혹은 동료가 자신의 코드에 관심을 가져주고, 더 나은 방법을, 내가 받아들일 수 있는 방법으로 알려준다면, 그것은 인간적인 소통입니다. 그런 소통을 통해서 지식이 전파되고 더 나은 프로덕트를 만들 수 있다면 당장 시도하지 않은 이유가 어디 있겠습니까?

로그인하고 자유롭게 의견을 남겨주세요.