조직은 DevOps를 도입하면서 의사 결정과 작업을 개발 수명 주기 초기 단계로 이동하면 개발 프로젝트의 위험을 식별하고 줄일 수 있음을 인식했습니다. 이 프로세스를 '원점 회귀'라고 합니다. 그 결과 오늘날의 개발자들은 고객에게 기능을 제공하기 위해 더 많은 작업을 수행할 것이 요구되고 있습니다. 또한 확장 가능한 소프트웨어 아키텍처를 설계하고 안전하고 성능이 우수한 코드를 개발하고 인프라를 설정하고 테스트를 수행하며 애플리케이션을 배포 및 모니터링해야 합니다. 이러한 접근 방식에는 많은 이점이 있지만 개발자가 코드를 작성하는 데 집중할 시간이 줄어들어 소프트웨어 품질에 원치 않는 영향을 미치거나 새로운 기능의 출시가 지연될 수 있습니다.
DevOps 엔지니어가 외부 고객에 대한 소프트웨어 배포를 최적화하는 데 집중하는 것처럼, 플랫폼 엔지니어는 내부 고객(즉, 개발자)에게 일관되고 원활한 경험을 제공하는 플랫폼을 빌드하는 데 중점을 둡니다. 내부 플랫폼 빌드는 어떤 모습일까요? 일상적인 작업에는 개발자에게 자율성을 부여하는 표준화된 환경을 만드는 작업이 포함되어야 합니다. 이렇게 하면 새로운 서비스를 개발하고 배포할 때 내부 고객의 인지 과부하를 줄일 수 있습니다. 내부 개발자 플랫폼에는 개발자를 위한 최적의 경로를 만들 수 있도록 특정 결정, 표준, 프로세스가 포함됩니다. 이를 통해 개발자는 코딩에 집중할 수 있으며 결국 고객을 위한 더욱 우수한 소프트웨어 환경을 만들 수 있습니다. 즉, 조직은 왼쪽으로 이동하는 것 외에도 '하향 이동'하여 더 많은 책임을 플랫폼에 밀어내야 합니다.
개발자가 플랫폼을 최대한 활용하기 위해 API를 개발할 때는 다음을 수행해야 합니다.
우수한 응용 분야는 신중하고 일관된 상품과 서비스를 제공하는 것입니다. 또한, 복잡함을 숨기고 원활하고 즐겁게 작동하도록 합니다. 궁극적인 목표는 항상 사용자에게 만족스러운 경험을 제공하는 것이며 성공적인 제품을 만드는 조직은 항상 사용자를 염두에 두고 '외부'에서 시작합니다. 개발자가 영감을 주는 애플리케이션을 만들 수 있는 역량을 강화해야 우수한 경험을 제공할 수 있으며 이를 위해서는 우수한 API를 제공해야 합니다. 우수한 API는 조직 복잡성을 추상화하므로 개발자가 사용자 경험을 빌드하는 데 집중할 수 있습니다. 그러나 훌륭한 API는 그냥 갑자기 나타나는 것이 아닙니다. 또한 이러한 조직은 API를 디지털 제품처럼 취급하여 제작과 관리에 전체 팀의 역량을 플랫폼의 핵심 기능으로 활용하고 있습니다.
개발자가 디지털 제품을 빌드하는 데 활용하는 플랫폼도 제품으로 취급되어야 합니다. 따라서 플랫폼 엔지니어링팀은 사용자, 즉 — 개발자 —의 요구사항을 이해하고 그들에게 즐거운 경험을 제공하기 위해 사용자와 함께 '아웃사이드 인' 접근 방식을 취해야 합니다. 플랫폼 엔지니어는 개발자가 프런트엔드 앱, 백엔드 서비스 개발이나 API 제작 및 소비 여부에 관계없이 소프트웨어를 빌드할 때 활용할 내부 템플릿과 도구를 생성, 빌드, 통합해야 합니다. 팀 역할은 조직에서 만들고 있는 소프트웨어를 테스트, 보호, 배포 및 관리하는 방법을 설정하는 것입니다. 사일로를 제거하면 더욱 우수한 API를 만들 수 있습니다.
소프트웨어 개발의 다른 측면과 마찬가지로 팀은 개발자가 공통적으로 우려하는 API 아키텍처 요소를 개별적으로 다시 만들지 않도록 해야 합니다. 대신 즉시 활용할 수 있는 간단한 도구와 구성 옵션 세트를 제공하세요. 플랫폼에서 가장 잘 처리하는 API 관리에는 다음이 포함되지만 이에 국한되지는 않습니다.
Apigee 플랫폼팀과 내부 고객에게 API를 보다 효과적으로 빌드, 관리, 운영할 수 있는 일련의 기능을 제공하는 API 관리 플랫폼입니다.
Apigee를 사용하면 API 제작자가 개발자에게 더욱 강화된 보안, 탐색, 관측 가능성을 제공함으로써 비즈니스 로직을 노출하는 API를 빌드하고 관리할 수 있습니다. 제품팀은 API를 다양한 소비 행동을 가진 유연한 '제품' 집합으로 묶어 게시할 수 있습니다. 또한 Apigee는 API 소비자가 어떤 API 제품을 사용할 수 있는지 쉽게 알아보고 문서를 탐색하고 빠르게 온보딩하여 최소한의 마찰로 애플리케이션 개발을 시작할 수 있도록 지원합니다. 이제 Apigee는 생성형 AI의 도움을 받아 API 개발 방식도 재구상하고 있으며 이를 통해 숙련된 개발자와 신규 개발자 모두 시스템 간의 통신을 원활하게 관리할 수 있습니다.
Apigee에서의 API 관리 프로세스는 API 프록시를 빌드하는 것부터 시작합니다. API 프록시는 개발자가 백엔드 서비스에 액세스하는 데 사용하는 인터페이스를 노출합니다. 개발자는 이러한 서비스를 직접 사용하는 대신 제작자가 만든 Apigee API 프록시에 액세스합니다. 프록시를 사용하면 실제 API에서 백엔드를 분리하여 고객에게 더욱 안정적인 환경을 제공할 수 있습니다. 이렇게 하면 고객에게 영향을 미치지 않고도 백엔드를 업데이트하고 변경할 수 있습니다. API팀은 프록시가 제공하는 기능을 활용하여 API 동작을 보호하고 제어할 수 있습니다. 생산 팀과 소비 팀 수가 증가함에 따라 API 프로그램을 성공적으로 확장하려면 플랫폼에서 원활한 자동화 파이프라인과 재사용 가능한 기능을 통해 최적의 경로를 지원해야 합니다.
회사에서 추가 수익을 창출할 수 있는 새 API를 만든다고 가정해 보겠습니다. 팀에서 개발자와 함께 이러한 새 API를 만드는 방법에 대한 포괄적인 전략을 수립합니다. 이제 팀에서는 이러한 요구사항을 취하여 공통 정책, 트래픽 라우팅 제어, 오류 처리 규칙을 포함하는 독자적인 API 템플릿의 형태로 표준화합니다. 사용 사례에 따라 각 사용 사례를 다루는 템플릿 세트가 있을 수 있습니다. 온프렘 환경에서 실행되는 기존 백엔드에 캐싱 또는 변환 정책 제공이 일반적인 사용 사례에 해당할 수 있습니다. apigee-samples 저장소는 시작할 수 있는 훌륭한 장소이며 DevRel 저장소에도 참고용으로 샘플 프록시 템플릿이 포함되어 있습니다. 플랫폼팀은 정책 템플릿 외에도 개발자가 프록시를 빌드하고 배포하는 데 사용할 파이프라인을 표준화할 수 있습니다. Apigee는 이러한 최적의 경로를 지원하는 CI/CD 파이프라인을 만드는 데 활용할 수 있는 관리 API와 도구를 제공합니다. Google에서는 출발점으로 사용할 수 있는 참조 구현을 게시했습니다.
소스 코드의 MVP API 프록시 파이프라인은 다음과 유사합니다.
한 단계 더 나아가 파이프라인에서 Apigee의 API 허브와 같은 내부 카탈로그에 API를 등록할 수 있습니다. API 허브는 조직이 API 관련 정보를 문서화, 검색, 게시하는 데 도움이 되는 도구입니다. 허브에 기본 제공되는 레지스트리에는 수명 주기를 진행하는 동안 API의 각 버전에 대한 자세한 정보(예: 관련 사양, 현재 배포, 소유권 및 연락처 정보, 종속 항목 등)가 포함되어 있습니다. 고객은 기본 제공 속성 외에도 사용자가 검색하고 필터링할 수 있는 자체 분류를 정의할 수 있습니다. API 허브에서는 품질과 일관성을 더욱 향상시키기 위해 스코어카드도 제공합니다. 개발자는 이 카드를 통해 API 설계가 예상 표준을 어떻게 충족하는지 더 잘 파악할 수 있습니다. API 허브 레지스트리는 백스테이지와 같은 내부 개발자 포털이나 기타 내부 개발자 플랫폼 도구와 동기화될 수 있습니다.
마지막으로 외부 소비자의 경우 파이프라인에서 추가 문서와 사용자 가이드와 함께 API 제품을 공개 API 포털에 게시하므로 스타일 지정과 브랜딩을 맞춤설정할 수 있습니다.
API를 대규모로 빌드할 때는 공통 정책을 재사용하여 개발 속도를 높이고 전송 시간을 줄이는 것이 좋습니다. Apigee에서는 공유 흐름을 통해 API 전반에 표준화와 일관성을 적용할 수 있습니다. 공유 흐름을 사용하면 정책과 리소스를 결합하고 FlowCallout 정책 또는 흐름 후크를 사용하여 여러 API 프록시 간에 정책과 리소스를 공유할 수 있습니다. 일반적으로 특정 영역을 담당하는 플랫폼팀이나 주제 전문가가 API 프록시와 별도로 공유 흐름을 개발하는 경우가 많습니다. 예를 들어 표준 요청 및 응답 필드 집합을 캡처하여 Cloud Logging에 작성하는 공유 흐름을 개발할 수 있습니다. 표준화된 오류 메시지와 코드를 출력하는 오류 처리 흐름이나 서드 파티 ID 공급업체와 통합되는 인증 흐름일 수도 있습니다. API 프록시와 동일한 도구와 개념을 사용하여 공유 흐름 개발을 자동화, 테스트, 배포할 수 있습니다. 일반적인 공유 흐름의 몇 가지 다른 예시는 여기를 참조하세요.
GitOps는 DevOps가 널리 사용되면서 인기를 끌었습니다. 이 프레임워크는 Git, pull 요청, CI/CD 파이프라인, 자동화, 규정 준수 정책을 통한 버전 제어 사용과 같은 권장사항을 활용합니다. API 제공 권장사항에 대한 자세한 내용은 이 블로그를 참조하세요. 이러한 관행은 개발자를 위한 최적의 경로로 자리 잡을 수 있습니다. 예를 들어 개발자는 Duet AI를 사용하여 pull 요청을 트리거하는 OpenAPI 사양을 기능 브랜치로 내보내기 전에 만들도록 API를 설계할 수 있습니다. pull 요청이 승인되고 병합되면 CI/CD 파이프라인이 자동으로 시작되고 환경마다 프로세스가 반복됩니다. Apigee에서 플랫폼팀은 개발 수명 주기를 진행하는 동안 별도의 조직과 환경을 만들어 프록시를 배포하고 테스트할 수 있습니다. GitOps 전략을 사용하여 Git 저장소의 각 브랜치를 Apigee 환경에 매핑할 수 있습니다.
Apigee의 사용한 만큼만 지불하는 모델을 사용하는 고객은 기능이 다양한 여러 환경 유형을 선택할 수 있으며 고객은 여러 사용 사례에 맞게 다양한 환경 유형을 만들 수 있습니다.
소스 저장소에 프록시와 공유 흐름 코드를 호스팅하고 GitOps를 사용하면 API 개발자를 위한 독자적인 최적의 경로를 만들 수 있으며 개발자는 이를 통해 우수한 API를 설계하고 기본 비즈니스 로직을 구현하는 데 집중할 수 있습니다. 개발자가 VS Code용 Cloud Code 플러그인을 사용하여 로컬에서 개발하고 테스트하면 더욱 수월해집니다.
개발자와 플랫폼팀 간의 공동작업이 증가하면 개발자가 직접 모든 작업을 수행해야 한다는 부담에서 벗어날 수 있습니다. 복잡성이 줄어듦으로써 개발자는 자신이 가장 잘하는 일에 집중할 수 있으며 이를 통해 고객에게 더욱 우수한 경험을 제공할 수 있습니다. API와 플랫폼을 조직 제품으로 간주하면 자율성, 속도, 품질, 혁신이 향상됩니다. 위에서 설명한 전략을 사용하면 개발자의 업무 부담이 줄어들어 개발자가 더욱 우수한 API를 빌드할 수 있습니다. 시작할 준비가 되셨나요? 무료로 가입하여 자체 무료 샌드박스에서 빌드를 시작할 수 있습니다. 가격 책정에 대한 자세한 정보가 필요하신가요? Apigee의 새로운 가격 책정을 확인하고 Google의 리소스를 사용하여 개발자 플랫폼에 API 관리를 삽입할 수 있습니다.