전문가시스템의 개발절차

1. 서론

본 장에서는 지금까지 살펴보았던 전문가시스템과 관련된 다양한 요소기술들을 토대로 하여 실제 활용가능한 시스템을 개발하는 과정을 소개하고자 한다. 전문가시스템도 궁극적으로는 전체 정보시스템의 한 구성요소로 볼 수 있기 때문에 일반적인 정보시스템의 개발에 필요한 시스템 분석 및 설계와 관련된 모든 개념이 전문가시스템의 개발에도 적용될 수 있다.

그러면 전문가시스템의 개발을 위하여 종래의 시스템 분석과 설계기법을 그대로 활용하면 되는가? 그렇지는 않다. 전문가시스템은 기존의 정보시스템과는 구분될 수 있는 특성을 지니고 있기 때문에 종래의 시스템 분석과 설계기법을 그대로 적용시킬 수는 없으며, 다소 변형된 자신의 독특한 개발과정을 거침으로써 보다 효율적으로 시스템을 구축할 수 있다. 따라서 본서에서는 전문가시스템 개발 절차를 계획 단계와 개발 단계로 구분하여 설명하고 있다.

이하에서는 이러한 두 가지 단계 중 개발단계의 효율화를 위하여 기존 정보시스템 부문에서 널리 활용되고 있는 시스템 개발주기방법과 프로토타이핑 방식을 혼합한 새로운 개발주기를 우선 소개하고,다음으로 전문가시스템의 개발을 위하여 계획단계와 개발단계에서 각각 수행되어야 할 세부내용을 살펴보기로 한다.

2. 시스템의 개발 절차

일반적으로 전문가시스템을 효율적으로 개발하기위하여 그 개발 절차를 정형화하여 사용하고 있는데, 본 절에서는 이러한 내용을 소개하고자 한다. 전문가시스템의 개발도 기존의 정보시스템 개발에 사용되는 방법을 근간으로하고 있으나,이들 두 시스템들간의 특성상의 차이 때문에 그대로 활용될 수는 없고 다소 변형된 독자적인 개발과정을 거치는 것이 바람직한 것으로 인식되고 있다. 따라서 본 절에서는 우선 이들 두 시스템들간의 특성상의 차이점을 살펴본 뒤에, 기존의 정보시스템 개발에 많이 활용되고 있는 시스템 개발주기와 프로토타이핑 방식에 대해 공부하고, 이어서 전문가시스템 개발을 위한 적절한 개발 절차를 소개하고자 한다.

2.1 전문가시스템과 일반 정보시스템

여기서는 전문가시스템을 개발하는데 이어 일반적인 정보시스템 개발에 사용되는 방법들을 어느 정도 활용할 수 있는지를 파악하기 위하여, 전문가시스템과 일반 정보시스템을 비교하여보도록 한다.

우선 기업에서의 일반적인 정보시스템과 전문가시스템의 공통점을 살펴보면 첫째, 양 시스템이 모두 의사결정과 관리과정의 질적 향상을 궁극적인 목적으로 삼고 있다는 점이다. 둘째, 시스템의 개발에 필요한 자원과 시간을 확보하기 위하여 최고경영층과 사용자의 동의를 구하여야 한다. 마지막으로 개발과정에서 시스템 분석과 설계기법으로부터 큰 도움을 받을 수 있다는 점이다. 즉, 일반적으로 시스템 분석과 설계는 지금까지 기업에서의 정보시스템을 개발하는데 있어 무엇보다 중요한 역할을 담당해온 것으로 인식되고 있다. 이러한 시스템 분석과 설계 작업은 전문가시스템의 개발에 있어서도 마찬가지로 중요한 역할을 수행하는 것으로 생각할 수 있다. 왜냐하면 기업에서의 전문가 시스템도 궁극적으로는 전산화된 일종의 의사결정도구로 생각하여 일반 정보 시스템의 범주에 포함시킬 수 있기 때문이며, 특히 규모가 크고 전략적인 차원에서 중요성이 높은 전문가시스템을 개발하고자 할 경우에는 이러한 시스템 분석과 설계의 필요성은 더욱 커지게 된다.

다음으로 기업에서의 정보시스템과 전문가시스템의 차이점을 특히 분석 및 설계의 관점에서 살펴보면 다음과 같다. 첫째, 전문가시스템은 정보시스템에 비하여 새롭고 아직은 많이 보급되지 못한 상태이다. 따라서 최고경영층, 전문가, 그리고 사용자들로서는 전문가시스템의 목적을 정의하고 그 능력과 한계를 정확하게 파악하기 위하여 보다 심도 깊은 대화와 토의가 필요하다. 둘째, 일반적으로 정보시스템은 정형화된 업무처리부문을 주요 대상으로 하고 있으나, 전문가시스템은 비구조화 혹은 반구조화된 의사결정문제를 해결하기 위하여 설계된다. 그리고 전문가시스템의 개발자는 이러한 문제를 해결할 수 있는 구조를 만들어 넣어야 한다. 따라서 최종적인 전문가시스템을 개발하기 위해서는 수 차례의 반복과 시행착오를 거칠 수 있는 개발 방법론이 채택되어야 한다. 이러한 방법이 바로 프로토타이핑 방식이다. 셋째, 전문가시스템은 해당 분야의 전문적인 지식을 보유하고 있는데, 이러한 지식은 이미 제12장에서서 살펴본 바와 같이 상당히 복잡하고 어려운 지식획득 과정을 통해서 얻을 수 있다. 이에 비하여 정보시스템은 그 수집 및 보관 방법이 이미 잘 정의되어 있는 자료를 주로 처리하기 때문에 자료수집 과정에서의 어려움은 없다. 따라서 전문가시스템을 개발하기 위해서는 지식획득을 효율적으로 수행할 수 있는 적절한 방법이 강구되어야 한다. 넷째, 전문가시스템은 대개 구체적인 해답을 제시하거나, 문제를 진단하거나 특정 조치를 취하게 한다. 이에 비하여 정보시스템은 궁극적인 해답을 제시하기 보다는 이를 위한 입력자료만을 던져준다. 따라서 전문가시스템의 개발에는 시스템으로부터 제공될 해답에 대한 절차검증 (Verification) 및 성과검증 (Validation) 을 위한 추가적인 절차가 필요하게 된다.

2.2 시스템 개발주기와 프로토타이핑

상대적으로 큰 규모의 전문가시스템을 개발하기 위해서는 보다 정형화된 시스템 개발단계를 사용하여야 한다. 시스템 개발주기란 소프트웨어라는 눈에 보이지 않는 상품을 개발하는데있어 진행상태를 모니터하고, 필요한 경우 설계변경 내지 프로젝트 중단의 조치를 취할 수 있도록 개발과정을 단계화하여 매단계마다 산출되는 중간산물을 점검, 확인함으로써 성공적인 시스템을 개발하자는 프로젝트 관리기법으로 볼 수 있다. 시스템 개발주기의 내용은 학자들에 따라 약간의 차이는 있으나 대개 분석, 설계, 코딩, 테스팅, 구현, 그리고 유지보수등의 여섯 단계로 구성되는 것이 일반적인 것으로 인식되고 있다.

시스템 개발주기 접근방법은 전문가시스템의 개발을 위한 정형화된 틀을 제공하기 때문에 개발과정에서 발생될 수 있는 오류나 실수의 가능성을 최소화할 수 있다는 장점을 가지고 있는 반면 다음과 같은 단점도 함께 지니고 있다는 점을 알아야 한다. 즉, 실제경영자들이 자신의 눈으로 개발된 시스템을 확인할 수 있는 것은 완전한 시스템이 개발된 후라야 가능하다. 그리고 이 단계에 이르기까지에는 상당히 긴 시간이 소요되므로 개발과정에서 경영자로 하여금 개발에 필요한 자금투자를 유도하는데 많은 어려움이 있다.

시스템 개발주기가 지닌 문제점을 해결하기 위하여 많이 사용되는 것이 프로토타이핑 방식이다. 일반적으로 시스템 개발에는 불확실성이 수반된다. 특히 규모가 큰 시스템의 개발은 더욱 그러하다. 많은 인력과 자금을 투입하여 개발한 시스템이 사용자 요구를 제대로 충족시킨다는 보장이 없기 때문이다. 이러한  불확실성은 사용자 요구를 정의하기 어려운 비구조적 혹은 반구조적인 문제를 주로 다루는 의사결정지원시스템 혹은 전문가시스템일수록 더욱 커진다. 이러한 상황에서 시스템개발의 한 방법론으로 등장한 것이 프로토타이핑 방식이다. 프로토타이핑이란 초기 모형을 뜻하는 것으로 개발 초기에 시스템의 모형을 간단히 만들어 사용자에게 제시하여 사용자로 하여금 실제 작동시켜 기능의 추가, 변경 내지 삭제를 요구하도록하여 시스템을 점차적으로 개선시켜 나가도록 하는 방식을 말한다. 이렇게 함으로써 경영자와 사용자들은 짧은 시간 내에 자신들이 궁극적으로 사용하게 될 시스템을 이해할 수 있을 뿐만  아니라, 시스템 개발자의 입장에서도 대상 영역의 문제를 보다 잘 이해하게 되고, 개발범위를 잘 인식하며 향후 확장영역을 결정하는 점 등에서 큰 도움을 받을 수 있게 된다.

이러한 이유로 전문가시스템의 개발에 프로토타이핑 방식이 많이 사용되고 있다. 이미 앞에서도 살펴보았듯이 전문가시스템의 개발대상 영역은 주로 비구조적이거나 반구조적인 문제를 해결하는 것이다. 이러한 문제의 경우, 처음부터 사용자 요구를 정의하는 것이 불가능한 경우가 많다. 그런데 많은 인력과 자금을 투입하여 완전한 시스템을 개발한 후에 사용자의 만족여부를 판단하는 것은 너무나 위험부담이 크다. 따라서 간단한 초기 모형을 만들어 사용자의 피드백 (Feedback) 을 받아 잘못된 부분을 수정하는 과정을 거쳐 점진적으로 완전한 기능을 갖도록 하는 개발 방법이 바람직하다.

