어디까지나 픽션입니다.
들어가며
안녕하세요! 아이들나라 백엔드팀 최현구입니다. 여러분은 혹시 위 그림과 같은 상황을 겪어보신 적 있으신가요? 재미로 만든 그림이지만, 사내 적극적인 코드 리뷰 문화가 정착되지 않았다면 언제든지 발생할 수 있는 일이라고 생각합니다. 이번 글에서는 아이들나라에서 적극적인 코드 리뷰 문화를 만들기 위해 특별한 스터디를 도입해 본 경험을 공유합니다.
현재 아이들나라에서는 수십 명의 개발자들이 고객분들께 더 멋진 키즈 서비스를 제공하기 위해 고군분투하고 있습니다. 그중에서 백엔드팀은 아이들나라에 필요한 도메인(회원구독, 주문배송, 전시편성, 교육, 컨텐츠 관리, 데이터 등)별로 파트가 나뉘어 있습니다.
각 파트가 나뉘어 있을 때 누릴 수 있는 가장 큰 장점은 도메인 전문화입니다. 각 파트원들은 빠른 시일 내에 도메인에 특화될 수 있고, 도메인에 어울리는 기술 스택을 학습하고 공유할 수 있습니다. 특정 도메인에 대한 경험과 지식이 늘어가기 때문에 비 개발직군의 도메인 전문가와 의사소통도 굉장히 유리해집니다. 특화되는 만큼 성숙하고 고도화된 아이들나라 서비스를 신속하게 만들 수 있습니다.
그러나 서로 다른 파트에 속한 백엔드 개발자 간 교류는 점차 줄어들게 됩니다. 각자의 도메인 지식을 익히는 것에 바빠 다른 파트 도메인에 관심을 갖기 어렵고, 도메인 별로 프로젝트가 나뉘어 서로 다른 깃허브 저장소를 다르게 갖기 때문에 서로의 코드를 마주하기도 쉽지 않습니다. 이 때문에 개발자마다의 코드 리뷰 경험도 달라질 수밖에 없습니다. 내부에서 적극적으로 코드 리뷰가 이루어지는 파트도 존재하지만, 비교적 소극적인 파트도 분명 존재하기 마련입니다. 경험이 많지 않은 개발자들로 이루어진 파트에서는 서로 어떤 코드가 더 나은 코드인지 이야기 나누기 어렵습니다.
적극적인 코드 리뷰는 왜 중요할까요? 코드 리뷰 과정에서 자연스레 동료 개발자의 노하우를 획득할 수 있고, 프로젝트 구조와 맥락을 자연스럽게 공유함으로써 이해도와 업무 연속성을 높일 수 있습니다. 또한 자신의 작업 내용이나 동료의 작업 내용을 인지하면서 코드 품질과 안정감 향상을 기대할 수 있습니다.
저는 아이들나라 팀 전반에서 적극적이고 유기적인 코드 리뷰 문화가 강화되길 기대했습니다. 각자의 전문화된 도메인을 모두 파악하기 어렵지만, 어떤 코드가 읽기 좋은 코드인지, 어떤 아키텍처가 유지보수하기 쉬운 아키텍처인지는 도메인과 상관없이 개발자 모두가 공통으로 이해하고 리뷰하는 데 절대 어려움이 없다고 생각합니다. 때문에 코드 리뷰를 재밌는 놀이로 느끼고, 서로의 깃허브 저장소를 구경하며 자연스럽게 코멘트를 남기는 분위기를 조성하고 싶었습니다.
그렇다면 어떻게 팀원들을 설득하고 적극적인 코드 리뷰 문화를 만들 수 있을까요?
동료 개발자를 설득하는 가장 쉽고 강력한 방법
항상 새로운 아이디어를 제안할 때에는 타인의 공감과 이해가 필요합니다. 그 아이디어가 갖는 효과, 효능을 따져보는 것도 중요하지만 내 의견이 합리적인지, 내 제안이 타인에게 어떻게 받아들여질 지 충분히 고민해 보는 것이 더욱 중요합니다.
사람은 무언가를 판단할 때 의외로 자주 비합리적인 추론을 베이스로 판단하는데, 이를 인지 심리학에서는 인지편향이라고 합니다. 그리고 제안하는 쪽에서는 흔히 확증편향(Confirmation bias)을 겪게 됩니다. 자신이 합리적인 이유로 해당 아이디어를 제시했다고 생각하지만, 실제로는 자신이 익숙하거나 ‘오래전부터 꼭 해보고 싶었어.' 와 같은 편향된 생각 때문에 아이디어를 제시할 수도 있습니다.
확증 편향(Confirmation bias)은 원래 가지고 있는 생각이나 신념을 확인하려는 경향성이다. 흔히 하는 말로 “사람은 보고 싶은 것만 본다”와 같은 것이 바로 확증 편향이다. 확증 편향은 자신의 믿음에 대해 근거 없는 과신을 갖게 한다. 사람들은 자신의 정치적 지향과 다른 사실에 대해 불신하며, 과학적 사실에 반해 자신의 믿음을 고수하려 하기도 한다. 반면, 자신의 신념에 유용하다고 여겨지는 정보는 적극적으로 받아들인다.
— 확증 편향
반대로 제안을 듣는 쪽에서는 제안이 충분히 합리적임에도 평소 자신에게 익숙하지 않거나, 그동안 해왔던 생각과 다른 경우에는 제안에 반하는 마음이 생기곤 합니다. 이를 동기 추론 편향(Motivated reasoning bias)이라고 부릅니다.
동기 추론 편향(Motivated reasoning bias)은 의식적으로든 무의식적으로든 감정에 기반한 동기 편향이 새로운 정보가 인식되는 방식에 영향을 미치는 인지적, 사회적 반응이다. 자신의 현재 신념과 일치하는 근거에는 강한 선호를 나타내고, 객관적으로 합리적인 근거임에도 불구하고 자신과 모순되는 새로운 정보에는 부정적인 경향을 말한다.
결국 내 제안이 얼마나 합리적인지 자세히 설명하는 것도 중요하지만, 팀원들이 제안에 공감하고 필요를 느낄 수 있도록 마음을 움직이는 것을 놓쳐선 안 됩니다. 필요를 느낄 수 있는 가장 쉽고 강력한 방법은 역시 필요 상황을 직접 마주하는 것입니다. 그리고 동료들과 함께 마주할 수 있는 필요 상황을 가장 신속하게 만들 수 있는 방법이 바로 미션 스터디라고 생각했습니다.
직접 코드를 짜며 경험하는 미션 스터디
코드 리뷰도 해 본 사람이 잘 한다.
여러 단계로 나뉘어 있는 쉬운 난이도의 미션을 진행하면서 기존에 자신이 생각했던 좋은 코드와 좋은 테스트를 적극적으로 작성하고, 이를 리뷰하면서 더 나은 코드로 다듬는 것과 동시에 새로운 지식을 공유하는 효과도 기대할 수 있습니다. 이 미션 기반 코드 리뷰 활동을 스터디에 접목한다면 자연스럽게 서로의 코드를 리뷰하는 행위가 연속될 것으로 예상했습니다.
그리하여 탄생한 미션 스터디
우아한테크코스와 넥스트스탭에서의 경험을 되살려 보름 안에 끝장내는 코틀린 미션 스터디를 준비했습니다. 총 5단계로 이루어진 자동차 경주 게임 미션에서 참가자들은 각 단계마다 Pull request, Code review, Approve & merge 3가지 과정을 거쳐야 합니다. 리뷰이는 단계별 요구사항을 충족시킨 후 리뷰어에게 Pull reqeust 를 남기고, 리뷰어는 코드 품질을 높이는 방법과 리뷰이에게 도움이 될만한 정보를 전달하기 위한 적극적인 코멘트를 작성하여 Code review 를 진행합니다. 리뷰이는 리뷰어가 만족할 만큼의 코드를 작성할 때까지 리뷰 내용을 반영하거나 토의를 진행해야 합니다. 리뷰어가 만족할 만큼의 코드가 완성되었다면 Approve & merge 를 진행하고, 그렇지 않다면 Code review 과정을 반복합니다.
최종적으로 자동차 경주 게임을 완성했을 때 결과물은 아래와 같아집니다.
경주할 자동차 이름을 입력하세요(이름은 쉼표(,)를 기준으로 구분).
최현구,아이들나라,전시편성짱
시도할 횟수는 몇 회인가요?
5
실행 결과
최현구 : -
아이들나라 : -
전시편성짱 : -
최현구 : --
아이들나라 : -
전시편성짱 : --
최현구 : ---
아이들나라 : --
전시편성짱 : ---
최현구 : ----
아이들나라 : ---
전시편성짱 : ----
최현구 : -----
아이들나라 : ----
전시편성짱 : -----
최현구, 전시편성짱 (이)가 최종 우승했습니다.
Plain Text
복사
미션이 난이도가 쉬운 편이기 때문에 평소 고민하던 객체지향 설계 및 TDD(Test Driven Development)를 적극적으로 시도해 볼 수 있고, 각자가 알고 있던 소소한 언어(코틀린) 관련 팁도 공유할 수 있습니다. 무엇보다 서로의 코드를 자연스럽게 리뷰하는 습관을 만들 수 있습니다.
스터디 머릿말로 “보름 안에 끝장내는” 을 강조했는데, 보름이라는 기간은 참가자들의 텐션과 집중도를 최대한 끌어올릴 수 있는 기간입니다. 한 달 이상 지속되는 스터디는 대부분 일정이 밀리기 부지기수였고, 중도에 하차하는 인원도 생기기 때문에 최대한 짧은 호흡과 높은 집중도로 스터디가 완료되길 기대했습니다. 또한 미션 스터디가 이번 한 번으로 끝나지 않고 여러 번 반복되길 기대했습니다. 바쁜 일정에 쫒겨 이번 미션 스터디를 패스하더라도, 다음 미션 스터디는 부담 없이 참여할 수 있도록 짧은 호흡을 가져가고자 했습니다.
최종적으로 아홉 분이 참여해 주셨고, 그중에는 프론트엔드 엔지니어와 데이터 엔지니어도 계셨습니다. 백엔드 엔지니어를 중심으로 기획한 스터디에 두 직군이 참여하신 이유는 코틀린 언어에 대한 호기심과 객체지향 설계에 대한 고민이었는데, 미션 난이도가 높지 않은 편이기에 코틀린에 익숙하지 않은 두 분도 부담없이 참여하실 수 있었습니다. 아홉 명의 참여자끼리 순환구조로 서로 리뷰 요청과 리뷰를 진행하면서 단계별로 미션을 진행해 나갔습니다.
미션 스터디를 더욱 알차게 진행하기 위한 규칙과 가이드
미션 스터디 시작에 앞서 더욱 적극적이고 알찬 진행을 위해 몇 가지 규칙과 가이드를 정리했는데요. 크게 객체지향을 지키기 위한 규칙과 리뷰이, 리뷰어를 위한 가이드로 나눌 수 있습니다.
미션 내에서 무조건 지켜야할 객체지향 생활체조 원칙
1.
한 메서드에 오직 한 단계의 들여쓰기(indent)만 한다.
a.
for 문 내부에서 if 문이 포함되는 순간 2 indent 가 된다.
2.
else 예약어를 쓰지 않는다.
3.
모든 원시 값과 문자열을 포장(VO)한다.
4.
한 줄에 점을 하나만 찍는다.
5.
줄여 쓰지 않는다(축약 금지).
6.
모든 엔티티를 작게 유지한다.
7.
3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
8.
일급 컬렉션을 쓴다.
9.
무의미한 getter/setter/프로퍼티를 쓰지 않는다.
소트웍스 앤솔러지의 객체 지향 생촬 체조 원칙을 참고하여 아래와 같은 9가지 규칙을 두었습니다. 이 규칙들은 미션을 진행하는 동안 절대적으로 지켜져야 할 규칙으로서, 미션 진행과 코드 리뷰의 중추가 됩니다. 9가지 규칙을 지키면서 의식적으로 가독성이 높은 코드를 작성할 수 있고, 때로는 리뷰 코멘트의 근거가 되어주기도 합니다. 만약 메서드 내 들여쓰기가 너무 심해 코드 가독성이 떨어질 경우 “객체지향 생활체조 원칙에 따라 메서드를 분리하여 들여쓰기를 줄여보는 건 어떨까요?” 처럼 확신을 갖고 코멘트를 남길 수 있습니다.
리뷰이를 위한 가이드
•
시간 확보
◦
친구들과 약속을 보름 뒤로 미룬다. (오랜만에 봐야 더 정겹고 할 말이 많다.)
•
매일 1~2시간씩 미션 진행
◦
일주일에 최소 3회 이상 코드 리뷰 요청을 보내자
◦
한 번에 모두 구현하기보다 일정한 시간을 꾸준히 투자하자. 밀리면 밀릴수록 부담스럽다.
•
리뷰어의 의견을 적극 수용하자
◦
거부감이 들 수 있지만 일단 적용해 보고, 적용하기 전과 후의 코드를 비교해본다.
◦
자신이 가진 것을 비울 때 가장 많은 것을 배울 수 있다.
•
그렇지만 리뷰어의 의견에 적극 반대도 해보자
◦
리뷰어는 선생님이 아니라 함께 일하는 동료 개발자.
◦
프로그래밍 설계와 구현에는 정답이 없다.
◦
요구사항에 적합한 최선의 설계와 구현 코드를 찾기 위해 노력하고 토론하자.
리뷰이가 적극적으로 미션에 임하기 위한 마음가짐도 몇 가지 나열했습니다. 리뷰이는 조금씩이라도 여러 번, 꾸준하게 미션을 진행하는 습관과, 내 작업물에 달리는 여러 가지 리뷰 코멘트를 즐거운 마음으로 대할 수 있는 태도를 갖는 것이 중요합니다. 특히 일주일에 최소 3회 이상이라는 정량적인 수치는, 집중도가 다소 떨어질 때 ‘이번 주는 리뷰 요청을 아직 한 번밖에 못 했는데, 서둘러야겠네.’ 라는 자극을 줄 수 있는 장치가 되어줍니다.
리뷰어를 위한 규칙
•
시간 확보
◦
친구들과 약속을 보름 뒤로 미룬다. (오랜만에 봐야 더 정겹고 할 말이 많다.)
•
매 리뷰요청 시 24시간 내로 리뷰 진행
◦
리뷰가 밀리기 시작하면 부담이 커진다. 리뷰이들은 오매불망 나의 리뷰를 기다리고 있다.
◦
리뷰할 시간을 별도로 정해두자. (매일 아침 출근 직후, 매일 저녁 퇴근 직전)
•
리뷰이에게 적극적으로 의견 내비치기
◦
리뷰어는 리뷰이를 가르치는 존재가 아니다. 더 나은 결과물을 위해 아이디어를 제안하는 동료 개발자.
◦
요구 사항 규모보다 극단적인 리팩터링을 제시해 볼 수도 있다. 이를 반영할지 말지는 리뷰이의 재량.
◦
리뷰이가 잘 모르는 부분에 대해서도 예시 코드와 함께 설명해 보자.
특정 지식에 대해 쉬운 문장으로 상대방에게 설명할 수 있어야 진짜 자신의 지식이다.
•
리뷰이의 코드를 평가하는 것이 아니라, 더 나은 결과물을 함께 만들기 위해 토론하는 과정임을 꼭 기억할 것.
◦
왜 개선이 필요한지 충분한 이유를 설명할 것
◦
바로 답을 이야기하기보다, 스스로 고민하고 개선할 수 있는 방법을 제시할 것.
◦
리뷰를 억지로 쥐어짜지 말 것. 할 말이 없으면 칭찬을 해라.
◦
팀 컨벤션에 포함되지 않는 사소한 스타일(성향) 차이는 가능하면 터치하지 않을 것.
•
완벽한 리뷰보다 완주를 목표로
◦
초~중반 단계에서 미션 진행이 더딜 경우 의욕이 크게 저하될 수 있다.
◦
말도 안 되는 코드를 작성했거나, 큰 규모의 리팩터링이 필요한 경우 request changed 를 남긴다.
◦
사소한 코멘트로 충분하다면 다음 단계 진행과 함께 리팩터링을 진행할 수 있도록 approve 를 남긴다.
◦
마지막 단계에선 만족스러운 코드가 완성될 때까지 놓아주지 말자.
리뷰어 역시도 미션 진행을 위해 몇 가지 마음가짐이 필요합니다. 어쩌면 리뷰이보다 훨씬 더 중요하다고 볼 수 있습니다. 리뷰어 역시 정해진 시간에 꾸준히 리뷰를 남기는 것과, 동료 개발자로서 더 나은 아이디어를 설명하고 제안하는 방법을 익히고 코멘트로 남기는 것이 중요합니다. “이 부분은 별도 클래스로 분리하는 게 낫겠어요.” 라는 무미건조한 코멘트보다 “이 부분은 반복적으로 수정하게 될 것 같은데요, 별도 클래스로 분리하면 찾기도 쉽고 테스트 코드 작성도 용이해질 것 같아요.” 같이 충분한 이유를 설명해 주면 좋습니다.
또한 미션 스터디 진행에 있어 리뷰이의 의욕을 관리해 주는 것이 매우 매우 중요한데, 리뷰어가 지나치게 열정적인 경우 리뷰이가 미션 자체에 질리는 불상사가 생길 수도 있습니다. 미션을 진행하면서 점진적으로 코드를 개선해 나갈 수 있도록 완급조절이 필요합니다.
이 사소한 차이가 스터디 전체의 분위기를 좌우한다.
드디어 미션 스터디 시~작!
만반의 준비를 갖춘 보름 안에 끝장내는 코틀린 미션 스터디가 드디어 시작되었습니다. 1단계와 2단계는 간단하게 손풀기용 프로그램을 구현하고, 3~5단계를 거쳐 자동차 경주 미션의 완성도를 높였습니다. (자세한 내용은 저장소를 확인해주세요.) 이론을 눈으로만 접하고 넘어가는 방식이 아닌, 직접 손으로 코드를 작성하고 서로 의견을 주고받는 방식이기 때문에 스터디 참여도와 집중도가 매우 높았습니다. 특히 쉬운 난이도의 미션을 손으로 직접 구현하는 방식에 대해선 “오랜만에 처음 개발을 배우던 시절로 돌아가 코드를 짜는 느낌이다.” 라는 반응이 많았습니다.
더 나은 코드를 위해 서로 적극적으로 아이디어를 공유하고, 능숙하게 잘 작성된 코드를 보면서 감탄도 하고, 아이디어를 참고해서 미션 내용을 리팩터링하기도 하고, 비교적 어려움을 느끼고 있는 리뷰이에겐 오프라인에서 자세하게 도움을 주고받기도 합니다.
사무실 한켠에 옹기종기 모여 오프라인 코드리뷰 - 빛과 소금 종인님
인상적이었던 부분은 프론트엔드 엔지니어 구화님의 리뷰였는데요. 코틀린과 객체지향 초보를 자처하시던 구화님께서는 스터디 초반 소극적인 리뷰 코멘트를 남겨주시다가, 스터디 막바지에 이르러서는 클린코드와 더불어 백엔드 엔지니어들도 무심코 지나쳤던 코틀린 기능들에 대해 적극적인 리뷰 코멘트를 남겨주셨습니다.
가장 감동이었던 점은 서로 매칭된 리뷰이-리뷰어가 아님에도 다른 사람들의 PR 에 관심을 갖고 코멘트를 남기는, 유기적이고 적극적인 코드 리뷰가 이루어졌다는 점입니다. ‘다른 사람들은 미션을 어떻게 진행했고, 어떤 리뷰를 받고 있지?’ 라는 호기심이 작은 씨앗이 되어, 하나의 PR 에 여러 의견이 오고가는 열매를 맺기도 했습니다.
좋은 아이디어는 서로서로 참고하기 / PR 하나에 너도나도 코멘트 남기기
미션 스터디 시작부터 보름 후
평균 진도율이 무려 80%
8월 10일에 시작된 미션 스터디는 보름 후인 8월 24일에 종료되었습니다. 회사 업무와 병행하다 보니 시간과 체력의 제약이 느껴지고 마감 기한 또한 명확하기 때문에 모든 단계를 완주하긴 현실적으로 어렵습니다. 초반에 높은 집중력으로 진도를 확 빼다가 업무에 밀려 주춤하신 분도 계시고, 막판에 스퍼트를 올려 미션에 집중하신 분들도 계셨습니다. 그러나 모두 포기하지 않고 적극적으로 참여해 주신 덕분에 평균 진도율 80% 라는 놀라운 결과를 얻을 수 있었습니다.
진도율은 미션 스터디의 참여도를 정량화한 수치입니다. 자발적으로 점심시간을 헌납하고 미션에 집중하기도 하고, 퇴근 후 한 공간에 옹기종기 모여 토의하며 진행하기도 했으며 주말 아침을 투자해 미션과 코드 리뷰를 진행하기도 했습니다. 보름간 미션 완주를 위해 쉬지 않고 달린 참여자 분들의 피나는 노력을 정량화한 것이니, 사실 진도율 80% 는 이미 예견된 일이었습니다.
미션 완주를 위해 노력하는 모습들
미션 스터디 종료일, 모든 참여자가 한 자리에 모여 KPT(Keep-Problem-Try) 회고를 진행했습니다. 아래는 참여자 분들이 남겨주신 KPT 중 일부입니다.
좋았던 점(Keep)
•
tailrec, value class 등 코틀린 관련 새로운 지식을 습득할 수 있어서 좋았습니다.
•
코드 리뷰 습관을 익히고, 잘하는 방법을 배울 수 있었어요.
•
다른 파트분들과 코드 리뷰할 기회가 적었는데 스터디를 통해 경험해 볼 수 있어서 좋았습니다.
(간접적으로 같이 일해보는 경험 ㅎㅎ)
•
단계별로 나뉘어 있는 게 좋았습니다. 특히나 객체지향과 코틀린에 익숙하지 않다 보니 '이전 단계에서 왜 이렇게 짰었지…' 하는 생각이 자주 들더라고요. 매 단계에서 내가 짠 코드들을 보고 후회하는 자극이 좋았습니다.
•
솔직히 처음에 살짝 귀찮았는데, 다들 너무 열심히 리뷰해 주셔서 재밌었어요 ㅋㅋㅋ
•
지정된 리뷰어가 아니어도 서로 리뷰해 주셔서 좋았습니다! 
코틀린 관련된 새로운 지식과 코드 리뷰 팁, 습관을 얻었다는 후기가 많았고, 다른 파트원들과 코드를 리뷰하면서 간접적으로 함께 일해보는 경험을 가졌다는 후기가 눈에 띕니다. 그 외에도 미션이 단계별로 나뉘어 있어 매번 새로운 자극을 받았다는 점에서 단계를 더 세분화해도 좋겠다는 생각이 듭니다. 무엇보다 모두가 적극적으로 참여해 주신 부분이 너무 좋았습니다.
아쉬웠던 점(Problem)
•
리뷰 요청과 리뷰 완료에 대한 알림이 오면 좋겠어요.
•
리뷰이-리뷰어가 고정되어 아쉬웠어요. 단계별로 로테이션이 돌아도 재밌을 거 같아요.
•
제 코드에 대해 더 신랄한 비판을 받지 못한 게 아쉬워요!
리뷰 요청과 리뷰 완료에 대한 알림이 없었기 때문에 매번 구두로 리뷰 요청과 완료 멘트를 주고받아야 하는 불편함이 있었습니다. 또 다른 참여자의 코드를 리뷰하거나 리뷰를 받아보고 싶은데, 스터디 기간 내내 리뷰이-리뷰어가 고정되어 있다는 점에 아쉬움을 느끼신 분들이 많았습니다. 더 강렬한 리뷰를 받고 싶다는 후기도 눈에 띄었습니다.
다음 미션 스터디에 적용해볼 액션 플랜(Try)
•
각 단계마다 리뷰이-리뷰어 매칭을 달리해보자!
•
슬랙 채널에 리뷰 요청, 리뷰 완료에 대한 알림이 오도록 자동화 해보자!
•
각 단계가 시작할 때마다 한 자리에 모여 공유하고 이야기하는 시간을 가져보자!
아쉬웠던 점(Problem)에 나열된 이야기를 토대로 다음 미션 스터디에 적용해 볼 액션 플랜을 구상했습니다. 매 단계마다 리뷰이-리뷰어 로테이션을 적용하고, 슬랙 채널에 리뷰 요청과 리뷰 완료에 대한 알림이 오도록 자동화를 해볼 계획입니다. 또 매 단계가 시작될 때마다 모이는 시간을 가져서, 미션에 관련된 생각과 팁을 공유하는 시간도 구상했습니다.
다음 미션 스터디에 대한 부푼 기대를 뒤로하고, 보름간의 노력 끝에 성공적으로 스터디를 마무리한 서로를 축하하기 위한 뒤풀이를 하며 첫 번째 코틀린 미션 스터디를 공식적으로 종료했습니다.
첫번째니까 손가락 하나
적극적인 코드 리뷰 문화
미션 스터디 종료 후, 다른 파트 깃허브 저장소를 보면 이전보다 훨씬 적극적으로 코드 리뷰가 오가는 모습을 확인할 수 있었습니다. 파트 너머까지 리뷰를 주고받는 일은 아직 어색하지만, 조금씩 유의미한 변화가 생기고 있었습니다. 이전보다 훨씬 더 코드 리뷰를 가볍고 즐겁게 주고받을 수 있었습니다.
파트를 넘나드는 즐거운 코드 리뷰!
첫 번째 코틀린 미션 스터디가 종료된 지 한 달이 되어가는 요즘은 어떨까요? 여전히 활발한 코드 리뷰가 이루어지곤 있지만, 미션 스터디가 막 종료되었을 때만큼은 아닌 것 같습니다. 시간이 흐르고 각 파트가 점점 더 성숙해지면서, 파트 너머로 적극적인 코드 리뷰를 남기기가 다시 뜸해진 것 같습니다.
하지만 큰 걱정은 없습니다. 지난 미션 스터디 회고에서 계획했던 액션 플랜들을 준비해서 두 번째, 세 번째 스터디를 또 진행하면 되니까요. 주기적으로 미션 스터디를 진행해 나가면서, 점차 적극적인 기간을 늘리고 뜸해지는 순간을 줄이다 보면 언젠가 저희는 파트를 넘어서까지 항상 적극적으로 코드 리뷰를 남기는 팀이 되어있을 겁니다.
