손 안 가는 서버 — cron으로 굴러가는 작은 자동화들

셀프호스팅 구축기 14편(마지막). 백업도(12편) 동기화도(13편) 결국 “정해진 시각에 알아서” 돌아야 한다. 그 엔진이 cron이다.

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

요약

• cron(크론)은 정해진 시각에 명령을 돌리는 리눅스 기본 스케줄러 — 따로 설치할 것 없다
• 우리 서버가 매일 알아서 하는 일: 백업 · DB 덤프 · 캐시 정리 · 헬스체크 · 요약 생성
• crontab 한 줄 = 분·시·일·월·요일 + 실행할 명령
• 함정 1: cron엔 PATH가 거의 없다 → 절대경로 안 쓰면 “command not found”
• 함정 2: 조용한 실패 — 로그로 안 남기면, 안 돈 걸 며칠 뒤에야 안다

1. cron이 뭔가 — 설치 없는 알람시계

cron은 리눅스에 기본으로 들어 있는 알람시계다. “매일 새벽 4시 반에 이 스크립트 실행”처럼 시각과 명령을 등록해 두면, 컴퓨터가 켜져 있는 한 알아서 돌린다. 셀프호스팅에서 반복되는 잡일은 거의 다 cron에 맡길 수 있다.

2. crontab 한 줄 읽는 법

등록 목록을 crontab이라 부른다. 한 줄은 다섯 칸의 시각 + 명령으로 이루어진다.

*는 “매번”이라는 뜻이다. 그래서 30 4 * * *는 매일 4시 30분이 된다.

30 4 * * *   /home/user/bin/db-dump.sh    >> /var/log/db-dump.log 2>&1
0  5 * * *   /home/user/bin/backup.sh      >> /var/log/backup.log 2>&1

3. 우리 서버가 매일 하는 일

작은 cron들이 쌓여 “손 안 가는 서버”를 만든다.

• DB 덤프 — 데이터베이스를 안전한 파일로 (백업보다 먼저)
• 파일 백업 — NAS로 전송 (12편)
• 캐시 정리 — 쌓인 임시 파일·만료 캐시 비우기
• 헬스체크 — 서비스가 살아 있는지 확인, 죽었으면 알림
• 요약 생성 — 어제 방문자·에러 한 장으로 정리

4. 초보가 꼭 밟는 함정 3개

① PATH가 없다. 터미널에서 잘 되던 명령이 cron에선 “command not found”로 죽는다. cron은 최소한의 환경에서 돌아 PATH가 거의 비어 있기 때문이다. 해결: 명령을 절대경로로 쓰거나(/usr/bin/python3), 스크립트 맨 위에 PATH를 직접 지정한다.

② 조용한 실패. cron은 에러가 나도 화면에 안 띄운다. 기본적으로 메일로만 보내는데 아무도 안 본다. 그래서 위 예시처럼 >> 로그파일 2>&1로 출력과 에러를 파일에 남겨야, 안 돌았을 때 추적이 된다.

③ 시간대. 서버 시계가 UTC인지 한국 시간(KST)인지 확인하자. 30 4 * * *로 “새벽 4시 반”을 노렸는데 서버가 UTC면 한국 시각으로는 오후 1시 반에 돈다.

5. 작은 자동화의 복리

cron 하나하나는 사소하다. 백업 한 줄, 캐시 정리 한 줄. 그런데 이게 쌓이면 내가 매일 손대지 않아도 서버가 스스로를 돌보는 상태가 된다. 셀프호스팅의 목표는 결국 이거다 — 만들어 놓고, 잊어버려도 굴러가는 것.

이 시리즈도 여기서 한 바퀴를 돈다. 빈 컴퓨터 한 대에서 시작해(1편), 블로그를 올리고, 도메인을 붙이고, 막고, 백업하고, 이제 자동으로 굴러가게 했다. 다음은 직접 한 대 세워 보는 일만 남았다.

한 줄 정리

cron은 “정해진 시각에 알아서”의 엔진이다. 한 줄에 분·시·일·월·요일 + 명령. 단 세 가지만 조심하자 — 절대경로로 쓰고, 로그를 남기고, 시간대를 확인할 것. 작은 자동화가 쌓이면 서버는 손이 안 가게 된다.

내 노트는 내 서버에 — Obsidian LiveSync + CouchDB 셀프호스팅

셀프호스팅 구축기 13편. 블로그를 내 서버에 올렸으면, 메모도 내 서버에 둘 수 있다.

← 이전 편: 12편 — 새벽마다 NAS로 (tar+ssh 백업)
→ 다음 편: 14편 — 손 안 가는 서버 (cron 자동화)

요약

