[태그:] 별고래-구축기

포트를 하나도 안 열고 — Tailscale로 내 서버에 어디서나 안전 접속

셀프호스팅 구축기 16편. 9편이 방문자를 블로그로 들이는 길(Cloudflare Tunnel)이었다면, 이번엔 나만 내 서버 안으로 들어가는 길이다.

짝이 되는 편: 9편 — 보이지 않는 다리 (Cloudflare Tunnel)

TL;DR (한 화면 요약)

문제: 집 서버에 밖에서, 혹은 다른 방 노트북에서 원격 데스크톱·SSH로 들어가고 싶다. 그런데 포트를 열면 위험하다.
옛 방식: 공유기에 원격 데스크톱 포트를 개방 → 전 세계 봇이 24시간 무차별 로그인 공격.
새 방식: Tailscale — 내 기기들(서버·노트북·폰)을 암호화된 사설망 하나로 묶는다. 공유기 구멍 0개.
안전한 이유: 인터넷에 포트를 하나도 노출 안 함 + 기기 간 종단간 암호화 + 로그인된 내 기기만 입장.
도구: 각 기기에 Tailscale 앱 설치 + 같은 계정으로 로그인. 5분.
비용: 0원 (개인 사용은 기기 100대까지 무료).

1. 풀고 싶은 문제 — 내 서버에 어떻게 들어가나

집에 작은 서버를 한 대 띄워두면 곧 이런 게 필요해진다. 밖에서, 혹은 같은 집 다른 방에서 그 서버에 원격 데스크톱(화면 그대로 보기) 이나 SSH(터미널) 로 들어가고 싶다.

가장 흔한 옛날 방법은 공유기에 포트를 여는 것(포트포워딩)이다. 그런데 이게 골치다.

골치	왜
무차별 공격	원격 데스크톱 포트를 인터넷에 열면, 켜자마자 전 세계 봇이 비밀번호를 찍어본다
비밀번호 한 겹	봇이 뚫으면 서버 전체가 넘어간다. 로그인 하나가 유일한 방어선
위치 노출	공인 IP만 알면 대략적인 동네가 추정된다
갱신 골치	통신사가 공인 IP를 바꾸면 접속 주소도 바뀐다

원격 데스크톱을 인터넷에 직접 여는 건 보안적으로 거의 자살에 가깝다. (앞서 9편에서 방문자용 트래픽을 다뤘다면, 이건 관리자인 나만 쓰는 통로라 더 민감하다.)

2. 다른 발상 — 포트를 열지 말고, 기기끼리 사설망

발상의 전환은 이렇다. 외부에서 서버로 들어오는 문을 열지 말자. 대신 내 기기들끼리만 통하는 암호화된 사설망을 따로 만들자.

이걸 해주는 게 Tailscale이다. 핵심 엔진은 WireGuard(현대적이고 빠른 암호화 터널 기술) 이고, Tailscale은 그 WireGuard 터널들을 설정 없이 자동으로 깔아주는 앱이다.

설치하면 내 기기들이 한 사설망(테일넷)에 묶이고, 각 기기는 100.x.x.x 형태의 사설 주소를 받는다. 이 주소는 인터넷엔 안 보이고, 내 기기끼리만 통한다. 멀리 떨어져 있어도 같은 방 랜선처럼 연결된다.

3. 어떻게 안전한가 — 소개팅과 통화

Tailscale의 가장 영리한 설계는 조정(control)과 데이터(data)를 분리한 것이다. 소개팅 주선자에 빗대면 쉽다.

조정 서버 = 소개팅 주선자: Tailscale 본사 서버가 기기들을 인증하고 서로를 소개시킨다. “이 둘은 같은 주인 거니까 연결해도 돼” 하고 공개키를 나눠준다. 하지만 실제 대화 내용은 절대 듣지 않는다.
데이터 = 실제 통화: 원격 데스크톱 화면 같은 진짜 트래픽은 기기끼리 직접(P2P), WireGuard로 종단간 암호화되어 흐른다. 본사 서버를 거치지 않는다.

여기서 나오는 세 겹의 보안:

보안 장치	내용
포트 0개 노출	서버의 원격 데스크톱 포트가 인터넷엔 존재조차 안 보인다. 스캐너가 찾을 표적이 없다
종단간 암호화	기기 간 모든 통신을 WireGuard가 암호화. 중간에서 가로채도 못 읽는다
신분 기반 입장	공유 비밀번호가 아니라, 내 계정으로 로그인한 기기만 사설망에 들어온다. 잃어버린 기기는 콘솔에서 즉시 차단

개인키(각 기기의 비밀 열쇠)는 그 기기를 절대 떠나지 않는다. 본사 서버엔 공개키만 올라가므로, 설령 본사가 털려도 내 트래픽은 못 푼다.

4. 트래픽 흐름 — 옛 방식과 비교

옛 방식은 공유기에 구멍을 뚫어 누구나 두드릴 수 있게 한다. 새 방식은 내 기기끼리 암호화 터널을 직접 잇고, 외부엔 아무 문도 열지 않는다.

5. Cloudflare Tunnel과 뭐가 다른가 — 공개용 vs 나만의

9편의 Cloudflare Tunnel과 헷갈리기 쉽다. 둘은 경쟁이 아니라 역할이 다른 보완재다.

	Cloudflare Tunnel (9편)	Tailscale (이번 편)
목적	방문자에게 블로그를 공개	나만 서버에 비공개 접속
대상	전 세계 누구나 (https)	내 로그인된 기기만
쓰는 곳	블로그·웹사이트 공개	원격 데스크톱·SSH·관리
비유	호텔 프론트데스크(손님 안내)	직원만 아는 뒷통로

블로그는 Cloudflare Tunnel로 세상에 열고, 그 서버를 관리할 땐 Tailscale로 나만 들어간다. 한 서버에 둘을 같이 써도 전혀 충돌하지 않는다.

6. 쓰는 법 — 5분

개념은 단순하다. 접속하려는 모든 기기에 앱을 깔고, 같은 계정으로 로그인하면 끝.

서버(예: 리눅스 미니PC)에 Tailscale 설치 → 로그인
내 노트북·폰에도 Tailscale 앱 설치 → 같은 계정 로그인
이제 모든 기기가 한 사설망에 묶이고, 각자 100.x.x.x 주소를 받는다
원격 데스크톱·SSH는 그 서버의 Tailscale 주소로 접속한다

MagicDNS를 켜면 주소 대신 기기 이름으로도 접속된다 (예: myserver → 그 기기). 이 사설 주소는 한 번 정해지면 안 바뀌어서, 즐겨찾기처럼 계속 쓸 수 있다.

7. 함정 — 우리가 실제로 만난 것

함정 1. 내부망 IP로 접속하면 막힌다

같은 집 안 기기는 두 개의 주소를 가진다 — 공유기가 준 내부망 IP(192.168.x.x)와 Tailscale이 준 사설 주소(100.x.x.x). 서버 방화벽을 ‘안전하게’ 잠가서 Tailscale 통로만 허용해두면, 내부망 IP로 접속할 땐 방화벽이 막아버린다.

증상이 고약하다. ping도 되고 SSH(22)도 되는데 원격 데스크톱만 안 된다 — 방화벽이 그 포트만 막고 있어서다. 같은 집이라도 Tailscale 주소로 접속해야 한다. 이걸 모르고 “집 안에서도 안 되네?” 하며 한참 헤맸다. (저장된 접속 주소가 내부망 IP로 되어 있던 게 범인이었다.)

함정 2. 양쪽 다 켜져 있어야 한다

Tailscale은 양쪽 기기에 다 떠 있어야 연결된다. 노트북에서 Tailscale이 로그아웃돼 있으면 당연히 사설망에 없어서 접속이 안 된다. 보통 부팅 시 자동 실행되지만, 안 될 땐 이걸 먼저 의심한다.

함정 3. 오래 안 켠 기기는 오프라인으로 빠진다

한동안 안 켠 폰 같은 기기는 콘솔에서 “오프라인”으로 표시된다. 다시 켜고 로그인하면 복귀한다. 기기 목록을 가끔 정리해주면 좋다.

8. 검증

연결됐는지 확인하는 가장 빠른 방법은 두 가지다 (양쪽 기기에서 Tailscale을 켠 상태에서).

① 서버의 사설 주소가 살아있나 — ping <서버의 Tailscale 주소> 로 응답을 본다.

② 목표 포트가 실제로 도달되나 — 윈도우라면 PowerShell에서:

Test-NetConnection -ComputerName <서버 Tailscale 주소> -Port <포트>

TcpTestSucceeded : True가 뜨면 사설망 터널이 정상이다. 이제 그 주소로 원격 데스크톱·SSH를 붙이면 된다.

FAQ

Q. Cloudflare Tunnel이랑 같이 써도 되나?
된다. 역할이 다르다. 블로그는 Cloudflare Tunnel로 공개하고, 서버 관리(원격 데스크톱·SSH)는 Tailscale로 한다. 충돌 없다.

Q. 무료 한도는?
개인 플랜으로 기기 100대·사용자 3명까지 무료다. 집 서버 몇 대 묶는 용도엔 평생 무료로 충분하다.

Q. Tailscale 회사가 내 트래픽을 보나?
못 본다. 본사 서버는 소개만 하고, 실제 데이터는 기기끼리 직접 암호화로 흐른다. (직접 연결이 막힌 까다로운 망에서는 암호화된 중계 서버를 거치는데, 그때도 양 끝에서만 복호화되어 중계 서버는 내용을 못 본다.)

Q. 전기·인터넷이 끊기면?
서버가 꺼지면 사설망에서 빠진다. 다시 켜지면 자동 복귀한다. 사설망 자체는 내 계정에 묶여 있어 그대로 유지된다.

