[12장 보충] 신뢰 쌓기: 나 - 전달법

최근 새로 출간 예정인 신간에 실린 추천 서문을 미리 받아봤습니다. 소프트웨어 공학 부문에서 너무나도 유명한 톰 드마르코가 쓴 이 추천 서문을 읽다가 갑자기 저는 무릎을 탁 치고 말았습니다. 왜나하면 저도 비록 길지는 않지만 인생을 살아오면서 이런 생각을 여러 차례 해봤기 때문입니다.

Our earliest experience of management is in the family where Dad is boss, she explained, so of course we tend to think of a manager as someone rather Dad-like.

예, 가족 내부에서 겪었던 다양한 경험으로 인해 '아빠'가 '보스'이고 프로젝트 관리자도 '아빠'와 유사하도록 우리는 머리 속 틀이 맞춰져 있는겁니다. 하지만 여기에는 절대적인 독재권력이라는 심각한 부작용이 있습니다. 상황에 맞던 맞지 않던 보스, 즉 아빠가 여러분에게 내리는 명령은 절대적이고 옳습니다. 여러분은 반론할 여지도 없이 시키는 말을 따라야 합니다.

설상가상으로 부모가 애들을 야단치거나 명령을 내릴 때 사용하는 방법은 상황을 더욱 악화시킵니다. '너는 못난놈이니 매일 이 모양이지'라는 야단은 정도의 차이가 있을지 모르겠지만 회사에서 쉽게 들을 수 있습니다. 이런 어려운 상황을 어떻게 극복해야 할까요? 오늘은 나-전달법(I-Message)이라는 강력한 의사 소통 도구를 통해 신뢰를 쌓는 방법을 알아보기로 합시다.

나-전달법을 언제 사용할까요? 주로 부모(즉, 프로젝트 관리자)에게 문제가 있는 경우 사용합니다. 프로젝트 관리자가 팀원의 행동을 수용할 수 없을 때 분노, 욕구불만과 같은 감정이 들게 마련입니다. 이 때 팀원의 행동을 수정하려고 하는 대다수 프로젝트 관리자는 팀원에게 해결 메시지(예: 이렇게 해, 저렇게 해, 이렇게 하지마, 저렇게 하지마)나 무시하는 메시지(예: 당신이 하는 일이 늘 그렇지 뭐)를 보내게 됩니다. 하지만 이는 무척 비효과적인 의사소통 기법으로 사람 사이에 신뢰를 망가뜨리는 가장 강력한 단일 요인이라고 보면 틀림없습니다.

이런 문제점을 해결하기 위해 나온 기법이 바로 '나-전달법'입니다. 즉, 기존에 '당신' 아니면 '너'로 시작하는 메시지를 '나'로 시작하는 메시지로 바꾸는 겁니다. '나'로 시작하면 팀원의 행동에 대 해 시시콜콜 간섭하지 않고서도 효과적으로 자신의 생각이나 감정을 전달할 수 있습니다. 이렇게 해야 사람 관계가 원만하게 이뤄지며 효과적으로 팀원의 행동을 변화시킬 수 있습니다.

'너' 전달법은 상대방을 탓하고 비난하며, 상대편에게 잘못이 있다고 전달하며 말로 공격하는 형태입니다. 하지만 '나' 전달법은 단순히 상대편의 행동에 대해 자신의 느낌을 설명하는 형태입니다. '나' 전달법은 청자가 아니라 화자가 중심이 되며, 자신의 느낌을 말하며, 다른 사람을 탓하지 않습니다.

예를 들어, 팀원 일정이 늦어질 경우 '너는 구제불능이야'라는 너-전달법 보다는 '나는 열심히 프로젝트를 진행하려고 애를 쓰는데, 계속해서 지연되고 있으니 답답하구나'라는 나-전달을 사용해야 팀원 스스로가 행동을 바꾸려는 책임을 느끼는 동시에 '부정적'인 자신의 이미지를 탈피하게 도와줍니다.

