개발자들이 코드리뷰를 하는 이유

이 글은 "코드리뷰"가 뭔지 처음 들어보는 학생들을 위한 글이다.

또는 그런 걸 전혀 모르는 CEO를 위한 글이다.

"코드 살펴보기"

단순히 그렇게만 생각하지 말고, 조금 더 세련되게 이해해보자.

 

 

 

1.

그 : “코드리뷰 해야 한대.”
나 : “???”
그 :“그걸 해야 한대.”
나 :“???”

갑자기 코드리뷰 회의가 잡혔다.
회의실에 프로젝트를 쏘면서
모든 개발팀이 모여서 코드를 보며 회의를 한다.

괜히 누군가 한마디 던진다.
A : “저거 저렇게 하면 안되고 ….”
B : “아, 저건 이런저런 이유로 저렇게 만든거구…”
A : “그래도 저건 저렇게 하면 안되구…”
B : "..." 

암튼 그랬다.
월급주는 경영진이 시킨 일이니까.

뭐 돈 드는 것도 아니니까 해보기로 했다.

 

그렇게 “코드리뷰”란 걸 처음으로 접했다.
물론 지금은 그렇게 하지 않는다.

사실 "코드리뷰"란 거 이미 옛날부터

모르는 사람 빼고는 다 하고 있었다.

 

2.

학 : “코드리뷰 좀 해주세요.”
나 : “음… 볼까? … 이건 이렇게 하는게 더 좋을것 같은데…?”
학 : “우와~ 그렇게 보면 척하고 알아요?”
나 : "..."

학생들이 하는 소리다.

흠. 코드리뷰.
학생들은 뭔가 판타지가 있구나.

 

3.

코드리뷰 하는 법
코드리뷰 체크리스트
코드검토
…

검색을 해본다.
안 나온다.
코드리뷰를 왜 하게 되었는지.

그러니, “회의식 코드리뷰”를 하지.
사장님이 시켜서 ...
질문 하나 없이 말이다.
하아…

 

“카카오스토리팀의 코드리뷰 도입사례”
정말 훌륭한 글이다.

정말 훌륭한 글이다.

하지만....

글 쓴 사람은 잘못이 없다.
듣는 사람이 문제다.
초보자는 그런 행위를 “코드리뷰”로 안다.

회사 전무님도 그게 코드리뷰인 줄 안다.
하아…

"꼭 코드리뷰할 것"

최악은 프로세스로 정해놓는 것이다.

개발팀 의견도 물어보지 않고 !!!

 

하아...

정말 회사가 망할 수 있다.

 

이걸 프로세스로 정한다는 것 자체가

회사 임원진이 "소프트웨어 제품의 생산과정"에

무관심하다는 뜻이다.

 

잘 알지 못할 순 있다.

하지만 "무관심"한 건 안된다.

 

4.

우리나라 IT산업은 빅3라고 이야기하는 대기업의 SI에 의해 성장했다.
함수가 1,000개가 넘으니까 정말 건설처럼 만든다.
철저한 분업이라 설계와 개발이 나뉘어진다.
그래서 별도의 소통관리기법을 사용한다.
바로 “문서”다.
그래서 문서로 일하는 게 발달했다.

하지만, 실리콘밸리 스타트업은 다르다.
그 사람이 개발하고, 그 사람이 운영하고, 그 사람이 책임자다.
함께 일하는 팀원들이 다 개발자다.
사장님께는 말로 설명하면 된다.
문서를 만들 이유가 없다.
간단히 손으로 그리고,
만들어 놓은 코드를 보면서 대화한다.

보지도 않는 100장짜리 분석설계 문서를 만들 이유가 없다.

개발하지 않는 누군가에게 개발을 설득시킬 필요가 없다.
책임은 책임자가 지고,
개발에 관계가 없는 사람은
개발과정에 참여하지 않는다.

그러니 그냥 코드를 보고,
토의하는 것 자체가
“회의” 이면서 “기술전수” 이면서,
“제품제작과정” 이면서, “의사결정과정”이다.

"코드리뷰" 자체가 회사의 "가치생산활동"이다.

 

5.

 

소설가 지망생이 있다.
레전드 소설가 OOO 님을 찾아갔다.

“선생님, 제가 글 쓴 걸 한 번 봐주세요.”

Level 1 : 

   음… 여기선 문장이 이렇게 끝나면 안되고.
   문법이 이렇게 틀렸구.  
   이쪽엔 마침표가 아니라 쉼표를 찍어야 해.

