바이브코딩으로 서비스를 만들다 보면 보통 이런 구조로 시작합니다.

  • 프론트엔드
  • 백엔드
  • 데이터베이스(DB)
  • 필요에 따라 추가되는 기타 서비스

처음에는 모두 한 서버에 올려도 충분합니다.

 

문제는 클라우드에 배포한 뒤에도
이 구성요소들을 전부 인터넷에 공개해두는 경우입니다.


인터넷에 공개해야 하는 것은 생각보다 적습니다.

사용자가 실제로 접속해야 하는 곳은 보통 다음과 같습니다.

  • 프론트엔드
  • 외부 요청을 받는 백엔드 API

반면 다음과 같은 구성요소들은 외부 사용자가 직접 접속할 이유가 없습니다.

  • 데이터베이스
  • 내부 관리자 도구
  • 파일 처리 서버
  • 메시지 큐
  • 모니터링 도구
  • 배치 서버
  • 기타 내부 서비스

즉, 외부에 공개할 서비스와 내부에 숨겨둘 서비스를 구분해야 합니다.


여기서 등장하는 개념이 DMZ입니다.

DMZ(Demilitarized Zone)는
외부 인터넷과 내부 시스템 사이에 두는 완충지대입니다.

 

집으로 비유하면 이해하기 쉽습니다.

🏡 현관 = 외부에 공개된 영역

손님은 현관까지 들어올 수 있습니다.

🚪 안방 = 내부망

가족만 들어갈 수 있습니다.

 

서비스 구조도 비슷합니다.

인터넷
   │
   ▼
프론트엔드 / 백엔드
   │
   ▼
DB / 내부 서비스 / 기타 시스템

외부 사용자는 프론트엔드와 백엔드까지만 접근합니다.

백엔드만 내부망을 통해 DB와 다른 서비스에 접근합니다.


왜 이렇게 나눠야 할까요?

예를 들어 백엔드 서버에 취약점이 생겼다고 가정해 보겠습니다.

DB와 내부 서비스까지 모두 인터넷에 공개되어 있다면
공격자는 각각의 포트에 직접 접근을 시도할 수 있습니다.

 

하지만 DB와 내부 서비스가 내부망에만 있다면

외부에서는 직접 접근할 수 없습니다.

 

즉,

공격자가 넘어야 할 보안 장벽이 하나 더 생깁니다.

 

중요한 것은 단순히 서버를 여러 대로 나누는 것이 아닙니다.

 

누가 어디까지 접근할 수 있는지 경계를 만드는 것입니다.


클라우드에서는 어떻게 구성할까요?

클라우드에서는 보통 네트워크를 두 영역으로 나눕니다.

공개 영역

인터넷에서 접근할 수 있는 영역입니다.

여기에는 보통 다음이 위치합니다.

  • 프론트엔드 서버
  • 백엔드 API 서버
  • 로드밸런서
  • 리버스 프록시

비공개 영역

인터넷에서 직접 접근할 수 없는 영역입니다.

여기에는 보통 다음이 위치합니다.

  • 데이터베이스
  • 내부 API
  • 배치 서버
  • 메시지 큐
  • 파일 처리 서버
  • 기타 내부 서비스

백엔드는 내부 IP를 통해
이 서비스들과 통신합니다.


프론트엔드도 항상 DMZ에 있어야 하나요?

구조에 따라 다릅니다.

 

정적 프론트엔드를 Vercel, Cloudflare Pages, CDN 등에 올렸다면
프론트엔드는 별도의 공개 서비스로 동작할 수 있습니다.

 

이 경우 구조는 대략 이렇게 됩니다.

사용자
   │
   ▼
프론트엔드
   │
   ▼
백엔드 API
   │
   ▼
DB / 내부 서비스

핵심은 같습니다.

 

사용자는 백엔드를 통해서만 데이터를 요청하고,
DB에는 직접 접근하지 않습니다.


그렇다면 개발자는 DB에 어떻게 접속할까요?

여기서 가장 많이 생기는 질문이 있습니다.

DB를 외부에 공개하지 않으면
클라우드에 있는 DB에는 어떻게 접속하나요?

대표적인 방법은 다음과 같습니다.

1. SSH 접속 후 DB 접근

먼저 서버에 SSH로 접속합니다.

 

그다음 서버 내부에서
DB의 내부 주소로 접속합니다.

 

가장 단순하고 흔한 방식입니다.


2. SSH Tunnel

SSH가 내 PC와 서버 사이에
안전한 통로를 만들어줍니다.

 

내 PC에서는 마치 로컬 DB에 접속하는 것처럼 사용할 수 있습니다.

DBeaver, DataGrip, TablePlus 같은 도구에서도
SSH Tunnel을 지원합니다.

 

예를 들면 내 PC에서 아래 주소로 접속합니다.

localhost:15432

그러면 실제 연결은 다음처럼 전달됩니다.

내 PC
   │
SSH Tunnel
   │
서버
   │
내부 DB

DB 포트는 인터넷에 공개하지 않아도 됩니다.


3. VPN

내 PC를 클라우드 내부망에 연결하는 방식입니다.

 

VPN에 접속하면
내 PC가 내부 네트워크에 들어온 것처럼 동작합니다.

 

기업이나 팀 단위 운영에서 자주 사용합니다.


4. 특정 IP만 허용

개발자의 고정 IP만 방화벽에서 허용하는 방법도 있습니다.

 

설정은 간단하지만
IP가 자주 바뀌면 관리가 번거롭습니다.

 

또한 SSH Tunnel이나 VPN보다
직접 노출 범위가 넓을 수 있습니다.


꼭 DMZ를 구축해야 하나요?

작은 개인 프로젝트라면
처음부터 복잡한 네트워크 구조를 만들 필요는 없습니다.

 

프론트엔드, 백엔드, DB를
하나의 서버에서 운영할 수도 있습니다.

 

다만 같은 서버에 있더라도
외부에 공개할 포트는 최소화해야 합니다.

 

보통 인터넷에 공개하는 포트는 다음 정도면 충분합니다.

80   HTTP
443  HTTPS
22   SSH

SSH도 가능하다면
허용 IP 제한이나 VPN, SSH 키 인증을 함께 사용하는 것이 좋습니다.

 

DB 포트는 외부에 열지 않고
서버 내부에서만 접근하도록 설정할 수 있습니다.


핵심은 서버 개수가 아닙니다.

DMZ를 이해할 때
서버를 여러 대로 나누는 것만 생각할 필요는 없습니다.

 

중요한 것은 다음 세 가지입니다.

 

무엇을 인터넷에 공개할 것인가

무엇을 내부에 숨길 것인가

누가 어떤 경로로 접근할 수 있는가

 

바이브코딩으로 빠르게 만드는 것도 중요합니다.

 

하지만 서비스가 실제 사용자를 받기 시작했다면
네트워크 경계와 접근 권한도 함께 고민해야 합니다.

 

AI가 코드는 빠르게 만들어줄 수 있지만,
어디까지 공개할지는 결국 운영자가 결정해야 합니다.


file_000000002e4081fd8c5d1387722fdf67.png.jpg