관련 글
일을 잘 하기 위해서는 기본적으로 프로젝트의 궁극적인 목적 뿐만아니라 ‘내가 할 일’ 즉 ‘역할과 책임(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이 수행하는 역할은 상황에 따라 다를 수 있으나 대표적인 것으로 몇가지 다루어 보았다. 다음 글에서는 프로젝트 수행시 빈번히 발생하는 위험요소와 대책에 대해 이야기하겠다.