내 맘대로 보는 세상

webdevmobile에서 3회(1, 2, 3)에 걸쳐 개최한 열린 세미나가 성공적으로 끝이 났습니다. 웹은 예전부터 관심을 가지고 지켜보고 있었지만 최근 HTML5 등의 이슈에 대해서는 제대로 follow up 하지 못하고 있어서 약간의 죄책감을 가지고 있었는데, 덕분에 HTML5에서 지향하는게 무엇인지에 대해 약간이나마 알 수 있어 재밌었습니다. :)

아무래도 HTML이란 이름 때문에 웹퍼블리셔 분들이 많이 참석하셨던데 (특히) 3회째 세미나는 웹퍼블리셔 분들보다 앱 개발자 분들이 좋아하셨을 것 같네요.

HTML5: API

첫 세션은 요번에도 이원석 박사님께서 담당해주셨습니다. 초점은 HTML5에 추가된 API 들에 초점이 맞춰져 있었고, Canvas 2D, Video API, Web Socket, Local storage, Local database 등에 대한 간략한 소개 위주였습니다.

이 정도 API면 왠만한 애플리케이션을 구현하는데는 거의 지장이 없을 것 같더군요. :)

그리고 AJAX의 경우 Cross domain에 대한 쿼리가 불가능했기 때문에 결제 모듈처럼 타 서버로 값을 넘겨주고 그 결과를 리턴받아 사용해야 하는 경우에는 JSON나 로컬 프록시 등의 편법을 사용해야 했는데요, Web Socket에선 이런 제약이 사라졌기 때문에 편법을 사용하지 않고도 훨씬 많은 일들을 할 수 있게 되었습니다.

시작은 플랫폼에 구속받지 않는 문서로 시작되었지만, 이제는 그 굴레를 벗어나 앱으로의 확장을 꿈꾸고 있는 것으로 생각됩니다.

HTML5: Device API

모바일 디바이스를 위한 확장으로 Device API라는 것도 소개를 해주셨는데, 거기에 포함된 것들은 Geo Location(GPS), Filesystem, … 등이 있었습니다.

다만 Geo Location 이라거나 Filesystem 등의 경우 사용자의 Privacy가 노출될 수 있는 문제가 있기 때문에 이를 보완하기 위한 것들이 아직 논의되고 있는 중이라고 하더군요. :)

Java servlet에서 하는 것처럼 signed javascript의 경우 geo location, filesystem 등에 접근하는데 제약이 없도록 하는 건 어떨까 하는 생각이 들었습니다.

HTML5: Worker

Worker는 운영체제의 Thread에 해당되는 기능이라고 합니다. 특정 js 파일을 인자로 new Worker(‘…js’)를 실행시키면 이 js 파일을 처리하기 위한 thread가 생성됩니다.

어떤 복잡한 (시간이 오래 걸리는) 자바스크립트 로직이 있을 경우 이 로직이 처리될 때까지 사용자의 인풋이 블럭될 수 있는 문제가 있습니다. Worker는 이런 문제를 피해가기 위해 추가된 기능이라고 하며, 역시나 실시간 앱 시장을 HTML5에서 얼마나 욕심내고 있는지를 확인시켜주는 기능이라고 생각합니다.

쓰레드 간의 통신을 위해서는 메시징을 이용하면 된다고 하네요.

HTML5 웹을 넘어 플랫폼으로…

이원석 박사님의 세션이 끝나고 든 생각은 ‘HTML5는 문서도 앱도 아니고 플랫폼이구나‘란 생각이었습니다.

그래픽/통신/데이터베이스/파일시스템/쓰레드/Inter-thread communication 등 운영체제들에서 제공하는 대부분의 기능이 HTML5에 정의되어 있는 것을 확인할 수 있었으며, 이 규격만 제대로 구현해도 하나의 운영체제로써의 역할을 할 수 있지 않을까 하는 생각마저 들었습니다.

삼성 등에서는 수없이 많은 휴대폰 모델을 개발하고 있으며, 각각을 위해 앱을 새로(완전히 새로는 아니더라도) 개발하고, 수정하는 과정을 거치고 있습니다. 이런 노력을 줄이기 위해 바다라는 플랫폼을 만들어냈고, 안드로이드라는 플랫폼을 차용하고 있는데요. 앞으로는 안드로이드나 바다 등의 플랫폼보다 웹 플랫폼이 더 사랑받을 수 있지 않을까 하는 생각이 들었습니다.

웹은 이제 옵션이 아닌 필수가 되어가고 있으며, webkit 같은 오픈소스 Web Library를 이용할 경우 쉽고 빠르고 안정적으로 웹 플랫폼을 제공할 수 있을 것으로 생각됩니다.

필수적으로 제공되야 한다면 차라리 이를 플랫폼으로 하고, 전화 App, DMB App 마저도 HTML5로 구현하면 어떨까 하는 생각까지 들더군요. (CDMA 모듈이나 DMB 모듈과 통신하기 위한 plugin을 제공하면 됩니다. 인터페이스만 동일하게 규격화 한다면, App은 재활용이 가능할 것입니다.)

조만영님의 얘기처럼 이제 곧 Web Engineer라는 직종이 새롭게 정의되지 않을까 하는 생각이 듭니다.

그럼에도 HTML5에 아쉬운 점…

