# Azure API Management(APIM) 포털 메뉴 완전 가이드

> 작성 기준일: 2026-08-12
> 대상: Azure Portal에서 APIM 리소스 진입 시 보이는 왼쪽 탐색 메뉴 전체
> 참고: Microsoft Learn 공식 문서(learn.microsoft.com/azure/api-management)를 기반으로 정리했습니다. 화면 구성/메뉴명은 Portal 업데이트에 따라 수시로 바뀌므로, 실제 운영 판단 시에는 반드시 최신 공식 문서와 Azure 가격 계산기를 함께 확인하세요.

---

## 0. 큰 그림 먼저 — APIM이 하는 일

APIM은 "API 게이트웨이 + API 수명주기 관리 + 개발자 포털"을 하나로 묶은 PaaS 서비스입니다. 백엔드(App Service, Function, AKS, 온프레미스 등) 앞단에 배치되어

- **게이트웨이(Gateway)**: 실제 트래픽이 지나가는 프록시. 인증, 속도 제한(rate limit), 캐싱, 변환(정책) 수행
- **관리 플레인(Management plane)**: API 정의, 정책, 제품/구독 관리
- **개발자 포털(Developer portal)**: API 소비자(외부/내부 개발자)에게 문서·테스트 콘솔·키 발급을 제공

이 세 축을 이해하면 아래 메뉴 대부분이 자연스럽게 분류됩니다.

메뉴는 크게 8개 카테고리입니다.

1. 개요(빠른 진단/거버넌스)
2. APIs(핵심 리소스 정의)
3. 개발자 포털(소비자 대면)
4. 모니터링
5. Deployment + infrastructure(운영/인프라)
6. 보안
7. 자동화
8. 도움말

---

## 1. 개요 (Overview)

| 메뉴 | 역할 |
|---|---|
| 개요 | 리소스 대시보드(엔드포인트 URL, 상태, 위치, 가격 계층 등 요약) |
| 활동 로그 | Azure Activity Log — 이 리소스에 대한 **관리 작업(제어 플레인)** 이력 |
| 액세스 제어(IAM) | Azure RBAC 역할 할당 |
| 태그 | Azure 리소스 태그 |
| 문제 진단 및 해결 | Azure 자체 자동 진단 도구 |
| 리소스 시각화 도우미 | 리소스 간 종속성 시각화(Resource Visualizer) |
| 이벤트 | Azure Event Grid 연동 이벤트 뷰 |

### 1-1. 개요(Overview)
서비스의 **게이트웨이 URL**(예: `https://{서비스명}.azure-api.net`), 관리 URL, 위치, SKU, 상태(온라인/생성중/업데이트중)를 한눈에 보여주는 랜딩 페이지입니다.

- **활용 예시**: 신규 팀원 온보딩 시 "게이트웨이 엔드포인트가 어디냐"를 빠르게 안내할 때, 또는 배포 파이프라인에서 Portal을 열어 SKU/상태를 육안 확인할 때 사용.
- **주의사항**: 여기 보이는 게이트웨이 URL은 **기본 도메인**(`azure-api.net`)입니다. 사용자 지정 도메인을 붙였다면 여기엔 반영되지 않을 수 있으니 실제 호출 URL은 API 설정에서 재확인하세요.

### 1-2. 활동 로그 (Activity log)
Azure Resource Manager 레벨에서 발생한 **관리 작업**(생성, 업데이트, 삭제, 스케일링, 키 재생성 등) 이력입니다. **API 호출 트래픽 로그가 아닙니다** — 이건 "모니터링 > 로그/메트릭"의 영역입니다.

- **활용 예시**: "누가 언제 이 APIM의 가격 계층을 바꿨는가", "정책을 언제 배포했는가"를 감사(audit)할 때.
- **주의사항**: 데이터 플레인(실제 API 요청/응답)은 여기 안 잡힙니다. 헷갈리는 사람이 많습니다.
- **비용**: Activity Log는 90일 무료 보관, 조회 자체는 무료입니다. Log Analytics로 장기 보관 연결 시 그쪽 비용이 발생합니다.
- 공식 문서: Azure Monitor Activity log 개요

### 1-3. 액세스 제어(IAM)
Azure RBAC로 "누가 이 APIM 리소스에 대해 무엇을 할 수 있는가"를 관리합니다.

- **주요 내장 역할**: `API Management Service Contributor`(관리 권한), `API Management Service Reader Role`(읽기 전용), `API Management Developer Portal Content Editor` 등.
- **주의사항**: RBAC는 **Azure 리소스(관리) 권한**이고, 개발자 포털 사용자/그룹 권한과는 **완전히 별개 시스템**입니다(개발자 포털 쪽은 아래 4장 참고). 이 둘을 혼동해서 "포털에 사용자 초대했는데 Azure Portal 접근이 안 된다"는 문의가 흔합니다.
- **활용 예시**: CI/CD 서비스 프린시펄에는 `API Management Service Contributor`만 최소 권한으로 부여, 읽기 전용 감사 계정은 Reader 역할로 분리.

### 1-4. 태그
표준 Azure 리소스 태그(비용 배분, 환경 구분: `env=prod`, `team=payments` 등)입니다. Cost Management의 태그별 비용 분석과 연동됩니다.

