Java Web Game 개발 가이드(9)

 

컨텐츠 문서화

프로젝트 문서

  프로젝트 문서에서 정의되는 문서의 단계는 다시 분석, 설계, 개발, 테스트, 이행 문서로 나누어 집니다. 하지만 우리는 소수가 개발 함으로 이 문서 항목 중 꼭 필요하다고 여기는 몇 가지만 살펴 보고 넘어 갑니다.

  아마 전 단계를 거쳐 왔다면 업무 분석에 관한 자료와 자신이 개발하려는 컨텐츠에 대한 요구사항 정의와 분석이 거의 완료 돼 있을 것이라 생각 됩니다. 이런 자료는 여러 가지 다양한 시각화 자료로 잘 정리해 둡니다. 실질적으로 이미 설계에 써먹어서 남에게 보여줄 때 빼고는 거의 볼일은 없을 것입니다. 하지만 잃어버리지 않게 잘 정리해 둡니다.

  시스템 개념도는 정의해 두어야 나중에 착오가 없습니다. 여러분은 앞서 환경 설정 시 이미 톰켓, 자바, MySql 에 대한 버전 및 설정이 끝나 있을 것입니다. 필자가 이 버전들을 선택한 이유는 여러분들이 아마도 가장 많이 사용하고 있는 호스팅 업체들을 기준으로 잡아둔 버전들 입니다. 이 문제를 가볍게 생각 했다가는 나중에 큰 고생을 치를 수 있습니다. 국내 각 호스팅 업체는 자바, 톰켓, 데이터 베이스의 버전을 모두 달리 적용하고 있습니다. 자바와 웹 서버는 큰 문제가 나지 않겠지만 MySql 의 경우 버전에 따른 쿼리가 매우 많이 달라지는 것을 볼 수 있습니다. MySql은 5.0 이후 버전부터 서브 쿼리가 잘 지원이 되며, 인코딩 설정에서 EUC-KR이 사라 졌습니다. 웹 서버의 경우 버전에 따라 커넥션 풀 설정법이 다를 수도 있고 이 모든 것은 대부분 리눅스나 유닉스 서버를 환경으로 채택되어 있습니다. 구현에 들어가기에 앞서 이 모든 사항들을 미리 문서에 정의 해 두고 서비스 받을 업체에 확인을 해 둡니다.

  다음은 화면 설계도와 메뉴 구조도를 작성 합니다. 화면 설계도는 전체적인 윤곽과 분위기를 일관되게 이끌어 갈 수 있고 참고 하도록 시각적으로 작성해 두는 것이 좋습니다. 이 과정을 통해 좀 더 구체적인 머릿속의 웹 게임 윤곽을 형상화 해 낼 뿐 아니라 중간에 개발방향을 잃지 않는 나침반 역할을 하게 됩니다.

<시스템 개념도 중의 한 그림>

  메뉴 구조도는 일종의 웹의 전체 지도와 같은 역할을 하게 됩니다. 이 메뉴 구조도가 있어야 모든 액션과 루틴을 한눈에 쫒아 갈 수 있습니다. 이 문서를 잘 작성해 두면 다른 사람이 개발에 참여할 시 진정한 빛을 발하게 될 것 입니다.

게시판 (BoaRD)	BRD	공지사항 (NoTiCe)	NTC	리스트	BRD_NTC_000000
				보기	BRD_NTC_001000
				입력	BRD_NTC_002000
				수정	BRD_NTC_003000
				삭제	BRD_NTC_004000
		팁(게임정보) (TIP)	TIP	게임소개	BRD_TIP_000000
					BRD_TIP_001000
					BRD_TIP_002000
					BRD_TIP_003000
					BRD_TIP_004000
		자유게시판 (Free BoaRd	FBR	리스트	BRD_FBR_000000
				보기	BRD_FBR_001000
				입력	BRD_FBR_002000
				수정	BRD_FBR_003000
				삭제	BRD_FBR_004000
		이용약관 (AgreeMenT)	AMT	보기	BRD_AMT_000000

<메뉴 구성도의 한 부분>

  위의 예보다 실제로는 훨씬 많고 복잡한 구조와 파일 리스트를 가지고 있을 것입니다. 사실 새로이 파일이 지속적으로 추가되고 첫 설계 때와는 비교도 되지 않는 시스템으로 덩치가 불어 났을 시 이 메뉴 구조도가 없다면 어떤 파일 하나를 찾아가는데도 엄청난 시간이 들어가게 됩니다. 여러분이 혼자서 개발을 할 때 가장 시간을 많이 아낄 수 있는 방법은 쓸데없는 곳에 시간을 허비 하지 않도록 네이게이션 성격의 문서들을 많이 가지고 철저히 버전 관리를 하는 것입니다.

  그런데 이 위의 메뉴에 보면 파일 명을 약자로 정의 하여 설계 한 것이 보일 것입니다. 이 메뉴 구성도대도 파일을 구성하다 보면 일관되고 규칙적인 명명법을 적용하게 되는데 이러한 것을 정의해 둔 문서를 개발 표준 정의서 라고 부릅니다. 이 개발표준 정의서는 보통 기업에서 네이밍에 따른 혼란을 줄이고 공통된 약속과 규약을 적용하여 누가 파일을 유지보수 할 시 이름만 보고서도 대략적인 파일의 내용을 유추 할 수 있는 규칙과 방법을 정의해 둡니다.

  이런 개발 표준 정의서의 내용은 상당히 세세하고 많은 부분을 정의 하는 것이 보통입니다. 모든 것을 모두 이 공간에 실을 수는 없지만 몇 가지 예를 들어 이해를 돕도록 하겠습니다.

Ex) 다음은 문서의 상단에 표기하는 공통 주석의 형식 입니다.

