SOA기반의 데이터 거버넌스 아키텍처
▲ 김현철 수석컨설턴트 ㈜데이터스트림즈 컨설팅팀
지난호에서 우리는 차세대시스템을 유발시킨 원인과 그 해결을 위한 데이터 표준 및 품질 관리와 데이터의 실시간 처리 등 다양한 데이터 통합 및 관리 기술에 대해 알아보았다. 이제 현재 가장 앞서있는 개념인 SOA와 데이터 거버넌스에 대해 알아보고 우리는 어떤 방향으로 가야하며 어떻게 접근할까에 대해 같이 고민하는 기회를 갖고자 한다.
IT의 두 마리 토끼 애플리케이션과 데이터
필자가 처음 전공과목을 들었을 때 Data processing이라는 기초 과목에서 딱 한 줄로 표현되는 문장으로 배운바 있다.
Data processing = INPUT Data → Processing(=Application) → OUTPUT Data(=Information or Garbage)
얼마나 단순한가? 양질의 데이터를 잘 정리 하여 원하는 답을 얻는 것. 역으로 쓰레기 데이터가 들어가면 결과도 쓰레기란 의미. 그런데 Processing에 대해서는 그다지 강조하지는 않는다.
그것은 Data는 쉽게 못 바꾸지만 Processing 부문은 전산쟁이가 늘상 하는 업(業)이기 때문이기에 당연시 생각되기 때문인 듯하다. 이 단순한 것이 실제 IT의 현실에서 어떻게 표현될까에 대한 답은 그림으로 보여준다.
▲ <그림1> Application Data 관계
여기에 각종 시스템 및 외부데이터의 연계 등등을 가미하면 전산쟁이가 왜 3D업종이며 도시락 싸들고 말리는 사태가 벌어지는지 충분이 이해하리라 본다.
어쨌든 우리의 선배는 이 문제를 데이터 관점 및 Application 관점에서 각각 접근한 Data Modeling과 Process modeling의다양한 방법들을 창안했고 CRUD matrix 등으로 두 마리 토끼를 잡으려 무지하게(?) 애를 써왔음을 기억하고 있다.
데이터와 process 이 두 마리 토끼를 잡으려고 파생된 방법론과 개념이 얼마나 많은가?
예를 들어 구조방법론(Structure Analysis & Design), 정보공학방법론(Information Engineering ), 객체지향벙법론(OOA), 컴포넌트기반개발방법론(CBD)에 이어 이제는 아키텍처라는 용어까지 가세하여 MDA(model driven Architecture), EA/ITA(Enterprise Architecture), SOA(Service Oriented Architecture)라는 많은 개념들이 파생되고 있고 앞으로도 계속해서 데이터와 process는 하나의 통합을 위해 헤겔의 변증법처럼 정-반-합의 과정으로 진리에 도달할 때까지 끊임없이 발전할 것이다.
SOA의 등장과 개념
서비스 기반 아키텍처 즉, SOA는 Business의 변화속도에 대응하기 위한 SW의 변화된 구조를 설명하는 개념이다.
최근의 Business 성패는 서비스의 질에 좌우되고 서비스의 질은 누가 더 빨리 시장과 고객의 변화를 리드하거나 대응 할 수 있느냐에 있으며 이를 위해 Real Time Enterprise라는 꿈과 같은 비즈니스 프로세스 관리 모델을 가능케 하고 이를 지향하는 IT 아키텍처로 요구된 것이 SOA이며 이는 과거의 Software 구조로는 도달하기 아주 힘든 것이다.
Software engineering에서 보면 소프트웨어의 위기(Software crisis)라는 말이 등장한다. HW는 무어의 법칙에 따라 앞선 HW기술이 나오기까지 걸린 시간의 1/2 밖에 걸리지 않는 기간마다 2배 이상의 앞선 성능과 집적도로 발전하고 있다.
실제 불과 몇 킬로바이트 남짓한 데이터를 처리하기 위해 전 층을 꽉 채운 진공관 컴퓨터에서 손톱만한 크기에 수십 기가바이트의 데이터가 저장되는 이 시대까지 걸린 시간은 수십 년이 채 안 된다.
▲ <현재 복잡한 구조 >
그에 반해 Software는 그렇지 못했다. 수많은 개발자의 부산물들이 다음 세대에서 재활용되는 경우도 있지만 대부분이 아키텍처나 기술의변화로 사장되거나 버려지고 천문학적인 시간과 노력이라는 비용에 비해 터무니없이 비효율적이라는 것이 Software crisis이다. 이의 해결을 Software Engineering 쪽에서 끊임없이 연구한 결과 객체지향(Object oriented Methodology)을 거쳐 현실세계를 표현하는데 가장 적합한 모델링 기법인 UML과 RUP 등의 적절한 개발 방법론들을 이용하여 컴포넌트 기반 개발이 시작됐다. 이러한 컴포넌트들을 네트워크상에서 언제든 사용 가능한 서비스 단위로 재활용이 가능하도록 그룹화 및 객체화 하여 SOAP, Web service와 같은 공통의 의사소통 인터페이스 구조를 갖추게 한 것이 SOA이다.
이를 좀 더 세련된 말로 풀어보면 SOA는 기업의 소프트웨어 인프라를 구축하는 방법을 정의하는 것으로 기업의 정보시스템을 네트워크 상에서 공유와 재사용이 가능한 서비스와 컴포넌트 중심으로 묶는 IT 아키텍처다. 이는 시스템을 누구나 이용 가능한 서비스로 간주하고, 연동과 통합을 전제로 아키텍처를 만들어 시스템 개발 단계에서부터 불특정 다수의 사용자 및 외부 시스템까지 고려해 IT 프로젝트를 진행하도록 한다. 그다지 명쾌하지 않은 부분이 서비스와 컴포넌트의 구분이지만 서비스는 일반인들이 친숙한 용어이고 컴포넌트는 전산쟁이가 부르는 용어쯤으로 구분하고 넘어가고 아래 그림으로 대략 설명을 때우고자 한다.
여기서 주목할 것은 Application에서의 약결합(loosely coupling)이 밀결합 구조인 CBD와 차이점을 보이고 있다.
<이후 컴퓨터월드 2010년 2월 호 P74 참조>