요 며칠동안 현재 인터넷 뱅킹과 관련된 이슈들을 정리해서 하나의 포스트를 작성하고 있다.

현재 문제점은 보안 채널을 제공하는데 INISafeWeb/XecureWeb 등의 activeX[1] 를 사용한다는 것과 공인인증서(비밀키)를 이용한 서명을 activeX 로만 구현해 놓았다는 것이 아닐까 싶다.

https 를 통해 128bit secure channel 을 구성할 경우 지저분한 프로그램이 깔릴 필요가 없고, 현재 사용 중인 대부분의 브라우져에서 웹페이지를 안전하게 접근하는 것이 가능해진다. 또한 보안채널을 이용할 때와 이용하지 않을 때 모두 동일한 방법을 통해 웹페이지를 코딩하는 것이 가능하기 때문에 웹 개발자/코더 입장에서도 훨씬 편하게 작업할 수 있을 것이다. 게다가 비싼 플러그인도 라이센스할 필요가 없으므로 원가 절감 효과까지 누릴 수 있다.

공인인증서를 이용한 서명의 경우의 경우는 여전히 activeX/plugin 인터페이스가 필요하겠지만 ‘공인인증서를 사용한 전자서명 인터페이스(api)’ 를 표준화 하게 되면, 공인인증서를 사용하는 사이트들을 이용하게 되더라도 각각에 대해 다른 플러그인을 설치할 필요가 없기 때문에 사용자 입장에서 더욱 편리하게 이용할 수 있을 것이다. 또한 플러그인이 할 일은 대폭 줄어들어 비밀키를 읽어 전자서명 하는 용도 정도로만 사용될 뿐이므로 구현 또한 쉬워질 것이라고 생각된다.

SEED 등 전자 서명에 필요한 모든 알고리즘은 openSSL 에 이미 구현되어 있고, 이를 이용하면 UI 정도의 작업만이 필요하게 된다. API 가 표준화 되고, 구현체가 opensource 로도 나오게 되면 멀티 플랫폼을 지원하는 건 시간 문제일 뿐이다.

개발자의 생산성을 비약적으로 향상시킬 방안이 있어도, 그 기술을 쓰는 개발자의 단가가 비싸다는 이유로 기각되곤 한다. 이는 혁신의 상실일뿐더러 기회의 상실이다. ‘보이지 않는 손’의 위업이라 해버리면 그만이지만, 정책이란 이러한 상실을 지키기 위한 것 아니었던가.

from: zdnet - 대한민국 개발자의 우울, 자기 책임론에서 구조 개혁론으로
http://www.zdnet.co.kr/itbiz/column…goodhyun/0,39030292,39161841,00.htm

공인인증서를 이용하기 위한 API 표준화, 그리고 보안 채널을 제공하기 위한 방법으로 https 를 이용하도록 마이그레이션 하는 것 이 두 가지 모두 생산성을 비약적으로 향상시킬 수 있는 방법이고, 더불어 최소한의 비용으로 드라마틱한 접근성 향상을 가져올 수 있는 방법이 될 것이다.

언제까지 이런 ‘혁신의 상실’ 을 반복하고만 있을 것인지 이를 보고 있는 난 너무나 답답하다.

[1] activeX 는 Microsoft Internet Explorer 를 확장시키기 위한 기술로 특정 프로그램을 설치한 뒤 jscript 를 통해 그 프로그램을 조작할 수 있는 방법을 제공하게 된다. 단 Microsoft Windows 에서만 사용이 가능하다.