ASP.NET MVC Framework이 발표된 후 두어 차례 CTP가 발표되었고 MIX08 시점에 다음 CTP를 발표할 예정이다. MIX08에 발표할 ASP.NET MVC는 이전 CTP와는 다르게 많은 기능 보강과 편의성을 제공할 것으로 보인다. 새롭게 변화될 특징에 대해 Scott Guthrie에 블로그에 올라온 글을 통해 정리해보자

1. ASP.NET MVC 설치 과정 불필요. 관련 DLL 복사만으로 사용 가능
지금까지 CTP에서는 별도의 설치 과정을 통해 System.Web.Mvc.dll을 GAC에 등록하는 과정을 거쳤으나 앞으로는 구축하는 애플리케이션의 \bin 디렉토리에 System.Web.Mvc.dll을 복사하는 것 만으도 ASP.NET MVC를 사용할 수 있다.
또한 ASP.NET MVC가 partial/medium trust를 지원함으로써 호스팅 업체 입장에서 부담을 줄여줄 계획이다.

2. URL Routing 기능 개선
지금까지 ASP.NET MVC에는 Rails에서와 같은 URI 기반의 직관적이고 간편한 라우팅 기법을 기본으로 제공하였다. 다음 CTP에서는 라우팅 룰에 이름을 부여하여 이름만으로 해당 라우팅 룰을 접근하여 사용할 수 있게 할 것이며, 와일드카드 룰을 사용할 수도 있고, 라우팅 룰을 선언하고 확장할 수도 있게 할 예정이다.  또한 이러한 라우팅 컴포넌트만을 MVC에서 분리하여 다른 ASP.NET 기반 기술 (가령, ASP.NET Dynamic Data, ASP.NET Web Forms) 등에서도 사용할 수 있게 할 예정이다. 

3. VS2008 툴 지원 향상
지금까지 ASP.NET MVC는 VS2008에서 project template을 제공하는 수준이었으나, project item template, project 환경 기본 설정 기능,  MSTest 이외의 NUnit, MBUnit, XUnit 등의 단위 테스트 기본 내장 지원 등이 포함될 예정이다.

4. [ControllerAction] 제거
Controller 클래스의 action 메소드들은 [ControllerAction] attribute을 지정하여 action 메소드임을 명시하였지만, 앞으로는 아래 그림처럼 Controller 클래스내의 모든 public 메소드는 기본적으로 action 메소드로 인식하게 된다.

5. 필터 지원
요청 전 후에 필터 체인을 만드는 것은 웹 프레임웍의 가장 기본적인 기능이다. ASP.NET MVC에서도 Controller 클래스에 필터를 적용할 수 있게 된다. 적용 단위는 Controller 클래서 전체 혹은 개별 action 메소드 단위이다. 아래 그림은 ASP.NET의 OutputCache를 활용하는 action 메소드와 Authorization을 활용하는 action 메소드를 보여준다.
 

6. HTML Helper 기능 내장
지금까지 ASP.NET MVC 내에는 내장된 기능으로 약간의 HTML UI Helper 메소드를 지원하였고 별도의 다운로드를 통해 부가적인 helper 메소드를 사용할 수 있었다. 하지만 앞으로는 이러한 helper 메소드를 모두 내장하여 별도의 다운로드 없이 사용할 수 있도록 할 예정이다.  아울러 ASP.NET AJAX 라이브러리와 ASP.NET MVC와의 원활한 상호운용을 위해 AJAX helper 메소드를 만들고 있다.

