배포했는데 왜 느릴까요? 서버·데이터베이스 Region 이해하기

바이브코딩으로 만든 서비스를 배포했습니다. 주소도 생겼고 첫 화면도 잘 열려요. 그런데 직접 사용해보면 어딘가 답답합니다.

첫 화면은 금방 나오는데 로그인이 느려요.
예약 버튼을 누르면 한참 기다려요.
관리자에서 목록을 열 때마다 늦어요.
localhost에서는 괜찮았는데 배포하고 느려졌어요.

AI에게 물어보면 코드 최적화, 이미지 압축, 캐시 같은 해결책을 제안합니다. 모두 확인할 가치가 있지만, 그전에 살펴볼 것이 있어요.

서버와 데이터베이스가 어느 Region에서 실행되고 있나요?

Region은 서비스를 실행하는 데이터센터의 지역을 뜻합니다. 서울, 도쿄, 싱가포르, 미국 동부처럼 실제 컴퓨터가 놓인 위치예요. 배포가 성공했다고 해서 서버와 데이터베이스가 자동으로 가장 가까운 곳에 모이는 것은 아닙니다.

이 글에서는 한 번의 클릭이 이동하는 경로를 따라가며 Region이 왜 속도에 영향을 주는지 알아볼게요.

아직 배포 플랫폼을 정하는 중이라면 Vercel·Netlify·Railway 비교를 먼저 읽어도 좋습니다.

배포했다고 모든 것이 가까워지는 것은 아니에요

웹서비스는 한 장소에서 혼자 작동하지 않습니다. 보통 여러 역할이 연결되어 있어요.

사용자의 브라우저
→ 웹페이지를 전달하는 곳
→ 요청을 처리하는 서버
→ 정보를 보관하는 데이터베이스
→ 필요한 경우 외부 API

각 역할을 서로 다른 회사의 서비스에 맡길 수 있습니다.

웹페이지와 Next.js 서버 → Vercel
데이터베이스 → Supabase
결제 → Toss Payments
이메일 → Resend

서비스 이름이 다르다는 것만 중요한 게 아니에요. 각 서비스가 실제로 어느 지역에서 실행되는지도 중요합니다.

서울에 있는 사용자가 버튼을 눌렀는데 서버는 미국에 있고 데이터베이스는 서울에 있다면 요청은 바다를 여러 번 건너야 할 수 있어요.

첫 화면은 빠른데 버튼을 누르면 느린 이유

“사이트가 느리다”는 말에는 서로 다른 상황이 섞여 있습니다.

웹페이지와 이미지가 나타나는 속도

HTML, CSS, JavaScript, 이미지처럼 미리 준비할 수 있는 파일은 CDN을 통해 사용자와 가까운 곳에서 전달할 수 있어요.

CDN은 같은 파일을 여러 지역에 복사해두고, 방문자와 가까운 곳에서 보내주는 전달망입니다. Vercel도 전 세계에 분산된 CDN의 접점을 통해 콘텐츠를 전달합니다. (Vercel Regions 문서 (새 탭에서 열림))

그래서 소개 페이지와 이미지가 빠르게 나타날 수 있어요.

로그인·예약·검색 결과가 돌아오는 속도

로그인, 예약, 주문, 검색, 관리자 목록은 미리 준비한 파일만 보내서 끝나지 않습니다. 서버가 요청을 받고 데이터베이스를 조회한 뒤 결과를 만들어야 해요.

예약 버튼 클릭
→ 서버가 로그인 상태 확인
→ 예약 가능한 시간 조회
→ 중복 예약 확인
→ 예약 정보 저장
→ 완료 결과 반환

이때는 CDN이 가깝다는 사실만으로 충분하지 않습니다. 실제 계산을 하는 서버 Region과 정보를 찾는 데이터베이스 Region이 중요해져요.

따라서 이런 현상이 생길 수 있습니다.

첫 화면과 이미지는 빠르다
하지만 로그인과 예약은 느리다

앞부분은 가까운 CDN에서 전달되지만, 버튼을 누른 뒤의 요청은 멀리 있는 서버와 데이터베이스를 거칠 수 있기 때문입니다.

한 번의 예약 요청이 미국과 서울을 오간다면

한국 사용자를 위한 예약 서비스를 예로 들어볼게요.

사용자: 서울
Next.js 서버: 미국 동부
데이터베이스: 서울

사용자가 예약 버튼을 누르면 대략 다음처럼 이동할 수 있습니다.

