서비스가 한두 개일 때는 http://서버IP:8096 같은 주소로 그럭저럭 버틴다. 그런데 서비스가 네 개를 넘어가면 슬슬 한계가 온다. 포트 번호를 외워야 하고, 가족에게 “8096이야, 2283 아니고”라고 설명해야 하고, 무엇보다 전부 HTTP라서 비밀번호가 평문으로 다닌다. 이때가 리버스 프록시를 들일 시점이다.
리버스 프록시가 해결하는 것
리버스 프록시는 모든 웹 요청을 한 곳(80/443 포트)에서 받아, 요청된 도메인 이름을 보고 알맞은 내부 서비스로 전달하는 중계자다.
media.example.com→ 내부의 8096 포트로photo.example.com→ 내부의 2283 포트로
효과는 세 가지다. 첫째, 포트 번호가 사라지고 기억할 만한 주소가 생긴다. 둘째, TLS(HTTPS) 처리를 프록시 한 곳에서 하므로 서비스마다 인증서를 설정할 필요가 없다. 셋째, 외부에 여는 포트가 80/443 둘로 줄어 공격 표면이 작아진다. 인증서는 Let’s Encrypt가 무료로 발급해주며, 유효기간이 90일이라 자동 갱신이 사실상 필수다 (Let’s Encrypt FAQ). 이 “자동 갱신을 누가 해주느냐”가 세 후보를 가르는 기준이 된다.
세 후보 비교
nginx — 검증된 표준, 손은 많이 간다
nginx는 리버스 프록시의 고전이자 표준이다. 자료가 압도적으로 많고, 웹서버·캐싱까지 겸할 수 있다. 다만 인증서 자동화는 내장이 아니라서 certbot 같은 외부 도구를 조합해야 하고, 서비스 추가마다 설정 파일을 직접 작성해야 한다. 설정 문법을 배우는 비용이 있지만, 그만큼 세밀한 제어가 가능하다.
Caddy — 설정 3줄, 인증서는 알아서
Caddy의 정체성은 자동 HTTPS다. 도메인만 적으면 인증서 발급·갱신·HTTP→HTTPS 리다이렉트까지 기본 동작으로 처리한다. 설정 파일(Caddyfile)도 짧다.
media.example.com {
reverse_proxy 127.0.0.1:8096
}이게 전부다. 홈서버처럼 “동작하는 HTTPS를 최소 노력으로” 원하는 환경에서 가장 빠른 길이다.
Traefik — 컨테이너와 한 몸
Traefik은 도커와의 통합이 특징이다. 컨테이너에 라벨을 붙이면 Traefik이 이를 감지해 라우팅을 자동 구성한다. 서비스를 자주 올리고 내리는 환경에서는 “프록시 설정을 따로 만질 필요가 없다”는 게 강력하다. 대신 초기 개념(엔트리포인트, 라우터, 미들웨어)의 학습 곡선이 셋 중 가장 가파르다.
선택 가이드
| 기준 | nginx | Caddy | Traefik |
|---|---|---|---|
| 설정 난도 | 중 | 하 | 상 |
| 인증서 자동화 | 외부 도구 조합 | 내장 | 내장 |
| 도커 통합 | 수동 | 수동 | 자동(라벨) |
| 자료량 | 최다 | 충분 | 충분 |
| 어울리는 사람 | 세밀 제어가 필요 | 빠르고 단순하게 | 컨테이너 중심 운영 |
처음이라면 Caddy로 시작하는 것을 권한다. 동작하는 HTTPS까지의 거리가 가장 짧고, 나중에 요구가 복잡해져서 갈아타더라도 “프록시 뒤에 서비스를 두는 구조” 자체는 그대로 이전된다.
내 답부터 적으면 셋 다 아직 안 쓴다. 이 서버에는 리버스 프록시가 없는데, 가능한 이유는 단순하다 — 인터넷에 공개한 서비스가 0개라서다. 내부 도구는 전부 VPN 터널 안에서만 접근하고, 불특정 다수에게 보여야 하는 유일한 물건(지금 읽고 있는 이 블로그)은 아예 집 밖의 정적 호스팅으로 내보냈다. 본문 끝의 “정말 공개해야 하나”라는 질문에 모든 서비스가 ‘아니오’로 답한 셈이고, 덕분에 80/443 포워딩도 인증서 갱신 실패 걱정도 내 운영 목록에는 존재하지 않는다. 물론 이 구성은 “공개할 게 없다”는 전제 위에서만 성립하고, VPN 앱 설치를 부탁하기 어려운 가족 사용자가 생기는 순간 무너진다. 그날이 오면 첫 후보는 본문 결론과 같다 — Caddy부터 시작할 생각이다.
공개하지 않는 서비스에도 HTTPS를 — DNS 챌린지
리버스 프록시를 들이면 한 가지 응용이 더 열린다. 집 안에서만 쓰는 서비스에 정식 HTTPS를 붙이는 것. 인증서 발급의 기본 방식(HTTP 챌린지)은 외부에서 80포트로 도달 가능해야 하지만, DNS 챌린지 방식은 도메인의 DNS 레코드에 값을 추가하는 것으로 소유를 증명하므로 서버가 인터넷에 노출될 필요가 없다 (Let’s Encrypt 챌린지 문서 참고).
Caddy와 Traefik 모두 주요 DNS 사업자의 API와 연동한 DNS 챌린지를 지원한다. 이 조합이면 “VPN 너머에만 존재하는 비공개 서비스”도 브라우저 경고 없는 정식 인증서로 쓸 수 있다 — 자체 서명 인증서의 경고를 매번 무시하는 나쁜 습관을 들이지 않아도 된다.
도입 전 마지막 확인
리버스 프록시는 “외부 공개”의 도구다. 도메인과 DDNS 설정이 선행되어야 하고, 공유기에서 80/443 포워딩이 필요하다. 그리고 그 전에 한 번 자문하자 — 이 서비스, 정말 인터넷에 공개해야 하나? 나만 쓰는 서비스라면 공개 대신 VPN이 정답일 수 있다. 이 판단 기준은 VPN vs 포트포워딩에서 자세히 다룬다.