from __future__ import dream

얼마전에 작년 4/4분기에 만든 코드를 리뷰 받느라 거의 3주의 시간을 쏟느라 고생을 좀 했는데, 이와 관련해서 정리를 해보고자 한다.
내일 물론 이 코드리뷰 과정에 대해서 팀 미팅 시간에 이야기를 할 기회가 있을거 같기도 하고 그렇다.

먼저 내 코드를 리뷰한다고 한다면 가장 먼저 드는 생각이, 뭔가 발가벋겨 진다는 생각일 것이다.. 아무리 코드를 잘 짠다고 하더라도 리뷰(검사)를 받는다는 것 자체가 그리 기분좋은 일은 아니다.
그렇지만 좀 쪽팔리더라도 정말 이 과정에서 배울게 너무도 많다는 것은 부정할 수 없다. .

내가 몸 담고 프로젝트의 코드 생산은 아래의 과정을 통하게 된다. .

1. 논문, 그리고 알고리즘을 리서치하고 이에 따른 다양한 시도를 한다.  그리고 이들을 평가하기 위한 퍼포먼스 테스트와 이들 결과가 좋다면 이들을 일주일에 한번정도 공유하는 자리를 가지게 된다.
2. 공유하는 자리에서 팀원들의 의견을 가미해 가면서 점점 퍼포먼스를 올리게 된다.
3. 이런 과정에서 꽤 좋은 퍼포먼스를 얻었다는 판단이 들면, 이를 코드 커밋을 하게 되는데, 이 전에 코드의 대부분의 핵심 알고리즘과 유닛테스트 코드가 이미 완성이 되어 있어야 한다. 나의 경우에는 거의 누더기 같은 코드로 결과만을 보기 위해 작성했다가 추후 고치는데 시간이 더 걸린 경험도 해봤다.  아마 능숙한 사람은 이미 이 단계에서 완성도 높은 코드를 가지고 있을 것이다.
4. 누구한테는 공포의 코드리뷰가 되는 단계다.
5. 그리고 영광의 코드 커밋..


대충 이런 개발단계를 거치게 되는데, 개인적으로 혹독한 코드리뷰를 통해 상당히 코드의 품질을 올릴 수 있었다고 나 자신이 느끼고 있다. 게다가, 다른 사람들의 조언을 듣게되면서 여러 코딩팁이나 핵심 노하우 등을 얻을 수 있었다.
조심성 있는 우리 팀분들은, 코드의 의미가 간단 명료하기를 원한다. 그리고 변수명에 이들의 역할과 의미가 함축되어 표현되기를 바라고 있다. 게다가 쓸데없는 코드를 더더욱이 싫어하며, 제일 싫어하는건 코드에 버그를 야기할 가능성이 있을 때 이다.
뭐 이정도를 지적받았다. ㅜㅜ

"C++ 코딩의 정석"에 나온 코드리뷰의 잇점을 좀더 써보자면....

1. 여러 동료들의 조언을 통해 코드의 질을 높일 수 있다.
2. 버그를 찾아내고, 적절하지 않은 부분이나 호환/확장성 문제를 찾아낼 수 있다.
3. 아이디어를 공유하는 과정에서 보다 나은 디자인을 찾아낼 수 있다.
4. 새로운 팀 동료나 아직 코드에 익숙하지 않은 사람은 보다 빨리 팀의 업무에 익숙해질 수 있다.
5. 팀의 커뮤니티에 도움을 주며, 일관된 목표를 향해 나아갈 수 있게끔 해준다.
6. 서로에 대한 신뢰, 동기 부여, 전문성 확보에 도움이 된다.

나의 입장에서 가장 공감이 가는 부분은 4번이다. 이처럼 대규모의 C++ 프로젝트를 처음 해보는 나로서는 이 코드리뷰를 통해서 무엇보다 소중하고 책에서 결코 얻을 수 없는 노하우를 얻고 있다. 그것도 C++ 베테랑들로부터 말이다.

어쩌면 이 코드리뷰 전 과정이 팀의 상향 평준화를 이루는 첨병역할을 하지 않나 싶다.

흥미로운 사실은, 코드리뷰를 받는 나에게만 이 시간 할당을 해주는게 아니라, 리뷰를 해주는 리뷰어들에게 까지 리뷰에 대한 시간 할당을 해준다는 사실이였다. 리뷰는 시간 날때 해주는것이 아닌, 프로젝트의 한과정으로 여기는 이런 개발문화를 배워야 할거란 생각이 든다. 이런 문화에서의 코드 한줄 한줄이 에플리케이션의 완성도와 안정성을 보장해 준다고 생각한다. 