최근 화두 중 하나는 3D입니다. 하지만 Canvas에서 2D에만 초점을 맞추고 있다는 점은 조금 아쉬웠습니다. 2D API로도 3D를 그려낼 순 있습니다. 하지만 3D API가 제공되지 않는다면, 하드웨어 가속 기능을 사용할 수 없고 이는 파워가 약한 모바일 디바이스에게 (실행 속도, 전력소모 두가지 측면에서 모두) 치명적인 문제가 될 수 있습니다.

다행히도 WebGL이라는 이름으로 (이원석 박사님 표현에 따르면 실험적인) Canvas 3D 규격이 준비가 되고있기는 한 것으로 보입니다만 아직 HTML5의 기본 기능으로는 분류되지 않고 있는 것 같네요. 조금 아쉬운 부분입니다.

또한 매번 문법을 파싱, 검사, 실행해야 하는 HTML5는 모바일 디바이스에서 약간의 부담일 수 있다고 생각합니다. 그렇기 때문에 java에서 그랬듯이 플랫폼에 무관한 바이너리로 변환해주는 기능(컴파일러)이 필요하지 않을까 하는 생각이 들었습니다.

물론 표준에 포함되지 않더라도 브라우져의 캐쉬단에서 파일을 컴파일해 저장해둔 뒤 다시 보여줘야할 땐 컴파일된 파일을 바로 로딩해서 보여주는 방법을 활용할 수도 있을거라 생각합니다.

에필로그

HTML5가 나오더라도 IE가 또 발목을 잡지 않을까 하는 이야기가 들려옵니다. HTML5, CSS3를 언제쯤 실무에 적용하면 좋을지에 대한 이야기도 들려옵니다.

저는 이렇게 이야기하고 싶습니다.

아직 PC를 위한 페이지에 적용하기는 조금 이를지 모르겠습니다. 하지만 모바일을 위한 페이지에는 적극적으로 HTML5를 활용해보아도 좋다고 생각합니다.

재작년말, 작년초 다음 커뮤니케이션 면접 때 ‘앞으로 웹이 어떻게 변할 것이라고 생각하시나요?’란 질문을 받았습니다. 그 때 전 이렇게 대답했습니다.

‘스토리지를 담당하는 서비스가 나오고, 이 서비스를 활용하는 어떤 매쉬업이 나올 것으로 생각됩니다. 웹은 이런 서비스들이 거미줄처럼 얽혀 무한한 가능성을 만들어낼 수 있는 플랫폼이 될 것으로 생각됩니다.’

그 때 제가 생각했던 것들이 점점 현실이 되어가고 있는 것 같습니다. 점점 더 재밌어지네요. 오랫만에 가슴이 두근두근 거리는 것 같습니다.

덧: 좀 게으름을 피다보니 그 때 나눴던 이야기들 중 까먹은 이야기가 너무 많네요… 메모라도 했음 좀 나았을텐데, 맨 몸으로 참석해서 맨 몸으로 돌아와버렸더니… OTUL

덧2: 다른 분들이 올려주신 후기들입니다. 역시 관점이나 생각에 따라 다들 느끼는 점이 다른 것 같습니다. :)

1. Wise님의 후기
2. Na!님의 후기

예전부터 방관자 입장으로 멀찍이에서 웹을 바라보고 있었는데, 최근 이슈가 되고 있는 HTML5에 대한 열린 세미나에 참석할 기회가 생겼습니다.

사실 기술 세미나는 잘 참석하지 않는 편인데, 요번 세미나 및 뒷풀이를 통해 재밌는 이야기를 많이 해볼 수 있었던 것 같습니다.

제가 이해한 내용, 그리고 사석에서 이야기 해봤던 내용은 다음과 같습니다. 다만 음주 토크가 좀(?) 있었고, 따로 HTML5에 대해 공부를 해보진 않았기 때문에 잘못된 내용이 있을 수도 있습니다.

좀 더 세분화된 컨텐츠 구조화를 위해 정의된 태그들

html4에서는 문서의 구조화를 위해 heading element(h1 ~ hx) 태그만을 활용할 수 있었습니다. 하지만 html5에서는 문서 컨텐츠의 구조화를 위해 article, aside, header, section 등의 태그가 새롭게 정의되었습니다.

문서 하나에 여러 가지 주제의 글들이 있을 경우 각각을 article로 묶어주고, 그 안에서 독립적인 구조(section, h1~hx)를 가질 수 있는 구조가 되었으므로, 기계 입장에서 조금 더 쉽게 문서를 분석해낼 수 있을 것으로 생각됩니다.

HTML5: 웹을 넘어 앱으로…

구글 애플리케이션, EyeOS, 구글 OS 등에서는 이미 웹을 이용한 애플리케이션의 가능성을 보여주고 있었습니다. HTML5에서는 드래그앤 드롭, Video, Audio, Canvas, Device API 등의 기능을 제공하고 있고, 이를 통해 네이티브 애플리케이션에 버금가는 기능들을 제공할 수 있게 될 것으로 생각됩니다.

열린 세미나에서는 W3C 위젯을 이용한 애플리케이션 개발 데모를 볼 수 있었는데요. 정말 간단하더군요. :)

