낮의 빛으로

THE RETE MATCHING ALGOROTHM

인공지능 개론 : Dan W. Patterson 저서, 김영렬.김우성.김정규.박용법.정목동 옮김, 지성출판사, 1995  (원서 : Introduction to Artificial Intelligence and Expert Systems, 1990), Page 258~262

생성 시스템 (production system) 들은 15장에서 기술된다. 그 시스템들은 전문가 시스템의 일반적인 구조이다. 전형적인 시스템은 생성 혹은 규칙의 형태로 영역 (domain) 전문가의 지식을 나타내는 구조를 포함한 지식 베이스와 현재 문제의 파라메터를 갖는 작업 메모리 (working memory) 와 어떤 규칙이 현재 문제에 적절한가를 결정하는 추론엔진 (inference engine) 을 포함한다.

그림 1 생성시스템의 성분과 기본 사이클

생성 시스템의 기본적인 인터페이스 사이클은 그림 1에서 표시한 비교(match), 선택(select) 그리고 수행(excute)이다. 이러한 연산은 다음과 같이 수행된다.

   비교 (Match)    사이클의 매치시간 동안 지식베이스내 규칙의 LHS(left hand side) 조건은 작업 메모리(working memory)를 계속 결합시키는 것을 만족하는 LHS 조건을 갖는 규칙이 무엇인지를 결정하기 위해 작업 메모리의 내용과 비교된다. 매치된 것으로 판명된 규칙들은 충돌집합(conflict set) 에 넣는다.

   선택 (Select)   충돌 집합 (conflict set) 에서 규칙중의 하나가 선택되어 실행된다. 이러한 선택 정책은 최신 사용법, 특정한 규칙, 그 외의 기준에 의해 결정된다.

  수행 (Execute)   충돌 집합에서 선택된 규칙은 그 기능 또는 규칙의 결말 부분 즉, 규칙의 RHS (Right Hand Side) 를 수행함으로써 작업 메모리 (working memory) 에서의 조항을 제거하거나 교체하는 것 또는 단순 정지 원인 및 입출력 연산, 덧셈과 같은 것들을 포함한다.

이상의 순환은 더 첨가될 규칙이 없거나 종결 조건에 도달될 때까지 되풀이된다. 전형적인 지식 베이스는 수백 또는 수천가지 이상의 규칙을 포함하는데 각 규칙은 몇가지(아마도 10여가지 이상의) 규칙들을 포함한다. 작업 메모리 역시 전형적으로 수백 가지 이상의 조항들을 포함한다. 결과적으로 작업메모리 (working memory) 에 대한 모든 규칙과 LHS 조건들을 소모적으로 매칭하는 데 수만번의 비교가 필요하다. 이러한 주장에 대한 설명은 서문에 잘 나타나 있는데 이러한 시스템은 계산 시간의 90% 정도가 매칭연산과 관련되어질 수 있다. 그러므로 각 사이클마다 매칭연산이 수 천번 수행되어지는 것을 제거할 수 있다. 이에 효과적인 매치 알고리즘을 개발하게 되었는데 이를 RETE라고 부른다. (Forgy, 1982)

RETE는 초기에 프로그래밍 언어의 OPS 계열의 일부분으로 개발되었다.(Brownston, et al 1985) 이러한 알고리즘에는 연속적인 사이클에서 비교가 반복되는 것을 피할 방법을 포함한 몇 가지 새로운 특성을 나타낸다.

RETE의 주요 시간 절약 특성은 다음과 같다.

대부분의 전문가 시스템에서 작업 메모리(working memory)의 내용은 사이클과 사이클 사이에서는 거의 변화가 없다. 데이타에는 임시 중복(temporal redundancy)이라고 알려진 지속성이 존재한다. 이것은 매 사이클마다 소모적 매칭을 불 필요하게 만든다. 대신, 매칭 정보를 저장함으로써 작업 메모리에의 변화를 사이클마다 비교하는 것만이 필요하게 된다.

게다가 RETE 에서는 작업 메모리의 대한 변화가 직접 충돌 집합으로 전송변환(mapping)되는 것을 막는다. (그림 2) 그 후 충돌 집합(conflict set)으로부터 한 규칙을 선택 실행할 때 그것은 집합에서 제거되고 남아있는 엔트리들은 다음 사이클을 위해서 저장된다. 즉, 작업 메모리에 대한 규칙들이 반복적으로 비교되는 것을 피하게 된다. 더 나아가 그들의 LHS에 나타나는 조건 조항(term)을 가지는 규칙을 색인화하여(indexing) 작업 메모리 교체에 매치되는 단지 그러한 규칙들 만 조사할 필요가 있다. 이것은 각 사이클에 요구되는 비교의 횟수를 상당히 감소 시킨다.

그림 2 작업 메모리에 대한 변화가 충돌집합으로 사상(mapping)

지식베이스의 대부분의 규칙들은 그것의 LHS 에서 발생하는 것과 같은 조건들을 가질 것이다. 이는 불 필요한 매칭이 발생할 수 있는 또 다른 방법이 되고 있다. 그러한 규칙들을 묶음으로서(grouping), 또한 동일 조건들을 공통항으로 연결하여 피할 수 있게 된다. 이는 모든 적용 가능한 규칙들에 대해 한번의 테스트를 실행함으로써 가능하게 될 것이다. 연결화(linking) 절차는 다음과 같다.

