오픈비 : 삽질은없다

Toad DBA Suite로 패키징된 제품 중에서 먼저 TDM 제품에 대한 리뷰를 간략하게 작성해 보았다.

<먼저, 본 리뷰에서 언급한 사항 중에 툴에 대해서 깊이 있게 알지 못해서 혹은, 특정 기능을 찾지 못해서 잘못된 내용을 기술할 수도 있음을 미리 알린다. 나름 기능을 찾기 위해 매뉴얼도 찾아보고 했지만, 자료도 부족하고 영어 울렁증이 있어서 말이다.>

TDM은 데이터 모델링 툴이다. 대표적인 데이터 모델링 툴로는 국내에서 많이 사용하는 Allfusion ERWin, DA#(encore), ER/Studio(Embarcadero), PowerDesigner(Sybase), Visio(Microsoft) 등이 있으며 UML 툴에서 데이터모델링을 지원하거나 eclipse plug-in으로 나온 제품들도 있다.

예전에 TDM의 초기버전은 논리모델이 없었으며, 물리모델만을 모델링 할 수 있도록 구성되어 있었던 것으로 생각된다. 이번 버전은 기존의 기능에 논리모델 기능 및 여러가지 다양한 기능을 추가하여 나온 제품인 듯 하다.

<?xml:namespace prefix = o /> 

"百聞이 不如一見"

TDM을 설치 후에 처음으로 실행한 화면이다.

TDM이 TOAD만큼 유명한 제품이 아니라서 그런지 샘플모델을 디폴트로 로드되도록 구성되어 있다. 첫 느낌은 색깔이 화려한게 일단 맘에 든다.

 

LDM & PDM

TDM이 다른 모델링 툴과 가장 차이점은 LDM(Logical Data Model)과 PDM(Physical Data Model)을 작성하고 관리하는 방식인 것 같다.

대부분의 모델링 툴은 LDM과 PDM을 동일한 구조를 갖도록 구성해야 한다.

 

위의 그림과 같이 Super Type과 Sub Type으로 구성된 논리모델이 있을 때, 물리모델에서는 테이블 단위로 구성되기 때문에 물리모델 단계에서 각 엔티티를 하나의 엔티티로 통합하거나 각각의 서브타입으로 분리하거나 하는 방식으로 변경을 한다.

Erwin이나 대부분의 모델링 툴에서는 논리모델시에 위의 그림처럼 Subtype으로 모델링을 하여도 최종 물리모델단계로 넘어가면서 엔티티를 통합/분리하므로 최종적으로는 하나의 엔티티가 어떤 서브타입으로 구성되어 있는지 모델만 봐서는 파악하기가 어려워진다.(물론 별도의 파일로 작성하면 가능은 하지만 상당히 관리가 불편해진다.) 그런 단점이 있으나 논리모델과 물리모델이 동일한 모습을 가지게 되므로 논리모델에서 물리모델로 전환이 쉬워지는 장점이 있으며 하나의 파일로 관리된다는 점도 장점 중 하나이다.

 

그러나 TDM은 일반적인 하나의 파일로 논리/물리를 관리하지 않으며 별개의 파일로 논리/물리모델을 구성/관리하도록 되어 있다.

 

위의 그림과 같이 간단히 논리모델을 TDM으로 작성하였다. 물리모델을 작성하기 위해서는 TDM에서는 Convertor를 이용하여 물리모델을 생성하여야 한다.

 

다음은 툴의 기능을 이용하여 물리모델을 작성한 화면이다.

두 모델을 비교하면 물리모델에서는 Subtype이 하나의 테이블로 통합되어 구성이 되어있다. TDM에서는 이렇게 비즈니스 로직을 담고 있는 논리모델과 테이블구조를 가지는 물리모델을 분리하여 관리하도록 하여 논리모델에서는 비즈니스 로직만을 충실히 담을 수 있도록 구성하여 기존 툴과의 차별성을 내세우고 있다.

 

그러나 데이터모델은 지속적으로 변경된다. TDM에서는 한번 변환한 모델간의 Alignment가 되지 않는다는 치명적인 단점이 있다.

가령 논리모델에서의 “사용자아이디”란 속성이 물리모델에서의 “USER_ID”란 컬럼으로 변경되어 있다는 정보를 툴이 인식을 하지 못한다. 그러므로 논리모델의 속성명이 변경되거나 컬럼사이즈가 변경, 컬럼의 추가 등의 변경이 발생하더라도 물리모델에서 인식을 하지 못하므로 개별적으로 두 모델을 따로 관리하여야 한다.

혹시 Convertor를 이용하면 되지 않을까? 열심히 궁리를 해보았지만 Convertor에서는 “사용자아이디”와 “USER_ID”가 완전히 서로 틀린 컬럼으로 인식하고 있어서 방법이 없었다.

 

