WAC Network APIs' Trend

2011년 WAC Network API 관련 Global Teaming Project 끝내면서 정리도 할 겸, 어느 기술지에 기고한 기고문을 블로그에도 올립니다. https://www.itfind.or.kr/WZIN/jugidong/1534/file53011-1534.pdf

WAC Network API 기술 동향

kt 유현성

모바일 비즈니스 생태계에서 앱스토어 비즈니스는 제조사, 플랫폼 사업자, 통신사를 막론하고 Value Chain에 속해 있는 모든 Player가 관심을 가지고 추진하고 있는 사업이다. 그만큼 앱스토어 비즈니스는 현재 모바일 비즈니스 생태계에서 주도권을 확보하기 위한 Strategic Point로 여겨져 왔고 이러한 이유로 각 Player들은 앱스토어 비즈니스 역량을 강화하기 위해 노력해왔다. 본 고에서는 이러한 앱스토어 비즈니스 환경에서 글로벌 통신사 및 제조사가 연합하여 결성한 스토어 표준화 사업인 WAC(Wholesales Application Community)의 비즈니스 현황에 대해서 간략히 살펴보고, 최근 WAC이 그 경쟁력을 강화하기 위해 추진하고 있는 Network API 기술 현황과 사업 현황에 대해 소개하고자 한다.

I. 서 론

앱스토어 비즈니스는 플랫폼 주도권을 확보하기 위한 전략적 요충지로 여겨져 왔고, 이러한 이유로 Device 제조사, 플랫폼 사업자, 통신사를 막론하고 Value Chain에 속해 있는 거의 모든 Player가 뛰어들고 있는 격전지이다. 이러한 상황 속에서 각 Player들은 자신의 앱스토어 경쟁력을 강화하기 위해 개발 환경의 편의성, 개발자 수익성 향상, UI/UX 측면에서의 경쟁력 강화를 위해 역량을 집중하고 있는 상황이고 크게는 Web App vs Native App이라는 경쟁 구도와 작게는 애플 앱스토어 vs 안드로이드마켓 경쟁 구도로 시장이 형성되고 있다. 이러한 비즈니스 흐름 속에서 그동안 통신사들은 앱스토어 비즈니스 뿐만 아니라 모바일 컨텐츠 시장 전반에서 점차 소외되어져 왔고 급기야는 그 상황이 심각한 수준에 이르게 되었다. 통신사는 이러한 상황을 타개하기 위한 전략 중 하나로 통신사, Handset 제조사, SW 개발 벤더가 연합한  WAC(Wholesales Application Community)을 결성하여 웹 런타임 기반 앱스토어 표준화 사업을 진행해왔고 그 첫 결실로 2011년 10월 K-Apps라는 이름으로 시장에 첫 발을 내딛였다. 하지만 아직도 앱스토어 시장의 지배적 위치를 차지하고 있는 애플 앱스토어나 안드로이드마켓에 대응하기에는 갈 길이 먼 상황이기 때문에 WAC은 그 경쟁력을 강화하기 위한 차기 전략으로 통신사들의 Network API를 활용할 방안을 모색 중이다.

본 고에서는 최근의 WAC 비즈니스 현황에 대해서 먼저 살펴본 후 WAC이 차기 전략으로 역량을 집중하고 있는 WAC Network API의 기술 현황과 사업 현황을 차례로 살펴보고 WAC이 발전하기 위해 필요한 전략이 무엇인지 고찰해보고자 한다.

 II. WAC 비즈니스 현황