### 1-5. 문제 진단 및 해결
연결 문제, 성능 저하, 정책 오류 등에 대해 Azure가 제공하는 자가 진단 마법사입니다. 게이트웨이 5xx 급증, 백엔드 타임아웃 등 흔한 패턴에 대한 체크리스트를 제공합니다.

- **활용 예시**: 장애 초동 대응 시 로그 분석 전에 1차로 돌려보면 원인 후보를 빠르게 좁힐 수 있음.

### 1-6. 리소스 시각화 도우미
연결된 리소스(VNet, Private Endpoint, App Insights 등)와의 관계를 그래프로 보여줍니다. 복잡한 네트워크 구성 검증에 유용.

### 1-7. 이벤트
Event Grid를 통해 APIM 관련 시스템 이벤트(예: 구독 생성/삭제 등 특정 이벤트)를 구독/시각화할 수 있는 진입점입니다.

---

## 2. APIs — 핵심 리소스 정의 영역

APIM의 "본체"에 해당하는 카테고리입니다. 실제 API 설계·정책·유통(제품화)이 여기서 이뤄집니다.

| 메뉴 | 역할 |
|---|---|
| 작업 영역 | 대규모 조직을 위한 API 관리 분할(Workspaces) |
| API | API 정의/작업(Operation)/정책 |
| MCP 서버 | AI 에이전트용 Model Context Protocol 서버 노출(신규 기능) |
| 제품 | API를 묶어서 유통하는 단위(Products) |
| 구독 | 제품/API에 대한 접근 키 |
| 명명된 값 | 정책에서 재사용하는 변수/시크릿 |
| Backends | 백엔드 엔드포인트 추상화 객체 |
| 정책 조각 | 재사용 가능한 정책 스니펫 |
| API 태그 | API 분류용 태그(카탈로그 검색용) |
| 스키마 | 재사용 가능한 데이터 모델(OpenAPI/XML 스키마) |
| 자격 증명 관리자 | 백엔드 인증정보(OAuth 등) 중앙관리 |
| API 센터 | Azure API Center 연동(조직 전체 API 인벤토리) |
| Power Platform | Power Apps/Power Automate 커넥터 노출 |

### 2-1. 작업 영역 (Workspaces)
큰 조직에서 여러 팀이 하나의 APIM 인스턴스를 공유할 때, 팀별로 API/제품/정책을 **격리된 하위 관리 단위**로 나눌 수 있게 해주는 기능입니다. 팀별로 RBAC를 워크스페이스 단위로 분리 부여할 수 있습니다.

- **활용 예시**: 하나의 프리미엄 APIM을 여러 사업부(결제팀, 물류팀, 파트너팀)가 공유하되, 각 팀이 서로의 API·정책·구독을 못 보게(또는 못 건드리게) 격리.
- **주의사항**: **Premium(v2) 계층 이상**에서 지원되는 비교적 최근 기능입니다. 기존 Standard/Basic 계층에서는 안 보일 수 있습니다. 워크스페이스 전환은 조직 구조 재설계급 작업이므로 신규 구축이 아니면 신중히 접근.
- 공식 문서: "Workspaces in Azure API Management"

### 2-2. API
가장 핵심 메뉴. 개별 API(예: `Orders API`)를 정의하고, 그 안의 각 엔드포인트(Operation, 예: `GET /orders/{id}`)를 관리하며, API/Operation 단위로 **정책(Policy) XML**을 적용합니다.

- **가져오는 방법**: OpenAPI(Swagger), WSDL, App Service/Function App 자동 임포트, WebSocket, GraphQL 스키마, gRPC 등 다양한 소스에서 가져오기 가능.
- **정책이 핵심**: `inbound`(요청 전) / `backend`(백엔드 호출) / `outbound`(응답 후) / `on-error` 4단계 파이프라인에 `<rate-limit>`, `<validate-jwt>`, `<cors>`, `<set-header>`, `<cache-lookup>` 등의 정책을 XML로 삽입.
- **활용 예시**:
  - 백엔드 코드 변경 없이 API Gateway 레벨에서 JWT 검증 강제
  - 레거시 SOAP 백엔드를 REST/JSON으로 변환해 노출(정책의 `<xml-to-json>` 등)
  - API 버저닝(`v1`, `v2`)과 리비전(revision) 관리로 무중단 배포
- **주의사항**:
  - 정책은 **범위(Scope)가 겹치면 상속**됩니다: 전역(All APIs) → 제품 → API → Operation 순으로 적용. 어디서 뭐가 적용되는지 추적하지 않으면 디버깅이 매우 힘들어짐.
  - **리비전(Revision)** vs **버전(Version)**을 혼동하기 쉬움. 리비전=같은 버전 내 무중단 변경 테스트용(비공개 가능), 버전=클라이언트에게 노출되는 실제 API 버전 분기.
  - Consumption 계층에서는 지원되지 않는 정책/기능이 있음(예: 일부 캐싱 정책, VNet 통합 등) — SKU별 기능 매트릭스를 반드시 확인.
- **비용**: API 정의 자체는 무료. 비용은 APIM 인스턴스의 SKU(가격 계층)와 호출량(Consumption 계층의 경우 호출 단위 과금)에서 발생합니다 → 5-1절 참고.