1. 서울 사용자 → 미국 서버
2. 미국 서버 → 서울 데이터베이스
3. 서울 데이터베이스 → 미국 서버
4. 미국 서버 → 서울 사용자

데이터베이스를 한 번만 조회한다면 왕복도 한 번입니다. 하지만 실제 기능은 여러 확인과 저장 과정을 거칠 수 있어요.

사용자 조회
예약 가능 시간 조회
중복 예약 조회
예약 저장
저장 결과 확인

서버와 데이터베이스가 멀면 이 과정마다 네트워크 왕복 시간이 더해질 수 있습니다. 각각의 작업은 짧아 보여도 여러 번 반복되면 사용자는 버튼이 늦게 반응한다고 느껴요.

Vercel도 Functions를 데이터 소스와 같은 Region 또는 가능한 가까운 곳에서 실행해야 지연을 줄일 수 있다고 안내합니다. Vercel Functions의 기본 실행 지역은 미국 워싱턴 D.C.의 iad1이므로, 한국 서비스라고 해서 서버가 자동으로 서울에서 실행된다고 가정하면 안 됩니다. (Vercel Functions 문서 (새 탭에서 열림), Vercel Regions 문서 (새 탭에서 열림))

사용자의 위치보다 데이터베이스가 더 중요할 때도 있어요

Region을 고를 때 흔히 듣는 기준은 “사용자와 가까운 곳을 고르세요”입니다. 출발점으로는 맞지만 항상 그것만 보면 되는 것은 아니에요.

다음 두 구조를 비교해볼게요.

A
사용자: 서울
서버: 서울
DB: 서울

B
사용자: 서울
서버: 서울
DB: 미국

A는 서버가 데이터베이스에 가까워서 여러 번 조회하더라도 이동 거리가 짧습니다. B는 브라우저와 서버는 가깝지만, 서버가 데이터를 확인할 때마다 미국을 오가야 할 수 있어요.

데이터베이스를 많이 사용하는 서비스라면 보통 다음 순서로 생각하는 편이 좋습니다.

데이터베이스가 어디에 있는가?
→ 서버를 데이터베이스 가까이에 둘 수 있는가?
→ 사용자가 서버에 접근하는 경로는 어떤가?

Supabase 프로젝트는 하나의 주 Region에 배포되며 서울을 포함한 구체적인 AWS Region을 선택할 수 있습니다. 프로젝트를 만들 때 선택한 데이터베이스 위치를 먼저 확인하세요. (Supabase Regions 문서 (새 탭에서 열림))

서버에서 Supabase PostgreSQL에 직접 연결하는 구조는 바이브코딩할 때 Supabase를 추천하는 이유에서 자세히 볼 수 있습니다.

그렇다고 무조건 서울을 고르면 될까요?

한국 사용자가 많다면 서울 Region은 자연스러운 후보입니다. 하지만 서비스 전체를 보고 결정해야 해요.

사용자가 어디에 있나요?

사용자의 대부분이 한국에 있다면 아시아 Region이 유리할 가능성이 큽니다. 사용자가 전 세계에 흩어져 있다면 CDN과 캐시, 여러 Region 운영을 함께 검토해야 할 수 있어요.

데이터베이스가 어디에 있나요?

서버가 데이터베이스를 자주 조회한다면 둘 사이의 거리를 줄이는 것이 중요합니다. 서버만 서울로 옮기고 데이터베이스를 미국에 그대로 두면 기대만큼 빨라지지 않을 수 있어요.

핵심 외부 서비스는 어디에 있나요?

AI 모델, 검색 엔진, 회사 내부 API처럼 요청 시간이 긴 외부 서비스가 있다면 그 서비스와의 거리도 영향을 줄 수 있습니다. 다만 외부 API의 처리 시간 자체가 길다면 Region을 옮겨도 개선 폭이 작을 수 있어요. 먼저 어느 구간에서 시간이 걸리는지 측정해야 합니다.

선택한 플랫폼에 원하는 Region이 있나요?

플랫폼마다 제공하는 지역이 다릅니다.

• Vercel은 서울을 포함한 여러 Functions Region을 제공합니다.
• Netlify Functions는 프로젝트 또는 함수별 Region을 설정할 수 있으며, 기본값을 바꿀 때는 데이터베이스와 사용자 위치를 함께 보라고 안내합니다. (Netlify Functions 설정 문서 (새 탭에서 열림))
• Railway의 아시아 배포 지역은 현재 싱가포르이며, 서비스 설정에서 Region을 선택할 수 있습니다. 제공 지역은 바뀔 수 있으므로 배포할 때 최신 목록을 확인해야 해요. (Railway Regions 문서 (새 탭에서 열림))
• Supabase는 서울, 도쿄, 싱가포르를 포함한 데이터베이스 Region을 제공합니다.

