우선 자극적인 제목에 죄송합니다. 이 글을 보시는 분들은 아마 한국 마이크로소프트의 학생 파트너인 MSP의 지원자분 일 것이라고 생각합니다. 이제 OB로 물러난 선배 MSP가 왠 자극질(?)이냐 싶겠지만, 4기, 5기 혹은 그 뒷 기수 후배들을 위해 저만의 면접 노하우(?)를 공유하고자 합니다.
면접(面接, Interview)은 사전적인 의미론 조사,진단, 시험, 취재의 목적으로 개인 혹은 집단과 대면하여 필요한 정보를 수집하는 절차를 뜻한다고 합니다. 아마 이번이 면접이 처음이신 분들도 있으실 것 같고, 우리나라의 알흠다운 병역 제도인 병역특례나 인턴으로 인해 면접을 한 두 번쯤 경험해 보신 분들도 있으실거라고 생각합니다.
여하튼, MSP 선발 과정 중 면접이 차지하는 비중은 어마어마 합니다. 내부에서는 면접이 MSP 전형 중 꽃(?)이라고 불리기도 합지요. 그만큼 지원자들의 얼굴을 본다는 건 아니고(그럼 내가 어떻게 붙었겠어…) 블로그와 딱딱한 지원서에서 벗어나서 좀 더 여러분들과 자세히 만나고 다양한 이야기를 듣고자 하기 위해 마련된 자리이죠.
이 글은 어떤 의도로 작성되었나요?
이 글을 작성한 작성자는 어떤 의도로 이 글을 작성하였을까요. 우선 제 소개가 늦은 것 같습니다. 저는 기술 분야 MSP로 활동한 이희덕입니다. 어찌보면 여러분들과 같이 1차, 2차전형을 모두 경험해본 사람 중 하나이기도 합니다.
이 아티클의 타이틀을 다소 과격하게 잡은 것도, 사실은 제가 MSP를 두 번 지원해서 합격했거든요. 한방에 붙은 2기, 3기분들은 좀 부럽기도 합니다만, 2기 때도 면접을 경험해 보고 떨어져서, 여러분들께 다소 도움이 될만한 경험들을 공유할 수 있지 않을까 싶습니다.
그 외에 불순한 의도로는, 4기 여러분들과 다소 친하게 지내고 싶다는 거(술자리 가서 아무도 아는 척 안 해주면 쓸쓸하잖아.. 아는 척 좀 해달라고 뇌물 쓰는거임 ㅇㅇ), 그 외에 블로그 트래픽을 높이려는 의도도 있습니다.
MSP 면접은 왜 실시하는 건가요?
“아 귀찮게 시리 쓰라는 건 왜이리 많고, 헉 블로그 글도 써야되? 근데 주제는 정해져있어 이건 뭐야 무서워. 게다가 면접까지 보러 오래. 왜이리 귀찮은 게 많아” - 2기, 3기 지원할 때 희희덕덕의 생각
사실 면접 전형은 어느 학생 프로그램에서나 다 실시하고 있는 절차 중 하나이지만, 입사 전형도 아닌데 면접까지 꼭 봐야 하나 라고 생각하시는 분들도 있을거에요. 하지만 MSP에 있어서 면접은 그 어떤 절차보다도 중요하고 신중하게 진행 된답니다.
여러분의 열정은 우선 1차 전형 때 3기 MSP 선배들이 여러분의 지원서와 블로그의 글을 통해 확인했습니다. 이 전통은 3기 선발 때부터 계속되어왔는데요. OB들의 까다로운 눈(?)에 열정이 정말 가득하더라도, 면접에 참여 하지 못하는 경우가 있어서 정말 아쉬웠습니다.
그렇다면, 면접이 가짜 열정과 진짜 열정을 구분하기 위해 진행되는 것일까요? 아닙니다.
MSP는 각기 다른 45인의 열정이 뭉쳐 로보틱스, UX, 매쉬업, 모바일등 다양한 꿈을 향해 나아가는 장이에요.
즉, MSP에 있어서 면접은 연령, 안면(다시 한번 말하지만 그랬으면 내가 어떻게 뽑혔겠어..), 출신성분(?)등을 불문하고, 여러분을 누구와 짝 지워줘야 그 열정이 시너지 효과를 낼 수 있을까. 한번 더 고민하기 위해 직접 모셔서 좀 더 다양한 이야기를 듣기 위해 진행됩니다.
토익, 스팩, 1차~5차전형까지 합쳐서 넘버링 해서 뽑는 공채 면접과는 확실히 다르다는 것을 알려 드리고 싶어요. 즉 면접은 여러분들을 줄 세우고 “아 이자는 우월해 우리한테 쓸모있겠어 크크”라고 부르는 게 아니라, 여러분들에게 최적의 짝을 지워주기 위해 진행되는 것이랍니다.
당신은 왜 합격/불합격 한 것 같나요?
어익후, 가슴 아픈 소리를 바로 하시는군요. 음, 실은 저도 잘 몰라요. 제가 왜 2기때는 떨어졌고, 3기때 붙었는지. 면접에 최첨단 복불복(?)시스템이 도입되어있는건지, 아니면 저의 안면(3기때 눈밑에 점을찍고 가서 몰라봐서 그런건지)을 보고 뽑은건지.. 아 아니다. 이런 재미없는 이야기 보다 제 주변에 붙은 자들의 이야기를 하는게 더 재밌겠네요.
면접관들은 여러분들을 해치지 않아요.
이 점을 가장 강조해서 얘기하고 싶습니다. MSP 1,2,3,4기 면접 진행절차 중 가장 많이 하는 질문이, “면접 때 뭐 입고 가야 하나요.” 이거든요. 사실 이 질문엔 답이 없어요. 앞서 설명했지만, MSP는 여러분의 안면(?)을 전혀 고려하지 않거든요. 아! 면접하라고 할 때 증명사진 내라고 한 건, 여러분이 아닌 분의 대리면접을 방지하기 위함이랍니다. 능력 있는 분들은 여러분과 똑같은 로봇을 만들어서 대신 면접을 보러 하더라도 아무도 모를 거에요.
MSP 면접을 할 때 들어오시는 면접관들은 대부분 30~40대 중후반의 남성과 여성분으로 한국 MS에서 재직중이시고, 사랑받는 한 가정의 가장, 혹은 딸과 아들입니다. 냉혈인간, 로봇(?)은 아니라는 거죠.
두번의 면접 현장을 경험해 본 바로는, 면접 현장에서 지나치게 긴장하시는 분들이 있는데, 전혀 그러실 필요 없습니다. 자신의 솔직한 이야기를 여러 사람들과 함께 수다떤다는 기분으로 임하세요! 지나치게 긴장을 하다 보면, 좀 더 본인을 숨기게 되고, 그러면 본인의 진면모를 면접관들이 알아채기 힘들답니다.
다른사람의 이야기에도 귀를 귀울여 주세요.
제가 MSP 면접을 처음 경험했을 땐 1:1 방식으로 진행됬는데, 3기 이후부터는 N:N 방식으로 진행된답니다. 즉 다수의 면접관들과 예비 MSP가 함께 참여해서 진행하는데, 그렇기 때문에 면접관들이 한 사람의 말에 좀 더 집중해서 청해야 하지요.
작년 3기 면접 때 참 아쉬운 사례가 있는데, 이 분께서는 면접에서 다른 사람의 질문에 참여도 하고, 심지어 다른 예비 MSP에게 질문까지 던지셨다고 하네요. MSP 면접은 앞서 강조했지만, 여러분의 다양한 이야기를 듣기 위해 진행되는것이기 때문에, 100초 스피치 이외에는 거의 Q&A 형식으로 진행된답니다. 그래서, 면접관들은 더욱더 여러분의 대답에 귀를 귀울일 수 밖에 없답니다.
여러분의 다양한 생각도 좋지만, 좀 더 귀를 귀울이는 자세를 갖추고 다양한 사람의 이야기를 듣는 것도 많은 도움이 될 거라고 생각합니다. 이외에 궁금한 사항은, 면접이 끝나고 개별적으로 질문해도 되잖아요? 뭐 그럼 좋은 인연으로 이어질수도 있고…
블로그의 글을 다시 한번 읽어봅니다.
앞서 이야기한것 처럼(아 이 말 너무 자주쓴다 식상해), MSP 면접은 100초 스피치와, Q&A로 진행되는데, 면접관들이 여러분들과 많은 이야기를 나누기 위해 참고하는 것은 증명사진, 이름, 지원서, 블로그 아티클 정도 밖에 없겠네요. 증명사진 보고 “헉 님 왜 실물과 다르심? 포샵하셨심?”이라고 물어 볼리는 없을거고, “헉 님 이름이 왜그럼? 개명하삼 ㅇㅇ” 이럴리도 없을거에요. 그럼 면접관들이 가장 먼저 참고할 것은 지원서와 블로그 아티클 정도 밖에 없겠죠?
면접에서 나오는 대부분의 질문도 여러분의 지원서와 블로그 아티클에서 나오게 된답니다. 그런데 아쉽게도 자신이 MSP 지원할 때 어떤 글을 썼는지 조차 기억하지 못하시는 분들도 있습니다. 면접에 임하기 전 꼼꼼히 참고해 보세요.
내가 누구인지 확실하게 알려주세요.
제가 위에서 부터 계속 강조한 이야기를 정리하면 MSP 면접은 “30~40대 한 가정의 사랑스러운 가정 혹은 딸, 아들인 MS 직원이(이건 해당안될수도 있음 이해바람 ㅇㅇ) MSP라는 장을 만드는데, 최적의 짝(?)을 만들어 주기 위해 진행되는 거임 ㅇㅇ”이라고 볼 수 있겠네요. 음 클럽 문지기랑 역할이 비슷해 보이는데.. (쩝)
클럽의 문지기가 하는 역할이 뭘까요? 클럽의 물을 최적으로 만드는 건데요. MSP 면접관의 역할도 MSP를 최적으로 만드는 일인데요.
그러기 위해 여러분들의 진면모를 파악하기 위해 면접관들이 많은 노력을 할거에요! 이러한 노력에 여러분도 좀 더 부흥하셔서(?), 100초 스피치에서 여러분이 누구인지 확실하게 알려주세요
저는 작년 이맘때(는 술을 마시고 놀고다녔군요.. 기말고사쯤 한창 지원서 썼던것 같은데..)를 회상하며 나만의 Love or Hate 열심히 탐독하고 있습니다.
다름이 아니오라!
MSP 4기를 지원하시는 지원자 여러분들의 궁금증+질문사항+그외 MSP3기라는 인물이 도대체 어떻게 생겼는지 궁금하시다! 하시는 분들을 위해
브레이크 세션을 진행할려고 합니다 : )
<MSP 3기때 나는 이렇게 놀았습니다. 그리고 왜 지원했을까요?>
시간 : 4월 29일 오후 3시 ~ 4시 발표자 : MSP 3기 이희덕(그외 추가 영입중) 장소 : 숭실대학교 베어드홀 1층 대강의실 103호 찾아오시는 방법 : 숭실대 입구역 3번 출구에서 나오시면 바로 숭실대가 나옵니다. 거기서 비와 바람이 몰아치는 계단을 넘어 올라오시면 그럴싸한 건물 옆에 다 쓰러져 가는 건물인 베어드홀이 있습니다. 그 건물 1층 103호로 찾아오시면 됩니다.
브레이크 세션은 숭실대학교 베어드홀 1층에 있는 대 강의실에서 진행되구요 좌석은 150석으로 넉넉하오니 (실제론 10석을 채우기도 매우 힘들어보입니다만..) MSP에 관심있는 누구든지 찾아오셔도 좋습니다.!
이날에는 MSP 1,2,3기의 활동을 알집의 압축실력보다 놀랍게(로지님 협찬 감사) 그리고 MSP 4기의 지원방법 및 절차에 대해 알려드리고!
그외 잡다한 궁금사항 (곰은 어떻게 굴러요. 재주넘어보세요. 아이폰개발하는법 가르쳐주세요) 을 터놓고 공유할 수 있는 시간을 마련해볼려고 합니다.
그.. 그럼 많이 참여해주시구요 혹시 오시다가 길을 모르겠다! 나는 귀한 분이라 베어드홀까지 모셔다 주셨으면 좋겠다 라고 생각하시면 010-2370-1413으로 당일 연락주시길 바랍니다.
요즘 사용자 경험(UX)을 고려한 설계의 중요성이 웹을 비롯한 여러 산업 분야에서까지 화두로 떠오르고 있는 것 같습니다.
국내에서도 사용자 경험을 공유하는 스터디 모임이 몇몇 운영 중이고, 몇몇 대학에서는 UX 과정이 개설된 곳도 있다고 합니다. 얼마 전엔, UX를 교류하는 컨퍼런스인 UXEye도 진행되었습니다.
그만큼, 사용자의 경험을 고려한 설계의 중요성이 강조되고 있는데, 국내외적으로 UX와 관련된 여러 서적들이 있으니, 개발자, 디자이너임을 떠나서 한번쯤 참고해 보시는 것도 좋을 것 같습니다.
UX 디자인은 사용자가 경험 할 수 있는 모든 감각과 상호작용을 기반으로 설계되는데, 웹과 같이 단 방향 미디어 매체에서는 주로 시각, 청각과 같은 감각과, 클릭, 터치와 같은 사용자의 인터랙션이 중요시 되고 있습니다.
사용자의 시각을 고려한 디자인 방법론에는 여러 가지가 있는데, 그 중 보색 대비는 사용자에게 강한 주목을 얻기 위해서 흔히 사용됩니다. 예를 들어, 도로표지판에서도 노랑과 검정을 함께 나타내어 주목의 효과를 강조하기도 합니다.
보색대비는 사용자에게 주목과 강조를 주기 위한 가장 본능적인 경험이고, 이를 적절히 활용하여 사용자에게 주의를 준다면 상당히 효과적인 UX 디자인 방법이 될 수 있습니다.
하지만, 본능적인 경험이 또 다른 본능적인 경험과 충돌하여, 최상의 경험은 커녕 사용자에게 심각한 위험을 준 사례가 있습니다.
90년대, 당시 일본에서는 닌텐도 게임을 기반으로 한 애니메이션인 포켓몬스터가 큰 인기를 얻고 있었습니다. 당시 포켓몬스터의 시청률이 1위를 여러 차례 달성하였고, 닌텐도 게임이 정식으로 발매되지 않은 한국에서 방영하여 지금까지도 계속 사랑을 받고 있는 애니메이션 이기도 합니다.
하지만 97년 12월 13일 방영된 포켓몬스터에서 단 3초의 실수로 그 인기가 분노로 바뀌어 버리는 사건이 발생하고 맙니다. 당시, 방영 분에서는 컴퓨터 세계의 대전을 다루었는데, 적이 소멸되는 순간 빨간색과 파란색의 보색이 상당히 여러 번 번갈아 표현되었습니다.
이 방영분이 방송된 직후, 전국의 700여명의 아이들에게 광 과민성 발작이라는 질병이 동시에 발생하였고, 구토를 일으키며 의식을 잃는 간질증상도 발견되어 수십 명이 병원 신세를 지어야 했습니다.
광 과민성 발작은 과도한 시각적인 변화로 인한 자극을 보호하기 위한 신경적인 본능인데, 의식을 잃고 구토를 하는것과 같은 동작으로 강렬한 시각적인 자극을 피하려고 합니다. 이전엔 게임을 하던 사용자에게서 간혹 발생하여 닌텐도 발작으로 알려지기도 했습니다.
하지만, 포켓몬스터 발작 사태처럼 수백 명이 동시에 발병하는 사태는 전 세계적으로 처음 있는 일이었고, 구토로 인해 기도가 막혀 사망할 수 있는 가능성까지 제시되면서 당시 일본 열도를 충격으로 몰고 가기도 했습니다.
이 사건이 발생한 직후, 언론에서는 대서특필 하였고, 당시 최고의 인기 애니메이션이었던 포켓몬스터는 4개월간 방송이 중지되는 강 징계를 받았고, 당시 상영 분 또한 완전히 폐기 되었습니다.
이후, 일본 애니메이션은 만화 시작 전 ‘방안을 밝게 하고, 멀리 떨어져서 시청하십시오.’와 같은 경고문을 반드시 방영하여야 했고, 보색대비가 포함된 강렬한 색체자극은 사용 할 수 없도록 규제화 되었습니다.
아울러, 전반적인 웹의 표준을 관리하는 컨소시움인 W3C에서도, 1999년 웹접근성가이드(WCAG) 1.0 에서 보색대비가 들어간 강렬한 색채전환 효과는 사용하지 말 것을 명시하였습니다.
하지만, 이런 사건의 경각성에도 불구하고, 잘못된 색체효과 사용으로 인한 사고는 아직까지도 흔한 편이라고 합니다. 얼마 전 2012년 런던올림픽 프로모션 사이트에서도 앰블램을 나타내는 부분에서 사용한 색채전환 효과가 광 과민성 발작이 발생할 것을 우려해 영상의 일부가 삭제되는 일도 있었다고 하네요.
사실 이 글에서 다룬 사례는 두 가지의 본능적인 사용자 경험이 충돌한 것으로, 그 결과가 사용자에게 혼란을 주어 중대한 위해를 준 사례이기도 합니다.
이처럼, UX 디자인 설계를 할 때에도 하나의 최상의 사용자 경험을 고려하여 설계하는 것 보다, 여러 가지 상층되는 사용자 경험들도 함께 고려하여 설계하는 것이 중요할 것으로 생각합니다.
이 글에서는 MIX09에서 나왔던 수 많은 이슈들 중에, 실버라이트3에서 새롭게 선보일 기능인 Out of Browser(이하 OOB)에 대해서 Adobe AIR 개발자 시각으로 어떤 점이 다른지에 대해 다루어 보고자 합니다.
OOB와 AIR의 차이점에 대해 말씀드리기 전에 우선, 실버라이트3의 새로운 기능들에 대해 간략히 정리해보겠습니다.
Media의 변화 실버라이트3에서는 H.264, AAC, MP4 코덱이 지원됩니다. 또, 제한적으로 GPU가속이 지원됩니다.
Perspective 3D 드디어 실버라이트3에도 3D가 공식적으로 지원된다고 하네요. 다만, 이번 플래시 10 처럼, 3D공간에 2D의 물체를 올려놓고, x,y,z축 정도만 바꿀수 있는 정도라고 하네요.
픽셀 셰이더 지원 런타임 단계에서, 픽셀 셰이더를 이용해 컨트롤에도 효과를 줄 수 있습니다. 어찌 보면, 플래시의 픽셀벤더와 상당히 흡사하다고 볼 수 있는데요. 픽셀셰이더는 HLSL이라는 bytecode를 사용하고 있습니다. 실버라이트3에는 기본적으로 제공되는 효과는 블러와 드롭쉐도우 정도만 있다고 하네요.
픽셀API / 그래픽 가속도 지원 동적으로 비트맵을 생성하고, 편집과 효과를 줄 수 있는 픽셀 API가 추가되었습니다. 그리고, 컨트롤러에 에니메이션 가속도 효과를 지정해 줄 수 있는 함수들도 추가되었습니다.
오디오/비디오 API 추가 동적으로 오디오를 생성하고(FP10의 SamplesCallbackData와 흡사), 동적으로 오디오/비디오 코덱을 작성할 수 있는 API가 추가되었습니다.
로컬커넥션 지원 실버라이트 플러그인 간 데이터 통신이 가능해 졌습니다. 그간 플래시에서 데이터를 공유하는 방식처럼, 로컬의 메모리를 통해 문자열 데이터들을 공유할 수 있습니다. 다른 브라우저나, 탭에서도 공유가 가능하다고 하는데, 보안 샌드박스 적용이 어떻게 되어있을지 궁금하네요.. ^^;;
Out of Browser 영어 뜻 그대로 브라우저를 떠나서, 웹을 떠나 데스크탑에서 실버라이트 애플리케이션을 구동하는 기능입니다. OOB를 위해 온/오프라인 API, 업데이트 API등을 지원합니다.
MIX09 키노트 직후 실버라이트3 베타의 SDK와 런타임 모두 공개되었습니다. 아래의 경로에서 내려 받아 바로 개발해 보실 수 있습니다. 다만, 실버라이트3 SDK는 영어와 일본어만 지원하기 때문에, 한국어 Visual Studio에서 개발하시는 분은, 영어판으로 새로 내려 받아 설치하셔야 합니다.
위에서 살펴본 실버라이트3의 새로운 기능들 이외에도, 새로운 UI Framework 및 컨트롤, 로컬파일저장 지원(보안샌드박스 유의), 텍스트엔진 향상, 검색엔진 최적화 지원 등의 많은 기능들이 추가되었습니다. 실버라이트3는 어찌보면, 작년 10월경에 출시된 Flash Player10 의 새로운 기능들의 집약판이라고 볼 수 있겠네요. ^^;; 정말 비슷비슷하죠?
저는 실버라이트3의 새로운 기능들 중 하나인 OOB에 대해 제일 처음엔 궁금한 점이 많았습니다. OOB는 웹상의 애플리케이션을 데스크탑 애플리케이션으로 확장하는 기능인데요. 사실, OOB와 비슷한 역할을 하는 데스크탑 플랫폼인 WPF가 오래전 부터 나와 있었고, 사실상 실버라이트는 WPF에 종속된 개념이기 때문이죠.
WPF는 Windows Presentation Foundation의 준말입니다. 약어일 땐 잘 몰랐는데, 풀어 쓰니 대충 무슨 뜻인지 아시겠죠? ㅎㅎ 저는 남자라 파운데이션을 써본 적이 없지만, 파운데이션은 모든 화장에서 기초가 된다고 하네요. WPF는, 당시 Winapi 별로 달랐던 여러 API들을 닷넷 프레임워크로 통일하는 것을 목표로 하고 있었습니다. 즉, WPF로 개발된 애플리케이션은 닷넷 프레임 워크가 설치가 가능한 모든 윈도우 플랫폼에서는 동일한 환경으로 실행되게 됩니다.
WPF 애플리케이션은 XAML이라는 마크업 언어로 사용자 인터페이스를 구상 할 수 있으며, 개발언어는 C#이나 VB.NET, J#로 개발 할 수 있습니다. 다만, WPF의 핵심 엔진인 닷넷 프레임워크가 윈도우 플랫폼 이외에는 지원하지 않기 때문에, AIR 애플리케이션과는 달리 윈도우 이외의 운영체제에서는 WPF 애플리케이션을 구동 할 수 없습니다.
그럼 다시 실버라이트 얘기로 돌아가 볼까요? 실버라이트는 정식 출시이전 코드네임이 WPF/e(Everywhere) 였습니다. WPF에 어디서나 라는 조건이 덧 붙었는데요. 실버라이트는, WPF 애플리케이션을 개발할 때처럼, XAML 마크업 언어로 애플리케이션의 사용자 인터페이스를 구상하고, 닷넷 프레임워크가 지원되는 언어로 개발 할 수 있습니다. 다만, WPF에서 제공하는 몇몇 기능들은 보안 샌드박스로 제한을 둔 대신, 윈도우 플랫폼 이외에도 다른 운영체제도 지원한다는 점이 있습니다.
즉, 실버라이트의 모체는 뺄 건 빼고, 줄인 건 줄여서 모든 플랫폼(Everywhere)에서 구동되는걸 목표로 하는 WPF와 같습니다. 최근엔, 윈도우 모바일 6.0 환경에서 구동되는 실버라이트 2.0도 출시되었다고 하네요.
OOB와 AIR
Adobe AIR는 크로스 플랫폼을 지향하는 런타임으로 현재 윈도우와 맥을 공식적으로 지원하고 있으며 리눅스는 비공식적으로 지원하고 있습니다. Adobe AIR는 플래시플랫폼에 묶여있고, 플래시나 플렉스, AJAX로 애플리케이션을 개발할 수 있지만 플래시플레이어에서 구동 되는 것은 아닙니다. 반드시 별도의 런타임이 필요합니다.
반면, 실버라이트3 OOB는 실버라이트 플레이어에가 설치되어 있는 사용자라면 별도의 런타임 설치 없이 이용할 수 있습니다. 또, 데스크탑에 설치하여 계속해서 사용할 수 있지만 WPF와는 달리 크로스플랫폼을 지원하고 있습니다.
즉, 추가 런타임 필요여부가 실버라이트3 OOB와 Adobe AIR의 가장 큰 차이점 이라고 볼 수 있습니다. 어도비AIR의 경우, 플래시플랫폼에 속해있고, 언어나 개발툴도 그대로 활용할 수 있지만, 브랜딩네임은 플래시와 다른점에서 알수 있습니다. 이처럼 실버라이트3 OOB와 Adobe AIR를 단일선상에 놓고 비교하는 것은 다소 무리가 있습니다.
개발과 배포
실버라이트3 OOB와 AIR는 애플리케이션을 개발하고 배포하는 과정부터 차이점이 많습니다. Adobe AIR는 플렉스빌더(플래시 빌더), 플래시 IDE, 드림위버 등에서 개발 할 수 있으며, 별도의 개발툴 없이 AIR SDK를 내려받아 개발을 진행할 수 있습니다. AIR SDK는 AJAX개발자용, 플렉스 개발자용으로 나뉘며, 개발 후 ADL을 통해 애플리케이션을 실행해 볼 수 있고, ADT를 통해 애플리케이션을 디버깅 할 수 있습니다.
반면, 실버라이트3는 OOB 구현을 위해 별도의 SDK를 내려 받을 필요는 없으며, 실버라이트3 SDK만 있으면 개발을 진행할 수 있습니다. 마찬가지로, 디버깅이나 애플리케이션을 실행하기 위해서도 별도의 런타임을 내려 받을 필요는 없으며, 실버라이트3 개발에 사용된 디버깅 플레이어를 그대로 사용할 수 있습니다.
다만, 실버라이트 애플리케이션을 OOB를 포함해 배포하기 위해서는 반드시 애플리케이션의 메니페스트 파일을 수정해주어야 합니다. 애플리케이션 메니페스트 파일은 실버라이트 프로젝트의 Properties폴더에 있으며, 파일명은 AppManifest.xml입니다.
애플리케이션 메니페스트 파일을 열면, 주석으로 지정된 부분이 있는데, 이 부분이 실버라이트 애플리케이션을 OOB로 함께 배포하겠다는 것을 설정해 주는 부분입니다. 이 부분의 주석을 제거하고 프로젝트를 Export하면, 실 버라이트 애플리케이션을 데스크탑에 설치할 수 있는 OOB 기능이 함께 첨가되어 배포됩니다.
반면, Adobe AIR는 애플리케이션을 배포하기 위해 단일 설치파일인 AIR 파일을 생성하는 패키징이라는 과정을 거쳐야하는데, 이 과정에서 반드시 공인된 CA기관으로 부터 발급받거나, 스스로 만든 인증서 파일로 서명 절차를 거쳐야 합니다. 서명 절차를 거치면, 디스크립터파일과 함께 프로젝트에 사용된 에셋파일등도 함께 묶인 단일 설치파일인 AIR파일이 만들어지게 됩니다.
그리고, AIR와 실버라이트3 OOB 모두 배포 과정중에서 데스크탑에 설치될 애플리케이션의 부가 기능을 설정 할 수 있는데, AIR는 애플리케이션의 아이콘이나 연결될 파일, 윈도우설정등은 디스크립터 파일에서 설정 할 수 있고, 실버라이트3 OOB는 창의 타이틀이나 애플리케이션의 아이콘은 애플리케이션 메니페스트 파일에서 설정 할 수 있습니다.
설치와 삭제
앞서 배포과정에서 살펴본 것 처럼, AIR 애플리케이션은 단일 설치파일 형태인 AIR로 배포가 되며, 실버라이트 OOB는 기존 실버라이트 파일과 같은 XBP 파일로 배포되거나, 서버사이드에 컴파일러를 설치해 XAML파일로 배포할 수 있습니다.
즉, 실버라이트3에서 OOB를 포함해 배포한 애플리케이션은 별도의 런타임이 필요없고, 웹 상에서도 실행이 가능합니다. 반면 Adobe AIR는 반드시 AIR 런타임이 설치되어 있어야 합니다.
실버라이트 애플리케이션을 OOB를 포함해 배포한 경우, 실버라이트 스테이지 범위 내에서 오른쪽 마우스를 누르면 실버라이트 구성 아래에 Install 이 활성화 된 것을 확인할 수 있습니다. Install 버튼을 누르면, 애플리케이션의 단축아이콘이 추가될 곳을 묻는 창이 나오게 됩니다. 여기서 OK를 누르면 설치과정을 모두 마치게 됩니다.
반면, AIR 애플리케이션은 단일 설치파일인 air 파일을 직접 내려 받아 설치하거나, 플래시로 만들어진 AIR 배지를 통해서 설치를 할 수 있습니다. AIR 배지는 SDK 내에 포함되어 있으며, 직접 커스트마이징을 할 수 있고, 브라우저 API를 이용해 새롭게 개발 할 수 있습니다. AIR 배지를 이용해 설치할 경우, 클라이언트에 AIR 런타임이 없더라도, AIR 런타임과 함께 애플리케이션을 설치 할 수 있습니다. 그리고, 실버라이트3 OOB와는 달리, 몇번의 설치 과정을 거쳐야 하며, 이 과정중에서 AIR 애플리케이션에 서명된 인증서 종류에 따라 사용자에게 경고메세지를 알려주기도 합니다.
그리고, 실버라이트3 OOB도 AIR 배지처럼 API를 호출하여 오른쪽 마우스 설치방식이 아닌, 버튼을 클릭하여 애플리케이션의 설치를 진행하게끔 할 수 있습니다. 다만 이 경우엔 보안샌드박스에 의해 반드시 사용자의 직접적인 인터렉션에 의해 클릭되었을 경우에 설치 할 수 있습니다.
AIR 애플리케이션과 실버라이트3 OOB 애플리케이션은 설치 과정에선 큰 차이가 있지만, 설치 이후엔 사용자 입장에서 크게 다를 점은 없습니다. 두 애플리케이션 모두 다 크로스플랫폼을 지원하며, 아이콘을 클릭하여 애플리케이션을 실행 할 수 있습니다.
다만, 설치된 애플리케이션을 제거해야 할 경우 실버라이트3 OOB는 앞서 살펴본 것 처럼, 오른쪽 마우스를 눌러 애플리케이션을 제거하거나 API를 호출하여 애플리케이션을 제거하게끔 할 수 있습니다. 반면 Adobe AIR는 별도의 API를 호출하여 애플리케이션을 제거하게끔 할 순 없고, 윈도우 플랫폼의 경우 프로그램 추가/제거에서 제거를 하고, Mac OS는 애플리케이션을 휴지통에 넣어 제거하는 방법으로 제거할 수 있습니다. 그리고, AIR와 실버라이트3 OOB 모두 애플리케이션을 설치하거나, 삭제하는 과정의 인터페이스를 커스트마이징 할 순 없습니다.
덧붙여, 실버라이트 OOB 애플리케이션의 업데이트는 웹상에 올려진 XBP파일에 변화사항이 있으면, 자동으로 진행이 되며, Adobe AIR는 URLStream으로 내려받아 Updater 클래스를 이용해 업데이트를 진행하거나, 이미 구현된 업데이터 프레임워크인 AIR Update Framework(AIR 1.1 SDK부터는 포함되기시작)을 이용해 애플리케이션의 업데이트를 진행 할 수 있습니다.
가장 다른 것 하나
이처럼 실버라이트3 OOB와 AIR는 개발에서 배포, 설치에서 삭제까지 다른 점이 많습니다. 하지만, 가장 다른 점은 구현할 수 있는 기능의 한계에 있습니다.
앞서 눈치(?)채셨겠지만, 실버라이트3 OOB는 사실 웹에서 실행되는 실버라이트 애플리케이션과 구동원리가 같습니다. 즉, 쇼핑몰 바로가기 처럼 단축아이콘을 만들어두고, 별도의 런쳐를 두어 창을 띄우고 그 안에서 실행되는 형태입니다. 즉, 실버라이트3 OOB는 실버라이트3의 브라우저 센드박스 모델을 그대로 적용받고, 그 범위 내에서 벗어나는 기능을 구현 할 수 없습니다.
보안샌드박스라고 하니 조금 복잡해보이나요? 간단하게 정리해보면, OOB는 창을 벗어난 곳 이외에 어떠한 영역도 제어할 수 없습니다. 로컬의 파일의 목록을 불러오거나, 생성할때에도 브라우저 샌드박스 모델에 따라 반드시 사용자의 직접적인 인터렉션이 필요하며, 윈도우를 커스트마이징 하거나, 여러 개의 윈도우를 띄우거나, 클라이언트에 별도의 데이터베이스를 구축할 수 없습니다.
반면, Adobe AIR는 Flash Player와 독자적인 보안 샌드박스를 적용받게 되는데, 따라서 HTTP통신이나 소켓통신을 할 때에도 Phase 파일의 제한에서 벗어날 수 있고, 사용자의 인터렉션 없이 로컬에 파일을 쓰고 지울 수도 있습니다. 아울러, Webkit 엔진을 통해 브라우저 기능을 구현할 수 있고, Sqlite엔진이 탑재되어 로컬에 데이터베이스를 만들어 기록할 수 있습니다.
다만, 실버라이트3는 OOB를 위해 별도의 API를 제공하고 있는데, 앞서 설명한 설치와 제거를 위한 API를 비롯해, 현재 실버라이트 애플리케이션이 실행되고 있는 모델을 알수있는 API와, 온/오프라인 상태를 구분할 수 있는 API도 함께 제공하고 있습니다.
즉, OOB 기능이 포함된 애플리케이션은, API를 이용 실행 모델을 파악해서, 웹에서 실버라이트 애플리케이션을 실행 할때에는 AIR 배지처럼 설치화면만 나타나게 할 수 있고, 데스크탑에 설치될 경우 애플리케이션 기능을 제공하게끔 하는 데스크탑 전용 애플리케이션도 개발 할 수 있습니다. 또 네트워크 상태를 감지하여(AIR의 URLMonitor, SocketMonitor과 흡사) 온/오프라인 애플리케이션을 개발 할 수도 있습니다.
OOB가 스마트폰로 간다면?
OOB는 AIR와 달리 Native API를 지원하지 않고, 실버라이트3에서 구현할 수 있는 API만 사용할 수 있습니다. 그렇다고 해서 실버라이트3 OOB가 AIR에 밀린다고 생각하는 것은 아닙니다. 실버라이트3 OOB가 Native한 제어를 포기한 것은, 크로스플랫폼 지원을 향한 강한 의지를 보여준 것이라고 생각됩니다.
실제로 AIR 런타임의 경우 작년에 FP10이 출시되었을 때, FP10의 출시가 1달여가 지나 FP10의 API와 여러 feature가 포함된 AIR1.5가 릴리즈 된 만큼, 크로스플랫폼을 지향하는 플랫폼의 경우 Native 영역까지 제어하기 위해서는 많은 노력과 개발이 필요합니다. 특히, 플래시 플레이어와 AIR 런타임은 실행 구조(Virtual Machine)부터 다른 만큼 앞으로 플래시 플레이어에서 새롭게 나온 API가 런타임에 반영되어 릴리즈가 되는 시점이 어긋나는 현상은 계속될 것으로 보입니다.
저는 개인적으로, 실버라이트 OOB가 데스크탑에서 주력이 될 플랫폼 보다는 모바일에서 주력이 될 플랫폼으로 생각하고 있는데요. 실버라이트는 웹 플레이어 뿐만 아니라, 모바일용 플레이어도 WM6과 Symbian Platform 한해 2010년 출시를 목표로 하고 있습니다.
모바일 디바이스는 데스크탑 플랫폼에 비해 구현할 수 있는 기능이 종속적이고, 또 샌드박스에 의해 로컬의 제어는 대부분 엄격히 금지되어 있습니다. 또, 일반적으로 휴대전화용 애플리케이션에서는 시스템을 제어해야 할 일 이 많이 필요하진 않습니다. 간단한 휴대폰 게임에서도 세이브를 남기는 일 외에는 로컬을 제어할 부분이 없겠죠?
즉, MS에서는 실버라이트 OOB의 Native 제어를 포기하는 대신, 크로스플랫폼 지원정책을 강화하여 여러 모바일 디바이스에 쉽게 탑재함으로써, 모바일 시장에서 Flash Lite나 WIPI가 잡고 있는 점유율을 추격해 볼 수도 있을 것 같습니다. 또, 개발자는 별도의 임베디드 기술을 배울 필요 없이 실버라이트로 모바일 애플리케이션을 저작하고, Windows Mobile 환경 뿐 아니라 아이폰, 안드로이드 등 여러 플랫폼에 모바일용 애플리케이션을 개발하고 배포할수 있는 것만으로도 큰 메리트로 작용할 수 있을것 같습니다.
윈도우 모바일로 인터넷 탐색을 하면서, 실버라이트 게임을 하는 경우에 대해서 생각해 봅시다. 지금 하고 있는 게임이 마음에 들면, OOB 기능으로 내 휴대폰에 설치할 수 있습니다. 또, 온/온라인 애플리케이션으로 게임의 기록을 실시간으로 주고받고, 게임의 변경사항이 있을경우 자동으로 업데이트도 됩니다. 그리고, MS에서 다양한 모바일플랫폼을 지원한다면, 아이폰에서 실버라이트 게임을 설치하여 할수있을지도 모릅니다. 데스크탑에서 OOB 애플리케이션을 설치하는것보다 훨씬 즐거운일인것 같네요
OOB와 AIR의 경쟁무대를 모바일로 두고보면 상당히 재미있는 경쟁이 될 것 같습니다. 물론 이러한 경쟁에서도 선발주자는 아직 어도비입니다. 어도비는 오래전부터 모바일용 플래시 플레이어인 Flash Lite를 릴리즈해왔고, 올초에 이미, 모바일용 AIR의 일종인 Distributable Player 를 발표한적이 있습니다. 그리고 작년에 발표한, AIR 로드맵의 장기적인 목표는 데스크탑용 애플리케이션을 high feature 디바이스에서도 구동되는것을 목표로 하고 있습니다. 참고글 : AIR 2.0 베일을 벗나?
얼마전, 어도비 AIR는 2억대 클라이언트 설치돌파라는 기염을 토한적이 있었습니다. 물론, 실버라이트도 올림픽을 비롯한 미디어 마케팅에 힘입어 4억대 클라이언트 설치돌파를 하며, 플래시플레어의 독주에 바짝 다가서고 있습니다. 실버라이트3 OOB와 AIR, 과연 둘은 서로 윈윈하는관계가 될까요? 아니면, 모바일계의 혜성으로 서로 양날의 검이 될까요?
고1에 딱 한번뿐인 체험학습 전날, 지긋지긋한 울산 대공원으로 체험학습이 아닌 반별로 자유롭게 행선지를 정해 떠날수 있는 흔치 않은 기회였다. 반 아이들은 놀이공원에 가자고 성화였지만, 담임선생님은 체험학습은 의미가 있는곳으로 가야한다고 독단적으로 방송국 체험학습을 결정 했다.
방송국 외각을 둘러보고, 소규모 스튜디오를 구경하고있는중 방송국 관계자가 아나운서 카메라 테스트가 있는데 참석하지 않을것이냐고 제의를 했고, 담임선생님은 흔쾌히 승낙하셨다. 그렇게, 30명의 방청객, 한대의 카메라, 그리고 멀리서 지켜보고 있는 네명의 심사위원과 함께 더욱더 긴장되는 분위기에서 시험이 진행되었다.
응시자들은 정해진 대본을 따라 읽는 비교적 간단한 시험이었지만, 쉽지만은 않은 시험인것 같았다. 온갖 사회용어와 외래어들이 가득한 대본을 읽어내려가다가 이리저리 막히기도 하고, 발음이 꺽이기도 하고, 너무 급하게 읽다가 숨이 넘어가기도 하고.. 그런데 재미있는 공통점을 발견했다. "울산지역 방송국의 아나운서를 선발하는 시험인데 왜 사투리를 쓰는 사람이 없을까? 그러고보니 왜 뉴스에서는 사투리를 쓰지 않을까? 울산지역의 사람들만 시청하는것인데 사투리를 쓰면 지역주민들에게 더 정겹지 않을까?"
고1 국어책에는 표준어와 맞춤법에 대해 배워보는 '바른말 좋은글'이라는 단원이 있다. 항상 이 단원에서는 실수가 많아 국어선생님과 학생들에게 가장 긴장되는 단원이다. 아래는 교과서에 실려있는 표준어에 대한 정의이다.
표준어 : 교양있는 사람들이 두루 쓰는 현대 서울말
교양있는 사람들(?)이 두루 사용하는 현대의 서울말이라... 나의 국어선생님은 교양 있기가 꺼리셨는지, 아니면 표준어 사용이 부담스러웠는지, 맞춤법에 틀린 부분을 설명할때에도 교과서 지문과 다르게 '~했나? ~했노?'로 경상도 사투리로 직접 번역해 주시면서 설명해주셨다.
(그래서 그랬는지, 우리반 아이들의 기말고사 국어 시험지에는 갈매기가 여럿 날아다녔다.)
읍니다? 습니다? 거참 헷갈리네 - 이명박
그럼 왜 굳이 표준어 사용을 강요받는 것일까? 표준어를 사용하지 않는다고 해서 교양있지 않은 사람일까? 교과서에는 그 답을 이렇게 설명하고 있다.
1. 통일의 기능
2. 우월의 기능
3. 준거의 기능
통일의 기능은, 방언의 차이가 심하면 한나라 안에서도 제대로된 의사소통이 힘들듯이, 올바른 의사소통을 위해서 하나의 말로 통일해야 한다는 것이고, 우월의 기능은 표준어를 쓰는사람이 그렇지 않은 사람보다 우월하다는 것이다. 그리고 또 준거의 기능은, 국민으로써 하나의 규범을 따르고 지켜야 하는 약속인 것이다.
따라서, 통일,우월,준거 하기 위해 초등,중등,고등학교의 모든 과정에서는 표준어에 대해서 공부하는 과정이 나오며, 선생님들도 가급적이면 표준어를 사용해서 학생들을 가르쳐야 한다.
맞춤법 표준어는 어려워
위와 같이, 지역방송국의 아나운서를 선발하는 시험에서도, 방송 자체는 '공중에 상영'되는것을 목표로 하고, 아나운서는 정보를 읽음으로써 대중들에게 전달 함으로, 원할한 의사소통을 위해 지역방언(사투리)이 아닌 표준어를 사용해야 한다.
'표준어'는 우리가 만든 약속이고 지켜야 하지만, 그러기가 힘들다. 국민 모두가 '법'의 내용을 전부다 숙지하기가 힘들듯이, 표준어의 내용도 전부다 알고 있기가 힘들다. 하지만 최근엔, 토익, 토플등 외국어 붐으로 외국어의 문법을 틀려 쓰는건 부끄러워 하면서, 우리 모국어의 문법을 틀려쓰는건 아주 당연한것 처럼 인식되고 있다.
그래서 최근엔, KBS가 모든 공채 시험에서 어학시험(토익,토플) 반영을 폐지하고, 공채 시험자 전원은 반드시 한국어능력시험에 응시해야만 한다. 또한 응시 결과는 공채에 반영된다.
우리은행, 대한주택공사, 한국토지공사와 같은 대기업과 공공기관들도, 이런 KBS의 변화에 주목하기 시작했다. 가장 가까이 있는 우리말도 모르면서, 외국어 능력만 따지는 것은 자칫 원할한 업무수행이 되지 않을수도 있기 때문이다.
이런 '표준화'는 언어가 아닌 가장 먼저 의료계에서 근원되었다. 의료계에서는 혈청검사나 여러 의학적 검사를 통해 환자의 상태를 판단하고 처치를 한다. 하지만 제일 처음에는 검사 결과의 표준이 없기 때문에, 각 기관별로 검사결과가 다른 경우가 생겼다. 이런 경우, 긴급한 처치를 요하는 응급환자들에겐 생명이 위독할 수 있다. 따라서, 의료계에서는 모든 검사의 기준과 결과를 표준화 하고, 철저히 관리하고 있다.
어디 문제는 없을까?
웹표준?
이런 '표준화'의 바람이 최근엔 다시 웹에서 거세게 일고 있다.
최근 싸이월드 2에서 명칭을 변경한 싸이월드 블로그도 기획과정중 철저히 웹 표준을 지킬것을 원칙으로 해 이슈가 되었다. 또한, 음원 보호로 인해 현재 윈도우 이외의 환경에서 재생이 불가능한 음악플레이어도 가까운 시일내로 모든 환경에서 사용 가능하게 할것을 약속했다.
이런 웹 표준화의 바람은 나아가, 현재 거의 모든 포털사이트는 웹표준을 기준으로 작업을 진행하고 있다. 또, 최근엔 행정안전부에서는 대한민국 전자정부가 모든 국민의 접근성을 높이기 위해서, 모든 문서를 표준화 할것을 공시했다. 인터넷 쇼핑몰인 11번가에서도 업계중 유일하게 웹표준을 지향하며, 11번가의 메인페이지는 w3c validator 테스트를 통과했다.
업계에서 그동안 도외시 되어왔던 웹표준이 최근에 갑작스럽게 부상하고 있는 이유는 무엇일까? 그리고 정부까지 나서서, 뒤 늦게 웹 표준을 준수하려는 이유는 무엇일까?
이다. 표준어와 흡사하게도 교양있는 사람들이 두루 쓰는 서울말에서, 교양있는 사람들이 W3C(World-wide-web)로, 그리고 서울말이 HTML,CSS,XHTML,DOM 등으로 바뀌었을 뿐이다.
W3C는 큰 규모의 국제적인 컨소시움 단체인데, 1994년 미국의 MIT대학과, 여러 기구와 대학들이 뭉쳐 설립한 표준기술 개발 단체이다. 서로의 기술이 표준으로 인정받기 위해, 가장 치열한 싸움이 일어나고 있는 현장이기도 하다.
웹 브라우저는 W3C에서 권고하는 표준안에 맞게 개발되며, 대부분의 메이저급 브라우저에서는 W3C 권고안에 맞게 페이지가 표시되고 있다. 즉, W3C의 권고안에 맞게만 개발한다면, 거의 모든 브라우저내에서 똑같은 화면을 보여줄 수 있다는 것이다.
일단 근본적으로 웹 표준을 지킴으로써 얻을 수 있는 장점은 위의 설명과 같이 통일,우월,준거의 장점을 모두 얻을 수 있다. 모든 브라우저에서 같은 화면을 보일 수 있으며(통일), 웹 표준을 지키는 사람이 그렇지 못한 사람 보다 당연히 우위이며(우월), 웹을 이용하는 사람으로써 W3C에서 권고하는 약속은 지켜야한다(준거)
그리고, 웹 표준을 지킴으로써 얻을 수 있는 장점을 모두 활용할 수 있다. 첫째, 상호호환성(cross-browsing)을 쉽게 유지할 수 있다. 거의 모든 브라우저는 W3C의 권고안대로 개발이 되었고, 권고안대로만 웹사이트가 개발된다면, 타 브라우저 내에서 똑같은 화면을 볼 수 있다. 그리고, PDA나 모바일 환경등 임베디드 환경에서도 접근이 용이하고, 시각장애인을 위한 음성안내 페이지를 만들기도 용이하다. 이를 일컬어, 확장성과 이식성의 장점이라고 부르기도 한다.
둘째, 생산자에게 큰 도움이 된다. 웹 표준을 도입하는데 있어, 사용자를 고려할 일은 없다. 사용자는 아파트에 18mm 철근이 들어가있건, 17mm 철근이 들어가있건 신경쓰지 않는다. 다만 외관에 철근이 튀어나오거나 부실공사일경우 사용자들에게 지적받게 된다.(표준을 어긴경우) 웹 표준으로 작성할때 얻는 이점은 코드가 직관적이며, 코드를 유지보수 하기가 쉽고, 체계적으로 개발을 진행할 수 있으며, 만들어 진 코드를 얼마든지 재 활용 할 수 있다.
(나모 웹에디터 2008에서는 표와 레이아웃 상자를 따로 분리해, 그동안 table는 레이아웃용도가 아니었구나! 라고 깨웃친거 같으나, 실상은 테이블이다. table에는 namo_layoutbox 라는 비표준 태그가 들어가있다.)
최근에는 이러한 웹표준화의 기세에 부응하여, 주어진 레이아웃을 웹 표준에 맞게 작성하는 웹표준경진대회도 성황리에 현재 진행중이다.
표준어를 모르는것에는 부끄러움과 학습이 필요하듯이, 웹표준을 모르는것에도 부끄러움과 학습이 필요하다.
웹표준은 권고이다. 그래서 도입 여부를 고민 해야 하는 분들이 있는데 아니다, 반드시 지켜야 하는 것이다. 똑같은 시간을 들여 컨텐츠를 생산하더라도, 좀더 효율적이고 생산적인 방법을 위해서 나아가야한다. 부화뇌동하여 눈치볼 필요도 없다 그냥 무조건 지켜야 하는 것이다.
Active X의 위기 그리고 웹표준
Active X는 MS에서 개발한 인터넷 익스플로러 플러그인으로 IE3.0 부터 도입되어 지금까지 사용되어 왔다. 이러한 Active X는 증권, 은행등 금융기관과, 결제 서비스, 게임 다운로드 등 광범위한 부분에서 사용되어 지고 있다.
Active X를 설치하지 않으면 인터넷 뱅킹이 이용이 불가능하다.
특히, Active X는 보안이 중요한 금융기관 에서 사용자의 금융정보를 이중 삼중으로 보호하기 위해 사용하고 있다.
금융기관에서는 인터넷이 우리나라에 급속도로 번졌지만 인터넷 환경과 장비가 열약한 초기에, 가볍고 배포가 쉬운 Active X를 도입했다. 그 후, Active X는 급물살을 타면서, 거의 모든 웹 포털 사이트에서 사용하게 되었다.
하지만, 황금알을 낳는 거위로 불리던 Actifve X는 그 신화를 얼마 이어가지 못하고, 최근에는 미운오리새끼로 낙인되어 가고 있다.
인터넷 익스플로러가 아니면 네오위즈의 세이클럽을 이용할 수 없다.
Active X는 IE에서만 사용이 가능하다. 따라서, 이외의 브라우저를 사용하는 유저들은 위의 그림처럼 해당 사이트의 서비스를 사용할 수 없다. 또, 접근조차 할 수 없는 곳이 많다.
Active X는 모질라 재단의 파이어폭스가 등장하고, 점유율이 이전 넷스케이프와 같이 나날이 높아짐에 따라, 처음으로 위기를 맞이했다. 하지만 유럽등 일부 지역과는 달리 우리나라는 여전히 인터넷 익스플로러의 입지가 상당히 높은 편이며, 그러한 점유율의 변화가 유동적이지 않은 편이다. 위의 도표는 필자가 운영중인 애드나루 회원 58명의 사이트 방문자가 사용하는 브라우저를 분석한 자료인데, 방문자의 97.4%가 인터넷 익스플로러를 사용하고 있었고, 파이어픅소는 1%에 그쳤다.
하지만, 엎친데 덮친격이라고 했을까? Active X는 두번째 중대 고비를 맞게 된다. 바로 다양한 모바일 디바이스의 등장과 함께 초고속 무선인터넷의 등장이다. 최근엔 와이브로나 WCDMA를 통해 집이 아닌 외부에서도 얼마든지 초고속 인터넷에 접속이 가능하며, 플브라우징폰에서는 실제 브라우저와 같이 인터넷 탐색이 가능하다. 하지만, 이런 디바이스들 중 Active X의 사용이 가능한건 극히 일부며, 거의 대다수의 환경에서는 Active X를 사용할 수가 없다.
Active X는 엄연히 웹 표준과는 정 반대의 입지에 서 있으며, IE를 제외한 브라우저에서는 사용 자체가 불가능 하기 때문에, 최근엔 이러한 Active X를 대처하기 위한 방법을 강구하고 있다. 동기적으로 서버와 연결을 주고 받아야 하는 사이트의 경우 XMLHttpRequest(Ajax)나 Flash Socket를 통해 대체하고 있고, 보안이 중요한 금융권에서는 보안등급 차등화나 OTP도입, Flex나 Java를 통해 구연함으로써 그 빈자리를 매꾸어 나가고 있다. (최근엔 농협에서 Flex를 도입하여 리눅스 환경에서도 사용이 가능하다.)
Active X는 웹의 부족한 부분을 메꾸어주는 플러그인에서, 이젠 지향되지 말아야 하는 구시대의 산유물로 변해가고 있다.
웹표준 VS Active X
필자는 이와 비슷한 대결상황을 지켜본적이 있다.
작년에 '공개소프트웨어 프로젝트 챌린지' 라는 대회에 참가한 적이 있었는데, 참가자들끼리 친목도모와 지식공유를 위해서 '챌린지 캠프'를 운영했고, 1박2일의 짧은 기간동안 운영 되었다.
그중 참가자들이 프로젝트를 프리젠테이션 하고 멘토에게 조언을 구하거나, 참가자들이 질문을 던지는 시간이 있었는데, 광운대 팀에서는 '파이어폭스 플러그인을 이용한 웹 프리젠테이션 프로젝트'를 발표했다.
웹에서 프리젠테이션 프로젝트를 만들고, 또 파이어폭스 플러그인을 통해 웹에서도 프리젠테이션이 가능한 구조였다. 그런데, 역시나 참가자들 중 한명이 제동이 걸었다.
'웹 표준이 아니지 않는가? IE에서는 작동하지 않는다.'
장내는 순간 술렁거렸다. 다른 참가자중 한분이 일어나서,
'FF에서만 작동된다는건 이미 서두에 말을 했다. 그런데 프로젝트에 문제가 뭔가?'
라고 대응 했다.
그 이후에 서로 점유율 통계얘기 까지 나오고, 싸움이 더 커질려는것 같더니, 사회자가 나서서 중재하였다.
필자도 그때 애매한 입장이었다. 필자가 진행중인 프로젝트가 Flex 기반이어서, 참가자분께서 지적하신것 처럼 '표준 환경'이 아니며, Flash player을 설치하지 않은 환경에서는 이용이 불가능하기 때문이다.
파이어폭스가 점유율이 1%건, 인터넷익스플로러 점유율이 97%건, Flash Player 사용율이 99%이건 간에, 모두 w3c에서 표준기술로 인정하지 않으며 해당 플러그인이 지원하지 않는 환경에서는 사용할 수 없다. 즉 '웹표준'이 아닌것이다.
정면승부다. 두 사람의 입장도 다르고 관점이 다르다. 두 사람중 어떤 한 사람의 생각에 지지하기 위해서는 나의 생각을 기준해서 승부를 내려야 한다.
위의 두 사람의 우위를 가리기 위해서는 점수 자료가 필요하다. 우위를 가리는 가장 정확한 방법은 같은 지점을 달리게 해서 먼저 통과하는 사람이거나, 아니면 달리는 도중에 스피드건을 쏴서 속력이 높은 사람이겠지만. 엄연히 웹표준과 Active X는 다른 시작선 상에 서 있다.
그럼, 두 상대의 시작선을 맞추기 위해서, 상대가 이용하고자 하는 '웹'이라는 타깃에 궁극적인 목표부터 알아보고자 한다. (웹을 한 문장으로 담기가 너무 힘들었다. 나의 주관적인 입장으로 '웹'을 한 문장으로 정리를 했으니 이해를 바란다.)
웹 : 통신환경에 연결된 컴퓨터에서 정보를 배포하고 공유하기 위함
필자가 웹을 이용하는 목적에 시작선을 둘려고 한다. 필자는 웹 브라우저를 통해 웹을 접근하고 있으며, 수도없이 많은 사이트내에서 하이퍼링크를 이용해서 방문을 확장해 나간다.
- 정보를 배포할때 : 나의 정보, 혹은 생각을 배포할때
- 정보를 공유할때 : 타인의 정보, 혹은 생각들과 교감할때
정보의 배포와 공유는 의사소통의 일환이다. 울산지역 방송국 아나운서 선발 시험에서 처럼 99%의 울산사람이 경상도 사투리를 사용하더라도, 원할한 의사소통을 위해서 표준어를 사용하는것 처럼, 97%의 환경이 몰아간다고 하더라도, 웹 사투리(Active X,. 파이어폭스 플러그인, Flash player)를 사용할 수 없다. 원할한 의사소통을 위해 역시 웹표준을 지향해야 하며, 사투리 사용은 가급적 자제해야한다.
나의 승부의 결과는 당연히 웹표준의 압승이다.
하지만, 위에서 내가 지칭한 웹 사투리 에게도 승리를 주고싶다. 사투리(방언)는 해당 지역내의 문화를 담고 있고, 그 지역의 사람들의 교감을 다져주는 교두보 역할을 하고 있다. 비록 제주도 사투리를 제주도민외의 사람들은 이해할 수 없지만 그들의 문화를 담고 있는 유산이다. Active X는 원할한 정보공유와 배포를 위해서 지향하지 말아야 하는것은 맞다. 하지만 Active X든, 파이어폭스 플러그인이든, Flash Player이든, 웹의 한계를 극복하고, 좀더 풍부한 웹의 가능성을 열어 준것에 대해서는 박수를 처 주어야 하지 않을까..
별책부록 Adobe Flex vs Microsoft Silverlight
2008년 3월 18일 대한민국 서울, 이날은 Adobe가 국내에서 처음으로 Flex 3.0과 AIR의 런칭을 발표한 날이다. 수도없이 많은 인파가 몰려, RIA의 인기와 기대를 몸소 실감할 수 있었다.
한국 어도비 관계자가 정식적으로 런칭과 관련된 프리젠테이션을 하고, 이어 Adobe사 Ryan Stewart의 프리젠테이션이 이어졌다.
그의 프리젠테이션중 뼈대있는 발언이 있었다. "Flex는 Flash Player을 통해 돌아가는데, 이 Flash Player은 전세계 99%의 PC에 설치되어있으며, 상위 버전으로 전환율도 빠르다. 또한 다양한 플랫폼과 디바이스를 지원하기 때문에, 도입을 망설일 이유가 없다" 라는 내용이었다.
과연 99%의 사용자가 사용한다고 해서, Flex가 웹 표준 기술중 하나로 인정받을 수 있을까? 답은 '아니오' 일것이다. 99%가 사용하는 만큼 접근성은 비교적 뛰어나고, 웹의 제약을 벗어날 수 있지만, 그렇다고 해서 아직까지 풀 플래쉬 화면으로 구성된 사이트는 없다. 구글이나 야후같은 사이트가 과연 풀 플래쉬 화면으로 구성을 할까? 결론은 앞으로도 그럴리 없다.
웹표준은 99%가 아닌 100%를 지향해야 한다. 1%도 명백한 방문자이고, 그들이 플래쉬 플레이어가 설치되어있지 않을경우, 어떠한 정보도 얻어갈 수 없다.
Adobe에서도 이런 심중을 알았을까. Flex가 웹을 떠나려 하고 있다.
프리젠터는, 청중에게 '웹상의 정보를 굳이 브라우저까지 들어가서 탐색하는 불편함이 있어야 하는가' 라고 물었다. 그리고, 다음화면에서는 Adobe AIR를 소개하는 화면이 이어졌다.
AIR(Adobe Integrated Runtime)는 데스크탑 기반 런타임으로, 플렉스로 작성된 프로그램을 그대로 데스크탑에 이식할 수 있다는 장점이 있다. 그간, Flex2.0에서 Apollo 라는 코드네임으로 불리었지만, Flex3이 베일을 벗음과 동시에 AIR로 바뀌었다. 이번에 출시된 플렉스 빌더3에는 AIR개발킷이 존재하며, Flex SDK와 마찬가지로, AIR SDK도 무료로 사용이 가능하며, 그 소스는 공개되어있다.
더 나아가, Flex4.0의 목표(goal)는 컴퓨터를 벗어나, 다양한 디바이스로의 모험 이라고 한다.
그동안 코드네임 WPF/E(Windows Presentation Foundation/Everywhere)로 알려진 개발툴도, 실버라이트라는 이름을 달고 정식으로 출시 되었다. 최근엔 2.0으로 버전업을 하였다.
실버라이트는 플렉스와 마찬가지로 웹 플러그인 형태로 돌아가며, 실버라이트를 구동시키기 위해서는 실버라이트 플레이어 플러그인이 필요하다.
실버라이트는 고화질의 영상 출력이 가능하며, 데이터와도 연동이 가능하다.
실버라이트를 기반으로 개발한 OBS경인방송
특이한 점은, 그간 많은 환경을 지원하지 않았던 ms의 정책에서 탈피해 여러 환경에서 실버라이트 플레이어 플러그인이 돌아가게끔 한 점이다. 자사의 윈도우 뿐만 아니라, 맥의 OSX, 그리고 윈도우 모바일6 에서도 구동이 가능하다.
과연 이 치열한 다툼의 승자는 누구일까? '웹을 빠져나가려고 한' 플렉스의 승리일까? '웹을 들어가려고 한' 실버라이트의 승리일까?
당시 CERN에서는 다양한 국가에서 파견된 과학자나 기술자가 수천 여명에 이르렀고, 상당히 유동적으로 상주 하였습니다. 아울러, 동시에 수백 가지의 연구가 진행되는 곳 이었는데, 모두가 공동의 목표를 향해 연구하고 있는 연구소 이기도 했습니다.
특히, LHC와 같은 거대실험은 작은 실수 하나로 막대한 연구손실을 초래할 수 있어서, 연구 결과의 보존을 비롯해 상호 검증도 필요하게 되었는데, 당시 CERN에서는 거대한 조직에 비해 그러한 커뮤니케이션 구조가 존재하지 않았습니다.
이러한 문제점을 보완하고자, 당시 연구원이었던 팀 버너스리가 처음으로 웹에 대해 제안하게 되는데, 그는 WWW에 대해 아래와 같이 제안하였습니다.
하이퍼텍스트’로 알려진 비선형[불연속적인] 문서 시스템에 대한 나의 짧은 경험을 요약하고, 이런 시스템을 도입하기 위해 CERN이 해야 할 일과 기업이 제공해야 할 것을 설명한다. 마지막으로 우리가 개인적, 집단적으로 어떤 것을 창조해 놓았는지를 알아보기 위해, 지금 우리 자신이 하이퍼텍스트에 몰입하는 단계를 제안한다.
이 처럼 웹은 개인적, 혹은 집단적으로 작성 된 문서가 비 선형적인 단계로 연결하여 확장 할 수 있는 시스템으로, 하이퍼링크를 이용해 사용자들이 인터렉션을 할 수 있는 공간을 의미합니다.
팀 버너스 리가 웹에 대해 처음으로 제안한지 1년 후, 본격적인 개발이 진행되었고, 4년 뒤 웹 표준을 개발하고 장려하는 컨소시움인 W3C가 설립되었습니다.
이후, 초 고속 인터넷망의 확산과, 개인 컴퓨터 보급으로 웹은 빠르게 전파되기 시작하였습니다.
2009년 현재, 웹은 전 세계의 많은 사람들이 다양한 장비를 통해 접근하고 있으며, 하루에 수억 건의 정보가 쏟아지고, 다양한 교류가 일어 나는 전 세계적인 유일한 공간으로 자리매김 하였습니다.
RIA, 새로운 경험을 제안하다
웹은 과학연구를 공유하기 위해 처음으로 고안되었지만, 현 세대에 이르러서 전 세계의 모든 사람들이 균등하게 참여할 수 있는 공간으로 변모하기 시작하였습니다.
하지만, 최근에 웹은 또 다른 한계에 봉착하게 됩니다. 웹을 이용하는 사용자들이 점점 늘어나고, 그들은 웹이라는 공간에서 다양한 인터렉션을 경험하길 원하는데, 웹은 근본적으로 비 선형적인 문서를 묶는 하나의 집합체에 불과 하였습니다.
즉, 웹은 하이퍼링크에 강하게 의존하는 집합이고, 사용자가 컨텐츠를 확장해 나가는데에도 하이퍼링크 클릭과 같은 인터렉션만 존재 하고 있습니다.
이러한 웹의 단점을 극복하고자 2003년에 이르러서는, 웹 애플리케이션을 하나의 플랫폼으로 발전한 형태인 Web 2.0이라는 용어가 처음으로 도입되었고, Ajax, SOAP등 그와 파생되는 여러 가지 기술들이 제안 되었습니다.
최근엔 web 2.0은 집단 지성과 같이 사회적인 영향도 가미되어, 누구나 참여할 수 있는 네트워크 플랫폼으로 변화하고 있습니다.
Web 2.0과는 별도로, 2002년 매크로미디어에서 처음으로 RIA(Rich Internet Application)를 제안하였는데, 초기 RIA는 기존 웹의 한계를 극복하여, 다양한 인터랙션이 가능하고, 동적으로 데이터를 공유하며, 인터랙티브 한 효과를 구현 하는 것을 목표로 하고 있었습니다.
이후, MS, 어도비, 썬마이크로시스템즈등의 개발사에서 RIA 플랫폼을 속속 발표하였으며, 많은 서드파티사에서 RIA플랫폼을 도입하기 시작하였는데, RIA는 그간 웹의 한계를 넘어 새로운 사용자 인터페이스와, 인터렉션을 제공하며 사용자의 경험을 더 확장 할 수 있는 장점으로, 사용자에게 큰 호응을 얻고 있습니다.
특히 미디어 분야와 같이, 그간 웹에선 제공 할 수 없었던 기능은, RIA 플랫폼에 필연적으로 의존하게 되었고, 이들 회사는 RIA 플랫폼을 도입 한 후, ROI 성장을 달성 할 수 있었습니다.
현재, RIA는 새로운 사용자 경험을 제안하는 전 세계적인 개발 트랜드로 자리 매김하고 있지만, RIA와 웹 표준이라는 관점을 두고는 최근에 까지 꾸준히 논란이 일어나고 있습니다. 그러한 의견 중 대부분은 본질적 웹의 관점과는 어긋나기 때문에 지향하지 않는 것이 좋다는 의견일 것입니다.
하지만, 웹은 전자 메일처럼 인터넷 상에서 제공 되는 서비스 일 뿐이고, RIA도 기존의 웹의 한계를 극복하기 위해 인터넷 상에서 제공되는 서비스 중 하나입니다.
특히, RIA 플랫폼은 최근에는 웹을 떠나 모바일로도 확장하여, 어느 기기에서나 같은 사용자 경험을 제공하는 유비쿼터스 플랫폼으로 발전하고 있습니다. 그래서 요즘엔, RIA 개발자를 웹 개발자로 부르기 보단, 프론트앤드 개발자나, UI 개발자로 부르기도 합니다.
이처럼, RIA는 웹이라는 공간에서 일어나는 기술의 변화라기 보단, 사용자 경험을 다양한 환경으로 확장하는 생태계의 변화로 이해하여야 하는데, 이러한 논쟁은 RIA와 웹, 두 플랫폼의 발전 방향을 달리 본 다면 오해의 소지가 줄어들 것 이라고 생각합니다.
사용자 경험과 포카 요케
앞서 살펴본 것 처럼, RIA는 그간 웹의 획일적인 인터랙션에서, 보다 확장하여 새로운 사용자 경험을 제안하는 도구로써 널리 활용되고 있습니다.
사용자 경험이라는 용어가 다소 생소해 보일 수도 있겠지만, 기술적인 용어는 아니고, 사용자의 관점에서 어떠한 제품이나 서비스를 체험하며 생각하게 되는 모든 경험을 통틀어 이르는 용어입니다.
사용자 경험은, 컴퓨터와 사용자의 인터랙션을 위해 처음으로 고안되었지만, 요즘에는 그 규모가 커져서 인지심리학, 경영학 등 여러 분야에서 함께 연구되고 있습니다.
RIA가 웹의 한계를 넘어 다양한 사용자 경험을 제공 할 수 있는 것도, 여러 RIA 플랫폼 내에서 그간 웹과 달리 터치스크린, 키보드, 파일 입력 등 다양한 인터렉션 도구를 제공하고 있는데, 이러한 인터랙션 도구를 이용하여 사용자에게 보다 직관적인 인터렉션을 유도하게 끔 할 수 있기 때문입니다.
이처럼, 사용자가 제품 혹은 서비스를 사용하는데, 지각할 수 있는 모든 인터렉션을 설계하고 개발하는 방법론을 사용자 경험 디자인(UX Design) 이라고 합니다.
사용자 경험 디자인 방법론은 한 가지 답이있는게 아니라 상황별 혹은 인터렉션 도구 별로 상당히 많은 방법들이 존재하는데, 이번 글에서는 포카 요케 디자인 방법론에 대해 소개하고자 합니다.
포카 요케(ポカ ヨケ)라는 발음에서 느끼셨겠지만, 이 말은 실수를(ヨケ) 피한다(ポカ)라는 뜻의 일본어 입니다. 조금 더 풀어 쓴다면 사용자가 직면한 상황에서 실수를 피하도록 유도하여, 도달하고자 하는 목표에 실패하지 않도록 하는 디자인 방법론 입니다.
포카 요케는 토요타 자동차의 신게오 신고가, 자동차 공정 과정 중 발생할 수 있는 오류와 결함을 최대한 방지하고, 또 즉각적으로 수정 할 수 있도록 처음으로 고안하였는데, 그 원칙은 아래와 같습니다.
색으로 분류된 부품들을 사용할 것
조립 부품위에 형판을 둘 것
다양한 조작을 작업자에게 계수로 알릴 것
하나의 가지는 여러 다른 가지보다 크게 할 것
“실수를 방지하는 디자인 방법론?”라고 의문을 가질 분들이 있을 것 같습니다. 사실 사용자가 범할 수 있는 실수의 범위가 상당히 방대하기 때문에, 그러한 실수를 일일이 고려하기에는 상당히 많은 노력이 필요하게 됩니다.
일반적으로 어떠한 제품을 사용하여 사용하고자 하는 목표에 달성하기 위해서는 여러 방법들이 존재하게 되는데, 웹의 하이퍼링크와 같이 획일적인 단계로 구성되어 있을 경우 사용자가 실수할 가능성이 낮지만, 목표에 도달하기 위한 연결고리가 상당히 많을 경우 사용자가 실수할 가능성도 높아지게 됩니다.
포카 요케 디자인 방법론은 사용자가 하게 될 실수에 대해서도, 발생할 수 있는 인터렉션의 범위에 모두 두고 설계할 것을 권장하고 있습니다.
즉, 디자이너는 사용자가 제품을 사용하면서 발생 할 수 있는 실수 상황에 대해 우선 정립한 후, 이를 사전에 피하게 하여 사용자가 제품을 사용하는 중 실수로 인해 좌절한다거나, 목표에 미달하는 것을 방지하는 역할을 하게 됩니다.
이처럼, 포카요케는 공정 과정 중 실수를 방지하기 위해 공업 분야에서 제일 처음 도입되었지만, 최근에는 더 나은 사용자 경험을 설계하기 위한 UX 디자인 방법론으로도 부각 받고 있습니다.
포카 요케를 찾아보다
포카 요케라는 디자인 방법론이 다소 생경해 보일 수 있겠지만, 사실 최근에는 공업 분야를 넘어 여러 분야에서 흔히 적용중인 디자인 방법론 중 하나이기도 합니다.
포카 요케는 일본의 토요타에서 처음 고안한 방법론으로, 자동차 회사에서 처음 고안한 만큼, 우리가 흔히 이용하는 교통 수단인 자동차에서도 이러한 방법론을 활용한 사례를 흔히 찾아 볼 수 있는데요.
예를 들어, 운전자가 자동차 기어를 “P”로 놓게 되면, 시동이 걸리지 않도록 만들어 급작스러운 출발이나 엔진과열과 같은 사고를 미연에 방지 할 수 있습니다.
그리고, 트렁크나 자동차 문이 정상적으로 닫혀 있지 않을 경우, 운전자에게 대시보드나 소리를 통해 안내하여, 고속 주행 시 발생 할 수 있는 사고를 미연에 예방 할 수 있도록 설계되어 있습니다.
지금은 잘 사용되진 않지만 플로피 디스켓에서도 포카 요케를 찾아 볼 수 있습니다.
3.5인치 플로피디스켓의 우측 모서리에는 작은 홈이 하나 있었는데, 이 홈에 걸려있는 작은 플라스틱의 위치로 해당 디스켓의 읽기/쓰기 상태를 제한 할 수 있습니다.
사용자는 플로피 디스켓의 홈을 통해 컴퓨터에 삽입하지 않더라고 물리적으로 디스켓의 제어 상태를 쉽게 알 수 있고, 디스켓에 중요한 데이터가 있을 경우 레이블을 통해 알려 줄 수 있지만 원천적으로 쓰기 권한을 제한하여, 사용자가 중요한 데이터를 삭제하는 실수를 방지 하게 할 수도 있습니다.
2009년 현재, 플로피 디스켓은 USB에 밀려 거의 사용되지 않습니다. 다만, USB와 같이 새롭게 부각받는 저장 매체에도, USB를 뒤집어 꼽지 못하도록 만들거나, 저장소의 잔여 공간을 시각적으로 안내해 주는 등의 포카 요케 디자인 방법론이 활용되고 있습니다.
네이버, 다음등의 포털 사이트에서 자주 접하게 되는 검색어 자동 완성기도 포카 요케 방법론을 도입한 사례입니다.
검색어 자동 완성기는, 사용자가 검색어의 일부를 입력하면 해당 키워드와 유사한 키워드를 제안해 주는 기능으로, 구글에서 처음 도입 하였습니다. 이 기능은 Visual Studio와 같은 개발 도구에서 유용하게 사용하는 인텔리센스 팝업에서 힌트를 얻었다고 합니다.
인텔리센스 팝업은 코드 힌트 팝업으로도 알려져 있는데, 개발자가 개발 인터페이스에서 작업하는 과정 중 입력한 키워드 일부가 미리 선언된 클래스나 변수, 메서드와 일치한다면 팝업을 통해 나타내는 기능으로, 이 기능을 적절히 활용하여 개발자들은 개발 시간 단축과 실수 방지의 효과를 누릴 수 있어, 많은 개발자들이 상당히 유용하게 활용하고 있는 개발 도구 중 하나입니다.
재미있게도, 검색어 자동 완성기는 한국에서는 실수방지 측면에서도 사용되고 있는데, 사용자가 한국어로 구성된 문장을 영어로 입력할 경우 검색어 자동 완성기에서는 그 문장을 한글로 바꾼 형태로 제안 해 주기도 합니다.
하지만 인텔리센스 팝업과 달리 자동 완성기능에는 문제점이 있는데, 자동 완성기에서 제안하는 키워드는 사용자가 입력한 키워드 중 선호도를 분석하여 제공하는 데이터로, 인텔리센스 팝업과는 달리 제공되는 데이터가 상당히 유동적이고, 집단 지성에 강하게 의존하는 기능이어서 컨텐츠에 따라 제공되는 제안어의 정확도 차이도 있을 수 있습니다.
이외에도 종이 분쇄기에는 손이 들어가지 않도록 설계해 둔 것과, 에스컬레이터에 발 걸림 방지 솔을 달아 두어 사용자에게 경고를 나타내는 것도 포카요케 방법론 사례라고 볼 수 있습니다.
RIA와 포카 요케
앞서 포카 요케 방법론이 적용된 사례들에 대해 알아보았는데, 최근에는 컴퓨터와 사용자간의 인터렉션을 설계하는데에도 흔히 사용되는 디자인 방법론이기도 합니다.
특히, 하이퍼링크와 같이 직관적이고 획일적으로 구성된 웹과 달리, 다양한 인터랙션 도구를 제공하고 있는 RIA 플랫폼에서 사용자의 실수가 빈번하게 발생 할 수 있습니다.
따라서, RIA 플랫폼에서 UX 디자인을 설계할 때에는, 사용자들의 인터렉션을 면밀히 분석해서, 발생할 수 있는 실수를 미리 예방하는 것이 가장 좋습니다.
그럼, RIA 플랫폼에서 포카 요케 디자인 방법론의 적용 사례를 살펴 볼까요?
현재 대부분의 RIA 플랫폼은 위와 같이 객체에 대한 클릭, 멀티 터치, 키보드 입력, 데이터 입력등의 인터렉션을 지원하고 있고, 위의 네 가지 인터렉션이 가장 빈번하게 발생하고 있습니다.
RIA 플랫폼에서 제공하는 이들 인터렉션은, 웹과 달리 상당히 높은 자유도를 가지고 있으며, 이들 인터렉션을 적절히 고려하여 사용자 경험에 마침 맞는 애플리케이션을 저작 할 수 있습니다.
다만, 하이퍼링크를 이용해 정보의 확장이 발생하는 웹과 달리, RIA 플랫폼은 여러 인터렉션들을 활용해 사용자가 목표로 도달하는 과정을 다원화 할 수 있는데, 이 과정에서 여러 실수가 발생 할 수 있습니다.
위의 도표는, RIA 플랫폼에서 제공하는 주요 인터렉션에 대해 일반적으로 발생 할 수 있는 실수들을 나열해 본 것입니다.
도표에서 나타낸 상황 이외에도 여러 실수가 발생 할 수 있는데, 위의 상황들의 공통점은 애플리케이션의 시나리오에 마침맞지 않은 상황에 도달 한 것이라고 볼 수 있겠네요.
그리고, 위의 도표는 위의 실수에 대해, 포카 요케 디자인 방법론을 이용해 해결 방법을 제안한 것 입니다.
앞서 살펴본, 포카 요케 디자인 방법론에 따르면, 사용자가 겪게 될 실수를 최대한 피해가고(사전방지), 사용자의 실수를 즉시 알려주는(오류탐지)등의 대응을 하여, 사용자들이 당황하지 않도록 하는 것이 중요한데요.
위 도표의 대안방법들도, 잘못된 객체 클릭과 같은 사용자의 실수 인터렉션이 발생한 후 즉각적으로 사용자에게 알리는 것과, 키보드 입력 제한과 같이 사용자가 실수하지 않도록 미리 막아두는등의 방법으로 나뉘어져 있습니다.
이러한 실수 방지를 위해, 별도의 코딩이 필요하지만, 대부분의 RIA 플랫폼에서는 사용자의 실수를 앞서 방지하고, 즉시 알려 줄 수 있는 여러 유용한 도구들이 있습니다.
예를 들어, 실버라이트로 이미지 에디터를 개발 할 경우에 대해 생각해 봅시다. 이 애플리케이션은 이미지 에디터 인터페이스에서 사용자가 편집할 이미지를 업로드 다이얼로그를 통해 불러오는 과정을 거칠 것입니다.
하지만, 사용자들은 텍스트 파일 처럼, 이미지 에디터에서 사용되지 않는 파일을 로드 할 수 있는데, 이 경우 사용자가 실수를 한 것임으로, 사용자 인터페이스에 오류를 통해 다시 파일을 불러올 것을 안내할 수 있습니다.
위와 같이 사용자에게 오류를 즉시 안내해주는것도 좋은 포카요케 설계이지만, 실버라이트를 비롯한 닷넷 프레임워크에서는 이러한 실수를 미리 예방할 수 있는 도구를 지원하고 있는데, 업로드 다이얼로그에서 사용자가 이미지 파일 이외의 파일을 선택하지 않도록 제한해 둘 수 있습니다.
이처럼, 실버라이트를 비롯한 여러 RIA 플랫폼에는 사용자의 실수를 미리 예방 할 수 있는 여러 도구들이 존재합니다. 아울러, 이벤트 리스너를 이용해 사용자의 인터렉션을 추적하여, 개발하는 애플리케이션과 마침 맞는 오류 탐색기 및 실수방지기를 개발 할 수 있습니다.