### 2-3. MCP 서버 (MCP Servers)
Model Context Protocol을 통해 기존 REST API를 AI 에이전트(예: LLM 기반 코파일럿)가 "도구(tool)"로 직접 호출할 수 있게 노출하는 최신 기능입니다. 기존 API를 코드 재작성 없이 MCP 서버로 래핑합니다.

- **활용 예시**: 이미 APIM에 등록된 사내 API를 Copilot Studio나 사내 에이전트가 MCP 클라이언트로 바로 소비하게 할 때.
- **주의사항**: 2025년 이후 추가된 신생 기능으로 리전/계층 가용성이 제한적일 수 있고 빠르게 변경 중입니다. 프로덕션 적용 전 최신 GA 여부를 반드시 확인하세요.

### 2-4. 제품 (Products)
하나 이상의 API를 묶어 **개발자 포털에 유통하는 단위**입니다. 제품 단위로 사용량 한도(quota), 속도 제한(rate limit), 승인 필요 여부(구독 승인 프로세스)를 설정합니다.

- **활용 예시**:
  - `Free Tier` 제품(승인 불필요, 초당 5콜 제한)과 `Partner Tier` 제품(관리자 승인 필요, 무제한)으로 동일 API를 다른 조건으로 유통
  - 내부 전용 API는 `Unlimited`(기본 제공, 비공개) 제품에 담아 포털 미노출
- **주의사항**: API는 제품에 포함되지 않으면 **구독 키로 접근 자체가 안 됩니다**(제품에 속하지 않은 API는 기본적으로 개발자 포털에 노출되지 않고, "구독 필요" 설정 시 구독 없이 호출 불가). 신규 API 배포 후 "왜 401/403이 나지?"의 흔한 원인 1순위.

### 2-5. 구독 (Subscriptions)
제품(또는 특정 API/전체 API)에 대한 **접근 키(Subscription Key)** 발급 단위입니다. Primary/Secondary 키 2개가 세트로 제공되어 무중단 키 순환(rotation)이 가능합니다.

- **활용 예시**: 파트너사별로 별도 구독을 발급해 사용량을 개별 추적, 문제 발생 시 해당 구독만 즉시 취소(revoke).
- **주의사항**: 구독 키는 `Ocp-Apim-Subscription-Key` 헤더(또는 쿼리 파라미터)로 전달되는데, 이는 **인증(authentication)이 아니라 식별/과금 목적에 가까운 약한 보호**입니다. 실제 보안은 OAuth/JWT 검증 정책을 별도로 걸어야 합니다. 구독 키만 믿고 API를 공개하면 안 됨.

### 2-6. 명명된 값 (Named Values)
정책 XML에서 `{{key-name}}` 형태로 참조하는 재사용 가능한 상수/시크릿 저장소입니다. 일반 값, Key Vault 참조, 시크릿(마스킹) 세 종류를 지원합니다.

- **활용 예시**: 백엔드 URL, API 키, 클라이언트 시크릿 등을 정책 XML에 하드코딩하지 않고 이름으로 참조 → 환경별(Dev/Prod)로 같은 정책 템플릿을 값만 바꿔 재사용.
- **주의사항**: 진짜 민감정보(비밀번호, 인증서 키)는 "일반 값"이 아니라 **Key Vault 연동** 방식으로 등록해야 합니다. Key Vault 연동 시 APIM의 관리 ID(Managed Identity, 6-2절)에 Key Vault 접근 권한이 있어야 하며, Key Vault 측 자격 증명 만료/교체 시 APIM이 자동 동기화 실패할 수 있어 모니터링이 필요합니다.

### 2-7. Backends
백엔드 서비스(URL + 인증 방식 + 회로 차단기 설정 등)를 하나의 재사용 가능한 객체로 추상화합니다.

- **활용 예시**: 동일 백엔드를 여러 API가 공유할 때 URL을 한 곳에서만 관리. Circuit breaker(장애 백엔드 자동 우회), 부하 분산(다중 백엔드 풀) 설정도 여기서.
- **주의사항**: Backend 엔티티를 안 쓰고 정책에 URL을 직접 박아두는 구성도 여전히 가능하지만, 백엔드 교체/DR 시 유지보수성이 크게 떨어짐 — 신규 구축이라면 Backend 엔티티 사용을 권장.

### 2-8. 정책 조각 (Policy Fragments)
자주 쓰는 정책 블록(예: 표준 CORS 설정, 표준 에러 처리)을 **재사용 가능한 조각**으로 저장해두고 `<include-fragment>`로 여러 API/정책에서 불러다 쓰는 기능입니다.

- **활용 예시**: 전사 표준 보안 헤더 정책을 조각 하나로 만들어 모든 API에 include → 표준 변경 시 조각 하나만 수정하면 전체 반영.
- **주의사항**: 조각을 수정하면 이를 참조하는 **모든 API에 즉시 영향**을 줍니다. 변경 전 어디서 참조 중인지(사용처) 확인 없이 수정하면 광범위한 장애로 이어질 수 있음.

### 2-9. API 태그 (Tags)
API/Operation을 카테고리별로 분류하는 라벨. 개발자 포털의 API 카탈로그 검색/필터링에 사용됩니다.

### 2-10. 스키마 (Schemas)
여러 API가 공유하는 데이터 모델(JSON Schema, XML Schema)을 등록해두는 곳. OpenAPI `components/schemas`에 해당하는 재사용 가능 스키마 저장소입니다.

