짝 프로그래밍(Pair Programming)에 대해 아시나요?

짝 프로그래밍(Pair Programming)은 크립토나이트!

Chris Mountford 가 Agile에 대해 이야기 합니다.(2009년 6월)
http://www.atlassian.com/agile
짝 프로그래밍(Pair programming)은 애자일 개발(agile development) 방법에서 가장 논쟁적이며 대다수가 회피하는 내용입니다.
일부 사람들은 이것에 대해 매우 불편해 합니다.

짝 프로그래밍(pair programming) 은 하나의 컴퓨터에서 2명의 개발자가 같이 작업하는 것을 의미합니다. 그렇습니다. 일반적으로 한 사람은 코딩하는 동안 다른 사람은 여러 앞뒤 상황을 생각하는 것입니다. 다시말해 한 사람은 운전하고, 다른 한 사람은 지도로 방향을 확인하는 것입니다. 목적은 가장 좋은 결과물이 될 것입니다.

짝 프로그래밍(Pair programming)은 대부분의 개발자(developers)들이 익숙해 왔던 것보다 더욱 팀동료와의 밀착 작업을 요구합니다. 그리고 이것은 강력한 장점이면서도 약점이기도 합니다.

다른 사람과 밀착해서 일한다는 것은 개인적인 문제를 불러오기도 합니다. 제 경험으로는 이전 작업에서 짝 프로그래밍이 그 팀에서 불가능한 환경을 가진 일부 사람들에게는 개인적으로 대단한 도전임을 알았습니다.
용기와 성숙함을 필요로 하는 것입니다. 상호 존중과 유머 그리고 온화함이 모두 요구되는 건강한 환경이 필요합니다.
개인 위생에 관한 최소한의 규칙도 포함해서요. (신종플루가 유행하는 요즘 더욱 그렇습니다)
이것은 일반적인 사무실 작업환경마다 다를 수 있는데 일부 환경에서는 도입하기 매우 어려운 것이 사실입니다.
아마도 슈퍼맨과 같은 프로그래머만이 이러한 짝 프로그래밍 환경에 견딜 수 있을 것입니다. 그래서 이것이 크립토나이트(kryptonite)와 같은 것입니다.

서양사람이 동경이나 서울을 처음 방문할때의 문화적 쇼크와 같이, 개인공간의 침범, 즉 일부에게는 침입과도 같은 짝 프로그래밍은 자기 스스로가 헤쳐나가야 할 자신의 장벽이 되는 것입니다.


다른 사람과의 짝 프로그래밍은 개인적인 접촉을 동적인 도전으로 만듭니다. 서로 다른 행동을 요구하는 여러 경우가 있습니다. 예를들면, 초심자-숙련자 경우와 내성적인사람과 외향적인 사람 조합, 혹은 서로다른 일하는 방식과 문제해결방법을 가진 사람의 조합이 있습니다.
가령, 저는 때로 일반적이지 않은 방법으로 문제를 탐색하는데 이것은 방법론에 충실한 사람을 불안하게 하는 것입니다. 이 조합이 저에게 도움을 줄수 있다는 것을 알게되면 적절히 상대방과 소통하고 필요한 곳에서 저의 행동을 변하게 할 것입니다.

짝 프로그래밍은 상호 적응성과 협상기술을 필요로 합니다.

비효율적인 짝 프로그래밍으로 이끄는 일반적인 잘못된 패턴이 많이 있습니다. Laurie Williams 과 Robert Kessler 가 쓴 Pair Programming Illuminated를 예를 들면 이런 내용들은 이미 문서로 잘 정리되어 있습니다. 비효율적인 짝 프로그래밍은 하지 않는것보다 못하기 때문에 이러한 내용은 충분히 읽어볼 가치가 있습니다.

최근 짝 프로그래밍에 관해 제가 생각하는 여러 이유 중 하나는 변화를 위해 제가 한 것이 없었기 때문입니다.
여러 버그들을 수정하고 지원하는 과정은 제쳐놓고서라도, JIRA 4.0의 프론트앤드 기능에 대해 거의 저 혼자 일하고 있었습니다. 왜냐하면 저의 팀이 안타갑게도 현재 홀수 인원이기 때문입니다. (혹시 입사 하시겠습니까? wanna job?) 오히려 이것이 저를 짝 프로그래밍에 대해서 다소 객관적으로 평가할 수 있도록 만들었습니다.

짝 프로그래밍을 하지 않는 좋은 점 중 첫번째는 다른 사람과의 작업없이 헤드폰을 끼고 음악을 들으며 일할 수 있는 점입니다. 지속적으로 나의 의견이나 질문을 표현하는 방법을 고민하거나 들을 필요가 없습니다. 단지 생각하고 작업하는 것입니다. 이것은 기분 좋은 일입니다.

그러나 그것이 조금은 외톨이가 되었다는 것을 부정하지는 않습니다. 저는 여러 사람과 같이 있는 것을 좋아합니다.

짝 프로그래밍을 하지 않는 부정적인 부분은 여러분이 짝 프로그래밍을 하지 않는데 익숙해 질 때 알게됩니다. 제가 최근에 짝 프로그래밍을 하지 않는 동안, 제 작업의 퀄러티에 대해 상당히 의심스러워 졌습니다.

내 생각에 괜찮은데, 정말 좋은가? 내가 정말 능력있는가? 아마도 이것은 잘못된 접근일거야. 내가 놓치는 것이 확실히 있는가? 이것을 리뷰해줄 사람이 있는게 좋겠어.

이러한 모든 생각은 내가 테스트를 통과하고 다음단계에 대해 고민할 때 더욱 괴롭힙니다. 제가 짝 프로그래밍을 할 때는 생기지 않던 일입니다. 아마도 짝 프로그래밍을 했다면, 제 파트너와 상의했을 것입니다; 아마 파트너와 "공통의견"을 가지게 되었을 것입니다.

짝 프로그래밍은 팀을 밀착(making a team gel)시키는데 도움이 됩니다. 같이 시간을 보내는 것 – 짝 프로그래밍 만이 아니라, 일하는 동안 식사나 다른 사회적 활동을 공유하는 것과 같은 기타 활동들이 팀을 밀착시키게 도와줍니다.

그래서 이외에도 짝 프로그래밍을 실행하는 여러 다른 이유가 있지만, 반드시 짝 프로그래밍만이 이러한 효과를 얻는 유일한 방법은 아닙니다. 소스코드 리뷰(Code review) 또한 같은 효과를 위한 분명한 대안입니다. 아마도 이 시점에서 제가 Crucible을 언급하지 않으면 영업부서에서 제 팔을 부러뜨릴 겁니다.

그러므로, 만약 여러분이 짝 프로그래밍으로 코드개발 작업의 퀄러티를 개선하지 않고 있다면, 소스코드 리뷰를 하기 바랍니다. 왜냐하면 산업계에 별다른 이견 없이 널리 알려진 소프트웨어 개발 퀄러티(quality software development)를 보장하는 효과적인 방법이기 때문입니다.

Atlassian 개발팀은 짝 프로그래밍 혹은 코드리뷰 중 하나를 혹은 JIRA 팀의 경우는 2가지 모두를 때로는 부분적으로 같이 이용합니다.

코드리뷰를 위한 툴(Crucible for code reviews)을 이용하는 것은 기록보관이나 지역적으로 분산된 팀을 위해 짝 프로그래밍을 하는데 있어 좋은 점을 가집니다. 짝 프로그래밍은 코드리뷰에 대해 키보드 단축키를 교환하거나 팀을 밀착시키는데 좋은 장점을 가집니다.

그러므로, 더 나은 소프트웨어 품질을 위한 업무를 해야 한다면, 기억하십시요: 백짓장도 맞들면 낫다.