세계일주

얼마전에 무심코 TV를 보다가 결혼 후 신혼여행으로 몇 년간 세계 일주를 다니는 사람들의 이야기가 나왔었다. 저마다 자신의 현재 생활(여행?)에 만족을 느끼며 참된 삶을 살고 있다고 이야기 한다.

실제로 부럽다. 우리는 쫓기듯이 23시간을 비행기를 타고 멕시코 칸쿤으로 신혼여행을 다녀왔고 더 오래있고 싶었지만, 나와 아내의 휴가가 얼마남지 않았기 때문에 여유로운 휴가를 보내지는 못했었으니까…
다만 참된 삶이라는 부분은 동의하기 힘들다. 요즘 많은곳에서 다양한 삶(위와 같은 신혼여행을 2년 넘게 세계일주를 한다던가)을 보여주면서 보편적으로 사는 사람들을 그냥 그저 그렇게 살아가는 사람들로 만든 느낌이다. 사람은 저마다의 가치가 있고, 더 나은 삶이란 없어 보인다.

그렇다. 부럽고 질투나고 아니꼬와서 그냥 헛소리 해봤다.

라즈베리파이 홈 서버 만듬

일단 이런거 사봐야하는 직성이 풀리는입장이라… 일단 하나는 주변의 지인에게 하나는 팀원들이 공구하는데 끼어 우리집에는 라즈베리파이가 두대가 있었다.

사실 뭔가를 세팅하고 실험적으로 하는것을 좋아하지 않는 나는(리눅스도 싫어한다).. 그냥 라즈베리파이에 레트로파이라는 고전게임 에뮬 전용 기기를 만들어서 게임이나 간간히 즐기고 있었다.

문제는 집에 아들놈이 생기면서 게임을 할 시간이 없었던것…

그래서 활용방안을 고민해 보기로 했고 그 결론은 맥미니를 통해 활용하고있는 파일서버를 라즈베리파이로 변경해보자는것으로 정리했다.

내가 파일서버를 통해 이용하는것은 다음과 같다

  • 토런트를 이용한 다운로드
  • 동영상 파일을 애플티비를 통해서 보는 용도
  • 음악, 사진 파일 보관 및 실시간 확인

난 파일이나 데이터를 많이 모으는 사람이 아니었기 때문에 어떨결에 생긴 2 테라 하드 하나면 충분했다(중요 데이터는 별도로 백업을 여러군데 해두었다)

저것들 이용하기 위해서 이런저런것들을 설치했는데

  • 삼바서버는 애플티비에서 infuse를 통해 파일을 접근하여 동영상 실행을 위해
  • 트랜스미션은 토런트파일을 이용해 서버에서 파일을 다운받기 위해
  • 엔진엑스+php는 코믹글래스 웹 버전 설치를 위해

위의것들 말고도 외장 하드 자동 마운트나, 각 권한 설정등의 지식이 필요했는데 난아는것이 없었으므로 검색을 이용해서 해결했다

내가 참고한 사이트는 구글 검색을 통해서 찾았는데 대부분 http://withcoding.com/48 이 사이트에 정보가 나와 있었다. 즐거운 느낌이다.

덕분에 미디어 및 파일 서버가 하나 세팅되었고, 맥 미니는 나의 메인 컴퓨터로 되었다. 맥북에어는 아내님에게 조공으로 바쳤다.

뭔가 씁쓸하다

아기와 비행기 여행하기 part.2

사실 이전글이 제일 유용하다. 여러모로 아기는 비행기 안타는게 좋다.

그래도 우리 같은 경우 한 달에 한 번 이상 왕복 비행기를 타고 있어서 우리가 고려하는 점들을 몇 가지 남겨두려한다.

참고로 우리 아들은 이제 걷기 시작하는 돌 방금 지난 아이이다. 그래서 이 포스팅은 100일이후~ 12개월 미만의 아이에게 적용된다.

티켓팅

아기 있으니 좌석은 앞쪽으로 주세요. 짐은 빨리 나올 수 있게 해주세요. 라고 말이라도 해보자. 원래 제도가 모두 있으나, 요즘은 앞자리는 저가 항공의 경우 유료라서 먼저 팔리면 답 없고, 또 여행하는 아기가 워낙 많아서 이것도 경쟁이 치열하다. 그래도 말 한마디에 편할 수 있으니 요구사항을 요청하는것에 대해 아끼지 말자.

