Code Review
슬기로운 쿠팡페이 개발 생활
회의실이 많은 회사에서 근무하고 싶어요.
2016년 2월 난 쿠팡에 입사했다. 당시를 회상해보면 회의실이 부족했던 것 같다. 코드 리뷰를 해야 하는데 회의실은 없고 눈치 없는 시간은 계속 흘러갔다. 결국, 우리가 택한 방법은 사무실의 빈 벽을 이용하는 것이었다. 이런 식이다. 사진을 찍어 놀 걸 그랬다.
거의 선채로 코드 리뷰를 하고 가끔 화면 앞을 가로지르는 개발자도 있었다.놀라웠다. 회의실이 없거나 코드 변경의 범위가 작다면 안 하면 되지 않는가? 바빠 죽겠는데, 왜 이리 코드 리뷰에 집착하는 걸까? 수년 동안 개발을 해왔고, 많은 회사를 다녀봤지만 이런 코드 리뷰라는 문화를 가진 회사는 처음이었다. 기존 회사에서는 주로 개발 / QA / Release 순으로 진행을 했었다. 사실 동료들에게 나의 코드를 보여주거나 다른 동료가 내 코드를 고치는 것도 극도로 싫어했었다.
아주 가끔 코드를 보여주는 경우는 다음과 같았다.
개발하다가 잘 안될 때, 누가 도와줬으면 할 때
배포하고 문제가 됐는데 무엇이 문제인지 못 찾을 때
신규 라이브러리를 도입했을 때. "얘들아! 이거 이렇게 사용하는 거란다. 코드 엄청 짧아져!"
코드 리뷰하면 뭐가 좋나요? 바쁜데 그냥 배포하면 안 되나요?
로마에 가면 로마의 법을 따르는 법! 난 선택의 여지가 없었다. 지금부터는 내가 쿠팡에 입사해서 코드 리뷰라는 문화를 통해서 경험하고 깨달은 부분에 대해서 얘기해보려고 한다.
의사가 제 병 못 고친다.
개발을 마무리하고 나면 보통 자신만의 방식으로 테스트를 하거나, Test Code를 통해 개발물에 대한 검증을 한다. 그런데 아무리 많은 테스트를 했더라도 (심지어 테스트를 안 하는 개발자들도 많다.) 주관적으로 할 수 박에 없다. 코드 리뷰를 하다 보니 이런 부분을 누군가 찾아내더라는 거다.
"와~~ 이런 게 있을 줄이야! ㅠㅠ"
동료들에게 코드 변경 사항을 알린다.
처음 입사해서 업무에 빨리 적응 하려는 욕심에 문서를 찾아다녔다. 거의 없었다. Wiki가 있었지만 머랄까.. 그리 잘 정리되지 않은 느낌이랄까. 다이어그램을 이용한 문서가 그래도 볼 만했다. 전체 시스템 구성도가 있었고, Payment Flow를 잘 정리한 문서들이 있었다. 한 가지 신기했던 건, 몰라서 물어보면 너무 잘 알고 있는 거였다. "도대체 이 개발자들은 기억력 천재들인가?"
문서 찾는 걸 포기하고 다이어그램을 통해 전체 시스템을 이해하고 코드를 보기 시작했다. 코드는 읽을만했다. 생각해보면 코드만 한 문서가 어디 있단 말인가. 어차피 개발자들은 요구사항을 받아들여서 코드로 승화시키는 거 아닌가!
코드 리뷰 활동을 통해 왜 이 코드를 짜게 됐고, 어떤 부분을 수정하게 됐고, 어떤 부분은 새롭게 만들었다는 것을 알린다. 이런 활동을 통해 어떤 업무가 있고 어떻게 시스템이 동작하고 있는지 이해할 수 있었다.
나의 코드가 아닌 팀의 코드
코드 리뷰 활동을 통해 나의 코드가 팀의 코드가 된다. 내가 비록 개발하지 않았어도 코드 리뷰가 끝나게 되면 팀의 코드가 된다. 코드 리뷰를 통해 이미 왜 이 코드가 생성이 되었고, 코드의 결함을 파악했고, 이 코드가 문제가 있으면 어떤 에러 메시지가 나올 것을 이미 알고 있다. 그리고 이런 작은 코드들이 모여서 하나의 시스템이 완성된다. 자연스럽게 코드에 대한 Ownership이 생긴다. 배포 단계에서 Canary라는 과정이 있는데, 이 단계는 실제 운영서버 한대에만 배포를 해서 트래픽을 받고 에러가 없는지 또는 서버에 문제가 없는지 모니터링하는 과정이 있다. 코드를 어느 정도 이해한 상태이고 대략 언제쯤 배포될 것을 알기에 이때 문제가 발생하면 바로 RollBack 과정을 거치게 된다. 당연히 배포 담당자가 모니터링을 하지만 팀의 구성원들도 어느 정도는 알기에 이후 무엇이 문제 됐는지를 파악할 때도 도움이 된다. 혼자만 알고 있는 코드와 팀 동료들이 알고 있는 코드의 차이라고 이해해주면 좋겠다.
리뷰를 통해 배운다.
신기술이나 테크닉 등을 얘기하고 싶은 것이 아니다. 코드 리뷰를 할 때는 코드의 60~70%를 이해하고 있는 Tech Leader, Manager, 동료 개발자들 등 정말 바쁘지 않다면 참여를 한다. 이들은 코드 자체를 보기도 하지만 전체적인 맥락에서 어떤 문제가 있을지 입체적으로 리뷰하는 능력이 있다. 뛰어나서가 아니라 전체를 어느 정도 알기 때문이다. 동료 개발자들은 코드를 봐주고 Manager는 비즈니스 사항이나 히스토리 기반으로 조언을 한다.
대략 이런 이야기들이 오간다.
"함수 하나에 너무 많이 구현을 하면 나중에 코드를 보기 어려울 수 있어요."
"이런 건 꼭 코드로 짜야할까요? 담당자와 상의해서 데이터만 공유해주는 게 어떨까요?"
"이 날짜 포맷 변경하는 부분은 이미 Utility 함수가 있으니 구현하지 말고 Utility 함수를 사용하면 좋겠어요. 그래야, 일관성이 있고 유지보수가 쉬울 것 같아요."
"결제 인증 수단이 추가될 수 있다고 Leader 회의에서 들었습니다. 이 부분은 확장 가능하도록 개발하면 좋겠습니다."
"이 부분이 문제가 있다고 해서 결제가 실패되면 안 될 것 같아요. 부가적인 기능이니 별도 트랜잭션으로 분리하는 게 좋겠습니다. 에러 발생 시에 INFO 레벨 정도의 로그는 남기는 게 좋겠어요."
Junior Developer 및 입사한 지 얼마 안 돼서 전체를 모르는 개발자들에 대해서는 엄청난 이득이 될 수 있다. 친한 동료나 사수 한 명에게 조언을 듣는 거보다 여러 사람들이 리뷰를 해주는 거는 실제로 많은 도움이 된다. 의사 결정을 바로 할 수 있어서 시간을 아낄 수 있고, 몰랐던 부분에 대해서 다른 코드들도 보여주면서 더 깊이 알게 된다. 결국 이런 리뷰들이 여러 번 반복되다 보면 코드를 이해하는 능력이 높아지면서 자신감을 갖게 된다. 코드에 대해 자신감이 생기면 생산성이 높아진다.
코드 리뷰도 순서가 있나요?
1. 약속 잡기
특별한 건 없다. 개발을 완료하고 동료들의 회의시간을 검토해서 가급적 모두 모일 수 있는 시간으로 회의를 잡는다. 코드의 양이 적다면 Git Branch 명을 알려준다던가, 어떤 부분에 대해서 코드 리뷰를 하겠다고 스크럼 시간에 미리 말을 해주기도 한다. 코드의 양이 많을 때는 별도로 위키 문서를 만들거나 다이어그램 등을 그려서 초대 메일에 링크를 적기도 한다. 코드 양에 따라서 짧게는 30분, 길게 해도 1시간을 넘지 않는다.
"코드 리뷰 합니다. 쿠팡캐시 사용 시 금액 계산 버그가 있어서 수정했습니다. 많은 참석 부탁해요."
2. Concept Code Reivew
개발을 해야겠는데 막상 어떻게 시작을 해야 할지 모를 때가 있다. 또는 Sprint(2주) 내에 끝낼 수 없는 규모 있는 개발을 하고자 할 때, 타 팀과의 의존성이 많은 코드일 때는 Concept Code Review를 권장한다.
(Concept Code Review 단계는 필수 단계는 아니다.)
나의 생각을 동료들에게 물어보는 자리다. 실제로 많은 코드를 작성하고도 방향을 잘 못 잡아서 다시 개발을 하는 일들도 종종 있다. 얼마나 아까운 시간인가?
보통 다음과 같이 정리해서 콘셉트 리뷰를 요청한다.
Wiki - 자신이 이해하고 있는 요구 사항을 정리하고 구현을 한다면 어떻게 할지에 대해서 정리
다이어그램 - 타 팀과 어떻게 인터페이스 할지를 미리 그려본다.
캐시 사용 API에 대한 간단한 스케치백오피스 기능을 어떻게 만들지 스케치를 한다. 어떤 개발자는 Easter Egg를 심기도 한다. :)
백오피스 기능 스케치내 생각에 개발자들은 Concept Code Review 시간을 더 즐기는 것 같다. 정답을 정해 놓고 하는 자리가 아니라 어떤 방법이 좋을까에 대한 자리인 거다. 개발자들의 상상력이 발휘될 수도 있고 조금 더 자유로운 분위기에서 이야기를 나눌 수 있다.
3. Code Review
모두 모였다면, 간단히 해당 코드가 어떤 부분을 해결하기 위함인지? 에 대한 설명을 하고 에디터 화면을 공유해서 리뷰를 진행한다. 요즘 코로나로 인해 거의 재택근무를 하기 때문에 온라인 화상회의를 이용해서 코드를 공유하고 있다.
4. Update code & Deploy
코드 리뷰 과정에서 나온 수정사항이 많다면 3번 과정을 다시 한번 한다. 수정사항이 적다면 수정사항이 반영됐다는 걸 알리면서 동료에게 코드 Merge를 요청한다. Merge 요청을 받은 동료는 체크를 하고 Merge를 한다. 그런 다음 매니저가 코드를 한 번 더 점검하는 과정을 갖게 되고 배포가 진행된다.
중요한 이야기
코드 리뷰 경험이 전혀 없던 내가 어떻게 이 문화에 적응할 수 있었을까?
쿠팡 페이 조직은 어떻게 이런 문화를 계속 유지할 수 있었을까?
양쪽의 목적이 부합하다.
리뷰 요청자
코드가 요구사항에 맞게 작성됐는지 검증받기를 원한다. (제일 중요)
내가 모르는 코드의 결함을 알고 싶다. 배포 시 안정감을 준다.
구현한 내용을 팀에 알린다.
"이번 업데이트로 탈퇴한 사용자의 캐시 사용 요청이 들어오면 에러가 안 날 거예요."
리뷰어
어떻게 개발했을까 궁금해.
"이번 변화로 기존 프로세스가 어떻게 변경되는 거지?"
"백오피스에 이 기능이 있으면 다음 장애 때는 빨리 복구가 되겠구나!"
팀의 매니저나 Tech Leader는 팀에서 담당하는 비즈니스나 코드 레벨까지 어느 정도는 이해하고 있어야 한다. 그래서 가급적이면 코드 리뷰에 참여하려고 한다. 아무 신경도 안 쓰다가 갑자기 코드를 보여 달라고 하는 것보다는 낫지 않은가?
고수의 코드를 감상하기 위해서 :) 실제 입사 초기 시절에는 타 동료들이 코드를 어떻게 개발하고 어떤 사상을 갖고 있는지 궁금했다.
운영이 가능한 코드인가를 본다. 개인의 코드가 아닌 팀의 코드가 되는 과정
기름기 빼고 본질에 집중하다.
코드 리뷰 또한 사람이 하는 일이다. 리뷰를 하다 보면 의도치 않게 상대방의 감정을 상하게 할 수도 있다.
개인적인 감정이 아니라 해결하고자 하는 본질에 집중한다.
서로를 배려하는 부드러운 표현이 필요하다.
우리는 좋은 품질의 코드(운영이 가능한 코드)가 우리의 워라벨을 보장해줄 수 있다는 걸 알고 있다. :)
마치며
코드 리뷰를 어떻게 시작할지 망설이고 있는 분들에게 도움이 될 것 같아요.
최대한 쉬운 언어로 작성했는데 혹시라도 모르는 용어가 있다면 댓글 달아주세요. :)
읽어 주셔서 고맙습니다.
