Latest / M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어) / API 게이트웨이 쉽게 이해하기: 마이크로서비스를 위한 라우팅·보안·속도 제한, 정말 필요할까? (AI 더빙)

Transcript

API 게이트웨이 쉽게 이해하기: 마이크로서비스를 위한 라우팅·보안·속도 제한, 정말 필요할까? (AI 더빙) · M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어)

0:00
마이크로소프트 365, 코파일럿, AI, 에이저, 그리고 일의 미래를 만들어가는 사람들과 함께하는 10일간의 여정을 준비되셨나요?
0:08
이번 1월, M365 컨이더 커진 규모로 돌아옵니다.
0:12
전세계 MVP와 업계 전문가들이 선보이는 라이브 세션, 실무 데모, 그리고 실용적인 지식을 직접 경험하세요.
0:18
뻔한 슬라이드 나 지루한 전문 용어는 없습니다.
0:21
코파일럿 스튜디오, AI 에이전트, 패브릭, 보안, 거버넌스, 자동화 등 실질적인 과제들을 다룹니다.
0:29
IT 전문가든, 개발자든, 비즈니스 리더든 여러분을 위한 맞춤형 세션이 준비되어 있습니다.
0:35
10일 동안 다양한 기술을 탐구하고 전세계 커뮤니티와 교류할 수 있습니다.
0:40
라이브로 시청하고 실무에 바로 적용할 수 있는 통찰력을 얻어가세요.
0:44
2027년 1월, 10일간의 여정, 하나의 마이크로소프트 커뮤니티, 지금 등록이 시작되었습니다.
0:51
M365 CON.NET에 접속하여 오늘 바로 자리를 확보하세요.
0:56
M365 CON.NET입니다.
0:59
M365 CON.NET에서 참여하시고 1월 라이브 세션에서 뵙겠습니다.
1:05
작동하는 앱을 만들고 나서 서비스를 하나둘 추가하다 보면 어느덧 서비스 간 트래픽을 관리하는 것이 악몽이 됩니다.
1:10
그렇다면 API 게이트웨이란 정확히 무엇이며 정말로 필요한 걸까요?
1:14
이번 에피소드가 끝날 때 쯤이면 API 게이트웨이의 역할과 서비스 관리의 혼란을 해결하는 이유, 그리고 필요 여부를 판단하는 방법을 이해하게 될 것입니다.
1:22
문제점부터 시작해서 구성 요소, 그리고 이들이 어떻게 조화를 이루는지 알아보겠습니다.
1:27
문제점, 너무 많은 출입구, 빠르게 성장하는 회사를 운영한다고 가정해봅시다.
1:31
3층에는 영업팀이, 지하에는 회계팀이, 뒤쪽 별관에는 IT팀이 있습니다.
1:37
이제 각 부서마다 전용 출입구와 전화번호, 그리고 서로 소통하지 않는 전담 경비원이 있다고 상상해보세요.
1:43
방문객이 택배를 전달하려고 한다면 운이 좋길 빌어야 할 겁니다.
1:46
어떤 출입구를 이용해야 할지, 누구에게 말해야 할지, 경비원이 자리를 비웠을 땐 어떻게 해야 할지 전부 알아야 하니까요.
1:51
앱에 백엔드 서비스가 여러 개 있고, 모든 클라이언트가 각 서비스를 직접 호출할 때 일어나는 상황이 바로 이와 같습니다.
1:56
모바일 앱, 웹사이트, 다른 서비스 등 클라이언트는 모든 서비스의 위치와 각각의 인증 방식, 그리고 장애시 대처법을 일일이 알아야 합니다.
2:04
모든 개별 서비스가 보안, 속도 제한, 오류 처리를 스스로 해결해야 합니다.
2:09
이는 중복 작업이며, 일관성이 깨지기 쉽습니다.
2:12
은행을 예로 들어보겠습니다.
2:13
은행은 계좌, 결제, 대출, 부정행위 탐지를 위한 개별 서비스를 각각 운영합니다.
2:17
과거 방식으로는 이들 각각이 외부로 직접 노출되어 있었습니다.
2:19
모바일 앱은 4개의 서로 다른 URL, 4개의 서로 다른 인증 방식, 4개의 서로 다른 오류 처리 방법을 알아야 합니다.
2:25
이는 복잡성이 4배 증가하고 문제가 발생할 수 있는 지점도 4배 늘어난다는 의미이며,
2:29
API 게이트웨이는 바로 이러한 혼란을 해결하기 위해 설계되었습니다.
2:32
그렇다면 해결책은 무엇일까요?
2:33
API 게이트웨이란 무엇일까요?
2:35
API 게이트웨이를 호텔의 프런트 데스크라고 생각해보세요.
2:38
호텔에 들어갈 때, 객실 정비팀이 몇 층에 있는지, 주방은 어디인지, 유지 보수팀은 어떻게 연락하는지 알 필요가 없습니다.
2:44
그저 프런트 데스크에 가서 필요한 것을 말하기만 하면 나머지는 알아서 처리해줍니다.
2:48
그들은 귀하의 요청을 적절한 담당자에게 연결하고, 투숙객인지 확인하며, 기본적인 요청은 직접 처리하기도 합니다.
2:54
API 게이트웨이도 소프트웨어에 대해 동일한 역할을 합니다.
2:57
클라이언트와 백엔드 서비스 사이에 위치한 단일 진입점입니다.
3:01
모든 요청은 먼저 게이트웨이를 통과합니다.
3:03
게이트웨이는 요청을 어디로 보낼지, 허용할지 여부, 그리고 무엇을 돌려줄지 결정합니다.
3:07
물론 이 개념이 새로운 것은 아닙니다.
3:09
리버스 프록시는 수십 년 전부터 존재했지만, 마이크로 서비스 환경에서 API 게이트웨이는 필수적인 요소가 되었습니다.
3:14
앱을 여러 개의 작은 서비스로 나누면 갑자기 여러 개의 문이 생기게 됩니다.
3:17
게이트웨이는 단 하나의 정문을 제공합니다.
3:19
에이저 환경에서는 에이저 API 매니지먼트가 전체 플랫폼이며, 게이트웨이는 트래픽을 처리하는 핵심 구성 요소입니다.
3:24
하지만 그 패턴은 어디서나 동일합니다.
3:26
단일 진입점과 중앙 집중식 제어입니다.
3:29
모든 요청이 들어옵니다.
3:30
게이트웨이는 이를 확인하고 라우팅하며 응답을 돌려줍니다.
3:33
클라이언트는 백엔드 서비스와 직접 통신하지 않습니다.
3:35
오직 게이트웨이하고만 통신합니다.
3:37
이것이 실제로 무엇을 의미하는지 자세히 살펴보겠습니다.
3:39
가장 기본적인 작업인 라우팅부터 시작하죠.
3:42
첫 번째, 트래픽 라우팅입니다.
3:44
API 게이트웨이의 가장 간단한 작업은 라우팅으로, 각 요청을 올바른 서비스로 안내하는 것입니다.
3:49
웹사이트가 어떻게 작동하는지 생각해보세요.
3:51
링크를 클릭하면 브라우저가 요청을 보냅니다.
3:53
그 요청에는 경로가 포함되어 있습니다.
3:54
경로가 오저스 이면 게이트웨이는 이를 사용자 서비스로 보내야 함을 알고 있습니다.
3:58
오더스라면 주문 서비스로 보냅니다.
4:03
게이트웨이가 없다면 클라이언트는 모든 개별 서비스의 URL을 알고 있어야 합니다.
4:07
모바일 앱은 사용자 서비스, 주문 서비스, 결제 서비스, 카탈로그 서비스의 주소를 모두 알아야 합니다.
4:11
그건 관리해야 할 URL이 너무 많다는 뜻입니다.
4:14
게다가 그 중 하나라도 주소가 바뀌면 모든 클라이언트를 업데이트해야 합니다.
4:17
게이트웨이를 사용하면 클라이언트는 하나의 URL만 알면 됩니다.
4:19
바로 게이트웨이의 주소입니다.
4:20
서비스가 실제로 어디에 있는지는 신경 쓸 필요가 없습니다.
4:23
그저 게이트웨이의 요청을 보내기만 하면 게이트웨이가 나머지를 처리합니다.
4:26
이것이 가장 일반적인 API 게이트웨이 사용 사례 중 하나인 리소스 기반 라우팅입니다.
4:30
아파치 APISIX 연구에서도 이를 명시적으로 언급합니다.
4:33
경로, HTTP 메서드, 헤더, 심지어 클라이언트의 지리적 위치에 따라 라우팅합니다.
4:37
유럽에서 누군가 요청을 보내면 유럽 데이터 센터로 라우팅할 수 있습니다.
4:41
미국에서 요청을 보내면 미국 데이터 센터로 연결됩니다.
4:44
클라이언트는 이런 과정이 일어나는지 전혀 알지 못합니다.
4:46
그저 빠른 응답을 받을 뿐입니다.
4:48
라우팅은 버전 관리도 처리합니다.
4:49
사용자 서비스에 새 버전이 있다고 가정해봅시다.
4:51
기존 클라이언트는 여전히 V1, 유저즈를 사용하고 새 클라이언트는 V2, 유저즈를 사용합니다.
4:56
게이트웨이가 이들을 서로 다른 백엔드로 라우팅합니다.
4:58
새 버전을 배포하는 동안에도 기존 클라이언트는 계속 작동합니다.
5:01
클라이언트에 영향을 주지 않고 백엔드를 변경할 수 있습니다.
5:04
이는 실제 사용자가 있는 라이브 애플리케이션을 관리할 때 매우 중요합니다.
5:07
전자상거래 플랫폼을 생각해보세요.
5:09
카탈로그, 장바구니, 결제, 사용자 계정을 위한 서비스가 각각 분리되어 있습니다.
5:13
게이트웨이가 없으면 모바일 앱은 4개의 서로 다른 URL을 알아야 합니다.
5:16
게이트웨이가 있으면 하나만 알면 됩니다.
5:19
게이트웨이가 경로인 카탈로그, 장바구니, 결제, 계정을 읽고 각 요청을 올바른 서비스로 보냅니다.
5:25
단순한 라우팅은 쉬운 부분입니다.
5:26
다음 작업부터가 정말 유용한 부분입니다.
5:29
2부, 입구에서의 보안입니다.
5:31
모든 API 호출은 확인이 필요합니다.
5:33
누가 이 요청을 보내고 있나요? 적절한 권한을 가지고 있나요?
5:36
게이트웨이가 없으면 각 서비스가 자체적으로 인증을 처리해야 합니다.
5:39
이는 작업 중복을 의미하며 실수하기 쉽습니다.
5:42
한 서비스는 토큰을 제대로 확인하지만, 다른 서비스는 단계를 건너뛰거나 전혀 다른 방식을 사용할 수 있습니다.
5:47
결국 전체 애플리케이션에 걸쳐 일관성 없는 보안 상태가 됩니다.
5:51
게이트웨이가 이를 바꿉니다.
5:52
중앙의 한 곳에서 인증과 인가를 모두 처리합니다.
5:55
확인할 곳도, 강제할 곳도, 정책 변경 시 업데이트할 곳도 한 곳뿐입니다.
5:59
이것이 최고의 보안 모범 사례입니다.
6:01
모든 개별 요청에 대해 API 키, JWT, 워스 토큰 또는 인증서를 검증합니다.
6:07
모든 요청은 동일한 검사를 거칩니다.
6:09
예외는 없습니다.
6:10
게이트웨이는 규칙을 적용할 수도 있습니다.
6:12
이 API 키는 읽기 엔드 포인트만 호출할 수 있다.
6:14
라고 설정할 수 있죠.
6:15
또는 이 클라이언트는 카탈로그 서비스에만 접근할 수 있고, 결제 서비스는 안 된다.
6:18
라고 설정할 수 있습니다.
6:19
게이트웨이 수준에서 세밀한 권한을 정의하면 자동으로 적용됩니다.
6:23
백엔드 서비스는 권한 부여에 대해 전혀 걱정할 필요가 없습니다.
6:26
그저 요청을 처리하고 데이터를 다시 보내기만 하면 되죠.
6:28
핵심은이 겁니다.
6:29
게이트웨이는 문제가 발생했을 때 접근 권한을 취소할 수 있는 단일 지점입니다.
6:33
클라이언트의 API 키가 유출되면 게이트웨이에서 바로 취소하면 됩니다.
6:36
한 번이 변경으로 끝이죠.
6:38
모든 서비스를 업데이트하거나 무언가를 재시작할 필요도 없습니다.
6:40
해당 키로부터 들어오는 다음 요청은 즉시 거부됩니다.
6:43
실제 사례를 들어보죠.
6:44
은행에는 결제 서비스와 청구 서비스가 있습니다.
6:46
결제 서비스만 청구 시스템에 대한 쓰기 권한이 필요합니다.
6:49
게이트웨이가 이를 강제합니다.
6:51
클라이언트가 잘못된 엔드 포인트를 통해 청구 시스템에 쓰기를 시도하면 게이트웨이가 차단합니다.
6:55
청구 서비스는 해당 요청을 아예 보지도 못합니다.
6:57
게이트웨이는 더 깊은 보호를 위해 상호 TLS 및 웹후 통합을 지원할 수도 있습니다.
7:02
하지만 기본적으로 이것이 여러분의 첫 번째 방어선입니다.
7:04
보안도 중요하지만 너무 많은 요청이 한꺼번에 몰릴 때는 어떻게 할까요?
7:08
파트 3. 트래픽 관리입니다.
7:10
만 명의 사용자가 동시에 앱에 접속하면 무슨 일이 벌어질까요?
7:14
플래시 세일을 하거나 신제품 출시가 화제가 되거나
7:16
혹은 그냥 평범한 화요일인데 모두가 동시에 로그인했을 수도 있죠.
7:20
게이트웨이가 없다면 백엔드 서비스가 직접 타격을 입고 아마 다운될 겁니다.
7:24
서서히가 아니라 한꺼번에 말이죠.
7:26
그때 트래픽 관리가 필요한 겁니다.
7:28
게이트웨이는 각 클라이언트가 보낼 수 있는 요청 수를 제한할 수 있습니다.
7:32
속도 제한과 스로틀링은 표준 기능입니다.
7:34
게이트웨이에서 규칙을 설정하면 그대로 시행됩니다.
7:37
백엔드 서비스는 트래픽 급증을 전혀 느끼지 못합니다.
7:39
사용자별, API 키별 또는 IP 주소별로 할당량을 설정할 수 있습니다.
7:42
API에 무료 계층이 있다고 가정해봅시다.
7:44
무료 사용자는 시간당 100개의 요청을 보낼 수 있습니다.
7:47
프리미엄 사용자는 만 개를 보낼 수 있죠.
7:49
게이트웨이는 모든 요청을 추적하고 입구에서 해당 제한을 적용합니다.
7:52
무료 사용자가 제한에 도달하면 게이트웨이가 정중하게 나중에 다시 시도하라는 메시지를 보냅니다.
7:56
백엔드 서비스는 그런 요청이 있었는지 조차 알지 못합니다.
7:59
그들은 유료 고객을 위해 계속해서 원활하게 작동합니다.
8:02
게이트웨이는 로드 밸런싱도 처리합니다.
8:04
동일한 서비스의 인스턴스를 여러 개 실행 중에 라면 게이트웨이가 요청을 분산시킵니다.
8:09
첫 번째 인스턴스가 요청을 받고, 그 다음은 두 번째, 그 다음은 세 번째가 받습니다.
8:13
자동입니다.
8:13
만약 인스턴스 하나가 다운되면 게이트웨이가 다른 곳으로 경로를 변경합니다.
8:16
클라이언트는 절대 모릅니다.
8:18
그저 응답을 받을 뿐이죠.
8:19
상태 확인 기능을 포함한 로드 밸런싱은 시스템을 원활하게 유지해줍니다.
8:22
게이트웨이는 각 인스턴스에 핑을 보내 살아있는지 확인합니다.
8:25
살아있지 않다면 트래픽 전송을 중단합니다.
8:27
이는 트래픽이 많은 API에 특히 중요합니다.
8:29
게이트웨이가 없으면 트래픽 급증이 서비스에 직접적인 영향을 줍니다.
8:33
게이트웨이가 있으면 급증하는 트래픽을 먼저 받아 흡수하고 분산시켜 서비스가 과부하되지 않도록 보호합니다.
8:40
좋습니다.
8:40
그런데 데이터가 도착했을 때 형식이 맞지 않으면 어떻게 될까요?
8:44
4. 데이터 변환입니다.
8:46
때로는 클라이언트가 보낸 데이터가 백엔드에서 기대하는 것과 일치하지 않을 수 있습니다.
8:50
클라이언트는 JSON을 보내는데 백엔드는 XML만 이해할 수도 있죠.
8:53
필드 이름이 서로 맞지 않을 수도 있습니다.
8:55
클라이언트는 이름, 필드를 쓰는데 백엔드는 다른 형식의 이름을 기대하는 식이죠.
8:59
이런 불일치는 문제를 일으킵니다.
9:00
과거 방식대로 나면 모든 클라이언트를 수정하거나 백엔드를 다시 작성해야 했습니다.
9:04
좋은 방법은 아니죠.
9:05
게이트웨이는 데이터가 백엔드에 도달하기 전에 변환할 수 있습니다.
9:08
통역사라고 생각해보세요.
9:09
중간에 위치하여 들어오거나 나가는 데이터, 혹은 양쪽 모두를 변경할 수 있습니다.
9:13
그것이 바로 요청 및 응답 변환의 핵심입니다.
9:15
실제 사례를 들어보겠습니다.
9:17
XML을 사용하는 레거시 시스템이 있다고 가정해보죠.
9:19
15년 동안 인하 운영되어 왔습니다.
9:21
아주 잘 작동하죠.
9:22
그런데 이제 새로운 모바일 앱을 만드는데, 모바일 앱은 JSON을 사용합니다.
9:25
게이트웨이가 없다면 레거시 시스템을 다시 작성하거나 모바일 앱이 XML을 보내 도록 강제해야 합니다.
9:29
게이트웨이가 있다면 둘 다 할 필요가 없습니다.
9:31
모바일 앱은 JSON을 보냅니다.
9:33
게이트웨이가 이를 XML로 변환합니다.
9:34
시스템은 자신이 기대하는 데이터를 받게 되죠.
9:36
모바일 앱은 다시 JSON 형식으로 응답을 받습니다.
9:38
누구도 아무것도 다시 작성할 필요가 없었습니다.
9:40
그것이 바로 게이트웨이의 룸이입니다.
9:42
게이트웨이는 헤더를 추가하거나 삭제하고, URL을 변경하거나 민감한 데이터를 마스킹할 수도 있습니다.
9:45
응답에 신용카드 번호가 포함되어 있다고 상상해보세요.
9:48
그 정보가 클라이언트에게 그대로 전달되는 건 원치 않겠죠.
9:50
게이트웨이는 응답이 나가기 전에 해당 정보를 제거하거나 마스킹 처리된 버전으로 대체할 수 있습니다.
9:54
백엔드는 전혀 변경할 필요가 없습니다.
9:56
게이트웨이가 처리해주니까요.
9:57
이는 오래된 시스템을 현대화할 때 특히 유용합니다.
9:59
백엔드를 다시 작성할 필요가 없습니다.
10:01
클라이언트에게 변경을 강요할 필요도 없죠.
10:03
그저 게이트웨이만 수정하면 됩니다.
10:05
국제회의위 통역사와 같습니다.
10:06
모두가 각자의 언어를 말하지만, 통역사가 모두가 이해하도록 돕는 것이죠.
10:10
게이트웨이가 바로 여러분의 소프트웨어를 위한 그 통역사입니다.
10:12
라우팅, 보안, 스로틀링, 변환, 정말 많은 역할을 하죠.
10:15
하지만 이 네 가지는 별개의 것이 아닙니다.
10:17
어떻게 연결되는지 보여드리겠습니다.
10:18
모든 것이 어떻게 연결되는지 말이죠.
10:20
핵심은 이렇습니다.
10:26
게이트웨이는 인증을 확인합니다.
10:28
속도 제한을 검증합니다.
10:29
올바른 서비스로 라우팅합니다.
10:31
필요한 경우 데이터를 변환합니다.
10:33
응답을 다시 받습니다.
10:34
필요하다면 응답도 변환합니다.
10:36
그런 다음 클라이언트로 다시 보냅니다.
10:37
단일 파이프라인 2조.
10:39
모든 단계가 서비스에 개입 없이 자동으로 순차 처리됩니다.
10:42
진정한 힘은 특정 기능 하나에 있지 않습니다.
10:44
바로 통합에 있죠.
10:46
라우팅을 건드리지 않고도 새 보안 정책을 추가할 수 있습니다.
10:49
클라이언트를 변경하지 않고도 백엔드 서비스를 바꿀 수 있죠.
10:51
아무것도 재배포하지 않고도 속도 제한을 업데이트할 수 있습니다.
10:54
각 요소는 독립적이지만 모두 같은 파이프라인에서 작동합니다.
10:58
모든 것이 한 곳을 통과함으로 무슨 일이 일어나는지 완벽하게 파악할 수 있습니다.
11:02
로그, 매트릭, 분석까지 모두 한 곳에서 관리됩니다.
11:05
요청수, 실패한 요청, 느린 요청, 자원을 가장 많이 사용하는 클라이언트를 확인할 수 있습니다.
11:10
게이트웨이가 없다면 각 서비스에서 데이터를 개별적으로 수집해야 합니다.
11:13
게이트웨이가 있으면 바로 확인할 수 있죠.
11:15
그것이 핵심 통찰입니다.
11:16
게이트웨이는 단순한 라우터가 아닙니다.
11:18
전체 API 플랫폼을 위한 관제센터입니다.
11:20
모든 요청, 응답, 오류가 한 곳을 통해 흐릅니다.
11:23
일어나는 모든 상황을 한눈에 볼 수 있습니다.
11:26
그럼 실제로 어떻게 사용할까요?
11:27
지금 당장 할 수 있는 일에 대해 이야기해봅시다.
11:29
실행 가능한 핵심 요약입니다.
11:31
현실적으로 말해보죠.
11:32
서비스가 한두 개라면 아직 API 게이트웨이가 필요 없을 수도 있습니다.
11:35
직접 라우팅을 처리하고 각 서비스에서 인증을 관리하면 되니까요.
11:38
세련되지는 않지만 작동은 합니다.
11:40
하지만 서비스가 3개가 되거나 외부 클라이언트에 API를 노출하는 순간
11:44
복잡성이 빠르게 증가합니다.
11:45
게이트웨이는 금방 제값을 합니다.
11:47
그럼 첫 번째로 무엇을 해야 할까요?
11:49
게이트웨이에서 인증을 중앙 집중화하세요.
11:50
다른 무엇보다 먼저 하십시오.
11:52
서비스 하나를 골라 인증 확인을 게이트웨이로 옮기세요.
11:54
서비스 코드가 즉시 깔끔해지는 것을 느끼실 겁니다.
11:57
더 이상 토큰 검증 로직이 여기저기 흩어져 있지 않아도 됩니다.
12:00
모든 서비스에 동일하게 구현했는지 고민할 필요도 없습니다.
12:03
게이트웨이가 한 번 처리하면 모든 서비스가 혜택을 누립니다.
12:06
다음 단계는 속도 제한입니다.
12:08
간단한 제한만으로도 백엔들을 과부하로부터 보호할 수 있습니다.
12:11
클라이언트당 분당 100건과 같은 기본적인 설정으로 시작하세요.
12:13
그러면 문제가 있는 클라이언트가 서비스를 다운시키는 것을 막을 수 있습니다.
12:16
이야기를 계속해볼까요?