- 어느덧 3월 중순! 춘삼월이 왔다지만, 아직까지 마음도 겨울, 바깥도 겨울. 그렇다 보니 무척이나 심란하다. 1년 중 따뜻한 햇살 아래 벤치에 누워서 낮잠 자는 기회가 봄, 가을밖에 있지 않는데, 올해는 그 기간이 무척 짧아질 것 같아 걱정되는구나…  아 오늘 벤치에 앉아서 낮잠 시도했는데, 등 시려.

- 학교에는 10학번 후배들이 모락모락 피어나오기 시작했다. 녀석들, 어찌나 붙임성이 좋은 지, 처음 보는 선배한테도 ‘야~’라고 하는구나. 그냥 고맙게 웃어넘기며, ‘나 09학번인데’라고 하니깐 급 썰렁해지는 과사 분위기… 어째.. 그냥 나 10학번이라고 하고 다닐걸 그랬어.

- 그러고 보니 나도 신입생, 딱 저맘 때 정말 재미있게 놀았던 거 같다. 크크 그때처럼 놀고 싶어서 다시 수능 보고 11학번이 된다는건 왠지 오버겠지.

- 연애관계에서도, 일에서도 솔로가 된지 어느덧 한달 여가 되어가는구나. 연애관계는 뭐.. 그 닥 서로 바빠서 연락 못하고 지낸 사이라 그때도 그렇고, 지금도 그렇게 충격이 크진 않지만, 봄바람이 살랑살랑 불어오니 외롭고 옆구리가 시리고.. 그저 슬픈 듯.

- 일에서 솔로가 되다 보니, 무척이나 게을러지고 긴장감이 없어지기 시작했다 0_0 지금 먹고 있는 약 기운 탓인지 춘곤증인지 몰라도, 이 시간대가 되면 무척 졸립고 나른하다. 하지만 개발하랴, 기획서 쓰랴, 원고 내리랴.. 그저 바쁘구나..

- 한 2달 동안 일에만 미쳐서 지내다 보니, 챙겨주지 못한 사람들이 너무 많아서, 미안하다. 우선 나열! 그리고 뭔가 생각날 때마다 업데이트해야지

- 첫째로, 가족들한테 죄송하다. 일을 하는 동안 거의 한달 내내 집에 들어가질 못했다. 설에도 잠시 얼굴만 보고 바로 일하러 내려오고.. 이제부턴 따뜻한 말도 자주 건내고, 나도 가족 구성원처럼 잘 지내야지.

- 다음으로 어도비 코리아! 올해로 3년째 알고 지내는 건가. (참 오래되었다.) 근 세 달 동안 블로그 포스팅이며, 대외활동이며 아무것도 하지 못했다. 이제 곧 큰 소식이 들려올 예정이니, 열심히 해야지 ㅠㅠ 죄송해요 곰효희님

- 그리고 MSP! 사실, 1월 이후부터 쭉 모임에 나가지 못했구나. 마무리가 이건 영 아니여. 특히 막판 프로젝트가 서버 폭발 상태로 제대로 동작하지 않아서, 민해, 로지형한텐 그저 미안.. 멜로디언 대리님께도 죄송합니다. 다들 미안..

- 물리학과 09학번들! 너희들한텐 고저 미안한다는 말밖에 할말이 없구나. 요번 과엠티 가서 하나하나씩 풀자 구나.(밟지는 말고) 특히 군대 가버렸는데 그 전에 만나 입대주 조차 섞어주지 못한 여러 동기들한테 미안. 이항모교수님, 김진민교수님께도 죄송합니다.

- 그리고 저의 프로그램을 사용해주시는 많은 사용자분들께 죄송하다는 말씀을 드립니다. 희희덕덕, 덕지덕지, 덕글콜록, 쿠디, 유세윤플랫폼등 모든 프로그램의 업데이트와 관리가 많이 미진했습니다. 특히 수강신청때 대란을 맞이했을 숭실대를 포함하여, 여러 대학의 대학생분들께도 죄송하다는 말씀을 드리고 싶네요.

- 아아 마지막으로 요즘은 뭔가 그런 생각이 든다. 나랑 비전이 딱 맞고, 하고 싶은 무언가가 뚜렷한 누군가를 만난다면, 내 모든 열정을 다 받칠 각오도 되어있고, 즐겁게 할 수도 있을 것 같은데, 그런 분을 만나기가 참 쉽지 않구나. 그래서 오늘도 여기저기 방황 중!