[위의 그림처럼 좌측의 회원이 물리모델에서 존재하지 않는 것으로 나타나며, 우측의 USER 테이블에 해당되는 좌측의 논리모델도 존재하지 않는 것으로 나타난다.]

 

매뉴얼을 찾아보니 모델 변경시에는 물리모델을 먼저 변경하고 변경사항을 역으로 PDM -> LDM으로 병합해야 한다고 나와있었다.

그 말은 비즈니스 모델이 변경되었지만 물리모델에서 먼저 작업하고 비즈니스 로직을 나중에 고치라는 말도 안되는 방식을 툴은 강요하고 있는 것이다.

차기 버전에서 가장 개선되어야 할 부분이 아닌가 싶다.

LDM과 PDM을 별도의 파일로 관리하는 모델링툴의 대표적인 사례는 DA#이 있다. 이 툴은 논리모델의 변경사항을 한번의 클릭으로 물리모델에서 정확히 인식하며 엔티티 레벨, 속성 레벨의 변경정보를 정확히 모델러에게 알려준다.

 

엔티티 속성 편집창

다음은 LDM의  엔티티 속성 편집창의 모습이다.

 

 

일반적인 엔티티의 속성 정보를 저장할 수 있는 UI이다.

Caption 항목은 속성의 설명정보를 담는 항목이다. 대부분의 툴에서는 Description 이름으로 제공하고 있다.

모델링을 하다 보면 Caption 및 Description 기능이 모두 필요하다.

특히 우리나라 같이 비 영문 국가에서는 테이블 생성시에 Comment 객체에 컬럼의 한글명을 기입하고 논리모델에서는 컬럼의 상세한 업무규칙 및 컬럼의 정의를 할 수 있다면 가장 best 하지만 아쉽게도 그렇게 구별하여 지원하는 툴은 아직까지는 보지 못한 것 같다.(나만 필요하다고 느끼는 것인지도 모르겠다)

 

컬럼편집

TDM에서는 컬럼별로 복사를 할 방법이 없다. 엔티티 레벨에서는 복사가 가능하나 LDM에서 특정 속성만을 선택하여 다른 엔티티로 컬럼을 복사할 방법이 없다. 등록일자/수정일자 같은 시스템 공통속성을 전 엔티티에 모두 두기 위해서는 각 엔티티마다 모두 입력하는 방법밖에 없다. 이 부분도 반드시 차기 버전에는 들어가야 될 기능이 아닐까 싶다.

 

데이터 표준화 지원

TDM의 또 다른 단점 중 하나는 데이터 표준화에 대한 지원이다.

TDM에서 도메인을 지원하기는 하나 계층적으로 구성할 수가 없고 별도의 도메인타입을 만들 수 가 없어서 모든 도메인을 1차원적으로 구성해야 한다. 조금은 아쉬운 부분이다.

또한, 물리모델 생성시에 단어 및 용어 표준화를 지원하지 않는다. 툴을 열심히 뒤졌것만 찾을 수가 없었다. 특히 우리나라같이 한글로 논리모델을 작성하고 영문컬럼명으로 물리모델을 변환해서 사용해야 하는 환경에서 영문컬럼명 변환을 매번 모든 컬럼을 클릭하여 입력한다는 것은 엄청난 노가다다.  용어사전을 생성하여 두고 자동으로 변환되지 않는다면 엔티티가 100개만 넘어가더라도..(생각하기도 싫다)

이 부분도 차기 버전에 반드시 들어가야 될 기능이 아닌가 싶다.

 

WorkSpace & UI

TDM에서는 주제영역(Subject Area)를 Workspace란 명칭으로 사용한다. eclipse의 영향인 것 같기도 하다. 거의 모든 툴에서 subject area란 용어를 사용하는데 말이다.

TDM의 편리한 점 중 하나는 여러 모델을 tab 방식으로 조회를 할 수 있는 점인 것 같다.

그리고 TDM에서는 실행취소 기능을 제공한다. 이게 얼마나 편리한 기능인지는 이 기능이 없는 툴을 사용해 본 사람이면 공감을 할 것이다. Erwin의 경우에도 아직도 많은 사람들이 사용하고 있는 v4.xxx 버전에서는 이 기능이 없다. r7 버전부터 이 기능을 제공하고 있으니 말이다. 엔코아의 모델링 툴인 da# 의 경우도 실행취소 기능이 없어서 어떤 땐 무지 짜증이 날 때도 있다. TDM에서는 이 기능을 제공해 주니 그래도 쓸만은 하다.

 

Reverse Engineering

