웹 API로 웹 활용하기

학습 목표

이 유닛을 완료하면 다음을 수행할 수 있습니다.

• 웹 애플리케이션의 인기를 얻고 있는 두 가지 이유를 설명할 수 있습니다.
  
• 웹 API의 일반적인 용례를 제시할 수 있습니다.
  
• API 경제와 API가 가파르게 성장한 이유를 이해할 수 있습니다.
  

판도를 바꾸는 네트워크형 API

API는 동일한 로컬 네트워크의 범위로만 제약되지 않습니다. 개발자와 시민 통합자는 원격 시스템과 기기에서 제공하는 API를 사용할 수도 있습니다. 이는 여러 장소와 데이터 센터에 위치한 비즈니스의 네트워크와 같은 사설 연결이 될 수도, 인터넷과 같은 공용 네트워크가 될 수도 있습니다. 이렇게 방대한 네트워크의 핵심은 API 엔드포인트입니다.

엔드포인트는 전기를 소비하는 기기의 플러그를 꽂아 넣는 콘센트라고 할 수 있습니다.

콘센트에 꽂을 수 있는 기기의 숫자와 종류는 오직 전기 제품 생산자의 상상력과 관련 설비의 수용 능력에 의해서만 제한될 뿐입니다. 이와 마찬가지로 API의 엔드포인트에서 추상화된 데이터를 활용할 수 있는 애플리케이션의 숫자는 개발자의 상상력과 API 공급업체의 인프라의 수용력에 의해서만 제한됩니다.

실제로도 Google이 Google Maps의 API를 공개한 지 얼마 지나지 않아, 수천 명의 서드 파티 개발자가 해당 API를 사용해 Google의 지도 기능을 자신의 앱에 직접 구현했으며 그 결과 독특하고 혁신적인 애플리케이션이 앞다투어 발표된 바가 있습니다. Yelp, Lyft, Tesla처럼 모서리에 Google의 저작권이 표시된 지도를 제공하는 수많은 애플리케이션을 떠올려 보세요.

바로 이런 이유로 인해서 API는 혁신의 엔진이라고 불리기도 합니다. 특히 Integration Trailblazer라면 자신에게 주어진 수많은 API를 마치 서드 파티의 부품처럼 사용하여 새로운 비즈니스 성과를 달성하고 고객 경험을 구축해 나갈 수 있을 것입니다.

API 경제

Google과 같은 공급업체는 호출 횟수나 서비스 등급 분류 방법에 따라서 애플리케이션 개발자에게 API 사용료를 청구할 수 있습니다. 바로 이 지점에서 API 경제의 아이디어가 발현됩니다.

이제 애플리케이션 개발자는 API 사용 비용과 자체 기능 개발 비용을 저울질해야만 합니다. 혹은 API 경제에서 흔히 그러하듯이 개발자는 유사한 서비스를 더욱 저렴한 가격에 제공하는 공급업체를 찾아 나설 수도 있습니다. 가령 Google Maps에는 Here.com과 같은 유수한 경쟁자들이 있습니다.

API 경제를 성장시킨 주역은 개발자 생산성 향상과 보편적 데이터에 대한 갈망을 충족시키고자 치열하게 경쟁하는 서비스 공급업체들이었습니다. API로 호출할 수 있는 다양한 종류의 각 기능(신용 카드 처리, 매핑, 내비게이션, 번역 등)에 대하여 다수의 API 공급업체가 애플리케이션 개발자와 시민 통합자의 관심을 끌기 위해 경쟁을 펼치고 있습니다. 그 결과 API 기반 서비스의 형태로 더욱 다양한 기능이 공급되면서 API 경제는 주로 기성 API를 중심으로 구성된 애플리케이션의 세계로 빠르게 변모하고 있습니다. 최종 솔루션이 더 우수한 구성 가능성을 갖출 수록 다른 API가 제공하는 기능을 유연하게 도입할 수 있으며 이를 바탕으로 비즈니스의 전반적 역량도 강화할 수 있을 것입니다.

API 성장의 과거와 현재

네트워크로 연결할 수 있는 API가 탁월하다고 생각하실 수도 있습니다. 한편으로는 그렇게 대단한 것을 업계에서는 왜 진작 개발하지 못 했느냐고 의문을 가지실 수도 있겠죠. 사실 API는 일찍이 개발되었습니다.

