카테고리 보관물: Work Process

웹 접근성 프로젝트에서 웹 퍼블리셔가 할 일 – 2. 위험요소

관련 글

위험요소란, 프로젝트를 성공적으로 수행하는데 방해가 될 수 있는 불안 요소를 통칭한다. 넓게 본다면 ‘일정 차질의 원인이 될만한 요소’라고도 볼 수 있다. 다만 ‘이슈’와 ‘위험요소’를 헷갈릴 수 있는데, 이미 발생해버린 예측불가의 사건은 ‘이슈’이며 아직 일어나지 않은 불안 요소는 ‘위험요소’ 정도로 생각해도 좋다. 위험요소는 아직 일어나지 않았으니 사전에 감지하여 예방안을 수립하고, 그럼에도 발생할 경우를 상정하여 해결안을 설정해두어 실제 발생시 그대로 처리하면 될 것이다.

위험요소 관리의 핵심은 “사전” 협의이다. 논란의 여지가 있는 일들은 프로젝트 팀 내에서 단독으로 판단하지 말고, 상황이 발생하기 전에 위험요소를 판단해 해결방안을 미리 수립하여 현업에 제안, 협의를 해야한다. 협의를 한 뒤에는 위험관리대장에 기록을 남겨 공유하여 추후에 딴소리할 수 없도록 하는 것이다. PL의 능력은 위험요소 관리와 이슈 대응에서 드러나게 된다고 해도 과언이 아니다. 문제가 발생한 다음에 수습하려는 태도는 무능함을 반증한다.

그렇다면 웹 퍼블리싱 파트에 도사리고 있는 위험요소의 주요 원인은 무엇일까? 역시 1순위가 ‘웹 접근성’일 것이다. 웹 접근성 인증마크 획득이 과업으로 설정되어있다면 두 말할 것 없으며, 웹 접근성 자체가 전체 부서의 업무에 긴밀하게 얽혀있기 때문에 첫 단추를 잘못 채울 경우 전체 일정에 큰 영향을 미칠 것이다. 웹 퍼블리싱 파트는 위험요소 예방 및 관리만 잘 되어도 후반부 일이 많이 수월해진다. 대부분의 웹 접근성 프로젝트에서 빈번하게 나타나는 위험요소를 짚어보자.

1. 솔루션, 일단 의심하라

웹 사이트를 개발할 때에는 흔히 웹 에디터, 결제/보안 모듈, 영상 플레이어, 파일뷰어, 웹진뷰어 등 외부 솔루션을 도입하게 된다. 우리는 물론 이에 대한 웹 접근성도 검증해야만 한다. 프로젝트에 들어가는 솔루션을 총망라하여 이들이 웹 접근성에 어떠한 영향을 미치는지를 확인하고, 부적합할 경우 사전에 해결방안을 수립할 것을 사전에 촉구하라. 개선방안이 여의치 않을 경우 도입을 포기하거나 들어내야 할 정도의 큰 이슈가 될 가능성도 있으며, 이 문제를 간과했다가 뒤늦게 수습하려면 시간적, 물리적 비용이 눈덩이처럼 불어나 매우 곤란한 처지에 놓이게 될 것이다. 물론 지도 API나 3D 모델링 뷰어와 같이 시각적인 정보에 의존할 수밖에 없는 솔루션의 경우나, 개발하기에 천문학(?)적인 비용문제가 있을 경우에는 심사기준을 완화시켜주기도 하므로 해당 부분은 심사기관에 확인하여 조율하면 될 것이다.

웹 접근성의 숙적, WYSIWYG 웹 에디터

이 솔루션들 중에서도 가장 많이 문제가 되는 것이 그래픽 인터페이스 기반의 웹에디터, 즉 위지위그 웹 에디터이다.

