API의 이점 알아보기

학습 목표

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

• 추상화를 정의할 수 있습니다.
• API 사용의 이점을 설명할 수 있습니다.
• HTTP 동사와 그 쓰임새를 설명할 수 있습니다.

앞에서 등장한 헬스장의 사업주는 운동 기구를 설치하다가 문득 전력에 관한 표준 사양이 마련되어 있지 않다면 이 과정이 어떻게 되었을지 상상해 봤습니다. 그러면 문제가 될 것은 운동 기구 하나만이 아닐 것입니다. 사업주는 벽면의 배선, 배선을 공유하는 다른 기기, 전기 생산 방식(풍력, 원자력, 화력, 태양광), 심지어 동력원의 위치까지도 고려해야 할 것입니다. 다행히도 사업주는 이런 세부 사항을 고민할 필요 없이 어느 콘센트에든 플러그를 꽂을 수 있습니다.

API는 이와 같은 예측 가능성과 신뢰성을 제공합니다. 또한 구체적 목적과 주어진 상황에 부합하는 연결성을 확보해 주죠. API와의 통합은 쉽게 반복하거나 확장할 수 있습니다. 이렇게 연결이 구축되면 유용한 가치가 서로 교환됩니다. 빗대어 설명하자면 헬스장 사업주는 믿을 수 있는 동력원을 구할 수 있으며, 서비스 공급업체는 전력 소비량을 측정해서 요금을 청구할 수 있게 되는 것입니다.

API 사용의 이점

API를 통해 무궁무진한 기회를 만날 수 있습니다. 소프트웨어, 고객, 개발자, 시민 통합자, 개발자가 API를 통해 누릴 수 있는 이점을 살펴봅시다.

아웃소싱

표준적인 전력 공급과 호환되는 모든 장비(여기서는 운동 기구)는 외부 서비스에 전력을 아웃소싱할 수 있으며 모두 동일한 결과를 반복적으로 얻을 수 있습니다. 그와 마찬가지로 API는 예측 가능하며 표준적인 인터페이스를 통해서 주요 데이터와 기능을 아웃소싱할 수 있도록 합니다. 덕분에 개발자는 보편적이면서도 세밀한 정보를 어떻게 구할 것인지를 고민할 필요 없이 우수한 애플리케이션, 서비스, 고객 경험을 창출하는 데만 집중할 수 있죠.

Google Maps의 표준 인터페이스를 통해 매핑과 위치 정보를 앱으로 가져오는 Lyft의 사례를 생각해 봅시다. 예전에는 택시나 리무진을 호출하는 경우 매핑을 제공하는 서비스가 존재하지 않았습니다. 하지만 Lyft와 같은 차량 호출 서비스는 지도를 활용해 고객 경험을 향상시킬 수 있다는 것을 알아차렸습니다.

Google Maps의 API 덕분에 Lyft는 애플리케이션에 지도를 어떻게 구현할 것인지를 고민하지 않아도 됩니다. 대신 우수한 차량 공유 경험을 제공하기 위한 비즈니스 과정 그 자체에 집중할 수 있습니다.

Integration Trailblazer가 되려는 분들이라면 탁월한 고객 경험을 창출하기 위해서는 API를 본능적으로 자연스럽게 이용할 수 있어야 합니다. 이와 같은 습관을 조직의 다른 구성원들에게 전파하는 것이 여러분의 몫입니다.

이동성 향상

전력을 소비하는 장치는 어느 콘센트에든 연결할 수 있습니다. 예컨대 플러그, 그와 일치하는 콘센트, 관련 사양이 존재하지 않는다면 헬스장 사업주는 운동 기구를 건물 벽면의 전선에 직접 연결해야 할 것입니다. 이를 위해서는 필요한 도구를 챙겨서 전선을 밖으로 끄집어낸 다음 이어야 할 겁니다. 물론 건물 벽면에서 뻗어 나오는 배선에 대한 정보도 알아야겠죠.