- 혹시 뭔가 열정이 충만하고, 개발하기를 좋아하는 아이 하나랑 뭔가 해보고 싶은 분들은 hhdd at adnaru.com 이나 이 글 바로 밑에 댓글을 남겨주시면 감사하겠습니다 (__)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

- 항공기는 육로를 거치지 않는 지구상에 몇 안 되는 교통 수단 중 하나다. 그렇기 때문에, 육로에서는 발생하더라도 쉽게 대처할 수 있는 사고들도 적절한 대처를 할 수 없게 되고, 결국 대형 참사로 이어지는 경우가 종종 있다.

- 하지만 항공기는 모든 시스템이 고도로 자동화되고, 이중 삼중의 안전 체계가 잘 갖추어 져 있어, 실제로 사고가 발생하더라도 대형 참사로 이어지는 확률은 매우 드물다. 지금까지 발생한 항공사고들도 항공기의 기기 결함보다는, 조종과실이 대부분이다.

-  항공 관제 용어 중에 메이데이(MayDay)라는 용어가 있는데, 항공기 운항에 왠 봄날이냐, 노동절이냐 라고 할 수 있겠지만, 항공기 운항 중 발생할 수 있는 최악의 응급상황에 관제탑에 도움을 구할 때 사용하는 급전이다. 만약, 조종사가 관제탑에 메이데이를 치게 되면, 관제권에서부터 착륙까지 모든 상황에 있어서 우선권을 부여 받게 된다. 하지만 거대한 납 덩어리인 항공기가 공중에서 그러한 비상상태를 맞이하게 되면, 대부분 벗어날 수 없는 최악의 상황에 이르게 된다.

- 그래서 이보다 다소 응급도가 덜한 상태에서 도움을 구할 수 있는 팬-팬(PAN-PAN)이라는 관제용어가 있다. 조종사가 관제탑에 팬-팬을 치게 되면, 메이데이와 같이 관제에서 우선권을 받게 되며, 조종사는 관제탑에게서 운항과정 전반에 대해 많은 도움을 받을 수 있다. 물론 팬팬으로 급전을 날린 상황에서도 대형 참사가 발생한적도 있지만, 메이데이를 날린 상황보다는 응급상황을 극복 할 수 있는 확률이 높게 된다.

- 사람과의 관계에 있어서도 힘들 때, 혹은 위급할 때 메이데이를 치는 것은 돌파구를 찾는데 직효약으로 빠르게 작용할 수 있겠지만, 그 만큼의 부작용은 감내해야 하는 것 같다. 심지어, 그렇게 극복하지 못하고 그대로 추락해 버리는 경우는 돌이키기 힘들 정도로 큰 상처로 남게 되는 것 같다.

- 그래서, 대인관계에서 절체절명의 위기가 오기전에 “나 요즘 힘들다. 도와줘”라고 팬-팬(Pan-Pan)을 치는 것이 중요한데, 역시 이는 타이밍과 화법의 문제인 것 같아, 항상 망설이고 고민하게 된다. 그래서 결국 메이데이를 날려야 하는 상황도 오게 되는 것 같고..

- 결국 대인관계에 있어 팬-팬(Pan-Pan)을 치는 타이밍, 그리고 화술과 대처방법은 친분 관계를 넘어, 결국 한 사람의 대인관계의 관록 그리고 책임을 보여주는 것 같다. 조종사가 승객의 생명과 안전을 지키기 위해 팬팬을 치는 것 처럼.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이 세상의 모든 생명체들은 자기 자신의 숨통이 끊어질때까지 어찌보면 짧은시간동안 세상을 즐기기도 하고 이리저리 세상의 모난 구석에 부딪히며 살아간다. 그러한 생명체들 중에서 특히 인간은 살아가는동안 생각하는 정신 즉, 자아를 갖게 되는 유일한 존재이고, 다른 자아와 섞여 새로운 자아를 만들어 내기도 하고, 여러 자아들과 부딪혀 충돌하며, 성장해 나가기도 하는것 같다.

먹이사슬이라는 아주 규칙적이고 상쇄적인 사회에 묶인 거의 대부분의 생명체들과 달리 자아에 의해 몸이 지배되는 인간인 이상, 언젠간 나와 다른 자아와 충돌하게 되고, 그 속에서 상처를 얻게 되고 또 다른 세상을 발견하게 된다.
세상엔 참 힘든일이 많은것 같다.

