[스크랩/SW] 기고 | 나는 어떻게 개발자에서 컨설턴트가 되었나

Matthew Heusser | CIO

T 전문 기고가이자 컨설턴트인 필자에게 최근 몇몇 독자들이 질문해온 바가 있다. 컨설턴트라는 직업을 가지게 된 경로와 그 과정에서 터득한 교훈은 무엇인지에 대해 말해달라는 것이다.

사실 이는 컨설턴트 입장에서 대답하기 꺼려지는 질문이다. 고객이 아닌 컨설턴트에게 초점이 맞춰지면 뭔가 잘못되기 시작하는 경향이 있기 때문이다. 또 조언을 위한 조언을 하게 되고, 때론 듣는 사람에게 가짜 '약장수'처럼 여겨지는 경우도 발생하곤 한다.

하지만 소프트웨어 테스팅 컨퍼런스 애틀란타(Software Testing Conference Atlanta) 참석자들이 “박스 체커(Box-checker)에서 믿을 수 있는 조언자(Trusted Advisor)”가 되는 방법을 물어왔을 때, 이야기를 공유할 필요성을 느꼈다. 필자의 경험을 바탕으로 두 역할의 차이, 직장에서 인식을 바꾸는 방법에 대해 정리한다.


Credit: Vector Open Stock

역할과 인식, 현실
1900년대, 회사를 운영했던 사람들은 직종을 여러 단순한 업무의 직종들로 쪼갬으로써 쉽게 분업 경영을 할 수 있었다. 쉽게 예측할 수 있는 일(업무), 낮은 임금이 특징인 방식이다.

맥도날드와 월마트, 포드 자동차 등은 프레드릭 테일러(Fredick Winslow Taylor)의 <과학적 관리법(The Principles of Scientific Management)>이라는 저서에 뿌리를 두고 있는 이 개념은 '일과 노동자의 분리(Separating the worker from the work)'에 초점을 맞추고 있다.

그러나 모두 알고 있듯, 이 개념은 IT에는 적용되지 않는다. 딱 봐도 적용되지 않는다. 대다수 기업들은 구체적이고 특정적인 전문성과 경력을 갖춘 사람을 찾아 채용한다.

예를 들어 설명하면, ‘PostGres’를 이용한 ‘Ruby on Rails’에 3-5년의 경력을 갖춘 사람들을 찾는다. 여기에 그치지 않고, 특정 리눅스 버전과 자바스크립트 라이브러리를 요구사항으로 제시하기도 한다. 아주 엄격하게 기술적 역량과 전문성을 요구하고 있는 것이다. 경력이 많을 수록 직종 유연성은 더 떨어지게 된다.

다른 종류의 전문성들도 있다. 흠 없는 코드, 디자인 패턴, 기술적인 문제점(Debt)에 대한 인식 등은 모든 프로그래밍 언어에 적용되는 전문성이다. 이 밖에 일종의 경향성도 참고해야 한다. 예를 들어, 유지관리를 전문으로 하는 프로그래머들에게 신제품 개발을 맡기면 실패할 확률이 높다. 역으로 코드베이스를 유지 관리한 경험이 없는 프로그래머들에게 유지관리를 맡기면 문제가 발생할 수 있다. 좋은 코드를 분별해내는 전문성이 요구되기 때문이다.

이러한 요소들은 간단히 리스트로 제시할 수 없는 지식들이며, 피즈버즈(FizzBuzz) 같은 간단한 프로그래밍 훈련으로 해결될 문제 역시 아니다.

이러한 상황을 인식하고 있는가? 추진 방향과 요구사항에서 불확실한 부분, 그냥 방치되고 있는 문제들을 알고 있는가? 그렇다면 다음 단계, 즉 컨설턴트로 변신할 준비가 된 것이다.

필자에게는 10년 전 다음 단계로 나갈 사건이 발생했었다. 당시 재직하고 있던 보험 회사의 한 관리자는 화이트보드에 큰 붉은 글씨로 '자신의 역할을 알아야 한다 - 자신의 역할이 되어라!'라는 글을 남겼다.

