마이크로소프트 지식단원의 또 다른 에피소드에 오신 것을 환영합니다.저는 진행자 미르코 피터스입니다.오늘 다룰 주제는 거의 모든 사람이 들어봤지만실제로 제대로 이해하는 사람은 드문 API입니다.아마 이 용어를 많이 들어보셨을 겁니다.사람들이 아는 척하고 싶을 때 사용하는 기술 용어 중 하나죠.하지만 사실 API는 간단합니다.소프트웨어가 서로 통신할 수 있는 방법일 뿐입니다.스마트폰이 서버에 데이터를 요청하면서버는 그 데이터를 다시 보내줍니다.이것이 바로 API입니다.이제 API가 20개, 50개 또는 100개 있다고 상상해보세요.각 API는 서로 다른 인증 방식, 속도 제한,문서와 여부 등 여러 가지 차이점이 있을 수 있습니다.두 앱 간의 간단한 대화로 시작했던 것이 순식간에 혼란으로 변합니다.중앙 관리자가 없다면 각 팀은 바퀴를 다시 발명하는 것처럼각자 알아서 처리해야 합니다.어떤 팀은 자체 인증 시스템을 구축하고다른 팀은 자체 로깅 시스템을 구축합니다.보안 취약점이 곳곳에 발생합니다.개발자들은 어떤 API가 어떤 역할을 하는지 혼란스러워하고시스템 전체에서 실제로 무슨 일이 일어나고 있는지한눈에 파악할 수 없게 됩니다.에이저 API 매니지먼트는 이 문제를 해결합니다.하나의 제어센터를 제공하여 API를 관리할 수 있도록 해줍니다.마치 API를 위한 항공 교통 관제탑과 같다고 생각하시면 됩니다.이번 에피소드를 통해 에이저 API 매니지먼트 가부헛인지,왜 중요한지, 그리고 모든 구성 요소가 어떻게 연결되는지 이해하게 될 것입니다.커피 한 잔 준비하시고 함께 살펴보겠습니다.문제점은 너무 많은 API와 그에 따른 관리 부재입니다.이것이 바로 현대 소프트웨어의 현실입니다. 10년 전에는 하나의 큰 애플리케이션, 즉 모노리식 아키텍처,하나의 데이터베이스, 하나의 API로 구성된 간단한 구조였을 것입니다.

하지만 오늘날에는 동일한 애플리케이션이 수십 개의 마이크로 서비스로 분할되었을 수 있습니다.각 서비스는 사용자 계정, 결제, 재고 관리, 알림 등 하나의 기능을 처리하며각각 자체 API를 제공합니다.갑자기 시스템에 접근할 수 있는 진입점이 10개, 50개, 심지어 100개까지 늘어납니다.이제 이러한 API를 사용하는 애플리케이션을 개발하는 개발자라고 상상해보세요.각 API를 찾아 인증 방법을 파악해야 합니다.어떤 API는 API 키를 사용하고, 어떤 API는 OS를 사용하며, 어떤 API는 아무것도 사용하지 않습니다.접근 제한을 수동으로 처리하지 않으면 차단될 위험이 있습니다.또한 각 API가 요구하는 데이터 형식을 이해해야 합니다.정말 힘든 일입니다.운영 측면에서 보면 상황은 더욱 악화됩니다.중앙 게이트웨이가 없으면 각 팀은 자체 서비스에 보안 및 로깅 기능을 수동으로 추가해야 합니다.어떤 팀은 잘 수행하지만, 어떤 팀은 오류 로깅을 잊어버립니다.심지어 입력 유효성 검사를 전혀 하지 않는 팀도 있습니다.일관성이 없고 오류 발생 가능성이 높은 이러한 상황은 보안 악몽으로 이어질 수 있습니다.규정 준수는 거의 불가능해집니다.누가 언제 무엇에 접근했는지 증명해야 합니까?각기 다른 로깅 형식을 사용하는 20개의 서로 다른 서비스에서 감사 추적을 추출하는 것은 매우 어렵습니다.지난달 시스템에서 처리한 API 호출 횟수를 확인해야 합니까? 12개의 서로 다른 대시보드에서 매트릭을 취합해야 합니다.문제는 규모가 커질수록 이러한 문제가 더욱 심각해진다는 것입니다.중앙 제어 지점 없이는 개발자, 서비스, 고객을 늘릴 수 없습니다.건물을 생각해보세요.모든 방에 다른 잠금장치가 있다고 가정해봅시다.안내데스크나 안내책자도 없습니다.방문객들은 원하는 문을 찾으려고 헤매다가 결국 포기하게 됩니다.완전한 혼돈 상태입니다.