나는 그동안 그런 힘든일이 있을때, 보통은 "왜 나한테 그렇게 힘든일이 왔는지.." 부터 생각하는 사람이었다. 그리고 그런 힘든일을 잊기위해, 그 사건 자체를 축소하며, 왜곡하며 그렇게 분노하며 잊어왔던것 같다.

그리고 왜 그런 힘든일이 나한테 생기는지..
하늘은 원망한적이 많았다.
(특히 10대 중반에.. 몸이 많이 아팠을때)

하지만 한편으로는, 그런 일이 있어서 분명 크고 작은것을 잃게 되겠지만,
그런 상실이 또 다른 기회가 되어서,  

'나'라는 덩어리 위주의 터울, 즉 이기심에서 벗어나서, 좀 더 좋은사람이 되어 다양한 사람들과 섞이게 되고
한편으로는 성장할 수 있는 발판이 되는것 같다.

그래서 지금 이글을 쓰면서 고민하고 있는 시간,
그리고 그런 소중함을 깨닫게 해준 그 사람한테
참 고맙다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

일상이라는 카테고리를 만들어놓고, 정작 내 일상에 대해서 이래저래 터놓고 말하지 못한게 1년여가 지난것 같다. 블로그를 처음 열기 시작하면서 그동안 내 블로그에 많은 분들이 찾아와주셨고, 기술적 카테고리 이야기들을 많이 공개하고 공유하다보니, 정작 이 공간이 나의 공간이 아닌것 같은 일종의 이질감을 느꼈다. 그래서 나 조차도 요즘엔 자주 찾지 않게 되는구나...
이제 여기서 내 이야기 자주해야지, 그리고 이 공간에 좀 더 애착을 갖고, 많은 정보들을 공유하도록 노력해야지.

오늘은 이곳 저곳이 많이 떠들썩 하다.
TV, 신문지면 광고를 도배했던 김연아선수가 금메달을 따서일까.
아니면 김연아의 경기에 사람들이 감동해서 일까..
주변사람들 모두 다 들떠있는듯 하다. (적어도 오늘의 분위기로 봐선 대한민국이 잠들지 않을것 같은)

김연아의 경기를 지켜보면서, 그리고 경기 종료후 글썽이는 김연아의 모습을 보면서,
나 자신도 참 많은 생각이 들었다.

그러고 나서, 나 아닌 사람들과 이 감동(?)을 공유하고자,
언제나 뒷담화가 가득한 네이버 뉴스, 디씨갤들을 살펴봤는데,
반응이 장난이 아니구나..

금메달 연금은 얼마임? 김연아가 광고는 다 쓸겠네.. 대충 이런느낌의 글들..
그런 글들을 보면서, 왜 본인이 김연아도 아닌데, 그런 생각까지 하나 싶었다.
마치 시정잡배처럼... 아니 이건 확실히 말해서 질투심이지. 혹 이게 사람의 본능인걸까.

그 사람들은 알고 있을려나..
경기순간에는 화려한 조명을 받고, 관중들의 환호를 받아도
경기중에는 김연아 이외에 아이스링크에 아무도 들어갈 수 없다.

김연아에게 메달을 걸어주는 심판들도 경기장 밖에서 숨죽여 지켜볼뿐.
결국 그 공간에서는 김연아는 혼자단 말이다.

그리고, 김연아가 그런 성과를 거두기위해 혼자서 연습하는동안
(최근엔 스폰서쉽등으로 자주 방송에 나오는듯 하다만)
몇번이나 실패하고,  몇번이나 넘어지고,
몇년이나 그렇게 죽을도록 노력했는지.. 나는 감이 잘 안온다.

그렇게, 김연아는 많은 사람들의 지지와 사랑, 주변인들의 도움과 관심을 받아도
링크안에서는 항상 혼자가 될 수 없는 외로운 존재다. 앞으로도 그럴거고..

다른 올림픽 경기를 지켜봐도
경기중에는 내 옆을 따라잡고 추월하려는 경쟁자가 있더라도
그 경쟁자를 이기는건 나 자신의 힘이다. 결국 언제나 외로운 도전일뿐.
(물론 심판이 관여해서 개판이 된 경우도 있었다만)

바꿔서 생각해보면, 올림픽이란건 아니 모든 스포츠 경기라는건
그런 경기 모습 하나하나가, '우리네 인생의 축약체'라는걸 보여주려는게 아닐까.

최근에 이래저래 나한텐 힘든일이 있었다.
일에서는 좋은 결과가 있었지만, 사람과의 관계에서는 실패한
그래서 그런지 마음이 많이 불안정했었다.