유모차

유모차는 우리 같은 경우는 “게이트에서 맡길게요” 하고 들고가는 편이다. 보통 짐을 맡기고 티켓팅을 하는 순간까지는 꽤 여러가지 절차가 있기때문에 아이가 유모차에 앉아주는것이 여러모로 편하다. 유모차가 있는경우 짐은 빨리 나와서 찾을 수 있게 해주는 표식을 붙여주니 안붙여주면 당당하게 요구하자. 게이트에서 수화물로 부칠경우에 짐 표식이 있어야하는데 혹시 티켓팅 시에 안붙여주었다고 당황하지말고 게이트 입구에서 승무원에게 요구하면 임시 표를 붙여주니 걱정하지말자.
유모차에 애를 태웠더라도 공항검색대에서는 아이를 꺼내서 유모차는 검사를 진행해야하니 참고하자.(자고있는데 검색대를 지나야하면 망한다…)

공항시설이용

국내 공항은 수유실이 있다. 부모들은 그냥 게이트로 빨리 가지말고 수유실에서 아이에게 공간적인 여유를 주는것이 중요하다. 비행기의 좌석은 좁기 때문에 공항에서 시간에 쫓겨 아기띠하고 유모차하고 계속 이리저리 돌아다니면 아기는 피곤한 상태에서 비행기를 탄다는 사실을 꼭 기억하자. 시간을 아끼는 방법은 따로 있다.

특히 인천공항에는 게이트가 있는 탑승구역 및 탑승 동에 베이비 까페같은게 있다. 면세점에만 신경쓰지 말고, 아이랑 거기서 신나게 한시간은 놀아주는게 중요하다. 잘 놀면 잘 잔다. 이게 핵심이다.

우선 탑승

짐 검사, 비행기 탑승때는 줄 서지 말고 먼저 해달라고 당당하게 요구해라. 아빠는 옆에서 뻘쭘해(긁적긁적) 하면서 스윽 묻어가면 된다. 우리나라는 출산을 장려하는 국가다. 다른것도 없는데 이런거라도 받아 먹어야지. 그럼 줄서있는 다른 부모들의 혼란스러운 눈빛을 즐기며, 먼저 입장할 수 있다.

탑승 후

언제부터 비행기를 탈 수 있는지 궁금했는데… 우리나라 항공사들은 생후 7일부터 탈 수 있다고 한다. 다만 좋을거없으니… 우리는 100일 되던 기념으로 친정에 갔다…

일단 주변에게 아이가 있어서 미리 죄송하다.라고  눈빛, 약간의 목례, 나즈막한 안내 및 양해를 구하는 것이 좋다. 그리고 아이에게 귀여움을 발사 시키면 좋다.
아기의 귀여운 행동 + 나의 미리부터의 미안한 마음만 있어도 많은 분들이 이해해 주신다. 근데 아기가 울지 않고 별일 없으면 칭찬도 받는다. 아기가 착하다며!!! 반대로 ‘아이가 다 그렇지’라면서 그냥 버티는 부모를 보면 나도 화가 난다. 내 아이가 남의 여행을 방해할 수 있다(거의 100%)는 생각을 항상하자.

안 울리는 방법은… 사실  뭐 없다.  그냥 타면되고 그냥 계속 수유하면 된다. 우리는 모유로 해결했다.

우리는 보통 아침먹고 낮잠 잘시기에 딱 비행기를 타는것을 선호하는편이다. 비행기를 타자마자 수유하면 출발하고 잠들거나 약간 안정된 상태가 되드라. 우리는 보통 비행 시간이 1시간 이므로.. 큰 문제 없었다. 다만 타서 수유를 시작했는데 비행기가 기타 다른 사유로 안뜨면 그때부터 초조하다. 우리 아이는 1시간이상은 안자니까… 이유식 시기 부터는 그냥 계속 간식먹이고 밥먹이고 그랬다.

이런 저런의 노력으로 우리의 아들은 비행기에서 운적이 딱 두 번 이었다.  비행기가 늦게 출발해서 이륙후 40분부터 울었다. 비행기를 한 20번은 넘게 탔으니, 90%의 성공이다.

