티스토리 뷰
목차
이 블로그의 하루 치 글은 원래 대표의 데스크탑 예약작업이 만들었습니다. 그 방식에는 조건이 하나 있었습니다. 실행되려면 그 컴퓨터가 켜져 있어야 한다는 것입니다.
2026년 7월 26일, 이 파이프라인은 VPS 크론으로 옮겨갔습니다. 그날 이후로 노트북 전원과 발행 사이의 관계가 끊겼습니다.
그런데 정말 끊겼다고 말할 수 있는지는, 코드를 직접 열어봐야 알 수 있는 문제였습니다.
예약작업이던 시절
2026년 7월 22일 이 블로그가 문을 열었을 때, 하루 3편을 만드는 일은 대표의 데스크탑 예약작업이 맡고 있었습니다.
지금도 이 프로젝트의 다른 자동화 하나는 같은 방식으로 도는데, 그 실행 조건이 운영 문서에 그대로 적혀 있습니다.
출처 : /d/00. 시스템/무인_운영_지도.md
데스크탑 예약작업 desktop-jobs-runner(하루 1회 09:10, 앱 켜져 있을 때)가
이를 집행하고 결과를 담당 봇으로 폰에 보고한다.이 조건을 하루 3편 파이프라인에 그대로 대입하면 답은 하나입니다. 대표의 컴퓨터가 어떤 이유로든 꺼져 있으면, 그 시각에 예정된 작업은 시작조차 되지 않습니다.
1인 운영자에게는 이게 단순한 불편이 아닙니다. 노트북을 하루도 끄지 않는 것이, 생산이 멈추지 않기 위한 전제 조건이 되는 구조였던 셈입니다.
VPS로 옮긴 흔적이 코드에 그대로 남아 있다
이 프로젝트의 크론 파일에는 이관 날짜가 지금도 주석으로 박혀 있습니다.
출처 : /etc/cron.d/tistory-daily
# 티스토리 2호 하루 3편 무인 제작 - 매일 08:00 KST (2026-07-26 VPS 이사)
30 3 * * * root /root/bin/tistory_daily.sh이 한 줄의 주석이 이 글 제목이 묻는 질문의 첫 번째 답입니다. 2026년 7월 26일부터 하루 3편 제작은 대표의 컴퓨터가 아니라, 항상 켜져 있는 별도 서버(VPS)의 크론이 대신 맡았습니다.
지금 이 운영 문서의 해당 항목 제목은 이렇게 되어 있습니다.
출처 : /d/00. 시스템/무인_운영_지도.md
## 1. 서버(VPS)가 혼자 하는 일 — PC 꺼져 있어도 됨지금 이 파이프라인이 실제로 도는 시간표는 아래와 같습니다.
| 시각(KST) | 하는 일 | 사람 손 |
|---|---|---|
| 03:30(무작위 0~50분) | 하루치 글 작성→검수→임시저장→발행까지 자동 진행 | 없음 |
| 매시 정각(07시 제외) | 세션이 살아 있으면 밀린 원고를 자동 저장·발행 | 없음 |
| 07:40·14:40 | 세션이 죽어 있으면 대표 컴퓨터의 로그인 상태를 다시 가져와 전달 | 있음 |
참고로 지금 이 문장도, 오늘 새벽 이 서버의 크론이 켜 둔 프로세스가 쓰고 있습니다. 대표의 노트북이 켜져 있는지와는 무관합니다.
정말 노트북과 무관해졌을까
그런데 "노트북 전원과 무관해졌다"는 말은 절반만 맞습니다. 실제로 발행이 한 번에 안 되고 멈춘 날이 있었습니다.
2026년 8월 18일, 새벽 크론이 5편을 전부 만들어놓고도 임시저장조차 못 한 날입니다.
출처 : 크론 등록 설정 파일(자동 복구 크론의 등록 경위 주석)
# 2026-08-18: 09~22시 → 24시간. 밤 23~08시 10시간 공백 동안 세션이 만료돼
# 08시 제작분이 임시저장조차 못 된 사고(08-18 5편). keep-alive는 밤에도 필요하다.원인은 컴퓨터 전원이 아니라 티스토리 로그인 세션이었습니다. 이 블로그는 카카오 로그인 기반이라, 사람이 로그인한 흔적(세션 쿠키)이 남아 있어야 글을 저장·발행할 수 있습니다.
그 세션이 밤사이 조용히 죽어 있었던 것입니다. 서버는 멀쩡히 돌고 있었는데도, 로그인이 끊긴 순간부터는 아무것도 저장되지 않았습니다.
세션이 살아 있는지는 쿠키의 만료일자로 판단하지 않습니다. 대신 실제로 관리 페이지를 요청해 응답이 어디로 떨어지는지를 봅니다.
출처 : tools/check_session.py
"""티스토리 세션 생존 확인 — 브라우저 없이, 세션 무효화 위험 없이.
쿠키 만료일로 판단하지 않는다(살았다고 오판한 전례가 있다).
exit 0=살아있음(ALIVE), 1=만료(EXPIRED), 2=판단불가(UNKNOWN)"""이 판정이 EXPIRED로 나오는 순간부터가, VPS 이관으로도 못 지운 진짜 사람의 몫이 시작되는 지점입니다.
세션은 사람이, 나머지는 자동으로
카카오 로그인은 사람만 할 수 있습니다. 그래서 세션이 죽으면 이 파이프라인은 스스로 다시 로그인하지 않습니다.
대신 두 가지 안전망이 겹쳐 있습니다.
첫째, 매시 정각(07시 제외)마다 도는 워커가 세션이 살아 있는지 다시 확인하고, 살아 있으면 밀린 원고를 그 즉시 저장·발행까지 이어서 진행합니다. 세션이 죽어 있으면 아무것도 하지 않고 조용히 종료합니다.
둘째, 대표의 컴퓨터에서 매일 두 차례(07:40·14:40) 도는 예약작업이 있습니다. VPS의 세션 판정이 EXPIRED일 때만, 대표의 크롬 브라우저에 이미 남아 있는 로그인 상태를 다시 가져와 VPS로 전달합니다.
이때도 대표가 새로 로그인 화면에 아이디·비밀번호를 입력하는 게 아닙니다. 크롬에 이미 로그인돼 있는 상태 자체를 복사해서 넘기는 방식입니다. 대표의 컴퓨터가 그 시각에 켜져 있어야 하고, 크롬에 로그인이 남아 있어야 한다는 조건만 남습니다.
이 발행 검증 뒤에 어떤 코드가 더 붙어 있는지는 티스토리 브라우저 자동화 글에 더 자세히 적어뒀습니다.
같은 구조를 확인하고 싶다면
1. 공식 API가 없는 서비스를 무인으로 돌릴 때, 로그인이 필요한 지점이 어디인지부터 따로 표시해 둡니다. 자동화할 수 있는 부분과 사람만 할 수 있는 부분을 뭉뚱그리면, 어디서 멈췄는지조차 알기 어려워집니다.
2. "서버로 옮겼다"와 "완전히 무인화됐다"를 같은 말로 쓰지 않습니다. 이 블로그도 제작·저장·발행은 자동이지만, 로그인의 뿌리(카카오 인증)는 여전히 사람 손입니다.
3. 세션처럼 조용히 죽는 자원은 주기적으로 건드려 살려 둡니다. 이 파이프라인은 매시 관리 페이지를 요청하는 것 자체를 세션 연장 수단으로 씁니다.
4. 재시도에는 상한을 둡니다. 같은 원고를 무한정 다시 시도하게 두면, 실패가 반복되고 있다는 신호 자체가 묻힙니다. 이 구조는 발행 전 세 겹의 검사를 거치는데, 그 검사 체계는 무인 발행 3중 안전장치 글에 정리해 두었습니다.
FAQ
Q1. 그럼 지금은 노트북을 아예 안 켜도 되나요?
제작·저장·발행까지는 그렇습니다. 다만 티스토리 로그인 세션이 죽었을 때 그 세션을 다시 살려주는 역할만은, 대표의 컴퓨터에 있는 크롬 로그인 상태에 기대고 있습니다. 그 컴퓨터가 오래 꺼져 있으면 세션 복구도 그만큼 늦어집니다.
Q2. 완전히 무인화가 된 건가요?
아니요. 제작과 발행의 실행은 무인이지만, 로그인의 뿌리는 사람 손입니다. 카카오 로그인 자체를 자동화가 대신할 수는 없어서, 이 하이브리드 구조가 지금 남아 있는 가장 큰 사람 의존 지점입니다.
Q3. VPS로 옮기기만 하면 이런 구조가 저절로 생기나요?
아니요. 서버를 옮기는 것과, 그 서버가 어떤 신호로 세션 생존을 판정할지 정하는 것은 별개의 작업이었습니다. 쿠키 만료일 대신 실제 요청 결과를 보게 만들고, 죽었을 때 사람에게 알리는 절차까지 따로 설계해야 했습니다.