그러면 전문가시스템의 개발은 프로토타이핑 방식만으로 가능한 것인가? 그렇지 않다. 프로토타이핑 방식은 분석 단계에서의 사용자 요구를 정의하는 하나의 방법일 뿐 나머지 시스템 개발주기 전체를 포괄하는 방법은 아닌 것이다. 따라서 프로토타이핑 방식을 기존의 시스템 개발주기에 접목시킴으로써 상호보완적으로 활용할 수 있게 된다. 이러한 절충방식은 비구조적 혹은 반구조적인 문제를 다루는 의사결정지원시스템이나 전문가시스템의 개발에 아주 적합한 방법으로 생각된다.

2.3  전문가시스템 개발을 위한 절차

지금까지 일반 정보시스템의 경우, 전체적인 정보시스템에 대한 계획을 먼저 수립한 후 이 계획을 근거로 실제 단위 시스템들에 대한 개발작업이 수행된다. 이와 같이 계획단계를 거쳐 개발타당성이 입증된 시스템에 한하여 개발을 위한 절차에 대해 논하기 때문에 대개의 경우 계획 절차에 관한 언급없이 바로 개발 절차에 대한 내용을 소개하고 있다.

이러한 관점에서 볼 때 전문가시스템의 개발을 위해서도 계획 절차와 개발 절차를 모두 거쳐야 할 것으로 생각된다. 왜냐하면 개발경험이 많지 않으며, 개발과정이 정형화되어 있지 않은 시스템을 개발할 경우 초기 개발계획의 내용이 최종적인 시스템의 성공여부에 아주 중요한 영향을 미친다는 점을 감안해 볼 때, 전문가시스템의 성공적 개발을 위해서는 효과적인 계획수립이 필연적으로 뒤따라야 하기 때문이다.

따라서 전문가시스템 개발절차를 계획단계와 개발단계로 크게 나눌 수 나누기로 한다. 그리고 계획단계에 수행되어야 할 세부절차를 다음 그림 1 에서 볼 수 있는 바와 같이 기초 요구 분석, 문제해결 구조정의, 개발 추진계획 등으로 분류하였다.

한편 개발단계에서 수행해야 할 작업을 효율화하기 위해, 프로토타이핑 방식과 기존의 시스템 개발주기 방식을 결합한 절충형 개발 방법을 제안한다. 이 방법에 의하면 시스템 개발단계들은 다음 그림 2 와 같이 표현되며, 그림에서 표시된 화살표는 해당 개발단계의 내용이 반복적으로 수행될 수 있음을 보여 주고 있다. 그러면 이하에서는 전문가시스템 개발을 위한 계획 절차와 개발절차의 세부적 내용에 대해 보다 상세하게 살펴보도록 한다.

그림 1  전문가시스템 개발을 위한 계획 절차

그림 2  전문가시스템의 개발 절차

3. 계획 절차

전문가시스템 계획수립은 정보시스템 계획수립의 결과로, 혹은 전문가 그룹 또는 최종사용자 그룹에서의 요청에 의해 어떤 업무영역이 전문가시스템 구축 영역으로 결정되었을 때 이를 개발하기 위한 계획을 수립하는 것을 말한다. 이미 앞에서 살펴본 바와 같이 전문가시스템은 일반 정보시스템과 비교해 볼 때 그 특성이 다르므로 개발단계도 달라진다. 즉, 정보시스템은 업무수행에 필요한 데이터와 업무수행절차가 결정되면 이를 구축하기 위한 방법으로 자료처리방법에만 의존하지만, 전문가시스템으로 개발할 경우에는 대상 영역에서 사용되는 지식의 형태에 따라 다양한 시스템 개발 방법론이 적용될 수 있다. 예를 들어, 문제 성격에 따라 규칙기반 시스템, 신경회로망 시스템, 사례기반 시스템 등과 같은 다양한 방법들을 독립적으로 혹은 통합적 (Hybrid) 으로 활용할 수 있기 때문에, 계획수립 단계에서 적절한 방법론을 결정함으로써 이후 개발단계에서 해당 방법론에 적합한 개발 절차를 따를 수 있도록 해야 할 것이다. 이러한 계획수립 과정에서 수행되는 주요 업무는 앞의 그림 1 에서 보았던 바와 같이 기초 요구 분석, 문제해결구조 정의, 개발 추진계획 수립 등이다.

3.1  기초요구 분석

기초 요구 분석 단계에서는 문제해결구조를 결정하기 위하여 현 상황을 개략적으로 분석하여 문제의 특성을 파악한다. 이 단계에서 수행되는 주요 업무는 다음과 같이 크게 다섯 가지로 분류할 수 있다. 우선 계획수립을 위한 프로젝트를 편성하고, 둘째 대상 영역의 문제를 정확하게 정의하고 개발될 전문가시스템의 범위와 목표를 명확히 하며, 셋째 대상 업무영역에 대한 현 상황을 분명하게 기술하고, 넷째 개발될 전문가시스템에 대한 요구 사항을 파악한다. 그리고 마지막으로 전문가시스템을 구축하기 위한 개발 환경을 조사한다.

(1) 계획 프로젝트 편성

전문가시스템 개발을 위한 계획 절차를 보다 체계화하기 위하여 계획단계에서 수행해야 할 과업을 프로젝트로 편성하여 수행하도록 한다. 여기서는 주로 다음과 같은 내용의 작업이 이루어져야 한다.

① 계획프로젝트의 추진계획 및 범위의 결정 : 전문가시스템의; 영역을 파악하여 계획프로젝트의 범위를 설정하고 이를 수행하기 위한 추진방향을 정의한다.

② 계획프로젝트의 접근방법 정의 : 계획프로젝트의 범위와 목표에 대한 구현방법 및 기술을 프로젝트 관리자가 경영층에게 보고 하여 승인을 얻는다. 여기에는 계획프로젝트에 참여하는 부서와 우선순위 등을 고려한 단계별 접근 방법이 포함된다.

③ 계획프로젝트의 추진계획 승인 : 프로젝트 관리자는 계획프로젝트에 대한 승인후에도 해당 프로젝트가 완료될 때까지 경영층 및 핵심요원들과의 긴밀한 의사소통을 유지하여 이들로 하여금 계속적으로 프로젝트에 참여할 수 있도록 유도하여야 한다.

④ 계획프로젝트팀의 편성, 교육 및 책임할당 : 전문가시스템 계획수립 프로젝트의 성공적 추진을 취해서는 핵심적인 기능을 보유한 요원들로 팀을 편성하는 것이 무엇보다 중요하다. 또한 프로젝트의 범위, 목적, 접근방법 등에 대한 요원들의 교육과 적절한 임무부여도 중요한 성공요인들 중의 하나이다.

여기서 그냥 프로젝트라 하지 않고 굳이 계획프로젝트라는 표현을 사용하는 것은, 계획프로젝트에 의해 계획 절차를 마치고 개발단계에 접어들기 전에 실제 개발을 위한 개발프로젝트가 편성되어야 하는데 이러한 개발프로젝트와 구별하기 위함이다.

(2) 문제 인식

이 단계에서는 해당 영역의 문제점을 인식함으로써 해결해야 할 문제를 정확하게 정의하고 문제해결의 범위와 목표를 명확히 하여야 한다. 이 단계의 결과에 의해 이후에 수행되는 분석작업이 좌우되기 때문에 상당히 중요한 단계라고 생각된다. 여기서는 주로 다음과 같은 작업이 수행된다.

① 문제의 정의 : 전문가시스템의 대상 업무영역이 무엇인가를 정의한다.

② 문제의 범위 : 정의된 문제의 대상 업무영역 중 일부를 전문가시스템으로 개발할 것인지 혹은 전부를 개발할 것인지를 결정한다. 그리고 일부만을 개발할 경우 어느 영역을 포함할 것인가를 명시한다.

③ 개발목적의 정의 : 현재의 문제점을 해결하기 위한 목적이 무엇인가를 정의하고, 문제해결 후의 효과에 대하여 기술한다.

④ 사용대상자의 정의 : 개발될 시스템이 전문가를 대체하기 위한 것인지 아니면 지원하기 위한 것인지에 따라 사용대상자가 결정될 수 있다. 즉, 전자의 경우에는 비전문가가 사용자가 될 것이며, 후자의 경우에는 전문가가 사용자가 될 것이다.

이해를 돕기 위하여 금융기관에서의 대출자문 시스템을 예로 들어 살펴보기로 하자. 같은 대출자문 시스템이라 하더라도 고객으로 하여금 그들의 대출 가능성을 스스로 체크할 수 있도록 해주는 시스템을 원할 수도 있는 반면, 그 은행에서 지금까지 대출업무를 담당하고 있던 전문가가 퇴직하게 되어 그 사람이 가지고 있던 대출관련 지식을 전문가시스템으로 개발하고자 하는 목적이 있을 수 있다. 이 예에서 보면 알 수 있는 바와 같이 동일한 대상 영역을 다루는 시스템이지만 양자의 문제형태와 궁극적으로 추구하고자 하는 목적은 근본적으로 다르며, 이러한 문제형태의 차이점은 개발과정에서 야기되는 여러 가지 의사결정에 영향을 미치게 된다. 즉, 대출담당자의 역할을 대신하게 될 시스템의 경우에는 담당자의 의사결정과정을 그대로 흉내만 내면 되기 때문에 수집해야 할 지식도 해당 담당자의 지식으로 한정된다. 이에 비해 일반 고객이 사용자가 될 시스템의 경우에는 시스템의 목적이 여러 가지가 있을 수 있기 때문에 적절한 목적을 미리 설정해 두어야 한다. 즉, 대출가능성에 대하여 그저 예/아니오 형태의 답만 제시하면 되는지 아니면 다른 종류의 적절한 대안까지도 제시하도록 할 것인지 등을 사전에 결정해 두어야 한다.

