TuBrief
구독 채널
비디오
커뮤니티

Vercel과 AWS를 연결하는 서버리스 아키텍처 실무 설계서

TuBrief 편집팀
2026년 7월 21일
0
컴퓨터/소프트웨어

원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.

한국어Español中文العربيةEnglishहिन्दीDeutschFrançaisPortuguêsРусскийBahasa Indonesia日本語

관련 영상

Ship 26 NYC - 더 크게 생각하기: Vercel과 AWS로 프로토타입에서 글로벌 규모로 확장하기16:23

Ship 26 NYC - 더 크게 생각하기: Vercel과 AWS로 프로토타입에서 글로벌 규모로 확장하기

Vercel

커뮤니티의 다른 글

사내 시스템에 llm api 붙일 때 마주하는 현실적인 한계와 대응법

2026년 9월 13일

레거시 백엔드에 GPT-6 Astra 붙일 때 예산 승인과 보안 통과를 먼저 끝내는 법이 있습니다

2026년 9월 13일

에이전트끼리 대화하다 6천만 원 청구서가 나오는 이유

2026년 9월 13일

사내 RAG 벡터 검색에 Okta 권한 필터를 직접 거는 방법

2026년 9월 13일

브라우저 에이전트에게 내 구글 계정을 통째로 넘기면 안 되는 이유

2026년 9월 12일

Apple Won the AI Race

2026년 9월 12일

댓글 (0)

Log in to leave a comment

아직 작성된 글이 없습니다

© 2026 . All rights reserved.

TuBrief
구독 채널
비디오
커뮤니티
로그인

Vercel과 AWS를 연결하는 서버리스 아키텍처 실무 설계서

1. Vercel 서버리스 환경에서 AWS Aurora 데이터베이스 연결 한계 극복하기

서버리스 함수는 트래픽이 몰릴 때 수백 개의 인스턴스를 순식간에 띄운다. 이때 각 인스턴스가 PostgreSQL 기반의 AWS Aurora 데이터베이스에 직접 커넥션을 꽂으면 데이터베이스는 바로 다운된다. 16GB RAM을 쓰는 db.r6g.large 인스턴스의 최대 동시 커넥션 수는 1,600개 정도다. 연결 하나당 5MB 이상의 메모리를 먹기 때문이다. 게다가 서버리스 함수가 끝날 때 유휴 타임아웃 타이머가 멈추면서 커넥션 누수가 일어난다.

이 문제를 풀려면 프론트엔드와 데이터베이스 사이에 AWS RDS Proxy를 박아야 한다. 프록시는 수천 개의 클라이언트 연결을 받아내고 Aurora 본체에는 딱 필요한 만큼의 소수 커넥션만 유지한다. AWS CLI로 데이터베이스 인증 정보와 서브넷을 지정해 프록시를 만들고 대상 그룹 커넥션 풀의 최대 비율을 100퍼센트로, 유휴 비율을 50퍼센트로 맞추면 된다. Next.js App Router 프로젝트의 lib/db.ts 파일에서 최대 커넥션 수 10개, 최소 커넥션 수 1개, 유휴 타임아웃 5,000밀리초로 파라미터를 잡아야 워터폴 현상과 데이터베이스 리소스 독점을 막을 수 있다.

2. Amazon OpenSearch Serverless의 비용 최적화와 유휴 상태 관리

기본 OpenSearch Serverless는 트래픽이 없어도 최소 4 OCU를 항상 돌렸다. OCU당 시간당 0.24달러가 나가니 개발 환경인데도 월 700달러 이상이 그냥 깨진다. 새로 나온 넥스트젠 아키텍처는 10분 동안 요청이 없으면 컴퓨팅 자원을 0 OCU로 완전히 줄여버린다. 유휴 시 월 컴퓨팅 비용이 0달러로 내려간다.

다만 0 OCU 상태에서 검색 요청이 들어오면 10초에서 30초 사이의 콜드 스타트 지연이 발생한다. Vercel 서버리스 함수는 기본적으로 15초에서 25초 사이에 게이트웨이 타임아웃을 뱉기 때문에 동기식으로 호출하면 504 에러가 터진다. 비동기 처리 패턴을 짜야 하는 이유다. API 라우트에서 검색 요청을 받으면 고유 작업 아이디를 만들고 202 상태 코드를 즉시 던진다. 클라이언트는 이 202를 받으면 대기 시간 간격을 두고 상태 폴링 함수를 계속 찌르다가 작업이 끝났을 때 결과를 가져가면 된다. AWS CLI에서 generation 값을 NEXTGEN으로 잡고 최소 용량을 0 OCU로 두면 트래픽이 없을 때 돈이 안 나간다.

3. 글로벌 사용자 대상 1밀리초 미만 지연 시간을 위한 리전 라우팅 설계

Vercel 프로젝트를 그냥 만들면 컴퓨팅 리전은 미국 동부 iad1 리전으로 잡힌다. 한국 사용자가 접속했는데 데이터베이스는 서울에 있다면 요청이 태평양을 두 번 건너느라 400밀리초가 넘는 RTT 지연이 생긴다. Vercel 엣지 네트워크가 전 세계 126개 이상의 PoP에서 TCP 핸드셰이크를 1밀리초 만에 처리해도 동적 API 코드가 데이터베이스가 있는 물리 리전과 다르면 소용없다.

Vercel Compute 리전 코드를 AWS 백엔드 리전과 1대 1로 맞춰서 대서양 횡단 홉을 없애야 한다. vercel.json 파일에 루트 레벨의 기본 컴퓨팅 리전을 서울인 icn1으로 박고 장애 조치 리전은 도쿄인 hnd1로 등록한다. 개별 API 라우트 경로마다 실행 리전을 세분화해서 매핑하면 된다. 정적 자산은 전 세계 PoP에 캐싱하고 미들웨어는 엣지 런타임에서 JWT 검증만 처리하며 동적 API는 AWS 리전과 같은 위치의 Vercel Regional Compute에서 돌려야 전체 RTT를 10밀리초 이내로 잡을 수 있다.

4. 기존 모놀리식 백엔드에서 AWS 네이티브 서비스 조합으로의 점진적 마이그레이션 순서

한 번에 시스템을 갈아엎는 빅뱅 방식은 자살 행위다. 교목 아키텍처 패턴으로 가야 한다. 첫 번째 단계에서는 기존 모놀리식 데이터베이스와 AWS Aurora 간의 데이터 동기화를 뚫고 Vercel에 신규 백엔드 라우터를 올린다. 두 번째 단계에서는 미들웨어를 써서 똑같은 엔드포인트로 들어오는 트래픽을 기존 모놀리식과 새 AWS 서비스로 비율을 나눠서 보낸다. 세 번째 단계에서 신규 아키텍처가 버티는 게 확인되면 기존 모놀리식 코드를 완전히 날린다.

마이그레이션 중 데이터가 꼬이는지 보려면 지표를 똑바로 잡아야 한다. AWS DMS 복제 지연 시간은 100밀리초 미만으로 고정하고 멱등성 키 헤더를 강제한다. Vercel 미들웨어 미러링 요청 간 응답 데이터 불일치율은 0.01퍼센트 아래로 유지하고 RDS Proxy의 클라이언트 대기 시간 p99는 50밀리초 미만으로 잡는다. Aurora CPU 사용률이 70퍼센트를 넘거나 새 경로의 5xx 에러율이 1퍼센트를 넘으면 피처 플래그로 즉시 0퍼센트 롤백을 때려야 장애를 막는다.