[태그:] 블로그

야크 셰이빙, 멱등성, 도그푸딩, 데드맨 스위치 — 코드 밖에서도 통하는 개발 용어 4개

개발자들이 쓰는 말 중엔 코드보다 일하는 방식을 가리키는 게 많다. 오늘 넷이 그렇다 — 곁가지에 홀리는 함정, 몇 번을 해도 안전한 반복, 내놓기 전에 내가 먼저 써보기, 내가 멈췄을 때 안전하게 멈추는 장치. 알아두면 협업할 때도 혼자 일할 때도 쓰인다.

요약

야크 셰이빙: 진짜 할 일을 하려다 곁가지가 꼬리를 물어 엉뚱한 데서 시간을 다 쓰는 것
멱등성: 몇 번을 실행해도 결과가 한 번 한 것과 같은 성질 (재시도해도 안전)
도그푸딩: 남에게 내놓기 전에 내가 먼저 사용자로 써보는 것
데드맨 스위치: 내가 “살아있다”는 신호를 멈추면 시스템이 자동으로 안전하게 정지하는 장치
넷의 공통점: 코드 용어 같지만 실은 집중·안전·정직·대비라는 일의 태도

용어	한 줄 뜻	일에서는
야크 셰이빙	곁가지가 꼬리를 물어 본질을 잃음	집중
멱등성	여러 번 해도 결과가 한 번과 같음	안전한 반복
도그푸딩	내놓기 전 내가 먼저 써봄	정직한 검증
데드맨 스위치	내가 멈추면 시스템이 안전하게 정지	실패 대비

1. 야크 셰이빙 (Yak Shaving)

차를 닦으려는데 호스가 없다. 호스를 사려니 마트 회원카드가 만료됐고, 갱신하려니 옆집이 빌려간 책을 돌려줘야 하고… 정신을 차려보니 동물원에서 야크 털을 깎고 있다. 정작 차는 그대로다.

이렇게 진짜 목표를 위해 시작한 곁가지 작업이 꼬리에 꼬리를 물어, 원래 일과 상관없어 보이는 데서 시간을 다 쓰는 것이 야크 셰이빙이다. MIT에서 나온 표현이라고 알려져 있다.

개발에서 흔하다. “버그 하나 고치자” → “그러려면 라이브러리 업데이트” → “그러려면 빌드 도구 교체” → 반나절째 환경 설정 중. 일상도 똑같다 — 글 하나 쓰려다 블로그 테마부터 손보고 있는 것.

빠져나오는 법: “지금 이게 원래 하려던 일에 정말 필요한가?”를 한 번 묻는다. 아니면 곁가지는 메모만 남기고 본 작업으로 돌아온다.

2. 멱등성 (Idempotency)

엘리베이터 버튼을 열 번 눌러도 한 번 누른 것과 똑같이 온다. 이게 멱등성이다 — 같은 동작을 여러 번 해도 결과가 한 번 한 것과 같은 성질.

원래 수학 용어(f(f(x)) = f(x))인데, 개발에선 특히 재시도 안전에서 중요하다. 결제 요청을 보냈는데 응답이 안 와 다시 보냈다고 하자. 멱등하지 않으면 두 번 결제된다. 멱등하면 같은 요청은 한 번만 처리된다 — 요청마다 붙이는 “멱등 키”로 구분한다.

구분도 쉽다. “삭제”는 멱등이다(이미 지운 걸 또 눌러도 여전히 지워진 상태). “1개 추가”는 멱등이 아니다(누를 때마다 늘어남).

왜 알면 좋나: 자동화·재시도가 들어가는 모든 곳(결제·알림·동기화)에서 “이게 두 번 실행되면 사고가 나나?”를 판단하는 기준이 된다.

3. 도그푸딩 (Dogfooding)

“자기 개밥 자기가 먹기(eat your own dog food).” 개사료 회사가 자기 개에게 그 사료를 먹이며 품질을 증명했다는 데서 나왔고, 1988년 마이크로소프트가 “우리 소프트웨어를 우리가 먼저 쓰자”는 뜻으로 퍼뜨렸다고 알려져 있다.

뜻은 단순하다 — 남에게 팔거나 내놓기 전에, 내가 먼저 사용자로 써보는 것. 직접 써봐야 버그도 잡고, 사용자가 어디서 불편한지 몸으로 안다.

핵심은 정직이다. 내가 안 쓰는 도구를 남에게 권하긴 어렵다. 반대로 내가 매일 쓰는 도구는 빠르게 좋아진다 — 불편하면 내가 제일 먼저 아프니까.

한 칸 더 — 도그푸딩은 “내가 써보기”까지다. 그다음 칸은 모르는 남이 써보는 것이고, 진짜 시험은 거기서 시작된다.

4. 데드맨 스위치 (Dead Man’s Switch)

