'효과 제대로 누리려면...' API 전략을 추구할 때 따라야 할 3가지 원칙

기업 입장에서 개방형 서비스 생태계를 구축하면 비즈니스 가치를 보다 높일 수 있다. 이때 API 전략이 탄탄해야 제대로된 효과를 누릴 수 있다.
 

2000년대 초, 아마존(Amazon), 이베이(eBay), 세일즈포스(Salesforce) 같은 기업은 웹 애플리케이션들 사이의 인터페이스 표준화 트렌드를 주도했다. 그 결과, 누구든 소비할 수 있는 개방형 웹 API로 구성된 네트워크가 성장하면서 애플리케이션이 개발 및 통합되는 방식 전체가 개편되는 결과로 이어졌다.

이 기간 동안 아마존의 설립자 제프 베이조스는 직원들에게 ‘베이조스 API 지시’로 알려진 메모를 직원들에게 보냈다. 이 메모에는 어느 IT 리더나 개발팀의 노력의 가치를 극대화하기 위해 고려할 2가지 전략적 요건이 포함돼 있었다. 첫 번째는 각 팀에서 개발한 소프트웨어들 사이의 모든 인터페이스가 API를 통해야 한다는 것이다. 두 번째는 내부 API를 마치 회사 외부인들이 사용할 것처럼 작성해야 한다는 것이다.

이 접근 방식은 아마존이 어떻게 컴퓨팅 인프라를 표면화할 수 있었는지 보여준다. 아마존은 소매업자들이 자체 온라인 스토어를 구축할 수 있는 해당 기업의 EaaS(Ecommerce as a Service) 플랫폼 머천트.com(Merchant.com)로 출발해 더욱 광범위한 제품 AWS(Amazon Web Services)로 확장했다.

2023년이 되면서 IT 리더들은 지난 20년 동안 효과적인 API 개발 및 사용에 대해 더 많은 교훈을 얻었다. 교훈의 상당 부분은 마이크로서비스와 API를 중시하면서 ‘개방적인 동급 최고 기술 생태계’를 추구하는, 약 100개의 기술 제공업체로 구성된 글로벌 컨소시엄 마크얼라이언스(MACH Alliance)가 작성했다.

마크얼라이언스와 여러 IT 리더들은 모든 API 전략 효과를 극대화하는 3가지 원칙을 제시했다. 해당 원칙은 소프트웨어 시스템이 서로 잘 호환되도록 할 뿐 아니라 조직의 전반적인 소프트웨어 개발 전략에 따라 팀들이 협력할 수 있도록 한다. 결국, API와 마찬가지로 한 그룹이 다른 그룹에 서비스를 제공할 때 약속이 명확하고 경계를 준수해야 한다.

1. API 우선 접근방식을 도입하라
API 전략을 극대화하는 가장 효과적인 방법은 처음부터 소프트웨어 개발 전략의 구성요소로써 API를 우선순위에 두는 ‘API 우선’ 접근방식을 취하는 것이다.

API를 우선시하는 조직은 통합보다 접속에 더 집중한다. 그들은 다른 코드를 작성하기 전에 수행 서비스, 취하는 입력값, 생성 결과값 등의 API를 먼저 정의한다. 이런 방식으로 다양한 소프트웨어 구성요소를 통합하여 통일된 애플리케이션을 구축하는 대신, API를 통해 생태계에 제공되는 구성 요소로 나뉜 서비스를 사용한다. API 우선 접근방식을 사용하지 않는 조직은 API를 설계하기 전에 소프트웨어를 개발하기 때문에 유용성이 제한된다고 발텍(Valtech)의 글로벌 기술 SVP 겸 마크얼라이언스의 사장 캐스퍼 라스무센이 말했다.