Q. 회사에서도 쓰나?
쓴다. “제로 트러스트(아무것도 기본 신뢰하지 않음)” 사내망 접속 방식으로 기업에서도 널리 쓰인다. 개인 홈랩에 같은 원리를 공짜로 적용하는 셈이다.

한 줄 정리

집 서버에 어디서나 들어가려면, 공유기에 포트를 열어 봇 공격을 자초하는 옛 방식 대신, 내 기기들만 묶는 암호화 사설망을 만드는 Tailscale이 깔끔하다. WireGuard로 종단간 암호화하고, 인터넷엔 포트를 하나도 안 연다. 설치는 각 기기에 앱 깔고 같은 계정 로그인, 5분.

참고

2026-06-06

이름이 어렵다 — 사이트명 정하기

셀프호스팅 구축기 7편. 도메인보다 사이트명이 더 어렵다.

← 이전 편: 6편 — 도메인 사기: Cloudflare Registrar

요약

처음 이름 “잼잼의 항해일기” → 사흘 만에 “별고래”로 교체
도메인(sticknstone.org)과 브랜드명(별고래)이 달라도 OK. About 페이지에서 풀면 됨
영문 부제 “Star Whale” 병기 → 글로벌 검색 친화
1인 블로그 네이밍 5기준: 차별·메타포 깊이·기억성·도메인 충돌·영어 발음

1. “잼잼의 항해일기”의 문제

처음 정한 이름. jamjam과 “항해일기”의 조합. 사흘 동안 글 위치 정하면서 5가지가 거슬렸다.

거슬린 것	이유
너무 일상적	“공부·트레이딩·자동화” 같은 객관 콘텐츠와 톤 충돌
닉네임 노출	jamjam이라는 닉이 사이트 정체성보다 본인 정체성
모방 가능	“OO의 항해일기” 같은 블로그 너무 많음. 검색 노출 약함
영문 변환 어려움	“jamjam’s voyage diary” — 이상함
시야 좁음	“일기”는 개인 일기장. 외부 독자가 보기엔 너무 사적

2. 새 이름 후보들

새 사이트명 후보 5개를 비교했다.

이름	의미	차별	메타포	기억	영문
잼잼의 항해일기	내 일기	★	★★	★★★	★
firewhale	불 + 고래 (강렬함 + 깊이)	★★	★★★	★★★	★★★★
별고래	별 + 고래 (탐험·깊이)	★★★★★	★★★★★	★★★★	★★
한 평짜리 서재	1인 작업실	★★★	★★★	★★★	★
항해사의 자료실	정보 모음소	★★	★★	★★	★

별고래가 차별·메타포에서 가장 앞섬. 영문은 약하지만 부제 “Star Whale”로 보완 가능.

3. 별고래의 메타포 깊이


“별고래는 별을 향해 가는 깊은 항해” — 톤·콘텐츠 방향·블로그 정체성을 한 문장에 담음. 내 학습 노트는 “차분히 멀리” 가는 게 핵심이라 fit.

별은 방향, 고래는 깊이를 뜻한다. 빠르게 소비되고 사라지는 정보 대신, 한 주제를 오래 파고들어 멀리 가겠다는 태도다. 트레이딩·학습·자동화처럼 길게 누적해야 의미가 생기는 주제와 잘 맞물린다. 이름 하나에 그 방향을 담아두면, 글을 쓸 때마다 “이게 별고래다운가?”라는 편집 기준이 생긴다.

4. firewhale 탈락 — SEO 충돌

“불 + 고래” = 불의 강렬함 + 고래의 깊이. 좋아 보이지만 검색해보니:

점유자	무엇
firewhale.io	iOS 앱 개발사 (음악 앱 다수)
firewhale.org	Notable Publications
firewhalemusic.com	음악 아티스트
Firewhale (FIREW)	암호화폐 토큰
GitHub FireWhale	개인 계정

신규 사이트가 firewhale로 시작하면 영원히 묻힘.

별고래는 검색해보면 거의 깨끗하다.
SEO·GEO 노출 측면에서 유리하다 판단했다

5. 영문 부제 “Star Whale”

한국어 메인 + 영문 부제. WordPress 설정:

Site Title:    별고래
Tagline:       Star Whale — Self-hosted notes on learning, trading, automation

장점:
– 한국 검색: “별고래” 깨끗하게 1위
– 영문 검색: “Star Whale” 부분이 영문 노출
– 명함·SNS 자기소개: “별고래 (Star Whale)” 자연스러움
– 글로벌 확장 시 부담 X

Starwhale 한 단어는 starwhale.ai라는 ML 회사 있음. 나는 Star Whale 두 단어로 분리하면 무관 (브랜드 인접성만 약간).

6. 도메인과 사이트명 불일치 — 괜찮은가

도메인	사이트명	사례
`google.com`	Google	일치
`meta.com`	Meta	일치
`medium.com`	Medium	일치
`stripe.com`	Stripe	일치
`sticknstone.org`	별고래	불일치

일반론은 일치해야하나 나는 의도적 분리했다.

왜 분리해도 괜찮은가:
– About 페이지에서 한 줄로 풀면 자연스러움
– “Stick & Stone = 옛 항해사가 별을 가리키던 돌·막대 기구” → “별고래 = 그 별을 향한 깊은 항해” → 스토리텔링 자산
– URL을 외우게 하려는 게 아니라 검색해서 들어오게 하는 사이트라 도메인-브랜드 일치는 부차

기업 사이트라면 일치가 맞다. 개인 학습 노트 블로그는 다르다.

7. 변경 작업 — wp-cli 한 줄

wp option update blogname "별고래" --allow-root
wp option update blogdescription "Star Whale — Self-hosted notes on learning, trading, automation" --allow-root

