유능한 관리자 되는「7가지 지침」

이 글에서는 필자가 회사에서 일하면서 느낀 능력 있는 관리자가 되는 항목을 정리해봤다. 일반적인 이야기로 생각하지 말고 왜 그 항목이 정해졌는가와 자신은 지금 어떤 상태인가를 되짚어보며 발전의 기회로 삼기 바란다.

필자가 근무하는 곳의 위치는 서울 남산3호 터널 앞 50M 전방에 위치해 있다. 자리에 앉아있다 창문 너머를 바라보면 붉게 물든 남산의 모습과 서울을 한눈에 바라볼 수 있는 남산타워가 바로 보인다(서울 중심가에 있으면서도 남산의 정화된 공기를 마실 수 있는 곳이므로 나름대로 괜찮은 곳에 사무실이 위치해 있다고 생각한다).

1990년대 중반에 회사에 입사하여 지금까지 순식간에 시간이 지나갔던 것 같다. 이제 책상 앞에 있는 이름 옆에는 과장이라고 하는 타이틀이 붙어 있다. 사원 시절, 과장이라고 하면 왠지 높아 보이고 감히 함부로 이야기도 할 수 없는 직책이라고 생각한 때가 있었는데, 지금의 나를 돌아보면 사원 때 느꼈던 높은 과장이라기보다는 아직 많이 성장해야 할 사원의 모습이 아닌가 생각된다.

아침에 출근하면 회사의 사람들이 엘리베이터 앞에 길게 줄을 서서 각자의 팀으로 이동하게 된다. 사람들의 인상을 살피면 과중한 스트레스 탓인지 머리가 벗겨진 사람도 보이고 인상이 밝지 않고 찌그러진 사람도 있다(평균적으로 보면 직급이 높아진 사람일수록 인상은 더 밝지 않고, 더 많이 사회에 찌들어 가고 있다는 것을 느낀다).

즐거운 마음 그리고 긍정적인 사고
대다수 사람들은 조직에 들어가게 되고 다른 사람으로부터 관리를 받다가 점차적으로 관리를 하는 영역으로 이동하게 된다. 기술 중심의 SI 업체에서 역시 회사나 단체에 속해 있는 사람은 관리자로서 일은 하지 않을 수 없는 영역이 된다. 자신이 언어 개발자이든 DBA이든 패키지 전문가이든 어느 정도 직장 경력을 가지게 되면 관리의 영역을 할 수밖에 없는 것이다. 그러나 준비 없이 시간만 흘러 관리자가 그냥 되었다가는 여러모로 곤욕을 치르거나 다른 사람을 괴롭게 하는 일을 하게 되는 경우가 종종 있게 된다.

사실 이글을 쓰는 필자도 능력 있는 관리자가 되기 위해 아직도 노력하고 있으며 계속 데이터모델 및 데이터베이스 전문가로서 엔지니어 역할도 수행하면서 직급에 맞는 관리의 영역도 수행하기 위해 노력하고 있다. 능력 있는 관리자가 되는 비법을 한마디로 정의하라고 한다면 비전을 가지고 있으며 긍정적인 사고를 가지고 즐거운 마음으로 일하면서 강한 실행력을 가지고 있으면 능력 있는 관리자가 될 것이라 확신한다.

능력 있는 관리자에 대해서는 여러 가지 경영서적에 많이 나와 있다. 학술적으로 연구하고 이론적으로 정리된 내용보다는 필자가 현재 직장 생활 속에서 느끼고 적용 가능한 부분에 대해 7가지 항목을 정리해보았다. 만약 7가지 항목에 대해 자신 있게 ‘YES’라고 답할 수 있는 사람이라면 자질이 우수한 관리자이다.

[1] 지금 내가 하고 있는 일의 목표는 분명한가?

[2] 지금 내가 하고 있는 일에 가치가 부여되고 있고 일의 성과를 추출하고 있는가?

[3] 지금 나는 다양한 성격의 사람과 대화를 잘 할 수 있는가? 지금 나는 협상의 기술이 있는가?

[4] 지금 나는 프레젠테이션 스킬이 우수한가?

[5] 지근 나는 기획문서를 쉽고 빠르게 작성할 수 있는가?

[6] 지금 나는 시간관리를 하고 있는가?

[7] 지금 나는 변화와 개선점을 파악할 수 있고 제시할 수 있는가?

앞의 7가지 항목 중 가장 중요한 세 가지에 대해 살펴보도록 하자.