다시 한번 말하지만 그냥 안 타는게 가장 좋긴하다 ㅋㅋㅋ

접근성 점검 도구

정보화 진흥원의 좋은 기회를 통해 동향을 분석하게 되었고, 그 글을 내 블로그에도 옮겨둔다.

서론

접근성이라는 단어가 담고 있는 많은 키워드중에 “차별” 이라는 키워드는 접근성의 핵심 키워드가 아닐까 생각한다. 정보접근에 차별을 두지않는 콘텐츠를 만들기 위해서 콘텐츠 제공자는 접근성을 연구하고 장애나 환경에 대한 이해를 바탕으로 콘텐츠의 접근성을 높이는 노력들을 하고 있다.

그러나 수많은 장애, 환경을 모두 대응할 수 없으며, 사람마다 느끼는 정도의 차이가 존재하기 때문에 웹 콘텐츠 접근성 지침을 만들어서 접근성 준수의 기준을 마련해 두고 있다. 지침을 이해하고 적용하여, 콘텐츠는 다양한 장애 환경을 대응하는 접근성이 좋은 콘텐츠로 발전하게 된다.

일반적으로 어떤 제품이 만들어지면 제품에 문제는 없는지, 불량은 아닌지 확인을 하는 절차를 거친다. QC(Quality Control)라고도 하고 QA(Quality Assurance)라고도 하는 이 절차는 당연히 접근성에서도 필요하며, 콘텐츠의 접근성 품질을 관리하는 이 행위를 통해 차별이 없는 콘텐츠를 만들 수 있게 된다.

무결점의 콘텐츠를 제공하기 위해서 접근성 품질 관리시에 필요한 도구와 방법론등을 알아보고 검증의 미래에 대해서 전망해볼것이다.

한국의 웹 접근성 검증 동향

우리나라의 웹 접근성의 발전은 주로 민간 분야가 아닌 정부기관에서 발전시켜왔다.

정부기관을 중심으로 웹 접근성에 대한 연구와 검증 및 발전이 주로 이루어 졌으며, 2008년 4월 11일 부터 시행된 ‘장애인 차별금지 및 권리구제 등에 관한 법률’로 인해 접근성 준수에 대한 의무가 생기면서 더욱 탄력받게 되었다.

특히 행정,공공기관의 웹 콘텐츠들은 웹 접근성 실태조사, 웹 접근성 품질마크 인증 제도등을 통해 접근성 준수의 검증을 받게 되었고 접근성의 인식이 높아지는데 큰 기여를 했다고 볼 수 있다.

웹 접근성 실태조사

2005년 부터 진행된 웹 접근성 실태조사는 웹 사이트의 대표 페이지를 일부 선정하여 한국형 웹 콘텐츠 접근성 지침의 22가지 검사 항목의 준수여부를 측정하는 형태로 진행이 되어 왔으며, 대표 페이지의 선정 조건등이 변경해오면서 현재의 형태로 발전 되었다. 현재는 웹 사이트 말고도 모바일 앱에 대한 접근성 실태조사도 진행을 하고 있다.

실태조사의 대상은 행정, 공공기관을 비롯하여 많은 사용자를 보유하고 있는 민간 사이트까지 포함해서 진행하고 있으며 실태조사와 컨설팅을 병행하고 있다.

[표1] 연도별 웹 접근성 실태조사 점수 결과 표(2013년 기준)

구분 ‘05년 ‘06년 ‘07년 ‘08년 ‘09년 ‘10년 ‘11년 ‘12년 ‘13년
중앙부처 72.3점 (60개) 82.3점 (62개) 87.4점 (61개) 90.1점 (50개) 92.6점 (51개) 94.7점 (51개) 94.8점 (51개) 92.4점 (53개) 92.4점

(51개)

-중앙행정 72.3점 (56개) 81.8점 (58개) 88.2점 (57개) 90.6점 (46개) 92.5점 (47개) 94.6점 (47개) 94.7점 (47개) 92.4점 (49개) 92.4점

(47개)

-입법사법헌법 72.2점 (4개) 82.7점 (4개) 86.6점 (4개) 89.5점 (4개) 93.1점 (4개) 94.7점 (4개) 96.3점 (4개) 92.6점 (4개) 92.7점

(4개)

