마소 기고 - 복잡해진 IT 환경, 돌파구는「통합」

아래 글은 2004년 10월 '마이크로소프트웨어'지에 기고한 글이다.
우연히 기고하게 되었다는...-_-; 지금은 부서도 다르고...
에고...마이 묵었다..

================================================


복잡해진 IT 환경, 돌파구는「통합」

진동철 (LG CNS 기술전략팀)   2004/12/13


지금 이 순간 기업들은 시시각각 변하는 환경에 대응하기 위해서는 통합이 가장 최선의 전략임을 인식하고 있다. 그러나 아직도 어떻게 하면 효율적이고 효과적인 통합을 이룰 수 있을지 고민하는 기업들이 많은 것 또한 사실이다.

이에 효과적이고 효율적인 통합 방법을 알기에 앞서 왜 통합이란 화두가 나왔는지, 그 미래는 무엇인지 IT의 발전에 비춰 살펴보고자 한다.

단순한 사무 자동화 도구로부터 시작한 IT는 이제 기업에게든 개인에게든 없어서는 안 될 중요한 전략적 도구로 인식되고 있다. IT의 발전은 <그림 1>에서 보는 바와 같이 크게 세 단계로 구분할 수 있다.

먼저 1세대는 단위 업무 중심의 사무 자동화 단계이다. 메인프레임을 이용해 비용을 절감하고 업무 효율화를 높이던 시대라고 할 수 있다. 2세대는 클라이언트-서버 시대로서 생산성을 향상시키고 엔드 유저에게 PC를 통해 강력한 힘을 주던 시기였다. 이 시기의 IT는 업무 프로세스를 효과적으로 지원하고 온라인 의사결정을 가능하게 하는 시기였다고 볼 수 있다.

마지막으로 3세대는 우리가 흔히 알고 있는 e비즈니스 시대로서 IT가 새로운 수입원을 창출하고 전략적 도구로서 활용되는 시기이다. 기업의 명실상부한 인프라가 된 IT를 통해 새로운 가치를 만들어 내기 위해 노력했으며 이러한 노력은 통합을 통해서 좀 더 손쉽게 가능해지게 된 것이다.

<그림 1> History of IT (출처 : 가트너)

그렇다면 통합은 과연 얼마나 중요하게 인식되어 왔을까? <그림 2>는 가트너에서 지난 2003년 미국 CIO를 대상으로 설문한 결과이다. CIO들에게 기술적인 이슈 Top 10을 선택하도록 설문한 결과, 보안이 가장 큰 이슈였으며 그 다음이 바로 통합 이슈였다. 9.11 테러의 공포에 휩싸인 상황으로 인해 보안이 가장 큰 이슈가 된 점을 감안한다면, 통합이 가장 큰 이슈 중의 하나라고 감히 말할 수 있을 것이다.

실제 CIO들은 통합 문제로 인해 큰 어려움을 겪고 있다고 한다. 미국의 포춘급 대기업들은 평균적으로 7개의 다른 시스템을 보유하고 있으며 관리자의 75%가 이러한 구성이 문제를 일으키고 있다고 응답했다. 또한 합병을 고려 중인 회사의 46%가 상이한 IT 시스템의 통합에 어려움을 호소했으며 90%의 관리자들이 보다 향상된 통합을 요구하고 있다고 한다.

<그림 2> Top 10 기술 이슈(출처 : 가트너)

이렇듯 통합은 이제 단순한 문제를 넘어서 기업의 가장 큰 화두가 되고 있는 것이다.

기업이 처한 환경
그렇다면 왜 통합이 이슈가 될 수밖에 없었던 것일까? 그 이유는 현재 기업이 처한 환경을 파악함으로써 가늠해 볼 수 있다.

