백줄 글보다 낫다「다이어그램 작성 프로그램」

소프트웨어 개발이 어려운 이유 중 하나가 소프트웨어 자체와 그 개발 과정이 가시적이지 못하기 때문이다. 개발 진행이 소프트웨어 개발과 유사하다고 이야기하는 건축의 경우에도 시간이 흐르면 한 층 한 층 올라가는 건물을 볼 수 있다. 심지어 눈에 보이지 않는 전류의 흐름을 이용하는 전자제품의 경우에도 눈에 보이는 무언가를 개발 중에 볼 수 있다. 하지만 소프트웨어의 경우는 그 결과물조차 눈에 보이지 않고 컴퓨터 상에서 동작하는 논리적 결합물일 뿐이고, 이의 개발이 진행되는 동안에는 이 불가시성에 불확실성이 더해지기 마련이다.

보다 원론적으로 건축 전문가들은 모델하우스조차 없는 상황에서 설계도라는 모델만을 가지고 의사를 전달하기도 한다. 소프트웨어 개발에 있어서도 사용자와 개발자간에, 업무 전문가와 개발자간에, 개발자와 개발자간에 정보 전달의 도구로 이런 모델들을 사용할 수 있을 것이다. 실제로 소프트웨어 개발을 위한 수많은 모델들이 개발되었고, 개발되고 있는 상황이다. 하지만 모든 개발자가 제도판과 삼각자를 이용한 모델 작성에 익숙한 것은 아니다. 개발자에게 가장 친숙하고 가까이 있는 도구가 바로 컴퓨터이고 컴퓨터에 이러한 모델링이 가능하도록 능력을 더해주는 소프트웨어가 개발자의 제도판 역할을 해줄 것이다.

먼저 노파심에서 앞서와 같이 모델을 작성하는 경우 건축을 위해 반드시 필요한 설계도에 해당하는 모델과 사용자의 이해를 돕기 위해 작성하는 모델하우스에 해당하는 경우 모두 이의 비용이 공사비에 포함되고 이는 입주자(사용자)가 부담해야 하는 비용이라는 점을 이야기한다. 개발 중에 사용자에게 전달하는 문서의 저작 비용은 무료가 아니라는 점을 꼭 기억하자.

소프트웨어 개발의 경우 이러한 모델에도 건축의 경우와는 또 다른 제약이 존재한다. 실제 물리적 동작을 수행하는 모델보다는 다이어그램의 형태로 작성되는 논리적 모델이 대부분이라는 점이다. 건축을 위한 논리적 모델인 설계도를 누구나 이해하지는 못할 것이다. 마찬가지로 소프트웨어를 가시화해 주는 여러 다이어그램 또한 이를 이해하기 위한 사전 지식을 필요로 한다.특히 일정 수준 교육이 되어 있는 개발자라는 전문가 집단 내부에서 사용되는 다이어그램과 달리 사용자와의 의사소통시 사용되는 다이어그램의 경우에는 비전문가도 알아볼 수 있도록 쉬워야 한다는 필요성도 존재한다.

반면에 ‘동일하거나 유사한 정보를 전달하는 데 이 방법이 답이다’라고 말할 수 있는 방법은 존재하지 않는다. 비교적 최근에 소개된 UML보다 전통적인 플로우차트가 더 유용할 수도 있으며, 경우에 따라서는 정보를 축약한 다이어그램보다 풀어써 놓은 문장이 더 나을 수도 있다. 이렇게 읽기 편한 다이어그램을 작성하기 위한 노력은 경험과 사용자에 대한 이해, 방법론과 다이어그램 자체에 대한 이해, 나아가 인지과학의 영역까지 이야기되어야 할지 모른다. 이번 글은 읽기 편한 다이어그램의 작성이라는 광범위한 주제가 아니라 보다 편하게 다이어그램을 만들 수 있는 소프트웨어들을 살펴보는 것이 목적임을 미리 밝힌다.