라스무센은 “API 우선의 핵심은 특정 사용 사례에 적용되기 보다는 다재 다능한 인터페이스를 설계하는 것이다. 기존의 구형 소프트웨어 위에 API를 적용하는 경우 최소한 역사적으로 보았을 때 API 우선은 아니며, 구형 소프트웨어는 어떤 사용 사례에서 누구에게 어떤 기능을 제공하는지에 관한 가정이 따른다. API 우선은 훨씬 다재다능하고 훨씬 포괄적이다. 소비자를 웹 클라이언트로 가정하는 API 전략을 예로 들어보면, HTML을 전달하기 때문에 다른 환경에서 사용하기 어렵다”라고 말했다.

API 우선 접근방식을 통해 조직은 애플리케이션이 느슨하게 연결된 서비스의 집단으로 구조화되는 SOA(Service-Oriented Architecture)의 변종인 마이크로서비스 아키텍처를 제대로 활용할 수 있다. API 우선 접근방식을 도입한 기업으로 레고 그룹(The Lego Group)이 있다. 이 개념은 블록의 표준 인터페이스 덕분에 사용자가 블록들을 더 큰 블록으로 조립할 수 있는 레고 제품과 유사하다.

레고 그룹의 마케팅 및 채널 기술 부사장 니알 에드워즈는 “우리의 전략적 우선순위는 서비스를 노출하기 위해 API를 구축하고 운영하는 제품팀이 지원하는 느슨하게 연결된 시스템을 구축하는 것이다. 우리의 레고.com 기술 플랫폼은 수 년 동안 완전히 마이크로서비스 및 API 기반이었으며, 지금은 이 접근방식을 모든 기술 영역으로 전파하고 있다. 우리는 이 접근방식을 더욱 통합된 기업 시스템에 적용하고 있다”고 말했다.

레고 그룹은 API 우선 접근방식이 더 크고 복잡한 기능보다 마이크로서비스에 얼마나 유리한지를 보여주는 완벽한 예시를 제공한다. 새로운 API는 다양한 애플리케이션이 사용할 수 있는 좁게 정의된 서비스를 수행할 수 있다. 구형 시스템은 애플리케이션이 기존의 서비스가 새롭게 개발된 것처럼 소비할 수 있는 방식으로 API를 새롭게 탑재할 수 있다.

구형 기술 투자는 대체를 고려하기 때문에 CIO는 새로운 제공업체가 마이크로서비스를 제공하고 API 우선 원칙을 준수하는 경우에만 도입해야 한다.

2. API 정책을 수립하여 시행하라
내외부의 여러 그룹들이 개발한 소프트웨어 구성요소들 사이에서 느슨한 연결 및 높은 일관성을 확보하기 위해 보편적인 API 정책이 필요하다.

정책은 심지어 대부분의 API 작업을 다양한 개발팀들이 독립적으로 이행하더라도 일부 서비스는 IT가 중앙에서 수행된다는 점을 명시해야 한다. 예를 들어, 일관성을 확보하기 위해 액세스 관리는 중앙에서 관리하고 모든 API가 하나의 식별 및 인증 스키마를 사용해야 한다. 통일성을 확보하기 위해 데이터 형식을 중앙에서 관리해야 한다. 그리고 마지막으로 SLA(Service Level Agreement)를 IT가 정의하고 관리해야 한다. 예를 들어, 고객이 맞닥뜨리는 모든 것에 대해 API가 50밀리초 안에 대응해야 한다고 말할 수도 있다.

에드워즈는 “누가 무엇을 책임지는지 명확하지 않으면 혼란을 줄 수 있고, 누구도 진실의 근원을 알 수 없다. 기업 데이터 모델은 누가 어떤 데이터를 책임지는지 명시해야 하고, 해당 데이터의 사용자는 이를 캐시 처리하여 사용할 수 있지만 절대로 변경할 수 없음을 알아야 한다. 데이터의 변경은 소스에서만 이루어지며, 이런 변화는 발견 가능하고 모든 소비자에게 노출되어야 한다”고 말했다.