ERP라는 개념이 처음 나오고 그에 상응하는 ERP 패키지 제품들이 기업 내에 도입됐을 때 기업들은 이제 기업 내 모든 애플리케이션을 ERP라는 하나의 큰 그릇에 담을 수 있다고 생각했었다. 그러나 ERP가 기업 내 모든 업무를 지원해 주지 못함에 따라 고객 관리를 위한 CRM이 필요했고, 공급망 관리를 위한 SCM이 필요했다. 하나하나씩 이러한 패키지 제품들을 필요로 하게 되면서 기업 내에는 수많은 시스템들이 존재하게 됐다.

이러한 시스템들은 개별 업무를 지원하는 독자적인 기능을 수행하는데 최적화하기 위해 개별적인 데이터베이스와 애플리케이션 서버를 가진다. 이러한 모습은 바로 Silo(곡물 등을 보관하는 저장소)와 같은 형태로서 시스템마다의 독립성은 보장되나 시스템 간의 데이터 공유나 취합은 오히려 더 어려울 수밖에 없게 됐다. 즉 점점 독자적인 시스템으로 변해가는 Silo 형태에서는 정보 공유에 한계가 있었던 것이다.

<그림 3> Silo 형태로 존재하는 시스템들

최근 기업 경영에 있어 화두가 되고 있는 것 중에 ‘실시간 기업(RTE: Real-Time Enterprise)’이라는 것이 있다. 실시간 기업이란 기업의 기회·위협 요인을 경쟁사보다 먼저 파악해 효율적인 의사결정 후 민첩하게 대응하자는 개념이다.

<그림 4> 실시간 기업 모델(출처 : 가트너)

<그림 4>에서 보는 바와 같이, 실시간 기업에서의 핵심은 ‘실시간 감지’와 ‘신속한 대응’이다. 시장에서의 이벤트 또는 변화가 Awareness 단계에서 감지되면, 의미 있는 데이터를 수집해 Decision 단계로 넘어간다. Decision 단계에서 직원 간, 조직 간 협업을 통해 효과적인 의사결정이 이뤄지면 Action 단계에서 실행에 옮겨지며, 더불어 실행 결과에 대한 지속적인 모니터링도 이뤄진다.

이러한 일련의 단계에 소요되는 시간을 줄이고자 하는 것이 실시간 기업이 되고자 하는 노력이다. 따라서 이러한 흐름이 원활하게 수행되기 위해서는 적재적소에 실시간 데이터 수집 및 접근, 업무 프로세스의 중단 없는 연계가 필수이다. 즉 기업 내 모든 애플리케이션과 데이터가 필요할 때 바로바로 접근될 수 있는 통합 환경이 되어야 한다.

한편 예전에 비해 기업 간의 인수합병이 많아지는 경영 환경도 통합에 대한 관심을 불러일으키고 있다. 강자와 약자 간에 먹고 먹히는 양육강식의 법칙은 예전이나 지금이나 기업 경영에 있어 불변이긴 하지만, 최근 들어 기업 간 인수합병은 부쩍 늘어나는 추세이다. 이것은 합병을 통해 시장 내 1위 업체가 되거나 경쟁사를 미리 인수하자는 절박한 심정에서 나오는 경영 전략의 하나이다.

그러나 인수합병이 되면서 두 회사에서 갖고 있던 IT를 통합하는 것은 결코 쉬운 작업이 아니다. 단순히 데이터 센터를 합치거나 데이터를 교환하는 데에 그치지 않고 두 회사의 IT 인프라를 전면 통합하고 업그레이드 하는 작업이 병행되는 경우에는 더더욱 힘든 작업이 된다.

통합으로 과연 무엇을 얻을 것인가?
기업들은 통합을 통해 무엇을 기대하고 있는 것일까? 통합을 통해 가져올 수 있는 혜택은 여러 가지가 있을 수 있겠지만, 크게 IT 운영에 대한 부분과 기업 경영에 대한 부분으로 나눠 생각할 수 있다.