처음엔 그 사람이랑 하던일이 내 생의 전부인줄 알고,
그 사람과의 관계가 깨져버린 지금 앞으로 나는 이 일을 할 수가 없겠지..

내가 좋아하던 일을 할 수 있던 유일한 사람인데, 과연 누구랑 해..
이런생각도 많이 들었고.

하지만 김연아 선수의 경기를 지켜보면서,
누구랑 같이 어떤일을 하던, 누군가에게 의존하는 마음을 갖기 보단
팀을 꾸려 공동체를 만들더라도 결국 내 자신의 싸움이라는걸 알게 되었다.

단체 경기에서 팀웍이 하도 중요하다 하지만,
결국 그 팀웍이라는 존재 자체를 만드는것도 나 자신이고,

그러니 어떤 조직에서든 구성원에 대한 배려, 그리고 관심이 필요하겠지만,
그 이상 지나치게 되면 그건 간섭이고 집착이 되는거고..
그래서 지금은 그 사람에게 심장이 저리도록 많이 미안하다.
 
그리고 요즘은 내 스스로가 자신에게 좀 더 많은 관심과 지지, 격려가 필요하다는 생각이 든다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

요즘 사용자 경험(UX)을 고려한 설계의 중요성이 웹을 비롯한 여러 산업 분야에서까지 화두로 떠오르고 있는 것 같습니다.

국내에서도 사용자 경험을 공유하는 스터디 모임이 몇몇 운영 중이고, 몇몇 대학에서는 UX 과정이 개설된 곳도 있다고 합니다. 얼마 전엔, UX를 교류하는 컨퍼런스인 UXEye도 진행되었습니다.

그만큼, 사용자의 경험을 고려한 설계의 중요성이 강조되고 있는데, 국내외적으로 UX와 관련된 여러 서적들이 있으니, 개발자, 디자이너임을 떠나서 한번쯤 참고해 보시는 것도 좋을 것 같습니다.

UX 디자인은 사용자가 경험 할 수 있는 모든 감각과 상호작용을 기반으로 설계되는데, 웹과 같이 단 방향 미디어 매체에서는 주로 시각, 청각과 같은 감각과, 클릭, 터치와 같은 사용자의 인터랙션이 중요시 되고 있습니다.

 

사용자의 시각을 고려한 디자인 방법론에는 여러 가지가 있는데, 그 중 보색 대비는 사용자에게 강한 주목을 얻기 위해서 흔히 사용됩니다. 예를 들어, 도로표지판에서도 노랑과 검정을 함께 나타내어 주목의 효과를 강조하기도 합니다.

보색대비는 사용자에게 주목과 강조를 주기 위한 가장 본능적인 경험이고, 이를 적절히 활용하여 사용자에게 주의를 준다면 상당히 효과적인 UX 디자인 방법이 될 수 있습니다.

하지만, 본능적인 경험이 또 다른 본능적인 경험과 충돌하여, 최상의 경험은 커녕 사용자에게 심각한 위험을 준 사례가 있습니다.

90년대, 당시 일본에서는 닌텐도 게임을 기반으로 한 애니메이션인 포켓몬스터가 큰 인기를 얻고 있었습니다. 당시 포켓몬스터의 시청률이 1위를 여러 차례 달성하였고, 닌텐도 게임이 정식으로 발매되지 않은 한국에서 방영하여 지금까지도 계속 사랑을 받고 있는 애니메이션 이기도 합니다.

 

하지만 97년 12월 13일 방영된 포켓몬스터에서 단 3초의 실수로 그 인기가 분노로 바뀌어 버리는 사건이 발생하고 맙니다. 당시, 방영 분에서는 컴퓨터 세계의 대전을 다루었는데, 적이 소멸되는 순간 빨간색과 파란색의 보색이 상당히 여러 번 번갈아 표현되었습니다.  

 

이 방영분이 방송된 직후, 전국의 700여명의 아이들에게 광 과민성 발작이라는 질병이 동시에 발생하였고, 구토를 일으키며 의식을 잃는 간질증상도 발견되어 수십 명이 병원 신세를 지어야 했습니다.

광 과민성 발작은 과도한 시각적인 변화로 인한 자극을 보호하기 위한 신경적인 본능인데, 의식을 잃고 구토를 하는것과 같은 동작으로 강렬한 시각적인 자극을 피하려고 합니다. 이전엔 게임을 하던 사용자에게서 간혹 발생하여 닌텐도 발작으로 알려지기도 했습니다.