하지만 '나' 전달법을 사용할 때는 언어적인 요소가 아니라 비언어적인 요소(어조와 표정)이 무척 중요합니다. 만일 말은 '나' 전달법이지만 표정은 '너' 전달법일 경우 역효과가 나타나버리므로 결국에는 화를 내며 전달하는 '나' 전달법은 적대감을 나타내는 '너' 전달법과 동일해져버립니다.

그러면 화를 내지 말고 계속해서 생글생글 웃어라는 말일까요? 그렇지 않습니다. 문제는 '화'가 아니라 '화'를 내서 팀원을 억누르고 통제하려는 데 있습니다. 왜 '화'를 내어야 할지 다시 한번 자기 자신에게 물어보고, 정말 '화'를 내야 하는 상황인지 파악한 다음에 '화'를 내어야 합니다. 참을 인자 세번을 써야 한다는 말입니다.

나-전달법은 말은 쉽지만 실천은 결코 쉽지 않은 방법입니다. 따라서 다음 삼 단계로 이뤄진 공식을 그냥 외우십시오.

1. 행동 서술: 당신이 ~ 하면
2. 느낌 서술: 나는 ~라고 느낀다
3. 결과 서술: 왜냐하면 .. 이기 때문이다.

자 실습을 한번 해봅시다. 핵심 모듈을 맡은 팀원이 자꾸만 지적해도 동일한 논리 버그를 계속해서 만들어낼 때 어떻게 이야기해야 할까요? 이렇게 해봅시다.

"당신이 자꾸 동일한 논리 버그를 만들어 내면, 나는 프로그램의 중요한 부분이 잘못될까봐 두렵다. 왜냐하면 당신은 프로그램에서 가장 중요한 핵심 모듈을 맡고 있기 때문이다."

프로젝트 관리자라면 반드시 자신이 중심이 되어 팀원에게 말을 하는 방법을 익히십시오. 그래야 의식 중에 무의식 중에 팀원을 힐책하지 않게 됩니다.

마지막으로 각자 풀만한 연습 문제 하나 내면서 마치겠습니다. 원시 코드 관리를 죽어라고 싫어하는 팀원이 있는데, 이미 몇 차례 원시 코드를 덮어써서 다른 팀원을 난처하게 만들었을 때 어떻게 이야기해야 할까요?

참고 문헌: 부모 교육(오영희, 엄정애 공저, 동현 출판사 1999년)

"The Art of Project Management: 마음을 움직이는 프로젝트 관리" 역자 박재호 올림 EOB

[11장 보충] 연습과 이론을 어렵게 만드십시오

'연습을 실전처럼, 실전을 연습처럼'이라는 말이 있습니다. 프로젝트와 관련해서도 마찬가지입니다. 항상 프로젝트 상황과 도전 연습에 초점을 맞춰야 힘든 문제가 발생했을 경우에 이에 대응할 수 있게 됩니다. 오늘은 프로젝트 진행 연습을 위한 시물레이션과 전쟁 게임에 대한 내용을 알아보도록 하겠습니다.

에드워드 요돈이 쓴 "Death March"(2nd Ed.)를 읽다보면 가장 마지막 11장에 시물레이터와 전쟁 게임에 대한 내용이 나옵니다. 요돈은 '죽음의 행군'처럼 되어버린 프로젝트를 진행하면서 '경험'을 어떻게 쌓고 스트레스와 긴장과 기대하지 못했던 위기를 어떻게 다룰지 '연습'을 하는 방법이 없는지 자문합니다. 일정과 비용이 넘어가고 프로그래머가 나가 떨어지는 최악의 상황 때문에 실제로 고통을 받지 않고서 어떻게 프로젝트를 차례로 '망가뜨릴'지 프로젝트 관리자에게 가상적인 경험을 주는 방법은 없을까요?