규칙이 처음으로 지식 베이스에 적재될 때 이것은 규칙 컴파일러에 의해 검사되고 처리된다. 컴파일러는 LHS조건을 체크하고 규칙 이름과 LHS 조건 조항사이의 결합을 형성한다. 또한 컴파일러는 LHS에서 공통 조건을 가지는 모든 규칙과 연결되는 네트워크 구조를 구축한다. 이 네트워크는 새로운 작업 메모리 조항에 일치되는 바인딩(binding)에 만족되는 규칙 조건을 찾아내서 실행시간 동안 검사하고 위치화(locate)시키는 데 사용된다. 그림 3은 공통 LHS 조항을 공유하는 규칙들이 어떻게 그룹화되고 (grouping) 공통조건 조항으로 색인화(indexing)될 수 있는 지를 설명해 주고 있다.

LISP를 사용하여 결합시키고 색인(indexing)화를 형성하는 한 방법은 특성 LISP를 사용하여 결합시키고 색인(indexing)화를 형성하는 한 방법은 특성리스트 (property list)로 가능하다. 예를 들면,

(putprop 'R6 'father 'cond-1)

(putprop 'R6 'father 'cond-2)

(putprop 'R12 'father 'cond-1)

그림 3 전형적인 규칙과 컴파일된 네트워크 일부

 규칙들과 LHS 조건 사이의 연결(link)을 만들어 주고, 다음과 같은 문은

(putprop 'father (cons R6 (get 'father 'cond-1) 'cond-1))

동일한 LHS 위치에 조항(term)을 포함하는 모든 규칙들에 구체화된 LHS 조항을 연결해 준다. 절(clause)의 첨가와 같이 작업 메모리의 교체가 일어날 때(father bill joe) LHS 조건으로서  father를 포함하는 모든 규칙은 쉽게 확인되고(identify) 검색될(retrieved) 수 있다.

RETE에서의 검색(retrieved)과 규칙 조건의 연속적인 검사는 토큰(token)을 만드는 것으로 시작되는데 이러한 토큰(token)은 규칙 컴파일러에 의해 구축된 네트워크를 통과하게 된다.

네트워크는 적절한 검사 경로를 제공하는데 이 검사는 동일한 바인딩(binding)을 이끌어 내고 LHS 규칙을 완전히 만족시킨다. 매치 비교기(matcher)는 새로운 매치나, 더 이상 작업 메모리 요소에 매치되지 않는 규칙을 찾아내는 네트워크를 돌아다닌다. 매치 비교기(matcher)로부터 출력되는 것은 쌍(pair)으로 된 요소로 구성된 자료구조이다. 즉, 규칙 이름과 (R6  ( father bob sam )  (father mike bob))과 같은 LHS에 매치된 작업 메모리 요소의 리스트(list)이다.

독자는 다음 장에 제시될 색인화(indexing) 방법과 위에서 기술한 색인화(indexing) 방법이 유사하다는 것을 알 수 있다. 그 외 다른 시간 절약 기술도 RETE에서 적용된다. 그러나 위에서 쓰인 방법이 가장 중요한 방법이라고 할 수 있다. 실제로 이것은 수백 또는 수만 가지에 이르는 조건을 완전히 매치하는 것을 줄이는 방법을 제공한다.

데이터베이스 관리시스템은 기본적으로 대용량의 데이터를 효율적으로 저장 하고 관리할 뿐만 아니라 여러 사용자가 동시에 접근할 수 있는 환경을 제공하 고 시스템의 고장에 대비하여 데이터베이스의 상태를 일관성 있게 유지하는 회 복 기능을 제공한다. 데이터베이스 관리시스템에 대한 사용자의 만족도는 데이 터의 저장기술과 관련된 시스템의 성능에 크게 좌우된다. 시스템의 성능은 데 이터베이스 내의 데이터를 표현하기 위한 데이터 구조의 효율성과 데이터에 대 한 연산을 얼마나 효율적으로 수행할 수 있는 지 여부에 달려있다. 자료저장 기술은 데이터베이스 시스템의 하부에서 데이터베이스 관리시스템의 성능을 좌 우하는 기술이다.
본 절에서는 먼저 기존의 Oracle, DB2, Informix 등의 데이터베이스 관리 시스 템에서 자료저장에서 사용되는 핵심 기술인 인덱스, 동시성제어, 회복기법에 대하여 설명하고, 최근에 자료저장 기술과 관련하여 비정형 대용량 데이터의 저장 기법과 백업 관련 기술, 그리고 저장시스템의 하부 인프라로 등장한 네트 워크 자료저장 시스템의 기술과 그에 관련 된 최신기술인 NAS, SAN, iSCSI, DAFS 등에 대하여 다룬다.

1. 데이터 저장 핵심 기술

가. 인덱스

인덱스는 인덱스를 구성하는 키의 순서가 유지되는지의 여부에 따라 크게 두 종류로 나눌 수 있는데, 키가 일정한 순서로 유지되는 트리 계열과 키의 순서 와 관계없이 무작위로 유지되는 해쉬 계열로 구분할 수 있다. 트리 계열 인덱 스는 일정한 범위가 주어지는 연산을 처리할 때 유용하게 사용될 수 있으며, 해쉬 계열 인덱스는 특정한 키에 의한 빠른 데이터 접근을 제공한다. 트리 계 열 인덱스로는 B+ 트리, T 트리 등이 있으며, 해쉬 계열 인덱스로는 체인 버킷 해슁(CBH, Chained Bucket Hashing), 확장 해슁(EH, Extensible Hashing), 선 형 해슁(LH, Linear Hashing), 수정된 선형 해슁(modified Linear Hashing), 다중 디렉토리 해슁(Multi-directory Hashing) 및 확장된 체인 버킷 해슁 (ECBH, Extensible Chained Bucket Hashing) 등이 있다. 최근에는 지리정보시 스템과 멀티미디어 데이터베이스 등에서 비정형 데이터의 검색을 위해 R-트리 계열의 인덱스 기법이 사용된다.

(1)디스크 기반의 데이터베이스 시스템을 위한 인덱스 기법
기존의 Oracle, DB2, Informix, Sybase 등의 디스크를 기반으로 하는 상용 데이터베이스 관리시스템에서 기본적으로 사용되는 인덱스 기법은 B-트리, B+ 트리, B* 트리 계열의 인덱스와 확장 해슁과 같은 해쉬 계열의 인덱스 가 대표적이다.
B 트리의 확장 및 변형된 형태로는 B+ 트리, B* 트리 등이 있으며, 특히 B+ 트리는 디스크를 기반으로 하는 데이터베이스의 인덱스를 생성할 때 가 장 많이 사용되는 기법이다. B+ 트리는 B 트리 형태인 인덱스 부분과 실제 데이터들이 유지되는 말단 부분으로 구성되는데, 인덱스인 내부 노드의 데 이터는 단지 빠르게 단말 노드를 찾아가는 길잡이 정도의 역할만 수행한 다. 모든 데이터를 단말 노드에 유지하고 단말 노드끼리 연결 리스트를 구 성함으로써 범위가 주어진 연산을 수행할 때 데이터에 대한 빠른 순차적 접근을 제공한다.
확장해싱(EH) 기법은 데이터의 양이 변화함에 따라 해쉬 테이블의 크기를 확장할 수 있게 함으로써 동적인 환경에 적합하도록 고안된 해슁 기법으로 빠른 데이터의 검색을 위해 많이 사용된다.

(2)주기억장치 상주 기반의 데이터베이스 시스템을 위한 인덱스 기법
Altibase나 Timesten과 같이 주기억장치 상주 기반의 상용 데이터베이스 시 스템에서는 트리 계열의 인덱스로 B-트리 계열의 인덱스와 함께 T 트리를 사용 하고 있으며, 해싱 기능으로는 확장 해슁과 체인 버킷을 결합해서 만든 확장된 체인 버킷 해슁을 지원하고 있다.
T 트리는 AVL 트리와 B 트리의 장점을 이용하여 주기억장치 상주 데이터베이 스를 접근하는 데 적합하도록 고안된 대표적인 트리 계열의 인덱스기법으로 한 노드에 많은 수의 데이터를 갖는 이진 탐색 트리로 구성되어 빠른 데이터 접근 을 제공하며 메모리의 사용상에도 장점을 갖는다. T 트리의 노드에 포함되는 데이터는 실제 키 값이 아닌 키를 포함하는 레코드의 메모리 주소를 나타낸다. 키를 포함하는 레코드의 메모리 주소를 데이터로 사용함으로써 키 값을 구하 는 연산으로 인한 부하가 전체 인덱스의 처리 속도에 거의 영향을 미치지 않는 상태에서 고정 길이 키에 대해서 뿐만 아니라 가변 길이 키를 처리할 때 발생 하는 메모리 사용의 낭비 문제도 해결할 수 있다.
확장된 체인 버킷 해슁(ECBH)은 Kairos에 구현된 주기억장치 상주용 인덱스 로서 확장 해슁과 체인 버킷을 결합해서 만든 해쉬 인덱스이다. ECBH 인덱스는 EH 테이블, CBH 테이블, RID 풀(pool)의 3 부분으로 구성되며, EH에서의 단말 페이지를 CBH의 해쉬 테이블과 RID 리스트로 대치한 형태를 갖는다.

(3) 멀티미디어 데이터베이스 시스템을 위한 인덱스 기법
멀티미디어 데이터는 특별한 형식이 없는 비정형의 구조를 갖는다. 즉 전통 적인 관계형 데이터베이스에서 다루는 레코드 형태와 같은 일정한 구조를 갖지 않고 긴 문장이나 연속된 비트 스트림 형태를 갖는다. 이러한 비정형 데이터를 효율적으로 저장하고 이에 대한 내용 기반 검색을 지원할 수 있는 저장 및 검 색 기법이 필요하다.
공간 데이터 액세스를 위한 인덱스 구조로서 R 트리, R* 트리, MLGF(Multi-Level Grid File) 등의 구조가 사용되고 있다. R-tree는 B-tree로 부터 유도된 계층적 자료구조로 트리의 각 노드는 자신의 자식 노드를 포함하 는 가장 작은 d-차원 사각형으로 구성된다. 단말 노드는 데이터베이스에 있는 자식을 포함하는 대신 실제 기하학적 객체에 대한 포인터를 포함한다. 객체들 은 그들이 포함된 최소의 정렬된 사각형에 의해 표현된다. 가끔 노드는 디스크 페이지와 관련시켜 트리를 정의하는 파라미터가 공간 질의 동안 적은 수의 노 드가 방문되도록 선택된다. 서로 다른 노드에 해당하는 사각형들은 중복될 수 있다.
R-tree는 B-tree와 유사하게 높이가 균형화 된 트리이다. 인덱스는 완전히 동적이기 때문에 주기적인 재구성은 필요 없으며, R-트리의 단말 노드는 인덱 스 레코드 개체들을 포함한다. R 트리는 k 차원의 공간 객체를 자르거나 변환 하지 않고 겹치는 k 차원의 사각형 영역 안에 객체가 완전히 포함된다. R* 트 리는 R 트리의 색인 구조와 같으며 중간 노드의 영역 사각형들이 겹치는 것을 허용한다. R 트리가 색인 구조를 최적화하기 위하여 한가지 기준만을 적용하여 영역 사각형의 면적을 최소화하는 것에 비해 R* 트리는 네 가지의 최적화 기준 을 적용한다.
R* 트리의 삽입 알고리즘은 R 트리의 삽입 알고리즘이 영역의 면적만을 고려 하는 데에 비하여 영역의 면적, 둘레, 겹치는 영역의 크기를 모두 고려하여 공 간 객체를 삽입할 최적의 단말 노드를 선택한다.

나. 동시성 제어 기법

(1) 기존의 동시성 제어 기법
여러 트랜잭션이 동시에 수행되는 경우 데이터베이스의 일관성을 해치는 경우가 생길 수 있다. 이를 방지하기 위해서는 수행의 동시성을 제어해야 한다. 수행의 동시 성을 제어하기 위하여 잠금 기법을 사용한다.
Oracle, DB2, Informix 등의 대부분의 상용 데이터베이스 시스템에서 사용하는 동 시성 제어 기법은 데이터의 로크(lock)를 이용하는 두 단계 잠금(2 phase locking) 기법을 기반으로 하고 있다. 2단계 로킹 규약은 직렬 가능성을 보장할 수 있는 규약 으로 가장 많이 알려진 것으로 모든 트랜잭션들이 잠금과 잠금 해제 연산을 트랜잭 션은 잠금만 수행할 수 있고 잠금 해제는 수행할 수 없는 확장단계와 트랜잭션이 잠 금 해제만 수행할 수 있고 잠금은 수행할 수 없는 축소단계로 구분된다. 그러나, 2단 계 잠금 규약은 직렬 가능성을 보장하지만 반면에 교착 상태 문제를 내포하고 있어 이에 대한 해결 방법이 필요하다.
2단계 잠금 규약을 기반으로 Oracle과 같은 상용 제품에서는 여러 사용자들의 잠 금의 기다림 시간을 최소화하면서 동시에 소요되는 로크의 수를 최소화하기 위하여 고안된 다단위 잠금(Multi-granularity locking) 기법이 사용된다. 기존의 데이터베이 스 시스템에서 다단위 잠금 기법을 위해 선택되는 단위들은 필드, 레코드, 블록, 데 이터베이스 등의 일반적이다. 단위를 너무 좁게 설정하면 작업의 동시성은 향상되나 잠금 처리에 소요되는 비용이 많으며, 단위를 너무 넓게 설정하면 잠금 처리에 소요 되는 비용은 적게 되나 작업의 동시성이 떨어지게 되므로 응용분야의 특성에 맞는 단위를 설정하는 것이 필요하다.

(2) 분산 잠금 관리
인터넷 웹서버와 같이 다수의 사용자가 이용하는 데이터베이스 시스템에서는 고성 능의 시스템이 요구된다. 이러한 고성능의 요구를 만족하기 위해서 여러 대의 시스 템이 데이터베이스 서비스를 제공하는 병렬 서버와 클러스터 서버가 등장하게 되었 고 이러한 병렬서버와 클러스터 서버에서는 분산 서버간의 잠금의 관리를 위해서 분 산 잠금 관리자(Distributed Lock Manager, DLM)를 이용한다. Oracle의 병렬서버에 서는 DLM을 이용하여 병렬 서버가 모든 플랫폼에 걸쳐 다양한 기능을 제공할 수 있 게 되어 있으며, 서버의 성능 향상을 위해 여러 특징이 추가되었다. DLM은 데이터 잠금 정보가 노드를 통해 분산되는 것을 막기 위해 잠금 정보를 캐시에 저장하고, 충돌 블록에 대한 액세스를 통제할 수 있는 알고리즘이 제공되어 시스템 부하의 균 형을 이룰 수 있다.
분산 잠금 관리자의 중요 기능으로는 병렬 서버의 한 개 노드에 장애가 발생했을 때, 장애가 발생한 노드에서 수행되던 사용자 접속이 정상인 다른 노드의 세션으로 옮겨지며 접속이 자동으로 재확립되는 장애 복구(fail-over)기능이 있으며, 애플리케 이션 장애 복구는 시스템의 가용성을 높일 뿐 아니라 수동적인 부하 조절이나 강제 적인 시스템의 정지에도 효과적으로 사용될 수 있다.

다. 회복 기법

기존의 상용 데이터베이스 시스템에서 대부분이 로그 기반의 회복기법을 사용하고 있으며, 트랜잭션의 수행시간의 지연을 최소화하기 위해 로그를 위한 디스크 입출력 횟수의 최소화와 고장이 발생한 경우 신속한 시스템 회복을 목표로 하고 있다. 이를 위해 데이터베이스 시스템에서는 검사점(Checkpoint) 기법을 이용하여 로그의 양을 줄임으로서 회복의 시간을 빠르게 하고 있다. 대용량 멀티미디어 데이터베이스 시스 템 등에서는 자료의 효율적인 회복을 위하여 기본정보의 변화만을 수행기록으로 남 기고, 자료의 내용은 그림자 페이징 기법(Shadow-paging) 기법을 이용하여 이전 자 료의 내용을 디스크 내에 남아있게 한 후에 회복 시 그를 이용하고, 회복의 필요가 없을 경우 검사점이 수행되는 시기에 그를 삭제하는 방식 등의 별도의 처리과정이 행해지게 된다.
그림자 페이징 기법은 기본적으로 로그를 이용하지 않는다. 데이터베이스는 페이 지라는 일정한 크기의 블록으로 나뉘어 디스크에 저장된다. 페이지라는 용어는 운영 체제의 메모리 관리 기법에서 사용된 용어이다. 그림자 페이징 기법은 트랜잭션이 실행되는 동안 현재 페이지 테이블과 그림자 페이지 테이블의 두 페이지 테이블을 이용한다. 트랜잭션이 시작될 때에는 이 두 페이지 테이블은 동일하다. 트랜잭션이 실행되는 동안 현재 페이지 테이블만 사용하고 그림자 페이지 테이블은 사용하지 않 는다. 트랜잭션이 쓰기 연산을 수행할 때 현재 페이지 테이블만 변경한다. 판독과 기 록 연산을 위해 디스크 상에 존재하는 데이터베이스 페이지 블록을 찾을 때에도 현 재 페이지 테이블만 사용한다. 따라서, 그림자 페이지는 전혀 변함없이 트랜잭션 실 행 이전의 상태를 유지한다.

2. 최신 데이터 저장기술 및 현황

가. 비정형 대용량 데이터의 저장

멀티미디어 데이터는 기존의 문자와 수치 데이터와는 비교가 안 될 정도로 큰 용량 의 기억장소를 요구한다. 따라서 멀티미디어 데이터베이스는 데이터를 저장할 때 압 축 및 복원 기법을 필수적으로 사용해야 하며, CD-ROM과 같은 대용량의 저장 장치 와 다양한 저장 장치의 관리가 필요하다. 데이터의 압축 및 복원 기법으로서 널리 사 용되고 있는 기법은 이미지 데이터를 압축하기 위한 JPEG기법과 비디오 데이터를 압축하기 위한 MPEG기법으로, 국제적으로 널리 사용되고 있으며 많은 연구가 진행 중에 있다.
데이터베이스 내에 멀티미디어 데이터를 저장하고 관리하는 방법으로 우선 레코드 형태의 정형화된 데이터는 관계형 데이터베이스에 저장하고 이미지, 그래픽스 등 비 정형 데이터는 파일에 저장하는 방법과 이미지, 오디오, 텍스트 등 크기가 크고 가변 적인 데이터를 긴 자료 항목으로 저장할 수 있는 저장 기능을 제공하는 방법이 있다. 이러한 시스템들은 기존의 관계형 데이터 모델로 멀티미디어 응용을 지원하기 어려 운 점들을 해소하기 위하여 BLOB(Binary Large OBject)과 같은 기능을 가진 확장된 모델을 제공한다.
현재 관계형 DBMS 회사들이 자신의 제품에 멀티미디어 기능을 갖도록 확장한 제 품들을 여러 개 발표하였는데 그 예로는 Informix-OnLine, Oracle 9, Sybase 등이 있다. 국내에서는 관계형 DBMS 자체에 대한 상품화가 제대로 안된 실정에 있지만, 삼성전자에서 관계형 DBMS인 CODA를 개발하면서 BLOB을 이용하여 멀티미디어 데이터베이스를 지원하는 시제품을 1994년에 개발한 바 있으며, ETRI에서는 "바다" DBMS에도 BLOB 기능을 추가하였다.
특히, Oracle에서는 이미지, 사운드, 비디오텍스트와 같은 비정형 데이터를 저장하 기 위한 기반 타입으로 CLOB(Character LOB), BLOB (Binary LOB), 그리고 BFILES(데이터베이스 외부에 저장되는 LOB) 등이 있다. BLOB, CLOB 타입의 데이 터는 데이터베이스 내의 지정된 테이블 공간에 저장된다. 반면 BFILE 데이터는 데이 터베이스 밖의 운영체제가 관리하는 파일 시스템 내의 특정 디렉토리에 저장할 수 있다.
또한, Oracle9i R2에서는 Oracle Internet File System을 제공하여 인터넷을 위주로 한 기업의 데이터를 하나의 저장소에 병합할 수 있도록 해준다. Oracle Internet File System에서는 저장소에 저장된 문서를 사용자들이 Windows, Web, FTP 등의 인터 페이스를 이용하여 접근할 수 있도록 파일과 폴더의 형태로 제공함으로써, 데이터베 이스 관리시스템의 파일 관리자의 기능을 운영체제의 파일 시스템의 기능을 포함하 도록 확장하였다.

나. 백업 기술

최근 들어 백업은 컴퓨터산업에서 정보의 중요성이 인식되면서 가장 각광을 받는 분야로 부각되고 있으며, 그 시장 규모도 크게 확장이 되었다. 기업에 전산과 관련된 비용 중에서 30～50%가 기업에서 발생하는 정보의 백업에 소요되는 비용으로 조사 되고 있으며, 특히, 미국의 9.11 테러의 발생 이후 백업기술은 재해복구 기술과 결합 하여 데이터베이스뿐만 아니라 볼륨, 파일, 그리고 응용프로그램 등에 발생되는 엄 청난 양의 데이터를 효과적으로 백업하고 복구하는 기능을 수행해야 한다.

(1) 백업의 유형
백업의 유형으로는 모든 데이터베이스나 파일시스템의 내용을 백업 받아 두는 방 법으로 내용의 변화의 유무에 관계없이 복사를 하는 완전(full) 백업, 선택된 파일이 나 폴더들의 변경된 부분만을 백업하여 복원을 할 때에 증분 백업을 한 모든 백업 데 이터파일 또는 모든 백업 테이프를 이용하여 복원하는 증분(incremental) 백업, 변경 된 파일의 전부를 저장하여 복원을 할 때에 맨 마지막날 차등 백업을 한 백업 데이터 파일 또는 백업 테이프만 있으면 복원을 할 수 있는 차등(differential) 백업, 그리고 백업 간격별로 단계를 정한 후 단계별로 다단계로 점진적인 백업을 수행하는 다중레 벨 증분(Multilevel incremental) 백업이 있다.
Oracle에서는 베리타스 소프트웨어사의 Net- Bakcup과 결합하여 제공하는 백업 기능 중의 하나로 이전의 특정 시점을 기준으로 현재 백업하고자 하는 시점까지의 작업 내용 중에서 단지 변화된 블록의 내용만을 백업하므로 백업되는 데이터의 크기 를 상당히 줄일 수 있다. 이로 인해 데이터 파일의 백업 시간을 대폭 줄일 수 있으며, 백업 간격별로 단계를 정한 후 단계별로 다단계로 점진적인 백업을 수행할 수 있다. 복구해야 할 경우에는 데이터베이스의 상태를 분석해 수행에 필요한 연산을 결정 한다. 이러한 조작을 자동으로 수행하므로 관리자가 작업에 들이는 수고를 덜어주고 복구 작업 시의 에러 발생 가능성을 최소한으로 줄여준다.

(2) 백업의 기법
(가) 서버리스 백업
SAN 백업 구성 시에 활용 가능한 방법으로 만일 백업서버가 동시에 웹 서버나 데 이터베이스 서버로 활용되고 있다고 가정해 보자. 백업을 수행하면 백업서버의 CPU 에 부하가 걸리게 된다. CPU 사용률이 적게는 30%에서 많게는 100%까지도 올라간 다. 이렇게 되면 웹 서버나 데이터베이스 서버로의 성능을 내기란 여간 힘든 일이 아 닐 수 없다. 그렇지만 서버리스 백업을 사용하는 경우에는 백업서버에서는 백업을 위한 명령만을 백업장치에 전달하고, 백업장치는 디스크 스토리지와 직접 백업 데이 터를 전송 받게 되고, 백업서버는 지정한 시간에 한번씩 백업 이상 유무를 확인하는 작업만을 수행하게 된다.
CPU의 사용률은 10% 전후가 되고, 서버의 또 다른 기능을 원활하게 사용하게 될 수 있게 된다. 물론, 서버리스 백업은 ISV에서 제공하는 백업 어플리케이션의 옵션으 로 구성되는 것이다.
(나) snapshot
온라인 백업은 일상의 업무 수행에 가장 영향을 주지 않기 때문에 24시간 가용성을 필요로 하는 데이터베이스에 알맞다. 그러나, DBMS는 백업 도중에 트랜잭션을 로깅 해야 하므로, 백업과 백업 후에 쌓인 트랜잭션을 실제 데이터에 적용해야 하기 때문 에 성능이 약간 저하된다. 볼륨 백업 시간을 최소로 하기 위해서, 고객들은 현재 한 볼륨을 snapshot으로 상용하여 그 snapshot 볼륨으로 백업을 받는 기능을 사용하 고 있다. 이때, 실제 볼륨은 신속하게 실제 운영에서 사용할 수 있게 된다.
(다) LAN-Free 백업
데이터베이스 시스템의 하부 인프라가 SAN과 같은 네트워크 기반의 시스템으로 구성이 된 경우는 파이버 채널로 구성된 별도의 SAN에 각 서버의 스토리지가 직접 연결되어 있기 때문에 백업을 위한 데이터의 이동을 파이버 채널을 이용하고 스토리 지간의 데이터 트래픽은 기존의 LAN을 사용하지 않는다. 따라서 시스템의 성능은 급격히 향상되는데, 이것은 데이터와 통신 트래픽이 더 이상 제한된 표준 LAN의 대 역폭에 대해 경쟁하지 않기 때문이다. SAN 환경에서는 스토리지의 리소스는 통합 관리되며, 다수의 서버에 의해 공유되어 사용될 수 있다. 또한 파이버 채널 스위치의 추가를 통해 SAN 솔루션은 쉽게 확장 가능하다.
SAN 환경에서 데이터가 지능적인 백업 애플리케이션을 통해 관리되도록 다양한 소프트웨어를 개발하고 있다. 기존의 백업 방식에 비해 LAN-Free 방식은 광채널 구 성요소를 설치하는데 많은 초기 투자비용이 들어가는 단점을 가지고 있다. 그러나 스토리지의 통합 및 중앙 관리는 전체소요비용을 크게 줄일 수 있어 궁극적으로는 기업에게 더 많은 이점을 안겨준다.

3. 저장 인프라의 발전 및 기술

인터넷의 폭발적인 성장, 온라인 상에서의 정보유지 필요성, 의사결정 지원 정보의 수집/추적에 대한 필요성, 서버 통합, 비즈니스 중심 어플리케이션으로 의 PC 서버 움직임, 그리고 어플리케이션의 복잡성 증가 등 다양한 요인들로 인해 현재 기업 규모의 시스템에서는 대용량 데이터베이스 시스템의 구축, 데 이터웨어하우스(Data Warehouse)의 구축, 그리고 ERP(Enterprise Resource Planning) 시스템 등의 도입으로 대용량 스토리지 시스템에 대한 요구가 계속 높아지고 있다. 이러한 높은 신뢰성과 성능, 장애 복구성(fault tolerance), 그리고 통합된 관리와 고속 백업이라는 요구에 대한 솔루션으로 등장한 인프라 가 바로 SAN(Storage Area Network)과 NAS(Network Attached Storage)로 대변 되는 네트워크 자료 저장 시스템이다. SAN과 NAS는 분산 네트워킹에서 주류가 되고 있으며 조만간 데이터베이스 시스템의 위한 스토리지 부착 및 공유에 대 한 일반적인 방법이 될 것으로 전망되고 있다.

가. NAS

DAS는 서버와 외장형 스토리지 사이를 전용의 케이블로 직접 연결하는 것으 로 기존의 서버와 스토리지를 직접 연결하는 전통적인 방식이다. 만약 서버가 UNIX나 Linux서버와 같은 오픈 시스템이면 SCSI 케이블을 이용하여 연결하는 방법이다. 이러한 DAS는 저장된 데이터에 대한 서비스를 스토리지에 접속된 서 버가 처리해야 함으로 서버에 큰 부하가 발생한다.
NAS는 네트워크 접속용 스토리지로서 Ethernet과 같은 LAN 인터페이스를 통 해 네트워크에 직접 연결되는 새로운 개념의 데이터 저장장치로 네트워크 상에 서 서로 다른 이기종 플랫폼간의 효율적인 데이터 통합 사용과 기존의 서버-중 심형 스토리지와 같이 일반용 서버의 상위구조나 그 복잡함 없이 오직 데이터- 펌프(Pump Data : 스토리지 시스템 자체와 클라이언트간에 신속하게 바로 데이 터 전송이 이루어지는 것) 라는 데이터 처리의 목적만을 위해 최적화 된 데이 터-중심형의 데이터 전용 스토리지 시스템이다.
기존의 서버-중심형 방식과는 달리 NAS는 데이터 저장장치가 서버에 종속되 지 않고 독립적으로 네트워크에 직접 연결된다. 그 결과 사용자는 파일서버를 거치지 않고 필요한 데이터를 직접 NAS 저장장치를 통해 훨씬 빠른 속도로 접 근할 수 있다. 즉, 클라이언트에서 요구된 데이터의 저장/전송에 따른 네트워 크 로드(Load)는 서버로부터 분리되어 NAS에서 분담함으로써 상대적으로 네트 워크 상에서 서버의 성능은 향상되는 효과를 가져온다. NAS의 장점은 파일의 공유 기능이다. NAS의 파일서버가 NFS나 CIFS 프로토콜을 통해 여러 어플리케 이션 서버들 사이에 파일을 공유 할 수 있게 해준다. 현재 존재하는 파일 공유 솔루션으로는 NAS가 가장 안정적이라는 장점을 지닌다. 그러나, NAS는 데이터 의 전송에 LAN을 사용하므로 LAN이 불안정하거나 과부하가 발생한 경우에 성능 이 떨어진다는 단점을 지니고 있다.

나. SAN

SAN은 다양한 업무 프로세스로 분산되어 있는 저장장치를 통합 운영하여 업무의 효율성 증대, 인프라에대한 중복투자 방지 및 이기종간 데이터 공유를 목적으로 만들어진 서버와 저장장치간의 네트워크를 의미한다. 개별적으로 연결되어 있는 저장 시스템을 화이버 채널을 이용하여 별도의 전용 네트워크에 연결하여 집중 적으로 관리함으로써 데이터의 고속전송, 고 가용성, 확장성 및 공유 기능을 제공하 기 위한 시스템이다. [그림 4-9-2]는 SAN의 구조를 보여 준다.
SAN은 데이터베이스 관리시스템 및 트랜잭션 프로세싱 시스템처럼 일반적으로 자 체 대규모 데이터를 관리하는 고성능 애플리케이션에 적합하다. 모든 물리적 위치와 관련된 유연성과 특정 레코드나 작은 레코드 집합에 대한 빠른 접근에 초점을 맞추 고 있다. 이러한 어플리케이션은 파일수준의 공통 접근을 요구하지 않고 블록 수준 의 성능 및 제어를 요구한다. 데이터베이스 [그림 4-9-2] SAN의 구조 관리시스템에서는 블록 수준의 읽기와 쓰기를 요구하며 SAN은 이러한 요구를 충족시킬 수 있으며, 다양한 확장성을 제공함으로 급증하는 데이터의 용량과 관리를 충족시킬 수 있다.

SAN은 다음과 같은 장점을 지닌다.
- 고속의 전송속도(200MB / Full- duplex이상)
- 장거리 전송(100Km이상)
- 뛰어난 연결성과 확장성이 뛰어나다.(Over 16 Million)
- 용이한 Data 관리 - 용이한 통합 및 관리
- 저렴한 비용
- Multi-protocol Flexibility(SCSI, ESCON, IP)
- One active SAN another Standby(Fail Over)
- Hi-availability SAN(Clustering)

다. iSCXI

SAN은 DAS와 같이 서버에 직접적으로 스토리지를 연결하는 게 아니라 스위치 를 통해서 전체 스토리지 영역을 구성해 DAS의 한계인 확장의 어려움을 해결했 다. 그러나, SAN은 많은 장점에도 불구하고 시스템의 구축비용이 비싼데다 벤 더들간의 호환성 등이 문제로 지적됐다.
이러한 SAN의 문제점을 극복하고자 고안된 게 iSCSI라는 기술이다. 스토리지 시장의 새로운 화두로 떠오른 iSCSI는 "internet SCSI’의 약자로 스토리지 연 결에 사용됐던 물리적 SCSI연결 방식 대신 물리적으로는 이더넷을 사용하며 내 부적으로는 SCSI 프로토콜을 사용하려는 기술 표준으로 IBM과 시스코가 2000년 2월 IETF(Internet Engineering Task Force)에 제출한 스토리지 네트워크 기술 로써 현재 표준 안이 완성단계에 있다.

[그림 4-9-3] DAFS에서의 파일 접근 방법

iSCSI의 핵심은 TCP/IP상에서 캡슐화 된 SCSI 정보를 이동시키는 것으로 로 컬 혹은 원격지에서 서버와 스토리지를 연결하여 스토리지가 여러 지역에 분산 돼 있고 IP 네트워크의 관리가 쉬운 고성능의 네트워크 스토리지 상에서 사용 된다. iSCSI 이전에 SAN을 구축하기 위한 유일한 스토리지 네트워크 방법은 사 용자가 각각의 분리된 SAN 인프라스트럭처에 투자해야 하는 파이버 채널뿐이었 다. 왜냐하면 이것은 10M, 100Mbps 이더넷에 비해 빠른 기가비트의 속도를 제 공하기 때문이다. 하지만 파이버 채널은 표준이 설정돼 있지 않아 벤더들 간에 호환이 어려웠으며 비용도 고가였다.
iSCSI에 관심을 갖는 이유는 스토리지 시장의 규모가 연간 4백억 달러에 달 하며 지속적으로 성장하고 있기 때문이다. 즉 이러한 스토리지들의 연결이 가 능하게 되면 사용자에게 더 높은 가치를 제공할 수 있다. 기존 스토리지는 DAS 형태로 전체 네트워크와 독립돼 있었다. 하지만 iSCSI의 도입으로 사용자는 원 격에서도 데이터베이스에 접근할 수 있다. 즉 고객에게 미치는 가장 큰 영향도 스토리지에 IP 네트워크를 이용해 접근, 자원의 사용이 가능하다는 것이다. 이 것은 스토리지 네트워킹의 혁명이라 할 수 있다.

라. DAFS

10GB 네트워크 기술의 등장은 스토리지 업계에도 상당한 파급력을 전해주고 있다. RAID 기술이 기존 스토리지의 물리적인 한계를 극복한 반면 iSCSI는 기존 SCSI 기술 을 10GB 네트워크 상에서 사용할 수 있도록 개발이 진행 중이다. 하지만 본격적인 10GB 시대가 도래하면 iSCSI는 도태할 것이라는 전망도 조심스럽게 개진되고 있다. 이러한 상황에 DAFS(Direct Access File System)의 등장은 현재의 스토리지 네트워 크를 한 단계 올릴 수 있을 것으로 기대되고 있다. [그림 4-9-3]은 DAFS에서의 파일 접근 방법을 보여 준다.
DAFS는 DAFS Collaborators라는 기관을 중심으로 IBM, HP, SUN, ORACLE 등 모 두 85개 이상의 업체들이 참여하여 서로 역할을 분담하여 성능, 확장성, 안정성 개선 이라는 목표를 가지고 노력해 왔다. 이들은 이미 노력의 결실을 일정 수준 이상까지 완성하여, 2001년 9월 DAFS Specification Version 1.0이 이미 완성되어 IETF에 제출 되었으며 DAFS API Specification Version 1.0은 2001년 11월 완성되었다. DAFS Collaborators는 크게 두 가지 분야에 초점을 두고 진행되고 있는데 그 중 하 나는 DAFS라는 프로토콜 자체를 만드는 분야이며, 나머지 하나는 RDMA(Remote Direct Memory Access) 기술을 구현하고 그 기술을 DAFS에 접목시키고자 하는 분 야이다.
현재 DAFS 프로토콜을 만드는 분야는SNIA (Storage Networking Industry Association)의 한부문으로써 DAFS Implementers Forum이라는 그룹을 중심으로 그 노력이 진행되고 있다. 초창기부터 이 포럼에 참가하여 초기 개발자로서 그 중심 적인 역할을 수행하고 있는 업체들로는 네트워크 어플라이언스를 중심으로 브로드 밴드 스토리지, 에뮬렉스, 인텔, 그리고 베리타스 소프트웨어와 같은 회사들이 있다. 이 업체들이 초창기부터 구현하고자 했던 것은 dDAFS(driver DAFS)였다. 그러나 진 정한 DAFS의 실현은 uDAFS(user DAFS)의 완성이라고 보았을 때 이들만의 노력으 로 이룩할 수 있는 것은 DAFS의 최종적인 목표는 될 수 없는 것이었다. 이러한 뜻에 동참하여 uDAFS의 최종 완성을 목표로 이들에 다시 합류하는 애플리케이션 업체들 이 있는데 이들이 바로 오라클, 사이베이스, DB2 등 있다.

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

1. Go to Help -> Software Updates -> Find and Install.
2. Select the “Search for new features to install” option.
3. Press the “New Remote Site…” button
4. and enter “Technoetic” for the name
5. and “http://www.technoetic.com/eclipse/update” for the URL.
6. Press OK, and install the Jode plugin from the subsequent list of features.

<<프로세스 능력 성숙도 모델(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