[지디넷코리아]시스템을 개발하고 운영한다는 것은 사용자가 본인이 맡은 업무에 대한 전문성만큼 시스템 개발과 운영에 대한 지식이 부족하기 때문에 태어날 수 있었던 직업 또는 직무이다. 이런 사용자의 업무에 대한 전문성을 인정하면서 정보시스템 구축과 관련한 사용자의 비전문성을 이해해야 시스템에 대한 명확한 요구사항을 얻어낼 수 있다.

하지만 대부분의 시스템은 개개인의 업무에 국한된 지원이 아닌 업무가 상이한 사용자간의 업무 흐름을 파악해내야 하고, 사용자의 권한, 위치에 따라 다른 정보를 제공할 수도 있어야 한다. 사용자는 소프트웨어를 개발하는 능력만 부족한 것이 아니라 본인의 업무를 표현하고 모델링하는 능력 또한 부족하다. 사용자, 바꾸어 말하면 최고의 업무 전문가를 앞에 두고 시스템 구축에 필요한 업무 정보를 얻어내고 이 정보들을 모델링하고 조직화할 수 있는 능력은 개발자의 몫이지 사용자에게 요구할 대상이 아닌 것이다.

<표1> IDEFO 다이어그램 프로그램

프로그램명 제작사 특징 BPWin(현재명칭은 Process Modeler) 컴퓨터 어소씨에이츠(www.CA.com) ERWin 연계기능 AI WIN7 Knowledge Based Systems Inc(www.kbsi.com) 비지오연동, SVG, XML 저장 등의 기능 지원 SA(System Architect) POPKIN Software(www.popkin.com) 통합 CASE 도구로 일련의 IDEF 다이어그램 모델링 지원 비지오 마이크로소프트(www.microsoft.com) 다이어그램 작성 차원의 IDEFO 다이어그램 작성 가능 스마트드로우 스마트드로우(www.smartdraw.com) IDEFO-IDEF4(객체지향 분석)에 이르는 IDEF 방법론의 다이어그램 작성 가능

사용자로부터 업무 흐름에 대한 설명이나 이에 따르는 요구사항을 들을 수 있다는 것은 하나의 능력이다. 모든 이에게 친근감을 주는 사람일지라도 학창시절 엄청 싫어하던 아무개와 닮았다는 이유 하나로 특정 사용자로부터 필요한 정보를 얻는데 곤란을 겪거나 그 반대로 재능과 전혀 무관한 학연, 지연 등에 의해 ‘일사천리+알파’로 사용자로부터 정보를 얻어내는 경우가 종종 있다. 이번 글을 통해 이야기하고자 하는 영역은 이런 심리학의 영역으로 다뤄져야 할 부분이 아닌 어디까지나 공학적인 접근을 통해 개별 업무와 업무 내부의 흐름, 외부 요소들, 업무들 간의 관계 등을 파악해 내고 이를 조직화하는 대표적인 방법과 이를 지원하는 도구에 대한 것이다.

아울러 UML을 표기 도구로 사용하는 RUP를 비롯한 많은 방법론들은 일반적으로 ‘4+1’이라고 불리는 영역(뷰)을 제시하고 있다. ‘+1’에 해당하는 것은 분석의 시작점이라 할 수 있는 유스케이스 뷰를 의미하며 ’4‘에 해당하는 영역은 논리적 뷰(Logical View), 구현 뷰(Implementation View), 프로세스 뷰(Process View), 배치 뷰(Deployment View)로 전통적인 비즈니스 프로세스와 시스템 프로세스의 구분과 달리 4개 영역에 대해 각각의 프로세스(UML의 프로세스 뷰가 아닌)를 도출해 낼 수 있도록 하고 있다. 4개 영역 모두에 대해 시퀀스, 상태 다이어그램 등 입출력과 흐름을 표시하는 다이어그램을 반드시 만들어 낼 필요가 없는 경우도 고려하고 있는 것이 일반적이다.

<그림 1> RUP의 4+1 뷰