• Obsidian 공식 싱크는 월정액 — 노트를 내 서버 데이터베이스에 직접 동기화하면 비용 0원 + 데이터 주권
• 방법: Self-hosted LiveSync 플러그인 ↔ CouchDB(도커 컨테이너) 실시간 양방향
• CouchDB는 반드시 127.0.0.1에만 묶는다 — 도커가 자동으로 0.0.0.0에 여는 함정을 조심
• 내 기기들만 닿게: 사설 네트워크(VPN 메시) 안에서만 접근, 인터넷에는 비공개
• 삽질 일지: ERR_SSL_PROTOCOL_ERROR의 범인은 인증서가 아니라 “뒤에 서버가 안 떠 있던 것”

1. 왜 공식 싱크 대신 셀프호스트인가

Obsidian(옵시디언)은 노트 앱이고, 여러 기기에서 같은 노트를 보려면 동기화가 필요하다. 공식 Sync는 잘 되지만 월정액이다. 그리고 내 메모가 남의 서버를 거친다.

이미 블로그용 서버가 굴러가고 있으니, 노트 동기화도 거기 얹으면 된다.

대가는 “직접 구성”이다. 한 번 세우면 그 뒤로는 공식만큼 매끄럽다.

2. 구조 — 플러그인 ↔ CouchDB

CouchDB(카우치DB)는 변경분을 실시간으로 주고받는 데 강한 데이터베이스다. LiveSync 플러그인이 노트가 바뀔 때마다 CouchDB로 보내고, 다른 기기는 그걸 당겨 온다.

flowchart LR
    PC[노트북 Obsidian] -->|변경분| DB[(CouchDB / 내 서버 도커)]
    Phone[폰 Obsidian] -->|변경분| DB
    DB -->|동기화| PC
    DB -->|동기화| Phone

3. 절대 0.0.0.0에 열지 마라

여기가 가장 중요하다. CouchDB를 도커로 그냥 띄우면 포트가 0.0.0.0(모든 네트워크 인터페이스)에 열린다. 이러면 같은 와이파이의 다른 기기, 심지어 잘못 설정된 공유기 너머까지 내 데이터베이스가 노출된다.

ports:
  - "5984:5984"             # 위험: 0.0.0.0, 모든 인터페이스에 노출
  - "127.0.0.1:5984:5984"   # 안전: 내 컴퓨터 자신만 접근

127.0.0.1에만 묶으면 서버 바깥에서는 보이지 않는다. 그럼 폰은 어떻게 접속하냐고? 사설 네트워크(VPN 메시) 안에서만 닿게 한다. 내 기기들끼리만 연결된 가상 LAN을 만들고, CouchDB는 그 안에서만 https로 노출한다. 인터넷 전체에는 끝까지 비공개다.

4. 삽질 일지 — ERR_SSL_PROTOCOL_ERROR

설정을 마치고 https 주소로 접속했더니 브라우저가 ERR_SSL_PROTOCOL_ERROR를 뱉었다. 당연히 인증서 문제인 줄 알고 인증서만 한참 들여다봤다. 아니었다.

진짜 원인은 단순했다. CouchDB 컨테이너 자체가 안 떠 있었다. https 주소(앞단)는 만들어 놨는데 그 뒤에서 받아 줄 서버가 없으니, TLS 연결이 끝까지 맺어지지 못하고 브라우저가 “SSL 오류”로 보고한 것이다.

교훈: “SSL 에러”가 항상 인증서 문제는 아니다. 앞단(주소·인증서)과 뒷단(실제 서버)을 나눠서, 뒷단이 살아 있는지부터 확인하자. curl로 백엔드 포트를 직접 찔러 보면 5초 만에 갈린다.

한 줄 정리

노트 동기화도 내 서버로 가져올 수 있다 — LiveSync 플러그인 + CouchDB면 구독료 0원. 단, CouchDB는 127.0.0.1에만 묶고 사설 네트워크로만 접근. 그리고 ERR_SSL_PROTOCOL_ERROR를 만나면 인증서보다 뒷단 서버가 살아 있는지를 먼저 의심하자.

새벽마다 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)를 켜야 한다. 포트를 하나 더 여는 것이다.

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

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 덤프 먼저, 그다음 파일 백업. 그리고 크기를 확인해 “성공”을 검증하자 — 비어 있는 백업은 백업이 아니다.

공짜로 워드프레스 지키기 — 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 무료판이 해주는 것

개인 블로그가 진짜로 필요한 건 위 셋(방화벽·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. 돈이 아니라 클릭 몇 번의 문제다.

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

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

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

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

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

<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 한 줄로 검사하자. 시크릿은 새면 교체뿐이니, 처음부터 안 쓰는 게 가장 싸다.