코드리뷰 장점을 언급했던 저번 글에 이어서, 코드 리뷰를 할 때 마음가짐은 어떠해야 하는 지 얘기해보려고 한다. 코드리뷰의 가장 큰 걸림돌 2개는 Programming Ego 와 코드리뷰를 하기 위한 준비 과정이다. 이 중에서도 Programmer's Ego 에 대해서 먼저 얘기를 해보자면...

프로그래머는 자신이 만든 코드를 자기 자신과 동일시하는 경향이 있는데, 이는 화가나 작가들도 마찬가지다. 스스로의 자아를 결과물에 투영하는 것인데, 이것 자체는 자연스러운 현상이다. 예를 들어 전시회를 열고 있는 예술가 에게 다가가서 당신의 그림은 이런 부분들이 잘못되었으니 개선이 필요하다고 얘기한다 해보자. 화가 머리 끝까지 난 예술가가 뺨을 거칠게 철썩하고 내려치지 않았으면 다행이다. 자신의 예술 혼을 불어넣은 작품은 곧 예술가 그 자신이기 때문에 그런 것인데, 비슷한 일들이 프로그래머에게도 자주 일어난다. 자신이 정성껏 만든 코드를 누군가가 와서 문제점을 지적해대면, 스스로의 방어기제를 작동시키게 되어 적극적인 방어에 나서게 된다.

그러나, 프로그래밍의 경우는 예술과 약간 다른 면이 있다는 의견도 있다. ‘프로그래밍 심리학’ 에서 일부 인용을 해보면,

자신이 작성한 프로그램을 자신의 것으로 여기는 데 무슨 문제가 있는가? 화가는 그림을 자신의 것으로 여긴다. 작가는 책을 자신의 것으로 여긴다. 건축가는 건축물을 자신의 것으로 여긴다. 그렇게 귀속시킴으로써 훌륭한 프로그래머, 화가, 작가, 건축가는 사람들에게서 존경을 받고 실력이 조금 떨어지는 사람들은 그 훌륭한 작품을 모방해 발전하지 않는가? …

그러나 사람들이 프로그램을 읽지 않음을 우리는 이미 알고 있다. 따라서 어떤 프로그래머를 흠모한다고 해서 그 프로그래머의 작품을 모방하게 되지 않는다. 단지 매너리즘을 부추길 뿐이다. …

우리가 어떤 그림이나 소설, 건물이 열등하다는 생각은 취향의 문제다. 그러나 어떤 프로그램이 열등하다는 생각은 적어도 잠재적으로 객관적인 증명 또는 반증이 가능하다. 최소한 우리는 프로그램을 컴퓨터에서 실행해 나오는 결과를 볼 수 있다. 화가는 경우에 따라 비판을 수용하지 않을 수도 있다. 그러나 프로그래머가 컴퓨터의 판단을 무시할 수 있을까?

119p, 4장 프로그래밍 그룹, 프로그래밍 심리학

요약하자면, 프로그래밍은 예술과 다르게 객관적인 자료에 의해 그 결함이 입증 가능하고, 그 결함은 취향의 문제가 아니라 모두가 동의 가능한 문제이다라는 것이다. 이런 측면에서 프로그래밍은 소설이나 그림 같은 예술의 그것보다는 신문기사같은 것들과 유사성이 있다고 할 수 있겠다. 편집자와 동료들의 기사 리뷰를 받는 기자를 생각해보라. 결국 프로그래머는 자신이 작성한 코드에서 스스로의 자아를 분리하는 일을 해야만 하고, 또 그럴 수 있어야 한다.

일찍이 제랄드 와인버그는 Egoless Programming 이라는 걸 소개하며 자아를 주입하지 않고 코딩을 하자는 걸 이야기했었는데, 코딩호러에서 Egoless Programming 10계명으로 요약해놓은 걸 보면 다음과 같다.

