brunch

매거진 보통의 서비스기획 PO 이야기

라이킷 109 댓글 3

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 도그냥 Sep 26. 2021

API는 왜 온라인 서비스의 핵심요소가 되었나

(1) API - Driven은 선택이 아니라 필수다.

도그냥의 Intro : 이번 추석 연휴동안 API-driven 이라는 단어에 빠져서 이것저것 공부하면서 보냈다. 이 부분에 대해서 혼자만 정리한게 아까워서 몇 회에 걸쳐서 브런치에 살짝 공유해보려고 한다. :) API를 만든다는 것은 더이상 선택이 아니라 필수다. 이 조사를 하고 정리를 하면서 기술적인 시각에서 볼 것이 아니라 비즈니스적인 시각으로 프로덕트를 바라보듯이 이해해야한다는 것을 확신했다 :) 한 학기를 투자한 것 처럼 나에게는 어려운 도전이었고 글도 다소 어려운 글일 수 있지만 그 맥락은 굉장히 재밌다는 생각이 들었다.

API의 기본적인 활용 유형

API(Application Programming Interface)란 응용 프로그램을 사용할 수 있도록, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있도록 만든 인터페이스를 뜻한다. API는 소프트웨어 개발과 밀접하게 일해온 사람이라면 너무나 익숙한 단어가 됐지만, 실제 눈에 보이는 UI가 없기 때문에 개발자가 아닌 사람들에게는 IT 업계에서 일하고 있다고 해도 피상적으로만 이해하기 쉬운 영역이다.

source : wishcat.com

보통 많이 사용되는 설명 이미지는 위와 같다. 직접적으로 개발을 수행하는 직군이 아니라면 이 그림만으로는 이해가 되지 않을 수 있다. 하나의 프로그램 2가지 부분으로 나눠서 생각해볼 수 있다. 앱이나 웹의 프론트엔드(frontend)는 데이터에 대한 조회, 수정, 저장, 삭제를 요청하는 클라이언트(client)가 있고, 실제 데이터를 저장하고 있는 데이터베이스를 불러와서 대답을 해주는 하는 서버(server)가 존재한다.

간단한 예시로 DB상의 데이터가 ‘여러가지 색깔의 공’이 있는 커다란 바구니고, ‘바구니에서 파란공이 있는지 찾아서 알려주는 기능’을 서버에서 처리할 수 있게 만들어 두었다고 해보자. 클라이언트에서는 파란공이 있는지 알려달라고 요청하면 서버는 답변을 주어야 한다. 1990년대 후반부터 2000년대 초에는 서버와 클라이언트 개발에 대한 구분이 없었다. 마치 공이 담긴 바구니를 들고 있는 사람과 파란공을 찾는 행위를 1명의 사람이 한다면 우리는 별다른 통신 방법이 필요하지 않은 것과 마찬가지였다. 현재는 사용자가 직접 사용하는 UI를 구성하는 APP과 Web frontend는 클라이언트라는 이름으로 서버와 분리되었다. 때문에 ‘공을 들어 있는 바구니를 들고 있어서 파란공을 찾을 수 있는 사람’, 그리고 ‘파란공 있는지 물어보는 사람’이 다르기에 이 사이에서는 서로 물어보고 답변을 하는 커뮤니케이션이 필요하다. 바로 이 역할을 해주는 것이 API다. 이 글에서는 우리가 흔히 알고 있는 RESTful 방식 외에도 위와 같은 역할을 하는 모든 인터페이스를 범API로 보고 기술하려고 한다.

이러한 API를 개념을 바탕으로 현재는 주고받는 형태나 방식, 통신 방식 등에서 서로 합의를 하는 것이 API 명세서이며, 주는 쪽과 받는 쪽에서는 이러한 약속을 바탕으로 API를 통일시키고 합의하는 작업을 통해서 서로 통신을 주고받는다. 1개의 회사의 내부에서만 API를 사용하는 경우인 Private API의 경우에는 그 규약을 서버 개발자와 클라이언트 개발자만 서로 합의하면 되지만, 외부의 다른 곳에서도 사용하도록 열어주는 Public API의 경우에는 그 규약에 대해서 서로 문서화하여 합의하고 서로를 특정할 수 있도록 key를 발행한다. 그러한 public API중에서도 접속하는 대상에 대한 제약이 없는 경우를 OpenAPI라고 하며, Open API를 운영하는 많은 회사들은 API 규약을 공유하기위해 디벨로퍼 페이지를 만들어두고 있다.

