적응형 거버넌스가 API 개발자에게 필요한 자율성을 제공합니다

NGINX | 2022년 11월 10일

오늘날의 기업은 전 세계에 분산된 팀이 여러 배포 환경에서 API와 마이크로서비스를 구축하고 배포하는 형태로 운영되는 경우가 많습니다. F5의 「애플리케이션 전략 현황 보고서」에 따르면, 조직의 81%가 퍼블릭 클라우드, 프라이빗 클라우드, 온프레미스, 엣지를 아우르는 세 가지 이상의 환경에서 운영되고 있습니다.

이러한 복잡한 멀티 클라우드 아키텍처의 안정성과 보안을 보장하는 것은 이를 유지 관리하는 플랫폼 운영 팀이 직면한 주요 과제입니다. F5 보고서의 설문 조사에 참여한 소프트웨어 엔지니어링 리더들에 따르면, 플랫폼 운영 팀이 직면한 멀티 클라우드 과제 중 가시성(45%)과 일관된 보안(44%)이 가장 큰 비중을 차지했습니다.

오늘날 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는 보안과 안정성을 유지하고, 해당 API에 액세스해야 하는 팀과 사용자가 원활하게 이용할 수 있도록 관리되어야 합니다.

어떤 API 거버넌스 모델을 사용할 수 있나요?

API 거버넌스를 정의하고 적용하는 방법은 다양합니다. NGINX에서는 일반적으로 고객이 다음 두 가지 모델 중 하나를 적용하는 경우가 많습니다:

중앙 집중식 – 중앙 팀이 변경 사항을 검토하고 승인합니다. 운영 규모에 따라 이 팀이 병목 지점이 되어 진행 속도를 늦출 수 있습니다.
분산형 – 개별 팀이 자율적으로 API를 구축하고 관리합니다. 이를 통해 출시 기간을 단축할 수 있지만 전반적인 보안과 안정성이 저하될 수 있습니다.

하지만 기업이 API 우선 여정을 발전시켜 나가면서 프로덕션 환경의 API 수가 늘어나면 두 모델 모두 한계를 드러내기 시작합니다. 중앙 집중형 모델은 대개 여러 단계의 검토와 승인을 요구하는 획일적인 접근 방식을 적용하려 합니다. 이로 인해 개발팀의 업무 속도가 느려지고 마찰이 발생하며, 답답함을 느낀 개발자들은 때로 요구 사항을 우회할 방법을 찾기도 합니다(악명 높은 ‘섀도 IT’).

또 다른 모델인 분산형 거버넌스는 처음에는 API 개발자에게 효과적이지만, 시간이 지날수록 복잡성이 증가합니다. API를 배포하는 여러 팀이 자주 소통하지 않으면 API마다 설계와 작동 방식이 달라지고, 버전 변경으로 인해 서비스 간 장애가 발생하며, 팀과 서비스 전반에 걸쳐 보안이 일관되지 않게 적용되는 등 전반적인 경험이 API마다 제각각이 됩니다. API를 구축하는 팀의 경우, 추가 작업과 복잡성으로 인해 결국 중앙 집중형 모델과 마찬가지로 개발 속도가 현저히 느려집니다.

클라우드 네이티브 애플리케이션은 개별 마이크로서비스가 서로 통신하고 요청을 보낸 곳으로 응답을 전달하기 위해 API에 의존합니다. 기업들이 유연성과 민첩성을 확보하기 위해 마이크로서비스를 계속 도입함에 따라, API의 무분별한 확산은 사라지지 않을 것입니다. 따라서 이처럼 복잡하고 끊임없이 변화하는 환경에서는 API를 관리하기 위한 새로운 접근 방식이 필요합니다.

적응형 거버넌스로 API 개발자의 역량 강화

다행히 더 나은 방법이 있습니다. 적응형 거버넌스는 API 개발자에게 자율성을 부여하는 동시에 플랫폼 운영 팀이 전사 API의 안정성과 보안을 보장하는 데 필요한 통제력을 확보할 수 있는 대안 모델을 제공합니다.

적응형 거버넌스의 핵심은 기업 전반의 민첩성을 확보하기 위해 통제(일관성 유지의 필요성)와 자율성(현지에서 의사 결정을 내릴 수 있는 능력) 사이의 균형을 맞추는 것입니다. 실제로 적응형 거버넌스 모델은 의사 결정 권한을 분리하여 여러 팀에 분산합니다.

플랫폼 운영 팀은 공유 인프라(API 게이트웨이 및 개발자 포털)를 관리하고 API 전반의 일관성을 보장하기 위한 글로벌 정책을 수립합니다. 반면 API를 구축하는 팀은 해당 서비스 또는 사업 부문의 분야별 전문가 역할을 합니다. 이들은 각자의 비즈니스 상황에 따른 요구 사항을 충족할 수 있도록 역할 기반 액세스 제어(RBAC), 서비스 요청 속도 제한 등 API에 대한 로컬 정책을 수립하고 적용할 권한을 부여받습니다.