리버스 엔지니어링은 초기 AS-IS 데이터 모델 분석시에 반드시 필요한 부분이다. 특히 엔티티가 몇 백개씩 되는 대형 사이트에서는 이 기능이 없으면 DB 분석시에 엄청난 시간이 걸릴것이다. 리버스 엔지니어링과 관련하여 또 반드시 필요한 기능은 테이블 정렬 기능이다. 몇 백개 되는 테이블이 아무런 연관없이 이름을 툴위에 쭉 나열한다면 테이블을 거의 분석하기가 힘들것이다. 대부분의 시스템에서 명식적인 FK를 설정하지 않고 데이터베이스를 구성하기 때문에 툴에서 컬럼명을 기준으로 가상의 Relation을 생성해주고, 사용자가 지정하는 Key Entity 혹은 Main Entity를 중심으로 주변에 Action Entity를 배치하게 해준다면 리버스 된 모델이 사용자가 인지하기 쉬운 구조로 재배치되어 많은 도움이 되리라 생각된다.

TDM에서는 리버스 기능은 훌륭하나 테이블 정렬기능은 단순정렬밖에 제공되고 있지 않아 아쉬움이 남는다.

아래 그림은 운영하고 있는 시스템을 리버스로 물리모델을 생성하는 과정을 담고 있는 화면이다.

 

 

설치시에 데이터소스를 오라클과 MS-SQL만으로 한정하였기에 해당되는 항목이 위의 정보만 나타난다. MS-SQL 2008과 ORACLE11도 출시되었으니 조만간에 추가되지 않을까 싶다. 또한 QUEST사의 대표적인 제품인 TOAD와 연동할 수 있는 기능이 눈에 띈다.

 

Data Provider 및 접속정보를 입력한 후 Reverse해야 될 대상을 선택하는 화면이다.

 

다음은 리버스에 대한 옵션을 선택하는 화면이다.

 

최종적으로 리버스해야될 테이블은 선택하고 나서 Execute 버튼을 클릭하면 TDM은 리버스를 시작한다.

 

 

위의 그림은 최종적으로 리버스된 물리모델의 모습이다.

 

테이블 속성편집 창

리버스된 테이블의 속성 편집창이다.

상당히 많은 탭이 보인다.

 

SQL Preview 기능은 다른 툴에서는 잘 없는 기능인데 편리한 기능인 것 같다.

 

테이블의 속성정보 (위 그림은 파티션정보이다.)을 콤보박스나 그리드 같은 UI를 사용하지 않고 Text로 입력하도록 구성되어 있는 모습이다.

 

 

리버스한 정보 중 오라클 패키지의 SQL Preview화면이다. 주석의 일부분이 진한갈색으로 보이는건 왜 그런지 모르지만 리버스는 훌륭히 수행한 것 같다.

 

모델 Compare 및 Alter Script Generation

극히 일부의 모델링툴에서만 제공하는(Erwin) 편리한 기능이 TDM에도 탑재되어 있다. 모델간의 비교 및 비교를 통한 Alter Script를 생성해주는 기능이다. 변경되는 양이 적을 경우에는 툴보다는 손으로 스크립트를 작성하는게 편리하다. 그러나 큰 규모의 변경이 일어나는 경우에는 툴의 기능을 이용하면 편리하게 업무를 처리할 수 있다.

 

 

위의 그림은 물리모델에서 하나의 컬럼을 추가한 후 ALTER SCRIPT를 생성하기 위해 Convertor를 실행시킨 모습이다.

 

최종적으로 생성된 Alter 스크립트이다. 변경된 부분 중에서 필요한 부분만 선택하여서 Alter 스크립트를 생성할 수 있다.

Reporting

프로젝트 개발시에 모델링에 대한 산출물은 필수산출물이다. 나는 대체로 별도로 산출물을 작성하지 않으며 ER모델을 아주 상세하게 작성한 후 고객사의 양식에 맞게끔 툴로 Generation하여 제출하는 편이다. 그러므로 이 기능은 아주 필요한 기능이다.

TDM은 HTML 방식과 rtf 파일을 제공하고 있다.

위의 그림은 Report 생성시에 필요한 사항을 선택하는 화면이다.

최종적으로 Reporting된 화면은 아래와 같다

내부 프로젝트나 별도의 양식이 없는 프로젝트의 경우에는 사용이 가능하나 고객사 혹은 내부 산출물 양식이 지정되어 있는 경우는 이정도 레포팅 기능으로는 부족하지 않나 싶다.

별도의 양식을 디자인하는 기능이나 혹은 Erwin처럼 별도의 API를 제공은 고사하더라도 최소한 엔티티나 테이블의 정보를 엑셀로 출력하는 기능정도는 있어야 하지 않을까 싶다.

