2021.04.13

최고위층 의제로 떠오르다··· CIO를 위한 'API 관리' 가이드

Mary Branscombe | CIO
디지털 트랜스포메이션을 추진 중이거나 새로운 매출원을 개발하려는 CIO들에게 있어서 API가 중요한 도구로 부상하고 있다.

애플리케이션 프로그래밍 인터페이스, 즉 API의 재주는 다양하다. 텍스트, 라벨 이미지 등을 번역하고 텍스트 메시지를 전송하며 사기 여부를 확인하고 오픈 뱅킹 데이터를 검색하며 다양한 비즈니스 거래를 처리할 수 있다. API가 머지않아 코로나19 백신 접종 상태를 검색하는 수단이 될 수 있다. 

API가 IT 및 조직 내 개발 프로세스에 중요해지면서 CIO들은 이와 관련한 관리, 준법감시, 액세스에 관해 생각해 보아야 하게 됐다. 어떤 거버넌스 모델을 통해 어떤 API로 어떤 기업 데이터에 누가 액세스하게 될까?

또한 조직이 API를 통해 효과적으로 아웃소싱하는지 여부도 고려해야 한다. 아울러 내부 개발자들이 비즈니스 전략에 맞게 API를 선택하고 있는지도 확인해야 한다. 순수하게 기술적인 이유만으로 API를 선택하면, 자칫 비즈니스 효과를 초과하는 예산을 쏟아부을 수 있다.

즉 CIO에게는 민첩성에 영향을 미치지 않으면서 API 사용을 통제할 수 있는 정책이 필요하다. 이를 위해서는 조직 내에서 어떤 내부 및 외부 API가 사용되고 있으며 어떤 목적으로 사용되고 비용은 얼마나 되며 얼마나 신뢰할 수 있는지를 명확히 파악해야 한다. 전략적으로, CIO는 API가 비즈니스에 어떻게 기여하는지 명확히 파악해야 한다.
 
Image Credit : Getty Images Bank


통합과 구성
마이크로소프트의 로우코드(Low-code) 애플리케이션 플랫폼 부사장 찰스 라마나는 “많은 고객들이 API 경제와 API 카탈로그를 보유하고 있다. 기업의 모든 사일로 전반에 걸쳐 데이터를 노출시키는 미래를 원하고 있다”라고 말했다.

라마나는 “로우코드 플랫폼을 통해 API 게이트웨이 또는 API 관리 솔루션을 사용하면 많은 기회가 열린다. 왜냐하면 개발자들은 마이크로서비스를 구축하여 다른 개발자들이 소비할 수 있도록 공개하고 시민 개발자들은 파워(Power) 플랫폼을 통해 이를 소비할 수 있기 때문이다”라고 덧붙였다.

하지만 ‘API 경제’는 단순한 로우코드와 노코드(No Code)의 수준을 넘어선다. 포스트맨(Postman)의 CEO 아비나브 아스타나에 따르면, 기업은 프로젝트가 완료될 때까지 기다리는 대신에 소프트웨어 지정 및 설계를 시작하는 즉시 API에 관해 생각해야 한다. 

그는 “API를 후순위로 방치하면 준법감시 및 거버넌스 위험이 더 증가하게 된다. 현재 애플리케이션을 구축하고 있다면 어떤 형태로든 외부 세계와 연결되는 것일 터다. 처음부터 계획을 세워야 한다”라고 말했다.

API가 외부의 서비스를 소비하기 위해서만 존재하는 것은 아니다. 많은 조직들이 기업 내에서 보편적인 데이터에 대한 셀프 서비스 액세스를 제공하거나 제공업체와의 정보 교환 간소화를 위해 자체 API를 개발하곤 한다. 

새로운 공급사를 온보딩(Onboarding)시키거나 결제 쿼리(Query)를 처리하는 경우, 송장 결제에 관한 정보 및 배송 상태를 손쉽게 제공할 수 있다면 더욱 효과적이겠지만 여러 개의 ERP 시스템에 얽매어 있는 경우가 많다. API를 개발하고 카탈로그에서 공개하면 지원 티켓이 범람하는 상황을 미연에 방지할 수 있다.

구글 컨설팅 기업 SADA의 CTO 마일스 워드가 “다른 이들에게 제공하거나 다른 곳에서는 얻을 수 없는 조직 고유의 데이터나 역량에 관해 생각해 보라. API는 흐름이 있을 때에만 실제로 가치가 있는 정보에 연결하는 수단이다. 중앙의 프로그램 가능하고 확장 가능한 인터페이스를 통해 제공될 수 없는 데이터가 있어서 유용한 곳으로 흘러갈 수 없다면 그 노력의 우선순위를 설정해야 할 때이다”라고 제안했다.

