Talk with Hani

로망은, 실현되리라!

느끼게 하라, 그리고 자유롭게 하라

 

대한민국 소프트웨어는 위기다?!

이 위기를 도약의 발판으로 삼고 싶으신가요? 그렇다면 ‘대한민국 소프트웨어, 리스타트’, 이 책을 한 번 읽어 보세요.
대한민국 소프트웨어, 리스타트

Yes24 교보문고 알라딘 리브로 인터파크

저를 포함해서 팀원이 4명인 프로젝트를 관리했을 때 일입니다. 팀원 한명은 실력이 뛰어났고, 팀원 2명의 실력은 좋은 편이거나 아직 배울 게 많은 편이었습니다. 개발할 기능의 난이도에 차이가 있었지만, 제시간 안에 프로젝트를 끝내려면 팀원들의 실력이 빠른 기간 안에 상향평준화되어야 했죠. 그래서 생각해 낸 방법이 짝 프로그래밍이었습니다.

그런데 문제는, 팀원들이 짝 프로그래밍을 한번도 경험해 보지 않았다는 것이었습니다. 스탠드 업 미팅도, 경험해 보지 않은 분들에게 상당히 낯설고 부담스러운 애자일 프랙티스죠. 그런데, 실천하기 가장 어려운 실천방법으로 꼽히는 짝 프로그래밍을 애자일 프랙티스를 한번도 경험해 보지 않은 팀원들에게 소개한다는 게 부담스러웠습니다. 팀원들도 프로젝트에서 실수할 여력이 없다는 것을 잘 알았고 뭔가 새로운 방법이 필요하다는 것을 인지했기 때문에, 용기를 내어서 짝 프로그래밍을 해보자고 했습니다.

팀원들은 드러 내놓고 거부하지 않았지만, 다들 새로운 방법으로 접근한다는 걸 좋아하는 눈치가 아니었습니다. 특히 실력이 괜찮은 팀원은 혼자 생각하고 일하는 걸 좋아하는 편이라고, 넌지시 짝 프로그래밍을 거부했습니다. 물론 팀원들이 기다렸다는듯이 짝 프로그래밍을 환영할 것이라고 기대하지 않았지만, 암묵적인 거부에 조금 당황스러웠죠.

하지만 프로젝트의 성공 가능성을 높이려면, 기존의 방법대로 프로젝트를 수행해선 안 된다는 것을 알았기에, 솔루션을 찾아야 했죠. 그래서 실력이 가장 좋은 팀원과 제가 짝이 되고, 다른 개발자들을 짝으로 묶어 짝 프로그래밍을 1주일 동안만 해보자고 제안했습니다. 1주일 동안, 경험하고 나서도 혼자 개발하는 기존 방법이 괜찮다면, 그렇게 하자고 말했습니다. 마음씨 좋은 팀원들은, 독단적인 PM의 제안을 수락해 주었습니다.

긴 진화의 역사 속에서, 인간은 변화를 거부하는 습성을 지니게 되었죠. 하지만 이에 반해, 변화 무쌍한 험난한 세상 속에서 인간은 생존하기 위해, 변화에 훌륭하게 적응하는 방법도 배웠죠. 그래서 제 전략은 이랬습니다. 일단 1주일 안에 개발자들은 짝 프로그래밍을 경험하고, 변화된 개발환경에 대개 적응할 것이라는 생각이 들었습니다. 그리고 제가 오피니언 리더 격인 개발 실력이 좋은 팀원에게 짝 프로그래밍의 성공 경험을 선사함으로써, 1주일 후 그 팀원을 짝 프로그래밍의 전도사로 만들고 싶은 순진한 생각도 한몫했습니다.

짝 프로그래밍을 시작하고 나서, 저와 짝이 된 팀원들은 매우 빠른 속도로 짝 프로그래밍에 익숙해졌죠. 그리고 곧 저와 팀원 사이에는, 배움의 선순환이 일어났습니다. 팀원은 제 단축키 신공에 감탄했고, 전 팀원의 디버깅 실력에 탄복했습니다. 금세 1주일이 지나고, 짝 프로그래밍을 계속해야 할 것이냐를 결정할 날이 돌아왔습니다. 제 순진한 생각처럼, 제 짝인 팀원이 짝 프로그래밍 전도사로 변신하지 않았지만, 팀원들은 모두 짝 프로그래밍의 효과를 느낀 탓인지 짝 프로그래밍을 계속하는데 찬성했습니다. 그리고 짝을 바꿔서 개발을 했고, 야근을 조금 많이 했지만 프로젝트는 잘 끝났죠.

어느날, 제 처음 짝이었던 팀원에게 짝 프로그래밍이 어땠는지 물었습니다. 당연히 긍정의 답을 기대하면서 한 질문이었죠. 그런데,

음… 확실히 짝 프로그래밍이 효과적이라는 데 이견이 없는데요. 그래도 전 혼자 생각하면서 프로그래밍하는 편이 더 좋은 것 같아요. 누군가 옆에 앉아서 같이 일한다는 게 부담스럽더라고요.

팀원의 예상밖 답변에 당황했습니다만, 팀원의 솔직한 대답 덕분에 많은 걸 깨닫게 되었습니다. 독단적인 PM이 되고 싶지 않아서 여러 가지 방법을 써보아도, 다수의 의견에서 안정을 찾으려는 사람들에게 공개적인 의견을 수렴한다는 것에, 한계를 절감했습니다. :)

그리고 어떤 방법이 뛰어나더라도, 심리적으로 그 방법에 호의적이지 않다면, 아무리 효과가 좋아도 사람들은 그 방법을 택하지 않을 것이라는 점을 새삼 깨달았습니다. 그래서 똑똑한 사람이라도 감정에 스크래치가 생길 때 올바른 판단을 하기 어렵다는 점, 그런 것들을 다시 한번 느꼈죠.

물론 짝 프로그래밍을 전파하려는 제 시도는 절반의 성공으로 끝났기에 아쉽지만, 훗날 그 팀원의 성향이 조금 변하거나 다양한 방법을 선택해야 하는 시점에, 저와 함께 했던 짝 프로그래밍의 추억이 올바른 선택을 하는 데 도움을 준다면, 기쁘겠습니다.


3 Responses to “느끼게 하라, 그리고 자유롭게 하라”

  1. dlfma Says:

    에너지는 높은 곳에서 낮은 곳으로 흐르기 마련이라죠. 확실히 순준이 비슷한 사람들이 함께 업무를 하다보면 여러가지 배울점도 많아지고 장점이 많긴 합니다. 하지만 장시간 계속될 경우 이런 신선한 자극은 점점 무뎌지고 서로가 상대방에게 짐이 되어 비효율적으로 흐르는 경우가 많더군요. 당면 과제를 달성하는 데 최소한의 에너지만을 사용하려는 것, 극히 자연스러운 현상이더군요.

  2. Hani Says:

    dlfma님.
    말씀하신 것들을 나쁜 게 말하면 매너리즘이고,
    좋게 말하면 최적화죠. :)
    자신이 그런 상황이라는 걸 깨달을 수 있는
    눈이 필요한데 말입니다.

  3. 짝 프로그래밍? « All That Codes Says:

    […] Talk about Software with hani : 느끼게 하라, 그리고 자유롭게 하라 (http://www.talk-with-hani.com/archives/1044) […]

Leave a Reply

가끔 스팸차단기에 의해 코멘트(트랙백)가 막히나, 하루에 한번씩 정상처리 해드립니다.