낮의 빛으로

A candy colored clown they call the sandman
Tiptoes to my room everynight
Just to sprinkle stardust and to whisper
Go to sleep, everything is alright
I close my eyes then I drift away
Into the magic night I softly say
A silent prayer like dreamers do
Then I fall asleep to dream
My dreams of you

In dreams I walk with you
In dreams I talk with you
In dreams you're mine
All of the timewith you
Ever in dreams, in dreams

But just before the dawn
I awake and find you're gone
I can't help it, I can't help it if I cry
I remember that you said goodbye
It's too bad that all these things
Can only happen in my dreams
Only in dreams
In beautiful dreams

<<프로세스 능력 성숙도 모델(CMMI)의 적용>>

황영하ㆍ박종근

미국방성(DoD)의 자금 지원를 받아 프로세스 능력 성숙도 모델을 개발하고 있는 카네기멜론대학(Carnegie Mellon University)의 SEI(Software Engineering Institute)에서는 1993년 SW-CMM(Capability Maturity Model for Software) Version 1.1 모델과 1994년 SE-CMM(Systems Engineering Capability Maturity Model) Version 1.0을 개발하여 공표한 데 이어, 2002년도에는 CMMI(Capability Maturity Model Integration) Version 1.1 모델을 개발하여 공표하였다. 또한, CMMI Version 1.1 모델의 발간과 함께, 2003년도 말을 기준으로 하여 기존 SW-CMM 모델의 공식적인 폐기를 선언하였다. 즉, 기존의 소프트웨어공학과 시스템 공학분야로 양분된 모델을 CMMI 모델로 통합한 것이다. 이에 본 고에서는 CMMI 모델의 개요에 대하여 알아보고, 관련 표준 동향을 기초로 하여 관련 국제표준 및 모델과의 관계 및 그 적용 방안에 대하여 소개하기로 한다.

서 론

CMMI(Capability Maturity Model Integration) 프로젝트는 미국방성(Dapartment of Defense) 자금을 받은 NDIA(National Defense Industrial Asso-ciation)의 시스템공학위원회의 산학협력 프로젝트로 시작되었다. 이 프로젝트의 목적은 조직의 사업 전반에 걸쳐서 개발 프로세스를 개선하고자 하는 조직에 초점을 맞추어, 소프트웨어공학과 시스템공학으로 양분된 프로세스 모델을 하나로 통합하여 개발하는 것이었다. 통합된 CMMI 모델을 사용함으로써 프로세스 모델을 적용하고자 하는 조직은 여러 모델을 사용하는데 따르는 중복 비용을 절감하고, 사업 전반에 걸친 프로세스, 교육 및 평가와 관련하여 일정 효과를 얻을 수 있게 되었다. 또한, CMMI 프로젝트의 결과로, Staged 혹은 Continuous 모델에도 같이 적용할 수 있는 융튱성 있는 통합 모델이 개발되었다[5].
본 고에서는 카네기멜론대학의 SEI에서 현재 진행 중인 CMMI 프로젝트의 개요와 그 적용방안에 대하여 알아보고, 최근 동향에 대해서도 소개하기로 한다.

CMMI의 개요

1. 개요

1997년, 미국방성의 OSD(Office of the Under Secretary of Defense)는 NDIA와 함께 SEI의 SW-CMM을 계속 발전시키기 위한 프로세스 개선 모델의 통합을 위한 CMMI 프로젝트를 시작하였다. 1989년에 시작된 SW-CMM은 공군에서 경쟁력 있는 소프트웨어 개발업체를 선정하기 위하여 그 조직의 소프트웨어 개발 프로세스를 평가해 보고자 시작되었다. 그후 1993년에 SW-CMM V1.1[2]이 개발되어 공표되었고, 계속해서 V2.0이 개발되었으나 공표되지는 않았다. CMMI 프로젝트는 상호 다른 여러 가지 모델을 적용함에 따라 소요되는 비용과 노력을 절감하고, 엔지니어링 프로세스 개선을 위한 공용성을 극대화하여 통합된 모델을 개발하기 위하여 시작되었다[4].
1998년에 CMMI 프로젝트 추진 조직이 결성되었고, 아래 세 가지의 소스 모델을 통합하는 것으로 시작되었다[3].

- SEI의 Capability Maturity Model for Software(SW-CMM)

- Electronic Industries Alliance Systems Engineering Capability Model, Interim Standard (EIA/IS 731): EPIC(Enterprise Process Improvement Collaboration)에 의해 만들어진 Systems Engineering CMM(SE-CMM)과 INCOSE에 의해 만들어진 Systems Engineering Capability Assessment Model(SECAM)을 통합한 모델

- IPD-CMM: 미국방성(DoD)과 산업계에 의해 Integrated Product and Process Develop-ment(IPPD) 환경에 초점이 맞추어진 프로세스 성숙도 모델(EPIC에 의해 draft 형태로 공표됨.)

초창기의 의도는 시스템공학(CMMI-SE)과 소프트웨어공학(CMMI-SW)에 따라 두 가지로 분리된 모델을 생각하였으나, 여러 토론을 거쳐서 EIA/IS 731.1로부터 Continuous representation을 유지하고, SW-CMM에서 익숙한 Staged representation으로 두 가지의 representation을 유지하면서 프로세스 모델은 하나로 통합하는 것으로 최종적으로 결정되었다. 따라서, 어떤 representation이 좋은지가 중요한 것이 아니라, 적용하려는 조직의 요구에 어느 representation이 가장 적합한지를 결정하여 적용하는 것이 중요하다 할 수 있다(representations에 대해서는 아래의 2항에서 설명하기로 한다)[4].

2. 모델의 구조

CMMI 모델은 각각의 Process Areas(PAs)내에서 specific goals와 generic goals의 달성정도를 측정함으로써 개선의 수준(정도)을 나타낼 수 있게 설계되었다. CMMI-SE/SW/IPPD 모델에는 Requirement Development, Validation, Configuration Management, Project Planning 등을 포함하여 총 24개의 PAs로 구성되어 있다.
CMMI 모델은 해당 프로세스가 조직 혹은 프로젝트에 적합한지를 판단할 수는 없다. 반면에, 프로세스가 만족해야 하는 최소한의 기준을 제시함으로써, 모델이 조직의 규모와 사업 목적에 따라서 적절하게 조정되어(tailored) 구현될 수 있게 할 뿐이다.