바로 이러한 문제를 해결하기 위해 API 관리가 설계되었습니다.에이저 API 매니지먼트란 무엇일까요?바로 관제탑입니다.그렇다면 에이저 API 매니지먼트는 정확히 무엇일까요?가장 간단하게 정의하자면, 백엔드 API와 이를 사용하는 앱, 웹사이트, 디바이스, 파트너 사이에 위치하는 관리형 서비스입니다.하지만 단순히 프록시 역할만 하는 것은 아닙니다.프록시는 트래픽을 전달하는 역할만 할 뿐입니다.에이저 API 매니지먼트는 API 위 전체 수명 주기를 관리합니다. API를 개시하고, 보호하고, 모니터링하고, 최종적으로는 서비스 종료까지 지원합니다.완벽한 제어센터라고 할 수 있죠. 에이저 API 매니지먼트는 크게 세 가지 주요 구성 요소로 이루어져 있습니다.첫 번째는 게이트웨이입니다. 게이트웨이는 마치 입구와 같습니다.앱이나 웹사이트에서 들어오는 모든 요청은 백엔드에 직접 도달하지 않고 먼저 게이트웨이를 거칩니다.게이트웨이는 요청을 처리하고, 설정한 정책을 적용하고, 매트릭을 수집한 다음, 적절한 백엔드 서비스로 전달합니다.교통경찰과 같은 역할을 한다고 생각하면 됩니다.다음은 관리 평면입니다.여기에서 모든 것을 정의합니다. API, 정책, 제품, 구독 등을 에이저 포털, 명령줄 또는 바이섭이나 테라폼과 같은 코드형 인프라를 통해 설정할 수 있습니다.모든 작동 방식을 설정하는 제어실이 바로 여기입니다.그리고 개발자 포털이 있습니다.이 포털은 내부 및 외부 개발자가 API를 검색하고, 문서를 읽고, 구독키를 받고, 브라우저에서 직접 API 호출을 테스트할 수 있는 셀프 서비스 웹사이트입니다.더 이상 PDF 파일을 이메일로 주고받을 필요가 없습니다.이해를 돕기 위해 비유를 들어보겠습니다.현대적인 공항을 생각해보세요.게이트웨이는 활주로입니다.모든 비행기는 먼저 활주로에 착륙합니다.관리구역은 관제탑입니다.

교통을 통제하고, 규칙을 정하고, 모든 것을 모니터링합니다.그리고 개발자 포털은 정보 게시판입니다.조종사는 비행 전에 게시판을 확인하여 누구와도 대화하지 않고 필요한 모든 정보를 찾을 수 있습니다.이제 게이트웨이를 자세히 살펴보겠습니다.바로 앱이 실제로 통신하는 부분이며, 진정한 마법이 일어나는 곳입니다.게이트웨이는 API 위 정문입니다.앱이 실제로 통신하는 부분이기 때문에 게이트웨이에 대해 이야기해보겠습니다.모바일 앱, 웹사이트 또는 IoT 기기에서 발생하는 모든 요청은 백엔드가 아닌 게이트웨이를 먼저 거칩니다.이것이 바로 핵심입니다.게이트웨이는 최전선에 위치하여 단일 진입점 역할을 합니다.게이트웨이는 요청을 전달하기 전에 정책을 적용할 수 있습니다.정책은 XML 또는 JSON 형식으로 작성하는 규칙으로,요청 속도 제한, IP 필터링, 헤더 재작성, 인증 확인 등을 포함합니다.이 모든 작업은 백엔드 코드를 한 줄도 수정하지 않고 수행할 수 있습니다.구체적인 예를 들어보겠습니다. API의 무료 사용자용과 프리미엄 사용자용이 있다고 가정해봅시다.정책을 통해 무료 사용자는 분당 5권의 요청으로 제한하고,프리미엄 사용자는 100권의 요청을 허용할 수 있습니다.백엔드는 이러한 차이를 알지 못하고 단순히 요청을 처리하기만 합니다.게이트웨이가 정책 시행을 담당하는 것입니다.게이트웨이는 캐싱 기능도 제공합니다.제품 목록처럼 자주 변경되지 않는 데이터가 반복적으로 요청되는 경우,게이트웨이는 응답을 캐시하여 바로 제공할 수 있습니다.백엔드를 전혀 신경 쓸 필요가 없으므로,응답 속도가 빨라지고 서버 부하가 줄어듭니다.데이터 변환 기능도 제공합니다.백엔드에서 XML을 반환하지만,모바일 앱에서는 JSON을 기대하는 경우,게이트웨이는 이를 즉시 변환할 수 있습니다.백엔드와 앱 모두 코드를 수정할 필요가 없습니다.