비주얼 개발자
어찌 보면 현재의 소프트웨어 개발자는 프로그래밍 언어보다 다양한 다이어그램을 능숙하게 그려낼 수 있는 능력을 갖추어야 할 것으로 보인다. 데이터베이스를 표현하는 ERD, ORM 등의 다이어그램과 네트워크 구성도, 하드웨어 구성도, UML 다이어그램 등 개발자가 전문가로 인정받는 영역뿐 아니라, 일정 관리를 위한 Gannt, PERT/CPM 차트, 비용 산정을 위한 IDEF3, 워크플로우 다이어그램 등 관리 영역, 심지어 프로그램이 속한 업무 영역에 해당하는 다이어그램까지 이해하고 있어야 하며 게다가 사용자 인터페이스의 절반 이상은 개발자의 몫이기도 하다.

소프트웨어와 이의 개발 과정을 가시화하기 어렵다는 난제를 해결하기 위한 노력이 축적된 결과 개발자는 프로그래밍 언어를 능숙하게 다루는 것은 기본이요 남들보다 뛰어난 가시화 능력을 지니고 있어야 한다. 눈으로 들어오는 정보에 남들보다 민감하고 까다로워야 하는 것이 소프트웨어 개발자이고 이 눈높이에 맞추어 남들이 쉽게 알아볼 수 있는-비주얼하다고 표현되는 결과물을 만들 수 있어야 개발자인 셈이다.

이들 중 현재 보편적으로 개발자가 작성할 줄 알아야 하고 읽을 줄 알아야 한다고 여겨지는 UML과 DFD, ERD의 작성이 가능한 프로그램들을 살펴보려 한다. 최근의 CASE(Computer Aided Software Engineering) 도구들은 대부분 이러한 다이어그램의 작성을 지원한다. 글에서 살펴보고자 하는 프로그램들은 CASE라기보다는 소프트웨어와 무관한 다이어그램들을 작성하면서 소프트웨어 관련 다이어그램을 작성할 수도 있는, 어찌 보면 범용 그래픽 프로그램에 해당하는 프로그램이 더 정확한 표현이 될 것이다.

오피스의 핵심으로 떠오른 ‘비지오’
먼저 가장 지명도 높은 다이어그램 작성 프로그램인 비지오를 살펴보자. 비지오의 경우 간단한 제도, 비즈니스 다이어그램, 소프트웨어 다이어그램 영역에서는 명품으로 인정받는 소프트웨어로, 마이크로소프트가 원 제작사를 인수해 오피스 추가 제품군에 포함시킨 제품이다.

앞서 기사에서 살펴볼 프로그램들이 범용 그래픽 소프트웨어로 볼 수 있다는 이야기를 했었다. 비지오 또한 범용 제품이다. 감사, 워크플로우, 업무 흐름도, 조직도 등의 비즈니스 다이어그램과 전기 회로, 사무실 배치도 등의 제도 기능, 그리고 UML을 포함하는 소프트웨어 다이어그램까지 미리 작성된 다양한 스텐실(비지오 전용의 클립아트라 볼 수 있다)을 이용해 드래그 앤 드롭 방식으로 작성할 수 있다. 아울러 원하는 스텐실이 없을 경우에는 얼마든지 새로운 요소를 작성하고 재사용할 수 있는 범용성을 갖추고 있다.

얼핏 생각하면 객체지향 개발을 한다면 비지오의 UML 기능만을 사용하게 될 것 같지만 실제 분석과 설계 단계에서는 소프트웨어 다이어그램에 못지않게 비즈니스 영역의 다이어그램을 이용하게 된다. 일례로 전사적 차원의 개발이 진행된다면 조직 내외의 업무 흐름과 조직 체계를 분석해야만 제대로 된 업무용 소프트웨어를 만들 수 있으니 조직도와 업무 흐름도 등이 요긴하게 사용될 것이다. 이런 시각에서 편의상 비즈니스 다이어그램, 소프트웨어 다이어그램, 기타 다이어그램으로 분류해 먼저 비지오(2003 기준)가 직접적으로 지원하는 소프트웨어 개발 관련 다이어그램을 분류해 살펴보겠다.

