미래에는 API의 A가 자동화를 의미합니다.

API는 애플리케이션 프로그래밍 인터페이스를 의미합니다. 수년에 걸쳐 밀접하게 결합된 명령형 사양에서 느슨하게 결합된 선언형 모델로 발전했습니다. 오늘날 가장 일반적인 API는 RESTful이며 통합을 가능하게 하는 데 사용됩니다. 구현 및 호출 모드에 관계없이 API는 앱 개발과 연관되는 경향이 있습니다. 

하지만 또 다른 API 경제가 꾸준히 확장되고 있습니다. 이는 운영에 달려 있습니다. 그리고 해당 도메인에서 API의 "A"는 자동화를 의미합니다.

운영 분야에서 API가 나타내는 것은 인프라와 애플리케이션 서비스의 온보딩, 구성, 운영을 자동화하는 기능입니다. 따라서 운영을 지원하는 데 필요한 인터페이스(API)는 자동화를 단순화하는 데 중점을 두어야 합니다.

조직이 디지털 혁신의 두 번째 단계 에 완전히 진입하고 전달 및 배포 파이프라인 전반에서 자동화를 확장하기 시작함에 따라 이러한 초점은 중요합니다. 자동화를 확장하려면 앱의 배포 파이프라인을 구현하는 일관되고 반복 가능하며 예측 가능한 프로세스를 개발할 수 있는 능력이 필요합니다. 

Kentik에서 2019년 자동화 현황 보고서에 따르면 절반 이상(53%)의 조직이 이미 네트워크 구성에 자동화를 사용하고 있으며, 40%는 정책 관리를 자동화했습니다. 우리의 조사에 따르면 그 비율이 훨씬 더 높아서 네트워크를 자동화하는 비율이 86%에 달했습니다. 동일한 연구인 2020년 애플리케이션 서비스 현황에서는 배포 파이프라인 전반에서 자동화 상태의 일관성이 점차 높아지고 있는 것으로 나타났습니다.

조직에서 사용하는 도구 역시 변화하고 있습니다. Python은 여전히 가장 인기 있는 옵션 중 하나이지만, IT에서는 DevOps와 클라우드 기반 앱이 영향을 미치고 있습니다. 배포 파이프라인은 Jenkins 및 Ansible과 같은 도구에 의해 점점 더 주도되고 GitHub 및 GitLab Enterprise와 같은 저장소에 의해 트리거됩니다. 미래를 내다보면, 인프라와 앱 서비스는 고급 분석을 통해 생성된 실행 가능한 통찰력에 의해 주도될 것입니다.

배포 파이프라인에서 API를 호출하는 것은 사람이 아니라 시스템입니다. 따라서 자동화를 특별히 염두에 두고 운영 API를 설계하는 것이 필수적입니다. 즉, 고려해야 할 사항이 여러 가지 있다는 뜻입니다.

첫째, 운영 API를 호출할 수 있는 시스템을 고려해야 할 수도 있습니다. Jenkins나 저장소에서 제공하는 데이터는 기존 네트워크 자동화 도구 및 서비스에서 제공하는 데이터와 상당히 다를 것입니다. 즉, 다른 곳에서 데이터를 얻거나 가능한 경우 표준화된 값을 기본값으로 사용하는 것을 의미할 수 있습니다. 

두 번째로, '자격 증명이 있는 사용자' 호출과 별도로 '자격 증명이 있는 머신' API 호출의 필요성을 해결하는 것이 중요합니다. 오늘날 대부분의 인증 시스템은 "사용자"가 인간이라고 가정합니다. API 키는 좋은 옵션일 수 있지만, 머신 전용 자격 증명을 유지하도록 설계된 시스템을 배포, 운영 및 관리하기 위해서는 IT 운영 측면에서 어느 정도 학습이 필요합니다. 하지만 이는 디지털 혁신의 세 번째이자 마지막 단계로 접어드는 시점에서 매우 중요합니다. 이 단계에서는 AI 지원 애플리케이션 서비스와 운영이 운영 부담에서 더 큰 비중을 차지하게 됩니다.

오늘날에는 작업을 자동화할 수 있는 스크립트를 작성할 수 있는 도구가 있어서 좋습니다. 하지만 미래에는 API의 A가 사람 대신 기계 간의 상호작용과 호출에 영향을 미치기 때문에, 최소한 운영 맥락에서는 자동화를 거의 전적으로 지칭하게 될 것이라는 점을 인식하는 것이 중요합니다.