WEBVTT

00:00:00.160 --> 00:00:02.540
마이크로소프트 지식단원의 또 다른 에피소드에 오신 것을 환영합니다.

00:00:02.680 --> 00:00:04.240
저는 진행자 미르코 피터스입니다.

00:00:04.440 --> 00:00:06.340
오늘 다룰 주제는 거의 모든 사람이 들어봤지만

00:00:06.340 --> 00:00:08.600
실제로 제대로 이해하는 사람은 드문 API입니다.

00:00:08.800 --> 00:00:10.700
아마 이 용어를 많이 들어보셨을 겁니다.

00:00:11.080 --> 00:00:14.440
사람들이 아는 척하고 싶을 때 사용하는 기술 용어 중 하나죠.

00:00:14.640 --> 00:00:16.700
하지만 사실 API는 간단합니다.

00:00:17.180 --> 00:00:19.580
소프트웨어가 서로 통신할 수 있는 방법일 뿐입니다.

00:00:19.820 --> 00:00:21.160
스마트폰이 서버에 데이터를 요청하면

00:00:21.160 --> 00:00:22.580
서버는 그 데이터를 다시 보내줍니다.

00:00:22.800 --> 00:00:24.020
이것이 바로 API입니다.

00:00:24.240 --> 00:00:27.020
이제 API가 20개, 50개 또는 100개 있다고 상상해보세요.

00:00:27.240 --> 00:00:29.740
각 API는 서로 다른 인증 방식, 속도 제한,

00:00:29.740 --> 00:00:32.100
문서와 여부 등 여러 가지 차이점이 있을 수 있습니다.

00:00:32.300 --> 00:00:35.740
두 앱 간의 간단한 대화로 시작했던 것이 순식간에 혼란으로 변합니다.

00:00:35.960 --> 00:00:38.220
중앙 관리자가 없다면 각 팀은 바퀴를 다시 발명하는 것처럼

00:00:38.220 --> 00:00:39.360
각자 알아서 처리해야 합니다.

00:00:39.540 --> 00:00:41.040
어떤 팀은 자체 인증 시스템을 구축하고

00:00:41.040 --> 00:00:42.840
다른 팀은 자체 로깅 시스템을 구축합니다.

00:00:43.020 --> 00:00:44.640
보안 취약점이 곳곳에 발생합니다.

00:00:44.860 --> 00:00:47.080
개발자들은 어떤 API가 어떤 역할을 하는지 혼란스러워하고

00:00:47.080 --> 00:00:49.040
시스템 전체에서 실제로 무슨 일이 일어나고 있는지

00:00:49.040 --> 00:00:49.980
한눈에 파악할 수 없게 됩니다.

00:00:50.220 --> 00:00:52.180
에이저 API 매니지먼트는 이 문제를 해결합니다.

00:00:52.180 --> 00:00:54.580
하나의 제어센터를 제공하여 API를 관리할 수 있도록 해줍니다.

00:00:54.740 --> 00:00:57.620
마치 API를 위한 항공 교통 관제탑과 같다고 생각하시면 됩니다.

00:00:57.880 --> 00:01:00.060
이번 에피소드를 통해 에이저 API 매니지먼트 가부헛인지,

00:01:00.340 --> 00:01:03.240
왜 중요한지, 그리고 모든 구성 요소가 어떻게 연결되는지 이해하게 될 것입니다.

00:01:03.400 --> 00:01:05.340
커피 한 잔 준비하시고 함께 살펴보겠습니다.

00:01:05.760 --> 00:01:08.420
문제점은 너무 많은 API와 그에 따른 관리 부재입니다.

00:01:08.640 --> 00:01:10.500
이것이 바로 현대 소프트웨어의 현실입니다.

00:01:10.680 --> 00:01:13.080
10년 전에는 하나의 큰 애플리케이션, 즉 모노리식 아키텍처,

00:01:13.320 --> 00:01:16.100
하나의 데이터베이스, 하나의 API로 구성된 간단한 구조였을 것입니다.

00:01:16.100 --> 00:01:20.120
하지만 오늘날에는 동일한 애플리케이션이 수십 개의 마이크로 서비스로 분할되었을 수 있습니다.

00:01:20.300 --> 00:01:24.060
각 서비스는 사용자 계정, 결제, 재고 관리, 알림 등 하나의 기능을 처리하며

00:01:24.060 --> 00:01:25.660
각각 자체 API를 제공합니다.

00:01:25.820 --> 00:01:29.260
갑자기 시스템에 접근할 수 있는 진입점이 10개, 50개, 심지어 100개까지 늘어납니다.

00:01:29.440 --> 00:01:32.600
이제 이러한 API를 사용하는 애플리케이션을 개발하는 개발자라고 상상해보세요.

00:01:32.820 --> 00:01:34.860
각 API를 찾아 인증 방법을 파악해야 합니다.

00:01:35.060 --> 00:01:39.680
어떤 API는 API 키를 사용하고, 어떤 API는 OS를 사용하며, 어떤 API는 아무것도 사용하지 않습니다.

00:01:39.840 --> 00:01:41.900
접근 제한을 수동으로 처리하지 않으면 차단될 위험이 있습니다.