HTML/CSS로 UI를 구성하고 javascript로 사용자 인터렉션을 구현하고, config.xml을 통해 시작 페이지나 윈도우 사이즈 등을 정의한 뒤 zip으로 묶으면 끝입니다. (사실 확장자를 zip에서 widget으로 바꿔주는 과정이 추가로 필요하긴 합니다.)

사실 어떻게 보면 안드로이드 앱 개발 과정과 크게 달라보이진 않습니다. 참고로 안드로이드 앱 개발 과정은 XML로 UI를 구성하고, JAVA로 사용자 인터렉션을 구현하고 패키징을 하는 과정으로 구성됩니다. Widget을 만드는 방법과 동일하죠? (사실 둘 다 개발툴로 이클립스를 사용하다 보니 더욱더 거기서 거기가 아닐까 싶은데…)

하지만 아무래도 특수하게(그리고 빡빡하게) 정의된 XML보단 아주 유연하게 정의된 HTML 쪽이 진입 장벽이 쉽다고 생각됩니다. 그리고 이미 파이어폭스, 사파리, 오페라 등등 아주 훌륭한 에뮬레이터(?)들이 수없이 존재한다는 점은 큰 장점이죠.

안드로이드에서도 앱(웹?) 스토어를 준비하고 있고, 휴대폰 시장에서도 대동단결하여 W3C Widget을 지원할 예정이라고 하네요.

하지만 그 이면에서 생각해볼만한 문제들…

분명 HTML5는 표현에 머물러있던 HTML4를 확장하기 위해 많은 노력을 하고 있는 것으로 보입니다. 웹을 넘어 앱으로 나아가기 위한 준비에 특히나 초점을 맞추고 있는 것으로 생각되구요.

하지만 조금 생각해봤을 때 몇 가지 생각해볼만한 문제를 발견할 수 있었습니다.

HTML을 통한 Widget 개발은 쉽다. 그런데 소스 노출 문제는 어떻게?

HTML을 통한 widget 개발은 분명 쉬워보입니다. 하지만 zip이라는 아주 범용적인 압축 포멧을 사용하고 있다보니 widget을 소스로 다시 풀어내기도 쉽습니다.

제가 어떤 widget을 개발해서 판매한다고 하면 누군가 제 widget을 압축 해제하고 조금만 수정한다면 무슨 일이 일어날까요?

뒷풀이 자리에서는 이런 내용에 대해 논의해볼 수 있었고, 이런 문제 때문에 digital signature 기능이 새롭게 추가되고 있다는 이야기를 들을 수 있었습니다만 digital signature가 이 문제를 해결할 수 있을 지에 대해서는 조금 더 생각을 해봐야할 것으로 생각됩니다.

Video Tag… Open Codec은 답이 될 수 없는건가?

W3C에서 HTML5 표준화와 관련해서 난항을 겪고 있는 점 중 하나가 Video Tag에 어떤 코덱을 사용해야하는지를 결정하지 못해서라고 들었습니다.

하지만 Video tag를 보니 아래와 같이 fall back을 제공할 수 있는 구조로 되어 있었습니다.

<video width="320" height="240" controls>
  <source src="pr6.mp4"  type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
  <source src="pr6.webm" type='video/webm; codecs="vp8, vorbis"'>
  <source src="pr6.ogv"  type='video/ogg; codecs="theora, vorbis"'>
</video>

다시 말해 Codec 이슈를 open codec으로 해두고, 서비스 프로바이더에서 타겟에 맞춰 알아서 파일들을 제공하면 안될까 하는 생각이 들었습니다.

사실 DMB, DVB 등의 서비스를 지원하는 장치에는 이미 H.264/AVC 코덱이 포함되어 있습니다. 이런 장치들은 이미 하드웨어 코덱을 가지고 있을테므로 (혹은 라이센스된 코덱을 가지고 있을테므로) 이와 링크된 WebView library에서 따로 라이센스를 지불할 필요는 없을거라고 생각됩니다.

OS 위에 올라가는 브라우져라면? 윈도우에서는 DirectShow를 이용하면 됩니다. 맥에서는 퀵타임을 이용하면 됩니다. 리눅스에선 Xine, vlc, gstreamer 등을 이용하면 됩니다. 이렇게 할 경우 미디어 플레이어/Quicktime/Totem 등에 코덱을 설치하게 되면 브라우져에서도 이 코덱으로 인코딩된 영상을 재생할 수 있습니다.

게다가 이 기능을 브라우져 자체에서 제공하는 것이 아니므로 따로 라이센스료를 낼 필요는 없을 것이라 생각되므로 이후 어떤 코덱이 더 많이 사용될 지는 시장의 선택에 맡기면 될 것이라 생각합니다.

WebM 코덱이 많이 사용된다면 WebM 코덱을 지원하는 Consumer Device도 점점 늘어날 것입니다. Ogg Theora도 마찬가지겠죠.

이원석 박사님께서 막차 시간 문제로 일찍 돌아가셔야 했던 관계로 이 이야기를 길게 나누지 못해 조금 아쉬웠네요.

에필로그

하여튼 오랫만에 재밌는 이야기를 나눌 수 있었던 자리였던 것 같습니다. :)

세미나 일정이 이원석 박사님의 출장 일정에 맞춰지기 때문에 다음 일정이 어떻게 될 지는 아직 잘 모른다고 하네요. 다음에도 또 재밌는 이야기들을 나눌 수 있었음 좋겠습니다.

