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

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

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

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

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

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

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

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

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

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

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

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

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

다음으로 사무공정에 해당하는 다이어그램들로 감사 다이어그램, 결함의 체계적 분석 다이어그램, 기본 순서도, 데이터 흐름도(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 제품들과 연계가 가능하다.

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

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 차트의 경우도 스마트드로우의 소프트웨어 기본 심벌에 포함되어 있다.

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

 

저는 기획할 때, 업무속도는 빠르지만 빠진게 많다는 말을 자주 들었었습니다. 그래서 기획서 버전이 하루에도 몇 번씩 업이 될 때가 있었죠. 결국 프린트용지를 수백장씩 소모하고 나서야 2-30페이지짜리 기획서가 하나 완성되곤 했습니다. 상당히 낭비가 심한 기획자였던 셈이죠. 이면지로 쓴다고 해도 계속 누적되는 이면지 속도를 도저히 따라잡을 수가 없었습니다. 참 난감한 추억…이었으면 좋겠습니다만 여전히 고쳐지지 않는 습관중 하나입니다. 특히 종이로 뽑아놓고 손에 잡고 봐야 틀린 부분이 눈에 뜨이는 성격인지라. 쩝.

이런 식으로 계속 빼먹고 고치는 걸 반복하다보니 주변의 평도 그렇지만 저도 제가 참 답답하더라구요. 뭐가 문제일까? 어떻게 하면 빠진 부분이 있는 문제있는 기획서를 만들지 않게 될 것인가? 이 것이 항상 저에게는 고민거리였습니다.

그러다가 UML이라는걸 접하게 되었고, 유즈케이스라는걸 접하게 되었죠. 이 것들을 지금도 잘 알고있지는 않지만, 이 것이 빼먹지 않고 꼼꼼하게 기획하는 데에는 상당히 유용한 도구라는 것을 알게 되었습니다.

UML과 유즈케이스는 프로그래머들이 프로그램을 어떻게 짤지 사용하는 도구인데요. UML의 경우에는 프로그래머가 아닌 사람들이 사용하기에는 조금 어렵습니다. 무엇보다 기획자가 그냥 써먹기에는 난점이 있더군요. 하지만 유즈케이스의 경우 상당히 쓸만했습니다. 유즈케이스 자체가 프로그래머들이 프로그램을 하기 전에 고객의 요구사항을 분석하기 위해 만든 툴이거든요.

유즈케이스의 가장 큰 장점은 UML처럼 기호로 이루어진 것이 아니라 일반 문장으로 이루어져 있으며, 형식이 자유롭다는 것입니다. 실제 유즈케이스 책에서도 적합하게 사용할 수 있도록 첨삭하는 것을 권하고 있습니다. 단점이라면… 모르겠네요. 아직은 단점이라고 할만한 것을 발견하지 못해서요. 기획자 입장에서는 기획해야 할 내용을 체크하는데 이만한 툴을 아직까지 본 적은 없습니다.

유즈케이스는 프로그래머들이 프로그램에 대해 전혀 모르는 고객들의 요구사항을 프로그램이 가능하도록 구조화하기 위해 만들어진 형식입니다. 프로그램에 대해 전혀 모르는 고객이 넘겨줄 수 있는 정보는 각 단계와 단계에 필요한 정보들 정도가 전부겠지요. 이 것을 정리한 문서라고 보시면 됩니다. 간단하게 설명하자면 “어떤 목적을 이루기 위한 과정과 정보를 단계별로 서술한 문서” 라고 할 수 있겠습니다. 현금인출기에서 돈을 뽑는 것을 단계별로 서술한 것 등이 되겠죠. 카드를 넣고, 돈 찾기를 선택한 다음, 패스워드를 입력하고, 금액을 정한 다음, 기계가 서버와 통신해서 처리를 하고, 돈을 넘겨주면 끝나는 일련의 과정을 한 단계 한 단계 설명한 문서. 이 것을 생각하면 되겠습니다.

이 것이 게임 기획과 어떤 관련이 있는가? 라고 이야기하자면. 게임의 어떤 단계에서 어떤 일이 있을 것인가를 구조화하고 관련되어 필요한 정보를 목록화하는데 아주 유용하기 때문입니다.

저 같은 경우 주로 이런 목록을 사용합니다.

1.       유즈케이스 명, 단계 : 어떤 경우인가. 얼마나 상세한 수준인가를 나타냅니다.

2.       선행조건 : 이 유즈케이스가 동작하기 위한 선행조건이 무엇인가?

3.       기본 보장사항 : 이 유즈케이스에서 최소한으로 보장해주어야 할 사항은 무엇인가?

4.       기본 플로우 : 이상적으로 진행될 경우의 기본 흐름

5.       대체 플로우 : 기본 플로우에서 발생될 수 있는 예외상황의 경우 처리

6.       기타 : 부가적으로 설명할만한 기타사항

대략 이 정도면 큰 문제없이 내용서술이 가능하더라구요. 하지만 역시 목록만으로는 설명이 어려우니 실제로 무언가 적어봐야겠죠.

아주 간단한 부분을 생각해보죠. 횡스크롤 방식의 액션게임에서 적을 공격할 때를 생각해보겠습니다. 적에게 명중하기 시작하면 액션이 변화하면서 콤보가 들어간다던가 하는 경우도 있겠습니다만 간단하게 생각하죠. 공격버튼을 누르면 캐릭터가 무기를 휘두르고, 무기에 명중한 캐릭터는 모두 동일하게 공격당한다고 생각합시다. 캐릭터가 맞든 안맞든 공격한 캐릭터는 정해진 애니메이션을 한 번 하고 끝납니다. 으음.. 너무 간단한가? 싶기도 합니다만.. 그냥 가 보죠.

일단 정리하면 다음과 같이 되겠습니다.

1. 공격버튼을 누르면 공격이 시작된다.

2. 주인공 캐릭터가 현재 위치에서 진행방향을 향해 공격한다.(명중여부에 상관없이 동작을 한다.)

3. 주인공 캐릭터의 공격에 명중하는 적은 모두 공격을 받는다.

4. 공격을 받은 적은 데미지를 입고, 피해가 심각한 적은 죽는다.

5. 죽은 적에 해당하는 점수를 플레이어 점수에 더한다.

음. 일단 정리는 되었네요. 이걸로 OK는 아닙니다만. 대략 이런 흐름으로 진행된다는 것은 정한 것 같습니다. 이제 여기에 좀 더 상세한 내용을 추가하면 될 것 같습니다. 일단 데미지 공식이 빠져있네요. 이것만 있으면 크게 빠진 건 없을 것 같습니다. 이 항목은 4번 항목에 부가된 것이니까 4-1 정도로 해서 넣어두기로 하죠. 그리고 공격이 어떻게 명중하느냐에 대한 내용도 없네요. 이건 공격시 현재의 위치에서 진행방향을 중심으로 좌/우 90도씩의 각도로 1미터 범위의 반원을 그린 다음. 해당 범위안의 적은 모두 맞는걸로 하죠. 이 내용은 3-1로 넣도록 하죠.

그럼 아래 내용처럼 되겠습니다.

1. 공격버튼을 누르면 공격이 시작된다.

2. 주인공 캐릭터가 현재 위치에서 진행방향을 향해 공격한다.(명중여부에 상관없이 동작을 한다.)

3. 주인공 캐릭터의 공격에 명중하는 적은 모두 공격을 받는다.

3-1. 공격의 명중판정은 공격 시작시 정해진다. 현재 위치에서 진행방향을 중심으로 좌/우 90도. 거리 1미터의 반원 내 모든 적이 공격에 맞는다.

4. 공격을 받은 적은 데미지를 입고, HP가 0 이하인 적은 죽는다.

4-1. 데미지 공식은 (주인공 캐릭터의 공격력 – 적 캐릭터의 방어력) 이다.

5. 죽은 적에 해당하는 점수를 플레이어 점수에 더한다.

흠. 이 정도면 기본적인 흐름이 되겠죠. 음. 된 것 같습니다. 그러면 늘 이 순서대로 게임이 진행될까요? 그렇지는 않을겁니다. 가장 큰 예가 공격도중의 주인공을 다른 적 캐릭터가 공격하는 경우가 되겠네요. 음. 이걸 어떻게 처리하면 좋을까요? 이번에는 공격 시작시 일괄적으로 맞는걸로 처리해버리기로 했으니 중간에 공격을 받게 되면 공격이 취소되는 등의 기획은 넣기가 어렵습니다. 그렇다고 앞의 내용을 고치기는 귀찮고… 그냥 공격을 발도술처럼 순간적으로 하는걸로 하고, 그 뒤에 경직을 넣기로 합시다. 이 때 공격을 받으면 데미지 상태로 바꾸어 주는걸로 하죠. 실제 기획에서는 이러면 안되지만 말입니다.

이 경우는 기본흐름에는 속하지 않는 내용입니다. 바로 대체 플로우에 들어갈 내용이죠. 대체플로우의 경우 저는 그 이벤트가 발생할 번호의 서브로 생각해서 번호를 붙입니다. 1,2,3,4 식으로 가는게 아니라 2-1, 2-2 같은 식인거죠.

음. 이거 말고 대체흐름으로 발생할만한게 있을까요? 흐음… 없는 것 같네요. 그럼 다시 한 번 정리해보죠. 이번에는 유즈케이스 목록에 넣도록 하겠습니다.

1.       유즈케이스 명, 단계 : 주인공캐릭터 공격. 상세 단계.

2.       선행조건 : 플레이어가 공격 버튼을 누른다.

3.       기본 보장사항 : (이 상태에서는 특별히 보장해줄게 떠오르지 않아 생략합니다.)

4.       기본 플로우

A.       주인공 캐릭터가 현재 위치에서 진행방향을 향해 공격한다.(명중여부에 상관없이 동작을 한다.)

B.       주인공 캐릭터의 공격에 명중하는 적은 모두 공격을 받는다.

B-1. 공격의 명중판정은 공격 시작시 정해진다. 현재 위치에서 진행방향을 중심으로 좌/우 90도. 거리 1미터의 반원 내 모든 적이 공격에 맞는다.

C.       공격을 받은 적은 데미지를 입고, HP가 0 이하인 적은 죽는다.

C-1. 데미지 공식은 (주인공 캐릭터의 공격력 – 적 캐릭터의 방어력) 이다.

D. 죽은 적에 해당하는 점수를 플레이어 점수에 더한다.

5.       대체 플로우

A-1. 공격 도중 적의 공격을 받게 되면 현재 동작을 중지하고 데미지를 받는다.

6.       기타 :

음. 대략 이쯤 되겠습니다. 이 정도로 정리하고 나면 대략 주인공 캐릭터의 공격이 어떻게 이루어질 건지, 어떤 일들이 있는지를 전체적으로 체크했다고 할 수 있겠죠. 이제는 플로우를 점검하면서 필요한 상세정보를 뽑아내고. 이 유즈케이스와 상세정보를 바탕으로 기획서를 써 나가면 될 것입니다.

정리하자면, 유즈케이스는 기획해야 할 내용을 점검하고 잊어버리거나 빼먹은 부분을 체크하여 빠진부분 없이 기획하기에 매우 좋은 툴입니다. 기본적인 순서와 내용은 있지만 그 것도 가이드라인일 뿐이고 필요에 따라서 얼마든지 내용을 바꿀 수 있구요. 하지만, 이 것은 기획서가 아니라는 점을 기억할 필요가 있습니다. 기획서를 작성하기 전, 사용하기에 유용한 도구라는 한계가 있죠.

저처럼 빼먹는게 많아서 문제를 자주 일으키는 기획자가 있으시다면, 유즈케이스의 사용을 적극 권장합니다.