블로그의 리퍼러(Referer) 검색어 통계를 보면 'X인터넷', 'x-internet 제품 비교'와 같은 X-인터넷 관련 키워드가 심심찮게 눈에 띄고 있다. 작년에 작성했던 'X-인터넷의 흐름, Smart Client 프로젝트를 마치고...'란 글 때문에 유입되는 방문자가 적지 않은 셈이다.
이 글에서 예전 프로젝트가 스마트 클라이언트 기반이었기 때문에 X-인터넷에 대해서 간단하게 언급한 바 있다. 스마트 클라이언트는 단순하게 정의하자면 닷넷 프레임워크 기반의 X-인터넷 개념이다. 포스트 내용은 프로젝트의 간략한 후기 정도라서 X-인터넷 솔루션 제품들의 비교 내용을 기대하고 들어왔었다면 실망하고 돌아가는 분들이 꽤 되지 않을까 싶다. ^^;
그 포스트를 올리고 바로 이어진 프로젝트에서는 Java 기반 플랫폼에서 티맥스소프트의 프로웹(ProWeb)이라는 X-인터넷 솔루션을 사용하였다. 경험치가 증가(?!)되었고, 왠지모를 죄책감도 들어 "X-인터넷 솔루션 제품의 비교와 선택"을 주제로 한번 얘기를 해볼까 한다. ^^
본론에 들어가기 전에 X-인터넷(X-Internet)과 RIA(Rich Internet Application)란 용어에 대해서 짚고 넘어가야 할 것 같다. 두 용어는 모두 화려한 기능과 유려한 디자인을 구현하는 사용자 인터페이스(UI)로 표현되는 Rich (Web) Client 기술에 대한 의미로 혼용되고 있어 구분이 모호하기 때문이다.
따지고 보면 두 용어의 태생부터가 다르다. X-인터넷이라는 용어는 2000년 10월에 포레스터리서치(Forester Research)의 CEO인 George F. Colony가 자사의 웹 페이지에 기고한 "MY VIEW: X INTERNET"이라는 글이 그 기원이라고 한다. X-인터넷이 인터넷 어플리케이션을 다루는 소프트웨어 패러다임이라고 할 수 있다면, RIA는 매크로미디어(현재의 어도비)의 플래시(Flash) 기술에서 유래된 용어로 특정 벤더에 의해 만들어진 개념이라고 할 수 있다.
따라서 태생적 관점에서 볼때 RIA 보다는 X-인터넷이 보다 크고 포괄적인 개념이라고 생각된다. 하지만 여러 자료를 참고하다보면 두 용어가 최근에는 거의 동일한 의미로 사용되고 있는 것 같은 느낌을 받는다. 오히려 웹2.0이 대두하면서 두 개념의 장점을 통합하여 RIA라는 용어로 통일되는 추세라고 한다.
RIA의 대표적인 기술로는 어도비(Adobe)의 Flash 및 Flex, AIR 플랫폼(어도비 통합 런타임, 코드명 Apollo)과 함께 Microsoft의 Silverlight와 WPF, 스마트 클라이언트(Smart Client) 등이 있다. 그리고 Sun의 JavaFX와 Java Applet, Ajax 및 DHTML 등에 기반한 기술들이 있는데 아무래도 Adobe와 MS의 경쟁이 치열하다.
RIA 시장의 기대주, 실버라이트와 플렉스, 자바FX 스크립트
국내 시장의 경우 국산 X-인터넷 관련 솔루션 제품들이 거의 독식하다시피 했는데, 최근에는 이들에게 적지않은 위협을 느끼고 있는 듯 하다. 이들 제품의 경우 Active-X나 에이젝스(Ajax)에 기반한 제품들이 대부분이었지만 X-인터넷이라는 용어 자체가 RIA 개념과 점차 통합, 확대되어가면서 RIA를 표방하는 제품들이 속속 등장하고 있다. 또한 웹표준 준수를 위해 Active-X도 점차 사용하지 않는 방향으로 가는 추세인듯 하다.
아마도 X-인터넷 관련 제품의 시장이 먼저 형성되었기 때문일까, 나의 경우 이들 제품들에 대해 "RIA 솔루션"보다는 "X-인터넷 솔루션"이란 이름이 왠지 더 친숙하다.
국산 제품으로는 마이플랫폼(MiPlatform, 투비소프트), 가우스(GAUCE, 쉬프트정보), 트러스트폼(TrustForm, 컴스퀘어), 오즈(OZ Xstudio, 포시에스), 프로웹(ProWeb, 티맥스소프트) 등이 있으며, 이들 중 마이플랫폼, 가우스, 트러스트폼이 주류라고 알고 있다. 오즈와 프로웹의 경우 국내 X-인터넷 시장의 후발주자격이다. '토종 빅 3(마이플랫폼, 가우스, 트러스트폼)' 제품들은 금융, 제조, 공공, 통신 등 여러 산업분야에 걸쳐 많은 레퍼런스를 확보하고 있으며, 국내 X-인터넷 시장 자체가 기업 내부용 시스템에서 대고객용 시스템 영역까지 확대(B2B->B2C)되고 있다고 한다.
IT 정보환경의 진화
이제 본론으로 들어가서 위에 언급한 솔루션 제품들과 그외의 수많은 제품 및 기술들을 어떻게 비교 및 평가하고 어떠한 변별 작업을 통해 취사선택할 것인가하는 문제를 제기해본다. 하지만 나 자신의 지식과 경험이 부족하므로 거창한 화두를 커버하기보다는 실제 프로젝트를 통해 접했던 부분들에 대해서만 언급해보고자 한다.
당연한 얘기지만 Enterprise Software 개발을 위한 UI 솔루션 선정에는 개발 측면, 성능 및 기능 측면, 유연성 측면, 기술지원 등 다양한 측면이 고려되어야 하며 이를 위해서는 업무를 잘 이해하고 있는 도메인 전문가와 시스템 요구사항에 대해서 잘 알고 Rich Client를 경험해본 아키텍트의 역할이 중요하다. 개인적으로 제품 선정에 아키텍트가 빠져서는 안된다고 생각하는데, 그렇지 않을 경우 전체 아키텍처를 구상하고 제품을 선정하는 것이 아니라 채택된 제품에 아키텍처를 맞춰야할 수도 있기 때문이다. 그리고 무엇보다 업무에 맞는 제품을 선택하는 것이 중요하다.
나의 경우 GUI 중심의 보기 좋은 화면을 만들어주는 플래쉬나 에이젝스, 실버라이트 등과 같은 기술을 사용해보지는 못했다. C/S와 유사한 UI를 보여주는 스마트 클라이언트는 사실 .NET의 'Windows Forms'이다. 일반 윈도우 폼과 다른 것이라면 UI의 배포 및 실행, 백엔드 서비스가 HTTP 프로토콜을 기반으로 한다는 것 뿐이다. 프로웹이라는 제품도 C/S 적인 UI를 보여주고 있다. 스마트 클라이언트와 다른부분이라면 Java 기반이라는 것이다. 이 둘은 모두 독립 실행과 브라우저에 내장되어 실행되는 두가지 모드를 지원한다. stand alone/browser embedded, jnlp mode/applet mode 등과 같이 용어는 다르지만 같은 말이다.
스마트 클라이언트 기반의 프로젝트를 수행하면서, 핵심 프레임워크를 구현하고 어플리케이션의 라이프 사이클 제어(실행, 배포, 캐쉬)하고 웹서비스와 연동하는 백엔드 구현부를 제공하고 기본 컴포넌트와 컨트롤 셋을 구현 및 지원하면서 개발의 제반 사항들에 관여를 하였다. 물론 모든 구현을 스스로 만든 것은 아니고 필요한 부분들은 오픈소스를 적극활용하였기 때문에 가능한 일이었다. 아무튼 이때의 경험은 자바 기반에서 프로웹으로 구현하는데에도 적지않은 도움을 주었다.
ProWeb 구성도
한가지 프로웹 기반의 프로젝트에서 프로웹이란 제품은 나에게 선택 사항이 아니라 주어진 조건이었다. 이미 프로젝트가 착수된 시점에 뒤늦게 투입되었기 때문이다. 프로젝트에 투입되고 나서 어플리케이션의 기본적인 구조를 설계하면서 내가 처음 한 작업은 이전 프로젝트의 경험을 기반으로 작성한 프로웹에 대한 질문 리스트였다.
이런 것은 구조적으로 가능한 것인지, 또 이런것들은 기술적으로 지원되는 것인지, 이런저런 컨트롤들에 대한 질문 리스트를 작성하여 티맥스에서 답변을 받았었다. 이런 것들을 바탕으로 기본적인 구조와 특징을 파악하고, 2주정도 기술지원을 나온 인력과 협의하여 어플리케이션의 기본 틀을 잡아나갔다.
어플리케이션 작성 샘플 화면
이때 만들었던 질문 리스트는 제품 결정 사후에 작성한 것이었지만, 내가 만약 제품을 결정해야 하는 입장이라면 사전에 이와 유사한 체크 리스트를 작성해서 제품들을 비교해보지 않을까 싶다. 경험적인 한계가 있지만, 몇가지 체크해야할 항목들을 정리해보았다. '일반적이고 비기능적인 사항'들과 '기능적인 사항'들로 구분하였다. 만들고자 하는 어플리케이션의 컨셉에 따라 첨삭해서 보면 될 것 같다.
[일반적이고 비기능적인 사항]
안정되고 검증된 솔루션인가?
일반적으로 레퍼런스가 많은 제품이 시장의 요구 사항이 잘 반영된 것이다. 가능하다면 다양한 채널을 통해 제품을 경험해본 사람들의 의견을 들어보는 것이 좋다.
당연한 얘기지만 제품은 업무의 요구 사항을 수용할 수 있어야 한다. 따라서 제품 자체의 구조와 기능을 체크해야 하고 만들고자 하는 시스템 전체의 구성과 레거시 시스템과의 연계를 고려해야 하고 여타 컴포넌트와의 연동이 가능한지 조사해야 한다.
후보군의 제품들을 벤치마크테스트(BMT)하거나 데모 및 시연을 통해 가능한 항목을 체크하여 비교 분석해볼 필요가 있다.
확장 가능한 유연한 아키텍처인가?
솔루션 제품의 아키텍처는 실제 시스템의 안정성과 개발의 효율에 절대적 영향을 갖는다.
계층화된 아키텍처(Layered Architecture)의 구조를 갖고 다양한 표준 데이터 소스와 연동할 수 있는 확장 가능한 구조인지 확인한다. 예를 들어 MVC 기반의 아키텍처를 지원한다면 개발 및 유지보수의 효율성 증대하고 각 계층의 독립성을 높일 수 있으며, XML 및 웹서비스를 지원한다면 타시스템과의 인터페이스가 수월해질 수 있다.
그리고 제품의 아키텍처와 제공하는 기술이 필요한 기능을 구현하는데 무리가 없는지 확인하고 구성 모듈(컴포넌트)의 종속성을 확인해볼 필요가 있다. 제품의 구조 자체가 개발의 제약 사항으로 작용하여 구현이 제품에 종속되는 일이 없도록 하여야 한다.
최근엔 개발시에 Spring, Struts, Hibernate, iBatis 등과 같은 일명, 대세 프레임워크(오픈소스)를 활용하는 것은 "선택이 아닌 필수"로 여겨진다. 상용 프레임워크나 자체 개발한 프레임워크를 사용한다 하더라도 구성 자체가 오픈소스를 활용하고 또 오픈소스를 지원하게끔 되어 있다. 따라서 X-인터넷의 UI 구성을 제외하고 백엔드(Data Access 부분이나 Business) 구현부를 기존 프레임워크나 잘 알려진 오픈소스를 사용할 계획이라면 이들에 대한 지원 및 연동 여부를 반드시 확인하여야 한다. 제품이 백엔드 구현부에 대한 프레임워크를 제공하기 때문에 그것을 사용하는 것을 고려하더라도 향후 운용중인 표준화된 서비스와 연계할 상황이 발생할 가능성을 배제할 수 없으므로 다른 일반적 프레임워크와 표준 기술을 지원하는 것이 좋다고 생각한다.
개발 환경은 어떠한가?
기본적으로 개발 언어 및 방식을 확인해야 한다. 개발 언어로 Java나 .Net 등과 같은 원하는 언어를 지원하는지 확인한다. UI 개발의 경우 자체 스크립트를 사용할 수도 있다.
중요한 것은 러닝 커브를 고려해야 한다는 것이다. 진입장벽이 낮고 개발자들의 접근성이 좋아야 한다. 오래전 일이지만, 자체 스크립트를 사용하는 어떤 제품의 경우 UI 개발에만 80% 이상의 손이가고 익숙해지기까지도 상당한 시간이 소요된다는 얘기를 들은 적이 있다. 잘못된 개발툴의 선정은 프로젝트의 리스크로 작용한다.
통합개발환경(IDE)에 대한 기능도 검증하여야한다. 좋은 개발툴의 지원 여부는 생산성과 직결된다. 지원하는 IDE에서 UI를 디자인하고 또 디버그 가능한지도 확인해볼 필요가 있고 배포 및 버전 관리에 대한 지원 여부도 미리 확인하는 것이 좋다. 배포니 버전 관리니 하는 것들은 별개로 환경을 갖춰도 상관없겠지만 말그대로 IDE에 통합되어 있다면 작업이 그만큼 더 편리해진다. 이러한 내용들은 향후 유지보수와도 관계가 된다.
실행 환경은 어떠한가? Any OS? Any browser?
서버단의 다양한 OS를 지원하고 웹접근성, 크로스 브라우징, UI의 구조(구조, 표현, 동작의 분리) 등을 고려하여 "웹 표준"을 준수하고 있는지를 확인해야 한다.
서버에 위치한 X-인터넷 엔진의 기동과 종료, UI 및 관련 리소스의 관리, 배포 및 에러 모니터링 등과 같은 제반 사항들에 대한 관리자를 제공하는지 여부와 관리자의 기능과 역할에 대해서도 리뷰해볼 필요가 있다.
그리고 사용자가 어플리케이션을 실행하기 위해서 기존 C/S와 같이 독립 실행(Stand Alone) 형태로 접근하기를 원한다면 클라이언트에서 완성된 어플리케이션을 실행하는 방식에 대해서도 알아볼 필요가 있다. 제품이 자체 뷰어를 제공하는지, 브라우저 내장(Embedded Web Browser) 방식으로 실행되는지를 확인한다.
브라우저로 실행하는 경우 최종적으로 렌더링되는 HTML 및 관련 리소스가 웹표준을 준수하고 IE, Firefox 등을 비롯한 다양한 브라우저 환경에서 동일한 포맷으로 출력되는지도 확인해야 한다.
또한 뷰어는 자동으로 배포되며, 어플리케이션은 최신의 버전으로 자동 갱신되는지도 확인해야 한다.
성능과 보안은?
작업시 백엔드를 제외한 X-인터넷 관련 계층에서의 퍼포먼스를 고려해야 한다. 실제 백엔드 서비스의 수행 시간은 짧지만 UI를 구성하는 컨트롤(혹은 컴포넌트) 자체에 문제가 있어서 결과 화면의 출력이 늦어질 수도 있다. 특히 대량 데이터를 조회하는 그리드(Grid 혹은 Table 류)가 포함되어 있거나 화면 구성이 복잡하여 하나의 화면 상에 수많은 컨테이너성 컨트롤들과 거기에 포함된 컨트롤들이 존재하고, 다른 화면을 인클루드(include)하는 등 복잡도가 증가하게 되면 결과 출력이 느려질 수 있다. 이런 경우 실제 처리 성능과 무관하게 제품의 화면 처리 성능으로 인하여 응답속도가 늦어지고 전체 퍼포먼스가 저하되는 것 처럼 보여질 수 있다.
대량 데이터를 조회하는 경우 서비스에서 리턴한 결과를 화면에 전달할 때 분할 전송 하거나 데이터를 압축하여 트래픽을 최소화하는 기술이 사용되기도 하므로 이런 기술들이 포함된 제품인지도 체크해보면 좋을 것 같다.
화면(클라이언트)과 서비스(서버)간의 보안 기능도 체크해야 한다.
기술 지원은 원활한가?
고객 입장에서 요구 사항을 전달했을 때, 업체에서 효율적 적용을 위한 기술 지원이 제대로 되고 있는가도 체크 포인트이다. 또한 제품 자체의 결함을 개선하기 위해 꾸준히 패치하고 버전업하고 있는지도 확인해야 한다. 역으로 아직 시장에 정착하지 못한 초기 버전의 경우 자체 결함이 너무 많아 개발 기간 내내 패치하느라 볼장다볼 수도 있다. 기본적으로 안정적인 제품을 선택해야 한다.
제품에 포함되어 있지 않거나, 있어도 업무의 요구사항을 충족하지 못하는 컨트롤(컴포넌트)이라면 사이트에 특화된 사용자정의(Custom) 컨트롤을 만들어 사용할 수 있어야 하며, 필요한 경우 업체에 생성해주기를 요청할 수 있다. 이러한 요구가 잘 수용되고 있는지도 확인할 필요가 있다.
기술 지원이 원활하지 않을 경우 개발자들에게 수면부족 현상이 나타날 수 있다. 물론 벤더에게 모두 요구하고 무리하게 요청할 수는 없다. 정당한 사유로 서로 이해할 수 있는 범위 안에서의 말이다.
[기능적인 사항]
컨트롤러(Controller)는 유연하고 확장 가능한가?
일반적으로 화면 계층(Presentation Layer)과 서비스 계층(Business Layer) 사이에 있어서 UI의 요청(request)를 파악하고 적절한 서비스를 호출하여 결과를 리턴해주는 역할을 수행하는 컨트롤러가 대부분 포함된다. X-인터넷 솔루션의 경우 컨트롤러 자체가 서버 상의 X-인터넷 엔진에 포함되는 경우가 있을 수 있다. 이러한 경우 사이트에 필요한 구현을 추가/변경하여 커스터마이징할 수 있는지 여부가 중요하다고 생각한다.
단순하게 생각해서 클라이언트의 요청에 대해서 전역적인 전후 처리 및 사용자 트랙킹이 필요하다고 하자. 이럴때 메인 컨트롤러가 변경 불가능하다면 의도하지 않게 구현부가 지저분해지고 좋지 않은 구조로 변경될 수 있다. 컨트롤러에 대한 추상층(abstract)을 지원하거나 원하는 작업을 할 수 있는 인터페이스를 제공해주는 것이 좋다.
화면에 대한 여러가지 사항
공통 작업을 미리 적용한 화면을 만들고 상속해서 사용할 수 있는 구조인지를 확인해야 한다. 그렇지 않을 경우 공통 기능을 따로 구현한다 하더라도 만드는 화면마다 이 기능을 호출(call)하는 구현부가 모두 포함되어야 한다. 또한 기본적인 몇가지 Layout으로 유형별 템플릿을 만들어서 화면을 작성할 수 있는 기능이 포함되어 있다면 좋을 것 같다. Copy & Paste는 실수를 유발할 수 있다.
화면 구성이 용이하고, 단순하거나 복잡한 다양한 형태의 레이아웃을 작성할 수 있는지 확인한다. 그리고 런타임에 동적으로 컨트롤을 추가/제거하여 다이나믹한 화면을 구성할 수 있는지도 확인한다.
SDI(Single Document Interface)는 물론이고 필요하다면 MDI(Multiple Document Interface)를 지원하는지 확인한다.
로드된 화면 목록을 관리하고 재사용할 수 있는지, 팝업화면 및 MDI 또는 Tab에 포함된 화면들간의 전환 및 네비게이션은 원할한지, 각 화면간의 파라미터(데이터) 교환은 용이한지 등 필수적인 사항들을 확인해야 한다. 이러한 내용들은 기본 API로 지원되는 제품이 좋을 것이다.
기본적인 컨트롤(컴포넌트) 셋트가 지원되는가?
화면 구성에 필요한 text(masked 포함), radio, checkbox, combo(drop down), lable, link, date picker, image 등의 기본적인 컨트롤 셋트가 잘 구비되어 있는지 리뷰해볼 필요가 있다. group, tab, panel 등의 컨테이너(container)성 컨트롤들과 화면 네이게이션 등에 필요한 tree, menu 컨트롤들도 효율적인 사용이 가능한지 확인한다.
X-인터넷의 특성상 레포트 툴과 별개로 기본적인 chart와 graph 컨트롤 지원 여부도 체크한다. 고품질의 보고서 개발을 위한 양식과 API를 포함하고 있으면 더욱 좋다.
부가적으로 upload, download에 대한 컨트롤 보유 여부와 필요하다면 ActiveX, mail, ftp, browser 등의 컨트롤도 포함되어 있는지 확인한다.
너무 많은 것을 바라나? 이왕이면 다홍치마다. ^^
부가적인 부분을 제외하고 위에 기술한 기본 컨트롤 항목들을 포함하여 그외 필요한 컨트롤들은 반드시 지원 여부를 체크하고, 또한 사용이 용이한지 확인해본다.
또 하나 언급이 필요한 것은 사용자정의(Custom) 컨트롤을 제작해서 사용할 수 있는 구조인가하는 것이다. 화면 디자인과 구현에는 적절한 표준이 있기 마련이다. 제공되는 컨트롤을 상속하거나 몇개의 컨트롤을 조합(내부에 인스턴스 변수로 참조)하여 복합컨트롤을 생성할 수 있는 구조라면 표준(공통)의 모양과 행위를 갖는 컨트롤 목록을 생성하여 개발자에게 제공할 수 있다. 따라서 자연스럽게 표준을 강제할 수 있게된다. 사용자정의 컨트롤을 만들 수 없는 구조라면 적어도 컨트롤의 스타일을 정의해서 공유할 수 있는 구조까지는 지원이 되어야 할 것 같다.
그리드(테이블) 컨트롤
내가 상각하기에 가장 중요하게 체크해야 되는 컨트롤은 기본적인 조회 데이터의 목록을 보여주는 그리드(grid 혹은 table)이다!
화면의 원래 목적은 필요한 데이터를 사용자가 알아보기 쉽게 표현해주는데 있다. 특히, 데이터의 목록을 보여주고 처리하는데는 다양한 표현 양식과 유연한 처리 구조가 요구될 수 밖에 없다. X인터넷과 무관하게 개발 경험이 어느정도 있다면 그리드가 얼마나 중요한지 잘 이해할 것이다.
그리드 컨트롤을 위한 체크 항목들을 생각나는대로 나열해보겠다.
그리드의 기본 구성이 헤더(column)와 Row로 구분된다고 할 때 그리드의 레이아웃은 다양하게 변경될 수 있어야 한다. 일반적 형태의 그리드 외에 cross tab, tree 형태의 레이아웃도 지원하는지 살펴볼 필요가 있다. 헤더 및 Row를 두줄로 하여 단건의 데이터를 표현할 수도 있어야 하고 cell간의 병합도 자유로워야 한다.
cell 데이터는 일반 text에서부터 combo, check, image 등으로 표현될 수 있어야 하며, 타 컨트롤을 호스트하기 위한 컨트롤도 cell에 들어갈 수 있어야 한다.
원하는 데이터로 필터링하여 조회할 수 있어야 하고 그리드 내의 데이터는 원하는 형태로 formatting할 수 있어야 한다.
또한 조회 데이터를 사용하여 그리드를 만들때, 구현부에서 roop를 돌며 동적으로 그리드를 그려내는 것이 아니라 데이터 바인딩을 지원함으로써 개발자로 하여금 최소한의 코드를 사용할 수 있도록 해야 한다. 물론 특수한 경우 코드를 사용하여 row와 cell을 자유롭게 병합 및 컨트롤하여 동적으로 그리드를 그려낼 수 있어야 한다.
메인 화면에 검색 기능이 있어 화면의 데이터를 조회/하이라이트 할 필요가 있을 때 원래의 컨트롤에 search 기능이 포함되어 있다면 한결 수월해질 수 있다. 또한 단순히 조회의 결과를 출력하는 기능 뿐만 아니라 단건, 다건에 대한 데이터 편집과 유효성 체크(validation)를 유연하게 지원할 수 있어야 한다.
이쯤되면 구현은 안하고 제품에 모든것을 위임하려 하느냐 하는 생각도 들겠지만 거저 먹겠다는 의미가 아니다. 예를 들자면 그리드 내에 몇개의 데이터가 신규로 추가되고 몇개의 데이터가 삭제되었는지, 혹은 수정되었는지 정도는 구현부에서 쉽게 접근하고 참조할 수 있을 정도의 API는 제공을 해야한다는 얘기이다. 적어도 dirty 체크를 할 수 있는 flag 정도는 있어야 한다.
상황에 따라 한 화면에 여러개의 그리드가 존재할 경우 상호간에 관계(relation)를 부여할 수 있는지도 살펴봐야 한다. drill down의 지원 여부 등도 중요한 요건이 될 수 있다. 또한 제대로 된 그리드라면 데어터를 그룹핑하여 소계, 합계, 총계 등을 표현할 수 있어야 하고 칼럼별 소팅을 지원할 수 있어야 한다.
조회된 데이터 목록을 excel이나 CSV 등으로 export하는 기능까지도 지원한다면 더욱 좋다. 그리드의 scroll(수평, 수직)도 고려해야 한다.
이들 외에도 그리드는 고려할 사항들이 많다. 다시 한번 말하지만 그만큼 그리드는 UI의 핵심 요소이기 때문이다. 사실, 이러한 내용들은 그리드 컨트롤의 기본 기능 요건이라기 보다 개발에 필요한 사항이라고 해야하는 거이 맞을지도 모르겠다. 아무튼 그리드가 많은 기능을 갖고 있으면 그만큼 개발에 유리하다.
이벤트 및 서비스 호출 방식은?
서비스는 동기적 호출외에 비동기 방식의 call back이 필요할 수 있다. 사실, 이것은 제품의 이벤트 모델 구현 수준에 따라 달라질 것 같다. 업무의 복잡도, 기능 수준, 화면의 구성 등에 따라 다양한 서비스 호출 방법이 요구될 수 있다. 프로세스의 기본 흐름을 용이하게 구현할 수 있는지와 이벤트 핸들링과 구현도 유연성과 용이성을 체크하도록 한다.
내용이 두서가 없지만 여기까지 생각나는 것들을 죽 적어봤다. 주로 기술적인 관점에서 일반적인 사항이라고 생각되는 것들인데, 환경에 따라서 체크할 항목들은 가변적일 것이다. 이를테면 내가 수행한 프로웹 기반 프로젝트에서는 PDA 지원 여부가 이슈가 되었던 적이 있다. 자세한 내역은 말하기 어렵지만 우여곡절 끝에 PDA 구현은 .net으로 가야했다.
사실, 이 포스트는 일전에 한번 작성을 했었는데 예기치 않은 사고로 모든 내용을 유실하고 오늘에야 다시 작성을 하였다. 새로 쓴다는 기분으로 작성하여 원래 작성했던 내용과 다소 포맷이 달라지고 내용도 달라진 것 같다. 왠지 유실한 포스트가 더 잘 쓰고 내용도 좋았던 것 같은 생각이 드는 것은 왜일까? ^^;
아무튼 이전 글에는 없는 내용을 하나 추가하면서 마무리 한다. 우연히 발견한 글인데 RIA 기술을 평가하기 위한 요소들에 대한 내용을 발췌하여 붙인다. 조금 중복되는 내용도 있는 것 같다.
아래 내용은 'Rich Internet Applications의 기술 옵션'이란 글에서 인용한 것임을 밝힌다.
[평가 요소]
RIA 기술을 평가할 때 다음 요소들을 고려해야 한다.
UI의 풍부함 정도
UI를 개발할 때 기본적인 UI 위젯이나 컨트롤이 어느 정도 있는가? 이러한 컨트롤을 가지고 데이터 바인딩과 이벤트 바인딩을 어떻게 수행 할 것인가? 새로운 컨트롤은 사용하기 쉽고 쉽게 플러그인 되어야 하다. 몇몇 RIA 기술에는 애니메이션 API를 페이지에 추가하는 등 풍부함과 더 많은 정보를 추가하는 간단한 방식이 있다. 예를 들어, 사용자가 버튼을 단 한번만 클릭하도록 버튼을 움직이게 할 수 있다.
복잡성
개발자들은 많은 세월 동안 기존 페이지 기반 모델을 사용해 왔다. 쉽고 단순하다는 이유에서였다. 하지만 보이는 모습은 형편없다. RIA 기술은 배우기도 쉽고 구현 및 확장하기도 쉬워야 한다. 기존 웹 기술과 운용성도 있어야 한다.
유연성과 컴포넌트화
다양한 미들웨어 컴포넌트와 협업할 수 있는 유연성은 중요한 것이다. 협업은 쉽게 구성 및 확장되어 새로운 커스터마이징 위젯을 만들 수 있어야 한다. 일단 커스텀 위젯의 라이브러리를 만들면 이들을 애플리케이션에서 재사용 할 수 있다.
페이지 리프레쉬
전체 페이지 대신 페이지 블록을 리프레쉬 하면 매우 큰 효과가 있다. 블록을 리프레쉬 하면 애플리케이션이 더욱 빨라지고, 가용성도 높아지며, 시각적인 효과도 더 좋아진다. 에러를 더욱 잘 관리할 수 있다.
사용자가 웹 페이지에서 액션이나 첫 번째 태스크를 수행한다면 데이터는 백그라운드에 있는 서버로 간다. 사용자는 같은 페이지에서 또 다른 태스크를 시작한다. 그 동안, 첫 번째 태스크에서 온 피드백이 같은 페이지의 몇 부분을 업데이트 한다. 따라서 이와 같은 방식으로 웹 페이지를 디자인 한다면 작업 효율성이 높아질 것이다.
보안
RIA를 적용할 때 기존 애플리케이션과 비교하여 보안 위협은 없는지를 확인한다. 서버 통신과 관련한 보안, 클라이언트에서 다운로드 된 브라우저 플러그인과 확장을 주목하라.
기본적인 웹 패러다임 지원
이 기술은 오늘날 웹 애플리케이션에서 진화하고 있는 기본적인 웹 패러다임-사용자 장치 독립, 브라우저 독립, 업로드와 다운로드에 바이너리 파일 전송 지원-을 지원해야 한다. 기술의 성숙도도 문제가 된다.
툴링
단위 테스팅과 디버깅 지원을 사용하여 통합 개발 환경(IDE)에서 개발자들이 사용할 수 있는 툴링을 검토하라. 툴링은 기존 에디터나 지원 에디터를 갖춘 플러그인이 될 수 있다.
가용성
사용자는 브라우저 애플리케이션이 보통의 브라우저 기능들과 함께 작동하는 것을 기대한다. 특히 이미지 저장하기 기능, 페이지의 내용을 찾는 Ctrl+F, 카피& 페이스트는 FLASH 기반 솔루션에서는 작동하지 않는다. RIA 디자인의 기본을 인간과 사용자 인터랙션 (HCI) 원리에 맞춰라.
※ 마지막으로 내용에 인용한 이미지의 출처는 다음과 같다.
엑셀 콤보박스 이용하기
