[펌] Open API

Web 2.0 이라는 개념이 소개되기 시작하면서 부터, 여기저기서 'Open API'를 얘기하기 시작했다. 해외의 Google이나 Amazon, Ebay, flickr 등은 물론이고 NHN 또는 Daum과 같은 대형 포털에서부터 최근의 더블트랙(미투데이), 오픈마루스튜디오(스프링노트)에 이르기까지 그들이 제공 할 수 있는 모든 서비스들은 REST 방식으로 이미 공개되었거나 계속 공개되고 있는 실정이다.

사실, 이러한 Open API의 개념은 통신(Telecommunication)이라는 폐쇄성 짖은 분야에서 더 일찍이 소개되고 구체적인 플랫폼으로 구현 및 적용되기 시작했다. 이전의 원시적인 회선교환 방식에서 지능망(IN:Intelegent Network) 개념이 도입되면서 망 자체를 Control 할 수 있는 시스템이 필요하게 되었고, 그러한 Control 포인터 시스템들은 다양한 통신 부가 서비스 제공을 가능하게 만들었다. 이러한 시기에 웹이라는 오픈 된 환경으로 많은 사용자들이 몰리게 되고, 그러한 열린 환경에서 통신망 자원을 자유롭게 이용 할 수 있는 개념이 필요하게 된 것이다.

통신망이라는 자원을 소유한 통신망 사업자들은 그들의 망을 더 이상 폐쇄적으로 관리하지 않고, 많은 3rd Party 업체들이 그러한 망 자원을 활용하여 기발한 부가 서비스를 만들고 이익을 창출해서 그 이익을 공유하길 원했다.

Parlay/OSA 표준은 이러한 요구사항에 기인 한 개방형 표준으로 자리잡았으며, 2002년 말에 KT에서 처음으로 상용 플랫폼을 구축하여 Parlay/OSA에 기반한 서비스 환경을 갖추게 된다.

1. Parlay/OSA

Parlay Interface

CORBA 기술을 근간으로 하는 Paraly 규격은 두 가지 시스템으로의 구성을 원칙으로 한다. 내부 통신망 자원과 연동 이슈를 관장하는 Parlay Gateway를 들수 있고, 실제적으로 내부 통신망 자원을 Parlay Gateway와 Parlay라는 규격을 통하여 제어 할 수 있는 로직(서비스)을 포함 한 Parlay Application Server를 들 수 있다.

Parlay 규격에서는 통신망 사업자의 내부와 외부 사이에 Parlay Gateway가 위치하여 그들이 가진 망 자원을 Capability 별로 SCF(Service Control Function) 형태로 보유하여 Parlay 규격으로 개방하고, 외부의 3rd Party 사업자들이 자유롭게 Parlay 규격을 이용하여 통신망 자원을 사용함으로 공동으로 얻게되는 부가 수익을 기대했었다.

이 당시, 외부 사업자들의 형태를 살펴보자.
2002년 이후, 닷컴 버블이 꺼지고 내실있는 웹 문화가 정착되어 가는 시점에서 많은 사용자들이 새로운 이상세계를 Virtualization 한 세상에서 구현하기 위해 웹을 이용해 왔다.
웹이라는 환경으로 수많은 사용자들이 몰려들기 시작하면서, 웹의 근간이 되는 시스템들 자체도 복잡해지고 광범위해지기 시작한다. 웹 시스템을 직접 개발해야 하는 개발자들의 역활도 각 모듈에 맞게 세분화되고 전문화 되어져 간다. (화면을 디자인하는 사람과 비지니스 로직을 개발하는 사람, 인터페이스를 담당하는 사람 등...)

사실 CORBA라는 기술은 이러한 웹 개발자들에게는 생소한 기술이고, 쉽게 접근하기에 용이하지도 않았다.