2010년 2월, 스페인 바르셀로나에서 열린 MWC(Mobile World Congress)에서 공식 출범을 알린 WAC은 초기에 24개의 Mobile Network Operator들로 구성되었다. Device fragmentation을 막기 위해 웹 기술 기반의 Open Standard를 표방한 WAC은 2011년 현재 16개사(AT&T, China Mobile, Deutsche Telekom, GSMA, kt, NTT Docomo, Orange, SK Telecom, SMART Communications, Softbank Mobile, Telekom Austria Group, Telecom Italia, Telefonica, Telenor Group, Verizon Wireless, Vodafone)로 구성된 Board of Directors와 Board of Directors Observers 7개사, Operator Members 7개사, Sponsors 3개사, Associates 29개사로 구성된 Open Standard Forum으로 그 세를 확장해왔다. (자세한 Member List는 http://www.wacapps.net/our-members 참조)

2010년 9월 WAC은 기존 Vodafone주도의 JIL(Joint Innovation Lab) 1.2.2 spec 기반의 WAC 1.0 Spec을 발표하고 Vodafone, Telefonica 등 6개 사업자가 WAC 1.0을 상용화하였으나 흥행에 실패했다. 이후 WAC은 곧바로 WAC 2.0 spec 작업에 돌입하였고 WAC 2.0은 JIL 1.2.2 Spec의 subset에 불과했던 WAC 1.0 spec을 버리고 대부분의 spec을 W3C 규격에 기반하여 작성했다. WAC은 스스로 WAC 2.0 규격 중 약 70%는 W3C 규격을 사용하였다고 평가하였고 HTML5의 일부 기능들을 지원하는 WRT(Web RunTime) Core spec과 Device APIs 표준을 새롭게 정의하여 WAC 2.0 규격을 2011년 2월에 최종 발표한 후 Operator On-boarding Process를 발표하여 WAC 2.0 사업에 통신사업자의 참여를 독려했다. 이렇게 WAC 비즈니스가 급물살을 탔던 2010년 말부터 2011년 초까지 한국 사업자들도 WAC에 많은 관심을 가졌고 이 시기에 K-WAC(Korea WAC)이라는 이름으로 WAC 사업을 추진하기 시작하였다. K-WAC은 최근 K-Apps라는 이름으로 그 명칭을 바꾸었고 한국무선인터넷산업연합회(이하 MOIBA : Mobile Internet Business Association)가 주관해왔다. K-Apps는 국내 개발자들이 WAC spec을 이용하여 한국 통신 3사를 대상으로 WAC Application을 배포할 수 있도록 함과 동시에 Global WAC시스템과 연동하여 국내 개발자들이 Global WAC Ecosystem에서 Application 배포를 할 수 있도록 하는 가교 역할을 하는 것을 목표로 추진되어 왔다. 2011년 현재 무료 Application에 한해서 K-Apps가 상용화를 하였고 올 연말까지 유료 Application에 대해서도 유통을 지원하는 기능을 오픈할 예정이다. 그러나 WAC 2.0 기반의 WAC 비즈니스를 상용화한 사업자는 현재까지 K-Apps 뿐이기 때문에 해외 App 수급이나 Global WAC 유통 지원 사업은 아직도 기지개를 키지 못 한 상황으로 볼 수 있다. WAC의 기치였던 Across multiple device and operating system에 더해서 Across operator and country가 더해져야만 그 파급력이 커질 수 있다는 것을 잘 알고 있는 한국 사업자들로서는 좀 더 많은 Operator들이 WAC 2.0 기반의 Application 유통 Business를 상용화하기를 바랄 수 밖에 없기 때문에 WAC2C라는 Task Force를 결성하여 미국, 아시아 사업자를 중심으로 WAC 2.0 상용화에 박차를 가하고 있다.

이렇게 WAC이 시장에 그 모습을 드러내기 위해 준비하는 동안 안드로이드가 급격한 속도로 Ramp-up되었다. 2010년 3분기 Market share가 25.3%였던 안드로이드가 2011년 3분기 Market share 52.5%를 기록하고 있고 그 성장 속도는 가히 놀라울 정도이다. 이러한 안드로이드의 급성장은 WAC에 큰 위협 요소가 될 수 밖에 없는 것이 사실이다. Across multiple device and operating system이라는 WAC의 가치는 각 OS별 Market Share의 격차가 크지 않을 때 그 효과가 발휘될 수 있기 때문이다. 이러한 이유로 유럽사업자들이 WAC 2.0 비즈니스에서 Post WAC 2.0으로 관심을 돌리고 있다. 즉, 안드로이드의 급성장 그리고 그에 따른 유럽사업자들의 WAC 2.0비즈니스로부터의 이탈은 WAC 2.0 활성화에 큰 위협이 되고 있는 상황이다.

위와 같이 WAC 2.0 비즈니스도 그 성공을 확신할 수 없는 환경 속에서 WAC은 그 경쟁력을 강화하고 좀 더 많은 개발자들이 WAC에 관심을 가지도록 하기 위해 WAC Network API 표준을 정의하여 WAC 2.x를 신속히 추진하려고 하고 있다. WAC Ecosystem이 초기에 자리를 잡기 위해서는 좀 더 많은 개발자들이 WAC에 관심을 가지게 하고 더 나아가 WAC Ecosystem과 Relationship을 가지게 하는 것이 시급하다는 것을 잘 알기 때문이라고 볼 수 있다.

III. WAC Network API 기술 현황
 

WAC Network API를 상용화하기 위해 WAC이 그 역량을 집중하고 있는 이유에 대해서 간략히 살펴보았다. 본 장에서는 이러한 배경 속에서 추진되고 있는 WAC Network API의 기술 현황에 대해서 살펴보고자 한다. WAC은 내부적으로 여러 개의 AC(Advisory Council)를 운영하는데 그 중 하나가 WAC Network API AC이다. 각 AC의 의장은 회원사에서 선출하며 AC 멤버들은 해당 기술 분야의 Spec에 대해서 논의하고 조율하는 역할을 하게 된다. 사실 WAC Network API Spec은 개발자 입장에서 보기에는 기존 GSMA OneAPI Spec에 기반하고 있기 때문에 전혀 새로운 것이라고 볼 수는 없다. WAC Network API AC도 OneAPI Spec에 기반하고 있는 단말과 서버간 연동 spec보다는 WAC 시스템과 Operator간의 연동을 위한 Architecture를 정의하는데 집중해왔다. WAC Network API를 동작하게 하기 위한 Architecture가 Centralized된 Architecture로 구성되어 있기 때문이기도 하다. 즉, WAC Network API를 사용하는 모든 Client는 WAC Gateway를 통해서 통신사의 시스템과 연동하는 방식의 Architecture로 구축되고 있다. 그 이유는 WAC Network API를 쓰는 Application이 Single Access Point만을 관리하도록 하게 하기 위해서이다. 예를 들면, 어떤 Application이 각 통신사의 Network API를 호출하기 위해서 Endpoint A(kt), B(skt), C(lgu+)를 여러 개 관리할 필요 없이 WAC Gateway만을 호출하도록 하는 원리이다.

2010년 11월부터 2011년 2월까지 WAC Network API AC에서는 Architecture Focus Group이라는 AC내 소규모 엔지니어가 참여하는 Task Force를 구성해서 WAC Network API End to End Architecture를 설계했다. 여기에서 Target으로한 Network API는 Carrier Billing In App Payment API였다. 실제로 개발자가 가장 필요로 하는 통신사의 API가 Carrier Billing을 지원하는 In App Payment API라는 판단 때문이었다. In App Payment API 사용을 위한 사용자 인증 Interface에는 OAuth 규격이 사용되어졌고 과금 Interface 규격은 GSMA OneAPI의 Payment API 규격 기반으로 작성되었다.

아래 [그림 1]은 WAC Network API Platform의 Conceptual한 개념도이다. Application으로부터 Single Access Point가 되는 WAC Gateway, 개발자가 Item 정보를 등록하고 API Key를 발급받는 절차를 수행하는 WAC DWP(개발자 포털), 개발자와의 정산을 수행하는 WAC Settlement 시스템으로 구성되어있다.

[그림 1. WAC Network API Platform Technical Overview]

그림에서 OpCo는 통신사의 Endpoint가 되는 시스템을 의미하며 일반적으로 통신사가 이미 보유한 SDP(Service Delivery Platform)나 CSG(Common Service Gateway)가 이 역할을 담당하게 된다. 해당 시스템은 WAC Gateway와 연동하여 사용자를 인증하고 과금을 수행한 후 과금 자료를 통신사 내부 정산 시스템에서 처리할 수 있도록 처리할 수 있도록 지원한다. 최종적으로 통신사의 정산 시스템이 WAC 정산 시스템과 연동하여 개발자 정산에 필요한 프로세스를 타게 된다. 각 Node의 기능을 간략히 살펴보면, WAC Gateway는 Application으로부터 In App Payment API 호출이 들어왔을 때 Operator Discovery(가입자의 통신사를 찾는 기능) 기능과 개발자가 등록한 판매 가능한 Item을 조회할 수 있는 Query API를 제공하는 것이다. WAC DWP는 개발자 포털로서 API 사용 권한 발급, Item등록, SDK 다운로드 및 개발자 가이드의 역할을 하게 되고 이렇게 접수된 개발자 정보, Item 정보 등의 Meta Data를 통신사의 시스템으로 Provisioing해주는 역할을 담당하게 된다. 마지막으로 WAC Settlement 시스템은 통신사로부터 과금 이력 자료를 T1 Spec으로 수신 받아 개발자와 정산하는 역할을 담당한다.

WAC Gateway에서 제공되는 실질적인 Payment API는 Charge, Status, List Transaction, Refund API로 구성된다. Charge API는 실제 과금을 요청하는 Interface이고, Status API는 과금 상태 조회, List Transaction API는 과금 이력 조회, Refund API로 환불을 진행할 수 있는 Interface를 제공한다. 여기서 Refund API는 차기 버전에서 제공될 예정이고 나머지 API들은 현재 제공이 확정된 API들이다. 현재 제공되고 있는 규격에 대한 자세한 내용은 WAC Network API Beta Project에서 사용 중인 소셜 코딩 싸이트 Https://github.com에서 User 등록 후 early.access.developer.support@wacapp.net으로 메일을 보내 승인을 받으면 안드로이드용(Java) SDK 사용이 가능하다.

한국 통신사업자들은 위와 같이 구성된 WAC Network API 플랫폼에 연동하기 위해 WAC 2.0과 마찬가지로 K-Apps를 통한 연동을 구상해왔다. 아래 [그림 2]는 현재 WAC Network API Project를 위한 WAC/K-Apps/한국 통신사업자 시스템간의 상관관계에 대해서 High-Level Architecture를 표현한 것이다.

  

[그림 2. WAC Network API를 위한 WAC/K-Apps/한국 통신사간 시스템 연동 구성]

그림에서 보는 바와 같이 K-Apps는 개발자 정보, 어플리케이션 정보 및 Item 정보에 대한 Meta Data를 한국 통신사업자의 플랫폼으로 Provisioning 해주는 역할과 정산 내역을 WAC에 중계하는 역할을 하고 있다. API 호출은 WAC Gateway와 통신사의 Endpoint간에 직접 연동하는 것으로 구성되어 있다. 하지만 이러한 구성은 Interim한 구성으로 WAC 2.0과 마찬가지로 향후 K-Apps가 Network API에 대해서도 직접 개발자 등록을 직접 받게 된다면 역방향의 데이터 Provisioning도 필요하게 되고, 국내 개발자를 대상으로 WAC Network API에 대한 국내 지원 Case를 고려하게 된다면 Regional WAC Gateway(K-Apps내 WAC Gateway 역할을 하는 Node)가 필요할 수도 있다. 향후 Regional WAC Gateway 구축은 다음과 같은 측면에서 고려해볼 만 하다. 지속적으로 추가될 WAC Network API에 대한 효과적 Integration과 국내 개발자 대상 독자적 Network API 사업 추진이라는 두 가지 측면이다. 즉, 향후 추가될 WAC Network API에 대해서 각 통신사별 Adaptation을 하기 보다는 K-Apps내에 Regional WAC Gateway가 국내 통신사에 대한 Backend Integration을 담당하여 좀 더 효과적으로 WAC과 Integration을 할 수 있다는 점과 국내 개발자를 대상으로 독자적인 Network API 사업을 추진이 가능하다는 점에서 충분히 검토가 가능할 것으로 보여진다.

위와 같이 2011년 11월 현재 WAC Network API 기술 현황에 대해서 살펴보았다. 아직은 Beta 규격이고 상용 Product으로서 모든 개발자에게 Release되기 위해서는 WAC 개발자 포털과 SDK의 보완이 필요한 상황이지만 그 작업이 빠르게 진행되고 있으므로 WAC Network API의 기술 현황에 대해서 지속적으로 주목할 필요가 있다.

IV. WAC Network API 사업 현황
 

WAC은 WAC Network API 상용화를 위해 2011년 2월까지 기본 Spec을 설계하였고 이렇게 설계된 기술 규격을 기반으로 WAC Network API Beta 0.1 Project를 2011년 4월부터 시작했다. WAC Network API Beta 0.1 Project는 In App Payment API를 WAC기반 앱스토어뿐만 아니라 안드로이드마켓 등 오픈 마켓 전체에 시범 오픈하는 것을 목표로 AT&T, DT, Telefonica, SMART, Telecom Austria Group, kt, SKT 등 총 10개 사업자가 참여하고 있다. 2011년 10월 필리핀의 SMART가 최초로 상용화하였으며 2011년 12월 현재 Telecom Austria Group의 M-Tel과 독일의 DT, 한국의 kt와 SKT가 WAC NAPI 시스템과 연동을 완료하고 상용화하였다. WAC Network API를 통해 WAC는 Carrier Billing을 위한 Payment Aggregator로 시장에 진입하게 된다. 이는 기존 WAC 2.0까지와는 전혀 별개의 비즈니스를 WAC에서 추진 중이라도 해석될 수 있으나 WAC이 개발자와의 Relationship을 좀 더 신속하게 확보할 수 있는 방향으로 사업의 흐름을 일시적으로 선회한 것으로도 해석할 수 있다. 실제로 유럽사업자들이 WAC 2.0보다는 WAC Network API 비즈니스에 더 큰 관심을 보이고 있는 것도 이러한 이유라고 볼 수 있다. 즉, 아시아 사업자를 중심으로 한 WAC2C로 WAC 2.0 사업 활성화를 모색하고 다른 한편으로는 WAC Network API Beta Project를 통한 Payment Aggregator로서의 시장 진입을 통해 개발자들과의 Relationship을 확보하는 2 Track 사업전략으로 접근하고 있다.

WAC Network API Beta Project는 SMART가 0.1 version으로 이미 상용화하였고 2011년 말과 2012년 초에 걸쳐 다수의 사업자가 상용화할 예정이다. Beta 0.2도 이미 WAC Office 주도로 착수되었다. Beta 0.2에서는 각 통신사별 인증 시나리오를 가져갔던 Beta 0.1과는 달리 통신사별 인증 시나리오를 통일하고 One Click Payment 구현을 통해 In App Payment UX가 좀 더 향상되고 개발자 포털의 기능들이 보강된다. 개발자가 Application으로부터 벌어들이는 수익의 대부분이 In App Payment와 In App Advertisement이라는 점과 통신사만이 가지는 기능이 Carrier Billing이라는 점이 교차되면서 WAC은 이 부분에 집중하고 있는 것이다.

하지만, WAC이 Payment Aggregator로서 시장에 진입해서 성공하는 것도 보장된 것은 아니다. Carrier Billing을 지원하는 대표적인 Payment Aggregator인 BOKU나 BilltoMobile 등이 이미 그 Coverage를 넓히고 있는 상황이기 때문이기도 하거니와 개발자 입장에서는 제공되는 Coverage가 통신사 단위로 접근하는 것보다는 국가 단위로 접근하는 것이 더 매력적이고 궁극적으로는 Global Coverage를 가지는 것이어야만 관심을 가질 것이기 때문이다. WAC이 이러한 숙제를 해결하기 위해서는 Payment API의 UX를 향상시키는 것도 중요하지만 통신사별 Integration 전략보다는 국가 단위의 Integration 전략을 펼쳐야 할 것으로 보여지며 궁극적으로 WAC Membership을 통해 경쟁 상대가 되는 Payment Aggregator들보다 더 넓은 Global Coverage를 제공해야만 할 것이다. 이러한 측면에서 한국 통신 사업자들은 WAC Network API Beta Project에 각 통신사가 개별적으로 참여하기 보다는 K-Apps를 통해 하나의 Unit처럼 WAC Network API를 Integration하는 방향으로 사업에 참가하고 있다고 볼 수 있다. WAC 입장에서도 국가 단위로 Coverage를 넓혀 가는 것이 필요하기 때문에 한국 사업자들이 개별적으로 사업에 참여하는 것보다는 K-Apps를 통해 참여하는 것에 대해 지원하고 있다. 그러나 한국 이외에는 모두 통신사 단위로 Integration 되고 있기 때문에 이 부분은 앞으로 풀어야 될 숙제중의 하나라고 생각된다.

V. 결론

앞서 살펴본 바와 같이 급변하는 모바일 비즈니스 환경 속에서 WAC 역시 시시각각 변하는 비즈니스 환경에 적응하기 위해 전략의 수정과 Roadmap에 대한 변화를 꾀할 수 밖에 없다. 하지만, WAC이 시장에서 자리매김을 하고 성장 발전하는 모습을 보이기 위해서는 WAC 참여사들의 좀 더 적극적인 협업과 좀 더 강력한 WAC의 Leadership이 필요해 보인다. 결국 WAC은 앱스토어 비즈니스에서 후발 주자이거나 아직 경쟁력을 가지지 못하고 있는 통신사와 Handset 제조사가 주도하는 것이기 때문이다. K-Apps가 비록 무료 Application만을 대상으로 WAC 2.0 세계 최초 상용화를 하였지만 WAC이 실질적으로 시장에 첫 발을 내딛였다는 것만으로도 큰 의미를 부여할 수 있을 거라고 생각되며 이를 시작으로 WAC 2.0에 On-Boarding하는 사업자가 점차 늘어나서 WAC이 진정한 Global Application 유통 채널로 면모를 갖추고 WAC Network API를 통해 개발자를 끌어들이는데 속도를 붙여야만 WAC도 앱스토어 비즈니스 시장에서 자리매김을 할 수 있을 거라고 보여진다.

앞으로 WAC Network API는 In App Payment를 시작으로 Call Control, Messaging, Number Provisioning 등 Transactional API와 Anonymous Customer Reference, Location, Device Profile, User Profile등 Informational API로 제공 API를 점진적으로 확대해나갈 계획이다. 다만, 이러한 API들을 Product 수준으로 얼마나 시장에 빨리 내놓을 수 있느냐가 관건이고 만약 개발자들이 WAC Network API에 매력을 느끼고 많이 활용할 때 전체적인 WAC Ecosystem이 형성되고 발전할 수 있을 것으로 생각된다. 아마도 2012년이 WAC이 실질적인 그 가능성을 보여줄 지 아니면 시장에서 외면당할지 판가름되는 중요한 해가 될 것으로 예상된다.

 

<참 고 문 헌>

[1]    WAC Developer Website, http://www.wacapps.net

[2]    WAC Member Site, https://members.wholesaleappcommunity.com/redmine  

[3]    GSMA OneAPI Home, https://gsma.securespsite.com/access/Access%20API%20Wiki/Home.aspx

[4]    WAC Network  API Beta Github, https://github.com

[5]    W3C and WAC alignment document, http://www.w3.org/2010/12/wac-alignment.html