가. Representations
CMMI 모델은 두 가지의 representations을 제공한다. 이 두 가지의 representations은 사용자 즉, 조직이 프로세스 개선을 위한 접근 편리성에 따라 선택할 수 있는 각각의 접근 방법을 제공한다. Representations은 겉으로는 다르게 구성되어 있지만, 본질적으로는 동일한 내용을 담고 있다.
Continuous representation은 프로세스 능력(capability)-프로세스가 성취할 수 있는 예상 결과들의 범위-에 초점이 맞추어져 있다. 낮은 능력을 가진 프로세스는 즉흥적으로 실행되며 현재의 프로세스 실행자에 너무 의존적이고, 결과를 예상하기 어려우며 산출물의 품질보다는 프로젝트 일정을 맞추는 데 급급한 모습을 보인다. 반면에, 높은 능력을 가진 프로세스는 잘 정의되며 관리되고, 측정에 의하여 지속적으로 개선되며 해당 분야 기술이 잘 발휘될 수 있는 밑거름이 된다.
Continuous representation은 각 프로세스의 개선 정도에 대한 정보를 제공할 뿐만 아니라, 지속적인 개선을 위하여 필요한 프로세스를 선택할 수 있도록 조직에게 융통성을 제공한다. 프로세스의 능력 수준(capability level)은 총 6단계-(0) Incomplete, (1) Performed, (2) Managed, (3) Defined, (4) Quantitatively Managed (5) Optimizing-로 측정된다. 능력 수준은 각 PA에 제시되어 있는 specific goals와 generic goals의 달성 정도에 따라 결정된다. 예를 들어, 해당 PA의 specific goals과 generic goals가 능력 수준 2까지 달성되면, 그 조직의 해당 PA는 능력 수준 2에 이르게 된다.
Continuous representation은 조직의 사업 목적과 효과적인 위험관리를 위한 적용 프로세스와 개선의 순서를 조직이 스스로 정할 수 있게 되어 있다. Continuous representation은 EIA/ IS 731.1에서 적용한 representation으로, EIA/IS 731.1에 의하여 프로세스 모델을 구현한 조직에서 선호하는 접근 방법이다.
Staged representation은 조직 전체의 성숙도(organizational maturity)-수준별 관련 프로세스 집합의 전체 능력-에 초점이 맞추어져 있다. 그리하여, 높은 성숙도를 가진 조직은 조직이 가지고 있는 프로세스 집합의 능력이 낮은 성숙도를 가진 조직보다 더 높다는 것을 의미한다. 조직의 성숙도 수준(maturity level)은 총 5단계-(1) Initial, (2) Managed, (3) Defined, (4) Quantitatively Managed, (5) Optimizing-로 측정된다. 성숙도 수준은 성숙도가 높은 조직으로 가기 위한 과정상에 있는 잘 정의된 중간 단계로 볼 수 있다.
Staged representation은 기초적인 수준의 basic management practices부터 시작해서 정해진 경로(path) 및 순서에 따라 계속 발전해 나가면서 프로세스 개선을 추진하는 접근 방법을 사용하고 있다. 동일한 성숙도 수준을 적용하고 있는 SW-CMM으로부터 별도의 추가적인 조치가 없이 바로 CMMI로 전환하는 것도 가능하다.
Staged representation에서 generic practices는 common features로 분류되어 각각의 내용에 포함되어 있다. Common features중에서 “Commitment to Perform”은 경영방침(management policy)을 개발하고 그에 대한 지원(sponsorship)을 확보하는 practices로 구성되어 있고, “Ability to Perform”은 계획, 자원, 책임과 권한, 교육 등을 개발하고 실행해 나가는practices로 특성화되어 있다. “Directing Implementation”은 측정하고 관리하는 성과 관련 practices로 구성되어 있고, “Verifying Implementation”은 실행(implementation) 및 그 적합성에 관련된 practices로 이루어져 있다.

나. Integration
기존의 프로세스 개선 모델과 CMMI 모델과의 가장 큰 차이는 프로세스 개선에 대한 여러 분야의 관점을 하나로 통합했다는 것이다. CMMI-SE/SW 모델은 시스템공학과 소프트웨어공학 분야에 공통된 PAs을 통합하였다. CMMI-SE/SW/IPPD 모델은 Integrated Product and Process Development 환경에 필요한 몇가지practices를 추가하였다. CMMI-SE/SW/IPPD 모델은 일부 내용상 약간의 개정과 두 가지 PAs만을 추가한 점이 CMMI-SE/SW 모델과 다른 점이다. 2002년에 정식으로 공표된 CMMI-SE/SW/IPPD/SS 모델은 CMMI-SE/SW/IPPD 모델에서 아웃소싱과 관련된 practices가 더하여졌다. 그리하여, 기본 모델에서 일부 최소한의 추가만으로 여러 분야에 적용가능한 모델을 개발하였다.

. Process Areas

(그림 1)은 조직이 사업을 수행하기 위하여 사용하는 다양한 프로세스들 간의 통합성을 표현하고, 다양한 CMMI process areas 간의 관계를 보여주고 있다.

가. Process Management Process Areas
프로세스 개선 프로그램을 성공적으로 실행하기 위하여 필요한 모든 practices을 포함하고 있으며, 우수 사례, 프로세스 자산 및 교훈 등을 공유하고 문서화하는 능력을 제공한다. 또한, 품질과 프로세스 성과를 정량적인 목표로 세우기 위한 좀 더 진보된 능력도 제공한다.

나. Project Management Process Areas
프로젝트를 계획하고 모니터링 및 통제하기 위한 프로세스 관리 활동들을 담고 있으며, 공급자 혹은 고객과의 공약(commitment)을 체결, 유지 및 모니터링하는 메커니즘을 제공한다. 또한, 협력적인 팀제 환경을 마련하고 유지하는 메커니즘과 프로젝트를 역동적이고 정량적으로 관리하는 공통된 방법을 제공한다.

다. Engineering Process Areas
초기 요구사항 개발에서부터 사용자 환경에서의 결과물 인도에 이르기까지 제품 개발 생명주기 활동들을 지원한다.

라. Support Process Areas
제품 개발과 유지보수를 지원하기 위해 필요한 프로세스들을 제공하고, 통합을 원활하게 하기 위한 작업환경의 개발과 유지보수를 지원한다.

마. Custom Process Areas
사업환경에 따라, information insurance, enterprise integration, safety등의 특성화된 process area가 필요할 수 있다.

4. 모델의 평가

일반적으로CMMI 모델을 이용한 프로세스 개선 프로그램을 실행하려고 하는 조직은 조직내 개선이 필요한 부분을 식별하고 조직내 프로세스가 모델에 합당한지를 알아보기 위하여 자체 진단 심사(diagnostic assessment)를 실시한다. CMMI Product Suite의 한 요소인 Appraisal Require-ments for CMMI(ARC)는 CMMI 모델을 이용한 평가 방법을 적용하고자 할 때 고려해야 할 요구사항을 정의한 것이다. 이러한 요구사항은 자체적인 진단 평가 방법을 개발하려고 하는 조직에서 지침으로 사용될 수 있다. 평가 방법에 대한 또 하나의 대안으로, Standard CMMI Appraisal Method for Process Improvement(SCAMPI)를 사용할 수 있다. SCAMPI는 CMMI process area의 능력과 성숙도 수준을 측정할 수 있도록 표준화된 툴이다. CMMI V1.1 Product Suite에서 중요 추가 사항 중의 하나는 프로세스 개선을 위한 내부 평가뿐만 아니라 외부 평가를 위한 통일된 방법이다. SCAMPI는 외부 평가뿐만 아니라 내부 평가에도 모두 적용할 수 있는 평가 방법이다.

CMMI의 적용

1. 초기 Pilot testing 결과