일부 애플리케이션은 거의 API 호출로만 구축되기도 한다. 가트너가 말하는 ‘구성 가능한 상거래’가 이런 트렌드의 좋은 예라고 커머스툴즈(commercetools)의 CPO(Chief Product Officer) 켈리 고취가 말했다.

API와 같이 구성 가능한 기술은 일반적인 기업 개발 접근방식을 바꾸어 놓기도 했다. 고취는 “자바(Java) 코드를 생산하는 200명의 역외 개발로 구성된 팀이 필요 없다. 일반적으로 이벤팅(Eventing) 아키텍처와 API 호출을 통해 다양한 애플리케이션이 호환되도록 할 수 있는 숙련된 배관공만 있으면 된다. 이런 일에는 사람을 많이 투입할수록 더 느려지고 어려워진다”라고 말했다.

CIO에게 필요한 것으 승인되어 사용 중인 API 카탈로그와 보편적인 보안 프레임워크를 통해 개발자들이 액세스에 사용하는 API 게이트웨이에서 적용될 수 있는 포괄적인 거버넌스 전략이라고 고취가 말했다. 그는 “구축할 API와 제3자 제공업체로부터 선택할 API를 결정하되, 게이트웨이는 개발자를 위해 이런 API에 대한 액세스를 관리하는 방식이 된다”라고 설명했다.

API 게이트웨이는 하드웨어 기기인 경우가 많지만 그것도 바뀌고 있다. API 관리를 위해 알려진 도구가 많으며 (많은 경우에 API에 대한 개별적인 조치 수준까지) 사용량, 오류율, 기타 식별 가능성 지표를 제공할 수 있는 종점 및 인스턴스 필터링을 포함하여 서비스 구성, 속도 제한, 액세스 통제를 위한 옵션이 있는 모든 주요 클라우드에 대한 상품 서비스이다. 또한 공개 API의 성능과 가용성을 추적할 수 있는 API메트릭스(APImetrics) 등의 제3자 서비스도 있다.

현장의 API
공식 API 전략을 수립하는 첫 단계는 어떤 API가 제공 및 사용되고 있는지 감사하는 것이다. 그리고 나서 이것들을 문서화하고 검색할 수 있도록 한다.

“조직 내 여러 곳에서 많이 중복되고 있다”고 말하면서 아스타나는 CIO가 개발자와 아키텍처 논의에 참여하여 API 관리에 대한 인식을 높여야 한다고 제안했다.

이미 사용 중인 API는 간과하기 쉽다. API 카탈로그를 구축 중인 한 대형 의료 조직은 사용 중인 450개의 API에 대한 목록부터 시작했다. 최종 수치는 약 4,000개였다. 프록시(Proxy)와 로그 파일 및 기타 포렌식을 살펴보는 도구는 이미 기업 내에 존재하는 API를 찾아 OpenAPI 설명을 생성할 수 있게 해준다.

카탈로그가 공개되면 API 공개 및 소비 추적뿐 아니라 API 라이프사이클 관리에 대한 더욱 전략적인 정책을 추적하는 데 사용되어야 하며, 여기에는 외부 API 제공자가 과격한 변화를 수행하거나 서비스를 모두 차단하는 경우에 불만을 처리하는 것이 포함된다.

일부 CIO들은 API 아키텍트를 고용하여 API 전문가 조직이나 거버넌스 그룹을 만들어 API 정책을 감독하기 시작했다. 특히, (로봇 공정 자동화는 엑셀 스프레드시트에서 API를 생성할 수 있기 때문에) 조직 내 API 사용량 분포를 추적하여 내부 API를 제공하는 시스템이 적절히 리소싱 되도록 하고 이를 보호해야 한다. 그래야 범블(Bumble)과 에퀴팩스(Equifax) 같은 서비스에서 발생했던 것처럼 데이터가 노출되는 사고를 막을 수 있다. 

Digital.ai의 EMEA 기술 책임자 윈스턴 본드는 “이러한 사고는 최신 앱이 API에 얼마나 의존하고 기업이 이 모든 API를 비밀로 유지하면서 모두 숨기는 것이 얼마나 복잡한지 보여준다. 클라우드 기반 마이크로서비스들 속에서 개발된 범블 같은 앱은 일반적으로 방화벽 뒤에 안전하게 유지되고 있는 많은 연결 부분을 노출시킨다”라고 말했다.

비용, 신뢰, 컴플라이언스
API 사용량에 대한 투명성을 확립해야 하는 또 다른 이유는 비용 관리이다. API는 여느 클라우드 서비스처럼 취급받는 경우가 많지만 API는 눈에 덜 띄는 경우가 많기 때문에 비용 과잉으로 이어질 수 있다.