적응형 거버넌스를 통해 각 팀이나 사업 부문은 조직의 공유 인프라를 활용하면서 자체 워크플로를 정의하고 필요한 통제 수준을 적절히 조정할 수 있습니다.

NGINX로 API를 위한 적응형 거버넌스 구현

API 전략을 계획하고 구현할 때 다음 모범 사례를 따라 조직에 적응형 거버넌스를 도입하세요:

공유 인프라 제공 – 팀에서 API 프록시와 문서를 게시할 수 있도록 API 게이트웨이와 개발자 포털에 대한 액세스 권한을 제공합니다
팀에 자율성 부여 – 팀이 공유 작업 공간에서 API를 온보딩하고 수명 주기를 관리할 수 있도록 지원
글로벌 정책과 로컬 제어 간의 균형 유지 – 공유 인프라 전반에 글로벌 정책을 적용하는 동시에 각 팀이 서비스별로 세부적인 제어 권한을 갖도록 지원

이제 F5 NGINX Management Suite의 일부인 API Connectivity Manager를 사용하여 이러한 사용 사례를 구현하는 방법을 살펴보겠습니다.

공유 인프라 제공

조직 내 여러 팀이 API를 구축하고 있으며, 인증 및 권한 부여, mTLS 암호화 등 유사한 기능을 각자의 마이크로서비스에 포함해야 합니다. 또한 내부 팀, 비즈니스 파트너, 외부 개발자 등 API 소비자가 문서와 버전 관리 기능을 이용할 수 있도록 해야 합니다.

각 팀이 자체 솔루션을 구축하도록 요구하는 대신, 플랫폼 운영 팀에서 공유 인프라에 대한 액세스를 제공할 수 있습니다. API Connectivity Manager의 모든 작업과 마찬가지로 UI 또는 완전한 선언형 REST API를 사용해 단 몇 분 만에 이를 설정할 수 있으며, API를 사용하면 API Connectivity Manager를 CI/CD 파이프라인에 통합할 수 있습니다. 이 게시물에서는 몇 가지 일반적인 워크플로를 설명하기 위해 UI를 사용합니다.

API Connectivity Manager는 인프라와 서비스라는 두 가지 유형의 워크스페이스를 지원합니다. 플랫폼 운영 팀은 인프라 워크스페이스를 사용하여 API 게이트웨이 클러스터 및 개발자 포털 클러스터 형태의 공유 인프라를 등록하고 관리합니다. API 개발자는 서비스 워크스페이스를 사용하여 API와 문서를 게시하고 관리합니다.

공유 인프라를 설정하려면 먼저 인프라 워크스페이스를 추가합니다. 왼쪽 탐색 열에서 인프라를 클릭한 다음 탭 오른쪽 상단의 + 추가 버튼을 클릭합니다. 워크스페이스의 이름을 지정합니다(여기서는 간단한 “Hello, World!” API를 구축하는 가상의 팀을 뜻하는 team-sentence를 사용합니다).

그림 1: 인프라 워크스페이스 추가

다음으로 워크스페이스에 환경을 추가합니다. 환경에는 API 게이트웨이 클러스터와 개발자 포털 클러스터가 포함됩니다. 워크스페이스 이름을 클릭한 다음 … 아이콘을 작업 열에서 클릭하고 드롭다운 메뉴에서 추가를 선택합니다.

그림 2와 같이 환경 만들기 패널이 열립니다. 이름 필드와 선택적으로 설명 필드를 입력하고 환경 유형(프로덕션 또는 비프로덕션)을 선택한 다음, 추가하려는 인프라(API 게이트웨이 클러스터, 개발자 포털 클러스터 또는 둘 다)의 + 추가 버튼을 클릭합니다. 환경 설정을 완료하려면 만들기 버튼을 클릭합니다. 전체 지침은 API Connectivity Manager 설명서를 참조하세요.

그림 2: 환경 생성 및 인프라 온보딩

팀에 자율성 부여

사업 부문, 지리적 지역 또는 기타 논리적 경계를 기준으로 팀을 논리적으로 분리하는 것은 합리적입니다. 단, 팀이 성공하는 데 필요한 도구에 접근하지 못하게 해서는 안 됩니다. 공유 인프라를 이용한다고 해서 팀이 전역 수준의 활동까지 신경 써야 하는 것은 아닙니다. 대신 팀이 자체 요구 사항을 정의하고, 로드맵을 수립하며, 마이크로서비스를 구축하는 데 집중할 수 있도록 해야 합니다.

팀이 체계적으로 업무를 수행할 수 있도록 플랫폼 운영 팀은 서비스 워크스페이스를 제공하여 각 팀이 서비스와 문서를 구성하고 운영할 수 있게 할 수 있습니다. 이러한 워크스페이스는 논리적 경계를 설정하고 서비스 개발을 위한 개발, 테스트, 프로덕션 등의 다양한 환경에 대한 액세스를 제공합니다. 이 과정은 이전 섹션에서 만든 인프라 워크스페이스를 생성하는 것과 유사합니다.