CMMI의 초기 pilot test 목적은 모델, 교육, 평가 방법 등을 이용하여 경험을 얻고 그 경험을 CMMI products에 피드백하여 개선시키고자 하는데 있었다. 1999년에 CMMI V0.2 draft 모델이 최초로 개발되고 나서, CMMI Phase I Pilot Program이 실시되었다. 여기에 7개의 조직이 참여를 신청하여, 1999년 12월부터 2000년 6월까지 실시되었다. 그 후에 발간된 V1.0에 대해서도 2000년 10월에 Phase II Pilot Program이 8개의 조직을 대상으로 하여 실시되었다. 두번에 걸친 pilot program에서 평가 방법으로는 SCAMPI 모델이 사용되었으며, 18PAs를 가진 CMMI-SE/SW 모델을 이용한 성숙도 수준 3에 대한 평가를 시행하였다. 특히, Pilot II 에서는 PA당 평균 5시간의 인터뷰가 실시되었으며, 이 때 이루어진 결과는 SCAMPI V1.1에 반영되어 개선되었다. 이Pilot program에 참가한 조직은 Boeing사를 비롯하여 BAE SYSTEMS, Goddard Space Flight Center NASA, Lockheed Martin, Motorola Inc., Northrop Grumman Information Technilogy Sector, Raython Company, THALES, United Space Alliance, U.S. Army TACOM-ARDEC Software Enterprise 등이 참여하였다.
Pilot Program을 통해 얻어진 경험들은 여러 논문이나 학회(Software Engineering Process Group Conference, DoD Software Technology Conference, SEI Symposium 등)를 통하여 발표되었다. 여기에 5가지 key lessons learned를 요약하면 다음과 같다.

- 검증된 technology transition approaches이 CMMI에 적용된다. 계획을 포함한 검증된 transition approaches가 적용되며, 그러한 approaches는 성공 확률을 높이는 데 필요하다.

- 한 분야에 국한된 모델을 적용할 때보다 CMMI를 적용할 때 더 광범위한 지원이 필요하다. 조직 구조에 따라 다르지만, 일반적으로 higher management or executive level, additional peer management sponsors, greater subset of the overall enterprise를 필요로 한다.

- 한 분야에 국한된 모델보다는 CMMI 모델을 사용하는 것이 프로세스 산출물에 미치는 영향이 더 크다. 예를 들면, 여러 분야로의 확장으로 인해 존재하는 프로세스 자산에 대한 재사용의 기회가 확대된다.

- 통합된 기반구조(integrated infrastructure)가 CMMI 모델을 적용하는 데 결정적인 역할을 한다. Process group, management steering group, process asset library(PAL) 등을 포함하는 기반구조를 필요로 한다.

- CMMI-SE, CMMI-SW, CMM-SE/SW 모델에 동일한 PAs, goals, practices가 존재하기 때문에 모델 범위를 여러 분야로 확장하는 것이 용이하다. 예를 들면, CMMI-SW 모델로부터 CMMI-SE/SW 혹은 CMMI-SE/SW/IPPD 모델로의 확장이 용이하다는 것이다.

2. CMMI 적용시 고려 사항

CMMI를 적용하고자 결정하려는 조직이 고려해야 할 사항으로는 다음과 같은 세 가지를 들 수 있다.

- Stability: 안정성은 적용을 고려하는 조직에게는 매우 중요한 사항으로 상대적으로 변화가 적은 안정적인 모델을 고려하게 된다. CMMI는 V1.0에서 실시된 pilot test에 의하여 한번 정화하고 에러를 수정하는 과정을 거쳐서 V1.1이 공식적으로 발간되었기 때문에 안정성에 대한 신뢰할 만하다.

- Usability: 적용 모델을 고려할 때 사용 편리성 또한 매우 중요한 요소이다. CMMI는 여러 상이한 환경에서 사용하는 공통된 용어와 단계를 적용하려고 노력하였으며, 프로세스 개선 그룹과 평가팀의 입장에서 개선과 그에 대한 검증을 명확하게 할 수 있도록 많은 시간을 투자하였다.

- Extensibility: 확장성 또한 중요한 고려 사항이다. CMMI는 V1.0이후에 계속적인 확장을 통하여 V1.1을 발간하였다. Integrated Product and Process Development 환경을 위하여 몇가지 goals와 Pas를 추가하였고, Supplier Sourcing 환경을 위한 PAs도 추가하였다. 그리하여, 모델간의 공통성(Commonality)을 극대화하였으며, 새로운 분야와의 통합을 위한 모델 확장을 최소화였다.

3. CMMI 적용을 위한 접근 방법

조직에서 CMMI를 기반으로 변화를 추구하고자 할 때 적용할 수 있도록, SEI에서 제공하고 있는 일반적인 접근 방법은 SEI 홈페이지(www.sei.cmu.edu/ideal/ideal.html)에서 쉽게 찾을 수 있다. SEI에서 제시한 IDEAL 모델은 개선 조치를 시작하고, 계획하며, 실행하기 위한 접근 방법을 제공한다. IDEAL 모델에서 정의하는 5단계는 Initiating, Diagnosing, Establishing, Acting, Learning 등이다.

IDEAL과 유사하지만, CMMI를 실행하는 다른 접근 방법으로는 (그림 2)에서 보여주는 enterprise-level roadmap이 있다. 이 roadmap의 목적은 다음과 같다.

4. CMMI compatibility

가. 기존 모델과의 compatibility
CMMI는 <표 1>에서 보여주는 능력 수준과 프로세스 개선을 위한 다양한 프레임워크들과 compatibility를 갖는다.

나. 표준과의 compatibility
표준 혹은 지침 문서들 간의 상호 비교는 본질적으로 사과와 오렌지를 비교하는 것과 같다. 각 표준 혹은 지침 문서는 특정 목적으로 특정 계층에 정보를 제공하기 위하여 작성되었으므로 각기 다른 형태와 내용으로 구성되어 있다. 그러나, 많은 조직들은 조직적인, 사업적인 혹은 공학적인 관리 등 다양한 측면에서 여러 표준 혹은 지침문서들을 고려해야 할 상황이기 때문에, 다양한 표준 혹은 지침문서들 간의 유사성과 상이점 등을 비교한 정보는 매우 유용하다.
<표 2>의 목적은 일반적으로 이루어지는 표준들 간의 비교와는 약간 다르다. 여기의 비교 분석에는 일부 표준에 대한 공식적이고 조직적인 상세한 비교가 포함되어 있다. 이 비교 분석은 일반적으로 조직의 방침, 프로세스 및 절차를 수립하고 개선시키는 책임을 맡고 있는 프로세스 엔지니어들에게 유용할 것이다. 그러나, 이 분석은 관리자들에게 다음과 같은 두 가지의 종합적인 관점을 제공하기 위하여 실시되었다. (1) CMMI와 관련된 문서들에서 어떤 주제들(topics)이 포함되거나 포함되지 않았는지에 대한 이해, (2) CMMI topic과 관련하여 제공되는 지침 정보가 CMMI보다 많은지 혹은 적은지에 대한 이해ㆍ추가로, CMMI practice와 모순되는 부분은 강조되었다.

