기본 콘텐츠로 건너뛰기

모든 사람에게 공평한 환경을 제공하는 것은 불가능하다.

일전에 욘 폰 테츠너 오페라소프트웨어 CEO의 인터뷰 내용 중 가장 기억에 남는 내용은 아래와 같은 내용이었다.

“웹은 하나 뿐입니다. 컨텐트를 제공하는 기술이 무엇이든 동일한 웹 경험을 제공하는 것이 중요합니다. 지금껏 데스크톱 웹브라우저는 마이크로소프트가, 모바일은 오페라가 주도해왔습니다. 앞으로는 어떤 기술을 쓰든, 어떤 기기든 이용자가 똑같은 경험을 하도록 바뀔 것입니다. 이는 전세계 흐름이기도 합니다.”

이 발언에 깔려 있는 뒷배경은 살포시 접어두고 그 내용만 살펴본다면 정말 공감이 가는 얘기이다.

우리의 웹 환경은 어떨까? 과연 모든 사람에게 똑같은 경험을 제공하고 있을까?

최근에 '장애인 차별 금지법'이 발효되면서 국내에서도 아주 미미하지만 곳곳에서 장애인을 위한 웹 환경의 구축에 관심을 쏟고 노력을 하고 있다.

하지만 아직은 그 갈 길이 너무 먼 것은 사실이다. 그런데 더 큰 문제는 기형적인 우리의 웹환경의 개선을 위한 접근이 장애인과 일반인이라는 이분법으로 갈려있다는 것이다.

그 이분법적인 논리 속에서 우리의 웹환경은 더욱더 기형적인 모습으로 변질되어 가고 있고, 더 큰 문제는 그 논리 속에서 또다시 소외를 받고 있는 사람들이 있다는 것이다.

우리의 웹환경이 더욱더 기형적으로 변해가고 있다는 것은 일반인이든 장애인이든 동일한 환경에서 인터넷을 사용할 수 있도록 개선되어야 함에도 불구하고 많은 경우 일반인을 위한 웹 환경과 장애인을 위한 웹환경을 분리해서 개발하고 있다는 것이다.

즉, 일반인이 접속하는 홈페이지와 장애인만 접속해서 사용해야 하는 홈페이지가 분리돼서 개발되고 장애인을 위한 홈페이지는 일반 홈페이지에 정말 눈꼽만하게 보이지도 않는 구석에 링크를 걸어놓고 생색을 내는 경우이다.

이런 경우 장애인을 위한 홈페이지는 데이터의 업데이트가 거의 이루어지지 않은 채 방치 되는 경우가 대부분이다.

일단 주변에 생색내기로 개발은 했지만 유지 보수를 하지 못하는 것이다. 거기다가 실제로 장애인들이 그 홈페이지에 접속할 수 있는 방법은 전혀 고려도 되어 있지 않다.

다른 경우로는 장애인들의 환경은 고려하지 않고 장애인들을 위한 편의 기능이 제공되고 있다는 것이다.

고가의 장비이기 때문에 실제로 장애인들 사이에서도 보급율이 저조한 것은 사실이지만 기존에 보급된 장애인들을 위한 컴퓨터에는 각 장애에 맞도록 화면의 일부를 확대하거나 화면의 내용을 음성으로 출력하는 기능이 기본으로 탑재되어 있다.

때문에 현재의 웹 서비스에서 제공하는 시각장애인을 위한 확대 기능이나 음성 안내는 사실 무용지물이다.

그런데 누구도 그런 것에 대해 고민을 하거나 아는 사람은 그다지 많지 않다.

외국이라고 해서 무조건 잘하는 것은 아니지만 이러한 문제에 대한 근본적인 해결책은 국내에서는 마치 당연하다는 듯이 떡칠되어 있는 각종 플래시와 실버라이트를 그리고 Active X를 포함한 모든 컴포넌트를 걷어내는 것이 필요하다.

웹에 거추장스럽게 붙어있는 모든 컴포넌트를 걷어내고 웹 표준에 맞도록 홈페이지를 개발할 필요가 있다.