지금 내가 하고 있는 일의 목표는 분명한가?
영화 ‘벤허’에서는 주인공이 노예선에 잡혀 배 밑창에서 노를 젓는 장면이 나온다. 배 밑창에 있는 노예들은 배가 어디로 가고 있는지 도무지 알 수가 없다 그저 앞에서 북소리가 들리면 열심히 노를 젓는 일만을 수행한다. 그 일의 방향은 배를 담당하는 관리자(선장)가 결정하고 그에 따라 배의 Key를 담당하는 사람은 Key를 돌리고 배의 밑창에서는 노를 젓는 것이다. 이 배에서 만약 배의 관리자가 정확한 방향을 설정하지 못하고 아래 있는 사람에게 열심히 노를 저으라고 했다면 원하는 목적지에 가지도 못하고 노를 젓는 사람은 힘만 들게 된다.

필자가 97년도에 객체지향에 관련된 파일럿 프로젝트를 회사 내에서 수행하였다. 당시에는 신기술이었던 객체지향기술을 적용하여 연구 프로젝트를 수행하여 전사적으로 지식을 확산하는 것이 목적이었다. 즉 시스템 구축이 완료 되도 업무에서는 전혀 사용하지는 않고 객체지향 개념을 적용한 시스템 구축에 관련된 노하우를 회사 내 다른 사람이 적용 가능하도록 확산하는 것이 목적이었던 것이다.

그러나 프로젝트를 진행하면서 어떻게 하면 정해진 시간 안에 업무를 분석하고 설계하여 개발을 완성하는지에 대해서만 초점을 맞추어 개발했고, 원래 계획했던 전사 확산이라고 하는 영역은 슬그머니 사라져버렸다. 프로젝트를 이끌고 있던 프로젝트 관리자가 목적을 잊어버리고 당장 눈앞에 보이는 시스템의 완성에만 목적을 두었던 것이다.

결과적으로 시스템은 완성이 되었지만 지식 확산을 위해 관련 문서를 정리하거나 다른 사람에 대한 교육계획을 수립하지 않았고 지식으로 정리를 하지 않아 전사 확산이라고 하는 목적은 달성할 수 없었다. 6개월 동안 프로젝트를 수행했던 사람들은 다른 프로젝트에 투입이 되어 버렸고 개발된 시스템은 전혀 사용되지 않는 휴지조각이 되어버렸다. 프로젝트가 정확한 목적을 잃어버렸던 것이다.

프로젝트에 참여했던 모든 팀원이 목적을 잘못 설정한 책임이 있지만 그중에서도 프로젝트 계획하고 책임지고 있었던 관리자의 책임이 가장 크다고 할 수 있었다. 한 사람당 비용을 700만원씩 계산하여 투입인원이 8명이었으므로 700만원×8명×6개월 = 3억 3600만원이 소요된 프로젝트가 개인의 기술 향상(대략 5000만원) 이외에 거의 무용지물이 되어버린 것이다. 그런데 많은 조직에서 수행하고 있는 일을 살펴보면 이와 같이 분명한 목적의식이 결여된 상태 또는 잘못 설정된 상태에서 어떤 일이 실행되고 있는 경우를 종종 본다.

관리자는 일을 진행하면서 하고 있는 일의 목적의식을 분명하게 하고 있는가를 반드시 체크해 볼 필요가 있다. 시스템 구축 프로젝트를 할 때 프로젝트 구성원은 이번에 하는 일은 업무에 있어서 어떤 부분이 개선되기 위해 적용하는지 알고 그러한 차원에서 업무분석이 정상적으로 수행되고 있는지를 집중적으로 검토해야 한다. 그 일을 담당하는 관리자는 지속적으로 목적에 대비하여 일의 방향이 올바른지 검증하고 다른 방향이면 다시 교정하는 작업을 수행해야 하는 것이다.

서버 장비, 디스크, 네트워크 장비 등을 담당하는 팀의 관리자라면 그 일에 있어서 가장 중요한 목적이 무엇이고 그 목적에 맞게 모든 일의 기능과 프로세스가 확립되어 있는지 확인해야 한다. 시스템을 구축하는 팀을 맡고 있다면 해당 시스템의 목적은 무엇인지 그 일을 왜 실행하고 있는지를 정확하게 인지한 상태에서 다른 팀원에게 계속 그 목적을 알리는 역할을 수행해야 한다.

필자는 시스템 구축을 하는 여러 프로젝트에서 개발자에게 다음과 같은 질문을 많이 한다. “당신이 개발하고 있는 이 화면은 이전 시스템과 비교했을 때 어떤 개선의 효과가 있습니까? 사용자에게 어떠한 장점을 제공하고 있습니까?”라고 질문하면 개발자는 “나는 그저 계약에 의해 업무가 분석되고 설계된 내용을 가지고 개발할 뿐입니다. 무엇이 개선되는지는 저도 잘 모르겠군요”라고 이야기하는 경우가 많이 있다.

