쾌속 학습팀 |
 |
패러다임 전환, 죽느냐 사느냐
몇 년 전 있었던 실화다.
PHP1 를 쓰던 회사였다. 사장님이 이상한 컨퍼런스에 다녀오더니 뭘 들었는지 갑자기 전사 명령이 떨어졌다. “올해 안에 MVC 기반의 자바로 바꿔라!” 코드도 바꿔야 하고, 언어도 바꿔야 하지만, 무엇보다도 사람이 바뀌어야 하는 상황. 그 다음 해가 되었다. 어떤 팀은 자바로 잘 옮겨탔지만 몇몇 팀은 여전히 PHP를 부둥켜 안고 울고 있다. 왜 이런 차이가 생겼을까?
이런 기술적 변화의 순간은 언제나 찾아올 수 있다. 이름하여 패러다임 전환(paradigm shift). 더군다나 IT 업계는 이런 전환 주기가 특히 짧은 편이다. 고생은 개발자들이 한다. 개발자들에게 있어 학습이라는 것, 더 나아가 빠른 학습이라는 것은 늘 고민거리다.
최소 침습 심장 수술
2001년 10월, 하버드 비즈니스 리뷰에 심장 수술에 대한 논문이 한 편 실렸다. 하버드 비즈니스 리뷰는 경영 전문 잡지가 아닌가? 논문 제목은 "Speeding Up Team Learning"이다. 최소 침습 심장 수술법을 어떤 팀이 빨리 익히는가 하는 것이 주제다. 수술팀은 '팀'에 대해 논의할 때 단골 손님으로 등장한다. 공동 목표가 확실하고 결과를 객관적으로 평가하기 쉬우며, 전문성이 요구되기 때문이다. 그 논문 저자들은 수술팀에 대한 연구가 경영자들에게 많은 도움이 되리라 기대했다. IT 종사자들에게는 이 연구가 좀더 각별할 수 있는데, 수술팀이야말로 (IT 업계의 팀 이상으로) 서로 다른 분야의 다양한 전문가들이 참여하는 곳이기 때문이다. 예컨대 수술팀을 모델로 한 개발팀 조직법이 있을 정도다.
전통적인 심장 수술은 가슴을 완전히 열어 제끼고 수술을 하지만, 최소 침습법은 가능한 절개를 최소화한다. 환자 입장에서는 좋다. 회복 기간이 더 짧아진다. 하지만 의사는 괴롭다. 전혀 새로운 방법을 익혀야 하고, 수술 시간도 오래 걸린다.
실험에서는 이 수술법을 도입하려는 병원들을 조사했다. 각 병원에서 차출된 팀이 공통된 교육 훈련을 거치게 했다. 그 팀들이 수술에 익숙해짐에 따라 수술 시간 변화를 측정해 봤다. 일종의 학습 곡선을 비교한 것이다.
최소 침습 수술법이 기존 방법에 비해 워낙 혁신적인지라 의사들이 익숙해지는 것이 쉽지 않았다. 각 병원에서 최초 수술에 걸린 시간은 전통적 수술법에 비해 두세 배 길었다. 전통적 수술법이 두 시간 걸렸다면, 새 수술법은 대여섯 시간은 걸렸다는 이야기다. 물론 수술을 거듭하면서 수술 시간은 점차 줄어들었다. 하지만 놀라운 점은 이 수술 시간 감소율이 팀마다 천차만별이었다는 것이다.
학습 속도와 상관 없는 것
논문 저자들은 학습 속도와 상관 없는 것들에 먼저 놀랐다. 예를 들어, 교육 배경이나 수술 경험 등은 학습 곡선의 기울기에
영향을 주지 못했다. (참고로, 의사의 실력, 예컨대 수술 성공률과 경력년차가 통계적으로 상관성이 없다는 것은 널리 알려진
사실이다. 무작정 나이 든, 혹은 젊은 의사에게 자신의 몸을 맡기는 실수를 범하지 않으시기를!)
파란색 실선은 첼시아 병원(Chelsea Hospital)이고, 빨간색 점선은 마운틴 메디컬 센터(Mountain Medical Center)다. 최초 수술은 두 병원 모두 6시간대에 육박했다. 하지만 20번의 수술을 거친 후에 첼시아 병원은 5시간 대에 머무르고 있지만 마운틴 메디컬 센터는 3시간 대로 접근했다.
자, 이제 놀랄만한 정보를 알려드리겠다. 첼시아 병원(학습이 느린 곳)의 최소 침습 수술 도입 팀 리더는 저명한 심장 외과의였다. 또한 그 팀이 도입하려는 최소 침습 수술에 대해 이미 많은 경험이 있었다. 반면, 마운틴 메디컬 센터의 팀장은 경험이 부족한 젊은 외과의였다.
이 외에도 우리 상식의 허를 찌르는, 관련이 없는 것들은 많았다. 높은 위치의 경영진이 해당 기술을 지지, 지원하는지 여부도 기술 도입에 별 영향을 주지 못했으며, 퍼포먼스 데이타를 수집하고 분석하는 것 등의 프로젝트 심사(audit), 결과 보고(debrief, after-action report) 등도 팀의 성공과 실패에 중요한 임팩트를 주지 못했다.
그럼 도대체 무엇이 학습 속도를 결정하는가?
부하는 리더를 닮는다
지난해까지 엠파스에서 부사장을 지냈던 박태웅 님을 얼마 전 뵈었는데, 그 자리에서 공감할만한 이야기를 들었다. 부하는 리더를 닮는다는 것이다. 명시적으로 이렇게 해라 저렇게 해라 말하지 않지만, 은연 중에 문화가 형성된다. 예를 들어, 리더가 술을 잘 먹으면 직원들이 모두 술을 많이 먹게 되고, 또 리더가 공부를 좋아하는 사람이면 직원들도 공부를 열심히 하게 된다. 아, 그랬었지, 맞다, 맞아 하면서 고개를 끄덕였다.
이 논문을 읽으면서 박태웅 님의 말씀이 떠올랐다. 첼시아 병원은 저명한 심장 수술의를 치프(chief)로 임명했는데, 그 사람은 다른 병원에서 최소 침습 수술을 여러 번 집도해본 경험이 있었다. 그는 새로운 기술에 투자해야 한다고 경영진을 설득했고, 팀이 공식적 교육 훈련을 받도록 했다. 하지만 그 외과의 자신은 팀원을 선정하는 데에 큰 신경을 쓰지 않았다. 단순히 근속 연수로 팀원이 뽑혔다. 그는 첫 번째 수술 전의 예행 연습에 참여하지도 않았다. 그는 인터뷰에서 이렇게 말했다. "저를 훈련시키는 것이 문제가 아니라, 그 팀을 훈련시키는 것이 문제였죠." 첼시아 병원의 팀은 50회 이상의 수술 후에도 수술 시간이 별로 줄지 않았다.
마운틴 메디컬 센터는 별 볼 것 없는 변두리 병원이었다. 최근에 그곳은 새로운 수술에 관심이 있는(그러나 수술 경험은 없고 유명하지도 않은) 젊은 외과의를 고용했다. 그 의사는 해당 기술을 구현한다는 것은 전혀 다른 스타일의 작업 방식을 도입하는 것이라고 생각했다. 그는 인터뷰에서 "독재자가 아니라 파트너가 될 수 있는 능력이 핵심입니다"라고 하며, "팀의 다른 누군가가 제안하는 것에 기반을 두고 수술 중에도 자신이 하는 일을 바꿔야만 합니다. 이것은 수술실의 전적인 변화를 의미합니다"라고 덧붙였다. 팀원들은 만족감과 자부심이 높았다. 이 팀은 전체 연구에서 가장 빨리 학습한 두 팀 중 하나였다.
논문에서는 팀 학습 속도에 대해 리더가 끼치는 영향을 주목한다. 단순한 기술적 탁월함을 갖춘 사람보다 학습 환경을 만들 수 있는 리더여야 한다는 것이다.
학습 환경
학습이 빠른 팀은 팀원을 뽑을 때부터 달랐다. 선발 자체가 매우 협동적으로 이루어졌을 뿐 아니라(비유하자면 디자이너를 뽑는 데 개발자가 관여한다든지), 선발 기준도 달랐다. 단순한 업무 수행 능력뿐만 아니라 다른 사람과 협력을 얼마나 잘 하는가, 새롭고 애매모호한 상황을 즐길 수 있는지, 자기보다 지위가 높은 사람에게도 자신있게 의견을 제안할 수 있는지 등을 보고 뽑았다.
또한, 속도가 빠른 팀은 (특히 리더가 중심이 되어) 새로운 수술 도입을 기술적 도전이라기보다 조직적 도전으로 받아들였다. 개개인이 새로운 기술을 획득해야 한다고 보지 않고, 함께 일하는 새로운 방법을 만들어야 한다고 생각했다. 학습 속도가 느린 팀과의 인터뷰를 일부분 인용해 보자. "도대체 뭐가 새롭다는 건지 모르겠어요. 이 기술의 기본적인 요소들은 수년 전부터 존재해 왔는데 말이죠." 사람들은 새로운 기술을 비꼬고 조소하기도 했다. 냉소주의는 전염성이 강하다. 반대로, 속도가 빠른 팀의 구성원들은 자신이 팀원이 됐다는 사실 자체를 자랑스럽게 생각하고 있었고 환자들이 나아지는 모습을 본다는 생각에 흥분해 있었다.
마지막으로, 속도가 빠른 팀은 심리적으로 보호가 되었다. 뭔가 새로운 것을 제안하고 시도하는 데에 열려 있었고 실패에 대해 관대했으며 잠재적 문제를 지적하고 실수를 인정하는 데에 부담을 느끼지 않았다. 팀원들은 모두 팀 퍼포먼스를 높히기 위해 새로운 방식을 실험해 보는 걸 강조했다. 설사 새로운 방식이 효과가 없는 것으로 밝혀질지라도 말이다. 그들은 개인 단위의 실험에서 그치게 하지 않고 모두가 공유하는 실험을 했고, 무엇보다도 학습이 실행과 동시에 이루어졌다. 예를 들어 한 병원에서는 수술 중에 간호사가 외과적 문제 해결을 위해 별 고민 없이, 오랫 동안 사용되지 않고 있던 형태의 집게(iron intern이라고 알려진)를 사용하는 것을 제안했고 그 후 집게는 팀 작업 절차의 영구적인 일부가 되었다.
기술 전환에 성공한 개발팀
처음 소개했던 PHP와 자바 이야기로 돌아가자. 성공적으로 기술을 도입, 전환한 개발팀은 뭐가 달랐을까. 리더와 팀원들의 학습에 대한 태도에 근본적인 차이가 있었다. 빠른 팀은 도전 자체를 팀의 학습 능력에 대한 도전으로 받아들였다. 같이 학습해야 한다고 생각했다. 학습을 팀의 중대한 목표로 받아들였다. 리더는 기회와 가능성, 큰 변화의 흐름에 동참하는 중요성과 즐거움 등을 강조했다. 반면 속도가 느리거나 낙오된 팀은 학습을 개인의 과제로 치부했다. 학습보다 단기 퍼포먼스를 중요시했다. 리더는 낙오의 위험성을 강조하고, 팀원들의 실력이 부족하다고 불평했다. 다른 회사에 존재하는 팀 이야기가 아니다. 심지어 옆 자리에 있는 팀끼리도 이런 차이가 있었다. 해당 팀에 자바를 잘 하는 사람이 있냐 없냐는 큰 작용을 하지 못했다.
다시 현실로
현실로 돌아와 보자. 나는 팀장도 아니고, 정치적인 힘도 없다. 내가 무엇을 할 수 있을까? 팀원과 팀장에게 이 글을 권해보자(애자일 이야기 글을 팀원과 팀장에게 권해 긍정적 변화를 이끌어 내고 있는 이야기를 주변에서 듣곤 한다). 그럴 수 있는 분위기도 안 된다면?
우선 자신의 학습 환경을 만들라. 거기서부터 출발이다. 개별 기술 이상으로 일하는 방식에 대해 실험을 해보라. 그 실험이 실패한다고 좌절하지 말라(사실 실험에 실패는 없다 -- 학습할 수만 있다면). 학습과 일을 굳이 분리하지 말고 동체로 만들라. 학습과 실행은 하나다. 진정한 학습은 실행 속에서 이뤄지고, 진정한 실행은 학습을 수반한다. 우선 언제 시작할지 계획부터 짠다고? 지금 당장 안 한다면 장차 할 확률은 절반 이하로 떨어진다. 당장 30분만 투자해 보자. 새로운 일의 방식을 경험해 보자. 일단 30분만 업무 개선을 시도해 보자. 이 부분에 이르면 워드 커닝햄의 명언을 인용하지 않을 수 없다. "작지만 유용한 프로그램들을 매일 작성할 것을 추천합니다." 이 말의 힘을 느끼려면 정반대를 생각해 보라. '크고 쓸모없는 설계를 가끔 생각해 보기.'
그리고 학습 코뮌을 구축하라. 주변에서 나와 함께 학습 환경을 만들 수 있는 동지를 찾아보라. 고미숙 씨가 최근 저술한 "공부의 달인, 호모 쿵푸스"(필자는 이 책의 몇몇 부분에서 의견을 달리 하지만...)라는 책에서는 공부의 달인이 되기 위해서는 소위 작당하는 능력이 중요하다고 말한다. 작당하자.
주
1 PHP로도 MVC나 OOP가 충분히 가능하다. 다만 이 비슷한 사례가 있었다는 이야기일 뿐이다.
 [지난 developerWorks Column 보기]
|
김창준 