결국, 웹 기술 기반의 3rd Party 사업자들에게 CORBA 기반의 Parlay 인터페이스를 이용하여 Application Server를 구현하고 그 위에 개방형 서비스를 얹어 사용하라는 것은 너무 무책임 한 권고가 되어버렸다.

실제로 웹 기반 기술을 가진 3rd Party 사업자들이 Parlay 인터페이스로 통신망 자원을 활용한 사례는 국내에서 한 건도 발생하지 않았다.

그렇다면, 이러한 문제를 어떻게 해결해야 할까?
KT의 사례에서 볼 수 있듯이, MSP(Master Service Provider) 모델이 그러한 해답이 될 수 있다.

 

2. TCP/IP 또는 HTTP 기반의 3rd party 연동 규격

Proprietary Interface

통신 기술에 익숙한 MSP는 통신망 사업자들과 실제 서비스들을 제공하려는 SP들 사이에서 중계자 역활을 한다.
MSP의 역활을 다양하게 정의 해 볼수 있겠지만, 가장 포괄적인 의미로 정의 해 보자면 SP들에게는 그들에게 좀 더 쉬운 인터페이스로 통신망 자원을 이용할 수 있게 제공하고, 통신망 사업자들에게는 SP들을 직접 관리하는 수고를 들어주는 Role이 아닐까 한다.

Parlay/OSA 구현 모델에서 보면, Parlay Gateway는 통신망 사업자의 폐쇄망 안으로 들어가고, 외부망으로 통신망 자원을 열어주는 관문국 역활은 Parlay Application Server가 맡게 되는 형태로 변형되었다.

실제, Parlay 인터페이스로 통신망 자원을 활용하는 서비스는 MSP가 구현하여 그들의 Parlay Application Server에 Deploy하고, 그러한 서비스를 외부의 3rd party 사업자들이 MSP에서 정한 연동 규격으로 사용 할 수 있게 함으로써 CORBA 기반 기술에 비해서 좀 더 쉽고 유연한 인터페이스의 제공(TCP/IP or HTTP)과 함께 단위 서비스 형태로 Wrapped 된 서비스 형태를 제공 할 수 있게 된 것이다.

하지만, 웹 기술 기반의 3rd party 사업자들에게는 TCP/IP 규격 또한 CORBA 기술에 비해서 그렇게 용이하게 구현 될 수 있는 기술이 아니었다.
HTTP 규격의 경우, REST와 같은 형태이긴 하지만 통신 서비스의 특성 상 Low Latency Data for the Browser 형태일수 밖에 없기때문에 최종적인 서비스 응답을 받기 위해서 사용했던 응답 메커니즘 또한 3rd party 사업자들이 이해하기에 용이하지 않았다.

이러한 시기에, Parlay/OSA 표준화 그룹은 CORBA 기반의 Parlay 규격이 3rd party 사업자들이 쓰기에는 좀 부담스러운 인터페이스임을 인지하고, 그 기술에 대한 보완재로 SOA 기술 기반의 Parlay X 인터페이스를 발표하기에 이르렀다.

 

3. Parlay X

Parlay X Interface

CORBA 기반의 Parlay 규격에 비해서 통신망 자원을 세세하게 제어 할 수는 없었지만, 단위 서비스 형태의 기본 서비스 기능을 SOA 기반의 Web Service 함수를 호출할 수 있게 함으로써 서비스 구현의 용이성에 초점을 맞추었다고 할 수 있다.
80에 해당하는 실용성에 큰 비중을 두고 20에 해당하는 섬세한 서비스 기능 구현을 포기하는 파레토의 법칙을 따른 셈이다.

하지만, 이미 수많은 사용자들이 몰려들고 새로운 커뮤니티를 형성하며 새로운 형태의 기술들에 열광하고 더 새로운 무언가를 발견하기를 갈망하는 웹 기술의 근황 상, 단순한 통신 서비스 기능만을 이용할 수 있게 정의 한 Parlay X 규격은 웹 기술의 요구사항에 비해서 너무 초라한 기술임에 틀림없다