프로젝트를 담당하고 있는 관리자나 개발의 리더는 모든 개발자가 자신이 하고 있는 일의 목적이 무엇인지를 반드시 전달하여 목적에 부합한 일을 수행할 수 있도록 지속적으로 관리할 필요가 있다.

일에 가치가 부여되고 성과를 추출하는가?
때로는 많은 사람들이 “당신은 회사에서 얼마만큼 일하고 있습니까?”라고 질문을 받으면 “나는 하루에 12시간 이상을 회사에 일하고 있습니다. 나는 며칠 째 밤을 샜습니다. 그리고 사우나에서 몸을 회복한 뒤 다시 일한 적도 많아요”라고 이야기를 한다. 그리고 일의 수행한 시간을 양을 가지고 자신의 일의 가치를 이야기하거나 성과를 이야기하는 경우가 많이 있다.

그러나 이러한 일의 수행방식에 따른 그 사람의 평가는 명백하게 잘못된 측정방식이다. 문제는 내가 얼마나 오래 책상 앞에 앉아서 일을 수행했느냐가 아니라 내가 책상에 앉아서 일을 했는데 어떤 품질로 어떤 성과를 나타냈느냐가 중요한 것이다.

팀의 관리자는 팀원들로 하여금 가시적인 성과를 도출할 수 있어야 한다. 얼마나 열심히 일했느냐에 초점을 맞출게 아니라 팀원으로부터 어떤 일이 수행되어서 목적이 달성되고 있는지 어떤 성과를 만들어내고 있는지에 초점을 맞추어야 한다.

필자는 전라북도 산골의 촌 동네에서 자라났다. 꼼꼼하기로 소문난 할아버지는 무슨 일을 하든 가장 확실하게 하곤 했다. 시골에서 농사를 지으셨기 때문에 어떤 재료에 물건을 묶어서 일을 하는 경우가 많았다. 어린 내가 밧줄로 물체를 묶어놓고 할아버지에게 다 되었다라고 말씀드리면 90% 정도는 할아버지가 묶어놓은 줄을 풀어서 다시 꼼꼼하고 단단하게 묶었던 적이 있다.

농촌에서는 가을에 벼가 누렇게 모두 익으면 벼에 달려 있는 벼 알갱이를 모두 털어내고 나머지 볏짚은 잘 묶어서 단을 쌓게 된다. 낮게는 2미터 높이에서 높게 쌓아올리면 7～8미터 정도가 된다. 잘 쌓아놓은 볏짚은 그 해 겨울 먹는 풀이 부족한 소에게 외양간 여물통에 끊여서 주기도 하고 날것으로 주기도 하면서 소의 영향을 보충하는 가장 긴요한 농사의 부산물이다. 쌀이 사람을 위한 부산물이라면 볏짚은 소의 생명을 위한 부산물인 것이다.

늦은 가을에 동네에서는 거의 모든 집이 볏짚을 쌓아올리고 겨우내 아래에 있는 볏짚부터 소에게 제공한다. 아래에서 볏짚 한단 한단 빼내다 보면 높이가 7～8미터인 볏단이 쓰러지는 경우가 자주 있다. 그런데 할아버지가 쌓아놓은 볏단은 얼마나 꼼꼼하고 단단하게 쌓아두었던지 이른 봄이 될 때까지 거의 끄떡없이 서있었다. 하단의 많은 볏짚을 끄집어내어 가분수 모양을 하고 있어도 신기하게 볏단이 쓰러지지 않았던 것이다.

많은 사람이 동일한 시간을 투자하여 볏단을 쌓아올렸지만 볏단 품질은 동네에서 제일 좋았던 셈이다. 그러다보니 여러 이웃집에서 볏단 올릴 때면 할아버지에게 부탁하는 경우가 종종 있었다.

무슨 일을 할 때 그저 누가 보지 않는다고 대충하고 누가 보고 감시하면 일하는 조직은 망할 수밖에 없다. 또는 그 조직에서는 상호간의 감시체제가 일할 수 있는 원동력(에너지)이 되므로 감시체제가 조금이라도 허점이 생기면 그 조직은 무너질 수밖에 없다. 아무리 많은 시간을 책상에 앉아 있어도 일의 효율이 떨어져 있다면 그 조직은 심각한 병에 걸린 조직이나 다름없다.