총평

Toad Data Modeler(TDM)은 버전 3으로 오면서 많은 기능이 추가되었지만, 아직까지는 부족한 기능이 많은 편이다. 소규모 프로젝트에서는 가능한 수준이 아닌가 싶다. 그러나 데이터베이스 관련한 SW의 노하우가 많은 Quest사의 제품이니만큼 그리 오래지 않아 필요한 기능들이 모두 추가되고 TDM만이 제공하는 특별한 기능까지. 향후에는 Toad와 같은 명성을 TDM도 얻을 수 있으리라 생각한다.

http://www.iabf.or.kr//Lab/share/css/base.css


@charset "euc-kr";

/*

 * default definition

 */

body {

	margin: 0;

	padding: 0;

	font-size: 0.75em;

	line-height: 1.5em;

	/*

	font-family: Dotum, "돋움", sans-serif;

	*/

	font-family: "Malgun Gothic", "Lucida Grande", Tahoma, Verdana, AppleGothic, UnDotum, sans-serif;

}

* html body {

	/*

	font-size: 12px;

	*/

}

form {

	margin: 0;

	padding: 0;

}

hr {

	display: none;

}

p, div, th, td, select, input {

	color: #333;

}

a:link, a:visited {

	color: #555;

	text-decoration: none;

}

a:active, a:hover {

	color: #777;

	text-decoration: none;

}

img, 

input.type-image {

	border: 0 none;

}

input.type-text, 

textarea {

	border: 1px solid #ddd;

	background: #fff;

	padding: 1px;

}

input.type-text:hover, 

input.type-text:focus, 

textarea:hover, 

textarea:focus, 

select:hover, 

select:active {

	background-color: #ffd;

}

input, select, textarea {

	vertical-align: middle;

	font-size: 1em;

	color: #333;

}

select {

	font-size: 11px;

	font-family: Dotum, "돋움", sans-serif;

}

span.button, 

img.button, 

a.button {

	cursor: pointer;

	vertical-align: middle;

}

