이건 정말 대박 아이디어인데 사람들은 왜 몰라줄까?

이런 생각은 평소에 누구나 가질 수 있죠. 그래서 1박 2일 동안 어떤 주제를 막론하고 원하는 것을 만들어 사람들에게 보여줄 수 있습니다. 이런 행사에서 공감을 많이 받게 되면 그 아이디어는 사업이 되거나 적어도 기존의 서비스들을 개선하는데 훌륭한 밑천이 될 것입니다.

명찰과 생존킷

저는 올해 저희 XE 팀원들과 함께 처음으로 참가를 했습니다. 개인적으로 평소에 갈망하던 아이디어가 있던 것은 아니었지만 팀원들과 좋은 추억을 만들 수 있다는 기대감이 더 컸습니다. 다양한 주전부리를 제공하는 것도 그렇구요. 휴대폰으로 미투데이에 생존킷을 찍어 올렸더니 궁금해하시는 분들이 있어서 노트북 위에 펼쳐놓고 한 번 더 찍었죠. 평소에는 손도 안대던 것들인데 이렇게 지급해 주니까 먹게 되네요. 이 밖에도 각종 먹거리들이 행사장 밖에 수북히 쌓여 있어서 오며가며 집어먹게 되어 있습니다.

생존킷 내용물

행사에 참여하기 위해 평소부터 뭔가 준비를 할 수도 있었습니다. 꼭 단 하루만에 무언가를 해야 하는것은 아닌거죠. 아마도 미리 준비를 해왔다면 좀 더 여유있게 즐길 수 있었을지도 모르겠네요. 하지만 저희 팀처럼 정말 아무 준비도 없이 노트북만 딸랑 들고와서 시작해도 괜찮은것 같아요. 기획, UI, 프로그램 산출물까지 단 하루만에 완성시켜야 한다는 제약을 즐기는 것도 매력 있던데요.

새벽 4시 버닝데이 행사장 풍경

행사장은 이렇게 작은 테이블과 의자들이 빼곡히 들어서 있는데 사람들은 정말 밤 새도록 이러고 있답니다. 오래간만에 딱딱한 의자에 오래 않아 있으려니까 사무실에 있는 허먼밀러 에어론 의자가 무지하게 그립더라구요. 물론 이렇게 않아서 개발만 하는것은 아니구요. 개발자들에게는 가볍게 즐길 수 있는 프로그래밍 문제도 제공이 되는데 제한 시간 내에 누가 가장 정확하고 빠르게 풀었는지가 실시간으로 화면에 중계 되기도 합니다. 그리고 순위별로 10만원에서 5천원까지의 상금이 즉시 지급 됩니다. 이 밖에 휴게실에 가면 각종 보드게임과 닌텐도 게임도 즐길 수 있구요.

중식으로 제공된 아웃백 도시락

버닝데이의 또 다른 이름은 사육데이 입니다. 식사부터 야식에 군것질 꺼리까지 1박 2일동안 계속해서 나오기 때문에 그런 별칭이 붙었다죠. 도시락은 식성따라 즐길 수 있도록 여러 종류가 나오는데 그 중 아웃백 도시락이 비주얼이 좋길래 집어 들었습니다.

소스코드 등록 및 발표자에게 지급된 무선 키보드 마우스 세트

먹거리도 먹거리지만 이 행사의 백미는 가장 마지막에 있는 ‘발표’ 시간 입니다. 수십여 참가 팀들은 하루동안의 결과물들을 정확히 ‘4분’동안 다른 참여자들에게 소개할 수 있습니다. 물론 이건 의무적인것은 아니지만 대부분의 지원자들이 발표를 한답니다. 

개인적으로 모든 아이디어에 흥미가 있었던 것은 아니었지만 대부분의 결과물들은 일단 독창적 입니다. 참가자들은 서로 다른 참가팀들의 발표를 보면서 평가를 하게 되는데 공감을 많이 받은 아이디어는 본선에 오르게 되고 본선 진출자는 몇 일 후에 다시 만나서 경합을 벌이게 된답니다. 본선에 오른 아이디어들이 빨리 세상의 빛을 볼 수 있다면 좋겠네요.

버닝데이 행사를 총괄하고 있는 권순선님

마지막으로 버닝데이에 참가하면서 느낀 점은 ‘버닝데이=개발자들의 축제’ 라는 것입니다. 공대생들의 유머가 통하고 개발 오덕들이 기를 활짝 펼 수 있는 그런 시간과 공간을 경험할 수 있었습니다. 저는 공대생도 아니고 프로그래머도 아니지만 앞으로 기회가 된다면 매년 참가하고 싶습니다. 이런 즐거운 자리를 만들어준 회사와 담당자분들 그리고 함께 했던 동료들에게 감사한 마음입니다.

<div> 요소를 ‘디브, 딥, 디-아이-브이’ 라고 읽는 경우 업계 전문가들은 이것이 무엇을 말하는지 쉽게 알기 때문에 아무 문제가 없습니다. 그러나 이 표현을 듣는 비 전문가들은 <div> 요소에 대하여 발음만 피상적으로 기억하게 될 뿐입니다. 저는 HTML이 전문적인 용어로 취급되거나 전문가들의 전유물이 되어서는 안된다는 생각 때문에 이것을 풀어서 읽어야 한다고 주장합니다.

‘디비젼’이라고 읽게 되면 듣는 사람으로 하여금 ‘division’ = ‘분할’ 이라는 의미를 떠올리게 되고 이것은 <div> 요소의 본래 의미나 바른 용법을 알고자 할 때 중요한 단서가 될 것입니다. ‘디브’라고 표현할 때 ‘dive(뛰어들다), divert(우회시키다), diverse(다양한) …’와 같은 전혀 다른 의미의 용어를 떠올리는 실수는 하지 않게 되겠죠.

아래 열거하는 요소들은 모두 표준 HTML 요소들 입니다. 이 요소들의 공통점은 모두 어떤 단어들이 축약되어 HTML 요소 이름으로 정해진 것들입니다. 한 가지 재미난 실험을 해볼까요? 아래 요소들을 보이는 그대로 읽어서 비 전문가에게 전달한 다음 어떤 의미인지 알아맞혀 보라고 퀴즈를 내보십시오. 풀어쓴 말이 무엇인지. 요소들의 본래 의미가 무었인지. 또한 나는 얼마나 알고 있는지 스스로를 평가해 보십시오. 괄호 안쪽을 드래그 하면 풀어쓴 말을 볼 수 있습니다. 먼저 여러분의 답을 떠올리고 그 다음 풀어쓴 말을 확인해 보십시오.

• abbr (abbreviation)
• cite (citation)
• del (delete)
• dfn (definition)
• div (division)
• em (emphasis)
• img (image)
• ins (insert)
• kbd (keyboard)
• optgroup (option group)
• param (parameter)
• pre (preformatted)
• samp (sample)
• sub (subscript)
• sup (superscript)
• var (variable)

100점을 기록하신 분이 있다면 축하드립니다. 댓글에 코멘트 한 줄 부탁 드립니다. 저도 100점 못 받았거든요. 만약 HTML을 보이는 그대로 읽지 않고 풀어쓴 표현으로 발음한다면 어떠했을까요? 상황이 지금보다 더 좋아지지 않았을까요?

웹의 보편성을 생각할 때 HTML은 모두가 다루기 쉬워야 하고 사용하고 있는 언어가 장벽으로 작용해서는 안된다고 생각합니다. 초등학생들도 HTML을 배웁니다.

웹 전문가 여러분께 질문 드립니다. 전문가들 사이에서만 통하는 말을 하시겠습니까? 되도록 모두가 이해하기 쉬운 표현을 위해 노력 하시겠습니까? 정말 전문가라면 비 전문가인 대중에게 자신의 분야를 쉽게 설명할 수 있어야 하지 않을런지요.

모두가 이해하기 쉬운 표현을 위한 노력에 동참해 주실 분들은 HTML 요소 이름의 풀어쓴 말과 한국말 표현 페이지를 참고해 주세요. 의견도 가감없이 부탁 드립니다. 감사합니다.