7. Refactoring & Design Improvement
앞으로의 ASP.NET MVC는 리팩토링을 통해 디자인 면에서 향상을 꾀할 것이며 이로써 확장성과 테스트에 좀 더 용이한 프레임웍이 될 것이다. 즉, 기본적으로 내장된 기능을 사용할 수도 있고, 내장 기능을 사용하되 약간의 커스터마이징을 가할 수도 있고, 완전히 내장 기능을 드러내고 자체 기능을 사용할 수도 있게 할 것이다. ASP.NET MVC는 각 구성 요소(model-view-controller)를 원하는 모듈로 치환할 수 있는 데, 여기에 완전 치환외에 커스터마이징을 쉽게하여 약간의 기능을 수정할 수 있도록 확장한 것이다. 뷰 엔진 locator 로직을 치환하기 위해서 이제는 뷰 엔진 구현 로직 전체를 치환하지 않고서도 가능하다. 물론 뷰 엔진을 통째로 치환하는 것도 가능하다. 그 밖에 많은 관심을 받고 있는 DI Container와의 통합도 쉬워진다. 지금까지 ASP.NET MVC에서 기본 제공하는 객체 라이프싸이클 관리 모듈을 쓰지 않고 가령,Spring.NET의 ObjectFactory를 쓰고자 한다면, ObjectFactory를 사용하는 ControllerFactory를 만들어 ASP.NET MVC의 Controller Factory로 삼으면 되었는데, 여기에 부가 기능을 추가할 예정이다.

8.  ASP.NET MVC 소스 공개 및 디버깅
얼마전 공식적으로 .NET Framework 의 기본 라이브러리 소스가 공개되어 디버깅시 좀 더 편리한 환경을 구축할 수 있게 되었는데, ASP.NET MVC도 마찬가지로 소스가 공개될 예정이다. 또한 Visual Studio의 project에서 빌딩할 수 있는 형태로 다운로드가 되기 때문에 디버깅에 곧바로 활용할 수 있다.  또한 필요하면 ASP.NET MVC 소스에 버그 패치를 하여 애플리케이션 개발에 활용할 수도 있으나 패치된 ASP.NET MVC 소스를 배포하는 것은 허용되지 않는다.

이 글은 Scott Guthrie의 블로그 포스트를 번역한 것이며 일부 필자의 의견 및 내용이 첨가되었다. 원문은 아래에서 확인할 수 있다.
원문보기

Posted by 장현춘

이는 닷넷과 자바의 차이점을 언급할 때 가장 간단하면서 핵심을 찌르는 표현이었으나 언제 부터인가 두 개발 플랫폼은 서로를 너무 사랑하는 듯 닮아가고 있어 더 이상 맞는 표현은 아니다.
닷넷 진영을 먼저 살펴보면, 노벨의 모노 프로젝트 덕택에(?) 닷넷 애플리케이션도 유닉스로는 썬 솔라리스, 리눅스로는 수세와 레드햇을 포함한 왠만한 리눅스 배포판, 맥 OS, 그 외에 FreeBSD, OpenBSD를 포함하여 각종 BSD 계열에서 동작한다는 사실을 관심있는 닷넷 개발자라면 이미 다 아는 사실이다. 다만, 모노 프로젝트의 닷넷 구현은 아직까지 1.1에서 2.0사이에 머물고 있어 닷넷 3.x 기반의 기능은 사용할 수가 없다. 현재 Visual Studio로 컴파일한 닷넷 애플리케이션을 별도의 재컴파일 과정 없이 그대로 모노 환경에서 실행시킬 수 있으며 자바처럼 mono Babo.exe 라고 실행한다는 점이 다를 뿐이다. 물론, 해당 애플리케이션이 모노가 구현한 라이브러리로만 구현되어 있는 경우에 에러없이 동작한다. 이것이 가능한 이유는 마이크로소프트가 닷넷 CLI (Common Language Infrastructure)와 C# 스펙을 ECMA 표준으로 등록하여 공개하였고, 모노 프로젝트가 이를 기반으로 별도의 CLR을 만들어 닷넷 개발 및 운용 환경을 제공하면서도 둘 사이에 표준 기반의 호환성이 생긴 것이다.
마이크로소크트는 모노 프로젝트에 대해 공식적으로 지원하지는 않았었다. (그럼 비공식적으로는 ?? :) ) 얼마전 Silverlight의 리눅스 버전을 노벨의 모노 프로젝트 일부로 Moonlight라는 이름으로 개발하기로 마이크로소프트와 노벨이 합의하면서 두 회사 사이의 협력 관계가 모노 전체 프로젝트로 확산될 것인가가 관심의 대상이 된 적이 있다. 하지만, 협력 범위는 Moonlight로 한정하기로 하였다. 어쨌거나 닷넷도 이제는 "다수 언어, 다수 플랫폼" 이라고 비공식적으로(?) 얘기할 수 있을 듯 하다.

