2009년 11월 15일 일요일

동료 검토와 관련된 짧은 토론

오늘 잠시 같이 개발을 하는 동료와 한 짧다면 짧고 길다면 긴 토론을 정리하려고한다.

 

토론의 주제는 바로 다음과 같다.

현재 개발이 진행중인 2개의 모듈을 2명이 어떤 방식으로 개발하는 것이 좋을 것인가?

현실을 그대로 반영한다는 의미에서 대화체로 이야기를 풀어 나가 볼까 한다.

 

나 :

현재는 각각의 모듈을 한명이 전담하여 개발을 진행하고 있는데 추후에 이부분을 좀 변경할 필요가 있을 것같다.

 

동료 :

각 모듈에 대하여 각각의 오너쉽은 확실히 하고 다른 사람이 보조 역활을 하는 방식으로 진행하자.

 

나 :

만약 그렇게 한다면 동료 검토를 할 경우 다른 모듈에 대하여 잘 모르게 될텐데 제대로된 동료검토가 안될 것 같다. 동료 검토라는 관점에서 2명이 모든 모듈에 대하여 잘 알아야 할것 같다.

 

동료 :

동료 검토를 위하여 다른 사람이 개발한 모듈에 대하여 알아야 하는 것인 아닌것 같다. 그리고 실제 개발을 담당한 사람보다 검토를 하는 사람이 더 잘 알 수는 없다.

 

나 :

그러면 동료 검토가 제대로 되지 않을 것 같다. 자신이 모르는 모듈을 검토한다는 것이 잘 이해가 되지 않는다. 결국 형식적인 검토로 거치고 제대로 된 검토는 되지 않을 것 같다.

 

동료 :

각각의 모듈에 대하여 오너쉽을 한명이 가져가는 것이 협업을 하지 말자는 의미는 아니다. 하지만 효율이라는 것을 생각했을때 각 모듈에 대한 오너쉽은 개인이 가져가는 것이 맞을 것 같다.

 

나 :

현재는 그럴 수 있지만 장기적으로 생각하면 두명이 2개의 모듈을 상세히 잘 아는 것이 더 효율적일수 있다고 생각한다. 나중을 일을 생각해서도 처음부터 모듈에 대한 이해도를 높히기 위해서 같이 개발을 진행하자.

 

동료 :

검토를 하는 것은 세부적인 구현의 레벨까지 하는 것이 아니고 개발을 하기위한 표준이라던지 설계와 같은 상위레벨로 하는 것이라고 생각한다. 검토는 인터페이스 단위로 관점에서 이루여 져야지 다른 사람이 구현한 모든 것을 검토할 수는 없다. 특히 현재 우리와 같이 자원의 한계가 있는 상황에서 모든 모듈을 모든 사람이 개발하는 것은  효율이 너무 떨어진다. 각자 비교우위의 관점에서 잘 할수 있는 것에 집중하자.

 

나 :

한명이 개발하는 것보다 두명이 동시에 모든 모듈을 잘 아는 것이 각각의 모듈에 대하여 창조적인 방식으로 일할 수 있을 것 같다. 한명이 개발을 전담한다면 혼자하기 때문에 발생하는 오류들도 생길 것 같다.

       

사람의 기억이라는 것의 한계도 있고 의사소통의 한계라는 것도 존재하기 때문에 오늘 있었던 이야기를 정확히 옮겼다고는 생각하지 않는다. 아니 분명히 내가 생각하고 싶은 방향으로 많은 변형이 되었을 것이다. 하지만 오늘 토론의 쟁점은 다음의 2가지 일것이다.

동료검토를 위하여 다른사람이 개발한 것에 대하여 비슷한 수준의 이해가 필요하고 그렇게 하기 위해서는 개발 과정을 번갈아 가면서 진행하여 상호간의 모듈의 이해를 높힐 필요가 있다.
모듈을 동시에 2명이서 번갈아 가면서 개발하는 것은 효율이라는 관점에서 시행하기 힘든 일이다. 각 모듈에 대하여 동시에 개발하지 않더라고 충분히 협업을 진행할 수 있다.