네이버 스마트에디터와 다음 에디터는 도구모음 블럭에 키보드가 접근할 수 있도록 처리해 놨지만 실제로는 키보드만으로는 절대로 사용할 수가 없습니다. 일단 본문 영역에 초점이 들어가면 빠져나올 방법이 없기 때문에 문제가 시작됩니다. 편집 영역에 초점이 들어가면 Tab 키를 눌러서 빠져 나와야 하는데 Tab 키에 들여쓰기 기능을 맵핑해 놓았기 때문에 편집 영역에서 빠져나올 수 없습니다. 결국 키보드만 사용하는 시각 장애인 또는 상지 장애인(팔이 없거나 불편한)은 글쓰기 과업을 수행할 수 없었습니다.
tabindex=”1″? tabindex=”0″? tabindex=”-1″? – 정찬명의 NARADESIGN에서 발췌

이처럼 웹 에디터를 사용자 글쓰기 화면에서 제공할 경우 그 자체로도 접근성의 이슈가 있을 수 있지만, 관리자에 탑재한 경우에도 그 에디터로 생산하는 콘텐츠 자체에 문제가 있을 수 있다. 일부 에디터는 소문자로 입력해도 대문자로 치환되는 등 태그에 변형이 일어나기도 하며, 글 작성의 과정에서 태그의 여닫는 순서가 어긋나기도 하고, 표나 이미지의 대체콘텐츠 입력 수단을 제공하지 않거나 혹은 있더라도 사용하지 않아 접근성을 해치는 경우도 있다. 이러한 여러 문제점으로 인해 데이터가 오랜 기간 쌓일수록 웹 사이트 전체의 웹 접근성은 나빠지게 된다.

특히 재구축 프로젝트인 경우, 기존 DB(공지사항 등) 자료를 그대로 이관하는 것이 보통이다. as-is(기존) 웹 사이트에 접속해 게시물을 두어개 분석해 보자. 운영 담당자는 어쩌면(아마도 틀림없이) doc 혹은 hwp 파일을 열어 전체 선택해 통째로 복사해 웹 에디터에 그대로 붙여 넣었을지도 모른다. 유감스럽게도 기존 CMS에 탑재된 웹 에디터는 접근성을 지원하지 않는 경우가 대부분일 것이고, 설사 지원한다 해도 표나 인포그래픽의 대체콘텐츠를 친히 입력했을리 없다는 것이다. 끔찍하지만, 접근성이 미비한 이 콘텐츠는 DB를 이관하는 과정에서 고스란히 to-be(재구축) 게시판으로 옮겨질 것이며 이 게시물마저도 웹 접근성 평가 대상에 포함된다. 아무리 재구축을 잘 해놓아도 이 데이터가 얹혀지는 순간… 당신의 순결한 페이지는 더럽혀(?)지고 마는 것이다.

계륵같은 웹 에디터, 꼭 써야하나?

입력 담당자에 올바른 사용법을 숙지시키고 반드시 지키도록 한다면 딱히 웹 에디터가 문제될 일은 없을 것이다. 그러나 교육한대로 담당자가 잘 이행하지 않는 경우가 대부분이며, 담당자가 여러명일 경우에도 관리가 어렵다. 이 문제에 대해 알린 뒤, 웹 에디터를 쓸지 말지 결정하는 것은 온전히 현업의 의견에 달려있다. 운영관리의 편의성에 좀 더 비중을 두는 사기업, 웹 접근성 자체에 좀 더 비중을 두는 공공기관, 자료 입력 담당자가 전국 각계부처에 수백명인 공기업(이 경우 극약처방으로 웹 에디터를 들어냈다) 등 상황은 다양하다. 이는 프로젝트 초기에 협의를 진행하여 현업의 상황에 맞추어 결정을 촉구해야 한다. 나중에는 개발일정과 맞물려 현업 담당자들의 선택의 폭이 좁아지므로 최대한 일찍 문제를 제기하는 편이 서로 좋다.

구 웹 에디터가 저지른 사고, 수습은 누가?