00:01:41.900 --> 00:01:44.520
또한 각 API가 요구하는 데이터 형식을 이해해야 합니다.

00:01:44.660 --> 00:01:45.660
정말 힘든 일입니다.

00:01:45.840 --> 00:01:47.820
운영 측면에서 보면 상황은 더욱 악화됩니다.

00:01:48.020 --> 00:01:51.600
중앙 게이트웨이가 없으면 각 팀은 자체 서비스에 보안 및 로깅 기능을 수동으로 추가해야 합니다.

00:01:51.800 --> 00:01:54.140
어떤 팀은 잘 수행하지만, 어떤 팀은 오류 로깅을 잊어버립니다.

00:01:54.380 --> 00:01:56.300
심지어 입력 유효성 검사를 전혀 하지 않는 팀도 있습니다.

00:01:56.520 --> 00:01:59.600
일관성이 없고 오류 발생 가능성이 높은 이러한 상황은 보안 악몽으로 이어질 수 있습니다.

00:01:59.800 --> 00:02:01.440
규정 준수는 거의 불가능해집니다.

00:02:01.620 --> 00:02:03.800
누가 언제 무엇에 접근했는지 증명해야 합니까?

00:02:03.800 --> 00:02:07.900
각기 다른 로깅 형식을 사용하는 20개의 서로 다른 서비스에서 감사 추적을 추출하는 것은 매우 어렵습니다.

00:02:08.020 --> 00:02:11.040
지난달 시스템에서 처리한 API 호출 횟수를 확인해야 합니까?

00:02:11.200 --> 00:02:14.020
12개의 서로 다른 대시보드에서 매트릭을 취합해야 합니다.

00:02:14.220 --> 00:02:17.340
문제는 규모가 커질수록 이러한 문제가 더욱 심각해진다는 것입니다.

00:02:17.520 --> 00:02:21.020
중앙 제어 지점 없이는 개발자, 서비스, 고객을 늘릴 수 없습니다.

00:02:21.300 --> 00:02:22.340
건물을 생각해보세요.

00:02:22.600 --> 00:02:24.760
모든 방에 다른 잠금장치가 있다고 가정해봅시다.

00:02:24.940 --> 00:02:26.600
안내데스크나 안내책자도 없습니다.

00:02:26.940 --> 00:02:30.340
방문객들은 원하는 문을 찾으려고 헤매다가 결국 포기하게 됩니다.

00:02:30.640 --> 00:02:31.920
완전한 혼돈 상태입니다.

00:02:31.920 --> 00:02:34.940
바로 이러한 문제를 해결하기 위해 API 관리가 설계되었습니다.

00:02:35.180 --> 00:02:37.140
에이저 API 매니지먼트란 무엇일까요?

00:02:37.320 --> 00:02:38.300
바로 관제탑입니다.

00:02:38.560 --> 00:02:41.480
그렇다면 에이저 API 매니지먼트는 정확히 무엇일까요?

00:02:41.660 --> 00:02:47.840
가장 간단하게 정의하자면, 백엔드 API와 이를 사용하는 앱, 웹사이트, 디바이스, 파트너 사이에 위치하는 관리형 서비스입니다.

00:02:48.000 --> 00:02:50.100
하지만 단순히 프록시 역할만 하는 것은 아닙니다.

00:02:50.280 --> 00:02:52.100
프록시는 트래픽을 전달하는 역할만 할 뿐입니다.

00:02:52.300 --> 00:02:54.680
에이저 API 매니지먼트는 API 위 전체 수명 주기를 관리합니다.

00:02:54.860 --> 00:02:58.320
API를 개시하고, 보호하고, 모니터링하고, 최종적으로는 서비스 종료까지 지원합니다.

00:02:58.320 --> 00:03:02.160
완벽한 제어센터라고 할 수 있죠. 에이저 API 매니지먼트는 크게 세 가지 주요 구성 요소로 이루어져 있습니다.

00:03:02.360 --> 00:03:04.720
첫 번째는 게이트웨이입니다. 게이트웨이는 마치 입구와 같습니다.

00:03:05.020 --> 00:03:08.520
앱이나 웹사이트에서 들어오는 모든 요청은 백엔드에 직접 도달하지 않고 먼저 게이트웨이를 거칩니다.

00:03:08.740 --> 00:03:14.080
게이트웨이는 요청을 처리하고, 설정한 정책을 적용하고, 매트릭을 수집한 다음, 적절한 백엔드 서비스로 전달합니다.

00:03:14.280 --> 00:03:16.420
교통경찰과 같은 역할을 한다고 생각하면 됩니다.

00:03:16.740 --> 00:03:18.080
다음은 관리 평면입니다.

00:03:18.340 --> 00:03:19.960
여기에서 모든 것을 정의합니다.

00:03:19.960 --> 00:03:27.840
API, 정책, 제품, 구독 등을 에이저 포털, 명령줄 또는 바이섭이나 테라폼과 같은 코드형 인프라를 통해 설정할 수 있습니다.

00:03:28.060 --> 00:03:30.760
모든 작동 방식을 설정하는 제어실이 바로 여기입니다.