먼저 왼쪽 탐색 열에서 서비스를 클릭한 다음, 탭 오른쪽 상단의 + 추가 버튼을 클릭합니다. Workspace에 이름을 지정하고(여기서는 “Hello, World” 서비스에 api-sentence를 사용), 필요한 경우 설명과 연락처 정보를 입력합니다.

그림 3: 서비스 워크스페이스 만들기

이제 API 개발자를 초대하여 개발자를 위해 만든 워크스페이스에 프록시와 문서를 게시하도록 할 수 있습니다. API 프록시와 문서를 게시하는 방법에 대한 전체 지침은 API Connectivity Manager 설명서를 참조하세요.

글로벌 정책과 로컬 제어 간의 균형 유지

적응형 거버넌스를 구현하려면 글로벌 정책을 적용하는 것과 팀이 민첩성을 높이는 의사 결정을 내릴 수 있도록 권한을 부여하는 것 사이에서 균형을 유지해야 합니다. Platform Ops에서 적용하는 글로벌 설정을 정의하고, API 개발자가 사용할 도구와 내릴 수 있는 의사 결정의 범위를 규정하는 ‘가드레일’을 설정하여 책임을 명확히 구분해야 합니다.

API Connectivity Manager는 공유 인프라에 적용되는 전역 정책과 API 프록시 수준에서 관리되는 세분화된 제어 기능을 함께 제공합니다.

API Connectivity Manager에서 사용할 수 있는 전역 정책은 다음과 같습니다:

오류 응답 형식 – API 게이트웨이의 오류 코드 및 응답 구조 사용자 지정
로그 형식 – 액세스 로깅을 활성화하고 로그 항목의 형식을 사용자 지정합니다
OpenID Connect – OpenID Connect 정책으로 API 액세스를 보호합니다
응답 헤더 – 응답에 헤더를 포함하거나 제외합니다
요청 본문 크기 – 수신 API 페이로드의 크기를 제한합니다
인바운드 TLS – API 클라이언트와의 TLS 연결에 대한 정책을 설정합니다
백엔드 TLS – TLS를 사용하여 백엔드 서비스와의 연결을 보호합니다

API Connectivity Manager에서 사용할 수 있는 API 프록시 정책은 다음과 같습니다:

허용되는 HTTP 메서드 – 사용할 수 있는 요청 메서드를 정의합니다(GET, POST, PUT 등).
액세스 제어 – 다양한 인증 및 권한 부여 기법(API 키, HTTP 기본 인증, JSON 웹 토큰)을 사용하여 API에 대한 액세스를 보호합니다.
백엔드 상태 확인 – 지속적으로 상태를 확인하여 백엔드 서비스에 대한 요청 실패 방지
CORS – 외부 도메인의 클라이언트가 리소스에 제어된 방식으로 액세스할 수 있도록 설정
캐싱 – 캐싱 정책으로 API 프록시 성능 향상
프록시 요청 헤더 – 선택한 헤더를 백엔드 서비스로 전달
속도 제한 – 수신 요청을 제한하고 API 워크로드를 보호합니다

다음 예에서는 UI를 사용하여 API Gateway Proxy와 백엔드 서비스 간의 통신을 보호하는 정책을 정의합니다.

왼쪽 탐색 열에서 인프라를 클릭합니다. 편집하려는 API 게이트웨이 클러스터가 포함된 환경의 이름을 클릭하면 해당 탭에 그 환경의 API 게이트웨이 클러스터와 개발자 포털 클러스터가 표시됩니다.

그림 4: API Gateway 클러스터 및 Developer Portal 클러스터의 전역 정책 구성

정책을 적용할 API Gateway 클러스터의 행에서 … 아이콘을 작업 열에서 클릭하고 드롭다운 메뉴에서 고급 구성 편집을 선택합니다. 왼쪽 열에서 전역 정책을 클릭하면 구성할 수 있는 모든 전역 정책 목록이 표시됩니다.

그림 5: API Gateway 클러스터에 대한 정책 구성

TLS 백엔드 정책을 적용하려면 해당 행의 오른쪽 끝에 있는 … 아이콘을 클릭하고 드롭다운 메뉴에서 정책 추가를 선택합니다. 요청된 정보를 입력하고 인증서를 업로드한 다음 추가를 클릭합니다. 그런 다음 저장 및 제출 버튼을 클릭합니다. 이제부터 API Gateway 클러스터와 백엔드 서비스 간의 트래픽이 TLS로 보호됩니다. 전체 지침은 API Connectivity Manager 설명서를 참조하세요.

요약

API 거버넌스를 계획하고 구현하는 것은 API 전략의 성공을 보장하는 데 매우 중요한 단계입니다. 분산형 모델을 지향하고 적응형 거버넌스를 활용해 각 팀과 API의 고유한 요구 사항을 충족하면, API와 클라우드 네이티브 환경의 높은 생산성을 뒷받침하는 속도와 민첩성을 유지하면서도 일관된 거버넌스를 확장하여 적용할 수 있습니다.