API를 마이크로서비스가 뒷받침해야 가장 효과적일 수 있다. IT 리더는 이런 가정에 따라 API를 정의한 후 서비스를 내부적으로 구축하거나 이 접근방식을 고수하는 서비스를 제공하는 제공업체를 선택해야 한다.

커머스툴즈(commercetools)의 CSO이자 API와 마이크로서비스에 관한 4권의 서적을 집필한 켈리 괴츠는 “API는 독립적으로 호출 가능하고 상태가 없으며 멱등이어야 한다”라고 말했다. 즉, 애플리케이션은 다른 API를 호출할 필요없이 API를 사용할 수 있으며, 서비스 내부의 값은 호출할 때마다 다른 값을 생성하는 방식으로 변경되지 않는다. 예를 들어, API를 호출하여 카트에 여러 번 추가할 수 있으며, 멱등인 경우 호출할 때마다 같은 방식으로 작동할 것이다.

마지막으로, 정책은 내부 전용 API와 외부 API 사이에 차이가 없어야 한다. 라스무센은 “베이조스 지시의 훌륭한 점은 기본적으로 API를 표면화해야 한다고 말한 것이다. 그리고 내부 프로젝트로 시작된 AWS의 경우 이미 회사 내부에서 사용되고 있는 것에 대한 액세스만 변경함으로써 외부 세계에 제공했다”고 말했다.

API 정책이 수립되면 핵심은 모든 팀이 준수하도록 하는 것이다. 많은 부분이 움직이고 연결되며 데이터가 전송되기 때문에 IT 리더는 이런 필수적인 측면을 간과해서는 안 된다.

3. API 카탈로그를 구축하여 유지하라
API 비전을 충족하기 위해 이렇게 광범위한 서비스가 필요할 가능성이 높기 때문에 조직이 생성하는 API뿐 아니라 제공하기 위해 조직이 제3자에 의존할 가능성이 높은 것들을 인덱싱해야 한다.

괴츠는 “CIO는 API 카탈로그와 해당 카탈로그를 관리하기 위한 전략을 개발해야 하는데, 카탈로그는 API를 정의하고 기업이 필요한 모든 기능을 포함해야 한다. 그러면 이런 서비스를 제공하는 소프트웨어를 구축할지 또는 구매할지 결정할 수 있다”고 말했다.

카탈로그는 중앙에서 관리해야 하지만 구현 책임은 개별 팀 또는 외부 제공업체에 맡겨야 한다. 하지만 서비스를 개발하는 사람은 카탈로그에 정의된 내용을 따라야 한다고 괴츠는 말했다.

그는 “API를 구현하는 팀은 데이터베이스 외에 다른 많은 것들을 선택할 수 있으며, 그들이 엉망으로 만드는 경우 책임을 물어야 한다. 팀이 올바르게 관리하고 있는지 쉽고 빠르게 판단할 수 있고, API가 중단되면 문제가 있음을 알 수 있다"라고 말했다.

중앙의 카탈로그는 잘 문서화돼 있어야 하며, 내부 및 외부 사용자가 필요에 대한 설명 또는 일련의 키워드에 기초해 API를 찾을 수 있는 검색 도구가 함께 제공돼야 한다. 에드워즈는 “레고 그룹은 개발자들이 레고 블록처럼 서로의 API를 찾고 활용해 더 큰 제품을 구성할 수 있도록 중앙 집중식 검색 도구에 투자했다”라고 말했다.

앞서 언급한 3가지 원칙을 준수하고 수년 동안의 경험을 통해 얻은 지혜에 주의를 기울임으로써, IT 리더는 모든 서비스로 향하는 경로를 확보하도록 프레임워크를 구축할 수 있다. 소비자는 탄탄한 인터페이스를 신뢰할 수 있으며 생산자는 서비스 구축에 필요한 자유를 얻는다. 양쪽 모두 자신의 시간에 맞춰 혁신할 수 있다.
ciokr@idg.co.kr