하지만 표준 인터페이스가 있다면 기구를 쉽게 옮길 수 있습니다. (소프트웨어 업그레이드, 새로운 서비스로의 마이그레이션, 데이터 센터 확장을 생각해 보세요.) 인터페이스의 패턴이 바뀌어도 문제가 되지는 않습니다. 예를 들어 북미에서 영국으로 장소를 옮긴다 해도 체계적인 표준이 확립되어 있기 때문에 장비를 쉽게 연결할 수 있습니다.

추상화

헬스장의 예시에서 전기 콘센트는 기저 서비스인 전기의 추상화 계층입니다. 여기서 추상화란 무슨 뜻일까요? 이는 다른 시스템의 세부적인 작동 방식을 숨기는 방법입니다.

120볼트의 교류 전기를 콘센트를 통해 표준적인 방식으로 제공하는 한, 전력 서비스 공급업체는 콘센트 이후에서부터 동력원에 이르는 시스템의 모든 구성 요소를 얼마든지 변경할 수 있습니다. 전기를 소비하는 기기는 해당 변경 사항을 알지 못합니다.

API는 데이터와 제공되는 기능 사이에 존재하는 추상화 계층이자 소스에서 작업을 완료하고 실행하기 위한 논리로서 작용합니다. 다시 말해 사용자의 소프트웨어는 타 시스템으로 연결하는 방법만 알면 되며 타 시스템의 원리를 알 필요가 없습니다.

시스템의 통신이 이뤄지는 인터페이스는 사전에 약속된 표준(전기의 경우 120볼트 교류)을 나타냅니다. 이는 애플리케이션이 서비스를 요청하고 데이터와 기능(지도 디스플레이 등)을 수신할 수 있도록 합니다. 모든 API는 사전에 약속된 자체적 표준을 갖고 있는데, 이를 API 계약이라고 합니다. API를 의도한 환경에서 사용할 수 있는 것은 이 계약 덕분입니다.

개발자 생산성 향상

처음부터 모든 코드를 직접 작성하는 프로그래머는 거의 없습니다. API는 기존의 코드 베이스를 언제 어디에서든 사용하도록 설계되어 있으며 이를 다시 만들어 쓰지 않습니다. 기존 코드를 재사용하면 애플리케이션이 서로 차별화되기가 어려워지겠지만, 프로그램은 API를 참조(흔히 API를 '호출'한다고 표현)함으로써 원하는 데이터와 기능을 제공받을 수 있습니다. API는 일반적인 작업은 물론 특수한 작업까지도 처리할 수 있습니다. 덕분에 애플리케이션의 개발 기간은 월간 단위, 심지어는 연간 단위에서부터 주 단위로 대폭 줄어들 수 있습니다.

개발자의 생산성이 이토록 높아진 덕분에 비즈니스는 전례 없는 수준으로 민첩하게 움직일 수 있죠. 비즈니스 혁신을 위한 API 중심 통합에서 학습하셨듯이, 이제는 API 덕분에 새로운 제품과 더 나은 비즈니스를 예전보다 훨씬 짧은 시간 내에 구현할 수 있습니다.

HTTP 프로토콜을 사용해 데이터에 액세스하기

개발자가 애플리케이션을 API에 어떻게 연결해야 한다고 규정하는 규칙과 법률은 없지만 그와 관련된 몇 가지 표준은 마련되어 있습니다. 예를 들어 애플리케이션이 인터넷의 API에 연결할 때 대부분의 API 공급업체는 HTTP(하이퍼텍스트 전송 프로토콜)를 통해서 연결을 지원합니다. 이 프로토콜은 월드 와이드 웹이라고 불리기도 하죠.

스마트폰에 설치된 애플리케이션으로 API를 호출하든, 웹 브라우저를 통해 현재까지의 칼로리 소모량을 조회하든, 운동 기구의 소프트웨어를 통해 운동 정보를 저장하든, 사용자는 동사라고 하는 특수한 HTTP 명령어 집합을 활용하게 됩니다.

대부분의 경우 서비스 제공자는 소프트웨어가 HTTP 동사를 사용하여 연결할 수 있도록 API 엔드포인트라는 특수 웹 주소를 제공합니다. FitBit의 관련 사례를 살펴보시죠.

