인터넷 금융 공개 표준 프로토콜의 여러가지 구조

앞에서 살짜쿵 얘기해 보았던
〈인터넷 금융 서비스 플랫폼 문제의 현실적 대안〉에서 공개 표준 프로토콜을
도입하는 방법에 대해서 조금 더 자세하게 살펴 보겠습니다. 물론,
photon님께서 말씀하신
대로 단기적인 해결책은 우선 현재 돌아가는 형태 안에서 플러그인을
많이 쓰이는 대안 플랫폼들에 포팅하는 것이 되겠습니다. 장기적인 안을
고려하자면 여러 다른 형태도 고려해 봄 직 합니다.

자바스크립트 API로 표준화하기

이 방법은 자바스크립트 API를 “인증서를 확인하라”, “개인 인식 번호를
전송하라”, “송금 확인을 해서 싸인하라” 등의 기초적인 기능을 수행하도록
표준안을 만드는 것입니다. 그러니까, 세션 암호화 등의 밑에 깔리는
것들은 HTTPS를 이용하고, 인증서 확인과 관련된 것을 웹브라우저 플러그인으로
들어가거나 다른 방법으로 자바스크립트의 함수를 호출하는 것으로 해결을 하는
방법입니다. 도식화 하자면, (이 그림은 일반인의 이해를 돕기 위해 과하게
단순화를 한 것이며, 실제 구조를 정확하게 표시한 구조도가 아닙니다.)

대충 모양은 이렇게 나오는데, 예를 들자면
W3C XMLHttpRequest
같이 자바스크립트 오브젝트를 정의하는 형태이면 적당할 듯 합니다.

자바스크립트 API를 그냥 중간전달자로만 활용하기

이 구조는 지금 이니텍과 소프트포럼에서 채택하고 있는 방식과 비슷한
것입니다. 정확히는 이니텍과 소프트포럼은 Active X 오브젝트나
플래시 오브젝트를 대신 경유하고 있지만, 경유하는 과정을 굉장히 단순하게
전달자로만 쓴다는 점에서는 비슷합니다.
원래는 128비트 암호화를 웹브라우저에서 HTTPS로 지원하지 않아서, 암호화를
하려다 보니 이런 형태를 띠게 되었습니다. 이 구조에서는, 자바스크립트
API를 제공하기는 하는데, 거의 의미없이 그냥 전달만 합니다. 안에
전달 받은 곳에 구체적인 프로그램 동작이나 사용자의 행위를 요구하는 것에
대한 정보가 암호화되어 저장됩니다.

이 경우에는 호출하는 방법도 물론 표준화를 해야겠지만, 매우 간단하기 때문에
별로 흉내내는 것도 어렵지는 않아지고 플랫폼에 따라서 선택적으로 취할 수도
있습니다. 자세한 내부 정보의 바이너리 포맷을 정하는 것이 표준화에서 중요한데,
RFC3261 SIP 같이 텍스트
기반의 프로토콜을 채택할 수도 있고,
RFC2138 RADIUS같이
바이너리 프로토콜을 채택할 수도 있습니다.

바닥부터 TCP또는 SSL기반의 프로토콜을 만들기

독일에서 쓰는
HBCI (Home Banking Computer Interface)에서 쓰는 방식입니다.
이 방식에서는 HTTP나
SMTP같이 아예
바닥부터 프로토콜을 새로 만들어 버립니다. 이렇게 되면, 꼭 웹브라우저에 의존할 필요가 없기 때문에,
플랫폼이 GUI 프로그램이 될 수도 있고, 텍스트 콘솔이 될 수도 있고,
웹 브라우저에 들어갈 수도 있고, 심지어 집 현관문에 붙은 인터폰에
들어갈 수도 있습니다. 구조를 보면 대략,

이렇게 볼 수 있습니다. 바닥부터 만드니 만큼 호환성에 대한 테스트가
많이 이뤄져야 하고, 구현 작업에서 전반적인 작업량도 많습니다.

RPC 기반의 프로토콜

네트워크 부분을 신경쓰지 않고 그냥 서버를 호출할 수 있게 RPC
프로토콜을 활용하는 방법입니다. 인터넷을 경유하는 RPC 프로토콜로는
SOAP이나
XMLRPC 같은 것이 많이 쓰입니다.

전체적인 구조는 이렇게, 클라이언트가 호출하는 RPC API를 정하고,
네트워크에서 돌아가는 RPC 클라이언트 – 서버 구간은 기존 표준을
활용하게 됩니다.
Blogger API 같은 것이 대표적인 RPC 기반 표준 API입니다.
SOAP와 XMLRPC 둘 다 밑에 HTTPS를 깔고 들어갈 수 있기 때문에,
암호화 채널에 대해서도 크게 복잡하지 않습니다.

표준 API만 정하고 SDK 제공

이 방법은 아예 프로토콜을 정하지 않고, 금융회사나 보안솔루션회사에서
제공해 주는 SDK(Software Development Kit)를 이용해서 최종
프로그램을 컴파일하는 방식입니다.
여기서 각 SDK의 API를 통일해서 표준 API만 지키면 아무 회사의
SDK라도 사용할 수 있게 하는 것입니다.

실제 예를 찾아보면, IETF Draft 상태인 Diameter API가 그런 비슷한
방법입니다. 이 표준안에서 정의된 API로 Sun과 Toshiba등의 회사에서
SDK를 만들었기 때문에 어느 회사의 라이브러리를 쓰느냐와 상관 없이
그냥 링크를 할 수 있습니다. (Diameter는 범용 표준 인증/과금 프로토콜인데,
TCP와 SCTP위에서 작동하는 바이너리 프로토콜입니다.) 물론, OpenGroup의
SUS (Single UNIX Specifications)도
그런 비슷한 것이긴 하지만, 용도가 좀 다르군요. ^^;

물론, 이렇게 되면, 제공되는 SDK가 네이티브 바이너리인 경우에는
플랫폼의 제약이 매우 심해지겠지만, 자바 클래스 라이브러리이거나
파이썬 모듈 같이 크로스플랫폼 포맷이라면 별 제약이 없을 수도
있습니다.

객관적이지 않은 편견을 드리지 않기 위해서, 각 방식의 장단점에 대해
제 주관적인 의견을 최대한 빼고 쓰려고 노력해서 설명을 해 봤습니다.
^^; 장기적인 대안은 아직 멀리 있는 뜬구름 잡는 얘기이기는 하지만
그래도 독일에서도 어떻게든 공개 표준이 있는 만큼, 우리도 영원히
못할 일은 아닌 듯 싶습니다.