현명하게도 요돈은 원자력 발전소 운영 요원이나 비행기 조종사가 연습을 할 때 사용하는 시물레이터와 실제 실탄을 쏘고 부상당하는 위험을 줄이기 위한 전쟁 게임을 떠올립니다. 실제 위험을 감수하지 않고서도 가상적이면서 통제된 위험을 경험해보는 방법은 최적의 훈련 기법입니다. 매뉴얼과 강의만으로는 부족하며 실제로 경험을 해봐야 지식이 체화되기 때문입니다. 예를 들어, 여러분도 시물레이터로 연습을 한번도 해보지 않은 비행기 조종사가 모는 비행기에 탑승하실 용기가 있습니까? 글쎄요, 저 같으면 이런 위험한 비행기는 안타고 말겠습니다.

하지만 흥미롭게도 특정 분야에서 프로젝트 관리 경험이 전무한 프로젝트 관리자를 시물레이터나 전쟁 게임 훈련 과정을 제공하지도 않은 상황에서 실전에 투입하는 관례는 너무나 일반적이다 못해 어느 누구도 훈련 시켜야 한다는 생각조차 하지 못하고 있습니다. 실전에서 비참하게 망가지고 난 다음에 얻은 경험을 다음 프로젝트에 사용해야 하는 상황인데, 문제는 매번 상황이 바뀐다는 점입니다. 이렇게 해서야 체계적인 경험 축적이 제대로 이뤄지겠습니까? 물론 운이 아주 좋다면 계속해서 프로젝트를 성공시킬지도 모르겠지만, 대다수 관리자에게 이런 운은 따라오지 않습니다. 만일 특정 프로젝트를 수행하기 앞서 미리 시물레이터나 전쟁 게임을 치뤄서 앞으로 일어날 상황에 대해 어느 정도 파악이 되어 있다면 그만큼 프로젝트 성공 확률은 높아질 것입니다.

그렇다면 구체적으로 들어가서 어떻게 프로젝트와 관련한 시물레이션을 수행하고 전쟁 게임을 벌이도록 할 수 있을까요? 요돈은 오스트레일리아 컴퓨터 협회에서 1994년부터 연례 모임에서 진행하고 있는 전쟁 게임을 예로 듭니다. 여러 프로젝트 팀에게 동일한 "프로젝트 시나리오"(동일한 요구 사항, 동일한 시간, 동일한 자원)를 주고 고정된 시간내에서 동작하는 소프트웨어를 개발하도록 아주 잘 정의된 목표를 주는 겁니다.

이런 식으로 훈련을 할 경우 프로젝트 관리자와 팀원은 프로젝트와 관련한 다양한 측면(특히 사기, 쇠진, 초과 근무)에 대한 말못할 가정과 "정신적인 모델"를 자연스럽게 논의할 수 있습니다. 전쟁 게임 시나리오를 따라 훈련을 하면서 어떤 방식이 먹혀 들어가고 어떤 방식이 먹혀들어가지 않는지 파악을 하게 됩니다. 이런 가상적인 경험은 실제 현실에서 체험하는 경우와 비교해서 훨씬 더 저렴하다는 장점도 있습니다.

전쟁 게임을 치룰 경우 사후 분석이 가능합니다. 여러 팀이 특정 상황에서 추진한 방법을 상호 비교해보고 앞뒤로 왔다갔다하면서 연관성을 분석하는 방법을 사용할 경우 값비싼 시행착오 없이도 여러 가지 상황을 다양하게 직/간접 체험하는 효과를 올릴 수 있습니다.

뜬구름 잡는 이야기라구요? 실제로 시중에 온라인 코스도 있고, 오프라인 코스도 있고, 논문과 연구 결과도 찾아볼 수 있습니다. 더 많은 정보가 필요하시다구요? 구글에서 'management flight simulator'를 검색해보세요.

뱀다리: 나중에 제가 과거 마이크로소프트에서 근무했으며 'Dynamics of Software Development'로 유명한 짐 매카시와 관련한 이야기를 할 때 다시 한번 전쟁 게임을 언급하겠습니다.

"The Art of Project Management: 마음을 움직이는 프로젝트 관리" 역자 박재호 올림

[10장 보충] 프로세스를 거부해야 할 때

