2009년 3월 24일 화요일

코드리뷰 정착이 어려운 이유

코드리뷰는 소프트웨어를 개발하는데 있어서 가장 좋은 문화중의 하나이지만 또한 가장 정착시키기 어려운 것 중의 하나입니다.
 
코드리뷰를 도입하거나 정착하기 어려운 이유는 다음과 같습니다. 
  • 공개적으로 망신을 당하거나 자신을 비판하는 것에 대한 두려움
  • 과거의 부정적인 코드리뷰에 대한 경험
  • 자신이 실력이나 약점이 드러나서 평가가 나빠질 것에 대한 두려움
  • 자신의 코드는 완벽하다는 밑도 끝도 없는 확신 및 자신에 대한 너그러움
  • 코드리뷰가 개발 일정을 지연시킨다는 생각
  • 코드리뷰보다는 테스트가 더 효율적이라는 믿음
  • 남을 비평하거나 비평 받는 것을 싫어하는 문화
 
실제로 준비 없이 코드 리뷰를 시행하면 위와 같은 모든 일이 일어나서 개발자들의 거부감을 불러 일으키게 됩니다.
 
주기적으로 시간을 정해놓고 끝장 코드리뷰를 하고 있는데, 시간이 지날수록 지루하고 졸리게 되고, 코드에 대한 사전 검토 없이 바로 코드리뷰에 들어와서 코드를 보니 코드가 눈에도 잘 안 들어 오고, 서로 코딩 스타일이나 모양에 대해서 지적을 하느라고 진도가 안 나갑니다.
코드리뷰에 들어온 개발자를 한번 왕창 깨놨더니 다들 코드리뷰를 하기 두려워 하고, 처음에는 의욕을 가지고 시작했으나 점점 "이거 왜 하나"라는 생각이 들어서 슬슬 피하게 됩니다.
개발하기도 바쁜데 리뷰할 시간이 어디 있나 생각이 들고, 바쁘게 코드를 작성하다 보니 남을 보여주기가 창피하기도 합니다. 또, 내 코드 다 오픈하면 내 힘이 줄어드는 것이 아닌가 하는 생각이 듭니다.
회사에서는 코드리뷰를 자꾸 하라고 하는데, 안해도 그만이고 내 시간만 갉아먹는 코드리뷰는 적당히 피하고 싶은 것이 일반적입니다.
 
코드리뷰를 정착하기 위해서 툴을 사용하기도 하고, 제도를 만들기도 하지만, 하나의 정답이 있는 것은 아닙니다. 회사의 개발 역량 수준에 맞게 단계별 계획을 세워서 서서히 정착 시켜 나가야 합니다. 회사의 개발 문화 성숙도가 어느 정도 수준인지 어느 정도의 제도를 소화해 낼지 판단하고 적절한 계획을 세우는 것 또한 많은 경험이 필요한 일입니다. 일단 쉽게 시작할 수는 있지만 가장 효과적인 계획을 세우는 것은 경험자의 도움을 받는 것도 좋은 방법입니다.

모든 개발자들이 코드리뷰를 당연 시 하기 전까지는 언제든지 실패할 가능성이 있습니다.

