2015.09.14

기고 | 나는 어떻게 개발자에서 컨설턴트가 되었나

Matthew Heusser | CIO

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

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

하지만 소프트웨어 테스팅 컨퍼런스 애틀란타(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)은 흔한 컨설팅 업무 중 하나로 일상 업무를 담당하는 직원 입장에서도 쉽게 수행할 수 있다.

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

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

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

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

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




2015.09.14

기고 | 나는 어떻게 개발자에서 컨설턴트가 되었나

Matthew Heusser | CIO

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

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

하지만 소프트웨어 테스팅 컨퍼런스 애틀란타(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)은 흔한 컨설팅 업무 중 하나로 일상 업무를 담당하는 직원 입장에서도 쉽게 수행할 수 있다.

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

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

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

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

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


X