블로그

새벽마다 NAS로 — tar+ssh 자동 백업 (왜 rsync를 안 썼나)

셀프호스팅 구축기 12편. 서버는 지켰다(11편). 이제 서버가 죽어도 데이터는 살리는 법.

← 이전 편: 11편 — 공짜로 워드프레스 지키기 (Wordfence)
→ 다음 편: 13편 — 내 노트는 내 서버에 (Obsidian LiveSync)

요약

백업 없는 셀프호스팅은 시한폭탄 — 디스크 하나 죽으면 사진·글·DB가 한 번에 사라진다
매일 새벽 cron이 중요 폴더를 tar로 묶어 ssh로 NAS에 던진다
rsync(전용 데몬·포트 873)를 일부러 안 썼다 — SSH는 이미 열려 있으니 추가로 열 포트가 0
DB 덤프가 끝난 뒤 파일 백업이 돌아야 그 덤프까지 한 묶음에 들어간다 — 순서가 정합성을 만든다
“백업이 돌았다”와 “백업이 성공했다”는 다르다 — 0바이트 파일은 실패로 처리

1. 백업 없는 셀프호스팅 = 시한폭탄

내 컴퓨터에 블로그를 올린다는 건, 클라우드가 대신 해주던 백업도 내 책임이 된다는 뜻이다. SSD 하나가 수명을 다하거나, 명령 하나 잘못 치면, 몇 달치 글과 사진과 데이터베이스가 한순간에 날아간다.

규칙은 단순하다. 백업은 다른 물리적 장치에, 자동으로, 매일. 손으로 하는 백업은 반드시 잊어버린다.

2. 왜 rsync가 아니라 tar + ssh인가

백업이라면 보통 rsync를 떠올린다. 빠르고 증분 동기화도 된다. 그런데 NAS(여기선 시놀로지)에서 rsync를 제대로 쓰려면 rsync 전용 서비스(데몬, 포트 873)를 켜야 한다. 포트를 하나 더 여는 것이다.

항목	rsync 데몬	tar + ssh
추가로 열 포트	873 필요	0 (이미 쓰는 SSH 재사용)
증분 전송	가능	매번 전체
설정 복잡도	서비스·권한 설정	명령 한 줄
노출 면적	늘어남	그대로

우리 데이터는 작아서 매일 통째로 묶어도 부담이 없다. 그렇다면 포트를 더 여는 대가를 치를 이유가 없다. 노출 면적을 줄이는 쪽이 셀프호스팅에선 거의 항상 옳다.

3. 한 줄짜리 백업

tar czf - /중요/데이터/폴더 | ssh -p <포트> [email protected] "cat > /backup/site-$(date +%F).tgz"

tar czf -는 폴더를 묶어 화면(stdout)으로 흘려보내고, 그걸 ssh가 받아 NAS에서 파일로 떨군다. 중간에 임시 파일을 만들지 않으니 디스크도 덜 쓴다. 파일명에 날짜($(date +%F))가 들어가 매일 다른 이름으로 쌓인다.

4. 순서가 정합성을 만든다 — DB 먼저

데이터베이스는 그냥 폴더를 복사하면 안 된다. 쓰는 도중에 복사하면 반쯤 쓰다 만 상태가 백업될 수 있다. 그래서 먼저 DB를 안전하게 덤프(dump) 파일로 뽑고, 그 덤프가 끝난 뒤에 파일 백업이 돌아야 한다.

flowchart LR
    A[04:30 DB 덤프] --> B[덤프 파일 생성]
    B --> C[05:00 파일 백업
덤프 포함해서 묶음]
    C --> D[NAS 전송]

시간차를 두는 이유가 이것이다. 두 cron의 순서가 곧 백업의 정합성이다.

5. “성공”을 검증하라

가장 흔한 착각: cron이 시간 맞춰 실행됐으면 백업이 된 줄 안다. 하지만 실행 ≠ 성공이다. 디스크가 꽉 찼거나 NAS가 잠깐 죽었으면, 0바이트짜리 빈 파일이 남는다.

백업이 끝나면 만들어진 파일 크기를 확인한다
일정 크기 미만이면 실패로 간주하고 알림을 보낸다
오래된 백업은 자동 삭제(rotate)해서 디스크가 차지 않게 한다

이 세 줄을 추가하는 순간, 백업은 “있는 줄 알았는데 비어 있던” 함정에서 벗어난다.

한 줄 정리

백업은 다른 장치에·자동으로·매일. tar czf - … | ssh면 포트 하나 더 안 열고 NAS에 던질 수 있다. DB 덤프 먼저, 그다음 파일 백업. 그리고 크기를 확인해 “성공”을 검증하자 — 비어 있는 백업은 백업이 아니다.

2026-06-04

공짜로 워드프레스 지키기 — Wordfence 무료판과 유료 함정

셀프호스팅 구축기 11편. 봇은 이미 8편에서 왔다. 이번엔 현관에 상주 경비를 세운다.

← 이전 편: 10편 — 블로그에 뭘 쓰면 안 되나 (개인정보 검열)
→ 다음 편: 12편 — 새벽마다 NAS로 (tar+ssh 백업)

