사용자 삽입 이미지
최근 KB국민은행이 액티브X(Active-X)를 전혀 사용하지 않고도 인터넷뱅킹을 쓸 수 있는 시스템을 구현했다. 올 상반기 유행하던 범용실행파일(exe) 형태가 아닌 순수 HTML5로 개발한 것이라 업계의 눈길을 끌었다.

사실 순수 웹표준으로 인터넷뱅킹을 구현하려는 노력은 오래전부터 있어왔다. 한국전자통신연구원(ETRI)를 비롯해 보안업계에서는 HTML5 웹크립토API를 지원하는 웹브라우저에서 별도의 플러그인 없이 전자서명을 할 수 있는 방법을 논의해왔다. 당연히 PKCS(Public-Key Cryptography Standards) 라이브러리를 채택해 암호 기능도 갖췄다. 소프트포럼, 예티소프트 등 전통적인 PKI 업체들이 지난해부터 이 시장에 매진했고 현재 솔루션으로 구현도 마쳤다.

오래전부터 완료됐음에도 불구하고 HTML5 기반 공인인증 시스템이 확산되지 않은 이유는 전자금융거래법때문이다. 동법 제9조에 따르면 금융회사들은 접근매체의 위조나 변조로 발생한 사고로 이용자가 손해를 입을 경우 책임을 져야 한다. 따라서 은행들은 접근매체(공인인증서 등)의 위조나 변조를 막기 위한 방법을 모색했는데, 그것이 개인방화벽, 키보드보안, 백신 등으로 불리는 ‘인터넷보안 3종 세트 프로그램’이다.

이러한 보안프로그램들은 웹표준으로 구현하기가 불가능하다. PC에서 발생하는 이상행위를 잡아야 하니 로컬(사용자PC)에 설치돼야 한다. 따라서 액티브X나 NPAPI, exe처럼 로컬과 웹브라우저를 연결해주는 형태로 설치를 할 수 밖에 없다.
사용자 삽입 이미지

이 상황에서 KB국민은행이 택한 카드는 보안3종세트를 버리는 것이다. 대신 사용자 인증단에서의 보안을 일회용비밀번호(OTP)로 강화했다. 스마트폰과 근거리무선통신(NFC) 기능으로 연동되는 OTP카드를 도입했다. 공격자의 입장에서는 물리적으로 분리가 돼 있고, 혹여나 복제가 가능하다고 치더라도 스마트폰과 연동이 되지 않으므로 보안성도 담보된다.

공인인증서 시스템은 앞서 설명한 것처럼 HTML5로 구현했다. HTML5로도 인증서 발급, 폐기, 암호화 등의 기능을 사용할 수 있다. HTML5에 포함된 웹크립토API가 그 기능을 수행할 수 있기 때문이다.
사용자 삽입 이미지

공인인증서 저장은 웹브라우저에 한다. HTML5 요구사항에 웹브라우저 저장소가 있는데, 여기에 공인인증서를 넣어두고 웹브라우저 내부에서 인증서를 호출해 전자서명을 하는 형태다. 공인인증서가 웹브라우저 안에 있으니 로컬과 연동해주는 프로그램이 당연히 필요가 없다. (혹자는 공인인증서를 은행의 서버에 저장한다고 오해를 하는데, ‘개인키(인증서)’는 양도가 불가능하기 때문에 그런 시스템이 나올 가능성은 없다.)

하지만 아직 완벽한 것은 아니다. 지금 사용되고 있는 공인인증서를 웹브라우저 저장소 규격에 맞춰 복사하는 작업이 필요하다. 이때문에 KB국민은행에서도 공인인증서를 변환하는 프로그램(certconverter)을 제공한다. 변환 프로그램은 공인인증서를 PKCS#12 형태(인증서와 개인키가 결합된)의 인증서로 바꿔준다. 이 때문에 액티브X와 ‘도긴개긴’이라고 평가하는 사용자도 있다.

더 큰 아쉬움은 따로 있다. 웹브라우저 저장소에 보관된 공인인증서는 KB국민은행 인터넷뱅킹에서만 사용할 수 있다. 타 은행이 HTML5 기반 공인인증서 시스템을 도입하더라도 공인인증서를 변환해서 저장하는 절차는 또 겪어야한다. 그리고 아직 웹크립토 워킹그룹에서 SOP(Same Origin Policy)로 인해 문제 해결이 끝나지 않았기 때문에 당분간 이러한 시스템은 유지될 것으로 보인다. 게다가 PC가 바뀌더라도 동일한 절차를 수행해야 한다. 이 시스템은 어디까지나 로컬에 설치된 웹브라우저 저장소에 공인인증서를 보관하는 것에 불과하기 때문이다.