저는

1. 기대하고 예측한대로 작동하지 않는 기능은 두 번 다시 거들떠 보지도 않고
2. 전화기를 PC에 연결한다거나 부가 어플리케이션을 설치하는 것을 굉장히 귀찮아 하고
3. 기기 매뉴얼 따위를 읽어보는 것을 끔찍이도 싫어하는

상식적인(?) 사람입니다.

올 한 해동안 사용한 세 종류의 기기는 모두 그 특징이나 호불호가 뚜렷하게 갈리는 제품인데 가장 마지막에 구입한 블랙베리는 아이폰 따위를 잊어도 좋을만큼 제 기대에 충분히 부응하는 그런 스마트폰 이었습니다. oojoo님께서는 꿩 대신 닭이라는 표현을 쓰시던데 저는 닭 먹어보니 꿩 안먹어도 될 것 같습니다.

내가 스마트폰을 사용하는 이유.

제가 스마트폰을 사용하는 이유는 다음과 같습니다.

1. 웹을 통해서 읽고 쓰고 사람들과 소통합니다.
2. 인맥과 일정을 관리합니다.
3. 전화를 합니다.

다른 분들은 ‘음악을 듣는다. 게임기로 쓴다. 네비게이션으로 쓴다.’ 같은 더 많은 이유가 있던데요. 저는 단지 AUX(차량 외부 입력단자)에 연결해서 차 안에서 MP3를 들으면 참 좋겠다는 생각만 가지고 있을 뿐. 이것도 귀찮아서 언제 전화기에 MP3를 옮겨다 놓을지 모르겠습니다. 이쯤 되면 제가 어떤 스타일인지 눈치 채셨겠지요? 단순하고 무식하고 멍청한 스마트폰 사용자 입니다. 저와 비슷한 유형의 소비자들이라면 어떤 기준으로 스마트폰을 선택해야 하는지 약간은 조언을 드릴 수 있을 것 같습니다.

나의 스마트폰 선택 기준.

1. 웹을 브라우징 할 수 있어야 하고 웹과 무선으로 동기화 되어야 한다.
2. 매뉴얼을 읽지 않은 상태로 조작했을 때 기대한 대로 되어야 한다.
3. 꼭 필요한 어플리케이션은 이미 탑재되어 있어야 한다.
4. 반응 속도와 입력 속도가 빨라야 한다.

웹을 브라우징 할 수 있어야 하고 웹과 무선으로 동기화 되어야 한다.

WAP은 콘텐츠도 빈약하고 폐쇠적인데다가 시장도 정체되어 있어서 올해를 기점으로 이미 사양길로 접어들었다(T스토어 접속 웹이 46%로 가장 많음)고 생각 합니다. 저는 올 해 초부터 스마트폰에서 풀브라우징을 통해 웹을 사용하기 시작했고 지금은 전화기를 구매할 때 전화를 할 수 있는지 아닌지의 여부보다 ‘웹을 사용할 수 있는지 아닌지’를 더 중요한 선택 기준으로 생각합니다. 하루 중 약 2시간 가까이 모바일 기기로 웹 서핑을 합니다.

스마트폰을 사용하면서 만족했던 기능은 구글 싱크 였습니다. 구글 싱크를 한번이라도 제대로 사용해 보신 분이라면 다른 스마트폰을 구입할 때 구글 씽크의 지원을 받을 수 있는지 아닌지의 여부는 매우 중요한 구매 조건이 될 것입니다. ‘T*옴니아, 아이팟터치, 아이폰, 블랙베리’는 모두 구글 씽크가 지원하는 기기 입니다. 전화기를 바꿀 때마다 ‘주소록, 일정’ 따위를 옮기기 위하여 ‘전화기를 PC와 연결’하는것은 정말 짜증나는 일입니다. 구글 씽크는 간단하게 무선으로 웹 데이터를 스마트폰과 동기화 시켜 줍니다.

다행히도 올 한해동안 사용한 세 종류의 모바일 기기는 모두 ‘웹을 사용하고 동기화 할 수 있어 만족’ 했습니다.

메뉴얼을 읽지 않은 상태로 조작했을 때 기대한 대로 되어야 한다.

메뉴얼 없이 조작할 때 기대한 대로 되지 않는다는 것은 복잡한 UI를 잘못 설계했다는 의미 입니다.

이 기준으로 제가 사용했던 기기들을 줄을 세워보면 ‘T*옴니아 > 블랙베리 > 아이팟 터치’ 순입니다. T*옴니아는 정말 기능이 많고 조잡하며 예측 불가능한 UI가 많은데 아이팟 터치는 애플 제품이 대부분 그렇듯 매우 단순하고 직관적 입니다. 블랙베리는 단순하지는 않지만 UI를 효과적으로 설계해서 어렵다는 생각이 들지 않습니다. 기대한 대로 찾아가면 거기에 찾는게 있고 기능키도 PC에서 사용하던 것들을 연상해서 눌러보면 예측한 대로 동작해서 착착 감기는 맛이 있다고나 할까요.

이 부분에 대해서는 아이팟 터치를 통한 경험으로 미루어 볼 때 ‘아이폰’과 ‘블랙베리’에게 동등한 점수를 주고 싶지만 평소 PC에 익숙하지 않은 사람이라면 ‘아이폰’을 더 쉽다고 느낄 것입니다.

꼭 필요한 어플리케이션은 이미 탑재되어 있어야 한다.

토핑한다는 표현을 쓰죠. 어플리케이션 내려받아서 설치하고 사용하는 것을 즐거워하는 분들이 많은데 저는 그걸 굉장히 귀찮아 하고 약간의 거부감이 있습니다.

사실 이 부분은 어플리케이션 설치 UI와도 밀접하게 관련이 되어 있는데 어플 설치가 쉬우면 재미를 느끼지만 그 과정이 조잡하면 짜증이 납니다. 어플 설치할 때 보통 PC와 연결해야 하는 ‘T*옴니아’는 가장 짜증 스러웠고 ‘아이팟 터치’는 국가별로 제공하는 어플 목록이 달라서 해외 계정과 국내 계정을 오락가락 하려면 PC와 연결해야 하기 때문에 좀 번거롭지만 저 같은 사람에게도 토핑하는 재미를 주었으며 ‘블랙베리’는 한 마디로 토핑할 필요가 거의 없는 ‘있을건 있고 없을건 없는’ 폰 입니다. 딱히 대중적이지는 않지만 ‘스마트폰 구매자’가 찾을만한 웬만한 기능은 다 있다는 뜻입니다.

‘블랙베리’에서 제가 가장 감동했던 것은 ‘음성인식 콜’ 기능이고 그 다음은 ‘메신져(구글톡, MSN, 야후, AIM, ICQ …)’ 였는데 ‘음성인식’ 기능은 음성 녹음 없이 실시간으로 들리는 한국어 음성을 주소록에서 바로 찾아 전화를 걸어주는 기능 입니다. ‘우리집’ 이라는 단어를 녹음해야 하는줄 알고 불러봤는데 그냥 바로 전화가 걸려버려서 깜짝 놀랐지요.

반응 속도와 입력 속도가 빨라야 한다.

반응 속도를 결정하는 것은 운영체제이고, 입력 속도를 결정하는 것은 입력 인터페이스 입니다.

‘윈도우즈모바일’은 너무 느린데다가 ‘T*옴니아’의 ‘감압식 터치’ 방식은 임계치 이상의 압력을 주어야 하는데 사람의 감각이 그리 정확하지 않기 때문에 정확도가 떨어져서 제게 최악의 경험을 주었습니다. 게다가 ‘스타일러스 펜’은 넣고 빼기가 정말 귀찮고 걸리적 거립니다.  T*옴니아는 느리고 불편하고 정확하지 않았던 거죠.

아이팟 터치는 빠르고 ‘정전기식 터치’ 방식이라서 민감하게 반응했지만 QWERTY 키보드를 누르는것만큼 빠르고 정확하지는 않았습니다. 입력 지연 시간이 있고 엄지 손가락의 살점을 이용하기 때문에 QWERTY에 비하면 오타율이 높을 수 밖에 없습니다. 그러나 웹 브라우징시 ‘줌인/줌아웃’ 할 때 사용하는 ‘듀얼 터치’ 방식은 현존하는 방식 가운데 최고라고 생각합니다.