웹 에디터를 안고 가기로 했건 들어내기로 했건 간에 이미 작성된 기존 글은 어쨌든 수습을 해야한다. PM이나 개발팀에서는 전혀 생각조차 안하고 있었던 일일테지만, 이는 분명 뜨거운 화두가 될 것이다. 기존 데이터가 별로 없다면 몰라도 수 천 건에서 많게는 수 만 건에 이를 수도 있는 일이다. 재구축 업무만으로도 일정에 허덕이고 있을 당신의 팀은, 수 만 건의 게시물까지 모두 수정해야만 할지도 모르는 위기에 봉착했다. 아, 너무 쫄진 않기를 바란다. 불행 중 다행히도 문의게시판과 같이 홈페이지 사용자가 입력하는 글은 심사대상에서 예외로 치니까. 그렇다고 아직 안심하기에는 이르다. 단순히 몇 천 개의 게시물만이 줄어들었을 뿐이다.

방패삼을 만한 핑계를 황급히 찾아보자. 당신이 속한 프로젝트 팀이 맡은 업무의 역할과 책임이 어디까지였는가? ‘재구축’이라는 사실을 떠올렸는가? 자료를 이관하는 것은 재구축 그 이전에 만들어진 콘텐츠로, 엄격하게 따지고 들자면 이것은 현업의 운영팀에서 지속적으로 관리해왔으며 앞으로도 관리해야 하는 운영 콘텐츠이지 재구축 대상에 해당하지 않는다. 옳거니! 현업 해당 부처에서 처리하는 것이 맞다는 이야기이다. 물론 기존 운영팀이 할 줄 알았다면 이렇게 관리하지 않았겠지. 그러므로 재구축 팀의 웹 퍼블리싱 PL은 이에 대한 가이드라인을 수립하여 현업 운영 담당자에 교육을 진행하는 선에서 그 소임을 다 했다고 볼 수 있다는 말이다. 초기 웹 접근성 컨설팅 업체에서 방문 교육을 실시하는 경우라면, 현업의 운영 담당자와 함께 교육받는 것으로 이 과정을 생략할 수도 있을 것이다.

요약하자면 기존 운영 데이터는 현업의 운영 담당자 측에서 수정하는 것이 적절한 역할분담이며, PM은 심사 이전까지 작업을 완료하도록 기한을 제시하고 점검하는 것이 옳다. 물론 웹 퍼블리싱 PL은 현업 운영팀에 가이드라인을 제시하여 교육하는 일을 선행해야 할 것이다. 이것이 가장 이상적인 그림이다. 이를 현업에서 순순히 받아들인다면 이보다 큰 해피엔딩은 없을 것이라는 말이다. 하지만 현실은 녹록치 않은 법. 일부(실은 대부분의) 까칠한 우리의 고객은 이렇게 말할 지도 모른다.

“접근성 마크를 따주기로 했으면 이것도 알아서 해결해주셔야하는 것 아닙니까? 우리가 시간이 남아 돌아서 이걸 다 합니까?”

덧붙여, 교육 이후 올라갈 콘텐츠 정도는 본인들이 하겠다고 선심쓰듯 이야기할 것이다. 아주 틀린 말도 아니기 때문에 심약한 PM은 “아 네 저희가 해야죠”하면서 일을 덥석 물어오기도 하므로, 미리 입조심을 시켜야 한다. 무조건 다 가져와서 독박쓰지말고, 서로의 일정과 인력자원 여부에 따라 역할을 분담하는 밀당을 해야한다는 말이다. 단, 본래 업무 롤은 현업에 있다는 사실을 정확히 인지시킨 상태에서 이야기를 풀어나가는 편이 유리할 것이다. 그렇다고 원래 너희 일이라는 식으로 강경하게 말하여 갑의 분노를 사지는 말자. 괜히 적대적 관계가 되어 좋을 것이 없다.