그럼, 자바의 경우를 살펴보자.
자바 진영에서도 JVM이 공식적으로(native하게) 지원하는 것은 아니지만, 별도의 프로젝트성으로 혹은 학문적 필요에 의해 많은 언어들이 개발되어 JVM에서 동작하는 언어가 현재 약 200여종에 이른다고 밝히고 있다 (여기 참조). 공식적으로 즉, native하게 JVM에서 지원하는 언어로는 엔터프라이즈 용이 아닌 작은 업무 개발에 적합한 script 언어인 Groovy가 JDK 1.4 부터 지원되고 있다. JDK 1.6 즉 JDK 6.0 부터는 Mozilla Rhino 자바 스크립트 엔진을 탑재하고 자바 스크립트를 자바와 혼용하여 쓸 수 있도록 각종 API도 지원하고 있다. 여기까지는 자바 언어가 주류이고 그 외 작은 업무 개발을 위해 스크립트를 지원하는 정도이나 자바는 이제 다수 언어 지원을 위해 한발 더 내딛었다. 며칠전 썬은 다빈치 머신 (Da Vinci Machine)을 발표하면서 JVM에서도 native하게, 또 JVM의 장점을 가장 잘 살린 아키텍처 및 패턴 등을 사용할 수 있게 다수 주류 언어 지원 계획을 발표하였다. VM 기술이 이제 성숙하였고 보편화되어 가기 때문에 남은 것은 자바 이외의 다수의 주류 언어를 어떻게 JVM내에서 혹은 JVM의 장점을 가장 잘 살리면서 자바 이외의 언어가 가진 장점을 JVM에서 활용할 수 있도록 하느냐가 관심사가 된 것이다. 다빈치 머신은 JDK 차기 버전인 7.0에서 일부 포함될 예정이다. 결국 자바도 "다수 언어, 다수 플랫폼"을 향해 가고 있다.

Posted by 장현춘

  Office Business Application (OBA)라 함은 지난 시간에 살펴본 바와 같이, 마이크로소프트의 오피스를 클라이언트 접점으로 하고 백엔드의 기업전용(LOB) 애플리케이션(ERP, CRM, SCM 등)을 연동하여 사용케함으로써 복잡하고 정형화된 LOB 애플리케이션을 익숙한 오피스 인터페이스를 통해 접근하도록 함으로써 생산성을 향상시키고 사용자 경험을 극대화할 수 있는 새로운 애플리케이션 개발 방식이다.
  이번 시간부터는 OBA의 기술적인 특징과 차별화된 점을 살펴보도록 한다.