00:03:30.980 --> 00:03:32.380
그리고 개발자 포털이 있습니다.

00:03:32.720 --> 00:03:40.800
이 포털은 내부 및 외부 개발자가 API를 검색하고, 문서를 읽고, 구독키를 받고, 브라우저에서 직접 API 호출을 테스트할 수 있는 셀프 서비스 웹사이트입니다.

00:03:41.000 --> 00:03:43.080
더 이상 PDF 파일을 이메일로 주고받을 필요가 없습니다.

00:03:43.340 --> 00:03:44.660
이해를 돕기 위해 비유를 들어보겠습니다.

00:03:44.960 --> 00:03:46.220
현대적인 공항을 생각해보세요.

00:03:46.480 --> 00:03:47.580
게이트웨이는 활주로입니다.

00:03:47.580 --> 00:03:49.660
모든 비행기는 먼저 활주로에 착륙합니다.

00:03:49.820 --> 00:03:51.140
관리구역은 관제탑입니다.

00:03:51.380 --> 00:03:54.320
교통을 통제하고, 규칙을 정하고, 모든 것을 모니터링합니다.

00:03:54.500 --> 00:03:56.440
그리고 개발자 포털은 정보 게시판입니다.

00:03:56.660 --> 00:04:00.600
조종사는 비행 전에 게시판을 확인하여 누구와도 대화하지 않고 필요한 모든 정보를 찾을 수 있습니다.

00:04:00.820 --> 00:04:02.500
이제 게이트웨이를 자세히 살펴보겠습니다.

00:04:02.880 --> 00:04:06.440
바로 앱이 실제로 통신하는 부분이며, 진정한 마법이 일어나는 곳입니다.

00:04:06.700 --> 00:04:08.840
게이트웨이는 API 위 정문입니다.

00:04:09.080 --> 00:04:12.720
앱이 실제로 통신하는 부분이기 때문에 게이트웨이에 대해 이야기해보겠습니다.

00:04:12.720 --> 00:04:18.160
모바일 앱, 웹사이트 또는 IoT 기기에서 발생하는 모든 요청은 백엔드가 아닌 게이트웨이를 먼저 거칩니다.

00:04:18.400 --> 00:04:19.540
이것이 바로 핵심입니다.

00:04:19.740 --> 00:04:22.420
게이트웨이는 최전선에 위치하여 단일 진입점 역할을 합니다.

00:04:22.640 --> 00:04:25.220
게이트웨이는 요청을 전달하기 전에 정책을 적용할 수 있습니다.

00:04:25.460 --> 00:04:27.620
정책은 XML 또는 JSON 형식으로 작성하는 규칙으로,

00:04:27.840 --> 00:04:30.800
요청 속도 제한, IP 필터링, 헤더 재작성, 인증 확인 등을 포함합니다.

00:04:32.180 --> 00:04:34.880
이 모든 작업은 백엔드 코드를 한 줄도 수정하지 않고 수행할 수 있습니다.

00:04:35.100 --> 00:04:36.160
구체적인 예를 들어보겠습니다.

00:04:36.160 --> 00:04:39.360
API의 무료 사용자용과 프리미엄 사용자용이 있다고 가정해봅시다.

00:04:39.500 --> 00:04:41.840
정책을 통해 무료 사용자는 분당 5권의 요청으로 제한하고,

00:04:41.960 --> 00:04:43.780
프리미엄 사용자는 100권의 요청을 허용할 수 있습니다.

00:04:43.960 --> 00:04:46.820
백엔드는 이러한 차이를 알지 못하고 단순히 요청을 처리하기만 합니다.

00:04:47.020 --> 00:04:48.980
게이트웨이가 정책 시행을 담당하는 것입니다.

00:04:49.160 --> 00:04:50.980
게이트웨이는 캐싱 기능도 제공합니다.

00:04:51.220 --> 00:04:54.660
제품 목록처럼 자주 변경되지 않는 데이터가 반복적으로 요청되는 경우,

00:04:55.120 --> 00:04:57.600
게이트웨이는 응답을 캐시하여 바로 제공할 수 있습니다.

00:04:57.840 --> 00:04:59.720
백엔드를 전혀 신경 쓸 필요가 없으므로,

00:04:59.860 --> 00:05:02.260
응답 속도가 빨라지고 서버 부하가 줄어듭니다.

00:05:02.260 --> 00:05:04.080
데이터 변환 기능도 제공합니다.

00:05:04.240 --> 00:05:05.660
백엔드에서 XML을 반환하지만,

00:05:05.800 --> 00:05:07.660
모바일 앱에서는 JSON을 기대하는 경우,

00:05:08.080 --> 00:05:09.720
게이트웨이는 이를 즉시 변환할 수 있습니다.

00:05:09.880 --> 00:05:12.380
백엔드와 앱 모두 코드를 수정할 필요가 없습니다.

00:05:12.740 --> 00:05:17.700
게이트웨이는 변환을 처리하고 모든 호출, 요청, 응답, 오류를 기록합니다.

00:05:17.940 --> 00:05:21.280
누가 언제 무엇을 호출했는지에 대한 완벽한 감사 추적을 제공합니다.