보통 이 경우 해결하는 방식은 다음과 같다.

  1. 현업에서 수정한다. 담당자가 한가하지 않은 이상 이렇게 될 리 없지만…
  2. 현업과 재구축 프로젝트 팀이 나누어 작업한다. 향후 운영을 위해 교육차 진행한다는 명분을 두어 실행해보자. 이쪽에서도 일정 부분 감수하는 컨셉이다. 먹힌다.
  3. 현업과 협의하여 기간별로 끊어 지난 게시물은 삭제한다. 실제로 게시물이 너무 많을 경우는 이렇게 하는 경우가 많다. 게시물의 중요도가 높으면 통하지 않는다.
  4. 재구축 프로젝트 팀에서 수정한다. 최악의 경우지만, 자료가 적고 일정이 충분한 경우 그냥 해주는 경우가 많다. 일정 조정 및 인력 충원에 대한 이슈가 발생할 수도 있다.

간혹 문제되는 게시판을 심사기간에만 닫았다가 심사기간이 끝나면 다시 오픈하는 방식을 취하기도 하는데, 이는 눈속임과 다를바 없으므로 원칙적으로 당연히 해서는 안되는 일이다.

슬프게도 재구축 프로젝트팀에서 지난 게시물 수정을 모두 담당하게 된 경우, 개발PL에 DB 데이터 분량 파악을 요청하고 해당 공수를 산정하여 퍼블리싱 일정을 반드시 추가 확보토록 하자. 집에 일찍 들어가기 싫은 사람은 일정 확보를 과감히 생략하면 효과가 대단히 좋을 것이다. 간혹 DB 데이터를 맘대로 수정해서는 안되는 보안정책의 문제도 있을 수 있으므로, 수정한 코드를 직접 관리자 시스템에 접속하여 입력할 것인지 html 문서형태로 전달만 할 것인지 등에 대한 상세 방안은 현업 담당자와 개발PL과 협의하여 진행하면 된다.

2. 화면설계서에서 웹 접근성 찾기

어서 와, 웹 접근성은 처음이지?

간혹 웹 접근성이 뭔지 잘 모르는 기획자와 작업을 하게 되는 경우가 있다. 사실은 간혹이 아니라 대개의 경우 그렇다. 이는 앞서 얘기했던 바와 같이 웹 접근성에 대한 것은 모두 퍼블리싱 팀에 의존하려는 세태에서부터 나오는 문제인데, 안타깝긴 하지만 어쩔 수 없이 우리는 그 사람과 일을 해야만 한다. 그렇다고 다짜고짜 기획자에게 찾아서 ‘웹 접근성에 대해 얼마나 아시느냐’고 물어보는 실례를 범할 수는 없으니, 이를 판단하기에 가장 좋은 방법은 우선 관리자 시스템의 화면설계서를 확인해보는 것이다.

제 점수는요…

관리자 시스템을 통상 CMS라고 이야기 하겠다. CMS 화면설계서를 열어 가장 복잡한 ‘입력화면’을 찾아보자. 이미지 첨부 필드는 있는데 해당 이미지에 대한 대체텍스트를 넣는 필드가 없다면 이는 사용자 페이지에서 보면 접근성 위배가 될 것이다. 여러 장의 이미지를 입력할 수 있는 화면이라면, 이에 대한 대체텍스트 필드도 각각 대응되어 있어야 한다. 업로드하는 이미지의 성격에 따라 입력필드의 type과 글자수 제한도 다르게 지정될 수 있다. (입력필드 글자수 제한에 관련한 사항은 개발팀에서 DB를 설계할 때 지정하는 부분이므로, 기획자만이 아니라 DBA도 연관되어있다.) 이미지 첨부의 경우, 해당 자료의 성격이 단순 사진이라 설명글이 길어질 일이 없을 경우라면 대체텍스트를 넣는 필드의 글자수 제한이 작게 설정되어 있더라도 상관없지만, 간혹 방대한 텍스트가 입력된 이미지를 첨부하게 되는 화면이라면 글자수 제한을 작게 설정해서는 안된다. 예를 들어 이벤트를 안내하는 페이지일 경우, 이벤트 안내 이미지를 통으로 집어넣도록 설계하는 경우가 있다. 이미지 하나에 들어가는 내용이 많아지면 대체콘텐츠를 입력하는 필드 역시 <input type="text" />가 아닌 <textarea></textarea>로 설계했어야 옳을 것이다.