전통적인 LOB 애플리케이션들은 구조적이고 정형화된 비지니스 프로세스를 모델링하여 처리하는 데 최적의 솔루션을 제공해왔다. 하지만, 실제 비지니스는 이러한 잘 구조화된 비지니스 프로세스보다는 비구조적인, 사람과 사람사이의 소통을 통해 이루어지는 프로세스가 훨씬 많으며 이러한 것들은 전통적인 LOB 솔루션이 제공할 수 없는 영역이었고, 바로 이러한 부분을 마이크로소프트의 오피스를 통해 엮음으로써 효과적인 비지니스가 이루어지도록 하는 것이 바로 OBA인 것이다.
  아래 그림은 이를 형상화한 것이다. LOB 솔루션이 제공하는 구조적인 프로세스 진행 와중에 우리의 비지니스는 이처럼 많은 사람과 사람사이의 소통을 필요로하며, 이러한 소통은 단순 문서의 전달만이 아닌 비정형화된 형태의 메시지 통신을 포함할 수도 있고 엑셀과 같은 툴의 도움을 받아 견적서를 작성하기도하고, 차트를 구성하기도 한다.

  이와 같은 비구조적인 비지니스 프로세스를 포함하는 위해서 우리의 애플리케이션은 어떠한 아키텍처를 가져야 할 것인가 ? 일반적으로 우리가 베스트 프랙티스로 인정하고 있는 3 tier를 살펴보자. 통상적으로 Presentation Tier, Business(혹은 Application) Tier,  Data(혹은 Integration) Tier 등으로 구분한다. 그 어느 티어에서도 사람과 사람사이의 비구조적인 통신을 효과적으로 처리할 수 있는 곳이 없다. 따라서 OBA 입장에서는 이러한 사람과 사람사이의 협업을 담당하도록 Presentation Tier와 Business Tier 사이에 Productivity Tier를 둔다.

  위 그림은 각 Tier가 담당하는 역할을 보여주며 Productivity Tier를 제외한 나머지 Tier는 전형적인 3Tier 아키텍처와 동일하다. Productivity Tier의 주요한 역할은 다른 사람과의 협업을 가능하게 해주는 문서와 정보의 공유 및 관리 기능, 협업과 통신 지원 등이다. 
  닷넷 플랫폼의 지원하에 오피스 2007은 위의 4Tier 아키텍처에 적합한 모든 기능을 제공하고 있으며 또한 개발 측면에서도 Visual Studio에 위저드로 내장되어 있는 VSTO (Visual Studio Tool for Office) 기능을 활용하여 쉽게 개발할 수 있다. 개발 플랫폼이자 LOB 애플리케이션의 얼굴로 자리잡고 있는 오피스 2007의 기능을 도식화하면 다음과 같다.

  정리하면, OBA는 위에서 살펴본 오피스 2007의 막강해진 클라이언트 및 서버 기능을 활용하여 Layered Architecture 기반으로 LOB 애플리케이션 연동하여 생산성을 극대화시키는 개발 방식인 것이다. 주의할 것은 Layering을 했다고 해서 즉, Architectural Pattern만 적용했다고 해서 엔터프라이즈 애플리케이션이 되는 것은 아니다. 맨처음 이슈로 제기했던 비구조적인 커뮤니케이션을 효과적으로 처리하기 위해서는 4 Tier 모두에서 적절한 Composition이 이루어져어 한다.

Posted by 장현춘

