도안구 기자님이 그제 "SOA 구세주는 하드웨어?"라는 기사를 쓰셨네요. IBM이나 HP 등이 XML 가속기 등을 이용해서 SOA 프로젝트의 성능 향상을 시킬 수 있다는 게 하드웨어 벤더들의 이야기인가봅니다.
놀새~의 경우 2006년 말 모 통신사 SOA BMT 및 초기 프로젝트를 수행하면서 나타났었던 XML처리에 대한 문제를 고민하고 있었습니다. 그 즈음 프로젝트 SI인 L사의 혁신팀이 데이터파워 등의 XML 가속기에 대한 사업(총판 정도?)을 하려했었고 프로젝트 팀에서는 성능 향상을 위하여 시연회 때 참석을 했었던 기억이 있습니다.
결론부터 이야기하자면 도입하지 않는다였습니다. 그 때 해당 회사가 IBM에 인수되었었는데 초기 제품인데다가 차세대 프로젝트에서 검증되지 않은 플랫폼을 도입한다는 것 자체가 모험이었습니다. "권한은 있는데 책임은 지지 않으려 하는" 심리가 확연히 드러났다라고 볼 수도 있겠습니다.
또 한가지 요인은 이미 그 때 Azul이라는 H/W형 자바가 이미 나와있었음에도 불구하고 국내에서는 거의 검토도 하지 않았습니다. 자바라는 엔터프라이즈 솔루션에 대한 가속기가 있다는 것을 거부하는 마당에 이제 도입 초기의 SOA에 XML 가속기는 어불성설이었던 셈이지요.
어찌되었건 SOA 프로젝트는 대외에 성공적으로 끝이 났다고 이야기합니다. 가만히 생각해보면 국내에 도대체 실패한 프로젝트가 있긴 하는지 궁금할 다름입니다 소위 "광팔기(고스톱에서)"케이스로 CxO레벨에서 무언가 업적을 남겨야 하므로 프로젝트 내부를 까보면 개판임에도 불구하고 어떻게든 오픈은 시켜놓는 케이스로 진행되고 있다는 겁니다. 이러한 것을 경험하신 분들도 있을 것이고 들으신 분들도 있으실 겁니다.
개념을 IT화시키는 데 걸리는 평균 시간
바코드 시스템은 1932년에 고객의 자동 구매를 위한 프로젝트로 시작이 됐습니다. 하지만 실제 최초 설치된 것은 1960년대였고 활성되기 시작한 것이 1980년대부터였습니다.
ERP(Enterprise Resource Planning)은 1960년초에 IMC(Inventory Management Control)이라는 재고 관리를 위한 시스템 개념으로부터 시작되어 1970년대 MRP(Manufacturing Resource Planning), CIM(Computer Integrated Manufacturing)으로 발전하면서 1990년대에 ERP 붐을 일으켰습니다.
CRM(Customer Relationship Management)는 전단지와 같은 카탈로그 마케팅(catalog marketing)으로 1950년대에 처음 시작이 되었고 SCM(Supply Chain Management)는 MRP II(1970년대)와 같이 시작해서 1990년대에 와서야 비로소 정착하게 됩니다.
BPM(Business Process Management)의 경우는 1970년대 제록스의 OA(Office Automation) 개념으로 시작되었으니 지금 딱 30년째이고 어느 정도 성숙 단계로 접어드는 시기입니다.
위의 경우를 살펴보았을 때 우리가 현재 사용하고 있는 IT개념들이 정착되는데 걸리는 시간이 평균 30년입니다.
EAI(Enterprise Application Integration) 등장
EAI는 1990년대 메이저 ERP 사용 기업들이 시스템을 업그레이드 하면서 레거시 시스템과의 연계 요구로 처음 생겨나게 되었습니다. 이 때 TIBCO, Vitria, WebMethod, iWay 등의 전통 EAI 업체가 생겨나게 되었습니다. 이 업체들의 특징은 기본 코어 엔진은 낮은 가격에 실제 레거시와 붙는 어댑터의 개발 생산성, 성능에 집중하므로서 고가의 어댑터를 통한 제품을 공급하기 시작하였습니다.
시작 시점은 1990년대라고 했습니다. 그러면 대부분의 EAI프로젝트는 성공을 했을까요? 보고서(Trotta, Gian(2003-12-15). "Dancing Around EAI 'Bear Traps'". http://www.ebizq.net/topics/int_sbp/features/3463.html. Retrieved on 2006-06-27)에 의하면 전세계의 70%의 EAI 프로젝트는 실패했다고 보고됩니다. 문제는 다음과 같았습니다.
- 지속적인 기업환경 변화에 시스템이 따라주지 못함
- 대상 시스템에 대한 전문가 부재
- 각 사용자 부서와 협업, 의사 소통이 제대로 이루어지지 않아 인터페이스 도출 어려움
- 기술, 문화, 정치적인 이유로 부서의 시스템을 다른 사업부에 보여주기 원치 않음
- 많은 부서 참여로 인한 요구 사항 중첩 및 해결책 모호로 인하여 최종 시스템 구조가 명확하지 않음
EAI 프로젝트의 가장 큰 폐해 요소로 기업들은 해당 패키지 애플리케이션 벤더 및 EAI 벤더에게 lock-in 되었다고 보고되었습니다.
Vendor Lock-in은 고객이 벤더, 제품, 서비스에 의존한 나머지 lock-in 비용이 발생하여 시장에 빠르게 진입하지 못하는 현상을 일컫습니다. 놀새~의 글을 읽는 분들이 겪는 가장 대표적인 케이스의 생활 벤더 lock-in은 DSLR 카메라입니다. 타사의 죽여주는 렌즈를 구입하고 싶을 때 렌즈만을 구입하는 것이 아니라 카메라 바디를 바꾸어야 하는 switch-cost가 발생을 하게 되는 경우입니다.
국내의 EAI 프로젝트를 보더라도 실제 공공, 제조는 거의 제로에 가깝다고 말할 수 있고 그나마 통신, 금융이 복잡한 시스템들로 인하여 도입을 한 경우가 상당수 있습니다. 문제는 도입됨과 동시에 빼도 박지도 못하는 상황이 발생할 수 있다는 것입니다.
그렇다면 SOA는?
1996년 가트너 보고서에는 이런 말이 실립니다.
문제는 대부분의 벤더들이 SOA 제품을 기존의 EAI 제품에 웹서비스 기능 강화를 통하여 이루어보고자 했지만 앞서 도안구 기자께서 쓰신 글에도 MS, IBM, Oracle 등의 벤더 웹서비스도 잘 호환이 안되는 경우가 상당수 발생합니다. 결국 벤더 통합을 이루어낼 수 있는 재사용 컴포넌트 만들기란 쉽지 않다는 결론을 내릴 수도 있습니다.
신문기사를 보면 KTF가 SOA 프로젝트의 막바지에 다다랐습니다. 성능 개선작업이 진행되고 있다고 합니다. 하지만 전문가가 그리 많지 않은 상황에서 개발자들이 성능(performance)을 낼 수 있는 코드를 작성했다고 보기 또한 어렵습니다.
기사 내용 인터뷰 중 하나를 살펴보겠습니다. 한국 오라클의 인터뷰에서 "SOA는 이기종 시스템 환경에서 프로세스 혁신과 맞물려 진행할 때 큰 효과를 볼 수 있다"라고 이야기하고 있습니다. 이 기종은 맞는 이야기입니다. 하지만 PI 프로젝트와 맞물렸을 때 큰 효과는 그저 궁금할 다름입니다.
프로세스 개선(EA관점)도 중요하겠지만 가트너가 하고자 했던 SOA는 궁극적 목표는 재사용을 통한 서비스 조립으로 기업의 민첩성 향상, 즉 그만큼 다른 경쟁사보다 시장에 빨리 진입하겠다는 의도입니다. SOA 프로젝트가 효과를 보려면 전사적인 SOA 조직을 통한 서비스 컴포넌트 축적을 통하여 향후 프로젝트의 서비스가 기존의 작성된 서비스를 참조할 때 최고의 효과를 볼 수 있습니다. 즉 단기간에 효과를 볼 수 없다는 게 SOA의 가장 큰 단점일 수도 있습니다. 당연히 비용 곡선은 다음과 같이 구성되겠지요.
EAI의 태생일수도 있는 제품이라면 당연히 EAI가 가졌던 문제를 그대로 가져가게 될 확률이 그만큼 높아지게 됩니다.
해법은?
나름 기업에게 제시할 수 있는 해법을 놀새~ 머리 속에 생각하고 있고 그것을 고객에게 이야기하고 있습니다. 고객은 "그렇게 하면 될 수 있겠구나"라고 맞장구는 치면서 정작 앞서 이야기한 "책임지고 싶지 않다"라는 말도 안되는 이유로 슬슬 피하네요.
혁신을 실행하지 않는다면 도태될 수 밖에 없을 것입니다.
더 쓰고 싶은데 노무현 전 대통령 및 영결식 보러 가야겠습니다.
놀새~의 경우 2006년 말 모 통신사 SOA BMT 및 초기 프로젝트를 수행하면서 나타났었던 XML처리에 대한 문제를 고민하고 있었습니다. 그 즈음 프로젝트 SI인 L사의 혁신팀이 데이터파워 등의 XML 가속기에 대한 사업(총판 정도?)을 하려했었고 프로젝트 팀에서는 성능 향상을 위하여 시연회 때 참석을 했었던 기억이 있습니다.
결론부터 이야기하자면 도입하지 않는다였습니다. 그 때 해당 회사가 IBM에 인수되었었는데 초기 제품인데다가 차세대 프로젝트에서 검증되지 않은 플랫폼을 도입한다는 것 자체가 모험이었습니다. "권한은 있는데 책임은 지지 않으려 하는" 심리가 확연히 드러났다라고 볼 수도 있겠습니다.
또 한가지 요인은 이미 그 때 Azul이라는 H/W형 자바가 이미 나와있었음에도 불구하고 국내에서는 거의 검토도 하지 않았습니다. 자바라는 엔터프라이즈 솔루션에 대한 가속기가 있다는 것을 거부하는 마당에 이제 도입 초기의 SOA에 XML 가속기는 어불성설이었던 셈이지요.
어찌되었건 SOA 프로젝트는 대외에 성공적으로 끝이 났다고 이야기합니다. 가만히 생각해보면 국내에 도대체 실패한 프로젝트가 있긴 하는지 궁금할 다름입니다 소위 "광팔기(고스톱에서)"케이스로 CxO레벨에서 무언가 업적을 남겨야 하므로 프로젝트 내부를 까보면 개판임에도 불구하고 어떻게든 오픈은 시켜놓는 케이스로 진행되고 있다는 겁니다. 이러한 것을 경험하신 분들도 있을 것이고 들으신 분들도 있으실 겁니다.
개념을 IT화시키는 데 걸리는 평균 시간
바코드 시스템은 1932년에 고객의 자동 구매를 위한 프로젝트로 시작이 됐습니다. 하지만 실제 최초 설치된 것은 1960년대였고 활성되기 시작한 것이 1980년대부터였습니다.
ERP(Enterprise Resource Planning)은 1960년초에 IMC(Inventory Management Control)이라는 재고 관리를 위한 시스템 개념으로부터 시작되어 1970년대 MRP(Manufacturing Resource Planning), CIM(Computer Integrated Manufacturing)으로 발전하면서 1990년대에 ERP 붐을 일으켰습니다.
CRM(Customer Relationship Management)는 전단지와 같은 카탈로그 마케팅(catalog marketing)으로 1950년대에 처음 시작이 되었고 SCM(Supply Chain Management)는 MRP II(1970년대)와 같이 시작해서 1990년대에 와서야 비로소 정착하게 됩니다.
BPM(Business Process Management)의 경우는 1970년대 제록스의 OA(Office Automation) 개념으로 시작되었으니 지금 딱 30년째이고 어느 정도 성숙 단계로 접어드는 시기입니다.
위의 경우를 살펴보았을 때 우리가 현재 사용하고 있는 IT개념들이 정착되는데 걸리는 시간이 평균 30년입니다.
EAI(Enterprise Application Integration) 등장
EAI는 1990년대 메이저 ERP 사용 기업들이 시스템을 업그레이드 하면서 레거시 시스템과의 연계 요구로 처음 생겨나게 되었습니다. 이 때 TIBCO, Vitria, WebMethod, iWay 등의 전통 EAI 업체가 생겨나게 되었습니다. 이 업체들의 특징은 기본 코어 엔진은 낮은 가격에 실제 레거시와 붙는 어댑터의 개발 생산성, 성능에 집중하므로서 고가의 어댑터를 통한 제품을 공급하기 시작하였습니다.
시작 시점은 1990년대라고 했습니다. 그러면 대부분의 EAI프로젝트는 성공을 했을까요? 보고서(Trotta, Gian(2003-12-15). "Dancing Around EAI 'Bear Traps'". http://www.ebizq.net/topics/int_sbp/features/3463.html. Retrieved on 2006-06-27)에 의하면 전세계의 70%의 EAI 프로젝트는 실패했다고 보고됩니다. 문제는 다음과 같았습니다.
- 지속적인 기업환경 변화에 시스템이 따라주지 못함
- 대상 시스템에 대한 전문가 부재
- 각 사용자 부서와 협업, 의사 소통이 제대로 이루어지지 않아 인터페이스 도출 어려움
- 기술, 문화, 정치적인 이유로 부서의 시스템을 다른 사업부에 보여주기 원치 않음
- 많은 부서 참여로 인한 요구 사항 중첩 및 해결책 모호로 인하여 최종 시스템 구조가 명확하지 않음
EAI 프로젝트의 가장 큰 폐해 요소로 기업들은 해당 패키지 애플리케이션 벤더 및 EAI 벤더에게 lock-in 되었다고 보고되었습니다.
Vendor Lock-in은 고객이 벤더, 제품, 서비스에 의존한 나머지 lock-in 비용이 발생하여 시장에 빠르게 진입하지 못하는 현상을 일컫습니다. 놀새~의 글을 읽는 분들이 겪는 가장 대표적인 케이스의 생활 벤더 lock-in은 DSLR 카메라입니다. 타사의 죽여주는 렌즈를 구입하고 싶을 때 렌즈만을 구입하는 것이 아니라 카메라 바디를 바꾸어야 하는 switch-cost가 발생을 하게 되는 경우입니다.
국내의 EAI 프로젝트를 보더라도 실제 공공, 제조는 거의 제로에 가깝다고 말할 수 있고 그나마 통신, 금융이 복잡한 시스템들로 인하여 도입을 한 경우가 상당수 있습니다. 문제는 도입됨과 동시에 빼도 박지도 못하는 상황이 발생할 수 있다는 것입니다.
그렇다면 SOA는?
1996년 가트너 보고서에는 이런 말이 실립니다.
"잘 정의된 인터페이스를 가진 재사용이 가능한 일련의 컴포넌트들로 구축되는 기술 구조 방식을 SOA(Service Oriented Architecture)라 한다"목적은 공유와 재사용이라 했습니다. 벤더들은 앞다투어 이 개념을 제품화시키기 위해 노력했고 여기에 EAI, WAS 벤더들이 마구잡이로 달려들기 시작을 했습니다. 하지만 현재의 결과는 어떨지 상상해보세요.
문제는 대부분의 벤더들이 SOA 제품을 기존의 EAI 제품에 웹서비스 기능 강화를 통하여 이루어보고자 했지만 앞서 도안구 기자께서 쓰신 글에도 MS, IBM, Oracle 등의 벤더 웹서비스도 잘 호환이 안되는 경우가 상당수 발생합니다. 결국 벤더 통합을 이루어낼 수 있는 재사용 컴포넌트 만들기란 쉽지 않다는 결론을 내릴 수도 있습니다.
신문기사를 보면 KTF가 SOA 프로젝트의 막바지에 다다랐습니다. 성능 개선작업이 진행되고 있다고 합니다. 하지만 전문가가 그리 많지 않은 상황에서 개발자들이 성능(performance)을 낼 수 있는 코드를 작성했다고 보기 또한 어렵습니다.
기사 내용 인터뷰 중 하나를 살펴보겠습니다. 한국 오라클의 인터뷰에서 "SOA는 이기종 시스템 환경에서 프로세스 혁신과 맞물려 진행할 때 큰 효과를 볼 수 있다"라고 이야기하고 있습니다. 이 기종은 맞는 이야기입니다. 하지만 PI 프로젝트와 맞물렸을 때 큰 효과는 그저 궁금할 다름입니다.
프로세스 개선(EA관점)도 중요하겠지만 가트너가 하고자 했던 SOA는 궁극적 목표는 재사용을 통한 서비스 조립으로 기업의 민첩성 향상, 즉 그만큼 다른 경쟁사보다 시장에 빨리 진입하겠다는 의도입니다. SOA 프로젝트가 효과를 보려면 전사적인 SOA 조직을 통한 서비스 컴포넌트 축적을 통하여 향후 프로젝트의 서비스가 기존의 작성된 서비스를 참조할 때 최고의 효과를 볼 수 있습니다. 즉 단기간에 효과를 볼 수 없다는 게 SOA의 가장 큰 단점일 수도 있습니다. 당연히 비용 곡선은 다음과 같이 구성되겠지요.
해법은?
나름 기업에게 제시할 수 있는 해법을 놀새~ 머리 속에 생각하고 있고 그것을 고객에게 이야기하고 있습니다. 고객은 "그렇게 하면 될 수 있겠구나"라고 맞장구는 치면서 정작 앞서 이야기한 "책임지고 싶지 않다"라는 말도 안되는 이유로 슬슬 피하네요.
혁신을 실행하지 않는다면 도태될 수 밖에 없을 것입니다.
더 쓰고 싶은데 노무현 전 대통령 및 영결식 보러 가야겠습니다.
http://www.javapattern.info/trackback/253
