오늘 잠시 같이 개발을 하는 동료와 한 짧다면 짧고 길다면 긴 토론을 정리하려고한다.
토론의 주제는 바로 다음과 같다.
현실을 그대로 반영한다는 의미에서 대화체로 이야기를 풀어 나가 볼까 한다.현재 개발이 진행중인 2개의 모듈을 2명이 어떤 방식으로 개발하는 것이 좋을 것인가?
나 :
현재는 각각의 모듈을 한명이 전담하여 개발을 진행하고 있는데 추후에 이부분을 좀 변경할 필요가 있을 것같다.
동료 :
각 모듈에 대하여 각각의 오너쉽은 확실히 하고 다른 사람이 보조 역활을 하는 방식으로 진행하자.
나 :
만약 그렇게 한다면 동료 검토를 할 경우 다른 모듈에 대하여 잘 모르게 될텐데 제대로된 동료검토가 안될 것 같다. 동료 검토라는 관점에서 2명이 모든 모듈에 대하여 잘 알아야 할것 같다.
동료 :
동료 검토를 위하여 다른 사람이 개발한 모듈에 대하여 알아야 하는 것인 아닌것 같다. 그리고 실제 개발을 담당한 사람보다 검토를 하는 사람이 더 잘 알 수는 없다.
나 :
그러면 동료 검토가 제대로 되지 않을 것 같다. 자신이 모르는 모듈을 검토한다는 것이 잘 이해가 되지 않는다. 결국 형식적인 검토로 거치고 제대로 된 검토는 되지 않을 것 같다.
동료 :
각각의 모듈에 대하여 오너쉽을 한명이 가져가는 것이 협업을 하지 말자는 의미는 아니다. 하지만 효율이라는 것을 생각했을때 각 모듈에 대한 오너쉽은 개인이 가져가는 것이 맞을 것 같다.
나 :
현재는 그럴 수 있지만 장기적으로 생각하면 두명이 2개의 모듈을 상세히 잘 아는 것이 더 효율적일수 있다고 생각한다. 나중을 일을 생각해서도 처음부터 모듈에 대한 이해도를 높히기 위해서 같이 개발을 진행하자.
동료 :
검토를 하는 것은 세부적인 구현의 레벨까지 하는 것이 아니고 개발을 하기위한 표준이라던지 설계와 같은 상위레벨로 하는 것이라고 생각한다. 검토는 인터페이스 단위로 관점에서 이루여 져야지 다른 사람이 구현한 모든 것을 검토할 수는 없다. 특히 현재 우리와 같이 자원의 한계가 있는 상황에서 모든 모듈을 모든 사람이 개발하는 것은 효율이 너무 떨어진다. 각자 비교우위의 관점에서 잘 할수 있는 것에 집중하자.
나 :
한명이 개발하는 것보다 두명이 동시에 모든 모듈을 잘 아는 것이 각각의 모듈에 대하여 창조적인 방식으로 일할 수 있을 것 같다. 한명이 개발을 전담한다면 혼자하기 때문에 발생하는 오류들도 생길 것 같다.
사람의 기억이라는 것의 한계도 있고 의사소통의 한계라는 것도 존재하기 때문에 오늘 있었던 이야기를 정확히 옮겼다고는 생각하지 않는다. 아니 분명히 내가 생각하고 싶은 방향으로 많은 변형이 되었을 것이다. 하지만 오늘 토론의 쟁점은 다음의 2가지 일것이다.
동료검토를 위하여 다른사람이 개발한 것에 대하여 비슷한 수준의 이해가 필요하고 그렇게 하기 위해서는 개발 과정을 번갈아 가면서 진행하여 상호간의 모듈의 이해를 높힐 필요가 있다.
모듈을 동시에 2명이서 번갈아 가면서 개발하는 것은 효율이라는 관점에서 시행하기 힘든 일이다. 각 모듈에 대하여 동시에 개발하지 않더라고 충분히 협업을 진행할 수 있다.
오늘의 토론은 이정도에서 마무리를 하였다. 효율이라는 관점에서 일단은 동료의 의견을 따라야 할 것 같다. 하지만 완전히 납득한 상태는 또 아닌 것 같다. 다른 사람이 구현한 소스를 명확히 이해하지 못한 상태에서 과연 검토가 제대로 이루어 질 수 있는 것인가하는 점은 계속 납득하지 못하게 하는 주요 원인인것 같다. 이제 앞으로 계속 같이 개발을 진행할 사이이니 직접 동료검토도 하고 협업도 하면 과연 그게 가능한 것인지는 알 수 있을 것이라는 생각을 하면서 일단 오늘은 이 생각을 그만 하여야 할 것 같다.