오늘날의 기업들은 성공적인 비지니스를 위해 소위 LOB (Line of Business), 즉 기업용 애플리케이션 도입에 많은 투자를 한다. 대표적인 LOB 애플리케이션으로는 ERP, CRM, SCM 등이 있으며 이러한 LOB 애플리케이션은 기업의 비지니스에 있어서 필수적인 시스템인 것처럼 여겨지고 있다. 정도의 차이는 있으나 예전에는 이러한 LOB 애플리케이션을 자체 구축하여 보유하는 경향이 있었으나, 오늘날에는 많은 기업에서 한참 주가를 올리고 있는 SaaS 기반 서비스 형태로 이용하는 경향이 늘고 있다.
기업내의 사용자 입장에서는 이러한 LOB 애플리케이션을 활용하여 날마다의 업무를 수행하여야 하는데, 이러한 애플리케이션을 사용하는 것이 그다지 쉽지만은 않다. 대부분의 기업내 사용자들의 프로젝트의 견적을 제출하기 위해 엑셀을 사용하여 각종 데이터를 변환하여 차트로 구성하여 비교하기도 하고, 전화와 사내 메신저를 통해 업무를 처리하기도 하고, 작성한 기안을 승인 받기 위해 결제 시스템을 이용하기도 하는 등 LOB 애플리케이션 단독으로 제공하기 어려운 비구조적인 비지니스 프로세스들과 LOB 업무들이 혼재된 현실 속에 살고 있다. 더군다나, 가트너 조사에 의하면 55%의 CRM 프로젝트는 사용자 기대수준에 미흡하여 실패하고 있으며, 40% 이상의 ERP 프로젝트는 사용자들이 채택하여 사용하는데 있어 문제를 일으키고 있고, 기업내 사용자들이 업무 수행이 필요한 정보의 55~70%를 각종 LOB 애플리케이션이 아닌, 바로 옆 사람에게서 얻는다고 한다. 또한 메일의 통한 업무가 확산됨으로 인해 사내 사용자들에 있어 평균적으로 하루 일과 시간의 20%를 메일 시스템에 할애하고 있는 게 현실이다.
이처럼 LOB 애플리케이션의 사용은 비지니스를 위해 불가피하지만, 이러한 애플리케이션들은 사용자들이 날마다 사용하고 있는 엑셀이나 아웃룩과 같은 애플리케이션 만큼의 숙련도나 업무 생산성을 제공하기 힘들며 MOSS가 제공하는 전화나 메신저, 문서 공유 폴더 등을 통한 협업 등 비구조적인 비지니스 프로세스의 지원 또한 힘든 상황하에서 오피스와 LOB 애플리케이션의 결합을 꿈꾸는 것은 전혀 이상하지 않다.
마이크로소프트는 바로 이 점에 주목한다. 사내 사용자들이 늘 사용하고 있고 익숙한 MS 오피스 인터페이스를 통해 백엔드의 각종 LOB 애플리케이션을 사용하여 업무를 처리할 수 있게 한다면 전반적인 생산성 제고는 물론 툴에 대한 사용자 교육 등에 들어가는 비용을 절감할 수  있다. 예를 들자면, 영업 사원이 고객에게 메일 발송할 때 CRM과 연동된 아웃룩을 통해 필요한 고객사의 비지니스 정보를 조회하면서 메일을 보낸다든지, 메일 보내기 등과 같은 Customer care 활동 등을 바로 CRM 시스템에 저장하여 나중에 통계를 뽑아 본다든지 하는 등, 예전 같으면 메일 시스템, CRM 따로 따로 보면서 진행하고 진행 결과를 일일이 CRM에 입력해야 했어야 하는 등과 같은 작업이 불필요하게 된다. 
아래는 OBA 1세대라고 할 수 있는 "Duet"이다. MS 아웃룩을 통해 SAP의 회계, 인사, 재고 시스템과 연동하여 업무를 처리할 수 있는 만든 것으로 Microsoft와 SAP은 Duet 2.0, 3.0 등을 지속적으로 개발하기로 발표한 바 있다. 

아래는 아웃룩에 plug-in 형태로 내장된 Microsoft Dynamics CRM을 보여준다.

또 다른 예로써 아래 사진은 마이크로소프트 사내 포털이다. 기업용 검색엔진과 맞물려 사람 이름을 넣고 "People" 탭을 선택하면 사내 CRM과 연동하여 해당 직원에 대해 연락처나 상태(Presence) 정보를 아래와 같은 형식으로 보여주고, "Intranet" 탭을 선택하면 해당 직원이 올린 글이나 작성한 문서를 찾아 일반 검색 엔진의 검색 결과 처럼 보여주며, "Customers"를 선택하면 CRM 시스템으로부터 해당 고객에 대한 정보와 MS 컨택 직원에 대한 정보를 보여준다. 이것이 MOSS를 이용하고 있는 웹 기반 OBA의 한 예이다.