웹표준화와 웹접근성 강화에 대한 이슈가 커지고 있다. 오는 4월 11일(차주11일(차주 금요일) '장애인 차별금지 및 권리구제를 위한 법률'이 시행되고, MS의 Internet ExplorerExplorer 8은 그동안 문제가 많았던 CSS 렌더링 엔진을 자사 제품중(IE 5.5, 6,6, 7) 가장 완성도 있는 표준 지원 엔진으로 바꿔놓았다. 애플은 자사의 'Safari''Safari' 웹브라우저를 윈도우용으로 출시하였고, 최근에는 웹표준기술 테스트인 Acid3를 통과했다는 소식을 전했다. 오페라오페라 역시 'Safari'와 같은 날 Acid3를 통과했고, 모바일 시장(휴대폰, PDA 등에 탑재되는탑재되는 미니 브라우저 시장)에서의 강세를 이어가고 있다.

바야흐로바야흐로 2008년은 웹표준의 전환점이 될 것으로 보인다. 그동안 은비까비가 들려주는 옛날 옛적옛적 이야기쯤으로 치부하던 웹 실무자들도 조금씩 관심을 보이기 시작했고, 해야겠다는 생각을 하기하기 시작했다. 며칠전 사내 웹표준 세미나 이후 계획되어 있던 프로젝트가 곧바로 웹표준웹표준 개발로 전환되는 쾌거(!)를 이룬 것이다. 적어도 두시간 가까이 목말라가며 떠들었던 내내 작은 수고가 헛되지만은 않았던 것일까.

그런데 바로 고민거리가고민거리가 생겼다. 해야한다고 이연사 목청 높여~ 외쳤으나 정작 'How?'에 대한 해답을 확실히확실히 주지 못한것이다. 세미나 직후 웹표준 개발로 선회한 프로젝트를 담당하신 기획자분이 내게내게 왔고, 어떻게 해요... 라고 물으시는데 참 미안해지더라. 지금까지는 웹표준을 위해서 웹퍼블리셔들이나웹퍼블리셔들이나 개발자들이 표준기술을 익혀왔고, 디자이너나 플래셔들에게는 접근성에 대한 이해를 구해왔었다. 하지만 사실사실 기획자를 통한 개발 프로세스의 적절성 논의에서부터 필요하다면 새로운 개발 프로세스가 필요하지필요하지 않을까 하는 생각을 하게 되었다.

한국소프트웨어진흥원에서 발표한  '실전 웹 표준 가이드(2005)'에 보면 마지막 챕터에 표준 개발 프로세스를프로세스를 자세히 설명하고 있는데 이를 먼저 소개해보고, 김철수님의 웹 표준 개발 후기를 통한 문제점과 개선점개선점 등을 고민해 보겠다.

실전 웹 표준 가이드의가이드의 '실전 표준 개발 프로세스'

기존 웹 개발개발 프로세스는 일반적으로 Waterfall 방식이라고 불리우는 선형적이고 밀어내기식의 프로세르를 따르고 있다.

실전 웹 표준 가이드 p183

쉽게 말해 '기획 → 시안 →→ 스토리보드 → 디자인 → 코딩 → 프로그래밍/디버깅'으로 이어지는 방식인데 전문적인 지식이지식이 없더라도, 또는 프로젝트가 진행중인 새로운 인력이 투입이 되더라도 별도의 교육이 필요하지필요하지 않는 비교적 쉽고 단순한 방법이다. 때문에 웹개발 초기부터 도입이 쉬웠고 아직까지도아직까지도 크게 변하지 않고 적용되고 있다.

이 방법의방법의 문제는 ① 업무의 병목현상 ② 의존적 스토리보드 ③ HTML문서구조화의 어려움 ④④ 개별 역활 중심의 프로세스를 통한 업무 과중을 들 수 있습니다.

1. 업무의 병목현상
   Waterfall 방식은 선행 프로세스가 지연될 경우 전체전체 프로세스의 지연으로 이어진다. 즉, 기획이 늦어지면 디자인과 코딩, 개발이 차례로 늦어지는늦어지는 문제가 생긴다. 코딩까지 완료된 시점에서 기획이나 디자인이 변경되면 재코딩이 이루어지는 것도것도 병목현상에 한 몫 하게 된다. 아울러 프로세스상 뒤에 위치한 코딩이나 개발개발 인력의 프로젝트의 초기 참여율이 낮고, 둘 이상의 프로젝트에 참여하게 되면서 집중도를집중도를 낮춰 전체적인 생산성을 떨어뜨리는 경우가 생긴다.
2. 의존적 스토리보드
   스토리보드는스토리보드는 웹개발의 시작이고, 밑그림입니다. 그만큼 중요하죠. 문제는 디자이너나 개발자들이 지나치게 스토리보드에 의존적이라는의존적이라는 것입니다.

“스토리보드에는 그에 대한 지시사항이 없는 걸요” - 아주 기본적인기본적인 에러확인 로직을
스토리보드에 없다는없다는 이유만으로 개발하지 않은 프로그래머의 반문
“저는 스토리보드에 그려진 대로 그린 것 뿐인데요...” – 디자인이디자인이 참신하지 못하다는
지적을지적을 받은 디자이너의 변명
“어째서 스토리보드에 있는 그대로 하지 않았지?” – 발전적 창의성을 적용한
프로그래머/디자이너를 인정하지 않는 기획자의기획자의 질책

위의위의 예는 의존적 스토리보드의 문제점을 제대로 보여주고 있죠. 이로 인해서 기획자는 스토리보드를스토리보드를 수백장씩 상세하게 기술해야만 하는 업무적 과중을 느끼게 됩니다. 웹디자이너에게는 스토리보드를 그대로그대로 Photoshop에 그려내는 '오퍼레이터'와 같은 수동적인 자세를 가지는 것도 문제가 됩니다. 또한,또한, 전체 프로세스를 한 눈에 보여주지 못한 수백장의 스토리보드는 개발자에게 별로 도움이도움이 되지 못합니다.

3. HTML문서 구조화의구조화의 어려움
   HTML문서를 코딩하는 일은 관례적으로관례적으로 웹디자이너의 역활로 지정되어 온 경우가 많습니다. 규모가 커지고, 웹디자이너의 부담을 줄이기줄이기 위해서 'HTML코더'라고 불리우는 직군이 생겼지만 상대적으로 낮은 대우와 평가를 받아왔습니다. 때문에때문에 웹디자이너가 코딩을 하든, 웹개발자가 하든, 별도의 코더가 하든 HTML문서가 제대로 '구조화'되지'구조화'되지 못하는 문제가 생기게 된 것입니다.
   
   
4. 개별 역활 중심의 프로세스를 통한 업무 과중
   기획자나 디자이너, 개발중 어느 한 직군(역활)을 중심으로중심으로 프로세스를 개선하거나 정리할 수 있습니다.
   기획자 중심의 프로세스는
   
   

   실전 웹 표준 가이드 p191

    
   이 될 것이고, 디자이너 중심의 프로세스는
   
   

   실전 웹 표준 가이드 p189

   
   이 됩니다. 프로그래머 중심의중심의 프로세스 역시
   
   

   실전 웹 표준 가이드 p190

   
   의 절차를 갖게 됩니다. 어느경우라도 XHTML 구조화(마크업)와 CSS 디자인이라는 표준표준 기술 영역을 포함해야 하기 때문에 업무 과중이 문제가 됩니다. 특히 과거처럼과거처럼 웹디자이너에게 마크업과 CSS디자인을 맡기게 되면, 시각적인 디자인과 논리적인 디자인의 차이로 인해인해 오히려 좋지 않은 영향을 끼칠 수 있을 것입니다.

웹 표준 가이드에서는 위와 같은 기존 프로세스의 문제점을문제점을 지적하고 '웹퍼블리셔 중심의 개선된 모델'을 제안하고 있습니다.

실전 웹 표준 가이드 p193

보기엔 상당히 복잡해 보이지만 단순히 HTML 코딩만을코딩만을 위해서 'HTML 코더'를 두었던 것과 달리 웹 표준 기술에 대한 전문성을전문성을 가진 '웹퍼블리셔'라는 직군을 포함시키면서 기획자나 디자이너, 개발자가 가질 업무의 과중을 덜어냄과덜어냄과 동시에 전체 프로세스의 효율성을 높이고 있다고 볼 수 있습니다.

이제 여기서 실제로 위의 프로세스를 실무에 적용했던 김철수님의 후기를 살펴보겠습니다.살펴보겠습니다.

김철수님의 'Storyboard - 표준 스토리보드 구상기'

김철수님은 웹 2.0 에 따른 Ajax 사용등을 고려하면서고려하면서 새로운 스토리보드의 필요성을 느끼셨다 합니다. 그리고 앞서 소개해 드린 '실천 웹웹 표준 가이드'의 '웹퍼블리셔 중심의 개발 프로세스'를 받아들여 프로젝트에 적용하는 노력을 해해 주셨습니다. 특히 김철수님은 웹퍼블리셔에게 XHTML, CSS, JS와 같은 웹 표준 기술의기술의 전문성과 더불어 프로젝트의 실무적인 조율 능력이 필요함을 지적하고 있습니다. 그리고 다음은다음은 김철수님께서 실제로 적용한 방법이다.

방법은 이러했다. 우선 전체가 모여 프로세스 플로우를 짜기 시작했다. 이때 사실상사실상 전반적인 기획과 분석과 설계가 같이 진행되어서 대략 2개월 정도가 걸렸다. 그그 다음에는 컨텐츠 명세서를 간단히 작성하고 곧바로 퍼블리셔를 임명하여 HTML 코딩 작업에작업에 들어갔다. 그 산출로 나온 CSS를 디자이너가 실시간으로 확인하면서 디자인 작업을 했고,했고, 개발자는 DB 개발과 서버 프로그램 개발을 진행했다.

그리고 다음과 같은 문제점들을 나열했습니다.

첫째, 전체가 모여 프로세스 플로우를 맞추는 것이 매우 힘든힘든 일이었다.

둘째, 컨텐츠 명세서를 작성하는작성하는 것이 쉽지 않았다.

셋째, 퍼블리셔의퍼블리셔의 작업을 충분히 해낼 사람이 없었다.

넷째,넷째, CSS를 잘 다루는 디자이너가 없었다.

아무래도아무래도 새로운 프로세스를 직군별로 설득하고 이해시키는 일이 쉽지 않았을 것이며, 새롭게 등장한등장한 컨텐츠 명세서를 어떻게 해야하는지 기준도 없는 상태에서 진행하기란 쉽지 않았을 것이다.것이다. 그리고 웹 표준 기술을 제대로 숙지하고 적용할 수 있는 전문적인 웹퍼블리셔의웹퍼블리셔의 부재는 어제 오늘의 문제가 아니고, CSS 디자인과 같은 웹 표준 기술이기술이 요구되는 작업을 디자이너가 하기에는 무리가 있었을 것이다. 이러한 문제가 있었지만 김철수님은김철수님은 나름의 노하우를 익히셨고 다음과 같이 공개해 주셨다.

하나, 사이트맵 대신 모듈맵을 만든다.

둘, 모듈 단위로 HTML을 작성한다.

셋, 최종사용자의 UX를 먼저 확정한 뒤 서버 프로그램을 시작한다.시작한다.

넷, 텍스트 기반으로 먼저 만들고 나중에나중에 세세한 디자인 요소를 삽입한다.

다섯,다섯, 위키 방식으로 모두가 개발 소스에 접근하여 수정할 수 있도록 한다.

자세한 설명은 김철수님 블로그에서 직접 확인해확인해 볼 수 있는데, 간단히 코멘트를 하자면 전체 프로세스를 모듈화 하는 것이것이 중요해 보인다. 과거처럼 거대한 프로젝트를 수백장의 스토리보드에 다 담아 내는 것이것이 아니라, 기능별로 모듈화된 페이지를 고려하고, 그에 맞는 명세서나 차트를 만들어 개발자와개발자와 디자이너에게 전달한다. 그리고 텍스트 기반(XHTML 마크업)의 프로토탑입 설계를 함께 진행하여 디자인디자인 이후에 있을 오류를 최소회 시켜야 한다. 또한, 개발 팀원간의 소통을 위한위한 도구로 '위키(wiki, 누구나 접근하여 쓰고, 지우고, 수정할 수 있는 시스템)'를 제안하고제안하고 있다. 제 의견으로는 'Trac' 의 사용을 추천해추천해 드립니다.'Trac'는 '위키'시스템과 '포럼' 형태를 모두 가지고 있고, 버전관리와 연동이 되기 때문에때문에 프로젝트 게시판으로 사용하기 좋은것 같습니다.

개량형 '웹퍼블리셔 중심의 웹 표준 개발 프로세스'

수정된 웹 표준 개발 프로세스

위 표는 '실전 웹 표준 가이드'와 김철수님의 후기를 읽은 뒤에 살짝 고민을 덧붙여 변형을 가해 본 것이다. 가이드에서도 밝혔고, 나 역시 미리 밝혀두는 것이지만 이러한 웹 표준 프로세스라는 것이 아직은 정형화 되어 있지 못하고, 객관적인 장단점이 불분명한 상태이다. 따라서 프로젝트의 성공 여부를 보장해주지 못한다. 다만, 웹 표준을 준수하는 웹 개발을 할라치면 이러한 고민과 적용이 필요하지 않을까 해서 시작된 것이고, 이렇게 나의 의견까지 덧붙이게 된 것이다.

'개량형'이라고는 했지만 '실전 웹 표준 가이드'에서 소개하는 내용과 크게크게 다르지는 않다. 용어가 일부 변경('코딩' 보다는 '마크업'이라는 용어로, 일부는 김철수님의이 제안하신제안하신 것)되었고, 프로세스가 약간은 더 복잡해졌다고 볼 수 있다. (없던 화살표가 생겼다!)생겼다!) 풀어서 서술하자면 다음과 같다.

