 |
ⓒ Getty Images Bank |
<이미지를 클릭하시면 크게 보실 수 있습니다> |
API 관리 솔루션 전문 업체 콩(Kong)의 CTO이자 공동 설립자인 마르코 팔라디노는 “API는 사용자와 기업이 웹에서 서비스와 데이터에 액세스하는 방식에 필수적인 요소”라며, 생성형 AI, 웹3, 블록체인과 같은 새로운 영역에서 API의 역할이 중요하다고 강조했다. 하지만, “그 중요성에도 불구하고 IT나 글로벌 경제에서 API의 중요성을 인식하는 사람은 거의 없는데, 이는 대부분 조용한 혁명이었기 때문”이라고 지적했다.
대다수 기업은 점점 더 많은 API 디자인 스타일과 표준으로 API 포트폴리오가 확장되는 상황에 직면해 있다. 데이터 통합 및 API 관리 전문업체인 액스웨이(Axway)의 DX 촉진 담당 부사장인 브라이언 오튼은 “거의 모든 조직이 이 작업을 수행하고 있다”라며, “최근에도 이벤트 기반 자원 및 그래프QL과 함께 REST API를 보고 싶어하는 대형 식품 소매업체와 이야기를 나눈 적이 있다"라고 밝혔다.
기업은 다양한 API 스타일을 짜맞추는 것 외에도 여러 API 게이트웨이 또는 관리 도구를 동시에 사용한다. 가트너의 애널리스트 마크 오닐은 “이미 API 관리 솔루션을 보유하고 있는 기업이 API 관리 솔루션을 구매해야 하는 시점에 와 있다”라고 말했다. 오닐은 현재 플랫폼을 대체하기 위한 경우도 있지만, 많은 경우 누적적인 구매라고 말한다.
이런 다중 패러다임의 세상에서 API 거버넌스는 서로 다른 스타일을 연결하고 기술 포트폴리오의 난립으로 인한 문제를 피하기 위한 핵심 요소로 부상하고 있다. API 분야 전문가들에 따르면, 거버넌스는 문서화, 조직 전반의 공통 패턴 중앙 집중화, 도구 통합, 개발자 경험을 개선하는 내부 플랫폼 구축에 더욱 중점을 둬야 한다.
API 채택에 영향을 미치는 주요 기술 트렌드
API는 점점 더 많은 소프트웨어 개발 트렌드의 중심에 있다. 그 중심에는 대규모 디지털 현대화 노력이 있다. ID 및 인증 솔루션 전문 업체인 큐리티(Curity)의 CTO 제이콥 이데스코그는 “지난 몇 년 동안 대규모 조직에서 웹 앱의 전반적인 현대화가 큰 원동력이었다. 신생 기업과 발빠른 기업은 이미 이 기차에 올라탔지만, 대기업들이 마침내 변화를 시작하면서 광범위한 API 채택을 촉진했다”고 말했다.예를 들어, 최신 모바일 개발은 기계 간 통신을 원활하게 하기 위해 백엔드의 API에 크게 의존하고 있다. API 보안 전문 업체 파이어테일(FireTail)의 CEO 제레미 스나이더는 “모든 모바일 앱은 사실상 클라우드의 백엔드 서비스에 대한 프런트엔드에 불과하며, API를 통해 서로 통신한다"라고 설명했다. 또 클라우드 기반 스토리지와 서비스형 데이터베이스의 사용이 API 중심 개발에 기여했다고 덧붙였다.
API 성장에 영향을 미치는 또 다른 영역은 규정 준수이다. 예를 들어, 전 세계적으로 오픈 뱅킹 규제가 강화되면서 은행은 API를 만들거나 공개해야 했다. 이데스코그는 “많은 은행이 이번에 처음으로 공개 API를 제공했다”고 지적했다. 놀랍게도 오픈 뱅킹 트래커는 현재 500개 이상의 오픈 뱅킹 API를 카탈로그화했다.
그리고 상호 운용성 요구 사항은 금융뿐만 아니라 모든 기업으로 확장되고 있다. 전문 서비스 업체인 런치애니(LaunchAny)의 수석 API 컨설턴트인 제임스 히긴보텀은 “최근 몇 년 동안 기업과 파트너 및 고객 간의 상호운용성 요구로 인해 엔터프라이즈 API 채택이 증가했다"라며, 소프트웨어 재사용도 내부 API 채택의 동기가 된다고 밝혔다.
API는 또한 AI 애플리케이션 개발에도 도움이 된다. APIwiz의 제품 디자인 책임자인 아누라그 슈클라는 “API는 LLM에 정확한 데이터를 제공해 AI 시스템에서 보다 정확한 응답을 가능하게 하는 결정적인 역할을 한다”라고 강조했다. 웹 API는 최근 생성형 AI 물결의 배후에 있는 필수 요소일 뿐만 아니라 수년 동안 노코드/로우코드 개발을 촉진해 왔다.
플랫폼 엔지니어링, 컴포저블 아키텍처, 마이크로서비스 아키텍처, 단일 페이지 애플리케이션, OAuth 기반 보안 시스템, 서드파티 SaaS 애플리케이션 통합, 하이브리드 멀티클라우드 전략 등도 API 의존도를 높이는 데 기여하는 영역으로 꼽을 수 있다. 요컨대, API는 엔터프라이즈 소프트웨어 개발 트렌드 전반에 걸쳐 널리 퍼져 있다.
개발자 포털 프로노빅스(Pronovix)의 CEO 크리스토프 반 톰은 “API는 다른 모든 디지털 인터페이스의 유틸리티와 같은 기본 계층이 되고 있다"라고 강조했다. 톰은 API를 전동 공구를 구동하는 전기에 비유한다. 그리고 생성형 AI 콘텐츠의 시대가 도래함에 따라 정보를 소비하는 프로그래밍 방식이 증가해 API 채택이 더욱 늘어날 것으로 전망했다.
다양한 API 스타일을 사용하는 기업 환경
HTTP 표준이 잘 알려져 있고 많은 도구가 이 패러다임에 적합하기 때문에 REST API 스타일은 여전히 내부 또는 외부 API에 널리 사용되고 있다. 그러나 현대의 기업은 이제 SOAP부터 REST, 그래프QL, gRPC, 이벤트 중심 아키텍처 등에 이르기까지 다양한 API 설계 표준을 채택하고 있다. 런치애니의 히긴보텀에 따르면, 고성능 서비스 간 통신을 위한 gRPC와 개발 속도 향상을 위한 그래프QL의 증가하고 있는 있다. 큐리티의 이데스코그 역시 그래프QL의 사용이 증가하고 있다며, “유용한 경우와 그렇지 않은 경우에 따라 디자인 패턴 환경에 자리를 잡은 것 같다"라고 설명했다.오픈소스 기반의 애플리케이션 개발 및 ID 관리 솔루션 업체 WSO2의 CTO인 아상카 아베싱헤는 “기업은 다양한 영역에 대응하기 위해 여러 API 디자인 스타일과 표준을 채택하는 것이 일반적이다"라고 말한다. 이는 문제 영역마다 고유한 접근 방식이 필요한 경우가 많기 때문이다. 또한 금융, 의료 또는 물류와 같은 영역에 맞는 도메인별 API를 배포할 수도 있다.
목적에 맞는 다양한 API 스타일을 활용하는 것은 기능적인 관점에서 합리적일 수 있으며, 더 많은 기업이 협업을 시작하고 있음을 나타낼 수 있다. 또한 개발자가 도구를 선택할 수 있는 권한을 부여하면 전반적인 개발자 경험에도 도움이 된다. 개발자를 위한 API 포털을 운영하는 HCSS의 API 및 데이터 제품 관리자 미카엘라 할리웰은 “HCSS는 특정 제품 사용례에 대한 팀의 자율성과 개발자의 선호도 및 전문성에 따라 이런 변화가 이뤄지고 있다”고 말했다.
반면에 분열된 API 환경이 항상 계획된 것은 아니다. API 솔루션 전문업체 앰배서더 랩(Ambassador Labs)의 기술 디렉터 매트 보겟은 기업이 자체 표준에 따라 여러 팀을 조정하지 않고 마이크로서비스로 전환할 때 파편화가 쉽게 발생할 수 있다고 지적하며, “사용자 계정을 관리하는 마이크로서비스는 그래프QL API로 지원되는 반면, 결제를 관리하는 마이크로서비스는 REST가 포함된 OpenAPI를 사용할 수 있다"라고 말했다.
운영 측면에서는 이런 파편화가 낭비로 이어질 수 있다. 파이어테일의 스나이더는 “대규모 조직에서는 동일한 사용례를 두 개의 다른 사업부에서 두 개의 다른 개발팀이 두 개의 다른 API 표준을 사용해 해결하는 경우를 흔히 볼 수 있다"고 덧붙였다.
최근 여러 스타일의 사용이 증가하는 것은 API 거버넌스에 대한 표준이 존재하지 않기 때문일 수도 있다. 로우코드 API 관리 플랫폼 업체인 APIwiz의 세일즈 영업 엔지니어링 디렉터인 아딥 타히르는 “기업 내 API 프로그램 전반에 걸쳐 효율적인 표준화가 부족하다”라며, “이는 주로 팀들이 사일로에서 작업하고 서로에 대한 적절한 가시성을 확보하지 못하기 때문이다"라고 지적했다. 이로 인해 발생하는 너무도 흔한 결과는 일관성 없는 문서화인데, 프로덕션 환경의 실제 동작과 일치하지 않는 경우가 많다.
멀티 API 게이트웨이가 운영에 미치는 영향
기업의 내부 API 스타일은 일반적으로 다양할 뿐만 아니라 API를 관리하기 위해 다양한 도구를 사용하는 경우가 많다. WSO2의 아베이싱헤는 “기업이 여러 API 게이트웨이 또는 API 관리 솔루션을 동시에 활용하는 것은 드문 일이 아니다”라고 말한다. 그 이유 중 하나는 비즈니스 전반에서 발생하는 이뤄지는 병렬적인 조달 때문이다. 종종 여러 사업부에서는 특정 요구사항에 따라 또는 API 수명 주기의 다양한 단계를 지원하기 위해 선호하는 솔루션을 선택하게 된다.또한 기업이 시간이 지남에 따라 아키텍처를 발전시키면서 레거시 API를 유지 관리하고 새로운 마이크로서비스 기능을 지원하거나 인그레스 트래픽을 라우팅하기 위해 다양한 도구를 반복적으로 도입할 수 있다. 앰버새더의 보겟은 “API 게이트웨이는 교체하기 어려운 구성 요소이기 때문에 당시 어떤 기술을 선택했든 바꾸지 않을 가능성이 높다"고 설명했다. 이 때문에 인수합병 후 API 솔루션을 교체하기가 까다로운 것이다.
일반적인 기업의 여러 부분이 클라우드 여정의 여러 단계에 있거나 멀티클라우드를 사용하고 있기 때문에 API 관리 요구 사항도 서로 다르다. 큐리티의 이데스코그는 “일부 조직은 마이그레이션 여정에 있으며 쿠버네티스로 이전하고 있지만 아직 이전을 완료하지 않았기 때문에 여러 개의 게이트웨이가 존재할 수밖에 없다”라고 설명했다. 또한 레거시 인스턴스에는 레거시 게이트웨이 솔루션이 필요한 경우가 많다. 할리웰은 “HCSS에서는 특정 온프레미스 인프라에 맞춰 서로 다른 게이트웨이를 사용하는 하이브리드 환경 때문”이라고 밝혔다.
멀티 게이트웨이 환경의 또 다른 이유는 보안과 규정 준수이다. 예를 들어 런치애니의 히긴보텀은 동일한 조직에서 내부, 파트너, 고객 대면 API 클라이언트 네트워크 트래픽을 분리하기 위해 서로 다른 API 게이트웨이 인스턴스를 적용하는 경우를 본 적이 있다. 히긴보텀은 “이런 여러 API 게이트웨이 인스턴스는 여러 수준의 운영에 영향을 미칠 수 있는 연쇄적인 장애를 줄이는 동시에 규제 감사를 수행하는 데 필요한 시간과 자원도 절감할 수 있다”고 설명했다.
간단히 말해, API를 구축하는 팀이 많으면 여러 개의 API 관리 솔루션을 사용하게 될 가능성이 높다. 파이어테일의 스나이더는 “다른 개발자와 보안 팀 모두를 위한 중앙 집중식 문서와 가시성이 충분하다면 이는 허용될 수 있다. 하지만 이는 또한 문제가 될 수 있다”라고 덧붙였다.
다양한 API 환경을 관리하는 방법
많은 IT 책임자가 기술의 무분별한 확산을 방지하기 위해 거버넌스가 필요하다고 생각한다. API 거버넌스는 엉성하게 정의되고 서로 다른 API의 세계를 좀 더 구조적으로 만드는 것을 목표로 한다. 이 개념은 문서화, 설계 표준, 보안 정책, 최신 게이트웨이 및 레거시 관리 솔루션, 엔지니어링 리더십 등을 포괄한다.콩의 팔라디노는 “효과적인 API 포트폴리오 관리에는 모든 서비스를 관리하는 API 게이트웨이를 사용해 각 반복에 대한 거버넌스를 구현하는 것이 포함된다”라고 설명했다. 팔라디노는 인증, 권한 부여, 네트워크 안정성 및 장애 조치와 관련된 표준을 시행하는 데 있어 자동화가 중추적인 역할을 한다고 생각한다.
즉, API 거버넌스는 단순한 단일 도구가 아니라 가장 중요한 전략이다. 파이어테일의 스나이더는 “기본적으로 인벤토리, 수명 주기 관리, 거버넌스와 관련해 필요한 모든 사용례를 즉시 해결할 수 있는 도구는 없다"라고 지적했다. 따라서 스나이더는 API 거버넌스 전략을 개발할 때 특정 도구보다 요구사항의 우선순위를 정할 것을 권장한다.
그렇다면 우선순위가 높은 요구사항은 무엇일까? API 전문가들은 API 거버넌스 이니셔티브를 시작할 때, 특히 다양한 API 스타일과 표준이 포함된 API 인벤토리를 다룰 때 고려해야 할 여러 가지 팁을 제시했다.
문서화와 API 카탈로그 통일
먼저 모든 서비스를 찾아 문서화한다. 가능하면 사양 우선 접근 방식을 채택하는 것이 좋다. 앰배서더 랩의 보겟은 “서로 다른 모든 API를 사양 파일에 설명하는 프로세스를 도입하라”고 강조했다. OpenAPI 정의와 같이 기계가 읽을 수 있는 적절한 API 설명은 검색 가능성을 돕고 스타일 가이드, 린팅 및 계약 테스트에 사용될 수 있다.
정의를 보고 관리할 수 있는 중앙 집중식 공간을 마련하는 것도 중요하다. 이를 API 인벤토리 또는 카탈로그라고 부르기도 한다. 기술 컨설팅 업체 이노큐(INNOQ)의 대표 컨설턴트 에릭 와일드는 “제품 포트폴리오와 기술 문제를 명확하게 분리해야 한다"라고 지적했다. 와일드는 서로 다른 API 게이트웨이와 관리 도구에 대해 단일 제어 영역과 거버넌스 계층을 설정하는 가트너의 연합 API 관리를 따를 것을 권장한다. 궁극적인 목표는 표준 인프라 구성 요소와 게이트웨이 패턴의 전사적 사용을 촉진하기 위해 통합 카탈로그를 만드는 것이다.
다양한 API 게이트웨이의 통합
API 게이트웨이 및 관리 도구와 그 사용 패턴을 정확하게 파악한다. API 관리 전문업체 어피어블(Apiable)의 CEO 알란 크나브는 “첫째, 사일로화된 모든 API 게이트웨이를 연결하고 기존 API를 수집해야 한다. 둘째, 이를 분류하고 소유권을 속성화해 누가 무엇을 책임지고 있는지 확인할 수 있어야 한다”고 강조했다.
API 관리 도구는 대다수 기업에서 확산되고 있다. 따라서 단일 컨트롤 플레인으로 API 게이트웨이를 통합하면 일관성을 개선하고 내부 프랙티스를 표준화할 수 있다. 가트너의 오닐은 많은 기업이 “서로 다른 공급업체의 여러 다른 API 게이트웨이를 사용하기 위한 단일 컨트롤 플레인”을 원한다는 데 동의한다. 하지만 이 개념은 시장에서 제한적으로 지원되고 있다는 것이 오닐의 지적이다.
그럼에도 불구하고 게이트웨이 전반에서 검색과 재사용성을 촉진하는 효과적인 방법이 있다. 프로노빅스의 톰은 “최소한 여러 팀의 API를 조직 전체에서 구성하고 재사용할 수 있도록 통합 API 관리가 가능한 통합 개발자 포털이 있어야 한다"라고 강조했다. 단일뷰를 구현하면, API 전반의 트래픽을 모니터링하는 데도 도움이 된다.
설계 및 보안 패턴의 중앙 집중화
중앙 집중식 거버넌스 프레임워크는 API 수명 주기의 여러 영역에 걸쳐 있으며, 기업 내부의 API 구현 센터가 주도하는 명확한 조직 표준에 달려 있다. HCSS의 할리웰은 “API 표준을 정의하고 시행하고 의사 결정을 내리기 위한 중앙 집중식 프레임워크를 구축하는 것부터 시작하라”며, “이는 기술 책임자 그룹이 될 수도 있고 거버넌스를 감독하는 특정 팀이 될 수도 있다”고 설명했다.
API 거버넌스는 레거시 서비스에서 폐쇄회로처럼 반복되지만, 이상적으로는 그린필드 개발을 위한 설계 우선 프로세스에 포함되는 것이 좋다. APIwiz의 타히르는 “API 프로그램의 성숙도를 높이는 유일한 방법은 설계, 빌드, 런타임 단계에 걸쳐 체계적인 거버넌스 프레임워크를 채택하는 것이다. 즉, 조직은 설계 및 구현 전에 API 전략을 먼저 정의하고 설계해야 하는 API 정의 및 설계 우선 접근 방식을 따라야 한다”라고 강조했다.
API 거버넌스 프레임워크는 보안도 고려해야 한다. 보안팀에서 가장 중요하게 생각하는 것은 통합된 고객 식별자와 API 요청에 대한 잘 정의된 권한 집합에 초점을 맞춘 깨끗한 ID 계층을 구축하는 것이다. 타히르는 “이를 통해 더 나은 권한 부여가 가능하며, 이는 결국 무엇이 사용되고 누가 액세스할 수 있는지에 대한 가시성이 향상된다는 것을 의미한다"라고 설명했다. 액세스 제어 외에도 API 표준에 대한 린팅 적용, 모니터링 및 분석 도구 활용, 인프라 보호를 위한 속도 제한 적용을 권장하는 전문가도 있다.
잊어서는 안되는 개발자 경험
API 거버넌스팀은 피드백 메커니즘을 구축하고 개발자를 옹호해야 한다. 런치애니의 히긴보텀은 “이는 API 디자인팀이 결과 기반 디자인 프로세스를 통해 솔루션을 고민하고 API 사용자와 공감해 가장 적합한 API 디자인 스타일을 선택할 수 있도록 안내하는 것을 의미한다”라고 말한다. 예를 들어, 설계자가 업계 표준과 공급업체 기반 표준을 차별화할 수 있도록 지원하면 의사 결정을 간소화할 수 있다.
긍정적인 개발자 경험에는 API 검색과 거버넌스 규칙 적용의 자동화가 포함된다. 파이어테일의 스나이더는 “릴리즈 프로세스가 엄격하게 통제되지 않는 한, 가장 좋은 방법은 자동화된 도구를 사용해 API에 대한 데이터와 해당 사용례에 필요한 올바른 구성 데이터를 수집하는 것이다"이라고 강조했다. 액스웨이의 오튼은 “API 업체가 CI/CD 파이프라인에서 자동화를 통해 운영 방식의 일부로 API를 일관되게 관리할 수 있도록 지원하라”고 덧붙였다.
효과적인 API 거버넌스의 이점
API 거버넌스는 서로 다른 API 포트폴리오에 많은 긍정적인 결과를 제공할 수 있다. WSO2의 아베이싱헤는 “효과적인 API 거버넌스는 API 전반의 일관성 및 표준화 보장, 재사용성 및 상호 운용성 촉진, 보안 및 규정 준수 조치 강화 등 여러 가지 이점을 제공한다"라고 말한다. API 설계 및 구현을 조직 전반에서 보다 일관되고 협업적인 프로세스로 만들면 복잡성과 통합 문제를 줄일 수 있다.규정 준수 및 보안 개선
가장 주목할 만한 것은 API 거버넌스가 규정 준수 및 보안에 미치는 영향이다. 콩의 팔라디노는 “효과적인 API 거버넌스는 안전하고 안정적이며 확장 가능한 디지털 서비스를 보장해 비즈니스 목표와 규정 준수를 지원한다"라고 강조했다. 거버넌스는 모든 API가 엄격한 표준을 준수하고, 취약성으로부터 보호되며, GDPR 및 HIPAA와 같은 규정을 충족하도록 보장하는 데 필요하다.
적절한 API 거버넌스 기반이 있으면 섀도우 IT를 피할 수 있다. 이데스코그는 “API를 게시하는 방법과 API가 액세스할 수 있는 신원 데이터에 대한 명확한 구조를 제공하지 않으면 여러 팀이 자체 솔루션을 개발해 이미 해당 기능이 있는 플랫폼에 새로운 시스템을 도입하게 된다”고 지적했다.
잘못 정의된 액세스 제어 정책은 많은 API 이니셔티브의 골칫거리이다. 인증 및 권한 부여 오류는 OWASP의 상위 10가지 API 위험 목록에서 높은 순위를 차지한다. 이런 영역을 다루는 거버넌스는 점점 더 API로 눈을 돌리고 있는 공격자에 대응하는 데 도움이 된다. APIwiz의 타히르는 “API는 민감한 데이터와 시스템에 대한 진입점인 경우가 많다. 최근 티모바일과 델에서 발생한 데이터 유출과 같은 사건은 악의적인 공격자들이 항상 지켜보고 있다는 것을 보여준다”고 덧붙였다.
자원과 노력의 효율적인 활용
잘 관리된 API는 보안 및 규제 요구사항을 해결하는 것 외에도 디지털 환경 전반에서 일관성을 높일 수 있다. 이노큐의 와일드는 관리되지 않는 API는 “플랫폼에서 베스트 프랙티스를 확립하는 대신 동일한 문제를 여러 번 해결하기 때문에 자원 낭비를 초래할 수 있다”고 지적한다. 적절한 API 거버넌스를 통해 중복 작업을 없애고 프로젝트에 필요한 API를 찾는 시간을 줄일 수 있다. 스나이더는 “구현하려는 기능에 대한 API가 이미 존재하는 경우가 많다. 거버넌스가 잘 갖춰져 있다면 이를 찾는 데 도움이 되는 인벤토리에 액세스할 수 있을 것이다”라고 설명했다.
히긴보텀은 “많은 경우, 라이선스 및 유지보수 비용을 줄이면서 프로세스를 통합하고 단순화하기 위해 확산을 줄이기 위한 노력이 진행 중이다"라고 덧붙였다. 이외에도 더 빠른 소프트웨어 제공, 라이선스 및 유지 관리 비용 절감, 비즈니스 효과 모니터링 용이, 수익화 잠재력 향상, 전반적으로 더 간결한 결과 등을 이점으로 꼽을 수 있다.
일관된 API 설계
API 거버넌스는 또한 더욱 일관된 내부 설계 표준을 촉진할 수 있다. 보겟은 “견고한 거버넌스는 API가 일관되고 예측 가능한 패턴을 사용하도록 보장해 API가 서로 그리고 외부 인터페이스와 쉽게 작동할 수 있도록 한다"라고 말한다. API 스타일 가이드, 린팅 규칙, 계약 테스트는 결함을 줄이거나 누락된 보안 체계를 발견하는 데 도움이 될 수 있다. 보겟은 “거버넌스가 없으면 이런 세부 사항을 소홀히 다뤄 심각한 위험을 초래할 가능성이 매우 높다”고 지적했다.
이렇게 표준을 설정하고 가능한 경우 설계 검토 및 점검을 자동화하면 API 설계 프로세스에 큰 도움이 된다. 또한 이런 조치는 API 수명 주기에서 반복적인 작업을 줄이고 향후 개발에 정보를 제공할 수 있다. 히긴보텀은 “효과적인 API 거버넌스를 통해 팀은 신규 또는 업데이트된 API의 설계 및 제공에 착수할 때 기본 결정을 쉽게 내릴 수 있다. 또한 조직이 과거의 노력에서 얻은 교훈을 포착하는 데에도 도움이 된다”고 설명했다.
더 나은 협업 및 비즈니스 연계
마지막으로, API 거버넌스 프레임워크가 마련되어 있으면 내부 또는 외부 사용자 등 다른 이해관계자와의 협업이 개선된다. 할리웰은 “API 거버넌스는 모두가 같은 방향으로 나아갈 수 있게 해준다. 일관되고 잘 문서화된 API를 제공하면 사용자 경험이 향상되고 API가 작업하기 쉽다는 평판을 얻을 수 있다"라고 강조했다.
내부 지식 공유는 비효율을 줄이고 편법을 피할 수 있다. 또한 비즈니스 이해관계자의 API 인지도 향상에도 도움이 된다. 어피어블의 크나브는 “가장 큰 이점은 비즈니스 관리자가 어떤 API를 사용할 수 있고 어떤 팀이 이를 관리하고 있는지 이해할 수 있는 비즈니스 수준에서 얻는다"라며, “API가 거버넌스가 거의 또는 전혀 없는 사일로에 존재하는 경우, 개발자는 비즈니스 회의에서 가능한 것과 불가능한 것을 설명해야 하는 경우가 많다"라고 말했다.
API 거버넌스의 미래
API 환경은 기업마다 매우 다양하며, 거버넌스를 중앙 집중화하려는 노력은 아직 진행 중이다. 히긴보텀은 “API 포트폴리오가 증가함에 따라 API 거버넌스의 필요성이 더욱 커지고 있다. 지난 10년 동안 마이크로서비스, 서버리스 기능, SPA(Single-Page Applications)의 도입으로 엔터프라이즈 API 포트폴리오의 규모가 몇 배로 커졌다”고 말했다.미래를 내다보는 다른 사람들은 업계 전반의 API 표준이 더 많아질 것으로 전망한다. 할리웰은 “OAuth, 그래프QL, OpenAPI, AsyncAPI와 같은 표준 프로토콜을 채택하려는 움직임이 더욱 강해질 것으로 보인다”고 말했다. 또한 AI가 API 설계를 등급화하고 예측 분석 및 자동화된 규정 준수와 같은 자동화를 추진해 수동 거버넌스 노력을 줄이는 데 중요한 역할을 할 것으로 본다.
동시에 AI 기능 통합을 서두르다 보면 이미 과부하가 걸린 API 카탈로그가 더 악화될 수 있다. 히긴보텀은 “생성형 AI는 API 포트폴리오의 무분별한 확산에 또 하나의 기폭제 역할을 할 것”이라며, “문제는 API 경제가 오늘날 우리가 목격하고 있는 API 확산 문제를 해결하는 데 필요한 인력, 프로세스, 도구를 구축하는 데 가치를 둘 것인지 여부이다”라고 지적했다.
떠오르는 플랫폼 엔지니어링 분야가 이 질문에 답하는 데 도움이 될 수 있다. 또한 기존의 도구와는 별개의 통합된 카탈로그가 더 많이 등장할 것이다. 프로노빅스의 톰은 “조직은 검색 기능과 검색 가능성을 강화하는 것부터 시작해야 한다. 보안 및 관리 목적의 API 레지스트리는 해당 개발자 포털과 구별될 수 있다”고 강조했다.
보안 요구사항이 향후 API 거버넌스에서 더 큰 역할을 할 것으로 보는 사람들도 있다. 이데스코그는 “향후 몇 년 동안 거버넌스는 권한 부여의 관점에서 바라보게 될 것이라고 생각한다. 더 나은 인증 도구는 더 강력한 거버넌스를 가능하게 할 것이며, API 경제의 거버넌스 측면에 큰 동력이 될 것”이라고 전망했다.
이를 위해 업계 주도의 보안 규정이 전반적으로 더 많은 API 거버넌스 프랙티스를 장려할 것으로 예상된다. APIwiz의 슈클라는 “오픈 뱅킹 및 의료 표준과 같은 외부 규제의 증가와 AI 데이터 보안에 대한 우려가 커지면서 조직이 API 이니셔티브에서 엄격한 거버넌스를 우선시하게 될 것이라고 확신한다”고 말했다.
그러나 API 거버넌스의 요구사항은 하나의 도구로 해결할 수 없기 때문에 기업의 문화적 변화도 필요하다. 이는 경우에 따라 적절한 책임자에게 API 표준을 이끌도록 맡기는 것을 의미한다. 어피어블의 크나브는 “API가 올바르고 최신 상태로 작동하는지 관리하는 API 제품 관리자가 존재한다는 사실만으로도 제대로 구현되면 놀라운 일이 일어날 것”이라고 말했다.
요컨대, API 거버넌스는 다각적인 기술적 딜레마에 답해야 하는 조직 전반의 API 사용에 대한 가시성과 제어에 대한 다각적인 접근 방식을 요구한다. 보겟은 “거버넌스, 표준화 또는 플랫폼 전략 등 어떻게 부르든 API가 확산되고 컴포저블하고 유연한 마이크로서비스 아키텍처에 대한 필요성이 증가함에 따라 API 경제에서 거버넌스는 더욱 중요해질 것”이라고 강조했다.
editor@itworld.co.kr
Bill Doerrfeld editor@itworld.co.kr
저작권자 한국IDG & ITWorld, 무단 전재 및 재배포 금지
이 기사의 카테고리는 언론사의 분류를 따릅니다.
기사가 속한 카테고리는 언론사가 분류합니다.
언론사는 한 기사를 두 개 이상의 카테고리로 분류할 수 있습니다.
언론사는 한 기사를 두 개 이상의 카테고리로 분류할 수 있습니다.