진정한 일의 측정은 성과와 품질로 가능하다. 그 사람이 얼마나 많은 일을 했느냐에 초점을 맞추지 말고 그 사람이 무슨 일을 성취했느냐 그리고 그 일이 가치고 있었고 품질은 우수한지를 보아야 할 것이다. 팀원에게 밤늦게 일하라, 휴일 날에도 출근하라, 휴가를 반납하라고 이야기하면 안 된다. 어떤 일을 언제까지 어떠한 품질로 완성하라고 요청해야 한다. 정해지지 않은 시간에 추가적인 일은 해당 팀원이 스스로 알아서 할 수 있도록 해야 한다. 그리고 지속적으로 팀원이 전문적인 기술을 가질 수 있도록 배려하여 고품질의 성과가 나올 수 있도록 하는 데 목적을 두어야 한다.

8년 전에 공통 프로그램을 개발하는 역할로 S 프로젝트를 수행하는데 일주일에 한두 번은 밤을 샜다. 그리고 토요일도 늦게까지 일하고 휴일, 명절날도 열심히 개발한 적이 있었다. 물론 그 당시 관리자는 우리가 가급적 모든 시간을 회사에 나와 열심히 개발하기를 원했다.

그러나 맑은 정신으로 일이 이루어지지 않음으로 인해 많은 버그들이 필자가 개발한 프로그램에 존재했고 이로 인해 공통 모듈을 사용하는 개발자들이 끊임없이 필자가 개발한 프로그램으로 인해 곤욕을 치르고 있었을 뿐만 아니라 일의 진척도 늦어진 경우가 있었다.

4년 전 K 프로젝트에서는 대부분 9시 이전에 퇴근을 했고 휴일 날도 거의 출근한 적이 없었다. 그러나 일을 할 수 있는 낮 시간에 맑은 정신으로 일할 수 있었고 의사결정도 용이했으며 일의 효율성이 향상되어 이전보다 훨씬 적은 변경으로 지원할 수 있었다.

이때 관리자는 가급적 일과시간 안에 집중력을 가지고 일하기를 원했고 그 사람에게 맡겨진 일에 대한 성과를 분명하게 체크하고 관리하였다. 프로젝트에는 여러 가지 요인이 있었지만 결과적으로 두 번째 프로젝트가 훨씬 안정적으로 프로젝트를 오픈했었다.

다양한 성격의 사람과 대화를 잘 할 수 있는가?
사원 시절에 국내의 공공기관을 대상으로 하는 프로젝트의 공통 컴포넌트 개발자로 일했던 적이 있다. 고객으로부터 편집이 용이한 에디터 개발을 요청받아 몇 개월 동안 개발을 수행하여 거의 완성단계에 이르렀는데 갑자기 고객이 해당 에디터에서는 제공할 수 없는 기능을 추가로 요청하였다.

필자는 그런 기능은 불가능하다고 하자 고객은 ‘그럼 이 에디터는 사용이 불가능하겠군요’라는 의견을 제시하였다. 그 이야기를 들은 필자는 수개월 동안 고생하여 만든 프로그램을 사용하지 않겠다는 고객의 이야기에 흥분하여 얼굴이 빨개지고 고객과 언성이 높아져 언쟁을 하고 있었는데 옆에 있던 관리자가 필자의 손을 잡으며 진정시켜놓고 그러면 어떻게 할 것인지에 대한 대한을 차근차근 풀어나간 적이 있었다.

만약 필자가 계속해서 언성을 높이면서 대화를 했다면 계약관계부터 프로젝트 여러 분야에서 문제가 발생할 수 있는 상황이었다. 당시 필자의 관리자가 효과적으로 대화하고 협상하여 나중에는 개발한 에디터도 효율적으로 활용할 수 있었고 프로젝트도 원만하게 진행할 수 있었다. 그 때의 일을 거울삼아 상대방과 대화할 때 필자의 상황이 분리할 때도 나름대로 감정을 억제하고 효과적인 대화를 하기 위해서 무척 애를 쓴다.

IT업의 특성상 엔지니어(개발자, DBA, 시스템관리자)로 일을 시작하는 경우가 많다보니 상대방과 대화할 때 내가 개발한 소스나 개발된 내용에 대해 지적을 받게 되면 아주 과민 반응하는 경우를 많이 본다. 이러한 습성이 관리자가 될 때까지 이어져 다른 사람과 이야기할 때 불필요하게 과민반응하거나 협상의 자질이 낮은 경우가 엔지니어에게 자주 볼 수 있는 현상이다.