00:05:21.520 --> 00:05:24.140
이것만으로도 규정 준수를 위해 충분히 가치가 있습니다.

00:05:24.420 --> 00:05:25.920
전세계 사용자를 대상으로 하는 경우,

00:05:26.100 --> 00:05:27.880
여러 지역에 게이트웨이를 배포할 수 있습니다.

00:05:28.140 --> 00:05:30.620
트래픽은 자동으로 가장 가까운 지역으로 라우팅되어,

00:05:30.620 --> 00:05:33.240
지연 시간을 줄이고 더 나은 사용자 경험을 제공합니다.

00:05:33.420 --> 00:05:36.060
또한 게이트웨이는 실제 백엔드 URL을 숨깁니다.

00:05:36.260 --> 00:05:37.960
클라이언트는 게이트웨이 주소만 보게 되며,

00:05:38.280 --> 00:05:39.880
백엔드 서버는 인터넷에서 숨겨집니다.

00:05:40.040 --> 00:05:42.900
이는 기본적으로 제공되는 보안 기능 중 가장 큰 장점입니다.

00:05:43.120 --> 00:05:45.420
모든 것을 제어하는 엔진, 정책.

00:05:45.580 --> 00:05:49.620
앞서 언급한 정책은 APIM을 진정으로 강력하게 만드는 핵심 요소입니다.

00:05:49.880 --> 00:05:52.060
정책을 통해 백엔드 코드를 수정하지 않고도,

00:05:52.140 --> 00:05:54.060
요청 또는 응답 동작을 변경할 수 있습니다.

00:05:54.320 --> 00:05:56.560
API를 감싸는 래퍼라고 생각하면 됩니다.

00:05:56.560 --> 00:05:58.800
트래픽이 흐르면서 자동으로 요소를 추가,

00:05:58.800 --> 00:06:00.560
제거 또는 변경할 수 있습니다.

00:06:00.800 --> 00:06:03.680
정책은 요청 수명 주기의 내 지점에서 실행될 수 있습니다.

00:06:03.920 --> 00:06:06.880
백엔드에 도달하기 전, 즉 요청이 들어오는 시점입니다.

00:06:07.120 --> 00:06:08.940
인바운드는 응답이 클라이언트에 도달하기 전,

00:06:09.240 --> 00:06:10.440
즉 돌아오는 길에 적용됩니다.

00:06:10.620 --> 00:06:13.060
백엔드는 요청이 서비스에 도달하기 직전에 적용됩니다.

00:06:13.260 --> 00:06:15.800
그리고 오류 발생 시 N은 무언가 실패했을 때 적용됩니다.

00:06:16.000 --> 00:06:18.100
일반적인 인바운드에는 호출자의 신원을 확인하기 위한

00:06:18.100 --> 00:06:19.560
JWT 토큰 유효성 검사,

00:06:19.820 --> 00:06:21.560
API 키 확인, URL 제작성,

00:06:21.840 --> 00:06:22.780
IP 주소 제한 등이 있습니다.

00:06:22.780 --> 00:06:25.780
이 모든 작업은 백엔드가 요청을 수신하기 전에 수행됩니다.

00:06:25.960 --> 00:06:28.340
아웃바운드의 경우 응답 본문을 변환할 수 있습니다.

00:06:28.560 --> 00:06:30.900
텍스트를 찾아서 바꾸거나 민감한 필드를 제거하거나

00:06:30.900 --> 00:06:32.060
형식을 변경할 수 있습니다.

00:06:32.260 --> 00:06:35.500
응답을 캐싱하여 반복적인 요청이 백엔드에 도달하지 않도록 할 수도 있습니다.

00:06:35.720 --> 00:06:38.020
내부 정보를 유출하는 헤더를 제거할 수도 있습니다.

00:06:38.260 --> 00:06:39.420
구체적인 예를 들어보겠습니다.

00:06:39.840 --> 00:06:43.180
API에서 반환하는 제품 설명에 파란색이라는 단어가 많이 포함되어 있다고 가정해봅시다.

00:06:43.340 --> 00:06:45.700
브랜드를 변경하여 노란색을 사용하고 싶습니다.

00:06:45.880 --> 00:06:49.080
백엔드 코드를 수정하는 대신 아웃바운드 정책 하나만 추가하면 됩니다.

00:06:49.200 --> 00:06:51.840
파란색을 찾아 노란색으로 바꾸는 것입니다.

00:06:51.840 --> 00:06:54.320
이렇게 하면 백엔드 코드는 전혀 변경되지 않습니다.

00:06:54.480 --> 00:06:57.300
속도 제한 및 탈당량 정책은 백엔드를 악용으로부터 보호합니다.

00:06:57.500 --> 00:07:00.660
만약 누군가의 앱이 악의적으로 API를 초당만 번씩 무차별적으로 호출하기 시작하면

00:07:00.660 --> 00:07:02.920
정책이 개입하여 속도를 늦추세요 라고 지시합니다.

00:07:03.100 --> 00:07:05.080
그러면 백엔드 시스템은 안정적으로 유지됩니다.

00:07:05.260 --> 00:07:06.420
고급 로직이 필요하신가요?

00:07:06.640 --> 00:07:09.000
정책 내에서 사용자 지정 시샵 표현식을 작성할 수 있습니다.