게이트웨이는 변환을 처리하고 모든 호출, 요청, 응답, 오류를 기록합니다.누가 언제 무엇을 호출했는지에 대한 완벽한 감사 추적을 제공합니다.이것만으로도 규정 준수를 위해 충분히 가치가 있습니다.전세계 사용자를 대상으로 하는 경우,여러 지역에 게이트웨이를 배포할 수 있습니다.트래픽은 자동으로 가장 가까운 지역으로 라우팅되어,지연 시간을 줄이고 더 나은 사용자 경험을 제공합니다.또한 게이트웨이는 실제 백엔드 URL을 숨깁니다.클라이언트는 게이트웨이 주소만 보게 되며,백엔드 서버는 인터넷에서 숨겨집니다.이는 기본적으로 제공되는 보안 기능 중 가장 큰 장점입니다.모든 것을 제어하는 엔진, 정책.앞서 언급한 정책은 APIM을 진정으로 강력하게 만드는 핵심 요소입니다.정책을 통해 백엔드 코드를 수정하지 않고도,요청 또는 응답 동작을 변경할 수 있습니다. API를 감싸는 래퍼라고 생각하면 됩니다.트래픽이 흐르면서 자동으로 요소를 추가,제거 또는 변경할 수 있습니다.정책은 요청 수명 주기의 내 지점에서 실행될 수 있습니다.백엔드에 도달하기 전, 즉 요청이 들어오는 시점입니다.인바운드는 응답이 클라이언트에 도달하기 전,즉 돌아오는 길에 적용됩니다.백엔드는 요청이 서비스에 도달하기 직전에 적용됩니다.그리고 오류 발생 시 N은 무언가 실패했을 때 적용됩니다.일반적인 인바운드에는 호출자의 신원을 확인하기 위한JWT 토큰 유효성 검사, API 키 확인, URL 제작성, IP 주소 제한 등이 있습니다.이 모든 작업은 백엔드가 요청을 수신하기 전에 수행됩니다.아웃바운드의 경우 응답 본문을 변환할 수 있습니다.텍스트를 찾아서 바꾸거나 민감한 필드를 제거하거나형식을 변경할 수 있습니다.응답을 캐싱하여 반복적인 요청이 백엔드에 도달하지 않도록 할 수도 있습니다.내부 정보를 유출하는 헤더를 제거할 수도 있습니다.구체적인 예를 들어보겠습니다.

