처음부터 서버 운영 자체가 목적은 아니었다. AI와 IT를 공부하며 생긴 메모를 한곳에 모으고 싶었고, 나중에는 내가 만든 에이전트가 매일 새로운 주제를 찾은 다음, 읽어볼 만한 인사이트를 정리해 주면 좋겠다는 생각도 들었다. 이미 UGREEN DXP2800 NAS를 쓰고 있었고 도메인과 Cloudflare 계정도 마련해 둔 상태였다. 그래서 새 호스팅을 구매하기보다 내 장비와 인프라를 이용해 블로그를 직접 운영해 보기로 했다.
먼저 구조는 아래와 같이 잡았다
구성은 WordPress, MariaDB, Cloudflare Tunnel로 잡았다. WordPress는 글과 화면을 맡고, MariaDB는 데이터를 보관한다. Cloudflare Tunnel은 외부 방문자의 요청을 NAS 안의 WordPress로 전달한다. 공유기에서 80번이나 443번 포트를 직접 열지 않아도 된다는 점이 마음에 들었다.
컨테이너는 Docker Compose로 묶었다. WordPress와 데이터베이스를 따로 실행하되 같은 내부 네트워크에서만 통신하게 했다. 외부에 필요한 것은 블로그 화면뿐이었다. 데이터베이스 포트를 인터넷에 노출할 이유는 없다.
공개 영역과 관리 영역도 나눴다
블로그 본문은 누구나 볼 수 있어야 하지만 관리자 화면까지 같은 방식으로 공개하고 싶지는 않았다. 공개 주소는 Cloudflare Tunnel에 맡기고, WordPress 관리자 화면은 집 안의 네트워크나 Tailscale로 NAS에 연결했을 때만 접근하는 방향으로 정했다.
이 구분은 뒤에서 꽤 중요해졌다. 글을 읽는 경로, 내가 관리하는 경로, Hermes가 참고할 자료를 모으는 경로의 요구가 서로 달랐기 때문이다. 처음부터 완벽하게 설계한 것은 아니었다. 하나씩 작동시켜 보고 불편하거나 위험한 지점을 다시 나눴다.
직접 운영하면 내가 결정할 것이 많다
관리형 블로그라면 신경 쓰지 않아도 될 저장 위치, 권한, 백업, 인증서, 접근 경로를 직접 정해야 했다. 대신 어떤 데이터가 어디에 있고 어떤 서비스가 인터넷에 닿는지 눈으로 확인할 수 있었다. 문제가 생겼을 때 원인을 따라가는 과정도 공부가 됐다.
지금 돌아보면 이 블로그의 첫 번째 결과물은 글이 아니라 구조였다. NAS 안에서는 WordPress와 MariaDB가 역할을 나누고, 외부 공개는 Cloudflare가 맡으며, 관리 작업은 Tailscale 안으로 숨긴다. 다음 글에서는 이 구조를 Docker Compose로 옮기면서 실제로 막혔던 부분을 정리해 보려 한다.