#10. 개발 문화(3)
코드리뷰
누군가에게 평가를 받는다는 것
살아오면서 문득 들었던 생각 중에 하나는 '우리는 매 순간 누군가에게 평가를 받고 있다'라는 사실입니다. 초등학교 시절 숙제를 제출할 때 선생님이 찍어주는 '참 잘했어요' 도장을 받았을 때, 군입대를 앞두고 받은 신체검사에서 '1등급'을 받았을 때, 대학원 졸업을 앞두고 많은 교수님들과 석박사 과정 선후배들 앞에서 논문 심사를 받았을 때, 회사를 입사하기 위해 인터뷰를 하거나 코딩 테스트를 했을 때까지 알게 모르게 수없이 많은 평가를 받아오며 살아가야 하는 숙명을 지녔을지도 모른다는 사실은 어쩔 땐 우울하기까지 합니다.
매일 이런 평가만 받는다면 좋겠지만... [사진 출처 : https://upload.wikimedia.org/wikipedia/commons/thumb/5/59/%27%EC%] 하지만 평가를 받음으로써, 상대방이나 내가 가고자 하는 집단의 성향을 파악할 수 있으며 나 스스로가 어떠한 결점이 있는지 확인할 수 있는 가장 빠르고 정확한 방법 중에 하나라고 생각을 합니다. 내가 천직으로 삼고 있는 프로그램 엔지니어의 직업처럼 혼자 고민해야 하고, 혼자 작성해서, 혼자 테스트해야 하는 빈도가 많은 분야는 만드는 과정에 있어서 자가당착에 빠지는 경우도 많고, 옳지 않은 알고리즘으로 작성함에도 불구하고 뜻밖의 올바른 결괏값이 나왔을 때 자기 합리화에 빠져버리는 경우도 많습니다. 이럴 때 필요한 것은, 관여하지 않은 제삼자의 관점에서 평가를 받는 방법이 가장 효과적이겠지요.
코드리뷰
충청도에서 사는 사람과 강원도에서 사는 사람은 공통적으로 '한국어'를 사용하지만, 말하는 방식이나 뉘앙스가 조금씩 차이가 있습니다. 개발도 마찬가지로 'JAVA'라는 언어를 사용하지만, 동일한 결괏값을 뽑아내는 프로그램이라 할지라도 각 개발자마다 구현하는 방식이 다르거나 표현하는 스타일이 다릅니다. 결괏값이 올바르다면, 해당 프로그램으로 동작하는 시스템에는 큰 문제가 없지만, 역할이 자주 변경되어야 하는 회사나 협업이 중요시되는 프로젝트에서는 제각각인 구현 방식과 코드 스타일은 잠재적인 문제점을 초래하게 됩니다.
더군다나, 앞서 언급한 바와 같이 결괏값은 올바르지만 구현 알고리즘이 잘못된 경우에는 추후에 치명적인 오류를 발생하게 되는 직접적인 원인이 됩니다.
코드를 개발자가 작성하고, 다른 개발자가 정해진 방법을 통해 검토하는 일을 '코드 리뷰'라고 합니다. 코드를 작성한 개발자는 코드 리뷰를 통해 팀에서 정한 코딩 규칙(코딩 인벤션)에 잘 맞춰졌는지, 해당 코드에 문제점을 없는지를 확인함으로써 좀 더 견고한 프로그램을 산출하며, 자신의 결점이나 개선점을 찾을 수 있게 됩니다.
최근에는 이러한 코드 리뷰를 하는 개발팀이 많아짐으로써, 위처럼 예를 들어가면서 까지 설명을 해야 하는 상황은 좀처럼 만나기 쉽지 않았지만, 불과 4~5년 전 (지극히 개인적인 경험이지만)만 해도 코드 리뷰를 한다는 것은 꽤나 설득하기 힘든 일이었습니다.
감히, 네놈이 내 코드를 검사해?
라던가
나도 바빠 죽겠는데 남의 코드 봐줄 시간이 어딨음?
라던가
어이 X팀장, 그 시간에 이 프로젝트 좀 해줘.
등의 자신을 평가한다는 것에 대한 거부감도 많았고, 시간낭비라는 인식이 강했다는 기억이 남아있습니다.
물론, 그 당시에도 꾸준하게 코드리뷰를 하며 개발팀을 꾸린 사례들을 많이 봐왔었습니다만, 저에게 있어서는 부럽기만 한 소설책이었던 적이 있었습니다.
저는 이직할 때, 면접 시 '이 회사는 코드 리뷰를 합니까? ' 또는 '해당 팀원들은 코드 리뷰에 대한 경험이 있습니까'라고 질문하며 코드리뷰의 여부에 따라 회사를 결정합니다. 그 정도로 코드 리뷰는 중요하다고 생각합니다.
리뷰 부탁드립니다. (レビュー お願いします)
이 회사에서는 Github에서 버전 관리 및 배포관리를 하고 있습니다. 따라서 PR(Pull Request)를 통해 코드 리뷰를 하게 되는데, 대략적인 프로세스는 다음과 같습니다.
branch생성 -> 소스 작성 -> 로컬 테스트 -> commit & push -> PR(Pull Request) 작성 -> 코드 리뷰 -> 승인 및 거절 (거절 시엔 다시 소스 작성으로 리턴) -> (승인 시) master branch 또는 development branch로 merge -> 완료(배포)
각 단계마다 각 팀이나 회사에서 정한 규칙들이 적용되기도 하지만, 일반적인 프로세스는 위와 대부분 동일하게 적용됩니다. (좀 더 구체적인 설명을 찾아보고 싶다면 링크 클릭! 비교적 쉽게 설명이 되어 있네요.)
보통, 개발자와 리뷰어(개발자의 코드를 리뷰하는 역할)는 개발 킥오프 시점에 미리 정해 놓는 것이 일반적이지만 (흔히, 우리나라에서의 사수 부사수처럼) 이 회사에서는 딱히 정해진 규칙 없이, 자신이 받고자 하는 개발자에게 부탁하는 것이 일반적입니다. 물론, 리뷰어도 자신만의 스케줄이 있기 때문에 갑자기 리뷰를 요청하기보다는 아침에 진행하는 칸반 Standup 회의나 Slack에서 미리 양해를 구하고 요청을 합니다.
Github에서 승인자를 선택한 후에 PR을 생성하게 되면 자동으로 승인자에게 메일이 발송되어, 리뷰 요청이 왔는지에 대한 판단을 할 수 있지만, 리뷰어의 편의를 위해 Slack 채널에 다시 한번 리뷰어에게 요청을 합니다.
일반적으로는 Slack을 통해 리뷰 요청을 합니다.이 회사는 코드 리뷰에 대한 특정 룰은 없지만 지금까지 경험한 느낌으로 정리해 본다면 다음과 같은 암묵적인 룰을 통해 코드 리뷰가 이루어집니다.
1. 코드 리뷰 단위는 branch단위로 요청한다.
2. 리뷰어는 개발자의 판단으로 1명 이상이 될 수 있다.
3. 리뷰어가 없을 경우에는 코드 리뷰를 생략할 수 있으나, 코드 merge전에 코드 리뷰는 기본적으로 진행하도록 한다.
4. 코드 리뷰는 반드시 github PR을 통해서 진행한다. (PR 없이 오프라인 리뷰는 진행하지 않음)
5. 가급적 리뷰는 요청 후 1일 이내로 진행한다. (휴일 제외, 업무시간 기준)
6. 리뷰 내용은 반드시 comment로 남긴다.
리뷰의 내용은 리뷰어에 따라 약간의 스타일 차이가 있지만, 굉장히 타이트한 리뷰가 진행됩니다.
지금까지 느낀 바로는, 이 회사의 개발자들은 자신의 개발보다 타인의 코드를 리뷰하는데 더 많은 신경을 쓰고 있는 건 아닐까 싶을 정도로 꼼꼼하게 확인을 합니다.
괄호와 중괄호 사이에 스페이스 용납 못함!글 앞머리에 언급했던 것처럼 코딩 인벤션도 매우 중요한 부분 중에 하나이기 때문에 괄호 사이에 공백 하나까지도 리뷰를 해줄 정도로 꼼꼼하게 리뷰를 해 주기 때문에 팀 스타일에 빨리 적응이 가능하고, 추후 다른 개발자가 인계를 받아도 같은 스타일로 코드를 읽고 쓸 수 있는 장점이 있습니다. (알고리즘이나 코드 효율성에 대한 부분은 따로 언급할 필요가 없을 정도로 엄격합니다.)
저의 경우에는 입사 초기 그 스타일을 따라잡지 못해 한 branch에 리뷰 코멘트를 30개가 넘을 정도로 많은 피드백을 받았습니다.
입사 초기 PR할때마다 쌓여가는 PR거절과 수정제안 코멘트... T^T물론 리뷰 시 해당 코드에 대해 토론을 펼치면서 많은 코멘트가 달리는 경우도 있긴 하지만 위의 그림은 모두 수정 요청 코멘트였습니다. 많은 고민을 한 뒤에 개발을 한 뒤에 수많은 지적 코멘트를 받았을 때는, 당연히 힘이 빠지고 의욕이 꺾이는 경우도 있습니다. 또한, 개인적인 스케줄을 짜서 순차적으로 작업을 진행해야 하는 경우에는 해당 리뷰가 길어져서 일정까지 계속 미뤄지는 경우도 있어서 마음이 조급 해지는 경우도 있기도 합니다.
더군다나, 리뷰어 또한 자신의 업무 시간을 할애하여 리뷰를 하기 때문에 프로젝트 전체적으로 일정이 딜레이 되는 경우도 이 곳에서는 종종 있습니다.
하지만, 이곳의 모든 개발자들은 리뷰 자체도 개발의 일정으로 자연스럽게 인식하고 있기 때문에 일정으로 인해 리뷰를 대충 하거나, 대충 해주길 바라는 모습은 전혀 보이지 않습니다.
결과적으로 우리 회사의 솔루션은 비교적 탄탄한 소스로 구성되어 있으며, 버그 발생률도 현저히 낮습니다.
긴급 패치의 경우에는, 새벽에 리뷰 요청이 오는 경우도 있지만, 그 부분에 대해서 모두들 당연하게 받아들이고 있으며 긴급이라고 해서 코드 리뷰를 생략하거나 대충하는 경우는 아예 없습니다. 오히려 더 꼼꼼하게 살펴보는 모습을 보면서 제 스스로의 마음가짐을 다시 가다듬는 기회가 되기도 합니다.
하지만 칭찬만큼은 확실히
아무리 코드 리뷰가 몸에 배어있다고 해도 남에게 지적받는 일에 대해서는 마냥 기분 좋게 받아들일 수는 없는 일입니다. 하지만, 개선점에 대해서 확실하게 수정하고, 오랜 고민 끝에 작성한 코드에 대해서 호응을 얻었을 때에는 다시 힘이 나게 마련이지요.
개인적으로 생각하는 코드 리뷰에서 가장 중요한 부분 중 하나는 바로 리엑션이라고 생각합니다.
지적에 대해서는 냉정하게, 칭찬에 대해서는 확실하게 한다면 리뷰를 받는 개발자도 다음 리뷰에 대한 두려움이나 걱정은 가볍게 사라지지 않을까요?
Looks Good To Me!!
잘못된 점이 있을 때는 폭격기처럼 쏟아내는 수정안에 정신이 없지만, 그로 인해 완벽한 소스가 되었다면 온갖 움짤과 이미지를 이용해 수고했다는 표시를 해줍니다.
우리 회사지만 부러워.
개발 문화라는 것은 CTO나 개발 팀장 혼자만의 능력으로는 이루어 질 수 없다는 것을 계속 느낍니다.
꼬꼬마 주니어 개발자 시절에는 열정만으로 밀어붙여 그 문화를 만들어 내지 못했을 때, 회사탓을 많이 했던 기억이 납니다. 하지만 경력이 두자리 수가 된 지금 시점에서는 팀을 이루고 있는 개발자들의 의식이 더 중요할 지도 모르겠다는 생각을 해봅니다.
애자일이던, XP프로그래밍이던, 칸반이던 온갖 좋은 개발 문화 이론들이 쏟아져 나온지 오래되었지만, 자연스럽게 정착된 팀에서 일해 보는 것은 그리 흔치 않은 일이라 생각합니다.
회사의 개발자에 대한 신뢰도 있어야 하며, 개발자 스스로의 책임의식도 중요하고, 당장 코앞의 성과가 아닌 장기적인 성과를 바라보며 기다릴 줄 아는 센스와 인내심도 함께 녹아들어야 좋은 개발 문화가 자리를 잡는 것이 아닌가 합니다.
우리 회사이기에 좋은 점만 부각해서 설명한 부분이 전혀 없지는 않습니다. 현실에는 분명 단점도 존재하고 부족한 점도 많이 있습니다.
하지만, 좋은 개발 문화에 몸에 베어있는 개발자들로 이루어진 팀을 갖고 있는 회사는 어쩌면 세상에서 가장 강한 회사가 아닐까 합니다. 적어도 회사의 서비스가 실패할 수는 있어도 회사가 실패할 경우는 없을 것 같은 설명하기 힘든 묘한 자부심이 드는 것은 아마 저도 개발자라는 직업을 갖고 있어서 일지도 모르겠습니다.
오늘은 우리 동네(치바 카시와)에 첫눈이 왔답니다. 2016년 11월 이후 1년 3개월만에 내린 눈이네요. 서울은 여전히 춥고 미세먼지까지 겹쳐있다는 뉴스를 봤습니다. 부디 건강조심하시면서 지내세요!
