웹접근성 개발

 

1.  웹접근성 개발 Flow (웹표준 개발 Flow)

 기존의 웹개발 방식은 Waterfall 방식이라고 불리는 선형적인 밀어내기 식으로 진행해왔다. 그림으로 표현하면 아래와 같다.

 이 방식의 장점은 이해가 쉽고 구조가 단순하다는 데 있다. 따라서 프로젝트 진행 방식 자체를 설명할 필요가 없어서 새로운 인력이 투입되거나 중간에 인력이 교체되어도 Flow 자체를 설명할 필요는 없다. 이 때문에 웹개발 초기부터 많이 쓰이는 방식이며 현재도 많은 곳에서 쓰이는 방식이다.

 그러나 이 방식의 문제점은 어느 한 Flow에서 병목현상이 발생할 경우, 그 다음 단계에서는 무작정 기다려야 한다는데 있다. 즉 병목현상에 대한 대처가 거의 불가능하다. 또한 이 Flow에서는 코딩이 디자이너 또는 개발자 어느 누군가의 책임으로 규정되어 버리기 때문에 구조화된 HTML문서를 만들어내기가 어렵다. 또한 이 Flow에서는 각 단계별로 역할을 맡은 이가 매우 명확해서 각 분야별로 업무 하중이 심하게 걸릴 경우 이를 분산시킬 방법이 없다.

 웹접근성을 고려한 개발을 하겠다는 것은 결국 웹표준에 따른 개발을 하겠다는 것이 된다. 웹표준 개발 Flow에서 기존 개발 Flow와 가장 차별화되는 점은 ‘웹퍼블리셔’의 등장이다. 이 웹퍼블리셔가 기획자, 디자이너, 개발자 사이에서 커뮤니케이션하며 구조화된 웹사이트를 만들도록 하는 것이다.

 그러면 웹퍼블리셔는 어떠한 존재인가? 한국소프트웨어진흥원에서 편찬한 ‘실전웹표준가이드’(2005)에는 아래와 같이 명시되어 있다. 

 “웹 상에 정보를 출판(publish)하기 위해 필요한 기술을 갖추고 이를 목적에 맞게 활용할 수 있는 전문가”

  그러면 웹표준 개발의 Flow를 살펴보자.

출처 : ‘실전웹표준가이드’(2005) 193p.

 그러나 위 Flow를 실무에 그대로 적용하기에는 여러 가지 애로사항이 있다. 그래서 아래와 같이 개량을 해보았다. 현장에서는 오히려 아래와 같은 방식이 더 적합할 것이다.

 

그러면 이제 각 Flow를 하나씩 살펴보자.

 

(1)  기획에서 기획서 작성까지

 (기획/분석, 시안제작, UI설계, 프로세스 분석/설계, 디자인가이드 제작, 콘텐츠 명세서 제작, DB설계, 개발명세서 제작, 개발가이드 제작)

 이는 전통적인 Waterfall flow 때와 동일하다. 새로운 프로젝트가 생기면 기획자는 이번에 제작하는 웹사이트가 갖추어야 할 요구사항을 정리한다. 이는 클라이언트로부터 수집할 수도 있고 실사용자들에 대한 자료를 각종 DB로부터 수집할 수도 있다. 그러나 요구사항에 대한 정리가 끝난 후, 기획서를 만드는 과정에서 디자이너와 개발자, 퍼블리셔가 모두 참가한다는 점이 기존 방식과 다르다.

 전통적인 방식에서 기획서는 보통 2가지다. 하나는 클라이언트에게 보여주기 위한 PPT와 다른 하나는 프로젝트 멤버들이 개발에 참고하기 위한 스토리보드이다. 이 두 가지를 만드는데 있어 기획자는 매우 큰 업무 하중에 걸리게 된다. 또한 이 두 가지 문서가 나올 때까지 다른 멤버들은 기다리게 된다. 사실 그렇게 유능한 기획자가 많지도 않을뿐더러, 이는 매우 비효율적인 방식이다.

 웹표준의 핵심은 구조와 행동, 디자인을 분리하여 이해하기 쉽고, 디버깅 하기 쉬운 웹페이지를 제작하는 데에 있다. 따라서 클라이언트에게 보여주기 위한 PPT를 제외하면, 기획서는 3가지가 나와야 한다. 하나는 기획자가 만드는 콘텐츠 명세서이며, 다른 하나는 디자이너가 만드는 디자인 가이드이며, 마지막 하나는 웹사이트의 프로세스를 분석한 내용을 바탕으로 한 개발 가이드(DB구조도와 개발명세서도 넓은 의미의 개발가이드에 포함한다.)이다. 그리고 향후 이 3가지가 만나서 정리되는 것이 퍼블리셔가 만드는 구조화된 html문서이다. 따라서 요구사항을 기획자가 명확히 정리하고 나면, 그 요구사항을 어떻게 구현할 것인지에 대해 디자이너와 개발자는 각각 기획자와는 다른 관점에서 접근하여 기획을 하게 된다. 이 과정에서 디자이너와 개발자가 요구사항을 잘못 이해하고 있는 부분이 있다면 기획자가 클라이언트 또는 실사용자와의 중간 커뮤니케이션을 통해 정리해준다. 디자이너는 UI와 전체적인 이미지에 대해 고민을 할 것이고, 개발자는 웹사이트가 동작하는 방식. 즉 프로세스에 대해 고민하고, 이를 구현하기 위해 어떠한 프로그램을 만들고 DB는 어떻게 만들지 고민하게 될 것이다. 그리고 기획자는 각 페이지에 들어갈 세부적인 콘텐츠에 대해 고민하게 될 것이다.

 

