Field Log · Entry
Tistory·네이버 블로그 자동화에 실패하고 git으로 간 이야기 (1/3)
업무 기록을 블로그로 남기려고 Tistory와 네이버에 자동 게시 스크립트를 붙이려 했습니다. 결과는 실패였습니다. 로그인 단계의 CSRF·캡차·2FA가 모두 막아섰고, 정식 API에도 한계가 있었습니다. 결국 git push 한 번으로 끝나는 개인 도메인 정적 블로그로 옮겼습니다. 이 글은 그 1차 시도의 회고입니다.
이 글이 답하는 질문
- 왜 Tistory·네이버 자동화는 안 되는가? 정식 API로도 안 되는가?
- 1년 전엔 GitHub Pages도 못 만들던 사람이 어떻게 개인 도메인 블로그까지 갔나?
- “딸깍” 배포가 왜 꾸준함의 핵심인가?
왜 블로그 자동화를 시도했나
저는 파트타임 산업공학 박사과정이고, 낮에는 반도체 장비 PHM 데이터 파이프라인과 사내 RAG를 다룹니다. 이 일들을 하다 보면 그날 안 적으면 일주일 뒤에 사라지는 통찰이 매일 나옵니다. 그래서 업무 기록을 블로그로 남기기로 했습니다.
문제는 매번 수동 게시였습니다. 글을 쓴 다음에도 로그인하고, 카테고리를 고르고, 태그를 넣고, 썸네일을 올리고, 공개 설정을 확인합니다. 한 글당 5~10분의 의식 자원이 더 듭니다. 이 마찰이 쌓이면 어느 순간 “오늘은 그냥 메모장에만 적자”가 됩니다.
마찰은 꾸준함의 가장 큰 적입니다. 한 번에 5분짜리 작업도 매일 하기로 마음먹는 순간 50분이 되는 일이 자주 있습니다.
그래서 자동화를 결정했습니다. 글만 쓰면 나머지 단계는 스크립트가 처리하게 만들고 싶었습니다.
1차 시도: Tistory·네이버 자동 게시 스크립트
먼저 가설은 단순했습니다. 로그인 폼을 분석하고, 토큰을 추출하고, 글 작성 API에 POST 한다. 평소 사내 RAG에서도 비슷한 방식으로 외부 시스템을 자동화하던 패턴이었습니다.
requests로 Tistory 로그인을 시도해 봤습니다 (아래는 당시 시도를 단순화한 재현 코드입니다).
import requests
from bs4 import BeautifulSoup
s = requests.Session()
login_page = s.get("https://www.tistory.com/auth/login")
csrf = BeautifulSoup(login_page.text, "html.parser").find("input", {"name": "csrf"})["value"]
res = s.post("https://www.tistory.com/auth/login", data={
"loginId": USER, "password": PWD, "csrf": csrf,
})
# (재현 시연) 200 응답을 받지만 캡차 챌린지 페이지로 리다이렉트되며 종료200은 떴습니다. 그런데 본문이 캡차 챌린지 페이지였습니다. CSRF 토큰만 맞춰서는 통과되지 않았습니다.
다음으로 Playwright로 네이버를 시도했습니다 (마찬가지로 단순화한 재현 코드입니다). 헤드리스 브라우저면 실제 사용자처럼 동작하니 더 잘될 거라 기대했습니다.
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
page = p.chromium.launch().new_page()
page.goto("https://nid.naver.com/nidlogin.login")
page.fill("#id", USER); page.fill("#pw", PWD)
page.click("#log\\.login")
# (재현 시연) 2FA OTP 화면 + 헤드리스 자동화 탐지로 종료이번엔 2FA OTP 화면에서 멈췄습니다. 헤드리스 자동화 탐지가 같이 걸린 건지, 새 IP라서 그런 건지 분리하지 못했습니다. 어느 쪽이든 매번 사람이 OTP를 넣어야 한다면 자동화의 의미가 없습니다.
“그럼 정식 API를 쓰면 되지 않나”가 다음 가설이었습니다. 그래서 Tistory 오픈 API와 네이버 개발자센터 블로그 API를 봤습니다. 둘 다 발급 자체는 가능하지만 한계가 분명했습니다.
- Tistory 오픈 API: 신규 발급이 사실상 동결돼 있어서 새로 키를 받기 어렵습니다.
- 네이버 블로그 글쓰기 API: 본인 인증·앱 등록·심사 절차가 있고, 마크다운 그대로 올라가지 않아서 변환 레이어를 또 만들어야 합니다.
캡차·2FA·노봇 정책은 우회 대상이 아니라 신호였습니다. 이 플랫폼은 “사람이 직접 올리는 글”을 가정하고 만들어졌고, 그 가정을 깨려면 정책 위반과 계정 정지 위험을 같이 떠안아야 합니다. reCAPTCHA 같은 봇 탐지 시스템은 자체 정책으로도 우회 시도를 약관 위반으로 정의합니다.
2차 시도: GitHub Pages — 1년 전엔 못 만든 이유
자동화가 어렵다면 발상을 바꿔야 했습니다. 로그인이 필요 없는 게시 방식, 즉 정적 사이트 + git push.
GitHub Pages는 git push가 곧 배포라서 자동화 친화적입니다. 그런데 사실 1년 전에도 한 번 시도했다가 접었습니다. 이유는 단순했습니다.
- Jekyll·Ruby 환경 진입장벽: macOS에서 Ruby 버전 충돌, gem 설치 오류로 한나절을 썼습니다.
- 한국어 폰트와 디자인 통제: 기본 테마는 한글 자간이 어색했고, 커스텀하려면 또 Liquid 템플릿을 배워야 했습니다.
- 도메인이
*.github.io라서 검색 권위가 약하다는 인상.
당시 결론은 “이거 만들 시간에 글 한 편 더 쓰자”였습니다. 그래서 다시 Tistory로 돌아갔고, 그 결과가 이번 자동화 실패였습니다. 1년이 지나서 다시 시도하니 환경이 달라졌습니다. 바이브 코딩이라고 부를 만한 흐름이 생겼고, AI 에이전트가 환경 설정을 같이 잡아주면서 진입장벽이 낮아졌습니다.
”딸깍” — 마찰을 0으로 만든다는 것
여기서 자주 등장하는 단어가 “딸깍”입니다. 마우스 한 번, 단축키 한 번에 끝난다는 뜻입니다.
수동 게시는 7단계입니다. 글 작성 → 로그인 → 캡차/2FA → 카테고리 → 태그 → 썸네일 → 게시. 단계마다 의식 자원이 빠져나갑니다. git push는 2단계입니다. 글 작성 → push.
“딸깍”은 단순히 짧다는 뜻이 아닙니다. 의식 자원과 결정 피로를 모두 0에 가깝게 만든다는 뜻입니다.
박사과정 일정과 본업 사이에서 글을 쓸 수 있는 시간은 보통 새벽 1시간, 그리고 점심 30분뿐입니다. 이 시간에 5분짜리 게시 마찰이 들어오면, 글의 결론을 다 적기 전에 그날 끝납니다.
사내 RAG 시스템도 비슷한 이유로 로그인을 한 번 더 묻는 쪽보다 한 번에 끝나는 쪽이 사용률이 훨씬 높았습니다. 마찰 한 단계 = 사용률 절반이라는 경험칙은 블로그에도 그대로 적용됩니다.
결정 트리: 자동화 × 마찰 × 검색 노출 (3축)
자동화 가능성만으로는 부족했습니다. 글이 검색에 노출돼야 꾸준함의 보상이 생깁니다. 그래서 세 축으로 비교했습니다.
| 후보 | 자동화 | 마찰 | 검색 노출 |
|---|---|---|---|
| Tistory·네이버 | 실패 (로그인 보안) | 높음 (수동 7단계) | 중 — 플랫폼 권위는 있으나 도메인은 빌리는 것 |
| GitHub Pages | 가능 (git push) | 중 (Jekyll 진입장벽) | 중 — *.github.io 도메인 권위 약함 |
| 개인 도메인 정적 사이트 | 가능 (git push) | 낮음 | 높음 (시간 필요·통제 가능) ← 선택 |
세 번째 줄에서 “검색 노출 높음”에는 시간 필요라는 단서가 붙습니다. 신규 도메인은 구글 샌드박스 효과로 3~6개월은 거의 안 잡힙니다. 그래도 “통제 가능 변수가 가장 많은 쪽”을 골랐습니다. 디자인·구조·내부 링크·메타 태그·Core Web Vitals 모두 직접 만질 수 있고, 시간이 지나 도메인 연령이 쌓이면 그 통제력이 그대로 누적됩니다.
스택은 Astro로 정했습니다. 정적 빌드 + MDX 지원 + 한국어 폰트 통제가 쉽고, 빌드 산출물을 Railway에 올려 git push 자동 빌드, 도메인은 Cloudflare에서 관리합니다. 1년 전이라면 이 셋 중 하나에서 막혔겠지만, 지금은 AI 에이전트가 환경 설정을 같이 잡아주면서 한 주 만에 배포 라인까지 갔습니다.
결론: git 기반 정적 사이트 + 개인 도메인
처음 메모장에 적었던 한 단락은 이랬습니다.
“꾸준히 하기 위해 ‘딸깍’이 중요하다 생각. 개인 도메인에서 블로그하면 검색 최적화로 돈도 벌 수 있지 않을까. 이건 요즘 바이브 코딩이 가능해서 가능. 1년 전만 해도 github 블로그도 복잡해서 못 만들던 내가 개인 도메인 블로그를 개설.”
이게 1편의 결론입니다. 자동화가 막혔다고 글쓰기를 그만두는 게 아니라, 내가 통제할 수 있는 인프라로 옮기는 것. 그리고 그 이동이 1년 전엔 불가능했지만 지금은 가능하다는 것.
도착점은 이 사이트 자체입니다.
다음 편에서는 이 도착점에 어떻게 갔는지를 다룹니다. Astro + Railway + Cloudflare 스택의 구체적 설정, git push에서 배포까지 30초 안에 끝나는 파이프라인, 그리고 신규 도메인이라 구글에 안 잡히던 첫 2주를 어떻게 넘겼는지까지.
FAQ
Q1. 스크립트로 Tistory·네이버를 우회하면 정말 안 되나요? 기술적으로 불가능하지는 않지만 권장하지 않습니다. CSRF·캡차·2FA·노봇 정책을 우회하면 약관 위반이 되고, 계정이 정지되면 그동안 쓴 글도 같이 묶입니다. 자동화의 목적은 꾸준히 글을 쌓는 것인데 그 꾸준함의 토대가 흔들리는 건 본말전도입니다.
Q2. 왜 GitHub Pages가 아니라 Astro인가요? Astro와 GitHub Pages는 직접 비교 대상이 아닙니다. Astro는 프레임워크, GitHub Pages는 호스팅입니다. 이 글에서 비교한 건 (a) Jekyll로 GitHub Pages를 직접 운영하는 방식 vs (b) Astro로 빌드해 다른 호스팅(저는 Railway)에 올리는 방식입니다. (b)를 고른 이유는 세 가지입니다. (1) Jekyll·Ruby 환경 진입장벽보다 Astro + Node 쪽이 지금 시점에서 더 쉽습니다. (2) 한국어 폰트·디자인 통제가 MDX와 잘 맞습니다. (3) 호스팅을 분리하면 빌드 결과를 어디든 옮길 수 있어 락인이 약합니다.
Q3. 개인 도메인 블로그로 수익화가 가능한가요? 단기적으로는 어렵습니다. 신규 도메인은 구글 샌드박스 효과로 3~6개월간 검색 노출이 극히 적습니다. 백링크와 도메인 연령이 쌓여야 광고·제휴 모두 의미 있는 트래픽이 들어옵니다. 1년 단위 누적 게임으로 보는 게 맞습니다.
Q4. 이 시리즈는 몇 편으로 끝나나요? 3편입니다. 1편(이 글) — 자동화 실패와 결정. 2편 — Astro·Railway·Cloudflare 스택 구축기. 3편 — 신규 도메인이 구글에 안 잡히던 시기와 검색 등록·내부 SEO로 넘긴 방법.
마무리
- Tistory·네이버 자동 게시는 로그인 단계의 CSRF·캡차·2FA에서 막혔고, 정식 API도 발급·변환 한계로 실용적 대안이 아니었습니다.
- 1년 전 GitHub Pages를 못 만들던 같은 사람이 지금 개인 도메인 블로그를 만든 차이는 AI 에이전트와 함께 하는 바이브 코딩으로 환경 설정 비용이 줄었다는 점입니다.
- “딸깍” 배포는 단축키가 짧다는 뜻이 아니라 의식 자원과 결정 피로를 0에 가깝게 만든다는 뜻이고, 이게 꾸준함의 실제 변수입니다.
다음에 읽으면 좋은 글
- (2/3) Astro + Railway + Cloudflare로 git push 30초 배포 파이프라인 만들기 — 준비 중
- (3/3) 신규 도메인이 구글에 안 잡히던 2주, Search Console·네이버 등록·내부 SEO로 넘긴 방법 — 준비 중