이만 후기 끝!

p.s) 막상 써놓고 보니 제 블로그 제목대로 정말 제 맘대로만 보고 온 것 같네요.

참고 자료

1. Future Web Accessibility: HTML5 Semantic Elements
2. HTML5 articles and sections: what’s the difference?
3. Video on Web – Dive into HTML5
4. 제 2회 열린 세미나 후기

며칠 전 모 사이트를 통해 뭔가를 지르기 위해 인터넷 카드 결제를 시도했다. XecureWeb, nProtect, Ahnlab V3, … 등등 뭐가 뭔지 알 수도 없는 ActiveX들을 설치하기 위해 UAC가 작동했고, ActiveX 하나하나 단계적으로 설치될 때마다 카드 번호, 유효기간, 윈도우 관리자 비밀번호를 입력해야 했다. ^[1]

결국 카드 번호, 유효기간, 윈도우 관리자 비밀번호를 15번이나 입력한 끝에 모든 ActiveX 설치를 끝낼 수 있었지만 난 더이상 결제를 진행할 수가 없었다. nProtect가 64bit 윈도우7에 설치된 인터넷 익스플로러 8을 죽여버렸기 때문이다.

그날 난 보안의 끝을 보았다.

결제를 아예 진행할 수가 없는데, 어떻게 사고가 일어날 수 있단 말인가! 머리가 아프면 머리를 없애면 된다. 손이 아프면 손을 잘라버리면 된다. 세상에 이렇게 간단한 일을 왜 우린 그렇게 고민해왔던 것일까?

어쨌든 결제를 위해 난 Mac OS X에 설치된 Parallel(가상 PC 프로그램)을 실행시켰고, 그 안에 설치된 윈도우 XP를 통해 결제를 진행해야했다. 윈도우가 설치된 PC가 있었음에도 윈도우에서 결제를 진행하지 못해 Mac OS X를 켰고, Mac OS X 안의 Parallel을 실행시킨 뒤, Mac OS X 안의 Parallel 안의 윈도우 XP를 이용해서 결제를 해야했던 것이다.

이런 짜증나는 상황에 대해 tweeter에서 한 마디를 던졌고, 그 tweet에 대해 친구가 내게 물었다.

‘미쿡 쇼핑몰의 카드 결제는 어떻게 생각해? 안전해?’

국내 사이트의 결제 시스템과 해외 사이트의 결제 시스템 어떻게 다를까?

난 ebay.com, radtech.us, …, panic.com 등등 다양한 해외 사이트를 통해 물건/소프트웨어를 구입한 경험이 있다. 이런 사이트들에서 사용하는 결제 시스템은 쉽고 가볍고 간단했으며, 나에게 인터넷 익스플로러 사용을 강요하지도 않았다.

도대체 뭐가 어떻게 다른건지를 비교해보기 위해 국내 사이트의 결제 시스템과 해외 사이트의 결제 시스템에서 요구하는 정보를 비교해보자.

VISA 안심클릭과 해외 일반 카드 결제 시스템을 비교해보면 CVC 비밀번호를 사용하느냐 아니면 VISA 안심 클릭 비밀번호를 사용하느냐 정도의 차이 밖엔 없다.

그렇다고 VISA 안심클릭 비밀번호를 등록하는데 대단한 정보가 필요한 것도 아니다. 해외 일반 카드 결제 시스템에 필요한 정보 외에 주민등록번호 정도가 필요하다.

ISP 결제에 요구되는 것들도 그리 대단한건 없다. 공인인증서와 비슷하다고 볼 수 있는 ISP와 이 ISP 안에 저장된 비밀키를 끄집어내기 위한 비밀번호만 있으면 된다. 카드번호는 ISP 발급시만 입력해주면 된다.^[2]

ISP 발급/재발급도 마찬가지로 크게 대단한 정보가 필요하진 않다. 그냥 카드 정보 정도만 알고 있으면 된다.

휴대폰 결제는 더 간단하다. 휴대폰 번호와 자신이 어떤 사업자로부터 서비스를 받고 있는지에 대한 정보를 알고 있으면 된다.

Paypal 같은 경우는 Paypal account에 등록된 카드 혹은 은행 계좌(Bank account)를 통해 결제하는 시스템이므로 자신의 Paypal ID, Password만을 요구한다.

자 정리해보자.

일반 카드 결제는 카드 정보만을, VISA 안심클릭은 카드 정보 외에 CVC 번호 대신 안심 클릭 비밀번호를 요구한다. 그리고 ISP와 Paypal은 ISP/Paypal ID + Password를 요구한다.

사실 위에 정리된 내용을 바탕으로 봤을 때 ISP를 제외하고는 인터넷 익스플로러 외에서도 결제를 진행하는데 문제가 없어야 한다.^[3]

그럼 도대체 어떤 차이가 있길래 국내 사이트의 결제 시스템은 인터넷 익스플로러에서만 동작하는걸까?

자 지금까지 읽은 내용 만을 생각한다면 VISA 카드를 통해서는 어떤 사이트에서든지 결제를 쉽게 진행할 수 있어야 한다. 하지만 슬프게도 현실은 그렇지 못하다.