기차 기관사가 운전 중 쓰러지면 어떻게 될까. 옛 기차엔 페달이 있었다. 기관사가 페달을 계속 밟고 있어야 기차가 달리고, 발을 떼면(쓰러지면) 기차가 자동으로 멈춘다. 이 장치가 데드맨 스위치다.

이름은 섬뜩하지만 발상은 단순하다 — 내가 멈췄을 때, 시스템이 알아서 안전하게 멈추는 것. 평소엔 “나 살아있다”는 신호를 계속 보내야 하고, 그 신호가 끊기면 최악을 가정하고 안전 쪽으로 작동한다.

개발·자동화에서 그대로 쓴다. 자동매매 봇이 응답을 멈추면 포지션을 자동으로 정리한다(안 그러면 시장이 급변해도 무방비). 서버가 주기적 “심장박동(heartbeat)”을 못 보내면 다른 서버가 대신 깬다.

왜 알면 좋나: 무인으로 도는 모든 것(봇·크론·자동화)에 “이게 죽으면 어떻게 안전하게 멈추지?”를 미리 심는 발상이다. 켜는 것보다 죽을 때를 설계하는 것이 진짜 안전이다.

한 줄 정리

세 용어는 코드가 아니라 태도를 가리킨다.

야크 셰이빙 → 곁가지에 홀리지 말고 본질에 집중하라
멱등성 → 반복·재시도해도 안전하게 설계하라
도그푸딩 → 내놓기 전에 내가 먼저 써봐라
데드맨 스위치 → 잘 돌 때가 아니라 죽을 때를 설계하라

이름을 알면 일이 어디서 새는지 가리킬 수 있다. 개발자와 대화할 때도, 혼자 일할 때도.

2026-06-07

포트를 하나도 안 열고 — 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

탭이 안 되는 링크 — 텔레그램에서 옵시디언 노트 열기

셀프호스팅 구축기 15편. 구축기를 마쳤어도 막상 쓰다 보면 후속 문제가 나온다 — 13편에서 동기화한 노트, 그 링크가 폰에서 탭이 안 됐다.

← 이전 편: 13편 — 내 노트는 내 서버에 (Obsidian LiveSync)

요약

옵시디언 노트는 obsidian://open?vault=...&file=... 형태의 고유 링크를 가진다
이 링크를 텔레그램으로 보내면 파란 링크가 아니라 회색 죽은 글씨 — 탭이 안 된다
원인: 채팅앱은 http/https만 자동으로 링크화한다. obsidian:// 같은 커스텀 스킴은 무시
해결: https 주소 한 단을 끼운다 — https로 받아서 브라우저가 obsidian://로 튕기는 “셔틀” 페이지
그 셔틀을 집 서버 대신 Cloudflare Worker(서버리스)에 올렸다 — 집 컴퓨터가 꺼져도 동작, 비용 0원

1. 증상 — 회색으로 죽은 링크

옵시디언은 노트마다 고유 링크를 준다. 노트를 우클릭해 “obsidian URL 복사”를 누르면 obsidian://open?vault=내볼트&file=폴더/노트 같은 주소가 잡힌다. 이걸 텔레그램으로 보내면 파란 글씨가 될 줄 알았는데, 회색 평문으로 떴다. 눌러도 아무 일도 안 일어난다. 링크가 아니라 그냥 글자였던 것이다.

2. 원인 — 채팅앱은 http/https만 링크로 만든다

채팅앱은 메시지 글자를 훑어 URL을 찾으면 자동으로 탭 가능한 링크로 바꾼다. 단 이 자동 변환은 http://·https://(그리고 텔레그램 자체의 tg://)에만 적용된다. obsidian://·notion://·slack:// 같은 앱 전용 커스텀 스킴은 변환 대상이 아니라 평문으로 남는다. 텔레그램 iOS 저장소에도 “커스텀 URI 스킴 링크는 클릭이 안 된다”는 같은 이슈가 올라와 있다.

버튼이나 마크다운 링크로 우회하면 되지 않냐 — 그것도 안 된다. 봇이 메시지에 붙이는 인라인 버튼·링크 역시 http/https/tg만 허용한다. 커스텀 스킴은 거부된다.

3. 정석 패턴 — https “셔틀” 한 단 끼우기

커스텀 스킴이 직접 못 가니, 중간에 https를 한 번 거치게 한다.

텔레그램에는 https 링크를 보낸다 → 파란 링크가 된다
탭하면 브라우저가 그 https 페이지를 연다
그 페이지의 자바스크립트가 obsidian://로 튕긴다 → 옵시디언이 열린다

이 패턴은 새로운 게 아니다. obsid.net이라는 공개 무료 서비스가 정확히 이 일만 한다 — vault와 file을 받아 브라우저에서 obsidian://로 넘겨주는 정적 페이지다. 그대로 써도 된다.

4. 그런데 왜 직접 만들었나