Level 2 : 

   음… 문단을 이렇게 자르면 읽는 사람이 어려워해.
   문체가 좀 더 쉬웠으면 좋겠어.

Level 3 : 

   음. 기승전결이 조금 이상한데?
   “기” 부분이 너무 길어서 소설이 늘어지는 느낌이야.
   조금 짧게 줄여보는 게 어떨까?

Level 4 : 

   음… 갈등구조가 약해. 새로운 인물이 있음 좋겠어.
   누구랑 누구가 사귀다가 헤어지고,
   새로운 누군가를 등장시키는 게 어떨까?
   그럼 스토리가 좀 더 다양해지고 재미있을 것 같어.

 

코드를 놓고 할 수 있는 이야기는 다양하다.
코드 컨벤션부터, 어플리케이션 구조, 처리속도, CPU사용율,
에러처리, 메모리 이야기, 부하분산 이야기 등등

회원가입 프로세스나 결제 프로세스 등등.
비지니스 흐름까지 관여하고 결정할 수 있다. 

코드를 놓고 일이야기를 하는 것.
그 모든 행위가 코드리뷰다.

6.

6-1.

옛날엔 SI (System Integration)할 때도 코드리뷰는 했다.
뭘 잘 모를 땐 아는 사람한테 가서 물었다.

 

나 : “이게 왜 안돌까요?”
그 : “아… 이렇게 짜면 안되고, 이렇게 해야 해요.
    제가 짠 걸 보여드릴테니까 참고하세요.”
나 : "감사합니다."

어느 때인가부터 코드를 안보여주기 시작했다.
뭔가 "월권", "참견"이라고 생각했다.

 

6-2.
"서비스 개발운영"을 하게 되었다.
코드보기는 필수였다.

소스코드는 하나인데, 여러 사람이 함께 고쳐야했다.

개발과 운영을 함께 해야 하니,  
서로 백업하는 건 필수였다.

 

기능을 1-2-3-4 로 개발했는데,

4-2-1-3으로 배포해야 하는 게 일상이었다.

그나마도 순서가 매번 바뀌었다.

버전관리, 배포관리도 일이었다.

맨날 예상치 못한 곳에서 장애가 나니까,
배포 전에 내 코드를 검사받는 일은 아주 당연했다.

오히려 절실했다.

"내 코드 좀 봐주라~"
ZIP 파일로 압축하면 1 MB 도 안되는 그 소스 파일 하나에
하루 2천만원의 매출이 발생되었기 때문이다.

 

6-3.
다시 SI 로 돌아왔다.

소스파일을 일일이 다 살펴보았다.

흠...

깊숙이 관여하진 않았지만, 
사고가 나지 않게 미리미리 대처했다.

개발자는 사실 나쁜 사람이 아니다.
시간만 있다면 말이다.
어려운 로직을 하루만에 만들려니까
코드가 개판이 되는거다.

 

요즘 SI는 코드리뷰까진 안해도

코드검수 정도는 하기도 한다.

물론 그것도 안할 때가 있다.

문서로 퉁치는거다.

 

6-4.
“스타트업”으로 넘어왔다. 
소스파일 보기는 일상화되었다.
만들기 전에 어떻게 만들지 미리 의논한다.
만들다가 어려운게 있으면
화이트보드 앞에 붙어서 이런저런 그림을 그려댄다.

나 : “우리, 꼭 그렇게 해야해?”
그 : “음… 그렇네. 그럼 이렇게 만들어볼까?”

서로 나누는 이야기가 그대로 코드에 들어가고,
어떻게 테스트할지까지 의논도 한다.

코드리뷰는 일하는 문화다.
시작은 동료에 대한 “믿음”이다.

 

7.

7-1. 
산업혁명 이후 돈을 버는 핵심은

동일한 품질을 대량생산하는 거였다. 
품질유지는 단연코 “설비”가 중심이다.

사람은 그냥 설비를 뒷받침 하는 존재다.
실수할 수 있기 때문에, “불신”을 기본으로 업무방식을 설계한다.

모든 걸 계획하고 규정을 만들어 프로세스 방식으로 처리한다.

"이탈"은 곧 "품질"의 하락이기 때문이다.

 

그런데 이건 만들기만 하면 팔리는 제품에나 어울리는 방식이다.

효과성이 아니라 생산성, 효율성이 중요한 사업에 통하는 방식이다.

 

7-2.

“인터넷 서비스”는 그렇지 않다.

만들어도 팔리지 않는다.

보이지 않으니까 있는 줄도 모른다.

이름없이 사라지는 제품이 세상에 수백만개나 된다.