자 국내 사이트와 해외 사이트의 결제 시스템이 어떤 식으로 다른지 살펴보자.^[4]

자 우선 암호화 통신과 관련해선 무슨 차이가 있을까?

자 우선 암호화 통신을 위해 사용되는 보안 채널 부분을 살펴보면, 국내 사이트는 XecureWeb, iniSafeWeb 등의 Plugin 기술이 사용되고, 해외 사이트는 브라우져에 구현되어 있는 SSL 프로토콜을 사용한다. (ActiveX^[5] 라고 표현하지 않은 이유는 XecureWeb이 firefox/safari 등의 플러그인으로 제공되기도 하기 때문이다.)

간혹 인터넷 익스플로러 외의 브라우져를 위한 암호화 통신 플러그인을 제공하기도 하지만 뒤에서 얘기하게 될 기타 보안용 ActiveX 때문에 국내 결제 시스템에서는 인터넷 익스플로러에서 밖에 결제를 진행할 수 있다.

간단히 이 둘의 차이를 살펴보면, SSL은 브라우져와 서버 사이에 보안 채널이 형성되어 암호화된 통신을 한다는 것이고, XecureWeb/iniSafeWeb 등은 브라우져와 서버 사이에는 plain text 채널이 형성되고, 플러그인을 통해 암호화된 데이터를 이 plain text 채널을 통해 전송한다는 것이다.

물론 둘 다 암호화된 데이터를 주고 받는다는 것은 동일하다. 하지만 SSL을 사용할 경우 브라우져의 주소 창 등을 통해 암호화된 통신을 한다는 것을 확인할 수 있는 반면 플러그인을 사용할 경우 암호화된 통신을 하는지 안하는지를 확인할 수가 없다.^[6]

플러그인을 사용할 경우 암호화된 통신을 하는지 안하는지를 확인할 수 없다는 점 때문에 사용자들은 피싱과 MITM 공격에 무방비가 될 수 밖에 없다.

하지만 SSL을 사용하는 경우 주소창의 색이 노란색으로 변한다거나 주소창에 인증서의 소유자 이름이 크게 표시되므로 현재 보안 채널을 사용한다는 것을 명확히 확인할 수 있다. 이런 표식이 없다면 피싱 혹은 MITM 공격을 당하고 있는 것으로 간주할 수 있으므로 조금만 조심한다면 이런 공격들로 인한 피해를 피해갈 수 있게 된다.

게다가 SSL 프로토콜은 이미 대부분의 브라우져에 구현되어 있으므로 추가로 플러그인을 설치할 필요 없이 결제를 진행할 수 있다는 장점이 있다.

그럼 결제 창을 표시하는 방법은 뭐가 문제지?

자 다음으로 결제 창을 표시하는 방법을 살펴보면, 국내 결제 시스템의 경우 대게 새 창으로 결제 창을 띄우고 있지만, 해외 결제 시스템의 경우 대체로 사이트 내에 결제 폼을 표시하곤 한다.

사이트 내에서 결제 폼을 표시할 경우 이 결제가 이 사이트 내에서 이루어진다는 것을 명확히 확인할 수 있다는 장점과 함께 앞에서 얘기했던 암호화된 통신을 사용하는지를 확인할 수 있다는 장점이 있다.

하지만 새 창으로 결제 창을 띄울 경우 어떤 사이트에서 띄운 결제창인지를 쉽게 알 수 없는 문제와, 구 버젼의 브라우져에서 피싱에 무방비로 노출되는 문제가 있다.^[7]

프레임을 사용하는 것은 위에서 얘기한 것보다 더 위험하다. 프레임을 사용하면 새 버젼의 브라우져에서도 주소를 확인할 수 없게 된다. 이 페이지가 내가 원했던 사이트에서 제공하는 것인지 피싱 사이트에서 제공하는 것인지, 암호화된 통신을 사용하는지 사용하지 않는 것인지 아무 것도 알 수가 없다.

프레임을 사용하게 되면 보안 문제 외에도 사용성을 떨어뜨린 다는 단점이 있다. 플러그인 설치를 위해 익스플로러의 경고창에서 ‘설치가 차단된 객체 설치’를 선택한 경우를 생각해보자. 이렇게 하면 페이지가 갱신되게 되고, 프레임에서 선언되어 있는 첫 페이지로 이동되게 된다.

이렇게 되면 그 객체 설치 전까지 진행됐던 과정을 다시 반복해야하는 문제가 생길 수 있다.^[8]

그 외엔 어떤 차이가 있는거야? 해외 사이트는 무조건 안전한가?

그런데 지금까지 알아본 내용들만 바탕으로 생각해보면, 카드 정보나 개인정보가 유출될 경우 얼마든지 피해를 입힐 수가 있다는 결론이 나온다. 그럼 이런 피해를 막기 위해 어떤 장치들을 제공하고 있을까?

우선 국내 사이트에서 제공하고 있는 해법으로는 30만원 이상 결제시 공인인증서 사용 의무화가 있고, ^[9] 해외 사이트에서 간간히 사용하는 해법으로는 카드의 결제 주소(Billing address)와 배송지가 다를 경우 거래를 거부하는 것이 있다. (모든 사이트에서 거부하는 건 아니지만 고액 거래시 꽤 안전한 해법이 될 순 있을 것 같다.)

