안녕하세요. 김수보 멘토입니다.
면담을 하다보니 “코드리뷰”에 대해 막연한 카뎃분들이 많더군요.
고민을 하다 제 블로그에 올렸던 내용을 다듬어서 올려봅니다.
※ 출처 : https://greypencil.tistory.com/141
이 글은 “코드리뷰”가 무엇인지 처음 들어보는 “학생”들을 위한 글입니다.
또는 그런 걸 전혀 모르는 CEO분을 위한 글입니다.
코드리뷰…
코드 살펴보기?
단순히 그렇게만 생각하지 말고,
조금 더 세련되게 이해해보기로 합니다.
1. 어느날 회사에서
그 : “코드리뷰 해야 한대.”
나 : “???”
그 :“그걸 해야 한대.”
나 :“???”
갑자기 코드리뷰 회의가 잡혔습니다.
회의실에서 빔프로젝트를 쏘면서
모든 개발팀이 모여서 회의를 합니다.
괜히 누군가 한마디 던집니다.
A : “저거 저렇게 하면 안되고 ….”
B : “아, 저건 이런저런 이유로 저렇게 만든거구…”
A : “그래도 저건 저렇게 하면 안되구…”
B : “…”
암튼 그랬습니다.
그렇게 “코드리뷰”란 걸 처음으로 접했습니다.
이런 왜하지?
이해할 수 없었습니다.
하지만 월급주는 경영진이 시킨 일이니까.
뭐 돈 드는 것도 아니니까.
일단은 해보기로 했습니다.
물론 지금은 그렇게 하지 않습니다.
사실 “코드리뷰”란 거.
옛날부터 이미 하고 있었습니다.
코드 잘못하면 망하는 팀들은
이미 옛날부터 하고 있었습니다.
“문화”라기 보다 “생존”이니까요.
2. 환타지
학 : “코드리뷰 좀 해주세요.”
나 : “음… 볼까? … 이건 이렇게 하는게 더 좋을것 같은데…?”
학 : “우와~ 그렇게 보면 척하고 알아요?”
나 : “…”
학생들이 하는 소리입니다.
흠. 코드리뷰.
학생들은 뭔가 환타지가 있구나.
처음 알게 됩니다.
3. 왜 하는지 아는 사람?
코드리뷰 하는 법
코드리뷰 체크리스트
코드검토
…
검색을 해봅니다.
음, 안 나오네요.
코드리뷰를 왜 하게 되었는지.
그러니, “회의식 코드리뷰”를 하지.
사장님이 시켜서,
질문 하나도 없이 말이죠.
하아, 할 말이 없습니다.
“카카오스토리팀의 코드리뷰 도입사례”
정말 훌륭한 글입니다.
정말 훌륭한 글입니다.
하지만….
글 쓴 사람은 잘못이 없습니다.
듣는 사람이 문제죠.
초보자는 어떤 고민의 결과로 이걸 이해하지 않고,
이런 행위 자체를 “코드리뷰”로 외워버립니다.
똑같이 따라하기를 하고는 “코드리뷰”를 했다고 안심합니다.
회사 전무님도 그게 코드리뷰인 줄 압니다.
하아…
“꼭 코드리뷰할 것”
최악은 프로세스로 정해놓는 것입니다.
개발팀 의견도 물어보지 않고 !!!
하아…
정말 회사가 망할 수 있습니다.
이런걸 프로세스로 정한다는 것 자체가
회사 임원진이 “소프트웨어 제품의 생산과정”에
무관심하다는 뜻입니다.
당사자의 일이 아니니
잘 알지 못할 순 있습니다.
하지만 “무관심”한 건 안됩니다.
현대자동차 CEO가 엔진을 만들진 않지만,
적어도 그 과정과 제작기간, 비용 등에 대해선
자세하게 알고 있습니다.
코드리뷰가 “장애시간”을 줄여준다든지,
에러 재현현상을 줄여준다든지,
새로운 기능의 배포시간을 줄여준다든지
등등의 변화(중장기 포함)를 만들어내지 못한다면,
그냥 자기만족에 불과할 뿐입니다.
4. 문서소통, 코드소통
우리나라 IT산업은 빅3라고 이야기하는 대기업의 SI에 의해 성장했습니다.
함수가 1,000개가 넘으니까 정말 건설처럼 만듭니다.
철저한 분업이라 설계와 개발이 나뉘어집니다.
그래서 별도의 소통관리기법을 사용합니다.
바로 “문서 소통”이죠.
그래서 문서로 일하는 게 발달했습니다.
하지만, 스타트업은 다릅니다.
그 사람이 개발하고, 그 사람이 운영하고, 그 사람이 책임자입니다.
“(문서)그런거 만들지 말고 (프로그램)만들걸 보여주세요.”
대기업에 있다가 스타트업으로 이직했을 때
사장님에게 제일 처음 들었던 소리입니다.
스타트업에선 함께 일하는 팀원들이 다 개발자입니다.
사장님께는 말로 설명하면 됩니다.
문서를 만들 이유가 없죠.
개발자들끼리라면 간단히 손으로 그리고,
만들어 놓은 코드를 보면서 대화하면 됩니다.
보지도 않는 100장짜리 분석설계 문서를 만들 이유가 없죠.
누군가를 설득시킬 필요가 없으니까요.
책임은 책임자가 지고,
개발에 관계가 없는 사람은
개발과정에 참여하지 않습니다.
그러니 그냥 코드를 보고,
토의하는 것 자체가
“회의” 이면서 “기술전수” 이면서,
“제품제작과정” 이면서, “의사결정과정”입니다.
즉, “코드리뷰” 자체가 그 회사의 “가치생산활동”이죠.
5. 소설 리뷰, 코드 리뷰
소설가 지망생이 있습니다.
레전드 소설가 “아무개”님을 찾아갑니다.
“선생님, 제가 글 쓴 걸 한 번 봐주세요.”
Level 1 : 문법 지적단계
음… 여기선 문장이 이렇게 끝나면 안되고.
문법이 이렇게 틀렸구.
이쪽엔 마침표가 아니라 쉼표를 찍어야 해.
Level 2 : 문체 지적단계
음… 문단을 이렇게 자르면 읽는 사람이 어려워해.
문체가 좀 더 쉬웠으면 좋겠어.
Level 3 : 구조 지적단계
음. 기승전결이 조금 이상한데?
“기” 부분이 너무 길어서 소설이 늘어지는 느낌이야.
조금 짧게 줄여보는 게 어떨까?
Level 4 : 플롯 지적단계
음… 갈등구조가 약해. 새로운 인물이 있음 좋겠어.
누구랑 누구가 사귀다가 헤어지고,
새로운 누군가를 등장시키는 게 어떨까?
그럼 스토리가 좀 더 다양해지고 재미있을 것 같어.
코드를 놓고 할 수 있는 이야기는 다양합니다.
코드 컨벤션부터, 어플리케이션 구조, 처리속도, CPU사용율,
에러처리, 메모리 이야기, 부하분산 이야기 등등
회원가입 프로세스나 결제 프로세스 등등.
등등등
등등등
등등등
비지니스 흐름까지 관여하고 결정할 수 있습니다.
코드를 놓고 일이야기를 하는 것.
그 모든 행위가 “코드리뷰”입니다.
6. 어떻게 변해왔을까?
6-1. 옛날 SI
옛날엔 SI (System Integration)할 때도 코드리뷰는 했습니다.
무언가를 잘 모를 땐 아는 사람한테 가서 물었습니다.
나 : “이게 왜 안돌까요?”
그 : “아… 이렇게 짜면 안되고, 이렇게 해야 해요.
제가 짠 걸 보여드릴테니까 참고하세요.”
나 : “감사합니다.”
그런데 어느 때인가부터 코드를 안보여주기 시작했습니다.
뭔가 “월권”, “참견”이라고 생각했죠.
분업화가 자리잡히면서 그랬던 것 같습니다.
6-2. 운영개발(DevOps)을 할 때
“서비스 개발운영”을 하게 되었습니다.
코드보기는 필수였습니다.
소스코드는 하나인데, 여러 사람이 함께 고쳐야했거든요.
개발과 운영을 함께 해야 하니,
서로 백업하는 건 필수였습니다.
기능개발은 1-2-3-4 로 했는데,
4-2-1-3으로 배포해야 하는 게 일상이었습니다.
그나마도 순서가 매번 바뀌었죠.
버전관리, 배포관리만도 버거운 일이었습니다.
맨날 예상치 못한 곳에서 장애가 나니까,
배포 전에 내 코드를 검사받는 일이 아주 당연했습니다.
“내 코드 좀 봐주라~”
오히려 절실했죠.
압축하면 1 MB 도 안되는 그 소스 파일 하나에
하루 2천만원의 매출이 발생했거든요.
6-3. 요즘 SI
다시 SI 로 돌아왔습니다.
프로젝트 팀원들이 개발하는
소스파일을 일일이 다 살펴보았습니다.
흠…
깊숙이 관여하진 않았지만,
사고가 나지 않게 미리미리 대처했습니다.
아무도 모르게 말이죠.
개발자는 사실 나쁜 사람이 아닙니다.
시간만 있다면 말이죠.
어려운 로직을 하루만에 만들려니까
코드가 개판이 되는겁니다.
그런데 코드를 볼 줄 모르면, 그걸 판단하거나 관리할 수 없습니다.
요즘 SI 세계는 코드리뷰까진 안해도
코드검수 정도는 합니다.
물론 그것도 안할 때가 있습니다.
문서로 퉁치죠.
운 나쁘면 장애가 빵빵 터집니다.
시스템과 개발자가 웬수로 보이죠.
6-4. 스타트업
“스타트업”으로 넘어왔습니다.
소스파일 보기는 일상화되었죠.
만들기 전부터 어떻게 만들지 미리 의논합니다.
만들다가 어려운게 있으면
화이트보드 앞에 붙어 서서
이런저런 그림을 그려댑니다.
나 : “우리, 꼭 그렇게 해야해?”
그 : “음… 그렇네. 그럼 이렇게 만들어볼까?”
서로 나누는 이야기가
그대로 코드에 들어가고,
어떻게 테스트할지까지 의논도 합니다.
코드리뷰는 “일하는 문화”입니다.
시작은 동료에 대한 “믿음”부터죠.
7. 왜 코드가 중요할까?
7-1. 제조업 시대
산업혁명 이후 돈을 버는 핵심은
동일한 품질을 대량생산하는 거였습니다.
품질유지는 단연코 “설비”가 중심이죠.
사람은 그냥 설비를 뒷받침 하는 존재입니다.
실수할 수 있기 때문에,
“불신”을 기본으로 업무방식을 설계합니다.
모든 걸 계획하고 규정을 만들어
프로세스 방식으로 처리한다.
“이탈”은 곧 “품질”의 하락이거든요.
그런데 이건 “만들기만 하면 팔리는 제품”에나 어울리는 방식입니다.
안팔리면 망합니다. 다 적자거든요.
한달에 10만원짜리 10개 팔면서 “설비”이야기하면 사업망하는 겁니다.
즉, 효과성이 아니라 생산성, 효율성이 중요한 사업에나 통하는 방식입니다.
7-2. 인터넷 서비스 시대
“인터넷 서비스”는 그렇지 않습니다.
보통 만들어도 팔리지 않습니다.
보이지 않으니까 있는 줄도 모릅니다.
이름없이 사라지는 제품이 세상에 수백만개나 됩니다.
그래서 “뜨는 제품” 하나에 매달립니다.
그게 회사를 먹여살립니다.
생산성과 효율이 아니라, “효과성”이 중요해진거죠.
대량판매는 “Copy”와 “Download”로 이루어집니다.
굳이 1조원짜리 생산설비를 갖출 필요가 없어진거죠.
7-3. 생산조직의 변화
인터넷 사업으로 오면서
“실험”과 “구현”을 빠르게 반복할 수 있게 조직이 바뀝니다.
비싼 사람을 사서 비싼 결과를 만들게 합니다.
아니면 1+1 > 2,
시너지를 만들기 위해
“일하는 방법”을 고민합니다.
“전문경험”이 빠르게 활용될 수 있도록,
“믿음”을 기본으로 프로세스를 재설계합니다.
커뮤니케이션 비용을 줄이는거죠.
그게 “코드리뷰”입니다.
100장짜리 문서로 내 계획이 틀리지 않았음을 증명한 후
개발팀에게 넘기는 절차를 만드는 게 아니라,
그냥 가서 이야기하고 좋은 결과를 만들기 위해 협력하는겁니다.
지난주 배포한 기능의 반응이 좋지 않으면
그냥 이번주에 고치는 겁니다.
그래서 코드리뷰 문화는
회사가 어떻게 운영되는지
확인할 수 있는 나침반과도 같습니다.
스타트업이 누군가를 설득하기 위한 문서를 만들고 있으면
뭔가를 확실히 잘못하고 있는거죠.
8. 회사마다 다르다
학생 : “어, OOO 님은 그렇게 이야기 안하시던데요.”
흠…
코드리뷰는 뭔가 대답을 택일하는 게 아닙니다.
요즘 서버쪽 언어는 휴먼화되면서,
코드자체는 쉬워지고 있습니다.
파이썬이나 node 가 그렇죠.
빨리 배워서 만들라고 만든 언어입니다.
빨리 못배우면 “언어”가 잘못 만들어진거예요.
“Low Code” 열풍도 불고 있습니다.
Low Code 인데, 어려우면 이상한 거죠.
심지어 요즘은 “Serverless” 랍니다.
코드를 특별히 잘못 짤 이유가 없죠.
대충 짜도 돌아가도록 언어가 변했습니다.
대신 복잡하게 얽히니까 “디자인 패턴” 을 봅니다.
물론 빡세게 볼 때도 있습니다.
초당 트랜잭션 처리 능력이 높아야 하는 경우는
“와 저런것까지 본다구?” 하는 부분까지 봅니다.
파라미터 하나를 잘못 넘겼느니 합니다.
그런데, “단말” 쪽은 다릅니다.
나중에 업데이트할 수 없는 코드라면,
아무리 작은 코드라도 보고 또 봅니다.
팔려서 고객 손에 들어가고 나면
영원히 손댈 수 없거든요.
내보내기 전에
보고 또 보고,
수십번 또 보고,
여러 사람이 보고,
모르는 사람이 보고,
증명된 코드를 재활용합니다.
이렇게 코드리뷰는
단말과 서버가 다릅니다.
금융업체와 네이버가 다르고,
프론트엔드와 백엔드가 다르죠.
즉, 코드리뷰는 회사마다 다릅니다.
일하는 방식이 다르거든요.
“흠, 그럼 미리 배울 수 있는 건 아무것도 없는건가?”
학생들 입장에선 헷갈릴 수 있습니다.
음, 코딩은 이론이 아닙니다.
범용화된 지식이 필요한 게 아닙니다.
코딩은 훈련의 영역입니다.
그냥 카카오 스타일을 하나 따라해봅니다.
몇개 따라서 해보면 금방 감이 옵니다.
다만 정답이 하나인 것처럼 외우진 않으면 됩니다.
세상에는 정답이 없구,
정답을 찾아가는 과정만 있거든요.
9. 코드리뷰에서 코드커뮤니케이션으로
코드커뮤니케이션.
이거 하려면 팀이 있어야 합니다.
최소한 3명이 모여 있어야 하죠.
Extreme Programming,
Pair Programming
이런 것도 한번씩 해봅니다.
“코드커뮤니케이션”은
여러 개발자가 함께 일을 할 때
커뮤니케이션 손실을 줄여주고,
업무의 정확성을 높여주고,
제품제작기간을 줄여주고,
새로운 효과성을 만들어내기 위한
소프트웨어 개발자가 습득해야 할
기초기술에 해당됩니다.
이런 기초기술을 마음껏 사용하려면
그렇게 일하는 문화가 있어야 합니다.
이렇게 바꾸는 걸
기업문화를 바꾼다고 표현합니다.
10. 코드리뷰, 뭐가 좋아지나
“코드리뷰하면 뭐가 좋아지나?”
요리교실에 비유해봅니다.
“선생님, 제 음식 이거 맛좀 봐주세요.”
맛있는 음식도 먹어본 사람이 만듭니다.
이론으로 들어도 모릅니다.
음식은 머리가 아니라 입으로 느끼는 거잖아요.
코드도 마찬가지입니다.
백날 들어봐야 모릅니다.
남이 만든 좋은 코드를 보고,
선배들한테 물어보고,
친구들한테 배워서 따라해보고
혼자 토닥거려봐야 좋은 코드를 만듭니다.
다양한 코드를 많이 볼수록
다양한 프로그램을 많이 만들어볼수록
다양한 개발자와 함께 일을 할수록
다양한 장애케이스를 겪을수록
다양한 문제를 돌파할수록
개발스킬은 늘어납니다.
후배가 그래야 선배의 손도 가벼워집니다.
요약
재미난 걸 많이 만들고,
친구들과 코드를 놓고
기술구조나 데이터에 대해 이야기를 나누어 보세요.
그리고, 멘토에게도 코드를 보여주세요.
그게 실력이 성장하는 지점입니다.
끝.