블랙베리는 자체 운영체제를 쓰고 있는데 거의 지연되는 상황이 없고 QWERTY 키보드는 입력 딜레이와 오타율이 적어서 모바일 기기에서 채용했을 때 가장 효과적인 입력방식 이라고 결론을 내렸습니다. 블랙베리의 트랙볼 조작은 화면을 직접 클릭하는 터치 방식보다 포인터 이동에 좀 더 시간이 걸리는 단점이 있지만 경쾌한 조작감을 줍니다.

결론. 블랙베리, 나의 스마트폰 선택 기준.

지극히 주관적이고 편향적이겠지만 제가 세운 기준에 따라 스스로 평가하고 내린 결론은 이렇습니다.

1. 웹을 브라우징 할 수 있어야 하고 웹과 무선으로 동기화 되어야 한다. = ‘T*옴니아, 아이팟 터치, 블랙베리’
2. 매뉴얼을 읽지 않은 상태로 조작했을 때 기대한 대로 되어야 한다. = ‘아이팟 터치, 블랙베리’
3. 꼭 필요한 어플리케이션은 이미 탑재되어 있어야 한다. = ‘블랙베리’
4. 반응 속도와 입력 속도가 빨라야 한다. = ‘블랙베리’

블랙베리의 한글 서체가 너무 마음에 들지 않는다는 분도 많이 계신데 저도 처음에 그렇게 생각 했었지만 지금은 생각이 바뀌었습니다. 서체는 마누라 얼굴 같다는 생각이 듭니다. 시간이 지나면서 못생긴 얼굴은 점점 이뻐 보이고 이쁜 얼굴은 그냥 그렇게 보입니다. 불편한게 아니라 단지 좋은 첫 인상을 주지 못할 뿐이죠. 사용하다 보면 어느 순간부터 아무렇지도 않고 점점 예쁘게 변하는것 같습니다.

오늘은 웹 전문가들 사이에서 필요로 하는 몇 가지 개념에 대한 이야기를 하려고 합니다. "저 친구는 사람은 좋은데 이 분야에 대한 개념이 좀 없더라구" 이런 소리를 듣지 않으려면 이 분야에서 쓰는 용어에 대한 개념 정도는 탑재를 하는게 좋겠지요. 차라리 "저 친구 네가지는 없는데 이 분야에 대한 개념은 있더라구" 라는 말을 듣는게 더 낫지 않겠습니까?

• "웹 2.0 서비스 구현을 위한 웹 표준."
• "ActiveX를 사용하면 접근성이 떨어진다."
• "1%를 위한 접근성 때문에 99% 사용자를 위한 사용성을 포기 하라구요?"
• "상호 운용성이나 호환성이나 뭐가 달라요?"
• "접근성이나 보편적 설계나 결국 같은 말 아닌가요?"

이런 개념 없는 대화의 주인공 속에는 저도 포함되어 있습니다. 제 블로그 포스트나 댓글에서도 찾을 수 있구요. 지금도 그다지 개념이 충만한것 같지는 않지만 멀리 떠난 개념 찾아 오늘 한번 떠나 보렵니다. 웹 개발자가 기본적인 소양으로 알아 두어야 할 개념 몇 가지를 소개하려고 하는데 사전적인 정의는 위키백과에서 참고하는 것을 더 권장 드립니다. 제가 소개하는 각 용어들의 개념은 백과 사전에는 없는 다소 주관적인 관점 입니다.

웹 표준

W3C는 웹이 상호 운용성(어떤 소프트웨어나 하드웨어에서도 접근 가능한 웹)을 갖는 것을 목표로 하고 있는데 이 때 상호 운용성을 확보할 수 있도록 주요한 수단으로써 제시하고 권고하고 있는 것이 바로 웹 표준 입니다. 여기서 흔히 발생하는 실수는 웹 표준 자체를 목표로 삼는 것입니다. 상호 운용성이라는 목표는 궁극의 가치로써 변하지 않는 것이고 변해서도 안되나 웹 표준이라는 수단은 상황에 따라서 적절히 변형하거나 포기하는등의 방법으로 현실에 임해야 하는데 수단을 목표로 삼게 되면 웹 표준에 고집스럽게 집착하게 됩니다. 단적으로 말해서 웹 표준에 집착하게 되면 정책 결정 과정에서 자칫 현실 감각을 잃고 원래의 목표인 상호 운용성을 포기해 버리는 우스운 상황도 발생하게 됩니다. 저는 웹 표준을 신뢰하고 웹이 표준에 기대는 방법으로 구현되어야 한다고 철썩같이 믿고 실무에 응용하며 지지하는 사람이지만 웹 표준이 현실을 반영하지 못하는 상황에서까지 웹 표준을 물고 늘어지고 싶지는 않습니다. 웹 표준을 이해하되 한계를 알고 표준 자체가 목표가 되어서는 안된다는 생각을 하고 있습니다.

또한 웹 2.0이라는 용어를 웹 표준과 함께 섞어 쓰는 표현은 요 몇해를 통틀어 가장 우스운 표현 가운데 하나라고 생각 합니다. 웹 표준은 웹 2.0 이라는 마케팅 용어가 등장하기 이전부터 이미 존재하는 개념인데 마치 웹 표준이  웹 2.0의 필수 요소이고 기술 스펙이며 트랜드가 된 것처럼 취급하는 문장이 만연 합니다. 웹 2.0 서비스라고 불리우는 웹 사이트들이 상호 운용성을 확보하기 위해 웹 표준에 기대는 경향이 있는 것은 사실이지만 웹 표준이 웹 2.0의 필수 요소도 아니고 웹 2.0 이라는 용어를 기술 스펙 처럼 이해하는 것도 문제라고 생각 합니다. 웹 2.0이 특정 기술 스펙을 요구하고 있다는 식으로 접근하는 것은 잘못된 현상이며 현재의 사회/문화적 측면을 해설하기 위해 창조된 용어로써 이해해야 한다는 겁니다. 좀 더 까칠하게 이야기 하면 웹 2.0 이라는 용어는 마케팅 수단에 불과하다는 생각도 가지고 있습니다.

웹 접근성

웹 접근성은 장애인이 웹을 이용할 수 있는 상태 또는 그것을 측정하는 개념 입니다. 하지만 W3C에서 조차도 이 개념을 이렇게 정의해 놓고 비 장애인들의 접근 환경을 아우르는 개념을 WCAG(Web Content Accessibility Guidelines) 지침에 추가로 언급 함으로써 웹 접근성의 개념 자체를 모호하게 만드는데 일조하고 있다고 생각 합니다. 저도 오랜시간 장애인이 아닌 사용자들의 접근환경을 측정할 때 웹 접근성이라는 개념을 사용해서 잘못된 지식을 전파하고 다녔습니다. 비록 그것이 결과적으로 긍정적이었을지는 모르지만 논란을 불러 일으킬 수 있는 표현이었음을 인정하지 않을 수 없습니다.

ActiveX와 같은 부가 애플리케이션이 비록 Microsoft에 종속된 기술로써 상호 운용성이 없을 지언정 접근성이 없다고 단언하는 등 잘못된 표현을 해왔던 것입니다. 웹 접근성은 장애인이 웹에 접근할 수 있는지를 측정하는 개념이기 때문에 장애인이 IE 브라우저를 통해서 ActiveX를 설치 및 실행할 수 있다면 그것은 자체적으로 웹 접근성을 확보한 상태이기 때문에 접근성이 없다는 표현은 틀린 표현 입니다.

비 장애인의 웹 접근에 관한 개념을 설명할 때에는 ‘상호 운용성, 호환성, 사용성’ 따위의 개념을 빌어 설명하거나 측정해야 합니다. 앞으로 웹 접근성이라는 개념을 사용할 때에는 그 중심에 ‘장애인’이 포함된 개념인지를 분명히 짚고 넘어가 주시기 바랍니다.