### 2-11. 자격 증명 관리자 (Credential Manager, 구 "Authorizations")
APIM이 **백엔드로 나가는(outbound)** 요청에 필요한 OAuth 2.0 자격 증명(예: Microsoft Entra ID, GitHub, Google 등 외부 서비스 인증)을 중앙에서 관리하고 토큰 갱신을 자동화하는 기능입니다.

- **활용 예시**: APIM 정책이 Microsoft Graph API를 호출해야 할 때, 클라이언트 시크릿/리프레시 토큰 관리를 직접 코딩하지 않고 Credential Manager의 Authorization 프로바이더에 위임.
- **주의사항**: 구독 키(2-5절, 인바운드 인증 식별자)와는 목적이 완전히 다릅니다 — 이건 아웃바운드(APIM→외부 서비스) 인증입니다. 이름이 비슷해 헷갈리기 쉬움.

### 2-12. API 센터 (API Center)
별도 Azure 리소스인 **Azure API Center**(조직 전체의 API 인벤토리/거버넌스 카탈로그)와 이 APIM 인스턴스를 연동하는 진입점입니다. APIM에 등록된 API를 API Center의 중앙 카탈로그에 자동 동기화할 수 있습니다.

- **주의사항**: API Center는 **별개의 과금 리소스**입니다. APIM 메뉴에서 클릭한다고 자동으로 무료가 아니며, API Center 자체 요금제를 따로 확인해야 합니다.

### 2-13. Power Platform
등록된 API를 Power Apps/Power Automate용 **커스텀 커넥터**로 내보내는 기능입니다. Citizen developer(현업 개발자)가 Power Automate 플로우에서 사내 API를 바로 사용할 수 있게 해줍니다.

- **주의사항**: Power Platform 커넥터로 내보낼 API는 인증 방식이 Power Platform이 지원하는 형태(API Key, OAuth2 등)와 맞아야 하며, Power Platform 환경(Environment)에 대한 별도 라이선스/권한이 필요합니다.

---

## 3. 개발자 포털 (Developer Portal)

API 소비자에게 문서·테스트 콘솔·구독 관리 UI를 제공하는 자동 생성 웹사이트(정적 사이트 + CMS 형태) 관리 영역입니다.

| 메뉴 | 역할 |
|---|---|
| 포털 개요 | 포털 편집/게시 진입점 |
| 설정 | 인증 방식, 이용약관 등 포털 전역 설정 |
| 사용자 | 포털 가입자(개발자) 계정 관리 |
| 그룹 | 사용자 그룹(가시성 제어 단위) |
| ID | 외부 로그인 제공자(Entra ID, Azure AD B2C 등) 연동 |
| 위임 | 회원가입/구독 로직을 외부 사이트에 위임 |
| OAuth 2.0 + OpenID Connect | 테스트 콘솔용 OAuth 서버 등록 |

### 3-1. 포털 개요
WYSIWYG 편집기로 포털 페이지를 구성하고 "게시(Publish)"하는 관리 콘솔로 이동합니다.

- **주의사항**: 편집 내용은 **게시(Publish) 버튼을 눌러야** 실제 라이브 포털에 반영됩니다. 임시 저장만 하고 게시를 잊는 실수가 흔합니다.

### 3-2. 설정
포털의 회원가입 허용 여부, 기본 언어, 이용약관 필수 동의 여부 등 전역 옵션.

### 3-3. 사용자 (Users)
개발자 포털에 가입한 외부/내부 개발자 계정 목록. Azure Portal IAM(1-3절)과는 **별개의 사용자 저장소**입니다.

- **주의사항**: 여기서 관리자가 사용자를 초대(Invite)하거나 상태(활성/차단)를 관리할 수 있지만, 이 계정으로 Azure Portal에 로그인할 수 있는 건 아닙니다.

### 3-4. 그룹 (Groups)
사용자를 묶어 **특정 제품(Product)의 가시성**을 제어하는 단위입니다. 기본 제공 그룹: `Administrators`, `Developers`(가입 즉시), `Guests`(비로그인 방문자).

- **활용 예시**: 파트너사 그룹을 만들어 `Partner Tier` 제품만 보이게 하고 일반 방문자에게는 숨김.

### 3-5. ID (Identities)
개발자 포털 로그인 방식을 설정합니다. 이메일/비밀번호(기본) 외에 Microsoft Entra ID, Entra ID B2C, 기타 OpenID Connect 제공자를 추가할 수 있습니다.

### 3-6. 위임 (Delegation)
회원가입·로그인·구독 관리 화면 자체를 APIM 내장 포털이 아니라 **자체 구축한 외부 사이트**로 넘기는(위임하는) 고급 기능입니다. 기업이 이미 자체 개발자 포털/CRM을 갖고 있을 때 사용.

- **주의사항**: 위임 서명 검증 로직을 직접 구현해야 하는 등 구현 난이도가 높습니다. 대부분의 조직은 기본 내장 포털로 충분합니다.

### 3-7. OAuth 2.0 + OpenID Connect
개발자 포털의 "Try it" 테스트 콘솔에서 OAuth 인증이 필요한 API를 테스트할 수 있도록 OAuth 서버 정보(Authorization endpoint, Token endpoint, Client ID 등)를 등록합니다.