하지만, 포켓몬스터 발작 사태처럼 수백 명이 동시에 발병하는 사태는 전 세계적으로 처음 있는 일이었고, 구토로 인해 기도가 막혀 사망할 수 있는 가능성까지 제시되면서 당시 일본 열도를 충격으로 몰고 가기도 했습니다.

이 사건이 발생한 직후, 언론에서는 대서특필 하였고, 당시 최고의 인기 애니메이션이었던 포켓몬스터는 4개월간 방송이 중지되는 강 징계를 받았고, 당시 상영 분 또한 완전히 폐기 되었습니다.

이후, 일본 애니메이션은 만화 시작 전 ‘방안을 밝게 하고, 멀리 떨어져서 시청하십시오.’와 같은 경고문을 반드시 방영하여야 했고, 보색대비가 포함된 강렬한 색체자극은 사용 할 수 없도록 규제화 되었습니다.

 

아울러, 전반적인 웹의 표준을 관리하는 컨소시움인 W3C에서도, 1999년 웹접근성가이드(WCAG) 1.0 에서 보색대비가 들어간 강렬한 색채전환 효과는 사용하지 말 것을 명시하였습니다.

하지만, 이런 사건의 경각성에도 불구하고, 잘못된 색체효과 사용으로 인한 사고는 아직까지도 흔한 편이라고 합니다. 얼마 전 2012년 런던올림픽 프로모션 사이트에서도 앰블램을 나타내는 부분에서 사용한 색채전환 효과가 광 과민성 발작이 발생할 것을 우려해 영상의 일부가 삭제되는 일도 있었다고 하네요.

사실 이 글에서 다룬 사례는 두 가지의 본능적인 사용자 경험이 충돌한 것으로, 그 결과가 사용자에게 혼란을 주어 중대한 위해를 준 사례이기도 합니다.

이처럼, UX 디자인 설계를 할 때에도 하나의 최상의 사용자 경험을 고려하여 설계하는 것 보다, 여러 가지 상층되는 사용자 경험들도 함께 고려하여 설계하는 것이 중요할 것으로 생각합니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

안녕하세요. 희희덕덕입니다.

한글팀이 발촉한지 약 1년의 시간이 지난 것 같습니다. 그 동안 한글팀은 아무도 한글문제 해결에 관심을 갖지 않았을때, 한글문제와 관련되어 뜻있는 개발자 7인이 모여 결성한 팀으로 한글 문제에 관심을 갖는 작은 성과에 시작하여, 해결에 까지 이어지는 큰 성과로 이어오고 있습니다.

최근에 해결된 한글 문제는 아래와 같습니다.
플렉스, 한글 입력 지연문제가 해결되었습니다.
AIR, 한글삭제 문제가 해결되었습니다.
Flash Player, transparent 한글 문제가 해결

그리고, 최근에 Flash Platform의 한글 입력 문제가 하나 더 해결되었습니다