사용성

사용성은 효율과 효과를 측정하는 개념 입니다. 흔하게 발생하는 오해는 사용성이 비 장애인들만을 평가 대상으로 하고 있다는 점입니다. 하지만 사용성은 장애인들의 사용 효율과 효과를 측정할 때에도 필요한 개념으로써 사용성 자체는 장애인과 비 장애인을 구분하지 않습니다. 사용성이 비 장애인들의 효율과 효과를 측정하는 개념이라는 오해는 마우스와 같은 특정 입력 장치에만 인터렉션을 의존하도록 만들었습니다.

마우스 클릭 횟수를 줄이고 마우스 휠을 이용해서 탐색하는 방법을 도입함으로써 사용성을 높였다고 말하지만 왜 거기서 장애인과 키보드를 선호하는 고급 사용자는 제외되어야 하나요? 사용성은 그런 개념이 아닙니다. 일단 장애인도 접근할 수 있도록 구현해 놓고 그 안에서 다양한 유형의 사용자 패턴을 모두 고려해야 합니다. 신체 건강한 20~30대 성인 8명쯤 모아놓고 사용성 테스트 진행하면서 얻을 수 있는 결론만으로 웹의 만족도를 10% 증가 시켰다는 이야기는 키보드를 선호하는 사용자들 눈에 그들만의 잔치일 뿐입니다.

사용성 테스트가 뽑아내는 숫자 놀이에 ‘모든 사람의 만족’ 이라는 개념이 빠진것은 아닌지 점검해 봐야 한다고 생각 합니다.

상호 운용성 & 호환성

상호 운용성과 호환성이라는 용어는 사실 둘 중 어느 것을 선택 하더라도 개념 없다고 표현할 만큼 명백하게 구분되는 개념은 아닙니다. 하지만 한 가지 분명한 것은 상호 운용성은 소프트웨어와 하드웨어를 넘나드는 호환성을 지녔을 때 또는 그런 개념을 측정할 때 사용한다는 것이고 호환성은 특정 소프트웨어 또는 특정 하드웨어 안에서만 제한적으로 호환이 될 때에만 사용한다는 점이 다릅니다. 호환성이 있다고 표현할 수 있는 대표적인 기술은 ActiveX 이고 상호 운용성이 있다고 표현할 수 있는 기술은 HTML 정도가 되겠습니다.

만약 앞으로 이런 용어를 사용한다면 그것이 특정 하드웨어 또는 소프트웨어 안에서만 실행 가능한 것인지 하드웨어와 소프트웨어를 넘나드는 것인지를 분별해서 보다 정확한 용어를 사용해야 할 것입니다.

유니버설 디자인

웹 접근성이라는 개념의 중심에 ‘장애인’이 있었다면 유니버설 디자인의 중심에는 ‘모든 사람’이 있다는 점이 다릅니다. 유니버설 디자인은 설계에 있어서 장애인과 비 장애인을 구분하는 것을 금기하고 있으며 모든 사람이 되도록 동일한 방법으로 사용하고 동일한 만족을 얻을 수 있도록 개선하는 것에 초점을 맞추고 있습니다.

웹 접근성이나 사용성은 웹을 측정하는 개념으로써 주로 장애를 제거하거나 개선하기 위하여 사용되는 개념인 반면 유니버설 디자인은 철학 또는 이념으로 이해해야 합니다.

저는 웹 표준, 웹 접근성, 사용성과 같은 각각의 개념들이 모두 모여도 웹을 바르게 구현하는데 한계가 있고 서로 충돌하는 가치도 발생하기 때문에 그 한계를 극복하기 위한 철학으로써 이것이 필요하다고 주장하고 있습니다. 다소 추상적인 개념으로 다가올 수 있으나 유니버설 디자인은 보다 균형잡힌 시각을 길러주고 웹 개발의 궁극의 목표를 잃어버리지 않는데 도움이 될꺼라고 믿습니다.

대화의 기술

이런 주제로 결론을 맺는 것은 아직 세상 덜 살아본 저 자신에게 다소 부담스러운 주제이기도 한데요. 3학년이 되니까 선배랍시고 자꾸 2학년 후배들에게 잔소리를 하고 싶어지네요. 전문 분야에 대한 해박한 지식을 가지고도 대화의 기술이 부족해서 종종 트러블 메이커가 되거나 좋지 못한 평판을 받는 후배들을 응원하고 싶은 겁니다. 3학년 선배들도 2학년땐 그랬거든요.

한참 군생활 하던 시절에 소대 하사관이 "너희들 동그라미가 되고 싶은 세모의 마음을 아느냐" 라는 쌩뚱맞은 질문을 해서 참 실없다 하고 웃고 말았는데 그 질문이 살다보니 한 10년도 지나서 이해가 되더라구요. 지금은 모가 나서 잘 움직이지도 못하고 때로는 다른 사람에게 뾰족한 모서리로 상처를 주기도 하지만 동그라미가 되고 싶은 세모의 마음을 가끔씩 헤아려 봐 주세요.

블로그 포스트를 읽거나 미투데이를 사용하다 보면 다양한 분들의 이야기를 듣게 되는데요. 종종 반박의 여지를 남겨두지 않는 강한 표현들과 비난 수준의 비판이 심심치 않게 발견 됩니다. 부정적인 표현은 긍정적인 표현으로 바꾸는 연습도 해보세요. 욕이 고통을 감소시켜 준다는 실험결과도 있다고 하는데요. 욕을 듣는 사람의 입장을 배려하면 공공 장소에서 함부로 배설하지 않는게 에티켓 이겠죠.

대화의 기술은 나의 지식이 완전하지 않고 세상 속에서 타인들과 부대끼며 다듬어 질 필요가 있다는 것을 깨닫는 것으로부터 출발한다고 생각 합니다. 전문분야의 해박한 지식과 함께 네가지를 갖춘 UI 개발자가 되었으면 좋겠습니다. 일단 저부터 좀 되구요.

모바일 장치는 입력이 매우 불편하기 때문에 사실 블로그에 간단한 댓글을 쓰는것도 귀찮습니다. 일정을 관리한다던가 연락처를 수정하는 것도 마찬가지 일입니다. 좁아 터진 모바일 기기에 터치팬이나 손가락으로 뭔가 입력하는 장면은 걷보기와 다르게 참으로 궁상맞기까지 합니다.

앞으로 일정의 입력은 주로 구글 캘린더로 관리할 예정이고 주소록도 마찬가지 입니다. 그리고 그 결과는 제 스마트폰에 동기화 되어서 출력이 되겠지요. 구글 캘린더에 입력한 결혼기념일 일정은 몇일 있으면 곧 제 스마트폰에서 "결혼기념일이 일주일 남았습니다" 하고 알려줄껍니다. ^^; 스마트폰에 뭔가를 입력하는 수고를 덜어서 매우 좋습니다.

옴니아폰에서 구글에 싱크하는 과정을 캡쳐 하였습니다. 도움이 되시면 좋겠네요.

애플의 아이팟 터치(ipod touch)도 싱크 됩니다. 링크를 따라 가시면 설명이 잘 되어 있으니 저는 생략 합니다. ^^;

그러나 위키 문법은 알고 싶지도 않다.

활용가치가 무척 높은 도구임에도 불구하고 아직까지 대중에게 사랑받지 못하는 이유는 바로 위키 문법 때문이라고 생각합니다. 웹 문서 형식에 익숙한 제가 쓰기에도 불편하고 위키 종류마다 문법도 각각 달라서 리치 텍스트 편집기가 없으면 도무지 글을 쓸 엄두가 안납니다. 위키 문법은 복잡한 HTML 문법을 대체할 목적으로 개발되었지만 또 하나의 골치 아픈 문법이 되었습니다. 현존하는 각종 브라우징 기기들이 대부분 자바스크립트를 지원하므로 리치 텍스트 편집기는 거의 모든 브라우저에서 구동 됩니다. 이런 시점에서 위키 문법이 꼭 필요한 것인지를 생각하건데 더 이상은 필요 없다고 생각합니다 시각장애인등 리치 텍스트 에디터 사용이 용이하지 않은 사람에게는 여전히 필요하다고 생각합니다. 스프링노트는 사용자에게 문법 따위를 고민하지 않도록 하면서도 시멘틱한 글쓰기를 유도하고 있습니다. 저는 위키를 설치하자 마자 미디어위키 전용 FCK 에디터를 확장기능으로 추가 했습니다. 문법이 복잡한 표 데이터도 쉽게 작성할 수 있기 때문에 무척 만족스럽습니다. 

