2014년 12월 30일 화요일

페어 프로그래밍을 넘어서 - Mob programming

 오늘은 최근 업무상 Ruby를 다루다 발견한 재미있는 프로그래밍 기법에 대해 소개해 보고자 한다.

 애자일 코치이자 개발 매니저인 우디 줄Woody Zuill이 제안한 Mob Programming이라고 하는 작업 기법은 페어 프로래밍의 확장판으로 우리말로 번역하자면 떼 코딩 정도가 되겠다.
우디 줄이 직접 그린 몹 프로그래밍 로고(?)
우선 몹 프로그래밍을 설명하기에 앞서 아이디어의 근원이 되는 페어 프로그래밍을 간단히 살펴보자. 


백지장도 맏들면 낫다 - 페어 프로그래밍

 페어 프로그래밍은 익스트림 프로그래밍에서 나온 에자일 개발의 대표적인 실천 방법 중 하나이다. 페어 프로그래밍에 대해 간단히 정리해 보자면 다음과 같다.

 페어 프로그래밍은 말 그대로 두 사람이 짝을 이루어 한 대의 컴퓨터로 작업한다. 키보드를 잡은 사람은 드라이버, 옆에서 이를 보조해 주는 사람은 네비게이터라고 부르며 각각의 역할은 다음과 같다.
페어 프로그래밍에서의 드라이버와 네비게이터는
명칭을 차용해 온 랠리 선수들의 역할 분담과 동일하다.
출전 : http://jesusgilhernandez.com/

  •  드라이버
 키보드를 조작하며 직접 코드를 작성한다.
 네비게이터와 논의가 가능 하도록 작성하는 모든 코드 요소들에 대해서 말로 설명해 가며 작업을 진행시킨다.
 네비게이터의 질문과 의견에 대해서 건설적으로 응답해야 하며, 네비게이터의 의견은 프로세스의 일부이므로 짜증을 내거나 방어적으로 대응해서는 안된다.
  •  네비게이터
 드라이버가 눈앞의 나무를 보며 달려간다고 한다면 네비게이터는 큰 지도를 살펴보며 목적지에 다다르는 길을 안내하는 역할을 해야 한다. 
 네비게이터는 드라이버의 작업을 지켜보며 더 나은 방법이 있다고 생각되는 부분에 대해서 조언하고, 의문이 드는 점에 대해서는 언제든지 질문 하며, 잘못되었다고 생각되는 부분에 대해서는 즉시 지적을 할 수 있어야 한다.

 페어 프로그래밍에 대해서는 한국 eXtreme Programming 사용자 모임에서 문서를 제공하고 있는데, 여러 경험자들의 노하우를 잘 정리해 놓고 있으므로 아직 읽어보지 않는 사람이라면 페어 프로그래밍에 대해서 어느 정도 알고 있다고 하더라도 시간을 들여 읽어 볼만한 가치가 있다.

 페어 프로그래밍 도입의 걸림돌로 주로 지적되는 것은 작업의 효율성이다. 당장 두 명의 프로그래머가 화면 하나로 작업을 해야 하니 아무래도 각자 작업하는 것 보다 작업 효율면에서 떨어지지 않겠느냐는 것 이다. 하지만 실제 도입한 경험자들의 경험담에 의하면 커뮤니케이션 비용 절감으로 작업 품질이 높아지는 것 이외에도 집중력의 지속도 크게 향상된다 한다. 
 필자는 실제 페어 프로그래밍을 체험해 보진 않았지만 당장 옆에 사람이 뻔히 지켜보고 있는데 웹서핑 같은건 할 수가 없을 것 같긴 하다. 아마도 여러 애자일 개발 실천 방법중 효과가 좋다고 보고되고 있음에도 불구하고 생각보다 널리 퍼지고 있지 않는 이유도 어쩌면 프라이버시 유지에 부담을 느껴서 이지 않을까? 