참고로, 이 분석에서 CMMI의 소스 모델(CMMs, EIA731 등)은 다른 자료들에서도 많이 찾을 수 있으므로 포함되지 않았다.
<표 2>에서 사용된 표기의 범례는 다음과 같다.

- Similar: CMMI와 동일한 깊이/강도로 언급됨.
- Out of scope: 언급되지 않음.
- More guidance: CMMI보다 더 많은 지침/설명이 포함됨.
- Less guidance: CMMI보다 더 적은 지침/설명이 포함됨.
- Minimal guidance: 최소한의 지침만이 약간 언급됨.
- Different focus: CMMI와는 매우 다른 관점에서 언급됨.

비교 대상이 된 표준은 다음과 같다.

- ISO 9001 : 2000 Quality Management Systems-Requirements: 품질경영 시스템의 실행을 지원하기 위한 조직 차원의 기반구조에 초점이 맞추어진 표준으로 일부 프로젝트 관리와 엔지니어링에 관련된 요구 사항을 포함하고 있다.

- ISO 10006 Quality Management: Giuideline to Quality in Project Management, 1997: ISO 9004-1을 보충하는 지침문서로 “normative” 표준은 아니다. 오히려, 프로젝트 관리 practices관점에서 ISO 9004-1에 대한 설명을 제공하는 문서이다. 주요 소스들 중의 하나는 Project Management Institute Guide to the Project Management(PMBOK), 1996 버전이다.

- IEEE 1220 Standard for Application and Management of the Systems Engineering Process: 시스템 공학 생명주기 표준으로, 이 표준에는 ISO9001:1994 품질경영 시스템이 존재한다는 것과 IEEE 1220은 ISO 12207의 요구 사항과 모순되지 않는다는 기본 가정이 포함되어 있다.

5. CMMI 적용을 위한 자원, 예산 및 일정[7]

여기에서는 CMMI를 적용하여 프로세스를 효과적으로 개선하기 위하여 필요한 인적 자원과 교육, 예산 및 일정에 대하여 설명한다.

가. 인적자원과 교육
(그림 3)은 프로세스 개선 인력을 위하여 구성 가능한 조직내 구조를 제시하였다.

프로세스 개선 계획을 수립하고 그에 따라 실행하는 것이 장기적인 관점에서 매우 중요하다. 전체 조직내에서 Management Steering Group은 다음과 같은 역할을 수행한다.

- 프로세스 개선 활동을 주관한다.
- 조직의 사업 목적과 연결된 프로세스 개선 목적에 대한 장기 비전을 제시한다.
- 프로세스 개선 활동을 수행하기 위해 필요한 자원(인력과 예산)을 지원한다.

Engineering Process Group은 조직의 사업 목적과 연계된 프로세스 개선 목적에 대하여 깊이있게 이해하고 프로세스 개선경험을 가진 “change agent”로 구성되며, 다음과 같은 역할을 수행한다.

- 여러 분야(품질보증, 형상 관리, 과제 관리 등)에서 프로세스 개선 mentor로써의 역할을 수행한다.
- 조직내 프로세스 개선 활동을 조직화하고, 그 조직은 개별적인 프로젝트 단위별로 구성될수 있다.
- 프로세스 개선 활동을 수행하기 위해 필요한 자원(인력과 예산)을 지원한다.
- 조직내 프로세스 개선 활동기간 동안 존재하며, 영구히 유지될 수 있다.

Process Action Teams(PATs)는 조직의 문화와 역사를 이해하고 조직의 변화를 유발하는 능력을 가진 “change agent”로 구성되며, 다음과 같은 역할을 수행한다.

- 지속적으로 개선해야 할 특정 process area에서의 실행계획을 수립하고 실행한다.
- 조직 혹은 프로젝트에서 필요한 기간 동안 존재한다.

이러한 인력에 대한 교육은 다음과 같은 여러 수준으로 구분되어 진행될 수 있다.

나. 예산
조직내에서 수행하는 다른 프로젝트와 같이, CMMI 적용을 프로젝트화하여 추진하는 것이 좋다. CMMI 적용 프로젝트 추진을 위한 예산은 각기 조직의 특성에 따라 다르겠지만, 다음과 같은 지침은 유용할 것이다.

- Engineering Process Group의 멤버는 full-time funding을 지원한다.
- Process Action Team(PAT)의 멤버는 근무시간의 50% funding을 지원한다. PAT는 제한된 기간 동안 작은 규모로 운영한다.
- PAT의 결과와 비용을 관리한다. 이슈가 있다면 필요한 활동들의 funding과 범위를 적절히 조정하여 준비한다.
- “change agent”와 PAT를 위한 적절한 CMMI 교육을 실시한다. 최소한 CMMI 초급 및 중급과정에 1주일의 예산을 준비한다.

다. 일정
조직의 특성에 따라 CMMI 적용을 위한 일정은 매우 다르게 추진할 수 있다. 각 조직의 시작 시점은 다르다 할지라도, 다음과 같은 지침은 유용할 것이다.

- CMM-SW를 적용할 때의 SEI 측정자료를 참고하면, 프로세스 개선 경험이나 기반구조가 거의 없는 조직은 성숙도 level 2에 이르는데 일반적으로 18개월 혹은 24개월이 소요된다. 여기에서 다시 성숙도 level 3까지의 소요기간은 추가적으로 12개월이 소요된다.

- 높은 프로세스 성숙도 혹은 능력 수준을 가진 조직은 약 1년의 기간이 소요된다. 일반적으로, 새로운 프로세스를 조직내에 내재화하는 데는 최소한 6개월이 소요된다.

결 론

지금까지 프로세스 능력 성숙도 모델인 CMMI에 대한 전반적인 개요와 CMMI를 적용하고자 할 때 참조할 수 있는 적용 방안에 대하여 살펴보았다. 현재 CMMI는 미국 카네기멜론대학의 소프트웨어공학연구소(SEI)에서 개발된 모델로 소프트웨어공학과 시스템공학을 통합한 프로세스 능력 성숙도 모델로써 새로운 발전의 기회를 맞이하고 있다. 또한, 국제표준화기구(ISO)에서 국제표준으로의 전환이 확정되어 표준 제정이 활발히 진행 중인 SPICE (ISO/IEC 15504)와 함께 프로세스 능력 성숙도 모델이라는 고유한 영역을 확보해 나갈 것으로 기대된다. 조직에서 제공하는 제품과 서비스의 품질을 향상시키기 위하여 프로세스 모델의 적용을 고민하고 있는 조직에게 CMMI는 국제표준인 SPICE(ISO/IEC 15504)와 함께 많은 도움을 줄 수 있을 것이다.

제공 : DB포탈사이트 DBguide.net

출처명: ITFIND

박영택
숭실대학교 컴퓨터학부 교수

1.개요
2. 시맨틱 웹 기술
3. 시맨틱 웹 피라미드
4. 시맨틱 웹 시장
5. 시맨틱 웹 시장 동향
6. 결론

1. 개요