여전히 불편한점이 많음에도 불구하고 KB국민은행의 시도는 칭찬받아 마땅하다. 우선 보안3종세트를 걷어냈다는 점이 가장 크다. 또 스마트OTP 보급에 투자를 아끼지 않는 것도 인정할 만 하다. 현재 KB국민은행은 이달 말까지 10만개 한정으로 발급 수수료를 면제해주고 있다.

2015/09/08 06:00 2015/09/08 06:00

서버와 브라우저, 브라우저와 브라우저간 실시간 양방향 통신을 가능하게 하는 ‘웹소켓’이 최근 웹 시장에 화두로 떠오르고 있다. 미디어의 발달로 인해 웹에서 양방향통신을 요구하는 사용자와 기업이 늘어가고 있기 때문이다.

현재 웹 환경에서 가장 많이 사용되고 있는 HTTP(Hyper Text Transfer Protocol) 방식은 말 그대로 텍스트를 사용자에게 잘 보여주기 위한 통신규격이다. 사용자가 서버로 ‘정보(텍스트)를 보여달라’라고 요청(Request)하면 서버가 해당 정보를 클라이언트(웹브라우저)로 보내는 형태를 띄고 있다.

즉 HTTP 환경에서 웹브라우저는 요청을 보내고 받는 역할만 하게 된다. 이는 웹브라우저가 새로운 정보를 확인하기 위해서는 지속적으로 요청을 보내고 정보를 내려받는, 이른바 새로고침(Half Duprex, 단방향통신)이 필요하다는 의미와 동일하다.

그러나 인터넷서비스가 발전하면서 사용자들은 자신이 원하는 정보를 즉각, 서버에서 알아서 보내주기를 원하게 됐다. 새로운 정보가 나오면 자신에게 즉각 전송할 수 있는 기능과 자신이 필요로 할 때에 정보를 요청할 수 있는 기능, 동적표현 등의 기능이 그것이다.

이에 대해 가장 먼저 답을 내놓은 것은 썬마이크로시스템즈(Sunmicrosystems, 썬)다. 썬이 개발한 자바애플릿(JavaApplet)은 자바머신만 설치돼 있으면 ‘어느정도’의 양방향통신을 가능하도록 했다.

자바애플릿 등장이후, 어도비 플래시, MS 액티브X, 실버라이트 등이 등장했다. 이들은 과거 텍스트로만 이뤄졌던 웹 환경을 크게 성장시킨 원동력이었다. 비록 액티브X는 너무 과도한 사용으로 인해 국내에서 많은 비난을 받고 있지만.

그러나 이들의 가장 큰 문제점은 순수 웹환경이 아니라 별도의 애플리케이션을 웹브라우저에 설치해야 사용이 가능하다. 흔히 말하는 RIA, 플러그인이 필요하다는 의미다.

많은 사람들은 RIA 이후에 등장한 기술이 HTML5라고 알고 있지만, 사실은 에이젝스(Ajax)가 먼저다. 에이잭스는 ‘Non-RIA’방식이 웹에서 할 수 있는 모든것을 보여줬다. 검색엔진에서 추천검색어를 보여주는 것, 웹 지도에서 마우스 스크롤만으로 줌인, 줌아웃 할 수 있는 것등이 사용자가 가장 많이 경험할 수 있는 에이젝스 구현의 예다.

그러나 여기에도 한계는 있다. 에이젝스 자체는 여전히 단방향 통신이기때문에 ‘폴링(polling)’방식을 버릴 수 없었다는 것이다. 즉 서버가 새로운 정보를 습득하면 웹브라우저에 쏴주는 구조가 아니라 웹브라우저가 요청을 하면 서버가 내려주는 방식이라는 의미다. 물론 쿼리를 미리 분석해놨기 때문에 얼핏보면 양방향통신으로 보이긴 한다.



시대는 흐르면서 웹은 점점 더 고도화됐다. 플래시처럼 인터렉티브한 표현이 가능하면서 HTTP처럼 플러그인이 없어도 구동되고, 에이젝스처럼 양방향통신(처럼보이는)이 가능한 기술에 대한 니즈가 나왔다.