요약

워드프레스는 전 세계 웹의 40%가 넘게 쓴다 — 그래서 자동 공격 봇의 1순위 표적
Wordfence 무료판이면 방화벽(WAF) · 2단계 인증(2FA) · 멀웨어 스캔이 전부 된다, 비용 $0
함정: 설치하면 화면이 무료를 숨기고 유료($149/년)로 유도한다 — 무료 키는 작은 밑줄 링크에 숨어 있다
무료와 유료의 진짜 차이는 “방화벽 룰을 30일 늦게 받는다”뿐 — 개인 블로그엔 무방
확장 방화벽은 PHP보다 앞에 서야 진짜 막는다 — .htaccess 한 줄, 켜기 전 백업 필수

1. 워드프레스는 왜 표적인가

전 세계 웹사이트의 40%가 넘게 워드프레스로 돈다. 점유율이 높다는 건 공격자 입장에서 취약점 하나로 수천만 사이트를 노릴 수 있다는 뜻이다.

8편에서 봤듯, 도메인을 공개하면 24시간 안에 로그인 페이지로 무차별 대입(brute force)이 들어온다. 사람이 아니라 자동 봇이다. 플러그인·테마의 알려진 구멍도 끊임없이 긁어 간다. 그래서 워드프레스는 “띄웠으면 바로 경비를 세워야 하는” 시스템이다.

2. Wordfence 무료판이 해주는 것

기능	무료판	설명
방화벽(WAF)	O	알려진 공격 패턴을 들어오는 길목에서 차단
2단계 인증(2FA)	O	비번이 털려도 한 겹 더 — 무차별 대입 1차 방어
멀웨어 스캐너	O	변조된 파일·심어진 백도어 탐지
실시간 악성 IP 차단	30일 지연	유료는 즉시, 무료는 30일 뒤 수신

개인 블로그가 진짜로 필요한 건 위 셋(방화벽·2FA·스캔)이고, 전부 무료다. 실시간 IP 목록은 대형 표적 사이트에나 의미 있는 차이다.

3. 무료 키 찾기 — 스토어의 유료 함정

설치하면 “라이선스를 받으세요” 화면이 뜨고, 누르면 워드펜스 스토어로 보낸다. 여기가 헷갈린다.

크고 파란 버튼 = “real-time protection” = 유료(연 $149). 장바구니에 자동으로 두 개가 담겨 더 비싸 보이기도 한다.
무료 키는 그 아래 작은 밑줄 링크에 숨어 있다: I'm OK waiting 30 days for protection updates(30일 늦게 받아도 괜찮아요).
이 링크를 눌러야 이메일로 무료 라이선스 키가 온다. 플러그인에 붙여넣으면 끝. 비용 $0.

결제 화면처럼 보이지만, 결제하지 않아도 된다. “30일 기다려도 괜찮다”는 문장 하나를 찾는 게 전부다.

4. 진짜 방어는 PHP보다 앞에 — 확장 방화벽

기본 상태의 방화벽은 워드프레스(PHP) 안에서 돈다. 즉 공격 요청이 이미 PHP까지 들어온 다음에 검사한다. 한 발 늦다.

“방화벽 최적화(Optimize)”를 켜면, PHP가 실행되기 전에 먼저 검사하도록 웹서버 설정(.htaccess)에 한 줄이 추가된다.

php_value auto_prepend_file '/var/www/html/wordfence-waf.php'

flowchart LR
    V[방문자/봇] --> W[확장 방화벽
PHP보다 먼저]
    W -->|정상| P[PHP / 워드프레스]
    W -->|공격| X[차단]

⚠️ 켜기 전에 반드시 .htaccess를 백업하자. 서버 환경에 따라 이 한 줄이 사이트를 500 에러로 만들 수 있는데, 그때 복구는 백업한 .htaccess를 되돌리는 것이다. 그리고 처음엔 “학습 모드”로 하루이틀 정상 트래픽을 익히게 둔 뒤 자동으로 보호 모드로 전환된다.

5. 로그인 자체를 숨기기 (보너스)

/wp-login.php는 전 세계가 아는 주소다. 별도 플러그인으로 로그인 주소를 다른 경로로 숨기면, 봇이 두드릴 문 자체가 사라진다. 어디로 숨겼는지는 당연히 공개하지 않는다 — 그게 핵심이다.

여기에 2FA를 켜고 “이 기기 7일 기억” 옵션을 쓰면, 보안은 챙기면서 매번 코드를 입력하는 번거로움은 던다.

한 줄 정리

무료 Wordfence면 개인 블로그 방어는 충분하다. 유료 유도 화면에서 “30일 기다려도 괜찮다”는 작은 링크만 찾으면 $0. 확장 방화벽은 켜기 전 .htaccess 백업, 로그인 주소는 숨기고 2FA. 돈이 아니라 클릭 몇 번의 문제다.

2026-06-04

블로그에 뭘 쓰면 안 되나 — 셀프호스팅 글의 개인정보 검열

셀프호스팅 구축기 10편. 서버를 막는 것만큼, 그 서버 이야기를 쓴 글을 막는 것도 중요하다.