(sorce : 카카오 개발자 페이지)

활용방식으로 나눈 API의 용도

이러한 API는 활용도 측면에서는 API를 통해서 제공되는 형태에 따라서 나눠볼 수 있다. 구글의 프로덕트 매니저인 닐 메타 외 2인의 실리콘밸리의 PM들이 쓴 책인 <IT 좀 아는 사람>(원제 : Swipe to unlock)에서는 API의 제공방식에 따라 3가지 유형인 1)기능API, 2)데이터API, 3)하드웨어API로 나눠서 설명한다. 이 구분을 기반으로 좀 더 이해할 수 있는 형태로 풀어서 작성해보려고 한다.

1) 기능 API : API를 제공하는 대상에게 특정한 클라이언트 프로그램의 기능을 실행시킬 수 있도록 요청하는 API에 해당한다. 실제 활용되는 서비스로 예를 들어보면, 네이버의 간편결제 수단인 N페이를 예로 들 수 있다. 사용자의 입장에서는 ‘쇼핑몰 페이지 -> 네이버페이 버튼 클릭 -> 네이버 페이지 주문페이지 및 결제완료 -> 쇼핑몰의 주문완료 페이지’로 이동되는 프로세스만 눈에 보이지만, 실제 이러한 과정을 위해서는 결제가능 여부를 물어보고, 결제완료 여부를 전달하고, 다시 결제 정보를 수신하는 등의 쇼핑몰사와 네이버 페이간의 여러 개의 기능을 수행하는 API를 통한 처리를 진행한다. 이를 통해서 쇼핑몰은 네이버페이결제가 처리됐음을 확인받고 주문을 완료한다. 이렇게 특정한 ‘확인’이나 ‘생성’, ‘삭제’등의 기능을 직접적으로 수행하는 API를 기능 API라고 한다.

(Source : 네이버페이, 네이버페이가 일반 쇼핑몰내에서 통신하는 API의 종류와 순서,)

2) 데이터 API : 데이터API는 이미 보유하고 있는 데이터를 요청한만큼 가공하여 전달하는 API다. 특정한 기능을 수행하기 보다는 원본 데이터를 제공하여 데이터를 전달받은 곳에서 알맞게 가공하여 사용한다. 가장 쉬운 예로는 다양한 앱들에서 어디나 존재하는 날씨정보와 같은 경우가 있다. 날씨 정보는 공공API를 통해서 기상청에서 가지고 있는 날씨 데이터를 가져와서 각각 앱에 적합한 형태로 노출시키는 방법이다. 사실상 모든 API는 데이터나 이미지 URL 등 데이터 정보를 파일로 전달받으나, 그 활용 목적 자체가 데이터에 있기에 데이터 API라고 구분한다.

3) 하드웨어 API : 이름 그대로 하드웨어를 제어하거나 하드웨어로부터 데이터를 받는 API를 의미한다. 다른 두 API가 보통 web을 기반으로 한다면, 이 API 유형은 실물 디바이스나 센서와의 연결을 위한 형태로 가장 오래된 형태다. 모바일 환경에서는 OS인 안드로이드, ios 시스템을 통해서 디바이스에 속해 있는 다양한 센서 기능이 서비스를 풍성하게 해주는 방식으로도 많이 사용된다. GPS나 자이로스코프, 온도 센서, 지문인식 센서, 홍채센서 등 다양한 센서들을 앱 서비스에서 활용하기 위해서는 각각의 디바이스와 통신하는 API가 필요하다. 예를 들어 은행 서비스 앱에서 지문인식 로그인을 호출하기 위해서는 해당 디바이스에서 제공되는 지문인식 센서를 API로 호출하여 실행시키고 또 API를 통해서 센싱 정보를 가져온다. 구글에서는 안드로이드 환경에서 이러한 생체 인식 정보를 통신하는 아키텍쳐를 공유하고 있다.

Source: 구글 안드로이드 소스 https://source.android.google.cn/security/biometric?hl=ko

API-driven 서비스가 비즈니스 핵심이 되기까지

Web2.0 사상과 API의 활성화 과정

