AWS 서비스 10개를 3개로 줄이면 무엇이 달라질까?

웹 인프라2026년 7월 30일글: 홍서진, Duolabs15분 읽기aws blog model-openai-gpt-5.5 serverless technical-note web-infrastructure

Next.js로 웹 서비스를 만들 때 AWS 서비스를 하나씩 고르면 꽤 긴 목록이 나온다. CDN, API 입구, 함수 실행, PostgreSQL, 인증, 파일 저장, Redis, Queue, 이벤트 예약, 배포 파이프라인이 각각 다른 서비스다.

같은 웹 애플리케이션을 Vercel, Supabase, Upstash 조합으로 바라보면 목록은 세 개로 줄어든다.

AWS에서 직접 구성              관리형 웹 스택

CloudFront + API Gateway  →   Vercel
Lambda                    →   Vercel Functions
RDS PostgreSQL            →   Supabase Database
Cognito                   →   Supabase Auth
S3                        →   Supabase Storage
ElastiCache Redis         →   Upstash Redis
SQS + EventBridge         →   QStash
CodePipeline              →   Vercel Git 배포

이 표가 흥미로운 이유는 단순히 제품 수가 줄어서가 아니다. 낮은 수준의 범용 클라우드 부품을 직접 조립하는 방식과, 웹 개발에 필요한 결정을 미리 묶어 둔 플랫폼을 사용하는 방식의 차이를 한눈에 보여주기 때문이다.

다만 먼저 분명히 해야 할 점이 있다. 양쪽 제품이 일대일로 완전히 같다는 뜻은 아니다. 표는 일반적인 Next.js 웹 서비스에서 담당하는 역할을 기준으로 한 대응이다. AWS는 훨씬 넓은 범용성과 세밀한 제어를 제공하고, 관리형 웹 스택은 자주 쓰는 경로를 짧게 만든다.

첫 번째 층: 요청을 받고 코드를 실행한다

AWS에서는 사용자의 요청이 애플리케이션 코드에 도착하기까지 여러 서비스를 조합할 수 있다.

사용자
  ↓
CloudFront
  ↓
API Gateway
  ↓
Lambda

CloudFront는 콘텐츠를 사용자 가까이에서 전달하고, API Gateway는 HTTP API의 입구가 되며, Lambda는 요청에 따라 코드를 실행한다. 각 서비스가 명확한 책임과 설정을 가진다.

Vercel에서는 이 흐름이 하나의 배포 결과로 묶인다.

사용자
  ↓
Vercel CDN과 라우팅
  ↓
Next.js Route Handler
  ↓
Vercel Function

Vercel 공식 문서에 따르면 모든 요청은 분산 CDN을 지나며 캐시, 라우팅, 보안, 압축을 적용받는다. 캐시에서 응답할 수 없을 때 함수 코드가 실행된다. Next.js 파일 구조와 배포 인프라가 연결되어 있기 때문에 별도 API Gateway를 먼저 구성하지 않아도 된다.

src/app/api/orders/route.ts

이 파일은 애플리케이션 코드이면서 배포 후에는 HTTP 엔드포인트와 서버리스 함수가 된다. 개발자가 줄인 것은 기능이 아니라 연결 작업이다.

두 번째 층: 데이터를 영구 저장한다

AWS에서 관계형 데이터를 저장하려면 RDS PostgreSQL을 선택할 수 있다. 회원 인증은 Cognito, 파일은 S3로 나누는 구성이 일반적이다.

RDS PostgreSQL  → 업무 데이터
Cognito         → 사용자 인증
S3              → 이미지와 첨부파일

Supabase는 이 세 역할을 PostgreSQL을 중심으로 묶는다.

Supabase Database → PostgreSQL
Supabase Auth     → 사용자·JWT·RLS 연동
Supabase Storage  → 파일·버킷·접근 정책

Supabase의 중심은 추상화된 독자 DB가 아니라 전체 권한으로 접근할 수 있는 PostgreSQL이다. Auth는 JWT를 발급하고 PostgreSQL의 Row Level Security와 연결된다. Storage도 파일 접근 권한을 RLS 정책과 연동하며 S3 프로토콜 호환 API를 제공한다.

이 통합의 장점은 사용자, 업무 데이터, 파일 권한을 같은 정책 체계로 이해할 수 있다는 것이다. 작은 팀이 Cognito의 사용자 풀, S3 버킷 정책, RDS 권한을 각각 연결하는 대신 Supabase 프로젝트 안에서 관계를 구성할 수 있다.

