API Gateway REST API와 HTTP API 선택 기준

AWS 실전 운영 시리즈 4/12

AWS API Gateway에는 크게 REST API와 HTTP API가 있다.

HTTP API는 더 가볍고 저렴하고 빠르다. 그래서 새로 만들 때는 HTTP API가 먼저 떠오를 수 있다.

하지만 항상 HTTP API가 정답은 아니다.

운영 콘솔처럼 브라우저 기반 SPA, 여러 endpoint, CORS preflight, API Key, 요청 검증, MOCK 응답 같은 요소가 중요하다면 REST API가 더 나을 수 있다.

문제 상황

운영 콘솔의 프론트엔드는 별도 도메인에서 동작했다.

API는 Lambda를 통해 제공되었고, 여러 path와 method가 있었다.

필요한 것은 단순히 Lambda를 HTTP로 호출하는 것만이 아니었다.

• path별 라우팅
• CORS preflight 처리
• OPTIONS MOCK 응답
• API Key 또는 Usage Plan 확장 가능성
• Access Log
• stage 배포
• 요청 검증 가능성
• 추후 백엔드 교체 여지

이 조건에서는 REST API를 선택할 이유가 있었다.

선택을 단순화하면 다음 흐름으로 볼 수 있다.

실무에서는 비용표만 보고 고르기보다, 브라우저 요청을 어디서 끊고 어떤 운영 정책을 API Gateway에 둘지 먼저 보는 편이 안전하다.

HTTP API의 장점

HTTP API는 좋은 서비스다.

장점은 분명하다.

• REST API보다 저렴하다.
• 지연 시간이 낮다.
• 설정이 단순하다.
• Lambda proxy와 잘 맞는다.
• JWT authorizer 같은 현대적인 인증 구성이 쉽다.

단순한 API를 빠르게 만들 때는 HTTP API가 자연스럽다.

특히 모바일 앱이나 서버 간 API처럼 브라우저 CORS 복잡도가 낮고, 고급 Gateway 기능이 필요 없다면 HTTP API가 좋은 선택이다.

REST API의 장점

REST API는 오래된 만큼 기능이 많다.

운영 콘솔에서 유용했던 기능은 다음과 같다.

• resource/method 단위 설정
• MOCK Integration
• Usage Plan
• API Key
• Request Validation
• Mapping Template
• stage 기반 배포
• 상세한 method response/integration response 설정

특히 CORS preflight를 Lambda까지 보내지 않고 Gateway에서 처리하려면 MOCK Integration이 유용하다.

브라우저 기반 SPA에서는 이 차이가 운영 편의성으로 이어진다.

비용 차이만 보면 안 된다

HTTP API가 더 저렴한 것은 사실이다.

하지만 내부 운영 콘솔처럼 호출량이 많지 않은 시스템에서는 비용 차이가 큰 의사결정 요인이 아닐 수 있다.

월 호출량이 낮다면 REST API의 추가 비용보다 운영 기능의 가치가 더 클 수 있다.

선택 기준은 다음 질문이어야 한다.

• 호출량이 비용을 크게 좌우할 만큼 많은가
• Gateway에서 처리하고 싶은 운영 기능이 있는가
• CORS, 인증, 요청 검증을 어디서 관리할 것인가
• path별 정책이 필요한가
• 추후 외부 클라이언트가 붙을 가능성이 있는가

비용은 중요하지만 유일한 기준은 아니다.

MOCK Integration이 필요한 경우

CORS preflight는 브라우저가 보내는 OPTIONS 요청이다.

이 요청에 대한 응답은 대부분 정적이다.

예를 들어 허용 method, 허용 header, 허용 origin을 알려주면 된다.

이런 응답을 위해 Lambda를 실행할 필요는 없다.

REST API의 MOCK Integration을 쓰면 API Gateway가 직접 응답할 수 있다.

Browser OPTIONS
-> API Gateway MOCK response
-> Lambda 호출 없음

이 구조는 비용과 지연을 줄이고, Lambda 코드에서 CORS 분기를 줄인다.

Usage Plan과 API Key

운영 콘솔이 처음에는 내부용이어도 나중에 외부 도구나 스크립트가 같은 API를 호출할 수 있다.

이때 클라이언트별 제한이나 API Key가 필요할 수 있다.

REST API는 Usage Plan과 API Key 기능을 제공한다.

작은 시스템에서는 처음부터 엄격히 쓰지 않더라도, 나중에 확장할 자리가 있다는 점이 유용하다.

Request Validation과 Mapping Template

초기에는 Lambda 코드 안에서 모든 검증을 처리할 수 있다.

하지만 외부 입력이 늘어나면 Gateway 단에서 기본 검증을 하고 싶어질 수 있다.

REST API는 JSON Schema 기반 request validation이나 mapping template을 사용할 수 있다.

모든 프로젝트에 필요한 것은 아니지만, 운영 경계에서 잘못된 요청을 걸러낼 수 있다는 점은 장점이다.

Stage와 배포 관리

REST API는 stage 개념이 명확하다.

예를 들어 prod, dev 같은 stage를 둘 수 있고, 배포 시점도 관리할 수 있다.

운영 콘솔에서는 stage 배포를 잊으면 설정 변경이 반영되지 않는다는 단점도 있다.

하지만 그만큼 배포 단위가 명확하다.

API Gateway 설정을 바꿨다면 stage 배포까지 해야 한다는 사실을 배포 가이드에 남겨야 한다.

선택 기준 정리

대략 이렇게 판단할 수 있다.

조건	더 어울리는 선택
단순 Lambda HTTP 호출	HTTP API
비용과 지연이 최우선	HTTP API
JWT 기반 인증 중심	HTTP API
MOCK OPTIONS가 중요	REST API
API Key/Usage Plan 필요	REST API
Request Validation 필요	REST API
path별 세밀한 설정 필요	REST API
사내 트래픽 규모	기능 기준으로 선택

중요한 것은 서비스 이름이 아니라 필요한 운영 기능이다.

정리

HTTP API가 더 새롭고 가볍다고 해서 항상 정답은 아니다.

운영 콘솔에서는 REST API가 더 나은 선택일 수 있다.

특히 다음이 필요하다면 REST API를 검토할 만하다.

• CORS preflight를 Gateway에서 처리
• OPTIONS MOCK 응답
• Usage Plan과 API Key
• Request Validation
• path/method 단위 정책
• 명확한 stage 배포

작은 시스템에서는 비용 차이보다 운영 단순성이 더 중요할 때가 있다.

API Gateway 선택도 결국 "무엇을 더 싸게 호출할 것인가"가 아니라 "운영 경계를 어디에 둘 것인가"의 문제다.

함께 볼 GitHub 저장소

• aws-console-operations-notes