2부에서는 AI의 도움을 받아 Docker를 시작하고, 하나씩 서비스를 만들어가면서 NAS가 단순한 저장장치에서 작은 서버로 바뀌어가는 과정을 적었다.
그런데 서비스를 계속 만들다 보니 새로운 문제가 생겼다.
WordPress가 하나 있고,
또 다른 WordPress가 있고,
Vaultwarden도 있고,
Jellyfin도 있다.
모두 하나의 NAS에서 실행되고 있는데, 사용자는 각 서비스를 어떻게 구분해서 접속해야 할까?
처음에는 이것부터 해결해야 했다.
그래서 이번에는 도메인과 Reverse Proxy를 이용해 하나의 NAS에서 여러 서비스를 나누어 사용하는 과정을 기록해보려고 한다.
서비스마다 주소가 필요했다
집 안에서는 생각보다 간단했다.
NAS의 주소를 알고 있으면 필요한 서비스로 접속할 수 있었다.
그런데 웹사이트를 직접 운영하기 시작하니까 숫자로 된 주소만으로는 뭔가 아쉬웠다.
내가 만든 WordPress 사이트라면 나만 알아볼 수 있는 주소가 아니라,
다른 사람이 봐도 기억하기 쉬운 주소가 필요했다.
그래서 도메인을 연결하기 시작했다.
처음 연결한 도메인은 내가 운영하려는 사이트의 주소로 사용했고,
그다음에는 다른 WordPress에도 별도의 도메인을 사용했다.
이제 문제가 하나 생겼다.
도메인은 서로 다른데 실제 서버는 같은 NAS였다.
한 대의 NAS에서 여러 사이트를 운영할 수 있을까?
처음에는 조금 의아했다.
“같은 NAS인데 어떻게 서로 다른 사이트를 구분하지?”
그런데 여기서 Reverse Proxy라는 개념을 알게 됐다.
쉽게 생각하면 Reverse Proxy는
사용자가 어떤 주소로 들어왔는지를 보고 그 요청을 적절한 서비스로 전달해주는 역할
을 한다.
내가 이해한 구조는 이런 모습이었다.
NAS
│
Reverse Proxy
│
┌─────────┼─────────┐
│ │ │
▼ ▼ ▼
moneyiswater ittsman Vaultwarden
도메인 도메인 도메인
│ │ │
▼ ▼ ▼
WordPress WordPress2 Vaultwarden
실제로 여러 서비스가 하나의 NAS 안에서 동시에 실행되고 있지만,
외부에서는 각각 완전히 다른 서비스처럼 보이게 되는 것이다.
이걸 이해하고 나니 NAS가 훨씬 재미있어졌다.
도메인과 서비스가 연결되기 시작했다
이전까지는 Docker에서 서비스를 만드는 것 자체에 집중했다.
그런데 이제는 그 서비스에 이름을 붙이는 단계로 넘어갔다.
예를 들어 내가 운영하는 WordPress 사이트는
moneyiswater.net
으로 연결하고,
두 번째 WordPress는
ittsman.com
으로 연결했다.
Vaultwarden은 별도의 서브도메인을 사용했다.
이렇게 만들어놓으니 브라우저에서 주소를 입력했을 때 각각 원하는 서비스가 바로 나타났다.
하나의 NAS인데 마치 여러 서버를 사용하는 것처럼 느껴졌다.
DNS라는 것도 이때 제대로 알게 됐다
도메인을 연결하면서 자연스럽게 DNS를 만나게 됐다.
처음에는 DNS를 그냥
“인터넷 주소를 연결해주는 것”
정도로만 생각했다.
그런데 직접 도메인을 연결해보니 DNS 설정 하나에도 여러 가지 방식이 있다는 것을 알게 됐다.
A 레코드가 있고,
CNAME도 있고,
TXT도 있었다.
처음에는 뭐가 뭔지 복잡했다.
하지만 실제로 필요한 설정을 하나씩 적용해보면서 개념을 익혔다.
특히 www 주소를 별도로 연결할 때 CNAME을 사용하는 것도 직접 해보면서 알게 됐다.
www도 따로 설정해야 했다
예를 들어
moneyiswater.net
으로 접속하는 것과
www.moneyiswater.net
으로 접속하는 것은 주소상으로는 다른 호스트였다.
그래서 www 쪽도 별도로 처리해줘야 했다.
결국
moneyiswater.net
│
▼
내 사이트
www.moneyiswater.net
│
▼
moneyiswater.net처럼 연결했다.
처음에는 “왜 www까지 따로 설정해야 하지?”라는 생각이 들었다.
그런데 DNS를 직접 만져보니
내가 보기에는 같은 사이트라도 인터넷에서는 각각 별도의 이름으로 취급될 수 있다는 것
을 알게 됐다.
HTTPS 인증서도 직접 연결했다
웹사이트를 외부에서 사용하려면 HTTPS도 필요했다.
그래서 도메인만 연결하는 것으로 끝나는 것이 아니라 인증서도 함께 구성했다.
처음에는 인증서라는 말도 어렵게 느껴졌다.
하지만 실제로 설정을 진행하면서
도메인이 제대로 연결되어 있는지 확인하고,
인증서를 적용하고,
브라우저에서 HTTPS로 접속해보는 과정을 반복했다.
정상적으로 자물쇠 표시가 나타났을 때는 꽤 뿌듯했다.
내 NAS에서 실행 중인 WordPress가 이제 인터넷에서 정상적인 HTTPS 웹사이트처럼 보이기 시작했기 때문이다.
하나를 만들고 나니 두 번째가 더 쉬워졌다
처음 WordPress를 연결할 때는 신경 쓸 것이 많았다.
도메인 연결부터 DNS,
Reverse Proxy,
HTTPS까지 하나씩 확인해야 했다.
그런데 첫 번째 사이트가 정상적으로 동작하고 나니 두 번째 사이트는 조금 덜 막막했다.
이번에는
“앞에서 했던 구조를 기준으로 새로운 서비스만 연결하면 되겠구나.”
라는 생각을 할 수 있었다.
그래서 두 번째 WordPress도 같은 NAS에서 운영하게 됐다.
NAS 한 대가 여러 서버처럼 느껴졌다
이때부터 NAS를 바라보는 느낌이 조금 달라졌다.
실제로는 NAS 한 대다.
그런데 사용자 입장에서는
moneyiswater.net
↓
사이트 A
ittsman.com
↓
사이트 B
별도의 서브도메인
↓
다른 서비스처럼 각각 독립적인 서비스처럼 사용할 수 있었다.
하나의 하드웨어 안에서 여러 서비스를 분리해서 운영한다는 것이 꽤 재미있었다.
Reverse Proxy를 사용하면서 관리해야 할 것도 늘어났다
물론 편해진 만큼 관리해야 할 것도 생겼다.
도메인이 늘어나면 어느 도메인이 어느 서비스와 연결되어 있는지 기억해야 했다.
어떤 서비스는 WordPress이고,
어떤 서비스는 Vaultwarden이고,
어떤 서비스는 Jellyfin이었다.
그리고 설정을 잘못 건드리면 한 서비스가 정상적으로 접속되지 않을 수도 있었다.
그래서 나중에는 Reverse Proxy 설정을 볼 때
“이 주소는 어디로 연결되는가?”
를 먼저 확인하는 습관이 생겼다.
처음에는 설정 하나하나가 전부 어려웠다
지금 보면 DNS나 Reverse Proxy가 그렇게 복잡해 보이지 않는다.
하지만 처음에는 전부 새로운 개념이었다.
A 레코드가 뭔지,
CNAME은 왜 필요한지,
HTTPS 인증서는 어디에 적용되는지,
Reverse Proxy는 왜 필요한지.
그런데 이것도 결국 Docker를 처음 배울 때와 비슷했다.
모르는 것이 나오면 AI에게 물어봤다.
내가 지금 어떤 구조로 되어 있는지 설명하고,
현재 설정 화면이나 오류 내용을 보여주고,
“이건 왜 이런 거야?”
라고 다시 질문했다.
그러면 그 상황에 맞춰 설명을 들을 수 있었다.
덕분에 단순히 설정을 복사해서 사용하는 것이 아니라
내 환경에서 각각의 설정이 어떤 역할을 하는지 조금씩 이해하게 됐다.
특히 기억에 남았던 것은 ‘연결 하나가 여러 단계라는 것’이었다
예전에는 웹사이트에 접속하는 것이 그냥 주소를 입력하면 되는 일이라고 생각했다.
그런데 직접 서버를 운영해보니 뒤에서는 여러 가지가 움직이고 있었다.
브라우저
↓
도메인
↓
DNS
↓
접속 경로
↓
Reverse Proxy
↓
Docker 서비스
↓
애플리케이션어딘가 하나라도 잘못되면 접속이 되지 않는다.
처음에는 이 구조가 복잡하게 느껴졌다.
하지만 반대로 생각하면 문제가 생겼을 때 어디를 확인해야 하는지도 알 수 있었다.
문제가 생기면 하나씩 거꾸로 확인했다
예를 들어 사이트가 열리지 않는다고 하자.
처음에는 WordPress가 고장났다고 생각하기 쉽다.
하지만 꼭 WordPress가 문제라는 보장은 없다.
DNS가 잘못됐을 수도 있고,
Reverse Proxy 설정이 잘못됐을 수도 있고,
Docker 서비스 자체가 중단됐을 수도 있다.
그래서 나중에는 이런 식으로 확인하게 됐다.
사이트 접속 안 됨
↓
도메인 확인
↓
DNS 확인
↓
Reverse Proxy 확인
↓
Docker 컨테이너 확인
↓
애플리케이션 확인이런 과정을 직접 경험하면서 서버를 운영한다는 것이 조금씩 익숙해졌다.
그리고 한 가지 욕심이 더 생겼다
여러 서비스를 도메인으로 연결해놓으니 처음에는 상당히 만족스러웠다.
그런데 어느 순간 이런 생각이 들었다.
“이 모든 연결을 NAS가 인터넷에서 직접 받아야 할까?”
당시에는 크게 생각하지 않았다.
이미 잘 작동하고 있었기 때문이다.
하지만 서비스를 계속 늘리다 보니 네트워크 구조 자체를 다시 생각해보고 싶어졌다.
특히 Cloudflare를 사용하고 있었기 때문에 다른 방법도 있다는 것을 알게 됐다.
그때부터 Cloudflare Tunnel이라는 기능을 알아보기 시작했다.
기존 방식을 버릴 생각은 처음부터 없었다
중요한 것은 처음부터 모든 것을 다시 만들 계획은 아니었다는 점이다.
기존 Reverse Proxy도 정상적으로 작동했다.
WordPress도 잘 접속됐고,
두 번째 WordPress도 잘 접속됐고,
다른 서비스도 정상적으로 동작했다.
그런데 NAS를 직접 운영하다 보니
“지금보다 더 나은 방법이 있을까?”
라는 생각이 계속 들었다.
결국 기존 환경을 한 번에 뒤집는 것이 아니라 하나씩 테스트하면서 새로운 방식을 적용해보기로 했다.
그리고 그 첫 번째 실험이 Cloudflare Tunnel이었다.
직접 만들어보니 도메인이 단순한 주소가 아니었다
NAS를 처음 사용할 때는 도메인을 그냥 웹사이트 주소라고 생각했다.
하지만 직접 서비스를 연결해보니 도메인은
서비스를 구분하고,
접속 경로를 만들고,
사용자가 원하는 서비스로 연결하는
중요한 역할을 하고 있었다.
하나의 NAS에서 여러 서비스를 운영하려면
“어떤 이름으로 어떤 서비스를 연결할 것인가”
를 정하는 것 자체가 하나의 작업이었다.
NAS를 직접 운영하면서 조금씩 서버다운 구조가 만들어졌다
처음에는 파일을 저장하는 NAS였다.
그다음에는 Docker를 올리고 서비스를 만들었다.
그리고 이제는 각 서비스에 도메인을 연결했다.
이 과정을 거치면서 NAS 안의 구조가 점점 명확해졌다.
DS224+
│
Docker
│
┌──────────┼──────────┐
│ │ │
▼ ▼ ▼
WordPress WordPress2 Vaultwarden
│ │ │
▼ ▼ ▼
moneyiswater ittsman 서브도메인
.net .com
하드웨어는 그대로인데,
내가 사용하는 방법이 계속 발전하고 있었다.
다음에는 인터넷 연결 방식을 다시 바꿔보기로 했다
여기까지 만들고 나니 기본적인 웹서비스 운영은 어느 정도 가능해졌다.
하지만 아직 만족스럽지는 않았다.
“NAS에 직접 인터넷 연결을 만들어놓는 방식 외에 다른 방법은 없을까?”
이 질문에서 결국 Cloudflare Tunnel을 사용하게 됐다.
처음에는 단순히 새로운 기능 하나를 시험해보려고 했다.
하지만 실제로 적용해보니 DNS부터 Tunnel 연결 상태, Docker의 실행 방식까지 확인해야 했고,
예상하지 못했던 오류도 여러 번 만났다.
그리고 그 과정을 거치면서 기존에 사용하던 외부 접속 구조를 하나씩 바꾸게 됐다.
다음 글에서는 Cloudflare Tunnel을 직접 구축하면서 실제로 어떤 문제를 만났고, 어떻게 하나씩 해결했는지 기록해보려고 한다.
NAS를 직접 운영하다 보니,
처음부터 완벽한 구조를 만드는 것보다
문제가 생길 때마다 하나씩 더 나은 구조로 바꿔가는 과정 자체가 구축의 일부라는 생각이 들었다.