먼저 IT 운영에 대한 부분으로 이미 투자한 IT 자산에 대한 활용도를 높일 수 있다는 점을 들 수 있다. 기업들은 이미 많은 시간과 비용을 들여 수많은 시스템을 구축해 놓고 있다. 이러한 시스템들이 환경의 변화에 좀 더 능동적으로 대응할 수 없다면 매번 기업들은 기존 시스템을 버리고 새로운 시스템을 구축해야 할 것이다. 이 얼마나 비용 소모적인가? 통합을 제대로만 한다면 매번 새로운 요구사항에 대해 시스템을 만들지 않더라도 기존 시스템의 활용도를 높여 빠른 대응을 할 수 있을 것이다.

또한 IT에 대한 유지보수 비용을 줄일 수도 있다. 앞서도 말했듯이 기업 내 산재해 있는 시스템들은 점점 복잡해지고 그에 따라 관리하기 위한 비용과 시간은 엄청나다. 효과적인 통합을 할 수 있다면 이러한 비용과 시간을 단축할 수 있는 것이다. 이렇듯 기존 자산을 재활용하고 유지보수 비용을 줄일 수 있다는 점은 경제 상황이 그다지 좋지 않은 현 시점에서 볼 때 기업들에게 매력적인 점이 아닐 수 없다.

두 번째로, 기업 경영 측면에서 볼 때 통합은 기업에게 민첩성 및 유연성을 줄 수 있다. 앞서 설명한 실시간 기업이 되기 위한 실시간 데이터 수집, 접근, 무중단 프로세스의 실현을 가능하게 해 줌으로써 경쟁력 있는 기업이 되도록 하는 것이다. 예를 들면, 콜센터의 에이전트가 고객의 전화 응대시 창고에 있는 재고 수량을 즉시 확인하고 민첩하게 대응할 수 있다면, 그 기업은 좀 더 많은 사업기회를 가질 수 있는 것이다. 또는 기업 내 통합을 위한 인프라가 탄탄히 갖춰져 있다면 잦은 업무 프로세스 변경에 대해서도 유연하게 대응할 수 있다.

통합에 대한 기업의 성숙도 평가 모델
그렇다면 기업들이 어느 정도 통합에 대해 준비가 되어 있는지, 또는 어느 정도 대응을 하고 있는지 어떻게 평가할 수 있을까? 이에 대해 CGI의 자회사인 AMS에서는 4 레벨의 통합 성숙도 평가 모델을 발표한 바 있어 간략히 살펴보고자 한다.

[1] 레벨 1 : Point-to-Point Integration(<그림 5>)
가장 낮은 단계인 레벨 1은 애플리케이션 간에 기본적인 데이터 교환이 이뤄지는 단계이다. 각 인터페이스는 custom-built되며 전체적인 구조는 서로 엮인 스파게티 모양이 된다.
[2] 레벨 2 : Structural Integration(<그림 6>)
레벨 2에서는 좀 더 진보한 미들웨어 툴을 사용해 애플리케이션 간의 정보 교환을 표준화하고 컨트롤할 수 있게 된다.
[3] 레벨 3 : Process Integration(<그림 7>)
레벨 3에서 기업은 드디어 애플리케이션 간의 데이터 공유의 차원을 넘어서 애플리케이션 간 정보 흐름을 관리할 수 있게 된다. 다시 말하면 비즈니스를 통합하게 되는 것이다.
[4] 레벨 4　: External Integration(<그림 8>)
통합의 최상위 단계는 진정한 의미의 기업 간 통합을 이루는 단계라고 말할 수 있다. 이 단계에서 기업은 공급자, 고객을 기업 내 애플리케이션에 직접 통합해 그야말로 가상기업을 실현하게 되는 것이다.

<그림 5>　Point-to-Point Integration

<그림 6>　Structural Integration

<그림 7>　Process Integration

<그림 8>　External Integration

통합을 위한 다양한 기술들
<그림 9>는 다양한 통합 기술들의 레이어를 보여주는 그림으로서, 포레스터에서 제시한 것이다. 통합 기술은 분류하는 사람마다 조금씩 다를 수 있으나 여기에서는 데이터 레벨의 통합, 애플리케이션 레벨의 통합, 프리젠테이션 레벨의 통합, 프로세스 기반의 통합으로 구분했다.