톰 드마르코가 지은 데드라인이라는 프로젝트 관리에 대한 소설을 읽다보면 CMM과 같은 프로세스 개선 공정에 대해 강하게 비판하는 구절이 여러 번 나옵니다. 누구보다도 소프트웨어 공학 부문에서 잔뼈가 굵었을텐데 자칫 잘못하면 스스로 무덤을 팔지도 모르는 이런 내용을 드 마르코가 강조한 이유는 무엇일까요? 오늘은 여기에 대해 개인적인 생각을 적어보도록 하겠습니다.

혹시 HACCP이라는 단어를 보신 적이 있습니까? '식품위해요소 중점관리기준'이라고도 불리는 이 단어는 식품의 원재료 생산에서 제조, 가공, 유통 단계를 거쳐 우리 식탁에 오르기 전까지 각 단계에서 발생할 수 있는 위해 요소를 규명하고 이를 중점적으로 관리하기 위한 위생 관리 시스템을 일컫습니다. 갑자기 아닌 밤중에 홍두깨라고 프로젝트 관리에서 음식 이야기를 꺼내냐구요? 조금만 더 가봅시다.

패스트푸드의 어두운 면을 적나나하게 그린 책인 '패스트푸드의 제국'(에릭 슐로서 지음, 김은령 옮김, 에코리브르 펴냄)를 보면 HACCP이 떠오르게 된 동기를 소개합니다. 햄버거에 이콜리 균이 감염된 음식을 먹고 아이들이 사망하는 바람에 큰 사회적인 문제를 일으킨 이후에 도축장과 가공 공장이 의무적으로 HACCP을 따르도록 미 행정부에서 규정을 만들어 내었습니다. 쉽게 말해 음식물을 안전하게 가공하고 유통하는 새로운 프로세스를 도입한 셈입니다. 하지만 유감스럽게도 현실은 그렇지 못했습니다. 연방 조사관과 육류 검사관은 고개를 가로저었고, 현장에서 직접 뛰고 있는 품질 관리자조차도 HACCP은 서류상의 이야기일 뿐 실질적으로는 별 도움이 안된다는 맘 속에 품고 있던 이야기를 꺼내놓았습니다. HACCP는 이름만 거창하지 실제로는 도축장과 가공 공장이 자발적으로 만든 프로그램을 따르도록 면죄부를 주는 결과를 초래했고, 고양이에게 생선을 맡긴 꼴이 되고 말았습니다. 한국에서도 단체 급식 과정에서 식중독 사고가 생겨서 큰 대기업이 곤란을 겪기도 했었는데, 과연 대기업 내부적으로 체계적인 프로세스가 없어서 이런 일이 생겼을까요?

HACCP은 거리가 너무 먼가요? 그렇다면 조금 더 소프트웨어 쪽 이야기로 넘어옵시다. ISO 900x 시리즈 인증을 받아본 경험이 있는 분이라면 누구나 느끼겠지만, 이론과 실제는 다릅니다. ISO 900x 시리즈도 실제 생산 공정에는 전혀 무관하게 서류 작업만 제대로 하면 얼마든지 획득할 수 있습니다. HACCP과 마찬가지로 ISO 900x도 빈틈이 너무나도 많은 규약인 셈입니다. 프로세스를 제대로 따라서 작업을 하면 되지 않겠느냐구요? 현장에 가서 이런 틀에 박힌 이야기를 하면 바로 쫓겨납니다. 시간과 인력을 충분히 확보하지 않은 상태에서 프로세스에 따라 작업하라는 이야기는 매일 철야하고 휴일 근무하라는 이야기와 똑같습니다.