요런 저런 개발 프로세스와 문화를 경험하다보니, 특정 개발 프로젝트를 바라보는 관점이 많이 변하게 되었다. 예전에는 그 프로젝트에 어떤 능력있는 사람이 있나 없나를 보고 에플리케이션의 미래를 첨쳤다고 한다면, 지금은 프로젝트의 개발 문화를 더 보게 되었다. 정말 잘 만들어진 에플리케이션은 특출난 몇명의 개발자들이 만드는게 아니라 아주 잘 다듬어진 개발문화를 갖춘 조직에서 나온다는 사실을 직접 몸소 경험하고 있는 중이다.

오늘 원래 회사 4시에 퇴근 할 수 있는 날인데, 지금 새로 작성된 코드들 디버깅과 실제 런타임 테스트를 하고 있다. 한 2시간 전까지만 해도 심각한 버그를 가지고 있어서 금방 프로세스가 assert문으로 죽어 버리곤 했는데, 원인을 발견해 고쳐서 현재 열심히 테스트 모델 빌드중에 있다.
아마도 이번 빌드 마지막 코드 체크인은 내일 아침 그러니까, 미국 시간으로 오후 늦게나 하게 될 듯 하다.




이번에 절절하게 느꼈는데, 방어적인 코딩 방식이 얼마나 버그를 막는데 도움을 주는지 피부로 실감할 수 있었다. 아무리 코딩을 잘 한다 하고 경력이 많아 실수를 안할거라 생각하지만, 결코 이 코딩의 세상에서는 완벽함을 부르짓어서는 절대 안된다는 겸손한 생각을 다시 한번 해본다.
리뷰동안 방어적인 코드를 주장하는 팀원분들 덕분에 프로그램도 쾌적하고 깔끔하게 돌아가는 느낌을 받고 있는 중이다.. 기분 탓인가? ㅋ


여튼 모델 빌드는 진행중이고... assert 지뢰가 터지면 바로 달려가 디버깅 하겠지만, 잘 돌아갈 듯 보인다. (수천개의 데이터를 돌려보고 잘 돌아간다면 코드 체크인 해도 무방하리라 생각한다. 역시 안정성 테스트는 예상되는 입력을 잘 샘플링해 되도록 많이 집어 넣고 테스트 하는게 최고다.)


다름이 아니라 요즘 새로 구입해서 읽는 R in a Nutshell 이야기를 이 틈에 하고자 한다. 사실 R을 잘 사용하기 위해서라기 보다. 내가 좋아하는 업무 성격들이 잘 반영된 언어라서 그런 욕구 추구 측면에서 틈틈히 공부하는 언어중에 하나이다. 작년에는 이 언어를 이용해서 논문 데이터 분석 알바를 한적이 있는데, 덕분에 이 언어를 공부하는 책값을 구하는데는 도움이 참 많이 되었다. (하지만 어떤분은 R은 교수님이 모른다고, SAS를 이용해 돌려달라고 하는 그런 요구도 있었다. 결국 결과는 같은데 말이다.)




책의 저자는 온라인에서 광고를 파는 더블클릭(구글이 몇년전에 인수한)의 개발팀장이였고, 관련 데이터를 분석하기 위해 이 언어를 상당히 심도깊게 사용한 듯 하다. (뭐 내용을 보면 금방 알 수 있다)

이 책은 R을 아주 기초부터, 머신러닝의 영역인 분류나, 회귀분석까지 다루고 있고, 무엇보다 책이 가독성이 좋아 흡사 국내서를 보는 듯한 착각이 일 정도이다. 읽어보면 알겠지만 거의 중학교 수준의 영어면 이해하는데 큰 문제가 없을 정도이다.
무엇보다 맘에 드는건 틈틈히 등장하는 사용팁들인데, 이 팁들이나 기교가 언어를 이해하는데 많은 도움이 되더라..

아마도 이 포스팅을 읽으시는 분들이 head first statistics나 statistics in a nutshell을 아주 재밋게 봤고, 충분히 숙지를 했다면, 그 활용을 위해 이 R언어를 배워봄직도 할거라 생각한다.

책의 뒷부분에 상당히 재미난 예제들이 많이 나온다는 저자의 이야기가 있는데, 빨리 읽어보며 즐거움을 만끽해야 겠다.