OBA는 이처럼 오피스 클라이언트(엑셀, 아웃룩, 워드 등)나 MOSS 2007(Microsoft Office Sharepoint Server)을 사용자 인터페이스로 하여 백엔드의 각종 LOB 애플리케이션과 연동함으로써 오피스 제품군이 제공하는 사용자 편의성 및 생산성을 제공하면서 LOB 애플리케이션 제공하지 못하는 비구조적인 비지니스 프로세스를 MOSS 기반하에 제공할 수 있는 신개념의 Composite Application이다. 
Composite Application은 단순히 사용자 인터페이스만을 그러한 형태로 가져 간다는 것이 아니라, 기업내에서 필요하로하는 애플리케이션을 구축함에 있어 기업내에 이미 산재되어 있는 소프트웨어 자산 (Software Assets) 이나 외부에서 서비스 형태로 제공되는 소프트웨어(서비스)를 애플리케이션의 각 티어에서 조합하여 구축함을 의미한다. 즉, Composite Application이 의미하는 바는 시스템 구성의 전 영역에 있어서 Composition이 일어나는 것이며 이를 위해 적절한 각 티어별로 컨테이너 혹은 플랫폼이 전제되어야 진정한 Composite Application의 장점을 누릴 수 있다.
마이크로소프트 오피스는 이제 30여개의 제품들이 모여 하나의 플랫폼을 형성하고 있다. 단순히 데스크탑 통계툴이나 프리젠테이션을 넘어 기업의 비지니스를 용이하게 하는 각종 애플리케이션을 엮고 시너지를 유발하는 개발 및 운영 플랫폼으로 진화했으며 이를 가장 효과적으로 사용하는 방법이 OBA인 것이다.

Posted by 장현춘
TAG OBA

Software + Services가 미치는 영향에 대해 살펴보기로 하자.
전통적인 Software 중심적인 시각에서 Services가 더해져서 이루어지는 세상은 예전과 다른 시각을 가질 것을 요구하며 다양한 영역에 다양한 사람들의 삶에, 그리고 일의 방식에 영향을 미치고 있다.
먼저, 서비스를 제공하는 입장에서 살펴보기로 한다.

개발자에게 있어서 Software + Services는 어떤 영향을 미치는 것일까 ?
개발자에게 있어 솔루션을 개발한다는 것은 예전에는 필요한 모든 요소, 모든 기능을 자신이 모두 개발하여 소유하는 것을 의미하였다. 모든 것을 개발하여 내 영역안에, 내 회사 방화벽안에 설치하여 운영하는 것을 상정하여 개발이 이루어졌다. 하지만, Services가 개발 영역에 개입하게 되자 상황은 달라졌다. 구축하고자 하는 기능 모두를 자신이 개발할 필요가 없으며 일부는 외부에 Services 형태로 노출되어 있는 것을 이용하고 일부는 자신이 개발하게 되고 이렇게 내부에서 개발한 것과 외부에서 들여다 쓴 서비스간에 통합이 또 다른 주요 이슈가 된다. 통합에 있어서도 SOA 기반의 소위 Services Compostion이 될 수도 있고 그 보다 lightweight한 사용자 중심의 mash-up이 될 수도 있고, 아울러 이러한 서비스를 사용하는 입장이 될 수도 있고 또는 그러한 기능을 제공하는 서비스를 제공할 수도 있다. 요약하면, 필요한 기능을 모두 개발하여 소유하는 시대는 지나가고 시스템의 개발과 서비스의 소유가 분리되는 시대에 개발자들의 아키텍처와 코드가 적응을 해야하는 시대가 된 것이다.
또 다른 면에서 Services의 등장은 개발자에게 있어 고민 거리를 던져주게 된다. 예전에 자신이 개발한 기능은 내부 사용자만을 위한 것이 었지만, Services를 통해 외부에 노출되게 되면 사용자 수는 예측 불가능하게 된다. 이것은 기회이자 도전이 된다. 불특정 다수를 위해 노출된 서비스는 규모의 경제를 가능하게 하며, 이를 통해 예전에는 비용 대비 효과면에서 관심밖의 영역 이었던 것들까지도 서비스의 대열에 합류할 수 있게 된다. 하지만, 이것은 Scalability라는 중요한 이슈를 제기한다. 기업 내의 사용을 위해 개발했던 시대에는 기업만을 위한 Scalability, 즉 Enterprise level Scalability만을 고려하면 되었지만, 불특정 다수에게 서비스 형태로 노출되는 기능은 Internet Scalability 혹은 Cloud Scalability를 가능하게 되는 그러한 아키텍처, 그러한 프로그램밍이 되어야 하는 것이다.
시스템을 운영하는 IT Pro 입장에서 Services의 개입은 어떠한 영향을 미칠까 ?
모든 것을 회사 방화벽안에 설치하여 소유하는 시대에 시스템에 대한 통제와 통합, 커스터마이징이 필요한 만큼 원하는 수준으로 가능하던 시대에서, 나의 권한 밖에 위치한 서비스를 통제하거나 커스터마이징하는 데 제약이 따르는 서비스까지 모두 포함하여 관리가 이루어져야하는 시대가 된 것이다. 통제 가능한 레벨이 다른 내외의 서비스를 효과적으로 관리하기 위한 노력이 필요하게 된다.
아울러, 위에서 언급한 Internet Scalability 혹은 Cloud Scalability 이슈는 IT Pro에 있어서도 커다른 부담이 될 수 밖에 없다. 더군다나 초고속 인터넷의 급속한 보급으로 인해 시스템에 가해지는 부하의 이동 속도도 그 만큼 빨라질 수 밖에 없다. SLA 기반으로 서비스를 제공하는 입장이라면 급격한 사용자의 증가에 따른 시스템의 부하를 적절히 분산하거나 미리 차단하여 서비스가 중단되지 않도록 하는 장치가 필요하다.
서비스를 사용하는 입장에서 서비스의 개입은 어떤 영향을 미칠까 ?