<그림 9> 다양한 통합 기술들(출처 : 포레스터)

통합 기술에 대해서는 뒷편에서 자세히 다루므로 여기에서는 앞에 표시된 기술들에 대해 간략히 소개하고 넘어가도록 하겠다.

- BPM(Business Process Management) : 프로세스에 대한 디자인, 통합, 모니터링
- EAI(Enterprise Application Integration) : 애플리케이션 간의 통합
- Workflow : 업무 처리에 대한 흐름 관리
- EDI(Electronic Data Interchange) : 표준 업무 문서에 대한 전자 교환
- Portal : 프리젠테이션 레벨의 통합
- Mobile Adaptation : 무선 기기에 대한 통합 지원 기능
- Distributed Objects/Services : 오브젝트 레벨의 통합
- Host Integration : 메인프레임에 대한 통합
- EII(Enterprise Information Integration) : 메타데이터를 이용해 여러 소스로부터의 데이터를 실시간으로 통합된 뷰 제공
- ETL(Extraction, Transformation and Loading) : 배치 기반의 고용량 통합
- Distributed DBMS : 데이터를 공유하기 위해 분산 스키마, 동기화 등의 기술 이용
- Data Replication : 두 개 이상의 떨어진 데이터 소스 사이의 데이터 동기화 및 복제

<그림 9>의 레벨에 따른 통합 기술들 외에 웹 서비스와 SOA(Service-Oriented Architecture), ESB(Enterprise Service Bus) 등이 최근 주목을 받고 있는 기술들이다. ESB는 개념이 나올 때만 해도 웹 서비스, JMS 등 표준에 기반한 통합 기술로서 경량의 EAI라고 알려졌으나 현재는 SOA를 구현하기 위한 백본이 되는 기술로 포지셔닝하고 있다.

이렇듯 통합을 위한 다양한 기술들이 존재하지만, 필자가 강조하고 싶은 것은 하나의 통합 기술이 모든 통합 문제를 해결해 주지는 못하며 또한 그렇게 해서도 안 된다는 점이다. 통합 이슈가 생기는 문제부터 파악하고 그에 맞는 적절한 해법을 활용해야 할 것이다.

통합시 고려사항
통합을 시도할 때 무엇을 고려해야 할까? 먼저 통합의 목적을 명확히 해야 하며 그 목적은 기업의 비즈니스 전략과 맞아 떨어져야 한다. 단순히 다른 곳에서 통합을 한다고, 또는 통합이 유행이니까 한다는 자세는 버려야 한다. 자신에게 왜 통합을 할 필요가 있는지를 명확히 하지 않으면 투자한 만큼 효과를 얻지 못할 것이다.

둘째, 통합을 통해 얻을 수 있는 가치를 파악해야 한다. 통합의 목적을 정당화하기 위해서는 통합을 통해 얻을 수 있는 가치를 정의해야 한다. 물론 정확한 ROI 측정이 쉽지만은 않은 작업이지만 이렇게 통합에 대한 가치를 먼저 생각해야만 통합이 한때의 유행으로 그치지 않을 것이다.

셋째, 통합 레벨에 맞는 적절한 해법을 찾아야 한다. 예를 들면, 데이터 수준의 통합을 위해서 고가의 솔루션을 도입한다는 것은 이치에 맞지 않는다. 대부분의 통합 솔루션은 데이터 통합부터 프로세스 통합까지 지원하고 있고, 이에 따라 솔루션 도입에 고가의 비용을 필요로 한다. 데이터 수준의 통합만으로 만족한 조직이라면 전체적인 통합 인프라의 도입을 지양하거나 미들웨어 솔루션을 검토해 IT 비용을 줄여야 한다.

넷째, 예상되는 통합 이미지가 통합의 목적과 일치하는지 확인해야 한다. “어떻게 통합을 구현할 것인가”에 집중하다 보면 원래의 통합 목적과 거리가 먼 통합이 될 수 있다. 통합 후 예상되는 프로세스나 시스템의 변경이 통합의 목적과 일치되는 방향으로 나가고 있는지 수시로 확인해야 한다.

