홈서버가 있는데 블로그는 AWS에 올린 이유
글 작성과 빌드는 집에서, 공개는 S3와 CloudFront에서 맡긴다. 홈서버 운영과 공개 사이트 운영을 나눠 보니 무엇이 편해지고 무엇이 남는지 정리했다.
집에는 Proxmox 홈서버가 있다. Gitea와 개발 환경도 이미 돌아간다. 그렇다면 블로그까지 집에서 공개하면 될까? 준비하다 보니 글을 만드는 장소와 방문자에게 보여 주는 장소는 달라도 된다는 결론에 이르렀다.
집에서 공개할 때 따져 본 것
리버스 프록시와 포트 포워딩으로 블로그를 서비스할 수는 있다. 하지만 그 경우 공개 도메인이 집 공인 IP를 가리키고, 공유기·서버·회선이 멈추면 블로그도 함께 멈춘다. 프록시 설정과 업데이트도 계속 관리해야 한다. 속도 역시 집 회선의 업로드 성능과 동시 접속 상황에 영향을 받는다.
그래서 방문자 요청은 AWS로 보내고, 집에서는 글 작성·빌드·배포만 하기로 했다. 공유기 포트 포워딩을 없애고 집 서비스는 Tailscale로 접속한다. 열린 포트를 줄인다고 보안 문제가 사라지는 것은 아니지만, 공개 웹 서비스 운영 부담을 집 네트워크에서 떼어 낼 수 있었다.
집: VS Code → Gitea → Gitea Actions Runner
검사·Jekyll 빌드·배포
↓
AWS: 비공개 S3 버킷 ← CloudFront ← 방문자
방문자는 집 서버가 아니라 CloudFront에 접속한다. 집에서 AWS로 나가는 요청은 집 Runner가 보내는 것뿐이다. 글 배포와 예약 발행, 매주 저장소 암호화 백업, 매시간 공개 사이트 점검이다. 집이 꺼져도 이미 배포한 정적 페이지는 제공되지만, 새 글 발행과 백업, 점검은 멈춘다.
CloudFront를 고른 기준
정적 사이트에 필요한 것은 비공개 원본, HTTPS, 캐시, 한국 방문자의 응답 속도였다. S3를 비공개로 두고 CloudFront의 Origin Access Control(OAC)로 읽도록 구성했다. 응답의 x-amz-cf-pop이 ICN이면 그 요청은 서울 엣지에서 처리된 것이다. 모든 방문자가 항상 서울 엣지를 쓰거나 일정한 속도를 보장받는다는 뜻은 아니다.
2026년 9월 기준 CloudFront 정액제 Free 플랜은 월 100만 요청과 100GB 전송량을 기본 사용량으로 제시한다. 초과분에 별도 요금이 붙지는 않지만, 사용량이 계속 크게 넘으면 전달 성능이 조정될 수 있다. 페이지뷰로 단순 환산하기 어려운 이유는 페이지마다 이미지·CSS·JS 요청 수와 전송량이 다르기 때문이다.
요금도 ‘블로그 전체 0원’으로 단정할 수 없다. 플랜에 포함되는 기능과 별개로 S3 요청, 포함 범위 밖의 AWS 기능, 도메인 등록비 등은 확인해야 한다. Route 53 호스팅 영역도 플랜에 연결해야 해당 비용 혜택을 받는다. Free 플랜에는 CloudFront 상세 접속 로그가 포함되지 않아 현재는 Google Analytics로 방문 경향을 본다.
이렇게 나누고 얻은 것
- 공개 사이트의 독립성: 집 서버를 재부팅해도 이미 배포한 페이지는 계속 제공된다.
- 운영 범위의 분리: 집은 원본과 빌드를, AWS는 방문자 응답을 맡는다.
- 복구 선택지: 집의 Git 원본은 별도로 암호화해 S3에 백업한다.
대신 AWS 계정 보안, 비용 알림, 배포용 자격 증명, 캐시 무효화까지 직접 챙겨야 한다. 이 구조는 홈서버를 없애는 선택이 아니라 홈서버가 잘하는 일과 공개 인프라가 잘하는 일을 나누는 선택이었다.