페어 프로그래밍만 하더라도 근무시간에 딴짓 하기가 불가능해진다.
2인용도 있쟎아?
출처: 안랩


 다구리에 장사 없다 - 몹 프로그래밍

 몹 프로그래밍은 한 명의 드라이버와 여러 명의 프로그래머가 하나의 PC로 코딩 또는 문서화 작업을 진행하는 개발 방식으로 1:1방식인 페어 프로그래밍을 1:n으로 확장시킨 형태이다. 여기서 n은 에자일 개발팀 전체 인원수로 팀 전원이 참여한다는 것이 특징이다.

몹 프로그래밍 풍경.
여러 명이 동시에 진행상황을 확인 할 수 있어야 하기 때문에
프로젝터를 사용하는 모습이 흔히 보여진다.
출처: mobprogramming.org


 백문이 불여일견이리라. 몹 프로그래밍이 어떠한 형태로 진행되는지는 다음 영상을 참고해보자. 영어도 필요 없고 딱 3분만 투자 하면 된다.

화면 맨 오른쪽의 머리 숱이 적으신 분이 우디 줄이다.

 몹 프로그래밍이 추구하는것은 페어 프로그래밍의 장점인 커뮤니케이션 비용 최소화를 통한 작업 효율을 극대화 이다. n명이 하나의 테스크에 동원된다는 것은 전통적인 작업 관리 측면에서 보면 엄청나게 비 효율적인 작업 방식이다. 당장 전통적인 관리자 입장이 되어보라. gantt chart에 사용할 선이 하나 뿐이다!

 하지만 몹 프로그래밍의 생산성에 대해 xper.org에서 페어 프로그래밍에 언급된 다음의 요소들을 고려해 보자. 몹 프로그래밍은 원래 페어 프로그래밍의 장점을 극대화 하려는 시도이므로 장점과 단점 역시 보다 극대화 된 형태로 드러나게 된다.

  • 통합시간 : 모든 작업들이 한개의 직선 위에서 진행되므로 개개인의 작업을 통합하는데 필요한 시간이 사라지게 된다. 특히, 각자의 머리속에 있는 지식 도메인의 통합이 작업과 동시에 이루어 짐으로서 커뮤니케이션 비용을 줄일 수 있을 것이다.
  • 코드라인수 : 일반적으로 페어 프로그래밍의 라인수는 혼자 작업한 경우에 비해 절반정도로 줄어드는 것으로 보고되고 있다. 이 결과는 매우 중요한 의미를 지니는데, 단순히 타이핑하는데 들어가는 시간의 절약 뿐만이 아니라 낮은 결함률 과도 연관이 있다. 어떤 언어든 라인당 결함수가 일정하다는 소프트웨어 공학적 사실을 놓고 볼 때에, 적은 양의 코드는 더 향상된 품질을 지니게 된다고 볼 수 있다.
  • 낮은 결함률 : 팀 전체가 함께 생각하며 코드를 작성하므로 당연히 결함률도 떨어지게 될 것이다. 특히,  커뮤니케이션 부족에서 오는 다양한 사양에 대한 결함도 그때그때 발견하고 해결이 가능하므로 완성되는 코드의 품질은 매우 높아질 것으로 기대되어진다.  
  • 집중 지속 시간 : 아무래도 모여서 같이 작업하면 딴 짓 하기 힘들어진다. 
  • 지식공유 : 잘 조직된 팀이라 할 지라도 개인간의 능력차는 엄연히 존재한다. 몹 프로그래밍에서는 자잘한 테크닉에서 부터 어플리케이션의 도메인 영역에 대한 이해까지 폭넓게 지식을 확산시키는데 매우 유용할 것으로 기대된다.  
  • 프로그래머 육성 패턴 : 위의 지식 공유의 연장 선상 에서 필자가 몹 프로그래밍을 주목하는 가장 큰 이유는 프로그래머 육성 패턴으로서의 가능성 때문이다. 이에 대해서는 잠시 후에 좀 더 자세히 언급해 보겠다. 

 프로그래머 육성 패턴으로서 몹 프로그래밍의 가능성

 앞에서도 언급한 바와 같이 원래 몹 프로그래밍은 페어 프로그래밍이 가진 커뮤니케이션 효율을 극대화 시켜 작업의 질을 높이기 위한 테크닉이지만 필자가 주목하는 부분은 지식과 경험의 전달 패턴, 즉 프로그래머 육성 방법으로서의 가능성이다.

 오픈소스가 일반화된 요즘 시대에서 가장 좋은 교재는 오픈소스 프로젝트이며 인터넷을 통한 정보공유가 일반화된 지금 시대에서 필요한 정보나 지식은 영어라는 장벽 하나만 넘는다면 얼마든지 얻을 수 있지만, 그럼에도 불구하고 보다 더 디테일한 고수들이 문제 해결 방법이나 사소한 습관들을 엿볼 수 있는 방법이 없을까 에 대해서 갈망하고 고민하게 된다.

  몹 프로그래밍은 지식과 노하우의 공유라는 측면에서 상당히 극단적인 형태를 띄게 된다. 드라이버 입장에서는 자신의 모든 작업 습관이 드러나게 되므로 부담이 적지 않겠지만 지식과 노하우의 공유라는 측면에서는 어께넘어 배우는 것 과는 비교도 할 수 없는 효율을 가져 올 수 있을 것이다.

 실제 몹 프로그래밍이 진행되는 모습을 참고해 보고 싶다면 Youtube등에서 mob programming이라는 키워드로 영상을 찾아 볼 수 있을것이다. 필자가 추천하는 영상은 애자일 소프트웨어 개발 운동의 발기인중 한명인 엘리스터 콕번이 루비를 이용해 진행하는 몹 프로그래밍 영상이다. 구글 행아웃을 이용해 원격으로 진행 되는 것이 한 장소에 모여 개발하는 일반적인 몹 프로그래밍과는 다르지만 몹 프로그래밍 방식으로 진행되는 개발의 흐름을 잘 엿볼 수 있다.  