원칙적으로 이러한 작업들은 요구사항 도출과 병행되거나 이후에 이를 조직화하는 시스템 개발의 흐름 중 ‘분석’ 영역의 업무이나 경우에 따라서는 전산시스템 구축 이전에 BPR이나 ISP 등을 통해 또는 전산시스템 구축의 타당성을 입증하기 위한 단계에서 수행되기도 한다. 한명의 사용자가 시스템을 유용하다고 판단하는 기준은 화려한 그래픽, 빠른 반응 속도, 편리한 입출력, 멋진 보고서 등 다양하겠지만 시스템을 사용하는 모든 사용자가 시스템을 유용하다고 느낄 수 있는 첫 번째 조건은 얼마나 개별 업무를 잘 지원하고, 개별 업무들이 잘 조직화되어 있는가 하는 것이다. 이를 바꾸어 말하면 실무의 비즈니스 프로세스를 가장 자연스럽게 시스템에 담아내는 것이 될 것이고 이의 시작이 비즈니스 프로세스를 분석하고 모델링하는 작업이 될 것이다.

비즈니스 프로세스와 시스템 프로세스
시스템 개발 과정에 있어서 ‘프로세스’라는 용어가 적용되는 부분은 크게 업무 흐름에 대한 비즈니스 프로세스와 화면, 모듈 단위의 프로그램 내부 흐름에 대한 시스템 프로세스로 나누어 볼 수 있다. 프로세스는 사전적으로는 외부로부터 입력을 받아 출력을 만들어 내는 ‘처리’를 의미하지만 이러한 입출력 못지않게 주목해야 하는 부분이 그 처리 과정 내부의 ‘흐름’이다.

이런 이유로 프로세스를 도식화하는 방법은 기본적으로 플로우 차트 구조를 가지고 선행 후행의 과정과 예외 상황을 구분하는 것들이 대부분이고, 간단하게 박스와 화살표로 구성되는 플로우 차트부터 IDEF0, IDEF3 등의 구조적인 분석 방법에 사용되는 다이어그램과 UML의 시퀀스, 상태 다이어그램 등에 이르기까지 그 표기법은 다르지만 처리와 흐름, 그리고 예외라는 다이어그램이 담고 있는 정보는 대동소이하다 할 수 있다. 물론 UML의 경우 다이어그램간의 관계도 고려하고 있기 때문에 앞서 언급한 정보보다 더 많은 정보를 내재하고 있을 수 있다.

공장의 프로세스를 소프트웨어에도
밀가루와 물, 계란 등을 섞어 빵을 만드는 공장의 기계들을 생각해 보자. 밀가루를 비롯한 재료들을 반죽하는 기계, 이를 정해진 모양으로 빚는 기계, 다시 이를 구워내는 기계, 구워진 빵을 포장하는 기계 등이 공장 안에 자리잡고 있을 것이며, 공장을 놓고 보면 각종 재료와 포장 재 등을 입력받아 잘 구워져 예쁘게 포장된 빵을 출력하는 기능을 수행한다. 또 공장 내부의 프로세스를 보면 반죽 기계의 출력물인 빵 반죽이 모양을 빚는 기계에 입력되며, 이 기계의 출력은 빵을 굽는 기계에 입력되는 것과 같은 내부 흐름이 존재한다. 또 공장 차원에서 소요되는 수선유지비, 수도광열비 등을 포함하는 전체 입력과 공장의 출력에 해당하는 빵의 수량을 비교해 보면 빵의 원가를 알 수 있게 된다.

눈에 보이는 입력과 출력에 기초하는 프로세스의 경우 예를 든 것과 같이 프로세스뿐 아니라 상위 프로세스를 구성하는 단위 프로세스와 이를 구성하는 마이크로프로세스까지도 비교적 명확하게 모델링할 수 있다. 이렇듯 명확하게 프로세스를 도출해 낼 수 있는 대상에 적용되는 방법을 소프트웨어를 개발하고 이를 사용하는 과정과 같이 가시적이지 못한 업무에 적용해 보고자 하는 발상이 있었고 이러한 발상의 결과는 비교적 성공적인, 바꾸어 말하면 유용한 도구로 여겨지고 있다.

