안녕하세요, Mark입니다.
오늘은 코드보다 “구조”에 관한 이야기를 해볼게요. 새로 뭘 설치한 편은 아니고, 이미 돌아가고 있던 서비스 하나를 더 안전하게 재배치한 작업이에요.
주인공은 Vaultwarden, 제가 비트워든(Bitwarden) 앱 껍데기로 접속해서 쓰고 있는 자체 호스팅 비밀번호 관리자입니다.
🔓 문제의식: “접속은 되는데 안전한가?”
Vaultwarden을 처음 서버에 올렸을 때, 비트워든 앱에서 자체 호스팅 서버로 접속하려면 주소가 하나 필요했어요. 그래서 자연스럽게 도메인을 연결하고, Nginx Proxy Manager(NPM)로 HTTPS 인증서까지 발급받아서 썼습니다.
문제 없이 잘 돌아갔죠. 그런데 어느 날 곰곰이 생각해보니 이상한 점이 있었어요.
이 도메인 주소를 아는 사람이라면, 전 세계 어디서든 브라우저로 딱 접속하면 Vaultwarden 로그인 화면까지는 도달할 수 있는 구조였던 거예요.
물론 마스터 비밀번호가 없으면 못 뚫습니다. 하지만 문제는 “뚫릴 수 있느냐”가 아니라 “시도라도 할 수 있게 열려 있느냐”였어요. 로그인 화면이 인터넷에 공개되어 있다는 것 자체가, 무차별 대입 공격이든 뭐든 시도할 수 있는 표적이 된다는 뜻이거든요.
그리고 여기서 제가 놓치고 있던 부분을 깨달았어요.
블로그처럼 검색엔진에 노출되어야 하는 서비스와 비밀번호 관리자처럼 저와 제 기기 몇 개만 접근하면 되는 서비스를, 똑같은 방식(공개 도메인 + 공개 SSL 인증서)으로 운영하고 있었다는 거예요.
성격이 완전히 다른 두 서비스를 같은 틀에 욱여넣고 있었던 거죠. 구조적으로 리스크였습니다.
🧭 해결 방법: 모든 걸 통일하지 말고, 분리하기
처음엔 “그럼 방화벽 규칙을 더 촘촘하게 짜야 하나?” 고민했는데, 조사하다 보니 훨씬 간단한 답이 있었어요. 이미 설치해서 쓰고 있던 Tailscale에 tailscale serve라는 내장 기능이 있더라고요.
Tailscale은 여러 기기를 사설 네트워크로 묶어주는 VPN 서비스인데, 이 사설 네트워크 안에서만 접근 가능한 주소로 서비스를 노출시켜주는 게 tailscale serve입니다. 무료 플랜에도 포함되어 있어요.
핵심 명령어는 딱 한 줄이에요.
sudo tailscale serve --bg http://localhost:포트번호
sudo tailscale serve --bg http://localhost:포트번호
이 한 줄이면, Vaultwarden이 Tailscale 네트워크 안에서만 열리는 주소를 갖게 됩니다.
✅ 기존 방식과 뭐가 다른가요?
| 항목 | 기존 방식 (도메인 + NPM) | 전환 후 (tailscale serve) |
|---|---|---|
| 접속 범위 | 도메인만 알면 전 세계 누구나 | Tailscale 로그인된 기기만 |
| HTTPS 인증서 | Let’s Encrypt 직접 발급·자동 갱신 | 자동 발급, 자동 갱신 |
| 도메인 노출 | 검색엔진·DNS에 존재가 드러남 | 인터넷에서 존재 자체를 알 수 없음 |
| 방화벽 설정 | 포트 개방 필요 | 별도 개방 불필요 |
| 설정 난이도 | 도메인 연결 + 인증서 발급 + NPM 설정 | 명령어 한 줄 |
가장 마음에 들었던 부분은 인증서예요. 기존엔 Let’s Encrypt 인증서를 NPM으로 발급받아서 관리했는데, tailscale serve는 공개 인증서 발급 절차 없이도 HTTPS가 자동으로 적용되고 갱신도 완전히 알아서 처리됩니다. 신경 쓸 게 하나 줄어든 거죠.
🔧 실제로 한 작업
작업 자체는 단순했어요.
Vaultwarden이 돌아가는 로컬 포트를 대상으로 tailscale serve --bg 명령어 실행, 기존에 쓰던 공개 도메인(DuckDNS + NPM 프록시 호스트)은 완전히 제거, 비트워든 앱과 브라우저 확장프로그램의 self-hosted 서버 주소를 새로 생긴 Tailscale 전용 주소로 교체.
이게 전부예요. 오라클 클라우드 방화벽이나 다른 서비스(블로그 등)는 건드릴 필요조차 없었어요. Vaultwarden 하나만 콕 집어서 깔끔하게 분리할 수 있었습니다.
💡 얻은 인사이트
작업하면서 느낀 게, “모든 서비스를 하나의 방식으로 통일해서 관리하면 편하다”는 생각이 사실 함정일 수 있다는 거예요.
블로그(mark.it.kr, occultodyssey.com 등)는 검색엔진에 노출되고 아무나 들어와야 하는 서비스니까 공개 도메인 방식이 맞아요. 반면 Vaultwarden처럼 저와 소수 기기만 접근하면 되는 민감한 서비스는, 애초에 “존재 자체를 세상이 모르게” 만드는 게 훨씬 안전하더라고요.
💡 노출되어야 하는 것과 숨겨야 하는 것을 구조적으로 분리하기. 이게 이번 작업의 핵심 교훈이었어요.
✅ 핵심 요약
| 항목 | 내용 |
|---|---|
| 문제 | Vaultwarden이 공개 도메인으로 운영되어 전 세계에서 로그인 화면 접근 가능 |
| 해결 | Tailscale의 tailscale serve로 사설 네트워크 전용 접속으로 전환 |
| 핵심 명령어 | sudo tailscale serve --bg http://localhost:포트번호 |
| 효과 | HTTPS 자동 적용·자동 갱신, 도메인 존재 자체가 인터넷에서 비공개 |
| 교훈 | 모든 서비스 통일보다, 노출/비노출 서비스를 구조적으로 분리하는 게 핵심 |
마치며
비슷한 홈랩을 운영하시는 분이라면, 비밀번호 관리자나 컨테이너 관리 대시보드처럼 민감한 제어판을 하나쯤은 갖고 계실 거예요. 그런 서비스가 있다면 이번처럼 Tailscale 사설 네트워크 안으로 옮기는 걸 추천드려요. 방화벽 규칙 새로 짤 필요 없이, 명령어 한 줄로 끝나거든요.
“비밀번호 관리자 로그인 화면을 전 세계에 공개해두고 있었다는 걸 깨달은 순간, 등골이 서늘했습니다. 이제는 존재 자체를 아무도 모릅니다.” — Mark, 뒤늦게 문 잠근 홈랩 운영자
