01 계 - 전쟁 전 헤아려야 할 다섯 가지
그러므로 전쟁이란 다섯 가지에 따라 경영되어야 하고, 일곱 가지 항목을 비교해 그 정황을 탐색해야 한다. 첫째를 도라 하고, 둘째를 천이라고 하며, 셋째를 지라 하고, 넷째를 장이라고 하며, 다섯째를 법이라고 한다.
도란 백성이 윗사람과 뜻을 함께하는 것으로, 군주를 따라 죽을 수도 있고 살 수도 있는 것을 말한다. 그래서 백성은 위험을 두려워하지 않는다. 천이란 음양, 추위와 더위, 사계절의 변화를 가리킨다. 지란 멀고 가까움, 험준함과 평탄함, 넓음과 좁음, 살 곳과 죽을 곳을 가리킨다. 장이란 지혜, 믿음, 어짊, 용기, 엄격함을 가리킨다. 법이란 군대 편제, 조정의 벼슬 체계와 식량의 수송로, 주력부대의 보급 물자 운용을 가리킨다. 이 다섯 가지는 장수된 자가 반드시 들어야 하는 것으로, 이것을 아는 자는 승리하지만 알지 못하는 자는 승리할 수 없다.
장이란 지혜, 믿음, 어짊, 용기, 엄격함을 가리킨다.
직원들이 설득되어야 일이 순탄하며, 설득하기 위해서는 역량이 있어야 합니다.
리더는 팀원들이 따르게 만들어야 합니다. 팀원에게 강압적으로 지시하고 화를 내면서 따르게 하는 방법도 때때로 필요할 때가 있지만, 기본적으로 팀원들이 "따를만한 사람이다"라는 생각을 들게 만드는 것이 첫 번째입니다.
플랜트 업계 자체가 보수적이며 계급 체계가 강하기 때문에 설득하는 리더를 찾아보기 어렵습니다. 그나마 많은 경험자들에 의해 굴러가는 프로젝트의 경우 하던 대로 하면 되기 때문에 어떻게든 작업이 진행되지만, 혁신적인 업무를 진행할 때 문제가 드러납니다. 혁신을 이루기 위해서는 진정한 리더십이 필요하기 때문입니다.
회사 정책으로 거금을 들여 시스템 개발을 시작하게 되었습니다. 플랜트 업계는 시스템이 없어서 단순 반복 작업을 하는 경우가 많기 때문에 제대로 개발이 되면 큰 혁신을 기대할 수 있었습니다. 오랜 기간 큰돈을 들여 시스템이 개발되었지만 결과적으로 크게 실패를 했다고 평가할 수 있습니다.
실패에는 여러 가지 요인이 있지만 몇 가지로 요약할 수 있습니다. 우선 해당 개발 부서의 장이 개발에 대해 전혀 무지하고 직급만 높은 사람이었습니다. 회사에서 큰돈을 들여 진행하는 중요한 과제이기에 일단 높은 사람을 앉혀 놓은 것입니다. 게다가 아래에 있는 각 부서의 리더 역시 개발에 무지한 상태에서 업무를 받게 되었습니다. 그 아래 실무자 역시 프로젝트를 하다가 불려 온 IT에 무지한 직원이었으며, 그 직원들이 IT 개발자와 컨택을 하면서 개발하는 구조가 되었습니다. 플랜트 쪽 지식만 가지고 있는 인원들이 개발의 개념을 전혀 이해 못한 채 개발 부서에 요구만 해왔고, 개발 부서는 당장 요구 처리에만 급급하다 보니 누더기 같은 작품이 나오게 되었습니다. 플랜트 업의 Data는 생각보다 복잡하기 때문에 이런 통합 개발 작업을 하기 위해서는 많은 사람들이 프로젝트 전체 사이클에 대한 이해가 있어야 합니다. 하지만 개발에 관여한 누구도 개발 자체의 이해도 가지고 있지 않았으며, 프로젝트 개념에 대한 것도 자신의 분야만 알 뿐 전체를 알지 못하였습니다. 이런 무지의 상황에서 개개인의 능력이 아무리 뛰어나도 엉망인 완성품이 나오는 것은 당연합니다.
게다가 이런 상황을 알면서도 어떤 리더도 용기 있게 나서지를 못하는 분위기도 문제였습니다. 불가능한 지시를 받았을 때 해당 분야를 완전히 이해한다면 논리적으로 불가능한 이유와 대안을 제시할 수 있지만, 리더 역시 이해도가 낮기 때문에 윗선이 하는 잘못된 지시도 그대로 받아 수행하였습니다. 그러다 보니 실제 작업보다도 보고서에 공을 더 들이는 분위기가 되었습니다. 당시 개발팀은 보고서 하나만큼은 기가 막히게 꾸민다는 평가를 받았는데, 안 되는 상황을 잘 되는 것처럼 꾸미고 책임 회피를 하는 바람에 모두 완성되었다고 보고했지만 완성된 것이 하나도 없는 상태가 되어버렸습니다.
팀원이 따르는 리더가 되기 위해서는 우선 해당 분야를 알아야 합니다. 시스템 개발 실패의 가장 큰 요인은 누구도 시스템을 알지 못했고, 누구도 이 업의 연계 구조를 모두 이해하지 못하였기 때문입니다. 본인이 모르는 분야에 리더가 되었다면 정말 열심히 내용을 파악하여야 합니다. 본인이 직접 일을 하지 않더라도 상당히 구체적으로 알아야 제대로 통제가 가능합니다. 빌 게이츠와의 일화는 좋은 인사이트를 줍니다.
전직 MS 직원의 빌 게이츠와의 일화
번역 출처 : http://eggry.egloos.com/m/3762248
이 이야기는 전 MS 직원이었던 조엘 스폴스키가 빌 게이츠가 완전히 은퇴하던 2008년 빌 게이츠에 대한 자신의 기억을 쓴 것이다.
1991년 대학을 졸업한 뒤 나는 MS의 엑셀 팀에서 일하게 되었다. 내 직책은 프로그램 매니저였다. 내가 할 일은 새로운 프로그래밍 시스템을 만들어서 유저들이 엑셀을 자동화할 수 있게 하는 것이었다. 나는 이 기능에 대한 세부사항을 수백 페이지 분량의 문서로 작성하였다.
그 시절 MS에서는 우리가 BillG 리뷰라고 부르는 것이 행해지고 있었는데, 이는 빌 게이츠 스스로 주요 신기능에 대해 이것저것 검토해보는 것이었다. 그 시절 빌 게이츠는 이미 유명인이었고 세계에서 가장 부자인 사람으로 불리고 있었다. 내 BillG 리뷰 전날 나는 그에게 내 문서 사본을 보내라는 지시를 받았다. 그걸 인쇄하는데 프린터 용지함 하나 분량이 다 소모됐다.
일단 문서를 인쇄해서 보낸 뒤 나는 여전히 손볼 필요가 있는 수많은 디테일 중 하나를 꼽기로 했다. 그것은 엑셀의 내부 날짜 및 시간 함수가 베이직의 것과 호환되는지 하는 것이었다. 우리가 베이직을 엑셀의 프로그래밍 언어로 쓰기로 했기 때문이다.
다음날-1992년 6월 30일- 우리는 회의실에 모였다. 그 시절 MS는 지금보다 훨씬 덜 관료적이었다. 오늘날 11 혹은 12 계층이나 되는 관리구조 대신 나는 마이크 콘테에게 보고했는데, 그는 크리스 그레이엄에게 보고했고, 그는 피트 히긴스에게, 그리고 마이크 메이플을 거쳐 빌에게 올라갔다. 하부부터 최상위까지 6층 밖에 없었다. 우리는 그때 8 계층의 관리구조를 가진 제너럴 모터스 같은 회사를 조롱하곤 했다.
그러니 이 일에 관여된 모든 책임자들이 그 방에 있었던 것이다. 거의 사촌지간이나 진배없는 사이였다. 물론 우리 팀에서도 한 명 왔다. 그의 역할은 빌이 얼마나 Fuck을 많이 말하는지 세는 것이었다. F 카운터가 적을수록 더 잘했다는 의미이다.
빌이 들어왔다. 나는 그가 두 다리, 두 팔, 머리 하나를 갖고 있다는 게 참 신기하다고 생각했다. 거의 보통 인류와 똑같이 생겼던 것이다. 그리고 그가 내 문서를 손에 들고 있었다.
그가 내 문서를 손에 들고 있다고!
그는 내가 모르는 중역 한 명과 내가 이해할 수 없는 농담을 주고받았다. 몇 명이 웃었다. 그리고 빌이 나에게 돌아섰다. 나는 문서 여백에 코멘트들이 적혀있다는 걸 눈치챘다.
그가 첫 페이지부터 읽었어!
읽은 게 다가 아니라 여백에다가 필기까지 해놨던 것이다. 우리가 겨우 24시간 전에 보냈음을 생각하면 그가 전날 밤에나 봤을 게 분명하다.
그가 질문을 시작했고 나는 대답했다. 처음엔 상당히 쉬운 질문부터 시작했지만, 그게 어떤 것이었는진 기억나지 않는다. 그가 페이지를 휙휙 넘기면서 질문을 쏟아냈기 때문이다.
그가 내 문서를 넘겨보고 있어!(진정해! 초딩이야?) 그리고 모든 여백에 노트가 적혀있잖아! 모든 페이지에! 저걸 다 읽었단 말야?!
대화가 진행되면서 빌의 질문은 점점 어려워지고 디테일해졌다. 그리고 약간 랜덤성도 있는 것 같았다. 하지만 나는 신경 쓰지 않았다. 지금까지는 나는 빌을 친구 같은 존재라고 생각했다. 내 문서를 읽어준 좋은 사람 말이다. 내 머릿속에선 내가 어떻게 그의 질문에 그렇게 빨리 대답할 수 있는지 생각하고 있었다.
마지막으로 결정적인 질문이 왔다. "그런데 당신들" 빌이 말했다. "이 모든 걸 어떻게 쓰는지 모두 아는 사람 있나? 가령, 그 많은 날짜와 시간 함수들 말이야. 엑셀엔 많은 날짜/시간 함수가 있지. 베이직 기능에서도 같은 함수가 들어가나? 완전히 똑같이 작동하고?"
이것이 바로 내가 어제 하루를 할애하면서 조사했던 그 질문이었다. 그리고 내가 알아낸 것은 거기 모순이 있다는 것이었다. 엑셀과 베이직 모두 각 날짜는 정해진 숫자 코드가 있다. 1992년 어떤 날을 살펴봐도 양쪽은 동일했다. 하지만 19세기로 날짜를 돌려보면 엑셀과 베이직은 한자리 차이가 나는 것이었다. 어?
나를 도와줄 수 있을 것 같았던 사람은 엑셀의 오랜 프로그래머였던 에드 프라이스였다. 그는 물고기가 헤엄치는 스크린세이버를 만든 사람으로도 유명했다. 나는 에드와 거의 만난 적이 없었지만 금요일 오후 언제나 그가 내 사무실 밖 복도에 있는 미니어처 골프를 하는 걸 봐왔다.
"1900년 2월 28일로 가봐." 그가 말했다.
그 날짜의 엑셀 코드는 59였다.
"이제 3월 1일로"
숫자는 61이었다.
"60은 어디로 갔지?" 에드가 물었다.
"2월 29일이야!" 나는 자신 있게 말했다. "1900년은 윤년이었어!"
"1900년은 윤년이 아냐." 에드는 그렇게 답한 뒤 내가 이 문제에 대해 좀 더 생각하게 했다. 에드의 조언에 따라 내가 알아낸 것은 로터스의 프로그래머들이 그 날짜가 수학적 문제를 발생시키기 때문에 1900년을 무시하기로 했다는 것이었다. 그들은 아무도 현재보다 90년이나 전의 날짜에서 발생하는 문제에 신경 쓰지 않을 것이라고 생각했던 것이다. 그리고 엑셀을 만든 사람들 또한 그러했고 똑같은 버그를 엑셀에서도 발생시킨 것이었다. 하지만 베이직을 만든 사람들은 같은 문제에 봉착했을 때 내부 캘린더 날짜를 하루 당김으로써 해결하려고 했다. 그렇게 베이직은 제대로 된 날짜 시스템을 갖게 되었지만 다른 프로그램들과 문제를 일으키지도 않았다. 베이직이 하루 먼저 날짜를 세기 때문에 1900년 3월 1일의 베이직 내부 날짜 또한 61이었던 것이다. 그리고 여기서부터는 엑셀과 완전히 일치되는 것이다.
그러니까 둘의 시간과 날짜 함수가 호환된다고 해야 하는 것인가?
"그렇습니다." 빌에게 대답했다. "날짜는 완전히 동일합니다. 1900년 1월과 2월만 제외하고요."
침묵이 흘렀다. F 카운터와 내 상관은 놀란듯한 눈빛을 교환했다. 어떻게 그런 걸 알고 있지? 하는 눈빛이었다.
"OK. 좋아, 잘했네." 빌이 말했다. 그는 그의 노트가 적인 내 문서 사본을 들어 올렸다. 잠깐만!! 그거 저 주고 가요!... 그리고 나가버렸다.
"4번이야." F 카운터가 발표됐다. 다른 누군가가 말했다. "우와, 이건 내가 본 것 중 가장 적은 횟수야. 빌이 나이 먹으면서 부드러워진 건가?" 당시 그는 36세였다. 이후 나는 이 상황에 대한 정확한 해석을 얻을 수 있었다. "빌은 사실 너의 문서 같은 걸 보고 싶어 하는 게 아냐." 동료가 말했다. "그는 단지 자네가 모든 상황을 통제하고 있는지 알고 싶은 거지. 그의 방법은 네가 더 이상 모른다고 시인할 때까지 점점 어려운 질문을 하는 거야. 그리고 네가 미진하다는 걸 알고서야 그만두지. 아무도 그의 질문을 마지막까지 답했을 때 어떤 일이 일어날지 몰랐어. 그런 일은 일어난 적이 없거든."
내가 그걸 해냈단 말인가? 빌 게이츠는 놀랍도록 기술적인 사람이었고, 그는 MS의 소프트웨어에 대해 그걸 직접 만드는 사람보다 더 자세히 알고 있었다. 그는 수많은 변수들과 COM 오브젝트, IDispatch를 이해하고 있었고 왜 Automation이 vtables와 다른 지도 알았다. 그는 시간/날짜 함수에 대해 신경 쓰고 있었던 것이다. 프로그램을 만드는 사람들을 믿었다면 그렇게 간섭하지 않았겠지만, 빌 본인도 프로그래머이기 때문에 그에게 한순간이라도 거짓말을 한다는 건 불가능한 일이다. 그는 진정한, 진짜 프로그래머이기 때문이다.
프로그래머가 아닌 사람들이 소프트웨어 회사를 경영하려 하는 것은 서핑할 줄 모르는 사람이 서핑하려고 하는 것과 같다. 아무리 그가 해변가에 훌륭한 서핑 강사를 두고 있다고 해도 그는 계속 보드에서 바다로 빠질 것이다. MBA 문화는 사람들이 자기가 이해하지 못하는 조직을 경영할 수 있다고 믿게 만든다. 하지만 많은 경우 그렇지 못하다.
물론 시간이 흐르면서 MS는 거대해졌고 빌은 너무 지나치게 나아갔다. MS의 전략은 미국 정부와 충돌하기도 했다. 스티브 발머-그는 프로그래머가 아니다-가 CEO 직을 넘겨받았을 때, 이론상으로 이 덕분에 빌이 자기가 잘하는 것(프로그래머를 관리하는 것)에 더 집중할 수 있을 것 같았다. 하지만 그것조차 11 계층이나 되는 관리구조에서 오는 문제를 고칠 수는 없었다. 끝없는 회의와 뭘 만들든 간에 완고하게 이래야 한다고 주장하는 것들 말이다. 무료 웹브라우저 하나를 출시하기 위해 얼마나 많은 R&D 비용과 법무비용이 들었으며, 명성의 하락을 겪어야 했을까?
세상은 움직이는 법이고, 이달 빌은 공식적으로 그가 창립한 회사의 풀타임 직에서 퇴직했다. 그가 여전히 회장이긴 하지만 말이다. 내 옛날 부서도 바뀌었다. '엑셀 베이직'은 이제 '마이크로소프트 엑셀을 위한 마이크로소프트 비주얼 베이직 응용' 부서로 바뀌어서 수많은 TM과 R이 붙게 되었다. 사실 TM과 R을 어디 붙여야 되는지도 잘 모르겠다. 나는 1994년 회사를 그만뒀다. 이제 나는 내 회사를 꾸리면서 빌과 같은 식으로 리뷰를 하고 있다. 물론 절대 빌 만큼 잘하지는 못 하지만 말이다.
그리고 나는 빌이 나를 완전히 잊었을 거라 생각했다. 군중 속의 한 명에 불과하게 말이다. 그가 월스트리트 저널과 한 인터뷰를 보기 전까진 말이다. 그는 거의 지나가는 듯한 말투로, 어떤 훌륭한 엑셀 프로그램 매니저의 후임자를 찾는 게 얼마나 어려웠는지 말했다.
그게 나를 얘기하는 걸까? 에이 설마, 다른 사람일 거야.
빌 게이츠가 회장으로 있을 당시, MS는 세계 최고의 회사였고, 유능한 많은 직원들이 빌 게이츠라는 스타 경영자를 존경하며 열심히 따른 것은 그가 그만큼 많은 지식과 열정을 가지고 있었기 때문일 것입니다. 그의 입에서 나오는 F의 개수에서 알 수 있듯이 그는 직원에게 매우 엄격했지만, 해당 분야의 모든 것을 파악하고 있기에 직원들은 그가 허튼소리를 한다고 생각하지 않습니다. 틀린 부분을 명확히 짚어내는 그의 능력에 감탄하며 욕을 먹어도 진심으로 존경하며 따르게 되는 것입니다.
상반되는 이야기로 생각할 수도 있지만 리더는 자신의 직원을 믿어야 합니다. 리더가 본인의 지식이 많다고 생각하면 사사건건 간섭을 하며 직원을 믿지 못하게 됩니다. 반대로 자신이 잘 모른다고 생각하면 덮어놓고 맡기고 믿는 척을 하기도 하죠. 둘 다 좋지 않은 리더의 태도입니다.
능력이 있는 리더일수록 자신의 몸을 복제한 직원이 있었으면 좋겠다는 생각을 할 것입니다. 저 역시 직장에서 처음 부사수를 받았을 때 매우 허둥지둥했습니다. 제가 하면 다 할 수 있는 것을 가르치며 시행착오를 겪으며 해야 하기에, "그냥 내가 다 해버릴까"라는 생각이 들기도 했지만, 누가 봐도 바람직한 태도가 아니었고, 이때부터 좋은 리더에 대한 고민이 시작되었습니다.
좋은 리더라면 업무를 줄 때 명확하게 목적을 설명하고 중간 점검을 하기 전까지는 믿고 맡겨야 합니다. 그리고 성과물이 본인의 생각과 다르더라도 어쩌면 늘 해오던 방식보다 더 좋을 수도 있다는 자세로 검토를 하고, 하지만 많은 경험상 좋지 않은 부분에 대해서는 이유를 설명하면서 수정을 요구해야 합니다. 때로는 질책이 있을 수도 있고, 많은 코멘트를 할 수도 있겠지만 기본적으로 이 일의 효용성을 명확히 이해시키고 믿고 있다는 생각을 들게 만든다면 성공적으로 이끌 수 있을 것입니다.
이렇게 말하면 마치 모든 포커스를 팀원에게 두고 끌려가야 한다는 것처럼 들릴 수도 있을 것 같습니다. 하지만 앞서 빌 게이츠 역시 보고할 때 F를 달고 다녔다는 것에서 알 수 있듯이 일에 있어서는 엄격함을 유지해야 합니다. 본인도 잘 모르면서 두리뭉실하게 지시를 하고 무조건 질책을 하는 태도가 문제이지, 명확한 근거로 질책과 대안을 주는 것은 꼭 필요하며, 팀원의 사기를 저하시키지 않습니다.
단지 질책 시에 상관없는 내용까지 끌어오는 것은 지양해야 합니다. 본인이 "잘해주니 기어오르네", "풀어주니 말이 말 같지 않나" 같은 말을 자주 하는 상사라면 평소에 직원들과 친해지기는 포기하는 것이 좋습니다. 질책은 명확하게 해당 일에 대해서만 짧게 하고 질책의 이유를 명확하게 설명해야 합니다.
좋은 리더십을 발휘하였음에도 따라오지 못하는 직원이 있기 마련입니다. 의지가 있지만 역량이 부족한 직원은 업무를 조정하여 역량을 키울 수 있는 방향으로 유도하여야 합니다. 많은 인원이 톱니바퀴처럼 맞물려 돌아가는 업무에 구멍이 생기면 다른 많은 유능한 사람들에게도 큰 피해가 가기 마련이기 때문에, 부족한 역량을 가진 직원을 의욕만을 보고 많은 업무를 시켜서 생기는 여파는 상당히 다양하게 오기 마련입니다. 회사는 학교가 아니기 때문에 교육을 시킬 수 있는 한계가 있으며, 업무가 잘 돌아가는 것이 언제나 첫 번째 가치가 될 수밖에 없습니다.
따라올 의지가 없고, 관성에 젖어있는 직원은 앞의 경우보다 훨씬 더 안 좋은 케이스이며, 때때로 버리는 것이 최선이 될 수도 있습니다. 특히 사내 정치에만 관심이 있고 업무를 하지 않고 아부만 잘하는 직원은 가장 경계해야 할 대상입니다. 이런 직원을 데려갈 수밖에 없는 상황이라면 업무를 열심히 하는 직원의 사기를 떨어뜨리지 않도록 만들어야 하며, 절대로 아부에 넘어가면 안 됩니다.