---

## 4. 모니터링 (Monitoring)

| 메뉴 | 역할 |
|---|---|
| 분석 | Azure Monitor 기반 신규 API 사용 분석 대시보드 |
| 분석(클래식) | 구버전 Application Insights 기반 분석(레거시) |
| Application Insights | APM 연동(요청 추적, 종속성 추적) |
| 경고 | Azure Monitor Alert 규칙 |
| 메트릭 | 실시간 메트릭(용량, 지연시간, 요청 수 등) |
| 진단 설정 | 로그/메트릭을 Log Analytics 등으로 라우팅 |
| 로그 | Log Analytics 쿼리(Kusto/KQL) |
| 관리자 권장 사항 | Azure Advisor 권장 사항 |
| Workbooks | 사용자 지정 대시보드/리포트 |

### 4-1. 분석 / 분석(클래식)
API별/제품별/구독별 호출 수, 지연시간, 에러율, 대역폭 등을 시각화합니다. "분석(클래식)"은 구버전(Application Insights 기반) 기능으로, 신규 "분석"은 Azure Monitor 기반의 후속 기능입니다.

- **주의사항**: 클래식 분석은 순차적으로 폐기(deprecate) 예정/진행 중인 기능일 수 있으므로 신규 대시보드 구축 시 최신 "분석"을 우선 사용하세요.

### 4-2. Application Insights
개별 API 요청을 분산 추적(distributed tracing)하려면 Application Insights 연결이 필요합니다. 정책에 `<trace>` 를 추가하거나 진단 설정으로 샘플링 비율을 조정할 수 있습니다.

- **주의사항**: 100% 샘플링(모든 요청 추적)은 고트래픽 환경에서 **Application Insights 비용을 크게 증가**시킵니다. 프로덕션에서는 샘플링 비율을 낮추는 것이 일반적입니다.
- **비용**: Application Insights는 수집 데이터량(GB) 기준 별도 과금(Log Analytics 요금제 기반)입니다.

### 4-3. 경고 (Alerts)
용량 초과, 5xx 급증, 백엔드 지연 등에 대한 임계값 기반 알림 규칙을 Azure Monitor에 생성합니다.

- **활용 예시**: "5분간 5xx 비율 5% 초과 시 Teams/이메일/PagerDuty로 통보"

### 4-4. 메트릭
Capacity, Requests, Duration, Failed Requests 등 사전 정의된 플랫폼 메트릭을 즉석 차트로 확인.

- **활용 예시**: Capacity 메트릭은 **스케일 아웃 판단 기준**으로 자주 사용됩니다(6-3절 "스케일 아웃"과 연동).

### 4-5. 진단 설정 (Diagnostic settings)
게이트웨이 로그(GatewayLogs), 메트릭 등을 Log Analytics 작업 영역, Storage Account, Event Hub로 내보내는 설정입니다. **이 설정을 켜지 않으면 상세 요청 로그가 별도로 남지 않습니다.**

- **주의사항**: 신규 APIM 생성 후 진단 설정을 깜빡하고 안 켜서 장애 시점에 로그가 없는 경우가 매우 흔한 실수입니다. **구축 직후 반드시 설정하세요.**
- **비용**: Log Analytics로의 수집은 데이터량 기준 과금. Storage Account 보관은 스토리지 비용.

### 4-6. 로그
Log Analytics workspace에 연결되어 있다면 KQL(Kusto Query Language)로 `ApiManagementGatewayLogs` 등의 테이블을 직접 쿼리합니다.

- **활용 예시**: "지난 1시간 동안 어떤 구독 키가 429(rate limit)를 가장 많이 받았나" 같은 임의 쿼리 분석.

### 4-7. 관리자 권장 사항
Azure Advisor의 APIM 관련 권장 사항(비용 절감, 보안 강화, 안정성/성능 개선 제안)을 모아 보여줍니다.

- **활용 예시**: 유휴 상태로 방치된 고사양 SKU에 대한 다운그레이드 제안, 사용 중이지 않은 오래된 TLS 프로토콜 비활성화 제안 등을 정기적으로 확인.

### 4-8. Workbooks
Azure Monitor Workbook 템플릿으로 여러 메트릭/로그를 조합한 커스텀 대시보드를 만듭니다. 재사용 가능한 보고서 형태로 팀에 공유 가능.

---

## 5. Deployment + infrastructure

인스턴스의 규모, 네트워크, 가용성을 결정하는 **가장 비용/아키텍처 영향이 큰 카테고리**입니다.

| 메뉴 | 역할 |
|---|---|
| 가격 책정 계층 | SKU(Consumption/Developer/Basic/Standard/Premium 등) 변경 |
| 위치 | 다중 리전 배포(Premium 전용) |
| 스케일 아웃(자동 크기 조정) | 유닛 수 자동/수동 조정 |
| 자체 호스팅 게이트웨이 | 온프레미스/타 클라우드에 게이트웨이 배포 |
| 외부 캐시 | Redis 등 외부 캐시 연결 |
| 사용자 지정 도메인 | 커스텀 도메인 + TLS 인증서 |
| 네트워크 | VNet 통합 |
| 알림 | 시스템 이벤트(구독 생성 등) 이메일 알림 대상 |
| 알림 템플릿 | 발송되는 이메일 템플릿 편집 |
| 관리 API | APIM 자체 관리 REST API(ARM 외 별도) |