그 관리자가 이런 글을 썼을 때, 필자는 그 자리에 있지 않았다. 그 관리자가 무슨 말을 하려는 것인지 확실히 알 수 없었다. 나는 펜을 들어 작은 글씨로 "또는, 프로젝트에 필요한 부분을 파악하고 그것을 실행하라"라고 적었다.

당시 팀에는 방향타 역할을 해줄 인물이 필요했다. 앞서 언급한 능력을 보유하고 부족한 점이 무엇인지 파악해 이를 메울 인물이 필요했던 것이다 필자는 한 명의 직원에 불과했지만 컨설팅을 공부하기 시작했다.

컨설턴트가 실제 하는 일
컨설턴트가 하는 업무는 무엇일까? <컨설팅의 비밀 : 대체 뭐가 문제야(Secrets of Consulting: A Guide to Giving and Getting Advice Successfully)>라는 서적의 소제목에 힌트가 있다. 고객에게 차이를 가져올 수 있는 조언을 제시하고, 이를 실천하도록 만드는 것이다. 또는 최소한 수수료에 버금가는 가치를 창조시켜야 한다.

'클라이언트에게 솔루션을 소개할 수는 있지만, 이를 이행하도록 강제할 수는 없다'는 말은 사실이다. 그러나 자신이 제시한 솔루션을 따르는 사람이 없다면 컨설턴트로 오래 살아남기 힘들다.

컨설팅 직무를 얻고 수행하기 위해서는 무언가를 개선하고 싶어하는 회사가 있어야 한다.

필자는 당시 재직했던 보험 회사에서 내부 컨설팅 업무를 스스로 시작했다. 일상 업무를 진행하며 동시에 프로젝트 관리 업무도 담당했다. 당시 회사에는 일상 업무와 목표(Goal)를 분리시킨 평가 체계가 많았다. 나는 이 부분을 이점으로 활용했다. 목표를 작은 컨설팅 프로젝트로 이용한 것이다. 그러다 상사와 업무 범위를 논의할 기회를 갖게 됐다. 이때 상사와 '경계선'과 '기대'에 대해 합의했고, 필자가 하는 일을 계속 공유하기로 했다.

내부 컨설턴트 업무를 시작하는 이에게 좋은 출발점이 될 수 있는 것이 갭 분석이다. 갭 분석(Gap Analysis)은 흔한 컨설팅 업무 중 하나로 일상 업무를 담당하는 직원 입장에서도 쉽게 수행할 수 있다.

다음으로 필요한 것은 조직의 니즈다. 조직이 필요로 할 때 컨설턴트 업무를 해야 한다. 조직 재편으로 관리자가 바뀐 상황을 가정하자. 새 관리자는 늦어도 첫 연간 실적 평가에서 자신의 성과를 입증해 보이기 원할 것이다. 그렇다면 갭 분석 실시를 제안해볼 만하다. 새 관리자의 장기 비전, 현재 팀이 운영되는 방식, 그리고 갭(공백 또는 차이)을 찾아, 이를 해결할 방법을 제안하는 것이다.

새 관리자는 이 시기에 귀를 기울일 동기가 부여되어 있다. 만약 문제점을 말하면, 이를 개선하겠다고 말할 것이다.

부서가 바뀌었을 때, 이를 제안할 수도 있다. 예를 들어, 유닉스 관리 부서에서 윈도우 부서로 옮겼다고 가정하자. 모든 사람이 당신을 새로운 사람으로 인정할 것이다. 당신에게 배울 점이 있다고 생각할 것이다. 이를 이용해 기존 업무 문서를 분석해 비교하자고 요청한다.

그러면 직원들이 업무에 대해 알아야 할 '갭'을 찾게 된다. 기존 관리자와 직원들이 일을 잘못하고 있다는 의미는 아니다. 일하는 방식을 컨설턴트의 방식으로 기록하지 않았다는 의미일 뿐이다. 분석을 마쳤으면, 다른 분야에도 이를 적용한다. 프로세스를 적용하는데 그쳐서는 안 된다. 도전하고, 개선할 부분을 지적한다.