먼저 최종 사용자 입장에서 Software + Services가 주는 의미를 살펴 보기로 한다.
오늘날에 우리가 들고 다니는 대부분의 장치들은 정도의 차이는 있지만 연산 능력을 갖춘 것들이며 사용자들을 이러한 다양한 장치들을 사용하면서 이러한 것들이 서로 Seamless하게 엮이기를 기대한다. 한 장치에서 경험한 기능을 다른 장치에서도 경험하기를 원하며 그러한 경험들이 익숙한 형태로 제공되기를 기대한다. 즉,  사용자들의 Digital Lifestyle에 맞는 서비스가 제공되어야 한다. 이러한 면에서 전통적인 Software만으로 사용자들의 다양한 장치에 두루 적합한 서비스를 제공하기는 불가능하다. 아울러 인터넷 기반의 순수 서비스만으로 이러한 사용자들의 욕구에 부응하는 기능을 제공할 수 없다. 들고 다니는 하드웨어(장치)와 맞물려 최적의 Software + Services 조합이 필요한 이유가 바로 여기에 있다. 
기업내 사용자 즉, Information worker 들에게 있어서 Software + Services는 어떤 의미일까 ?
오늘날 재택 근무가 확산되어 팀원들이 옹기종기 한 곳에 모여 서로 의논하며 일하던 시대는 지나갔다. 언제 어디에 있더라도 늘 연결되어 있다면 공간의 제약은 문제가 되지 않는다. 한국마이크로소프트도 지난해부터 재택근무를 도입하고 있으며, 휴대폰과 Office Communicator를 통해 늘 연결된 환경에서 협업이 이루어지고 있다. 시공간적으로 가장 적합한 형태의 Software 혹은 Services를 이용하여 지속적으로 Seamless한 경험을 제공받으며 업무를 진행할 수 있다. 아울러 offline이거나 online에서거나 사용자들은 중단없이 주어진 일을 수행하길 원하다. online에서만 가능했던 순수한 Services 중심적인 사고에서 offline까지 함께 아우를 수 있는 Software + Services로의 전환이 필요한 이유 중에 하나이다.
그 외에도 고객과의 접점에서 비지니스를 수행해야 하는 비지니스 매니저들에게 있어서 Software + Services는 예전과 다른, 남들과 다른 차별화된 서비스를 제공할 수 있는 수단이 된다. 치열한 비지니스 환경 속에서 차별화된 서비스가 가능하다는 것을 커다란 무기가 될 수 있으며 Software와 Services의 최적의 조합을 통해 가능하게 된다.
위에서 살펴본 바와 같이 Software와 Services의 결합은 기업입장에서 오늘날의 비지니스를 가능하게 하는 IT 전반에 걸친 자연스런 변화이며 이러한 변화를 통해 사용자들의 기대에 부응하는 서비스가 가능하게 된다.

Posted by 장현춘