인터넷 금융 서비스 플랫폼 문제의 현실적 대안

요즘 웹 표준에 옹호적인 커뮤니티들에서는 한 법대 교수님의 웹 페이지 국제 표준화를 위한
민원/소송 준비를 무척 반기며 들떠 있습니다. 그 동안에도
웹 표준과 관련된 운동은 몇 번 있기는 했지만, 엉뚱한 사람들
불러다가 토론 한 번하고 끝난다거나, 기업 사이트들의 느리디 느려서
언제 끝날지 모르는 프로젝트의 시작을 떠들썩하게 광고한 것으로
그쳐왔습니다.

이번 소송 준비에서는 그야말로 “끝장을 보겠다”고 선언을 하시고
진행을 하고 있기 때문에, 정말로 뭔가 뚜렷한 변화가 있지 않을까 하고
생각하고 있던 것들 중, 인터넷 금융 서비스에 대한 부분을 글로
옮겨 봅니다.

지금까지의 상황

그 동안에는 마이너 브라우저와 플랫폼에 대한 운동으로 어정쩡한 태도로
시작해서, 어정쩡하게 끝난 프리뱅크 같은 커뮤니티 기반의 움직임도
있었고, 공개소프트웨어 포탈에서
정부 지원으로 진행된
이니텍/경원대학교의 프로젝트 같은 것도 있었습니다.
현재 소비자 인터넷 금융 기술 시장의 거의 대부분을 차지하고 있는
소프트포럼과 이니텍은
해외수출이나 다양한 서버 플랫폼의 지원 등을 위해서
이미 오래 전에 기술적으로는
이미 거의 완성단계인 듯 합니다.

“플러그인 만들어 주세요”의 문제

현재 “웹 페이지 국제 표준화를 위한
민원/소송 준비” 모임에서도 지금까지 다른 운동이나 프로젝트에서
진행해 왔던 것처럼, 플러그인을 다른 플랫폼으로 포팅하는 것을 유도를
하려는 듯 보입니다. 그렇지만, “플러그인을 리눅스로 포팅해 주세요.”
류의 의견으로는 지금 당장의 승리라고 볼 수 있을 지는 몰라도, 또 다시
다른 어쩔 수 없는 마이너 사용자들을 낳을 수 밖에 없습니다.

플래시 기반 플러그인

우선, 플래시로
플러그인을 포팅하는 것에 대해서 논하자면, 플래시는
생각보다 그렇게 공식 지원 플랫폼이 많지 않기 때문에, 또다른 소외를
낳을 수 밖에 없습니다. 즉, 윈도우, 리눅스, 맥 사용자는 전혀 불편함을
느끼지 않을 지 몰라도, FreeBSD, NetBSD 또는 리눅스라도 CPU가
MIPS나
UltraSPARC
같은 것인 경우에는 공식적으로 플래시가 지원되지 않습니다.
또한, 플래시의 가장 큰 문제점은 하드웨어 접근이 어렵다는 점입니다.
인증서 관련 작업은 특성상 비정규 USB 장치까지 접근을 해야하기 때문에,
순수 플래시로는 구현이 어려우며, 특히 전송 채널 암호화 같은 것은
플래시로 반응성이 제대로 나올 수 있을지도 의문입니다.

XPCOM 기반 플러그인과 ABI 문제

그 다음으로, 모질라 계열의 클라이언트 측 API인
XPCOM을 쓰는 플러그인은
우선, 모질라 계열의 브라우저들을 지원할 수는 있겠지만, 결국에는
여러 이유로 네이티브 라이브러리가 들어갈 수 밖에 없습니다. 즉,
플러그인 제작사의 네이티브 라이브러리가 지원되는 플랫폼에 한해서 지원이
가능하기 때문에, 사실상 플랫폼이 굉장히 제한될 수 밖에 없습니다.
오픈소스 플랫폼의 ABI(Application Binary Interface)가 상당히 다양하다는
것이 바로 그 이유입니다. 즉, 주요 오픈소스 운영체제인 Linux,
FreeBSD,
OpenBSD,
NetBSD,
OpenDarwin
만 따져도 벌써 5개인데, 여기에 각각 아키텍처가
6개씩이라고 치면 5*6=30, 그리고 각 플랫폼 별로 호환되지 않는 널리 쓰이는
libc 버전이 3개씩이라고 치면 30*3=90, 게다가 gtk, libX11, libcrypto등의
기타 라이브러리들 중에 5가지 정도의 버전 조합이 널리 쓰인다고 치면
90*5=450. 즉, 플러그인을 배포할 때 무려 450가지 아키텍처와 플랫폼 조합을
배포하고 테스트하고 관리해야 한다는 말이 됩니다. 게다가, 플랫폼 별로
브라우저도 또 3~4가지씩은 있고.. 450가지 중 많이 쓰이는 3가지 정도의 환경만
지원한다고 선언을 하면, 물론 구글 서비스 같은 곳에서는 통하겠지만,
마이너를 왜 차별하냐고 선언한 서비스가 별로 차이나지도 않는 마이너들을
또 다른 조건으로 차별하는 일은 설득력이 별로 없을 것입니다. 수치 산정에
좀 무리를 하긴 했지만, 앞으로 더 희한한 상황이 올 지도 모릅니다.