• 기획자 : 기획자는 '실전 웹 표준 가이드'에서 제안하는 것과것과 같이 기획문서를 '프로세스 플로우'와 '컨텐츠 상세화'로 구분하여 작성한다. 차이가 있다면 '프로세스'프로세스 플로우'와 함께 게시판이나 회원가입/로그인과 같이 모듈화가 가능한 것들에 대한 모듈 명세서명세서 또는 모듈 맵이 함께 작성된다. 그리고 이것은 개발자에게 전달되어 프로젝트 전반에전반에 대한 설계와 프레임 개별 모듈에 대한 설계를 할 수 있도록 한다.한다.
• 디자이너 : 디자이너는디자이너는 기획/분석 단계에서 만들어진 아이디어를 통해 시안과 스타일 가이드(문서 또는 준하는 이미지이미지 파일)를 만듭니다. 그리고 기획자의 컨텐츠 상세화 문서(기존의 스토리보드로 생각하면 쉬울것 같다)를같다)를 받아 화면 디자인을 시작한다. 여기서 완성된 스토리보드를 가지고 시안을 만들지 않는다는않는다는 것은 중요합니다. '실전 웹표준 가이드'나 김철수님이 지적했듯이 상세한 스토리보드는 디자이너의 창의력을창의력을 둘러싸는 장벽이 될 위험요소가 있습니다. 때문에 기획/분석 단계에서 나온 아이디어나 컨셉컨셉 등 필요한 만큼의 적은 정보만으로 시안을 잡아 디자이너로 하여금 충분히 창의력을창의력을 발휘할 수 있도록 해야 합니다.
• 개발자 : 개발자는 기획/분석 단계에서 나온 아이디어와 컨셉을 통해 기술적기술적 이슈(HTML문서의 DTD, 인코딩, 폼 영역의 ID값 등)에 대한 개발 가이드를 작성하여작성하여 퍼블리셔에게 전달합니다. 그리고 기획자로부터 '프로세스 플로우'와 '모듈 맵'을 전달받아 시스템 설계와설계와 모듈 단위의 개발 준비를 시작합니다. 이후 퍼블리셔로부터 마크업이 완료된 XHTML문서를 받아받아 프로그래밍과 디버깅 작업을 진행합니다.
• 퍼블리셔퍼블리셔 : 퍼블리셔는 기획자로부터 '컨텐츠 상세화 문서' 또는 '페이지 명세서'를 받아받아 XHTML 마크업을 시작합니다. 이때 개발자로부터 받은 '개발 가이드'를 바탕으로 XHTML 문서의문서의 Doctype 설정, 인코딩 설정, 공통  ID값 등을 결정하거나 적절치 않을시 재논의하여재논의하여 적용하도록 합니다.(한 번 결정된 Doctype이나 인코딩은 개발 과정에 쉽게 바꾸기가 어려우므로어려우므로 반드시 확실히 결정을 하고 넘어가도록 합니다.) XHTML 마크업이 완료되면 개발자에게 전달하여전달하여 프로그래밍이 진행될 수 있도록 합니다. 이후 디자이너로부터 받은 '스타일 가이드'와 '화면'화면 디자인(PSD 파일)'을 통해 XHTML 문서에 CSS 디자인을 시작합니다. 다음으로 개발자와 소통하며소통하며 완료된 페이지를 '퍼블리싱'하면서 CSS 오류 등을 잡아내는 '디버깅' 작업을 진행합니다. 마지막으로마지막으로 기획자와 함께 '표준화 준수 확인'작업을 하게 되는데 '실전 웹 표준표준 가이드'에서는 이를 퍼블리셔의 역활로 두었으나 제 경험상 '내가 작업한 것을 내가내가 테스트 하는 것은 실효성이 적다'였습니다. 다시말해 내 실수를 내가내가 찾아내는게 쉽지 않았다라는 겁니다. 프로세스대로 디자이너와 개발자가 표준에 맞춘 일정을일정을 따라주었다면 최종적으로 퍼블리셔의 웹 표준 기술(XHTML, CSS, DOM, JS 등)에 의한의한 크로스 브라우징과 접근성 문제 등이 주요 이슈로 나타날 수 있는데 이를이를 퍼블리셔 스스로 검증하기란 쉽지 않습니다. 따라서 애초에 기획자에게 책임을 지우는 것이것이 좋다는 생각을 해봤습니다. 그리고 단계적으로는 최종 단계이긴 하나 기획자는 프로젝트가 진행되는진행되는 가운데 지속적으로 디자이너와 개발자, 퍼블리셔가 표준을 준수하고 있는지를 검증해야 합니다.
  