만일 이러한 디테일이 무시된 설계서라면 일단 이 기획자는 웹 접근성에 대해 잘 알고 있는 사람은 아니라는 것을 짐작해볼 수 있다. 이 경우 디자인이 다 나올때까지 화면설계서를 모른척 했다가는 추후 작업자 모두의 일정과 공수에 영향을 미칠 수 있다. 그런 의미에서 화면설계서가 나오면 디자인이 나올 때까지 기다리지 말고, 설계서를 사전에 점검하여 의견을 나누도록 하자. 기획자가 미숙하여 설계서에 문제가 많을 경우에는 설계서 초안이 나온 뒤 리뷰 회의를 주재하도록 요청하여 그 자리에서 각 PL들과 의견을 교류해보자. 자연스럽게 전체 팀원들의 웹 접근성에 대한 의식을 고취할 수 있어 두루 이롭다.

3. 정시 퇴근을 위협하는 산출물

산출물? 무엇을, 어떻게?

엄밀히 말하면 위험요소라고 보기는 어려우나, 간혹 위협(?)요소로 작용하는 산출물 문제를 빠뜨릴 수는 없을 것 같다. 프로젝트 종료시 최종 제출할 산출물 종류 및 제출 형태를 사전에 반드시 확인하도록 한다. 이는 웹 접근성과의 관련은 없으나 퍼블리싱 팀의 차원에서 전체적인 작업 공수를 판단하는데 중요한 정보이다. 정식 산출물 목록표에는 html 파일에 대한 항목이 없는데, 인수인계시 운영팀에서 요청하는 경우가 대부분이다. 일례로 개발팀의 요청으로 html이 아닌 jsp로 모듈을 분할하여 작업한 프로젝트가 있었는데, 프로젝트 종료시 현업 운영팀 측에서는 서버를 세팅할 수 없는 환경이므로 무조건 html로 넘겨달라고 요구한 경우도 있었다. 안타깝게도 그때는 HTML 자동 추출 도구를 알기 전이어서, 무려 한 달 동안을 쓴 눈물을 삼키며 노가다 작업을 해야만 했다.

개발따라 강남 안간다

또한 콘텐츠 현행화에 대한 문제도 빼놓을 수 없는데, html 파일을 개발팀에 넘긴 뒤일지라도 추가적인 수정사항들은 필연적으로 발생한다. UI에 대한 특이 변경사항이 아니라면 개발팀에서 바로 수정해버리는 경우가 많은데 이런 경우 제출할 html 파일에는 버전관리가 되지 않아 같은 페이지임에도 내용이 다른 경우가 생기게 된다. 이에 대해 운영팀에서는 퍼블리싱 파일에도 운영 콘텐츠와 완전히 동일하게 해주기를 요청하는 깐깐한 경우가 있다. 퍼블리싱 파일과 개발파일의 괴리는 생길수밖에 없는 부분이므로, 사전에 이에 대한 것을 미리 양해를 구하고 협의점을 찾으면 문제가 되지 않겠지만, 협의도 없이 서로 다른 파일을 내민다면 담당자들은 이를 용인하지 않으려고 할 것이다.

+
이번 글은 정리하는 데에 매우 긴 시간이 걸렸다. 초안을 작성한 것은 한 달도 넘었는데 그 사이 무려 139회의 리비전을 생산했다. 사실 지금도 완전히 다듬어지지 않은 느낌이지만 일단 이렇게라도 올려두어야 진전이 있을 것 같다. 머릿속이 복잡해 다음 포스팅의 주제는 아직 정하지 못했지만 말이다.

관련 글

웹 접근성 프로젝트에서 웹 퍼블리셔가 할 일 – 1. 주요 역할

관련 글