1989년에 Tim Berners-Lee에 의해서 제안된 웹(Werld Wide Web: WWW)은 사람들 간의 정보 공유에 매우 큰 영향을 미쳤다. 많은 사람들은 자신이 생각한 내용이나 연구 결과를 HTML이라는 간단한 markup 언어로 표현하여 웹에 올려 놓을 수 있고, 웹에 올려진 정보는 사람들 간의 정보 공유에 매우 큰 기여를 하였다. 이에 따라 수많은 정보가 인터넷 상에 발표되고 유통되어서 사람들은 정보의 바다에서 자신이 원하는 정보를 유용하게 찾을 수 있고 이를 활용할 수 있게 되었다[1]-[2].
그러나 정보의 바다에 수많은 정보가 올려짐에 따라서 자신이 원하는 정보를 발견하는 작업이 점점 더 어려워지는 현상이 발생하게 되었다. 정보의 양이 적을 때는 웹으로부터 원하는 정보를 발견하는 데 어려움을 느끼지 못했지만, 점점 정보의 양이 많아짐에 따라서 정보를 발견하는 데 매우 많은 시간을 투자해야만 하는 현상이 생기게 되었다. 또한 웹에는 정보만이 존재하는 것이 아니라 점차적으로 서비스를 제공하는 응용 프로그램이 등장하게 되었는데, 이와 같은 응용 프로그램을 유효 적절하게 찾아서 활용하는 데도 많은 어려움에 봉착하게 되었다.
이러한 어려움을 극복하기 위해서 컴퓨터공학 분야에서는 소프트웨어 에이전트라는 방안을 제안하였다. 소프트웨어 에이전트는 사람이 하는 일을 대신하여 수행할 수 있는 지능형 소프트웨어를 총칭하여 부르는 이름이다. 사람을 대신한다는 의미는 일을 시킨 사람이 만족할 정도의 작업 결과를 내놓을 수 있다는 것을 뜻한다. 따라서, 소프트웨어 에이전트는 사람이 지시한 작업을 지시한 사람이 만족할 수 있는 수준의 결과를 제출할 수 있어야 한다. 그러나 사람이 지시한 일이라는 것이 일반적인 분야에서는 매우 높은 지능을 요구하기 때문에 지능형 에이전트를 구축한다는 것은 매우 어려운 일이다. 창의적인 작업이나 매우 복잡한 이론과 기술을 복합하는 분야에 에이전트를 활용하는 데는 아직까지 기술적인 어려움이 많이 있다. 그러나 비교적 단순 작업을 수행하는 분야에서는 에이전트가 성공적으로 사람의 일을 대신할 수 있다. 그러므로 웹은 에이전트가 사람에게 도움을 주기에 매우 좋은 분야이다. 사람이 웹에 있는 정보나 서비스를 검색하는 행위는 아직까지 단순한 작업이기 때문이다. 즉, 사람들은 자신이 원하는 정보의 주요 키워드를 주면 소프트웨어 에이전트는 웹에 있는 문서들에서 사람이 입력한 키워드가 있는 정보나 서비스를 찾아주면 되는 단순 작업만을 수행하면 되기 때문에 소프트웨어 에이전트가 매우 성공적으로 사람이 하는 일을 대신할 수 있었다. 이와 같은 대표적인 소프트웨어 에이전트가 우리가 일상 생활에서 활용하는 Google 같은 웹 검색 프로그램이다.
그러나 사람들은 이와 같은 단순 작업만을 수행하는 에이전트를 보다 지능화하기를 원하게 되었다. 그 이유는 단순한 에이전트만을 이용해서는 바쁜 일상 생활에서 자신이 만족할 수 있는 결과를 얻을 수 없었기 때문이다. 예를 들면, 키워드를 이용한 검색 프로그램을 이용하면 자신이 원하는 정보가 바로 나오는 것이 아니라 수천 또는 수만의 결과가 나오고 다시 사람이 이 중에서 자신이 원하는 정보를 찾는 수고를 해야 한다. 웹에 정보의 양이 적을 때에는 문제가 별로 심각하지 않았지만, 정보의 양이 많아지고 사람들이 보다 빠르게 정보를 요구하는 욕구가 높아짐에 따라서 기존의 웹은 많은 문제점을 노출하기 시작했다. 또한, 사람은 에이전트를 이용하여 웹에 있는 서비스를 자동으로 받고 싶지만, 기존의 에이전트는 단순 작업만을 할 수 밖에 없기 때문에 이와 같은 요구 사항을 만족시킬 수 없었다.
이와 같이 소프트웨어 에이전트가 제대로 동작을 못한 이유는 웹의 구조적인 문제에서 유래한다. 즉, 웹에 있는 모든 정보는 사람을 위한 정보이다. 사람은 웹에 있는 정보를 이해할 수 있으나, 소프트웨어 에이전트는 웹에 있는 정보를 이해할 수 없기 때문이다. 이와 같은 문제를 극복하기 위해서 웹을 주창하였던 Tim Berners-Lee는 1999년에 W3C를 중심으로 차세대 웹기술인 시맨틱 웹(Semantic Web)을 제안하게 된다[1]-[2],[8].

2. 시맨틱 웹 기술

가. 지능형 에이전트 기술

시맨틱 웹의 출현은 지능형 에이전트를 위한 새로운 공간을 제공하기 위한 것이라고 할 수 있다. 즉, 웹이 사람을 위한 사이버 공간을 제공하였다면, 시맨틱 웹은 지능형 에이전트를 위한 공간을 제공하여 보다 사람이 편리하게 에이전트로부터 정보를 찾거나 서비스를 받을 수 있게 하는 것이다. 웹에 있는 HTML문서는 사람이 보고 이해하는 데는 불편함이 없도록 설계되어 있으나, 소프트웨어 에이전트는 HTML문서를 이해할 방법이 없다. 예를 들면, 우리가 프랑스 영화를 볼 때 불어를 모르면 영화의 내용을 이해할 수 없는 것과 같이 소프트웨어 에이전트도 HTML문서를 보면 그 내용을 이해할 수 없다. 번역된 자막을 보면 우리가 프랑스 영화의 내용을 이해할 수 있는 것과 유사하게 소프트웨어 에이전트는 시맨틱 웹 환경에서 HTML문서의 메타데이터를 보면 HTML문서의 내용을 파악하게 된다. 그러나 불어 대본이 가지고 있는 의미와 자막에 번역된 의미의 차이는 매우 크다. 번역된 자막은 영화를 이해하는 데 필요한 최소한의 정보만을 가지고 있을 수 밖에 없다. 이와 같이 시맨틱 웹 공간에서는 지능형 에이전트가 웹에 있는 정보나 서비스를 한정된 범위에서 이해할 수 있는 구조를 만들어 줌으로써, 사람이 지능형 에이전트를 이용하여 보다 복잡한 작업을 시킬 수 있게 된다.
따라서, 소프트웨어 에이전트가 이해할 수 있는 단순한 언어를 이용하여 HTML 문서의 내용을 메타데이터의 형태로 표현하면 된다. 즉, HTML 문서가 있는 웹 공간은 사람을 위한 사이버 공간이고, HTML 문서의 메타데이터가 있는 웹 공간은 소프트웨어 에이전트를 위한 사이버 공간이라고 할 수 있다. 이때 메타데이터는 HTML문서의 내용을 표현하고 있어야 하는데, 사람이 생각한 모든 내용을 표현한다는 것이 불가능하므로 사람의 생각 중에서 소프트웨어 에이전트에게 가장 필요한 부분만을 개념화하여 표현하는 방식을 취하게 된다. 이와 같이 시맨틱 웹에서는 두개의 공간을 준비하여 지능형 에이전트가 활동을 할 수 있는 구조를 제공하게 된다.
시맨틱 웹 환경에서는 기존의 웹 공간과 이 웹에 있는 정보를 표현하는 메타 공간으로 구성된다. 이 메타 공간에 있는 정보는 웹 공간에 있는 HTML문서의 의미를 표현하고 있으며, 지능형 에이전트가 메타 공간에 있는 정보를 이해할 수 있도록 설계되어 있다. 메타 공간에 표현되는 언어는 한정된 vocabulary를 가지고 있고, 일정한 규칙을 가지도록 설계되었으므로 소프트웨어 에이전트는 메타 공간에 표현되는 언어를 이해할 수 있다. 따라서, 소프트웨어 에이전트는 사람이 지시한 작업을 수행하는데 웹에 있는 문서의 의미를 파악하면서 자동으로 문제를 해결할 수 있는 기반 구조를 가지게 되었다. 앞에서 들은 영화 예를 든다면, 영화의 자막이 없는 경우에 우리는 영화를 보면서 영화의 내용을 추측만하게 되지만 자막이 있는 경우는 영화의 내용을 알 수 있으므로 영화 스토리를 다른 사람에게 설명할 수 있게 된다. 기존의 웹에 있는 모든 소프트웨어 에이전트는 우리가 자막이 없는 프랑스 영화를 보는 것과 같이, 단순히 키워드 기반의 분석 작업에 의존하는 한계를 가지면서 사람이 지시한 작업을 수행하게 된다. 그러나 시맨틱 웹 환경에서의 지능형 에이전트는 웹에 있는 정보의 의미를 이해할 수 있는데, 이것은 우리가 영화의 자막을 보는 것과 유사하게 웹에 있는 HTML 문서의 메타데이터를 보면서 이해할 수 있게 된다.