좋습니다. 여기까지는 강 건너 불 구경이었습니다. 그렇다면 실제 소프트웨어를 다루는 CMMI와 같은 프로세스 개선 프로그램은 어떨까요? 역시 HACCP나 ISO 900x와 같은 운명에 처해있습니다. 심지어 CMM 5등급을 받은 놀라운 회사도 100% 소프트웨어 오류를 막을 수 없다는 연구 결과가 나와 있을 정도이니 할 말이 없습니다. 저도 미국 현지 CMMI 공인 강사가 진행하는 CMMI GAP Analysis 직전 단계까지 다루는 워크숍에 참석해보았지만, 최전선에서 야근하는 소프트웨어 개발자에게 불을 밝혀주는 빛나는 등대는 온데간데 없고 해변 가득 자욱하게 내려앉은 짙은 안개만 보다가 돌아왔습니다. 관리자를 위한 관리 기법은 관리자만 사용하면 됩니다. 이를 개발자에게도 강제하려다 보니 온갖 부작용이 생기게 됩니다.

좋습니다. 개발자가 상부에서 낙하산을 타고 내려온 프로세스를 거부할 때가 언제나구요? 특별한 추가 인력이나 시간 확보 약속이 없이 막무가내로 진행하는 경우와 소프트웨어 개발 생산성이 장기적으로도 떨어지고 단기적으로도 떨어지리라고 예측했을 경우입니다. 전사적으로 특정 프로세스를 도입하자는 이야기가 나올 경우 실제 생산성이 올라가는지를 검증하는 파일럿 프로젝트를 먼저 진행해보고 이 결과에 따르겠노라고 이야기하십시오. 별 외부 압력이 없는 파일럿 프로젝트조차도 특정 프로세스를 야전교범대로 그대로 적용해서 성공시키기란 하늘에 별따기입니다. 경험이 풍부한 개발자라면 이런 파일럿 프로젝트에 참가할 여력이 없을테고(제 말이 틀렸나요? 설령 파일롯 프로젝트에 투입된다고 할지라도 며칠 후 발등에 불이 떨어져서 유지 보수나 신규 프로젝트를 빌미로 얌전히 원상 복귀 될 겁니다. 제가 맛있는 맥주 내기 걸 수 있어요!), 병아리 개발자나 일부 의욕이 앞서는 개발자만 투입될테니 말입니다. 좋은 개발자가 없이 프로젝트가 성공할 수 있나요?

결국 오늘의 핵심은 _프로세스_가 아니라 _사람_이네요. 프로세스에 알듯말듯한 반감을 느끼신 분이라면 속이 좀 시원해 지셨나요?

"The Art of Project Management: 마음을 움직이는 프로젝트 관리" 역자 박재호 올림

[9장 보충] 새티어 변화 모델

그 동안 다른 책 번역 작업으로 인해 몇 주 쉬었습니다. 추석을 앞두고 맘을 가다듬는 의미에서 오늘은 9장 보충 글로 세티어 모델에 대해 한번 정래해 보았습니다. 실제로 구글 검색 엔진을 타고 '새티어'라는 키워드를 입력한 많은 분들께서 제 블로그를 방문했음에도 불구하고 딱히 도움을 주지 못했던 점이 마음에 걸렸는데, 오늘 풀어버리기로 하겠습니다.

새티어 변화 모델을 가장 잘 다룬 논문은 스티브 M 스미스씨가 지은 The Satir Change Model이며, 제럴드 M. 와인버그 큰형님께서 편집한 Amplifying Your Effectiveness: Collected Essays에 실렸었습니다. 오늘은 이 논문에서 몇 가지 중요한 사항을 따와서 소개하는 방법을 택하겠습니다.

새티어 변화 모델은 사람이 느끼고 생각하고 행동하는 과정을 5 단계로 나눠서 설명하는 모델입니다. 우선 다음 그림을 한번 보시기 바랍니다.

그림이 의미하는 바는 단순합니다. 현상 유지(status quo) 단계에서 외부 자극이 가해지면 저항(resistence)이 따르고, 저항이 커짐에 따라 혼란(chaos)이 생기고, 이런 와중에서 사고에 변화가 생기면서 통합(integration) 단계로 접어들고, 최종적으로 새로운 현상 유지(new status quo) 상태로 안정화 됩니다. 이런 과정에서 개인의 작업 효율이 오르락 내리락 하게 되는 겁니다. 누구나 새로운 환경에 접하고 새로운 사물을 받아들일 때 이런 과정을 겪어서 체화한다고나 할까요?