API는 운영체제(OS)를 제어하기 위한 프로그램 방식으로 1970년대부터 사용되었지만 2000년에 세일즈포스(Salesforce)가 웹기반의 세일즈 자동화 툴을 상용화한 시점은 지금 대세인 웹기반 API(web-based API)의 사용의 시작으로 본다. 이 후 이베이, 아마존이 각각 2000년과 2002년에 API를 제공하고 페이팔의 결제 서비스 API(2004) 등이 만들어지며 일부 e-commerce의 상품 정보를 공유하거나 2006년 Facebook이 SNS의 글을 게시하는 공유기능을 할 수 있는 API 등이 만들어지면서 일부 활용되기 시작했다. 그리고 지금은 API-based 서비스들이 새로운 소프트웨어 생태계를 만들어갈 정도로 성장했다. 웹기반 API는 이미 너무나 오래되고 익숙한 개념이지만, 웹의 사상적 발전에 따라서 새롭고 다양하게 사용되어 왔다.

2000년대 초 API는 새로운 웹생태계를 만들 수 있는 기반으로 주목받았다. 당시의 대부분의 서비스는 데이터센터에 DB와 서버를 모두 함께 가지고 있었기에 현실적으로는 모놀리틱(Monolithic Architecture)를 채택하고 있었다. 모놀리틱 서비스 내에서는 서버와 클라이언트가 분리되지 않고 모두 서버에서 처리하기 때문에 하나의 서비스 내부에서 API를 활용할 필요가 거의 없다. 아래 Web1.0에서의 도식이 바로 그런 상황에 나타낸다.

Web1.0과 web2.0 , Source: https://blog.api.rakuten.net/

소프트웨어 내부에서의 Private API가 대부분 필요하지 않았는데도 2000년대 초 API가 개발되고 공유된 것에는 ‘Web2.0’의 사상적 영향이 크다. Web2.0이란 개방, 참여, 공유의 정신을 바탕으로 정보가 쌍방향으로 소통하는 웹 기술을 말한다. 국내에서는 위키백과나 블로그, 커뮤니티처럼 사용자가 직접 데이터를 생성하는 참여형태가 Web2.0이라고 주목받았으나, 사실 기술적으로는 더 큰 함의를 가지고 있었다. 즉, 멀리 떨어져 있는 개발자들 간에 정보나 기술이 공유되어 더 많은 소프트웨어가 생산될 수 있는 기반에 대한 고민이 일어났고, 오픈소스 생태계와 API를 통한 정보 공유 기술에 대한 고민들이 일어났다. 서비스적으로는 흩어진 정보들을 모아서 새로운 서비스를 만들 수 있다는 점에서 주목을 받았고, 많은 사람들은 SNS를 기반으로 정보를 모으거나, 커스터마이징 된 포털사이트에서 온갖 정보를 모아서 한 번에 전달하고, 더 나아가면 이커머스에 모아진 상품의 판매 정보를 다시 외부로 공유하는 것에 대한 시도들을 하기 위해서 공개된 Open API를 만들기 시작했다. Public API가 조금씩 확대되어 사용되기 시작한 시기였다.

2010년대 스마트폰이 등장하고 각 OS별 앱(Application) 스토어가 활성화되면서 API는 두 가지 큰 변화와 함께 엄청난 성장을 하게 된다. 첫째, 스마트폰에 설치된 SDK기반의 네이티브 앱 클라이언트와 서버가 서로 분리되면서 구조적으로 API 활용이 늘어나게 되었다. 둘째, 개인 개발자들이 소프트웨어를 만들고 유통할 수 있는 앱스토어 생태계가 생겨나면서 2000년대 초반부터 웹기반의 OpenAPI들을 활용한 수많은 앱들이 탄생하였다. 창의력을 가진 개발자들은 오픈된 API들을 사용하여 새로운 앱들을 만들어내는 매쉬업(Mash-up) 서비스들이 만들어냈다. Web2.0에서 주장했던 소프트웨어가 생성되는 주기가 급격하게 빨라지며, 개발자들 사이에서 서비스를 만들어낼 때 API를 활용하는 형태가 대중화되었다.

2010년대 후반부터 2020년대 초인 지금까지는 소프트웨어 인프라적인 2가지 변화가 일어나고, API는 보조적이고 선택적인 활용대상이 아니라 비즈니스를 선도할 수 있는 위치로 변화하고 있다. 하나는 클라우드 인프라로의 이관이고 두번째로는 MSA의 확산이었다. 이 두가지 변화는 동시에 일어났다.