그러나 관리자는 반드시 여러 성격의 다른 사람과 대화할 때 원만하게 대화할 수 있는 기술을 익혀야 한다. 또한 어떤 대화를 할 때 내가 이야기하고자 하는 내용을 가지고 상대방을 설득할 수 있는 이른바 ‘입심’을 가지고 있어야 한다. 거짓말이나 사기꾼이 되어야 한다는 의미는 절대 아니다. 알고 있는 사실을 바탕으로 이야기하면서도 상대방을 얼마든지 설득할 수 있다는 것은 직접 해보면 알게 된다.

대화의 기술도 여러 가지 전문적인 방법이 많이 있지만 핵심은 첫 번째는 상대방의 이야기를 경청하고 핵심을 파악한 다음 다시 나의 의견을 논리적으로 이야기하는 것이다. 필자는 지금도 데이터모델링과 데이터베이스에 대한 기술을 무척 좋아하고 현재도 연구 중이다. 그리고 다른 한편으로는 필자가 기술로 생각했던 IT 기술 분야 이외에 상대방과 대화하는 방법이나 협상하는 방법도 보이지 않는 고난이도의 기술임을 알고 이 부분을 개발하기 위해 노력중이다.

효율적인 대화를 이끌기 위해서는 상황에 적합한 적절한 유머 감각이 아주 중요하다. 회사에서는 여러 사람이 대화하는 자리에서는 대화의 주제가 대부분이기 때문에 사람들의 표정도 굳어지고 사무적인 대화가 오가다보면 가벼운 내용도 심각하게 이야기되고 따라서 의사결정도 어려워지고 시간이 많이 지나게 된다.

이때 적절한 유머가 있으면 사람들의 얼굴 근육이 풀리게 되고 훨씬 원만하게 회의를 진행할 수 있게 된다. 필자는 요즘 어떤 회의를 주관할 때는 반드시 사람들이 한번 정도 웃을 수 있는 유머를 던지게 되는데 아주 효과가 좋다. 유머는 너무 상황과 동떨어지거나 저급하지 않고 상황에 적합한 주제로 하는 것이 가장 좋을 것이다.

여러분이 있는 조직에서 한번 실험을 해보라. 일부러 회의 분위기를 딱딱하게 한 상태에서 어떤 유형의 질문이 많이 나오는지 적절한 유머가 사용된 후에는 어떤 유형의 질문이 나오는지를 분석해 보면 금방 알 수 있다. 동일한 질문도 공격적으로 표현할 수도 있고 아니면 도움 요청을 위해 표현할 수도 있다.

자신이 가는 방향을 정확히 알아야 한다
대학생들이나 아직 회사에 입사하지 않은 학원생들은 IT 회사에서는 그저 컴퓨터 언어 잘 구사하고 데이터베이스 잘 관리하고 서버만 잘 관리하는 것으로 생각하는 경우가 많이 있다. 심지어는 회사에서 생활하고 있는 사람도 이러한 생각을 가지고 있는 경우가 많다.

그러나 시스템은 여러 사람이 함께 모여 완성해가는 특성이 있고 시스템은 비즈니스의 대상이 되고 비즈니스는 회사의 조직에서 발생해 실행되는 영역이 된다. 즉 IT업이라고 할지라도 조직이 있고 관리라고 하는 영역이 있으므로 이 영역에 대해 IT기술을 연구하듯 좀 더 전문적인 학습과 적용이 필요한 영역이 된다.

그저 수순을 밟듯 근무기간이 차 관리자가 되어 조직을 관리하고 다른 사람을 평가하는 사람이 되어서는 안 된다. 기술과 사람을 체계적으로 구성하고 다스릴 수 있는 준비된 관리자가 되어야 한다.

조직에서 영향력을 받는 위치에서 영향력을 미치는 위치는 그 사람으로 하여금 단순히 관리의 영역만을 기대하는 것이 아니라 그 사람으로 하여금 리더의 영역도 구성원이 기대하고 있음을 알아야 한다. John C. Maxwell은 ‘리더십의 법칙’이라는 책에서 “스스로 지도자라고 생각해도 따라오는 사람이 없다면 그저 산책만 하고 있었을 뿐이다”라고 이야기하고 있다.

리더란 ‘내가 가는 길의 방향을 정확하게 알고 있고 어떻게 실행해야 할지를 알고 있으며 나와 관련 있는 사람들을 함께 같이 그 방향으로 갈 수 있도록 하는 사람’이다. 분명하게 자신이 맡고 있는 조직의 구성원에게 방향을 제시하여 기꺼이 자신을 따라 일을 수행할 수 있도록 할 수 있는 능력(리더십)을 발휘하여 어렵고 복잡한 회사 조직에서 활기찬 직장생활을 할 수 있도록 해야 한다. @

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다