(3) 현상황 기술

수작업으로 이루어지고 있는 대상 문제영역 내에서 현상황을 정확하게 기술하도록 한다. 그리고 현재 처리되고 있는 지식의 형태를 파악함으로써 향후 개발될 시스템에서의 문제해결 방법 결정을 위한 기초로 활용될 수 있도록 한다. 여기서는 주로 다음과 같은 작업이 수행된다.

① 현재 사용하고 있는 문제해결 수단 : 현재 사용하고 있는 전문적인 문제 해결 수단을 모두 기술하는데, 여기에는 내부전문가의 도움, 외부전문가의 자문, 책자 및 규정집의 참조 등이 포함된다. 이 중 특히 전문가의 도움으로 문제를 해결하고 있는 경우, 시스템 개발시 이러한 전문가의 지원을 받을 수 있을 것인지도 조사하여야 한다.

② 현재 사용하고 있는 문제해결 방법 : 문제해결 방법을 파악하기 위해서는 입력-처리-출력 (Input-Process-Output) 의 관점에서 정리하는 것이 효과적이다. 즉, 문제해결을 위한 입력원천 혹은 필요 데이터가 무엇인지를 조사하고, 다음으로 문제해결 처리과정을 조사하며, 마지막으로 문제해결 후 작성되는 결과물이 무엇인지를 조사하면 된다.

③ 전문가의 지식습득 방법 : 지식의 특성상 계속 변화되는 지식일 경우 전문가가 신규지식을 습득하는 방법을 조사한다. 이에는 수동 혹은 반자동 습득방법, 자동화된 도구의 사용 등이 있을 수 있다.

④ 수작업 상황의 문제해결 성능 및 시기 : 문제해결에 소요되는 시간, 1일 사용횟수 등과 같은 시간적 측면과 사용하는 지식의 양과 투입인원 등과 같은 자원적 측면에서 조사가 이루어져야 한다.

⑤ 분산정도 파악 : 대상 문제영역의 지역적 분산정도를 파악하여 정리한다. 이에는 지식수집장소와 문제처리장소 등에 관한 분산정도의 내용이 포함된다.

⑥ 대상 문제영역의 자동환 시스템 현황 : 보유 하드웨어, 소프트웨어, 네트워크 장비들을 조사하여 정리한다.

(4) 요구 사항 파악

개발될 전문가시스템에 대한 요구 사항을 파악한다. 이러한 요구사항에 따라 개발될 시스템의 규모, 성능, 타당성 등의 내용이 결정될 수 있다. 이 외에도 시스템 개발완료 후의 시스템 평가를 위한 기초자료로 활용될 수 있다.

① 개발목적에 따른 시스템 수준 : 일반적으로 개발될 시스템의 수준에 따라 다음과 같이 다섯 가지로 분류하고 있는데, 궁극적으로 개발될 시스템이 이 중에서 어디에 속하는지를 미리 결정해야 한다.

• 데모용 프로토타입 (Demonstration Prototype) : 전체 문제영역 중 일부분 만을 대상으로 개발하는 시스템으로, 이를 통해 전체시스템 개발의 가능성 여부를 파악하기 위해 사용된다.
• 연구 프로토타입 (Research Prototype) : 전체 문제영역을 대상으로 하여 개발되었으나 테스트 및 수정이 충분하지 못한 상태의 시스템을 말한다.
• 현장 프로토타입 (Field Prototype) : 어느 정도 신뢰성이 있는 시스템으로 실제 사용자가 환경에서의 활용을 통하여 수정을 거치게 된다.
• 생산모델 (Production Model) : 질적 수준, 신뢰성, 속도, 성능 등의 면에서 거의 하자가 없는 상태의 시스템을 일컫는다.
• 상업용 시스템 (Commercial System) : 본격적인 양산체제로 접어든 상태를 말한다.

② 사용자 요구수준 : 전문가지원용 시스템을 원하는지 아니면 초보자용 시스템을 원하는지를 파악하여야 한다.

③ 성능측면의 요구사항 : 신속성, 신뢰성, 정확성, 일관성 측면에서의 요구사항을 정리한다.

④ 사용자 인터페이스 측면의 요구사항 : 사용 용이성, 출력장비 구성 (예 : 멀티미디어) 등에 관한 요구사항을 정리한다.

⑤ 입출력 내용에 대한 요구사항 : 입력내용의 관점에서는 입력 요구 데이터, 입력 종류의 타입 (사용자/전문가/시스템 데이터) 에 관한 사항이 정리되어야 하며, 출력내용의 관점에서는 출력 요구 내용, 출력형태, 출력대상 (사용자/타 시스템) 등에 관한 사항이 정리되어야 한다.

⑥ 시스템 분산에 대한 요구사항 : 입력과 출력관점에서의 시스템 사용처에 대한 요구사항이 파악되어야 하며, 지식보관처에 대한 요구, 분산된 지식의 통합정도에 대한 요구 등이 정리되어야 한다.

(5) 개발 환경 조사

현재 보유하고 있는 기술 (인적 자원), 시스템 환경 (하드웨어 측면), 개발도구 (소프트웨어 측면), 네트워크 등의 정보시스템 기반구조 (Infrastructure) 에 대한 조사와 확보된 예산 등 고려해 봄으로써 전문가시스템으로의 개발을 할 것인지의 여부를 결정하고, 만약 개발하기로 한다면 내부에서 자체적으로 할 것인가 아니면 외부에 용역을 줄 것인지를 결정하는 기초자료가 되도록 한다.

① 내부환경 : 개발자, 사용자, 하드웨어, 소프트웨어, 네트워크의 측면에서 정리되어야 한다.
우선 개발자의 측면에서 보면 지식공학자의 존재 여부, 존재한다면 기술 정도는 어떠한지에 관한 내용이 정리되어야 한다. 사용자의 측면에서는 사용자의 시스템에 대한 친숙도, 교육수준 및 전문성 정도가 파악되어야 한다. 하드웨어 측면에서는 하드웨어 구성도, 소유장비 명세, 이용가능한 장비내역 등이 조사되어야 한다. 소프트웨어 측면에서는 보유하고 있는 전문가시스템 개발도구 명세, 개발용 프로그래밍 언어, 유사 전문가시스템 보유 여부, 그리고 정보시스템 소프트웨어 내역 및 데이터베이스에 대한 조사가 이루어져야 한다. 그리고 마지막으로 네트워크의 측면에서는 기존에 설치된 네트워크의 구성도, 공공 통신서비스의 활용 정도 등에 관한 내용이 정리되어야 한다.

② 외부환경 : 여기서는 외부에서의 유사 전문가시스템 개발경험, 상품화된 전문가시스템 개발도구에 대한 조사, 특수 요구사항 지원기술 여부에 대한 조사가 이루어져야 한다. 우선 유사 전문가시스템 개발경험을 파악하기 위하여 이러한 시스템을 사용하고 있는 사례업체를 조사하고, 해당 문제와 유사한 전문가시스템 개발경험자가 존재하는지를, 그리고 해당 문제에 대한 기술적 컨설팅 지원업체가 존재하는지를 파악한다. 한편 상품화된 전문가시스템 개발 도구를 체계적으로 조사하기 위해서, 사용기종 및 운영체제 (OS), 지식 표현형태, 추론 방법, 비용 등의 내용을 담고 있는 개발도구 비교테이블을 작성하는 것이 바람직하다. 이러한 조사는 추론 도구와 지식획득 도구로 나누어 수행하도록 한다. 마지막으로 특수 요구사항 지원기술 여부를 판단하기 위하여 사용자 인터페이스 등에서 요구한 내용을 지원할 수 있는 기술의 현존 여부를 조사하도록 한다.

③ 시스템 설치환경 : 기존 정보시스템과의 연계성 여부, 사용중인 하드웨어 및 소프트웨어 환경, 사용자의 시스템에 대한 친숙도 등을 조사한다.

④ 비용환경 : 책정된 예산규모, 투입가능한 인력규모, 허용된 개발기간 등에 대한 조사가 이루어져야 한다.

3.2  문제해결구조 정의

전문가시스템은 일반 정보시스템과 비교해 볼 때, 데이터의 관리 외에 지식을 추가적으로 관리해야 하기 때문에 개발과정에 있어 상황적 접근방법이 요구된다. 일반적인 정보시스템 개발과정은 계획, 분석, 설계, 구현, 시험 등의 개발주기 모델로 구성되는데 비해, 전문가시스템의 개발과정에는 이외에 지식획득이라는 단계가 추가되어 이를 구현하기 위한 지식 표현구조에 따라 시스템의 구조가 크게 달라진다. 본 단계는 전문가시스템 개발에 있어, 대상 문제의 특성과 지식의 특성 등을 미리 파악하도록 함으로써 적절한 개발단계와 개발전략을 결정할 수 있도록 하기 위한 것이다. 문제해결구조 정의 단계의 대부분을 차지하는 것은 지식획득인데, 이에 대한 자세한 내용은 지식획득 부분을 참조하기 바란다. 이하에서는 이러한 문제해결구조 정의과정에서 수행되는 주요 내용인 문제해결구조 파악과 개발 방법론 선정에 대해 살펴보도록 한다.

(1) 문제해결구조 파악