과거에 Unix가 처음 출시되었을 때도 네트워크에 존재하는 다른 기계로부터 비즈니스 로직을 원격으로 호출하는 프로그래머를 흔히 찾아볼 수 있었습니다. RPC라 불리는 원격 프로시저 호출 기술이 사용되었죠.

이왕 전문 용어가 등장했으니 더 본격적으로 살펴볼까요? 시간이 지나면서 RPC는 Network DDE(동적 데이터 교환), CORBA(공통 객체 요구 매개자 구조), 전자 문서 교환(EDI) 등을 비롯한 다른 형태의 원격 데이터 및 기능 요청에 자리를 내주었습니다. 결국은 XML-RPC(또 RPC군요!)가 부상했으며 이는 나중에 XML과 단순 객체 접근 프로토콜(SOAP)을 기반으로 현재 우리가 알고 있는 웹 서비스로 발전했습니다.

새로운 원격 데이터 및 기능 액세스 기술이 출현할 때마다 업계는 드디어 유토피아가 도래했다고 생각했습니다. 하지만 이어서 오늘날 유행하는 웹 API가 등장했으며, 앞서 언급한 것처럼 GET, PUT, POST와 같은 특수 동사를 사용하여 웹 프로토콜(HTTP)에 이미 내장된 기능을 활용하는 API가 출현했습니다. 네, 여러분이 즐겨찾는 웹 사이트를 방문하기 위해 매일 사용하는 그 웹 프로토콜이 맞습니다.

통합의 가능성 있는 미래

과거의 사례를 살펴볼 때 현재의 시스템 통합 방식은 변화를 맞을 때가 되었는지도 모릅니다. 실제로 현재 널리 사용되는 웹 접근법과는 결을 달리하는 두 개의 비교적 새로운 API 기술이 존재하기도 하죠. 하나는 Facebook의 GraphQL이며, 다른 하나는 Google의 gRPC입니다.

현재의 웹 API와 비교했을 때 둘은 고유한 장점을 갖고 있습니다. 예컨대 GraphQL은 소셜 그래프 및 친구, 사진, 직장 등 서로 다른 데이터 항목이 상호 연관된 정보의 미로를 형성하는 방식에 착안하여 개발되었습니다. GraphQL은 데이터 그래프 전체로부터 한 번에 정보를 요청할 수 있게 해줍니다(반면 기존 API가 동일한 결과를 달성하려면 여러 번의 요청을 수행해야 합니다).

반면 gRPC는 또 그 나름의 장점이 있습니다. 이는 데이터를 쌍방향으로 스트리밍할 수 있는 HTTP/2 (HTTP 버전 2)를 활용합니다. gRPC는 HTTP/2를 사용해 API를 스트리밍 API로 만들 수 있습니다. 즉, 데이터를 사용할 수 있게 된 즉시 해당 데이터를 소비하는 애플리케이션에 이를 공급하는 API가 되는 것이죠. 주식 시세를 보여주는 등의 특정한 실시간 애플리케이션의 경우, 이는 기존 API처럼 앱이 새로운 데이터를 끊임없이 확인하도록 강제하여 데이터를 가져오는 것보다 훨씬 효율적인 방식일 것입니다.

같은 개념, 다른 기술

웹 프로토콜, GraphQL, gRPC, 또는 아직 개발되지 않은 새로운 API 접근법이든 결국 네트워크가 가능한 API라는 개념은 비즈니스 기능의 일부를 다른 애플리케이션이 원격으로 처리할 수 있는 네트워킹 가능한 서비스로 전환하는 것입니다. 이를 통해 고객 경험의 일부를 아웃소싱할 수 있죠. 아웃소싱이 가능한 부분(API 경제)이 확장될수록, 자체 역량만으로는 창출하기 어려운 혁신과 새로운 경험을 구현함으로써 여러분이 경쟁자를 앞서나갈 기회 또한 늘어날 것입니다.

하지만 이 기회는 반대 방향으로도 작용합니다. 여러분의 조직은 그 자신과 외부 개발자들에게 어떤 비즈니스 역량을 API 형태의 네트워킹 가능한 서비스로써 제공할 수 있을까요? 이는 말 그대로 수백만 달러짜리 질문입니다. 특히 Integration Trailblazer가 되고자 하는 분들께는 더욱 그렇겠죠!