그리고 paypal 같은 경우 이상 징후가 느껴진다고 하면 paypal account를 잠궈버리기도 한다. 사용자를 불편하게 만들기(시스템에 뭔가를 설치하는 것)보다는 사용자의 이상 행동을 분석하는 것이 답이라고 판단한 것 같다.

여기까지만 봐도 실제 거래의 대부분을 차지하는 소액 결제에서는 별 차이가 없는 것으로 보인다.

이제 국내 결제 시스템에서 가장 문제점인 보안 모듈들을 얘기해야할 것 같다. 이 보안 모듈들은 마이크로소프트 윈도우에 설치된 인터넷 익스플로러에서 말고는 결제를 진행할 수 없게 만드는 주범으로 다음과 같은 것들로 구성된다.^[10]

• nProtect: 키 입력을 가로채는 것을 방지
• anti-virus: spyware, virus, 웜 등에 감염되었는지를 검사하고, 이런 것들로 부터 추가적으로 공격당하는 것을 (잠시동안) 최소화하도록 방화벽을 띄움
• 피싱 방지

이런 모듈들과 관련해서 가장 큰 문제는 맥이나 리눅스 등을 위한 보안 모듈은 제공하지 않고 있으면서 이런 보안 모듈의 설치를 거부(혹은 설치가 불가)한 경우 서비스를 제공하지 않는다는 점이다.

이를 보면 자신들에 대한 맹목적인 믿음은 기대하면서도 사용자는 절대 믿지 않는다는 것을 알 수 있다.

시스템을 아무리 잘 관리해도 소용없다. 자신이 관리하는 방화벽/안티 바이러스 프로그램이 있어도 상관없다. 자신들의 솔루션을 꼭 설치해야만 그 결제 시스템을 이용할 수 있도록 만든다.

(우리는 결제시스템을 이용할 때마다, 인터넷 뱅킹을 이용할 때마다 이런 보안 모듈의 광고(로고?)를 봐야하므로 광고를 봐주는 돈을 받아야할 것 같기도 하다.)

그럼 대안은 무엇이 될 수 있을까?

매번 하는 얘기지만 자신들에 대해 맹목적인 믿음을 기대하는 마음의 반 만큼이라도 사용자를 좀 믿어줬음 좋겠다.

물론 해외 결제 시스템이 무조건 편리하고 안전하다는 이야기는 아니다. 하지만 관리자 잘 되고 있는 시스템에도 구지 보안 프로그램을 설치할 것을 강요하고, 보안 프로그램이 설치될 필요가 없는 맥/리눅스에서는 보안 프로그램이 제공되지 않는다는 이유로 서비스 제공을 거부하는 것은 분명 문제라고 생각한다.

내가 생각하는 해법은 다음과 같다.

1. 정말 무지한 사용자를 위해 보안 프로그램을 제공하는 것은 좋다. 대신 충분히 판단이 가능한 사용자들을 위해선 이런 보안 프로그램을 사용할 필요 없이 거래가 가능할 수 있게 해줬음 좋겠다.
2. 그동안 큰 이유없이 사용되어온 XecureWeb/iniSafeWeb 등을 걷어내고, 국제 표준으로 사용되고 있는, 게다가 대부분의 브라우져에 기본으로 구현되어 있기까지한 SSL 프로토콜을 사용해서 서비스를 제공해줬음 좋겠다.
3. 그리고 공인 인증서를 통한 인증만이 아니라 휴대폰 인증 등 플러그인을 사용하지 않아도 되면서 거래를 하는 것이 본인 임을 증명할 수 있는 다양한 방법을 검토해줬음 좋겠다.

누군가에게 맥을 추천했을 때, 누군가에게 리눅스를 추천했을 때, ‘뭐야 그걸론 인터넷 쇼핑도 할 수 없고, 인터넷 뱅킹도 사용할 수 없자나’ 같은 소리를 더 이상 듣지 않는 그런 날이 왔음 좋겠다.

인터넷 쇼핑에 굶주려 있는 내 맥이 굶주림을 채울 수 있는 그 날이 왔음 좋겠다.