플랫폼마다 가장 가까운 선택지가 다르기 때문에 “한국 서비스는 모두 서울”처럼 한 문장으로 정리할 수는 없습니다.

데이터 보관 규정이 있나요?

회사나 기관의 정책에 따라 데이터를 특정 국가나 지역에 보관해야 할 수 있습니다. 이런 조건이 있다면 속도보다 먼저 충족해야 해요. 개인정보와 계약 조건이 걸린 경우에는 해당 서비스의 최신 약관과 조직의 기준을 직접 확인해야 합니다.

여러 Region에 배포하면 무조건 빨라질까요?

서버를 서울, 미국, 유럽에 모두 배포하면 모든 문제가 해결될 것처럼 보입니다. 하지만 데이터베이스가 서울 한 곳에만 있다면 이야기가 달라져요.

유럽 사용자
→ 가까운 유럽 서버
→ 멀리 있는 서울 데이터베이스

사용자와 서버는 가까워졌지만 서버와 데이터베이스는 멀어졌습니다. 로그인이나 예약처럼 DB 조회가 많은 기능은 여전히 느릴 수 있어요.

여러 Region에서 같은 데이터를 빠르게 사용하려면 복제된 데이터의 읽기와 쓰기, 최신 상태의 일치, 장애 처리까지 생각해야 합니다. 서버를 여러 곳에 복사하는 것만으로 끝나는 문제가 아니에요.

처음부터 여러 Region을 사용하는 것보다 다음 순서가 안전합니다.

1. 사용자가 많은 지역을 확인한다.
2. 데이터베이스 Region을 확인한다.
3. 서버를 데이터베이스 가까이에 둔다.
4. 실제 요청 시간을 측정한다.
5. 필요한 이유가 확인된 뒤 여러 Region을 검토한다.

Region이 원인이 아닐 수도 있어요

느리다고 해서 모든 문제가 거리에 있는 것은 아닙니다.

• 한 번의 화면에서 같은 데이터를 반복해서 조회하고 있다.
• 필요한 것보다 너무 많은 데이터를 가져온다.
• 데이터베이스 검색에 필요한 인덱스가 없다.
• 외부 API가 늦게 응답한다.
• 큰 이미지나 동영상을 그대로 내려받는다.
• 서버가 처음 실행될 때 준비 시간이 길다.
• 오류가 나서 같은 요청을 계속 다시 시도한다.

Region은 중요한 점검 항목이지만 만능 답은 아니에요. 따라서 설정부터 바꾸기보다 각 구간이 실제로 얼마나 걸리는지 확인해야 합니다.

브라우저 → 서버
서버 내부 처리
서버 → 데이터베이스
서버 → 외부 API
데이터를 화면에 표시

“전체가 느리다”는 설명만으로는 원인을 찾기 어렵습니다. 첫 화면, 로그인, 목록 조회, 저장처럼 행동을 나눠서 시간을 비교하세요.

이런 프로젝트는 Region 영향을 다르게 받아요

소개 페이지와 블로그

대부분 미리 만들어진 페이지와 이미지라면 CDN이 많은 일을 맡습니다. 서버나 데이터베이스 요청이 적어서 Region의 영향이 상대적으로 작을 수 있어요.

예약·주문·관리자 서비스

버튼을 누를 때마다 서버가 권한을 확인하고 데이터베이스를 조회합니다. 서버와 데이터베이스의 거리가 체감 속도에 영향을 주기 쉬워요.

파일 업로드 서비스

사용자와 파일 저장소 사이의 거리, 업로드 파일 크기, 이미지 변환 과정이 중요합니다. 데이터베이스 Region만 바꿔서는 큰 파일 업로드가 빨라지지 않을 수 있어요.

AI 기능이 있는 서비스

서버가 외부 AI API를 호출해 답을 기다립니다. 사용자, 앱 서버, AI API 사이의 거리와 모델의 처리 시간이 함께 섞여 있어요. 어떤 구간이 오래 걸리는지 나눠 측정해야 합니다.

이미 배포했다면 이렇게 확인하세요

먼저 대시보드와 프로젝트 설정에서 위치를 적어보세요.

