조직은 Apigee의 최상위 컨테이너입니다. Apigee 조직에는 모든 API 프록시와 관련 리소스가 포함됩니다. 이 주제의 나머지 부분에서는 조직에 대해 좀 더 깊게 다루며 몇 가지 유용한 점은 다음과 같습니다.
Apigee 조직은 Google Cloud 조직과 구분되며 Google Cloud 조직의 하위 조직입니다. Apigee X 또는 Apigee Hybrid의 조직을 만들면 정확히 하나의 Google Cloud 프로젝트에 매핑되며 Apigee 조직과 Google Cloud 프로젝트는 이름을 공유합니다. 일부 Google Cloud 프로젝트에는 연결된 Apigee 조직이 없습니다.
Apigee 문서에서 '조직'이라는 용어를 사용하는 경우 특히 Apigee 조직을 의미합니다. Apigee 문서에서는 대안을 나타내기 위해 'Google Cloud 조직'이라는 문구를 사용합니다.
다음 다이어그램에서는 Apigee 조직과 환경, Google Cloud 프로젝트와 폴더 간의 관계를 보여줍니다.
조직 내 구성요소
다음 이미지는 Apigee 조직 모델의 주요 구성요소를 보여줍니다.
이 모델은 API, API 제품, 앱, 앱 개발자가 모두 Apigee 내에서 어떻게 연결되는지 정의합니다.
이 모델에는 Apigee의 모든 기능이 표시되지는 않지만 조직이 배포의 루트임을 알 수 있습니다.
다음 표에서는 조직 모델의 구성요소를 자세히 설명합니다.
구성요소
설명
조직
모든 Apigee 조직은 정확히 Google Cloud 프로젝트 하나에 속하며 한 프로젝트에는 조직이 최대 1개까지 포함될 수 있습니다. 조직에는 환경, API 프록시, API 제품, API 패키지, 앱, 사용자가 포함됩니다.
계정 소유자는 단일 조직에 제한되지 않습니다. 일부 계정 소유자는 여러 앱 개발자 커뮤니티를 지원하는 여러 조직을 정의하거나 구성원일 수 있습니다.
환경 및 환경 그룹
환경은 API 프록시를 배포하는 조직 내에 있는 격리된 소프트웨어 환경입니다.
한 조직에 환경을 여러 개 만들 수 있습니다.
환경 그룹은 호스트 이름이 하나 이상 있는 환경의 그룹입니다. 호스트 이름은 환경 그룹의 모든 환경에 배포된 API 프록시를 호출하는 데 사용되는 URL의 일부입니다.
API 프록시
API 프록시는 수신 요청과 백엔드 서비스 간의 인터페이스입니다.
프록시 항목은 Apigee가 클라이언트의 요청과 백엔드의 응답을 처리할 때 실행하는 지침과 정책을 포함합니다.
API 제품
API 게시를 위한 항목입니다. API 제품은 외부 개발자가 사용할 수 있도록 개발자 포털에 게시됩니다. API 제품은 하나 이상의 게시된 API에 액세스하는 인터페이스를 제공합니다. OpenAPI 사양을 사용하여 설명할 수 있는 인터페이스에는 하나 이상의 API 프록시에서 처리하는 하나 이상의 API 요청이 조합되어 포함될 수 있습니다.
조직의 사용자가 API 제품을 만듭니다. 이 과정에서 각 API 제품에 임의의 메타데이터를 연결할 수 있습니다. 흔히 사용되는 메타데이터 유형 중 하나로서 API 호출에 대한 액세스 한도를 지정하고, 보안 요구사항을 규정하고, 모니터링 및 분석을 허용하고, 추가 기능을 제공하는 서비스 요금제를 정의할 수 있습니다.
Apigee는 API 제품의 분석을 위한 데이터를 수집합니다.
API 공급업체
API 프록시 및 제품을 만들고 관리하는 개인 또는 항목입니다. 클라이언트 앱 개발자는 이렇게 게시된 API에 액세스합니다.
앱 개발자
조직에는 조직에서 정의한 API(API 제품으로 게시됨)를 사용하는 앱을 빌드하는 개발자 한 명 이상이 포함됩니다. 개발자는 API를 사용하지만, 조직에서 API를 만들거나 다른 작업을 수행할 수는 없습니다.
개발자는 회사 내부 인력일 수도 있고, 파트너일 수도 있고, API 액세스 비용을 지불하거나 지불하지 않는 외부 개발자일 수도 있습니다. 개발자를 API 사용 고객이라고 생각하면 됩니다.
개발자가 앱을 등록하고 API 키 또는 API에 액세스할 수 있는 기타 클라이언트 사용자 인증 정보를 받으려면 개발자가 조직에 등록되어 있어야 합니다. 조직에서 개발자를 추가, 업데이트 또는 삭제하는 방법은 API 제공업체가 결정합니다. 결정합니다. UI를 통해 수동으로 추가하거나, 웹사이트를 통해 등록할 개발자 포털을 만들거나, Apigee API를 사용하여 자체 등록 메커니즘을 정의하고 구현할 수 있습니다.
Apigee 앱(또는 앱)
개발자가 API를 사용하는 하나 이상의 클라이언트 앱을 만듭니다.
사용자 인증 정보 확인(예: API 키 또는 OAuth 토큰)이 필요한 API를 호출하는 클라이언트 애플리케이션을 만드는 개발자는 먼저 조직에 앱 등록을 만들어야 합니다. 앱 등록을 통해 클라이언트 애플리케이션이 API를 호출할 때 사용해야 하는 API 키, 키/보안 비밀 쌍 또는 기타 사용자 인증 정보가 개발자에게 제공됩니다.
모든 앱이 조직에 등록되었으므로 Apigee를 사용하여 앱과 API 사용에 대한 분석 정보를 모니터링하고 수집할 수 있습니다.
표시되지 않는 Apigee의 추가 구성요소는 API 키와 OAuth 토큰입니다.
Apigee에서는 간단한 API 키, 2-legged OAuth, 3-legged OAuth 등 여러 유형의 인증을 지원합니다.
API 제공업체에서 API 키 확인을 승인 메커니즘으로 지정하면 클라이언트 애플리케이션은 API를 요청할 때마다 API 키를 전달해야 합니다. 이 키가 유효하면 Apigee가 요청을 허용합니다. 또는 API 제공업체가 OAuth 토큰 확인을 승인 메커니즘으로 지정하면 클라이언트 애플리케이션은 먼저 OAuth 토큰을 가져온 다음 API를 요청할 때마다 해당 토큰을 전달해야 합니다. 이 토큰이 유효하면 Apigee가 요청을 허용합니다. 다른 커스텀 승인 스키마도 가능합니다.
API 제공업체는 개발자가 앱을 등록하는 방법을 정의해야 합니다. 각 앱 등록에는 하나 이상의 키 또는 사용자 인증 정보가 연결됩니다. 개발자가 개발자 포털을 통해 자신의 애플리케이션을 등록하도록 허용하면 개발자가 편리한 셀프서비스 환경을 통해 API에 액세스하는 데 필요한 키 또는 사용자 인증 정보를 검색할 수 있습니다.
앱 등록 시점에 개발자는 단일 API 제품 또는 여러 API 제품에 액세스하도록 선택할 수 있습니다. 개발자의 앱은 동일한 키/사용자 인증 정보를 사용하여 앱과 연결된 모든 API 제품에 액세스합니다.
언제든지 키를 취소하여 개발자의 앱이 더 이상 API에 액세스할 수 없도록 할 수 있습니다(개발자 앱의 등록된 표현은 조직에 여전히 존재함). 또는 개발자를 취소할 수 있습니다. 이 경우 해당 개발자에 등록된 모든 앱의 모든 사용자 인증 정보가 작동하지 않게 됩니다. 취소는 되돌릴 수 있습니다.
Apigee에서 앱 사용자 인증 정보를 만들 때 개발자가 특정 시간 후에 새 키 또는 사용자 인증 정보를 가져와야 하도록 만료를 지정할 수 있습니다.
Apigee 사용자
Apigee 사용자는 관리자, API 프록시, API 제품 생성자, 분석 및 기타 통계를 모니터링하는 사용자 등을 포함할 수 있는 조직의 API팀을 구성합니다. 최종 사용자는 Apigee 개발자가 빌드하는 앱을 사용하는 사람입니다. 대부분의 경우 이 문서에서는 Apigee 사용자를 나타내기 위해 '사용자'라는 용어를 사용합니다.
관리자는 조직에 사용자를 추가할 수 있습니다.
사용자마다 다른 역할과 액세스 권한을 가질 수 있습니다. 예를 들어 조직 및 조직 구성요소를 수정하는 권한을 가진 사용자를 조직 관리자 및 작업 관리자로 정의하고 API 프록시 및 API 제품을 만들 수 있는 권한이 있지만 다른 사용자를 수정할 수 있는 권한이 없는 다른 사용자를 정의합니다.
사용자는 여러 조직의 구성원일 수 있습니다. 예를 들어 회사에서 Apigee에 여러 조직을 정의하여 서로 다른 개발자 커뮤니티를 지원하면서 내부적으로는 모든 조직에 속하는 동일한 인원이 모든 API 프록시와 API 제품을 빌드할 수 있습니다.
사용자가 되기 위해 Apigee 조직을 만들 필요는 없습니다. 관리자는 사용자를 기존 조직에 추가할 수 있습니다.
유료 조직에서 구독 또는 사용한 만큼만 지불 가격 책정 모델을 사용하는지 여부와 관계없이 청구 목적으로 측정되는 항목은 환경, API 호출, 프록시 배포입니다.
구독 요금제를 사용하면 상당한 할인을 받는 대신 사용 권한을 선불로 결제할 수 있습니다. 구독 요금제는 환경 수가 많거나, API 호출 수가 많거나, Apigee에서 관리하는 API 프록시 수가 많은 등 소비량이 많은 경우에 적합합니다. 사용한 만큼만 지불 모델에서는 사용한 리소스에 대해서만 비용을 지불하지만 대량 할인을 이용할 수는 없습니다.
구독 권한
조직
모든 Google Cloud 프로젝트에서 Apigee를 사용 설정할 수 있습니다.
이렇게 하면 해당 프로젝트의 Apigee 조직이 생성됩니다. 원하는 만큼 조직을 만들 수 있습니다. Google Cloud 프로젝트를 만드는 데 필요한 사용 권한이나 요금이 없는 것처럼 Apigee 조직을 만드는 데도 사용 권한 요구사항이 없습니다.
환경
환경 사용 권한은 단위로 표현됩니다. 환경 단위 사용 권한을 사용하는 프로세스는 먼저 환경을 만든 후 해당 환경을 조직에 연결하는 2단계 프로세스입니다. 환경이 조직에 연결될 때 환경 단위 사용 권한이 차감됩니다. 단일 조직의 최대 환경 수는 한도를 참조하세요.
사용 가능한 Google Cloud 리전 중 하나 이상에서 Apigee 환경을 만들 수 있습니다.
환경이 매핑되는 각 리전은 사용 권한에서 환경 단위 1개를 사용합니다. 단일 리전에 프로비저닝된 환경은 사용 권한에서 환경 단위 1개를 사용합니다. 두 리전에 프로비저닝된 환경은 사용 권한에서 환경 단위 2개를 사용합니다. 총 환경 단위 사용량은 모든 조직에서 사용되는 환경 단위 수를 집계한 값입니다.
총 환경 단위 사용 권한은 구독 계층에 제공된 사용 권한과 환경 팩을 통해 추가로 획득한 사용 권한의 합계입니다.
Google은 환경에 대한 사용 권한을 적용합니다. 사용 권한 한도를 초과할 수 없습니다.
사용 권한 한도를 초과하는 환경을 만들려고 하면 오류가 발생합니다.
환경 팩을 추가로 구매하여 사용 권한을 확장할 수 있습니다.
API 호출
Google은 Apigee에서 처리하는 각 API 호출을 집계합니다. 총 API 호출 사용 권한은 구독 계층에 제공된 사용 권한과 호출 팩을 통해 추가로 획득한 사용 권한의 합계입니다.
구독 요금제에서는 API 호출에 대한 사용 권한 한도가 적용되지 않습니다. API 호출 사용 권한을 초과하더라도 Apigee는 계속해서 API 호출을 제공합니다. Google은 기존 사용 권한을 초과한 사용량에 대해 요금을 청구합니다. 언제든지 호출 팩을 추가로 구매하여 API 호출 사용 권한을 확장할 수 있습니다.
프록시 배포
Google은 배포하는 각 API 프록시를 집계합니다. 총 프록시 배포 사용 권한은 구독 계층에 제공된 사용 권한과 프록시 배포 팩을 통해 추가로 획득한 사용 권한의 합계입니다.
구독 요금제에서는 프록시 배포에 대한 사용 권한 한도가 적용되지 않습니다.
사용 권한이 허용하는 것보다 더 많은 프록시를 배포하여 프록시 배포 사용 권한을 초과하더라도 Apigee에서는 계속해서 새 프록시를 배포할 수 있으며 Apigee는 계속해서 API 호출을 제공합니다. Google은 기존 사용 권한을 초과하는 사용량에 대해 요금을 청구합니다. 호출 팩을 추가로 구매하여 프록시 배포 사용 권한을 확장할 수 있습니다.
모든 Google Cloud 프로젝트에서 Apigee를 사용 설정할 수 있습니다.
이렇게 하면 해당 프로젝트의 Apigee 조직이 생성됩니다. 원하는 만큼 조직을 만들 수 있습니다. Google Cloud 프로젝트를 만드는 데 비용이 들지 않는 것처럼 사용한 만큼만 지불 가격 모델에서는 Apigee 조직을 만드는 데도 비용이 들지 않습니다.
환경
Apigee 조직에 여러 환경을 연결할 수 있습니다. 환경을 사용하는 프로세스는 먼저 환경을 만든 후 해당 환경을 조직에 연결하는 2단계 프로세스입니다. Google은 조직에 연결된 환경에 대해 요금을 청구합니다.
환경을 단일 조직에 최대 85개까지 만들 수 있습니다.
멀티 리전 환경의 경우 Google은 환경을 사용할 수 있는 각 리전에 대해 요금을 청구합니다. 사용 가능한 Google Cloud 리전 중에서 원하는 리전을 선택할 수 있습니다.
API 호출
Google은 Apigee에서 처리하는 각 API 호출을 집계합니다. Google은 Apigee 환경에서 처리하는 API 호출 수에 따라 요금을 청구합니다. 제한이 없습니다. Apigee는 부하가 증가하더라도 자동으로 확장되고 API 호출을 계속 제공합니다.
프록시 배포
Google은 배포하는 각 API 프록시를 집계합니다. Google은 Apigee 환경에 배포된 API 프록시 수에 따라 요금을 청구합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-16(UTC)"],[[["\u003cp\u003eApigee organizations are top-level containers for API proxies and resources, distinct from Google Cloud organizations but mapped to a single Google Cloud project with a shared name.\u003c/p\u003e\n"],["\u003cp\u003eThere are two types of Apigee organizations: paid (production) organizations with full scalability and evaluation (eval) organizations, which are temporary and time-limited.\u003c/p\u003e\n"],["\u003cp\u003eAn Apigee organization's structure contains components such as environments, API proxies, API products, API providers, app developers, and apps, all managed within the organization's framework.\u003c/p\u003e\n"],["\u003cp\u003eApigee offers subscription and pay-as-you-go pricing models, with entitlements and billing based on environments, API calls, and proxy deployments, and also allowing users to be members of multiple organizations.\u003c/p\u003e\n"],["\u003cp\u003eApigee users within an organization can have various roles, from administrators to API creators, and end-users access APIs through apps built by Apigee developers.\u003c/p\u003e\n"]]],[],null,["# Understanding organizations\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\nAn organization is the top-level container in Apigee. The Apigee organization\ncontains all your API proxies and related resources. While the rest of this topic goes into\nmore depth about organizations, here are a few practical points:\n\n- An Apigee organization is distinct from and subsidiary to a Google Cloud organization. When you create an organization for Apigee X or Apigee hybrid, it maps to exactly one Google Cloud *project*, and the Apigee organization and Google Cloud project share a name. Not all Google Cloud projects have an associated Apigee organization.\n- Where the Apigee documentation uses the term \"organization,\" it specifically refers to an Apigee organization. The Apigee documentation uses the phrase \"Google Cloud organization\" to refer to the alternative.\n- Once created, you cannot rename an Apigee organization.\n- Your Apigee organization name is shown as the project in the URL for the Apigee section of [the Google Cloud console.](https://console.cloud.google.com/apigee/overview) For example: \n\n ```\n https://console.cloud.google.com/apigee/overview?project=ORG_ID\n ```\n- When you invoke REST calls to the Apigee API, the organization identifier is a required part of the path. For example, the following `curl` request returns a list of all API proxies in an organization using the [organizations API](/apigee/docs/reference/apis/apigee/rest/v1/organizations): \n\n ```\n curl https://apigee.googleapis.com/v1/organizations/ORG_ID/apis\n ```\n- While you may have created only one organization, you can be authorized in other organizations as a user or administrator with specific permissions. In the cloud console, you can switch to a different organization as described in [Switching between\n your organizations](/apigee/docs/api-platform/get-started/switch-org).\n\n**Note:** This video was recorded with a previous version of the Apigee UI; however, the concepts are still valid. \n**Video:** Watch a short video to learn how organizations support a\nmulti-tenancy architecture for API management. \n\nOrganization types\n------------------\n\nThere are two types of organizations:\n\n- **Paid:** A permanent organization with full scalability. Also known as a\n *production* organization. Paid organizations include those created as part of a Subscription or a Pay-as-you-go\n Apigee pricing model.\n\n- **Evaluation:** A temporary, self-service organization for testing\n Apigee. Sometimes referred to as *eval orgs*, these organizations are time-limited and\n lack the scalability and flexibility of production organizations.\n\n\nSee also [Compare eval and paid organizations](/apigee/docs/api-platform/get-started/compare-paid-eval).\n\n#### Evaluation organization lifespan\n\nEvaluation organizations have a limited lifespan:\n\n1. **Day 0:** Create the evaluation organization.\n2. **Day 30:** Google sends you an email notification warning of the upcoming expiration.\n3. **Day 60:** Google deletes the evaluation organization.\n\nApigee Organizations within the Google Cloud hierarchy\n------------------------------------------------------\n\nThe following diagram shows the relationship between Apigee organizations and environments,\nand Google Cloud projects and folders.\n\nComponents within an organization\n---------------------------------\n\nThe following image shows the major components of the Apigee organizational model.\nThis model defines how your APIs, API products, apps, and app developers are all related within\nApigee.\n\nThis model does not show all of the features of Apigee, but it is meant to show you that the\norganization is the root of a deployment.\n\nThe following table describes the components of the organizational model in more detail:\n\nAdditional components of Apigee that are not shown are the API keys and OAuth tokens.\n\nApigee supports different types of authentication, such as a simple API key,\ntwo-legged OAuth, three-legged OAuth, and others.\n\nIf the API provider specifies API key verification as the authorization mechanism, the\nclient application must pass an API key with every request to your APIs. If\nthat key is valid, Apigee allows the request. Alternatively, if the API\nprovider specifies OAuth token verification as the authorization mechanism, the client\napplication must first obtain an OAuth token, and then pass that token with\nevery request to your APIs. If that token is valid, Apigee allows the\nrequest. Other custom authorization schemes are possible.\n\nAs an API provider, you must define a way for developers to register their apps. Each\napp registration will have one or more keys or credentials associated to it. If you\nallow developers to register their own applications via a developer portal, the developer\ncan retrieve the key or credential required to access your APIs, via a convenient,\nself-service experience.\n\nAt the time of app registration, developers can choose to access a single API\nproduct or multiple API products. A developer's app uses the same key/credential to access\nall API products associated with the app.\n\nAt any time, you can revoke the key so that the developer's app no longer has access\nto your APIs (even though the registered representation of the developer's app still\nexists in your organization). Or, you can revoke a developer, in which case all of the credentials\nfor any apps registered for that developer become inoperable. Revocation is reversible.\nAt the time Apigee creates the app credential,\nyou can specify an expiry so that the\ndeveloper must obtain a new key or credential after a specific time.\n\nApigee users\n------------\n\nApigee users make up the organization's API team,\nwhich can include people such as administrators, API proxy and API product creators,\nor users monitoring analytics and other statistics. End-users are people who use the\napps that Apigee developers build. In most cases, this documentation uses the term \"user\"\nto refer to an Apigee user.\n\nAdministrators can add users to an organization.\n\nDifferent users can have different roles and access privileges. For example, define\nsome users as Organization Administrators and Operations Administrators with privileges\nto modify the organization and its components, and define other users with permissions to\ncreate API proxies and API products, but without the privileges to modify other\nusers.\n\nUsers can be members of multiple organizations. For example, your company might define\nmultiple organizations on Apigee to support different developer communities, even\nthough internally, the same people build all of the API proxies and API products and are\ntherefore members of all of your organizations.\n\nYou don't have to create an Apigee organization to be a user. An administrator\ncan add you to an existing organization.\n\nIn the Google Cloud console, go to the Apigee page.\n\n[Go to Apigee](https://console.cloud.google.com//apigee)\n\n\u003cbr /\u003e\n\nEntitlements and billing\n------------------------\n\nWhether the paid organization uses a **Subscription** or **Pay-as-you-go**\npricing model, the items that are metered for billing purposes are:\nenvironments, API calls, and proxy deployments.\n\nSubscription plans allow you to pre-pay for entitlements, in exchange for significant\ndiscounts. Subscription plans make sense at higher consumption volumes - where there are larger\nnumbers of environments, a high volume of API calls, or a large number of API proxies under\nmanagement by Apigee. Under the Pay-as-you-go model, you pay only for the resources you use, but\nyou do not enjoy volume discounts.\n\n### Subscription entitlements\n\nFor more details, see [Subscription entitlements](/apigee/docs/api-platform/reference/subscription-entitlements).\n\n\n### Pay-as-you-go entitlements\n\nFor more details, see [Pay-as-you-go entitlements](/apigee/docs/api-platform/reference/pay-as-you-go-entitlements)."]]