레이블이 금융권인 게시물을 표시합니다. 모든 게시물 표시
레이블이 금융권인 게시물을 표시합니다. 모든 게시물 표시

2009년 9월 13일 일요일

금융권 IT 아웃소싱에 대한 단상

전자신문의 CIOBIZ 컬럼의 글중 IT 아웃소싱과 관련된  글이 눈에 들어왔다.

 

토털IT 아웃소싱, 하나대투증권 vs SK증권 

 

IT인력 이동없이 IT계열사로 시스템관리 이관

 

소위 신의 직장이라는 금융회사들에서 IT 아웃소싱을 한다는 기사를 읽을때면

한편으론, "IT인력들은 더이상 신의 직장에 입성할 기회조차 점점 없어지는 구나..."

라는 생각이 들어 씁쓸해 지곤 한다.

 

대부분 아웃소싱을 하게 되는 순간,

특히 위와 같이 자회사로 분리되고 인력이동이 되는 순간,

기존 몸담았던 모회사와는 급여나 복지혜택이 차이나게 된다.(최소 몇년간은 동일할지 모르겠지만...)

 

그리고 SK증권 처럼 SI업체로 이동되는 경우에는

결국 SI인력이 되어 SK증권 SM을 담당한도록 파견나온 외주직원의 신분이 되는것이다.

또한 언제 다른회사 SI 프로젝트에 투입될지도 모르게 될 것이다.

 

현재 IT인력들의 수준을 보면, 점점 하향평준화 되고 있는 듯 싶다.

이는 너무나 열악한 IT업체의 근무 여건(특히, SI 프로젝트)과 보상의 미흡,

낮은 사회적 대우 및 인식 등의 문제로 인해 이공계 기피 현상과 맞물려

우수인력이 IT업계로 진출을 꺼려하고 있기 때문이라는 생각이 든다.

 

문과 출신들과 똑같이 공부하고, 아니 더 치열하게 공부했건만,

사회에서는 "갑"과 "을"의 잣대로 모든 신분(?)을 정해버리고, (그속에서 항상 "을"일수 밖에 없고)

M/M의 잣대로(소위 머릿수로만) IT의 생산성을 평가하고 전문성을 인정하지 않는

사회 전반적인 분위기 속에서 몇명이나 과연 IT에 인생을 걸고 투자하겠는가?

 

IT전문가에게는 소위 "사"자 분들(변호사, 의사 등) 보다 더 높은 수준의

사회적 대우나 보상이 당연시 되는 사회기반이 마련되어야 한다.

 

더이상 공부하지 않는 낮은 수준의 개발자와

깊고 넓계 보는 expert 수준의 아키텍트의 차이를 확실히 구별하여 평가하고

그에 상응하는 차별화된 보상과 인정을 해주는 업체와 회사가 많아진다면,

IT인력들에게도 확실한 동기부여가 되고, 그 수준도 상당히 높아질 것이다.

 

이렇게 된다면 현재와 반대로 비 IT인력들이 IT인력들에게 신도 가고싶은 직장이라는

부러움을 보내지 않을까?

 

<추신>

산업별 IT 아웃소싱 동향분석에 대한 CIOBiZ(2009.7.12일자 신혜권, 성현희 기자)기획 기사가

눈에 들어왔다. 회사별 아웃소싱 회사에 대한 정리가 인상적이다.

 

[기획]산업별 IT아웃소싱 동향 분석

 

 

2009년 9월 6일 일요일

금융권 차세대시스템의 실패에 대한 단상

전자신문의 CIOBIZ컬럼을 읽다가 근래 진행되고 있는 금융권 차세대시스템 프로젝트 실패에 대한

공감가는 기사가 있어 소개한다.

 

차세대 IT 프로젝트 '실패'에서 배운다

 

사실 대규모의 차세대시스템 구축을 하면서 기한내에 오픈한 사이트는 전무하다 시피하다.

그나마 몇개월 지나서 간신히 오픈하고, 한 1년 정도 지나서 안정화가 되면 성공이라고 말하는 분위기다.

 

위의 기사에서도 좋은 지적을 했지만, 실제 차세대시스템을 구축하면서 개인적으로 성공과 실패를

가름하는 요소라고 느끼점은 아래와 같다.

 

첫째, CIO는 책임질줄 아는 카리스마가 있어야 하며,

실무자 레벨까지 다양한 소리를 듣고 올바른 의사결정을 내리는 능력이 가장 중요하다.

 

둘째, PM은 다양한 구축업체를 아우르고 고객을 비롯한 다양한 stakeholder간의 커뮤니케이션을 통해

조율하고 같은 비전을 공유하여  힘을 합쳐 시너지를 발휘할 수 있도록 리딩하는 능력이 중요하다.

 

셋째, 아키텍트가 중요하다.

 

특히, 아키텍트의 중요성을 절감하였다.

다양한 솔루션에 대한 이해를 통한 연계 및 Troubleshooting, Performance Tuning,

표준 및 가이드 작성, 개발자 교육 등 그야말로 컨트롤 타워가 바로 아키텍트였다.

 

얼마나 경험많고, 유능한 아키텍트를 중심으로 프로젝트를 진행하는냐가

결국 얼마나 많은 시행착오(소위 삽질)를 줄이고 프로젝트의 전체 리스크 또한 줄이느냐와 직결된다.

 

어떤 무식한 PM은 아키텍트는 초기에 몇달 가이드정도 작성하고 빠지면 되고,

그후 개발자들 잔뜩 투입해서 찍어내듯 개발하면 된다고 서슴없이 말하곤 한다.

이러한 무개념의 PM들이 결국 이런 대규모 프로젝트를 망치는 주연중에 하나다.

 

단언컨데, 초급 개발자 열댓명 투입하느니, 제대로된 아키텍트 한명이 더 훌륭한 아웃풋을 낸다

 

몇달전 정명훈 지휘로 서울시립교향악단의 공연을 본적이 있다.

중고등학교때 그토록 많이듣던 베토벤 교향곡이 이리도 감동적일 수 없었다.

이때, 문득 지휘자가 아키텍트랑 너무도 닮았다고 느낀것은 지나친 비약이었을까?