지방자치단체 71.6점 (16개) 81.8점 (16개) 78.2점 (246개) 83.3점 (246개) 91.9점 (248개) 96.3점 (246개) 91.9점 (76개) 93.0점 (47개) 88.9점

(132개)

-광역지자체 71.6점 (16개) 81.8점 (16개) 86.8점 (16개) 91.6점 (16개) 93.9점 (16개) 97.0점 (16개) 96.1점 (16개) 94.4점 (17개) 90.4점

(17개)

-기초지자체 77.6점 (230개) 83.3점 (230개) 91.8점 (232개) 96.2점 (230개) 90.8점 (60개) 92.3점 (30개) 88.7점

(115개)

대민서비스 (전자정부) 77.1점 (1개) 78.4점 (1개) 74점 (19개) 80.3점 (20개) 82.2점 (19개) 87.1점 (19개) 87.5점 (39개) 89.8점 (40개) 87.4점

(59개)

공사·공단 74.6점 (101개) 84.2점 (98개) 86.5점 (95개) 88.4점 (94개) 86.1점 (59개) 87.5점

(50개)

교육기관

(초․중․고 등)

72.1점 (52개) 72.8점 (40개) 78.7점 (119개) 75.5점 (201개) 83.5점 (123개) 86.0점

(41개)

문화예술체육단체등 77.3점 (40개) 83.7점 (40개) 77.7점 (58개) 84.7점 (26개) 87.1점

(20개)

복지시설 79.6점 (20개) 80.4점 (20개) 59.8점 (102개) 70.1점 (32개) 67.9점

(32개)

의료기관

(종합, 치과, 한방)

80.0점 (20개) 77.9점 (82개) 66.5점 (99개) 78.8점 (32개) 83.2점

(20개)

중앙부처소속기관 74.6점 (35개)
지방공사 69.9점 (45개) 75.9점 (16개)
방송·언론 67.6점

(12개)

기타

(포털, 은행 등)

80.4점 (34개) 68.1점

(50개)

66.6점 (49개) 78.5점

(100개)

합계 72.2점 (77개) 81.8점 (79개) 79.8점 (326개) 81.0점 (503개) 86.6점 (536개) 86.9점 (722개) 77.1점 (800개) 83.1점 (477개) 84.5점

(517개)

웹 접근성 품질마크 인증 제도

웹 접근성 실태조사가 말 그대로 접근성 조사에 목적이 있었다면, 웹 접근성 품질마크 인증제도는 접근성이 준수된 웹 사이트를 인증하고 격려하는 방식으로 진행이 되었다. 인증마크를 획득한 사이트는 정보소외 계층의 정보접근권 보장에 앞장서는 기관 및 기업으로서의 국민적 호감 제고는 물론 정부는 대국민 정책 신뢰도 향상, 기업은 소비자 권익 보호라는 효과를 어필할 수 있었기 때문에 활성화되었다.

웹 접근성 품질마크는 실태조사와 다르게 검증받는 사이트의 입장에서는 마크 획득이 목표이기 때문에 좀 더 정확하고 자세한 검증 수단을 필요로 한다. 웹 사이트의 코드레벨에서 접근성을 검증하는 전문가 검증과 실제 장애환경에서 웹 사이트의 이용가능여부를 판단하는 사용자 검증, 두가지 방식을 모두 포함하여 진행하게 되었다.

정보화진흥원에서 모든 절차를 진행하던 웹 접근성 인증마크 제도는 33회차를 마지막으로 국가정보화기본법 개정으로 2013년 11월 23일부터 웹 접근성 품질인증 제도가 법적 근거로 시행됨에 따라 인증 마크 사업을 종료하고 웹 접근성 품질인증기관을 선정하여 진행하는 형태로 변경되어 현재까지 제도를 유지 하고 있다.

웹 접근성 검증 방식의 분류

전문가 검증

웹 접근성 검증 방식 중 전문가 검증은 한국형 웹 콘텐츠 접근성 지침의 22가지 검사 항목에 대해 코드레벨에서 각 검사 항목을 체크하는 방식으로 진행된다.

실제 코드레벨에서 문제점이 발견되기 때문에 접근성 준수, 미준수의 원인이 명확하게 분석되고, 개선방법도 비교적 명확하게 나오는 편이다.