<화면 1> 비지오의 사무공정 분류의 다이어그램 선택 화면

업무를 모델링하는 비즈니스 다이어그램
솔직히 ‘이것은 비즈니스 다이어그램에 속한다’라고 정의하는 것은 필자의 능력을 벗어난 일이라 생각한다. 공장자동화를 위한 소프트웨어라면 조직도보다 전기, 배관 등을 포함하는 공정도가 더 유용할 것이다. 주관적인 판단으로 경영학의 냄새가 풍기고 개발의 여러 단계 중 분석 단계에서 업무를 살펴보고 이를 정리할 때 유용하리라 생각하는 다이어그램들을 이 분류에 포함해 보았다.

먼저 비지오는 조직도의 작성을 지원한다. 결과물은 박스로 표시된 부서와 부서원 그리고 이를 이어주는 선으로 구성되지만 원래 조직도라는 것이 조직의 크기에 따라 양적인 차이가 있을 뿐 복잡한 다이어그램은 아닐 것이다. 하지만 그 유용성은 여타 다이어그램에 못지않을 것이다. 이러한 이유에서인지 비지오에서는 조직도가 별도의 다이어그램 범주로 분리되어 있다.

다음으로 사무공정에 해당하는 다이어그램들로 감사 다이어그램, 결함의 체계적 분석 다이어그램, 기본 순서도, 데이터 흐름도(DFD : Data Flow Diagram), 부서간 업무 흐름도, 워크플로우 다이어그램, 인과관계 다이어그램, EPC(Event-Process Chain) 다이어그램, TQM(Total Quality Management) 다이어그램 등의 작성이 지원되며 이들 다이어그램은 사무공정으로 분류되어 있다. 사무를 지원하는 프로그램을 작성하기 위해서는 이러한 다이어그램을 통한 업무 분석이 필요하다는 반증이 될 것이다. 얼핏 DFD는 소프트웨어 다이어그램이고 다른 다이어그램도 제각각의 특성을 지니고 있는 듯한데 이러한 다이어그램들을 사무공정이라는 분류 아래로 모은 이유가 무엇일까? 그 해답은 이 다이어그램들이 6-시그마, ISO-9000에서 사용되는 필수 프로세스들이라는 점이다. 바로 사무공정의 품질을 위해 분석한 정보들을 담는 모델들인 것이다. 보다 나은 품질의 소프트웨어 개발을 위해서는 보다 나은 사무공정의 분석이 필요하고 이 다이어그램들이 이러한 역할을 수행한다.

소프트웨어 설계도 소프트웨어 다이어그램
이제 소프트웨어의 개발 과정에서 목표 소프트웨어를 모델링하기 위해 사용되는 다이어그램들을 살펴보자. 비지오의 경우 MS의 제품답게 COM, OLE 등 자체 기술을 지원하는 모델들이 적지 않게 포함되어 있다. 먼저 데이터 흐름도를 지원한다. 앞서 비즈니스 다이어그램에 포함된 데이터 흐름도의 경우 동그라미와 굽은 화살표로 구성되는 YourDon-DeMarco 표기법의 데이터 흐름도이고, 소프트웨어 다이어그램 분류에 포함된 데이터 흐름도는 Gane-Sarson 표기법의 데이터 흐름도이다. 표기법의 이름은 모두 이를 개발한 사람의 이름이다. 이 둘의 작성법은 유사하나 최근의 CASE 도구나 서적 등에서는 Gane-Sarson 표기법을 사용하는 경우가 많아 보인다.