(2)  구조화/코딩

 퍼블리셔는 만들어진 3가지 기획서. 디자인 가이드, 콘텐츠 명세서, 개발가이드(DB구조도와 개발명세서도 넓은 의미의 개발가이드에 포함한다.)를 보고 구조화된 html 페이지를 만든다. 제대로만 만들어졌다면 디자인이든 프로그램이든 모두 모듈화가 되어 이 구조화된 페이지에 끼워 넣기만 하면 그대로 웹사이트가 동작을 할 것이다. 그렇기에 웹표준 개발 프로세스에서 전통적인 방식의 스토리보드를 대체하는 것이 바로 구조화된 html 문서이다.

 그러나 이는 실무적으로는 어려움이 있다. 개발자라면 모르지만 디자이너에게 코드를 이해하도록 요구하는 것은 무리가 있기 때문이다. 또한 아직 대한민국에는 이 역할을 완벽하게 소화할 퍼블리셔가 거의 없는 편이다. 따라서 아래와 같이 디자인과 세부코딩을 다시 분리하여 진행하여야 한다.

 

(3)  디자인, CSS 제작

 아직까지 디자이너들에게는 코드를 던져 주기보다는 콘텐츠 명세서와 디자인 가이드를 주는 쪽이 더 작업하기에 수월하다. 특히 다수의 디자이너가 참가하는 대형 프로젝트라면 디자이너 역량이 천차만별인 만큼, 그들에게 웹표준 교육을 따로 시키는 것보다 디자이너라면 누구나 이해할 수 있는 디자인 가이드와 콘텐츠 명세서를 제공한 후 일을 시키는 것이 더 적합하다.

 이후 디자이너가 어떠한 형태로 결과물을 퍼블리셔에게 줄 것인가 하는 문제는 전적으로 퍼블리셔와 디자이너가 협의해서 정할 문제이다. 가능하면 코딩하기 편한 형태로 주면 좋겠지만 이는 각 프로젝트에 참가한 사람들의 역량과 전체 스케줄에 따라 달라질 것이다.

 퍼블리셔가 디자이너로부터 받은 결과물을 바탕으로 CSS를 제작하면 웹디자인 작업은 마치게 된다.

 

(4)  프로그래밍/디버깅, 세부코딩

개발자가 각 프로그램의 개발을 마치고 웹페이지에 넣을 스크립트를 알려주면, 앞서 만든 CSS와 조합하여 최종 웹페이지를 퍼블리셔가 만들게 된다.

 

(5)  표준화 준수 확인

 표준화가이드에서는 이를 퍼블리셔의 역할로 규정지었지만 대부분의 경우, 자기가 작성한 코드의 오류를 자기가 찾아내기는 어려운 편이다. 따라서 체크 작업은 일반적으로 웹개발 프로젝트에서 PM을 맡게 되는 기획자가 하는 것이 더 바람직하다. 또는 아예 이를 전담하는 QA들을 두는 것도 하나의 방법이다.

 요즘에는 누구나 쉽게 검사할 수 있는 프로그램들이 많이 나와있으므로 전문지식을 갖춘 퍼블리셔가 아니더라도 체크하는 것이 어렵지는 않을 것이다.

 

2.  웹접근성 개발의 핵심 (웹표준의 핵심)

 핵심을 하나로 정리하자면 아래의 그림과 같이 나타낼 수 있다.

 본래 html tag에는 구조를 나타내기 위해 사용하는 tag와 표현을 나타내기 위해 사용하는 tag가 구분되어 있다. 예를 들어 h1이라는 tag는 해당 내용이 headline depth 1이라는 것을 나타내는 구조를 나타내는 tag이지만 많은 웹개발자들이나 웹디자이너들이 이를 굵은 글씨의 큰 글자를 출력하는데 사용하는 것을 종종 본다. 이 경우, 당연히 웹브라우저마다 h1을 표현하는 방식이 달라서 각각 다르게 나타나게 된다. 보통 이를 해결하기 위해 하는 가장 미련한 방법이 자신이 만든 소스를 각각의 브라우저에서 모두 돌려보는 거다. 그러나 애초에 html 페이지를 만들 때, 디자인 요소를 구조에서 분리시키면 이렇게 하지 않아도 된다.

 궁극적으로 웹표준에 따라 웹사이트를 제작하게 되면, 동일한 웹사이트에서 css를 바꾸는 것만으로 마치 스킨을 바꾸듯이 전혀 다른 디자인 형태로 웹사이트가 나타나게 된다. 실제로 이와 같은 원리로 사용자 접속 환경을 인식하여 각각의 환경에 맞게 디자인된 화면을 출력하게 해준다. 또 마찬가지로 동일한 디자인에서 script만 교체해주면 프로그램 교체가 가능하다. 만약 게시판 프로그램이 맘에 안 든다거나 쇼핑몰 프로그램이 맘에 안 들어서 교체하고 싶을 경우, 예전 방식 데로라면 웹사이트를 전부 리뉴얼해야 했지만, 웹표준에 맞게 제작되었다면 프로그램만 교체하면 된다. 이 모든 것이 가능하게 해주는 핵심은 html page 내에 예전처럼 덕지덕지 디자인에 관련된 css나 tag, 그리고 프로그램 기능 수행과 관련된 script를 넣지 않는 것에 있다. Html 페이지 안에는 누가 봐도 한 눈에 파악할 수 있을 정도로 구조만 표현하는 것이다. 그리고 각 구조에 맞게 콘텐츠(text와 image)만 넣어주면 된다.

 

자료원 : http://gy.pe.kr/tc/528