이 같은 고민은 HTML5가 등장하면서 한번에 해결됐다. HTML5의 꽃이라고도 불리는 웹소켓이 등장했기 때문이다.

웹소켓은 웹서버와 웹브라우저가 지속적으로 연결된 TCP를 통해 실시간으로 ‘양방향통신’을 할 수 있도록 만든 HTML5의 사양이다.

지금까지 설명했던 통신방법, 기술과 웹소켓의 가장 큰 차이는 프로토콜(접속방식)에 있다고 봐도 무방하다. 웹소켓의 프로토콜은 접속에 HTTP를 활용하지만 접속 이후의 통신은 웹소켓 자체의 프로토콜을 사용한다. 양방향통신이 가능하고 헤더(header)가 작기때문에 웹의 자원도 적게먹는 것도 특징 중 하나다.

양방향통신이 기본적인 기능이기때문에 오랫동안 통신을 유지할 때 가장 큰 위력을 발휘한다. 통신이 연결된 상태라면 언제든지 서버와 클라이언트간 데이터 송수신이 가능하다. 통신시에 지정되는 URL은 http://www.sample.com/과 같은 형식이 아니라 ws://www.sample.com/과 같은 형식이 되는 것도 특징 중 하나다.

모바일과 PC와의 연동도 가능하다. 모바일 웹브라우저에서 전송한 데이터를 PC에서 즉각 받아볼 수 있다.


HTML5 웹소켓 솔루션 업체 ‘카징(Kaazing)’의 존 펠로우스 최고기술책임자는 26일 방한해 “웹소켓을 사용하면 살이있는 웹을 구현할 수 있게 되며, 웹으로 모든 것을 할 수 있다”고 강조했다.

카징은 2007년에 설립된 웹소켓 솔루션 전문업체다. 카징이 보유한 솔루션은 웹소켓을 지원하지 않는 웹브라우저에서도 웹소켓을 사용할 수 있도록 가상화(에뮬레이트) 해주는 것이다.

실제 인터넷익스플로러, 안드로이드폰에서는 웹소켓을 사용할 수 없다. HTML5를 지원한다고 하더라도 웹소켓을 지원하지 않기 때문이다.

펠로우스는 “IE6를 비롯해 모든 브라우저에서 카징 웹소켓 솔루션을 사용할 수 있다”며 “애플의 에어플레이와 같은 기능이 웹소켓으로 구현할 수 있다. 웹에서의 N스크린이 가능하다는 의미”라고 말했다.

웹소켓은 네이티브 앱으로 구동되는 기존의 서비스를 웹으로도 구현할 수 있도록 한다. 홈트레이딩시스템, 경매장, 인터랙티브 SNS 등과 같은 서비스를 프로그램이 아닌 웹으로 구현할 수 있게 된다.

이는 웹소켓이 가진 양방향통신이라는 특성 때문이다. 서버에 새로운 데이터가 올라오면 사용자의 요청이 없어도 내려보낼 수 있고, 사용자의 요청이 들어오면 또 해당되는 데이터를 보여준다.

펠로우스는 “앞으로 웹은 ‘살아있는(Living)’ 존재가 될 것이다. 그 시대가 도래한다면 웹 소켓은 가장 주목받는 기술이 될 것”이라고 전했다.

기업들이 실시간 양방향 데이터 통신이 필요한 경우, 많은 수의 동시 접속자를 수용해야 하는 경우, 브라우저에서 TCP 기반의 통신으로 확장해야 하는 경우, 개발자에게 사용하기 쉬운 API가 필요할 경우, 클라우드 환경이나 웹을 넘어 SOA 로 확장해야 하는 경우에는 HTML5 웹소켓을 고려해보는 것도 좋을 것이다.


2012/04/29 20:20 2012/04/29 20:20


어도비가 주력제품을 플래시 대신 HTML5, 에어(AIR)로 완전히 선회한 모양새입니다. 얼마전 보도됐던 ‘어도비의 모바일플래시 사업 포기’가 바로 그것입니다.

(관련기사 : 굿바이 모바일 플래시…어도비, 결국 포기)

사실 이는 오래전부터 예정돼 있었던 일입니다.

 

유선웹 시장에서도 웹접근성 이슈가 커지면서 객체타입인 플래시 대신 HTML을 기반으로 한 사이트가 속속 등장하고 있고, 전세계 모바일 시장의 절반을 차지하고 있는 아이폰, 아이패드가 플래시를 지원하지 않고 있기 때문입니다.

