Selumo목차
집에 둔 홈서버든 빌린 서버든, 한 대에 서비스 몇 개를 올리고 나면 곧 관리 도구가 서비스보다 많아져요. 분석 대시보드, 자동화 도구, 에러 추적기까지 전부 주소가 필요해지는 순간, 어디까지 열어 둘지 정해야 해요.
이 글에서 관리 도구는 방문자가 아니라 운영하는 사람이 여는 화면을 말해요. 가게로 치면 손님이 드나드는 매장이 아니라 직원만 들어가는 창고와 사무실이에요.
혹시 이런 고민 있으신가요?
- 관리 화면을 공개 주소에 두자니 불안하고, 닫아 두자니 접속할 때마다 번거로워요.
- VPN 을 깔았는데 막상 쓰기 불편해서 결국 잘 안 켜게 돼요.
- 앞에 프록시를 하나 더 세웠더니 방문자 주소가 전부 같은 값으로 찍혀요.
이 글을 읽으면
- 도구마다 "누가 부르는가"로 공개할 것과 잠글 것을 나눌 수 있어요.
- 로컬 전용, VPN, 공개와 각자 로그인, 터널과 접근 정책, 네 가지 입구의 장단점을 비교해 고를 수 있어요.
- 앞단 프록시가 늘어났을 때 방문자 주소를 제대로 읽도록 설정하고 확인할 수 있어요.
1단계. 도구를 부르는 쪽으로 나누기
입구를 고르기 전에 도구 목록부터 두 칸으로 나눠요. 기준은 하나예요. 그 주소를 방문자의 브라우저가 부르는지, 사람인 여러분만 부르는지예요.
웹 분석 도구(방문자가 어떤 페이지를 봤는지 세는 도구)가 좋은 예예요. 방문자 브라우저가 스크립트를 받아 가고, 기록도 브라우저가 직접 보내요. 이런 도구를 로그인 뒤에 숨기면 수집이 멈춰요. 에러 추적기, 고객 상담 위젯, 기능 플래그 도구(코드를 다시 배포하지 않고 기능을 켜고 끄는 스위치)도 같은 이유로 방문자 쪽에서 불리는 경로가 있어요.
반대로 비즈니스 대시보드나 워크플로 자동화 도구는 사람만 열어요. 이쪽은 인터넷에 보일 이유가 없어요.
| 구분 | 예 | 입구의 조건 |
|---|---|---|
| 방문자가 부르는 것 | 서비스 앱, 로그인 서버, 웹 분석, 에러 추적, 상담 위젯, 기능 플래그 | 공개 주소여야 하고, 관리 화면은 각자 로그인으로 지켜요 |
| 사람만 부르는 것 | 비즈니스 대시보드, 워크플로 자동화 | 공개 주소로 우회해 들어올 길이 없어야 해요 |
| 서버 자체 | SSH, 데이터베이스 직접 접속 | 인터넷에 열지 않아요 |
SSH(Secure Shell)는 멀리 있는 서버에 암호화된 통로로 접속해 명령을 치는 방법이에요. 서버의 열쇠에 가까워서 가장 깊이 잠가야 해요.
저희도 이렇게 나눴어요. 웹 분석은 방문자 브라우저가 직접 보내야 해서 처음부터 공개였어요. 에러 추적, 상담, 기능 플래그 도구는 관리 화면만 따로 숨기려면 수집 경로와 호스트를 나눠야 해서, 지금은 각자 로그인으로 둬요.
TIP
표의 가운데 칸을 채울 때 "이 주소를 막으면 방문자 쪽에서 무엇이 깨지는가"를 물어보세요. 깨지는 게 없으면 사람만 쓰는 도구예요.
2단계. 네 가지 입구를 비교해 고르기
도구를 나눴으면 입구를 골라요. 선택지는 크게 네 가지예요. 표에 나오는 낱말은 표 아래에서 하나씩 풀어 둘게요.
| 입구 | 이렇게 동작해요 | 좋은 점 | 대가 |
|---|---|---|---|
| 로컬 전용과 SSH 터널 | 도구를 서버의 127.0.0.1 포트에만 열고, SSH 포트 포워딩으로 접속해요 | 인터넷에서 보이지 않아요. 인증서가 필요 없어요 | 도구마다 포트를 기억해야 하고, 접속할 때마다 터널을 열어야 해요 |
| VPN(예: Tailscale) | 사설망에 붙은 기기만 도구에 닿아요 | 로그인 폼 하나에 기대지 않아요 | 리버스 프록시가 사설 이름과 공개 이름을 나눠야 하고, 도구마다 대역 허용 설정이 필요해요 |
| 공개 주소와 각자 로그인 | 도구마다 공개 서브도메인을 주고, 도구의 로그인 화면으로 지켜요 | 어디서나 바로 열려요. 설정이 가장 적어요 | 로그인 화면이 인터넷에 보여요 |
| 터널과 접근 정책 | 터널 프로그램이 도구로 바로 보내고, 그 앞에서 이메일 같은 정책으로 걸러요 | 공개 주소로 우회할 길이 없어요 | 외부 서비스에 기대고, 자동화 도구가 부를 때 토큰이 필요해요 |
127.0.0.1은 "이 컴퓨터 자신"을 뜻하는 주소예요. 여기에만 연 도구는 서버 안에서만 닿아요. 포트는 한 서버 안에서 프로그램마다 붙는 방 번호예요.- SSH 포트 포워딩은 SSH 통로를 통해 내 컴퓨터의 포트를 서버의 포트에 잇는 방법이에요. 내 브라우저로 서버 안쪽 방에 들어가는 비밀 복도라고 보면 돼요.
- VPN(Virtual Private Network, 가상 사설망)은 인터넷 위에 우리 기기끼리만 쓰는 사설망을 만드는 도구예요. Tailscale 은 이 사설망을 설치 몇 번으로 만들어 주는 서비스예요.
- 리버스 프록시는 3단계에서 자세히 설명해요. 서브도메인은
app.example.com처럼 도메인 앞에 이름을 붙인 주소예요. - 인증서는 브라우저가 주소창에 자물쇠를 띄우게 해 주는 신분증이에요. 공개 도메인이 있어야 무료로 받기 쉬워요.
- 터널은 서버가 바깥 서비스로 먼저 연결을 열어 두고, 요청을 그 연결로 받아 오는 방식이에요. 서버에 들어오는 문을 따로 열지 않아도 돼요.
어느 것이 정답이라기보다, 여러분이 실제로 매일 쓸 수 있는 것을 고르는 게 중요해요. 저희는 이 표를 세 번 오갔어요.
처음에는 로컬 전용으로 시작했어요. 관리 콘솔을 로그인 폼 하나만 둔 채 공개하는 것보다 SSH 포트 포워딩이 낫다고 봤고, 사설 이름으로 인증서를 받을 방법이 없었기 때문이에요.
그다음 VPN 을 계획했지만 접었어요. 서비스를 많이 띄우면서 포트 번호로 접속하다 보니, 어느 포트가 비었는지 잊는 일이 반복됐어요. VPN 경로로 도구를 열려면 리버스 프록시가 이름을 나눠야 하고, 도구마다 대역 허용 라벨(이 주소 범위에서 온 요청만 받으라는 표시)을 붙여야 했어요. 라벨 하나가 빠지면 그 도구는 공개 주소로 그대로 열려요.
그래서 지금은 모든 도구를 공개 주소에 두고 각자 로그인으로 지켜요. VPN 은 버리지 않고 서버 본체에 둔 채, SSH 와 데이터베이스 직접 접속에만 써요.
웹 도구는 모두 공개 주소와 각자 로그인, VPN 은 SSH 와 데이터베이스에만
참고
VPN 컨테이너 하나로 컨테이너 네트워크 전체를 잇는 방법도 있지만, 저희는 제외했어요. 컨테이너는 프로그램 하나와 그 실행 환경을 묶어 서로 섞이지 않게 돌리는 상자예요. 그 상자들을 통째로 이으면 IP 주소(기기를 찾는 숫자 주소)와 포트로 접속하게 되고, 인증이 없는 내부 서비스와 데이터베이스까지 사설망의 모든 기기에 열려요.
3단계. 공개 앱은 프록시 뒤에 두고 와일드카드 DNS 잡기
공개하기로 한 것들은 리버스 프록시 하나가 받게 해요. 리버스 프록시는 들어온 요청의 호스트 이름(주소창에 적힌 도메인)을 보고 알맞은 컨테이너로 넘겨 주는 문지기예요. 건물 안내 데스크가 방문 층을 듣고 엘리베이터를 알려 주는 것과 같아요. 인증서 발급도 보통 여기서 해요.
DNS(Domain Name System)는 도메인 이름을 서버의 숫자 주소로 바꿔 주는 인터넷의 전화번호부예요. 서비스를 자주 추가한다면 DNS 에 와일드카드 레코드를 하나 두세요. 모든 서브도메인이 같은 서버를 가리키게 하는 레코드예요. 아래 A 레코드는 이름을 숫자 주소에 잇는 가장 기본적인 항목이에요.
; 예시: example.com 의 모든 서브도메인을 한 서버로*.example.com. A <서버 공개 주소>example.com. A <서버 공개 주소>이렇게 해 두면 새 서비스를 올릴 때 DNS 를 건드리지 않아요. 저희는 새 서브도메인마다 배포 도구(컨테이너를 서버에 올리고 교체해 주는 프로그램)의 도메인 칸에 주소 하나를 적는 것으로 끝나요. 리버스 프록시가 그 칸을 보고 라우팅하고 인증서를 받아요.
저희는 DNS 를 Cloudflare 로 옮기면서 프록시도 켰어요. Cloudflare 는 DNS 와 함께, 방문자와 서버 사이에 서서 요청을 대신 받아 주는 프록시를 제공하는 회사예요. 기록에 남은 이유는 WAF(Web Application Firewall, 악성 요청을 거르는 웹 방화벽), 엣지 TLS(Transport Layer Security, 방문자 가까운 곳에서 암호화 연결을 맺어 주는 기능), 접근 정책 같은 기능을 쓸 수 있게 된다는 것이었어요. 대신 리버스 프록시 앞에 프록시가 하나 더 서게 됐고, 이건 4단계에서 다뤄요.
공개 앱까지 터널로 옮길지도 따져 봤지만 그대로 두기로 했어요. 저희가 쓰는 배포 도구의 무중단 배포(새 버전으로 바꾸는 동안에도 서비스가 멈추지 않게 하는 배포)는 리버스 프록시가 새 컨테이너로 트래픽을 넘기는 구조라고 판단했기 때문이에요(Coolify 롤링 업데이트 문서). 옮겨서 얻는 것은 서버 주소를 숨기는 정도였고, 방문자 주소 판별과 로그인 서버의 앞단 설정을 다시 맞추는 위험이 붙었어요.
TIP
같은 서버에 다른 서비스도 돌고 있다면, 웹이 쓰는 공개 80, 443 포트를 닫거나 리버스 프록시 설정을 바꾸는 작업은 입구 계획에서 빼 두세요. 새 입구는 기존 서비스를 건드리지 않고 옆에 더하는 쪽이 되돌리기 쉬워요.
4단계. 앞단 프록시가 늘면 방문자 주소 설정 맞추기
프록시를 하나 더 세우면 앱이 보는 접속 주소는 방문자가 아니라 바로 앞 프록시가 돼요. 택배가 중간 물류센터를 거치면 받는 쪽에는 물류센터 주소만 찍히는 것과 같아요. 진짜 방문자 주소는 X-Forwarded-For 헤더에 담겨 와요. 헤더는 요청 본문 앞에 붙는 꼬리표이고, 이 헤더는 "원래 누가 보냈는지"를 적는 칸이에요. 프록시를 하나 지날 때마다 이 헤더 뒤쪽에 주소가 하나씩 붙는 방식이에요(Cloudflare HTTP 헤더 문서).
문제는 이 헤더를 브라우저도 마음대로 보낼 수 있다는 점이에요. 그래서 맨 앞 값을 믿으면 안 되고, 여러분이 세운 프록시가 붙인 항목만 믿어야 해요. 오른쪽에서 프록시 수만큼 떨어진 항목이 방문자 주소예요.
맨 앞 값은 꾸밀 수 있으니, 믿는 프록시가 붙인 오른쪽 값을 읽어요
저희 웹 앱은 이 규칙을 코드 몇 줄로 둬요. 아래는 그 방식을 일반화한 예시예요.
// 믿을 수 있는 프록시 수(hops)만큼 오른쪽에서 센 항목이 방문자 주소export function clientAddress(headers: Headers, hops: number): string | undefined { if (hops === 0) return undefined const entries = (headers.get("x-forwarded-for") ?? "") .split(",") .map((entry) => entry.trim()) .filter(Boolean) return entries.length >= hops ? entries[entries.length - hops] : undefined}API(Application Programming Interface, 앱이 데이터를 주고받는 창구) 서버가 Express(Node.js 로 웹 서버를 만드는 널리 쓰이는 라이브러리) 기반이라면 trust proxy 설정으로 어떤 프록시의 헤더를 믿을지 정해요. 저희 API 는 이 값을 환경변수(코드 밖에서 프로그램에 넘기는 설정 값)로 받고, 비어 있으면 소켓 주소(실제로 연결을 맺은 상대의 주소)를 그대로 방문자 주소로 써요.
이 값이 틀리면 어떤 일이 생길까요? 비로그인 요청 횟수를 주소별로 제한하는 경우, 모든 방문자가 한 주소로 세어져요. 한 사람이 한도를 다 쓰면 다른 사람까지 막혀요.
TIP
설정을 바꾼 뒤에는 서로 다른 두 네트워크, 예를 들어 집 와이파이와 휴대폰 데이터에서 비로그인 요청을 보내 보세요. 두 요청이 다른 주소로 세어지면 프록시 수가 맞은 거예요.
참고
저희는 앞단 프록시 수를 1 로 두고 배포했지만, 이 값은 아직 실제 요청으로 확인하지 않은 가설이에요. 비로그인 요청 제한이 모두를 한 주소로 세기 시작하면 이 값부터 보기로 해 뒀어요.
5단계. 사람만 쓰는 도구는 터널과 접근 정책으로 잠그기
1단계에서 "사람만 부르는 것"으로 나눈 도구는 한 단계 더 잠글 수 있어요. 핵심 조건은 리버스 프록시에 그 도구의 경로가 아예 없어야 한다는 거예요. 경로가 없으면 누가 서버 공개 주소로 호스트 이름을 속여 보내도 닿을 곳이 없어요.
터널 프로그램을 컨테이너로 띄워 도구 컨테이너로 바로 보내면 이 조건이 저절로 서요. Cloudflare 의 경우 cloudflared 라는 프로그램이 이 역할을 하고, 이 서비스를 Cloudflare Tunnel 이라고 불러요. 설정을 파일로 관리하고 싶다면 로컬 관리형 터널을 쓰면 돼요(로컬 관리형 터널 문서).
# 예시: 호스트 이름 -> 컨테이너 이름:포트tunnel: <터널 ID>credentials-file: /etc/cloudflared/credentials.jsoningress: - hostname: dashboard.example.com service: http://dashboard:3000 - hostname: automation.example.com service: http://automation:8080 - service: http_status:404위에서부터 호스트 이름을 맞춰 보고, 맞으면 오른쪽 컨테이너로 보내요. 마지막 줄은 어느 이름에도 맞지 않는 요청을 404(없는 페이지) 응답으로 돌려보내는 규칙이에요.
그다음 그 호스트 이름 앞에 접근 정책을 걸어요. 접근 정책은 터널 입구에 세운 경비원이고, Cloudflare 에서는 이 기능을 Cloudflare Access 라고 불러요. 가장 단순한 정책은 "이 이메일만 통과"예요(Cloudflare Access 정책 문서). 사람이 아닌 프로그램, 예를 들어 로컬에서 도는 자동화 도구가 이 뒤의 주소를 부른다면 서비스 토큰(사람 대신 프로그램이 들고 다니는 출입증)을 따로 만들어 요청 헤더에 실어 보내야 해요.
마지막으로 배포 도구에서 그 도구의 도메인 칸을 비워, 리버스 프록시 경로를 지워요. 이 순서를 지키면 도구 하나를 다시 공개하고 싶을 때 거꾸로 하면 돼요. 접근 정책에서 빼고 도메인 칸을 다시 채우면 원래대로예요.
저희는 비즈니스 대시보드와 자동화 도구를 이 방식으로 옮길 계획을 세웠어요. 다만 지금은 미뤄 둔 상태예요. 대시보드는 자체 로그인 뒤에서 잘 돌고, 터널이 없어도 동작에 문제가 없기 때문이에요. 대시보드를 외부에서 숨겨야 할 때 다시 꺼내기로 했어요.
참고
에러 추적, 상담, 기능 플래그 도구의 관리 화면까지 접근 정책 뒤에 두려면, 방문자 브라우저가 부르는 수집 경로와 관리 화면의 호스트를 나눠야 해요. 이 작업이 끝나기 전에 통째로 잠그면 수집이 멈추니 주의하세요.
자주 묻는 질문
Q1. VPN 이 불편하면 아예 안 쓰는 게 나을까요?
역할을 좁히면 여전히 쓸모가 있어요. 저희는 웹 도구 접속에서는 VPN 을 뺐지만, SSH 와 데이터베이스 직접 접속에는 계속 써요. 인터넷에 절대 열면 안 되는 것만 VPN 뒤에 두면 매일 켤 일이 줄어요.
Q2. 관리 화면을 각자 로그인만 두고 공개해도 괜찮을까요?
도구 목록이 적고, 도구마다 강한 비밀번호와 가입 제한을 걸 수 있다면 출발점으로는 충분할 수 있어요. 다만 로그인 화면이 인터넷에 보인다는 대가는 남아요. 방문자가 부를 일이 없는 도구부터 5단계 방식으로 옮기는 순서를 추천해요.
Q3. 공개 앱도 터널로 옮기면 서버 주소를 숨길 수 있지 않나요?
숨길 수는 있어요. 하지만 무중단 배포가 리버스 프록시에 기대고 있다면 그 구조를 다시 짜야 하고, 방문자 주소 판별과 로그인 서버 설정도 다시 맞춰야 해요. 얻는 것과 다시 맞출 것을 나란히 적어 보고, 얻는 게 작다면 그대로 두는 게 나아요.
정리
- 도구를 "방문자가 부르는가, 사람만 부르는가"로 먼저 나눠요.
- 입구는 로컬 전용, VPN, 공개와 각자 로그인, 터널과 접근 정책 중 매일 쓸 수 있는 것을 골라요.
- 서비스가 자주 늘면 와일드카드 DNS 하나로 새 서브도메인의 DNS 작업을 없애요.
- 앞단 프록시가 늘면 믿을 프록시 수를 맞추고, 두 네트워크에서 요청을 보내 확인해요.
- 사람만 쓰는 도구는 리버스 프록시 경로를 지우고 터널과 접근 정책 뒤에 둬요.
완벽한 입구보다 되돌리는 법이 분명한 입구가, 서버 한 대로 여러 서비스를 굴리는 팀에게 더 오래 가요.