00:07:09.240 --> 00:07:12.400
이러한 표현식은 성능 향상을 위해 컨파일됨으로 런타임 비용이 발생하지 않습니다.

00:07:12.600 --> 00:07:15.220
사용자 역할을 조회하고 동적 속도 제한을 계산하거나

00:07:15.220 --> 00:07:17.820
요청 헤더에 따라 응답을 조건부로 변환할 수도 있습니다.

00:07:18.000 --> 00:07:19.180
핵심은 바로 이것입니다.

00:07:19.380 --> 00:07:21.920
정책을 통해 API를 실행하는 코드를 건드리지 않고도

00:07:21.920 --> 00:07:23.740
API의 동작 방식을 제어할 수 있습니다.

00:07:23.960 --> 00:07:27.420
즉 변경 속도가 빨라지고 배포 횟수가 줄어들며 위험이 감소합니다.

00:07:27.660 --> 00:07:30.540
제품 및 구독은 소비자를 위한 API 패키징입니다.

00:07:30.800 --> 00:07:33.040
이제 API 가정이 되고 정책이 설정되었으며

00:07:33.040 --> 00:07:34.820
게이트웨이가 원활하게 작동하고 있습니다.

00:07:35.080 --> 00:07:38.500
하지만 어떻게 하면 다양한 고객에게 서로 다른 액세스 권한을 부여할 수 있을까요?

00:07:38.680 --> 00:07:40.520
바로 제품 및 구독이 필요한 부분입니다.

00:07:40.880 --> 00:07:43.680
APIM에서는 API를 제품이라는 것으로 그룹화합니다.

00:07:43.680 --> 00:07:45.560
일종의 번들이라고 생각하면 됩니다.

00:07:45.860 --> 00:07:49.200
예를 들어 기본 API만 포함하는 무료 등급 제품을 제공할 수 있습니다.

00:07:49.440 --> 00:07:51.260
읽기 전용 액세스만 제공하는 무료 제품과

00:07:51.260 --> 00:07:53.100
쓰기 작업 및 관리자 엔드포인트를 포함한

00:07:53.100 --> 00:07:55.620
모든 기능을 제공하는 프리미엄 제품을 생각해 볼 수 있습니다.

00:07:55.820 --> 00:07:59.360
개발자는 개별 API를 구독하는 것이 아니라 제품을 구독합니다.

00:07:59.560 --> 00:08:00.960
구독하면 구독키를 받게 되는데

00:08:00.960 --> 00:08:04.360
실제로 두 개를 받아서 다운타임 없이 하나를 교체할 수 있습니다.

00:08:04.580 --> 00:08:07.580
이 키가 해당 제품의 모든 API를 사용할 수 있는 접근 권한입니다.

00:08:07.800 --> 00:08:10.060
구독 방식은 개발자가 직접 제어할 수 있습니다.

00:08:10.300 --> 00:08:12.060
제품의 승인 절차를 추가할 수도 있고

00:08:12.060 --> 00:08:14.860
구독자를 수동으로 승인하거나 누구나 가입하여

00:08:14.860 --> 00:08:16.980
즉시 액세스할 수 있도록 개방할 수도 있습니다.

00:08:16.980 --> 00:08:20.660
또한 구독 전에 사용자가 동의해야 하는 법적 약관을 포함할 수도 있습니다.

00:08:20.840 --> 00:08:23.420
특히 API가 민감한 데이터를 처리하는 경우 중요합니다.

00:08:23.600 --> 00:08:25.480
이것이 바로 API 수익화 방법입니다.

00:08:25.700 --> 00:08:28.160
무료 제품은 낮은 호출 제한, 분당 5회 호출을 제공하고

00:08:28.160 --> 00:08:30.440
유료 제품은 더 높은 제한 또는 더 많은 엔드포인트,

00:08:30.640 --> 00:08:32.820
분당 100회 호출과 프리미엄 기능 이용 권한을 제공합니다.

00:08:32.980 --> 00:08:34.780
백엔드는 이러한 제한에 신경 쓰지 않습니다.

00:08:35.000 --> 00:08:37.740
게이트웨이가 호출자가 구독한 제품에 따라 제한을 적용합니다.

00:08:37.940 --> 00:08:39.060
실제 사례를 들어보겠습니다.

00:08:39.060 --> 00:08:41.340
화상 회의 앱을 개발한다고 가정해보세요.

00:08:41.560 --> 00:08:45.880
참석자용 제품에는 세션 일정, 발표자 양력, 장소 지도를 위한 API가 포함됩니다.

00:08:46.080 --> 00:08:48.940
스폰서용 제품에는 잠재 고객 확보 API도 포함됩니다.

00:08:49.160 --> 00:08:51.920
스폰서는 참석자 배지를 스캔하여 연락처 정보를 얻을 수 있습니다.

00:08:52.140 --> 00:08:55.060
동일한 백엔드를 사용하지만 제품은 다르고 접근 권한 수준도 다릅니다.

00:08:55.260 --> 00:08:57.520
두 개의 구독키는 순환 방식으로 관리됩니다.