대표적인 도구로는 IDEF(ICAM Definition) 방법론의 다이어그램을 뽑을 수 있다. 또 데이터의 입력과 출력을 대상으로 프로세스를 분석하는 DFD(Data Flow Diagram) 또한 큰 맥락에서 프로세스를 분석하는 도구로 볼 수 있다. IDEF는 1980년대 초 미국 공군에 의해 시스템을 기능, 정보, 동적 관점에서 모델링하기 위한 방법론으로 개발되었고 기능 모형을 모델링하기 위한 IDEF0, 시스템 내부의 데이터 흐름을 표현하는 IDEF1X 시스템의 작동 방식을 표현하는 IDEF3 등이 널리 알려져 있다. IDEF1X의 경우 ERD(Entity Relationship Diagram)를 그리는 표준의 하나로 정보공학(Information Engineering) 표기법과 함께 가장 많이 접할 수 있는 ERD 표기법이기도 하다.

PWin으로 모델링하는 프로세스
IDEF0, IDEF3 등의 다이어그램과 DFD를 포함한 모델링을 지원하는 도구로 많은 사용자 층을 확보하고 있는 도구가 CA의 BPWin이다. 현재의 정식 제품명은 Process Modeler이지만 워낙 BPWin이라는 이름으로 알려져 있으므로 기사에서는 BPWin이라는 이름을 사용하겠다. 프로세스 모델링 기능 외에 자사의 ERWin 같은 도구와 연계해 다양한 영역의 분석이 가능한 도구이기도 하다. 먼저 IDEF0 다이어그램을 이용해 업무의 기능적 측면을 분석해 가는 과정을 살펴보자.

IDEF0 모델링 방법
IDEF0 다이어그램에 사용되는 기호는 단지 두 개 뿐이다. 사각형 박스(activity)로 표현되는 활동과 활동 간의 관계, 기능 및 제약사항을 설명하는 화살표(concept) 이 두 개의 그래픽 요소를 규칙에 맞게 사용하는 것으로 다양한 의미를 부여할 수 있게 된다. 각각의 박스는 A0과 같이 0이라는 최상위 레벨을 표현하는 다이어그램부터 A1, A2와 같은 세부 프로세스로 나누어지며 이는 다시 A1.1, A1.2와 같은 세부 프로세스로 분할되어 가며 원하는 수준까지의 모델링을 수행하게 된다. 적당한 수준이라는 표현을 바꾸어 말하면 모델링을 원하는 목적에 부합되는 수준이라 할 수 있다.

앞서 반죽을 하는 기계의 경우 해당 기계의 구성요소를 분해해 전원장치, 모터 등의 동작을 설명하는 수준까지 세분하여 정보를 얻는 것이 목적은 아닐 것이다. 배경도(conceptual diagram)부터 시작하는 세분화된 DFD를 그려 본 독자라면 트리 구조로 분해되는 모델링 구조를 쉽게 이해할 수 있을 것이다.

사각형 박스로 표현되는 활동의 의미는 활동, 프로세스, 운용, 변환 등 미묘한 차이를 가진 다양한 의미를 가질 수 있으나 기사에서는 이를 프로세스로 호칭하겠다. 다이어그램을 구성하는 그래픽 요소 중 남은 하나인 화살표는 위치에 따라 다양한 의미가 부여되게 된다. 좌측에서부터 프로세스 박스의 좌측으로 들어오는 화살표는 해당 프로세스의 입력이 되며 프로세스 박스의 우측에서부터 시작해 우측으로 나가는 화살표는 출력을, 위에서 내려와 프로세스 박스의 상단으로 들어오는 화살표는 해당 프로세스의 통제·제어, 아래 방향에서 프로세스 박스의 아래쪽으로 연결되는 화살표는 해당 프로세스에서 사용하는 메커니즘을 의미한다. 이를 ICOM이라 불린다.

<화면1>제빵프로세스의 최상위 레벨 다이어그램		<화면2> 제빵과정을 1차적으로 세분화한 예

<화면 1>을 보면 우선 밀가루와 기타 재료를 입력받아 ‘맛있는 빵’을 만들어 내는 최상위의 다이어그램임을 쉽게 이해할 수 있을 것이다. 집에서 빵을 만든다면 모르지만 시판하는 제품으로서의 빵이기 때문에 식품위생법 등 법적인 제약을 받게 된다. 간단하게 프로세스 내부에서 어떠한 분기를 생성하는 조건부터 법령, 기업 목표 등 외부의 제약을 포함한 제약 조건이 컨트롤로 표현된다.