GET https://api.fitbit.com/1/user/[user-id]/activities/date/[date].json

FitBit은 우리에게 친숙한 'www' 대신 'api'를 사용하고 있습니다. 여기서 개발자는 GET 명령을 사용해서 애플리케이션에 표시할 정보를 반환하고 있습니다. 이 사례의 엔드포인트에서 예상되는 응답에는 마지막 활동(달리기)과 사용자가 최근 완료한 운동 과제가 포함됩니다.

연결된 러닝 머신이 이 API를 사용하면 사용자에게 유용한 정보를 풍부하게 제공할 수 있게 되는 것입니다! Fitbit API에 GET 요청을 보낸 후 수신한 응답을 아래에서 확인해 봅시다.

API

물론 위의 응답은 사람이 직관적으로 이해하기 힘들며 러닝 머신 사용자에게도 전달되지 않습니다. 해당 정보의 형식은 HTTP와 함께 자주 사용되며 JSON(JAvaScript 개체 표기법)이라고 불리는 또 다른 표준에 따라 변환됩니다. 위의 내용이 아주 전문적으로 보이겠지만, MuleSoft Composer와 같은 새로운 시민 통합 도구를 사용하면 프로그래머가 아닌 사람도 이러한 출력을 활용할 수 있습니다. 이를 통해 시민 통합자는 API의 새로운 활용 방안을 고안하고 그에 따라서 자체적으로 통합을 구축할 수 있게 됩니다. 프로그래머는 위와 같은 응답을 읽고 처리하기 위해서 코드를 작성해야 하겠지만, 비즈니스 관리자 또는 러닝 머신 설계자와 같은 시민 통합자는 마우스를 클릭하기만 하면 됩니다.

러닝 머신 인터페이스

러닝 머신이 응답을 수신하면 사용자는 지금까지의 칼로리 총소모량, 최근의 운동 과제 달성도 등의 정보를 확인할 수 있게 됩니다.

이제 해당 러닝 머신의 사용자 인터페이스 설계자의 입장에서 생각해 봅시다. 위의 그림과는 다른 사용자 인터페이스를 고안할 수 있지 않을까요? 응답을 통해 확보한 다른 데이터를 활용해서 화면을 구성할 수도 있지 않을까요? 당연히 가능할 겁니다. 이처럼 사용자 인터페이스를 유연하게 구성할 수 있다는 것은 API가 제공하는 추상화를 통해 얻을 수 있는 장점 중 하나입니다.

한 가지 더, 애플리케이션은 한 번에 하나의 API만 사용하도록 제한되지 않습니다! 애플리케이션은 여러 API와 API 공급업체를 호출할 수 있습니다. 이러한 복합 애플리케이션은 매시업이라고도 불립니다. 이는 어떤 재료든 포용할 수 있는 레시피와 같아서, 그 가능성은 오직 사용자의 상상력에 의해서만 제한될 뿐입니다.

현재 인터넷으로 수많은 API가 제공되고 있습니다. ProgrammableWeb.com의 최신 집계에 따르면 23,000개 이상의 API가 존재한다고 합니다. 이에 힘입어 소프트웨어 개발자들과 시민 통합 도구를 갖춘 비전문 프로그래머들은 웹을 프로그래밍 가능한 플랫폼으로 변모시켰습니다. 이제 웹은 Windows, Mac, Linux와 같은 기존의 플랫폼보다도 더욱 강력해졌다고 해도 과언이 아닐 것입니다. 이는 다양한 레시피의 개발을 지원하기 위해 언제든 사용할 수 있는 거대한 향신료 선반이 주어진 것과 같습니다. 조직의 비즈니스 절차와 고객 경험을 규격화된 재료를 통해 구축된 매시업의 관점에서 바라보기 시작한다면 API를 통한 비즈니스 혁신을 시작할 수 있을 것입니다!

리소스

• Trailblazer Community: MuleSoft Composer
• Trailhead: Lightning 플랫폼 API 기초