API에서 반환하는 제품 설명에 파란색이라는 단어가 많이 포함되어 있다고 가정해봅시다.브랜드를 변경하여 노란색을 사용하고 싶습니다.백엔드 코드를 수정하는 대신 아웃바운드 정책 하나만 추가하면 됩니다.파란색을 찾아 노란색으로 바꾸는 것입니다.이렇게 하면 백엔드 코드는 전혀 변경되지 않습니다.속도 제한 및 탈당량 정책은 백엔드를 악용으로부터 보호합니다.만약 누군가의 앱이 악의적으로 API를 초당만 번씩 무차별적으로 호출하기 시작하면정책이 개입하여 속도를 늦추세요 라고 지시합니다.그러면 백엔드 시스템은 안정적으로 유지됩니다.고급 로직이 필요하신가요?정책 내에서 사용자 지정 시샵 표현식을 작성할 수 있습니다.이러한 표현식은 성능 향상을 위해 컨파일됨으로 런타임 비용이 발생하지 않습니다.사용자 역할을 조회하고 동적 속도 제한을 계산하거나요청 헤더에 따라 응답을 조건부로 변환할 수도 있습니다.핵심은 바로 이것입니다.정책을 통해 API를 실행하는 코드를 건드리지 않고도API의 동작 방식을 제어할 수 있습니다.즉 변경 속도가 빨라지고 배포 횟수가 줄어들며 위험이 감소합니다.제품 및 구독은 소비자를 위한 API 패키징입니다.이제 API 가정이 되고 정책이 설정되었으며게이트웨이가 원활하게 작동하고 있습니다.하지만 어떻게 하면 다양한 고객에게 서로 다른 액세스 권한을 부여할 수 있을까요?바로 제품 및 구독이 필요한 부분입니다. APIM에서는 API를 제품이라는 것으로 그룹화합니다.일종의 번들이라고 생각하면 됩니다.예를 들어 기본 API만 포함하는 무료 등급 제품을 제공할 수 있습니다.읽기 전용 액세스만 제공하는 무료 제품과쓰기 작업 및 관리자 엔드포인트를 포함한모든 기능을 제공하는 프리미엄 제품을 생각해 볼 수 있습니다.개발자는 개별 API를 구독하는 것이 아니라 제품을 구독합니다.구독하면 구독키를 받게 되는데실제로 두 개를 받아서 다운타임 없이 하나를 교체할 수 있습니다.

이 키가 해당 제품의 모든 API를 사용할 수 있는 접근 권한입니다.구독 방식은 개발자가 직접 제어할 수 있습니다.제품의 승인 절차를 추가할 수도 있고구독자를 수동으로 승인하거나 누구나 가입하여즉시 액세스할 수 있도록 개방할 수도 있습니다.또한 구독 전에 사용자가 동의해야 하는 법적 약관을 포함할 수도 있습니다.특히 API가 민감한 데이터를 처리하는 경우 중요합니다.이것이 바로 API 수익화 방법입니다.무료 제품은 낮은 호출 제한, 분당 5회 호출을 제공하고유료 제품은 더 높은 제한 또는 더 많은 엔드포인트,분당 100회 호출과 프리미엄 기능 이용 권한을 제공합니다.백엔드는 이러한 제한에 신경 쓰지 않습니다.게이트웨이가 호출자가 구독한 제품에 따라 제한을 적용합니다.실제 사례를 들어보겠습니다.화상 회의 앱을 개발한다고 가정해보세요.참석자용 제품에는 세션 일정, 발표자 양력, 장소 지도를 위한 API가 포함됩니다.스폰서용 제품에는 잠재 고객 확보 API도 포함됩니다.스폰서는 참석자 배지를 스캔하여 연락처 정보를 얻을 수 있습니다.동일한 백엔드를 사용하지만 제품은 다르고 접근 권한 수준도 다릅니다.두 개의 구독키는 순환 방식으로 관리됩니다.키가 유출될 경우 새 키를 생성하면 됩니다.두 번째 키를 사용하면 서비스 중단 없이 전환할 수 있습니다.새 키를 생성하고 앱을 업데이트한 후 기존 키를 폐기하면 됩니다.매우 간편합니다. 개발자 포털은 API 사용자를 위한 셀프 서비스 플랫폼입니다. API 제품 설정이 완료되면 이제 개발자가 해당 제품을 찾을 수 있도록 해야 합니다.바로 개발자 포털이 그 역할을 합니다.개발자 포털은 모든 APM 인스턴스에 내장된 웹사이트입니다.개발자는 포털을 통해 API를 탐색하고 문서를 읽고 브라우저에서 바로 엔드포인트를 대화형으로 테스트할 수 있습니다.별도의 설정이나 이메일 교환이 필요 없습니다.