또한 검증자의 실수가 아니라면, 페이지에 있는 모든 요소에 대한 검증이 가능하다. 이는 장애에 처한 환경과 비장애 환경에 대한 차이를 줄여주는 효과를 가질 수 있다.

지침의 이해 정도의 수준 차이와 지침의 접근 방식의 차이 발생 가능성으로 인해 전문가별로 상이한 검증 결과가 나올 가능성이 있기 때문에 여러명의 전문가에게 동시 진행을 하는 것이 일반적이다.

한국 정보화 진흥원에서 진행했던 웹 접근성 품질 마크 인증 제도의 경우 사이트 한곳의 접근성을 점검하기 위해 세 명의 전문가가 교차 검증을 진행했었다.

다만 코드 레벨의 전문가 검증 방식은 검증 대상 페이지의 모든 요소와 코드를 모두 분석하고 체크하기 때문에, 많은 시간과 인력을 필요로 했다. 이것은 접근성 검증 도구가 개발되고 발전되게 하는 계기가 되었다고 볼 수 있다.

사용자 검증

사용자 검증은 실제 장애환경에 있는 검증자가 실제 웹 사이트를 이용하는 방식으로 검증을 진행한다. 그래서 실제 사용자가 웹 사이트를 사용하듯이 그대로 수행의 흐름을 정해놓고 어려움이 있는지를 체크하는 방식이다.

사용자 검증의 경우 수행 흐름을 미리 정해놓기 때문에 수행에 해당하는 요소가 아닌 부분에서 문제점을 누락하는 경우가 발생되고 비장애 환경과의 비교 분석이 힘들 수 있다. 또한 다양한 장애 환경을 모두 준비해서 검증하기 쉽지 않다. 그렇지만 준비된 장애 환경에 한해서는 가장 확실한 검증 수단이라고 볼 수 있다.

접근성 검증 도구의 분류

접근성 검증도구는 접근성의 준수여부를 측정하기 위해 존재한다. 접근성 준수의 기준인 지침이 각 나라별 단체별로 다른게 존재하고, 도구의 접근방식이 모두 다르며, 목표도 다르기 때문에 상황에 맞는 도구의 선택은 중요하다.

접근성 자동 검증 도구

웹 사이트의 주소를 입력하면 기계적으로 사이트의 페이지를 가능한한 방문하여 접근성의 준수 여부를 분석하여 그결과를 노출해주는 방식으로 대표적인 도구로는 K-Wah 4.4가 있다.(현재는 배포 중단 중)

K-wah4.4는 사이트 내의 모든 페이지를 자동으로 분석한다는 장점이 있다. 이는 검증 작업에 필요한 인력 소모가 크지 않다는 것을 의미한다. 대상 페이지를 선정할 필요가 없으며, 코드 분석이 가능한 인력이 확인하지 않아도 웹 사이트의 접근성 준수의 정도를 가늠해 볼 수 있다.

그렇지만 자동 분석의 경우 기계적인 방법으로 접근성을 점검하기 때문에 접근성 준수에 대한 사람의 판단이 필요한 항목과 접근성이 준수된 정도의 차이를 구분해 낼 수 없다. 즉 접근성 준수의 조건 중 필요한 항목에 대한 지원여부만 가려낼 수 있지, 적절하게 접근성을 고려하고 있는 가는 판단할 수 없다. 이를 필자는 보통 접근성에 대한 정량적 접근이라고 한다

정량적 접근을 통해 접근성의 준수여부를 판단할 수 있는 항목은 보통 다음과 같다.

  • img alt 속성 제공 여부
  • input[type=”image”] alt제공 여부
  • 문서의 title 요소 제공 여부
  • frame, iframe 요소의 title 속성 제공 여부
  • html 요소의 lang(xml:lang) 속성 제공 여부
  • label과 서식의 연결 상태

위의 사례 말고도 몇 가지 더 있을 수 있지만 지침에서 말하는 모든 검사 항목을 준수하는지 검증을 할 수는 없다.

예를 들어 사용한 이미지에 대체 텍스트가 선언되어 있는지는 자동 검증을 통해 확인 할 수 있지만 선언되어 있는 대체 텍스트가 이미지의 내용을 잘 설명 했는지는 선언 여부가 아닌 판단이라는 항목이 필요하기 때문이다.