새로운 일을 시작했을 때도 이를 적용할 수 있다. 새로운 시각을 가졌음을 강조한다. 그리고 팀의 장기 비전을 묻고, 개선할 부분을 찾는 분석을 실시한다.

컨설팅 업무들
다시 갭 분석을 설명하겠다. 갭 분석의 출발점은 목표와 최종 상태를 파악하는 것이다. 다시 말해, 기업이 도달하고 싶은 장소를 묻는 것이다. 이를 출발점으로 삼아, 현재 상태를 조사하고 간극을 찾아낸다.

필자는 통상 갭과 함께 개선을 위해 필요한 부분을 제안한다. 참고로 필자의 컨설팅 기업 엑셀론 디벨롭먼트(Excelon Development)는 고객들이 컨설턴트의 도움 없이 스스로 해야 할 몇 가지가 있다는 점을 제시하는데 만전을 기한다. 또 기업의 목표 달성에 도움이 될 서비스 '메뉴'를 제시한다.

내부 컨설턴트로 역할하면서 이런 일을 할 수 있다. 그러면 갭을 메울 역할을 맡게 될 확률이 높다.

갭 분석에 흔히 사용하는 도구 중 하나는 Strength(강점), Weakness(약점), Opportunity(기회), Threat(위협)으로 구성된 SWOT 분석이다. 강점과 약점은 내부 요소이고, 기회와 위협은 외부 요소이다. 참고로 이는 팀 수준에서만 수행해야 하는 분석이 아니다. 예를 들어, 우리는 조직 내부와 외부에서 기회와 위협을 분석했으며, 조직 외부의 산업 트렌드를 리스트로 정리했다.

필자는 독립하기까지 알찬 3년을 보냈다. 첫 회사는 소셜, 웹 기반 회사인 소셜텍스트(Socialtext)로 온라인 커뮤니티 활동에 관여해야 했다. 소셜텍스트는 직원을 내부 컨설턴트로 취급한다. 직원들에게는 이에 맞게 책임과 권한이 주어진다. 벤처 자본의 투자를 받은 신생 창업 회사였기 때문에 매 분기 실적 보고에 따른 결과가 따랐다. 해고를 당하거나 '축배'를 들 수 있었다는 의미이다. 회사는 우리가 현재 상태를 계속 인식할 수 있도록 도움을 줬다. 그러나 매 분기 초는 힘든 시기였다.

필자는 소셜텍스트에서 일 하면서 불확실성과 위험에 대한 인내력을 터득했다. 컨설턴트가 될 준비를 할 좋은 기회였다. 포트폴리오 매니지먼트 앤 스트래티지(Portfolio Management and Strategy)에서 컨설팅을 하고 있는 동료인 아담 유레트 또한 유사한 이야기를 했다. 그는 퍼시픽(Pacific)에서 3년간 일하면서 적은 소득으로 장기간 일하는 방법을 터득했고, 이는 컨설턴트 삶을 준비하는데 도움이 됐다고 말했다.

직원 컨설턴트로 근무하면서 터득한 마지막 교훈은 고객에게 초점을 맞추는 것이다.

초점은 고객
스스로를 외부의 인물로 생각하기 쉽다. 다른 사람을 위해 보고서와 분석 자료를 개발하는 사람이다. 그리고 점심 식사 동안 이렇게 자신과 자신의 일을 설명하기 시작한다. 이는 그럴듯해 보이지만, 동시에 함정이다.

컨설턴트는 고객의 '상태'를 개선하는 직종이다. 자신이 아닌 고객이다. 자신에 초점이 맞춰지면 대화에서 이상한 일이 발생하기 시작한다. 뭔가를 놓치기 시작한다.