다섯째, 단순하면서도 큰 효과를 볼 수 있는 영역에서부터 점진적으로 추진해야 한다. 단순반복 업무의 자동화 등과 같이 단순하면서도 운영상의 부담을 줄이거나 정확성을 기해야 하는 프로세스들부터 통합을 적용해 점진적으로 전체 프로세스가 통합될 수 있도록 추진해야 한다.

여섯째, 통합 전문가를 육성해야 한다. IT 환경이 점점 더 복잡해짐에 따라 이러한 다양한 환경을 이해하고 적절한 통합 해법을 제시해 줄 수 있는 전문가가 각광을 받을 것이다. 기업들은 이러한 통합 전문가들로 구성된 ‘통합 역량 센터’(Integration Competency Center)를 운영하고 이들에 대한 전폭적인 지원과 육성을 아끼지 말아야 한다.

통합 전문가가 갗춰야 할 자질 IT 리서치 기관인 포레스터는 통합 전문가가 되고 싶어 하는 이에게 다음과 같이 요구하고 있다. 점점 통합이 중요해지는 이 시점에 통합 전문가가 되고 싶어하는 사람들은 한번쯤 마음에 새겨 봄직할 것이다.

[1] 통합 기술이나 툴에 대한 해박한 현장 경험과 지식을 갖추어라.
[2] 통합을 위한 다양한 대안을 제시할 수 있도록 준비하라.
[3] 개발 방법과 프로세스에 대한 전문가가 되어라.
[4] 아키텍처에 대해 이해하라.
[5] 조직 내 애플리케이션과 데이터 소스에 대해 알고 있어라.
[6] 복잡한 프로젝트에 대한 관리 능력을 키워라.
[7] 효과적인 커뮤니케이션 및 협상 능력을 갖춰라.

통합의 미래
통합의 미래는 과연 어떻게 될 것인가? 대략 BPF(Business Process Fusion)와 SOA(Service-Oriented Archtiecture)라는 두 가지 측면에서 먼 미래를 가늠해 볼 수 있을 것 같다.

BPF는 2003년 가을 가트너가 발표한 개념으로서 단순한 기업 간의 정보 통합이나 업무 프로세스 개선을 넘어서 정보와 업무 흐름의 완전한 통합을 말한다. 다시 말하면, 단순한 정보의 통합을 넘어선 프로세스의 통합 및 관리, 지원에 이르는 모든 경영 업무의 통합 관리를 일컫는 새로운 의미의 기술 기반을 의미하는 것이다. 또한 특정 업무 영역의 흐름만을 따르는 처리 방식이 아니며 업무 영역 안에서도 다양하게 분리되어 있는 이벤트 중심의 업무 프로세스들 간의 조합을 꾀함으로써, 실시간 기업 환경에서 일어나는 다양한 문제들에 대해 효율적이면서도 신속한 대처를 가능케 하는 방법이다.

<그림 10> BPF로의 발전 예시도(출처 : 가트너)

BPF는 단절돼 있던 업무간의 경계를 헐고 기업의 활동에 새로운 넓은 시각과 업무 흐름의 통제력을 제공하고 변화에 민감하게 대처할 수 있는 능력을 갖게 해주며, 그런 의미에서 완전한 통합을 제공한다고 말할 수 있다.

이러한 BPF를 구현하기 위해서는 무엇을 해야 하는가? 먼저 엔드-투-엔드 프로세스 방식의 시스템 통합이 필요하다. BPF 하의 통합은 SOA를 이용한 엔드-투-엔드 프로세스를 지원하는 시스템 통합이 중점이 되어야 한다. 또한 애플리케이션 간에 같은 성향을 가진 업무 처리 프로세스들을 통합하는 ‘수평적 통합’과 업무 처리 프로세스와 데이터 관리 시스템간의 ‘수직적 통합’이 동시에 이뤄져야 한다.