### 5-1. 가격 책정 계층 (Pricing tier) — 비용 핵심
가장 중요한 메뉴입니다. 계층별 대략적 특징(정확한 최신 가격은 반드시 Azure 가격 계산기에서 확인):

| 계층 | 특징 | 대표 사용처 |
|---|---|---|
| **Consumption** | 서버리스, 호출당 과금, 콜드스타트 있음, VNet 통합/캐싱 등 일부 기능 제한 | 저트래픽/이벤트성 API, PoC |
| **Developer** | 모든 기능 사용 가능하지만 **SLA 없음** | 개발/테스트 전용, 프로덕션 금지 |
| **Basic / Basic v2** | 소규모 프로덕션, SLA 있음 | 소규모 서비스 |
| **Standard / Standard v2** | 중간 규모, VNet 통합(v2) 지원 확대 | 일반 프로덕션 |
| **Premium / Premium v2** | 다중 리전, VNet 완전 통합, 워크스페이스, 무제한 스케일 유닛 | 엔터프라이즈/대규모/고가용 |
| **Isolated (레거시)** | 완전 격리 네트워크(단종 방향, v2로 대체 추세) | 특수 컴플라이언스 |

- **주의사항**:
  - **Developer 계층은 SLA가 없습니다.** 프로덕션에 절대 사용하면 안 됩니다(가격이 싸다고 오용하는 사례가 많음).
  - 계층 다운그레이드는 항상 가능한 게 아닙니다(예: Premium에서 만든 워크스페이스/다중 리전 구성이 있으면 하위 계층으로 못 내려감). 계층 선택은 **되돌리기 어려운 결정**일 수 있으니 신중히.
  - v1(Basic/Standard/Premium 클래식)과 v2(Basic v2/Standard v2/Premium v2) 라인업은 내부 아키텍처가 다르고 기능 지원 범위도 다릅니다. 신규 구축은 v2 라인업이 권장되는 추세입니다.
- **비용 구조 요약**: Consumption은 호출 수(백만 건당) + 데이터 전송량 과금, 나머지 계층은 **유닛(Unit) 단위 시간당/월 정액 과금**(유닛 = 처리 용량 단위, 스케일 아웃으로 유닛 수를 늘리면 비용도 선형 증가)입니다.

### 5-2. 위치 (Locations)
**Premium 계층**에서만 지원되는 다중 리전 배포. 하나의 APIM 리소스를 여러 Azure 리전에 게이트웨이 복제본으로 배포해 지연시간을 줄이고 리전 장애에 대비합니다.

- **주의사항**: 리전을 추가하면 해당 리전만큼 **유닛 비용이 추가로 곱해집니다**(리전마다 최소 1유닛). "위치 = 무료 복제"가 아닙니다.

### 5-3. 스케일 아웃(자동 크기 조정)
게이트웨이 처리 용량을 늘리는 **유닛(Unit) 수**를 수동 또는 규칙 기반(예: CPU/메모리/요청 수 임계값) 자동 조정합니다.

- **주의사항**: Consumption/Developer 계층은 이 개념이 다르거나(Consumption은 완전 서버리스로 자동 확장, Developer는 유닛 개념 자체가 제한적) 지원 방식이 다릅니다. Basic 이상부터 본격적인 다중 유닛 스케일이 의미를 가집니다.
- **비용**: 유닛 수만큼 **직접적으로 시간당 요금이 증가**하는, 비용에 가장 즉각적으로 영향을 주는 설정 중 하나입니다.

### 5-4. 자체 호스팅 게이트웨이 (Self-hosted gateway)
APIM의 관리 플레인은 Azure에 두고, 실제 트래픽을 처리하는 **게이트웨이(데이터 플레인)만 컨테이너로 온프레미스/타 클라우드/Edge에 배포**하는 하이브리드 구성입니다.

- **활용 예시**: 규제상 데이터가 특정 국가/사내망을 벗어날 수 없는 경우, 정책 실행은 로컬에서 하되 API 카탈로그/거버넌스는 Azure에서 중앙 관리.
- **주의사항**: v1은 Consumption 계층에서 미지원 등 SKU별 제약이 있었고, 컨테이너 자체의 라이프사이클(업그레이드, 인증서 갱신, 컨테이너 호스팅 비용)은 사용자가 직접 관리해야 합니다 — "완전 관리형"이 아닙니다.

### 5-5. 외부 캐시 (External cache)
기본 내장 캐시 대신 **외부 Redis(Azure Cache for Redis 등)**를 연결해 캐싱 정책(`<cache-store>`, `<cache-lookup>`)이 이를 사용하게 합니다.

- **활용 예시**: 다중 리전/다중 유닛 환경에서 캐시를 **인스턴스 간 공유**해야 할 때(내장 캐시는 유닛/리전별로 분리되어 있어 공유가 안 됨).
- **비용**: Azure Cache for Redis는 별도 리소스로 별도 과금됩니다.

### 5-6. 사용자 지정 도메인 (Custom domains)
기본 `*.azure-api.net` 대신 `api.mycompany.com` 같은 자체 도메인 + TLS 인증서를 게이트웨이/포털/관리 엔드포인트별로 설정합니다.