다음으로는 엔터프라이즈 응용 프로그램 다이어그램이다. 기업의 업무 시스템은 단순히 클라이언트 상에서만 동작하는 프로그램이 아니라 데이터 서버, 미들웨어, 웹 서버, 프록시, 웹 클라이언트, 클라이언트 등 다양한 계층(Tier)으로 구분된 하드웨어 및 소프트웨어들이 네트워크를 통한 유기적 결합 위에서 동작하는 경우가 대부분이다. 이러한 전체 시스템 구성도를 작성할 수 있도록 제공된 템플릿이 엔터프라이즈 응용 프로그램 다이어그램이다.

프로그램 내부의 흐름을 모델링하는 경우 프로그램 구조 다이어그램을 사용한다. 스택, 배열, 힙 등 메모리 구조와 스위치, 호출, 데이터 흐름, 함수 등 언어를 구조화시킨 다이어그램을 작성할 수 있다. 비슷한 용도로 사용할 수 있는 N-S(Nassi-Shneiderman) 차트의 경우도 온라인에서 작성에 필요한 스텐실을 다운받을 수 있다. 소프트웨어 분류에는 이외에 COM과 OLE의 퍼블릭 인터페이스와 이의 호출 관계를 모델링할 수 있는 COM과 OLE 다이어그램, 데이터 구조를 모델링하는 Jackson 다이어그램(창안자의 이름이 마이클 잭슨이다. 가수 마이클 잭슨만큼 유명인사이다), 실시간 시스템 모델링에 사용되는 ROOM 다이어그램을 지원하며, 윈도우 XP 인터페이스를 모델링할 수 있는 스텐실을 제공한다.

소프트웨어 분류의 다이어그램 중 가장 강력한 기능을 맛볼 수 있는 부분이 UML 다이어그램이다. 다이어그램 작성 중 UML 스텐실을 여는 경우 단지 UML에 사용되는 스텐실들을 끌어놓기 할 수 있을 뿐이지만 시작부터 UML작성을 선택하고 다이어그램 작성을 시작하는 경우 CASE 도구로 변모한 비지오를 만날 수 있다. UML에 사용되는 표기, 제약 등이 자동으로 처리되고 다이어그램 구성 요소가 목록으로 만들어지며, 비주얼 베이직, 비주얼 C++ 코드의 포워드, 리버스 엔지니어링도 가능하다.

기타 소프트웨어 개발 관련 다이어그램
비지오에서 사무공정과 소프트웨어 분류 외의 분류에 나누어진 다이어그램들의 경우도 소프트웨어 개발과 무관한 다이어그램들은 아니다. 우선 네트워크 분류의 다이어그램들은 네트워크 장비의 구성과 연결, LDAP, 액티브 디렉토리 등 디렉토리 서비스의 구성을 표현할 수 있다. 다음으로 데이터베이스 분류에는 IDEF1x 표기법의 엔티티 관계도(ERD : Entity Relationship Diagram)와 스키마, 타임, 엔티티, 상수, 함수, 규칙을 요소로 작성되는 Express-G 다이어그램, 객체와 관계 데이터베이스를 모두 지원하고 이들간의 연결고리 역할을 수행할 수 있는 ORM(Object Role Model) 다이어그램이 포함되어 있다.