일을 잘 하기 위해서는 기본적으로 프로젝트의 궁극적인 목적 뿐만아니라 ‘내가 할 일’ 즉 ‘역할과 책임(R&R)’을 정확히 파악하고 있어야 한다. 이는 너무나도 당연한 이야기임에도 불구하고, 막상 프로젝트 현장에 가보면 뭘 해야할지 몰라 우왕좌왕하는 PL이 의외로 흔하다. 요구하는 역량에 비해 경험이 부족한 인력이 투입 되는 경우가 생각보다 많다는 것이다. 본인 역시 경험과 역량이 갖춰지기도 전에 본의아니게 PL을 맡게 되어 고생했던 기억이 있기 때문에, 막막한 초보 PL에게 도움이 될까하여 조금은 장황하게 풀어 써보기로 했다.

앞서 꼭 읽어보기를 권한 프로젝트의 성공을 좌우하는 요소들에서도 수차례 언급되었듯, PL(Part Leader)은 서브 파트의 PM과도 같다. PL은 전체 프로젝트의 진행 과정(분석 – 설계 – 구현 – 시험 – 이행)에서 담당 파트의 산출물을 작성하고, 위험요소 관리, 일정 관리, 팀원 관리 및 업무분장, 이슈 해결 등을 수행하는 것이다. 그 중에서도 PL의 역량에 많은 영향을 받는 부분이 일정 및 팀원 관리이고, 위험요소와 이슈 관리 영역은 거의 ‘경험’이 좌우한다해도 과언이 아니다.

그렇다면 PL 공통 역할말고, 웹 퍼블리싱 PL만의 고유 업무에는 어떤 것들이 있을까? 팀원일 때 했던 일들에 대해서는 이미 잘 알고 있을테니, PL이 하는 일에 대해 살펴보자.

웹 접근성 가이드 배포 및 교육

프로젝트 팀원들의 웹 접근성 인식 수준을 파악해보면 생각보다 하향평준화 되어있다. 그렇기에 화면 설계에 들어가기에 앞서 기획자/디자이너/개발자를 대상으로 교육을 진행할 필요가 있다. 인증마크를 획득해야 하는 중대형 프로젝트 대부분은 웹 접근성 컨설팅 업체를 별도로 선정한다. 그렇다면 해당 업체에서 웹 접근성 내부 평가를 진행해줄 뿐 아니라 웹 접근성 교육을 실시해주기도 하므로, 가능하다면 일정을 잡아 사전 교육까지 요청하는 것이 좋다. 별도의 외부 컨설팅이나 교육 지원 없이 프로젝트를 진행해야만 하는 상황이라면, 웹 접근성 관련한 업무는 웹 퍼블리싱 팀에서 도맡아 진행하게 될 것이므로 교육도 웹 퍼블리싱 팀에서 준비해야 한다.

교육 열심히 해봐야 기억도 못할 게 뻔한데 시간낭비를 왜 하는지 의문이 드는 사람도 있을 것이다. 하지만 이는 절차상이라도 필요한 일이다. 퍼블리싱 팀에서 공정상 웹 접근성이 미비한 부분을 발견하면 특별한 경우를 제외하고는 즉각 시정을 요청(늦게 시정할수록 인력 및 시간 비용이 불어난다)하는 것이 좋은데, 듣는 사람 입장에서는 바쁜 와중에 (웹 접근성에 대한 인식이 낮은 몇몇 사람의 눈에는) 중요하지도 않은 이 작업을 굳이 시간내어 처리해야한다는 사실이 달가울 리 없다. 특히 프로젝트 막바지에는 일이 몰려 예민한 상태이므로 “바빠서 못합니다, 이런건 진작 말해주셨어야죠”라는 적반하장 식의 타박이 돌아오기 쉬우며, 공식적인 교육절차는 이같은 상황을 미연에 방지해줄 뿐 아니라 정정 요청시 타당한 근거가 되어줄 것이다.

