9222 전용 프로필과 플랫폼별 로그인 상태를 구분해 티스토리만 복구할지 바로 판단할 수 있다.
한 플랫폼의 로그아웃을 전체 세션 장애로 오해하면 정상 계정까지 다시 인증하거나 발행 전용 환경을 다른 프로필로 바꿀 수 있기 때문이다.
읽기 전에 확인할 근거
블로그 자동발행 로그인 복구는 9222 포트가 열렸는지만 보지 말고 전용 프로필과 플랫폼별 로그인 상태를 따로 확인해야 해요. 2026년 8월 4일 preflight에서는 블로거와 네이버는 유지됐고 티스토리만 로그인이 필요해, 다른 계정은 건드리지 않고 티스토리만 복구하는 것으로 범위를 정했습니다.
쉽게 말하면 9222는 자동발행 프로그램이 Chrome으로 들어가는 전용 출입문이에요. 블로거·티스토리·네이버 로그인은 그 안에 있는 서로 다른 세 개의 열쇠에 가깝습니다. 출입문이 열려 있다고 세 열쇠가 모두 정상인 것은 아니고 열쇠 하나가 풀렸다고 나머지까지 다시 만들 필요도 없어요.
오늘 preflight가 알려준 것은 한 가지였어요
당일 점검에서 확인할 문제는 전체 로그인 장애가 아니었습니다. 블로거와 네이버 세션은 유지됐고 티스토리만 로그인 복구가 필요한 상태였어요.
- 블로거: 기존 로그인 상태 유지
- 네이버: 기존 로그인 상태 유지
- 티스토리: 로그인 복구 필요
- 공개 발행: 로그인 재검사가 끝날 때까지 진행하지 않음
여기서 멀쩡한 블로거나 네이버까지 로그아웃한 뒤 다시 연결하면 작업 범위만 커져요. 추가 본인확인이 생길 수도 있고 정상 세션을 잃을 수도 있습니다. 그래서 preflight가 지목한 플랫폼만 손보는 것이 이번 운영 기록의 핵심이에요.
9222가 열렸다는 것과 로그인이 됐다는 것은 달라요
Chrome DevTools Protocol 공식 문서에 따르면 원격 디버깅 포트를 켠 Chrome은 /json/version에서 브라우저 정보와 연결 주소를, /json/list에서 현재 디버깅할 수 있는 대상을 보여줍니다. 이 응답은 브라우저에 연결할 수 있다는 증거이지 티스토리 로그인이 완료됐다는 증거는 아니에요.
프로젝트의 기계 플레이북에는 한 단계가 더 있습니다. 9222를 사용하는 Chrome의 사용자 데이터 위치가 발행 전용인 chrome-blog-debug인지 먼저 대조하도록 정해져 있어요. 다른 작업이 임시 Chrome을 같은 포트로 실행했다면 세 플랫폼이 한꺼번에 로그아웃된 것처럼 보일 수 있기 때문입니다.
Chrome도 원격 디버깅에는 기본 사용자 데이터가 아닌 별도의 user-data-dir를 사용하라고 안내합니다. 이 기준은 단순한 폴더 정리가 아니라, 평소 쓰는 Chrome 정보와 자동화용 환경을 분리하는 보안 경계예요.
- 9222가 응답하지 않으면 전용 Chrome 실행 상태부터 확인해요.
- 9222가 응답해도 chrome-blog-debug 프로필인지 대조합니다.
- 프로필이 맞을 때만 플랫폼별 preflight 결과를 로그인 판정에 사용해요.
티스토리만 복구하는 실제 순서
전용 프로필이 맞고 티스토리만 로그인 필요로 나왔다면 카카오 계정의 정상 로그인 절차만 진행해요. 블로거용 Google 로그인이나 네이버 계정은 건드리지 않습니다.
- 9222를 사용하는 Chrome이 chrome-blog-debug 프로필인지 확인해요.
- blog-publish preflight에서 티스토리만 로그인 필요로 표시됐는지 다시 봅니다.
- 같은 전용 Chrome에서 티스토리 관리 화면을 한 탭으로 열어요.
- 티스토리가 제공하는 카카오 로그인 경로로 진행합니다.
- 추가 본인확인, 비밀번호 재입력, 보안 알림이나 캡차가 나오면 자동 진행을 멈춰요.
- 사용자가 정상 인증을 마친 뒤 preflight만 다시 실행합니다.
- 티스토리가 통과로 바뀌었는지 확인하고 이 로그인 복구 작업에서는 글을 공개하지 않아요.
티스토리는 카카오 계정 기반이라 블로거에서 쓰던 ‘Google로 계속하기’를 대신 누르는 방식이 맞지 않아요. 로그인 수단이 다르면 정상 세션 복구가 아니라 엉뚱한 계정 연결로 이어질 수 있습니다.
자동화가 넘지 않아야 할 선도 분명해요
이번 절차는 저장된 정상 세션이 있는 전용 프로필을 다시 확인하는 운영 복구예요. 계정 보호 장치를 건너뛰거나 인증을 대신 풀어 주는 절차가 아닙니다.
- 저장되지 않은 비밀번호를 추측하거나 가져오지 않아요.
- 캡차와 추가 본인확인을 자동으로 통과시키지 않습니다.
- 다른 Chrome 프로필의 쿠키를 복사하지 않아요.
- 로그인 복구가 끝났다는 이유만으로 공개 발행 성공을 단정하지 않습니다.
- 인증 실패 상태에서 게시 작업을 반복해 중복 글을 만들지 않아요.
회사 계정처럼 관리 정책이 적용된 환경, 카카오 계정 자체가 잠긴 경우, 등록된 휴대전화 확인이 필요한 경우에는 이 순서만으로 끝나지 않을 수 있어요. 그때는 플랫폼이 보여주는 정상 복구 안내에 따라 계정 소유자가 직접 확인해야 합니다.
복구 완료의 기준은 화면이 아니라 재검사예요
티스토리 관리 화면이 열렸다는 사실만으로 완료라고 기록하지 않아요. preflight를 다시 실행해 티스토리 로그인 판정이 통과로 바뀌었는지 확인해야 합니다.
이후 실제 발행을 시작할 때도 별도의 검증이 남아요. 발행큐의 준비 상태, 원고와 이미지 검수, 공개 후 라이브 제목·본문·대표이미지 확인까지 마쳐야 발행완료가 됩니다. 로그인 복구와 공개 성공은 서로 다른 단계예요.
오늘 기록의 범위는 여기까지입니다. 9222 전용 프로필을 보존하고 정상인 블로거와 네이버는 그대로 두며 티스토리만 정상 로그인 절차로 복구한 뒤 preflight로 다시 판정하는 것까지예요.
확인한 기준
2026년 8월 4일에 실제 소유 산출물인 publish/README_발행큐.md와 블로그_마스터_자료/02_기계_플레이북.md를 대조하고 당일 preflight에서 블로거·네이버 로그인 유지와 티스토리 로그인 필요 상태를 확인했어요. 계정명·쿠키·비밀번호 같은 개인정보는 확인 대상과 공개 내용에서 제외했습니다.
- Chrome DevTools Protocol 공식 문서: 9222 HTTP 엔드포인트와 브라우저 연결 정보
- Chrome DevTools Protocol Target 도메인: 디버깅 대상 조회와 연결 범위
- Chrome for Developers: 원격 디버깅 포트와 별도 user-data-dir 보안 기준
티스토리의 추가 인증 여부와 이후 공개 발행 결과는 확인하지 않았어요. 로그인 화면에서 보안 확인이 나타나면 자동 통과를 시도하지 말고 계정 소유자가 직접 처리해야 합니다.