댓글 11개:

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

    답글삭제
  2. 헝그리맨님 반갑습니다.
    일단 지역적으로 떨어지면 코드리뷰가 절대적으로 어려운 것은 사실입니다. 이럴때는 "Pass around"방법을 쓰는데 툴의 도움을 받을 수 있습니다. 하지만 이 방법은 그리 신뢰도가 높은 방법은 아닙니다. 여러사람이 리뷰를 할 수도 있지만, 어차피 중복되기 때문에 낭비가 될 수도 있고, 리뷰를 잘 해준다는 보장도 없습니다. 그래도 안하는 것보다는 훨씬 낫죠.
    중요한 것은 꾸준히 하는 것입니다. 그러기 위해서는 처음부터 욕심을 부리면 절대로 안되죠. 결국은 성숙도인데, 성숙도에 맞는 계획을 세워야 하고, 어느 정도의 계획이 적당한지는 몇년의 시행착오를 겪는 방법과 경험자에게 도움을 받아서 Pace를 조절하는 방법이 있습니다. 혹시 코드리뷰를 시행하시다가 어려운 점이 있으면 언제든지 알려주세요. 제가 아는한 최대한 도움이 되어 드리면 기쁘겠습니다.

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

    답글삭제
  4. codeart님 안녕하세요.
    방법이야 많지만, 안타깝게도 일반적인 방법론이 별로 도움이 안됩니다. 즉, 골프를 잘치는 방법은 수두룩 하지만 여러가지 방법을 소개한다고 골프를 잘치는데는 별반 도움이 안됩니다. 차라리 연습장 가서 직접 쳐보는데 도움이 됩니다. 또, 무작정 쳐보기만 한다고 실력이 느는 것도 아니죠. 직접 배우면서 연습도 같이 해야 합니다.

    그래도 이왕 Code Review(Peer review)에 대해서 시작한 김에 리뷰시 주의할 사항 및 리뷰를 성공하기 위한 몇가지 팁을 조만간에 올려보려고 합니다. 너무 큰 기대는 마세요. 연습을 얼마나 하는 가가 더 중요하니까요.

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

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

    답글삭제
  6. ohyecloudy님 안녕하세요.
    코드리뷰보다 중요한 것이 설계 리뷰이고, 그보다 중요한 것이 스펙 리뷰인데, 이쪽은 코드리뷰보다 더 취약한 것이 현실입니다.

    답글삭제
  7. 개발과 연구, 개발자와 연구자 어린 시절 나는 찰흙을 가지고 무언가 만드느라 시간이 가는줄도 몰랐었다. 지금 생각하면 웃음이 나오는 일이지만, 신문과 TV에 나오는 각종 신기한 물건을 찰흙으로 만들어 나만의 세상을 만들고 스스로 조물주인양 흐뭇했었던 모양이다. 대학시절 전공했던 전자공학 대신 컴퓨터 관련 수업에 더 빠져들었던 것은 그때의 아련한 추억이 떠올라서였을까. 늘 물리법칙에 구속을 받는 전자공학과는 달리 컴퓨터는 프로그래머가 어떤 법칙에도 구..

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

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

    답글삭제
  9. 안녕하세요. 이성열님

    반갑습니다. 코드리뷰를 하기 위해서 열심히 노력하고 시도를 많이 하시는군요. 이와 같이 대형 LCD TV로 코드를 보면서 검토하는 것은 거의 Inspection 같군요. 많은 리소스와 비용이 드는 방법으로 개발자들이 미리미리 리뷰를 해오지 않으면 자칫하면 비효율적으로 진행되다가 포기할 수 있습니다.
    "리뷰를 하면 시간과 비용이 많이 들지만 꼭 필요하니까 한다"라고 결론이 나면 뭔가 잘못된 겁니다.
    나중에 이런 일이 닥치면 연락을 주세요. 원인이 뭔지 제대로 찾는 것이 필요합니다.

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

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

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

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

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

    답글삭제
  11. 안녕하세요.

    대부분의 경우 거부를 하는데 독특한 경험과 생각을 가지고 계시는 군요. 제가 아는 대기업 몇개도 과거부터 코드리뷰를 하고 있습니다. 저야 직업상 많은 회사의 사정을 잘 압니다.
    물론 코드리뷰를 제대로 하고 있는 회사는 아직 별로 없습니다.

    코드리뷰는 개발자들이 잘하는데 위에서 막을 방법이 별로 없습니다. 코드리뷰를 해서 버그는 더 줄어들지만 개발시간이 더 오래 걸린다는 것은 초단기적인 부작용이고 계속 그렇다면 방법을 좀 바꿔보시는 것이 좋겠습니다.

    코드리뷰를 제대로 하려면 코드 리뷰보다 스펙, 설계리뷰가 선행이 되어야 합니다. 그렇지 않고서는 효과적인 코드리뷰는 어렵습니다.

    답글삭제