00:08:57.720 --> 00:09:00.060
키가 유출될 경우 새 키를 생성하면 됩니다.

00:09:00.380 --> 00:09:03.140
두 번째 키를 사용하면 서비스 중단 없이 전환할 수 있습니다.

00:09:03.400 --> 00:09:06.540
새 키를 생성하고 앱을 업데이트한 후 기존 키를 폐기하면 됩니다.

00:09:06.540 --> 00:09:10.800
매우 간편합니다. 개발자 포털은 API 사용자를 위한 셀프 서비스 플랫폼입니다.

00:09:10.960 --> 00:09:14.060
API 제품 설정이 완료되면 이제 개발자가 해당 제품을 찾을 수 있도록 해야 합니다.

00:09:14.240 --> 00:09:15.860
바로 개발자 포털이 그 역할을 합니다.

00:09:16.100 --> 00:09:19.000
개발자 포털은 모든 APM 인스턴스에 내장된 웹사이트입니다.

00:09:19.200 --> 00:09:24.920
개발자는 포털을 통해 API를 탐색하고 문서를 읽고 브라우저에서 바로 엔드포인트를 대화형으로 테스트할 수 있습니다.

00:09:25.120 --> 00:09:27.220
별도의 설정이나 이메일 교환이 필요 없습니다.

00:09:27.560 --> 00:09:29.900
단, 기본적으로는 게시되지 않은 상태입니다.

00:09:30.140 --> 00:09:33.420
APM 인스턴스를 처음 생성하면 포털은 존재하지만 아무도 볼 수 없습니다.

00:09:33.420 --> 00:09:36.940
먼저 포털을 사용자 지정하고 게시해야 합니다. 위도적인 설계입니다.

00:09:37.160 --> 00:09:39.680
완성되지 않은 포털을 세상에 공개하고 싶지는 않겠죠.

00:09:39.860 --> 00:09:44.280
브랜드 색상, 로고는 물론 API 문서와 함께 워드프레스 블로그 콘텐츠를 삽입할 수도 있습니다.

00:09:44.480 --> 00:09:47.040
회사 이미지에 맞춰 완벽하게 맞춤 설정할 수 있습니다.

00:09:47.320 --> 00:09:49.200
진정한 가치는 셀프 서비스에 있습니다.

00:09:49.560 --> 00:09:54.100
개발자는 가입 후 구독키를 자동으로 발급받아 즉시 API를 호출할 수 있습니다.

00:09:54.380 --> 00:09:58.840
수동 이메일 발송, 승인 대기, 키 발급 문의 등의 지원 티켓 발행이 필요 없습니다.

00:09:59.180 --> 00:10:02.240
개발자가 직접 처리함으로 지원 부담이 크게 줄어듭니다.

00:10:02.240 --> 00:10:04.840
변경 로그와 릴리스 노트도 게시할 수 있습니다.

00:10:05.120 --> 00:10:09.000
API가 업데이트되면 개발자는 포털에서 바로 확인할 수 있습니다.

00:10:09.540 --> 00:10:12.540
URL만 있으면 누구나 접근할 수 있도록 공개하거나

00:10:12.540 --> 00:10:16.680
엔트라 아이디 테넌트 사용자만 볼 수 있도록 제안할 수도 있습니다.

00:10:16.920 --> 00:10:19.520
두 가지 옵션 모두 사용 사례에 따라 선택 가능합니다.

00:10:19.740 --> 00:10:23.020
개발자 포털은 API 관리를 진정한 플랫폼으로 만들어주는 핵심 요소입니다.

00:10:23.220 --> 00:10:25.300
API를 위한 매장이라고 생각하시면 됩니다.

00:10:25.600 --> 00:10:28.400
포털이 없다면 개발자는 문서를 뒤지고 여기저기 물어봐야 하지만

00:10:28.400 --> 00:10:31.640
포털이 있다면 필요한 정보를 바로 찾아 개발을 시작할 수 있습니다.

00:10:31.640 --> 00:10:35.140
보안, 인증, 권한, 부여, 그리고 비밀.

00:10:35.240 --> 00:10:38.680
이 모든 강력한 기능은 보안이 제대로 갖춰지지 않으면 무용지물입니다.

00:10:38.880 --> 00:10:42.300
API의 어떻게 아이디, 액세스, 그리고 비밀을 처리하는지 알아보겠습니다.

00:10:42.700 --> 00:10:44.820
API의 다양한 인증 방식을 지원합니다.

00:10:45.040 --> 00:10:47.540
가장 간단한 방식은 앞서 설명한 구독 키입니다.

00:10:47.760 --> 00:10:51.320
하지만 실제 운영 환경에서는 워스 2.0, JWT 토큰, 클라이언트 인증서,

00:10:51.600 --> 00:10:54.140
IP 필터링과 같은 더욱 강력한 인증 방식을 사용하는 것이 좋습니다.

00:10:54.300 --> 00:10:57.120
API의 민감도에 따라 이러한 인증 방식을 단계적으로 적용할 수 있습니다.

00:10:57.320 --> 00:11:00.600
실제 운영 환경에서는 엔트라 아이디를 사용한 워스 2.0 인증이 가장 좋은 방법입니다.