교육 이후 새로 투입될 팀원들을 위해 웹 접근성 가이드 문서를 만들어 배포하는 것도 중요하다. 신규 인원 투입시 이메일로 가이드 문서를 전달하고, 본인 부서에 해당하는 점검항목만큼은 반드시 숙지할 것을 당부하되 모르는 부분은 찾아와 질문할 수 있도록 하자.

웹 접근성 가이드 문서는 한 번 만들어 두면 거의 대부분의 프로젝트에 재사용할 수 있으니, 여유가 있을 때 틈틈이 작성해두는 것이 좋다. 참고자료로 네이버의 널리, 다음의 다룸 등이 있으며, 중간 규모 이하의 프로젝트에서는 핵심내용만을 추려 간결하게 작성하는 편이 효율이 더 좋다.

웹 퍼블리싱 가이드 배포 및 교육

코딩에 대한 가이드라인을 정의하는 것은 코드의 가독성, 일관성을 유지하려는 목적 뿐만 아니라 팀원들의 생산성을 증대시키기 위한 기초공사라고 볼 수 있다.

일반적인 ‘웹 퍼블리싱 가이드’는 HTML/CSS/JS 코드 작성 규칙 표준을 담은 컨벤션 문서를 말한다. 코드의 가독성 및 일관성을 지키기 위한 약속으로, 코딩 규약집, 마크업 컨벤션 등의 다양한 명칭으로 불린다. 이 문서에서는 개발 환경을 고려하여 DOCTYPE, 라이브러리 등을 선정하고 네이밍 규약에 대해 다룬다. 문서를 배포한 뒤에는 웹 퍼블리싱 팀원을 대상으로 교육을 진행하는 것이 좋으며, 추후 현업 운영팀에 인수인계하는 자료로도 활용될 것이다.

또한, 자주 쓰는 UI 컴포넌트 등을 템플릿화하여 별도의 HTML로 모아 정리해 두는 것을 통상 ‘HTML 가이드’라고 이야기 하는데, UI 가이드, 마크업 상용구, 템플릿 등 부르는 명칭은 각양 각색이나 역할은 비슷하다. HTML 가이드를 작성하는 가장 큰 목적은 ‘재사용’을 통한 생산성 증대에 있다. 화면설계서를 전달받아 자주 쓰이는 UI 컴포넌트를 선별하고, 디자인 팀에서 디자인 가이드(스타일 가이드) 형태로 작업한다. 이 디자인 가이드를 바탕으로 재사용하기 용이하도록 구조화하여 마크업하면, 실제 퍼블리싱 작업시 해당 컴포넌트 템플릿을 끌어다 쓰는 방식을 취해 작업 시간을 크게 단축할 수 있다. 레이아웃 이외에 흔히 정의되어야 할 UI 컴포넌로는 불릿, 타이틀(헤딩), 박스, 탭 메뉴, 글꼴 스타일, 게시판, 테이블, 버튼, 입력 서식, 간격 정책 등이 있다.

웹 접근성 내부 검수

컨설팅 업체가 배정되어있지 않은 경우, 웹 퍼블리싱 팀에서 웹접근성을 검수하게 된다. 통합테스트까지 끝난 시점에서 검수하는 것이 가장 좋지만, 현실적으로 개발팀은 그 시기에 가장 바빠 웹 접근성 검수 결과까지 반영할 충분한 시간적 여유가 없으므로 통합테스트와 동시에 진행하게 되는 경우가 다반사이다. 개발이 미비한 부분을 제외하고, 잘 되어있는 부분부터 미리 해나가는 것이다.

1차적으로 Kado-WHA로 웹 접근성 자동 검사를 수행한 뒤, 검출된 오류는 곧바로 개발팀에 넘겨 수정을 요청한다. 오류건수가 0이 될 때까지 반복작업이 필요하므로 수정작업 마감 기한을 협의해두는 편이 좋다.