“플러그인”의 역할

그럼, 플러그인은 과연 무슨 역할을 하는 것일까요. 우선, 가장 기본적으로
오프라인의 사람이 온라인의 이 사람이란 것을 증명하는 “신원 증명” 역할이
가장 주된 것입니다. 또한, SSL/TLS과 비슷한 역할을 수행해서, 다른 사람들이
통신 내용을 중간에서 보지 못하고, 변조하지 못하도록 하는 “채널 암호화”
기능도 지원합니다. 그리고, 송금이나 가입, 대출신청 등의 중요한 작업에서
사용자에게 내용을 확인하게 한 뒤에, 그에 대해서 싸인을 하게 하는
“부인 방지” 기능도 중요합니다. 사실 “신원 증명”이나 “채널 암호화”는 HTTPS 같은 것으로도 충분히 가능하지만, 바로 이 “부인 방지” 때문에 아직도 별도의 플러그인이 필요한 것입니다.

공개 표준 프로토콜

그래서 대안으로 생각할 만한 것은, 공개 표준 프로토콜을 수립하는 것입니다.
즉, 현재와 같은 웹브라우저에서 HTML을 통한 통신이든,
SOAP 같은 표준 RPC 프로토콜이나
별도의 프로토콜을 마련하든간에 플러그인 구현과 전혀 상관 없이, 서버는 서버대로
표준을 지키고, 클라이언트는 클라이언트 대로 표준을 지키면 제대로 서비스를
쓸 수 있도록 하는 것입니다. 우선 이렇게 되면, 굳이 은행이나 보안관련 회사들이
플러그인을 구현해 줄 필요 없이, 표준에만 맞으면 누구든 플러그인을 만들어서
팔아도 되고, 공짜로 줘도 되고, 혼자 써도 되고 여러가지 스스로의 환경에
맞는 선택을 할 수 있게 됩니다. 특히, 오픈소스 클라이언트가 나오면, 사용자가
자기 플랫폼에 맞게 컴파일을 할 수 있기 때문에, 아무리 특이한 플랫폼이
나오더라도 어떻게든 해 볼 수는 있는 여지가 있습니다. 또한, 이로써 얻을 수
있는 다른 이익으로는 똑같은 서버로 같은 기능을 PC외에도 손전화, PDA, 타블렛PC
또는 심지어 인터넷 뱅킹만 되는 전용 단말기까지도 쓸 수 있게 됩니다. 따라서,
인터넷 금융이 좀 더 자유롭고 잠재적인 발전 가능성을 얻게 됩니다.

보안 관점에서의 공개 표준 프로토콜

프로토콜이 공개되는 것에 대해, 일반적인 금융회사의 반응은 아마도 “보안에
취약하지 않겠느냐.”일 것입니다. 그렇지만, 사소한 하나의 보안 사건도
치명적인 금융의 특성상, 오히려 더 프로토콜을 공개해야 할 필요가 있습니다.
즉, 아무리 암호화를 하고 이런 저런 장치를 해 봐야, 결국에는
리버스 엔지니어링이나
스니핑을 통한 추측과 분석을 통해서, 디지털 컴퓨터 상의 구현인 한은
보안 결함은 뭐든 공격을 받을 가능성이 있기 마련입니다. 게다가,
금융 서비스에 대한 공격이라면, 그냥 돈 받고 해외로 도망가는 사람은
법적인 처벌도 신경을 안 쓸 것이기 때문에, 아무리 리버스 엔지니어링으로
불법으로 규정하려고 해도 법적으로 제재할 방법이 없습니다.
그렇지만, 간단하게 정의된 공개 표준 프로토콜은 결국 넓은 전문가
집단에서의 평가를 받을 수가 있으며, 보안적 위험성에 대해서도
어느 정도 위험성을 미리 느끼고 방어를 위한 수단을 공개적으로 여러 겹
마련할 수가 있습니다.

금융 회사로서의 입장