2021.04.13

최고위층 의제로 떠오르다··· CIO를 위한 'API 관리' 가이드

Mary Branscombe | CIO
디지털 트랜스포메이션을 추진 중이거나 새로운 매출원을 개발하려는 CIO들에게 있어서 API가 중요한 도구로 부상하고 있다.

애플리케이션 프로그래밍 인터페이스, 즉 API의 재주는 다양하다. 텍스트, 라벨 이미지 등을 번역하고 텍스트 메시지를 전송하며 사기 여부를 확인하고 오픈 뱅킹 데이터를 검색하며 다양한 비즈니스 거래를 처리할 수 있다. API가 머지않아 코로나19 백신 접종 상태를 검색하는 수단이 될 수 있다. 

API가 IT 및 조직 내 개발 프로세스에 중요해지면서 CIO들은 이와 관련한 관리, 준법감시, 액세스에 관해 생각해 보아야 하게 됐다. 어떤 거버넌스 모델을 통해 어떤 API로 어떤 기업 데이터에 누가 액세스하게 될까?

또한 조직이 API를 통해 효과적으로 아웃소싱하는지 여부도 고려해야 한다. 아울러 내부 개발자들이 비즈니스 전략에 맞게 API를 선택하고 있는지도 확인해야 한다. 순수하게 기술적인 이유만으로 API를 선택하면, 자칫 비즈니스 효과를 초과하는 예산을 쏟아부을 수 있다.

즉 CIO에게는 민첩성에 영향을 미치지 않으면서 API 사용을 통제할 수 있는 정책이 필요하다. 이를 위해서는 조직 내에서 어떤 내부 및 외부 API가 사용되고 있으며 어떤 목적으로 사용되고 비용은 얼마나 되며 얼마나 신뢰할 수 있는지를 명확히 파악해야 한다. 전략적으로, CIO는 API가 비즈니스에 어떻게 기여하는지 명확히 파악해야 한다.
 
Image Credit : Getty Images Bank


통합과 구성
마이크로소프트의 로우코드(Low-code) 애플리케이션 플랫폼 부사장 찰스 라마나는 “많은 고객들이 API 경제와 API 카탈로그를 보유하고 있다. 기업의 모든 사일로 전반에 걸쳐 데이터를 노출시키는 미래를 원하고 있다”라고 말했다.

라마나는 “로우코드 플랫폼을 통해 API 게이트웨이 또는 API 관리 솔루션을 사용하면 많은 기회가 열린다. 왜냐하면 개발자들은 마이크로서비스를 구축하여 다른 개발자들이 소비할 수 있도록 공개하고 시민 개발자들은 파워(Power) 플랫폼을 통해 이를 소비할 수 있기 때문이다”라고 덧붙였다.

하지만 ‘API 경제’는 단순한 로우코드와 노코드(No Code)의 수준을 넘어선다. 포스트맨(Postman)의 CEO 아비나브 아스타나에 따르면, 기업은 프로젝트가 완료될 때까지 기다리는 대신에 소프트웨어 지정 및 설계를 시작하는 즉시 API에 관해 생각해야 한다. 

그는 “API를 후순위로 방치하면 준법감시 및 거버넌스 위험이 더 증가하게 된다. 현재 애플리케이션을 구축하고 있다면 어떤 형태로든 외부 세계와 연결되는 것일 터다. 처음부터 계획을 세워야 한다”라고 말했다.

API가 외부의 서비스를 소비하기 위해서만 존재하는 것은 아니다. 많은 조직들이 기업 내에서 보편적인 데이터에 대한 셀프 서비스 액세스를 제공하거나 제공업체와의 정보 교환 간소화를 위해 자체 API를 개발하곤 한다. 

새로운 공급사를 온보딩(Onboarding)시키거나 결제 쿼리(Query)를 처리하는 경우, 송장 결제에 관한 정보 및 배송 상태를 손쉽게 제공할 수 있다면 더욱 효과적이겠지만 여러 개의 ERP 시스템에 얽매어 있는 경우가 많다. API를 개발하고 카탈로그에서 공개하면 지원 티켓이 범람하는 상황을 미연에 방지할 수 있다.

구글 컨설팅 기업 SADA의 CTO 마일스 워드가 “다른 이들에게 제공하거나 다른 곳에서는 얻을 수 없는 조직 고유의 데이터나 역량에 관해 생각해 보라. API는 흐름이 있을 때에만 실제로 가치가 있는 정보에 연결하는 수단이다. 중앙의 프로그램 가능하고 확장 가능한 인터페이스를 통해 제공될 수 없는 데이터가 있어서 유용한 곳으로 흘러갈 수 없다면 그 노력의 우선순위를 설정해야 할 때이다”라고 제안했다.