- **주의사항**: 인증서 만료 관리를 놓치면 전체 API 장애로 직결됩니다. Key Vault 연동으로 인증서를 등록하면 자동 갱신/동기화가 가능하니 수동 업로드보다는 이 방식을 권장.

### 5-7. 네트워크 (Network)
APIM을 VNet(가상 네트워크) 안으로 통합합니다. **External**(게이트웨이는 공인 IP로 접근 가능, 백엔드만 VNet 내부) 또는 **Internal**(게이트웨이 자체도 VNet 내부에서만 접근 가능) 모드를 선택합니다.

- **주의사항**: v1 라인업에서 VNet 통합은 계층 제약(Developer/Premium만 지원 등)이 있었고, 서브넷에 필요한 NSG 규칙(APIM 관리 트래픽용 포트 개방 등)을 놓치면 배포가 "Updating" 상태에서 멈추는 흔한 사고 패턴이 있습니다. VNet 통합은 **사전에 필요한 서브넷 크기/NSG 규칙을 공식 문서에서 정확히 확인 후** 진행하세요.

### 5-8. 알림 (Notifications)
"구독 요청 승인 대기", "할당량 근접" 같은 **시스템 이벤트 발생 시 이메일을 받을 수신자 그룹**을 설정합니다(Azure Monitor Alert와는 별개로, APIM 자체 내장 이벤트 알림입니다).

### 5-9. 알림 템플릿
위 알림/개발자 포털 자동 이메일(가입 환영, 구독 승인 등)의 **본문 템플릿**을 커스터마이징합니다.

### 5-10. 관리 API (Management API)
APIM 인스턴스 자체를 프로그래밍 방식으로 제어하는 **REST API**(ARM API와는 별도 체계, 주로 자동화/CI-CD나 커스텀 관리 도구 개발용)에 대한 정보/토큰 발급 진입점입니다.

- **주의사항**: 일반적인 IaC(Bicep/Terraform/ARM template)는 ARM 리소스 공급자를 통해 배포하는 것이 표준이며, 이 "관리 API"는 그와 별개의 레거시/특수 목적 API입니다. 신규 자동화는 ARM/Bicep 우선 고려를 권장.

---

## 6. 보안 (Security)

| 메뉴 | 역할 |
|---|---|
| 클라우드용 Defender | Microsoft Defender for Cloud 보안 권장 사항 |
| 관리 ID | System/User-assigned Managed Identity |
| 인증서 | 클라이언트 인증서(mTLS)/CA 인증서 관리 |
| 프로토콜 + 암호 | TLS 버전, 암호 그룹(cipher suite) 설정 |

### 6-1. 클라우드용 Defender
Microsoft Defender for Cloud(구 Security Center)의 보안 점수/권장 사항 중 이 APIM에 해당하는 항목만 필터링해 보여줍니다.

- **비용**: Defender for APIs와 같은 유료 플랜을 활성화하면 별도 과금이 발생합니다(무료 기본 보안 권장 사항과 유료 고급 위협 탐지는 구분됨).

### 6-2. 관리 ID (Managed Identity)
APIM이 Key Vault, Storage, 다른 Azure 리소스에 **암호 없이(비밀번호/키 하드코딩 없이)** 접근할 수 있게 하는 Microsoft Entra ID 자격 증명입니다.

- **활용 예시**: 2-6절 "명명된 값"의 Key Vault 참조, 5-6절 "사용자 지정 도메인"의 Key Vault 인증서 참조가 모두 이 관리 ID의 권한으로 동작합니다.
- **주의사항**: System-assigned ID는 APIM 리소스를 삭제하면 함께 삭제됩니다(재생성 시 새 ID가 생성되어 Key Vault 접근 정책을 다시 부여해야 함). 여러 리소스가 동일 ID를 공유해야 한다면 User-assigned를 사용하세요.

### 6-3. 인증서
클라이언트 인증서 기반 mTLS 인증에 사용할 CA 인증서, 그리고 APIM이 백엔드 호출 시 제시할 클라이언트 인증서를 관리합니다.

### 6-4. 프로토콜 + 암호
지원할 TLS 버전(TLS 1.0/1.1 비활성화 권장), 사용할 암호 그룹(cipher suite)을 화이트리스트 방식으로 설정합니다.

- **주의사항**: TLS 1.0/1.1을 비활성화하면 아직 이를 사용하는 구형 클라이언트의 연결이 즉시 끊깁니다. 변경 전 클라이언트 호환성을 반드시 파악하세요. 보안 컴플라이언스(PCI-DSS 등) 상 구버전 TLS/약한 cipher 비활성화가 요구되는 경우가 많습니다.

---

## 7. 자동화 (Automation)

| 메뉴 | 역할 |
|---|---|
| 작업 | Azure Automation 연동(런북 등) |
| 템플릿 내보내기 | 현재 리소스 구성을 ARM 템플릿으로 내보내기 |

### 7-1. 작업 (Tasks)
Azure의 표준 "Tasks" 기능(예: 인증서 만료 임박 시 Automation 런북 실행 등 조건부 자동화 워크플로 연결)입니다.

### 7-2. 템플릿 내보내기 (Export template)
현재 APIM 리소스의 설정을 **ARM(JSON) 템플릿**으로 즉시 추출합니다.