자 그렇다면 각 단계별 특징과 대처 방안을 간략하게 정리해보도록 합시다.

1. 현상 유지 단계: 이 단계는 아주 친밀하며 고향집 같은 분위기를 연출하는 단계입니다. 사람들 사이에 안정적인 관계가 유지되며, 무엇을 어떻게 풀어야 할지 누구나 다 아는 상황입니다. 하지만 이런 상황에 평생 머물러 있으면 안되므로, 사람들에게 그룹 외부에서 개선 방향, 정보, 개념을 얻도록 독려해야 합니다.
2. 저항: 외부 자극이 들어올 경우 일부는 변화를 추구하지만, 대다수 사람은 유효성에 대해 의심하고 쟁점을 회피하고 이런 외부 자극을 도입한 사람에게 비난을 가합니다. 이런 상황에서 사람들이 열린 마음으로 거부/회피/비난을 불러일으키는 충동을 억제하도록 유도해야 합니다. 정말 여려운 상황이죠?
3. 혼란: 이 단계에서는 그룹 상태를 아무도 모르게 됩니다. 낡은 기대는 어김없이 무너지고, 낡은 반응은 더 이상 효과를 발휘하지 못하며, 낡은 행동 양식은 꺼내지조차 못합니다. 소유와 자의식이 무너져 내리며, 불안함에 떱니다. 이런 상황에서 일시적으로 팀 작업 효율이 급격하게 감소하게 됩니다. 이와 같은 변화 과정을 잘 넘기려면 사람들이 느끼는 감정과 두려움을 회복하는 안전한 환경을 만들고 지원해야 합니다. 마법을 동원해서 한번에 이런 혼란을 해결하려고 지름길을 찾지 마십시오.
4. 통합: 이 단계가 되면 외부 자극이 어떤 이익을 주는지를 보여주는 사고 전환이 이뤄집니다. 갑자기 그룹에 활기가 넘치고 새로운 관계가 이뤄지며 소유와 자의식이 되살아납니다. 연습을 통해 팀 작업 효율이 급격하게 높아지기 시작합니다. 어려움에 도전하기 위한 새로운 방법을 찾도록 꾸준히 독려하는 방법이 최고입니다.
5. 새로운 현상 유지 단계: 변화를 제대로 인식해서 받아들였기에, 그룹과 개인은 새로운 현상 유지 단계로 올라섰으며, 더 나은 팀 작업 효율을 보입니다. 슬럼프에서 완전히 벗어나서 안정적인 상태에 접어들었다고 할까요? 그룹은 건전하고 고요한 상태로 돌아왔으며, 사람들은 감정적/육체적으로 집중이 가능합니다. 사람들이 안정감을 느끼게 만들어서 변화 과정에서 무엇을 배웠는지를 다시 한번 깨닫도록 만드는 방법은 현재 뿐만 아니라 미래의 경쟁력을 높이는 초석이 될겁니다.

이와 같은 변화를 몇번 겪은 팀이나 조직은 변화에 어떻게 대응할지 조직적인 학습 능력을 확보하게 됩니다. 따라서 외부 자극이 주어지더라도 더 이상 위협을 느끼거나 불안감을 보이는 대신에 새로움에 대한 흥분과 강한 동기 부여를 느끼게 됩니다.

여러분 조직은 어떻습니까? 새로운 방법론, 프로그래밍 언어, 조직 구조가 바뀔 때 어떻게 대응했습니까? 새티어 변화 모델을 다시 한번 적용해서 과거에 잘했던 경우와 그렇지 못했던 경우를 분석해보시기 바랍니다. 그리고 부끄러워하시지 마시고 과거 경험을 다른 개발자들과 함께 공유하도록 합시다.

유난히 긴 추석 연휴입니다. 아무쪼록 건강하고 즐겁게 보내시기 바랍니다. 추석 연휴 끝나고 다시 더 좋은 글로 여러분께 돌아오겠습니다.

"The Art of Project Management: 마음을 움직이는 프로젝트 관리" 역자 박재호 올림"