컨설턴트, 제대로 알고 고용하자
상태바
컨설턴트, 제대로 알고 고용하자
  • Intelligent Enterprise
  • 승인 2002.05.15 00:00
  • 댓글 0
이 기사를 공유합니다

필자는 컨설턴트로서 많은 프로젝트들을 보게 된다. 좋은 프로젝트들도 있고, 그렇지 못한 것들도 있다. 또 좋은 컨설팅과 나쁜 컨설팅, 그리고 더 안 좋은 경우로 좋은 컨설팅이 악용되는 사례까지 목격하게 된다. 한번은 동료 컨설턴트들과 함께 컨설팅 전쟁에 관한 이야기를 나눠볼 기회가 있었다. 그 자리에서 우리는 미션 크리티컬한 애플리케이션들을 개발할 때조차도 기업들이 컨설턴트들을 어설프게 활용하는 경우가 종종 있다는 이야기를 하며 실망감을 드러냈다. 이 글에서 필자는 미션 크리티컬한 애플리케이션들을 내부개발팀에 맡겨 개발하기 위해서, 또 전략적인 아웃소싱을 위해서 컨설턴트들을 효과적으로 활용하기 위한 몇 가지 가이드라인을 제공하려 한다.

‘일반 컨설턴트’와 ‘로열 컨설턴트’

경력에 상관없이 컨설턴트들은 2개 군으로 나뉘는 것 같다. 소위 일반 컨설턴트(enlisted advisers)로 불리는 제1군은 보편적으로 제2군보다 시간당 컨설팅 비용을 적게 요구하며 프로젝트 실무에 직접 참여한다. 기업들은 그들에게 비범한 생산성을 기대하고 있다. 기계처럼 코드를 만들어내기를 기대하는 것이다.

한편 로열 컨설턴트(royal advisers)로 불리는 제2군은 일반 컨설턴트들보다 시간당 컨설팅 비용을 더 높게 요구하는 경향이 있으며, 모든 해답을 가지고 있을 것이라는 기대를 받는다. 그들은 측근 세력으로 자리 잡고, 각종 회의에 참석하며, 자신들의 견해를 피력하고, 일반 컨설턴트들에게는 접근을 불허하는 레벨에 일반적으로 참여한다.

앞서 얘기한 토론 자리에 있었던 한 일반 컨설턴트는 실질적인 작업수행 방식에 자신이 아무런 영향력도 행사할 수 없음에 실망했다. 회사는 그에게 일정한 기대를 가지고 있었고, 그의 영역은 그것으로 제한되었다. 베스트 프랙티스를 가르치거나 프로세스의 확립을 지원하기 위해서 그는 튀지 않게 작업해야 했다.

보편적으로 그의 소스 코드는 버전제어시스템에 사용되었고, 잘 문서화되었으며, 야간에 구축되어 자동화된 스크립트로 테스트되었다. 나머지 개발자들은 여전히 서로에게 플로피를 돌리고 있었고 그러면서 결과를 낙관하고 있었다. 자신이 별다른 영향력을 미치지 못하는 것에 실망한 그는 다음에 컨설팅 일을 맡을 때는 아키텍트나 하이레벨 팀 리더 자리만 맡겠다고 결심했다.

로열 컨설턴트인 필자는 고기를 잡아주는 것이 아니라 고기 잡는 방법을 가르치는 접근법을 설파하고 있는 한 업체를 위해 일하고 있다. 수석 엔지니어들로 구성된 업체다. 우리는 좀더 고급스러운 작업들, 예컨대 아키텍처, 프로세스, 디자인, 테스팅 등에 대해 자문해달라는 요청을 받았다. 이런 작업들은 「나중에 생각하는 일」로 취급을 받는 경우가 많다. 소프트웨어 개발이란 코드 작성을 의미하는 것이라고 누구나 알고 있다. 하지만 이 소프트웨어가 아키텍처나 디자인을 필요로 한다는 것까지 모두가 알고 있는 것은 아니다.

또 프로세스는 마감시한에 쫓길 필요가 없는 사람들의 사치쯤으로 여겨지고 있다. 유감스럽게도 견고하고 유지관리가 용이한 코드를 구축하기 위해서는, 특히 주문처리나 레거시 마이그레이션 같은 전형적인 분산형 엔터프라이즈 애플리케이션들을 위해서는 이러한 나중에 생각하는 일들이 필수적이다.

대개의 경우, 경영진 중의 누군가가 프로젝트의 예산이나 일정이 예상을 초과하는 것에 대해 우려를 표시한다. 게다가 이전의 소프트웨어 릴리즈에서 잘 돌아가는 일들이 묘하게 문제를 일으킬 수도 있다. 이때 프로세스와 아키텍처의 가치에 대해 들어본 적이 있는 사람들은 외부의 도움을 구한다. 그러면 로열 컨설턴트가 입장한다.

이들은 『이와 똑같은 문제들을 다른 곳에서도 보았다』고 설명하고, 유효성이 증명된 솔루션 몇 가지를 제시한다. 하지만 이들은 비교적 몸값이 비싸기 때문에 직접적인 참여는 최소한으로 제한된다. 문제 해결 방법에 대한 질문을 받고 솔루션을 추천해주기는 하지만 그 솔루션의 구현 작업에 참여하는 것은 허용되지 않는다.

굳이 누구를 탓하고 싶은 생각은 없다. 로열 컨설턴트의 직접적인 참여가 제한되는 이유는 대개 예산 문제때문이다. 하지만 경영진의 의도가 아무리 좋은 것이라 해도 문제 해결 방법을 추천하는 것과 솔루션을 구현하는 것은 아주 다르다. 그것은 마치 내 차가 2단 기어에서 3단 기어로 변속이 안 된다는 말을 했는데 아, 그건 이미 알려진 문제다. TRAC ECU(전자제어유닛)를 업데이트 하면 된다는 말을 듣는 것과 같다. 전략 애플리케이션 개발에 있어서는 이러한 이해부족이 안 통한다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.