일부 애플리케이션은 거의 API 호출로만 구축되기도 한다. 가트너가 말하는 ‘구성 가능한 상거래’가 이런 트렌드의 좋은 예라고 커머스툴즈(commercetools)의 CPO(Chief Product Officer) 켈리 고취가 말했다.

API와 같이 구성 가능한 기술은 일반적인 기업 개발 접근방식을 바꾸어 놓기도 했다. 고취는 “자바(Java) 코드를 생산하는 200명의 역외 개발로 구성된 팀이 필요 없다. 일반적으로 이벤팅(Eventing) 아키텍처와 API 호출을 통해 다양한 애플리케이션이 호환되도록 할 수 있는 숙련된 배관공만 있으면 된다. 이런 일에는 사람을 많이 투입할수록 더 느려지고 어려워진다”라고 말했다.

CIO에게 필요한 것으 승인되어 사용 중인 API 카탈로그와 보편적인 보안 프레임워크를 통해 개발자들이 액세스에 사용하는 API 게이트웨이에서 적용될 수 있는 포괄적인 거버넌스 전략이라고 고취가 말했다. 그는 “구축할 API와 제3자 제공업체로부터 선택할 API를 결정하되, 게이트웨이는 개발자를 위해 이런 API에 대한 액세스를 관리하는 방식이 된다”라고 설명했다.

API 게이트웨이는 하드웨어 기기인 경우가 많지만 그것도 바뀌고 있다. API 관리를 위해 알려진 도구가 많으며 (많은 경우에 API에 대한 개별적인 조치 수준까지) 사용량, 오류율, 기타 식별 가능성 지표를 제공할 수 있는 종점 및 인스턴스 필터링을 포함하여 서비스 구성, 속도 제한, 액세스 통제를 위한 옵션이 있는 모든 주요 클라우드에 대한 상품 서비스이다. 또한 공개 API의 성능과 가용성을 추적할 수 있는 API메트릭스(APImetrics) 등의 제3자 서비스도 있다.

현장의 API
공식 API 전략을 수립하는 첫 단계는 어떤 API가 제공 및 사용되고 있는지 감사하는 것이다. 그리고 나서 이것들을 문서화하고 검색할 수 있도록 한다.

“조직 내 여러 곳에서 많이 중복되고 있다”고 말하면서 아스타나는 CIO가 개발자와 아키텍처 논의에 참여하여 API 관리에 대한 인식을 높여야 한다고 제안했다.

이미 사용 중인 API는 간과하기 쉽다. API 카탈로그를 구축 중인 한 대형 의료 조직은 사용 중인 450개의 API에 대한 목록부터 시작했다. 최종 수치는 약 4,000개였다. 프록시(Proxy)와 로그 파일 및 기타 포렌식을 살펴보는 도구는 이미 기업 내에 존재하는 API를 찾아 OpenAPI 설명을 생성할 수 있게 해준다.

카탈로그가 공개되면 API 공개 및 소비 추적뿐 아니라 API 라이프사이클 관리에 대한 더욱 전략적인 정책을 추적하는 데 사용되어야 하며, 여기에는 외부 API 제공자가 과격한 변화를 수행하거나 서비스를 모두 차단하는 경우에 불만을 처리하는 것이 포함된다.

일부 CIO들은 API 아키텍트를 고용하여 API 전문가 조직이나 거버넌스 그룹을 만들어 API 정책을 감독하기 시작했다. 특히, (로봇 공정 자동화는 엑셀 스프레드시트에서 API를 생성할 수 있기 때문에) 조직 내 API 사용량 분포를 추적하여 내부 API를 제공하는 시스템이 적절히 리소싱 되도록 하고 이를 보호해야 한다. 그래야 범블(Bumble)과 에퀴팩스(Equifax) 같은 서비스에서 발생했던 것처럼 데이터가 노출되는 사고를 막을 수 있다. 

Digital.ai의 EMEA 기술 책임자 윈스턴 본드는 “이러한 사고는 최신 앱이 API에 얼마나 의존하고 기업이 이 모든 API를 비밀로 유지하면서 모두 숨기는 것이 얼마나 복잡한지 보여준다. 클라우드 기반 마이크로서비스들 속에서 개발된 범블 같은 앱은 일반적으로 방화벽 뒤에 안전하게 유지되고 있는 많은 연결 부분을 노출시킨다”라고 말했다.

비용, 신뢰, 컴플라이언스
API 사용량에 대한 투명성을 확립해야 하는 또 다른 이유는 비용 관리이다. API는 여느 클라우드 서비스처럼 취급받는 경우가 많지만 API는 눈에 덜 띄는 경우가 많기 때문에 비용 과잉으로 이어질 수 있다.


X