하지만 Supabase Storage가 S3의 모든 기능을 그대로 제공하는 것은 아니다. 예를 들어 공식 호환성 문서상 S3 프로토콜을 지원하지만 S3 객체 버전 관리 등 일부 기능은 지원하지 않는다. 역할은 비슷해도 세부 기능이 같다고 가정해서는 안 된다.

세 번째 층: 빠른 임시 상태를 공유한다

웹 서버가 여러 개로 늘어나면 요청 횟수나 캐시 값을 각 프로세스 메모리에만 저장할 수 없다. AWS에서는 ElastiCache의 Redis 호환 기능을 사용할 수 있다.

Upstash Redis도 같은 계열의 역할을 맡는다.

ElastiCache Redis  → 클러스터 중심의 관리형 Redis
Upstash Redis      → 서버리스·HTTP 중심의 Redis

둘 다 캐시, 세션, 요청 제한, 실시간 카운터에 사용할 수 있다. 차이는 운영 모델이다. ElastiCache는 AWS 네트워크와 클러스터 구성을 세밀하게 제어하는 데 강하고, Upstash는 서버리스 함수가 REST API로 연결하며 요청량에 따라 비용을 지불하는 흐름에 초점을 맞춘다.

Upstash는 Vercel 공식 통합을 통해 Redis 연결 정보를 프로젝트 환경변수에 연결할 수도 있다. Next.js 함수가 짧게 실행되고 종료되는 모델에서 장시간 연결을 직접 관리하지 않아도 된다는 점이 잘 맞는다.

네 번째 층: 비동기 작업을 전달한다

AWS의 메시징 영역은 하나의 제품으로 끝나지 않는다.

SQS          → 소비자가 가져가는 메시지 Queue
EventBridge  → 이벤트 라우팅과 예약 실행
Lambda       → 이벤트를 받아 코드 실행

QStash는 이 중 서버리스 HTTP Worker에 필요한 경로를 묶어 제공한다.

애플리케이션
  ↓ 메시지 등록
QStash
  ↓ HTTP Push·재시도
Vercel Worker Function

QStash는 작업 전달, 자동 재시도, 예약, Dead Letter Queue, 중복 방지, 동시 실행 제한을 HTTP 엔드포인트 중심으로 제공한다. SQS를 소비하는 프로세스나 EventBridge 규칙을 각각 구성하지 않고도 Vercel 함수를 비동기 Worker로 사용할 수 있다.

그렇다고 QStash가 SQS와 EventBridge의 전체 기능을 대체하는 것은 아니다. AWS 계정과 서비스 전반의 이벤트 버스, 교차 계정 라우팅, 다양한 AWS 대상 통합이 필요하다면 EventBridge가 훨씬 넓다. QStash가 단순하게 느껴지는 이유는 범용 이벤트 플랫폼이 아니라 웹 API 전달이라는 좁은 문제에 집중하기 때문이다.

다섯 번째 층: 코드를 배포한다

AWS CodePipeline은 소스, 빌드, 테스트, 승인, 배포 단계를 모델링하는 범용 지속적 전달 서비스다. 각 단계에 CodeBuild, S3, ECS, Lambda나 외부 도구를 연결할 수 있다.

Vercel Git 배포는 웹 애플리케이션의 대표적인 배포 흐름을 미리 정해 놓는다.

브랜치 Push
  ↓
Preview 배포와 고유 URL 생성
  ↓
Pull Request에서 검증
  ↓
프로덕션 브랜치 Merge
  ↓
Production 자동 배포

Vercel은 GitHub, GitLab, Bitbucket, Azure DevOps와 연결해 브랜치 Push마다 Preview를 만들고 프로덕션 브랜치 변경을 자동 배포한다. 이전 커밋으로 되돌리면 배포도 되돌릴 수 있다.

일반적인 Next.js 서비스라면 별도 파이프라인 정의 없이 필요한 흐름이 만들어진다. 반면 수동 승인, 여러 계정과 리전, 복잡한 테스트 게이트, 다양한 배포 대상이 필요하면 CodePipeline 같은 범용 도구가 더 적합하다.

왜 이런 서비스들이 등장했을까

AWS는 거의 모든 산업과 워크로드에서 조합할 수 있는 범용 부품을 제공한다. 자유도가 높은 대신 선택과 연결의 책임도 사용자에게 있다.

Vercel, Supabase, Upstash는 웹 개발에서 반복되는 선택을 제품 안으로 가져왔다.

Vercel
Next.js 빌드·함수·CDN·배포를 연결

Supabase
PostgreSQL·인증·파일·Realtime을 연결

Upstash
서버리스 Redis·HTTP 메시징을 연결