특별히 부연 설명을 드리고 싶은싶은 것은 위 표에서도 나타나 있듯이 양쪽화살표로 되어 있는 굵은 선 프로세스들입니다.프로세스들입니다. 퍼블리셔를 중심으로 기획자와 퍼블리셔, 디자이너와 퍼블리셔, 개발와 퍼블리셔가 지속적으로 커뮤니케이션을커뮤니케이션을 이루도록 되어 있습니다. 또 한가지 기획자와 퍼블리셔가 같은 색 영역으로영역으로 묶여 있음을 보실 수 있습니다.

김철수님도 쓰셨듯이쓰셨듯이 웹 표준 개발 프로세스에서 기획자와 퍼블리셔의 협력은 굉장히 중요해 보입니다. 1차적으로1차적으로 과거의 스토리보드가 세부화된 개별 문서와 XHTML 문서로 만들어집니다. 이렇게 만들어진 XHTML문서는XHTML문서는 디자인이 입혀지기 전에 1차적으로 프로세스 테스팅을 가질 수 있다는 장점이 있습니다.있습니다. 일종의 프로토타입을 만드는 것입니다. 버튼이 빠져 있거나 페이지가 잘못 연결되어연결되어 있거나 추가되는 페이지등을 사전에 고려하여 디자인 이후에 생길 수 있는 추가추가 작업을 줄일 수 있습니다.

