2004년 컴퓨터 월드 기고 현 BEA 류윤상 팀장의 글

엔터프라이즈 포탈이란 무엇인가

개념 생성에서 현재까지 발전과정, 최신 EP 트렌드 분석

연/재/목/차

1회 : 엔터프라이즈 포탈의 개념(이번호)

2회 : EP의 컴포넌트 및 연관 솔루션(5월호)

3회 : EP의 Critical Success Factors(6월호)

4회 : 글로벌 사례 및 경험 소개(7월호)

류윤상 한국Plumtree수석 컨설턴트

강좌 │ EP의 솔루션 선택! (2회)

---------------------------------------------------------------------------

EP 솔루션 선택, 우리 회사에 적합한 솔루션은?

지난호에서 자세히 설명했던 바와 같이 근래 세계의 선두 기업들이 EP (Enterprise Portal)를 앞다투어 도입하고 있는 가장 중요한 원인은 기업이 전술상 또는 전략상으로 필요로 하는 업무용 어플리케이션을 적은 비용으로 빠르게 구현하여 비즈니스 유저들에게 제공함으로써 IT는 업무 어플리케이션 구축 비용 및 시간을 절약하고 비즈니스 유저들은 자신의 업무에 필요한 어플리케이션을 신속히 제공받음으로써 사업의 기회비용을 줄일 수 있는 가장 현실적인 대안으로 EP가 대두되고 있기 때문이라는 것을 다시 한번 유념해둘 필요가 있다.이렇게 EP를 기반으로 구현된 어플리케이션 들의 특징은 다음과 같다.

-       새로운 포탈기반의 어플리케이션을 작성함에 있어 기존에 기업이 보유하고 있는 데이터나 어플리케이션 로직, 서비스 등을 재사용한다.

-       검색, 협업, 웹퍼블리싱, 보안 등 어느 어플리케이션을 만들 때나 중복적으로 사용되어야 하는 기반서비스 들은 EP 프레임워크 단에서 제공되는 것을 재사용하여 중복투자를 방지한다.

-       이렇게 포탈과 한번 통합된 리소스는 다음 어플리케이션을 만들 때도 쉽게 재사용된다.

이러한 특징들에서 볼 수 있듯이 EP를 기반으로 한 어플리케이션 들은 해당 특정 목적의 어플리케이션을 구성하고 있는 거의 대부분의 서비스나 데이터를 이미 기업내부에 존재하거나 포탈 프레임워크에서 제공하는 것을 재사용하기 때문에 앞서 이야기 했던 EP를 도입하는 가장 큰 이유인 “비즈니스 환경의 변화에 따라 다양한 전술/ 전략적 어플리케이션을 짧은 기간의 개발 기간을 거쳐 신속하게 제공받아 사업 기회비용을 최소화한다.”는 커다란 명제가 실현가능해지는 것이다.

자 그럼 A라는 기업에서 위에서 설명한 목표를 실현하기 위해 EP를 도입하려 한다고 가정하고 그들이 현실적으로 겪는 어려움을 이야기 해 보자.기업의 검토 담당자는 일단 기초적인 정보수집 차원에서 EP라는 솔루션이 어떤 것들이 있는 지 시장조사를 해보지만 접촉하는 거의 모든 소프트웨어 벤더들은 모두 그들의 제품군 안에 포탈이라고 명명한 제품을 가지고 있었다.그 솔루션 들간의 차이점을 파악해보기 위해 검토 담당자가 생각해 온 몇 가지 기능 요구사항이 그들의 제품을 기반으로 하여 구현가능한지 문의해보지만 모든 업체가 다 가능하다고 이야기를 하고 있어 서로간에 어떤 차이점 들이 있고 어느 정도가 사실인지 파악할 수 없는 상황에 빠져든다.

좀 과장된 면이 없지는 않지만 위의 이야기는 현재 포탈을 검토하고 있는 기업들에서 흔히 겪고 있는 현실을 이야기한 것이다.

왜 이런 혼란이 생기는 걸까?다른 소프트웨어들을 검토할 때는 특정 목적 별로 솔루션들이 구분되어 있어 선택할 때 혼란이 적었는데 왜 포탈 솔루션은 이렇게 다양하고 그게 다 그것 같아 보이는 걸까?

그 첫 번째 이유는 엔터프라이즈 포탈이라는 컨셉이 내포하고 있는 개념의 방대함이다.엔터프라이즈 포탈은 결국 기업이 보유하고 있는 많은 IT자원들을 통합하고 이 통합된 서비스를 조합하여 새로운 어플리케이션을 만들어내는 기반이기 때문에 기업의 모든 IT자원과 직, 간접적으로 관련성을 지닌다.예를 들면, 오늘의 주된 주제로서 설명하려고 하는 SSO, KMS, Workflow, Content Management 등이 결국 이 엔터프라이즈 포탈이라는 것에 통합이 되어 새로운 어플리케이션을 만들어내기 위한 부속품으로 활용되기 때문에 엔터프라이즈 포탈 자체가 SSO처럼 보이기도 하고, Content Management System의 성격도 가지고 있는 것 같기도 하고, Groupware의 기능도 하는 것으로 생각이 들 수 있는 것이다.

이러한 혼란을 부채질하고 있는 또 하나의 원인은 요즘 거의 모든 소프트웨어 회사들이 자신들이 원래 주력으로 삼고 있던 기업용 소프트웨어의 사용자 인터페이스를 포탈과 비슷하게 변경하여 제공을 하면서 제품명을 “XX포탈”등의 형식으로 바꾸었거나, 포탈과 비슷한 사용자 인터페이스를 구현하는데 사용되는 소프트웨어 컴포넌트를 기존 소프트웨어 제품군에 포탈이라는 이름으로 추가적으로 포함시켰기 때문이다. KMS (지식관리시스템)를 예로 들어 보자.이 기업용 소프트웨어는 원래는 기업에서 생성되는 지식을 효과적으로 분류, 관리하기 위한 목적으로 개발된 제품이며 기본적으로 엔터프라이즈 포탈과는 기능상의 유사점이 거의 없는 소프트웨어이다.하지만 근래 들어 기업들이 포탈에 많은 관심을 갖게 되면서 이러한 지식관리소프트웨어의 사용자 인터페이스의 일부분을 포탈과 비슷하게 만들어서 제공하면서 이름을 “XX지식포탈”로 개명하여 마케팅을 하고 있다.이러한 솔루션의 사용자 인터페이스만을 보면 엔터프라이즈 포탈의 그것과 너무도 유사하기 때문에 전문가들이 아닌 다음에야 겉으로만 봐서는 이것이 진짜로 자신이 원하던 포탈 솔루션인지 아닌지를 구분하기가 어려워지는 것이다.