obsid.net이 있는데 굳이 직접 만든 이유는 이 시리즈의 일관된 이유와 같다.

제3자를 안 거친다 — 내 볼트 이름과 노트 경로가 남의 서버(로깅을 안 한다 해도)를 지나가지 않는다
내 도메인 — o.내도메인 한 줄, 링크가 내 것
내가 페이지를 통제 — 자동 이동이 막힐 때 누를 버튼, 어떤 노트인지 보여주는 파일명을 직접 넣을 수 있다 (7절 함정 때문에 중요하다)

처음엔 이미 띄워 둔 다른 앱의 정적 폴더에 페이지를 하나 얹었다. 작동은 했지만, 알림용 리다이렉트를 상관없는 앱 안에 끼워 넣은 꼴이라 경계가 더러워졌다. 리다이렉트는 어느 앱에도 속하지 않는 범용 유틸이다. 그래서 떼어내 독립시켰다.

5. 어디에 둘까 — 집 서버 vs 엣지

독립시킨다면 둘 중 하나다.

	집 서버에 작은 웹서버	Cloudflare Worker(엣지)
동작 조건	집 컴퓨터가 켜져 있어야	집 컴퓨터 꺼져도 동작
인증서	직접 발급·갱신	자동
비용	전기	무료(하루 10만 요청)
종속	없음	Cloudflare

리다이렉트는 1초짜리 정적 응답이라 집 서버를 굳이 깨워 둘 이유가 없다. Cloudflare Worker를 골랐다 — 코드 한 조각을 클라우드 엣지에 올리면 서버를 직접 굴리지 않고도 응답한다(이걸 서버리스라 한다). 6편에서 산 도메인이 이미 Cloudflare에 있으니 서브도메인 하나 붙이면 끝이다.

6. 작동 — https가 받아서 obsidian://로 튕긴다

Worker가 하는 일은 짧다. ?f=노트경로를 받아, 그걸 obsidian:// 링크로 바꾼 HTML 한 장을 돌려준다.

export default {
  async fetch(request) {
    const url = new URL(request.url);
    const file = url.searchParams.get('f') || '';
    const vault = url.searchParams.get('v') || 'MyVault';
    const uri = 'obsidian://open?vault=' +
      encodeURIComponent(vault) + '&file=' + encodeURIComponent(file);
    const html = '<!doctype html><meta charset=utf-8>'
      + '<p>' + file + '</p>'
      + '<a href="' + uri + '">노트 열기</a>'
      + '<script>setTimeout(function(){location.href=' + JSON.stringify(uri) + '},350)</' + 'script>';
    return new Response(html, {
      headers: { 'content-type': 'text/html; charset=utf-8' }
    });
  }
}

텔레그램에는 https://o.내도메인/?f=노트경로만 보낸다. 이건 https라 파란 링크가 되고, 탭하면 위 페이지가 떠서 옵시디언으로 넘긴다.

7. 함정 셋

① 자동 이동이 막힌다. location.href = obsidian://...로 자동 전환을 걸어도, 모바일 브라우저(특히 안드로이드 크롬·채팅앱 내장 브라우저)는 사용자가 직접 누르지 않은 커스텀 스킴 이동을 보안상 막는 경우가 있다(“Navigation is blocked”). 그래서 자동 이동에만 기대면 안 되고, 사용자가 탭할 “노트 열기” 버튼을 반드시 같이 둔다. 자동 전용 페이지가 가끔 안 먹는 이유가 이거다.

② 볼트 이름이 기기마다 다르다. obsidian://open?vault=X의 X는 그 기기에 등록된 볼트 표시 이름과 정확히 같아야 한다. PC에선 열리는데 폰에선 “노트 없음”이 뜨면 십중팔구 볼트 이름이 다른 것이다. 옵시디언 포럼에도 “안드로이드에서 앱은 열리는데 노트는 안 열린다”는 같은 사례가 있다. 링크에 &v=폰볼트이름을 맞춰 주면 된다.

③ 동기화가 먼저다. 링크는 노트를 여는 거지 만들어 주는 게 아니다. 그 노트가 폰에 동기화돼 있어야(13편 LiveSync) 열린다.

8. 비용

Cloudflare Worker: 0원 (무료 플랜 하루 10만 요청)
도메인: 이미 보유(6편), 서브도메인 추가비 없음
집 서버 부담: 없음(엣지가 응답)

한 줄 정리

채팅앱은 http/https만 링크로 만든다. obsidian:// 같은 앱 링크는 https 셔틀 한 단을 끼워야 탭이 된다. 그 셔틀을 Cloudflare Worker에 올리면 집 서버와 무관하게 공짜로 돈다. 단 자동 이동은 막힐 수 있으니 버튼을 같이 두고, 볼트 이름을 기기에 맞춰라.

2026-06-06

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

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

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

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