자동검사와는 별개로 수동 검사도 진행해야한다. 페이지가 적은 경우, 일정상 무리가 없다면 모든 페이지의 웹접근성을 검수하여 부적합 사항을 문서로 작업해두는 것이 좋다. 다만 분량이 방대하다거나 일정이 여의치 않을 경우 사이트의 핵심 페이지를 추려내어 상세히 검수하되, 그 외의 페이지는 각 점검항목에 부적합 항목을 한 두 건 씩 찾아내어 개선안을 제시하고 모든 동일한 경우 이와 같은 방식으로 처리하라는 안내로 대체할 수 있다. 이 역시 검수 결과는 개발팀에 넘기고, 완료 이후 올바로 적용이 되었는지 문서와 대조하여 확인하는 사이클을 반복한다. 추후 변경되거나 추가되는 페이지에서도 부적합 사항이 발생할 수 있으므로 작업자들에게 유의할 것을 촉구해야한다.

웹 퍼블리싱 PL이 수행하는 역할은 상황에 따라 다를 수 있으나 대표적인 것으로 몇가지 다루어 보았다. 다음 글에서는 프로젝트 수행시 빈번히 발생하는 위험요소와 대책에 대해 이야기하겠다.

관련 글

프로젝트의 성공을 좌우하는 요소들

프로젝트에서 웹 퍼블리싱 파트의 업무 공정과정을 정리하던 중 실무에 도움이 될만한 좋은 글 발견. PM의 관점에서 풀어낸 이야기이지만, 팀원일지라도 읽어둔다면 부서간 이해관계 파악과 통찰력 증대에 큰 도움이 될 것이다.

웹 접근성 프로젝트에서 웹 퍼블리셔가 할 일 – 0. 배경

관련 글

웹 접근성 프로젝트를 진행하다보면, 자주 발생하는 문제 상황임에도 미리 대비하지 못해 뒤늦게 수습하려는 경우를 심심찮게 보곤 한다. 퍼블리싱 파트만 웹 접근성을 준수했다고 웹 사이트의 웹 접근성이 우수한 것은 결코 아니지만, 현실적으로 이것에 대해 가장 많이 알고 있으며 업무 전반에 영향을 받는 부서가 바로 퍼블리싱 팀이기에… 그렇다, PM은 웹 퍼블리셔가 이 모든 위험요소를 점검하고 해결하리라 기대할 것이다. 그에 반해 타 부서의 팀원들은 웹 접근성 관련 작업에 굳이 시간과 노력을 할애하려 하지는 않을 것이다. 이는 사이트 구축의 목적이 기능 또는 콘텐츠이지 웹 접근성 그 자체는 아니라는 안일한 생각에서 기인한다.

웹 접근성은 목적이 아니라 ‘기본’이다. 기본을 중시하지 않는 프로젝트가 잘 된 프로젝트일 리 없을테지만, 어쩌다 이 기본을 잘 아는 타 부서 팀원을 마주치게 되면 감개무량하게 되는 슬픈 현실인 것이다. 차라리 팀원들의 웹 접근성 인식에 관해 어느 정도 체념하는 편이 정신건강에 이로울 지경이다. 그 인식의 빈 공백을 퍼블리싱 PL이 채워 넣기 위해서는 동분서주 챙길 것이 많다. 초반에 삐끗하면 프로젝트 막바지에 일이 산더미처럼 몰리고 웹 접근성 관련 이슈는 모두 퍼블리싱 팀이 덤터기쓰기 십상이다. 이러한 여러가지 위험요소들을 슬기롭게 해결하기 위해 적당한 타이밍에 적절한 사전작업을 해두어야만 한다.

다음번엔 웹 접근성 인증마크 획득을 과업으로 둔 중소형 프로젝트에서 마크업 개발을 주도하는 웹 퍼블리싱 PL의 경우를 상정하여 이야기를 풀어나가겠다. 또한 여력이 날 때마다 관련 자료를 보강할 생각이다. PL로서 프로젝트가 어떻게 돌아가는지 정도는 미리 숙지하고 있어야 하니, 프로젝트의 성공을 좌우하는 요소들을 먼저 파악하고 난 뒤 실무에 접근해보도록 하자.

관련 글