전문가시스템에 의한 문제해결구조를 파악하기 위한 방법은 단순한 문제유형의 분석에서부터 구체적인 수준의 지식 표현을 통한 분석에 이르기까지 매우 다양하다. 문제에 따라서는 이러한 모든 과정을 거쳐야만 그 구조를 파악할 수 있는 경우도 있지만 극히 일부의 정보만으로도 지식기반 시스템 혹은 신경회로망 시스템의 유형이 적합한지를 쉽게 파악할 수도 있다. 예를 들어, 문자인식 시스템의 경우 대상 영역의 전문가가 존재하지 않기 때문에 대상 영역 전문가로부터의 지식획득과 같은 일은 필요 없는 것으로 인식할 수 있다. 다음 그림 3 은 대상시스템을 전체적으로 분석할 수 있는 틀 (Framework) 을 제시하고 있다. 여기서는 어느 하나의 방법론을 결정하기 보다, 가능한 방법론을 모두 추출해 보고 이들을 시스템적 요구사항과 사용자 요구사항에 비추어 비교 평가하는 것이 바람직하다. 어느 특정 방법론이 전문가의 의견에 비추어 확실하다고 판단되면 그 방법론이 추출되는 시점에서 더 이상의 분석을 하지 않고 멈출 수도 있다.

그림 3  문제해결구조 파악을 위한 분석틀 (Framework)

① 대상 범위의 결정
문제해결구조의 분석을 위해서 먼저 일부 대상 영역을 선정해야 한다. 이때 선정된 대상 영역은 전체 문제를 대표할 수 있는 것이어야 한다. 왜냐하면 이를 근거로 전체적인 시스템 구조를 파악하고, 이러한 구조에 적합한 개발방법론을 선정할 수 있기 때문이다. 문제해결구조의 파악을 위한 대상 영역의 범위를 결정할 때에는, 기초 요구 분석의 결과를 토대로 전체 문제영역 중에서 가장 어렵다고 판단되는 부분이나 데이터의 성격이나 지식의 형태가 가장 보편적이라 생각되는 부분을 선택하는 것이 좋다. 이후 단계에서는 여기서 정한 대상 범위 내에서 정보를 직접 수집하고 분석하게 된다.

② 개발될 시스템의 역할 설정
기초 요구 분석 단계에서 도출된 문제정의 결과를 토대로 작성할 수 있으며, 필요한 경우 추가적인 조사를 할 수 있다. 시스템의 역할을 조사하는 목적은 시스템의 목표를 명확히 함으로써 문제해결구조의 절차를 결정하는데 도움을 받고자 함이다. 일반적으로 시스템의 역할은 다음과 같이 분류될 수 있다.

• 영역 전문가의 일을 대신하거나 지원하는 역할 : 이 경우에는 영역 전문가로부터 직접 지식을 획득하는 것이 중요하다.
• 현재 업무의 개선 혹은 현재 시스템의 성능향상을 위한 역할 : 이 경우에는 영역 전문가로부터의 지식획득보다 문제해결 방안의 개선을 위한 연구가 요구된다.
• 현재까지 풀 수 없었던 문제를 해결하는 역할 : 이 경우에는 문제해결을 위한 연구개발 단계가 필요하다.

③ 문제해결 방안의 형식 정의
문제해결 방안의 형식으로 다음과 같은 유형이 있을 수 있는데 이 중 적합한 형식을 정의하여야 한다.

• 지식을 기반으로 하는 문제해결 형식 : 사용자와 대상 영역으로부터 문제해결 방식을 추출할 수 있는 형태.
• 문제해결 방안을 대상 영역으로부터 추출할 수 없는 형식 : 예를 들면, 신경회로망의 문제해결 방식은 특정 대상 영역의 지식에 의존적인 것이 아니라 일반적인 문제해결 방식임.
• 연구개발 형식 (R&D 타입) : 현재까지의 문제해결 방안으로 쉽게 해결할 수 없는 형식으로 연구개발이 필요함.

④ 지식의 원천 파악
지식획득을 위해서는 먼저 지식의 원천을 조사해야 하는데, 지식의 원천은 대개 다음과 같이 세 가지 형태로 분류된다. 이들에 대한 자세한 내용은 지식획득 부분을 참고하기 바란다.

⑤ 지식의 획득
이미 지식획득 부분에서 살펴본 바와 같이, 지식획득을 위한 방법에는 수동방법, 반자동방법, 자동방법 등이 있다. 이들 각각에 대한 자세한 내용 역시 지식획득을 참고하기 바란다.

⑥ 지식의 형태 파악
대상 영역의 문제해결에 사용되는 지식의 형태가 다음 중 어디에 해당하는지를 판단하여야 한다.

• 문서 (Document) 위주
• 데이터 (Data) 위주
• 규칙 (Rule) 위주

⑦ 지식 표현의 불확실성 파악
지식을 표현하는데 불확실성이 있는지 파악하고, 있다면 어떤 형태로 이를 표현할 수 있는지를 정리한다. 불확실성을 표현하는 방법으로는 크게 다음과 같은 세 가지 방법이 있는데, 이들에 대한 자세한 내용은 불확실성의 표현과 처리 부분에 소개되어 있다.

• 퍼지 (Fuzzy)
• 불확실성 요소 (Uncertainty Factor)
• 통계적 방법 (Baysian Method)

⑧ 시스템 요구사항 확인
기초 요구 분석 단계에서 파악된 시스템 요구사항을 문제해결 관점에서 다시 정리한다.

⑨ 사용자 요구사항 확인
기초 요구 분석 단계에서 파악된 사용자 요구사항을 문제해결 관점에서 다시 정리한다.  

(2) 개발 방법론 선정

지금까지의 분석결과를 토대로 상황에 알맞는 적절한 개발 방법론을 결정하기 위한 단계이다. 여기서는 전문가시스템 개발에 주로 사용되는 대표적인 방법론으로 지식기반 시스템, 사례기반 시스템, 그리고 신경회로망 개발 방법론을 중심으로 소개하고자 한다. 대상 영역에 대한 분석결과가 이러한 세 가지 방법들 중 어느 하나에 속하는 경우, 해당 방법론에 대한 수명주기모형에 따라 개발하면 된다. 그러나 대상 영역이 복잡한 경우에는 이들이 복합적으로 활용되어야 하거나, 혹은 이 세 가지 방법론만으로는 개발이 불가능할 경우가 발생할 수가 있다. 이하에서는 이러한 경우에 대한 개발 방법론을 소개하고 있다.

① 대상 문제의 시스템 유형 정의
직전 단계인 문제해결구조 파악단계의 결과를 토대로 대상 영역의 문제를 어떻게 해결할 것인가를 정리할 수 있는데, 대개 다음에 열거된 문제해결을 위한 시스템 유형의 범주에 속한다. 이들 시스템 유형은 다음과 같이 정리할 수 있는데, 이중 문서관리위주의 시스템이나 R&D 유형의 문제에 대해서는 기존의 정보시스템 개발 방법론이나 연구개발 용역지침에 관한 자료를 참고하여야 할 것이다.

• 지식기반 시스템
• 사례기반 시스템
• 신경회로망 시스템
• 지식기반 시스템 + 사례기반 시스템 : 사례기반 시스템이 지식기반 시스템을 지원하는 형태인데, 사례기반 시스템이 지식기반 시스템의 결과를 설명하는 역할을 하는 형태이거나 혹은 지식기반 시스템이 사례기반 시스템을 지원하는 형태일 수 있다.
• 신경회로망 시스템 + 사례기반 시스템 : 사례기반 시스템이 신경회로망 시스템의 단점인 설명기능을 제공하는 형태를 예로 들 수 있다. 이 외에도 다양한 형태가 존재할 수 있다.
• 최적화 모형을 이용한 시스템 : 지식기반 시스템에서의 추론의 방법으로 최적화 모형을 사용하는 형태와 최적화 모형 시스템에서 규칙을 사용하는 형태가 있을 수 있다. 이러한 형태의 전문가시스템으로는 UNIK-PMA 가 있다.
• 문서관리 시스템 : 지식의 형태가 규칙이나 데이터 위주가 아니라 문서위주로 되어 있는 경우의 형태를 말한다. 이 경우에는 하이퍼텍스트 (Hypertext) 나 WWW(World Wide Web) 등의 방법을 이용하여 해결을 시도하는 것이 바람직하다.
• R&D 유형의 시스템 : 문제가 너무 복잡하여 단기간의 프로젝트는 해결이 힘든 경우인데, 이때에는 자체적으로 수행하기 보다는 외부 전문연구기관이나 전문업체에 위탁해서 연구용역을 수행하는 것이 바람직하다.

② 적절한 방법론 선택 및 정의
앞에서 소개된 8 개의 시스템 유형 중, 지식기반 시스템, 사례기반 시스템 그리고 신경회로망 시스템 중의 어느 하나로 정의되는 문제의 경우에는 각각의 수명주기모형 (상세분석, 설계, 구현, 시험 등) 을 개발 방법론으로 선택한다.
한편 네번째와 다섯번째 유형에 속하는 - 지식기반 시스템, 사례기반 시스템 그리고 신경회로망 시스템이 얽혀 존재하는 - 시스템의 경우에는 어느 하나를 주된 방법론으로 결정할 수 있는지를 검증한다. 지식기반 시스템이나 사례기반 시스템, 신경회로망 시스템 중 어느 하나가 주된 방법론으로 대표될 수 있다면, 이 방법론을 위주로 개발하되 필요한 경우 다른 방법론을 참조하는 형태로 개발될 수 있다. 예를 들면, 위의 다섯번째 유형과 같이 신경회로망 시스템과 사례기반 시스템이 함께 존재하는 시스템의 경우, 신경회로망 시스템 개발 방법론에 따라 개발하되 설명기능을 지원하는 사례기반 시스템 부분에 대해서는 사례기반 시스템 개발 방법론을 사용하면 된다.

3.3  개발 추진계획 수립

개발 추진계획 수립 단계에서는, 이제까지의 과정을 거쳐 선정된 전문가시스템 개발 방법에 따른 개발비용과 시스템 운영비용을 산정하고 시스템 효과를 예측함으로써 개발타당성에 대한 검토 및 조정작업을 수행하고, 본격적인 개발을 위한 프로젝트를 편성하게 된다.

(1) 시스템 개발계획 및 효과분석