00:11:00.600 --> 00:11:02.060
작동 방식은 다음과 같습니다.

00:11:02.300 --> 00:11:05.980
클라이언트 앱은 엔트라 아이디에서 토큰을 발급받아 API 요청과 함께 전송합니다.

00:11:06.180 --> 00:11:10.600
API의 은 서명, 발급자, 대상, 만료일을 확인하여 토큰의 유효성을 검사합니다.

00:11:10.820 --> 00:11:14.500
토큰이 유효하면 API의 은 토큰을 포함하여 요청을 백엔드로 전달합니다.

00:11:14.740 --> 00:11:19.260
API의 이미 토큰을 검증했기 때문에 백엔드에서는 이를 신뢰하고 재검증할 필요가 없습니다.

00:11:19.540 --> 00:11:21.940
각 서비스에서 처리해야 할 작업이 하나 줄어드는 셈입니다.

00:11:22.160 --> 00:11:23.580
이제 비밀에 대해 이야기해보겠습니다.

00:11:23.960 --> 00:11:27.360
API 키, 연결 문자열, 인증서와 같은 중요한 정보를 정책 파일이나 소세 제어 시스템에

00:11:27.360 --> 00:11:28.680
하드코딩하는 것은 바람직하지 않습니다.

00:11:28.860 --> 00:11:31.460
API의 은 명명된 값, 네임드 밸류즈 이라는 기능을 제공합니다.

00:11:31.640 --> 00:11:35.420
API의 비밀 정보를 중앙 집중식으로 저장하고 정책에서 이름으로 참조할 수 있습니다.

00:11:35.660 --> 00:11:37.780
실제 값은 정책 코드에 나타나지 않습니다.

00:11:38.000 --> 00:11:40.880
더 나아가 명명된 값을 에이저 키, 볼트에 연결할 수도 있습니다.

00:11:41.120 --> 00:11:42.940
비밀 정보는 키, 볼트에 암호화된 상태로 저장되고

00:11:42.940 --> 00:11:44.660
API의 은 런타임에 해당 정보를 가져옵니다.

00:11:44.820 --> 00:11:47.520
데봅스 팀을 포함한 누구도 실제 비밀 값을 볼 수 없습니다.

00:11:47.520 --> 00:11:50.320
키를 교체해야 할 경우 키, 볼트에서 업데이트하면

00:11:50.320 --> 00:11:52.800
API의 자동으로 변경 사항을 반영합니다.

00:11:53.020 --> 00:11:55.380
API의 은 관리형 아이디도 지원합니다.

00:11:55.620 --> 00:11:58.140
이를 통해 API의 은 자격증명을 저장하지 않고도

00:11:58.140 --> 00:12:01.720
키, 볼트, 나, 백엔드, API와 같은 다른 에이저 서비스에 인증할 수 있습니다.

00:12:01.960 --> 00:12:04.820
에이저에서 아이디를 관리함으로 사용자는 권한만 부여하면 됩니다.

00:12:05.060 --> 00:12:08.260
네트워크 격리를 위해 API의 을 가상 네트워크 내에 배포할 수도 있습니다.

00:12:08.480 --> 00:12:10.780
이는 프리미엄 등급, 프리미엄 티어에 해당합니다.

00:12:10.780 --> 00:12:12.780
즉, 에이저 프론트라고 하면

00:12:12.780 --> 00:12:17.020
백엔드 서비스를 인터넷에 직접 노출할 필요가 없다는 의미입니다.

00:12:17.020 --> 00:12:20.000
외부에서 볼 수 있는 유일한 서비스는 APIM입니다.

00:12:20.200 --> 00:12:23.100
이러한 계층적 접근 방식은 심층 방어 체계를 구축합니다.

00:12:23.300 --> 00:12:27.540
게이트웨이 인증, 안전한 비밀 정보 보관, 백엔드 네트워크 격리

00:12:27.540 --> 00:12:29.740
각 계층은 다음 계층을 강화합니다.

00:12:30.060 --> 00:12:32.120
어떤 요금제가 귀사에 적합할까요?

00:12:32.300 --> 00:12:33.320
비용은 얼마일까요?

00:12:33.540 --> 00:12:34.800
각 요금제를 살펴보겠습니다.

00:12:35.220 --> 00:12:38.380
소비 요금제는 API 호출 건당 요금을 지불하며 고정월 요금은 없습니다.

00:12:38.700 --> 00:12:41.880
프로토타입 제작과 같이 사용량이 적거나 급증하는 워크로드에 적합합니다.

00:12:42.100 --> 00:12:44.720
아직 어떤 요금제가 필요한지 잘 모르겠다 면이 요금제부터 시작해보세요.

00:12:44.720 --> 00:12:47.820
개발자 요금제는 월 50달러 정도의 저렴한 고정요금으로 이용할 수 있습니다.

00:12:48.020 --> 00:12:49.980
모든 기능을 제공하지만 SLA는 제공되지 않습니다.

00:12:50.120 --> 00:12:51.560
개발 및 테스트 환경에 이상적입니다.

00:12:51.760 --> 00:12:54.520
프리미엄 요금제의 모든 기능을 사용할 수 있지만 프로덕션 환경에서는 사용할 수 없습니다.

