Apigee

Google Cloud Apigee, 2024년 Gartner® Magic Quadrant™ API 관리 부문 리더로 선정

Wed, 13 Nov 2024 16:19:00 +0000

* 본 아티클의 원문은 2024년 10월 25일 Google Cloud 블로그(영문)에 게재되었습니다.

Google Cloud Apigee가 2024년 Gartner® Magic Quadrant™ API 관리 부문에서 9회 연속 리더로 선정되었다는 소식을 알려드립니다. 이처럼 연이어 리더로 선정되었다는 사실은 포괄적이고 혁신적인 API 관리 플랫폼을 제공하기 위한 Google Cloud의 노력을 인정받은 결과라고 생각합니다. Apigee는 비즈니스가 생성형 AI의 비중이 점차 커지고 있는 향상된 용량, 보안, 확장성을 활용해 클라우드 시대를 선도하도록 돕고 있습니다.

디지털 혁신 파트너

오늘날의 디지털 중심 세상에서 API는 비즈니스의 성장을 위한 필수 요소입니다. General Mills, Nationwide Insurance, PUMA, Freightos, Tieto, Veolia와 같은 업계 리더들이 Apigee를 믿고 API 생태계를 관리하는 이유가 바로 여기에 있습니다. Google Cloud에서는 더 나은 고객 경험을 제공하고, 혁신을 주도하고, 인프라를 보호하며, 새로운 수익 기회를 확보할 수 있도록 돕는 당사의 능력에 대한 기업의 신뢰를 소중하게 여깁니다.