이 단계에서는 전문가시스템으로의 개발을 위한 가능한 대체안들을 파악하여 그 중 최적의 대안을 선정하고, 선정된 대안에 대하여 소프트웨어 개발비용을 산정하고, 전문가시스템 운영비용을 추정하며 시스템 개발일정을 작성하게 된다. 이는 궁극적으로 전문가시스템 개발의 정량적, 정성적 효과를 분석함으로써 위험을 최소화하자는데 그 목적이 있다. 이 단계에서 수행해야 할 구체적인 내용을 살펴보면 다음과 같다.

① 시스템 개발대체안 평가
전문가시스템 개발을 위한 가능한 여러 가지 방안들을 평가하여 최적의 방안을 선정한다. 전문가시스템 개발도구를 도입하여 활용하는 것이 효과적일 경우에는 전문가시스템 개발도구 도입 평가기준에 의해 도입을 추진한다. 특히 시스템 개발 대체안을 작성ㆍ평가할 때에는 전문가시스템 개발계획서상에 다음 사항이 복수개로 작성ㆍ평가되어야 한다.

• 시스템 구조 (아키텍쳐)
• 하드웨어 및 소프트웨어 요건
• 시스템 운영방향
• 시스템 이용형태

② 소프트웨어 개발비용 산정
소프트웨어 개발비용의 경우 전문가시스템 개발비 산정기준을 만들어 사용한다.

③ 시스템 운영비용 추정
소프트웨어 개발완료 후 운영단계에서 소요되리라 예상되는 비용을 개략적으로 추정한다.

④ 시스템 개발 일정계획
소프트웨어 개발에 필요한 소요기간을 고려하여 일정계획을 수립한다.

⑤ 시스템 효과분석
시스템 개발완료 후 적용에 따른 정량적 및 정성적 효과를 분석한다.

⑥ 시스템 개발계획서 확정
작성된 시스템 개발계획 분석내용을 정리하여 전문가시스템 개발계획서로 확정하여 개발계획 승인부서 (예를 들면, 정보시스템 계획부서) 에 제출한다.

(2) 타당성 검토 및 조정

전문가시스템 개발 추진계획의 내용을 조직의 전체적인 정보시스템 중장기 계획 및 연간계획과의 관련성, 경제성, 기술성, 효율성 등의 관점에서 종합적으로 타당성을 검토하고 조정하는 단계이다. 이 단계에서는 다음과 같은 내용을 다루게 된다.

① 타당성 검토
정보시스템 계획부서에서는 요청된 전문가시스템 추진계획에 대해 타당성 검토를 실시한다. 어떠한 문제를 해결하기 위한 다른 특별한 방법이 없다고 해서 그것이 전문가시스템으로 해결되어야 한다는 것은 잘못된 생각이다. 현재 고려되고 있는 대상 영역의 문제를 전문가시스템으로 개발하기 위해서는 이에 대한 타당성이 있다고 판단될 경우라야 할 것이다. 일반적으로 전문가시스템 개발을 위한 타당성 조사에서는 정보시스템 계획과의 연계성, 운영적, 기술적, 경제적 측면에서의 검토가 이루어져야 한다.

• 정보시스템 계획과의 연계성 : 전체 조직의 정보시스템 중장기 및 연간계획과 해당 전문가시스템 계획과의 연계성을 검토한다.
• 경제적 타당성 : 시스템의 개발로 인하여 발생하는 유형 (Tangible) 및 무형 (Intangible) 의 이익과 개발 및 운영에 소요되는 인건비, 장비구입 및 유지보수 비용 등을 상호 비교하는 것이다.
• 기술적 타당성 : 컴퓨터 중심으로 보는 것이다. 즉, 제시된 대안을 위해 사용될 기술이 실용적인가, 그러한 기술 및 기술인력의 확보는 가능한가, 기간내 완성이 가능한가 등을 따지는 것이다.
• 운영적 타당성 : 사람 중심 (People-oriented) 의 검토이다. 시스템의 운영에 문제가 없겠는가를 검토하는 것으로, 제시된 대안에 대한 경영진과 사용자의 관심사항 및 수용 여부, 관리자의 지원정도, 그것이 조직구성원의 직무와 동기유발에 미치는 영향 등 검토하는 한편 입력자료의 획득 및 정확성 여부, 자료입출력 일정의 실현가능성 등을 조사한다.

② 사업조정 및 심의
자체개발할 것인지 혹은 외부용역에 의해 개발할 것인지 등의 개발 방법에 대한 조정 및 심의를 수행한다. 경우에 따라서는 전문가시스템 개발계획의 내용을 부분적으로 수정 또는 보완하게 된다.

③ 소프트웨어 개발 의뢰
시스템 개발계획서의 내용을 전문가시스템 정의서로서 확정ㆍ승인하여 정보시스템 개발부서로 개발을 의뢰한다.

(3) 개발 프로젝트 편성

앞에서 살펴보았던 계획 프로젝트의 편성과 마찬가지로, 전문가시스템의 개발을 보다 체계화하기 위하여 개발단계에서 수행해야 할 과업을 프로젝트로 편성하여 수행하도록 한다.

① 개발 프로젝트의 범위 및 방법 결정
전문가시스템 추진계획을 참조하여 프로젝트의 범위를 결정하고, 시스템 개발에 사용될 방법, 도구 등을 고려하여 프로젝트의 수행방법을 결정한다.

② 개발 프로젝트의 추진계획
개발 환경 및 사용가능한 도구, 사용자부서의 참여정도, 작업장소 (단일장소 혹은 복수장소) 등을 고려하여 개발 방법, 개발 범위, 개발 공정별 추진계획, 예상문제점 및 대책, 소요예산 등의 내용을 결정한다.

③ 작업 계획
소프트웨어 개발프로젝트 유형에 따른 개발공정별 작업순서, 작업 계획을 구성하는 세부작업 항목별 계획 (일정, 투입인력), 프로젝트의 작업표준 등을 설정한다.

④ 프로젝트팀 편성
프로젝트의 책임자 및 관리자를 결정하고, 개발공정별 투입요원과 기타 부서로부터의 지원인력을 선정하여 팀을 편성한다. 특히 외주개발의 경우에는 프로젝트의 효율적인 추진을 위하여 관리자 및 감독자로 구성된 사내 추진팀을 편성하는 것이 바람직하다. 프로젝트팀 구성요원에 대한 교육도 중요한 성공요인들 중의 하나이다.

4. 개발 절차

전문가시스템 개발을 위한 이제까지의 계획 절차를 통하여 개발계획이 수립되었으며, 실제 개발을 주도해 나갈 프로젝트팀도 구성되었다. 따라서 지금부터는 이러한 계획을 효과적으로 실행에 옮길 수 있도록 하는 개발 절차들에 대해 공부하기로 한다. 이러한 시스템 개발과정에서 수행되는 주요 업무는 앞의 그림 2 에서 보았던 바와 같이 상세분석, 설계, 코딩 및 테스팅, 구현, 유지보수 등인데 전문가시스템의 개발과정은 일반 정보시스템의 그것과는 달리 이러한 개발 절차들이 반복적으로 수행될수 있음을 명확하게 인식하여야 한다.

4.1  상세분석 단계

상세 분석 단계에서는 시스템 개발계획을 수립하기 위해 시행했던 기초 요구 분석의 결과를 토대로 보다 세부적인 분석작업을 수행함으로써 이후의 설계작업을 원활하게 할 수 있게 한다. 이 단계에서는 현행업무 또는 시스템에서 수행하는 업무기능, 의사결정과정 및 관련 자료들을 상세하게 조사하고 사용자의 요구정보, 자동화 업무영역, 성능, 기타 요건 등을 명시하고 업무에 대한 조사결과를 객체지향구조로 분석함으로써 신규시스템에서 수행되어야 할 자동화 처리기능, 객체 요건, 입출력 및 기타 요건 등을 정의한다. 이 단계에서 수행되는 주요 업무는 상세 업무 분석, 자동화 요구정의, 객체정의, 입출력정의 등이다.

(1) 상세 업무 분석

개발대상 업무별로 업무처리절차의 내용을 상세하게 기술하는데, 이는 자동화 업무영역정의를 위한 기초자료로 활용될 것이다. 그리고 대상 영역의 용어 및 관련자료들을 수집함으로써 개발자 (지식공학자) 로 하여금 자신의 업무를 보다 명확히 이해하게 하고, 대상 업무의 조직적 상황을 이해하기 위해 타업무와의 상관관계도 조사한다.

① 상세 업무 분석 일정계획

• 대상 업무를 효과적으로 검토할 수 있도록 업무담당자와의 면담일정계획을 수립한다.
• 업무담당자에 대한 책임, 권한, 기능, 경력 등의 업무에 관한 신상내용을 파악한다.
• 관련자료를 파악하고 조사일정계획을 수립한다.
• 면담질의서를 사전에 작성하는 등 효과적인 면담이 되도록 준비한다.

② 업무관련 자료 검토

• 면담조사를 효율적으로 진행하기 위해 업무처리절차, 지침, 규정집, 서식 등의 사전검토를 통하여 업무에 대한 지식을 미리 파악한다.
• 독자적으로 파악이 곤란한 사항에 대해서는 면담시 질의할 수 있도록 면담질의서를 준비한다.

③ 대상 업무절차의 파악

• 자료가 파악된 후에는 업무절차를 파악하기 위해 면담을 실시한다.
• 파악된 업무절차를 입력-처리-출력 (IPO) 의 3 단계 프로세스과정으로 분류한다.
• 면담자간에 의견이 일치되지 않을 경우에는 이를 조정하기 위한 업무담당자 회의를 소집한다.

④ 관련업무 상관관계 조사

• 대상 업무와 관련하여 업무처리상 우선순서의 관계에 놓여 있는 관련업무를 파악한다.
• 관련업무 사이의 데이터 입출력 관계를 파악한다.
• 관련업무 사이의 업무수행결과에 따른 상호 영향력을 파악한다.