기본 스킨 디자인으로는 만족 못해.

기본 스킨은 현재 위키백과에서 사용중인 스킨 입니다. 그러나 기본 스킨을 비롯하여 여분의 7개 스킨은 하나같이 만족스럽지 않아서 검색을 통해 다른 스킨을 찾았고 현재 모질라 위키에 적용된 스킨이 공개되어 있다는 것을 알았습니다. 아래 이미지는 모질라 스킨의 일부 입니다. 제가 보기에는 모질라 스킨이 가장 깔끔 하더군요. 조금 더 큰 스킨 이미지 보기.

모질라 스킨 적용하니 FCK 에디터 작동 안해 스킨 코드 수정 필요.

스킨이 2006년도에 공개된 후 버전 업데이트가 되지 않아서 FCK 에디터 출력에 필요한 자바스크립트를 로드하지 않는것 같아 보였습니다. 기본 스킨인 모노북 템플릿 으로부터 자바스크립트를 불러내는 부분을 찾아내어 모질라용 스킨에 덮어쓰기 하니 제대로 작동 하는군요.

수정 전 코드

<?php if($this->data['jsvarurl']) { ?>
<script type="text/javascript" src="<?php $this->text('jsvarurl'  ) ?>"></script>
<?php } ?>
<script type="text/javascript" src="<?php $this->text('stylepath' ) ?>/common/wikibits.js"></script>
<?php if($this->data['usercss']) { ?>
<style type="text/css">
<?php $this->html('usercss' ) ?>
</style>
<?php } ?>
<?php if($this->data['userjs']) { ?>
<script type="text/javascript" src="<?php $this->text('userjs' ) ?>"></script>
<?php } ?>
<?php if($this->data['userjsprev']) { ?>
<script type="text/javascript"><?php $this->html('userjsprev') ?></script>
<?php } ?>

수정 후 코드

<?php print Skin::makeGlobalVariablesScript( $this->data ); ?>
<script type="<?php $this->text('jsmimetype') ?>" src="<?php $this->text('stylepath' ) ?>/common/wikibits.js?<?php echo $GLOBALS['wgStyleVersion'] ?>"><!-- wikibits js --></script>
<!-- Head Scripts -->
<?php $this->html('headscripts') ?>
<?php if($this->data['jsvarurl']) { ?>
  <script type="<?php $this->text('jsmimetype') ?>" src="<?php $this->text('jsvarurl') ?>"><!-- site js --></script>
<?php } ?>
<?php if($this->data['pagecss']) { ?>
  <style type="text/css"><?php $this->html('pagecss') ?></style>
<?php }
  if($this->data['usercss']) { ?>
  <style type="text/css"><?php $this->html('usercss') ?></style>
<?php }
  if($this->data['userjs']) { ?>
  <script type="<?php $this->text('jsmimetype') ?>" src="<?php $this->text('userjs' ) ?>"></script>
<?php    }
        if($this->data['userjsprev']) { ?>
        <script type="<?php $this->text('jsmimetype') ?>"><?php $this->html('userjsprev') ?></script>
<?php    }
        if($this->data['trackbackhtml']) print $this->data['trackbackhtml']; ?>

리치 텍스트 에디터 확장 없이 WYSIWYG 편집하는 방법.

확장 기능 사이에 문제가 발생하여 FCK 에디터를 사용할 수 없거나 글을 작성하는 곳이 미디어위키가 맞지만 리치 텍스트 편집기가 설치되어 있지 않아 불편하다면 Firefox 브라우저를 사용하고 BBComposer 라는 확장을 추가하는 것도 차선책이 될 수 있습니다.

글 입력상자^textarea 위에서 오른쪽 마우스를 클릭하면 ‘BBComposer’ 문맥 메뉴가 등장.

글 입력상자는 즉시 WYSIWYG 상태로 전환이 되거나 설정에 따라 아래와 같이 새 탭으로도 출력된다.

위키 한 번 써보세요!

위키 설치에서 잘 쓰는 요령까지 두루 알려 드렸으니 이제 참여 하셔야죠? 현재 다음과 같은 콘텐츠를 제 위키에서 운영 중입니다.

• UI 개발자를 위한 북마크 – UI 개발자를 위한 북마크를 함께 만들어봐요!
• WCAG 2.0 – 웹 콘텐츠 접근성 지침 2.0 한국어 번역에 참여하세요!

모든 문서는 누구에게나 열려 있으며 새로운 문서를 추가하거나 기존의 문서를 편집하면서 발생할 수 있는 부작용에 대하여 아무런 책임을 지지 않으셔도 됩니다. 자유롭게 이용하세요.

작성한 모든 콘텐츠는 배타적 소유권을 주장할 수 없으며 공공의 이익을 위하여 기증한 것으로 간주 합니다. 저작권이 있거나 보안으로 취급되는 내용을 기록하지 마세요. 여러분이 작성한 문서를 다른이가 편집할 수 있으며 선의든 악의든 훼손할 수도 있음을 미리 알아두세요. 편집에 참여한 사람이나 운영자는 모든 상황에서 아무런 권리와 책임도 취하지 않을 것입니다.

여러분을 믿구요. 또 강력한 되돌리기(복구)기능이 있으니 너무 걱정하지 않으셔도 됩니다. ^^

웹 기반의 TTS 솔루션이 접근성을 향상시켜준다는 거짓말.

TTS 솔루션은 웹 페이지의 글자를 음성으로 출력해주는 장치로써 커서 또는 캐럿이 위치한 곳의 텍스트를 음성으로 출력해 주는 원리로 작동 되는데 크게 두 종류로 나뉩니다.

1. 데스크탑 기반의 TTS  – 사용자 PC에 설치되는 TTS로써 흔히 ‘스크린리더’ 또는 ‘화면낭독기’ 라고 불리우며 웹 페이지 뿐만 아니라 윈도우즈 운영체제 구성요소까지 모두 음성으로 출력해 주는 소프트웨어 입니다. 국내에는 ‘센스리더‘라는 제품이 시각장애인들 사이에서 가장 많이 사용되고 있습니다.
2. 웹 기반의 TTS – 특정 웹 사이트에 종속된 TTS로써 웹 사이트에 접속할 때 ActiveX 또는 Window Media Player 등을 구동시켜 웹 페이지의 문자를 음성으로 출력해 줍니다. 하지만 사용자의 포커스가 웹 브라우저의 뷰포트(화면표시영역) 바깥쪽으로 나갔을 때 아무런 음성을 출력하지 않으므로 음성을 이용하여 브라우저를 제어해야 하는 시각장애인들에게는 무용지물 입니다.

웹 기반의 TTS 제조사는 이 솔루션을 웹 사이트에 탑재 하기만 하면 마치 시각장애인(전맹 또는 약시 포함)들이 웹 페이지를 제대로 사용할 수 있을 것처럼 말하지만 이것은 새빨간 거짓말 입니다. 웹을 이용하는 모든 시각장애인들은 이미 데스크탑 기반의 설치형 TTS 장치를 보유하고 있습니다. 데스크탑 기반의 TTS를 보유하고 있지 않으면 PC를 부팅하거나 웹 브라우저를 띄울 수 있는 방법이 없기 때문입니다. 이 말이 사실인지 확인하고 싶으시다면 지금 당장 눈을 가리고 운영체제를 재 부팅해서 제 블로그까지 찾아와 보시기 바랍니다. 데스크탑에 설치된 화면낭독기의 도움 없이 이것은 원천적으로 불가능한 일입니다.

장애인을 위한 별도의 텍스트 기반 웹 사이트는 필요 없습니다.