이번 호에서는 엔터프라이즈 포탈과 흔히 관련되는 여러 가지 기업용 소프트웨어들을 살펴보고 이렇게 현재 시장에서 복잡하게 얽혀있는 솔루션 들의 상호 관련성, 보완성, 및 차이점을 설명하여 기업이 자신의 비즈니스적 문제를 해결을 하려 할 때 솔루션 선택의 가이드라인을 제시하고자 한다.

Portal & SSO (Single Sign On)

엔터프라이즈 포탈을 검토하는 고객들이 가장 기본적으로 생각하는 단위기능 중 하나가 바로 한번의 로그인을 통해 자신이 사용할 수 있는 모든 사내 시스템을 사용하도록 해주는 싱글사인온 (앞으로는 SSO로 표기) 기능이다.

물론 이러한 SSO이라는 것은 하나의 개념이기 때문에 이를 구현하는 데 특별히 어떠한 소프트웨어가 필수적으로 필요한 것은 아니며, 소프트웨어 패키지 없이도 어느 정도의 개발을 통해 구현할 수도 있고 또 국내에도 실제로 이런 방식으로 구현한 기업들을 몇 차례 경험해 본적이 있다.이렇게 개발을 통해 SSO을 구현한 기업들은 대부분 디렉토리 서버 (Directory Server)를 사용하여 사용자 정보를 한군데로 통합하고 사내의 어플리케이션에 접근 시 이 디렉터리 서버에 있는 사용자의 정보를 참조하여 해당 어플리케이션을 접근할 수 있는지를 판단하도록 해주는 방식으로 구현된 경우가 많다.이렇다 보니 이러한 디렉터리 서버가 SSO기능 자체를 수행해 준다고 오인하고 있는 사람들이 있는 데 이것은 잘못 알려진 내용이다. 실제 Directory Server는 일종의 데이터베이스일 뿐이다.단지 관계형 데이터베이스와는 그 구조가 다르고 정보 저장보다는 정보 검색에 특화된 설계구조 (Schema) 갖고 있는 데이터보관소 기능에 국한된 것이다. 이 정보를 참조하여 타 어플리케이션들에 대한 인증을 처리하고 SSO을 가능하도록 해주는 것들은 추가적으로 자체 개발하여 구현된 경우도 있고, 아예 이를 위해 전문 SSO 패키지를 구매하는 경우도 있다.물론 전문 팩키지를 사용하는 경우에도 디렉터리 서버와 같은 통합된 사용자 정보 보관소가 필요하고 또 일반적으로 함께 구현되는 경우가 대부분이다.

그러면 대부분의 SSO 패키지들이 공통적으로 가지고 있는 구조를 한번 살펴봄으로써 그 실체를 파악해보자.다음의 그림은 SSO 솔루션의 구조를 단순화하여 나타낸 것이며 어느 특정 제품을 표현했다기 보다는 상당히 일반화를 하여 그 구조를 설명하고자 한 것이다.

위의 그림에서 볼 수 있는 것처럼 SSO 솔루션은 주로 다음의 3가지 작업을 수행한다.

1. Authentication: 사용자가 진짜인지 그 진위여부를 가려낸다. (Are you who you say you are? - Authentication Server에서 수행)

2. Authorization: 사용자가 접근하려고 하는 자원에 해당 사용자가 권한이 있는 지 판단 (Are you allowed to access what you are trying to access? - Policy Server에서 수행)

3. SSO 토큰 (Token) 생성: SSO Interceptor가 현재 접근한 사용자가 인증 받은 사용자인지를 판단하는 기준인 SSO 토큰을 생성하고, 필요할 경우 여기에 부가적인 사용자의 정보를 추가적으로 담아 SSO 솔루션이 보호하고 있는 뒷 단의 어플리케이션에 추가적인 사용자 정보를 전달한다.

다시 설명하면 SSO 솔루션은 보호가 필요한 웹사이트 (즉 웹 서버의 특정 디렉토리)에 대하여 대개 ISAPI (Internet Server API)나 NSAPI (Netscape Server API)형태로 되어 있는 Interceptor (또는 필터라고도 함)를 올려놓고 이 Interceptor에서 토큰의 존재여부를 판단하여 토큰이 있으면 요청 리소스에 엑세스를 허용하고, 토큰이 없으면 인증창으로 퉁겨내어 인증을 받기 전에는 해당 리소스를 사용할 수 없게 하는 구조로 구현되어 있다.물론 각 솔루션 업체들마다 약간의 기능, 성능의 차이는 보이지만 대체로 이러한 구조를 공통적으로 가지고 있는 것이 일반적이다.

그럼 포탈과 SSO솔루션의 관계는 무엇일까?포탈만 사용해서 SSO을 구현할 수 있을 까?만약 그것이 사실이라면 포탈은 SSO 솔루션의 기능을 포함하고 있는 것인가?

결론적으로 말하면 포탈은 SSO 솔루션의 기능을 포함하고 있지는 않다.업체별로 하나의 제품군으로 SSO솔루션을 포탈과 같은 제품군에 포함시켜 놓은 경우는 있지만 두 가지 솔루션은 그 목적이 전혀 다른 솔루션이다.물론 포탈 소프트웨어만 가지고 포탈과 통합된 서비스나 어플리케이션들에 대하여 SSO을 구현하는 경우도 있지만 이는 SSO 솔루션을 사용하여 구현했을 때와는 그 구조가 다르며 일반적으로 권유하는 방법은 아니다.