주요 사용자: 한국
웹 배포 플랫폼: Vercel
서버 Functions Region: 확인 필요
데이터베이스: Supabase Seoul
파일 저장소 Region: 확인 필요
오래 걸리는 외부 API: 확인 필요

그다음 느린 행동 하나를 골라 요청 경로를 그립니다.

관리자 주문 목록 열기
→ Next.js 서버
→ PostgreSQL 연결
→ 주문 조회
→ 결제 상태 조회
→ 결과 반환

Vercel에서는 프로젝트의 Functions 설정에서 실행 Region을 확인하고, Netlify와 Railway도 서비스 설정에서 Region을 확인할 수 있습니다. 설정을 바꾸기 전에는 데이터베이스, 저장 공간, 외부 API와의 연결에 어떤 영향이 있는지 먼저 점검하세요.

특히 데이터가 있는 서비스를 다른 Region으로 옮기는 일은 화면 설정 하나로 끝나지 않을 수 있어요. Railway도 볼륨이 연결된 서비스의 Region을 바꾸면 볼륨 이동과 서비스 중단이 발생할 수 있다고 안내합니다. (Railway Regions 문서 (새 탭에서 열림))

AI에게 Region을 점검시키는 프롬프트

AI에게 “서비스가 느리니 Region을 바꿔줘”라고 바로 요청하지 마세요. 먼저 현재 경로와 근거를 읽기 전용으로 조사하게 하는 편이 안전합니다.

배포한 서비스에서 로그인, 예약, 목록 조회 같은 서버 기능이 느립니다.
아직 코드나 배포 설정을 변경하지 말고 Region과 요청 경로를 점검해줘.

다음을 실제 프로젝트 파일과 제공된 배포 설정을 근거로 확인해줘.

1. 주요 사용자가 있는 지역
2. 정적 파일을 전달하는 CDN 또는 배포 플랫폼
3. Next.js Functions나 백엔드 서버가 실행되는 Region
4. 데이터베이스 서비스와 Region
5. 파일 저장소와 Region
6. 결제, 이메일, AI 등 주요 외부 API
7. 느린 기능이 거치는 서버 요청과 DB 조회 순서
8. 한 요청에서 반복되는 DB 조회나 외부 API 호출
9. 현재 Region을 확인할 수 없는 항목
10. Region 변경 시 필요한 재배포, 데이터 이동, 중단 가능성

결과는 다음 표로 정리해줘.
구간 | 출발 위치 | 도착 위치 | 확인한 근거 | 예상 영향 | 추가 측정 방법

Region이 원인이라고 단정하지 말고,
코드·DB 조회·외부 API·큰 파일 등 다른 원인 후보도 함께 구분해줘.
마지막에는 영향이 크고 확인 비용이 낮은 점검부터 순서대로 제안해줘.

AI가 배포 서비스의 대시보드에 접근할 수 없다면 추측하게 하지 말고, 내가 어느 화면에서 무엇을 확인해야 하는지 안내하게 하세요.

정리

• Region은 서버와 데이터베이스가 실제로 실행되는 지역입니다.
• CDN이 가까워서 첫 화면이 빨라도 로그인과 예약 같은 서버 기능은 느릴 수 있습니다.
• 데이터베이스를 자주 조회하는 서비스는 서버와 DB 사이의 거리가 중요합니다.
• 한국 사용자가 많아도 모든 서비스를 무조건 서울에 둘 수 있거나 그래야 하는 것은 아닙니다.
• 여러 Region에 서버를 배포해도 데이터베이스가 멀리 있으면 문제가 남을 수 있습니다.
• Region을 바꾸기 전에 실제 요청 경로와 각 구간의 시간을 확인해야 합니다.
• AI에게는 설정 변경보다 현재 위치와 근거를 먼저 조사하게 하세요.

배포는 코드를 인터넷에 올리는 것으로 끝나지 않습니다. 사용자가 버튼을 누른 뒤 요청이 어디까지 갔다가 돌아오는지도 서비스의 일부예요.

첫 화면은 빠른데 로그인이나 예약만 느리다면 코드를 전부 고치기 전에 먼저 그 경로를 그려보세요.

사용자 → 서버 → 데이터베이스 → 서버 → 사용자

이 선이 바다를 몇 번 건너는지 알게 되면, 어떤 Region을 가까이 둬야 하는지도 훨씬 선명해집니다.

배포한 프로젝트의 성능과 설정을 직접 점검하려면 바이브코딩 가이드 13장의 배포 실습을 참고하세요.