어제 Daum DNA에서 개최한 ‘API Meetup‘에서 해외 API 산업의 주요 리더 두분이 70여명의 개발자들과 함께 API의 현주소와 다양한 이슈들을 생각해 보는 시간을 가졌습니다.
행사 내용과 발표 자료 Q&A를 간단하게 요약해 봤습니다!
1. API 경제의 진행 사항 – Steven Willmott
– 숫자: 프로그래머블웹닷컴에 11k의 공개 API가 있다지만, 내부 API는 그의 10배로 추정되고 수백만개의 모바일앱의 백엔드를 생각하면(20~30%)라도 백만개에 달한다.
– API는 멀티 플랫폼 기반의 모바일 백엔드, 과거 SOA 시스템의 대체를 위한 B2B, HTML5 기반 웹앱 등의 세 가지에 의해 발전하고 있다.
– API 사용처는 파트너 및 고객 생태계 뿐 아니라 트랜잭션, API as a Business, 내부 혁신 등 다양하게 활용되고 있다.
– API는 원본 데이터를 내부에서 먼저 API로 만들어 사용하고, 이를 고객이 재사용, 파트너에게 공개, 그 이후 모두에게 오픈 API로 내놓는 것이 올바른 사이클이다. (대개 그 반대로 함^^)
– API 분야의 기술적 이슈는 매우 다양하며, 오픈소스와 벤더 사이의 교집합이 이어지고 있고 모든 기술 논의가 초기 단계이므로 누구나 좋은 아이디어가 있으면 참여했으면 한다.
발표 자료 – Progress in the API Economy – April 2014
2. 다음 API 사례 – Channy Yun
– API 산업은 매우 성장하고 있고, 단순히 아마존, 이베이, 구글 같은 웹 2.0 기업 뿐만 아니라 다양한 업체들이 활용을 시작하고 있다.
– 업체 관점에서 다양한 비지니스 기회를 타진해볼 수 있고, 개발자들에게는 견고한 API 설계를 통해 좀 더 재사용성 높은 프로그램 개발이 가능하다.
– API는 먼저 가치있는 서비스를 제공해야 한다. 나에게는 가치 있고, 서드파티에는 부가적인 것
– API 비지니스 모델을 명확하게 설정해야 한다. 20여가지 모델이 있고, API 설계시 비즈모델도 필요
– API는 쉽게 사용할 수 있어야 한다. 개발자들이 읽기 쉽고 개발하기 쉬운 리소스 제공 필요
– API는 외부 개발자 지원이 필요하다. 신뢰를 쌓고 서로 상생하는 모델을 추구해야 한다.
3. 재사용 가능한 API – Mike Amundsen
– 너무 다양하고, 너무 기초적이고, 너무 구현에 시간이 많이 걸리는 API가 많다. API 설계 시 10가지 하지 말아야 할 것을 살펴보자.
1) 프로토콜(혹은 URL)에 너무 의미적 표현을 담지 말고, 요청 결과 메시지에 담아라!
2) 사람이 읽는 문서화 파일에 시간을 들이지 말고, 좀 더 읽기 쉬운 하이퍼미디어를 활용해라!
3) 개발자들이 프로토콜 전문가라고 생각하지 말고, 가급적 SDK나 라이브러리를 제공하라!
4) 나의 객체 모델을 사람들에게 전달하려 하지말고, 결과 메시지 모델로 알려주라!
5) 서비스를 싱글 인스턴스로 설명하지 말고, 추상화된 클래스로 설명하라!
6) 작업 순서를 클라이언트 코드에 담도록 하지 말고, 결과 메시지에 링크로 담아라!
7) 외부 개발자들의 코드에 문제가 생기지 않도록, 호환성 및 신규 기능 분기를 잘해라.
8) 외부 개발자가 계속 코드를 수정하도록 하지 않게, 신규 기능은 Dark release(모르게 출시)해라.
9) 하나가 죽으면 다 죽지 않도록, API 자체도 분산하고 캐싱을 하도록 해라.
10) API가 완벽하도록 운영할거라 생각하지 말고, 확률의 물리 법칙에 따르라.
– 어떤 것은 아주 쉬울지 모르나, 어떤것은 매우 어렵고… 좋은 아이디어를 많이 내야 한다.
4. 주요 Q&A 요약
Q: API 관리 서비스를 하다보면, 국내 SI 같은 커스트마이징 요구를 받지 않나?
A: 그런 요구가 있을 때 마다, 빠르게 기능 구현(Iteration)을 해서 피드백을 받고 하는 절차를 통해 서비스를 일반화 시킨다. 특히 고객들은 무엇을 원하는지 모르는 곳이 많고, 해보면서 기능을 정교하게 설계해야 한다. 만일 특정 업체의 요구만 들어주면, 비용이 많이 들고 사업 기회가 줄어들 수 있다.
Q: 다음이 API 트래픽을 늘리기 위해 하는 일은?
A: 과거에는 무작정 오픈하고 개발자나 학생들에게 매쉬업을 권장하는 일을 했지만, 최근 몇 년 동안은 사내 API를 만들고 이를 제휴사에게 배포하는 일을 주로 하고 있다. 실제 트래픽도 제휴사와 오픈 API가 80:20 법칙을 따른다. 스티븐의 발표대로, 먼저 사내에서 쓰고 파트너에게 주고 오픈하는 라이프사이클을 따라가야 한다.
Q: 3Scale은 API 관리 시스템을 장애에 어떻게 대응하는가?
A: 초기에 오픈 소스인 nginx를 게이트웨이에 두고 API Backend 여러벌을 분산해 왔다. nginx는 좋은 프록시 서버고 필요시 개량해서 사용중인데, 이들이 다른 데이터 센터에도 제공 중으로 다중 백업이 되는 시스템이다. 우리 사무실 건너편에 nginx 사무실이 있어서 도움을 많이 받는다.
Q: API 가격 정책은 어떻게 하는가?
A: API 가격은 단순히 트래픽으로 하는 것 뿐 아니라, 라이센스 수나 개발자 수 등으로 하기도 하고 기능 추가 시 올리기도 한다. API Business Model이라는 PT의 2) Developer pay go 항목을 보면 다양한 가격 책정 정책이 있다.
그 밖에도 많은 질문이 있었고, 행사를 마치고도 한동안 계속 서서 토론을 하였습니다. 앞으로 다음 DNA는 API 서비스 뿐만아니라 API 제공자간의 정보 공유에도 노력하도록 하겠습니다.
Update. 당일 밋업에 참여하신 ZDNet 임유경 기자님께서 왜 우리는 아마존처럼 API 사업 못하지? 라는 좋은 후기 기사를 작성해 주셨습니다. 감사합니다!
※ Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. 본 채널은 광고를 비롯 어떠한 수익도 창출하지 않습니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources. This channel does not monetize via any advertising.)
좋은 글 잘 봤습니다.