그럼 SSO과 포탈은 어떤 관계가 있을 까?

포탈은 SSO 솔루션 입장에서 보면 그가 보호하는 많은 웹사이트 중 하나의 웹사이트일 뿐이다.

이를 이해하기 위해 다음의 그림을 보자.

그림 2) 포탈과 SSO 솔루션의 관계

SSO 솔루션은 자신이 보호해야 하는 웹 리소스 (웹 서버)들 상에 탑재되어 그 웹사이트에 대한 접근을 허가한다.더 정확하게 말하면 사용자는 SSO 솔루션을 통과하기 전에는 자신이 요청한 URL에 물리적으로 액세스 할 수가 없다.앞에서 설명한 토큰을 가지고 있는 클라이언트가 자신이 액세스할 권한이 있는 웹 리소스에 접근하여 할 경우에는 SSO 솔루션이 해당 요청을 통과시키며 그때가 되서야 그 해당 리소스에 물리적으로 접근한 것이다.포탈은 이렇게 SSO 제품이 보호하는 여러 개의 웹사이트 중 하나일 뿐이다.위의 그림에서 보듯이 노란색 포탈 웹사이트와 주황색 다른 웹사이트를 접근하기 위해서는 공통적으로 SSO 제품을 먼저 통과해야 한다.그때 필요한 것이 SSO 토큰이며 이는 그림의 파란색에 노란색 번개모양으로 그려져 있는 것들이다.보통 웹사이트와 포탈이 SSO 솔루션과의 통합에 있어 다른 점은 엔터프라이즈 포탈은 이 포탈에 통합된 뒷단의 많은 웹 리소스에 대해서도 같

은 SSO 기능이 제공되어야 하기 때문에 자신이 받은 SSO 토큰을 자신의 뒷단에 있는 웹 리소스 들에 전달해 줄 수 있는 기능을 가지고 있는 것이 차이점이라면 차이점이라고 할 수 있다.

Portal & EAI (Enterprise Application Integration)

엔터프라이즈 포탈이 시장에서 알려지기 시작하면서 이를 도입하고자 하는 기업들이 가장 혼란을 많이 겪었던 것 중의 하나가 포탈과 EAI가 어떻게 틀린 것이며 어떤 관련이 있는 지에 대한 것이다.

실제 포탈 시장 초기에는 EAI 벤더들을 중심으로 엔터프라이즈 포탈을 구현하려면 필수적으로 EAI를 먼저 수행해야 한다는 주장이 있기도 했다.이것이 사실일까?대답은 “그렇지 않은 경우가 대부분이다.”라는 것이다.

EAI에 대하여 살펴보자. EAI라는 개념도 상당히 방대한 것이기 때문에 그 정의에 따라 상당한 차이가 있을 수 있으나 EAI 솔루션 들이 제공하는 주된 기능은 기업이 보유하고 있는 서로 상이한 다양한 어플리케이션이나 데이터베이스 사이에 서로 메시징을 할 수 있는 버스 (Bus)를 구현하는 것을 뜻한다.

그림 3) EAI 시스템의 구조

예를 들면, 기업의 인터넷 쇼핑몰을 통하여 카메라가 하나 판매되면 이 이벤트를 회계 시스템에서 받아서 매출로 기록하고 Inventory시스템에서는 재고를 하나 줄이는 일련의 작업이 자동화될 수 있다.물론 이러한 작업이 가능하기 위해서는 EAI 솔루션이 제공하는 메시징 버스의 표준에 맞도록 각 어플리케이션이나 데이터베이스의 정형화 (Normalization)과정을 거쳐야 하기 때문에 많은 비용이나 노력이 소요되는 것이 일반적이다.이러한 작업을 통하여 얻을 수 있는 부가적인 효과는 이 Message Bus에서는 일반적으로 웹 인터페이스를 제공하기 때문에 해당 버스와 통합된 어플리케이션이나 데이터를 웹단으로 끌어낼 수 있는 방법을 제공한다는 것이다. 가끔 EAI 벤더들이 기업이 가지고 있는 웹으로 구현되지 않은 어플리케이션의 웹화 방안으로 EAI솔루션을 제안하는 것이 이러한 이유 때문이다.하지만 역시 EAI 솔루션의 주된 기능은 서로 다른 다양한 시스템을 묶어 하나의 큰 줄기의 프로세스를 만들어 내는 데 있다고 할 수 있다.

그림 4) EAI 솔루션을 사용하여 구현한 여러 다양한 시스템을 통합하는 프로세스

엔터프라이즈 포탈을 구축함에 있어 EAI 솔루션이 필요한 경우는 위에서 보는 경우처럼 여러 상이한 시스템을 아우르는 프로세스를 포탈상에서 구현해야 할 경우에 한정되며 이러한 프로세스는 대부분 사용자들의 간섭이 없는 상태로 자동화되는 경우가 대부분이기 때문에 포탈에서는 이러한 프로세스를 일으키는 트리거 포인트나 결과 모니터링 화면만 통합이 되는 경우가 대부분이다.하지만 포탈을 구현함에 있어 이렇게 여러 시스템을 아우르는 복잡한 프로세스가 필요한 경우는 극히 제한적이며 많은 경우 전혀 필요 없는 경우도 많은 것이 사실이다.

결론적으로 얘기하면 EAI 솔루션을 사용하여 통합된 새로운 형식의 프로세스 (위의 그림과 같은)는 포탈과 통합되는 수많은 서비스 들 중의 일부이며 포탈 상에서 구현되는 업무 어플리케이션의 성격에 따라서는 전혀 필요 없는 경우도 있다.아래의 그림은 포탈과 EAI 솔루션과의 관계를 도식화하여 설명한 것이다.

그림 5) 포탈과 EAI

