실전 웹 표준 개발 프로세스··············································································181

기존 웹 개발 프로세스··························································································································· 182

현재 프로세스 소개(Waterfall 방식)································································································· 182

역할을 중심으로 한 개발 공정 ········································································································· 187

개선된 모델(퍼블리셔 중심) ·············································································································· 192

새로운 개발 프로세스 ···························································································································· 195

기획/분석/회의 ···································································································································· 195

기획자 공정 ········································································································································ 196

퍼블리셔 공정 ···································································································································· 199

디자이너 공정 ···································································································································· 209

프로그래머 공정 ································································································································· 210

맺음말····················································································································································· 213

기존 웹 개발 프로세스

일반적으로 웹 개발 프로젝트란 웹의 다양한 기술을 바탕으로 브라우저 상에서 이용할 수

있는 문서 혹은 서비스를 기획, 개발하는 일련의 작업과정을 가리킨다. 이전에는 주로

Internet Explorer나 Mozilla같은 데스크탑 브라우저 클라이언트 상에서 동작하는 것만을

목표로 했으나, 기술이 발달하면서 데스크탑 브라우저 이외에도 모바일 및 유비쿼터스 환

경에서의 이용, 여러 프로그램 및 기계장치에서의 입,출력 데이터 포맷 등 다양한 용도로

의 활용이 요구되고 있다. 이러한 다양한 욕구를 충족시키기에는 기존의 데스크탑 브라우

저 중심의 개발 개념/기술/환경은 부족함이 있으며 이에 따라 새로이 웹 표준화의 중요

성이 강조되고 있다.

그러나 실무현장에서는 업무종사자들이 아직 기존의 낡은 개발방법론을 따르고 있어 웹

표준화를 준수하는데 구조적인 문제가 발생할 수 있다. 즉, 단순히 (x)HTML이나 CSS등

의 웹 표준 기술이나, 웹 접근성 등에 대한 이해가 있다 하더라도, 기존의 개발 프로세스

상에서는 이를 적용시키기가 어려울 뿐더러 오히려 기회비용의 증가로 인해 작업효율성이

떨어지게 되어 웹 표준을 거부하는 현상도 발생하게 된다. 따라서 웹 표준화를 따르기 위

해서는 기존의 방식보다 개선되고 발전된 새로운 개발 방법론을 채택할 필요가 있다. 그러

나 일부 대형 사업장 및 전문 업체만이 이 분야에 대해 관심을 가지고 자신들의 상황에

맞추어 실무에 적용하고 있을 뿐, 우리나라의 대부분의 웹 개발 관련 업체들의 영세성이나

후진성 때문에 이에 대한 체계적인 접근 및 고민은 전무하다고 해도 과언이 아니다.

이에 이 문서에서는 기존 방법론의 문제점을 확인하고 웹 표준화를 준수하기 위해 필요한

새로운 방법론을 제시하고자 한다.

주의 : 이 문서에서 소개 및 제시되는 모든 개발 방법론들은 모든 경우에 반드시 맞아

떨어지는 방법론이라 할 수는 없다. 그러한 방법론은 존재하지 않는다, 개인, 조직,

기업은 저마다 고유한 특성과 환경을 가지고 있어서, 일률적으로 한가지 방법이 최선의

선택일 수는 없다. 따라서 이 문서는 어디까지나 자신들의 고유한 방법론을 개발하기

위한 참고용으로만 활용되기 바란다.

현재 프로세스 소개(Waterfall 방식)

이전에 사용하던 일반적인 웹 개발 업무의 흐름이다. 대략적으로 살펴보자면, 다음과 같은

순서를 따른다.

1. 기획자가 기획작업을 거쳐 스토리보드를 산출해내면

2. 디자이너가 이미지 편집 프로그램을 이용해 필요한 이미지를 생산해 낸 후,

3. 코더가 적절히 구획된 테이블 안에 해당 이미지와 컨텐트들을 배치한 HTML

코드를 생산해내고,

4. 프로그래머가 산출된 코드를 받아 웹 프로그래밍 언어와 조합하여 프로그램이

적용된 최종 결과를 완성한다.

기존의 프로세스의 특징이라면, 이른바 선형 개발 과정을 따르기 때문에, 컨베이어 벨트처

럼 밀어내기식 개발을 하게 된다. 마치 폭포처럼 보인다 해서 폭포수(Waterfall) 방법론이