아무리 좋아도, 금융 회사로서는 새로운 시스템의 도입이 쉽지는 않은데,
금융 회사의 입장에서 얻을 수 있는 이득을 예상해 보겠습니다.
우선, 금융 회사는 클라이언트 측 보안 솔루션을 공급하는 회사와
서버측 솔루션을 공급하는 회사를 분리할 수 있는 자유가 생깁니다.
또한, 리눅스 사용자들이 매일같이 지원해달라고 아우성을 쳐도, 표준을
지키니까 표준 프로토콜을 지원하는 클라이언트를 쓰라고 대답하면 되기
때문에, 공짜로 새로운 플랫폼 지원을 얻을 수가 있습니다. 아무래도 더
중요한 것은 보안상 한 회사에 지나치게 의존할 수 밖에 없었던 것을,
공개 프로토콜로 하게 되면 양쪽을 분리해서 생각할 수 있고, 외부에
위탁할 수 있는 방법도 생기므로 보안 감사가 훨씬 더 쉬워집니다.

보안기술회사로서의 입장

보안기술회사도 중요한 당사자로서 손해만 있다면, 이런 움직임에
참여할 수가 없겠지요. 그러나, 보안기술회사라도 공개 표준이 도입되는
것이 나쁘지만은 않습니다. 공개 표준이 도입되면, 포팅이 훨씬 자유로워지기
때문에, 잠재적인 새로운 플랫폼이 늘어납니다. 따라서, 굳이 금융회사의
적극적인 리드가 없더라도 다른 플랫폼으로 포팅해서 그 쪽에서 벌일
수 있는 시장이 확보됩니다. 그리고, 당장에 이런 일이 생기면 서버쪽에서
작업해야 할 것이 꽤 있기 때문에, 프로젝트가 생겨서 좋겠죠. 🙂
물론, 잠재적인 금융사고에 대해 폐쇄적인 프로토콜에서 생기는 문제보다
공개 프로토콜에서 생기는 문제가 발견하기 쉽기 때문에, 미래의 금융사고에
대한 예측가능성 면에서도 유리하다고 볼 수 있습니다.

정부로서의 입장

정부는 계속 늘어나고 있는 MS의 데스크탑 운영체제 점유율에 때문에
외화 유출과, 독점사에 대한 지나친 의존성을 피할 수 있다는 점에서
당연히 여러 플랫폼을 장려하는 것이 더 안전합니다. 또한, 플러그인을
포팅하는 것으로 해결하면, 지속적으로 발생하는 마이너 플랫폼 때문에
이런 저런 민원이 생기고, 제대로 지원하는지 감시 하는 데에 쓰이는
노력을 많이 줄일 수 있겠습니다.

오픈소스 사용자로서의 입장

당연히 좋지 않겠어요? ^^;

제대로 된 보안을 위해

현재 국내 소비자 인터넷 금융 서비스는 사용자들에게 강제로 관리자 권한을
요구해서 바이러스/웜 감염 위험에 노출시키고, 많은 네이티브 소프트웨어 설치를
요구함으로써 중간자 공격에 의한 심각한 보안 위험을 방치하고 있습니다.
게다가, 지원하는 플랫폼을 획일화해서, 한 회사의 독점을 계속 더 촉진시키는
역할까지도 수행하고 있습니다.
한편, 어설픈 키보드 안전 플러그인은 사실상 완벽하게 동작할 수가 없는
것이 자명한데, 사용자에게 마치 안전한 것 같은 인식을 심어줘서 오히려
위험합니다.
결국, 정보의 위치와 흐름을 고려해 볼 때, 해결하는 방법은 비밀번호를 컴퓨터의
통제에서 벗겨내는 방법 밖에 없습니다. USB 장치가 요즘 사용자 권한에게도
많은 기능을 제공하는 쪽으로 발전하고 있는 것을 보면, USB 장치를 통한
적절한 키 관리/사인 등이 결국 좀 더 나은 해결책이 아닐까 합니다.
물론 비싼 장치를 배포해야하는 부담이 있긴 하지만, 사용자들이 하드웨어를
받을 때는 지불하려는 성향이 훨씬 높다는 것을 생각해 보면, 뭐 크게
문제가 되지는 않을 것 같고요. 🙂
USB 장치를 접근하는 것만 허용하면, 어설픈 보안을 하느라 관리자 권한을
요구하는 것이나, 엄청나게 깔아대는 플러그인도 별로 많이 필요가 없어질
것입니다. (드라이버를 깔아야하는 문제는 생기지만요;;)

공개 프로토콜의 시대

이미 Flickr, Amazon같은 인터넷 기반의 서비스 뿐만 아니라,
해외의 큰 규모의 은행들도 API를 공개해서 오픈소스 프로그램에서 쓸 수 있게하고 있습니다.
이제 열만한 것은 열어서, 열린 것들끼리의 카테시안 프러덕트를 최대한
활용하는 다양성의 시대가 되고 있습니다.
온몸을 항상 천으로 똘똘 두르고 있으면, 상처가 곪아도 안 보이고 발견하기도
힘들 뿐더러, 장갑 낀 손으로 다른 사람과 악수하면 사람들과 친해질 수도
없습니다. 어느 정도 얼굴도 보여주고 맨손도 느낄 수 있어야 공기도 통하고
좋겠지요.