1. XecureWeb 등에서 키가 로딩된 상태를 유지하기 위해 프레임을 사용하고 있으며, 이 때문에 페이지가 리프래쉬 되면(ActiveX 설치를 위해 창 위 쪽 경고 메시지에서 ‘차단된 프로그램 설치’를 선택하게 되면) 결제를 시작하는 단계로 이동하며, 폼에 입력했던 정보는 모두 리셋된다. [↩]
2. 카드 정보를 알고 있으면 ISP를 재발급 받는 건 일도 아니고, 카드 정보를 모르더라도 시스템이 장악됐다면 ISP를 빼내는건 문제도 아닐텐데, 이게 왜 안전한건지 난 모르겠다. 오히려 입력할 정보가 적으니 더 위험할 것 같은데… [↩]
3. Visa 안심클릭(3D secure)의 경우는 해외에서도 사용되는 방식으로 해외에서는 크로스 브라우징이 지원된다. [↩]
4. paygate의 결제 모듈은 (인터넷 익스플로러를 사용하지 않을 경우) 해외 결제 시스템과 동일한 특징을 가지고 있으며, 인터넷 익스플로러 외에서도 문제 없이 결제가 진행된다. [↩]
5. ActiveX는 단순화된 버젼의 OLE(Object Linking and Embedding) 2.0, COM(Component Object Model) 인터페이스를 만족시키는 native windows application이다. [↩]
6. 국내 보안 프로그램, 국내 결제 시스템은 언제나 이런 식이다. 자신들을 무조건적으로 믿으라고 강요한다. 자신들의 ActiveX가 시스템을 지켜줄 것이라고 속여, 보안 등급을 낮추게 만들고 관리자 권한으로 브라우져를 띄울 것을 요구한다. [↩]
7. 구버젼의 브라우져에서는 주소창을 숨기는 것이 가능하다. 그렇기 때문에 결제 창을 어떤 사이트에서 띄운 것인지 알 수 없고, 결제 정보가 어디로 전송될지를 예측하기도 쉽지 않다. 게다가 MITM 등으로 가짜 사이트가 보여지고 있다고 하더라도 암호화된 통신을 하는지 안하는지를 알 수 없기 때문에 공격을 당하고 있다는 사실을 알아채기가 쉽지 않다. [↩]
8. 사실 이건 xecureWeb/iniSafeWeb의 동작 방식 때문에 frame을 사용해야 하는 것인데, 그것 때문에 이런 사용성 저하까지 덩달아 나타나고 있다. SSL이라는 아주 훌륭한 대안이 있는데, 이렇게하면서 까지 이런 플러그인을 사용해야하는 이유를 난 도무지 상상할 수가 없다. [↩]
9. 이게 참 뜨거운 감자인데, 관련해선 오픈웹에 있는 포스트들을 읽어보면 좋을 것 같다. [↩]
10. 이런 보안 모듈들을 통해 시스템이 엉망 진창으로 뚤려있다고 하더라도 결제를 안전하게 진행할 수 있게 하겠다는 의도인데, 얼마나 효율적인지에 대해선 난 할 말이 없다.
    [↩]

UNIX를 사용할 때 보안을 위해 가장 먼저 해야하는 행동이 무엇인지 아시나요?

답은 ‘root(슈퍼 관리자) 권한으로 사용하지 않는 것‘ 입니다.

1. 관리자 권한으로 사용하지 않는다면 시스템의 중요한 파일들이 변경될 위험을 최소화할 수 있습니다.
2. 관리자 권한으로 사용하지 않는다면 스니퍼 등은 실행될 수 없습니다.

관리자로 시스템을 사용하는 것은 매우 위험합니다. 그렇기 때문에 irc 등에선 사용자 아이디가 root인 경우 접속을 차단해버리기도 합니다.

관리자로 사용하는 것이 위험하다는 사실은 윈도우에도 동일합니다. 그렇기 때문에 얼마 전 시스템을 윈도우7 기반으로 설치하면서 약간의 불편함을 감수하고 일반 유져 계정을 만들었고, 이 계정을 통해서만 시스템을 사용하기 시작했습니다.

정말 보안에 신경을 쓰고 있는 시스템에선 사용할 수 없는 인터넷 뱅킹!

관리자 권한을 최소한으로 사용하기 위해서는 다음과 같은 불편을 감수해야만 했습니다.

1. 인터넷 뱅킹을 위해 은행 사이트에 접근하면 관리자 권한으로 ActiveX를 설치하기 위해 관리자 비밀번호를 요구합니다.
2. 인터넷 뱅킹을 위해 은행 사이트에 접근하면 관리자 권한으로 ActiveX를 업데이트하기 위해 관리자 비밀번호를 요구합니다.

물론 전 관리자의 비밀번호를 알고 있기 때문에 권한 상승을 통해 아쉽게나마 인터넷 뱅킹을 사용할 수 있었습니다.

하지만 만약 시스템의 보안을 열심히 신경쓰고 있는 어떤 관리자가 있고, 다른 가족들에게는 보안을 위해 일반 유져 권한만을 제공해주는 경우라면 어떨까요? 이 경우 관리자 외에는 인터넷 뱅킹을 사용할 수 없습니다.

재밌죠? 정말 보안에 철저히 신경쓰고 있는 경우에는 사용할 수 없는 인터넷 뱅킹이라니…

보안 등급을 *낮음*으로 설정해주세요?

게다가 관리자로의 권한 상승을 요구하는 것 뿐만이 아닙니다. 대부분의 경우 ‘인터넷 보안 등급을 *낮음*으로 설정해줄 것’을 요구합니다.

아이러니하지 않나요?

보안을 위해 사용된다고 얘기하는 프로그램을 설치하기 위해, 사용하기 위해 인터넷 보안 등급을 낮춰야 하는 상황이라니…

게다가 OS 차원에서 제공하는 보안 기능을 최대화 하기 위해 ‘일반 유져’로 시스템을 사용하고 싶음에도, 이런 보안 기능을 제대로 사용할 수 없게 ‘관리자 권한’으로 시스템을 사용해줄 것을 강요하는 상황이라니…

버그 투성이 브라우져, 버그 투성이 운영체제는 문제가 되지 않습니다.

얼마 전 h은행에서 제공한 iPhone용 app에서는 보안을 위해 jailbreak된 iPhone에서는 해당 app을 사용할 수 없도록 하고 있습니다.

왜 이런 기능은 iPhone을 위해서만 제공하고 있는걸까요?