또 프로세스에서 사용하는 메커니즘으로 반죽기, 오븐 등의 기계와 제빵사 등의 인력 자원까지를 메커니즘으로 표현할 수 있을 것이다. 아무리 많은 재료가 들어온다고 하더라도 장비와 인력의 여유가 없다면 이를 가공할 수 없을 것이다. 이렇게 보면 장비의 여유, 인력의 여유는 메커니즘이라기보다 제약사항으로 표현될 수도 있을 것이다.

IDEF0 다이어그램을 그리는 원칙 중 하나가 메커니즘인지 컨트롤인지 애매모호한 경우는 컨트롤로 파악하라는 것이다. 경우에 따라서는 아래 방향에서 들어오는 화살표는 하나도 없는 다이어그램이 생성될 수도 있을 것이다. 원칙적으로 상위 다이어그램에 표시된 ICOM 화살표는 반드시 하위 다이어그램의 어느 프로세스인가에 연결돼야 한다.

역으로 하위 다이어그램의 세세한 정보를 다루는 ICOM 화살표들을 굳이 상위 다이어그램에 다 표시할 필요는 없다. 화면에서 사용되지 않거나 굳이 표현할 필요가 없는 ICOM 화살표들은 터널링을 표시해 최상위 레벨에서는 표현되었으나 중간 레벨에서는 화면 표시를 생략하고 이를 사용하는 최하위 프로세스를 포함한 다이어그램에만 나타낼 수도 있다.

세부 프로세스의 모델링
BPWin을 사용하여 IDEF0 다이어그램을 그릴 때 경우에 따라 하위 프로세스를 IDEF0 외에 IDEF3 또는 DFD 다이어그램을 선택할 수 있다. 하위 프로세스가 작동(process flow)에 관심을 두는지 데이터의 흐름에 관심을 두는지에 따라서 원하는 형태의 다이어그램을 선택할 수 있다. IDEF0의 경우 하위 다이어그램을 다른 형태로 작성할 수 있지만 IDEF3과 DFD의 경우는 동일한 형태의 다이어그램만을 하부 다이어그램으로 작성할 수 있다. DFD만을 그리는 경우에 DFD 배경도로부터 프로세스의 세분과 IDEF0의 프로세스 세분 과정이 동일하거나 상당 부분 유사하므로 IDEF0으로 프로세스를 분석해 나간 뒤 필요한 수준에서부터 하위 프로세스의 DFD만을 작성하는 방법도 BPWin을 이용하는 경우라면 가능하다.

IDEF3 다이어그램의 경우 IDEF0의 ICOM들이 객체로 변환된다. IDEF3 다이어그램은 프로세스간의 전후·인과 관계를 파악할 수 있는 도구로 크게 이들 간의 흐름을 위주로 표기하는 방법과 객체가 갖는 상태(behavior) 변화를 위주로 표기하는 방법이 있다. BPWin에서 지원되는 기능은 주로 전자를 구현한 것으로 프로그램 내부적으로는 IDEF0은 비즈니스 프로세스, IDEF3은 프로세스 플로우라는 명칭을 부여하고 있다. 상태 변화를 위주로 표현하는 경우는 UML의 상태 다이어그램과 유사한 정보를 제공한다.

<화면2>IDEF3에 기반한 스웜레인 다이어그램