웹 기반의 TTS 제조사는 웹 페이지에 포함되는 텍스트 이외 각종 RIA^{Rich Internet Application} 콘텐츠들이 일반적으로 접근성이 떨어지기 때문에 별도의 텍스트 기반 웹 사이트가 필요하다고 주장합니다. RIA 콘텐츠가 일반적으로 접근성이 떨어지는 것은 사실이나 그것은 어디까지나 RIA 기술을 구현하는 단계에서 접근성을 확보하지 못한 것일 뿐 RIA 기술 자체가 접근성이 없는 것은 아니기 때문에 별도의 웹 사이트 구축은 어디까지나 최후의 수단이 되어야지 최선의 수단이 되어서는 안됩니다.

또한 웹 기반의 TTS 제조사는 웹 접근성 지침을 잘못 해석하여 자신들의 사업에 유리한 방향으로 해석하고 있습니다. 다음은 국내 표준으로 자리잡은 인터넷 웹 콘텐츠 접근성 지침 가운데 관련 항목 입니다.

항목 4.2 (별도 웹사이트 제공) 콘텐츠가 항목 1.1에서 4.1에 이르는 13개 검사 항목을 만족하도록 최대한 노력하였으나 해결되지 않는 부분이 남아있다면 텍스트만의 콘텐츠를 제공하는 웹 페이지(또는 웹사이트)를 별도로 제공해야 한다.

이 항목은 별도의 웹 사이트 제공을 권장한다는 의미가 아닙니다. ‘최대한 노력하였으나 해결되지 않는 부분이 남아있다면’ 이라는 전제가 깔려있기 때문에 별도의 웹 사이트 제공은 최후의 수단이 되어야 한다는 점을 명시하고 있습니다. 신기술이 접근성을 확보하지 못했을 때에만 제공하라는 의미로써 현재의 웹에 보편적으로 통용되는 신기술들(RIA)은 자체적으로 접근성을 확보할 수 있도록 대부분 기술지원이 되고 있습니다. 따라서 우선은 RIA의 접근성을 확보하는 작업이 선행이 되어야지 RIA의 접근성은 개선하려는 노력도 없이 별도의 텍스트 기반 웹 사이트를 제공하려 한다면 이것은 올바른 문제해결 순서가 아닙니다.

웹 접근성 때문에 불필요한 예산을 낭비하지 말아 주세요.

웹 접근성을 확보하기 위하여 무엇을 더 추가할 것인지 고민하기 보다 무엇을 더 빼야 할 것인지를 생각해주세요. 웹 기반의 TTS 솔루션 구입비용과 별도의 텍스트 기반 웹사이트에 소요되는 비용은 완전히 예산 낭비 입니다. 웹은 현존하는 기술만으로도 충분히 접근성을 확보할 수 있도록 표준을 제공하고 있고 신기술을 제공하는 기업들(Adobe, MicroSoft)도 W3C 표준과 미국의 재활법에 따라 자체적인 접근성을 지원하기 때문에 HTML 문서 한장만으로도 정상인과 장애인이 동등하게 접근할 수 있습니다. 웹에 무언가를 추가하려고 할수록 웹은 더욱 조잡하게 변질되고 유지보수 비용은 늘어날 것입니다. 제 문제가 아니라면 뒷짐지고 구경만 하고 있을 일이겠지만 세금 꼬박꼬박 납부하는 국민의 한 사람으로써 공공분야 정보화 담당자 분들께 간곡히 부탁드립니다. 웹 기반의 TTS 솔루션을 탑재하거나 별도의 텍스트 기반 웹 사이트를 제공하지 않고도 당당히 ‘웹 접근성 품질마크’ 인증을 받은 공공기관 웹 사이트를 소개합니다. 더도 말고 덜도 말고 딱 이만큼만 하시면 됩니다.

• 국가지식포털
• 국토해양부
• 보건복지가족부
• 부산광역시
• 산림청
• 우정사업본부
• 청와대
• 한국원자력문화재단
• 한국정보문화진흥원
  
• 한국조폐공사
  

상기 정보화 담당 부서에 연락하셔서 어떻게 웹 접근성 품질마크 인증을 획득할 수 있었는지 자문을 구해보실것을 추천 드립니다. 웹 접근성 품질마크 인증은 공공기관들의 경영평가 항목에도 포함되어 적지않게 점수로 반영될 예정인 것으로 알고 있습니다. 부디 지혜롭게 현안을 해결해 주시리라 믿습니다.

강의 수시간 전에 도착한 저희는 석찬님의 안내로 ‘어우늘‘이라는 전복요리 전문점에 들러 식사를 했었는데요. 생전 처음 먹어보는 전복구이맛에 그만 홀딱 반해 버렸습니다. 전복구이는 직접 불에 그을린듯한 전복향과 입속에 퍼지는 육즙이 일품입니다. 이날 석찬님께서는 제주에서 이름난 맛집만 골라 안내 해주시며 저녁까지 풀코스로 쏘셨습니다. 게다가 다음 GMC^{Global Media Center} 사옥에 초대하여 구석구석 직접 안내까지 해주시는 친절까지 베풀어 주셔서 너무 즐거운 추억이 되었고 이 자리를 빌어 감사드립니다. 사진을 몇장 찍었는데요. 함께 보시죠. ^^

제주시 오등동 다음 커뮤니케이션 글로벌 미디어 센터.

제주시에 이렇게 눈이 내리는 날은 흔치 않다고 하는데 저희는 운이 아주 좋았군요. ^^

제주도에 돌하르방이 많지만 이런 하르방은 여기 밖에 없을껄요. ㅎㅎ.

출입구 안내 데스크로 누구나 평일 오후 2시에 방문하면 직원의 안내를 받아 사옥 구석구석을 돌아볼 수 있습니다.

휴식공간겸 카페테리아로 일반인들의 출입이 허용되어 있는 곳입니다.
계단이 없어서 휠체어도 접근하기 좋네요. ^^

카페테리아에서 커피 한잔 시켜놓고 책을 읽거나 인터넷도 할 수 있군요.

사무공간을 빠져나오면 바로 이런 휴게공간이 마련되어 있습니다.

직원들에게 무료로 상시 제공되는 음료와 먹을 거리들.

쉬면서 게임도 즐길 수 있는곳이 여러곳 마련되어 있더군요.

세상에. 헬스장까지. 이런거 부러워하면 안되는데. ㅜㅜ;

캐빈이라고 하는 프로젝트룸에 비치된 망원경. 어렸을 때(사실 지금도) 무지 갖고 싶어했던 아이템.

공원 아닙니다. 다음 직원들을 위한 운동장입니다. 저 농구장 옆에는 바베큐 파티장도 따로 있어요.

인근 주거단지 인데요. ‘다음이 살면 나라가 살고, 다음이 망하면 나라도 망한다’는 문구가 인상적입니다.
이렇게 응원하는 국민들이 있는 한 다음이 망하기는 쉽지 않겠는데요. ㅎㅎ.

사무공간은 건물 이곳저곳에 부서별로 나뉘어 있고 현재 약 150여명 정도가 근무하고 있다고 합니다.

좌로부터 정찬명, 윤석찬, 고영수 입니다. ^^ 세 사람의 공통점은 뭘까요?

제주대학교 컴퓨터공학과 오픈소스 개발 방법론에서 XE에 대해 설명중이신 고영수 팀장님.

같은 수업에서 오픈 UI 프로젝트를 설명하고 있는 정찬명.

흑돈가라고 하는 곳에서 간단한 음주와 함께 학생들과 저녁식사. 지금까지 먹어본 돼지고기들을 의심하게 됨.
한라산이라는 소주가 있다고 하기에 함께 들었는데 소주도 나쁘지 않더군요.(사실 소주맛 잘 몰라요 ㅡㅡ;)

제주공항을 이륙하고 있습니다. 왜 공항에는 눈이 쌓이지 않는거죠? ㅜㅜ; (무슨생각으로 이럴까요)

남해 상공. 하늘과 바다 그리고 섬들이 정말 아름다운.

서울 톨게이트 보이세요? 저희 회사도 보이고 집도 보이네요. ㅎㅎ.