UML의 경우와 마찬가지로 시작부터 ERD 작성을 선택하고 다이어그램 작성을 시작한 경우 비지오는 ERD를 지원하는 CASE 도구 역할을 수행한다. 데이터베이스로부터 리버스 엔지니어링이 가능하고 변경된 결과를 포워드 엔지니어링으로 데이터베이스에 반영할 수 있다. 이때 데이터베이스의 연결은 데이터베이스의 네이티브 드라이버가 아닌 ODBC, OLEDB를 사용해야 한다. 비주얼 스튜디오에 포함된 비지오 아키텍트 버전의 경우 ORM과 논리적 모델과 물리적 모델간의 자동 변환을 지원한다. 개념적 모델을 ORM으로 작성하고 이를 논리적, 물리적 ERD로 전개하는 것이 가능하다는 이야기이다. 객체지향 개발을 수행할 때 객체의 상태를 영속적으로 보관하는 장소로 관계 데이터베이스를 사용하는 경우 이들간의 불일치를 조정하기 위해 또 다른 ORM(Object-Relational Mapping)을 수행한다. ORM 다이어그램에서 표현되는 관계는 UML에서 사용되는 객체간의 관계를 완벽하게 지원하므로 객체와 관계 데이터베이스간의 맵핑을 수행하는 경우에도 ORM 다이어그램은 유용한 수단이 될 수 있다.

웹 다이어그램 분류의 웹 사이트 개념도와 맵의 경우 웹 사이트의 구성과 서버 구성을 표현할 수 있으며, 프로젝트 일정 분류의 Gannt 차트, PERT 차트 등은 프로젝트의 일정을 점검하고 진행 상태를 시각화하는 데 핵심적인 수단이 되어준다. 이들 일정 관련 차트의 경우 엑셀, 아웃룩, 프로젝트 등 MS 제품들과 연계가 가능하다.

<화면 2> 비지오의 다이어그램 갤러리

끌어놓기만 알면 어떤 다이어그램도 그릴 수 있다 - 스마트 드로우
그림을 편집하는 일이 주 업무인 사람이 포토샵은 필요 없고 자신은 모든 작업을 그림판에서 한다고 주장하는 경우는 없을 것이라 생각한다. ‘글에 능한 자는 붓을 가리지 않는다’라고 하지만 서예 전문가일수록 남들보다 좋은 붓을 가지게 되는 것이 당연한 현상이다. 파워포인트의 그리기 기능으로 못 그릴게 무어냐고 하면 할 말은 없지만 짧은 시간을 투자해 양질의 다이어그램을 작성하는 것이 전문 도구를 선택하는 이유가 될 것이다. 스마트드로우의 경우 비지오에서 작성 가능한 소프트웨어 관련 다이어그램의 대부분을 작성할 수 있다.

ERD나 UML 다이어그램을 작성하는 경우 규칙을 점검해주는 CASE 툴의 기능을 제공하지는 않지만 스마트드로우는 다이어그램을 보다 수월하고 보기 좋게 그릴 수 있게 해주는 전문 다이어그램 도구이다. 비지오와 비교해 특징적인 면은 홈페이지의 튜토리얼에서 확인할 수 있듯이 Catalyst, Fusion, SSADM 등의 방법론을 명시적으로 지원한다는 점이다. UML의 경우도 UML로 ‘Unified’되기 이전의 세 친구(three amigos)의 방법론에 사용되던 다이어그램을 지원한다.
구체적으로 Booch의 OOAD(Object Oriented Analysis and Design), Rumbaugh의 OMT(Object Modeling Technique), Jacobson의 OOSE(Object Oriented Software Engineering)가 이에 해당한다.

UML의 경우 Jacobson의 UseCase 다이어그램을 시발점으로 다이어그램의 작성이 이루어지는 것이 일반적이나 굳이 표준의 UML을 따르지 않고 객체지향 분석 설계를 수행하는 경우나 기존에 이러한 방법론들을 기준으로 작성된 다이어그램들을 재작성하는 경우 등에 이들 다이어그램들을 이용할 수 있을 것이다. 스마트드로우의 GUI 디자인 기능은 비지오를 뛰어넘는 기능들이 제공된다. 비지오의 최신 버전이 윈도우 XP 스타일의 UI를 그릴 수 있는 기능만을 제공하고 있으나 스마트드로우의 경우 매킨토시 UI와 웹 UI를 작성할 수 있는 기능을 제공하고 있다. 비지오의 경우 기본 지원 스텐실에서 빠져버린 N-S 차트의 경우도 스마트드로우의 소프트웨어 기본 심벌에 포함되어 있다.