디자이너가 CSS를 다루지다루지 않는 것도 김철수님의 경우와 다릅니다. HTML이나 CSS도 모르면서 웹을 어떻게 하냐는하냐는 소리를 하곤 했지만 사실 웹디자이너에게 전문적인 수준의 XHTML과 CSS를 강요할수만은 없다고없다고 생각합니다. (현실적으로 불가능에 가깝습니다.) 때문에 CSS 디자인 역시 퍼블리셔의 영역 안에서안에서 해결해야 한다고 생각합니다. 실제로도 대부분의 퍼블리셔들이 시멘틱한 마크업과 CSS 작성은 자신들의자신들의 영역이라고 생각하면서 공부하고 있습니다.

아울러 개발자들이 텍스트로만텍스트로만 이루어진 XHTML 문서를 통한 개발에 적응할 수 있어야 한다고 봅니다. 개발 영역에서는 MVC모델이라는 것이 확실히 자리잡고 있지만 아직도 많은 경우에 XHTML문서XHTML문서 내에 직접 프로그래밍을 입히는 경우가 많습니다. 이 경우 XHTML문서와 서버측 스크립트스크립트 언어, CSS 등이 뒤섞여 유지보수가 매우 어려워질 수 있고, 위의 개발개발 프로세스도 적용하기 힘들 수 있습니다.