단, 기본적으로는 게시되지 않은 상태입니다. APM 인스턴스를 처음 생성하면 포털은 존재하지만 아무도 볼 수 없습니다.먼저 포털을 사용자 지정하고 게시해야 합니다. 위도적인 설계입니다.완성되지 않은 포털을 세상에 공개하고 싶지는 않겠죠.브랜드 색상, 로고는 물론 API 문서와 함께 워드프레스 블로그 콘텐츠를 삽입할 수도 있습니다.회사 이미지에 맞춰 완벽하게 맞춤 설정할 수 있습니다.진정한 가치는 셀프 서비스에 있습니다.개발자는 가입 후 구독키를 자동으로 발급받아 즉시 API를 호출할 수 있습니다.수동 이메일 발송, 승인 대기, 키 발급 문의 등의 지원 티켓 발행이 필요 없습니다.개발자가 직접 처리함으로 지원 부담이 크게 줄어듭니다.변경 로그와 릴리스 노트도 게시할 수 있습니다. API가 업데이트되면 개발자는 포털에서 바로 확인할 수 있습니다. URL만 있으면 누구나 접근할 수 있도록 공개하거나엔트라 아이디 테넌트 사용자만 볼 수 있도록 제안할 수도 있습니다.두 가지 옵션 모두 사용 사례에 따라 선택 가능합니다.개발자 포털은 API 관리를 진정한 플랫폼으로 만들어주는 핵심 요소입니다. API를 위한 매장이라고 생각하시면 됩니다.포털이 없다면 개발자는 문서를 뒤지고 여기저기 물어봐야 하지만포털이 있다면 필요한 정보를 바로 찾아 개발을 시작할 수 있습니다.보안, 인증, 권한, 부여, 그리고 비밀.이 모든 강력한 기능은 보안이 제대로 갖춰지지 않으면 무용지물입니다. API의 어떻게 아이디, 액세스, 그리고 비밀을 처리하는지 알아보겠습니다. API의 다양한 인증 방식을 지원합니다.가장 간단한 방식은 앞서 설명한 구독 키입니다.하지만 실제 운영 환경에서는 워스 2.0, JWT 토큰, 클라이언트 인증서, IP 필터링과 같은 더욱 강력한 인증 방식을 사용하는 것이 좋습니다. API의 민감도에 따라 이러한 인증 방식을 단계적으로 적용할 수 있습니다.

실제 운영 환경에서는 엔트라 아이디를 사용한 워스 2.0 인증이 가장 좋은 방법입니다.작동 방식은 다음과 같습니다.클라이언트 앱은 엔트라 아이디에서 토큰을 발급받아 API 요청과 함께 전송합니다. API의 은 서명, 발급자, 대상, 만료일을 확인하여 토큰의 유효성을 검사합니다.토큰이 유효하면 API의 은 토큰을 포함하여 요청을 백엔드로 전달합니다. API의 이미 토큰을 검증했기 때문에 백엔드에서는 이를 신뢰하고 재검증할 필요가 없습니다.각 서비스에서 처리해야 할 작업이 하나 줄어드는 셈입니다.이제 비밀에 대해 이야기해보겠습니다. API 키, 연결 문자열, 인증서와 같은 중요한 정보를 정책 파일이나 소세 제어 시스템에하드코딩하는 것은 바람직하지 않습니다. API의 은 명명된 값, 네임드 밸류즈 이라는 기능을 제공합니다. API의 비밀 정보를 중앙 집중식으로 저장하고 정책에서 이름으로 참조할 수 있습니다.실제 값은 정책 코드에 나타나지 않습니다.더 나아가 명명된 값을 에이저 키, 볼트에 연결할 수도 있습니다.비밀 정보는 키, 볼트에 암호화된 상태로 저장되고API의 은 런타임에 해당 정보를 가져옵니다.데봅스 팀을 포함한 누구도 실제 비밀 값을 볼 수 없습니다.키를 교체해야 할 경우 키, 볼트에서 업데이트하면API의 자동으로 변경 사항을 반영합니다. API의 은 관리형 아이디도 지원합니다.이를 통해 API의 은 자격증명을 저장하지 않고도키, 볼트, 나, 백엔드, API와 같은 다른 에이저 서비스에 인증할 수 있습니다.에이저에서 아이디를 관리함으로 사용자는 권한만 부여하면 됩니다.네트워크 격리를 위해 API의 을 가상 네트워크 내에 배포할 수도 있습니다.이는 프리미엄 등급, 프리미엄 티어에 해당합니다.즉, 에이저 프론트라고 하면백엔드 서비스를 인터넷에 직접 노출할 필요가 없다는 의미입니다.외부에서 볼 수 있는 유일한 서비스는 APIM입니다.