나. 온톨로지 기술 개발

지능형 에이전트가 동작할 수 있도록 구조적인 공간을 만들어 주기 위해서는 사람이 만든 HTML문서의 내용을 메타데이터의 형식으로 표현하여야 한다. 이와 같은 메타데이터 공간을 지능형 에이전트가 활용하게 되므로 메타데이터를 표현하는 것은 매우 중요하다. 사람은 머리 속에 있는 생각과 개념을 이용하여 HTML문서를 표현하였으므로, 이와 같은 HTML 문서가 가지는 의미를 소프트웨어 에이전트에게 표현하기 위해서는 사람이 가지고 있었던 개념이나 생각을 표현하는 것이 필요하다. 이와 같은 시맨틱 개념을 이용하여 소프트웨어 에이전트를 위한 메타데이터를 표현하게 되는데, 사람이 생각한 시맨틱 개념을 소프트웨어 에이전트가 이해할 수 있도록 표현한 것을 온톨로지(Ontology)라고 한다[3].
온톨로지는 두가지 중요한 의미를 가지게 된다. 첫번째는, 메타데이터를 표현하기 위한 해당 분야의 개념이라고 할 수 있다. 예를 들면, 앞에서 예를 든 영화가 공상과학 영화라면 자막에는 과학 용어가 나오게 될 것이고 우리는 그 과학 용어에 대한 개념을 알고 있을 때 그 자막을 이해할 수 있다. 반대로 그 영화가 프랑스 역사물이라면 자막에 나오는 역사 사건에 대한 개념이 있을 때 그 영화의 내용을 이해할 수 있다. 이와 같이 자막과 같은 메타데이터가 있더라도, 그 자막에 있는 vocabulary에 대한 개념을 가지고 있을 때 그 내용을 알 수 있게 된다. 그러므로 온톨로지는 메타데이터에 있는 vocabulary에 대한 개념이라고 할 수 있다.
두번째는, 이와 같은 온톨로지는 공유(shared)된다는 점이다[3]. 즉, 온톨로지를 설계하는 것은 시맨틱 웹 프로그래머이고 이 프로그래머는 온톨로지를 설계할 때 일정한 규칙과 잘 정의된 방식에 따라서 설계하여 이 내용을 소프트웨어 에이전트에게 알려주게 된다. 이와 같은 과정을 거쳐서 온톨로지는 사람도 이해하고 소프트웨어 에이전트도 이해하는 특징을 가지게 된다. 여기서 소프트웨어 에이전트가 이해한다는 것은 에이전트가 온톨로지를 파싱할 수 있고, 그 구조를 이해한다는 것을 의미하는 것으로 지능을 가지고 이해한다는 것은 아니다. 따라서, 온톨로지 개발과정은 지능형 시스템의 지식베이스를 개발하는 과정과 매우 유사하다. 또한 온톨로지는 지능형 에이전트가 제공할 서비스에 따라서 다른 내용과 형식을 가지게 된다.

다. 메타데이터 표현 기술

시맨틱 웹이 성공하기 위해서는 메타데이타가 필수적이다. 사실 시맨틱 웹이 출현한 이유는 지능형 에이전트가 웹의 정보를 이해할 수 있는 공간을 구축하기 위함인데, 이와 같은 공간이 결국은 메타데이터이다. 즉, 웹에서는 HTML 문서와 같은 한 종류의 정보만 존재하지만, 시맨틱웹에서는 HTML문서가 가지고 있는 의미있는 정보를 지능형 에이전트가 이해할 수 있도록 메타데이터를 필요로 한다. 메타데이터는 웹상의 문서나 정보의 의미를 표현하는데, 예를 들면, 그 문서의 주요 개념, 저자, 저작 년월일 등이다. 어찌보면 매우 간단한 정보같지만 기존의 웹 상에서는 이와 같은 정보가 명시적으로 표현되지 않았기 때문에 소프트웨어가 처리하는데 매우 불편했고 따라서 소프트웨어의 지능이 떨어지게 되었다[1],[3].

3. 시맨틱 웹 피라미드

(그림 1)은 시맨틱 웹의 계층적 구조를 잘 나타내주는 대표적인 그림이다. (그림 1)을 보면 시맨틱 웹의 하부는 Unicode, URI, XML이라는 것을 쉽게 알 수 있다. 시맨틱 웹에서는 XML 구조를 사용하지만 단순히 markup 용으로 XML을 활용하고 있다. 시맨틱 웹에서는 모든 자료를 그래프의 구조로 보고 있다. 그래프의 한 조각은 subject, object과 이 둘을 연결하는 링크 정보로 표현된다. 이와 같은 그래프 구조를 표현하기 위해서 시맨틱 웹에서는 RDF(Resource Description Framework) 방식을 이용하고 있다. 앞의 구조에서 Ontology vocabulary, Logic, Proof는 시맨틱 웹의 중요한 구성요소이다. 이 부분이 가지는 의미는 앞에서도 설명하였듯이 소프트웨어 에이전트가 이해할 수 있는 온톨로지 vocabulary로 메타데이터를 표현하면, 이 내용을 소프트웨어 에이전트가 이해하고 인공지능의 로직 기반의 추론 과정을 이용하여 사람이 지시한 작업을 지능적으로 수행한다는 것을 의미한다. 이와 같이 로직 기반의 지능형 추론과정을 거치게 되면, 소프트웨어 에이전트는 자신이 수행한 작업을 설명할 수 있게 된다. 따라서, 에이전트가 수행한 작업의 내용을 Proof 하는 기능을 가지게 된다. (그림 1)은 시맨틱 웹이 지능형 소프트웨어 에이전트가 작업을 수행할 수 있는 인프라를 구축하고 있다는 점을 중시하고 있다고 볼 수 있다. 마지막으로, 소프트웨어 에이전트는 나쁜 의도를 가지고 있으면 안되고 서로 믿을 수 있도록 설계되어야 한다는 내용을 표현하고 있다.