뜨는 제품 하나가 중요하다.

그게 회사를 먹여살린다.
생산성과 효율이 아니라, 효과성이 중요해진거다.
대량판매는 “Copy”와 “Download”로 이루어진다.

굳이 1조원짜리 생산설비를 갖출 필요가 없다.

 

7-3.
“실험”과 “구현”을 빠르게 반복할 수 있게 조직이 바뀐다.

비싼 사람을 사서 비싼 결과를 만들게 한다.

아니면 1+1 > 2,

시너지를 만들기 위해

"일하는 방법"을 고민한다.

“전문경험”이 빠르게 활용될 수 있도록,
“믿음”을 기본으로 커뮤니케이션 비용을 줄인다.

그게 “코드리뷰”다.

100장짜리 문서로 내 계획이 틀리지 않았음을 증명한 후

개발팀에게 넘기는 절차를 만드는 게 아니라,

그냥 가서 이야기하고 좋은 결과를 만들기 위해 협력하는거다.

지난주 배포한 기능의 반응이 좋지 않으면

그냥 이번주에 고치는 거다.

 

코드리뷰 문화는 회사가 어떻게 운영되는지

확인할 수 있는 나침반과도 같다.

 

8.

학생 : “어, OOO 님은 그렇게 이야기 안하시던데요.”

흠…
코드리뷰는 대답을 택일하는 게 아니다.

요즘 서버쪽 언어는 휴먼화되면서,

코드자체는 쉬워지고 있다. 
파이썬이나 node 가 그렇다.

"Low Code" 열풍도 불고 있다.

심지어 요즘은 "Serverless"란다.

 

코드를 특별히 잘못 짤 이유가 없다.

그래서 "디자인 패턴" 등을 많이 본다.

 

물론 빡세게 볼 때도 있다.

초당 트랜잭션 처리 능력이 높아야 하는 경우는

"와 저런것까지 본다구?" 하는 부분까지 본다.

파라미터 하나 넘기는 것까지 본다.

 

단말 쪽은 다르다.

나중에 업데이트할 수 없는 코드라면,

아무리 작은 코드라도 보고 또 본다.

팔려서 고객 손에 들어가고 나면

영원히 손댈 수 없기 때문이다.

수십번 보고,

여러 사람이 보고,

증명된 코드를 재활용한다.

 

코드리뷰는 
안드로이드와 서버가 다르다. 
금융업체와 네이버가 다르고, 
프론트엔드와 백엔드가 다르다. 

즉, 코드리뷰는 회사마다 다르다.

일하는 방식이기 때문이다.

“흠, 그럼 미리 배울 수 있는 건 아무것도 없는건가?”
학생들 입장에선 헷갈릴 수 있다.
그냥 카카오 스타일을 하나 배워서 따라해보자.
몇개 따라서 해보면 금방 감이 올거다.
다만 정답이 하나인 것처럼 외우진 않으면 좋겠다.

세상에는 정답이 없구,
정답을 찾아가는 과정만 있다.

 

9.

코드커뮤니케이션.
이거 하려면 팀이 있어야 한다.
최소한 3명은 모여야 한다.

Extreme Programming,
Pair Programming
이런 것도 한번씩 해보자.

 

코드커뮤니케이션은

여러 개발자가 일을 할 때
커뮤니케이션 손실을 줄여주고,

업무의 정확성을 높여주고,
제품제작기간을 줄여주고,
새로운 효과성을 만들어내기 위한

기초기술에 해당된다. 

 

이런 기초기술을 마음껏 사용하려면

그렇게 일하는 문화가 자리잡아야 한다.
이렇게 바꾸는 걸
기업문화를 바꾼다고 표현한다.

10.

 

요리교실도 소프트웨어랑 비슷하다.

 

"코드리뷰"하면 뭐가 좋아지나?

 

요리를 생각해보자.

맛있는 음식도 먹어본 사람이 만든다.

이론으로 들어도 모른다.

음식은 머리가 아니라 입으로 느끼는 것이기 때문이다.

 

코드도 마찬가지다.

백날 들어봐야 모른다.

남이 만든 좋은 코드를 보고,

혼자 토닥거려봐야 좋은 코드를 만든다.

 

다양한 코드를 많이 볼수록

다양한 프로그램을 많이 만들어볼수록

다양한 개발자와 함께 일을 할수록

다양한 장애케이스를 겪을수록

다양한 문제를 돌파할수록

개발스킬은 

늘어난다.

 

후배가 그래야

선배의 손도 가벼워진다.

 

끝.