이 문제는, 한글팀에서 Halo의 Textinput 컨트롤의 입력지연문제와 함께, 어도비의 이슈트래킹시스템(http://bugs.adobe.com)에 등재하여, 총 38건의 투표를 받았고, 중요도는 B로 설정되었습니다.

FxTextinput - Korean text input is a problem that is very slowly

이 문제점은, 지난해 12월 경에 등재하여, 이슈트래킹시스템에는 6월 8일까지 논의되었으며, 이후 Flash Player 팀의 Bugbase에 2350482로 등재되어 관리되었습니다.

그리고, 최근 내부빌드인 10.1.50.351에서 이 문제가 완전히 해결되었다고 Flash Player팀에서 알려왔고, 한글팀에서 이 문제점이 해결 된 것을 확인하였습니다.

이 문제가 해결될 수 있도록, 귀중한 시간을 내어 투표를 해 주신 38분의 개발자 분께 진심으로 감사의 말씀을 드립니다. 또, 이슈트래킹 시스템에서 해당 문제의 중요성에 대해 피력해주신 변경덕님께 감사드리며, 특히 해당 문제점의 번역에 많은 도움을 주신 이상용 대표님께도 감사의 말씀을 드리고 싶습니다.

한글팀에 많은 지지와 적극적인 참여를 보내주신 많은 분들께 감사드립니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

지난 3월, 마이크로소프트의 컨퍼런스인 MIX09(http://live.visitmix.com/)가 라스베가스에서 개최되었습니다. 작년 MIX08에 이어, 올해도 재미있고 굵직굵직한 이슈들이 많이 발표되었다고 하네요.

특히, MIX09 주제가 ‘The Next Web Now’ 인 만큼 실버라이트 3 베타버전 공개와 함께, IE8의 정식 릴리즈, Expression3와, 새로운 프로토타입 설계툴인 SketchFlow가 공개되는 등 굵직굵직한 라인업 또한 많았습니다.

MIX09의 모든 키노트는 인터넷을 통해 공개되어 있으니, 한번 짬짬이 보시는 것도 좋을 것 같습니다.(언어의 압박이 조금…) 또, 한국 MS의 에반젤리스트들의 블로그에도 MIX09와 관련된 정보들과 후기들도 많이 올라와있으니 한번 둘러보세요 : )

MIX09 키노트 다시보기
UXfactory MIX09 실황중계
준서아빠가 생각하는 행복한 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 SDK
실버라이트3 런타임

위에서 살펴본 실버라이트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, 과연 둘은 서로 윈윈하는관계가 될까요? 아니면, 모바일계의 혜성으로 서로 양날의 검이 될까요?

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

대박

2005년 6월 21일 ~ 2009년 10월 20일 오후 9시 50분

어제 밤 저희 집의 막내이자 가족이었던
대박이가 갑작스레 생을 달리 했습니다.

아침까지만 해도 나를 바라보고, 말도 하던 녀석이
이렇게 세상을 떠나게 된 것이 아직도 믿겨지지 않습니다

내 원망 참 많이 할 녀석
내일이면 다시 일어나서, 우리 가족들한테 인사를 건내 줄 것 같은 녀석

하지만 이 녀석이 내일 차가운 땅에 묻히고 나면,
적어도 우리 가족들 외엔 추억해주고 명복을 빌어줄 분들이 없습니다.

제 블로그를 찾아주신, 많은 분들께서
대박이를 추억해주고, 명복을 빌어주길 간절히 바랍니다.
갑작스레 떠난 녀석인 만큼 우리 대박이가 좋은 곳에 갈 수 있도록..

잠시라도, 5분, 1분, 아니 마음속으로라도 좋으니
우리 대박이가 좋은 곳으로 갈 수 있도록, 기도해주세요.

참으로 이쁘고 고마운 녀석
내 아픔과 슬픔도 함께 했던 녀석

이제 마음속에 묻어야하겠지만.
그 녀석을 내 마음속 평생 묻어두고, 추억하며
대박이가 내 마음속에서라도 살아 갈수 있길 바랍니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이 동영상은 Microsoft의 Future Vision에 이어, 미래의 사용자 경험 개선들을 전체적으로 담고 있는 동영상인데요.
Microsoft Future Vision : Banking
Microsoft Future Vision : Manufacturing
Microsoft Future Vision : Retailing
Microsoft Future Vision : Healthcare

앞서 여러 Future Vision들에서 다룬 것처럼, 이 동영상에도 사용자가 접촉할 수 있는 모든 사물과 인터력센을 가능하게끔 한 점이 이색적입니다.

사실 이 동영상에는 소프트웨어 적인 면 보단 하드웨어적인 변화를 많이 담고 있어서, 언제쯤 실현이 될 지는(?) 확실하진 않으나, 사용자가 경험 할 수 있는 최고의 UX를 담고 있지 않나 생각해봅니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이번 동영상은 의료 산업 분야의 Future Vision 입니다. 의료 산업은 다른 산업들에 비해, IT와의 융합이 급속도로 이루어지고 있는 분야 중 하나인데요.

IT와 의료 산업이 만난 대표적인 예로 EMR을 들 수도 있고, 거의 대부분의 검진 장비도 컴퓨터로 구성되어있습니다. 요즘 메이저 병원에서 대대적으로 도입하고 있는 키오스크 서비스 또한 그 변화의 대표주자라고 볼 수 있습니다.

이 동영상에서는, 예방과 치료 두 분야에서 상당히 개선된 UX를 보여주고 있는데요. 사용자가 운동을 하면서, 심장의 페이스 변화를 담당의에게 보내고, 병원에서 치료받는 환자는 검사 결과를 의사와 함께 보면서 좀 더 빠른 치료효과를 얻을 수 있도록 돕고 있습니다.

요즘 U-healthcare 분야가 각광받고 있는 만큼, Microsoft의 Healthcare Future Vision에서 보여준 변화가 실생활에서도 적용될 날이 머지 않을 것 같습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.