이러한 계층적 접근 방식은 심층 방어 체계를 구축합니다.게이트웨이 인증, 안전한 비밀 정보 보관, 백엔드 네트워크 격리각 계층은 다음 계층을 강화합니다.어떤 요금제가 귀사에 적합할까요?비용은 얼마일까요?각 요금제를 살펴보겠습니다.소비 요금제는 API 호출 건당 요금을 지불하며 고정월 요금은 없습니다.프로토타입 제작과 같이 사용량이 적거나 급증하는 워크로드에 적합합니다.아직 어떤 요금제가 필요한지 잘 모르겠다 면이 요금제부터 시작해보세요.개발자 요금제는 월 50달러 정도의 저렴한 고정요금으로 이용할 수 있습니다.모든 기능을 제공하지만 SLA는 제공되지 않습니다.개발 및 테스트 환경에 이상적입니다.프리미엄 요금제의 모든 기능을 사용할 수 있지만 프로덕션 환경에서는 사용할 수 없습니다.기본 요금제는 프로덕션 환경에 적합한 입문용 요금제입니다.처리량은 낮고 가상 네트워크를 지원하지 않지만 SLA가 제공됩니다.사설 네트워크가 중요하지 않은 내부 도구나 소규모 프로젝트에 적합합니다.대부분의 기업은 표준 요금제를 선택합니다.가상 네트워크 지원 99.95% SLA 그리고 우수한 처리량을 제공합니다.비즈니스의 중요한 API를 운영하고 있다면 아마도 이 요금제가 적합할 것입니다.프리미엄 요금제는 최고의 안정성과 프라이빗 네트워크가 필요한 글로벌 기업을 위한 제품입니다.다중지역 배포, 자체 호스팅 게이트웨이, 99.99% SLA, 완벽한 가상 네트워크 인젝션 기능을 제공합니다.가격은 월 2700달러부터 시작합니다.마이크로소프트는 또한 V2 요금제, 베이직 V2, 스탠다드 V2, 프리미엄 V2를 도입했습니다.이 요금제는 요청 할당량과 100만 건 초과 사용량 기준으로 요금을 간소화합니다.여러 개의 계량기를 관리하는 대신 명확한 요청 버킷을 제공받고 초과 사용량에 따라 간단하게 요금을 지분할 수 있습니다.선택 방법은 다음과 같습니다.

테스트용으로는 개발자 요금제로 시작하고, 프로덕션 환경에서는 스탠다드 요금제로, 글로벌 규모 또는 프라이빗 네트워크가 필요한 경우에는 프리미엄 요금제로 업그레이드하세요.나중에 언제든지 요금제를 마이그레이션 할 수 있다는 점도 기억하세요.소규모로 시작하여 필요에 따라 확장해 나가세요.지금까지 다룬 내용은 다음과 같습니다. API 관리는 수많은 API 위 복잡성을 하나의 제어센터로 통합하여 게이트웨이, 정책, 보안 및 개발자 환경을 관리합니다.핵심은 API 관리가 단순한 프록시 이상의 기능을 제공한다는 것입니다. API 관리 도구를 API 생태계의 두뇌이자 신경계라고 생각해보세요.이 도구가 없으면 각 팀이 자체적으로 인증, 로깅, 속도 제한 기능을 구축하게 됩니다.결국 일관성이 부족해지고 보안 취약점이 발생하며 전체적인 상황을 파악할 수 없게 됩니다.하지만 API 관리 도구를 사용하면 모든 서비스에 대해 처음부터 다시 개발할 필요 없이 일관성, 보안, 확장성을 확보할 수 있습니다.간단한 예시를 들어보겠습니다. 현재 직접 노출하고 있는 API 하나를 생각해보세요.함수 엔드포인트 나앱 서비스일 수도 있습니다. API 관리 도구를 앞에 두면 보안 상태와 사용량 모니터링 기능이 어떻게 달라질까요?이 예시만 생각해봐도 API 관리 도구의 가치를 알 수 있습니다.이제 채널을 구독해주세요.앞으로의 에피소드에서는 API 가져오기, 첫 번째 정책 적용, 실시간 사용량 모니터링 방법을 보여드리겠습니다.이론에서 실습으로 바로 넘어가는 과정을 경험하실 수 있습니다.이 영상이 도움이 되었다면 앱을 개발하는 다른 사람과 공유해주세요.몇 달 동안의 골칫거리를 덜어줄 수 있을 겁니다.시청해주셔서 감사합니다.