과거에 비해 입지가 좁아졌다는 의미로 풀이할 수 있습니다.


게다가 보안관계자들도 웹사이트에 플래시를 되도록 사용하지 말라고 권고하고 있습니다. 이는 바로 플래시가 가지고 고질적인 보안문제 때문입니다.

플래시는 매년 몇 차례씩 보안의 취약점을 드러냈습니다. 웹에서 사용되는 플러그인들은 대체로 보안에 취약한 것은 사실이지만 플래시의 경우 매달 한번씩은 보안패치가 진행될 만큼 많은 해커들의 공격을 받아왔습니다.

얼마 전 국내 모 소셜커머스 업체의 해킹사건도 플래시의 취약점을 노린 사건이었죠.

웹사이트에 삽입한 악성 스크립트 중에서는 일부 버전에서 동작 가능한 어도비 플래시 취약점을 통해 추가적인 악성파일을 다운로드 시도하고, 이런 방식을 거쳐 최종 다운로드된 095.exe, 95.exe, 122.exe 악성파일에 PC가 감염되면 정상 시스템 파일인 lpk.dll 파일을 변조해 특정 온라인 게임 계정정보 탈취 등이 이뤄진 것입니다.


이런 이유로 국내외 인터넷서비스 업체들은 플래시를 걷어내기 위한 전략을 내세우고 있습니다. 구글의 경우 플래시를 기반으로 구동되는 유튜브를 HTML5로 변환해 서비스하고, 스위피(Swiffy)라는 ‘플래시->HTML5’ 변환도구도 만들고 있습니다.

네이버의 경우도 가장 최근 개발한 네이버me를 HTML5로 개발하기도 했습니다. 프레젠테이션 파일을 공유할 수 있는 슬라이드쉐어의 경우도 최근 플래시에서 HTML5로 형식을 변경했죠.

모바일 역시 사정은 비슷합니다.

지난해 애플과 어도비가 서로 각을 세우며 대립했던 것을 기억하실겁니다.

지난해 4월 애플 스티브 잡스 의장은 애플 홈페이지에 “애플이 플래시를 거부하는 것은 기술적 문제다. 플래시가 보안상의 기술적 약점을 갖고 있으며 우리는 어도비와 이 문제를 해결하기 위해 노력해 왔으나 제대로 해결되지 못했다. 아이폰과 아이팟, 아이패드에 플래시를 지원함으로써 애플 제품의 신뢰도를 떨어뜨리고 싶지는 않다”고 지적했습니다.

물론 일각에서는 이러한 기술적인 문제보다 ‘어도비’를 싫어하는 스티브 잡스의 의향이 들어간 것으로도 분석하기도 했습니다.

(스티브 잡스가 어도비를 싫어한 이유는 어도비 플래시는 멀티플랫폼이 가능했기 때문입니다)

반대로 어도비의 입장에서는 전세계 스마트폰 시장의 절반가까이를 차지하고 있는 아이폰을 포기하기 힘들었을 것입니다.

그래서 어도비는 여론을 활용하기로 합니다. 어도비는 애플 아이오에스(iOS)가 폐쇄적인 정책을 띄고 있기 때문에 플래시가 탑재되지 못하고 있으므로 다 함께 개방해서 동반성장하자는 의미의 광고를 집행했습니다. 물론 광고에서 애플을 지칭하는 단어는 없었지만 당시 상황을 비춰보면 알 수 있었겠지요.

하지만 아직까지 iOS에서는 플래시가 지원되지 않고 있습니다.

대신 어도비는 구글과의 제휴를 통해 구글 안드로이드에 모바일 플래시 플레이어를 공급합니다.

다만 사용자들의 평은 좋지 않았습니다. ‘플래시 형식의 콘텐츠가 스마트폰에서도 볼 수 있다’ 수준이지 쾌적한 수준은 아니었기 때문입니다. 모바일 플래시 플레이어 자체가 매우 무겁기도 해 스마트폰의 발열이나 과도한 배터리소모도 약점으로 지적됐습니다.

상황이 이렇게 되자 어도비는 모바일 플래시 개발을 포기하기에 이르렀습니다. 안드로이드에만 제공해봤자 경쟁력이 없기 때문입니다.