← 이전 편: 9편 — 보이지 않는 다리: Cloudflare Tunnel
→ 다음 편: 11편 — 공짜로 워드프레스 지키기 (Wordfence)

요약

셀프호스팅 글은 본질적으로 내 서버 구조를 공개한다 — 튜토리얼 가치와 정찰 정보 사이의 줄타기
내가 실제로 흘린 것: 리눅스 계정명, 미니PC 내부 IP, 개인 이메일 (비번·토큰은 다행히 안 샘)
가려야 할 5가지: 시크릿 · 개인정보 · 내부 네트워크 · 파일 경로 · frontmatter
시크릿은 한 번 새면 교체밖에 답이 없다 — 검색엔진이 이미 긁어간 뒤다
발행 전 grep 한 줄이면 기계가 대신 훑어준다

1. 내가 실제로 흘린 것

9편까지 신나게 써놓고 다시 보니, 글 곳곳에 이런 게 박혀 있었다.

/home/내계정/... — 리눅스 계정명이 경로에 그대로. SSH 무차별 대입(brute force)의 표적이 된다.
http://192.168.x.x:3001 — 미니PC 내부 IP. 내 홈 네트워크 구조를 알려주는 셈.
도메인 설명하다 슬쩍 들어간 개인 Gmail 주소 한 줄.

비밀번호·토큰은 운 좋게 변수 placeholder나 <openssl rand -hex 24> 같은 예시값으로 써둬서 안 샜다. 하지만 위 셋은 진짜였다.

문제는 공개 블로그가 영구적이라는 점이다. 검색엔진이 인덱싱하고 캐시가 남는다. 지운다고 없던 일이 되지 않는다. 그래서 시크릿이 한 번 샜다면, 지우는 게 아니라 즉시 재발급해야 한다.

2. 가려야 할 5가지

분류	예시	왜 위험한가
① 시크릿	API 키·토큰·비번·개인키	계정·서버 탈취
② 개인정보	계정명·이메일·실명	신원·표적·스팸
③ 내부 네트워크	사설 IP·내부 호스트명·NAS 주소	침입 후 횡단 정찰
④ 파일 경로	/home/내계정/…	계정명·구조 노출
⑤ frontmatter	글 맨 위 메타데이터	발행 때 통째로 새기 쉬움

⑤번이 의외다. 마크다운으로 쓰면 글 맨 위에 ---로 둘러싼 메타데이터(frontmatter, 작성자·날짜·파일명 등)가 있는데, 발행 변환이 한 번 어긋나면 이게 본문에 코드블록으로 통째 노출된다. 실제로 내 글 하나가 그렇게 frontmatter를 다 드러내고 있었다.

3. 지우지 말고 일반화하라

핵심은 삭제가 아니라 치환이다. 튜토리얼 가치는 살리되 내 진짜 정보만 가린다.

실제	발행본
/home/내계정	/home/user
내부 IP 192.168.1.50	192.168.0.x 또는 <server-ip>
개인 이메일	[email protected]
비번·토큰	PASSWORD 변수, <your-token>

<openssl rand -hex 24>처럼 여기에 직접 생성한 값을 넣으세요라고 명시하면, 읽는 사람도 따라 하기 더 좋다. 일반화가 오히려 더 친절한 튜토리얼이 되는 셈이다.

4. 발행 전 자동 검사 (grep 한 줄)

눈으로 매번 잡으면 결국 샌다. 발행 전에 기계로 훑는다.

grep -rEn "/home/[a-z]+|[0-9.]+|@(gmail|naver)\.com|_TOKEN=|_KEY=|PASSWORD=" 내-글-폴더/

계정 경로·IP·개인 메일·시크릿 흔적을 한 번에 잡는다. 결과가 0줄이어야 발행. 변수·꺾쇠 플레이스홀더만 남으면 통과다.

발행한 뒤엔 실제 공개된 페이지도 한 번 더 본다. 캐시 때문에 옛 화면이 남아 있을 수 있어서다.

curl -s https://내도메인/글-주소/ | grep -E "/home/|192.168.|@gmail"

5. 더 큰 질문 — 애초에 공개할까?

개인정보를 다 가려도 남는 문제가 있다. 글 자체가 내 인프라 지도라는 것.

나는 글로 쓰지 않는 비공개 운영 도구를 따로 돌린다. 키와 IP를 아무리 가려도 이런 구조의 관리 도구가 여기 있다는 사실 자체가 정찰 정보이기 때문이다.

그래서 순서가 중요하다. 이 시리즈를 공개할까?를 먼저 정하고, 공개하기로 한 것만 앞의 검열을 거친다. 가릴 수 있는 정보와, 애초에 쓰면 안 되는 주제는 다른 층위의 문제다.

한 줄 정리

서버를 막는 P0가 있다면, 글을 막는 P0도 있다. 계정명·내부 IP·개인 메일·시크릿·frontmatter 다섯 가지를 플레이스홀더로 일반화하고, 발행 전 grep 한 줄로 검사하자. 시크릿은 새면 교체뿐이니, 처음부터 안 쓰는 게 가장 싸다.

2026-06-03

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

셀프호스팅 구축기 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