또한 설계나 코딩의 중복 없이 변경·제어가 쉽게 이뤄지는 애플리케이션의 개발이 필수적이다. 마지막으로 사용자 관점에서의 모든 업무 정보의 통합과 공유가 이뤄져야 한다. 이러한 BPF가 구현되기 위한 아키텍처로 최근 각광받고 있는 것이 SOA이다.

SOA란 서비스 기반의 아키텍처로서, 서비스를 디자인하고 개발하고 조립해 새로운 애플리케이션을 구축하는 방식 또는 그 기반이 되는 기술들과 아키텍처를 말한다. CORBA나 MOM(Message-Oriented Middleware) 등 다양한 기술들이 SOA를 가능하게 할 수 있었지만 현재 SOA를 구현하기에 가장 적합하다고 평가되는 기술은 웹 서비스이다. 사실 SOA라는 개념은 나온 지 꽤 됐으나 최근 웹 서비스 도입이 증가함에 따라 SOA도 같이 화두가 되고 있다고 볼 수 있다.

가트너는 오는 2008년까지 새로운 애플리케이션의 75%에 SOA가 적용될 것이라고 전망하고 있으며, 포레스터는 SOA를 도입함으로써 통합 프로젝트의 개발, 유지보수 비용을 30% 이상 절감할 수 있다고 보고한 바 있다. 지난 상반기에는 IBM, BEA 등 주요 업체들이 SOA에 대한 전략을 발표해 업계의 관심을 불러 일으키고 있다.

<그림 11>은 지난 2월호 The Harvard Business Review지에 실린 델타 항공의 SOA 적용 사례이다. 델타 항공은 6000만 라인의 코드로 된 30개 이상의 IT 플랫폼을 운영하고 있었는데, 이들 간에는 전혀 통합이 되어 있지 않아 많은 문제점을 야기하고 있었다. 예를 들면, 관제탑에 의한 게이트 변경이 승무원뿐만 아니라, 기내식 준비 요원, 예약 담당자, 정비사, 화물 수송자 등에게 전달되어야 하나 IT 통합의 부재로 인해 제대로 된 정보는 제때에 전달되지 못했다.

이러한 문제점을 해결하고자 델타 항공은 1998년부터 2003년까지 분산되어 있는 IT를 ‘Delta Nervous System’이라는 아키텍처로 통일했다. 즉 고객, 비행, 스케쥴, 직원에 대한 데이터베이스를 통합했으며 모든 애플리케이션과 인프라를 연결하는 공통된 미들웨어를 구축한 것이다. 이렇게 함으로써 델타 항공은 모든 정보를 공유할 수 있게 됐으며 필요할 때는 손쉽게 상위의 애플리케이션을 큰 어려움 없이 교체할 수 있게 됐다.

<그림 11> 델타 항공 사례(출처 : 하버드 비즈니스 리뷰)

“지금은 통합 전문가가 필요한 때이다”
앞서도 말했듯이 통합은 이제 기업의 최우선 전략 중의 하나로 인식되고 있다. 모든 기업이 통합을 기업 경영의 화두로 올리고 있다. 그러나 통합은 단 한 번에 모든 것이 이뤄지는 것이 아니다. 또한 하나의 기술이나 솔루션으로 모든 통합 문제를 해결할 수 있는 것도 아니다. 따라서 점점 복잡해지는 IT 환경 하에서 어떤 기술이 또는 어떤 솔루션이 문제를 해결해 줄 수 있을지 능수능란하게 해법을 제시할 수 있는 통합 전문가가 어느 때보다도 중요해지는 때이다. @


 

정리 | 조규형 | jokyu@korea.cnet.com

참고 자료

❶ 홍정기, ‘EAI 구현 전략과 사례’, 시사컴퓨터

❷ Charlie S. Feld, Donna B. Stoddard, ‘Getting IT Right: Delta Air Lines’, The Harvard Business Reivew

❸ www.eaijournal.com, Enterprise Architecture and J2EE

❹ Ken Vollmer, ‘Staffing The Integration Competency Center’, 포레스터