복잡한 CORBA 기반 기술을 대신 할 만한 Web Service 기반 기술을 이용 할 수 있는 측면에서는 경량화의 잇점을 얻을 수 있었지만, 통신 자원을 Parlay X 규격에서 정의 한 대로 외부 사업자들이 활용하기에는 여전히 난해하며, 구현을 위해 들이는 노력에 비해서 얻을 수 있는 효과가 너무 미비했다.(그 만큼 규격에 정의 된 기능 셋들이 너무 단조로웠다고 할 수 있다.)

4. HTTP/SOAP 기반의 3rd Party 연동 규격

HTTP/SOAP Interface

TCP/IP 또는 HTTP 기반의 3rd party 연동을 통한 서비스 기능 노출은, 쉽게 WSDL을 정의하여 배포함으로 SOA 기반의 Web Service 형태로 호출 할 수 있다.
이렇게 노출되어 진 단위 서비스 형태의 템플릿들은 WSDL을 통해서 Stub 객체를 만들고 그 객체의 특정 함수를 호출만 함으로써 기능 수행을 할 수 있는 유연한 방법을 제공 할 수 있게 되었다.

물론 서비스를 이용하기위해서 SP 관리 및 인증, 과금 등 OSS 및 BSS를 아우르는 3rd party management 기능들도 여러 서비스들이 공통으로 사용할 수 있는 기능들이므로 Web Service 형태로 개방되어져야 한다.

이제는 외부의 3rd party 사업자들은 마음만 먹으면 BPM(Business Process Management) 형태로 Web Service를 조합하여 새로운 Mash-Up 서비스를 개발 할 수 있게 되었다.

사실, 이러한 요구사항을 연유로 기획되어진 플랫폼이 바로 OSAG(Open Service Access Gateway)이다.

기존에는 기능 셋들이 수직적으로 배치되어진 형태로 서비스 로직이 디자인 되었다면, 이제는 그러한 수직적인 로직 배치의 로직들에서 공통되는 기능 셋들을 따로 단위 서비스 화 함으로써 각 서비스는 이전 보다 복잡성을 줄일 수 있고 기능 모듈화를 통한 Loosely coupled 된 형태로의 디자인 모델을 추구하기 시작했다.

하지만, 이런 SOA 기반의 Web Service 호출을 통한 인터페이스 방법도 웹 개발자들에게는 부담스러운 인터페이스 방법이었다.(나중에 안 사실이지만...)
WSDL을 deploy 해야하고 SOAP 규격대로 XML 문서를 Encoding/Decoding 하는 성능 비용 또한 비싸게 지불해야했다.

 

5. REST 기반의 Open API

RESTful Interface

좀더 light-weight 한 인터페이스 모델은 알게 모르게 우리의 곁에서 다가오고 있었다.

해외의 인터넷 대표 기업들인 Google이나 Amazon.com, ebay 등과 국내의 NHN, Daum 등에 이르기까지 그들의 서비스(검색, 광고, 지도, 백과, 온라인 결재 등)들을 Open API 형태로 개방하기 시작 한 것이다.

그들은 이미 HTTP/SOAP 기반의 Open API들을 95% 이상 RESTful 한 방법으로 바꾸고 있다.

사실, REST(Representation State Transfer)는 하나의 추상적인 방법론일 뿐이지, 꼭 준수해야 할 사항을 명시한 표준 규격이 아니다.

만약,  서비스 제공자와 사용자 간 인터페이스 포맷을 JSON(Javascript onotation)으로 사용한다면 HTTP/SOAP 방식의 인터페이스에서 많은 성능 이슈를 불러 일으켰던 XML 문서의 Encoding/Decoding 메커니즘을 완전히 제거 할 수 있는 성능 이점을 얻을 수 있다.

download2.png

0.03MB

download3.png

0.03MB

download1.png

0.03MB

download5.png

0.04MB

download4.png

0.03MB