블로그 | API 관리가 그토록 복잡해야만 할까?

소프트웨어 애플리케이션은 서로 연결되어 있다. 우리가 사용하는 소프트웨어의 거의 모든 부분은 다른 애플리케이션, 데이터 스트림, 함수는 물론 내부(PC 내 또는 장치 상) 및 외부 서드파티 IT서비스와 연결될 가능성이 있는 앱의 형태를 띠고 있다.

그러나 2000년대 이전에는 상호 연결이 이 정도는 아니었다(웹 브라우저가 DVD-ROM 디스크 에 담겨 있어서 직접 설치해야 했던 때가 기억나는가?). PC가 비교적 독립적인 형태일 때가 많던 시절이었다. PC의 ‘연결’이라고 해봐야 저장 및 백업용 회사 파일 서버에 연결하거나 가끔 공유 스프레드시트에 접근하는 것이 고작이었다.

하지만 지금은 사정이 다르다. 지금은 클라우드 네이티브 웹 중심 모바일 우선 소프트웨어가 다른 독립체에 방대하게 연결되어 있으며 API(Application Programming Interfaces)를 통해 연결되는 경우가 많다. API는 애플리케이션 요소와 서비스에 ‘말’을 걸고 ‘연결시킬’ 수 있다. 필수 문법에 따라 작성되며 동사와 명사로 구성된 함수 호출이라는 것에 의해 구현된다. 

이렇게 웹을 구축했고 클라우드를 구축했으며 현재의 개념으로 최신 IT시스템인 것의 내부에 존재하는 모든 신경 노드를 서로 연결하는 도관을 구축했으니 끝난 것일까? 그렇기도 하고 그렇지 않기도 하다. 위의 서술 내용은 모두 사실이지만 API는 알고 보면 개발에 비용이 많이 들고 일관성 있게 통제하기가 까다로우며 세부적으로 추적하려면 복잡하기 때문이다. 

“API당 3만 달러 되시겠습니다”
엑스웨이(Axway) CITO 빈스 파두아에 따르면 오늘날 한 API를 구축하려면 평균 3만 달러 안팎의 비용이 요구된다. 대부분의 규모의 기업에서 몇 주 내지 몇 달의 기간이 소요된다. 엑스웨이는 API 활동, 호출, 강건성 및 보안과 관련된 까다로운 작업 일체를 담당할 API 관리 플랫폼을 개발하는 기업이다.

파두아는 “조직들은 재사용, 중앙집중화 된 거버넌스, 가시성이 관건인 탄탄한 API 관리 계획을 수립해야 한다”라고 강조했다. 아울러, API 복잡성이 생기는 원인에 대해 서로 다른 클라우드 인스턴스에 걸쳐 서로 다른 보안 요건, 조직이 시스템 확장을 시도할 때 생기는 문제, 클라우드 이주 여정 자체에서 생기는 문제 등이라고 설명했다.

이 주제에 대해 나름의 주장을 펼치고 있는 뮬소프트(MuleSoft)는 올 봄 API 관리용 애니포인트 플랫폼(Anypoint Platform)의 최신 주요 릴리스를 내놓았다. 뮬소프트는 소프트웨어 애플리케이션 개발자들에게 추가 코드를 작성할 필요 없이 단일 질의로 여러 개의 기존 API로부터의 데이터를 검색, 접근 및 제공하게 해 줄 수 있다고 주장한다. 

회사의 애니포인트 데이터그래프(Anypoint DataGraph)를 활용하면 뮬소프트에서 ‘작성 가능 비즈니스 기능’(composable business capabilities)이라 부르는 것을 만들 수 있는데 이는 다양한 API 공급원으로의 연결로 형성된 것이다.

이런 의미에서 작성 가능 비즈니스 기능이 뜻하는 것은 a) API에 의해 도관으로 돌려지는 최신 클라우드 네이티브 애플리케이션 데이터 서비스와 b) ‘리프트 앤 시프트’ 작업으로 클라우드에 재호스팅 된 구형 서비스에 대한 연결의 조합이다.

