티스토리 Open API 종료 후 자동 발행 구축기 (CDP 브라우저 자동화)

티스토리 Open API는 2024년 2월에 완전히 종료되었습니다. 글 작성, 수정, 파일 첨부까지 전부 막혔고, 지금 엔드포인트를 호출하면 404만 돌아옵니다. 그런데도 여러 블로그를 운영하다 보면 예약 발행 자동화가 절실해지는 순간이 옵니다. 이 글은 API 없이 티스토리 자동 발행을 실제로 구축하면서 겪은 과정과 함정을 정리한 기록입니다.

남아 있는 선택지 확인

먼저 공식 경로가 정말 없는지 확인했습니다. 아래 세 가지를 직접 호출해 본 결과입니다.

open.tistory.com                 → 404
www.tistory.com/apis/post/write  → 404
API 앱 등록 페이지                 → 404

공식 문서 저장소에도 종료 안내만 남아 있습니다. 결국 남는 대안은 세 가지였습니다.

1) 수동 붙여넣기 — 가장 안전하지만 자동화가 아닙니다. 2) 이메일 발행 — 기능 자체가 유지되는지 불확실하고 예약·카테고리 제어가 안 됩니다. 3) 브라우저 자동화 — 티스토리 글쓰기 화면을 프로그램이 직접 조작하는 방식입니다. 결국 3번밖에 없습니다.

구조: 로그인은 사람이, 반복은 기계가

브라우저 자동화에서 가장 먼저 부딪히는 문제는 로그인입니다. 카카오 계정 비밀번호를 스크립트에 넣는 방식은 보안상 최악이고, 2단계 인증에서 어차피 막힙니다. 그래서 구조를 이렇게 잡았습니다.

크롬을 디버깅 포트로 실행 (전용 프로필)
  chrome.exe --remote-debugging-port=9222
             --user-data-dir=...전용폴더

→ 사람이 이 창에서 한 번만 로그인
→ 세션이 프로필에 남음
→ 자동화 도구는 CDP로 이 크롬에 붙어서 조작만 함

자동화 도구는 비밀번호를 아예 모릅니다. 이미 로그인된 브라우저를 빌려 쓸 뿐입니다. 평소 쓰는 크롬과 프로필을 분리해 두면 서로 영향도 없습니다.

발행할 글은 로컬 대시보드의 대기열에 쌓아 두고, 스케줄러가 몇 분마다 대기열을 확인해서 발행 시각이 지난 글만 처리하게 했습니다. 발행이 끝나면 결과를 대기열에 다시 보고합니다. 이렇게 하면 워드프레스처럼 API가 있는 블로그와 같은 워크플로우로 관리할 수 있습니다.

에디터 조작에서 만난 함정 세 가지

1. 저장 확인창이 모든 것을 멈춘다

티스토리는 임시저장된 글이 있으면 글쓰기 화면 진입 시 "저장된 글이 있습니다. 이어서 작성하시겠습니까?"라는 confirm 창을 띄웁니다. 문제는 이 네이티브 대화상자가 떠 있는 동안 CDP의 JavaScript 실행이 전부 타임아웃된다는 점입니다. 게다가 이 창은 페이지 이동 후, 저장 후에도 다시 나타납니다.

해결은 모든 스크립트 실행 전에 Page.handleJavaScriptDialog로 대화상자를 먼저 닫는 것입니다. 항상 "아니오"로 답해서 대기열의 내용으로 새로 시작하게 했습니다. 대화상자가 없을 때 호출하면 에러가 나므로 그냥 무시하면 됩니다.

2. 본문은 iframe 안의 TinyMCE

제목은 일반 textarea(#post-title-inp)라 값을 넣으면 되지만, 본문 에디터는 iframe(#editor-tistory_ifr) 안의 TinyMCE입니다. iframe의 contentDocument.body.innerHTML에 HTML을 직접 넣고, tinymce.activeEditor.fire('change')로 변경을 알려야 저장 대상으로 인식됩니다. 이 구조 덕분에 오히려 HTML 원문을 그대로 밀어 넣을 수 있어서, 워드프레스용으로 만든 본문을 재사용할 수 있었습니다.

3. 프레임워크가 합성 이벤트를 무시한다

input.value에 값을 넣고 input 이벤트를 dispatch하는 고전적인 방법이 티스토리 관리 화면 곳곳에서 통하지 않았습니다. 저장 버튼이 비활성 상태로 남습니다. 화면이 실제 키 입력을 기준으로 상태를 갱신하기 때문입니다. CDP의 Input.insertText나 실제 키 이벤트를 쓰면 해결됩니다. 겉보기에 값이 들어가 있어도 프레임워크 상태는 비어 있을 수 있다는 점이 브라우저 자동화의 흔한 함정입니다.

예약 발행의 경계

발행 레이어를 열면 공개 범위(공개/보호/비공개), URL 슬러그, 발행일(현재/예약)을 제어할 수 있습니다. 예약 모드의 시·분은 평범한 number input이라 값만 넣으면 되는데, 날짜는 달력 팝업 버튼이라 자동화 난도가 올라갑니다. 저는 당일 예약만 지원하고, 다른 날짜가 지정되면 조용히 잘못 발행되는 대신 명시적으로 실패하게 만들었습니다. 자동화에서 확신 없는 동작은 실패로 처리하는 편이 낫습니다.

이 방식의 정직한 한계

API 기반과 달리 이 구조는 화면에 의존합니다. 티스토리가 에디터 구조를 바꾸면 셀렉터가 깨지고, 그때마다 다시 맞춰야 합니다. 실행 중에는 PC와 크롬이 켜져 있어야 하고, 로그인 세션이 만료되면 사람이 다시 로그인해야 합니다. 발행 빈도가 낮다면 그냥 수동 붙여넣기가 합리적일 수 있습니다.

반대로 여러 블로그를 정해진 리듬으로 운영한다면 이 구조는 값어치를 합니다. 글 작성과 검수는 대시보드에서 한 번에 하고, 발행은 플랫폼별로 알아서 흘러가게 되기 때문입니다. 같은 대기열에서 워드프레스는 REST API로, 티스토리는 브라우저 자동화로 나가는 구조를 만들어 두면 플랫폼이 늘어나도 워크플로우는 그대로 유지됩니다.

다음 글에서는 이 대기열의 반대편, 워드프레스 REST API 예약 발행에서 겪은 타임존 함정을 다루겠습니다.