오늘의 토론은 이정도에서 마무리를 하였다. 효율이라는 관점에서 일단은 동료의 의견을 따라야 할 것 같다. 하지만 완전히 납득한 상태는 또 아닌 것 같다. 다른 사람이 구현한 소스를 명확히 이해하지 못한 상태에서 과연 검토가 제대로 이루어 질 수 있는 것인가하는 점은 계속 납득하지 못하게 하는 주요 원인인것 같다. 이제 앞으로 계속 같이 개발을 진행할 사이이니 직접 동료검토도 하고 협업도 하면 과연 그게 가능한 것인지는 알 수 있을 것이라는 생각을 하면서 일단 오늘은 이 생각을 그만 하여야 할 것 같다.

댓글 6개:

  1. trackback from: 이 정도도 안되면서 Peer Review를 한다고요?
    소프트웨어 개발의 기초도 되어 있지 않으면서 무리하게 Peer Review를 시도하다가 실패하기 십상입니다. 개발의 체계도 전혀 없이 코딩위주로 개발을 하고 있다면 Peer Review할 것도 별로 없거니와 Peer Review를 통해서 공유의 문제와 품질을 향상할 수 있을 것으로 착각하는데, 이는 Peer Review를 너무 만만하게 보는 것입니다. 피아노 기초도 안되어 있으면서 쇼팽을 치려는 것과 같고, 기초 체력도 부족하면서 축구의 고급 기술은..

    답글삭제
  2. trackback from: Peer Review의 방해꾼들
    Peer Review가 정말 중요하다고들 다들 생각할 것 같지만, 실상은 그렇지 않습니다. Peer Review의 중요성을 알고 있는 사람은 정말 많은 경험과 깨달음을 얻은 사람이고 대부분은 Peer Review의 중요성을 모르거나 심지어는 노골적으로 또는 은연 중에 방해를 합니다. Peer Review는 (이미 언급했지만), 소프트웨어의 결함을 줄이고 개발 비용과 시간을 절약하며, 개발자들 간의 정보와 지식을 공유하고, 개발자들을 성장시키며, 개발..

    답글삭제
  3. trackback from: Peer Review의 치명적인 유혹
    Peer Review는 익히 언급했다시피 가장 중요한 소프트웨어 개발 문화 중에 하나입니다. 그런데, Peer Review를 시행하다보면 경영층에서는 Peer Review를 평가에 이용하고 싶은 생각이 들게 마련입니다. Peer Review 시행자체를 권장하기 위해서 Peer Review 시행 여부를 관리자들의 평가 기준에 포함하는 것은 일리가 있지만, Peer Review의 내용을 평가에 반영하는 것은 자칫 부작용이 더 클 수도 있습니다. 평가에..

    답글삭제
  4. trackback from: Peer Review를 성공하기 위한 요소들
    얼마 전에 "코드리뷰 정착이 어려운 이유"라는 글을 올린 적이 있습니다. 그에 대해서 codeart 님께서 코드리뷰에 대한 일반적인 방법론에 대해서 궁금해 하시더군요. 하지만 이런 방법론은 알면 도움이 되지만, 이것을 안다고 코드리뷰를 성공하는데는 별로 도움이 안됩니다. 하지만 몇가지 성공 요소는 생각해 볼 수 있습니다. 이제부터는 코드리뷰보다는 Peer Review라고 하겠습니다. 사실 코드만 리뷰를 하는 것이 아니고 스펙문서부터 소스코드등 개발..

    답글삭제
  5. trackback from: 코드리뷰 정착이 어려운 이유
    코드리뷰는 소프트웨어를 개발하는데 있어서 가장 좋은 문화중의 하나이지만 또한 가장 정착시키기 어려운 것 중의 하나입니다. 코드리뷰를 도입하거나 정착하기 어려운 이유는 다음과 같습니다. 공개적으로 망신을 당하거나 자신을 비판하는 것에 대한 두려움 과거의 부정적인 코드리뷰에 대한 경험 자신이 실력이나 약점이 드러나서 평가가 나빠질 것에 대한 두려움 자신의 코드는 완벽하다는 밑도 끝도 없는 확신 및 자신에 대한 너그러움 코드리뷰가 개발 일정을 지연시킨다는..

    답글삭제
  6. 동료검토가 당연한 것 같으면서도 실제 하려고 하면 어려다고 생각됩니다. 동료검토에 대한 글은 이제까지 계속 읽고는 있었습니다만 한번더 읽어보도록 하겠습니다. 그리고 부족한 글에 관심을 보여주셔서 감사합니다.

    답글삭제