API 이코노미
빠르게 부상하고 있는 API-First 회사들이 비즈니스 생태계를 바꿔놓고 있다
모든 산업은 초기에 선발주자가 완성품에 들어가는 모든 부품을 처음부터 끝까지 직접 생산해야 한다. 소재·부품·장비 등을 공급해주는 하위 업체가 생겨날 만큼 시장이 충분히 크지 않기 때문이다. 하지만 수요가 증가하고 시장이 커지면서 회사에게 공급하는 업체들이 생겨나고, 그 업체에게 더 작은 단위 부품을 공급하는 하위업체가 생겨나는 등 공급망이 세분화되고 정교해진다.
즉 시장이 성장하면서 수익 창출이 가능한 단위가 점점 작아진다. 역사적으로 수많은 산업에서 목격된 패턴이다.
소프트웨어 산업도 마찬가지다. 초기에는 한 회사가 하드웨어와 소프트웨어를 모두 만들어야 했다면, 시간이 지나면서 OS가 하드웨어에서 해체(disaggregate)되어 소프트웨어 전문 회사들이 생겨났고, 결국 애플리케이션도 OS에서 분리되었다.
최근에는 클라우드 기술의 발달로 전통적인 소프트웨어 기업이 SaaS 회사, 그리고 최근에는 API의 형태로 한 단계 더 해체되고 있다.
그렇다면 API란 무엇인가?
가장 근본적으로 API는 input을 받아 output를 제공하는 일련의 규칙인데, API라는 정해진 규칙에 따라 두 응용프로그램이 서로 대화하고 데이터를 교환하거나 기능을 요청할 수 있다.
예를 들어 날씨 API에 도시라는 input을 넣으면 날씨 정보라는 output으로 반환된다. 회사들은 직접 날씨정보를 전수 조사하는 것이 아니라 이러한 API를 통해 기상청의 소프트웨어 시스템과 “대화”하여 어플에 날씨 정보를 업데이트한다. 결제 등의 기능 수행도 마찬가지다. 이커머스 회사들은 결제 API, 결제 조회 API, 정기결제 API 등을 활용하여 고객으로부터 돈을 받고, 승인·취소된 결제 기록을 다시 확인하거나, 정기 구독과 같은 기능을 추가한다. API라는 프로그래밍 인터페이스를 통해 몇 줄의 코드로 손쉽게 데이터를 호출하거나 다양한 기능을 구현할 수 있게 되었다.
UI는 일반 사용자를 위한 인터페이스라면, API는 애플리케이션 프로그래밍을 위한 인터페이스다. 잘 설계된 그래픽 UI를 통해 우리가 어플을 손쉽게 이용하는 것처럼, 소프트웨어 혹은 소프트웨어 개발자도 API를 통해 다른 소프트웨어와 소통하며 데이터와 기능들을 빠르게 호출할 수 있다. Technically 블로그를 운영하는 Justin Gage의 표현을 빌리자면 API는 복잡한 기능을 사용하기 편리한 Interface로 감싸줌으로써 레고 블록처럼 손쉽게 사용할 수 있도록 만들어준다.
“Applications are just a bunch of functions that get things done: APIs wrap those functions in easy to use interfaces so you can work with them without being an expert.”
API는 결국 개발자를 위한 편리한 dev tool이다. 전통적으로 (‘전통적’이라고 하기엔 10년도 채 안 되었지만) API는 직접 오픈 소스 라이브러리를 기반으로 사내에서 구축된 후 통합, 운영 및 관리되었다. 그러나 언제나 개발 부족한 상황에서 모든 솔루션을 직접 개발하고 관리하는 것은 너무나 비효율적이다. Third-Party API 덕분에 이제 개발팀은 모든 기능의 코드를 처음부터 짤 필요 없어졌다.
API-First 회사의 등장
Third-Party API 도입이 활발해지면서 API의 형태로 소프트웨어를 배포하는 API-First 회사들이 기하급수적으로 생겨나고 있다. API-First 회사는 많은 기업들이 필요로 하는 필수 기능 하나를 전문적으로 도맡으며 고객사에게 이를 연동하기 편리한 API의 형태로 제공한다.
Craft Ventures의 Grace Isford는 API-First 회사들을 19개 버티컬로 나누어 정리했는데, 생각해보면 표에 있는 로고들은 과거 사내에서 직접 개발해야 했던 핵심 기능들이다. 이제 개발자들은 몇 줄의 코드로 각 분야의 전문가들이 만든 솔루션을 손쉽게 구현하고, 회사의 핵심 서비스를 개발하는데 집중할 수 있다.
Third-Party API의 소중함을 깨닫게 해준 사례
티몬에서 일하며 API는 정말 많은 시간을 절약해준다는 것을 몸소 느낄 수 있었다. 2014–2018년 동안 한국에서 거의 매 달 새로운 결제 옵션이 등장했다. 카카오페이, 토스, 네이버페이, 페이코 등 새로운 결제 옵션이 등장할 때마다 연동이 필요했다. 한 개의 결제 옵션을 연동하고 QA 과정을 거쳐 출시하는 데까지 꼬박 2–3개월이라는 시간이 걸렸다. 다시 말하자면 4개의 결제 옵션을 연동하는데만 1년이 걸릴 정도로 개발 맨아워가 정말 많이 들어가는 작업이었다. 회사에서는 해당 지불 옵션이 전체 거래액에 얼만큼 기여를 할지, 즉 연동할 가치가 있는지 논쟁이 벌어졌고, x결제 옵션을 추가하면 체크아웃 시 이탈률이 y% 감소하여 거래액이 $z 증가할 것이라는 다양한 가설이 오갔다. 심지어는 특정 결제 옵션으로부터 우선순위로 연동해달라는 부탁과 함께 대규모 일회성 지원금을 제공받은 기억도 있다.
결국 핵심적인 몇 개의 결제 옵션을 연동하기로 결정했고 나머지는 개발 우선순위 맨 뒤로 밀리게 되었다. 실은 연동 자체도 복잡했지만 유지 관리가 훨씬 더 어려웠던 것 같다. 밤늦게 결제 실패 통지를 받으면 그것이 연동 과정에서 발생한 문제 때문인지, 아니면 관리 오류인지, 아니면 결제업체 시스템에 문제가 발생한 건지 알아봐야 했고, 확인 후에는 문제를 해결할 방안을 찾고 회계 시스템에도 수정된 수치를 반영하느라 애쓴 기억이 있다. 이 모든 업무를 처리하기 위해 결국 티몬의 결제 담당 조직이 커졌고, 75명까지 늘어났었다.
아임포트와 부트페이와 같은 같은 Third-Party 결제 API 회사들이 생겨나면서 상황이 바뀌었다. 결제대행사별로 각각 연동할 필요 없이 아임포트 API를 통해 한 달이면 한꺼번에 20개 이상의 결제 옵션 연동이 가능한 시대가 왔다. 유지 관리의 상당 부분도 API-First 회사가 맡아서 처리해준다. 당시 티몬에 이러한 툴이 있었다면 정말 많은 시간과 비용을 아낄 수 있었을 것이다.
빠르게 성장하고 있는 API-First 회사들
고객 커뮤니케이션 전문 Twilio, 사용자 인증 전문 Auth0, 채팅 전문 Stream, Web 3.0 기반의 Alchemy 등 API-First 회사의 성공사례가 증가하면서 API Economy에 정말 많은 투자금이 몰리고 있는 것을 확인할 수 있다. GGV의 API-First Index에 따르면 현재까지 총 $12bn이 API-First 회사에 투자되었고, 그중 $5bn이 2021년에 집행되었다. 또한 전체 투자금의 40%가 핀테크 API 회사에게 돌아갔다는 통계도 있다.
핀테크 비중이 크지만 개발자 리소스를 더 자세히 살펴보면 사실 핀테크 외에도 자체적인 회사로 전환이 가능한 API 기능들이 정말 많다. 우리가 흥미롭게 보고 있는 영역 중 하나는 회사 내부 규정을 Third-Party 응용프로그램과 통합해주는 기능이다. Third-Party 회사의 관리 규정이 회사의 내부 정책과 상충될 수 있고, 특정 서비스의 경우 정부의 변화하는 정책 가이드라인을 반영해야 하는 등 규정 통합은 상당히 까다로운 영역이다. 까다롭다는 것은 전문적인 서비스로 제공받았을 때 그만큼 가치가 있을 수 있다는 뜻인데, 정책 변화를 모니터링하며 누가 어떤 정보를 액세스 할 권한이 있는지 확인하고 승인하는 기능들이 분리되어 또 하나의 독립적인 API-First 회사로 등장하지 않을까 조심스레 예상해본다.
API 비즈니스 모델의 장점
API-First 기업의 비즈니스 모델은 상당히 매력적이다.
- Aligned Revenue Model 대부분의 SaaS 서비스는 사용자 기반의 프라이싱 모델을 채택하고 있다면, API는 사용량 기반(예: API 호출 건당 $x)으로 과금되기 때문에 고객과 서비스 제공자의 이해관계가 조금 더 일치하게 되는 수익 모델이다.
- Lower CAC API는 전통적인 B2B 세일즈 과정을 거치기보다는 주로 개발자 커뮤니티에서 입소문을 타면서 성장하기 때문에 고객 취득비용이 낮다.
- Lower Overhead 물론 outlier 이지만 직원 4명(모두 개발자)으로 구성된 한국 API 회사를 실사했었는데, EBITDA 마진이 80%에 육박한 걸로 기억한다.
- Sticky Customers 제한된 리소스를 고려했을 때 갑자기 사용 중이던 Third-Party API를 중단하고 직접 개발하는 것을 정당화하기 매우 어렵다.
- Additional Business Opportunities Infra-as-a-Service(IaaS) 또는 데이터 기록, 분석, 접근 제어 등 API 관리를 통해 추가 매출원을 만들 수 있다.
(API 비즈니스 모델의 장점과 리스크는 추후 포스팅에서 더 자세히 다룰 예정이다)
만약 회사의 수많은 백엔드 기능이 Third-Party API를 통해서 구축된다면, 이는 회사 경영과 API 이코노미에 어떤 영향을 미칠까?
- API 유지∙관리 생태계의 동반 성장
API-First 회사뿐만 아니라 API 생애 주기 전반에 걸쳐 API를 지원하는 생태계가 확장될 것이다. SaaS 회사의 폭발적인 성장과 함께 SaaS 서비스를 관리해주는 시장이 형성된 것처럼, API의 경우에도 API 콜에 대한 기록, 분석, 데이터 접근 제어 등 API 생성과 유지∙관리를 지원하는 회사들도 함께 생겨날 것으로 예상된다.
앞으로 기대되는 관리 영역 중 하나는 API 보안이다. 최근 사이버 공격 추이를 살펴보면 API가 해킹의 주요 표적이 되고 있는데 API 사용에 대한 가시성을 높이고 보안 취약점을 감지하며 API를 보호해주는 회사들도 더 많이 생겨날 것이다.
2. 회사의 가격과 비용 구조에 대한 영향
애플리케이션의 백엔드가 모두 Third-Party API로 구성된 경우 애플리케이션 자체에 대한 가격과 비용 구조는 어떻게 변화할지 살펴볼 필요가 있다.
이론적으로 API는 사용량 기반으로 과금되기 때문에 회사는 변동비에 크게 노출된다. 회사가 성장하면서 API 사용량이 많아지는 경우 변동비가 기하급수적으로 늘면서 현금 흐름이 악화될텐데, 과연 이러한 상황에서 회사들은 다시 자체 API를 구축하는 DIY 모델로 돌아갈까?
API-First 예시는 아니지만 Dropbox 사례를 살펴보면 힌트를 얻을 수 있는데, 회사가 성장하면서 고객에게 받는 수익은 비교적 고정된 반면 회사의 Amazon S3 백엔드 스토리지 비용은 가변적이었기 때문에 고객이 많아지면서 회사 비용이 급속도로 부풀었다. Dropbox는 결국 자체 서버와 스토리지를 구축했고 어마어마한 현금을 벌어들이는 회사가 되었다.
물론 Third-Party API에 비하면 스토리지는 상당히 큰 비용이다. 하지만 Third-Party API 사용이 많아질수록 누적 효과를 무시할 수 없을텐데 이러한 환경에 놓인 회사들이 어떤 선택을 하게 될지 궁금해진다.
3. 개발팀 구성 변화
SaaS와 API-First 의존도가 높아지면서 회사의 개발팀 구성이 달라질 수 있다. Third-Party API를 사용한다는 것은 백엔드 개발과 관리 업무가 “아웃소싱” 되는 것과 마찬가지인데, 이에 따라 사내 개발 인력이 프런트 엔드에 집중될 가능성이 높다.
과거 (다시 강조하지만 매우 가까운 과거에는) 백엔드 개발자가 조직의 큰 부분을 구성했다. 회사에서 서버를 관리하고, 자체 스위치를 구입하고, 데이터베이스를 구축하는 IT 팀이 필요했기 때문이다. 하지만 클라우드 기반의 SaaS와 API 서비스들이 생겨나면서 개발 팀이 백엔드 인프라를 직접 구축하고 관리할 필요가 없어졌다. 오늘날의 개발 조직 구성을 살펴보면 프런트엔드 개발자가 백엔드 엔지니어보다 훨씬 더 많은데, 프런트엔드 엔지니어가 백엔드 역할도 조금씩 맡으며 점점 풀 스택이 되어가고 있다고 표현할 수도 있을 것 같다.
4. API-First 회사의 롤업플레이
API-First 시장도 타산업에서 보았듯이 한차례 통합이 일어날 것으로 예상된다. 한 버티컬 내에서 유사 기능들이 수직적으로 통합될 수도 있고, 분야 관계없이 조금 느슨한 회사의 연합체의 형태로 통합이 이루어질 가능성도 있다. 하지만 두 경우 모두 (1) 단일 B2B(D) 영업 조직으로 세일즈가 일어나고 (2) 통합된 API들을 관리해주는 상위 SaaS 서비스 레이어가 구축됨으로써 시너지가 발생할 것이다.
통합된 모습을 상상해보기 위해 이커머스 버티컬에 API HoldCo가 있다고 가정해보자. API Hold Co.는 이커머스 분야 내 결제, omni-channel 통합, ERP, PIM, CRM, OMS, WMS, POS API 기능을 롤업한다.
API Hold Co. 는 각 분야의 API를 인수하거나 직접 개발한 후 데이터 오케스트레이션 기능을 가진 API 관리 SaaS 솔루션을 얹을 것이다. API 호출 수 확인, 효율성 모니터링, 혹은 추가로 개발이 필요한 API가 있는지 확인하는 등의 작업이 필요하다.
오케스트레이션 레이어 위에 API 기능마다 SaaS 서비스를 추가할 수도 있다. 예를 들어 결제 API로 다양한 결제 시스템을 연동했지만 A 결제 회사는 취소건을 포함해서 결제 데이터를 제공하고 B 회사는 결제 건과 취소건을 별도로 제공하는 등 데이터가 들어오는 양식이 다를 가능성이 높다. 수많은 결제 데이터를 분류하고 통일하는 작업이 쉽지 않을텐데, 이를 대신 해주는 SaaS 레이어는 정말 큰 도움이 될 것이다.
통합된 API/SaaS 제품들은 판매대상이 하나(=개발자)이기 때문에 단일 영업 팀에서 세일즈가 가능하다.
API는 개발자를 위한 “레고 블록”이라고 말하지만 이러한 작은 레고 블록은 개발자뿐만이 아니라 회사의 팀구성부터 가치 창출 방법까지 전사적인 영향을 미치고 있다. 앞으로 더 많은 API-First 회사들이 생겨날 것으로 기대되며 어떤 양상으로 통합이 이루어질지도 궁금해지는 부분이다.