- **활용 예시**: 수동으로 Portal에서 구성한 인스턴스를 IaC로 전환(코드화)하고 싶을 때 초안 생성용으로 유용.
- **주의사항**: 내보낸 템플릿에는 시크릿 값이 포함되지 않거나 플레이스홀더로 대체되는 경우가 많고, 일부 하위 리소스(정책 XML 전체, 개발자 포털 콘텐츠 등)는 완전히 캡처되지 않을 수 있습니다. 그대로 재배포 가능한 "완전한 백업"으로 맹신하지 말고 검토 후 사용하세요. 진짜 IaC 운영이 목표라면 Bicep/Terraform으로 처음부터 코드화하는 것이 낫습니다.

---

## 8. 도움말 (Help)

| 메뉴 | 역할 |
|---|---|
| 리소스 상태 | Azure 플랫폼 관점의 이 리소스 가용성 상태(Resource Health) |
| 지원 + 문제 해결 | Microsoft 지원 티켓 생성 |

### 8-1. 리소스 상태 (Resource Health)
Azure 플랫폼이 감지한 이 특정 리소스의 가용성 상태(정상/성능 저하/사용 불가)와 과거 이력을 보여줍니다. 애플리케이션 레벨 문제가 아니라 **Azure 플랫폼 레벨** 이상 유무 판단에 유용합니다.

### 8-2. 지원 + 문제 해결
Microsoft에 정식 지원 요청(Support Request)을 여는 창구입니다. 심각도(Severity) 선택에 따라 응답 SLA가 다르며, 이는 가입한 **Azure Support Plan**(무료/Developer/Standard/Professional Direct 등)에 따라 달라집니다.

- **주의사항**: Sev A(치명적, 프로덕션 다운) 등급으로 열려면 유료 지원 플랜이 필요한 경우가 많습니다. 프로덕션 운영 중이라면 사전에 적절한 Support Plan 가입 여부를 점검해두세요.

---

## 9. 비용 관점 총정리 (실무 체크리스트)

APIM 비용은 크게 4가지 축에서 발생합니다.

1. **SKU/유닛(5-1, 5-3)**: 계층 선택과 유닛 수 — 가장 큰 비중. Consumption은 호출량 기반, 그 외는 시간당 정액 × 유닛 수.
2. **다중 리전(5-2)**: Premium에서 리전 추가 시 리전마다 유닛 비용 추가.
3. **부가 리소스**: Application Insights/Log Analytics(4-2, 4-5 — 수집 데이터량 기준), Azure Cache for Redis(5-5), Key Vault(2-6, 6-2), API Center(2-12), Defender for APIs(6-1) — 모두 **APIM 요금과 별개로 청구**됨.
4. **네트워크 아웃바운드 데이터 전송**: 리전 간/인터넷 이그레스 트래픽.

**비용 절감 팁**:
- 개발/테스트 환경은 Developer 계층(SLA 없음 전제) 또는 Consumption 계층 사용
- Application Insights 샘플링 비율 조정으로 로그 비용 절감
- Azure Advisor(4-7) 권장 사항 정기 검토
- 사용하지 않는 다중 리전/워크스페이스 정리

> 정확한 현재 가격은 반드시 [Azure 가격 계산기](https://azure.microsoft.com/pricing/calculator/) 및 [API Management 가격 페이지](https://azure.microsoft.com/pricing/details/api-management/)에서 리전/계층별로 재확인하세요. 본 문서의 가격 구조 설명은 개념적 요약이며 실제 숫자를 포함하지 않습니다(변동성이 크기 때문).

---

## 10. 자주 하는 실수 Top 5 (요약)

| # | 실수 | 원인 메뉴 | 해결 |
|---|---|---|---|
| 1 | 신규 API 배포 후 401/403 | API가 어떤 제품(Product)에도 속하지 않음 | 2-4 제품에 API 추가 |
| 2 | 장애 시점에 상세 로그가 없음 | 진단 설정 미설정 | 4-5 진단 설정을 구축 직후 활성화 |
| 3 | Developer 계층을 프로덕션에 사용 | SLA 없음을 간과 | 5-1 최소 Basic 이상으로 |
| 4 | 정책 조각/전역 정책 수정으로 광범위 장애 | 상속 범위 미파악 | 2-2, 2-8 참조처를 먼저 확인 후 수정 |
| 5 | VNet 통합 후 "Updating" 멈춤 | 서브넷 NSG 규칙 누락 | 5-7 사전에 필요 규칙 정확히 확인 |

---

## 참고(공식 문서 인덱스)

- API Management 개요: Microsoft Learn > Azure > API Management > Overview
- 정책 참조: Microsoft Learn > API Management policy reference
- 가격 계층 비교: Microsoft Learn > API Management pricing tiers / SKUs
- VNet 통합: Microsoft Learn > Use a virtual network with Azure API Management
- Workspaces: Microsoft Learn > Workspaces in Azure API Management
- Credential Manager: Microsoft Learn > Authorizations in Azure API Management
- 자체 호스팅 게이트웨이: Microsoft Learn > Azure API Management self-hosted gateway overview

*(문서 구조 및 URL 경로는 Microsoft가 수시로 개편하므로, 각 항목은 Microsoft Learn 검색으로 최신 링크를 찾는 것을 권장합니다.)*