이 회사들이 판매하는 것은 서버 자원만이 아니다. 여러 클라우드 부품을 조사하고 연결하고 운영하는 개발자의 시간을 제품으로 바꾼 것이다.

오픈소스와 표준 기술을 활용한다는 점도 중요하다. Next.js는 자체 배포가 가능하고, Supabase의 중심은 PostgreSQL이며, Upstash Redis는 Redis API와 호환된다. 사용자는 낮은 수준의 기술을 새로 배우지 않고 관리형 경험을 선택할 수 있다.

물론 플랫폼 전용 기능을 깊게 사용할수록 이전 비용이 생기는 소프트 락인은 남는다. 완전한 이동 가능성과 높은 개발 속도 사이에서 어느 쪽을 우선할지는 서비스 단계에 따라 결정해야 한다.

실제로 무엇이 사라지는가

관리형 웹 스택으로 바꾸면 기능보다 다음 운영 작업이 줄어든다.

CDN 배포와 캐시 연결
API Gateway 라우트 설정
Lambda 배포 패키지와 권한 연결
사용자 인증과 DB 권한 연결
Redis 클러스터 용량 계획
Queue 소비자와 이벤트 규칙 구성
빌드 산출물 전달과 배포 파이프라인 구성
Preview 환경과 도메인 생성

대신 책임이 완전히 없어지는 것은 아니다.

환경변수와 비밀정보 관리
데이터 접근 정책과 RLS
PostgreSQL 인덱스와 쿼리 성능
백업과 복구 확인
함수·DB·메시지 사용량 관찰
Worker 멱등성과 실패 처리
공급자 장애와 비용 증가에 대한 대응

인프라를 없앤 것이 아니라 자주 반복되는 운영을 플랫폼에 위임한 것이다.

언제 AWS를 다시 직접 사용할까

서비스가 커져도 반드시 AWS 전체 구성으로 돌아갈 필요는 없다. 다음과 같은 요구가 생길 때 필요한 부분만 AWS에 둘 수 있다.

사설 VPC와 기업 네트워크 연결
고정 출발지 IP와 세밀한 보안 그룹
장시간 실행되는 컨테이너 Worker
GPU나 특수한 컴퓨트 자원
복잡한 교차 계정 이벤트 라우팅
조직 표준 IAM과 감사 체계
일정하고 큰 부하에 대한 세밀한 비용 최적화

예를 들어 사용자 요청은 계속 Vercel에서 받고, 데이터는 Supabase에 저장하면서, QStash가 무거운 작업만 AWS의 컨테이너 Worker로 전달할 수 있다.

사용자 → Vercel → Supabase
            │
            └→ QStash → AWS Worker 컨테이너

관리형 웹 스택과 AWS는 양자택일이 아니다. 기본 경로는 빠르게 만들고, 특별한 요구가 생긴 부분만 범용 클라우드로 확장하는 조합도 가능하다.

선택 기준

Vercel·Supabase·Upstash가 잘 맞는 경우

Next.js 중심의 웹 서비스
작은 팀과 빠른 제품 검증
일반적인 CRUD와 인증·파일 기능
서버리스 HTTP Worker
인프라보다 제품 기능 개발에 집중해야 하는 단계

AWS를 직접 조합하는 편이 나은 경우

네트워크와 권한을 조직 표준에 맞춰야 한다.
하나의 AWS 계정 체계에서 다양한 시스템을 연결한다.
웹 이외의 워크로드가 크다.
서비스마다 세밀한 확장·보안·비용 정책이 필요하다.
전담 클라우드 운영 역량이 이미 있다.

결론

AWS 서비스 열 개가 Vercel, Supabase, Upstash 세 개로 줄어드는 것은 같은 기능이 마법처럼 합쳐졌기 때문이 아니다.

AWS는 범용 클라우드 부품을 제공하고, 세 플랫폼은 일반적인 웹 서비스를 만드는 데 반복되는 선택을 미리 조합한다.

AWS 방식
필요한 부품을 선택하고 직접 연결한다.

관리형 웹 스택
이미 연결된 웹 개발 경로를 사용한다.

작은 팀이 Next.js와 PostgreSQL로 서비스를 시작한다면 세 플랫폼의 조합은 개발 시간을 크게 줄인다. 반대로 사설 네트워크, 복잡한 이벤트 구조, 특수 컴퓨트가 필요해지는 순간 AWS의 세밀한 제어력이 다시 가치가 된다.

좋은 선택은 어느 쪽이 더 전문적으로 보이는지가 아니라, 지금 제품에 필요한 제어 수준과 운영 비용을 정확히 맞추는 것이다.