emacs를 이용해 루비 코딩을 진행하는 방식 또한 눈여겨 봐 둘만 하다. 

몹 프로그래밍이 넘어야 할 벽 - 질문을 꺼려하는 문화

 몹 프로그래밍이 국내에 올바른 모습으로 보급되기 위해서는 무엇보다 넘어야 할 큰 장벽이 있다. 바로 질문을 꺼려하는 문화적 배경이다. 짝 프로그래밍 이든 몹 프로그래밍 이든 위계질서를 내려 놓고 열린 사고로 비판과 의문을 받아들이고 오답이든 정답이든 신경 쓰지 않고 솔직하게 자신의 생각을 밝힐 수 있어야 진정한 의미 에서의 의사 소통과 지식 공유가 이루어 질 수 있을 것이다.

질문이 허용되지 않는 경직된 문화 속 에서는
몹 프로그래밍이 아무리 좋은 기법이라 하여도
결코 올바로 자리 잡을 수 없을 것이다.

 뉴욕의 프로그래머 임백준은 ZDNet에 쓴 기사 -그대 힘으로 생각하라, 가차없이 질문하라- 를 통해 이처럼 질문을 꺼리는 문화가 인문학 결핍의 결과라고 말하고 있다. 필자 또한 이 의견에 격하게 동의하는바, ZDNet 기사의 일부분을 소개하며 Mob Programming소개 글을 마친다.

진정한 의미에서의 인문정신과 거리가 먼 우리의 교육과정과 직장문화는 사람들이 질문에 대해서 갖는 태도를 이렇게 기묘하게 우그러뜨려 놓았다. 질문을 구성하는 힘은 인문정신의 핵심이다. 질문을 하기도 잘 해야 하고, 받기도 잘 받아야 한다. 하지만 지금까지 우리는 인문정신이 탈색되어 사라진 무념무상의 순한 존재로 훈련되어 왔다. 
 질문을 받는다는 것은 (1) 자기 생각을 공개적으로 밝힐 수 있는 기회, 혹은 (2) 상대방의 질문을 내 생각대로 재구성할 수 있는 기회를 의미한다. 정답 혹은 오답이라는 개념은 없다. 그런데 우리는 질문을 받으면 정답을 말해야 한다는 심리적 압박 때문에 입을 열지 못한다.  오답을 말하는 것이 질문한 사람에 대한 무례라고까지 생각한다. 내가 스스로 무엇을 생각하는지가 아니라, 타인이 나를 어떻게 보는지가 더 중요하다.   



참고 문헌



시간:

댓글 1개: