미투데이의
iron님의 글에서
자그마한 짝 프로그래밍 토론이 이뤄지고 있습니다.
제가 짝 프로그래밍 경험이 많은 것도 아니고 애초에 XP의 여러 프랙티스 중에서도 그리 신뢰를 하던 놈이 아니라서 열정적이지도 않습니다. 하지만, 설계 개념을 공유해야 하거나 기술을 전달해야 할 때, 또는 서로의 경험을 나눌 때에는 유용하다고 생각하여 의도적으로 지난 프로젝트에서 몇몇 사람을 붙잡고 (알게 모르게) 짝 프로그래밍을 시도해봤습니다.
결과는 상당히 긍정적이었습니다. 교육 효과도 좋았고 저 자신도 집중이 훨씬 잘 되었습니다. 오히려도움 받은 경우도 많았고요. 하지만
백일몽님의 말씀처럼 에너지 소모가 상당해서 제 경우 2시간을 넘기니 차크라가 바닥나더군요. 원인은 물론 말 때문이었습니다. 일을 하면서 계속 대화를 해야 하고 교육목적인 만큼 설계 의도를 미리 설명해줘야 부조정사가 잘 따라오는데 일을 하면서 말을 하는 것이 보통 어려운 것이 아니었습니다.
이 부분에서 예전에 시청했던 다큐멘터리의 내용이 생각나더군요. EBS의 동과서였는데 한·중·일을 중심으로 한 동양 사람과 북미를 중심으로 하는 서양사람의 사고방식이 어떻게 다른지 비교하는 내용이었습니다. 서양사람들은 자기 중심적이고 분석적인 반면 동양사람들은 관계 중심적이고 종합적이라고 하더군요. (
간단한 요약이 있네요.
책으로도 나왔고요.)
다큐멘터리 내용 중 어떤 행동을 하면서 자기가 하는 일을 말로 중얼거리면서 하도록 했을 경우의 동과 서가 어떻게 다른지 비교하는 부분이 있었습니다. 서양 사람들은 자기의 행동을 말로 표현하면서 일을 했을 때 더 효과적으로 일을 할 수 있었습니다. 마치 마징가 같은 로보트 조종사가 다음에 어떤 공격을할지 말로 하는 것처럼 말이죠. ㅎㅎ
반면에 동양인은 자기 행동을 말로 표현하는데 무척 어려워했고 일 처리 능력도 현저하게 떨어졌습니다. 동양인은 자기 행동을 일일이 분석해서 말로 표현하는 일이 아주 낯선 일이라고 하더군요. 제 경험을 봐서도 이런 분석이 맞는 것 같습니다.
결국, 한국인이 짝 프로그래밍을 하는 데는 문화적인 장애가 있는 것이죠. 물론 장애는 극복할 수 있고 개인의 성향에 따라서 극복하는데 느끼는 어려움의 정도가 차이가 나리라 생각됩니다. 분명한 것은 짝 프로그래밍을 하려고 하거나 이를 보급하고 싶은 사람들은 이 점을 염두에 두고 추진해야 할 것이라 생각됩니다.
제 경우 짝 프로그래밍 수련의 방법으로 몇 가지 생각한 것은 다음과 같습니다.
- 처음에는 짝 프로그래밍을 하루에 2시간 이상 하지 않는다.
- 자기가 하는 일을 말로 표현하는 능력을 키운다.
- 함축적으로 의사전달을 할 수 있는 환경을 조성한다.
1번이야 개인마다 가지는 차크라의 양이 다르니 수련 정도에 따라 알아서 할 일인듯 합니다. 최소 1주에 한두 시간은 짝 프로그램을 해서 점차 익숙해지도록 하는 것이 좋을 듯싶더군요. (물론 저는 모든 프로그래밍을 짝으로 해야한다고 믿는 수준은 아닙니다. 대략 저는 극단적인 것을 좋아하지 않습니다. ^^);;
2번은 Subversion이나 CVS 같은 SCM에 변경사항을 반영할 때 자기가 한 일을 잘 표현하는 실력부터 키우는 것이 좋을 것 같았습니다. CVS 같은 경우는 파일 단위로 관리가 되기 때문에 변경 작업을 파일 수준에서 표현하면 되지만 Subversion은 프로젝트 전체에서 자신의 작업이 어떤 의미가 있는지 표현할 수 있어야 하기 때문에 많이 도움이 되는 듯합니다.
3번은 패턴이나 개발 표준이 유용할 듯합니다. 디자인 패턴이나 구현 패턴같이 이미 발표된 것을 스터디하거나 개발팀 고유의 패턴을 도출해서 이를 공유한다면 더 적은 수의 어휘를 사용해서 정확히 의도를 전달할 수 있기 때문에 짝 프로그래밍을 할 때에 신경을 덜 쓰고 할 수 있을 것 같더군요. 개발 표준은 말할 필요도 없겠죠.