/**

* Class        <code>클래스명</code>(JSP인 경우 생략하거나 파일명으로 대체)

* @program        프로그램명(또는 업무명)

* @description    설명

*

* @author        소속 / 개발자

* @update        2004/01/01

* @package        패키지명(JSP인 경우 생략)

* @see        참조나 사용된 파일(JSP인 경우 생략 가능)

*

* @DBTable        DATABASE명(JSP인 경우 생략 가능)

*/

   

Ex) 다음은 변수 명명법에 관한 표준 입니다.

변수 표준

변수 표준은 다음 두가지 경우에 따른다.

1) 시스템(공통)

- 가능한 헝가리안 표기법에 따른 Type Prefix를 적용하여 만든다.

- 변수 이름은 다음과 같이 구성된다.

- '임시 변수(Temporary Variable)'와 '상수(Constant)'는 예외이다.

- 의미 있는 변수명은 용어사전에 정의된 약어를 사용하는 것을 원칙으로 하며

샘플 : calToday

의미 : 타입이 Calendar인 Today 변수

   

- 구성항목별 설명

항목	설명
Prefix	헝가리안 표기법에 따른 Type Prefix 목록표의 Prefix를 사용.
의미 있는 변수명	용어사전을 참조하여 사용한다.

   

Ex) 변수 명명법의 한 방법인 헝가리안 표기법 예시 입니다.

헝가리안 표기법에 따른 Type Prefix 목록표 (변수)

   

구분	Prefix	사례
int	i	iCount
char	c	cType
long	l	lLength
double	d	dAmt
float	f	fAmt
Boolean	b	bCheck
byte, byte[]	bt	btIndex
BigDecimal	bd	bdSum
String	str	strName
StringBuffer	sb	sbQuery
StringTokenizer	st	stToken
IOException	io	ioEx
SQLException	sql	sqlEx
Exception	e	e, e1
Enumeration	enm	enumFiles
Date	dt	dtSystemDate
Timestamp	ts	tsSystemDate
Hashtable	ht	htStatefulBeanData
HashMap	hm	hmUser
Vector	vt	vctNewsList
Calendar	cal	calToday
세션(session) 변수인 경우	ss	ssName
DataContainer	dc	dcResultDC
DataWindow	dw	dwResultDW
Object	o	oObjectClassName

  사실 이러한 명명법들은 이미 몸으로 체득하고 개발에 임하므로 경험있는 개발자들은 이 부분에 대해 따로 문서화 하고 학습하지 않습니다.

프로젝트 관리문서

  관리 문서는 프로젝트를 진행 함에 있어 절차상의 혼란을 최대한 간소화 하고 빠른 커뮤니 케이션을 위한 인프라성 문서라고 생각 하시면 됩니다. 만약 혼자일 하는 것이 아니라면 회의록, 자리배치도, 신상명세서, 긴급 통화, 프로젝트 기물관리 대장, 기타 운영자료, 형상관리 따위를 말합니다.

이 글은 기본적으로 혼자서 모든 것을 다 개발하는 것을 목표로 함으로 이 문서에 대한 자세한 설명은 생략 하도록 하겠습니다. 다만 WBS 일정관리 계획, 형상관리, 백업관리에 대하여 몇 가지만 짚어 보도록 하겠습니다.