더 나쁜 것은 변화가 발생하지 않는다. 고객의 상태가 개선되지 않는다. 사람들이 컨설턴트가 매일 무슨 일을 하는지 의심을 갖기 시작한다. 이야기 하는 것? 이야기하고, 보고서를 쓰는 것이 업무인가?

고객(상사, 프로젝트 팀, 동료 등)이 원하는 것을 파악한다. 그리고 이들이 이를 성취하도록 돕는다.

일을 잘 했는데 소외되는 경험을 알 것이다. 도와준 사람들은 큰 성과를 일궈냈지만, 자신은 이를 인정받지 못하는 상황이다. 그러나 이는 나쁜 일이 아니다. 좋은 일이다. 스스로를 칭찬하라. 그리고 진짜 컨설턴트가 됐음을 자랑스러워하라. 당신의 조언이 활용된 것이다. 계속 그렇게 평판을 쌓으면 새로운 일이 주어질 것이다.

고객에게 듣기 싫은 소리를 해야 하는 상황도 발생한다. 타협하자는 유혹에 빠질 수도 있다. 당신이 생각하기에 가장 필요한 과업 대신 다른 과업을 제시하는 것이다. 그러나 진정한 컨설턴트는 일을 거절하거나, 프레임을 바꿀 수 있어야 한다. 물론 이로 인해 일을 못 얻을 수도 있다.

내부 컨설턴트이기 때문에 선택권이 없다고 생각할지 모르겠다. 그러나 자신은 수용할 수 없는 부분이라고 단언할 수 있는 방법이 있다. 어쩌면 일자리나 인간 관계에 위험이 초래될지 모르겠다. 그러나 주어진 상황을 수동적으로 받아들이기만 하면 안 된다는 점을 학습해야 한다. 이는 커리어 성장의 밑거름이다.

리차드 바크(Richard Bach)는 <환상(Illusions)>이라는 책에서 "항상 우리 잘못이 아니라고 생각해 책임을 지지 않는다. 그런데 책임을 지지 않으면, 항상 그 책임의 희생자가 되는 법이다"고 말했다.

1단계는 자신의 업무 프로세스를 책임지는 것이다. 이를 출발점으로 조언을 제공하기까지 큰 시간이 걸리지 않는다. 사람들은 당신을 내부 컨설턴트라고 생각할 것이다. 굳이 직함을 바꿔 달 필요가 없다.

다음 단계
필자는 또 기술직 직원이나 조직 내 성장을 넘어서는 3번째 방식을 가르키고 싶다. 플레이어/코치, '콘트랙터 플러스(Contractor plus)'로 지칭할 수 있다. 직원 보수 분석 분야에서 일하는 친구는 코디네이터, 관리자, '내부 컨설턴트'라고 지칭한다. 표현이야 어떻든, 전체를 탐구해 통찰력을 제시하고, 장점과 단점, 상쇄되는 부분에 대해 조언하고, 아이디어가 실현되기까지 지원하는 역할이다. 자신의 현 직책과 일상 업무를 유지하면서 이렇게 할 수 있다. 프로세스 내부가 아닌 프로세스 너머에서 일하는 방식이다.

자신의 일상 업무에 추가해 이를 시작해보자. 다음 변화를 위한 출발점이다. 더 야심 찬 목표를 갖고 있다면, 그리고 모든 사람들이 팀원이자 컨설턴트로 업무에 변화를 가져오기 희망할 때 좋은 방법이다. 딴 내부 업무와의 균형을 잡는데 위험이 따르며 또 인식 측면에서 위험이 초래될 수 있다.

마지막으로 컨설턴트로의 변신을 위해 참고할 만한 4가지 간단한 질문이 있다. 지금 당장 당신의 프로젝트에 필요한 것은 무엇인가? 무엇을 할 것인가? 어떻게 진행되고 있는가? 마지막으로 다음은 무엇인가?

* Matthew Heusser는 엑셀론 디벨롭먼트 수석 컨설턴트다. ciokr@idg.co.kr 

출처: http://www.ciokorea.com/news/26605