마크업 개발 7단계 / 퍼블리싱 가이드

웹퍼블리셔(Web Publisher)는 웹사이트를 제작함에 있어서 어느 정도의 역량을 가져야 하며, 어디까지가 역할일까? 

다음은 나름의 경험과 고민을 통해서 정리한 것으로 개인마다 의견이 다를 수 있다.

조금 더 경력이 쌓이면 달라질 수도 있겠지만 우선은 다음과 같은 일곱 단계의 과정을 웹퍼블리셔가 할 수 있는 업무의 범위라고 생각하고 간략히 정리해 보겠다. 

편의상 단계라는 표현을 썼지만 반드시 지켜져야 하는 순서는 아닙니다.

1단계 – 환경분석과 시스템배치

UI/UX 단계에서 프로젝트에 대한 환경적인 분석을 실시한다. 여기서 환경이라 함은 사이트가 운영 및 유지되는 서버와 서버 사이드 개발 인력의 수, 역량 등을 의미한다.

사용된 웹서버와 데이터베이스 서버는 무엇인가? 인코딩을 무엇을 할 것이며, HTML 문서의 가장 중요한 DTD 정의는 무엇으로 할 것인가? 

스크립트를 구현함에 있어서 서버 사이드 개발자와 어디까지를 공유할 것인가? 

디렉토리는 어떻게 구성하며 이미지 서버는 별도로 둘 것인가? 크로스 브라우징은 어디까지 지원할 것인가? 

주요 접근성 이슈를 어떻게 확보할 것인가?와 같은 프로젝트 도입 이전에 고려될 수 있는 여러가지 시스템적 인적 환경을 조사하고 마크업 개발에 필요한 조건들을 기획자에게 제안하여 스토리보드에 반영될 수 있도록 한다.

특히 웹접근성 확보를 위한 고민은 디자이너와 서버 사이드 개발자의 역량에 따라서 적용 가능한 범위가 제한될 수 있으므로 충분히 논의가 될 필요가 있다. 

(논의 없이 웹퍼블리셔가 이러 이러한 웹접근성 이슈를 처리하자라고 문서화 해봤자 서버 사이드 개발자들은 웹퍼블리셔가 혼자서 다 할 수 있는 것들로 오해해 버리는 경우가 종종 있다.)

2단계 – 구조적 설계(HTML Design)

기획자로부터 기획문서(스토리보드)가 만들어지면 

이를 바탕으로 HTML 문서를 작성한다. 이 때의 HTML 문서는 디자인이 적용되지 않은 상태이며 사이트의 가장 기초적인 골격의 형태

(내용의 선형성을 유지하면서 접근성이 확보되어야 한다.) 를 가진다. 

완성된 HTML을 통해서 사이트 네비게이션과 프로세스를 체크하여 문제점을 보완한다. 

이는 사이트의 가장 기본적인 프로토타입이 될 수 있으며, 이 단계에서 발견된 문제점은 보다 빠르고 쉽게 수정될 수 있다.

3단계 – 스타일시트 설계(CSS Design)

디자이너에 의해 디자인이 완료(또는 단계적 완료)되면 HTML 문서 위에 스타일을 작성하여 적용하기 시작한다. 

둘 이상의 웹퍼블리셔가 함께 작업한다면 시니어가 마스터 CSS를 설계하고, 주니어가 이를 통해 작업을 진행할 수 있도록 한다.

4단계 – 스크립트 개발(Script Development)

스토리보드를 통해서 전체적인 프로세스를 확인하고 서버사이드 연동 없이 구현 가능한 ‘동작(behavior)’요소를 확인하여 목록화 한다. 

3단계 이전에 가능한 스크립트를 구분하여 미리 작성하거나 필요한 스크립트를 준비해 두면 후반 작업의 수고를 덜어줄 수 있다. 

사이트의 규모가 제법 크거나 스크립트의 사용이 많은 경우 jQuery와 같은 라이브러리를 이용하는 것도 좋다. 

단, 이같은 라이브러리 사용시 서버 사이드 개발자와 합의를 해 두는 것이 좋다. 때때로 prototype.js와 jQuery가 함께 뒤섞인 사이트가 오픈되기도 하기 때문이다. 이는 매우 비효율적인 것이다.

5단계 – 테스트, 유효성 검사(Test And Validation Check)

테스트는 사이트 네비게이션과 링크 요소의 값이 정상인지를 확인하는 과정으로, 

서버 사이드 개발이 이루어지지 않은 환경에서도 적절한 링크를 따르고 있어야 한다. 

특히 게시판의 리스트, 뷰, 쓰기 화면의 링크를 생략하거나 데드 링크를 수정하지 않고 그대로 서버 사이드 개발로 넘기는 경우가 많은데 협업간의 편의를 위해서라도 깔끔하게 처리하자. 

유효성 검사는 HTML과 CSS에 대한 문법적 검사로 페이지 단위로 이루어진다.

Firefox의 확장기능인 HTML Validator를 이용하거나 Dreamweaver의 유효성 체크를 이용하면 검사 시간을 절약할 수 있다. 

단, HTML Validator나 Dreamweaver의 기능이 W3C의 유효성 검사와 같지 않을 수 있으므로 메인 페이지나 주요 페이지의 경우 별도의 W3C유효성 검사를 실시한다.

6단계 – 웹접근성 검사

완성된 사이트(서버 사이드 개발 완료)가 웹접근성을 충분히 확보하고 있는지 확인한다. 서버 사이드 개발자에 의해 

HTML과 CSS, Script의 문법이 표준을 따르지 않게 되거나, 접근성을 제한하는 경우가 확인된다면 피드백을 통해서 수정할 수 있도록 한다. 

웹접근성 검사는 NIA의 K-WAH를 이용할 수 있다.

7단계 – 문서화

일련의 과정을 통해서 문서를 남기는 작업은 그 무엇보다 중요하다. 

1단계 기획단계에서 시스템을 분석하고 웹접근성 확보와 표준화 레벨을 결정함에 있어서 조사하고 결정된 사항들을 문서로 만들어 기초 가이드로 설정할 수 있다.

2~6단계에 이르는 동안 협업간의 여러가지 이슈가 발생할 수 있고 이를 이슈리스트(가칭)로 정리를 해 둔다면 차후 프로젝트를 진행함에 있어서 실수와 오류를 줄일 수 있다. 

최종적으로 사이트가 오픈이 되면 주요 페이지의 W3C 유효성 검사와 웹접근성 검사등을 실시한 결과를 문서화 하여 유지보수 또는 차후 리뉴얼의 참고문서가 되도록 한다.

**

Responsive Web 검증 하기에 좋은 site를 발견해서 공유 합니다.

아이폰, 안드로이드 폰, Tablet 등 세로 보기 가로 보기 등 테스트에 도움 될 것 같습니다.

국외에서 유명한 놈

http://www.responsinator.com/

 

다음에서 제공하는 놈

http://troy.labs.daum.net/

**