Portal & KMS (Knowledge Management System)

지식경영에 대한 필요성이 대두되면서 소프트웨어적으로도 이를 뒷받침하기 위한 많은 시도가 있어왔고 국내에서 이러한 시도의 결과물로서 대두되게 된 것이 바로 KMS라는 솔루션이다.물론 KM (Knowledge Management)이라는 것은 소프트웨어가 아니라 문화적인 측면이 더 중요한 것이 사실이지만, 보다 효과적으로 이러한 문화정착을 활성화하기 위해 IT기술을 접목한 것이KMS라고 할 수 있겠다.

품질이 높은 지식을 쉽게 등록하고 조회 할 수 있게 하고 또 그에 대한 평가를 통해 이를 활성화한다는 것이 기본적인 개념이며 이를 위한 일련의 지식 Screening 과정 및 분류체계, 지식등록 시 보상체계 등을 소프트웨어 적으로 관리할 수 있도록 구현한 것이 KMS시스템이라고 보면 되겠다.

이렇다 보니 이 시스템이 성공하기 위한 필수적인 조건은 앞으로 지식으로 분류될 만한 모든 컨텐츠 들은 KMS에 입력해야 한다는 데 있다.지금까지 현존해온 시스템에 있는 컨텐츠 중 지식으로 분류될 만한 데이터는 데이터 마이그레이션을 통해 KMS로 옮겨오고 앞으로 생성될 새로운 지식은 꼭 KMS에서 입력하자는 것이다.어떻게 보면 기업의 문서들을 체계적으로 관리하기 위해 중앙 집중적인 Document Management System (DMS)를 사용하는 것과 비슷한 개념이라 하겠다.

그럼 KMS와 포탈은 어떤 관련이 있을 까?많은 분들이 벌써 짐작하고 있겠지만KMS는 포탈에 “지식”이라는 컨텐츠를 제공해주는 하나의 통합대상이 되는 서브시스템이다.

사용자 입장에서 생각해보자.내가 어떤 정보를 게시판에 올리려고 한다.이러한 경우 내가 지금 올리려고 하는 컨텐츠가 단순 정보인지 지식인지를 판단하여 올릴 곳을 정한 후 그 해당 시스템에 입력해야 한다면 그 효율성이 과연 높아질까?

어떤 사용자가 정보를 찾으려고 한다.내가 찾는 정보가 단순 정보인지 지식인지 아니면 회계 어플리케이션 내에 저장되어 있는 현황 데이터 인지를 사용자가 일일이 판단하여 해당 시스템에 가서 조회를 해야 한다면 과연 

그 서브시스템들의 효용성이 높아질까?

이 두 가지 문제점을 포탈은 서브시스템의 종류에 상관없이 업무별 또는 목적 별로 조합형 어플리케이션을 만듦으로써 해결한다.사용자는 정보의 종류는 신경 쓸 수도 없고 신경 써서도 안된다.사용자는 그가 처리하고자 하는 업무에 관련된 중요한 정보, 지식, 컨텐츠 등을 하나의 논리적인 업무 어플리케이션에서 제공받고 해당 업무 어플리케이션을 구성하고 있는 단위 서비스들은 사용자의 액션에 따라 각기 자신의 레포지터리 (Repository)에 데이터를 저장하고, 그 레포지터리로부터 조회를 한다.이런 모든 과정은 사용자에게는 블랙박스형태로 표출되며, 사용자는 자신이 현재 입력한 데이터가 어느 시스템에 저장이 되며 나중에 조회를 할때는 어디로부터 해야 하는지를 전혀 신경 쓰지 않는 상태에서 업무를 처리하게 된다.왜냐하면 그가 데이터를 입력하고 조회하기 위해 접근하는 단 하나의 어플리케이션은 포탈을 기반으로 이러한 서브시스템들의 서비스들을 조합하여 만들어낸 새로운 형태의 업무 어플리케이션이기 때문이다.이러한 개념을 시장 조사 기관인 Gartner사에서는 Composite Application 또는 Service-oriented Application (SOA)라는 이름으로 명명하고 이를 새로운 어플리케이션 패러다임으로 소개하고 있다.이에 대한 자세한 설명은 지난호에서 자세히 설명한바 있다.

Portal & Groupware

흔히 그룹웨어를 기반으로 한 포탈을 얘기하는 경우가 있다.위의 지식관리시스템에 포탈 사용자 인터페이스를 입힌 경우와 비슷한 경우라고 할 수 있는 데 그룹웨어에서 다른 시스템들을 접근할 수 있는 링크를 모아서 제공하거나 가끔은 다른 어플리케이션의 화면도 포탈과 비슷한 형식으로 보여주는 경우도 있다.

한국 기업에 구축된 그룹웨어를 분석해 보면 많은 경우 불필요하게 비대해진 경우가 많다.다른 시스템에 대한 접근 통로뿐 아니라 목적, 업무별 공지, 게시판 등 그 업무의 복잡도에 비례하여 그룹웨어 시스템도

본연의 목적에서 벋어나 다른 목적으로 전용된 경우가 많다.왜 이런 일이 생겨났을 까?

그 이유는 그룹웨어가 기업의 전직원이 공통적으로 매일 접근하는 몇 안 되는 공간이기 때문이다. 전사적인 범위의 정보전달 매체로서 그룹웨어를 대체할 만한 특별한 대안이 없었기 때문에 그룹웨어가 필요에 따라 비대해지기 시작했고 그룹웨어를 이런 식으로 몇 년 정도 운영해온 기업들은 속도 저하, 정보의 산재 등의 어려움을 겪게 된다.본인의 게시물을 올려야 하는데 너무 게시판의 종류가 많다 보니 어디에다가 올려야 할 지 모르고, 그러한 콘텐트를 조회하는 사람들도 어느 게시판에 그 종류의 콘텐트가 올라올지 잘 모르는 상황이 되어버릴 정도로 정보 전달 통로의 심각한 왜곡이 있는 것이 현실이다.