00:12:54.740 --> 00:12:56.860
기본 요금제는 프로덕션 환경에 적합한 입문용 요금제입니다.

00:12:57.040 --> 00:13:00.340
처리량은 낮고 가상 네트워크를 지원하지 않지만 SLA가 제공됩니다.

00:13:00.520 --> 00:13:04.160
사설 네트워크가 중요하지 않은 내부 도구나 소규모 프로젝트에 적합합니다.

00:13:04.400 --> 00:13:06.580
대부분의 기업은 표준 요금제를 선택합니다.

00:13:06.800 --> 00:13:11.380
가상 네트워크 지원 99.95% SLA 그리고 우수한 처리량을 제공합니다.

00:13:11.380 --> 00:13:15.400
비즈니스의 중요한 API를 운영하고 있다면 아마도 이 요금제가 적합할 것입니다.

00:13:15.520 --> 00:13:19.940
프리미엄 요금제는 최고의 안정성과 프라이빗 네트워크가 필요한 글로벌 기업을 위한 제품입니다.

00:13:20.100 --> 00:13:25.840
다중지역 배포, 자체 호스팅 게이트웨이, 99.99% SLA, 완벽한 가상 네트워크 인젝션 기능을 제공합니다.

00:13:26.040 --> 00:13:28.160
가격은 월 2700달러부터 시작합니다.

00:13:28.420 --> 00:13:33.060
마이크로소프트는 또한 V2 요금제, 베이직 V2, 스탠다드 V2, 프리미엄 V2를 도입했습니다.

00:13:33.300 --> 00:13:36.740
이 요금제는 요청 할당량과 100만 건 초과 사용량 기준으로 요금을 간소화합니다.

00:13:36.740 --> 00:13:41.980
여러 개의 계량기를 관리하는 대신 명확한 요청 버킷을 제공받고 초과 사용량에 따라 간단하게 요금을 지분할 수 있습니다.

00:13:42.160 --> 00:13:43.380
선택 방법은 다음과 같습니다.

00:13:43.680 --> 00:13:49.680
테스트용으로는 개발자 요금제로 시작하고, 프로덕션 환경에서는 스탠다드 요금제로, 글로벌 규모 또는 프라이빗 네트워크가 필요한 경우에는 프리미엄 요금제로 업그레이드하세요.

00:13:49.840 --> 00:13:52.400
나중에 언제든지 요금제를 마이그레이션 할 수 있다는 점도 기억하세요.

00:13:52.600 --> 00:13:54.660
소규모로 시작하여 필요에 따라 확장해 나가세요.

00:13:54.860 --> 00:13:56.340
지금까지 다룬 내용은 다음과 같습니다.

00:13:56.340 --> 00:14:02.120
API 관리는 수많은 API 위 복잡성을 하나의 제어센터로 통합하여 게이트웨이, 정책, 보안 및 개발자 환경을 관리합니다.

00:14:02.260 --> 00:14:04.880
핵심은 API 관리가 단순한 프록시 이상의 기능을 제공한다는 것입니다.

00:14:05.060 --> 00:14:07.760
API 관리 도구를 API 생태계의 두뇌이자 신경계라고 생각해보세요.

00:14:07.980 --> 00:14:11.140
이 도구가 없으면 각 팀이 자체적으로 인증, 로깅, 속도 제한 기능을 구축하게 됩니다.

00:14:11.320 --> 00:14:15.060
결국 일관성이 부족해지고 보안 취약점이 발생하며 전체적인 상황을 파악할 수 없게 됩니다.

00:14:15.300 --> 00:14:21.400
하지만 API 관리 도구를 사용하면 모든 서비스에 대해 처음부터 다시 개발할 필요 없이 일관성, 보안, 확장성을 확보할 수 있습니다.

00:14:21.400 --> 00:14:25.940
간단한 예시를 들어보겠습니다. 현재 직접 노출하고 있는 API 하나를 생각해보세요.

00:14:26.180 --> 00:14:28.420
함수 엔드포인트 나앱 서비스일 수도 있습니다.

00:14:28.680 --> 00:14:33.020
API 관리 도구를 앞에 두면 보안 상태와 사용량 모니터링 기능이 어떻게 달라질까요?

00:14:33.240 --> 00:14:36.160
이 예시만 생각해봐도 API 관리 도구의 가치를 알 수 있습니다.

00:14:36.400 --> 00:14:37.740
이제 채널을 구독해주세요.

00:14:37.920 --> 00:14:43.120
앞으로의 에피소드에서는 API 가져오기, 첫 번째 정책 적용, 실시간 사용량 모니터링 방법을 보여드리겠습니다.

00:14:43.420 --> 00:14:45.620
이론에서 실습으로 바로 넘어가는 과정을 경험하실 수 있습니다.

00:14:45.840 --> 00:14:48.200
이 영상이 도움이 되었다면 앱을 개발하는 다른 사람과 공유해주세요.

00:14:48.200 --> 00:14:49.860
몇 달 동안의 골칫거리를 덜어줄 수 있을 겁니다.

00:14:50.060 --> 00:14:50.940
시청해주셔서 감사합니다.