위기에서는 절차보다 상황 판단이 중요하다.
절차는 일을 잘하기 위한 수단일 뿐 목적은 아니다.
마크 와트니에게 절차를 지키라고 강요했다면?
영화 ‘마션’에서 주인공 마크 와트니는 사고를 당해 화성에 혼자 남겨진다. 그리고, 그는 화성에서 살아남기 위해 로켓 연료를 태워 물을 만들고, 동료들의 배설물을 거름으로 이용해 감자 농사를 지어 식량을 마련한다. 화성의 혹한을 뚫고 탐사용 로버를 운전하기 위해서 플루토늄 발전기를 차 뒤에 놓고 히터 대신 사용하기도 하며, 화성 탈출을 위해 우주선의 무게를 줄여야 하는 상황에서 우주선의 상부를 모두 제거하고 낙하산으로 덮은 채 이륙한다. 그런데, 마크 와트니에게 아래의 절차를 지키라고 강요했다면 마크 와트니는 지구로 귀환할 수 있었을까? 그전에 암 걸려 죽었을 것이다.
1. 로켓 연료는 인체에 유해하니 절대로 기지 안에서 노출하지 말고, 정해진 용도 이외에 사용하지 말 것
2. 배설물은 예상치 못한 세균 번식을 초래할 수 있으니 절대로 기지 내에서 열지 말 것
3. 플루토늄 발전기의 방사능은 매우 치명적이니 절대로 땅에서 파내서 사용하지 말 것
4. 우주선의 상부를 제거하면 예상치 못한 충돌에 탑승자가 사망할 수도 있으니 절대로 제거하지 말 것
주인공 마크 와트니가 화성에서 탈출하기 위해서 우주선 상부를 탈거하고, 낙하산으로 덮고 있다. (마션, 2015)위기에서는 절차보다 상황 판단이 중요하다.
영화 ‘헌터킬러’에는 미국 핵잠수함이 북극해 근처에서 비밀작전을 수행하던 중에 갑작스럽게 발생한 러시아 내부 쿠데타로부터 러시아 대통령을 구하기 위해서 러시아 영해로 잠입하는 장면이 나온다. 하지만, 러시아 영해로 들어가기에는 기뢰와 탐지 장비가 가득한 협만을 지나가야 했다. 협만 통과를 포기하자니 쿠데타로 인해 미국과 러시아 간 전쟁이 발생하고, 협만 통과를 강행하자니 잠수함이 폭침당하는 상황 사이에 놓이게 된다. 고민 끝에 함장은 포로로 잡고 있던 러시아 잠수함 함장에게 상황을 설명하고 협만을 통과하는 길을 알려달라고 설득한다. 하지만, 적국 사람인 러시아인을 잠수함 상황실에 들여 경로를 지시받는 것은 중징계 사유였고, 부관을 포함한 모든 승조원은 러시아인이 상황실에 들어오는 것을 반대했다. 그런데도 러시아 함장에게 항로를 안내받는 것이 이 모든 상황을 해결할 수 있는 유일한 방법이라고 판단하였기 때문에 함장은 승조원을 설득한다. 결국, 함장은 러시아 대통령을 구하는 것은 물론 전쟁 위기도 극복한다.
'생존이 중요한가? 절차가 중요한가?'라고 부관에게 묻는 함장 (헌터킬러, 2018)직장 대부분은 효율적인 업무를 위해서 다양한 절차를 마련하고 개정하고 있다. 하지만, 때로는 그 절차가 소용없거나, 따르기 어려운 상황이 발생한다. 이때 리더는 정확한 상황 판단을 해야 하며, 이를 바탕으로 한 의사 결정을 통해 구성원이 무엇을 어떻게 언제까지 해야 할지 알려줘야 (당연히 왜 이렇게 해야 하는지도 알려줘야) 한다. 절차가 잘못된 것은 이후에 고치면 되지만, 결과가 잘못되면 되돌리기도 힘들뿐더러 함께 고생한 구성원들의 노고가 수포로 돌아가기 때문이다.
정확한 상황 판단을 위해서는 소통 능력과 유연성을 갖춰야 한다.
절차보다 상황 판단을 강조하기 위해서 최근 강조되고 있는 것이 Agile 문화다. 하지만, 구성원에게 Agile이 뭐냐고 물어보면, 대부분 ‘리더와 구성원의 소통을 강조하는 문화’라고 대답한다. 하지만, 아래 Agile의 탄생 과정을 보면 알 수 있듯이 단순히 소통만을 강조하는 것이 Agile은 아니다.
Agile은 90년대 Microsoft에서 당시 인터넷 브라우저를 독점하고 있던 Netscape를 이기기 위해 Internet Explorer를 만들면서 처음 적용한 방식이다. Microsoft는 일단 먼저 빠르게 Alpha version을 출시하여 사용자들에게 피드백을 받아 지속해서 빠르게 프로그램을 Upgrade 하였고, 매일 통합 테스트를 했다. 처음 Alpha version이 출시된 지 9개월 만에 정식 출시가 되었고, 이후 Netscape는 시장에서 점차 자취를 감췄다. 이후 기존의 폭포수 개발 모델('기획→디자인→개발→인증→적용→유지보수'의 과정을 따르며 단계별 엄격한 심사를 진행하고, 전체가 아닌 각 단계에서의 완성도를 중요하게 생각하는 모델)이 점차 사라지고 Agile 방식이 확대되었다. (출처)
즉, Agile은 소통 자체라기보다는 소통을 바탕으로 빠른 실행을 강조하는 개발 절차이다. (절차를 최소화한 개발 절차에 가깝다) 하지만, 대부분의 직장 생활에서 Agile은 제대로 뿌리를 내리지 못하고 있다. 제조업 기반의 직장에서는 더욱 그렇다. 대표적 이유는 아래와 같다.
첫 번째, 리더들과 구성원 간 소통이 원활하지 않기 때문이다. 문제가 생겼을 때, 개선점을 아는 것은 현장에서 일하는 구성원이다. 하지만, 리더는 자신의 생각과 맞지 않는다는 이유로 종종 구성원이 들고 오는 답을 실행하기 주저하거나 부정한다. 이렇게 되면 구성원들은 더는 건설적인 의견을 제안하지 않는다. 어차피 말해도 안 들어준다는 인식이 생길뿐더러 타인으로부터 인정받고 싶은 인간의 ‘자기 효율성’을 부정당하기 때문이다. 현장에서 일하는 구성원으로부터의 정보를 차단당한 리더는 결국 자신의 경험과 지식에 의존해 업무를 지시하고 의사 결정을 할 수밖에 없게 된다. 결국, 정답과 점점 멀어지는 악순환을 초래하고 만다.
두 번째, 리더들이 자신들에게 익숙한 개발 절차에서 벗어나기를 거부하기 때문이다. 리더들은 대부분 자신들이 일을 완벽하게 처리했기 때문에 성과를 인정받고 지금의 자리에 이르렀다고 생각하므로, 점점 더 일을 완벽하고 한 번에 처리하려는 성향이 강해진다. 개발 절차도 새로운 방식을 도입했다가 절차상의 문제로 일을 그르치는 상황을 피하기 위해서 자신에게 익숙한 방식을 선호한다. 결국 개발 방향이 빠르게 바뀌는 방식보다는 개발 단계별 엄격한 심사를 통해 완성도를 점검하는 폭포수 모델을 선호하는 경향이 강하다.
폭포수 모델은 문제가 생겨 개발 방향이 바뀌어야 할 때, 대처가 매우 느리다. 다시 기획 단계로 돌아가야 하기 때문이다. 그래서, 요즘 같이 주변 상황이 계속해서 바뀌어 목표가 수시로 바뀌는 상황이라면 폭포수 모델보다는 구성원의 의견(피드백)을 바탕으로 빠르게 개발 방향을 수정하는 Agile 방식이 더욱 적합한 개발 방식일 수도 있다. 하지만, Agile 방식은 리더들의 유연한 개발 방식과 소통이 전제되지 않는다면 절대로 정착될 수 없다. 리더로서 자신의 의견을 고집하기보다는 현장에 가까이 있는 구성원의 의견을 적극적으로 듣고, 상황에 맞게 수시로 개발 방향을 변경하는 것이 일의 효율을 높여 성공에 이르는 지름길이 아닐까 생각한다.