2000년대 초반에 등장한 SOA(Service-oriented Architecture)에 대한 운동이 일어나면서 소프트웨어를 제공하는 서비스를 단위로 잘라서 제공하자는 개념이 널리 확산되었던 적이 있다. 하지만 이를 위한 인프라에 해당하는 DB와 서버 등을 실제 구현하기에는 비용과 서비스를 분리한다는 기준에 대한 모호함이 있어서 개념으로만 남았었다. 그러나 2010년대 들어서 AWS(Amazon Warehouse Systems)과 같은 클라우드(Cloud)기반으로 인프라와 서버의 사용이 확산되면서 SOA에서 조금 더 서비스 단위가 작고, DB자체를 분리하되 API를 통해서 통신하는 MSA(Microservices Architecture)가 대세가 되기 시작했다. MSA를 채택할 경우 SOA보바도 더욱 서비스간 영향도를 줄여서 더 빠른 서비스 확장과 개선이 가능하다고 보는 것이다. 예를 들어서, 과거 이커머스에서는 주문서비스(checkout service)와 결제 서비스(payment system)이 하나도 되어 있었으면 주문데이터 생성 실패가 생기거나 결제서비스 실패가 생길 때 서로 영향을 주기도 하고, 주문서비스의 시스템을 고치는 것에 결제서비스가 영향을 받기도 했었다. 그러나 MSA를 통해서 DB와 서버까지 모두 분리가 되면 각각 개선을 해도 영향을 주지 않게 된다. 그렇게 되었을 때 각각의 서비스 개선의 속도는 굉장히 빨라진다.

(source ; https://www.xenonstack.com/insights/service-oriented-architecture-vs-microservices)

현재의 소프트웨어 업계에서의 API의 활용이 지금처럼 많아진 이유에 대해서 아래와 같이 요약할 수 있다.

첫째, 모바일 앱과 IaaS를 기반으로 MSA가 활성화 되면서 하나의 서비스가 해체되고 Private API를 사용하여 조립하는 구조가 되었다. 그리고 이러한 연결고리들에서 타사에서 제공하는 다양한 API와 연결할 수 있는 점접도 늘어났다.

둘째, 앱스토어를 통한 따른 소프트웨어 유통 플랫폼이 생겨나고, Web2.0의 사상이 확산되면서 공유된 OpenAPI를 기반으로 빠르게 소프트웨어를 만들어내는 것에 익숙해졌다.

(API 사용할 수 있는 연결점이 많아진 현재의 소프트웨어의 구조. Source: 직접작성)

Web3.0과 API-driven 서비스의 발달

Source : Fabric Ventures

이미 소프트웨어업계에서 API가 공기처럼 익숙한다면, 이제는 API의 진화의 방향을 봐야한다. Web2.0의 API에서 가장 흔한 구조는 RESTful 이라고 불리는 방식으로 Request 시점이 있어야만 작동하는 개념이다. 즉, 실행 시점이 필요하다. 하지만 Web2.0을 넘어선 Web3.0에서는 직접 요청을 할 수 있는 사용자가 없을 때도 AI, ML, IoT 등 다양한 서비스들과 통신하며 데이터를 공유하고 전달받을 수 있는 형태를 필요로 한다. 또한 기존에 비해서 실시간성 정보를 필요로 하며 더욱 즉각적인 소통이 필요해지고 있다. 기존의 request 시점이 없어도 연결된 모든 서비스들에 특정한 변화가 생길 때 즉각적으로 전달받을 수 있는 기술들을 필요로 하고 있다.

예를 들어서 네이버의 ‘알림’ 페이지를 보게 되면 네이버 서비스 내에서 다양하게 분산된 웹툰, 메일, 마이박스, 블로그, 카페 등 다양한 서비스내에서 일어나는 여러가지 시점의 행위 이벤트(Event)가 생기면 알림 페이지 하나로 전달하도록 되어 있다. 과거에는 사람이 ‘새로고침’이라는 행위를 하면 알림리스트를 갱신해서 볼 수 있거나 자동 갱신주기가 있었다면 앞으로의 변화는 누군가 블로그에 댓글을 달거나 좋아요를 눌렀을 때와 같이 사용자의 행위가 없더라도 실시간으로 알림을 줄 수 있어야 한다. 특별히 행위자가 없는 경우도 마찬가지다 쇼핑한 상품의 배송이 시작되거나 할 때나, AI를 통해서 사용자의 취향에 대한 프로파일링이 바뀌어서 적합한 상품을 추천하고자 할 때 알림을 줄 수 있도록 바뀌고 있다. 이러한 변화가 비단 네이버 서비스 내에서만이 아니라 더 많은 서비스들의 연결을 통해서 서비스가 만들어지고 앞으로의 API는 이러한 변화를 감당할 수 있도록 다양한 기술적인 변화와 발전이 예상되고 있다.