이게 끝. 추가로 갱신해야 하는 것:
– llms.txt 한 줄 (# 별고래 (Star Whale))
– About 페이지 (스토리텔링)
– OG 태그 (Rank Math 자동)
– 메일 발신자 이름 (UpdraftPlus 알림 등, 자동 따라옴)

FAQ

Q. 이름 한 번 정하면 못 바꾸나?
바꿀 수 있음. 단 일찍 바꿀수록 비용 0. 발행 글 100편 후 바꾸면 외부 링크·소셜·검색 인덱스 전부 손봐야 함.

Q. 영문 부제는 필수?
한국어만으로도 가능. 단 영문 부제 = 글로벌 검색 친화 + 명함 자연스러움. 5분 작업 대비 이득 크다.

Q. “별고래” 같은 합성 한국어가 외국인에게 어렵지 않나?
어려움. 그래서 영문 부제. 내 메인 독자는 한국인이라 우선순위는 한국어.

Q. 트레이드마크 등록해야 하나?
1인 블로그라면 불필요. 외부 사용자가 별고래 이름으로 상품·서비스 만들 가능성은 없다 봐야한다. 콘텐츠 누적 + 수익화 시점에 재검토.

Q. 사이트명 결정 못해서 발행 미루고 있는데?
임시명으로 발행 시작. 콘텐츠가 우선. 이름은 콘텐츠 5편 정도 쓰면 자연스럽게 굳어짐.

다음 편 예고

8편 — 24시간 안에 봇이 온다: 도메인 공개 전 보안 P0. xmlrpc 차단 + wp-login 슬러그 변경 = 25분 작업으로 brute force 99% 차단.

한 줄 정리

사이트명은 도메인보다 어렵다. 생각보다 예민한 주제.
별고래는 차별·메타포·검색 노출 5기준에서 다른 것보다 유리하기에 채택했다. 한국어 메인 + 영문 부제(Star Whale) + About 페이지 스토리텔링으로 도메인 불일치 보완하려한다.

2026-05-30

24시간 안에 봇이 온다 — 도메인 공개 전 보안 P0

셀프호스팅 구축기 8편. 도메인 띄우기 전에 반드시 끝내야 하는 25분.

TL;DR

WordPress 도메인 공개 = 24시간 안에 brute force 봇이 옴. 통계적 사실
25분 작업으로 99% 차단: ① 사용자명 admin 회피 ② xmlrpc 차단 ③ wp-login 슬러그 변경
이 셋이 보안 P0. 도메인 띄우기 전에 끝낸다
Wordfence·2FA는 P1 (도메인 띄운 후 추가)

1. 첫 24시간의 진실

WordPress 사이트가 인터넷에 노출되면 첫 24시간 안에:

공격	빈도	대상
`/wp-login.php` brute force	시간당 수천 회	관리자 비번
`/xmlrpc.php` pingback amp	끊임없음	DDoS 증폭
알려진 플러그인 취약점 스캔	끊임없음	옛 버전 플러그인
SQL injection 시도	자동 봇	`?id=1 OR 1=1` URL
User enum (`?author=1`)	자동 봇	사용자명 알아내기

이걸 막을 게 아니라 표면 자체를 없애는 게 P0.

2. P0 — 보안 3종 셋업

3. ① 사용자명 admin 회피

WordPress 설치 마법사가 첫 사용자 만들 때 admin이라고 입력하지 마세요. 봇 brute force 1순위 타겟.

좋은 예: jamjam, sailor904, 본인 닉
나쁜 예: admin, administrator, root, wpadmin

이미 admin으로 만들었으면 wp-cli로 새 사용자 생성 후 admin 권한 박탈 또는 삭제:

wp user create newname [email protected] --role=administrator --user_pass=$(openssl rand -base64 24) --allow-root
wp user delete admin --reassign=newname --allow-root

4. ② xmlrpc.php 차단 — mu-plugin

/xmlrpc.php는 WordPress 옛 API. 거의 안 쓰임 (Jetpack 사용자만). 봇이 brute force amplification (한 번 요청으로 비번 1000개 시도)에 악용.

/var/www/html/wp-content/mu-plugins/disable-xmlrpc.php:

<?php
/**
 * Plugin Name: Disable XML-RPC
 * Description: Block xmlrpc.php to reduce attack surface.
 */
if (!defined('ABSPATH')) exit;

add_filter('xmlrpc_enabled', '__return_false');
add_filter('wp_headers', function ($headers) {
    unset($headers['X-Pingback']);
    return $headers;
});
add_filter('xmlrpc_methods', function ($methods) {
    unset($methods['pingback.ping']);
    unset($methods['pingback.extensions.getPingbacks']);
    return $methods;
});
add_action('init', function () {
    $uri = $_SERVER['REQUEST_URI'] ?? '';
    if (stripos($uri, '/xmlrpc.php') !== false) {
        status_header(403);
        exit('xmlrpc disabled');
    }
});

검증:

curl -I http://localhost:8090/xmlrpc.php
# HTTP/1.1 403  ← 성공

5. ③ wp-login 슬러그 변경

/wp-login.php는 모든 WordPress 사이트가 똑같이 갖는 로그인 URL. 봇이 처음 들어와서 자동으로 칠 URL. 이걸 다른 슬러그로 숨김.

플러그인 wps-hide-login 설치:

wp plugin install wps-hide-login --activate --allow-root
wp option update whl_page starport --allow-root

starport는 사장님이 정한 비밀 슬러그. 추측 어려운 단어 + 본인 기억하기 쉬운 거. 예: byeolgorae-gate, secret-door-2026, starport.

검증:

curl -I -L http://localhost:8090/wp-login.php
# 301 redirect → 가짜 URL (봇 헛걸음)

curl -I -L http://localhost:8090/wp-admin/
# 404 (로그아웃 상태에선 admin 페이지 자체가 없는 척)

curl -I -L http://localhost:8090/starport/
# 200 (사장님만 아는 로그인 페이지)

⚠ 사장님이 슬러그 잊으면 본인도 못 들어옴. 즐겨찾기·메모 필수.

6. 결과 — 봇 입장에서

공격	차단 후 응답
`GET /wp-login.php`	301 → 가짜 URL → 봇이 거기서 시도 → 영원히 실패
`POST /xmlrpc.php`	403 즉시 차단. amplification 불가
`GET /wp-admin/`	404. 관리 페이지 자체가 없는 척
사용자명 brute force	`admin` 시도 → 우리 사이트엔 admin 없음
`?author=1` user enum	Rank Math가 자동 차단 (`Disable Author Archives`)

봇이 들이는 자원 = 사장님 사이트에서 얻는 게 0.

7. P0 vs P1 vs P2 — 우선순위

단계	작업	시점
P0 (필수, 도메인 공개 전)	사용자명·xmlrpc·wp-login 슬러그	이번 25분
P1 (도메인 띄운 직후)	Wordfence 위자드 + 2FA	사장님 GUI 작업
P2 (월 1회)	플러그인 보안 업데이트 + WPA(취약점 스캔)	운영 단계

P0 안 끝내고 도메인 띄우면 — 봇이 24시간 안에 와서 brute force 시작. 셋업 안 됐어도 어차피 못 뚫지만, 로그에 brute force 시도가 쌓이고 미니PC CPU 잡아먹음. 미리 막는 게 정신 위생.

8. 함정

함정 1. mu-plugin 자동 활성

mu-plugins는 일반 플러그인 위에서 강제 실행 (mu = Must Use). 따라서 xmlrpc 차단처럼 절대 비활성되면 안 되는 보안 정책은 mu-plugin이 맞는 곳.

함정 2. WPS Hide Login slug 잊기

whl_page 옵션을 DB에 직접 박아두기 때문에, 사장님이 슬러그 잊으면 본인도 못 들어옴. 복구 방법: wp option get whl_page --allow-root (미니PC SSH로) 또는 mu-plugin 임시 비활성.

함정 3. 인증 후 자동 우회

WPS Hide Login은 슬러그를 모르는 사람만 차단. 로그인된 세션은 그대로 /wp-admin/ 사용. 사장님이 한 번 로그인하면 그 이후 30분 동안 admin 페이지 자유.

함정 4. 로그아웃 시 새 슬러그로 진입

사장님이 로그아웃하면 다음 로그인은 /starport로. 즐겨찾기 갱신 필수.

FAQ

Q. 이미 도메인 공개해버렸는데 P0 안 했으면?
지금 즉시 cloudflared 끄거나 Tailscale Funnel 해제 → P0 셋업 → 다시 공개. 5분.

Q. Wordfence 위자드(P1)는 왜 P0 아닌가?
P0는 표면 자체를 없애는 것. Wordfence는 표면이 있는 상태에서 공격을 탐지·차단. 보완재.

Q. 슬러그를 /admin 으로 바꿔도 되나?
/admin도 봇이 시도하는 흔한 슬러그. 추천 X. 본인만 떠올릴 수 있는 + 추측 어려운 단어.

Q. 2FA 없어도 P0면 충분한가?
충분 + 충분. 2FA는 비번 노출됐을 때 마지막 방패. P0 + 2FA = 사실상 무적.

Q. xmlrpc 차단하면 Jetpack 못 쓰나?
Jetpack 일부 기능 X. Jetpack 자체가 없으면 무관. 우리 별고래는 Jetpack 안 씀.

다음 편 예고

9편 — 보이지 않는 다리: Cloudflare Tunnel. 드디어 도메인을 미니PC에 연결. 공유기 포트 안 열고, 미니PC IP 안 들키고, WAF·DDoS·CDN까지 무료로.

한 줄 정리

WordPress 도메인 공개 = 24시간 안에 봇이 옴. 25분 P0 셋업(사용자명·xmlrpc·wp-login 슬러그)으로 99% 차단. 도메인 띄우기 전에 끝낸다.

2026-05-30

보이지 않는 다리 — Cloudflare Tunnel로 우리집 블로그 외부 노출하기

셀프호스팅 구축기 9편. 도메인 산 다음, 우리집 컴퓨터까지 트래픽을 어떻게 끌어오나.

← 이전 편: 8편 — 24시간 안에 봇이 온다 (보안 P0)
→ 다음 편: 10편 — 블로그에 뭘 쓰면 안 되나 (개인정보 검열)

TL;DR (한 화면 요약)

문제: 우리집 미니PC에 WordPress를 띄웠는데, 산 도메인(sticknstone.org)을 외부에서 어떻게 연결하나
옛 방식: 공유기 포트 열기 → 공인 IP DNS 등록 → SSL 갱신. 5가지 골치
새 방식: Cloudflare Tunnel — 미니PC가 Cloudflare에 outbound로 다리를 미리 놓는다. 공유기 구멍 X, IP 노출 X
도구: cloudflared 데몬을 Docker로 가동. 5분
공짜 보너스: WAF·DDoS·CDN·SSL·트래픽 통계 전부 무료
비용: 0원 (도메인 갱신비 연 $10 별도)

1. 풀고 싶은 문제

블로그(WordPress)는 우리집 미니PC에 띄워뒀다. 도메인(sticknstone.org)도 샀다. 그런데 이 둘이 어떻게 만나야 하나?

평범한 길 (포트포워딩) 5가지 골치

골치	왜
공유기 구멍	443번 포트 외부에 열면 평생 봇 공격
공유 IP	통신사가 매번 바꿈. 자동 갱신 스크립트 필요
우리집 위치 노출	IP만 알면 대략적 동네 추정 가능
SSL 갱신	매 90일마다 Let’s Encrypt 직접
트래픽 폭주	DDoS 맞으면 우리집 인터넷 마비

2. 다른 길: 다리를 놓는다

발상의 전환: 외부에서 우리집으로 들어오는 연결을 받지 말자. 대신 우리집에서 외부 어딘가로 나가는 연결을 미리 만들어두자.

flowchart LR
    subgraph oldway["옛 방식 — 포트포워딩"]
        A1[방문자] --> A2[공유기 포트 443 오픈]
        A2 --> A3[미니PC 공개 IP]
        A3 --> A4[WordPress]
        A5[해커] -.공격.-> A2
    end
    subgraph newway["새 방식 — Cloudflare Tunnel"]
        B1[방문자] --> B2[Cloudflare 서울 DC]
        B2 -. 미리 열린 outbound 채널 .-> B3[미니PC cloudflared]
        B3 --> B4[WordPress]
        B5[해커] -.차단.-> B2
    end
    style A5 fill:#fdd,stroke:#a00
    style B5 fill:#dfd,stroke:#0a0
    style A3 fill:#fdd
    style B3 fill:#dfd

핵심: 미니PC가 먼저 손을 뻗는다. 외부 → 우리집 흐름이 아니라, 우리집 → Cloudflare로 outbound 연결을 늘 열어둔다. 방문자 요청은 Cloudflare가 이 채널로 미니PC에 던진다.

호텔 비유

호텔 손님(미니PC)이 친구를 만나고 싶을 때.

평범한 길: 호텔 입구에 자기 방 번호를 크게 써붙임. 친구는 그 번호로 들어옴. 동시에 도둑도 옴.
다리의 길: 호텔 프론트데스크(Cloudflare)에 미리 메모를 남긴다. 내 친구 찾는 사람 있으면 객실로 연결해달라고. 친구는 이름만 대고, 프론트데스크가 안내한다. 방 번호는 외부 노출 X. 의심스러운 사람은 1차로 거른다.

3. 트래픽 흐름 — 방문자가 도메인 칠 때

sequenceDiagram
    participant V as 방문자 브라우저
    participant CF as Cloudflare 서울 DC
    participant CD as cloudflared (미니PC)
    participant WP as WordPress 컨테이너
    V->>CF: GET https://sticknstone.org
    Note over CF: WAF·DDoS 1차 필터
    CF->>CD: 미리 열린 outbound 채널로 forward
    CD->>WP: http://localhost:8090
    WP-->>CD: HTML 응답
    CD-->>CF: outbound 채널 회신
    CF-->>V: SSL 종단·CDN 캐시 + 응답

4단계: 방문자 → Cloudflare(필터) → 다리 → 미니PC → 역순. 미니PC IP는 어디에도 안 등장.

4. 다리지기: cloudflared

이 outbound 채널을 우리집에서 유지하는 작은 데몬이 cloudflared — Cloudflare 공식 오픈소스.

왜 Docker로 띄우나

미니PC에 이미 Docker가 돌고 있다. 다른 컨테이너들과 같은 호텔에 묵는 게 자연스럽다.

flowchart TB
    subgraph minipc["미니PC (Ubuntu 24.04)"]
        subgraph docker["Docker 호스트"]
            CD[cloudflared / network_mode host]
            WP[wordpress-wordpress-1 :8090]
            DB[(wordpress-db-1 MariaDB)]
            RD[(wordpress-redis-1 Object Cache)]
            UM[umami_umami-1 :3001]
            UDB[(umami_db-1 Postgres)]
        end
        WP --> DB
        WP --> RD
        UM --> UDB
    end
    CF[Cloudflare 네트워크] -. outbound .-> CD
    CD --> WP
    CD --> UM
    style CD fill:#ffe4b5,stroke:#d97706
    style CF fill:#dbeafe,stroke:#1d4ed8

cloudflared만 network_mode: host로 띄워서 호스트의 localhost:8090(WP)와 localhost:3001(Umami)에 접근하게 한다.

설치 5분 가이드

폴더 + 설정 파일:

/home/user/cloudflared/
├── .env                # TUNNEL_TOKEN=eyJh... (Cloudflare 대시보드에서 받은 토큰)
└── docker-compose.yml

docker-compose.yml:

services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared
    restart: unless-stopped
    network_mode: host
    command: tunnel --no-autoupdate run --token ${TUNNEL_TOKEN}
    env_file: .env

가동 + 로그 검증:

cd /home/user/cloudflared
sudo docker compose up -d
sudo docker logs cloudflared --tail 20

성공 로그에 다음 4줄이 보인다 (Cloudflare 서울 데이터센터 4곳 동시 연결):

Registered tunnel connection ... location=icn06 protocol=quic
Registered tunnel connection ... location=icn01 protocol=quic
Registered tunnel connection ... location=icn05 protocol=quic
Registered tunnel connection ... location=icn06 protocol=quic

미니PC는 4중 백업 채널로 Cloudflare에 연결된다. 한 채널이 죽어도 나머지 3개가 살아있다.

5. 토큰은 위험하다 — 어디 두나

cloudflared가 Cloudflare에 자기를 증명할 때 쓰는 토큰. 발급 시 한 번 보여주고 끝.

토큰 다루기 원칙

.env 파일에 평문 저장. 권한 chmod 600 (소유자만 읽기·쓰기)
채팅·노트·git 커밋에 절대 평문 X
토큰 노출 의심 시 즉시 Cloudflare 대시보드에서 revoke + 재발급

정확한 명령

sudo chown user:user /home/user/cloudflared/.env
sudo chmod 600 /home/user/cloudflared/.env

6. 공짜로 따라오는 것

Cloudflare 무료 플랜으로 이 다리만 놓아도 따라오는 보너스:

보너스	설명	평소 가격대
WAF (웹 방화벽)	SQL injection·XSS 알려진 공격 자동 차단	월 $20~
DDoS 보호	트래픽 폭주 자동 흡수, 무제한	월 $200~
CDN	정적 파일 전 세계 캐싱. 외국 방문자도 빠르게	월 $10~
SSL 자동	Let’s Encrypt 갱신 신경 0	월 $5~
트래픽 통계	Cloudflare 대시보드에서 그래프로	(분석 도구)

총합 비용: 0원. 도메인 갱신비 연 $10만.

7. 함정 — 우리가 실제로 만난 것

함정 1. Operating System 선택 헷갈림

Cloudflare 대시보드의 cloudflared 설치 명령 화면에서 OS를 골라야 한다. 처음에는 자기 윈도우 PC가 OS인 줄 알고 Windows를 골랐다. 틀렸다. cloudflared가 설치되는 곳은 미니PC(Ubuntu)지 내 윈도우가 아니다. Docker를 골랐어야 한다.

함정 2. 토큰을 LLM 채팅에 그대로 붙여넣음

복사한 토큰을 LLM 채팅에 보내면 그 채팅 내용은 외부 서버에 저장된다. 토큰은 카드 비밀번호급 민감 정보. 작업 끝나면 즉시 Cloudflare 대시보드에서 토큰 회수 권장.

함정 3. cloudflared가 어떻게 다른 서비스에 forward하나

cloudflared 컨테이너만 띄우면 Cloudflare와 연결은 되지만, 들어온 요청을 어디로 보낼지는 별도 설정이다. Public Hostname 설정이라고 한다. 다음 편(10편)에서 다룬다.

8. 검증

가동 직후 Cloudflare 대시보드의 Tunnel 페이지 하단 Connection Status를 본다.

Before:  No connection detected yet
After:   Connected (체크)

이 한 줄이 바뀌면 다리가 놓인 것이다.

FAQ

Q. Tailscale Funnel과 무엇이 다른가?
둘 다 NAT 우회 + 미니PC IP 비공개라는 점은 같다. Cloudflare Tunnel은 WAF·DDoS·CDN·자기 도메인 사용까지 무료로 묶어준다. Tailscale Funnel은 전용 도메인 강제 + 보호막 없음. 블로그용은 Cloudflare가 우위.

Q. 미니PC가 꺼지면 어떻게 되나?
다리가 끊긴다. 방문자는 Cloudflare에서 521(Web server is down) 에러를 본다. 미니PC가 다시 켜지면 cloudflared가 자동으로 다리를 재연결한다 (Docker restart: unless-stopped).

Q. Cloudflare가 트래픽을 보나? 개인정보 우려?
Cloudflare는 SSL을 자기가 종단한다 = 평문 트래픽을 본다. 신뢰 모델은 Cloudflare는 내 편이라는 가정. 신뢰 못 하면 적합 X (대안: 자체 reverse proxy + Let’s Encrypt + dynamic DNS).

Q. 무료 플랜 한계는?
대역폭 무제한, 사이트 수 무제한, Tunnel 수 무제한. 단 Cloudflare Workers·R2 같은 부가 서비스에 별도 한도. 블로그 1개 운영엔 무료 플랜이 평생 충분.

Q. 도메인이 .org가 아니어도 되나?
무관. .com / .net / .io / .dev 모두 동일하게 작동. 단 도메인이 Cloudflare DNS를 쓰는 게 가장 쉬움 (자동 DNS 등록).

다음 편 예고

10편에서는 Public Hostname을 설정해 sticknstone.org → WordPress로 매핑하고, 글에 무엇을 쓰면 안 되는지(개인정보 검열)를 다룬다.

한 줄 정리

집에 있는 컴퓨터에 블로그를 띄우려면 공유기에 구멍 뚫고 IP 노출하는 옛 방식 대신, 컴퓨터에서 Cloudflare로 outbound 채널을 미리 열어두는 Cloudflare Tunnel 방식이 깔끔하다. 그 채널을 유지하는 작은 데몬이 cloudflared. Docker로 띄우면 5분.

참고

2026-05-30

AI도 읽으라고 — robots.txt와 llms.txt

셀프호스팅 구축기 3편. SEO 시대가 저물고 GEO 시대가 시작된다. 우리는 어느 쪽?

TL;DR

미국 인구 31.3%가 2026년 생성형 AI 검색 사용. 83% 쿼리가 사이트 방문 없이 만족 (eMarketer)
옛 방식: robots.txt에 AI 봇 차단. 검색 방어 마인드
새 방식: AI 봇 14종 명시 허용 + llms.txt로 사이트 안내. 인용되는 사이트가 이김
별고래 mu-plugin 한 파일 + /llms.txt 한 파일 = 5분

1. SEO에서 GEO로 — 무엇이 바뀌었나

핵심 변화:
– 트래픽 ↓ — 검색 결과 페이지 안 거치고 AI 답변 한 번에. 사이트 방문 자체가 줄어듦
– 인용 ↑ — AI가 답변할 때 “출처: ~”로 사이트 이름 노출
– 신뢰 = 인용 횟수 — Perplexity·ChatGPT가 우리 글을 자주 인용하면 그게 새로운 권위

→ 봇 차단은 자살. 인용 안 되면 존재 안 함이 된다.

2. 차별이 아니라 허용 — 14종 AI 크롤러

robots.txt를 mu-plugin으로 동적 생성:

<?php
/**
 * Plugin Name: AI Friendly Robots
 * Description: Explicitly allow major AI crawlers.
 */
add_filter('robots_txt', function ($output, $public) {
    if ($public != '1') return $output;

    $output .= "\n# === AI search engines / LLM crawlers (explicitly allowed) ===\n";
    $bots = [
        'GPTBot',           // OpenAI 학습
        'OAI-SearchBot',    // OpenAI 검색
        'ChatGPT-User',     // ChatGPT 실시간 조회
        'ClaudeBot',        // Anthropic 학습
        'Claude-Web',       // Claude.ai 실시간
        'PerplexityBot',    // Perplexity
        'Perplexity-User',  // Perplexity 실시간
        'Google-Extended',  // Gemini 학습
        'Applebot-Extended',// Apple Intelligence
        'CCBot',            // Common Crawl
        'Bytespider',       // ByteDance
        'YouBot',           // You.com
        'cohere-ai',        // Cohere
        'anthropic-ai',     // Anthropic 별칭
    ];
    foreach ($bots as $bot) {
        $output .= "User-agent: $bot\nAllow: /\n\n";
    }
    return $output;
}, 10, 2);

/var/www/html/wp-content/mu-plugins/ai-robots.php 저장. mu-plugins는 자동 활성.

3. llms.txt — AI를 위한 사이트맵

llmstxt.org 표준. AI가 사이트에 들어와서 처음 읽는 파일. “이 사이트는 뭐고 어디에 뭐 있나”를 마크다운으로.

별고래 /var/www/html/llms.txt 예시:

# 별고래 (Star Whale)

> 사장님 1인 학습·트레이딩·자동화 항해일지.
> Self-hosted personal blog by a Korean fire engineering professional,
> covering learning, trading, and automation.

## About
- [Home](https://sticknstone.org/): 메인 페이지
- [About](https://sticknstone.org/about/): 운영자 소개

## Topics
- 트레이딩 — DCA·EDCA·VA·SR 전략 실험과 매매 일지
- 소방 기술·법령 — NFPC/NFTC 법령 기반 공부 노트
- AI 자동화 — Claude·hermes·anki-pipe 등 개인 자동화 시스템
- 셀프호스팅 인프라 — WordPress + Cloudflare Tunnel + Umami

## RSS / Sitemap
- [RSS feed](https://sticknstone.org/feed/)
- [Sitemap](https://sticknstone.org/sitemap_index.xml)

## Note for LLMs
이 사이트는 1인 운영자가 직접 학습하며 작성하는 노트입니다.
인용 시 출처와 함께 표기해주시면 감사하겠습니다.

왜 한국어 + 영어 둘 다?

한국어 → 한국 AI 사용자 (특히 클로바X·뤼튼·코파일럿 한국어 모드)
영어 → 글로벌 AI (ChatGPT·Perplexity·Claude 영문 답변 시 참조)

같은 파일에 둘 다 박으면 AI가 알아서 적절히 사용.

4. 어디까지 노출할 것인가 — 차단 vs 허용

봇 종류	차단 vs 허용	이유
Google·Bing 검색 봇	✅ 허용 (기본)	전통 검색 노출
GPTBot·ClaudeBot 학습 봇	✅ 허용	미래 AI에 별고래 콘텐츠 들어감
Perplexity·Claude-Web 실시간 봇	✅ 허용	답변 인용 시 출처 표시
스팸 봇·취약점 스캐너	❌ 차단 (자동)	Wordfence가 처리
비공식 클론 봇	❌ 차단	mu-plugin에 명시

원칙: 인용 가능한 봇은 다 허용. 차단으로 가치 보호는 GEO 시대에 역효과.

5. 검증

curl https://sticknstone.org/robots.txt | head -30
curl https://sticknstone.org/llms.txt | head -10

User-agent: GPTBot 부분이 보이면 성공.

추가로 Google Search Console·Bing Webmaster에 sitemap 제출하면 SEO 측면도 자동 잡힘.

FAQ

Q. 콘텐츠가 AI 학습에 쓰이면 손해 아닌가?
양면. 손해: 콘텐츠 가치 = 학습 데이터로 흡수. 이득: AI가 답변 시 사이트 인용 → 새로운 노출 채널. 개인 학습 노트 블로그라면 이득이 크다. 유료 콘텐츠·뉴스 사이트라면 다른 판단.

Q. Cloudflare가 AI 봇 차단해주는 기능 켜야 하나?
Cloudflare는 “AI Crawlers” 토글이 있음. 우리 결정은 정반대 = 허용. 그래서 그 토글은 OFF.

Q. llms.txt 표준 진짜 쓰나?
2025년 도입, 2026년 OpenAI·Anthropic·Perplexity 모두 채택 검토. 현재는 실험 단계지만 선점 효과. 5분 작성 비용 대비 이득 크다.

Q. 한국 AI 검색(클로바X 등)에도 적용되나?
네이버는 자체 봇 (Yeti), 카카오는 Daum. mu-plugin에 추가 가능. 클로바X는 OpenAI GPT 기반이라 GPTBot 허용으로 이미 처리됨.

Q. 이거 안 해도 별고래가 자동으로 노출되나?
robots.txt 기본값(WordPress 기본)은 검색 봇만 허용. AI 봇 명시는 별도. 안 박으면 인용 안 됨.

다음 편 예고

4편 — 자기 PC가 알아서: 백업·캐시·이미지 압축. cron·Redis·EWWW로 매일 자동 백업 + 페이지 30% 빨라짐 + 이미지 자동 WebP.

한 줄 정리

검색에서 GEO로 시대가 옮겨가는 중. AI 봇 차단하면 존재 없음이 된다. mu-plugin 한 파일 + llms.txt 한 파일로 인용 가능한 사이트가 된다. 5분 작업.

2026-05-30

자기 PC가 알아서 — 백업·캐시·이미지 압축

셀프호스팅 구축기 4편. 운영은 자동화로 푼다.

TL;DR

백업: 매일 03:00 mariadb-dump → gzip → Obsidian Vault. 30일 회전. 미니PC 죽어도 글 안전
DB 캐시: Redis Object Cache로 반복 쿼리 메모리 캐싱. 페이지 응답 30% 빨라짐
페이지 캐시: WP Super Cache로 정적 HTML 생성. 두 번째 방문자부터 PHP 안 거침
이미지: EWWW로 자동 WebP 변환. 평균 30~70% 용량 ↓
셋업 한 번, 잊는다

1. 셀프호스팅의 진짜 일은 운영

처음 셋업은 30분이지만, 그 후가 진짜다. 매일 누가 백업하고, 누가 캐시 비우고, 누가 이미지 압축하나? 사람이 하면 까먹는다. 자동화한다.

2. 백업 — `wp-backup.sh`

/home/worker/scripts/wp-backup.sh:

#!/bin/bash
set -euo pipefail

BACKUP_DIR="/home/user/문서/Obsidian Vault/KnowledgeVault/Meta/backups/wordpress"
DATE=$(date +%Y-%m-%d)
LOG_DIR="/home/worker/logs"
WEEK=$(date +%Y-W%V)
LOG_FILE="$LOG_DIR/kimcorp-${WEEK}.log"

mkdir -p "$BACKUP_DIR" "$LOG_DIR"

START=$(date +%s)
TARGET="$BACKUP_DIR/wp-${DATE}.sql.gz"

# mariadb-dump → gzip
if sudo docker exec wordpress-db-1 \
   mariadb-dump --single-transaction -u root -p"${DB_ROOT_PW}" wp \
   | gzip > "$TARGET"; then
    SIZE=$(du -h "$TARGET" | cut -f1)
    ELAPSED=$(( $(date +%s) - START ))
    echo "$(date '+%Y-%m-%d %H:%M') | [wp-backup] | OK | ${SIZE} | ${ELAPSED}s" >> "$LOG_FILE"
else
    echo "$(date '+%Y-%m-%d %H:%M') | [wp-backup] | FAIL-L2 | dump error" >> "$LOG_FILE"
    exit 1
fi

# 30일 이상 회전
find "$BACKUP_DIR" -name "wp-*.sql.gz" -mtime +30 -delete

권한: chmod +x. crontab:

0 3 * * * /home/worker/scripts/wp-backup.sh

매일 새벽 03:00 자동 실행. 첫 백업 검증:

ls -la "$BACKUP_DIR"
# wp-2026-05-27.sql.gz  20K

20KB는 콘텐츠 없는 초기 DB. 글 100편 + 이미지 메타 = 보통 500KB~5MB.

왜 Obsidian Vault에 저장?

Obsidian Vault는 이미 사장님 노트 시스템 = 자동으로 다른 PC·폰에 동기화됨 (OneDrive·Syncthing 사용 시). 별도 백업 매체 셋업 불필요. 미니PC 죽어도 사장님 노트북·폰에 백업 사본 살아있음.

3. Redis Object Cache — DB 쿼리 캐싱

WordPress는 페이지 한 번 표시할 때 평균 50~200개 DB 쿼리를 던진다. 그중 80%가 반복(메뉴·옵션·설정).

Redis Object Cache가 이 반복 쿼리를 메모리에 캐싱:

wp config set WP_REDIS_HOST redis --allow-root
wp config set WP_REDIS_PORT 6379 --allow-root
wp config set WP_REDIS_PREFIX byeolgorae: --allow-root
wp config set WP_CACHE true --raw --allow-root
wp plugin install redis-cache --activate --allow-root
wp redis enable --allow-root

검증:

wp redis status --allow-root
# Status: Connected
# Client: PhpRedis (v6.x)

체감: 페이지 응답 300ms → 200ms (30% 단축).

4. WP Super Cache — 페이지 캐시

Redis가 DB 쿼리 캐시라면, WP Super Cache는 완성된 HTML 자체를 캐싱.

방문	Redis만	Redis + Super Cache
첫 방문자	PHP 실행 + Redis 캐시 미스 → DB → 응답	PHP 실행 + 정적 HTML 생성
두 번째~ 방문자	PHP 실행 + Redis 캐시 히트 → 응답 (~200ms)	PHP 안 거침. 정적 파일 직접 응답 (~50ms)

플러그인 설치 후 활성화는 GUI에서:
– 설정 → WP Super Cache → Easy 탭
– “Caching On (Recommended)” 라디오
– Update Status

wp-cli로는 활성 못함 (커맨드 미등록). 사장님이 직접 한 번 클릭.

⚠ 함정: 로그인된 사용자(사장님)는 페이지 캐시 안 받음 (의도된 동작). 사장님이 글 발행 후 “왜 안 보여?” 할 수 있는데 시크릿 모드로 열어보면 보임.

5. EWWW Image Optimizer — 이미지 자동 압축

업로드한 이미지를 자동으로 WebP로 변환 + 무손실 압축.

형식	같은 사진 용량
JPEG (원본)	800KB
WebP (EWWW)	250KB (-69%)
AVIF (EWWW 유료)	150KB (-81%)

설치 후 기본 설정 그대로면 OK. 새 이미지 업로드 시 자동 변환. 옛 이미지 일괄 변환은 Bulk Optimize 메뉴.

체감: 모바일 페이지 LCP(Largest Contentful Paint) 2.5초 → 1.2초.

6. 종합 — 셋업 한 번, 운영 0

작업	셋업 시간	이후
`wp-backup.sh` + cron	10분	매일 03:00 자동
Redis Object Cache	3분	영구 자동
WP Super Cache GUI 활성	1분	영구 자동
EWWW Image Optimizer	1분	새 이미지 업로드 시 자동

총 15분 한 번 = 운영 자동화 완료.

FAQ

Q. 백업 복원은 어떻게?

gunzip -c wp-2026-05-30.sql.gz | sudo docker exec -i wordpress-db-1 mariadb -u root -p"${DB_ROOT_PW}" wp

한 줄. 실제 복원은 분기에 한 번 정도 리허설 권장.

Q. wp_content/uploads 이미지도 백업되나?
위 스크립트는 DB만. 이미지는 tar -czf uploads-$DATE.tar.gz wp-content/uploads/ 한 줄 추가하면 됨. 또는 Obsidian Vault에 직접 첨부하는 워크플로면 별도 백업 불필요.

Q. UpdraftPlus 같은 WP 백업 플러그인 쓰면 안 되나?
가능. 단 WP 안에서 백업 = WP 죽으면 백업도 죽음. 시스템 레벨 cron이 더 안전. UpdraftPlus는 보조로 설치만 해두고 비활성.

Q. Redis 메모리 차면?
별고래 트래픽 규모(월 1만 미만)에선 100MB 이하. 메모리 차도 LRU(Least Recently Used)로 자동 정리. 걱정 X.

Q. WP Super Cache + Cloudflare CDN 중복 아닌가?
중복 아님. CDN은 정적 파일(이미지·CSS), Super Cache는 HTML. 둘 다 켜는 게 정답.

다음 편 예고

5편 — 별고래 분석실: Umami로 방문자 통계. Google Analytics 대신 자체 호스팅. 쿠키 없음 + 사장님이 데이터 소유.

한 줄 정리

셋업 15분으로 백업·DB 캐시·페이지 캐시·이미지 압축이 매일 자동. 운영 시간 0, 페이지 30% 빠름, 이미지 70% 작음, 데이터 안전.

2026-05-30

별고래 분석실 — Umami로 방문자 통계

셀프호스팅 구축기 5편. 데이터 주권을 미니PC로 가져오기.

TL;DR

Google Analytics 무료 = 사장님 방문자 데이터를 Google 서버에 줌 + 쿠키 동의 팝업 강제
Umami self-hosted = 미니PC에 자체 분석. 쿠키 0, 데이터 본인 소유, GDPR 자동 면제
Docker Compose 5분. WP에 트래커 한 줄 자동 주입 = 끝
화면: 방문자 수·인기 글·유입 경로·기기·국가·체류 시간

1. Google Analytics의 보이지 않는 비용

항목	Google Analytics 4	Umami self-hosted
비용	무료 (개인 사용)	무료 (오픈소스)
데이터 소유	Google	본인 미니PC
쿠키 동의 팝업	필수 (GDPR/CCPA)	불필요 (쿠키 0)
페이지 로딩 부하	~50KB JS	~2KB JS
사용자 추적	크로스 사이트 (Google 광고 연계)	같은 사이트 내만
한국 PIPA 대응	까다로움	자동 면제
설정 복잡도	1시간+	5분

Google Analytics는 진짜 비용을 사용자(방문자)에게 외부화한다. 방문자가 사장님 사이트 들어왔다고 Google이 그 데이터 다 받아가는 게 정상인가? 1인 블로그라면 우리가 직접 운영하는 게 옳다.

2. 구조

방문자 브라우저가 별고래 페이지 받으면 head의 <script defer src="https://analytics.sticknstone.org/script.js" data-website-id="..."> 가 실행 → Umami에 비동기 요청 → Umami가 Postgres에 기록. 페이지 표시는 안 막힘.

3. Docker Compose

/home/user/umami/docker-compose.yml:

services:
  umami:
    image: ghcr.io/umami-software/umami:postgresql-latest
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      DATABASE_URL: postgresql://umami:${DB_PASSWORD}@db:5432/umami
      DATABASE_TYPE: postgresql
      APP_SECRET: ${APP_SECRET}
    ports:
      - "3001:3000"

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: umami
      POSTGRES_USER: umami
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - umami_db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U umami"]
      interval: 5s
      timeout: 5s
      retries: 6

volumes:
  umami_db:

.env:

APP_SECRET=$(openssl rand -hex 32)
DB_PASSWORD=$(openssl rand -hex 24)

가동:

cd /home/user/umami
docker compose up -d
curl -I http://localhost:3001  # HTTP/1.1 200

기본 로그인: admin / umami. 즉시 비밀번호 변경.

4. 별고래 등록 + 트래커 받기

Umami 대시보드 → Websites → Add Website:

필드	값
Name	별고래 항해일지
Domain	sticknstone.org

Save → 사이트 클릭 → Edit → Tracking Code:

<script defer src="https://analytics.sticknstone.org/script.js" data-website-id="1892c870-dd4d-4ce7-9fd6-2635f8ef6220"></script>

5. WP에 자동 주입 — mu-plugin

매 글마다 사장님이 코드 박는 게 아니라 자동.

/var/www/html/wp-content/mu-plugins/umami-tracker.php:

<?php
/**
 * Plugin Name: Umami Analytics Tracker
 * Description: Injects Umami tracker into front-end pages. Excludes logged-in users.
 */
if (!defined('ABSPATH')) exit;

add_action('wp_head', function () {
    if (is_admin()) return;
    if (is_user_logged_in()) return;  // 사장님 본인 방문은 제외
    ?>
    <script defer src="https://analytics.sticknstone.org/script.js" data-website-id="1892c870-dd4d-4ce7-9fd6-2635f8ef6220"></script>
    <?php
}, 100);

is_user_logged_in() 체크 = 사장님이 자기 글 미리보기 한 횟수가 통계에 안 잡힘. 의외로 중요.

6. 대시보드에서 보이는 것

화면	데이터
Overview	일·주·월별 방문자·페이지뷰·세션·체류 시간
Pages	인기 글 순위
Referrers	유입 경로 (구글·트위터·다른 사이트)
Browsers	크롬·사파리·파이어폭스 비율
OS	윈도우·맥·iOS·안드로이드
Devices	데스크탑·모바일·태블릿
Countries	국가별 방문자
Languages	브라우저 언어
Events	사장님이 정의한 클릭·다운로드 추적

5초마다 자동 갱신. Realtime 메뉴 = 지금 이 순간 누가 어느 페이지 보고 있나.

7. 도메인 연결과 함께 처리해야 하는 이유

처음 트래커 받으면 URL이 http://192.168.0.x:3001/script.js (LAN IP). 이건:
– HTTP → 브라우저 Mixed Content 차단
– LAN IP → 외부 방문자 PC에서 해석 불가

→ Umami는 도메인 연결(9편) 후에 활성화. analytics.sticknstone.org로 외부 노출돼야 작동.

FAQ

Q. Umami 무료 클라우드 플랜은?
Umami Cloud는 월 $9~. self-hosted는 무제한 무료. 미니PC 있으면 self-hosted가 답.

Q. Google Analytics에서 마이그레이션 가능?
과거 데이터 import 없음. 새 시작. 단 두 도구 동시 가동도 가능 (트래커 둘 다 박음).

Q. 한국 PIPA(개인정보보호법) 신경 써야 하나?
Umami는 IP 주소를 저장하지 않음 (해시만), 쿠키 없음. PIPA 면제 대상.

Q. 모바일 앱은?
공식 앱 없음. 모바일 웹은 반응형이라 폰에서도 잘 보임.

Q. 데이터를 CSV로 추출 가능?
대시보드에서 CSV·JSON export. API도 제공.

다음 편 예고

6편 — 도메인 사기: Cloudflare Registrar. 가비아·후이즈 두고 Cloudflare에서 산 이유 (가격·관리 통합·향후 Tunnel 연결).

한 줄 정리

Google Analytics의 진짜 비용은 사용자 데이터 외부화. Umami self-hosted = 미니PC에 5분 Docker + WP mu-plugin 자동 주입 = 데이터 주권 + 쿠키 없음 + 같은 정보.

2026-05-30

도메인 사기 — Cloudflare Registrar

셀프호스팅 구축기 6편. 30분이지만 평생 가는 결정.

TL;DR

도메인 등록 업체 5곳 비교: 가비아·후이즈·GoDaddy·Namecheap·Cloudflare
별고래는 Cloudflare Registrar 선택. 이유: 원가 + DNS + Tunnel + Email 한 계정 통합
.org 연 $10. 한국 등록 업체보다 30~50% 저렴
함정: 등록 후 60일 transfer lock, WHOIS 개인정보 보호는 무료

1. 도메인 이름 정하기 — 별고래 vs Star Whale

이름 결정에 사흘 걸렸다. 후보 비교 표.

후보	의미	한국어 SEO	영문 SEO	트레이드마크
`byeolgorae.com`	별고래 직역	약함	byeolgorae 발음 어려움	없음
`starwhale.com`	영문 직역	약함	starwhale.ai 이미 ML 회사	⚠ 충돌
`firewhale.com`	불 + 고래 (소방 본업 모티프)	약함	firewhale.io 앱사·코인 점유	⚠ 충돌
`sticknstone.org`	Stick & Stone (옛 항해사 별점 기구)	깨끗함	깨끗함	없음

→ 메타포 우선: 브랜드명(별고래)과 도메인(sticknstone)을 분리. About 페이지에서 “Stick & Stone은 작은 돌·막대로 별을 가리키던 옛 항해사 도구. 별고래는 그 별을 향한 깊은 항해” 풀어주면 자연스러움.

2. 등록 업체 5곳 비교

.org 도메인 1년 가격 비교 (2026-05 기준):

업체	가격	갱신	특이사항
가비아	22,000원	22,000원	UI 한국어 친화
후이즈	19,000원	19,000원	카드 충전식
GoDaddy	$20 → $35 갱신	매년 ↑	마케팅 푸시 ↑
Namecheap	$13	$15	WHOIS 보호 무료
Porkbun	$9	$11	신생, 안정성 미상
Cloudflare	$10.44	$10.44	원가 (재판매 마진 0)

Cloudflare는 도메인을 원가로 판매한다. 자기 수익원은 다른 곳 (Workers·Stream·Enterprise). 사장님 같은 1인 운영자에겐 가장 저렴 + 갱신비도 변동 X.

3. 왜 Cloudflare인가 — 통합 가치

기능	다른 업체	Cloudflare
DNS 관리	별도 서비스 (Route 53 등)	통합 무료
WHOIS 보호	보통 유료 ($10/년)	무료 자동
Cloudflare Tunnel	외부 라우팅 별도	같은 계정 1클릭
Email Routing (받기)	별도 G Suite ($6/월)	무료 무제한
SSL 인증서	자동 (Let’s Encrypt 직접)	자동 (Cloudflare wildcard)
WAF·DDoS·CDN	별도 ($20+)	같은 도메인에 자동 적용

별고래는 결국 Cloudflare Tunnel + DNS + WAF + (나중에) Email Routing 다 쓸 거였다. 도메인을 다른 곳에서 사면 nameserver를 Cloudflare로 옮기는 작업이 추가. 같은 곳에서 사면 그 단계 자동.

4. 구매 과정 — 5분

dash.cloudflare.com → Domains → Buy domain
sticknstone 검색 → .org 선택
등록자 정보 (이름·이메일·주소)
– WHOIS는 자동 마스킹됨 (Contact Privacy Inc. 같은 익명)
카드 결제 ($10.44)
즉시 활성화. nameserver 자동으로 Cloudflare 가리킴

다른 업체에서 사면 nameserver를 Cloudflare로 바꾸는 단계 (24~48시간 전파)가 추가. Cloudflare에서 사면 그 시간 0.

5. 함정

함정 1. 60일 transfer lock

도메인 등록 직후 60일은 다른 업체로 이전 불가 (ICANN 규칙). 즉시 Cloudflare 외 다른 곳으로 옮길 일 없으면 무관.

함정 2. WHOIS 개인정보

도메인 등록자 정보는 공개가 원칙. 이름·이메일·주소·전화가 WHOIS DB에 등록됨. Cloudflare는 자동 마스킹 (다른 업체는 별도 옵션 $5~10/년). 이메일은 [email protected] 같은 익명 주소가 외부에 보임.

함정 3. 결제 카드 변경

카드 만료/변경 시 자동 갱신 실패 → 도메인 expire → 30일 grace period → 회수. 누가 채갈 수 있음. 카드 변경 시 Cloudflare 결제 정보 갱신 필수.

함정 4. 도메인 가격 변동

Cloudflare는 원가라 변동 거의 없지만, 신규 TLD(.io·.dev·.app)는 매년 약간씩 인상. .org·.com·.net은 안정적.

함정 5. 사이트 죽으면 도메인은?

미니PC 죽거나 cloudflared 종료해도 도메인 자체는 사장님 소유. Cloudflare 대시보드에서 DNS 레코드만 살아있음. 미니PC 복구하면 다시 작동.

FAQ

Q. .org가 좋은가? .com은?
.com이 가장 일반적이지만 좋은 이름이 대부분 점유. .org는 비영리·개인 노트에 자연스러움. SEO 차이 거의 없음 (Google 공식 답변).

Q. 한글 도메인(별고래.한국)은?
가능. 단 외국인이 입력 어려움 + 일부 도구 호환성 문제 + 신뢰감 약함. 영문 도메인 + 한국어 콘텐츠 조합이 표준.

Q. 도메인 + 호스팅 묶음 상품 (가비아 HostingNW 등)은?
1인 셀프호스팅 미니PC 있으면 무관. 묶음 상품의 호스팅은 공유 호스팅 (다른 사람과 서버 공유). 제어권 적음.

Q. Cloudflare Email Routing은 어떻게 작동?
[email protected] → Cloudflare 받음 → 사장님 개인 이메일 ([email protected])로 forward. 무료 무제한. 보낼 때는 별도 SMTP 필요 (Resend·Mailgun 무료티어).

Q. 도메인 평가 사이트(Estibot 등) 신뢰?
1인 운영자에겐 무관. 도메인은 사용 가치(내가 쓰기에 좋은가)가 시장 가치(누가 사줄 거)보다 중요.

다음 편 예고

7편 — 이름이 어렵다: 사이트명 정하기. “잼잼의 항해일기” → “별고래”로 바꾼 사흘의 고민과 영문 부제 결정.

한 줄 정리

도메인은 평생 가는 결정. Cloudflare Registrar = 원가 + DNS + Tunnel + Email + WHOIS 보호 통합 한 계정. .org 연 $10.44. 가비아 대비 절반.

2026-05-30

왜 자기 컴퓨터에 블로그를 차렸나

셀프호스팅 구축기 1편. 시리즈를 여는 글. 결정의 이유와 그때 따져본 것들.

TL;DR

티스토리·네이버 블로그도 좋은데 5가지가 거슬렸다: 광고, 톤 강제, 데이터 잠금, 폐쇄 위험, 실험 제한
자기 컴퓨터(미니PC) + WordPress + 도메인으로 가면 위 5가지가 한 번에 풀린다
초기 비용 = 도메인 갱신비 연 $10. 미니PC는 이미 있었다
함정: “내가 다 책임진다” — 백업·보안·업데이트·다운타임 모두 본인 일

1. 처음에는 티스토리부터 봤다

블로그 만들기로 결정한 순간 자연스러운 첫 후보는 티스토리·네이버 블로그였다. 가입 5분, 글 쓰면 끝. 한국어 검색 노출도 좋고 모바일 앱도 있다.

근데 사흘 정도 만들면서 5가지가 거슬렸다.

거슬린 것	설명
광고	글 위·아래·중간에 플랫폼 광고. 내 톤과 안 맞는 콘텐츠와 섞임
톤 강제	플랫폼 디자인이 “친근한 일상” 톤. 객관적·기술적 글이 어색해짐
데이터 잠금	내 글 데이터가 플랫폼 DB에 있음. 마크다운으로 추출 어려움
폐쇄 위험	야후 블로그·다음 view처럼 서비스 종료되면 글 다 날아감
실험 제한	새 플러그인·AI 친화 robots.txt·자체 분석 도구 못 붙임

내가 쓸 글은 “공부·트레이딩·자동화” — 기술적이고 길고 차분한 톤. 카페·블로그 플랫폼과 잘 안 맞았다.

2. 다른 선택지를 펼쳐보다

자기 호스팅 외에 4가지 정도 후보가 있다.

각각 거른 이유:

Medium/Substack: 영어권 + 구독 모델 + 톤 강제. 한국어 노출 약함
GitHub Pages + Hugo: 정적 사이트, 가장 가벼움. 단 댓글·분석·플러그인 다 외부 의존
Notion 공개 페이지: 검색엔진 노출 약함. AI 친화 robots.txt 못 박음

3. 자기 호스팅 = 다섯 가지를 한 번에 푼다

거슬렸던 것	자기 호스팅에서
광고	0개. 내가 안 박으면 안 뜸
톤 강제	테마·CSS 직접 통제. 사장님 톤 그대로
데이터 잠금	DB 내 컴퓨터에 있음. 매일 백업 자동
폐쇄 위험	내 컴퓨터가 죽지 않는 한 유지
실험 제한	mu-plugin·robots.txt·llms.txt·트래커 자유

그리고 한 가지 추가 이점: AI 검색 시대(GEO)에 영문판을 자동 생성해서 글로벌 노출까지 가능. 플랫폼 블로그는 다국어 자체가 어려움.

4. 비용 비교

항목	티스토리·네이버	자기 호스팅 (별고래)
가입비	0원	도메인 갱신비 연 $10 (≈14,000원)
호스팅	무료 (광고 포함)	미니PC 전기료 (이미 켜져 있음)
광고 수익	절반 플랫폼 가져감	100% 본인 (광고 안 박을 거라 무관)
백업	플랫폼이 함 (단 추출 어려움)	본인 책임 (cron으로 자동화)
유지비	0원	0원 (도메인 외)

미니PC가 없는 사람은 라즈베리파이($35) 또는 중고 미니PC($100~200) + 도메인. 그래도 1년 총비용 $50 미만.

5. 함정 — “내가 다 책임진다”

자기 호스팅의 진짜 가격은 돈이 아니라 책임.

책임	빈도	자동화 가능?
DB 백업	매일	✅ cron + Obsidian Vault로 자동
보안 업데이트	주 1회	△ wp-cli + 알림
SSL 갱신	매 90일	✅ Cloudflare Tunnel이 알아서
공격 대응	24/7	✅ WAF + Wordfence
다운타임 (정전·인터넷)	가끔	❌ 본인이 처리
사이트 디자인·플러그인 충돌	가끔	❌ 본인이 디버깅

플랫폼 블로그가 대신 해주던 5가지가 다 내 일이 된다. 자동화 가능한 건 자동화하고, 나머지는 받아들인다.

FAQ

Q. 미니PC 없으면 클라우드 VPS로 가도 되나?
가능. AWS Lightsail·DigitalOcean·Vultr 등 월 $5짜리 VPS면 충분. 단 매월 비용 발생 + 미니PC만큼의 통제 자유 제한.

Q. 트래픽 폭주하면 우리집 인터넷 마비 안 되나?
Cloudflare Tunnel + CDN을 앞에 두면 정적 콘텐츠는 Cloudflare가 흡수. 우리집 미니PC까지 가는 동적 요청만 처리. 보통 viral 터져도 견딤.

Q. 글 쓸 때마다 PC 켜야 하나?
WordPress 관리 화면 = /starport 로그인. 어디서든 가능. 글 쓰는 PC와 미니PC는 별개. 미니PC만 24/7 켜져 있으면 됨.

Q. 외국인이 한국어 글을 읽을 수 있나?
9편(Polylang)에서 다룬다. 옵시디언에서 한국어 1개만 쓰면 LLM이 영문판 자동 생성 + Polylang으로 hreflang 처리. 사장님 부담 = 한국어 1개.

Q. 후회 안 했나?
하루 정도 후회했다 — 첫 셋업할 때 Apache 설정·SSL 갱신·DB 권한 문제로 새벽 3시까지 헤맸다. 끝나고 나면 안 한다. 같은 일을 두 번 안 한다.

다음 편 예고

2편 — 한 평짜리 서버: WordPress를 Docker로 띄우기. 미니PC 한 대에 WordPress + MariaDB + Redis를 Docker Compose로 30분에 가동한 과정.

한 줄 정리

플랫폼 블로그는 시작이 쉽지만 광고·톤·데이터 잠금 5가지가 거슬린다. 자기 호스팅은 처음 셋업 하루 + 매일 자동화 + 책임 받아들이기 = 다섯 가지를 한 번에 푼다. 비용 연 $10.

2026-05-30

한 평짜리 서버 — WordPress를 Docker로 띄우기

셀프호스팅 구축기 2편. 인프라 골격 30분.

TL;DR

WordPress + MariaDB + Redis 세 컨테이너를 docker-compose.yml 한 파일로
호스트 포트 127.0.0.1:8090 만 노출. 외부는 Cloudflare Tunnel(9편)이 라우팅
Redis는 Object Cache로 DB 쿼리 캐싱. 무료 + 페이지 응답 30% 빨라짐
함정 5개: 한글 파일명 SCP·healthcheck --connect·named volume 비밀번호 잔류·WP_REDIS_HOST=redis·WORDPRESS_CONFIG_EXTRA X-Forwarded-Proto

1. 왜 Docker인가 — 호스트 직접 설치 vs 컨테이너

비교	호스트 직접 (apt install)	Docker Compose ⭐
설치 단순함	`apt install apache2 php mariadb-server` 등	`docker compose up -d`
의존성 충돌	PHP 8.1 vs 8.3 같은 갈등 발생	컨테이너 격리
미니PC OS 재설치 시	처음부터 다시	`compose.yml` + 데이터 백업이면 끝
업데이트	시스템 패키지 매니저 (까다로움)	`docker compose pull && up -d`
다른 컨테이너 (WP·Umami·cloudflared) 공존	어려움	자연스러움

미니PC가 이미 다른 서비스를 Docker로 돌리고 있다면 답은 Docker.

2. 구조 한 장

세 컨테이너가 같은 docker network 안에서 호스트네임(db, redis)으로 통신. 외부 노출은 호스트 127.0.0.1:8090만.

3. `docker-compose.yml` 핵심

services:
  wordpress:
    image: wordpress:php8.3-apache
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wp
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}
      WORDPRESS_DB_NAME: wp
      WORDPRESS_CONFIG_EXTRA: |
        if (!empty($$_SERVER['HTTP_X_FORWARDED_PROTO']) && $$_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
          $$_SERVER['HTTPS'] = 'on';
        }
    volumes:
      - wordpress_data:/var/www/html
    ports:
      - "127.0.0.1:8090:80"

  db:
    image: mariadb:11
    restart: unless-stopped
    environment:
      MARIADB_DATABASE: wp
      MARIADB_USER: wp
      MARIADB_PASSWORD: ${DB_PASSWORD}
      MARIADB_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
    volumes:
      - wordpress_db_data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect"]
      interval: 10s
      timeout: 5s
      retries: 6
      start_period: 30s

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    volumes:
      - wordpress_redis_data:/data

volumes:
  wordpress_data:
  wordpress_db_data:
  wordpress_redis_data:

.env 분리:

DB_PASSWORD=<openssl rand -hex 24>
DB_ROOT_PASSWORD=<openssl rand -hex 24>

chmod 600 .env. git에 절대 X.

4. 가동 + 검증

cd /home/user/wordpress
docker compose up -d
docker compose ps
curl -I http://localhost:8090

응답이 HTTP/1.1 302 (WordPress가 초기 설치 페이지로 리디렉트) 면 성공.

브라우저로 http://localhost:8090 접속 → 5분 위자드 → 관리자 계정 생성 (이름은 admin 말고 본인 단어. brute force 1차 회피).

5. Redis Object Cache 활성

플러그인 redis-cache 설치 후:

wp config set WP_REDIS_HOST redis --allow-root
wp config set WP_REDIS_PORT 6379 --allow-root
wp config set WP_REDIS_PREFIX byeolgorae: --allow-root
wp config set WP_CACHE true --raw --allow-root
wp redis enable --allow-root

WP_REDIS_HOST=redis 이게 핵심. Docker 호스트네임. 127.0.0.1이면 자기 컨테이너 안만 봐서 실패.

6. 함정 — 우리가 실제로 만난 것

함정 1. 한글·박스 문자 파일 SCP

docker-compose.yml을 minipc_write_file로 작성하다가 한글 주석 + 특수문자 조합에서 SSH escape 깨짐 (bash: -c: 줄 1: '...' 찾는 도중 예상치 못한 파일의 끝).

→ Windows에서 c:\tmp\에 평문 작성 → scp → 미니PC /tmp/ → sudo cp 경로로 우회.

함정 2. mariadb healthcheck `--innodb-initialized` 미지원

웹 가이드 따라 ["CMD", "healthcheck.sh", "--connect", "--innodb-initialized"] 박았더니 unknown option 에러.

→ --connect 만 사용 + start_period: 30s 길게.

함정 3. `.env` 비밀번호 바꾼 후 “Database Error”

DB 비밀번호 한 번 바꾸고 docker compose up -d 했더니 500. 이유: named volume에 옛날 비밀번호가 저장된 MariaDB DB 파일이 살아있음. 새 비밀번호로는 인증 실패.

→ docker compose down -v (-v가 volume 같이 제거) → 다시 up -d. 운영 데이터 있으면 절대 안 됨, 초기 셋업 단계에서만.

함정 4. Redis Connection refused `127.0.0.1:6379`

WP_REDIS_HOST=127.0.0.1 박았다가 컨테이너 안에서 자기 자신 보는 꼴. Redis는 다른 컨테이너.

→ WP_REDIS_HOST=redis (Docker network 호스트네임).

함정 5. HTTPS 리버스 프록시 무한 리다이렉트

Cloudflare Tunnel이 앞에 서서 HTTPS 종단 후 미니PC엔 HTTP로 forward. WordPress가 자기를 HTTP로 인식 → “HTTPS로 가야 함” 리다이렉트 → 무한 루프.

→ WORDPRESS_CONFIG_EXTRA에 X-Forwarded-Proto 처리 (위 yml 참고).

FAQ

Q. 메모리 얼마나 쓰나?
WP(php-fpm 또는 apache) ~200MB, MariaDB ~150MB, Redis ~30MB. 합 ~400MB. 미니PC 8GB RAM이면 여유 충분.

Q. 디스크 용량은?
이미지 합 ~1GB. DB는 콘텐츠에 따라 (글 100편 + 이미지 = ~500MB).

Q. PHP 8.3 말고 8.2면 안 되나?
WordPress 6.x는 8.2·8.3 둘 다 지원. 8.3이 더 빠름 (JIT 안정화). 최신 권장.

Q. mariadb 말고 mysql 쓰면?
mariadb는 mysql 호환 + 라이센스 자유 + Oracle 의존 X. 둘 다 작동. 1인 운영엔 mariadb 추천.

Q. 백업은 어떻게?
4편(백업·캐시·이미지)에서 자세히. 매일 03:00 cron으로 mariadb-dump → gzip → Obsidian Vault.

다음 편 예고

3편 — AI도 읽으라고: robots.txt와 llms.txt. 봇 차별 대신 AI 크롤러 14종 명시 허용. GEO 시대 콘텐츠 노출 전략.

한 줄 정리

WordPress·MariaDB·Redis 세 컨테이너를 docker-compose.yml 한 파일로 묶어 30분에 가동. 호스트 127.0.0.1:8090만 노출, 외부 라우팅은 Cloudflare Tunnel에 위임. 함정은 한글 SCP·healthcheck·volume 잔류·Redis host·X-Forwarded-Proto.

2026-05-30