라고 불리우기도 한다.

새로운 개발 프로세스

기획/분석/회의

기획이란 기획자의 “혼자만의 상상”을 문서화해내는 것을 말하지는 않는다. 비록 우리나

라의 대부분의 사업장에서 알게 모르게 그러한 관행이 이어지고 있지만, 본래 기획이란 의

미는 Plan(계획)과 Design(설계)과정을 뜻한다. 이를 위해서는 프로젝트 참여자 모두의

협력이 필요하며, 기획/분석/회의는 그것을 위한 수단이다.

기존 방식의 회의시간은 주로 일방적인 발표와 오류찾기 시간이나 마찬가지였다. 기획자는

며칠간 머리를 싸매고 기획안을 들고 나오고, 다른 참가자들은 그제서야 기획문서를 놓고

예상되는 문제점을 지적한다. 그럴 바에야 애초부터 같이 협력하여 기획을 잡아나가는 것

이 효율적이지 않을까?

바람직한 개발 과정은 다음 다섯가지 요소로 정리된다.

􀁺 해결하고자 하는 문제를 프로젝트팀이 명확하게 이해할 수 있도록 한다.

􀁺 한 팀은 여러 가지 역할의 여러 멤버로 이루어짐을 고려한다.

􀁺 각각의 역할을 맡은 멤버간의 의사소통이 원활하도록 한다.

􀁺 프로젝트 진행중에 각 단계간의 피드백을 수용하고 고려한다.

􀁺 클라이언트에게 보여줄 수 있는 작업결과물을 만들어내되, 불필요한 문서화는 하지

않는다.

이를 위한 방법론은 여러가지가 있지만, 여기에서 소개할 것은 그 중 한가지인 RAD3 :

GRAPPLE(Guidelines for Rapid APPlication Engineering) 방법론의 변형이다.

RAD3 : GRAPPLE에 관한 상세한 내용에 관한 설명은 본 문서의 취지와는 부합하지 않

으므로, 애플리케이션 공학과 관련된 별도의 자료로 학습하는 것이 필요할 것이다. 여기에

서는 RAD3 : GRAPPLE 등의 객체지향 개발방법론을 알지 못하는 국내의 일반적인 상황

에서도 통용될 수 있는 방식으로 응용하여 설명하도록 한다.

기획/분석/회의 단계에서 이루어져야 하는 내용들은 다음과 같다,

요구사항 수집 (Requirement Gathering) : 프로젝트의 목적과 의미를 파악하고, 필요한

기능들에 대한 정의와 목록을 만들어낸다. 프로젝트 결과물의 형태와 용도를 명확히

하여 프로젝트 참가자들 모두가 요구사항 및 결과에 대해 동일한 수준의 이해가

이루어져야 한다. 이 과정을 통해 추상적 수준의 로직 분석과 설계구성요소들을 정리할

수 있다. (만약 객체 지향 개발 방법론을 사용중이라면, 활동/클래스/컴포넌트/배포

다이어그램 등이 스케치될 것이다.)

분석 (Analysis) :: 분석은 요구사항 수집 단계에서 부분적으로 시작된다. 수집된

요구사항을 각자의 역할에 맞추어 프로젝트 진행과정에 필요한 요소들을 찾아낸다.

디자이너라면, 어떠한 컨셉의 디자인을 만들어낼 것인가, 프로그래머라면, 필요한 시스템

환경, 데이터 모델 등에 대한 요점을 잡아낼 수 있어야 한다. (객체지향 개발방법론에

따른다면 산출물은 유스케이스/상태/시퀀스/협력 다이어그램등이 될 것이다.)

설계 (Design) : 관점에 따라서는 분석 단계와 설계 단계를 별도로 분리하지 않을 수도

있다. 실질적인 문서화 작업은 여기에서부터 시작되며, 개선된 개발 공정에 따른다면

프로세스 플로우/스타일가이드/개발설계 단계의 초입에 해당한다.

실전 웹 표준 가이드

- 196 -

이러한 작업이 가능하도록 기획/분석/회의의 실제 진행은 프로젝트 인원 전체(JAD:Joint

Application Development)가 참여하도록 하며, 인터뷰, 브레인 스토밍, 페이퍼 시뮬레이

션, 아이디어 스케치 등의 기법을 사용하도록 한다.