이러한 문제는 그룹웨어가 포탈의 역할을 하려 했기 때문에 생겨나는 문제점 들이다.그룹웨어는 포탈에 그룹웨어가 제공하는 본연의 서비스 (메일, 결제, 수신문서 등)만을 제공하는 서브시스템일 뿐 포탈의 도입 목적인 다양한 업무별, 목적별 어플리케이션 구현 및 관리에 좋은 솔루션은 아니기 때문이다. 포탈 시스템이 제공하는 유연성은 그룹웨어를 이용하여 비슷한 목적을 이루려 했을 때 발생하는 문제점들을 근본적으로 해소해준다.

이 때문에 그룹웨어를 기반으로 포탈을 구현했던 많은 기업들이 다시 엔터프라이즈 포탈 솔루션을 도입하여 예전의 그룹웨어는 메일, 결제, 수신문서의 본연의 기능만을 남기고 나머지 역할은 모두 새로운 포탈로 옮기는 작업을 수행하게 된 것이다.

Portal & Search

포탈에 있어 검색은 필수적인 요소이다.검색이 없는 포탈이라는 것은 상상할 수도 없다. 포탈이라는 것이 기업이 가지고 있는 많은 서비스와 정보를 통합한 것이다 보니 그 종류와 양이 방대해 지게 된다.이를 효과적으로 사용자들이 찾아 쓸 수 있도록 해주는 것이 검색이다.

흔히 통합검색엔진이라는 이름으로 불리는 전문 검색엔진을 이용한 프로젝트는 문서들에 초점을 맞추게 된다.여러 시스템에 흩어져 있는 문서 및 콘텐트를 한번의 검색으로 모두 찾아주는 것이 그것이다.

하지만 포탈에서의 검색은 여기에 몇 가지가 더 추가된다.포탈에는 문서만이 통합되는 것이 아니기 때문이다.포탈에 통합되는 단위서비스들, 포탈을 기반으로 구현된 조합형 어플리케이션 들, 포탈을 사용하는 사용자 등 포탈에 통합된 모든 자원을 검색할 수 있어야 진정한 의미의 엔터프라이즈 검색일 수 있다.

따라서 엔터프라이즈 포탈 도입을 검토하는 기업들은 검색기능이 포

탈과 얼마나 타이트하게 통합되어 있는 지 확인하는 과정을 꼭 거쳐야 한다.문서만 검색하는 것은 기업이 가지고 있는 리소스 중 일부만을 포함하는 부분적 접근이기 때문이다.

Portal & Content Management, Portal & Collaboration

포탈에서 필요로 하는 여러 가지 기반서비스들 중에 대표적인 것이 컨텐츠관리와 협업기능이다.

기업 내외부에서 생산되는 각종 타입의 디지털 컨텐츠의 라이프사이클을 관리하는 CMS (Content Management System)은 크게 컨텐츠의 생성과 컨텐츠의 제공 (Delievery)을 관리하기 위한 솔루션이다.

1980년대 중반 무렵 소개되기 시작한 문서관리 (Document Management)에서 시작된 이 솔루션은 웹이라는 새로운 형태의 강력한 Delivery 채널이 부각됨에 따라 웹 페이지 형식의 컨텐츠를 관리하기 위한 Web Content Management의 영역으로 발전을 거듭해왔으며, 근래에는 웹 페이지 뿐만이 아니라 다양한 형태의Rich Media (동영상, 음성 등)까지도 그 영역에 포함시키고 있다.따라서 이러한 문서, 웹 컨텐츠, Rich Media 등 기업이 생성하고 사용하는 모든 컨텐츠를 관리할 수 있는 솔루션을 일컬어 엔터프라이즈 컨텐츠 관리 시스템(Enterprise Content Management System)이라고 한다.

그림) 엔터프라이즈 컨텐츠 관리 시스템의 구성요소

엔터프라이즈 포탈에서도 다양한 디지털 컨텐츠 들이 사용된다.그 중에서도 가장 대표적인 것이 웹 페이지 형식의 컨텐츠 들인데 CMS를 활용하면 이러한 컨텐츠 들이 생성되는 과정을 중앙에서 관리하여 정보가 퍼블리싱 되기 전 단계에서 컨텐츠의 내용 및 사용자 인터페이스 등의 품질 적합성을 확인할 수 있어, 현업에서 직접 컨텐츠를 작성하도록 할 수 있다.

이렇게 엔터프라이즈 포탈을 기반으로 만들어지는 업무별, 목적별 조합 어플리케이션 들에 이러한 CMS의 서비스를 사용함으로써 비즈니스 유저들이 직접 컨텐츠 생성에 참여할 수 있는 길을 제공해주는 것이다.

하지만 CMS도 역시 기업이 가지고 있는 많은 정보 모두를 관리할 수는 없다.아무리 CMS를 전사적으로 이용한다고 해도 이러한 디지털 컨텐츠 이외의 정보나 프로세스는 여전히 기존 어플리케이션이나 배후 시스템들에 남게 된다.결국CMS도 포탈과 통합되어 부분적인 서비스를 제공하는 부품일 뿐 엔터프라이즈 포탈의 역할을 대신할 수는 없는 것이다.

협업 (Collaboration) 소프트웨어는 사용자 들이 온라인 상에서 서로 함께 일을 할 수 있도록 도움을 주는 서비스 들을 제공해주는 기능성 어플리케이션의 집합이다.

이 중에는 일반인들도 친숙한 인스턴트 메신저나 게시판 등의 서비스뿐만 아니라 화상회의, 전자칠판, 프로젝트 관리 등 제품에 따라 다양한 형태의 기능들을 제공하고 있다.

그림) 협업 솔루션의 예

