조대협의 블로그

제목이 좀 모호하네요. 다니던 회사가 합병이 되면서 주로 수행하는 컨설팅의 범위가 더욱 넓어진것 같습니다. 아래 포스팅에도 언급했지만 예전에는 SA 역할을 많이 했습니다만, 요즘은 비지니스에 관련된 일을 많이 하게 됩니다. 주로 고객사의 신사업 개발이나 신시스템 프로젝트에 대해서 프로젝트 초기부터 참여하는 경우가 많습니다. (정식 발주전에도..) 그 과정에서 비지니스적인 부분을 많이 보게 됩니다. 예전에는 생각하지도 않았던, 비용 문제, Time to market에 의해서 개발기간이 짧아질 수 밖에 없는 문제, 경쟁사 분석, 법적 이슈, 세금문제나 조직구조에 대한 이슈등.. 그리고 같이 일하는 대상도 개발자나 파트너에서, 동급 컨설턴트나 외국 컨설턴트로 많이 바뀌었습니다. 사실 힘은 듭니다만 공짜로 강의..

Support engineer를 거쳐서 본격적인 컨설팅을 한지도 대략 3년정도 되가는것 같네요. 예전에는 주로 SA (Solution Architect)의 역할을 맏았습니다. 제품을 가지고 delivery를 어떻게 할까 고민을 하고, 솔루션 기반의 아키텍쳐를 그리는 역할을 합니다. 그러다가 작년 초인가 부터 AA (Application Architect)의 역할을 하고 있습니다. 실제 전체 시스템의 윤곽을 잡고 delivery를 하는 역할입니다. 솔루션에 대한 부분은 파트너나 presales들의 도움을 받아가면서 delivery하는데... 예전에는 제품에 대해서 아주 깊숙한곳까지 속속들이 꿰뚫고 있었는데, 요즘은 제품보다 큰 그림이나 비지니스 모델 그리고 전략에 대해서 많은 고민을 하고 있습니다. 그러다..

고객사에 아키텍쳐 컨설팅을 하다보면 항상 느끼는 거지만, 해당 시스템에 대해서 전체 그림을 그리고 이해할 수 있는 사람이 항상 없다는 것이다. 보통 프로젝트시에는 SI나 컨설팅 업체에서 AA(Application Architect)등의 역할을 받아서 전체 그림을 그리고 설계를 하지만, 외부 인력이고 프로젝트가 끝남과 동시에 rollout 해버리면 시스템을 이해하는 사람이 없다. 물론 고객사쪽에서 인수받게 되어 있지만, AA와 같은 컨설턴트 비용이 높은것이 그만한 역량을 가지고 있기 때문인데, 고객사에서 그만한 열정과 실력을 가지고 있는 사람은 드문것 같다. 그래서 애플리케이션의 부분적인 코드 수정만 할뿐 아키텍쳐에 대한 기본 사상이 유지되지 않고, 확장이나 발전시에 AS-IS 아키텍쳐를 아는 사람이 없으..

요즘 Gabriel이라는 호주산(?) 컨설턴트랑 일을 하고있습니다. 점심식사때 재미있는 이야기를 하더군요. 고객한테 이야기할때, 항상 2가지를 고르라고 한답니다. Cost,Quality,Quick 3가지 중에서요 Quality와 Quick(기간)을 갖춘 시스템을 원하면 Cost가 올라갈것이고 Cost와 Quality (저비용에 좋은 품질)을 원하면 당연히 Quick(기간)이 떨어질것이고 Quick과 Cost를 원하면 (단기간에 낮은 비용)으로 구축을 원하면 결과적으로 Quality가 떨어질것입니다. 당연한 사실이지만, 재미있는 접근 방법 같네요.