BPWin의 기타 기능
BPWin과 데이터베이스 분석 설계 도구인 ERWin은 두 개의 EXE 파일을 갖는 하나의 프로그램으로 봐도 될 정도로 연계가 잘 이루어진다. BPWin 기능 중 하나가 DFD를 그리는 기능이므로 DFD와 ERD를 주축으로 하는 프로세스와 엔티티간의 관계를 설명하는 CRUD(Create, Read, Update, Delete) 매트릭스와 같은 도표들도 이 둘을 연계해 생성할 수 있으며, DFD의 분석 결과를 토대로 엔티티를 파악하는 업무도 이 둘의 연계를 통해 가능하다. 또한 BPWin 내부에 시스템과 연관한 조직도를 그리는 기능이 포함되어 있고, 프로세스를 특정 역할에 따라 나누어 배치해 볼 수 있는 스윔레인(Swimlane) 다이어그램 작성 기능을 제공하므로 대규모 시스템 분석에 필요한 지역별 엔티티 매트릭스, 지역별 프로세스 매트릭스, 부서별 엔티티 매트릭스, 부서별 프로세스 매트릭스 등도 이를 이용해 작성할 수 있다.

또한 프로세스, ICOM 등 BPWin의 다이어그램을 구성하는 요소들을 구분에 따라 표 형태로 변환해 저장하는 익스포트 기능이 포함되어 있어 필요시 이를 기반으로 앞서 언급한 작업들을 엑셀 등에서 수행하거나 세세한 자료사전(data dictionary) 등을 작성하는 기초 자료로 활용할 수도 있다. 서두에 언급한 빵 가격의 계산과 같은 공정에 따른 비용 계산도 당연히 지원된다. 또한 변경관리 등을 위한 정보들도 템플릿화해 사용할 수 있도록 제공하고 있다.

처음에는 다소 어색한 그래픽 기능
주변에 BPWin을 소개할 때 사용자들이 프로그램에 대해서 어색해 하는 부분이 바로 BPWin의 그리기 방식과 복사 기능이다. 박스 형태의 프로세스를 배치하는 경우라면 큰 차이가 없으나 화살표를 그리는 경우 여타 그래픽 프로그램에서 이루어지는 동작과 BPWin의 그것이 다르기 때문이다.

MS의 오피스 제품군을 예로 들면 원하는 시작점을 클릭하고, 드래그하여 화살표가 끝나는 점에서 마우스 버튼을 놓아주면 선이 그어지는 클릭-드래그-릴리즈 방식으로 마우스가 드래그되는 동안 시작점과 마우스의 끝을 잇는 선이 화면에 나타나게 된다. 하지만 BPWin의 경우 화살표 그리기를 선택하고 화면의 상하좌우 IDEF0 프로세스 박스의 상하좌우 영역에 마우스를 가져가면 해당 영역이 검은색으로 반전된다. 이때 먼저 클릭한 영역이 시작, 나중에 클릭한 부분이 끝점이 되는 ‘시작점 클릭-끝점 클릭’이라는 두 번의 클릭을 필요로 한다. 화살표와 화살표를 잇는 경우도 마찬가지이다.

또 다이어그램의 특정 부분을 그림처럼 복사하고자 하는 경우 원하는 형태로 복사되지 않는 경우가 대부분이다. BPWin은 복잡한 관계를 포함하는 모델을 보여주고 있는 것이지 그림을 보여주고 있는 것이 아니기 때문에 일견 당연한 결과일 수 있다. BPWin의 FEO(For Exposition Only) 기능을 이용하면 본래의 흐름과 다른 시나리오를 적용할 수 있으므로 원하는 형태로 복사해 사용할 수 없다는 생각이 들면 FEO 기능을 살펴보기 바란다.

비즈니스 프로세스의 중요성
최근 비즈니스 프로세스라는 용어가 범람 직전이라 할 만큼 많이 사용되고 있다. BPR, BPML, BPEL 등 대상으로 하는 시각과 목적이 다를지라도 하나같이 비즈니스 프로세스의 흐름과 나아가 전사적 차원에서의 연계까지 이를 강조하는 이야기들뿐이다. IDEF0으로 비즈니스 프로세스를 표현하는 방법이 모든 경우에 최고, 최상의 방법이 되지는 않을 것이다. UML을 이용해 이러한 작업을 수행할 수도 있으며, XML 기반인 BPML 도구를 이용해 그래픽하게 이를 분석해내고 시스템 레벨의 흐름까지 한번에 파악해낼 수도 있을 것이다. 중요한 것은 사용자가 이에 대한 정보를 제대로 전해주지 못한다는 변명보다 이의 분석이 엄연히 개발자의 몫임을 인정하는 태도일 것이라 생각한다. @