이런 협업 서비스 들은 엔터프라이즈 포탈 구현에 있어 상당히 중요한 기능을 제공한다.요즘 업무 어플리케이션 들은 단순 정보 조회뿐만이 아니라, 해당 주제의 업무를 중심으로 함께 온라인 상에서 작업을 할 수 있는 공간을 제공해 주어야 하기 때문이다.예를 들어, 세일즈맨의 업무 지원을 위한 Sales Productivity Application이 있다고 하자.이 어플리케이션 내부에는 세일즈맨 들이 보아야 할 상품 정보, 고객 정보, 매출 정보 등의 정보도 제공을 해주어야겠지만 세일즈맨 들이 서로 또는 전문가에게 상품에 대하여 물어보고 의견을 교환할 수 있는 게시판 형태의 서비스가 없으면 아니 된다.엔터프라이즈 포탈을 기반으로 하는 어플리케이션 작성시 이러한 협업을 위한 다양한 서비스를 제공하는 것이 Collaboration 소프트웨어이며 이 역시도 포탈에 통합되어 재사용되어야 하는 서브 시스템 중 하나이다.

이러한 CMS와 Collaboration의 두 가지 서비스는 어떠한 업무 어플리케이션을 구성을 할 때도 필수적으로 포함되는 것이 일반적이다.따라서 이렇게 기반이 되는 서비스들은 포탈 단에서 재사용이 쉬운 형태로 제공되는 것이 좋다.포탈을 검토하는 기업들은 이러한 기능들을 세부기능을 가지고 평가하는 것도 중요하지만 해당 기능이 얼마나 포탈과 타이트하게 통합이 되어 있는 지에 더 신경을 써야 할 경우가 많다.아무리 좋은 기능을 제공할 지라도 포탈과의 통합이 어렵다면 그 시스템은 재사용이 상당부분 제한될 수 있기 때문이다.

Portal & BPM (Business Process Management)

BPM(Business Process Management) 솔루션은 기업 내외의 업무 프로세스를 가시화하고, 업무의 수행과 관련된 사람, 시스템을 프로세스에 맞게 실행 / 통제하며, 전체 업무 프로세스를 효율적으로 관리하는 시스

템이다.

기업내부에는 수많은 비즈니스 프로세스가 존재한다.이러한 프로세스는 두 가지의 큰 형태로 구분될 수 있다.

1. Simple Workflow

2. Complex Workflow

1번의 경우에는 우리가 흔히 주변에서 볼 수 있는 형태의 프로세스이다.예를 들면 임직원이 휴가신청을 시스템을 통해서 하면 그 신청을 그 직원의 메니저가 승인하고 그 결과는 HR에 송부된다.이러한 간단한 워크플로우는 굳이 BPM 솔루션 기반으로 개발할 필요는 없다.물론 나쁠 것은 없겠으나 투자대비 효과로 볼 때 이렇게 단순한 프로세스를 위해 값비싼BPM 소프트웨어를 투자하는 것은 효과적이지 않다고 할 수 있겠다.

2번의 경우는 다르다.이 경우는 해당 비즈니스 프로세스가 일반적인 코딩의 형태로 구현되기에는 너무나도 변수가 많기 때문에 전문 솔루션 없이 구현했다가는 그 유지보수에 엄청난 비용을 초래할 수 있는 것들이다.

기업이 BPM 솔루션 도입을 검토해야 할 때는 2번의 경우이다.하지만 이 경우도 지금 현재의 프로세스를 그대로 시스템화 하기 보다는 프로세스 자체를 최적화 시킨 후에 이를 시스템화하는 것이 바람직하다.따라서 BPM 솔루션 구축은 기업의 업무 프로세스에 대한 정비가 동시에 진행되어야 그 진가를 발휘할 수 있을 것으로 생각된다.

그림) BPM 솔루션의 프로세스 모니터링 화면

이러한 BPM 솔루션과 포탈이 함께 구현이 되었을 때의 관련성은 다음과 같다.간단하게 말하면 BPM은 뒷단에 흘러다니는 프로세스의 과정을 관리하며, 포탈은 이러한 과정에 있어 각 사용자가 처리해야 할 작업 및 필요 어플리케이션에 대한 인터페이스를 제공하게 된다.즉 사용자는 자신의 업무 포탈에서 자신에게 할당된 작업을 확인하고 수행하게 되며 포탈은 이러한 사용자와의 상호작용이 필요한 부분만을 단위 서비스로 만들어 사용자에게 제공하게 되는 것이다.

아래의 그림은 미국의 회계관리를 규정하고 있는 Sarbanes-Oxley법안의 규정을 만족하고 있는 BPM과 포탈이 통합된 시스템의 예시도 이다.

그림) 포탈과 BPM솔루션이 통합된 모습

끝맺는 말

이번 호에서는 기업들이 엔터프라이즈 포탈 구축을 검토할 때 주로 겪게 되는 어려움 완화에 조금이라도 도움이 되고자 포탈 솔루션과 주로 혼동을 일으키는 여러 가지 기업용 소프트웨어 들과의 상호 관련성 및 차별성에 대해서 이야기를 했다.

다양한 기업용 소프트웨어에 대하여 이야기를 했지만 결론적으로 이러한 소프트웨어 들은 포탈에 통합이 되어 최종사용자에게 하나의 단위 어플리케이션이나 기능, 콘텐트의 형태로 제공될 단위 서비스 들을 제공하는 것이며, 엔터프라이즈 포탈은 이러한 단위 서비스들을 조합하여 비즈니스적 가치를 극대화 시킬 수 있는 새로운 형태의 업무 어플리케이션을 구현하고 관리하는 Service-oriented Application Framework인 것이다.

다음 호에서는 솔루션 이야기에서 조금 벗어나 실제 엔터프라이즈 포탈 프로젝트를 기획함에 있어 유의해야 할 여러 가지 유의점에 대해 설명할 것이다.

맥이 뭐가 좋은데? 이거 왜 쓰는데?

글쎄 왜 좋을까? 

맥빠라서? 아님 아이폰 개발 하기 편해서?

여러 이유가 있을 것이다.

그중 하나는 맥이란 넘은 블루스크린 같은 에러도 자주 안 뜨고, 커널패닉도 자주 안뜨고, 죽는 일도 자주 없고 안정적이다란 이야기일것이다. 