(2) 자동화 요구 정의

여기서는 자동화 대상 업무의 영역을 정의함으로써, 이후 단계에서의 소프트웨어 및 하드웨어 기능요건의 파악을 위한 기초자료를 제공한다. 이를 위해서는 자동화 기능 요구 정의, 성능 요건 정의 등의 작업이 이루어져야 한다.

① 자동화 대상 업무 영역 정의

• 업무절차 중 자동화가 요구되는 영역을 조사한다.
• 개발자와 사용자간의 자동화 업무영역에 대한 의견을 수렴한다.
• 자동화 대상 업무는 정보수집-대안설정-대안선정 등 3 단계 의사결정과정을 통하여 결정될 수 있다.

② 자동화 기능 요건 정의

• 자동화 대상 업무영역에 대하여 자동화 형태를 완전 자동화할 것인지 아니면 반자동화함으로써 사용자를 지원하도록 할 것인지 등을 결정해야 한다.
• 완전자동형태의 경우, 시스템이 의사결정까지 수행하여 해결안을 제시하여야 한다.
• 사용자를 지원하는 형태의 경우, 시스템은 의사결정과정에서 사용자가 효과적으로 정보를 수집하거나 대안을 생성ㆍ선정할 수 있도록 지원해주는 기능을 담당하도록 한다.

③ 성능 요건 정의

• 전문가시스템이 제시할 해결안에 대한 기대수준을 정의한다.
• 전문가시스템의 수행속도에 대한 기대수준을 정의한다.
• 성능 요건의 시험기준을 적중률, 제약조건 만족률, 전문가 동의율 등의 방법을 사용하여 명확하게 제시하도록 한다.

(3) 객체 정의

전문가시스템에서 필요로 하는 모든 객체를 파악하여 정리함으로써, 차후 데이터베이스 혹은 파일구조, 지식베이스의 프레임 구조 설계를 위한 기초를 제공하도록 한다. 이를 위해 다음과 같은 작업이 수행되어야 한다.

① 객체 도출

• 상세 업무분석 단계에서 수집된 자료를 토대로 객체를 도출한다.
• 서식, 자료 등의 분석을 통하여 엔티티 객체를 도출한다.
• 처리절차의 분석을 통하여 컨트롤 객체를 도출한다.
• 담당자와의 면담을 통하여 인터페이스 객체를 도출한다.

② 객체정규화

• 엔티티 객체정의 내용의 중복성 분리 (제 1 정규형), 하위키 (Secondary Key) 에 종속되는 종속항목의 분리 (제 2 정규형), 주 키 (Primary Key) 에 의존하지 않는 종속항목의 분리작업 (제 3 정규형) 을 통하여 데이터 정규화를 수행한다.
• 정규화 결과에 따라 엔티티 객체를 확정한다.

③ 속성 정의

• 엔티티 객체의 각 속성 (Attribute) 에 대하여 속성명, 타입, 도메인, 길이 등을 정의한다.
• 코드체계를 정의하고 호환성을 검토한다.

④ 관계 정의

• 객체간의 계층관계, 구성관계 등을 정의하고 이를 해당 객체의 속성으로 반영한다.
• 유사 객체들의 일반화를 통하여 상속관계를 정의한다.

⑤ 연산 정의

• 객체간의 협력과정을 상호 전달하는 메시지를 통하여 분석함으로써 연산 목록을 작성한다.
• 각 연산을 적절한 객체를 할당한다.
• 연산에 대한 매개변수와 타입을 정의한다.

⑥ 객체모델 정의

• 객체의 속성, 연산부분을 통합하여 객체모델을 정의한다.

(4) 입출력 정의

신규시스템의 입출력 내용을 정의하고 사용자의 동의를 획득함으로써, 전문가시스템에서 관리, 유지, 보고되어야 할 데이터의 파악을 위한 기초를 제공할 수 있도록 한다. 이러한 입출력 정의 단계에서 고려해야 할 내용은 보고서, 화면, 서식 등이다.

① 보고서 정의

• 보고기능의 정의로부터 필요한 보고서 목록을 정의한다.
• 보고서 표준에 따른 각 보고서의 견본을 작성한다.
• 출력매체 및 빈도수에 따른 출력방법을 정의한다.

② 화면 정의

• 윈도우 환경에서 그래픽 사용인터페이스 (GUI) 에 의한 개발 방법을 채택할 경우에는 기본메뉴화면과 입력화면 및 출력화면에 대한 정의를 위주로 하고 운영과정에서 발생하는 구체적인 양식 (Form) 등은 설계시 구체화하도록 한다.

③ 서식 정의

• 입력 및 출력에 사용되는 일정한 서식의 목록을 정의한다.
• 각 서식에 대한 내용 및 사용법 등에 대한 설명을 기술한다. 

4.2  설계 단계

분석 단계를 거침으로써 해결해야 할 문제가 일단 정의되면, 다음으로 이러한 문제를 해결하기 위한 구체적인 방안이 마련되어야 한다. 이러한 과정을 설계라고 하는데 이를 통하여 개발될 시스템은 어떠한 모양을 갖게 될 것인지, 문제를 어떻게 해결하는지, 시스템의 주요 특성은 무엇인지, 다른 시스템과의 관계는 어떠한지 등을 알 수 있게 된다.

일반적으로 전문가시스템의 개발을 위한 설계 단계는 대상 영역으로부터 지식을 획득하는 것으로 시작된다. 즉, 문제해결을 위한 지식을 체계적으로 정리함으로써, 이를 표현하는 적절한 방법, 추론 방법 등을 설계할 수 있게 된다. 따라서 지식베이스의 설계가 선행되어야 하며 다음으로 이를 뒷받침할 수 있는 소프트웨어 설계, 하드웨어 설계, 사용자 인터페이스 설계 등이 뒤따르게 되는데 이하에서는 이러한 설계내용들에 대하여 상세하게 살펴보도록 한다.

(1) 지식베이스 (Knowledge Base) 의 설계

여기서 이야기하는 지식베이스의 설계는 지식을 모델링하는 과정을 일컫는 것으로서 일반적으로 논리적 설계라고도 부르고 있다. 이 단계에서의 주된 내용은 이미 지식획득에서 공부했던 지식획득 과정을 말하는 것으로, 이는 전문가시스템을 위한 도구나 프로그래밍 언어와 독립적으로 수행되어야 한다.

지식획득이란 여러 형태의 지식원천으로부터 필요한 지식을 추출하여 이를 구조적으로 조직화하는 과정을 말한다. 이미 앞에서도 살펴본 바와 같이 지식베이스의 구축을 위하여 지식의 수집을 책임지는 사람을 지식공학자라 하는데 이러한 지식공학자는 컴퓨터와 직접적으로 관계되는 기술보다는 오히려 대화 및 면담기술, 지식획득을 위한 그룹의 조직 및 관리, 새로운 대상 영역에 관련된 지식의 학습의지, 대규모의 신기술을 유연하게 처리하고 관리할 수 있는 능력등이 요구된다.

이와 같은 관점에서 볼 때, 지식획득으로 대변되는 지식베이스의 논리적 설계업무는 소프트웨어와는 독립적으로 수행되는 것이 바람직하다. 이렇게 함으로써 지식모델링 과정에서 유연성과 자유성이 보장되기 때문이다. 다시 말해서 지식 표현을 위한 소프트웨어는 지식의 종류나 성격에 의해 결정되어야지 소프트웨어가 지식모델링에 영향을 미쳐서는 안된다는 말이다. 따라서 모델링 단계에서의 지식은 유사코드 형태로 표현되는 것이 바람직한데 이를 지식베이스의 논리적 설계라고 부른다.

(2) 소프트웨어 (Software) 설계

소프트웨어와 관련하여 첫 번째로 직면하게 되는 사항은 시스템을 소스코드 (Source Code) 로부터 개발할 것인지 (Make) 아니면 상업화된 수많은 전문가 시스템 개발용 도구들 중에서 구매할 것인지 (Buy) 를 결정하는 것이다. 이러한 두 가지 방법은 표 1 에서 볼 수 있는 바와 같이, 상호 장단점을 지니고 있어 대부분의 경우 초기 프로토타입은 값싼 개발도구를 구매하여 개발하도록 하고, 후에 사용자들이나 개발자들이 모두 해당 시스템에 익숙해지고 기존의 개발도구들이 우리의 문제를 해결하는데 적합하지 않다고 판단될 때 소스코드로부터 직접 개발하는 전략을 활용하는 것이 바람직하다.

표 1  범용도구와 지식공학용 도구의 비교

여기서 만약 직접 개발하는 것으로 결정되면 개발자는 지식 표현 방법, 프로그래밍 언어, 그리고 프로그래밍 팀의 구성 등을 결정하여야 한다. 그런데 이러한 의사결증은 그림 4  에서 볼 수 있는 바와 같이, 소프트웨어의 개발이 완료될 때까지 수 차례씩 수정ㆍ반복되는 경우가 허다하다.

그림 4  전문가시스템 개발을 위한 소프트웨어의 결정

요즘은 전문가시스템 개발을 위한 다양한 도구들이 보급되고 있어 직접 개발하는 것보다는 소프트웨어를 구매하는 경우가 상대적으로 많은데, 이러한 경우에도 지식 표현 방법을 우선 결정하고 소프트웨어 상품에 대한 평가작업을 수행하여야 한다. 이와 같이 전문가시스템 소프트웨어를 결정하는 일은 생각만큼 그렇게 쉬운 작업은 아니다. 개발도구의 선정을 효율적으로 수행하기 위해서는 적절한 체크리스트 (Checklist) 를 사전에 마련하는 것이 바람직한데, 이를 위하여 일반적으로 고려해야 할 사항들은 표 2 에서와 같이 정리할 수 있다. 한편 소프트웨어가 구매되면 다음으로 시스템의 설치와 교육훈련과정이 뒤따르게 된다 (그림 4 참조).

