관련 글
위험요소란, 프로젝트를 성공적으로 수행하는데 방해가 될 수 있는 불안 요소를 통칭한다. 넓게 본다면 ‘일정 차질의 원인이 될만한 요소’라고도 볼 수 있다. 다만 ‘이슈’와 ‘위험요소’를 헷갈릴 수 있는데, 이미 발생해버린 예측불가의 사건은 ‘이슈’이며 아직 일어나지 않은 불안 요소는 ‘위험요소’ 정도로 생각해도 좋다. 위험요소는 아직 일어나지 않았으니 사전에 감지하여 예방안을 수립하고, 그럼에도 발생할 경우를 상정하여 해결안을 설정해두어 실제 발생시 그대로 처리하면 될 것이다.
위험요소 관리의 핵심은 “사전” 협의이다. 논란의 여지가 있는 일들은 프로젝트 팀 내에서 단독으로 판단하지 말고, 상황이 발생하기 전에 위험요소를 판단해 해결방안을 미리 수립하여 현업에 제안, 협의를 해야한다. 협의를 한 뒤에는 위험관리대장에 기록을 남겨 공유하여 추후에 딴소리할 수 없도록 하는 것이다. 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은 “아 네 저희가 해야죠”하면서 일을 덥석 물어오기도 하므로, 미리 입조심을 시켜야 한다. 무조건 다 가져와서 독박쓰지말고, 서로의 일정과 인력자원 여부에 따라 역할을 분담하는 밀당을 해야한다는 말이다. 단, 본래 업무 롤은 현업에 있다는 사실을 정확히 인지시킨 상태에서 이야기를 풀어나가는 편이 유리할 것이다. 그렇다고 원래 너희 일이라는 식으로 강경하게 말하여 갑의 분노를 사지는 말자. 괜히 적대적 관계가 되어 좋을 것이 없다.
보통 이 경우 해결하는 방식은 다음과 같다.
- 현업에서 수정한다. 담당자가 한가하지 않은 이상 이렇게 될 리 없지만…
- 현업과 재구축 프로젝트 팀이 나누어 작업한다. 향후 운영을 위해 교육차 진행한다는 명분을 두어 실행해보자. 이쪽에서도 일정 부분 감수하는 컨셉이다. 먹힌다.
- 현업과 협의하여 기간별로 끊어 지난 게시물은 삭제한다. 실제로 게시물이 너무 많을 경우는 이렇게 하는 경우가 많다. 게시물의 중요도가 높으면 통하지 않는다.
- 재구축 프로젝트 팀에서 수정한다. 최악의 경우지만, 자료가 적고 일정이 충분한 경우 그냥 해주는 경우가 많다. 일정 조정 및 인력 충원에 대한 이슈가 발생할 수도 있다.
간혹 문제되는 게시판을 심사기간에만 닫았다가 심사기간이 끝나면 다시 오픈하는 방식을 취하기도 하는데, 이는 눈속임과 다를바 없으므로 원칙적으로 당연히 해서는 안되는 일이다.
슬프게도 재구축 프로젝트팀에서 지난 게시물 수정을 모두 담당하게 된 경우, 개발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회의 리비전을 생산했다. 사실 지금도 완전히 다듬어지지 않은 느낌이지만 일단 이렇게라도 올려두어야 진전이 있을 것 같다. 머릿속이 복잡해 다음 포스팅의 주제는 아직 정하지 못했지만 말이다.