1. 당신이 실수할 것이라는 것을 이해하고 받아들여라. 진짜 중요한 것은 그 실수가 제품화 되기 전에 일찍 찾아내는 것이다. 운좋게도 JPL 에서 로켓유도 소프트웨어를 만드는 몇몇을 제외하면, 이런 실수가 치명적인 경우는 잘 없다. 그러니 우리는 배우고, 웃으며 털어버리고, 앞으로 나아갈 수 있다. 아니, 그렇게 해야 한다.
2. 당신과 당신의 코드를 동일시하지 말라. 리뷰의 핵심은 문제점들을 찾는 것이라는 것이라는 걸 잊지 마라. 문제들이 발견되는 건 당연하니, 그 중하나가 지금 찾아졌다고 해도 그것은 개인적인 공격으로 받아들여서는 안된다.
3. 당신이 얼마나 많은 무공을 알고 있든지 간에, 누군가는 더 많은 것을 알고 있다. 그런 사람들은 만약 당신이 부탁한다면 새로운 무공을 가르쳐 줄 것이다. 그것들이 필요 없다고 느껴지는 때일 수록, 다른 사람들부터 피드백을 찾고 또 받아들여라.
4. 협의없이 코드를 다시 만들지 말라. 코드를 고치는 것과 코드를 다시 만드는 것에는 미세한 차이가 있다. 그 차이를 알고, 코드리뷰의 과정에서 스타일을 지켜가는 체인지를 만들도록 노력해야한다. 독불장군은 곤란하다.
5. 자신보다 많이 알지 못하는 사람이라 해도 존경과 인내로 대하라. 개발자를 상대하는 일반의 non technical 한 사람들은 개발자들이 잘되면 프리마돈나이지만, 최악의 경우엔 떼쟁이 아기라는 의견을 가지고 있다. 분노와 조급함으로 인해 이런 편견이 굳어지도록 하지 말자.
6. 이 세상에 존재하는 유일한 고정 값은 ‘변화’ 그 자체이다. 열린 마음으로 미소를 지으며 변화를 받아들이자. 요구사항, 플랫폼, 새로운 도구들은 싸워 없애야하는 불편함이 아니라 새로운 도전으로 바라보자.
7. 지위가 아니라 지식이야 말로 권위를 만드는 유일한 근거이다. 지식은 권위를 낳고, 권위는 존경을 낳는다. Egoless 한 방법에 대한 존중을 받고자 한다면, 지식을 쌓아가라.
8. 당신이 믿는 것을 위해 투쟁하라. 하지만 패배는 겸허히 받아들여라. 때때로 당신의 생각들이 기각될 수 있다는 걸 이해해라. 나중에 당신이 옳았다고 밝혀지더라도, 복수를 하려 하거나 '거 보시오 내가 뭐랬소' 라고 한 두번 이상 말하지 말아라. 아쉽겠지만 기각된 당신의 아이디어를 순교자처럼 취급하거나, 슬로건처럼 쓰는 일이 없도록 하라.
9. 방 안에 박혀 혼자 있는 사람이 되지 말라. 자기 방에서만 혼자 코딩하다가 콜라가 필요해 잠깐 나타나는 그런 사람이 되지 마라. 방 안에서 혼자 코딩하는 사람은 연락하기도 어렵고, 잘 보이지도 않고, 통제 불능이다. 열려있고, collaborative 한 환경이 아니다.
10. 사람보다 코드 그 자체를 비판하라. 코드가 아닌 코드를 작성한 사람에게 친절하라. 가능한한, 당신의 모든 리뷰 코멘트를 긍정적인 방향으로 코드 개선에 중점을 두고 이야기하라. 코멘트를 팀의 표준, 프로그램의 스펙, 나아진 성능등과 연결지어 얘기하라.

The Ten Commendments of Egoless Programming

핵심은 나 뿐만이 아니라 우리 누구도 완벽한 사람은 없다라는 전제를 받아들이는 것이다. 그 다음은 내가 하는 이 일은 팀 과업의 일부이다라는 공유 의식이다. 버그를 잡고, 코드를 구현하는 것은 팀을 한발짝 앞으로 전진시키기 위한 것임을 이해하고 나면 상황은 한결 쉬워진다.

그 다음 과제는 실전에서 어떻게 코드리뷰를 할 것인가? 무엇을 리뷰할 것인가의 문제이다. 그러기 위해서 코드리뷰를 위한 환경을 어떻게 구축해야 하는지 알아봐야 되고, 그 전에 코드리뷰의 형식에는 어떤 것들이 있는지 짚고 넘어갈 필요가 있다. 그 후에 코드리뷰의 세세한 팁들과 HowTo 에 대한 이야기를 할 수 있을 것 같다.

코드리뷰 관련된 책이나 글들을 찾아보면, 정형화된 프로세스를 이야기하는 경우는 매우 적다. 리뷰라는 행위 자체가 몹시도 인간적인 것이라 그 과정을 기계적으로 정의하기가 쉽지 않은 까닭이다. 어쩌면, 형식에 묶이는 순간, 본말전도가 되는 경우가 많아서 그럴 수도 있을 것 같다. 어쨋든 다음 글에서 조금 더 세세한 부분을 이야기해보고 싶다.