소프트웨어와 관련된 의사결정문제는 시스템 설계 단계에서의 다른 문제들, 특히 하드웨어의 결정, 지식획득의 결과 등과 매우 밀접하게 연계되어 있다.

표 2  적합한 도구 (쉘 포함) 의 선정을 위한 체크리스트 (Checklist)

(3) 하드웨어 (Hardware) 설계

요즈음 많은 인공지능 언어들과 전문가시스템 개발용 도구들이 대부분의 하드웨어에서 활용이 가능해짐에 따라, 하드웨어의 선정기준은 주로 처리속도와 가격문제로 귀착되게 되었다. 대부분의 소프트웨어들이 마이크로 컴퓨터 (Microcomputer), 미니 컴퓨터 (Minicomputer) 혹은 워크스테이션 (Workstation) 등에서 작동이 가능해졌다. 그러나 미니 컴퓨터라고 해서 마이크로 컴퓨터에 비해서 처리속도가 더 나은 것은 아니다. 즉, 어떤 미니 컴퓨터들은 자신들의 시스템 소프트웨어로 인한 오보헤더 (Overhead) 때문에 마이크로 컴퓨터보다 오히려 성능면에서 뒤떨어지는 경우가 있다.

특히 소프트웨어를 직접 개발하기로 결정한 경우에는 개발에 사용될 프로그래밍 언어에 대해서 보다 나은 컴파일러를 제공하거나, 개발될 시스템에서 요구되는 그래픽, 음성합성, 네트워킹 기능 등과 같은 하드웨어 특성을 잘 갖추고 있는 하드웨어를 선정하여야 할 것이다. 그리고 특히 초기 프로토타이핑을 개발하는 과정에서는 새로운 하드웨어를 구매하는 것보다는 기존에 사용되고 있는 기계를 그대로 사용하는 것도 좋은 대안이 될 수 있다. 개발될 전문가시스템의 효용성이 높으면 높을수록 하드웨어에 대한 투자는 상대적으로 큰 반대급부를 보장하게 될 것이다.

(4) 사용자 인터페이스 (User Interface) 설계

대부분의 전문가시스템 개발도구에는 사용자가 자료를 입력하거나 시스템이 던지는 질문에 답할 수 있는 사용자 인터페이스가 제공되고 있다. 이러한 인터페이스에는 온라인 헬프 (On-line Help) 기능뿐만 아니라 시스템에 의해 제시되는 질문이나 답변에 개인적인 문구를 추가할 수 있는 기능 등이 포함되어 있다. 이러한 인터페이스는 초기 프로타입에는 적합할지 몰라도 보다 정교한 인터페이스를 원하는 경우에는 활용되기 힘든 경우가 많다.

일반적으로 사용자 인터페이스로 활용되고 있는 기술들로는 메뉴 (Menus), 서식 (Forms), 그래픽 (Graphics), 아이콘 (Icons), 음성 (Voice), 하이퍼텍스트 (Hypertext), 자연어 (Natural Language) 등을 들 수 있다. 이 중에서 메뉴나 서식, 그래픽 등은 상대적 보편화되어 있으며, 아이콘의 경우에 객체 (Objects) 를 주로 다루는 전문가시스템에 있어서는 사용자에게 매우 편리한 형태의 인터페이스로 인식될 수 있다. 음성을 이용하는 방식은 다른 작업을 수행하면서 시스템을 활용해야 하는 사용자에게는 효과적으로 활용될 수 있다. 이러한 방식은 최근들어 상당히 보편화되어가고 있는 실정이다. 하이퍼텍스트 형태는 전문가시스템 분야에서 활용도 측면에서는 아직 초기 단계에 있지만 이미 상품화된 제품들이 속속 등장하고 있는 추세이다. 자연어방식은 전형적인 인공지능분야의 응용영역으로 아직 완전한 자연어 처리기가 개발되지는 않았지만, 인공지능 이외의 영역에도 부분적으로 활용되고 있다.

전문가시스템의 개발이 궁극적으로 성공적이기 위해서는 사용자의 요구사항을 정확하게 인식하고 이를 만족시키기 위한 적당한 인터페이스가 제공되어야 한다. 따라서 사용자 인터페이스를 설계할 때에는 사용자가 어떠한 부류에 속하는지를 우선적으로 고려하여야 한다. 사용자 유형의 분류는 대개 다음과 같이 정리할 수 있다.

• 지속적 사용자 혹은 일시적 사용자
• 컴퓨터에 대한 개념이 있는 사용자 혹은 문외한인 사용자
• 내부 사용자 혹은 외부 사용자
• 전문적 사용자 혹은 비전문적 사용자
• 대상 영역에 정통한 사용자 혹은 초보적 사용자

결국 개발하여야 할 인터페이스의 기능은 이와 같은 사용자의 타입에 따라 달라지게 된다. 즉, 사용자 인터페이스를 위한 기술의 선정 및 설계내용은 궁극적으로 최종사용자가 어떠한 사람인지와 개발을 위하여 책정된 자원에 따라 결정되어야 한다.

4.3  코딩 (Coding) 및 테스팅 (Testing) 단계

일단 설계작업이 완료되면 다음 단계는 설계대로 코딩을 하고 테스팅하는 과정을 거치게 된다. 이러한 코딩 및 테스팅은 오류가 없는 완전한 시스템이 될 때까지 계속적인 반복과정을 거치게 된다.

(1) 코딩 (Coding)

전문가시스템의 개발에 있어서 코딩과 관련된 주요 활동을 살펴보면 다음과 같다.

• 쉘 (추론기관) 의 코딩 혹은 설치
• 지식베이스의 코딩
• 사용자 인터페이스의 코딩
• 다른 시스템과의 연계부문의 코딩

일반적으로 코딩작업의 난이도에 영향을 미치는 요인으로는 소프트웨어를 자체개발하느냐 아니면 외부로부터 구매하느냐에 대한 의사결정뿐만 아니라, 사용자 인터페이스의 복잡성 정도는 어떠한가 혹은 다른 시스템과의 연계성 정도는 어떠한가 등을 들 수 있다. 여기서 소프트웨어를 소스코드로부터 자체 개발하거나 사용자 인터페이스의 설계내용이 매우 복잡한 경우에는 일반적인 정보시스템을 개발하는데 주로 사용되는 소프트웨어 공학적 절차와 기법을 최대한으로 활용함으로써 개발될 시스템의 품질과 소프트웨어의 일체성을 확보할 수 있다.

이에 비해 외부로부터 구매하는 경우에는 지식베이스의 코딩이 가장 힘든 문제로 제기된다. 특히 지식획득 단계에서 지식에 관한 문서화가 어느 정도 잘 되어 있느냐에 따라 코딩에 소요되는 노력이 달라지게 된다. 즉, 문서화가 잘 되어있는 경우 지식베이스의 코딩은 아주 쉽게 처리될 수 있다.

(2) 테스팅 (Testing)

전문가시스템의 개발에 있어서 테스팅의 대상이 되는 주요 항목들을 살펴보면 다음과 같다.

• 시스템 개발도구의 검증
• 지식 표현상의 문법적 오류 검증
• 전문가시스템의 절차 및 성과 검증
• 전문가시스템의 신뢰도 검증

① 시스템 개발도구의 검증
여기서 이야기하는 시스템 개발도구에는 자체개발품과 외부구매품이 모두 해당된다. 특히 자체개발품의 경우에는 더욱 철저한 검증작업이 요구된다. 그렇다고 해서 외부구매품의 경우 검증작업이 전혀 필요없는 것은 아니다. 외부구매품의 경우에는 이미 구매시점에서 시스템에서 제공되는 예제시스템이 있으면 이를 통하여 자신의 대상 영역에서 요구되는 특성을 해결할 수 있을 것인가를 검증하여야 한다. 만약 제공되는 예제시스템이 없을 경우에는 검증용으로 아주 간단한 시스템을 개발하여 사용하도록 해야 할 것이다. 이렇게 함으로써 대규모의 지식베이스를 구축하기 전에, 해당 시스템의 문제점을 사전에 파악하여 해결할 수 있을 것이다.

② 지식 표현상의 문법적 오류 검증
구축된 지식베이스는 우선 문법적 측면에서 검증과정을 거쳐야 한다. 이러한 문법적 오류는 시스템에 따라 제공되는 수도 있지만 그렇다고 해서 완전하게 오류를 찾아주는 것은 아니다. 따라서 개발자는 이러한 오류를 쉽게 발견하기 위한 방법을 강구하여야 한다. 대개 지식베이스가 크고 복잡해지면 오류를 찾는다는 것은 매우 어려워진다. 따라서 지식베이스를 구축할 때 보다 작은 단위로 잘 게 쪼개어서 각 단위별로 시스템을 구축하도록 하는 방법을 권하고자 한다. 기존의 정보시스템을 개발하는데 사용되는 모듈화의 원리가 여기서도 적용될 수 있다. 즉, 지식베이스를 모듈화함으로써 개발시점에서의 오류의 발견 및 수정을 용이하게 할 뿐만 아니라 사용단계에서의 유지보수 작업도 효율적으로 수행할 수 있게 된다.

③ 절차검증 및 성과 검증
이것은 개발된 전문가시스템을 전체적인 관점에서 검증하는 과정이다. 우선 성과 검증 (Validation) 이란 시스템의 성능을 다루는 평가의 한 부분으로 인식된다. 간단히 말하여, 성과 검증이란 올바른 시스템을 구축하였는가를 판단하는 것이다. 즉, 개발된 시스템이 받아들일 만한 정도의 의미있는 시스템인가를 확인하는 것이다. 이를 효과적으로 추진하기 위하여 현장테스트 Field Test) 를 수행하기도 한다. 이에 비해 절차 검증 (Verification) 이란 시스템을 올바르게 개발하였는가를 파악하는 과정이다. 이것 또한 평가의 한 부분으로 얼마나 정확하게 시스템을 구축하였는가를 검증하고자 하는 것이다. 결국 절차 검증은 개발된 시스템의 내부적인 측면에 초점이 맞추어지는 반면 성과 검증은 시스템의 외부적인 측면에 초점이 맞추어지는 것으로 생각할 수 있다.