접근성 검증 보조 도구

위에서 말한 접근성 준수의 판단을 위해서 가장 좋은 방법은 사람이 직접 사용하고 눈으로 보고 판단하는 것이다. 결국 사용자가 웹 사이트의 이용을 통해 접근성 점검을 진행하는 방법이 필요하다. 이때 전문가에 의한 코드 수준의 정밀한 검증을 진행할 때 필요한 것이 접근성 검증 보조 도구다. 검증 보조 도구를 사용하면 시간과 인력이 많이 필요하게 되는 정성적 점검의 부담을 일부 절약할 수 있다.

접근성 검증 보조 도구는 종류가 엄청 많다. 코드분석을 통한 검증 보조를 하는 도구로는 외국에서는 wave(http://wave.webaim.org/), 국내에서는 openwax(http://openwax.miya.pe.kr/)가 많이 사용되고 있다.

이외에도 용도별로 플래시 객체의 접근성 점검 보조 도구, 명도대비의 검증 보조 도구, 발작 검증 보조 도구 등 접근성을 점검하려는 전문가를 보조할 수 있는 도구가 다량 존재한다.

두 가지로 분류된 검증 도구의 혼용

검증 보조 도구를 사용한다 해도 많은 시간과 인력이 필요한 것은 사실이고, 이것은 서비스 제공자 입장에서는 비용의 증가로 이어지는 부담을 가지게 된다.

따라서 자동으로 다량의 검증을 진행할 수 있는 기계식 검증을 선 진행하고, 기계식 검증을 통과한 콘텐츠를 대상으로 정성적 평가를 진행하되, 비용을 줄일 수 있는 검증 보조 도구를 충분히 이용하여 점검을 진행하는것이 현재의 일반적인 형태이다.

검증 도구의 미래

검증 도구(보조 도구를 포함한 도구 전체)가 시간과 인력을 효율화 하기 위함이라는 중요한 목적이 있기 때문에 비용(시간과 인력의 투입)을 줄이는 방법을 지속적으로 고민해야 한다.

수동 검증의 대상에 대한 모수를 줄임

  • computedStyle를 이용하여 전경과 배경의 측정을 통한 모든 텍스트에 대한 명도대비 분석을 통한 검증의 모수를 줄임
  • 자주사용되는 오류를 등록 후 검색을 통한 확실한 오류를 선별(예: 대체텍스트 – 아이콘, 불릿 등등)

자동 검증의 신뢰도 증가

지침의 일부 항목 중 페이지마다 반복적이고 일반적인 내용들은 검사전에 설정하는 내용을 통해서 검증의 비용을 줄일 수 있다.

  • 웹 사이트의 주 사용 언어 사전 지정 등록을 통한 주 언어 설정 여부
  • 웹 사이트에서 주로 사용하는 레이아웃의 설정을 통해 스킵 네비게이션의 올바른 작동 여부 등

자동 검증의 영역 확장

비용을 줄이는 방법에서 가장 우선시 되는 방법은 사람이 할 일을 기계에게 맡기는 것이다. 다행히도 기술의 발전은 지속적이어서 몇가지 가능성이 열려있다.

결론

위의 열거한 방법들은 아직 완전하지 못한 방법인것도 존재하고, 검증해결의 확실한 방법도 아니며, 지침의 모든 항목을 검증해 주지 않는다. 그러나 검증자의 편의를 조금이라도 볼 수 있는 방법을 찾는다면, 비용을 줄이는 효과를 지속적으로 얻을 수 있을 것이라 생각한다.

기본적으로 웹 사이트를 가장 잘 이해하고 분석할 수 있는 사람은 웹 사이트를 만든 사람이다. 검증자와 작업자가 달라서 새로운 시각을 가지고 검증을 진행해야할 필요도 있으나, 기본적으로 자가검증을 통하여 웹 사이트의 제작시기부터 접근성을 잘 준수하는 노력을 하는것이 더욱 중요할것이다. 위의 도구들은 접근성 검증 도구이기도 하지만, 접근성 제작 도구이기도 하다.

접근성 점검은 접근성을 잘 준수하기 위해 존재 하는 것이지 접근성 미지원의 민낯을 찾아내기 위함이 아니다.

닥치고 웹 표준