IE 점유율이 전 세계적으로 90% 이상을 육박하고 있을 당시에 우리는 다른 브라우저의 호환성을 고려하지 않고 오직 IE 제품을 기준으로 웹 개발을 진행하게 되었습니다. 그때 당시의 저는 ‘웹 표준’이라는게 있는지도 모르던 시절이고 IE 이외의 다른 브라우저가 있다는 사실도 알지 못했습니다. 하지만 IE 브라우저의 시장 점유율은 2004년부터 서서히 낮아지기 시작하여 2008년 하반기 현재는 70% 이하로 4년만에 약 20%나 떨어져 버렸습니다. 대안 브라우저들이 세상에 알려지기 시작했기 때문이고 비로소 저희는 IE 이외의 다른 브라우저를 고려해야겠다는데까지 생각이 미칩니다. 그리고  브라우저간 호환성을 유지하기 위하여 가장 손쉬운 방법을 찾게 되는데 이것이 바로 ‘웹 표준’ 이었습니다. 물론 처음에는 브라우저 호환성을 유지하기 위하여 웹 표준을 하나의 개발 방법론으로 받아들이기 시작 했지만 ‘웹 표준’이 단순하게 브라우저 호환성만을 유지하기 위한 수단으로 치부하기에는 너무 매력적인 가치를 지니고 있었습니다. ‘웹의 상호 운용성’을 넘어 ‘보편적 설계’까지 바라보게 만드는 계기가 됩니다. ‘웹 표준’은 모든 사람이 평등하게 웹에 접근할 수 있도록 잘 설계된 지침이었다는 것을 깨닫게 된 것입니다.

모든 사람이 평등하게 웹에 접근할 수 있어야 한다는 가치는 IE 6 사용자라도 예외가 없습니다. 아무리 버그가 많다 할지라도 시장 점유율이 0.1% 미만으로 떨어지기 전까지는 확실하게 하위 호환성에 대한 지원을 해야 합니다. NAVER 서비스 가운데 메이져 서비스들은 출시된지 10년이나 지난 제품인 IE 5.5 버전에서도 잘 볼 수 있도록 하위 호환성이 유지되고 있습니다. 하지만 이렇게 하위 호환성을 유지하는데에는 매우 큰 비용이 들어갑니다. IE 5.5 ~ IE 6브라우저들의 버그들은 윈도우가 업데이트 될 때 함께 업데이트 되는 것이 아니기 때문에 출시할 당시의 버그들은 대부분 현재까지도 존재하고 이러한 문제들은 UI 개발자들이 해결하게 됩니다. 개인적인 경험으로 미루어 UI 개발자들은 하루 일과중 적게는 30% 에서 많게는 50% 까지 IE 버그를 해결하는데 시간을 소비하게 됩니다. 이것은 UI 개발자들이 더 창의적이고 고도화된 업무에 집중할 수 없도록 만드는 원인 입니다. UI 개발은 예전과는 다르게 다른 직군의 개발자들이 넘보기 어려울만큼 고도화 되었고 쉽지 않은 분야가 되었지만 여전히 박봉에 아직도 HTML 코더 쯤으로 밖에 생각하지 못하는 사람들이 태반입니다. UI 개발 직군을 HTML 코더 쯤으로 밖에 생각하지 못하는 사람들은 그들이 처음 HTML만 가지고 웹을 만들던 시절만 생각하기 때문입니다. 지금은 UI 개발자가 자리를 비우면 이 일은 디자이너도 서버측 개발자도 대신할 수 없을만큼 어려운 일이 되어 있습니다.

저는 최근 XE UI 개발에 참여하면서 다른 사람들도 XE 스킨을 쉽게 만들고 다룰 수 있도록 지원하기 위하여 IE 버그들을 문서화 하는 작업을 시작하였습니다. 아직 국내에 적절한 레퍼런스가 없었고 누군가는 해야 할 일인데 아직 아무도 시도하지 않았으니 한번 해보자는 심정으로 시작하고 있습니다. 물론 해외에 잘 정리된 레퍼런스들이 있고 참고할 것입니다.

상황이 이렇다 보니 이미 해외에서는 대중들에게 IE 6 브라우저를 업그레이드 해줄 것을 요청하는 캠페인이 있었습니다. SAVE THE DEVELOPERS! 라는 이름으로 진행된 이 캠페인은 몇 달 지나지 않아 곧 MS IE 최신버전을 다운받을 수 있는 페이지로 Redirect 되면서 원래의 페이지는 사라져 버렸습니다. MS 에서 회유를 한 것인지 자진해서 그렇게 처리한 것인지는 잘 모르겠지만 이런 종류의 캠페인은 할만 하다고 생각 했습니다. 평소 친분있는 조현진님께서 ‘저희도 할까요?’ 라고 하시기에 ‘하면 좋지요. 최대한 불쌍하게~’ 라고 응수 했는데 눈 깜짝할 사이에 ‘개발자 좀 살려주세요!‘ 라는 페이지를 만들어서 보여주시더군요. 그래서 저는 배너를 준비해 두었습니다.

SAVE THE DEVELOPERS <!> Upgrade IE 6 Now!

이미지 처럼 보였다면 제가 잘 속였군요. ^^; 배너는 텍스트와 HTML/CSS 코드로 단 한줄 작성 하였고 IE 6 브라우저 사용자들에게만 보이도록 배너를 가져다 쓰는 사람이 선택 할 수도 있습니다. 그리고 이 캠페인의 구체적인 행동강령은 이렇습니다. 학교, 회사, PC방, 미용실, 병원등 공공장소에 설치된 PC에서 IE 6를 발견하시면 IE 최신 버전으로 업그레이드 하는 겁니다. 인터넷 환경을 좀 더 쾌적하게 업그레이드 한다는데 반대하실 분들은 아마 없겠죠? 사람 하나 살리는 셈 치고 좀 도와 주세요. ㅜㅜ;

보통의 남자들이 그러하듯 처음에는  기계에 무척 많은 관심이 많았었습니다. 지금 생각해도 니콘 FM-2 라는 이름을 지닌 수동 카메라는 한 때의 생활고로 팔아치운일이 무척 아깝다는 생각이 드네요. 제가 북극에 갈일은 없겠지만 그놈은 북극에 가서도 사진을 찍을 수 있는 녀석이라고 하는 그런 놈이었죠. 고전적이면서도 극한의 상황에서도 버틸 수 있고 찍는 사람의 실력에 따라서 천지차이의 느낌이 나는 아주 다루기 힘든 녀석이었다고 생각 됩니다. 어머니께서는 아버지의 수동카메라를 늘 둘째 마누라 라고 볼멘소리로 치켜 세우셨지만 저는 카메라를 여자에 비유한 것이 매우 적절한 표현이었다고 생각되네요. 정말 콧대높고 까다로운 그녀는 쉬운 상대가 아니었죠.

하지만 디지털 카메라의 기술 발전은 저와 같이 대충 찍기를 좋아하는 사람들도 아마츄어의 반열에 오를 수 있도록 독려하는 계기가 됩니다. 저는 굉장히 많은 사진을 경제적인 부담 없이 찍을 수 있게 되었고 득도하는데 많은 도움이 되었습니다. 아무리 사진을 못 찍는 사람이라도 많이 찍다보면 그 가운데 건질만한게 나오니까요. 그리고 제 사진을 보는 사람들의 피드백은 곧 더 좋은 사진을 찍는 계기가 됩니다. ‘이 사진 너무 잘나왔다’ 라는 한마디에 그와 비슷한 구도와 장면을 다시 한번 연출하려고 노력하게 되죠.

이쯤 되면 혹시 저를 아마츄어 사진작가쯤으로 오해하실 만한 분들도 계실까 싶어 미리 말씀 드리자면 ‘아마츄어’는 맞지만 ‘사진작가’는 아닙니다. ‘술 잘 먹어요?’ 라는 질문에 그냥 ‘좋아는 합니다’ 라고 답변하는것 같네요. 정말 그냥 좋아만 합니다. 그래서 이런 이야기를 하는 것이 주제넘지는 않을까 라는 걱정도 들지만 그럼에도 불구하고 사진에 대한 철학이나 노하우 같은 것들을 공유하고 싶습니다.