그러나, 꼭 그런 것 만은 아니다. 

OSX라는 OS는 아무래도 Unix Like하기 때문에 파일 시스템이 문제가 생기는 일이 종종 있다.

역시 브카에게도 시련이 이런 시련이 왔다.

어느날 갑자기 부팅이 느려졌다. (평상시는 그냥 잠재워서 다니지만 오랜 시간 들고 다녀야 하면 꺼놓는다)

이걸 해결해볼까 하고  암것도 모르는 브카는 

디스크 유틸리티를 실행시켰더니만.

 

에러 란다. 

별거 아니겠지. 

왜 이러지 이넘이? 

아마도 패러럴즈 띄워 놓고 그냥 파워눌러서 꺼서 그런가? 

아님 술먹고 가방을 던졌나?

너무나도 오랫만에 올리는 포스팅!

맥북을 구입한지 어언 한달이 다되어 가는데 이제서야 MacBook Pro개봉기를 올린다.

처음 그설레임을 그대로 ..

드디어 1주일의 기다림을 무색하게 하는 Macbook Pro Box

애플은 박스부터 깔끔하다.

앞과 뒤의 모습들

개봉을 하니 박스에 스폰지가 들어있어서 배송시에 충격을 완화할수 있도록 되어 있다.

맥북이 번쩍이는 이유는 잘 포장된 커버로 덮여 있기 때문이다.

아답타가 생각보다 작았다 무게역시나 일반 아답타보다 가볍다. 더군다나 흰색!

전체적으로 풀어놓은 모습이다. 간단하다.

드디어 Macbook pro를 풀어버린다.

앞면

뒷면

보호필름을 벗기고 나니 번들거린던 모습이 알루미늄 제질로 그 자태를 보여준다.

자판과 모니터 사이에는 보호지가 끼워져 있다.

알루미늄 유니바디에 까만 키보드, 그리고 전체적으로 까만 모니터

오~ 멋지다.

부팅을 최초로 시작했다.

애플 로고가 나오고... 특유의 오픈 멜로디가 나온다.

부팅 후 스노우 레오파드의 모습이다. 기본적으로 어플이 많이 Dock에 올라와 있다.

좀 더 좋은 사진을 찍으려 했으나 카메라와 회사라는 장소적 이유 때문에 아이폰으로 촬영을 했다.

첫느낌은 깔끔함.

그리고 새로움이다.

한달여 사용하고 있는데 이제서야 개봉기를 올린다.

개봉기 이후 프로그램 사용과 간단하게 배운 팁들도 차차 올려볼까 한다.

지금은 기존에 쓰던 회사에서 지급한 HP Elitebook을 집어 던지고 이녀석을 메인 노트북으로 사용중이다.

IE 말고는 불편함이 많지는 않다.

IE는 bootcamp와 parallers로 사용 중이다.

참고로 맥북을 구입후 소프트웨어 구입 비용이 너무 많이 증가하고 있다.

정말 애플은 지름을 권장하게 만드는 마력이 있는 듯 하다.

맥이라는 녀석을 클래식때 만난 이후에 20년이 지난 지금 다시 만나서 사용하고 있지만, 인터페이스의 편리성은 역시나 우수하다

제발 수리없이 쓸수 있기를 바라면서

이로써 허접 개봉기를 마친다.

▲ 출처 : http://www.flickr.com/photos/30404396@N00/335159280
(KOSA로 filckr에서 검색하면 처음에 나오는 사진 ^^)

브카가 SW경력 기술자 자격 관련 포스팅을 한지 어언 4개월이 지났다.

[연재] SW 경력 기술자 자격을 위한 경력 찾아 삼만리 - episode 1

길고도 힘든 싸움이 될 것이라고 생각하고 시작했지만,

역시나 너무나 힘든 작업이다.

아직도 관련 되어서 진행 중이며, 열심히 경력을 찾아서 헤매고 있다.

그 동안의  돌아다닌 길을 되 집어 본다.

먼저 몇가지 추가 사항이다.

네군데의 회사를 다녔던 브카는 먼저 각 회사인사과에 전화를 했고 양해를 구하고, 관련 사항을 이야기 했다.

중소기업이나 기존에 유대가 있는 회사는 그래도 인사과에 전화하기가 어렵지 않았는데,

대기업 같은 경우는 인사과 담당 직원만 찾는데, 한참 걸렸다. 더군다나 없어진 연구소 담당은…

그래도 운이 좋았는지 인사 담당자들과 모두 통화가 되었고, SW 경력 기술자 자젹에 관련된 사항을 이야기하고 협조를 구했다.

대부분 인사 담당자들은 관련된 인사 기록을 찾아보고 연락을 준다고 했고, 하나, 둘, 연락이 오기 시작했다.

물론, 직접 방문해서 이야기 해도 되지만 이런 업무에 시간을 뺏기기를 즐겨 할 사람은 없을 듯해서,

전화로 확인을 하고, 관련 서류를 Email로 보내서 확인을 받았다.

문제는 이때부터이다.

현재  KOSA에 등록이 되어 있고, 운영 중인 회사들은 규칙_서식21(근무경력확인서) 하나로 해결이 되고,

브카가 SW관련 업무를 했다는 것이 부서나 팀 등 인사기록이 남아 있어서 그나마 쉽게 인정을 받고, 빠른 협조가 이루어 졌지만,

현재 연구소가 사라지고, 부문이 사라진 회사는 KOSA에 등록이 안된 관계로

관련 서식인 별지 제2호 소프트웨어기술업무 전담부서 확인서 를 추가로 확인 받아야 하고,

이를 확인 받는데 회사입장에서는 SW관련 업무를 했다는 것을 알고는 있지만, 팀이나 부서에 관련 업무를 한 인사기록이 정확하지 않을 경우, 직인이 찍혀서 나가야 함으로 매우 조심스러워질 수 밖에 없다.