시맨틱 웹은 HTML, XML을 기반으로 하고 있으며, 인공지능, 소프트웨어 공학, 프로세스 모델링 등의 학제간 연구를 통해서 발전하고 있다. (그림 2)에서 보여 주는 바와 같이 미국과 EU에서는 RDF, DAML(DARPA Agent Markup Language), OIL(Ontology Inference Layer)와 같은 온톨로지 모델링 언어를 개발하였다. 그 후에 미국과 EU는 공동으로 DAML+OIL를 제안하게 되었고 W3C는 2004년에 OWL(Web Ontology Language)을 제안하게 된다[1]-[3]. OWL은 현재 시맨틱 웹에서 온톨로지 표현 언어의 표준으로 채택되고 있다. <표 1>은 온토롤지 모델 언어의 종류와 특징을 보여주고 있다.

4. 시맨틱 웹 시장

가. 시맨틱 웹 시장

시맨틱 웹 시장은 현재 매우 초기 단계에 있다. 현재의 실정은 1980년대 말의 웹 시장과 유사한 상황이다. 온톨로지 표현 언어는 표준화가 된 상태이지만, 메타데이터를 자유롭게 저작할 수 있는 저작 도구가 보편화되어 있지 않아서 일반대중이 활용하는 데는 많은 어려움이 있다. 그러나 초기의 웹 시장이 그러하듯이 전문적인 분야에서는 매우 활발하게 시장을 형성하고 있다. 미국과 EU에서는 W3C[7], DARPA[6], DERI[5] 등의 연구소와 IBM, HP, Google 등의 회사에서 LEAD(Live Early Adoption and Development)와 같은 방식으로 컬러 애플리케이션(killer application)을 발굴하는 작업을 수행하고 있다. 현재 시맨틱 웹 시장은 온톨로지나 메타데이터를 적극 활용하는 분야나 활용할 수 밖에 없는 분야에서 시장을 형상하고 있다. 전자의 경우는 블로그 시장을 예로 들 수 있는데, 블로그 시장에 있는 모든 사용자들은 자신의 정보를 광고하는 데 열심인 그룹들이다. 이 그룹에서는 자신의 정보를 널리 알리기 위해서 온톨로지 기반의 메타데이터를 적극 활용하는 분위기이므로 시맨틱 웹의 컬러 애플리케이션이 생길 수 있는 가능성이 매우 크다. 이런 이유 때문에 MIT 인공지능 연구실과 IBM T.J. Watson연구소, 그리고 EU의 SWAD-E(Semantic Web Advanced Development-Europe) 등에서 연구가 진행되어 왔다. 두번째 시장은 엔터프라이즈 소프트웨어 시장이다. 이 시장은 지식 공유를 매우 중시하는 분야이므로 온톨로지를 이용한 메타데이터를 저작한다는 불편함을 극복하고서라도 지능형 소프트웨어를 생산하려는 의지가 매우 높은 시장이다. 따라서, 향후의 ERP, CRM, SCM시장 등도 점진적으로 온톨로지 기반의 지능형 소프트웨어로 발전할 것이라는 예측이 많이 나오고 있다.
이와 같은 시장이 충분히 성숙되면, 일반 사용자가 시맨틱 웹 시장을 창출할 것으로 예상하고 있다. Google과 같은 회사에서는 2010년경에 일반 사용자들이 시맨틱 웹을 활발히 활용할 것이라는 전망하에 수년전부터 시맨틱 웹에 대한 연구를 진행하고 있다.

나. 시맨틱 웹 서비스 시장

현재 웹 시장은 서비스를 포함하는 시장으로 확산되고 있다. 즉, 과거의 웹에는 문서나 정지영상과 같은 정적인 콘텐츠를 포함하고 있었지만, 근래에 들어 웹에서 서비스를 처리할 수 있는 응용 소프트웨어가 출현하고 있다. 현재, WSDL, UDDI, SOAP과 같은 방식을 이용하여 웹에 있는 서비스를 표현하고, 저장하고, 검색하는 웹 서비스 시장이 활발히 만들어지고 있다. 시맨틱 웹 서비스 분야에서는 이와 같은 웹 서비스에 온톨로지를 이용하여 서비스에 대한 메타데이터를 표현하므로써 지능형 에이전트가 사람을 대신하여 작업을 수행할 수 있는 시장을 개척하는 시도가 이루어지고 있다. 궁극적으로 미래 사회에서는 현재 사람이 하는 모든 웹상의 트랜잭션을 지능형 에이전트가 대신하게 될 것이므로 시맨틱 웹 서비스 기술은 매우 필수적일 것으로 예측을 하고 있다.
시맨틱 웹 서비스 분야는 DARPA에서 주도적으로 연구와 개발이 진행되고 있다. 현재는 웹에 있는 서비스를 표현하기 위한 온톨로지 표현 언어에 대한 연구가 활발히 진행되고 있다. 또한 OWL-S를 이용한 웹서비스 온톨로지 구축을 하고 있다. 한가지 문제점은 기존의 대형 회사들이 이미 WSDL(Web Service Description Language), BPEL4WS(Business Process Execution Language for Web Service)과 같은 표준안을 사용하고 있기 ??문에 기업과 연구소간의 공동 작업이 매우 어려운 실정이다. 또한, EU에서는 DERI(Digital Enterprise Research Institute)를 중심으로 시맨틱 웹 기술을 이용한 웹 서비스에 대한 연구가 활발히 진행되고 있다[5]. DERI에서는 WSMO conceptual 모델을 이용한 웹 서비스에 대한 연구를 진행 중에 있다. DARPA의 OWL-S나 DERI의 WSMO는 시맨틱 웹 서비스를 지향하는 점에서는 같은 방향이지만, OWL-S가 logic 중심이고 procedural 실행과정을 중시한 반면에 DERI의 WSMO는 보다 declarative한 방식을 취하고 있는 차이점이 있다.
시맨틱 웹 서비스 연구의 성공은 기업에서 사용할 수 있는 시맨틱 웹 서비스 온톨로지를 개발하는 것이 무엇보다 중요하다. 아무리 좋은 온톨로지라 하더라도 기업에서 현재 사용하고 있는 WSDL, BPEL과 연동할 수 없다면 매우 늦은 속도로 시맨틱 웹 서비스 기술과 시장이 형성될 것이다. 또한, 시맨틱 웹 서비스 온톨로지를 구축할 수 있는 인프라와 인력 양성이 중요한 문제점으로 대두되고 있다. 현재 OWL-S 온톨로지를 구축할 수 있는 저작 도구가 매우 빈약한 상태이고, OWL-S나 WSMO의 개념을 이해하여 온톨로지를 활용할 수 있는 전문 인력이 적다는 점도 문제점으로 대두되고 있다.