스마트드로우에서 끌어놓기에 사용되는 클립아트들은 심벌이라 불리며 프로그램 설치시 심벌들을 설치하거나, 설치 후 필요로 하는 심벌을 선택한 경우에 해당 심벌만을 자동으로 설치하는 방식을 지원해 상대적으로 하드디스크의 공간을 많이 차지하는 심벌에 대한 배려를 담고 있기도 하다.

<화면 3> Dia를 이용한 UML 작성 화면		<화면 4> 스마트드로우 홈페이지의 N-S 차트 예제

Gnome판 비지오 Dia
비지오와 스마트드로우가 윈도우 기반의 프로그램이라면 Dia의 경우 Gnome이 동작하는 리눅스, 유닉스 등이 동작하는 환경을 기반으로 하는 프로그램이다. 프로젝트 공식 사이트에서 윈도우의 상업용 프로그램인 비지오와 같은 프로그램이라고 소개하고 있을 정도로 비지오에서 제공되는 기능과 동일하거나 유사한 기능들을 하나하나씩 추가해나가고 있는 프로젝트이다. 현재 버전 0.93이 최신판으로 아직 1.0 버전에 다다르지 않은 프로그램치고는 상당히 잘 알려진 프로그램이다. 윈도우에서 비지오 등으로 작업을 해본 사용자가 리눅스 등을 사용하는 경우의 답답함을 어느 수준 이상 해소해 준 프로그램이라고 할 수 있겠다.

상업용이 아니고 아직 1.0이라는 궤도에 오르지 않은 프로그램이다보니 비지오의 스텐실에 해당하는 셰이프들은 상대적으로 적은 편이다. UML과 ERD, 네트워크 다이어그램, 간단한 회로도, 기본적인 플로우차트가 현재 지원되는 셰이프들이다. Dia에서 작성된 다이어그램과 셰이프들은 XML 형태로 저장된다. 아울러 현재까지는 사용되고 있지 않으나 파이썬 스크립팅 기능을 포함하고 있어 비지오에서 VBA 기반으로 이루어지는 기능들을 구현할 수 있을 것으로 예상되며. 사용자 층이 넓어지면 이러한 XML + 파이썬 스크립팅을 통해 비지오의 CASE 도구 기능들도 구현될 것으로 기대해본다.

<화면 5> 스마트드로우의 피시본(fishbone)-인과 관계다이어그램

다이어그램에 대한 충분한 학습과 이해가 우선과제
안다고 생각하는 것보다는 말로써 이를 이야기하는 것이 어렵고, 말보다 글로써 이를 전하는 것이 어렵고, 남에게 이를 가르치는 것이 더 어렵다고 한다. 결국 무엇인가를 제대로 알았다고 표현하는 수준은 누군가에게 이를 가르칠 수 있어야 하는 수준이라는 생각을 해보게 된다. 이렇게 보면 다이어그램으로 무엇인가를 표현한다는 것은 글로써 전하는 것과 가르치는 수준에 걸쳐 있을 것이다. 글보다 축약되고 정리된 형태가 다이어그램이기 때문이다.

분명한 것은 다이어그램으로 무엇인가를 모델링한다는 수준은 해당 모델링 대상을 알고, 이를 말로 설명하는 수준을 넘어서 글로 정리할 수 있고, 이를 다시 다이어그램의 문법에 맞게 축약할 수 있는 수준일 것이라는 점이다. 이를 위해서는 모델링 대상의 이해만큼 다이어그램의 문법에 대한 학습과 이해가 선행돼야 할 것이다. 도구들은 일반적인 규칙에서 벗어나지 않는 다이어그램을 그릴 수 있는 도구이지 대상과 일치하는 정확한 모델을 그려주는 것은 아니라는 점을 기억하자. @