마이크로소프트웨어 2004년 10월호
이현철 mmouse@elasticware.com
일래스틱웨어 (eLasticWare ) 선임연구원 . 잡지 기자 출신으로 IT 에 뛰어들어 현재 .NET 어플리케이션을 개발하고 있다 . 인간중심 인터페이스에 관심을 가지고 있으며 , 최근 사용자 경험과 테스크 분석 등 실증적 방법을 바탕으로 누구나 쉽게 컴퓨터와 커뮤니케이션 할 수 있는 UI 찾기에 푹 빠져있다 .
이승준 plusjune@elasticware.com
일래스틱웨어 (eLasticWare ) 대표 . Microsoft MVP . 클라이언트 관련기술과 임베디드 관련 제품개발에 매진하고 있으며 , 주로 프로세스 관련한 소프트웨어 설계 / 구현 작업을 하고 있다 .
여러 가지 시스템을 운용하는 입장에서 여러 시스템의 관리 화면들을 한번에 묶어서 볼 필요성이 생긴다 . 이렇게 간단한 수준의 웹 페이지 통합에서부터 , EAI 차원의 UI 통합 그리고 , 클라이언트 프레임워크를 도입하는 SOA 수준의 UI 통합까지 다양한 차원의 UI 통합이 존재한다 . 사용자 인터페이스 (User Interface, UI) 통합에 대한 정의를 한마디로 명확하게 하기는 힘들며 , 통합을 여러 가지 관점에서 정의 할 수 있지만 결국 공통적인 목표는 어플리케이션 개발의 생산성과 기획부터 구축에 이르는 반복적인 라이프사이클을 단축하여 비용을 절감하는데 있다 .
최근에 서버 의존적인 작업의 많은 부분을 클라이언트로 이관하여 , 클라이언트의 기능을 최대한 활용하는 리치 클라이언트 기술과 X 인터넷 기술이 UI 통합의 새로운 화두로 자리를 잡고 있다 . 표준화된 통신 방법과 유연한 개발방법을 제공함으로써 궁극적으로는 SOA 를 위한 프레임워크로 발전해 갈 것이다 . 다양한 각도에서 UI 통합의 의미와 그 활용에 대해 살펴보자 .
EAI 관점에서 UI 통합
90 년대를 거치면서 많은 회사들은 자동화를 위한 시스템을 도입했고 SAP, 오라클 ERP, PeopleSoft, Siebel 과 같은 패키지 솔루션을 도입했다 . 이들은 독립적으로 모두 좋은 성능을 가지고 있었지만 서로 융합할 수 없었기 때문에 정보의 섬이 만들어졌고 , 대부분 경우 고객정보와 같은 중복 데이터를 가지게 되었다 . 이런 이유로 중복된 데이터가 변경되면 관리자들은 수동으로 관련된 정보를 각 시스템에서 찾아 업데이트해야만 하는 불편을 감수해야 한다 . 이것은 바로 정책 적용의 지연과 관리 비용 증가로 나타났다 . 심지어 어떤 경우에는 시스템들 간에 데이터가 일치하지 않는 현상마저 발생하게 되었다 . 사람들은 여러 개의 데이터 진입점 , 데이터 무결성 파괴 , 데이터 고립화 등의 문제에 관심을 가지게 되었고 , 이를 해결하기 위해 시스템 통합을 선택했다 . 이렇게 EAI 가 탄생하게 되었다 .
EAI 구현방식은 여러 가지로 제시되지만 대부분 크게 3 가지로 요약된다 .
- 데이터 수준 통합 (Data-level integration)
- 사용자 인터페이스 수준 통합 (User interface-level integration)
- 어플리케이션 수준 통합 (Application-level integration)
여기서 이야기하는 사용자 인터페이스 수준의 통합이 우리가 살펴보고자 하는 UI 통합의 개념을 지니고 있다 .
UI 통합을 위해 한 시스템과 연결되어 데이터를 다른 형태로 변경시키는 역할을 수행하는 인터페이스 엔진들이 사용되기도 한다 . UI 통합 다른 통합방법과 마찬가지로 복잡한 금융 시스템이나 병원 시스템과 같은 크고 다양한 시스템이 혼재되어 있는 곳에 적용 된다 .
UI 수준 통합은 실질적으로 여러 시스템에서 제공되는 다양한 소스를 사용하지만 최종 사용자에게는 통합된 UI 를 제공하는 것을 말한다 ( 사용자 인터페이스에 로직을 결합시키는 것이다 ). 이것을 스크립팅 (******ing) 기반의 UI 통합이라고 한다 . 클라이언트 / 서버 기반의 어플리케이션처럼 UI 의 이벤트내에 로직을 포함시킨다 .
이와 다른 방법으로 프록시 (proxy) 를 기반으로 하는 UI 통합도 있다 . 대표적인 사례가 바로 스크린스크래핑 (screen scraping) 기술이다 . 스크린스크래핑은 화면에 보여지는 내용을 가공하여 처리하거나 다른 시스템으로 전달하는 방법을 말하는데 , 주로 호스트 시스템을 연동하거나 혹은 이전 시스템을 수정할 수 없는 경우에 주로 쓰인다 . 다시 말해 , 통합의 대상이 되는 시스템을 수정하기 힘든 레거시 (legacy) 을 통합하는데 주로 쓰인다 . ( 데이터베이스를 쉽고 직접적으로 액세스 할 수 없거나 비즈니스 로직이 이미 인터페이스에 포함되어 있을 경우 UI 수준 통합이 유용하다 ). 메인프레임과 C/S 어플리케이션이 UI 수준 통합의 전형적인 대상이다 . 메인프레임은 일반적으로 데이터 저장소 접근이 용이하지 않고 , 일반적인 API 를 제공하지 않는다 . 그래서 , 많은 C/S 어플리케이션은 비즈니스 로직을 클라이언트에 내장한다 . 이러한 경우 UI 수준 통합은 데이터를 관리하고 액세스하는 유일한 통합 방법이 된다 .
사실은 UI 수준 통합은 어플리케이션 수준 통합이나 데이터 수준 통합만큼 추천되는 통합의 모델은 아니다 .
국내의 UI 통합
국내에서도 많은 기업들이 EAI 에 관심을 가졌고 , 다양한 방법으로 통합이 진행되었다 . 그러나 최근 금융권 , 특히 합병으로 거대해진 은행을 중심으로 이슈가 되고 있는 UI 통합은 단순히 EAI 방법의 하나로 보기에는 조금 다른 확장된 면모를 가지고 있다 .
최근 금융권에서는 기업 간의 합병으로 규모는 거대해지고 있으며 , 신용카드나 방카슈랑스의 도입으로 업무는 다양화되고 , 폰 뱅킹과 인터넷 뱅킹에서 나아가 PDA 나 이동전화를 통한 모바일 서비스 , 심지어 디지털 TV 를 통한 업무에 이르기까지 사용자 인터페이스는 더욱 다양해지고 있다 .
이로 인해 시스템은 이미 복잡해 질 만큼 복잡해져 버렸고 , 기존처럼 새로운 인터페이스별로 시스템을 구성하는 방법으로는 여러 가지 문제점을 낳게 되었다 . 외부 환경의 변화가 발생하거나 정책이 변동되면 일일이 모든 시스템을 업데이트해야만 하고 이 과정에서 많은 비용이 추가된다 . 또한 , 사내 업무용으로 활용되는 다양한 시스템들로 인해 통합과 유지 보수의 필요성이 데이터 수준과 어플리케이션 수준에서뿐만 아니라 사용자 인터페이스 (UI) 의 라이프사이클까지 고려하게 되었다 .
도입된 솔루션이 다양해지면 둔해진 반응과 복잡한 채널로 증가하는 유지보수 비용을 위해 또 다른 해결책이 필요하게 된 것이다 . 최근의 UI 통합은 이러한 필요성과 유지보수 비용문제를 해결하기 위한 솔루션의 개발과 도입으로 진행되고 있다 . 최근 대형 프로젝트를 준비하고 있는 국민은행과 신한 - 조흥은행이 이러한 대표적인 사례이다 .
UI 통합 이슈
UI 통합을 EAI 의 ‘UI 수준의 통합 ' 에서 논의되는 수준을 넘어 실질적인 의미로 재정의 해볼 필요가 있다 . 결국 UI 통합이란 다양한 클라이언트 개발에 소요되는 비용을 줄이고 , 사용자 인터페이스와 채널을 통합적으로 관리하려는 노력으로 볼 수 있다 . 즉 , ‘UI 를 통합한다 ' 기 보다 . “ 통합적인 방법으로 UI 를 라이프사이클을 관리 하는 방법 ” 으로 재정의 해야 할 것이다 . 물론 다양한 방법으로 UI 통합을 바라볼 수 있겠으나 , 보다 구체적이고 실질적인 측면에서 UI 통합이슈들을 정리해 보자 . UI 통합 이슈는 크게 ‘ 클라이언트 이슈 ', ‘ 서버 이슈 ', ‘ 개발지원 이슈 ' 의 3 가지 이슈로 정리해 볼 수 있다 .
UI 통합 ? 클라이언트 이슈
UI 통합에서는 클라이언트 기능이 강조되기 때문에 , 클라이언트는 리치 클라이언트 (Rich Client) 혹은 X 인터넷 기반으로 이루어 진다 . 클라이언트를 구성하는 기능들은 컴포넌트로 이루어지며 , 클라이언트에 따라 필요한 컴포넌트가 설치되어 수행된다 . 화면을 구성하는 UI 컴포넌트와 데이터를 처리하는 데이터 컴포넌트가 대표적이다 .
- 데이터 컴포넌트 ? 데이터 처리 및 클라이언트의 도큐먼트 (document 혹은 model) 을 관리한다 . 경우에 따라 로컬 데이터베이스를 관리하기도 한다 .
- UI 컴포넌트 ? 스크립팅으로 손쉽게 사용할 수 있는 그리드 컴포넌트 (grid), 리포트 컴포넌트 (report), 프린팅 한다 (printing) 와 UI 를 구성하는 메뉴 (menu), 트리 뷰 (tree view) 등의 UI 컨트롤을 제공한다 .
UI 통합 ? 서버이슈
UI 통합을 위해 사용되는 서버는 클라이언트에 배포되는 컴포넌트를 관리한다 . 타 시스템과 연결하는 데이터 통합 서버 (data integration server) 의 역할을 수행하기도 하며 CMS(Content Manage System), 인증 시스템등과 연결 고리 역할을 수행하기도 한다 . 주로 다음과 같이 이슈들이 있다 .
- 배포관리 ? 클라이언트에 배포되는 모듈을 관리하고 , 클라이언트의 종류에 따라 서비스를 관리한다 .
- UI 엔진 - 데이터를 수집하거나 다른 시스템과 연결하는 기능을 가지는 UI 엔진을 포함할 수 있다 .
- 다른 시스템과 연결 ? 인증서비스 , 캐쉬 서비스 등을 관리하거나 중재 하는 기능을 제공할 수 있다 .
- 동적 UI 생성 ? 화면상의 변경 혹은 변화된 내용을 생성하여 , 배포관리와 연결된다 .
UI 통합 ? 개발지원 이슈
UI 개발 및 유지보수는 화면을 손쉽게 만들 수 있도록 하는 것뿐만 아니라 , 수정이 용이하게 하고 , 데이터와 연결을 손쉽게 하도록 지원하는 것을 말하다 . 미려한 UI 를 생성하는 것 못지 않게 특히 , 리포트 생성이나 프린팅 등의 기능과 데이터 매핑을 지원이 필요하게 된다 .
단말 시스템 통합 구성 모델
[ 그림 1] 은 크게 ‘ 클라이언트 이슈 ', ‘ 서버 이슈 ', ‘ 개발지원 이슈 ' 가 적용된 단말 시스템을 통합한 구성 모델을 보여주고 있다 . Mode-Presenter-View 층 뿐만 아니라 , 기획 / 운용 / 관리 측면에의 시스템 운용도 고려를 해보아야 한다 .
[ 그림 1] 단말 시스템 통합 구성 모델
UI 통합의 기술 이슈
UI 통합의 범위는 워낙 크고 다양해서 , 자칫 피상적인 논의가 될 가능성이 크다 . 따라서 , 좀더 구체적인 내용으로 UI 통합에 따르는 기술적인 이슈에 대해 살펴보자 . 기술적인 측면에서 검토일 뿐 , 아래 논의되는 모든 것을 충족해야 한다거나 반드시 이렇게 구현되어야 한다는 것은 결코 아니다 . ( 전반적인 트랜드와 시장의 요구사항을 볼 때 대략 이러한 내용이 될 것 이라는 내용이며 , 다소 주관적인 견해임을 미리 밝혀둔다 )
인터페이스 엔진 / 통합 엔진 (interface engine)
기존 시스템으로부터 필요한 데이터를 추출하는 역할을 담당하는 시스템으로 다양한 기각 시스템과 연동하기 위해 적당한 인터페이스 (SNA, EJB, TCP/IP, DB 등 ) 를 제공 한다 . 여러 가지 데이터 소스를 하나의 인터페이스로 처리 , 관리함으로써 거래구현 및 유지보수 비용을 절감하는 효과가 있다 . 또한 기존 시스템의 변경을 최소화 하면서 채널을 통합해 정책을 신속히 적용할 수 있다 .
UI 생성 엔진 (UI Generation Engine)
통신을 통해 받은 데이터를 기반으로 클라이언트의 인터페이스를 생성하는 엔진이다 . 가지고 있는 프레임워크를 기반으로 화면을 동적으로 생성하고 이벤트에 해당하는 스크립트를 통해 화면간 호출 , 이동 , 데이터 연동을 지원한다 . 단순한 웹 화면에서 벗어나 다양한 인터페이스 도구를 지원할 수 있고 마우스 외에 키보드 , 메뉴 , 핫키 , 단축키와 같은 편리한 인터페이스를 제공할 수 있다 . UI 를 생성하는 표준적 표현으로 가장 주목 받는 것인 W3C 의 XForms 이지만 , XML 의 특성상 다양한 변환이 가능하여 다양한 표준들이 등장하고 있다 .
클라이언트 스크립팅 (Client ******ing)
사용자 인터페이스는 아무리 정형화하여 적용하여도 , 주어진 패턴으로는 항상 한계가 있으며 , UI 에서 상호작용을 기술하는데 충분하지 못하다 . 그래서 , 스크립팅 (******ing) 이 필요하게 된다 . 현재 스크립팅 언어의 표준으로 가장 널리 받아 들여지는 것이 ECMA ****** 이다 .
넷스케이프의 Java****** ( 원래 이름은 Live ******), IE(internet explorer) 의 J******, 플래시의 Action******, 모두 ECMA ****** 를 기반으로 하고 있다 .
통신 (Communication)
UI 를 담당하는 각 장치와 서버는 통신을 통해 사용자 요청과 데이터를 주고받는다 . 이러한 통신은 리모팅 서비스나 표준화 메시지인 XML 을 바탕으로 하는 XML 웹 서비스 (SOAP) 을 사용한다 . 기존 시스템 환경이 동일하거나 융합할 수 있는 기종으로 구성되어 있을 경우에는 JAVA RMI/IIOP 나 .NET 리모팅 (.NET Remoting) 과 같은 기술을 적용할 수 있지만 이 기종으로 구성되어 있을 경우와 이 기종간 통합이 예상될 때에는 XML 웹 서비스가 가장 좋은 해결책이다 .
버전관리 (Version Management)
클라이언트에 제공되는 UI 엔진을 자동배포하고 이를 최신 버전으로 관리한다 . 버전 관리자는 JAVA 애플릿이나 ActiveX 와 같은 기술을 바탕으로 클라이언트 장치에 알맞은 프레임워크를 제공하며 , UI 프레임워크가 설치된 클라이언트가 항상 최신 버전을 유지하도록 관리하는 기능을 가진다 .
개발지원
특히 빠른 시간에 기존 화면과 유사한 인터페이스를 개발 할 수 있는 도구를 제공한다 . 개발지원은 UI 개발의 생산성과도 밀접한 관련이 있기 때문에 , 편리하게 개발하고 개발된 내용을 테스트 할 수 있는 환경이 필요하다 . 또한 , 화면의 컨트롤과 데이터가 어떻게 여로 연결이 되는지를 편집하는 매핑도구 (mapping tool) 역시 UI 개발의 생산성을 높이는데 중요한 요소이다
기타 이슈
이동성 있는 클라이언트의 경우 오프라인상에서도 온라인일 때와 똑같이 사용이 가능하도록 오프라인에 대한 지원이 필요하다 . 일반적으로 데이터 동기화 (Data Synchronization) 을 제공한다 .
UI 통합 솔루션
UI 개발의 큰 문제 중의 하나가 UI 개발에 사용된 코드의 재사용이 어렵다는 점이다 ( 화면 기획을 제외하면 , UI 개발은 개발자 성향에 매우 의존적이다 ). UI 에 사용되는 컴포넌트를 제외하고 , 대부분의 UI 와 UI 관련 코드는 재사용되지 못하고 버려진다 . 개발자의 성향에 매우 의존적인 UI 의 표준화를 통해 개발의 생산성을 향상시키고 , 재사용 가능성을 높이며 보완 관리를 빠르게 하기 위해 다음과 사항을 고려해야 한다 .
- 뷰 (view) 와 상호작용 (interaction) 의 분리
- 서버와 통신 표준을 단순화
- 클라이언트 데이터 모델 표준화
- UI 와 데이터 모델 재사용
UI 통합을 설계하는 데는 여러 가지 방법이 있겠지만 크게 두 가지로 구분해 볼 수 있다 . 하나는 서버 측에서 각 디바이스에 맞도록 데이터를 가공해 연결할 수 있는 인터페이스를 두는 것이고 , 다른 하나는 동일한 데이터를 제공하는 서버에 연결되는 디바이스가 각각 알맞은 프레임워크를 지니도록 설계하는 것이다 . [ 그림 2] 은 4 가지 종류의 클라이언트와 여기서 사용 될 수 있는 표준적인 영역을 보여준다 ( 그림에서 진하게 표시된 부분이 표준적인 프레임워크로 자리잡을 수 있는 영역을 말한다 ).
[ 그림 2] 4 가지 클라이언트 모델
최근 후자의 경우와 같이 클라이언트에 기능을 위임하는 리치 클라이언트 방식이 다양한 인터페이스와 전송부하를 줄일 수 있어 주목 받고 있으며 , 대표적이 것이 X 인터넷 솔루션들이다 . 매크로미디어의 플래시 , JAVA 를 바탕으로 하는 알티오 (Altio), 그리고 마이크로소프트의 닷넷 스마트클라이언트 등이 있으며 , 국내에서도 많은 업체들이 X 인터넷 솔루션을 제공하고 있다 .
서버 사이드 통합
서버 사이드 통합의 경우 어플리케이션 레벨 통합을 시행하고 여기에 각 디바이스에 맞는 프리젠테이션 레이어를 둔다 . [ 그림 3] 에서 Winform 기반의 인터페이스와 Web 인터페이스 , 모바일 인터페이스를 가지고 있다 . 비즈니스 레이어에는 뉴스를 제공하는 News 서비스와 고객가입을 담당하는 Costomers 서비스가 있고 , 이를 어플리케이션 레이어에서 통제한다 . 프리젠테이션 레이어에는 각각 일반 웹 기반 UI 를 위한 WWW Transformer 와 모바일 기기를 위한 WAP Transformer 을 가지고 있다 . 이들로부터 HTML 데이터를 받은 각 기기는 브라우저 기반을 통해 페이지를 생성 한다 .
[ 그림 3] 무선 채널 통합 ( 출처 : IBM, Wireless integration)
리치 클라이언트
서버 사이드 통합은 모든 변환 과정을 서버에서 처리해야 하기 때문에 서버에 부하가 크고 통신 부하도 늘어난다 . 이를 해결하기 위해 서버에 구현되는 변환과정을 클라이언트에 부여하는 방식이 리치 클라이언트이다 . 스마트 클라이언트 또는 팻 (fat) 클라이언트라고도 불리는 이 방식은 각 디바이스에 적절한 프레임워크를 배포하고 이를 이용해 인터페이스를 디바이스에서 직접 생성한다 . 서버나 통신 부하를 줄일 수 있을 뿐만 아니라 웹의 한정적인 인터페이스에서 벗어나 다양한 구성을 가능하게 한다 . JAVA 의 애플릿이나 최근 주목 받고 있는 X 인터넷이 이에 속한다 . X 인터넷의 경우 , XML 메시지로 데이터를 표준화하고 스크립트와 같은 방법을 이용해 이벤트를 처리하게 된다 . 각 디바이스는 배포관리를 통해 항상 최신의 프레임워크 사용할 수 있다는 장점을 가진다 . 서버와의 통신 방법은 리모팅이나 HTTP 를 이용하는 XML 웹 서비스를 사용할 수 있다 . 클라이언트와 서버가 호환 가능한 기종으로 구성되어 있을 경우에는 리모팅을 사용할 수 있지만 , 이 기종으로 구성되었거나 확장가능성이 크다면 XML 웹 서비스를 사용하는 것이 유리하다 .
X 인터넷 기반의 UI 통합
미국 유수의 시장조사·분석업체 포레스터 리서치 (www.forrester.com) 에서는 “X 인터넷 ” 의 첫 단계를 “ 웹을 통해 사용자 중심의 풍부한 기능을 가진 지능적 애플리케이션을 서비스 하는 것 ” 이라고 정의하고 있다 .
이처럼 X 인터넷은 기존에 클라이언트 / 서버와 같은 소프트웨어가 가졌던 풍부한 기능을 웹 상에 구현함으로써 차세대 애플리케이션을 실현 가능케 하고 있으며 사용자가 어느 장치에서나 애플리케이션을 구현 가능하도록 해 주는 기술이다 . 하나의 어플리케이션을 웹 , C/S, 모바일 환경에서 모두 작동시킬 수 있다는 이점으로 UI 통합에 가장 큰 이슈가 되고 있다 . 배포가 용이한 Web 의 장점과 다양한 인터페이스를 제공할 수 있는 C/S 아키텍처의 장점만을 용합해 일반 브라우저뿐만 아니라 , 전용브라우저 , PDA, 이동전화 등 기업의 다양한 IT 환경에 맞추어 서비스가 가능하다 .
더구나 모든 시스템을 전면 개편하기 보다는 단계별로 기존 시스템들을 교체하지 않고 , 4GL 을 이용하여 개발된 시스템이나 레거시 시스템과도 직접적인 연동을 지원할 수 있기 때문에 기업의 필요에 따라 단계별 확장 및 대체가 얼마든지 가능하다 . 결국 X 인터넷 기술이 제공하는 것은 다음과 같이 요약 될 수 있다 .
- 클라이언트와 서버간에 표준화된 통신방법
- UI 를 기술 (describe) 하는 표준적인 방법을 제공
- 표준화된 개발방법을 제공
UI 통합 모델
이제 앞서 이야기한 다양한 기술적 배경과 이슈들을 바탕으로 하나의 모델을 제시해보려 한다 . ( 모델은 어디까지나 모델이다 . 실제 구체적인 상세 구현의 내용은 주변 상황에 따라 얼마든지 달라 질 수 있다 )
먼저 , 개념적인 개발 모델부터 살펴보자 . 필자가 제시하는 개발의 모델의 MVP(Model-View-Presenter) 패턴이다 . MVP 모델은 소프트웨어 개발의 패턴으로 널리 알려진 스몰토크의 MVC(Model-View-Controller) 을 발전시킨 패턴으로 MVC 모델보다 높은 유연성을 제공하는 설계패턴이다 ([ 그림 4] 참조 )
- Model : 도메인 데이터를 표현한다 . ( 내부에 selection 패턴과 command 를 가진다 )
- Presenter : 어플리케이션을 표현하고 조율한다 ( 다른 객체를 생성하거나 연결한다 )
- View : Model 의 전체 혹은 일부를 표시한다 .
MVP 는 계층적으로 구성되며 , ([ 그림 5] 참조 ) Model 과 View 는 Pluggable 하게 대체될 수 있다 . 
[ 그림 4] Mode-View-Presenter 사이의 상호작용
[ 그림 5] Model-View-Presenter 계층도
클라이언트가 공통적인 개발 및 유지보수 방법을 제공하려면 , 클라이언트 프레임워크를 가져야 한다 . 물론 , 닷넷의 CLR 혹은 자바의 J2SE 같은 환경은 클라이언트 프레임워크 역할을 수행하기에 좋은 기반이 되지만 , 이런 일반적인 목적 (general purpose) 의 프레임워크 못지 않게 , 특정 도메인에서 잘 사용될 수 있는 가볍고 유연한 프레임워크가 훨씬 좋을 수 있다 . Win32 클라이언트라면 COM 으로 구성된 COM 컴포넌트 라이브러리를 가지도록 설계될 수 있다 ( 사실상 현재 클라이언트는 Win32 클라이언트가 절대적으로 많다 )
[ 그림 6] 은 클라이언트 프레임워크가 갖추어야 할 내용들을 정리해 본 것이다 . ( 내용을 일반화하여 그린 그림이다 )
먼저 , 다양한 장치에 출력이 가능하도록 출력 부분이 교체가능 (pluggable) 해야 한다 . 즉 , View 부분만을 바꾸어도 적용이 가능해야 한다 . 또 , 표준적인 배포 패키지를 두고 , 화면을 구성을 기술 (describe) 하는 표준적인 방법이 제공되어야 한다 . 이때 , 화면을 디자인 하고 테스트 할 수 있는 도구가 함께 제공된다면 개발 생산성이 훨씬 높아 질 것이다 . 배포관리는 클라이언트가 항상 최신의 컴포넌트들을 유지하도록 한다 .
또한 , 프레임워크는 런타임 (Run-Time) 이 제공하는 다양한 기능들을 스크립트에서 손쉽게 사용할 수 있도록 한다 . 기본적으로 런타임은 화면 생성기능 , SOAP, HTTP, TCP 등 통신 기능 , 화면 출력 기능 , 프린팅 / 레포팅 등의 기능 등을 포함 한다 .
[그림 6] UI 프레임워크의 모델
UI 통합 ? EAI 관점이 아닌 SOA 관점에서
UI 통합은 ( 혹은 단말통합이라는 이름으로 진행되고 있다 ) 금융권과 같이 상당히 큰 규모의 시스템에서만 이슈가 된다 . 중소 규모 시스템에서는 UI 통합보다는 데이터통합이 훨씬 더 중요한 위치를 차지한다 . EAI 차원에서 볼 때 UI 통합은 에서 가장 마지막에 고려되는 것이다 . 즉 , 데이터 수준의 통합이나 어플리케이션 수준의 통합보다 우선 순위가 낮다 .
컴퓨팅 환경의 큰 발전 단계가 " 클라이언트 / 서버 " --> " 웹 기반 컴퓨팅 " --> "SOA" 가 될 것이라고 예측하는 전문가들도 상당 수 있다 . 그 만큼 SOA 는 이미 상당히 중요한 개념으로 자리 잡았다 . UI 통합 ( 혹은 단말 통합은 ) 은 EAI 차원에서의 접근보다 장기적인 안목의 SOA 차원에서의 접근이 더 옳다고 할 수 있다 . UI 통합을 EAI 차원이 아니라 SOA 차원에서 바라본다면 , 훨씬 다양하고 유연한 시스템 환경을 구축하고 그려낼 수 있을 것이다 . SOA 가 다른 모델과 크게 다른 특징으로 프로세스 ( 좀 더 정확히는 ‘ 비즈니스 프로세스 ') 를 위주로 정보시스템 인프라를 구축한다는 것과 느슨하게 결합된 (loosely coupled) 어플리케이션 개발 및 관리 아키텍처라는 점을 들 수 있다 .
단순 데이터 통합이나 기술적인 이슈를 통합의 모델로 삼는 것은 큰 효과를 거두기 힘들다 . 실제 통합을 추진하는 과정에서 가장 중요한 것은 비즈니스 모델과 기업내의 프로세스를 통합하는 것이기 때문이다 . 통합의 궁극적인 성패는 기술의 문제가 아니며 , SOA 역시 통합을 위한 바탕을 제공할 뿐임을 기억해야 할 것이다 .
