저희는 툴을 사용해서 코드리뷰를 진행중입니다. 하지만 툴을 사용하는 것도 역시 한계가 있는것 같습니다. 지역적으로 떨어져있지 않다면 얼굴을 맞대고 하는것이 좋은것 같습니다.

좋은 글 잘 읽었습니다. code review에 관한 일반 방법론이 있다면 혹은 관련 자료가 있으시면 추천해주시면 감사하겠습니다. 막상 시작하려니 위에서 말씀하신 부작용들도 걱정이 되고 실행방법도 좀 막막합니다.

말씀하신대로 코드와 자아를 동일시하는 그러니깐 코드에 대한 비판을 자기 자신에 대한 비판으로 받아들이는 자아적 프로그래밍(ego programming) 문화가 강해서 코드 리뷰도 오히려 어려워진 것 같습니다.

[_ 모든 개발자들이 코드리뷰를 당연 시 하기 전까지는 언제든지 실패할 가능성이 있습니다. _]
- 이 말씀이 정말 와닿습니다. 당연 시 되기 전까지 부단히 노력해야겠군요.

작은 SW 개발 업체를 운영하고 있는데..
코드 리뷰 없이 양산 장비에 설치된 프로그램이 심각한 문제점들을 드러내고 있습니다.
물론..문제들이 자꾸 발생하는데 해결을 잘 못하니까
처음부터 그런 코드를 작성한 개발자가 원망 스럽기도 하지만..
코드 리뷰 시스템을 안 갖춰놓은 회사의 책임도 분명히 있다고 생각합니다.

어찌 됐든 다시 코드 리뷰를 시작해봐야 할 것 같습니다.
지금까지 여러차례 시도 해 봤지만..
처음 몇번만 제대로 하다가 결국 흐지부지 되고 말았지요
개발 일정 압박도 심한데..
코드 리뷰를 하자고 하면 다들 잘 따라와 줄런지 걱정부터 되는군요
그래도 이번에는 대형 LCD TV를 스탠드와 함께 구매하여
프로젝터로 소스를 보는것 보다..훨씬 선명하게 소스를 함께 볼 수 있는 환경이 되었으니
다시 한번 추진해야죠

코드 리뷰 정착이 정말 어려운 이유는 그게 아닙니다. 개발자들의 심리적인 장벽이야 (코드 리뷰 원칙을 준수하면서) 적당한 시간 동안에 익숙해지기만 하면 그만이죠.

진짜 문제는... 윗선의 의지부족과 몰이해입니다. 코드 리뷰나 pair programming, test driven 이나, 본질은 지금 당장 시간이 들더라도 품질을 끌어올려서 나중에 디버깅이나 심지어는 재설계 등의 재앙에 들어가는 오버헤드 시간을 줄이겠다는 겁니다. 그런데 문제는 '지금 당장 시간이 들더라도' 는 눈에 보이는 명확한 것이지만, 개선 효과란 것은 코드 리뷰가 정말 제대로 정착되지 않으면 잘 드러나지 않는 것이거든요.

심지어는 고리타분한 경영진들은 코드 리뷰 잘해서 버그를 미리 없애서 잘 끝나면 '쉬운거 했네', 코드를 엉터리로 빨리 짜서 계속 디버깅 하느라 밤새면 '어려운거 열심히 하는군' 이라고 생각해 버립니다. 코드 리뷰도 결국은 디버깅 시간을 줄여서 이득을 보기 위함인데, 사고방식 자체가 오래 앉아 있는게 일 잘하는거라면 코드 리뷰와는 빠이빠이 해야죠.

참고로 전전 회사에서 코드 리뷰를 도입했습니다.(중소기업이 몇년 전에 코드리뷰를 도입했다는 것은 놀랍죠. 대기업도 아직 안하는데) 그런데 더 놀라웠다는 것은 팀장이 이렇게 얘기했습니다. "코드 리뷰 도입하면 그만큼 버그 처리 개수가 줄어들거고, 회사에서는 그거 감수하고 도입하는 겁니다. 그러니 코드 리뷰 시간 때문에 버그 처리 개수 줄어든다고 걱정하지말고, 이왕에 하는 거니까 제대로 코드 리뷰 합시다."

코드 리뷰의 장기적인 효과를 기대하지 않고 단기적인 성과만 바라고, 코드 리뷰가 정착될 때까지의 slow-down 은 전혀 감수할 생각이 없고 그냥 덤으로 코드 리뷰가 잘되길 바라는 회사에서의 코드 리뷰는 100% 실패할 수 밖에 없습니다. 그런 상황에서는 코드 리뷰 원칙도 제대로 지켜지기 힘들테니까요.