5. 시맨틱 웹 시장 동향

시맨틱 웹과 관련한 시장의 출현은 필수적인 것으로 간주되고 있다. 지금의 시맨틱 웹 시장은 1980년 말의 웹 시장과 매우 유사한 상황이다. 1980년대 말의 웹 시장이 형성되기 시작해서 지난 10여년간 매우 비약적으로 새로운 시장과 산업이 형성되었듯이 시맨틱 웹 시장도 향후 10년 동안 매우 빠른 속도로 확장될 것으로 예상하고 있다. Gartner 그룹의 분석에 의하면 온톨로지 기반의 기술이 향후 핵심 기술로 자리 잡을 것이며 2007년경에는 간단한 온톨로지가 응용 프로젝트의 75%를 차지할 것으로 예상하고 있다[9]. 2010년경에는 인공지능의 지식표현 기술[4]을 활용하는 강력한 온톨로지가 응용 프로젝트의 80% 이상을 차지할 것으로 예상하고 있다.
또한 Forrester의 연구 결과에 의하면 온톨로지를 이용하는 소프트웨어가 궁극적으로 성공할 것으로 예측하고 있다. 온톨로지 기반의 소프트웨어 에이전트를 활용하는 소프트웨어가 성공할 것이며 그렇지 못하는 응용 소프트웨어는 결과 쇠퇴할 것으로 예상하고 있고, 더 나아가서 점진적으로 자동화 할 수 있는 온톨로지 기술이 필요할 것으로 예상하고 있다[10]. TopQuadrant 사는 IT 분석가와 벤더들의 연구 결과를 바탕으로 2010년의 시맨틱 웹 시장을 (그림 3)과 같이 예상하고 있다. 이와 같은 분석은 향후에 활용될 Knowledge Management Infrastructure, 온톨로지 기반의 응용 소프트웨어, ERP/CRM 등과 같은 enterprise-class 응용 소프트웨어, 포털, 웹 서비스, 그리드 컴퓨팅, 유비쿼터스 컴퓨팅 등의 모든 소프트웨어를 대상으로 2010년의 시맨틱 웹 시장의 규모를 예측하고 있다.

TopQuadrant사의 분석을 보면, 시맨틱 웹을 위한 새로운 인프라를 구축하는 시장을 예상하고 있다. 현재 시맨틱 웹 시장을 활성화하기 위해서는 시맨틱 웹의 구축, 저장, 유통을 위한 제반 인프라가 필요한 실정이다. 이와 같은 현상은 1990년대 초반에 웹 시장이 시작할 때와 유사한 상황이라고 볼 수 있다. 근래에 들어 웹 시장에서는 많은 저작 도구와 관련된 유틸리티들의 출현으로 웹 산업의 활성화를 지원하고 있다. 시맨틱 웹 시장에서도 이와 같은 시도가 필요하다. 또한, 기존의 웹 소프트웨어를 시맨틱 웹 소프트웨어로 통합하기 위한 시장이 매우 활성화 될 것으로 예상한다. 이와 같은 시장은 시맨틱 웹 소프트웨어들의 통합 시장도 포함한다. 한가지 주목할 점은 시맨틱 웹 시장에서는 사람의 생각을 한정된 범위에서 이해하고 사람의 작업을 대신 수행할 수 있는 지능형 에이전트가 동작할 수 있는 인프라를 제안하고 있으므로, 이러한 기능을 활용할 수 있는 Discover & Access, Reasoning 시장이 활성화 된다는 점이다. 이와 같은 시장에서는 단순한 키워드 기반의 검색이 아니라 시맨틱 웹 상의 문서나 서비스의 의미를 파악한 지능형 에이전트가 자동으로 검색하고 계획할 수 있는 시장이 새롭게 형성되는 것을 의미한다. 또한, 통신(Communicate) 시장은 지능형 에이전트들 사이에 시맨틱 수준의 통신을 통하여 사용자가 요구한 작업에 대해서 전문가 수준의 결과를 얻기 위한 협업 시장을 의미한다.
IDC, Gartner, Meta Group, VSS, McKinset, TopQuadrant 사의 분석에 의하면 현재 2003년의 시맨틱 기술 시장이 20억 달러 규모에서 2010년에는 630억 달러 규모로 다른 소프트웨어, 하드웨어, 서비스 시장보다 현저하게 시장 규모가 확장될 것으로 예상하고 있다.

6. 결론

시맨틱 웹 분야는 새로 출현하는 시장이고 필연적으로 발전할 수 밖에 없는 분야로 간주되고 있다. 1980년 말에 웹 시장이 현재와 같이 큰 시장이 될 것이라고 예측한 사람들은 별로 많지 않았을 것이다. 2005년 현재 시맨틱 웹 시장에 대한 예측은 우리가 1980년 말에 웹 시장을 예측한 것과 같은 관점에서 접근할 필요가 있다고 본다. 그리고 시맨틱 웹은 지능형 에이전트가 동작하기 위한 인프라를 제공하고, 이를 기반으로 자동화되고 지능적인 소프트웨어가 동작하는 새로운 지능형 소프트웨어 시장을 가능하게 해준다. 이와 같은 시장은 매우 깊이 있는 원천 기술과 핵심 기술을 바탕으로 할 때, 국산 소프트웨어가 세계 시장을 선도할 수 있을 것이라고 예측할 수 있다. 단순한 프로그램 작업 만으로는 새롭게 도래하는 시맨틱 웹 시장을 선도할 수 없고, 보다 깊이 있는 원천 핵심 기술을 바탕으로 할 때 국산화율이 높은 시맨틱 웹 기반의 소프트웨어를 창출 할 수 있을 것이다.

<참 고 문 헌>

[1] Dieter Fensel, James Hendler, Henry Lieberman, and Wolfgang Wahlster, Spinning the Semantic Web, MIT Press, 2003.
[2] Grigoris Antoniou and Frank van Harmelen, A Semantic Web Primer, MIT Press, 2004.
[3] Dieter Fensel, Ontologies: A Silver Bullet for Knowledge Management and Electronic Commerce, 2nd edition, Springer, 2004.
[4] Ronald J. Brachman and Hector J. Levesque, Knowledge Representation and Reasoning, Morgan Kaufmann Publisher, 2004.
[5] DERI, http://www.deri.org
[6] DARPA, http://www.darpa.org
[7] W3C, http://www.w3c.org
[8] Tim Berners-Lee, James Hendler, Ora Lassila, “The Semantic Web,” Scientific American, May 2001.
[9] Gartner, Semantic Web Rechnologies Take Middleware to the Next Level, 2002.
[10] Forrester Research, How Things Will Communicate, 2001.

출처명: ITFIND