현재 어도비는 HTML5, 에어에 집중하는 모양새입니다. 지난 8월 HTML5 콘텐츠를 제작할 수 있는 도구인 어도비 엣지(Edge)를 발표하는 가 하면 지난달에는 모바일 하이브리드앱 개발도구인 폰갭(Phonegap)을 인수하고, 웹디자인 도구인 타입킷(Typekit)도 인수했습니다.

어도비의 변화된 전략을 보면 유선, 모바일에서 플래시를 볼 수 있는 날은 그리 많지 않은 느낌입니다
.



2011/11/11 08:06 2011/11/11 08:06


최근 HTML5와 같은 새로운 웹표준이 등장하면서 ‘웹’이 ‘앱’을 대체하게 될 것이라는 이야기가 나오고 있습니다.

- 매킨지 “앱스토어는 하향세로 접어들 것, 이제는 웹을 준비해야”
- 모바일 ‘웹’과 ‘앱’의 경계가 모호해지다
- “모바일 브라우저에서 이런것도?”…모바일웹의 놀라운 진화

이는 HTML5, CSS3와 같이 새로운 웹 기술들이 과거의 웹 기술과는 비교할 수 없을만큼 뛰어난 성능을 가지고 있기 때문이라는 주장입니다.

실제로 해외에선 구글, 국내에서는 다음이 모바일웹에 총력을 다하고 있습니다.

- 다음, 모바일웹 서비스에 총력
- [MWC 2010] 구글, 모바일에 ‘초점’ 맞춘다

그러나 웹이 뛰어나다고 해서 앱이 등한시될 것이라는 생각은 매우 위험하다고 생각됩니다.

‘웹서비스의 퍼포먼스가 앱과 비슷할 정도로 올라갔으니 플랫폼 제한이 없는 웹이 최고!’

이는 철저하게 서비스 프로바이더들의 생각에 불과합니다. 최종사용자들은 기술에는 관심이 없습니다. 어떻게 쓸 수 있느냐가 중요한 것이라는 얘기입니다.

그들의 입장에서는 웹에서 ‘네이트온’을 쓰나 앱에서 ‘네이트온’을 쓰나 같은 사용자경험을 준다면 어디서 쓰든 상관없다는 것입니다.

앱과 웹의 공통점과 차이점을 한번 보도록 하겠습니다.

앱과 웹은 모두 모바일 사용자에게 풍부한 사용자 경험을 주기 위해서 만들어진 서비스들입니다. 차이점은 멀티플랫폼을 지원하느냐(웹), 지원하지 않느냐(앱)의 차이겠지요.

앱의 경우 검색과 설치라는 전제조건이 붙지만 설치만 완료한다면 사용자들은 아이콘을 ‘클릭’하기만 하면 쉽게 사용할 수 있습니다.

웹의 경우도 앱과 크게 다르지 않지만, 매번 브라우저를 통해서 접근해야한다는 점에서 앱보다는 접근성이 떨어지겠죠. (아이폰에서는 웹앱을 바탕화면으로 빼는 기능이 있는 점은 논외로 하겠습니다. 모든 웹서비스가 이를 지원하지는 않기 때문이죠)

물론 기능의 차이도 다소 있는 것은 사실입니다만 앞서 설명한대로 그 간격이 점차 좁아지고 있는 것이 사실입니다.

결론을 내자면 웹과 앱은 인터넷서비스 생태계에 있어서 전혀 중요하지 않습니다. 웹을 쓸 사람은 웹을 쓰고, 앱을 쓸 사람은 앱을 쓰면 되기 때문이죠.

즉, 웹은 앱의 대체제가 아닌 보완제로 봐야합니다. 서로간의 장점을 살릴 수 있는 방법으로 말이죠.

가령 이런식입니다. 웹으로 앱스토어를 구축해 두고, 거기에서 웹 앱과 패키지 앱(설치형 앱)을 모두 유통할 수 있게 하는 것입니다.

웹 앱의 경우는 다운로드나 설치작업이 필요없이, 클릭 즉시 브라우저에서 실행되도록 하고, 패키지 앱의 경우 다운로드를 받을 수 있는 공식적인 채널로 이동시키면 될 것입니다.

결국 웹이든 앱이든 유통할 수 있는 생태계와 최종사용자가 중요하다는 것이지 ‘기술’만 가지고 왈가왈부해서는 답이 나오지 않을 것입니다.

저는 웹이 앱을 모두 대체하는 일은 앞으로도 없을 것이며, 앱스토어 역시 건재할 것이라고 굳게 믿습니다.



2010/11/15 08:48 2010/11/15 08:48