aside_block: <ListValue: [StructValue([('title', 'Google Cloud 무료로 사용해 보기'), ('body', <wagtail.rich_text.RichText object at 0x7fce2bfb6290>), ('btn_text', '무료로 시작하기'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

자신 있게 API 환경 탐색

API 환경은 끊임없이 진화하고 있습니다. 생성형 AI가 생산성 향상을 위한 전례 없는 기회를 제공하는 반면 보안 요구의 증가로 인해 새로운 복잡성도 생겨났습니다. Apigee는 이러한 과제를 자신 있게 해결할 수 있도록 설계되었습니다. Apigee가 제공하는 혜택은 다음과 같습니다.

포괄적인 API 수명 주기 관리: 설계부터 개발, 배포, 모니터링에 이르는 전체 API 수명 주기를 간소화합니다.
강력한 보안 기능: 고급 보안 정책과 위협 방지 기능으로 API와 데이터를 보호합니다.
확장성 및 성능: 많은 양의 API 트래픽을 쉽게 처리할 수 있어 최적의 성능과 안정성이 보장됩니다.
생성형 AI 기반 인사이트: API 사용량 및 성능에 대한 유용한 인사이트를 확보하여 API 전략을 최적화할 수 있습니다.

지속적인 혁신을 위한 Google Cloud의 노력

Apigee는 개발자가 성공하는 데 필요한 핵심 기능을 제공하기 위해 최선을 다하고 있습니다. Google Cloud는 Apigee가 진화하는 고객 니즈를 충족하는 세계적인 수준의 서비스로 계속해 자리할 수 있도록 투자를 지속하고 있습니다. 이번에 Gartner에서 리더로 선정되면서, 혁신을 지속하며 우수한 개발자 환경을 제공하고자 하는 Google Cloud의 노력이 더욱 힘을 얻게 되었습니다.

올해 Google Cloud에서 주력해 온 주요 분야는 다음과 같습니다.

생성형 AI 통합: Google Cloud는 개발자가 프롬프트와 자체 엔터프라이즈 컨텍스트를 결합해 새로운 API를 생성할 수 있는 Gemini Code Assist와 같은 생성형 AI의 강력한 기능을 활용하여 모든 API를 쉽게 빌드, 보호, 관리할 수 있도록 지원하고 있습니다. 또한 LLM 기반 검색으로 API 탐색 및 상호 연결 파악을 간소화합니다.
보안 및 규정 준수 강화: 위협에 대응하고 변화하는 요구사항을 충족하도록 강력한 보안 조치를 통해 플랫폼을 강화했습니다. 개발자가 악의적인 소비자를 신고하거나 자동으로 차단할 수 있어 더 많은 통제권을 확보할 수 있습니다. 향상된 데이터 저장 기능으로 전 세계 어디서든 규정을 준수하는 워크로드를 지원합니다.
개선된 개발자 환경: 개발자가 Gemini Code Assist를 활용하여 VS Code와 같은 직관적인 도구와 워크플로로 API 개발 속도를 높일 수 있습니다.
빠른 API 제공: 기존 사양에서 새 API를 신속하게 생성할 수 있습니다. 로컬에서 실행하거나 Cloud Run에 배포하여 프로토타입을 빠르게 제작할 수 있는 모의 백엔드도 쉽게 만들 수 있습니다.

고객 및 파트너 여러분께 감사드립니다

Apigee에 지속적인 성원과 신뢰를 보내 주시는 고객, 개발자, 파트너 커뮤니티에 깊이 감사드립니다. 제품 로드맵을 추진하고 안정적인 API 관리 환경을 제공하는 데 여러분의 의견과 협력이 매우 중요합니다.

보고서 다운로드

여기에서 보고서 전문을 다운로드(이메일 주소 필요)하거나 자세한 내용을 알아보세요.

_{Gartner, Magic Quadrant API 관리 부문, Shameen Pillai, John Santoro, Nicholas Carter, Andrew Humphreys, Mark O'Neill, 2024년 10월 16일.}

_{Gartner는 Gartner의 연구 간행물에 언급된 모든 공급업체, 제품 또는 서비스를 보증하지 않으며, 기술 사용자에게 최고 등급 또는 그 밖에 칭호가 부여된 공급업체만 선택하도록 권장하지 않습니다. Gartner 연구 간행물은 Gartner 연구 조직의 의견으로 구성되며 사실의 진술로 해석하면 안 됩니다. Gartner는 이 연구와 관련하여 상품성 또는 특정 목적에의 적합성에 대한 보증을 포함해 모든 명시적, 묵시적 보증을 부인합니다.}

_{이 그래픽은 Gartner, Inc.에서 연구 문서의 일부로 게시한 것으로서 문서 전체의 맥락에 따라 평가해야 합니다. Gartner 문서는 요청 시 Google에서 제공해 드립니다.GARTNER는 미국 및 기타 국가에서 Gartner, Inc. 및/또는 그 계열사의 등록 상표 및 서비스 표시입니다. MAGIC QUADRANT는 Gartner, Inc. 및/또는 그 계열사의 등록 상표이며 허가 하에 여기에 사용되었습니다. All rights reserved.}

GraphQL: API 소비자에 대한 일관된 접근방식 수립

Thu, 03 Jun 2021 00:00:00 +0000

* 본 아티클의 원문은 2021년 4월 2일 Google Cloud 블로그(영문)에 게재되었습니다.

개발자들은 애플리케이션 프로그래밍 인터페이스(API)를 사용해 새 모바일 또는 웹 앱의 데이터와 기능을 조합합니다. 하지만 API와 상호작용 시 개발자들이 가장 많이 사용하는 2가지 옵션은 REST와 GraphQL입니다.

이 문서에서는 두 접근방식을 비교하고 GraphQL API 소비자를 위한 보다 일관된 경험을 구축하는 데 적용할 수 있는 REST API 권장사항을 소개합니다. 두 접근방식은 우열을 가릴 수 없으며 동일한 프로젝트가 아니라면 같은 팀에서 둘 다 사용할 수 있습니다. 프로젝트에 수반되는 API 유형에 상관없이 일관된 경험은 개발자가 더 많은 작업을 빠르게 수행하는 데 도움이 됩니다.

REST 및 GraphQL 비교

REST는 API가 준수하는 소프트웨어 아키텍처 스타일로, 개발자가 사용하면 표준적인 방법으로 서비스와 상호작용할 수 있습니다. GraphQL은 API의 쿼리 언어이자 해당 쿼리를 처리하는 런타임입니다. REST와 GraphQL은 리소스를 URL로 식별하고 이를 통해 앱이 데이터나 기능을 가져올 수 있다는 점에서 유사하지만 많은 차이점이 존재합니다.

GraphQL은 단일 엔드포인트에서 데이터를 교환하는 반면 REST는 여러 엔드포인트와 관련될 때가 많습니다. GraphQL 리졸버는 필드의 데이터를 가져오는데 리졸버가 실패해도 나머지 쿼리에서 유용한 데이터를 가져와 반환할 수 있습니다. 상호작용 패러다임에는 다수의 REST 쿼리를 수행할 때 예상되는 상황이 반영되어 있습니다. 따라서 GraphQL 쿼리 하나가 여러 REST 쿼리를 대체하는 경우가 많습니다.
GraphQL은 과도한 또는 부족한 데이터 가져오기, 즉 엔드포인트가 앱에 필요한 수준에 비해 너무 많거나 적은 정보로 호출에 응답하는 것을 방지합니다. REST API는 다양한 결정 수준으로 제공됩니다. 데이터를 더 가져오는 경우도 있고 덜 가져오는 경우도 있습니다. 다시 말해 직원 이름과 ID 번호만 필요한 상황에서 전체 직원 프로필을 가져오는 등 앱이 지나치게 많은 데이터를 수신할 수도 있습니다. 마찬가지로 수신되는 데이터가 너무 적어서 앱에서 API를 한 번이 아닌 여러 번 호출해야 할 수도 있습니다.
REST는 HTTP 동사를 사용하며 페이로드 데이터 교환을 위해 일반적으로 JSON을 사용합니다. 하지만 GraphQL에서는 HTTP POST 동사가 가장 많이 사용되며 프로토콜 내에 다양한 쿼리 유형이 지정됩니다. 또한 GraphQL은 스키마 정의 언어(SDL)라고 부르는 커스텀 쿼리 형식도 사용합니다. 요청에 커스텀 쿼리 언어가 사용되더라도 JSON이 반환되어 클라이언트가 응답을 쉽게 활용할 수 있습니다. GraphQL 클라이언트 라이브러리는 ReactJS UI 프레임워크와 기본적으로 통합되며 다른 언어 및 패러다임에서도 사용할 수 있어 오늘날 많은 개발자들이 활용하고 있습니다.
개발자의 탐색 관점에 차이가 있습니다. 개발자는 REST API 작동 원리를 이해하기 위해 일반적으로 포털을 상점처럼 사용하며 API를 탐색하고 상호작용합니다. GraphQL에서 포털은 기본 제공되는 플레이그라운드이며 개발을 위한 공간 역할도 합니다. 포털은 통합 개발 환경으로서 개발자가 새로운 쿼리를 즉석에서 탐색할 수 있으며 탭 완성과 같은 기능이 지원됩니다. 문서도 다릅니다. REST는 일반적으로 OpenAPI 사양과 포털을 사용합니다. 몇몇 OpenAPI 확장 프로그램도 존재합니다. 예를 들어 Apigee SmartDocs는 OpenAPI 사양으로 양방향 문서를 만듭니다. GraphQL 개발자는 일반적으로 스키마 기반 양방향 문서(예: Graphiql)를 사용해 개발하고 GraphQL 엔드포인트와 상호작용합니다.

이러한 특성으로 인해 GraphQL이 점점 더 많은 사용 사례에 쓰이고 있지만 채택 시에 문제가 발생할 가능성도 있습니다. 상호 운용성과 내부 인프라 해체가 필요한 프로젝트의 경우 GraphQL은 상이한 여러 기존 시스템의 몇 가지 API를 만드는 데 유용한 도구입니다. 하지만 API 관리 플랫폼을 통해 REST API를 제공하여 내부 및 외부의 혁신을 촉진하는 기업에서 일반적으로 수립하는 셀프서비스 개발자 프로그램과 관련 성장 전략에도 활용할 수 있습니다.

이러한 프로그램은 API를 빌드한 팀 이외의 많은 사용자가 팀에서 의도하지 않은 여러 사용 사례에 이 API를 사용할 수 있다는 점에서 전통적인 인프라 중심의 API 프로젝트와 다릅니다. 일관적이고 안정적이며 직관적인 개발자 경험이 얼마나 중요한지 알 수 있는 대목이며 GraphQL을 채택하는 데 장애 요소로 작용하기도 합니다. REST API 그룹은 상대적으로 손쉽게 훑어볼 수 있고 작업 내용과 방식이 직관적으로 표현되지만 아직 GraphQL에 익숙하지 않은 사용자가 많습니다.

GraphQL에서 REST 기반 권장사항 사용

사용자는 작업에 가장 적합한 도구를 사용할 수 있어야 하며 이러한 도구에는 GraphQL과 REST가 모두 포함될 수 있습니다. GraphQL로 작업 생산성을 높이려면 Google에서 수년 간 개발자 프로그램을 구축하며 개발한 REST 기반 권장사항을 채택하는 것이 좋습니다.

API를 기업에서 애셋을 가져와 그 애셋의 가치를 높이기 위해 내부 직원, 파트너 또는 외부 고객 등의 개발자에게 맡길 수 있게 해주는 디지털 제품이라고 생각해 보세요. API는 디지털 제품이므로 개발자가 사용 방법을 이해하고 시장에 매력적인 경험을 선보이려면 일관된 경험이 필요합니다. 개발자가 겪는 불편은 API를 채택하고 디지털 기업의 성장 전략을 추진하는 데 큰 걸림돌이 되므로 REST와 마찬가지로 GraphQL에서도 일관성이 핵심입니다.

그래프를 복수형 명사로 정의된 데이터 중심 계층 구조로 취급

REST 아키텍처 스타일의 주요 원칙 중 하나는 인프라 복잡성을 합리화하는 일관적이고 간소화된 인터페이스를 만드는 것입니다. GET/listEmployeesByDepartment가 제대로 작성된 REST 쿼리라고 생각하는 사람은 없을 것입니다. 이는 자바 함수에 더 가깝게 보이는 스타일입니다. 올바른 형식의 REST 리소스에서는 GET /Employees, POST /Employees와 같이 복수형 명사를 사용합니다. REST API는 예측 가능한 기대에 안정적으로 부응함으로써 개발자가 리소스를 사용하고 새로운 경험을 구축하는 속도에 직접적인 영향을 미칩니다. 시간이 돈이라는 사실을 잊지 마세요.

GraphQL의 스키마는 그래프 계층 구조를 사용해 한 카탈로그에 포함된 도서의 제목 및 저자와 같은 항목 간 관계를 정의합니다. 근본적으로는 데이터 중심 계층 구조이지만 자바 함수 스타일의 기능 계층 구조로 취급되는 경우도 있으며 그로 인해 예측 가능하고, 직관적이며, 일관된 경험을 방해하여 불편을 초래할 수 있습니다.

올바른 형식의 GraphQL은 올바른 형식의 REST와 비슷해야 합니다. /Books에서 GET이 가능하다면 /Books에 POST도 가능하다고 가정해야 합니다. 데이터 기반 명사 대신 동사 기반 함수로 정의된 GET listBooksByGenre와 같은 자바 스타일의 구조와 비교해 보세요. 어떻게 해야 POST할 수 있을까요? /BooksByGenre, /Books, /listBooks 등에 해야 할까요? 알 수 없는 일입니다. 따라서 데이터 중심 접근방식을 취하고 그래프를 데이터 중심의 계층 구조로 취급하는 것이 좋습니다.

REST가 더 적합한 경우 GraphQL을 고집하지 않기

REST에서는 사용자가 특히 CQRS(Command Query Responsibility Segregation)와 같은 패턴을 사용할 때 여러 URL에서 데이터를 요청하고 제출하는 경우가 많습니다. CQRS는 마틴 파울러가 처음으로 식별한 설계 패턴으로 데이터를 읽는 모델과 데이터를 업데이트하는 모델을 구분합니다. 개발자들은 REST에서 종종 CQRS를 사용해 마이크로서비스 아키텍처의 여러 서비스에서 데이터를 가져옵니다.

GraphQL에서는 특히 데이터 유형이 매우 다양하거나 제출된 데이터가 지나치게 적을 경우 변형(GraphQL 개발자가 데이터를 제출하는 방식)이 급속도로 매우 복잡해집니다. 데이터 가져오기를 데이터 제출과 구분하는 CQRS와 유사한 스타일을 사용하는 것이 좋습니다. 이는 이미 REST 기반 API 레이어를 갖춘 대기업에 특히 유용할 수 있습니다. GraphQL은 API 관리 레이어에 더하거나 이를 대신하는 형태로 데이터를 가져올 수 있지만 여전히 기존 REST API를 통해 데이터를 제출할 수 있습니다. 즉, REST가 적합할 때 개발자가 GraphQL을 억지로 사용할 필요가 없습니다.

재사용 가능성 최적화

대기업에 GraphQL을 배포할 때 개발자들이 다양한 유형의 백엔드를 사용할 수 있어야 하는 경우 종종 문제에 직면합니다. 사업부별로 개발한 서로 다른 스키마 요소가 개발자에게 종종 스키마 제휴의 스키마 병합을 통해 하나의 종합적인 그래프로 제공됩니다. 데이터 표현에 일관성이 없기 때문에 쿼리 동작이 그래프의 부분마다 다른 데이터나 동작을 반환할 경우 문제가 발생합니다. SDL에서 변수 이름이 동일하게 표시되는데 데이터 소스가 다른 것으로 확인된다고 해서 다른 값 또는 형식을 반환해서는 안 됩니다.

또한 요청되는 그래프 부분에 관계없이 릴레이 커서 연결 및 입력 힌트가 모두 일관된 동작을 나타내야 합니다.

이는 특히 변형에서 문제입니다. 개발자가 스키마의 한 부분에 데이터를 특정 방식으로 제출하여 이 데이터가 해당 방식으로 기록될 경우 이 데이터가 스키마의 다른 부분에 제출되었을 때 다른 방식으로 기록되면 알 수 없기 때문입니다. 변형은 재사용 가능성과 API 제품화를 최적화할 때 특히 어려운 과제이므로 GraphQL에서 변형을 개발하고 설계하는 방식을 신중하게 고려해야 합니다.

마지막으로 필드 이름을 살펴보겠습니다. 동일한 이름의 필드 이름에서 스키마의 다른 부분에 있다는 이유로 서로 다른 데이터와 동작을 제공하면 개발자가 어려움을 겪게 됩니다. 예를 들어 스키마의 한 부분에는 이름, 중간 이름, 성이 필요한 이름 필드가 있고 스키마의 다른 부분에는 성과 이름이 필요한 이름 필드가 있다면 이러한 불일치로 인해 개발자가 작업을 포기할 수 있습니다.

GraphQL에서는 쿼리 효율성에 맞춰 최적화하기 쉬우나 재사용 가능성 측면에서 최적화하는 데 목적을 두세요. API가 개발자에게 혼동을 주는 상황을 피하면 큰 도움이 될 것입니다.

REST와 GraphQL 중에서 무엇을 사용하든 API는 관리가 필요한 제품입니다

그래프를 데이터 중심 계층 구조로 취급하는 것에서 재사용 가능성과 개발자 사용 측면에서 최적화하는 것에 이르기까지 대부분의 권장사항이 강조하는 핵심은 성장 전략에 유용한 API는 개발자를 위한 제품이므로 개발자의 API 사용 경험이 API 채택 여부를 결정하는 데 가장 중요한 요소라는 점입니다. 개발자 프로그램에서는 Apigee API 관리의 도움으로 수년 간 REST API를 사용해 이 아이디어를 반영했으며 기업에서 GraphQL에 이를 더 폭넓게 적용함에 따라 앞으로 개발자가 혁신을 이루는 데 이러한 API 프로그램이 더욱 유용하게 사용될 것입니다.

GraphQL과 REST 비교에 대한 자세한 내용은 Google Cloud Next 동영상을 확인하세요. 또한 이 커뮤니티 게시물에서 참조 구현에 관한 유용한 링크와 Apigee에서 GraphQL 쿼리 승인을 사용할 수 있는 도구를 제공하는 GitHub 저장소 링크를 확인할 수 있습니다.

Apigee 및 Google Cloud Armor를 사용한 멀티 레이어 API 보안

Wed, 28 Apr 2021 00:00:00 +0000

* 본 아티클의 원문은 2021년 3월 16일 Google Cloud 블로그(영문)에 게재되었습니다.

정보 보안이 연일 헤드라인 뉴스에 오르고 있습니다. 크고 작은 스킴에 사용되는 악성 봇부터 대기업과 그 고객을 대상으로 하며 궁극적으로는 수많은 정부, 조직, 개인에게 영향을 미치는 전면적인 '소프트웨어 공급망 공격'에 이르는 다양한 보안 위험에 대해 아마 들어보았을 것입니다.

기업이 온라인 채널을 통해 고객에게 서비스를 제공하고, 전 세계 원격 근무 인력으로 어디서나 운영될 수 있도록 디지털 프로그램을 확장함에 따라, 이러한 보안 공격은 점점 더 보편화될 것이라 예상됩니다. 애플리케이션 프로그래밍 인터페이스(API)는 기업 디지털 프로그램의 기반이 되는 구성요소로, 다양한 앱과 서비스를 지원하는 데이터와 기능을 연결하므로 악성 공격의 벡터인 동시에 기업이 공격 패턴을 파악하고 이를 차단하는 데 사용할 수 있는 유용한 정보원이기도 합니다. Google Cloud의 2021년 API 경제 현황 보고서에 따르면 악의적인 트래픽이 172% 증가하고 기업의 이상 감지, 봇 보호, 보안 분석 기능 사용량이 230% 늘어났습니다.

비즈니스 수행 시 민첩하고 스마트하며 사전 예방적인 디지털 보안 메커니즘이 필요해짐에 따라, API 보안은 기업 IT 보안 포트폴리오의 필수적인 부분이 되었습니다. 이 문서에서 설명하는 것처럼 Google Cloud의 Apigee X 최신 출시 버전은 API 보안을 훨씬 더 강력하게 만들어 줍니다.

Apigee 및 Google Cloud Armor를 사용한 멀티 레이어 API 보안

API는 다양한 디지털 애셋으로 들어가는 문이며 모든 문에는 그 뒤에 있는 것을 안전하게 지켜주고 무단 액세스로부터 보호해 줄 자물쇠가 필요합니다. 따라서 조직이 API를 최고 수준으로 보호할 수 있도록 Google Cloud는 Apigee와 Cloud Armor를 결합하여 업계 선두의 API 관리 및 웹 애플리케이션 방화벽 기술을 함께 제공합니다. Google Cloud의 전체 수명 주기 API 관리 플랫폼의 최신 출시 버전인 Apigee X를 통해 고객은 Cloud Armor 웹 애플리케이션 방화벽(WAF)을 API에 쉽고 편리하게 적용하여 보안을 한층 더 강화함으로써 승인된 사용자만 회사 디지털 애셋에 액세스하도록 할 수 있습니다.

날씨 데이터 및 예측의 글로벌 선두주자인 AccuWeather 같은 회사의 경우, 외부 개발자를 위한 새로운 애플리케이션을 구축하고 데이터와 기능으로 수익을 창출하여 이들 커뮤니티 역시 AccuWeather 애셋으로 혁신을 이끌어낼 수 있도록 하기 위해 API가 필수적이었습니다. AccuWeather는 API에서 이처럼 새로 확장된 노출 영역이 생김에 따라 디지털 애셋을 관리하고 보호하기 위해 강력한 보안이 필요했습니다.

AccuWeather의 최고 기술 책임자인 크리스 패티는 “지난 10년간 AccuWeather는 API를 사용하여 비즈니스 고객에게 가장 정확하고 유용한 날씨 정보를 제공하기 위해 디지털 솔루션으로의 혁신을 계속해 왔습니다. Apigee의 전략적 파트너십과 포괄적인 API 관리 플랫폼 덕분에 업계 선두의 API를 단 몇 주 만에 설계하고, 개발하고, 출시할 수 있었습니다.”라고 말했습니다. “현재는 하루에 500억 건 이상의 API 호출을 처리합니다. 많은 조직에서 자체 디지털 솔루션을 도입함에 따라, 혁신을 가속화하기 위해 API 우선 전략을 도입하는 회사가 점점 많아지고 있습니다. Apigee X 신규 출시 버전을 사용하면 reCaptcha, Cloud Armor, 콘텐츠 전송 네트워크(CDN) 같은 최고의 Google 기능으로 API 프로그램을 확장하여 글로벌 확장, 성능, 보안을 제공할 수 있을 것으로 보입니다.”

Apigee와 Cloud Armor를 모두 사용하면 여러 수준에서 API를 보호할 수 있습니다.

확대하려면 클릭

Apigee X에는 OAuth(Open Authorization), API 키, 역할 기반 액세스 권한, 기타 여러 API 수준 보안 기능이 포함되어 있고, Cloud Armor는 DDoS(Distributed Denial of Service) 방지, 지오펜싱, OWASP(Open Web Application Security Project) 상위 10개 위험 완화, 커스텀 Layer-7 필터링 같은 네트워크 및 애플리케이션 보안을 제공합니다. 개발자는 Apigee X와 Cloud Armor를 통해 즉시 사용 가능한 통합 보안 기능으로 여러 수준에서 API를 보호할 수 있습니다.

확대하려면 클릭

고객은 또한 Cloud Identity and Access Management(IAM)를 손쉽게 활용하여 Apigee 플랫폼에 대한 액세스를 인증 및 승인하고 고객 관리 암호화 키(CMEK)를 사용하여 암호화된 데이터를 더 세부적으로 제어할 수 있습니다.

Apigee X와 Cloud Armor는 애플리케이션 및 API에 위협 및 사기에 대한 강력한 방지 기능을 제공합니다. 또한 이러한 제품은 reCAPTCHA Enterprise의 안티봇 및 악용 방지 조치를 추가하는 WebApp and API Protection(WAAP) 솔루션의 일부로 제공됩니다.

공격자와 새로운 취약점은 끊임없이 발생하기 때문에 보안은 움직이는 과녁처럼 맞추기 어렵지만 API 보안에 멀티 레이어 접근법을 사용하면 기업은 보안을 침해하지 않으면서 새로운 디지털 서비스와 환경에 API를 빠르게 활용할 수 있다는 점에 안심할 수 있습니다. Apigee X에 대해 자세히 알아보고 Apigee와 Cloud Armor의 작동 모습을 보려면 이 동영상을 확인하세요.

디지털 우수성 시대의 도래(Apigee X 소개)

Mon, 08 Mar 2021 00:00:00 +0000

* 본 아티클의 원문은 2021년 2월 5일 Google Cloud 블로그(영문)에 게재되었습니다.

디지털 혁신은 수년간 기업의 최우선 과제였으며 전 세계적인 코로나19 대유행 상황에서 더욱 긴급한 사안으로 대두되고 있습니다. 대다수의 업계에서 이전에는 몇 년에 걸쳐 진행되었을 일을 몇 주 또는 몇 달 만에 관리해야 했습니다. Google Cloud의 '2021년 API 경제 현황' 보고서에서 실시한 설문조사에 따르면 2020년에 기업 중 4분의 3이 디지털 혁신에 계속 집중했으며 이들 중 3분의 2에 달하는 기업은 실제로 투자를 확대했습니다.

API는 디지털 혁신에서 중추적인 역할을 합니다. Google은 현재 기업이 직면하고 있는 어려운 상황을 극복할 수 있도록 돕기 위한 Apigee X 출시 소식을 전해드립니다. API 관리 플랫폼의 주요 출시 버전인 Apigee X는 AI, 보안, 네트워킹에 대한 Google Cloud의 전문성을 원활하게 결합하여 기업에서 디지털 혁신 이니셔티브가 구축된 애셋을 효율적으로 관리할 수 있도록 지원합니다.

연구 및 자문 기업 Gartner는 2020년 7월 보고서 'Gartner Market Share Analysis: Full Life Cycle API Management, Worldwide, 2019'를 통해 "API는 기업이 디지털화를 달성하는 데 있어 가장 중요한 단계 중 하나가 되었습니다. API는 마이크로서비스, EDA, 서버리스, 하이브리드 클라우드, 멀티 클라우드와 같은 현대적인 아키텍처 패턴을 채택하는 데 핵심적인 역할을 합니다."라고 전했으며 다음과 같이 덧붙였습니다. "코로나19를 극복한 이후 기업들은 경제 활동을 재개하면서 뉴노멀에 발맞춰 나아갈 길을 찾아야 합니다. 가장 성공적인 기업은 코로나19 위기 속에서 규모를 재조정하고 스스로를 재창조하는 작업을 시작했을 것입니다. 하지만 대부분의 기업은 경제 활동을 재개하는 시점에야 시작할 것입니다. 규모 재조정 및 재창조는 운영 관행을 해체하고 재구성하는 과정을 거치며, 이러한 활동에서 무엇보다도 중요한 것은 API 플랫폼의 역할입니다. API 플랫폼이 더 효과적이고 광범위할수록 재조정 및 재창조가 더 빠르고 쉬워집니다."

API는 소프트웨어 간 통신 방식이자 개발자가 규모에 맞게 데이터와 기능을 활용하는 방식이기 때문에 API는 단순히 소프트웨어 스택의 구성요소가 아니라 개발자가 규모에 맞게 비즈니스 전략을 실행하고 혁신을 이루기 위해 사용하는 제품입니다. 모든 제품과 마찬가지로 API도 관리가 필요합니다. Apigee가 이번 달에 10주년을 맞이함에 따라 Google은 전 세계 1,000여 곳의 고객과 협력하면서 10년 동안 쌓아온 심층적인 전문성과 경험을 제공합니다.

Nationwide Insurance의 연금테크 부문 부사장인 릭 슈나이얼은 “Apigee는 API 전략을 적용하는 방법과 API를 사용한 디지털 혁신에 대해 전략적으로 생각할 수 있는 방법을 안내했습니다.” “이전에는 개발하는 데 모놀리식 서비스로 2~3개월이 걸렸는데 지금은 마이크로서비스로 며칠이면 가능합니다. 또한 Apigee를 통해 개발을 연계할 수 있기 때문에 개발자는 중앙 집중식 모델을 거치지 않고 자체적으로 API를 만들고 공유할 수 있습니다. 자체적으로 시작할 생각조차 하지 못했던 비즈니스 연결이 Apigee API 관리 플랫폼을 통해 이루어졌습니다.”라고 말했습니다.

Deutsche Bank의 기업은행기술 부문 상무이사인 숀 코터는 “우리는 Apigee X를 사용하여 Deutsche Bank 생태계에 통합된 API 솔루션을 설계하고 구현하기를 기대합니다. API 주도 통합의 효과적이고 안전한 사용은 Google Cloud 파트너십의 핵심 구성요소이며, 은행이 서비스를 내부적으로 보다 손쉽게 연결하고 제3자와 혁신하며 더 광범위한 고객층에 상품을 제공할 수 있도록 지원합니다.”라고 말했습니다.

Apigee X와 함께 디지털 우수성 실현

디지털 혁신에 대한 투자 확대가 시사하듯이 경쟁력은 갈수록 혁신에 대한 야망보다는 실제 혁신을 이루었는지에 따라 확보됩니다. 단순히 클라우드를 사용하거나 API를 이용하거나 API 관리를 채택하는 것만으로는 충분하지 않습니다. 오히려 디지털 우수성, 즉 반복적으로 신속하게 배포하고 확장하며 디지털 프로그램에서 일관되게 제공할 수 있는 기능이 필수적입니다. 여기에는 수익 창출이 가능한 API 기반 플랫폼을 구축하고 측정 가능한 비즈니스 성과를 제공하기 위한 핵심 기업 전략으로 디지털을 채택하는 것이 포함됩니다. 고객이 점진적 혁신에서 디지털 우수성으로, API 기반 프로그램에서 API 기반 플랫폼으로 도약할 수 있도록 돕는 것이 Apigee X의 핵심 목표였습니다.

Pitney Bowes의 최고혁신책임자인 제임스 페어웨더는 “Pitney Bowes에서는 항상 고객에게 최상의 경험을 제공할 방법을 찾고 있으며 Apigee 기술을 통해 이를 실현할 수 있었습니다. Apigee X가 출시되어 정말 기쁩니다. Apigee X 출시로 기업이 API 주도 프로그램의 효율성을 향상하고 디지털 혁신을 더욱더 가속화할 수 있기 때문입니다.”라고 말했습니다. “지금처럼 불확실한 시기에 전 세계의 수많은 조직에서 API 전략에 집중하여 어디서나 운영하고, 프로세스를 자동화하며, 빠르고 안전하게 새로운 디지털 환경을 제공하고 있습니다. Apigee X는 reCAPTCHA Enterprise, Cloud Armor(WAF), Cloud CDN 등 새로운 기능으로 API를 지원함으로써 당사와 같은 기업이 디지털 이니셔티브를 쉽게 확장하고 고객, 직원, 파트너에게 혁신적인 환경을 제공할 수 있도록 해줍니다.”

Apigee X의 차별화 요소

Apigee X를 자세히 살펴보겠습니다.

전 세계적인 도달 범위, 고성능, 안정성

변화하는 시장 상황과 역동적인 근무 환경으로 인해 조직은 글로벌 확대를 위해 API 프로그램을 확장하고 분산된 인력을 지원하고 있습니다. Apigee X를 사용하면 고객이 Cloud CDN의 기능을 쉽게 활용하여 전 세계적으로 API의 가용성과 성능을 극대화할 수 있습니다. 이제 고객은 24개 Google Cloud 리전에 API를 배포하고 100여 개 위치에서 캐싱을 강화할 수 있습니다.

멀티 레이어 보안 및 개인정보 보호

API 프로그램을 확장하면 조직 안팎의 사기 활동 가능성도 커집니다. Google Cloud의 '2021년 경제 현황' 보고서에 따르면 지난 1년 동안 Apigee에서 악의적인 API 트래픽이 170% 이상 증가했습니다. Apigee X는 API 보안 강화를 위한 Cloud Armor 웹 애플리케이션 방화벽, Apigee 플랫폼에 대한 액세스 권한 인증 및 승인을 위한 Cloud Identity and Access Management(IAM) 등의 기능을 적용하기 위해 통합 접근 방식을 제공합니다. 이를 통해 기업은 CMEK로 암호화된 데이터를 더 세부적으로 제어하여 원하는 리전에 데이터를 저장할 수 있고 사용자가 VPC 서비스 제어를 사용하여 데이터에 액세스할 수 있는 네트워크 위치를 제어할 수 있습니다.

AI 기반 자동화

기업 비즈니스에 중요한 애플리케이션을 지원하기 위한 API 채택이 증가하면서 운영팀과 보안팀에서는 이러한 애플리케이션이 항상 사용 가능하고 안전하며 예상대로 작동하는지 확인해야 하는 부담이 커져가고 있습니다. Apigee X는 업계 최고의 Google AI 및 머신러닝 기능을 이전 API 메타데이터에 적용하여 자체적으로 이상 행동을 식별하고, 성수기의 트래픽을 예측하여, API의 규정 준수 요구사항을 따르도록 합니다. 따라서 API 운영자와 보안 관리자는 사소한 작업에 시간을 들이는 대신 실제 비즈니스에 중요한 프로그램에 집중할 수 있습니다.

API 관리 분야의 선두업체로 10년 동안 고객과 함께 일해오면서 Google은 기업이 API를 활용하여 새로운 디지털 환경과 더 강력한 지능형 자동화 기능, 더 효과적인 데이터 기반 애플리케이션을 빌드함으로써 진정으로 비즈니스 혁신을 이루는 모습을 확인했습니다. 이번 출시 이후에도 API 관리 기능은 계속해서 확대될 것이며 향후 10년간 디지털 우수성을 달성할 수 있도록 기업에 길을 열어줄 것입니다. 앞으로도 더 놀라운 혁신을 함께 이루어 나가기를 기대합니다. 여기를 클릭하여 Apigee의 새 출시 버전을 무료로 사용해 보세요.

^{Gartner는 자사 연구 간행물에 설명된 어떤 공급업체, 제품 또는 서비스도 보증하지 않으며 기술 사용자에게 최고 등급의 공급업체 또는 기타 지정된 공급업체만 선택하도록 권장하지 않습니다. Gartner 연구 간행물은 Gartner 연구 조직의 의견을 담고 있으며 사실의 진술로 해석되어서는 안 됩니다. Gartner는 이 연구와 관련하여 상품성 또는 특정 목적에 대한 적합성 보증을 비롯한 모든 명시적, 묵시적 보증을 부인합니다.}

API의 기초: API 설계에 대해 알아야 하는 모든 정보

Tue, 24 Nov 2020 09:00:00 +0000

* 본 아티클의 원문은 2020년 10월 22일 Google Cloud 블로그(영문)에 게재되었습니다.

애플리케이션 프로그래밍 인터페이스, 즉 API는 소프트웨어가 상호 간에 통신하는 방식입니다. API는 기본 시스템의 복잡함을 추상화하기 때문에 연동되도록 의도되지 않았던 시스템까지 색다른 방식으로 연결할 수 있습니다. 따라서 API는 최신 디지털 환경에서는 물론 오늘날 가장 흥미로운 비즈니스 기회를 실현하는 데에도 핵심 요소로 각광받고 있습니다.

하지만 API가 제공하는 가치는 API를 통해 액세스할 수 있는 기능 및 데이터뿐 아니라 API의 설계 방식에 의해서도 좌우됩니다. 많은 API가 통합용으로 설계됩니다. 즉 시스템을 연결하되 API의 추후 용도는 염두에 두지 않는 일회성 프로젝트에 그치는 것입니다. 가장 가치가 높은 API는 대체로 개발자의 작업을 간소화하기 위해 설계된 것이므로 추후 다른 개발자의 활용을 염두에 둔 설계인 경우가 일반적입니다. 이것을 소비용 설계라고 합니다.

이 차이는 비즈니스의 효율성과 혁신 역량에 큰 영향을 미칠 수 있습니다. 소비용으로 설계된 API를 사용하면 가치가 높은 기능과 데이터를 재사용할 수 있기 때문에 개발자가 서로 다른 API를 모듈식으로 조합하여 새로운 디지털 환경을 조성하거나 새로운 전략을 지원하는 데 사용할 수 있습니다. 파트너 참여 간소화 또는 디지털 생태계 참여 촉진 등을 목표로 한다면 이런 방식으로 API를 활용하는 것이 필수적입니다.

반면 통합용으로 설계된 API는 당장의 프로젝트 요구사항을 해결해 줄 수는 있지만 개발자가 이 API를 추후에 다른 용도로 활용하기는 어렵습니다. 이러한 API는 이후 다른 개발자가 쉽게 이해할 수 있는 방식으로 설계되지 않았을 뿐 아니라 향후 개발자가 예상하는 방식으로 작동하지 않을 수 있습니다. 이 경우 결국 새 API를 만들어야 하므로 업무 부담과 시간 지연을 초래합니다. 애초에 보다 광범위한 용도를 염두에 두고 API를 설계했다면 일어나지 않았을 일입니다.

API 설계자가 가치와 개발자 생산성을 극대화하는 API를 빌드하려면 어떻게 해야 할까요? 이미 Google Cloud 블로그에서 이 주제를 여러 번 다뤘기에 이번 게시물에서는 API 설계에 대한 도움말과 권장사항에서 가장 유용한 정보를 모아 제공해 드립니다.

다양한 접근방식: REST, RPC, GraphQL

API별로 수반되는 시스템 상호작용 방식과 설계 규범이 각기 다르기 때문에 본격적인 시작에 앞서 다양한 API 설계 모델을 두루 살펴보는 것이 좋습니다. 자세한 정보는 API 설계: gRPC, OpenAPI, REST 및 그 용도의 이해, REST와 RPC 비교: 해결하려는 문제에 따른 API 선택, GraphQL: API 소비자에 대한 일관된 접근방식 수립, 웹 API가 항목 중심이어야 하는 까닭을 참조하세요.

종합적인 API 설계 개요

다양한 API 설계 주제를 자세히 알아보려면 API 웹 설계: 잃어버린 고리: 개발자가 선호하는 인터페이스 만들기 권장사항이라는 eBook을 통해 기본 지식을 탄탄히 다질 수 있습니다. 2014년부터 Google 내부에서 사용되면서 Cloud API 및 기타 Google API를 설계할 때 가이드로 활용되는 Google Cloud API 설계 가이드도 유용합니다. 또한 API 설계 권장사항 및 일반적인 문제에는 API 설계와 관련된 각종 주제의 Q&A가 수록되어 있으므로 읽어보기를 권해드립니다.

구체적인 과제 및 권장사항

위의 기사에서는 여러 주제를 폭넓게 다루었지만 API의 장기적인 가치에 영향을 미칠 수 있는 보다 세부적이고 구체적인 API 설계 과제도 다수 살펴봤습니다.

예를 들어 API는 여러모로 관계를 정의하는 방식입니다. 소매업체 API의 경우 정보 모델이 고객, 주문, 카탈로그 항목, 장바구니 등과 같은 항목 간의 관계를 설명하기도 합니다. 마찬가지로 은행 API는 계좌가 어떤 고객의 소유인지, 각 융자금 또는 인출액은 어떤 계좌에 해당되는지 표현합니다. API 개발자가 관계를 표현하는 가장 일반적인 방법은 노출하는 항목의 필드에 데이터베이스 키 또는 프록시를 노출하는 것입니다. 하지만 이 방법은 적어도 웹 API에 있어서는 웹 링크에 비해 몇 가지 단점이 있습니다. 그 이유를 확인하려면 API 설계: API에서 관계를 표현하는 데 키가 아닌 링크를 사용해야 하는 이유를 참조하세요.

마찬가지로 API URL을 작성할 때 사람이 인지하기 쉬운 이름을 이용한 URL을 사용해야 하는 경우와 정적인 숫자 ID를 이용한 URL을 사용해야 하는 경우를 알면 다소 혼란스럽더라도 큰 도움이 됩니다. 예를 들어 은행 계좌의 경우 숫자 ID를 사용하지 않으면 신뢰성 높은 참조의 역할을 하기 어려울 수 있습니다. 계좌 소유자에 관한 세부정보(예: 이름, 주소, 결혼 여부)가 바뀌거나 불확실한 경우(생년월일, 출생장소)도 있기 때문입니다. 소유자의 ID에 신뢰성이 있더라도 계좌의 소유권이 바뀔 수도 있습니다. 따라서 정적인 숫자 ID가 가장 신뢰할 수 있는 선택사항입니다. 이 주제를 보다 자세히 알아보려면 API 설계: 이름과 ID 중에서 URL 방식 선택하기를, 사람의 가독성과 시스템 안정성을 알맞게 절충한 API 설계에 대한 자세한 설명을 원한다면 웹 API에서 URL 설계의 잘못된 이분법을 읽어보세요.

소비용으로 설계된 API는 원래 개발자를 위한 소프트웨어 제품이기 때문에 여타 소프트웨어 제품처럼 반복 및 개선이 가능합니다. 하지만 새 API의 버전 관리 방법에는 다소 차이가 있기 때문에 API 설계: 나에게 맞는 버전 관리 및 API 버전 관리에 대한 일반적인 오해를 주의깊게 읽어보시기 바랍니다.

마지막으로 API는 검색 엔진에서 단일 페이지 애플리케이션이 색인되는 방식에 영향을 미칠 수 있으므로 이와 관련된 비즈니스 니즈가 있는 경우 API 설계 및 SEO에 관한 2부작 시리즈를 길잡이로 삼으시기 바랍니다.

API의 활용도 높이기

위의 정보를 토대로 한다면 보다 강력하고 사용자 친화적이며 다용도로 활용할 수 있는 API를 만들 수 있을 것입니다. 소비 중심 API의 주요 역할 중 하나가 재사용을 촉진하는 것이므로 보다 다양한 애플리케이션을 더욱 신속하게 빌드할 수 있는 새롭고도 무수히 많은 길이 펼쳐지게 됩니다. API를 통해 비즈니스 성과를 도출하는 방법을 보다 자세히 알아보려면 Google Cloud Next ‘20: OnAir의 API 관련 주제 모음을 확인해 보세요. 지금 바로 시작해 보세요.

비즈니스 애플리케이션 플랫폼으로 디지털 혁신 가속화

Tue, 20 Oct 2020 10:00:00 +0000

* 본 아티클의 원문은 2020년 9월 8일 Google Cloud 블로그(영문)에 게재되었습니다.

2020년은 비즈니스 리더가 경험한 가장 파격적인 한 해였습니다. 많은 기업이 몇 년이 걸릴 법한 디지털 혁신을 단 몇 달 만에 도입했기 때문입니다. 노력의 과정이 순탄치만은 않았습니다. 많은 조직에서 기존 리소스와 워크플로가 확장되지 않아서 빠르고 신속하게 이전할 수 없었기 때문입니다. 이 때문에 혁신을 이루는 방식과 다양한 분야의 직원들의 참여 방법을 재고해야 했습니다.

기업에서 이러한 여정을 탐색하고, 복원력을 키우고, 혁신을 가속화하는 데 도움이 되는 비즈니스 애플리케이션 플랫폼이라는 카테고리를 소개하겠습니다. API 관리, 코드 없는 애플리케이션 개발, 자동화 및 데이터 통계 기능이 포함된 비즈니스 애플리케이션 플랫폼의 목표는 다음과 같습니다.

복잡한 백엔드에 관계없이 API를 통해 서비스, 데이터, 기능을 일관적으로 사용하는 방법 제공
기술 지식이 없는 직원이 코딩 없이도 데이터 기반 애플리케이션을 빠르게 빌드하도록 지원
애플리케이션 통합 및 확장과 비즈니스 프로세스 자동화를 간편하게 수행하도록 지원
사용자에게 Looker 같은 셀프서비스 도구를 통해 데이터에서 유용한 정보를 도출하는 기능 제공

비즈니스 애플리케이션 플랫폼은 Apigee API 관리 및 AppSheet의 코드 없는 애플리케이션 개발에 대한 Google Cloud의 투자를 기반으로 합니다. Google은 하이브리드 및 멀티 클라우드 아키텍처, 인공지능, 머신러닝, 수명 주기 관리, 보안, 생산성 및 공동작업에 대한 Google Cloud의 전문성을 활용하는 새 기능을 이러한 분야에 추가할 예정입니다.

오늘 이러한 계획의 일환으로 기업이 빠르게 애플리케이션을 빌드하고, 워크플로를 자동화하고, 유용한 정보를 도출할 수 있게 해주는 몇 가지 새 제품과 기능을 소개하겠습니다.

API 게이트웨이 베타 출시 - 개발자가 Google Cloud 워크로드 및 서버리스 백엔드용 API를 빌드, 보호, 모니터링할 수 있게 해주는 완전 관리형 제품
AppSheet용 Apigee 데이터 소스의 일반 안정화 버전 - AppSheet 사용자가 Apigee API를 활용하여 코딩 없이 앱을 빌드할 수 있도록 지원
AppSheet Automation의 사전 체험판 출시 - 기술 지식이 없는 사용자가 다양한 데이터 소스를 활용하여 프로세스를 대규모로 자동화할 수 있게 해주는 솔루션

API 게이트웨이를 사용하여 서버리스 API 관리

개발자가 다른 팀과 공유하고 웹을 통해 공개적으로 노출하기 위해 서버리스 애플리케이션을 API로 패키징하는 경우가 증가함에 따라 개발자 사이에서 서버리스 워크로드가 점점 보편화되고 있습니다. API 게이트웨이는 개발자가 여러 엔드포인트에 대한 코드를 작성하거나 인프라 구성 또는 확장에 대해 걱정할 필요 없이 Compute Engine, GKE, App Engine, 서버리스 백엔드(Cloud Functions 및 Cloud Run) 기반의 API를 보호하고 관리할 수 있게 해줍니다.

Envoy 기반 API 게이트웨이는 인증, 키 검증, 비율 제한 같은 기능과 고성능 및 확장성을 제공합니다. 현재 베타 버전으로 제공되는 이 서비스는 사용량에 기반한 등급별 가격 책정이라는 유연한 비용 산정 방식을 사용합니다. 많은 얼리 어답터가 열광적인 반응을 보였습니다. API 게이트웨이를 더 많은 사용자에게 확대하고 더 많은 개발자가 멋진 앱을 빌드하도록 지원하게 된 것을 기쁘게 생각합니다. 여기를 클릭하여 API 게이트웨이 베타 버전의 사용을 시작하세요.

“우리는 Google Cloud의 API 게이트웨이를 사용하여 Cloud Run, Cloud Functions, App Engine에서 실행 중인 서버리스 애플리케이션의 API를 관리하고 있습니다. 편리한 설정 방식과 내장된 보안 기능이 애플리케이션과 아주 잘 맞습니다”라고 Veolia의 선임 개발자 기욤 블라키에르가 말했습니다.

AppSheet용 새 Apigee 데이터 소스로 코드 없이 더 다양한 앱 빌드

코드 없는 애플리케이션 개발이 계속해서 인기를 끌고 있습니다. Gartner는 2019년 10월에 발간된 'The future of apps must include citizen development'라는 보고서에서 “2023년에는 대기업에서 활약하는 일반인 개발자가 전문 개발자보다 4배 이상 많을 것”이라고 예상했습니다.

AppSheet는 이미 G Suite, mySQL, Salesforce 같은 다양한 데이터 소스를 지원합니다. 이제 기업은 AppSheet용 Apigee 데이터 소스의 일반 안정화 버전을 통해 직장 내 일반인 개발자에게 훨씬 더 많은 데이터를 제공할 수 있습니다. 기업은 직원이 Apigee API를 활용하고 코딩이 필요 없는 앱을 빌드하도록 함으로써 기술 경험이 없는 비즈니스 계열 직원이 혁신적인 앱을 만들도록 역량을 강화하고 기존의 IT 백로그를 줄일 수 있습니다. AppSheet용 Apigee 데이터 소스에 대해 자세히 알아보려면 여기를 클릭하세요.

EBSCO의 최고 데이터 설계자인 매튜 브라운은 “우리는 지금까지 CRM 관련 데이터, Google 스프레드시트, 기타 다양한 소스를 사용하여 AppSheet로 앱을 빌드해 왔습니다”라고 말했습니다. “AppSheet용 Apigee 데이터 소스를 사용하면 애플리케이션을 빌드할 때 API를 통해 기존 데이터에 더 쉽게 액세스할 수 있어 생산성과 속도가 크게 향상될 것입니다.”

AppSheet Automation으로 수동 프로세스를 더 빠르게 자동화

비즈니스 프로세스가 수동 작업에 의존하는 경우 기업 발전에 도움이 되는 작업에 주력하기 보다 시스템을 업데이트하는 데 소중한 시간을 낭비할 때가 많습니다. 게다가 실수나 소통 오류가 발생할 여지도 많습니다. 비즈니스 계열 작업자는 이러한 문제와 밀접하므로 이들이 프로세스를 최적화하고 자동화하도록 역량을 강화하는 것은 기업 혁신에서 중요한 부분을 차지합니다.

Google Cloud의 AI 제품으로 구동되고 현재 사전 체험판으로 제공되고 있는 AppSheet Automation은 기업이 코드를 작성할 필요 없이 자동화를 더 빨리 구축하고 운영하도록 지원하여 이러한 요구사항을 충족합니다. 손쉽게 제어할 수 있어 전체 조직에서 데이터 보안이 보장되고 수동 작업 위주의 프로세스, 애플리케이션 통합, 문서 기반 프로세스를 비롯한 다양한 사용 사례를 해결할 수 있습니다. 자연어 입력에 따라 상황별 제안을 제공하는 직관적인 인터페이스를 기반으로 하는 AppSheet Automation은 AI와 코드 없는 개발의 장점을 결합하여 사용자가 동일한 통합 플랫폼 내에서 다양한 앱과 강력한 자동화를 구축하도록 지원합니다. 여기를 클릭하여 AppSheet Automation 사전 체험판을 신청하세요.

Ather Energy의 디지털 및 IIOT 부문 선임 관리자인 라우딥 마디네니는 “AppSheet 덕분에 팀에서 코딩 없이 다양한 애플리케이션을 빌드할 수 있습니다”라고 말했습니다. “곧 출시될 AppSheet Automation은 코드 없는 애플리케이션 개발과 자동화를 위한 통합 솔루션을 제공하여 개발자의 생산성을 효과적으로 높이고 출시에 필요한 시간을 단축할 수 있을 것입니다.”

비즈니스 애플리케이션 플랫폼으로 더 빠르게 이전

Google Cloud는 이러한 출시를 통해 기업이 IT 영역 너머까지 혁신하고 디지털 혁신을 가속화하도록 지원하는 데 주력하고 있습니다. Google은 비즈니스 애플리케이션 플랫폼이라는 새로운 카테고리가 핵심 기능을 통해 기술 개발자와 비즈니스 계열 개발자 모두가 애플리케이션을 만들고 확장하고, 워크플로를 빌드하고 자동화하며, 애플리케이션을 연결하고 현대화하는 데 도움이 될 것이라고 확신합니다. 개발자가 무엇을 개발할지 벌써부터 기대가 됩니다.

자세한 내용은 비즈니스 애플리케이션 플랫폼을 참조하세요.

API 중심(API-first)의 정의와 비즈니스 가치를 창출하기 위한 5가지 기회

Tue, 20 Oct 2020 10:00:00 +0000

* 본 아티클의 원문은 2020년 9월 4일 Google Cloud 블로그(영문)에 게재되었습니다.

최근 Oxford Economics에서 진행한 CIO 설문조사 결과에는 제가 주목했던 몇 가지 핵심 동향이 포함되어 있었습니다. 대부분의 기업이 API 중심 전략을 도입하고 있고 이 개념에 가장 충실했던 기업이 더 빠르게 혁신을 실현하고 비즈니스 파트너십을 통해 더 큰 가치를 창출했다는 점입니다.

그럼에도 불구하고 설문조사에 따르면 아직도 상당수의 기업이 API를 '통합 중심'으로 고려하고 있습니다. 이러한 사고방식은 해당 조직이 오늘날 가장 중요한 대부분의 비즈니스 기회를 활용하는 데 방해가 될 뿐만 아니라 미래에 등장할 새로운 기회에 적응할 수 있는 능력도 저해합니다.

API 중심이란 API가 많은 사용 사례를 제공하고 수많은 비즈니스 기회를 실현할 수 있다고 기대하는 것입니다. 통합 중심이란 일반적으로 특정 통합 프로젝트의 범위 내에서 사고하고 API를 향후 사용까지는 고려하지 않고 일회성으로 생성하는 것을 의미합니다.

통합 중심에서 API 중심으로 전환하는 것은 문화적 변화일 수 있지만 일단 전환을 완료한 기업은 효율성, 속도, 성장, 복원력, 미래 보장성을 고려한 중요한 기회를 활용할 수 있습니다. 아래에서 API 중심의 사고방식을 통해 얻을 수 있는 5가지 큰 기회와 실행 팁을 소개합니다.

1. 효율성 개선

일회성의 API 통합 프로젝트와 달리 지속적으로 생성, 공유, 문서화, 관리되는 API는 내부 서비스에 안정적으로 액세스하고 이를 재사용할 수 있게 해줍니다. 이렇게 하면 기존의 IT를 규정지었던 수많은 맞춤형 통합 프로젝트 및 중복 작업을 제거할 수 있습니다.

이러한 API는 기본 서비스의 모든 복잡성을 제거하고 셀프서비스 개발자 포털을 통해 규모에 맞게 사용할 수 있으므로 개발자들은 최신 디지털 환경과 애플리케이션을 개발하는 데 필요한 디지털 자산에 보다 쉽게 액세스할 수 있습니다. 이와 동시에 우수한 관리형 API를 통해 IT 관리자는 기업의 디지털 자산이 사용되는 방식을 파악하고 이를 제어할 수 있습니다.

또한 API는 독립적인 배포가 가능합니다. 따라서 개발팀은 서로 다른 속도로 움직이는 소규모의 보다 자율적인 그룹으로 운영될 수 있습니다. 이러한 변화는 애플리케이션이 모놀리식으로 빌드되어 대부분의 기능이 서로 밀접하게 연관되어 있고 전체 개발자의 업무가 수많은 종속 항목으로 서로 얽혀 있는 기존의 방식에서 크게 바뀐 부분입니다.

2. TTM(time to market) 단축

수많은 Google Cloud 고객을 통해 입증된 것처럼 이러한 모든 효율성은 API 중심 개발을 통해 기업이 훨씬 더 빠르고 효율적으로 애플리케이션을 출시하고 파트너십을 구축할 수 있다는 것을 의미합니다. 예를 들어 Nationwide Insurance는 마이크로서비스를 공유하고 재사용 가능하게 만드는 API 중심 접근 방식을 채택한 후 3달이 걸렸던 개발 주기를 단 며칠로 단축했습니다.

마찬가지로 인도네시아의 대형 은행인 Bank BRI는 API를 활용하여 파트너십의 기술적 복잡성을 해소함으로써 공동 혁신의 기회를 늘릴 수 있었습니다. 즉, 셀프서비스 API 포털을 통해 파트너에게 디지털 자산을 제공함으로써 6개월이 걸렸던 파트너 온보딩 시간을 1시간 미만으로 단축했습니다.

3. 새로운 비즈니스 모델 및 수익 창출 기회 활용

Bank BRI의 사례에서 알 수 있듯이 API는 내부 개발자의 효율성을 극대화할 뿐만 아니라 기업이 중요한 데이터와 기능을 타사와 공유함으로써 새로운 비즈니스 모델과 수익 창출 기회를 활용하는 데도 유용합니다. Oxford Economics에서 실시한 설문조사에 따르면 외부 파트너십 촉진을 목적으로 API를 사용하는 데 가장 많은 투자를 한 기업의 경우 연간 6.7%의 매출 증가를 기록한 반면 그렇지 않은 다른 설문조사 응답자의 경우 4.9%의 매출 증가율을 보고했습니다.

모든 기업은 자체 시스템 내에서 중요한 데이터와 기능을 보유하고 있으며 Bank BRI의 경우에서처럼 이러한 자산은 타사에서 액세스 비용을 지불할 만한 가치가 있는 경우가 많습니다. AccuWeather 및 Pitney Bowes와 같은 Google Cloud 고객은 유사한 API 수익 창출 전략을 갖췄습니다.

또한 수익 창출 외에도 외부 사용자와 API를 공유하면 한 기업의 서비스를 파트너의 고객에게 노출할 수 있고 API 기반의 디지털 자산을 사용하여 뉴스 앱을 빌드하는 혁신가의 범위를 넓힐 수 있습니다. API를 통해 직접 수익을 창출하지 않더라도 이러한 API는 현재에는 새로운 사용 사례를 제공하고 미래에는 이러한 사용 사례가 출현하고 발전함에 따라 새로운 수익 창출 기회를 제공할 수도 있습니다. AccuWeather의 CTO인 크리스 패티는 모든 개발자에게는 미래를 책임질 만한 잠재력이 있다고 말합니다. AccuWeather는 날씨 데이터에 액세스할 수 있는 모든 기능을 갖춘 API의 유료 버전뿐 아니라 기본에 충실한 무료 버전도 제공합니다.

4. 데이터 활성화 및 비즈니스 프로세스에 인텔리전스 적용

API는 기업이 중요한 디지털 자산을 내부 팀은 물론 타사와 공유하도록 지원할 뿐만 아니라 클라우드에서 실행되는 머신러닝 서비스와 같은 필요성이 높은 기능을 제공하는 외부 API에 연결할 수 있도록 해줍니다.

예를 들어 어느 기업은 방대한 양의 데이터를 보유하고 있으면서도 머신러닝에 대한 전문 지식은 거의 없을 수 있습니다. 그러나 API에 데이터를 배치하고 이를 타사 머신러닝 서비스에 연결하는 기업은 내부 머신러닝 역량은 더 느리게 발전시키더라도 유용한 최신 정보를 바로 도출할 수 있습니다. 마찬가지로 기존 시스템의 전면에 API를 배치하는 기업은 이러한 시스템을 클라우드에 보다 쉽게 마이그레이션하고 클라우드 기반 서비스와 연결할 수 있습니다.

최신 디지털 비즈니스 프로세스 및 환경은 대개 여러 기업의 소프트웨어로 구성되어 있고, 여기서 API는 한 조직의 데이터와 기능을 다른 조직의 데이터 및 기능과 연결하여 새로운 경험이나 효율성을 창출합니다. 이 생태계 중심의 접근 방식을 통해 기업은 핵심 역량을 디지털화하는 데 주력하는 동시에 이러한 역량을 시장에 제공하는 데 필요한 다른 많은 부분은 기술 파트너에 의존할 수 있습니다.

5. 복원력 및 미래 보장성 강화

API를 사용하면 중요한 데이터와 기능을 다양한 사용 사례에 맞게 재사용하고 다른 API와 결합할 수 있으므로 IT 시스템에 모듈성 및 복합성을 추가하여 궁극적으로는 복원력과 미래 보장성을 확보할 수 있습니다.

예를 들어 파트너가 사업을 중단하는 경우 해당 파트너를 교체할 때 한 파트너의 API를 다른 파트너의 API로 교환하기 위해 수개월에 걸친 복잡한 통합을 계획할 필요가 없습니다. 마찬가지로 고객이 음성 인터페이스를 통해 터치식 모바일 환경에서 제공하는 다수의 기능을 사용하기를 원하는 경우 이러한 요구를 수용하기 위해 터치식 인터페이스의 API를 음성 인터페이스를 사용하는 API에 연결하기 위한 전면적인 개편은 필요하지 않습니다.

기업은 적절한 기술 지원 기능을 통해 API를 최대한 활용할 수 있습니다.

API 중심 전략은 API를 미들웨어가 아닌 개발자의 역량을 강화하고 파트너십을 활성화하며 혁신을 가속화하는 소프트웨어 제품으로 인식합니다. 이것은 대개 API를 만들었다가 잊어버리는 통합 중심 작업에서는 중대한 변화입니다.

API를 처리하는 것은 수식의 일부일 뿐입니다. 기업이 귀중한 디지털 자산을 외부 사용자와 공유하려면 API 관리 도구를 통해 다음을 수행해야 합니다.

인증 및 승인과 같은 보안 조치 적용
악성 공격으로부터 자산 보호
가용성과 높은 성능을 보장하기 위해 디지털 서비스 모니터링
자산 측정 및 사용량 추적

API 게이트웨이는 기업이 공유하는 API를 보호하고 관리할 수 있는 좋은 출발점이 됩니다. 그러나 고급 기능에는 전체 수명 주기 API 관리 플랫폼이 필요할 수 있습니다. 이 플랫폼은 기본 게이트웨이 기능뿐만 아니라 수명 주기 관리 도구, 셀프서비스 포털을 통해 API 제품으로 API를 제공하는 메커니즘, 보다 세분화된 보안 보호, 수익 창출 옵션, 세분화된 사용량 분석 기능을 제공하므로 기업이 API 사용 방법, API 악용을 예방하는 다양한 기능, API 작업 등을 파악하는 데 도움이 됩니다.

적절한 도구를 통해 API를 활용하면 엄청난 비즈니스 기회를 창출할 수 있으며 모든 기업이 API 중심으로 전환하려고 노력하는 이유가 바로 여기에 있습니다.

Apigee

Google Cloud Apigee, 2024년 Gartner® Magic Quadrant™ API 관리 부문 리더로 선정

디지털 혁신 파트너

자신 있게 API 환경 탐색

지속적인 혁신을 위한 Google Cloud의 노력

고객 및 파트너 여러분께 감사드립니다

보고서 다운로드

GraphQL: API 소비자에 대한 일관된 접근방식 수립

REST 및 GraphQL 비교

GraphQL에서 REST 기반 권장사항 사용

REST와 GraphQL 중에서 무엇을 사용하든 API는 관리가 필요한 제품입니다

Apigee 및 Google Cloud Armor를 사용한 멀티 레이어 API 보안

Apigee 및 Google Cloud Armor를 사용한 멀티 레이어 API 보안

디지털 우수성 시대의 도래(Apigee X 소개)

Apigee X와 함께 디지털 우수성 실현

Apigee X의 차별화 요소

API의 기초: API 설계에 대해 알아야 하는 모든 정보

다양한 접근방식: REST, RPC, GraphQL

종합적인 API 설계 개요

구체적인 과제 및 권장사항

API의 활용도 높이기

비즈니스 애플리케이션 플랫폼으로 디지털 혁신 가속화

API 게이트웨이를 사용하여 서버리스 API 관리

AppSheet용 새 Apigee 데이터 소스로 코드 없이 더 다양한 앱 빌드

AppSheet Automation으로 수동 프로세스를 더 빠르게 자동화

비즈니스 애플리케이션 플랫폼으로 더 빠르게 이전

Google Cloud API 게이트웨이 공개 베타 버전 제공

API 중심(API-first)의 정의와 비즈니스 가치를 창출하기 위한 5가지 기회

1. 효율성 개선

2. TTM(time to market) 단축

3. 새로운 비즈니스 모델 및 수익 창출 기회 활용

4. 데이터 활성화 및 비즈니스 프로세스에 인텔리전스 적용

5. 복원력 및 미래 보장성 강화

기업은 적절한 기술 지원 기능을 통해 API를 최대한 활용할 수 있습니다.