④ 신뢰도 검증
전문가시스템이 사용자에게 정확한 해답을 제시할 수 있기 위해서는 이러한 시스템을 구성하고 있는 모든 하위시스템 (Subsystems) 들이 잘 설계되고 코딩되어야 한다. 즉, 시스템이 전체적으로 신뢰도가 높아야 한다. 전문가시스템의 신뢰도는 사용자들에게 얼마만큼 만족할 만하게 주어진 과업을 잘 수행하느냐의 정도에 달려 있다. 전문가시스템의 신뢰도에 영향을 미치는 항목을 대별해보면 다음과 같다.

• 소프트웨어 신뢰도
• 지식베이스 신뢰도
• 사용자 인터페이스 신뢰도

이론적인 관점에서 보면 전체적인 전문가시스템의 신뢰도는 이러한 세 개 구성요소들의 신뢰도를 각각 합산함으로써 구할 수 있을 것으로 생각된다. 우선 전문가시스템에서의 소프트웨어 신뢰도 측정을 위해서는 소프트웨어 공학에서 사용되는 일반적인 소프트웨어 신뢰도 측정방법을 활용할 수 있으며, 지식베이스의 신뢰도는 앞에서 설명되었던 절차 검증과 성과 검증 과정을 통하여 테스트될 수 있을 것이다. 마지막으로 사용자 인터페이스의 신뢰도를 측정하기 위해서 보통 현장에서 실제 시스템에 대한 사용자의 반응을 수집하는 방법을 활용하고 있으나, 이를 위한 체계적인 방법이 아직까지는 개발되지 않았다.

4.4  구현 단계

시스템에 대한 코딩과 테스팅이 완료되면 실행단계로 넘어가게 된다. 이러한 구현 단계는 시스템의 분석, 설계 및 개발단계에 못지 않게 중요한 단계로 전체적인 시스템의 성공여부에 결정적인 역할을 담당할 수도 있다. 구현 단계에서 고려되어야 할 사항은 다음과 같다.

• 사용자에 의한 시스템 수용 (Acceptance by the User)
• 사용자 교육 (User Training)
• 시스템 전환 (System Conversion)
• 문서화 (Documentation)

특히 구현 단계에서는 사용자의 적극적인 참여가 필수적이기 때문에, 상기 네 가지 항목 중에서도 사용자에 대한 신규시스템의 이해 및 교육은 매우 중요하다.

(1) 사용자에 의한 시스템 수용

새로운 시스템의 수용에 관한 문제는 기술적인 문제 이상의 행동론적이며 심리적인 문제로 연계된다. 대부분의 사용자들은 새로운 시스템에 대한 불안감과 저항감을 지니고 있어 아무리 잘 만들어진 시스템이라 하더라도 선뜻 받아들여지기는 어렵다. 따라서 개발될 시스템에 관한 분위기를 개발초기부터 꾸준하게 형성시켜 나가는 것이 사용자에 의한 시스템의 수용가능성을 높이는 방법이 될 수 있다. 이와 아울러 완전하게 개발된 시스템을 실제 사용자들에게 직접 보여줌 (Demonstration) 으로써 신규시스템에 대한 신뢰도를 향상시키는 것도 한 가지 방안이 될 수 있다.

(2) 사용자 교육

사용자로 하여금 새로운 시스템을 수용하도록 하기 위해서는 적절한 교육이 뒷받침되어야 한다. 시스템에 친숙해짐에 따라 그 시스템의 활용도는 높아지게 되기 때문이다. 그리고 특히 사용자가 지식의 유지보수까지 책임지게 되면 이러한 심도 깊은 교육의 필요성은 더욱 높아진다. 결국 사용자에 대한 교육 및 훈련은 성공적인 시스템 구현을 위해서는 핵심적인 요소로 인식되고 있다.

(3) 시스템 전환

사용자에 의한 시스템의 수용, 사용자에 대한 교육 및 훈련이 끝나면 바로 시스템 전환작업으로 넘어가게 된다. 일반적으로 시스템 전환을 위한 전략으로 다음과 같은 네 가지 형태를 사용하고 있는데 그 내용은 다음과 같다.

① 직접 전환 (Direct Conversion)
시스템에 오류가 없다는 것이 확인되면 어떤 날을 정해서 기존방식을 폐기시키고 새로운 시스템의 가동을 시작하는 방식이다. 이러한 전환방법은 고도의 위험을 내포하고 있으나 전환비용이 들지 않는다는 장점이 있다.

② 병행 전환 (Parallel Conversion)
일정기간 동안 기존방식과 새로운 시스템의 활용을 병행하는 방식이다. 기존방법을 없애기 전에 새로운 시스템이 기능상 하자가 없다는 것을 확인하기 위해서이다. 이러한 방법의 장점은 예기치 못한 오류로 인하여 야기되는 업무상의 혼란 및 경제적 손실을 최소화할 수 있다는 장점이다. 그러나 대신 상당히 비싼 대가를 치러야 한다.

③ 장소별 전환 (Pilot Conversion)
동일한 시스템이 여러 장소 혹은 부서에 도입되어야 할 경우에 우선 어느 한 곳에서 직접전환이나 병행전환을 통하여 시스템의 무결성을 확인한 뒤에 다른 곳에서도 도입하도록 하는 방식이다. 이 경우 최초의 실험대상이 되는 곳을 베타 테스트 혹은 파일럿 테스트 장소라고 한다.

④ 단계적 전환 (Phased Conversion)
버전 (Version) 별로 시스템을 도입하는 방식이다. 물론 버전 번호가 올라갈수록 시스템의 기능이 확장되고 성능이 보강된다. 이는 시스템이 개발되면서 개발되는 차례대로 운영에 들어가는 방식이라 할 수 있다.

(4) 문서화

시스템 구현 단계에는 문서화과정이 반드시 포함되어야 한다. 문서화를 통해서 사용자들의 교육을 원활하게 수행할 수 있을 뿐만 아니라 향후 시스템의 유지보수를 효율적으로 수행할 수 있게 된다. 문서화의 결과는 책자 형태로 만들어질 수도 있고 시스템에 온라인 (On-line) 형태로 만들어질 수도 있다. 그리고 문서화는 사용자가 어떠한 계층이냐에 따라 적합한 내용으로 구성되어야 한다. 즉 시스템의 유지보수자, 시스템 운영자 혹은 시스템의 최종사용자 각 계층에 적합한 문서화가 이루어져야 한다.

4.5  유지보수 단계

시스템이 사용자들에 의해 활용되는 과정에서 수행되어야 할 몇 가지 활동이 있는데 이에는 시스템의 운영, 유지보수, 시스템의 확장, 평가 등이 포함된다.

(1) 시스템 운영 (Operation)

Prerau [5] 는 시스템 운영과 관련하여 다음과 같은 방식으로 추진되는 것이 바람직하다는 견해를 피력하고 있다. 시스템이 고객에 대한 서비스 차원에서 사용자들에게 활용되고 있을 경우에는 시스템 운영자그룹을 결성하여 배포된 시스템의 원활한 운영을 지원해야 한다. 그렇지 않고 조직 내의 사용자들에 의해 활용되는 경우에는 운영ㆍ훈련을 책임지는 그룹을 조직하여 운영상의 문제에 대처해 나가는 것이 바람직하다.

(2) 시스템 유지보수 (Maintenance)

시스템의 원활한 운영을 위해서는 장기적인 관점에서의 유지보수 전담팀을 구성하고 교육시켜야 한다. 이러한 유지보수팀의 역할은 시스템의 운영상의 기능하자를 수정하는 것 외에도, 시간의 흐름에 따라 환경의 변화에 적응하기 위하여 수정되어야 하는 데이터나 지식 등을 보수하는 일도 담당하게 된다. 이 경우 유지보수를 중앙의 한 곳에서만 담당하게 할 것인지 아니면 시스템을 나누어서 이러한 기능을 분산시킬 것인지를 명확하게 하여야 한다.

또한 전문가시스템이 다른 시스템의 일부로 운영되고 있는 경우에도 전문가시스템의 유지보수 업무를 전체시스템의 유지보수를 책임지고 있는 사람에게 맡길 것인지 아니면 전문가시스템 유지보수 전담자를 둘 것인지도 결정해야 할 사항 중의 하나이다.

(3) 시스템 확장 (Expansion)

전문가시스템은 일반적인 다른 정보시스템과는 달리 문제해결 능력면에서 계속적으로 기능이 향상되어 갈 수 있는 시스템이다. 이러한 현상은 기존의 낡고 가치없는 지식은 폐기시키고 새로운 지식을 습득하도록 함으로써 가능해진다. 결국 지식베이스에 대한 유지보수 활동이 본 단계에서의 핵심적인 내용이 된다. 이러한 유지보수 활동은 유지보수 전담팀이나 최초개발팀에 의해 수행될 수 있다.

(4) 시스템 평가 (Evaluation)

일반적으로 전문가시스템에 대해서는 6 개월 혹은 1 년 단위로 정기적으로 평가하는 것이 바람직하다. 이러한 평가작업에는 다음과 같은 내용이 정리되는 것이 바람직하다.

• 시스템을 유지보수함으로써 얻을 수 있는 혜택과 이에 소요되는 비용과의 비교
• 새로운 지식을 반영하는데 있어 유지보수 작업만으로 충분히 가능한가?

이러한 항목들의 주기적인 평가는 앞으로도 계속 유지보수에 의해 시스템을 운영해 나갈 것인지 아니면 새로운 시스템의 개발로 나갈 것인지를 결정하는 기준이 된다.