• WBS 일정관리와 형상관리

  이 글은 웹 게임을 개발하기 위한 어찌 보면 좀 흥미 있는 주제로 이끌고 가고 싶지만 아무래도 실제적인 개발을 위한 영양가 있는 글로 이끌어 가면서도 분량을 최대한 줄이려 하다가 보니 글이 딱딱하고 재미없는 실무적인 이야기로 많이 흐르는 듯 합니다. 하지만 실무에서 사용되는 (실은 이것은 실무보다도 훨씬 적은 단계이지만) 많은 도구들은 그만큼 효율적이고 빠른 개발을 도와 주기에 채택된 방법들 입니다. 실질적인 금융권, 보험 등 관료제를 채택하는 많은 대기업들과 관공서에서 깐깐하게 체크하는 사항들이지요. 그럼 간단하게 알아보고 우리가 만들 웹 게임에 대한 일정도 세워 보도록 하겠습니다.

  WBS 는 일정을 효율적으로 표현하기 위한 도구 입니다. 제가 처음에 프로젝트의 실패는 개발자에게 쓰린 아픔을 준다고 했던 말이 기억 나시나요? 끝이 없는 프로젝트 만큼 무의미한 프로젝트는 없을 것입니다. 혼자서 개발을 진행하는 것 역시 철저한 관리와 일정이 지켜지지 않으면 결국 힘들고 좌절하며 심지어 흐지부지 포기하게 되기 일수 이지요. 하지만 소프트웨어 개발에 대한 일정이란 생각만큼 쉽게 세우기 힘이 듭니다. 그 이유는 사람의 코딩, 설계 능력과 범위를 수치화 할 수 없어 다른 일에 비해 가늠하기 힘들기 때문 입니다. 하지만 단계를 세분화 하고 자신의 능력을 솔직히 인정하며 성공적인 프로젝트 완성을 위한 골격을 만들어 두면 한층 일이 수월해 질 수 있습니다. 다음은 WBS 일정의 예 입니다.

  이 일정표는 대단히 크고 범위가 넓습니다. 단순히 예를 위한 그림이지만 너무도 재미없게 생긴 그림 입니다. 오른쪽에 11월에 대한 진척 예정이 있는데 단계별로 진척이 겹치지요? 단계별로 함께 진행해야 하는 사항과 여러 사람이 분업이 가능한 곳이 저렇게 겹치게 됩니다. 또한 이 일정을 그림으로서 각 사람들의 업무 분담이 이루어 지기 쉽습니다. 위처럼 아주 자세한 분석과 설계 과정이 선행 되었다면 기간을 잡는데 상당한 오차를 줄일 수 있습니다. 여러분의 웹 게임 프로젝트 역시 이렇게 세분화 하고 날자의 일정을 잡으면 결코 실패 하지 않는 개발이 될 것입니다.

• 형상관리를 활용하자.

  형상관리라 함은 모든 소스 버전관리라고 생각하면 됩니다. 자신이 수정하고 개발한 화면을 다른 사람이 받아 볼 때 겹치는 부분을 같이 수정 했다면 어떻게 해야 할까요? 아마 하나씩 틀린 곳을 서로 확인하며 소스를 합쳐야 하겠지요. 그러나 이런 식의 개발은 대단히 비효율 적입니다. 그렇기 때문에 이클립스에는 CVS라는 형상관리 방법을 기본 제공 합니다. CVSNT라는 프로그램을 한 컴퓨터에 설치하고 소스 서버로서 설정하고 운영하면 소스에 대한 버전 관리가 이루어 지며 서로가 작성한 소스를 손쉽게 받아보고 수정하여 올릴 수 있도록 도와 줍니다. 이 CVS에 관한 설정 및 개념은 나중에 기회가 닿으면 연재 하기로 하고 이 글에서는 이쯤에서 다음 장으로 넘어가 볼까 합니다.

  다음 장부터는 구체적인 구현 수준의 주제를 다룰까 합니다. 그래서 소스 구현을 앞두고 몇 가지만 설명 하고 넘어갈까 합니다. 여러분은 다양한 아이디어로 데이터를 구조화 하고, 유기적으로 연결 시키며 구현을 하기 위한 모든 제반 작업을 끝냈을 것으로 알지만 행여 자신이 데이터를 추상화 하는 도중 혹은 모두 끝내고 또 다시 떠오르는 다양한 아이디어를 대충 구조화 해 넣어 두고 넘어 왔을 수도 있습니다. 하지만 꼼꼼히 체크 하지 않은 테이블의 키 관계, 구현 상에서 참조되는 값들의 선 후 관계 들이 나중에 커다란 대 수술이 될 수 있음을 꼭 인지 하고 진행 하길 바랍니다. 특히 플레이어들이 게임을 즐기는데 있어서 심각한 버그들(기축 통화의 무한 유출, 아이템의 복사가능, 증발, 유닛의 끼임, 증발, 복사 등등)이 발생 할 수 있는 여지가 있는 구조는 좀더 심플하고 알기 쉬운 구조로 변경 할 것을 권장 합니다.