국내 홈페이지는 동영상, 이미지, 각종 플래시로 떡칠이 되어 있고 막상 문자로 인식될 수 있는 컨텐츠는 거의 전무한 실정이다. 덕분에 장애인들이 기본적으로 가지고 있는 음성 안내 기능은 그야말로 무용지물이 되어 버렸다.

동영상, 이미지, 플래시로 중요한 정보를 전달하는 것은 지양할 필요가 있다.

이러한 웹표준에 따른 개발에 따라 개발된 홈페이지는 텍스트 브라우저로 확인을 할 경우 홈페이지 내의 대부분의 중요한 컨텐츠의 내용을 확인하고 홈페이지에서 제공되는 서비스를 이용하는 데 문제가 없다.

대표적인 텍스트 브라우저로는 'Lynx(http://lynx.isc.org/)' 가 있다. (설치나 사용법은 잘 찾아보시기 바란다. 뜻이 있는 곳에 길이 있는 법이다.

Lynx 를 통해 외국 은행 중 BNZ(Bank of New Zealand - 뉴질랜드로 워킹홀리데이를 간다면 자주 이용하게 되는 은행 중 하나)와 국내 은행 중 신한은행을 들어가 본 결과이다.
클릭하시면 크게 보이니 비교해 보시기 바란다. BNZ의 경우 은행 업무 전체를 이용하는데 있어 전혀 문제가 없다는 것만 강조하고 싶다.

이것이 국내 웹의 실체이자 현실이다.

참고로 BNZ를 우리가 쓰는 일반 웹브라우저로 들어가본 화면이다.
디자인에 있어서 국내 은행보다 못할 것은 없다고 생각되지 아니한가?

신한은행의 경우 저시력자를 위한 눈이 편한 뱅킹이라는 서비스를 제공하고 있지만 초기 화면에서 이 서비스로 갈 수 있는 방법은 없다. 실제로 이런 서비스는 불필요하다. 장애인을 위한 환경이 무엇인지 그 기본조차 이해하고 있지 못하고 있다.
텍스트 브라우저에서 홈페이지를 이용할 수 있도록 개발하는 것은 가장 적은 비용이 들면서 가장 큰 효과를 볼 수 있는 방법임에는 분명하다.

이렇게 개발된 홈페이지는 저시력자들이 화면을 확대해서 인식하거나 음성으로 화면을 안내하도록 하는데 아무런 문제가 되지 않는다. 그런데 왜 이러한 쉬운 방법을 놔두고 어려운 방법만 찾는 것일까?

장애인을 위한 개발은 분명 일반적인 회사의 입장에서는 이익이 되지 않는 개발임에는 분명하다.

한국 사회에서 더 큰 문제는 대부분의 장애인이 경제적인 이익을 창출할 수 있는 주체가 되지 못하고 있다는 것이다.

즉, 장애인을 위한 서비스를 개발한다고 해도 실제 장애인이 비용을 지불하고 해당 서비스를 이용할 수 있는 경제적 주체가 되지 못하는 비중이 월등하다는 것이다.

내 개인적인 생각으로는 그러한 이유에서 장애인에 대한 서비스 개발이 천덕꾸러기 신세가 된 것이 아닌가 싶다.

그리고 장애의 유형에 따라 모든 장애의 유형을 지원해 준다는 것도 경제적인 관점에서는 절대 쉬운 선택은 아니다. (개인적으로 사실 불가능하다고 생각한다. 모든 장애 유형을 지원한다는 것은 현실적으로 어려운 문제라고 본다. 머.. 불가능하다고 단언할 수 없을 수도 있다. 하지만 현재로서는 장애에 대한 국내의 인식을 놓고 본다면 절대 불가능하다고 말하고 싶다.)

하지만 그러한 어떤 경제적인 논리를 떠나서 일반인들은 당연하다는 듯이 누리고 있는 자유로운 일상사는 공평하게 제공해주어야 하는 것이 아닐까?

은행업무, 관공서 업무와 같은 살아가면서 필요한 기본적인 일상들마저 제공할 수 없을 정도로 이 사회는 각박한 것일까?

장애인을 위한 배려가 필요한 환경을 따진다면 아마 몇박 몇일은 거뜬히 떠들 수 있을 것만 같다. 은행마다 비치되어 있는 ATM만 봐도 그 기기에 장애인을 위한 배려는 눈씻고 찾아봐도 개똥딱지만큼도 없다.

이러한 불평등한 환경을 평등한 환경으로 만들 수는 없는 것일까?

(장애인과 일반인 사이에서 소외받는 또다른 사람들에 대한 이야기는 다른 포스트에서 다루고자 한다. 이 포스트를 적으면서 너무 흥분한 나머지 글이 길어져 버렸다..)

댓글

이 블로그의 인기 게시물

테스트 케이스와 체크리스트의 차이가 뭐여?

테스트 실무에서 가장 혼돈되어 사용되는 용어 중 하나가 테스트 케이스와 체크리스트입니다. 많은 경우 체크리스트를 테스트 케이스로 사용하는 경우가 많습니다. 실제로 인터넷 커뮤니티나 블로그, ISO, IEEE, ISTQB 등등을 검색해보시면 테스트 케이스와 체크리스트에 대한 구분이 다 제각각입니다. 각각에 대한 정의가 다 제각각입니다. 사정이 이러하다보니 많은 사람들이 테스트 케이스와 체크리스트를 잘 구분하지 못하고 혼동해서 사용하는 경우가 많습니다. 물과 기름처럼 테스트 케이스와 체크리스트를 정확하게 구분할 수는 없겠지만.. ISTQB를 기준으로 말씀드리면 설계 기법을 통해 도출된 것은 테스트 케이스 그렇지 않은 것은 체크리스트라고 생각하시면 쉽습니다. 예를 들면 아래는 결정 테이블 테스팅 기법을 통해 도출된 테스트 케이스의 예제입니다. 실제 테스트 케이스는 위보다 복잡하겠지만 어쨌든 얘기하고 싶은 것은 위와 같이 설계 기법을 통해서 도출된 것은 테스트 케이스라고 합니다. 그런데 딱 보시면 아시겠지만 실제 테스트에서는 저 정도로는 테스트 커버리지를 충분히 만족했다고 얘기하기 힘듭니다. 그렇습니다. 어떤 분들은 테스트 케이스가 전가의 보도, 은 총알 쯤으로 생각하시는데.. 테스트 케이스는 일종의 마지노 선이라고 보시면 됩니다. 최소한 제품을 테스트 할때 이정도는 해줘야 한다는 최후의 방어선 정도라고 보시면 됩니다. 전쟁에서 최후의 방어선은 물러설 수 없는 마지막 보루입니다. 하지만 최후의 방어선만 지킨다고 전쟁에서 승리할 수는 없습니다. 프랑스는 마지노 요새만 믿고 있다가 독일에게 깔끔하게 발렸던 과거가 있지요. 전쟁에서 승리하려면 앞으로 나가야하고 치밀한 전략과 전술이 뒷받침 되어야 합니다. 더 높은 커버리지를 도달하고, 충분히 좋은 테스트가 수행되려면 테스트 케이스는 기본이 되어야 하고 거기에 더해서 체크리스트가 따라와 줘야 합니다. 이러한 체크리스트는 팀의 경험과 과거 프로젝트의 데이

비츠 스튜디오 버즈 플러스(투명) 사용 후기

제 내자분은 아직도 유선 이어폰을 쓰고 있습니다. 그게 좋다고 하시더라구요. 작년에 혹시나 해서 앤커 사운드코어 라이프Q35를 구매해서 조공해봤지만 결국은 안쓰시더라구요. 그래서 작년 추운 겨울에 제가 귀마게 용으로 잘 사용해왔는데.. 여름이 되니.. 와.. 이건 너무 덥고 무거워서 못쓰겠더라구요. 아이폰도 사고 애플 워치도 샀으니.. 다음은 에어팟인데.... 노이즈 캔슬링이 된다는 에어팟 프로 2는 ... 네... 너무 비싸더라구요... 이건 내자분께 얘기해봐야 결제가 될리가 없어서... 고민하고 있던차에.. 네.. 저는 봐버리고 말았습니다. 비츠 스튜디오 버즈 플러스의 그 영롱한 투명 버전의 자태를... 급 뽐뿌가 왔지만.. 여전히 20만원의 고가더라구요... 초기 출시 시기에 이벤트로 16만원 정도 했던거 같은데.. 그정도 가격이면 선 결제 후 보고 하면 될거 같은데.. 20만원은 너무 너무 비싸서 침만 삼키던 차에.. 당근에 15만원에 올라온 물건을 덥석 물었습니다. 애플 뮤직 6개월 프로모션 코드도 사용하지 않은 따끈따끈한 제품이라서 그냥 질렀습니다. 이상하게 인터넷이 실제 리뷰 게시물을 찾기 힘들어서.. 고민을 잠깐 했지만.. 그 투명하고 영롱한 자태에 그만... 어쨌든 구매하고 한달 정도 사용해본 후기를 간단하게 남겨봅니다. 1. 노이즈 캔슬링은 기대한 것과는 좀 다르고 앤커 사운드코어 라이프Q35 정도 되는 것 같습니다. 노이즈 캔슬링은 활성화하면 이게 소리를 막아준다기보다는 주변의 작은 소음만 제거해준다고 생각하시면 됩니다. 그러니까 옆에서 소근 거리는 소리나 선풍기 바람 소리 같은 작은 소리들이 사라지고 음악 같은 내가 듣고자 하는 소리가 굉장히 뚜렸해지만 지하철 안내 방송 같은 조금 큰 소리는 그냥 들립니다. 그래서 주변음 허용 모드를 켜보면 너무 시끄러워서 안쓰게 되더라구요. 전 에어팟 프로 2를 사용해 본적이 없어서 비교할 수는 없지만.. 아주 못쓸 정도의 성능은 아니라고 생각됩니다. 2. 저는 귓구멍이 너무 작아서 XS 사이즈의 이어팁

탐색적 테스팅의 역사

이 글은 James Bach 의 ' Exploratory Testing 3.0 '을 번역한 글입니다. 이번 글은 의미를 전달하는데 무리가 없는 선에서 대부분 의역으로 번역되었습니다. 때문에 잘못 번역된 부분은 댓글로 남겨주시면 수정하도록 하겠습니다.(읽어보시면 시제나 문체가 시시각각으로 변합니다. 감안해서 읽어주시면 고맙겠습니다.) 이 글은 James Bach의 허락을 얻은 후 번역한 글로 다른 곳에 퍼가실때는 반드시 원 출처와 본 블로그를 같이 언급해주시기 바랍니다. ----- [저자 주: 다른 글에서 이미 탐색적 테스팅을 이제는 테스팅으로 불러야 한다는 것을 얘기했다. 사실 Michael은 2009년에 테스트에 대해 얘기했었고, James는 테스터에 대해 얘기했던 것을 2010년에 블로그에 작성했다. Aaron Hodder는 2011년에 직접적으로 언급했고 Paul Gerrard 역시 그러했다.우리는 모든 테스팅은 탐색적이라는 것을 깊이 이해하고 가르쳤지만(여기에 James가 작년에 한 학생과 대화를 나눈 예가 있다.), "탐색적 테스팅"이라는 용어를 더이상 사용하지 않을 준비가 되어 있지 않다. 지금도 우리는 탐색적 테스팅이라는 용어를 사용하지 말아야 한다고 주장하지는 않는다. 다만 테스팅이 탐색을 어느 정도 포함한 스크립트 테스팅을 의미하는 것이 아니라 테스팅이 곧 탐색적 테스팅이라는 것이다.] By James Bach and Michael Bolton 태초에 테스팅이 있었다. 아무도 탐색과 스크립트 테스팅을 구별하지 못했다. Jerry Weinberg는 1961년 Computer Programming Fundamentals에서 테스팅의 형식화(formalizing)에 주의를 표명하고 테스팅은 본질적으로 탐색이라고 설명했다. 그는 책에서 "프로그래머의 의도에 대한 많은 정보 없이 프로그램과 프로그래머의 의도가 얼마나 일치하는지 기계적으로 검사하는 것은 어렵다. 만약 검사를 위해 컴퓨터에 간단