월 $20 이하로 사이드 프로젝트 인프라 구축하기 (AWS + Tailscale)
사이드 프로젝트를 시작할 때 가장 먼저 만나는 벽 중 하나가 인프라 비용이다. Vercel이나 Railway 같은 서비스를 쓰면 처음엔 공짜지만, 어느 순간부터 "이거 유료 플랜 써야 되나?" 하는 순간이 온다. 그렇다고 AWS를 제대로 쓰려면 복잡하고 비쌀 것 같고.
그런데 조합을 잘 하면 HTTPS, 커스텀 도메인, 리버스 프록시까지 갖춘 인프라를 월 $20 이하 로 운영할 수 있다. 심지어 여러 사이드 프로젝트를 같은 인프라에 올려도 비용이 크게 늘지 않는다.
내가 쓰는 스택은 이렇다:
- EC2 t4g.small (Savings Plan 3년)
- ALB (Application Load Balancer)
- ACM (AWS Certificate Manager — HTTPS 인증서, 무료)
- Route53 (도메인 + DNS)
- Tailscale (내부 서버 접근용)
아키텍처 개요
외부 트래픽은 Route53 → ALB → EC2 순으로 흐른다. ALB에서 HTTPS 종료(SSL termination)를 하고, EC2로는 HTTP로 전달한다. EC2 안에서는 여러 Docker 컨테이너가 각자 다른 포트로 돌아간다.
개발자가 서버에 접근할 땐 퍼블릭 IP나 bastion 서버 없이 Tailscale 을 통해 직접 접속한다. EC2의 보안 그룹에서 SSH 포트(22)를 인터넷에 열 필요가 없다.
실제 월 비용 계산
솔직한 숫자로 얘기해보자.
EC2 t4g.small (서울 리전)
t4g.small은 vCPU 2개, RAM 2GB짜리 ARM 기반 인스턴스다. 사이드 프로젝트 1~3개 정도는 거뜬히 돌아간다.
| 구매 방식 | 월 비용 |
|---|---|
| On-Demand | ~$15.18 |
| 3년 Reserved (No Upfront) | ~$9.20 |
| 3년 Reserved (All Upfront) | ~$5.69 |
3년 All Upfront로 하면 온디맨드 대비 62% 할인 이다. 사이드 프로젝트가 망해도 서버는 계속 쓸 거니까 3년 약정이 크게 부담스럽지 않다. 나는 No Upfront로 쓰는데, 선불 없이 월 $9.20이면 충분히 만족스럽다.
ALB (Application Load Balancer)
ALB는 고정 시간 요금 + LCU(Load Balancer Capacity Unit) 요금으로 구성된다. 서울 리전 기준으로 시간당 약 $0.028, LCU당 $0.008 정도다.
트래픽이 거의 없는 사이드 프로젝트라면 LCU는 최솟값(1 LCU)으로 잡아도 된다.
- 시간 요금: $0.028 × 730시간 = $20.44
- LCU 요금 (1 LCU): $0.008 × 730시간 = $5.84
ALB 월 고정 비용은 약 $20~$26 수준이다. 언뜻 보면 비싸 보이는데, 여러 프로젝트를 하나의 ALB에 올리면 비용이 분산된다. 프로젝트 3개가 ALB 하나를 공유하면 프로젝트당 ALB 비용은 $7~$9로 줄어든다.
Route53
- Hosted Zone: $0.50/월 (첫 25개 존)
- DNS 쿼리: 월 10억 건 이하면 $0.40/백만 건 (사이드 프로젝트 수준은 사실상 무시 가능)
도메인 등록 (Route53 기준 연간)
- .com: 약 $15/년 → 월 환산 $1.25
- .io: 약 $71/년 → 월 환산 $5.92
.com을 쓰는 게 훨씬 저렴하다. .io는 브랜드 느낌이 좋아서 쓰는 거지, 비용 효율로는 .com이다.
HTTPS (ACM)
AWS Certificate Manager에서 발급하는 인증서는 완전 무료 다. ALB에 붙이는 public 인증서는 발급도 갱신도 공짜다. Let's Encrypt처럼 90일마다 갱신할 필요도 없다.
총합
| 항목 | 월 비용 |
|---|---|
| EC2 t4g.small (3년 No Upfront) | $9.20 |
| ALB (트래픽 최소) | ~$22 |
| Route53 Hosted Zone | $0.50 |
| 도메인 .com | $1.25 |
| ACM 인증서 | $0 |
| 합계 | ~$33 |
프로젝트 3개를 올리면 프로젝트당 약 $11 이다. Vercel Pro($20/월)보다 싸고, 직접 제어가 가능하다.
물론 여기서 EBS 스토리지 비용(gp3 20GB 기준 월 $1.6 정도)과 데이터 전송 비용이 소량 추가되지만, 사이드 프로젝트 수준이면 큰 차이가 없다.
여러 프로젝트 라우팅 방법
ALB의 핵심 기능 중 하나가 호스트 기반 라우팅 이다. 도메인이 달라도 ALB 하나로 각각 다른 컨테이너로 보낼 수 있다.
예를 들어 EC2 하나에 세 개의 프로젝트가 돌고 있다면:
project-a.com → EC2:3000 (Node.js 앱)
project-b.com → EC2:8080 (Go 앱)
api.project-a.com → EC2:4000 (API 서버)
ALB에서는 리스너 규칙(Listener Rule)을 이렇게 설정하면 된다:
- HTTPS 리스너(443) 생성
- 규칙 추가 → 호스트 헤더 조건으로 도메인별 분기
- 각 규칙마다 대상 그룹(Target Group)을 다르게 지정
- 각 Target Group은 EC2의 다른 포트를 바라봄
Route53에서 각 도메인의 A 레코드를 ALB의 DNS 이름으로 Alias 설정하면 된다. ACM 인증서 하나에 여러 도메인을 SAN(Subject Alternative Name)으로 추가할 수 있어서 인증서도 하나로 커버 가능하다.
Tailscale로 서버 접근하기
퍼블릭 IP 없이, SSH 포트를 인터넷에 열지 않고 서버에 접속하는 게 Tailscale의 역할이다.
EC2 보안 그룹에서는 ALB에서 오는 트래픽(포트 80 혹은 앱 포트)만 허용하고, SSH는 완전히 막는다. Tailscale이 WireGuard 기반 mesh 네트워크를 만들어주기 때문에 개발자 노트북에서 ssh ec2-user@100.x.x.x 로 바로 접속할 수 있다.
설정 방법은 Tailscale SSH 설정하기 포스트에 정리해뒀다.
EC2에 Tailscale 설치는 간단하다:
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --authkey=<your-auth-key>
sudo tailscale set --ssh
이후에는 Tailscale IP로 SSH, 데이터베이스 접속, 로그 확인 등을 할 수 있다.
보안 고려사항
몇 가지 기본적인 것만 챙기면 된다.
EC2 보안 그룹 설정
인바운드 규칙:
- 포트 80/443: ALB 보안 그룹에서만 허용
- 앱 포트 (3000, 8080 등): ALB 보안 그룹에서만 허용
- SSH (22): 인터넷에서 열지 않음 (Tailscale로 대체)
SSH를 인터넷에 열지 않는 것만으로도 브루트포스 공격 시도가 로그에서 사라진다.
Tailscale ACL
Tailscale 관리 콘솔에서 개발자 계정만 EC2에 접근하도록 ACL을 설정해두면 된다. 팀원이 늘어나면 태그 기반으로 접근 제어를 세분화할 수 있다.
ALB + ACM
HTTPS는 ACM 인증서를 ALB에 붙이는 걸로 끝이다. 인증서 갱신은 AWS가 자동으로 처리한다. EC2까지 HTTPS로 연결하지 않아도 된다 — ALB와 EC2 사이는 AWS VPC 내부 통신이라 HTTP로 충분하다.
EBS 암호화
EC2 생성할 때 EBS 볼륨 암호화를 켜두면 데이터 보안 걱정이 많이 줄어든다.
정리
비용을 요약하면:
- EC2 단독 (3년 No Upfront): 월 $9.20
- ALB 포함: 월 ~$33 (단일 프로젝트 기준)
- 프로젝트 3개 공유: 프로젝트당 월 ~$11
Vercel이나 Railway 유료 플랜과 비슷하거나 더 저렴하면서, 서울 리전에 직접 제어 가능한 인프라를 가질 수 있다. 처음 설정이 1~2시간 걸리지만, 이후에는 신경 쓸 게 별로 없다.
사이드 프로젝트를 여러 개 돌리거나, 나중에 서비스가 커졌을 때 AWS 생태계를 자연스럽게 활용하고 싶다면 이 조합을 추천한다.
이렇게 한 번 제대로 세팅해두면 사이드 개발 서버를 10개씩 돌려도 Mac은 걱정 없이 버티고, 비용도 더 늘어나지 않는다. 도메인 하나만 더 사서 dev.새프로젝트.com 을 ALB에 붙이면 끝이다. 이게 진짜 좋다.
여기서 잘 굴리다가 상용으로 넘어가는 건 또 다른 문제인데, 궁금한 사람이 있으면 다음 글에서 어떻게 가장 가성비 좋은 상용 운영 환경을 구축하는지 풀어보겠다.