키보드 보안 프로그램을 설치하기 전에 최소한 윈도우 서비스팩만이라도 최신 버젼을 설치할 것을 요구해야하는 것 아닌가요?

피싱 방지 프로그램, 안티 바이러스 프로그램을 설치하기 전에 버그 투성이의 인터넷 익스플로러 6대신 인터넷 익스플로러 8을 사용할 것은 요구하지는 않는걸까요? ^[1]

인터넷 뱅킹/카드 결제? 윈도우 XP를 쓰세요. 윈도우 7? Vista? 특히나 64bit 윈도우라면 우린 테스트하지 않습니다.

혹시나 64bit용 윈도우 7을 사용하신다면 우리은행 홈페이지에 접속해보시기 바랍니다. 아 그 전에 아직 북마크 하지 않은 사이트가 있다면 미리 북마크해두시기 바랍니다. XecureWeb Updater가 인터넷 익스플로러 8을 죽여버릴것이거든요.

XecureWeb Updater만 문제일까요? 며칠 전 카드 결제를 위해 어떤 사이트에서 권한 상승을 위한 비밀번호를 수십 번이나 입력했지만 결국 전 카드 결제를 더이상 진행할 수 없었습니다. 결국에 nProtect로 인해 인터넷 익스플로러가 죽어버렸거든요.

인터넷에서의 카드 결제를 진행하기 위해 제가 마지막으로 선택한 방법은 Mac OS X에 설치된 Parallel(가상 컴퓨터 프로그램)에서 실행된 윈도우 XP를 사용하는 것이었습니다. 윈도우 7이 아무리 혁신적이면 뭐하나요. 인터넷 뱅킹, 인터넷 카드 결제 뭐 하나 제대로 할 수가 없는데…

아 맞다. 무제한의 Wideband 인터넷이 아니라면 인터넷 뱅킹은 꿈꾸지 마세요.

모두들 알고 있는 사실이겠지만 국내 인터넷 인프라는 매우 훌륭합니다. 집집마다 광랜이 설치되어 있고 Nespot, Wibro 등을 통해 밖에서도 굉장히 빠른 속도로 인터넷을 이용하는 것이 가능합니다.

이런 훌륭한 인프라 덕분에 무거운 플래쉬, 고용량의 ActiveX 설치 파일 등을 전송받는 비용을 무시하고 있는지도 모르겠습니다.

하지만 국내를 벗어나 국내의 인터넷 뱅킹을 사용하기 위해서 지불해야 하는 비용은 절대 저렴하지 않습니다. ActiveX 하나를 다운받는데 수 분을 기다리게 될 수도 있고, 호텔에서 비싼 돈을 주고 구입한 인터넷 사용량을 ActiveX 하나를 다운받기 위해 사용해야할 지도 모릅니다.

그나마 ActiveX 하나를 모두 다운 받지 못하고 내가 구입한 사용량을 넘어설 경우 다시 비싼 돈을 주고 인터넷 사용량을 구매해야합니다. 다운로드는 처음부터 다시 시작될테니 앞에서 낭비된 사용량은 무의미해지겠네요.

아 해외가 아니라더라 iPhone 테터링 등을 통해 인터넷을 사용하는 경우라면 인터넷 뱅킹을 시도하지 마세요. 한 달동안 무료로 사용할 수 있는 용량이 많아보였을지 모르겠지만 이 정도 용량을 사용하는 게 얼마나 간단한 일인지 알게되는데는 많은 시간이 필요하지 않을 겁니다. ;)

병주고 (가짜) 약주고… 언제까지 이래야하는건가요?

보안을 위해 가장 중요한 것들은 하지 못하게 만들고, 그럼으로써 생긴 보안 구멍은 당신들 보안 업체가 막아주겠다? 언제까지 이렇게 병 먼저 주고, 자신들 때문에 생긴 병을 치료하기 위한다는 이름으로 가짜 약을 제공할 셈인가요?

당신들 프로그램을 설치하기 전에는 아무 문제 없던 내 윈도우 7에서 당신들 프로그램을 설치한 후로는 인터넷 익스플로러가 죽어버리고, 블루스크린과 함께 리붓되어버리는 상황이 정말 ‘까마귀 날자 배떨어진 격’인건가요?

당신들이 제공하는 그 프로그램들을 설치하기 위해, 그리고 당신들이 제공하는 그 프로그램을 설치한 덕분에 오늘도 내 윈도우 7은 골병이 들고 있습니다.

덧: ‘인터넷 뱅킹’이란 이름에 오랫동안 속아왔습니다. 생각해보니 국내 금융권에서 제공하는 ‘인터넷 뱅킹’은 ‘인터넷 익스플로러 뱅킹’을 의미한 것이었는데, 이를 ‘인터넷 뱅킹’이라고 착각한 제 무지가 부끄럽습니다.

하긴 7살난 조카가 제 리눅스 데스크탑을 사용해보더니 그러더라구요. 인터넷 어떻게 쓰냐고… 파이어폭스, 사파리로 접근할 수 있는 웹은 인터넷이 아닌걸 이제야 깨달은 제가 부끄럽네요.

1. 구 버젼의 인터넷 익스플로러(IE)가 얼마나 위험한지는 이 글의 각주 1에 링크되어 있는 글을 읽어보시기 바랍니다. [↩]