이직을 한지 1년 하고도 반년이 지났다. (실화냐)
이 글을 쓰는 시점에 이직 후에 여름을 두번이나 겪었고, 조직 개편으로 팀을 옮기기도 하는 등 정신 없던 나날들을 보냈던 것 같다.
지금은 최고의 팀 동료들과 즐겁게 일을 하면서 또 한번 나날이 성장중에 있다.
짭퉁 실리콘벨리 개발자 신분으로 스타트업에서의 우여곡절을 기록으로 남기다가 한동안 글쓰기를 쉬었다. 많은 일들이 있었는데, 회고록 시리즈를 연재(?) 할지 여부는 아직 모르겠지만 분명한 사실은 많은 것들을 배우고 깨달았다는 것.
잡설이 길어졌는데, 어쨌든 오랜만에 키보드를 꺼내 들고 워밍업을 위해 주저리주저리 적어볼 이야기는 코드리뷰 "잘" 하는 법에 대해 논해 보기로 한다. (뭔 개소리야)
코드 리뷰는 왜 하는 것일까?
코드 리뷰를 하는 이유(목적)은 간단하다. 코드(제품)의 퀄리티를 높이기 위해서이다.
코드 리뷰는 이제는 전 세계적으로 당연히 해야 하는 필수 기업문화로 자리 잡았다. 과장 좀 보태서 코드 리뷰를 하지 않는 회사 또는 팀은 가면 안되는 것이라고 배웠다. (아직 코드 리뷰를 제대로 도입하지 않은 조직에는 죄송한 표현이지만 그만큼 중요하다)
"우리도 코드 리뷰를 도입했어요" 같은 글들은 요즘은 새로 올라오지도 않는다. (참조한 글 중에 카카오 사례는 2016년에 작성한 글이다)
그러면 나는 왜 이런 뻘글을 쓰고 있는가?
코드리뷰를 "잘" 하기는 힘들기 때문이다.
(미리 이야기 하지만, 내가 지금부터 쓰는 이야기들은 모두가 이미 알고 있고 뻔한 내용이고 구글의 코딩 가이드를 포함한 다른 가이드라인들을 참고한것을 짜집기 한것에 지나지 않는다)
그동안 내가 일해왔던 모든 회사, 팀에서는 코드리뷰(문화, 프로세스)를 개선하고자 하는 갈증은 공통적으로 존재했다. 코드 리뷰 문화는 꾸준히 케어해주지 않으면 금방 퇴색이 되어 버리고 기계적으로 프로세스에 의존하게 된다. 그러다 보면 우리는 중요한 것이 무엇인지 잊는다.
마치 스크럼을 위한 스크럼을 하는 것 처럼..
오래된 회사나 개발 문화와 역사가 깊음에도 불구하고 코드리뷰 생산성에 대한 회의적인 시각들과 우려들이 생기기 쉽다
그도 그럴것이 각자 자기 할일 바쁜데 코드 리뷰 문화가 제대로 정착 하기란 쉽지 않다.
생각보다 소프트웨어는 빠른 속도로 증식하고 복잡도가 증가하기 때문에 숙련된 시니어들도 코드리뷰에 벅찬 순간이 오게 마련이다
개인적으로 (나처럼) 새로 팀에 조인하는 사람들이 많아지면서 문화 전파에 실패 하지 않았나 하는 생각이 있지만, 팀마다 상황도 달라서 마냥 단정 지을수만은 없다. 스타트업과 달리 구성원이 많은 회사는 각자 나름의 이유와 고충이 너무나도 다양하기 때문이다
아무튼, 매니저가 이 기회에 우리 팀 내에서 코드 리뷰 프로세스와 문화에 대한 정리를 해보자는 제안을 하였다. 나만큼 pioneering과 challenging을 즐겨하는 액티브한 성향의 매니저를 만나 고생 참 많은 부분에서 자극을 받고 배우고 있다.
추석 연휴동안 쭉 놀면서 인터넷 상의 수많은 코드 리뷰 가이드들을 훑다 보니, 한결같이 동일한 이야기들을 하는 패턴을 몇개 발견하였는데 그 특징들은 다음과 같다.
완벽한 코드는 없다. (코드 리뷰 대상)
리뷰가 늦으면 안된다. (코드 리뷰 적시성)
싸우면 안된다. (코드 리뷰 문화)
완벽한 코드는 없다.
코드 리뷰에 있어서 가장 중요한 대전제이다. 리뷰를 해야할 타겟(커버리지) 뿐만 아니라 적시성과 문화에 영향을 미치는 가장 중요한 항목으로 모든 가이드라인 들이 이구동성으로 완벽한 코드는 없다는 것을 받아들여야 한다고 강조하고 있다.
In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect.
-구글의 The Standard of Code Review 중-
코드를 고치는 CL(Change List) 작성자와 리뷰를 하는 리뷰어들 모두, 우리는 우리의 궁극적인 목표가 무엇인지를 항상 머릿속에 염두에 두어야 한다.
우리의 제품을 기다리고 있는 수많은 고객들이 있고 원하는 기능을 제대로 구현을 하고 문제가 없는 것이 확인이 되면 거기에서 코드 리뷰는 끝내야만 한다
그 외의 코딩 컨벤션이나 스타일 등의 조언은 그저 optional 일 뿐이기 때문이다.
누군가 코딩 스타일 가이드나 컨벤션을 조금 지키지 못한것을 지적한다거나, 경험 많은 개발자가 오래된 코딩 스타일을 고수하는 것을 지적한다거나, 주니어 개발자가 기능 동작에 전혀 영향을 미치지 않을 경미한 수준의 자원 비효율 따위의 것들을 문제삼는 등의 리뷰들은, 제품 delivery 앞에서 한낱 먼지들에 지나지 않는다.
실제로 나는 예전 회사에서 동료와 메모리 선언을 local에 하느냐 global에 두느냐를 두고 argue 한 적도 있다. 지금 생각해 보면 진짜 piece of shit 수준의 토론이었다.
리뷰가 늦으면 안된다.
개발자들은 바쁘다. 그럼에도 내가 정말 급한 일이 있지 않는 이상 다른 사람의 코드 리뷰를 최대한 빨리 해 줘야 하는 가장 중요한 이유는
개인의 속도 보다는 "팀의 속도"가 중요하기 때문이다.
구글 가이드에 따르면 리뷰를 함에 있어서 특히 major change(핵심 변경 사항)에 대한 리뷰가 ASAP 이루어져야 하는 이유는 다음과 같다.
- 핵심 기능의 디자인 변경은 시간이 오래 걸린다. 따라서 최대한 리뷰를 빠르게 해서 미리 올바른 방향으로 수정이 되도록 유도해야 한다.
- CL 작업자가 뒤늦은 리뷰를 보고 또 rework을 하게 되면 피로도가 쌓이고 코드 수정에 많은 비용을 할애한다
많은 가이드라인들인 24시간 이내에 가급적 코드리뷰를 전달하라고 한다. (시작이 아니라 리뷰 결과 전달이다)
최근에 내가 하던 일에 집중하느라 코드 리뷰 요청을 2일 정도 늦게 본 적이 있었다. 다행히도 다른 동료들이 리뷰를 해 주었다. 흥미로운 CL이었기에 나도 토론에 참여를 하고 싶었지만 꾹 참았다. 이미 많은 부분들이 개선이 되어서 merge될 준비가 되어 있었고 내 아이디어에 대한 토론을 다시 시작하면 또 다시 딜레이가 되어서는 안되었기 때문이다.
사실 EA 코리아를 비롯해서 수많은 회사들이 이제는 더이상 정량적인 평가 기준으로 직원 평가를 하는 아재식 기업문화를 버리고 있다. (EA 코리아의 기업문화에 대한 이야기는 나중에 또 할 기회가 있으면 좋겠다)
누가 코딩을 얼마나 많이 하고 잘 했는지 여부 만으로 그 사람의 기여도를 평가하는 조직은 좀 과격하게 표현하면 "가면 안되는 곳" 이다.
싸우면 안된다.
동서고금을 막론하고 참 많이들 싸우나 보다.
본능적으로 과학자, 엔지니어들은 자신의 주관을 지키고 싶어하는 성향이 있다. 건전한 토론 문화가 정착된 조직에서는 이러한 투지는 전체 조직(팀, 회사)의 성장에 매우 지대한 공헌을 한다. 문제는 Discussion 이 아닌 Debate(또는 Ego)이 되어버리기 쉽다.
그리고 개발자들은 표현이 서툴다.
모든 가이드라인에서 공통적으로 표현을 완곡하게, 그리고 예의 바르게(courteously) 하라고 강조한다. (다들 싸워봤고, 그러인해 팀웍이 무너지거나 프로젝트가 실패한 경험이 있다는 뜻이겠지..?)
예전 회사에서 코드 리뷰를 하면서 개싸움을 해본적이 있는 경험자로서 쓰라린 기억들이 주마등처럼 지나간다.
"응 니 코드"
개개인의 성향이 모두 다르기 때문에 협업을 함에 있어서 상대방에 대한 배려는 이제는 정말 중요한 덕목이다.
더이상 조직내의 스타 개발자나 스티브 잡스식 독불장군이 인기를 끄는 시대는 지났다.
나는 리뷰를 받는 입장에서는 항상 경건하게 배운다는 자세로 임하려고 노력한다.
리뷰어가 나보다 경력이 많든 적든 나이가 많은 적든 나보다 잘 생겼든 (
그리고 어떤 유형의 표현과 리뷰들이 남겨지더라도 최대한 감정을 배제하고 논리적인 타당성만 판단하려고 노력한다. 이게 정말 쉽지 않다. 그리고 나는 여전히 많은 리뷰에 대해 방어적으로 대응한다(고 피드백을 받았다)
잊지 말자, 우리는 앞으로 나아가고 성장해야 한다.
그것 이외에는 전혀 쓸데 없는 것이다 정말로.
P.S. 더 많은 레퍼런스를 넣어봤자 별로 도움이 되지 않는다. 어차피 다 같은 소리들을 하고 있을테니까.
내가 내린 결론은 위에 3가지만 명심하고 각자 팀 문화에 맞게 코드 리뷰 문화를 함께 만들어 나가면 된다는 것이다.
References:
내가 내린 결론은 위에 3가지만 명심하고 각자 팀 문화에 맞게 코드 리뷰 문화를 함께 만들어 나가면 된다는 것이다.
References:
Google
The Standard of Code Review
Writing good CL descriptions
Kakao
카카오스토리 팀의 코드 리뷰 도입 사례 – 코드 리뷰, 어디까지 해봤니?
if kakao 발표자료
https://mk.kakaocdn.net/dn/if-kakao/conf2019/%EB%B0%9C%ED%91%9C%EC%9E%90%EB%A3%8C_2019/T05-S03.pdf
Code Review is a Waste of Time
https://medium.com/@ivorobioff/code-review-is-a-waste-of-time-4366811b00ca
부록:
개인적으로 겪어보고, 저질러봤던, (그리고 많은 가이드 라인에서 말하는) 코드 리뷰에서 좋지 않은 표현들은 다음과 같다.
- 아무 설명 없이 코드를 적는 것: 니 코드 보다 이게 낫다 라는 굉장히 강압적이고 무시하는 듯한 느낌을 줄 수 있어 조심해야 한다. 친한 사이에서 적은 코드 리뷰라 할지라도 잘 모르는 제 3자가 봤을때에도 그런 뉘앙스를 느낄수 있다. 그리고 이런 리뷰가 허용 된다는 무의식이 조직에 퍼지게 된다
- 이거 왜 이렇게 했어요? : 부연설명 없이 잘 이해가 안된다는 한마디는, 설령 정말 궁금해서 물어본 것이라 할지라도 온라인 코드 리뷰 상에서 제한적인 뉘앙스 때문에 오해의 소지를 불러 일으킬 수 있다. 그리고 리뷰어가 컨텍스트를 제대로 이해 못했다는 것과 다를바 없다. 컨텍스트를 이해하지 못하겠으면 정중하게 정보를 습득하기 위한 질문을 해야 한다.
- 핵심 내용에 대한 언급은 없고 컨벤션이나 코딩 스타일만 지적하고 있는 리뷰: 가장 위험할 수 있는 리뷰이다. CL 작성자의 감정을 상하게 할 수 있기 때문이다. 핵심을 언급하지 않고 주변만 서성거리고 있다는 것은, 리뷰어가 컨텍스트를 이해하지 못하고 있거나 CL에 굳이 언급할만한 큰 이슈가 없다는 뜻이다. Nit(Not important Though)는 한두개로 족하다.