좋은 사진은 카메라로 찍는게 아니다.

이 글의 본문에 삽입된 첫 번째 본인 사진을 제외한 나머지 사진은 모두 제가 촬영한 사진인데요. 좌측에 보시는 사진은 똑딱이만으로도 늘 좋은 사진을 즐겨찍는 제 친구의 사진입니다. 보이시죠? 똑딱이. 저 카메라를 들고 함께 사진여행을 떠났다가 한 겨울에 눈밭에 누워서 서로를 찍어주는 장면 입니다. 제가 가장 좋아하는 제 사진(맨 위 첫 번째 사진)을 찍어준 오랜 친구죠.

저는 사진에 대한 이론이나 원리를 조금 알게 된 사람들이 하나같이 격는 단계가 바로 장비에 대한 집착 이라고 생각합니다. 사진 동호회에 나가면 늘 새로 나온 카메라에 대한 이야기를 끝도 없이 늘어놓고 다른 회원들의 악세사리는 너무 편해 보이고 신기하기까지 합니다. 저는 가난해서 가진거라고는 카메라와 삼각대 그리고 열정 밖에 없는데 왜 자꾸 제 멀쩡한 렌즈를 바꾸라고 성화인지 모르겠습니다. ㅜㅜ; 

물론 이해는 합니다. 더 좋은 카메라와 더 좋은 렌즈가 있으면 사진은 더 깊은 맛을 내면서 보는 사람들의 탄성을 자아냅니다. 하지만 그리고 끝입니다. 저는 묘사가 뛰어난 사진보다는 무엇인가를 상상하게 만드는 그런 사진이 좋습니다. 그래서 사람들이 제 앞에서 장비 이야기를 너무 장황하게하면 저는 이렇게 말합니다. "그래서 장비값은 좀 하니? 내 생각에는 말이야. 장비는 좋은 사진을 찍는데 10% 밖에 기여하지 않아. 무엇 없는 목수가 연장탓을 하는 법이지."

제가 생각하는 좋은 사진이란 바로 이런 겁니다.

1. 운 좋게도 그 시간에 그 사람과 그곳에 있을 수 있었고 (50%)
2. 식상하지 않은 황금 구도를 잡은 후에 (30%)
3. 카메라를 적절하게 다룬 결과 (10%)

여기에 ‘좋은 장비’까지 있어준다면 그야말로 100% 완벽한 사진을 찍을 수도 있겠죠? 결국 좋은 사진을 찍으려면 하늘이 내려주는 자연이나 사람과의 인연이 있어야 한다는 생각을 했고 이것은 노력 여하에 따라 얼마든지 만들 수도 있다고 생각 합니다. 절대로 좋은 장비를 갖추는게 먼저가 아니라는 생각입니다. 전문가가 아니라면 말이죠.

좋은 사진은 교본에서 나오지 않는다.

사진에 입문하기로 마음먹은 이상 더 좋은 사진을 찍기 위해 인터넷에서 강좌를 찾아 보거나 책을 읽게 됩니다. 사진에 대한 이해와 장비에 대한 기본적인 소양을 기르는데 더 없이 좋습니다. 그러나 정말 좋은 사진은 교본에서 나오지 않는다고 생각 합니다. 메뉴얼 대로 사진을 찍으면 그저 문안한 결과를 얻을 수 있을 뿐 메뉴얼을 벗어나기가 쉽지 않게 될 것입니다. 

사진 촬영의 기교 가운데 제가 가장 중요하게 생각하는 것은 바로 ‘구도’ 인데요. 메뉴얼 대로 찍으면 대체로 문안한 사진을 얻을 수 있습니다. 얼떨결에 저희 집사람을 처음 소개해 드리네요. 표정도 무척 행복해 보이고 적절한 구도로 잘 클로즈 업된 사진입니다. 나쁘지 않군요. 일단 배운대로 찍었으니까요. 하지만 늘 이런 구도로만 사진을 찍는다면 집사람 보다 제가 먼저 식상할 것 같네요. 집사람 말고 사진이요.

교본에서는 앵글을 가로 세로로 3등분 한 다음 촬영 대상을 각각의 선이 교차하는 4개의 지점 중 한 곳에 두고 시선 방향으로 여백을 주라고 알려 줍니다. 인물의 표정을 촬영하는 경우는 되도록 인물의 장점이 잘 부각될 수 있도록 클로즈 업. 최악의 인물 사진은 화면을 배경으로 가득 매운 다음 사람은 앵글 한 가운데 콩알만하게 서 있고 발목은 앵글 밖으로 사라진 사진입니다. 메뉴얼과는 별 상관이 없이 막 찍은 저희 아들 사진은 어떤가요? 자동카메라로 대충 찍은듯 구도나 여백은 형편 없지만 모델의 표정 하나로 다른 모든것을 압도하지 않나요? 교본에서는 언제 사진을 찍으라고까지 알려주지는 않죠. 저런 순간을 잡아내는 것은 순전히 촬영하는 사람과 촬영 당하는 사람의 교감에 달려 있다고 생각합니다. 촬영 대상에 대한 애정이나 연민이 없으면 절대로 좋은 사진을 찍을 수 없을껍니다.

사진은 대본없는 인생 다큐멘터리.

사진을 취미로 한다고 말하기가 무색하게 요즈음에는 누구나 사진을 찍습니다. 그리고 사진만을 위한 여행을 떠나기도 하는데요. 사진이 목적인 여행을 떠날 때마다 느꼈던 점은 참 허탈하다는 점입니다. ‘이번에는 꼭 대박을 치고야 말겠어’ 라며 복권을 사고는 늘 마지막에 헛탕치는 그런 기분이죠. 대박의 꿈은 이제 접었습니다. 굳이 밖으로 나가야만 할까요?

그렇다고 일상 속에서 언제 있을지 모르는 절호의 찬스를 기다리고만 있을 수는 없는 일인데요. 저는 그냥 생각날 때 꺼내서 찍습니다. 카메라를 눈에 잘 보이는 곳에 둔 다음 집에서도 찍고 주말에 야외에 놀러 갈 때에도 그저 생각나면 챙겨가는 수준이지요. 불규칙하지만 자주 찍는것이 좋다고 생각해서 그렇게 하고 있습니다.

이렇게 사진을 찍다보니 아들이 4살이 되는 동안 4,000여장의 사진을 찍게 되더군요. 한해 평균 약 1,000장의 사진을 찍었고 하루 평균 2.7장의 사진을 찍은 샘입니다. 엄마 뱃속에서 찍은 초음파 사진으로 부터 시작해서 저희 아들 녀석이 크는 모습은 적어도 한 달에 한 차례 이상 촬영하고 있으니 대본없는 한편의 다큐멘터리가 되어가고 있습니다.

이렇게 모아진 사진들은 몇년에 한 번씩 썸네일 형태의 사진들로 가득 매워진 포토북으로 만들 계획이고 이미 올해 두 권의 포토북을 주문하게 되었습니다. 4살이 되는 동안 조금씩 성장하는 모습이 빼곡히 들어 있으니 나중에 아이가 성장해서 보면 얼마나 좋을까요? 부모에게 얼마나 사랑받고 자랐는지 알게 되겠지요.

아직 결혼하지 않았다고 해도 상관 없습니다. 사랑하는 연인 또는 가족과 행복한 시간들을 자주 사진으로 기록해 두시고 나중에 꼭 인화하거나 책으로 만들어보세요. 노년을 대비해서 보험을 드는 것보다 훨씬 좋다고 생각합니다. 아픈 다음에 보험금 받아야 무슨 소용인가요? 내일 당장 죽더라도 ‘난 참 행복한 인생을 살았어’ 라고 회상할 수 있다면 더 좋지 않을까요? 지금 당장 사진기를 잘 보이는 곳으로 끄집어 내 놓으시죠!

PS : 괜찮은 사진공유 서비스 있으면 소개좀 해주세요 ㅡㅡ;