암튼 어찌 어찌 해서 인사과 담당자 분들에게 애원(?)하고, 부탁해서 그나마 잘 진행이 되었다.

조금 수고를 덜하는 방법으로는

방문보다는 전화를 하고, 메일로 문서를 보내고 편지나 등기로 직인이 찍힌 문서를 받는 방법이 아무래도 돌아다니는 것보다는 쉽다.

애로 사항이라면 약간의 회사와의 이견이 있을 시에 풀기가 어렵다는 것이 단점이긴 하지만…

현재 브카의 SW 경력 기술자 자격을 위한 경력 찾아 삼만리는 1단계 진행이 되었다.

이젠 모든 서류를 갖추고선 신고를 하는 일이 남았다.

매달려 있기 힘들지만, 제대로 된 경력을 찾아 동분서주 계속 뛰어야 겠다.

휴~~~~~

물 쳐드삼! 정신 좀 차리게.

이미지출처 : www.samsung.co.kr

- 다운로드 PC벨

- 포토폰 북

- my Screen

- 애니콜 랜드

- 나만의 이미지

- 나만의 멜로디

현재 브카는 일명 블랙잭이라고 하는 SKT용 SCH-M620을 휴대폰으로 사용 중이다.

차량 운전시에 아무래도 전화를 받기가 힘들어서 큰(?) 맘을 먹고 블루투스 해즈프리를 장만했다.

BTM-202 라는 모텔로 평가도 좋고 가격도 착하고 해서 하나 훅~ 구매를 했다.

▲ BTM-202 이넘이다.

뭐 여기까진 좋다.

이녀석은 수신과 발신도 잘되고 블루투스 연결도 매우 잘된다.

하지만, 문제는 다른 곳에서 발생을 했다.

발신 시에  핸즈프리 통화를 누르면 항상 언제나

발신 시에 마지막으로 통화한 번호로만 연결이 되어서 통화가 된다.

번호 입력이나 주소록 선택해도 마지막 통화 번호로만 연결이 된다. ㅠㅠ;

그래서 핸즈프리 업체에도 문의를 해봤고, 삼성전자에도 문의를 해봤다.

결론은 현재의 블랙잭으로는 블루투스 프로파일(?)상 마지막 통화 번호로만 연결이 된다.

그러니까, 다른 핸즈프리를 써도 마찬가지이다. 엔지니어 얘기론 MS의 smartphone이나 PDA폰들은 전부 그렇다고 한다.

이 부분은 다른 휴대폰을 직접 테스트하지 않아서 모르겠다.

어찌됬든 블랙잭은 변경할 수 없다고 한다.

결국, 전화를 핸즈프리로 걸려면 미리 휴대폰으로 걸고, 끊고 나서 다시 핸즈프리로 거는 행위를 해야 하는 불편함이 있다.

삼성전자 홈페이지의 블랙잭 악세사리에 보더라도 WEP 180이라는 삼성 블루투스 핸즈프리가 역시나 마찬가지로 설명되어 있다.

반토막짜리 핸드프리가 된것이다. ㅠㅠ;

mymits나 todayppc에서 찾으면 혹시라도 수정 방법이 있지 않을까 생각은 하지만 귀찮아서 그냥 사용하기로 했다.

브카의 다른 핸드폰인 쿠키폰에서는 핸즈프리 BTM-202 동일 모델이 기능을 아주 잘 작동을 한다. (이런.. ㅠㅠ)

블랙잭 사용자라면 아니 Smartphone이나 PDA 폰 사용자라면 반드시 이 부분을 확인하고 블루투스 핸즈프리를 구매하길 권한다.

혹시라도 블랙잭에서 핸즈프리 기능을 전부 사용하고 있으신 분이 있으면 댓글 좀 부탁드린다.

어찌하면 되는지…. ^^;

혹시나 해서 ROM을 WM6.3으로 업글을 해보았지만, 마찬가지다.

업글까지 했는데 ㅠㅠ;

▲ 이 녀석이 업글한 UI다.

▲ 블랙잭~~~

ps.MS 안고쳐 줄꺼냐? 엉? 삼성이라도 고쳐줘야 되는 거 아닌가?

헐~~~

tistory에서 이사를 했습니다.

바로 textcube.com으로~~

적응은 안되고 있습니다. ^^;

http://brainchaos.kr

이사온것을 조금은 후회 하고 있습니다.

 

이유는 물론 스킨 적용하기가 너무 어렵다는거

제공하는 스킨말고 다른 스킨을 적용했더니 와... 너무 힘드네요.

특히나 트랙백 부분이 대박입니다.

 

저처럼 코딩 잘 못하는 사람은 너무너무 힘듭니다.

어찌됬든 일단은. 현재 스킨 적용까지는 마쳤습니다.

 

그런데 이런 mixUP 위젯이 에러가 납니다.

과감하게 뺐습니다. ㅠㅠ;

 

ps. 수정했습니다.

하츠(hots)의 꿈 (http://blog.bsmind.co.kr/37) 이곳을 참조하시면 됩니다. ^^;

 

사이드바 위젯은 현재 크롬에서만 잘 작동 합니다.

음 IE나 firefox에서는 움직이지도 않고 빠지지도 않고

에헤라 디여~~

 

암튼 여러가지가 많이 적용하는데 아쉽네요. 에고고고...

 

그리고 firefox에서 로그인이 안되는 문제가 있네요. ^^;

--> 지금은 잘됩니다.

그런데 도대체 연관글 설정했는데 왜 안나는거지 모르겟군요. 헐~~

그래도..

점점 더 발전하지 않을까란 생각에 옮겼습니다. (과연.. 기대해도 될지.~~)

얼마나 버팅길수 있을지는 모릅니다.

(이미 너무 티스토리에 길들여진 듯~~)

많이들 찾아와 주세요~~

그리고, 하나더~~

이곳 텍스트규브에서 구글 블로그 지원을 한다고 합니다.

한번 노려보는 것도~~ ㅠㅠ;

참고하세요~~

 See ya!!