API 라디오의 백색 소음
그러나 아직 전투의 반만 치렀을 뿐이다. 생성되는 새로운 디지털 서비스에 동력을 공급하는 데이터는 당연히 다양한 시스템에 상주한다(뮬소프트의 ‘2021년도 연결성 벤치마크 보고서’에 따르면 보통의 기업에 900개 이상의 애플리케이션이 있는 것으로 나타났다).

많은 경우에 API는 반응이 길고 복잡하며 프로그래머(그리고 궁극적으로 사용자)에게 필요 없는 필드를 포함한 모든 필드를 반환하도록 설계되는 경우가 많다. 즉, 개발자가 새로운 각각의 프로젝트에 필요한 데이터를 분석하고 추출하기 위해서라도 결국 커스텀 코드를 작성하게 된다는 뜻이다. 그렇게 하지 않으면 한 번에 여러 API를 작업하기 시작할 때 그 프로세스가 확장하지 않고 사용성 덕분에 생긴 효율성 이득의 많은 부분이 상실된다.

뮬소프트 제품 관리 담당 SVP 션 클라우스는 “재사용 가능한 API 세계가 열린 것은 사실이다. 그러나 여전히 한 번에 하나의 API 에만 연결할 수 있다는 한계가 있다. 뮬소프트는 기업들이 단일 요청으로 추가 커스텀 코드는 없이 한 번에 여러 개의 API를 재사용할 수 있게 하는 것을 목표로 하고 있다”라고 말했다.

그것이 어떻게 가능한가? 클라우스의 설명에 따르면, API들은 상호 관계가 있는 경우가 많기 때문에 개념적으로 서로 이어 붙여서 각 API에 포함된 모든 데이터와 기능을 그래프로 만들 수 있다. 즉, 개발자들은 피상적인 데이터 추출 작업에 많은 시간을 들일 필요가 없고 필요한 데이터는 그래프로부터 질의를 통해 얻으면 된다.

데이터그래프가 의미하는 것은 더 많은 시스템으로부터의 데이터에 대한 수요가 계속 늘어난다고 해도 더 많은 시스템을 통합하는 일에는 노력이 더 많이 필요하지 않을 수 있다는 것이다. 개발자들은 배후의 모든 복잡함과 관계를 이해하지 않고도 기존의 것으로부터 지렛대를 만들 힘을 가질 수 있다. 또 아키텍트와 IT 관리자는 관리하고 안전하게 보호해야 할 API 숫자가 줄어든다.

광활한 API의 미래
더 먼 미래와 관련해 뮬소프트는 API 관리가 어마어마하게 확장 가능해야 한다고 믿고 있다. 단지 API 숫자만이 아닌, 다양성도 감당해야 하기 때문이다. 미래의 기업들은 많은 ‘수송’과 아키텍처 패턴과 배치 환경이 있는 API의 광활한 우주에서 운영될 것이다. 

클라우스는 “우리는 구축 장소나 배치 장소 또는 방식을 불문하고 모든 API의 목록 작성 및 관리를 도울 것이다. 또한, 컨테이너화 된 마이크로서비스 환경에 맞게 만들어진 오픈 표준을 바탕으로 구축된 초경량 게이트웨이를 출시할 예정이다. API를 활용해 이벤트 주도의 비동기 트랜잭션을 기술하는 방식으로 이벤트 주도 시스템을 만들기 쉽게 할 것이며, 모니터링, 보안, 관리 및 거버넌스 통제가 통합된 차원을 제공할 것”이라는 말로 끝을 맺었다.

좋은 것들은 다 그렇듯이 API도 끝이 난다. 애플리케이션 사용 사례가 마감되거나, 데이터 서비스가 거버넌스 변경 대상이 되거나, API를 활용하는 더 넓은 IT 시스템이 더 이상 사용되지 않거나 어떻게든 쓸모 없게 되는 경우, API 역시 확실하게 물러나 문을 닫아야 한다.

API 관리자라는 직책이 찍힌 정식 명함을 소지한 사람을 만나지는 못하겠지만 API 관리는 모든 IT 부서에서 이제 고려해야 할 핵심 기술이다. 게다가 어차피 명함은 DVD-ROM처럼 1999년에나 어울리는 존재가 아니던가? ciokr@idg.co.kr