Threads에 글을 꾸준히 올리다 보면 작성보다 반복 작업이 더 피곤해진다. 주제를 정하고, 여러 게시물로 나누고, 순서를 확인하고, 발행 시간과 계정을 점검하는 일이 매번 이어진다.
이 과정을 Codex에 맡길 수는 있다. 다만 목표를 “AI가 알아서 올리게 만들기”로 잡으면 곧 문제가 생긴다. 계정 권한이 만료되거나, 잘못된 초안이 바로 공개되거나, 실패한 작업을 처음부터 다시 실행하는 상황이 발생하기 때문이다.
더 안전한 목표는 따로 있다. 원고 생성, 검수, 발행을 서로 다른 단계로 만들고 각 단계의 결과를 파일과 상태로 남기는 것이다. 이 글에서는 Claude Code나 Buffer 설정법이 아니라 Codex 프로젝트를 기준으로 그 구조를 설계한다.
대표 이미지는 원문 사이트의 이미지를 사용하지 않고 Img_Maker로 새로 생성한 개념 이미지다. 실제 Codex 화면이나 Threads 화면을 재현한 것이 아니다.
자동화의 단위를 ‘게시 버튼’에서 ‘상태가 있는 작업’으로 바꾸기
게시 버튼 하나를 자동으로 누르는 방식은 짧은 데모에는 잘 맞는다. 운영에서는 어떤 원고가 발행 대상인지, 누가 승인했는지, 요청이 몇 번 전송됐는지, 실패하면 어디부터 다시 시작해야 하는지를 답할 수 있어야 한다.
그래서 원고 하나를 idea → draft → reviewed → approved → submitted → published 상태로 관리한다. submitted는 발행 API에 요청을 보냈다는 뜻이고, published는 실제 응답이나 readback으로 공개 상태를 확인했다는 뜻이다. 둘을 같은 말로 취급하면 요청은 성공했지만 게시물은 없었던 상황을 놓치게 된다.
Codex에서는 프로젝트가 작업의 기준점이 된다
Codex는 대화창에 긴 프롬프트를 매번 붙여 넣는 방식으로만 쓰지 않는다. 프로젝트 안에 작업 규칙, 스킬, 원고 폴더, 검증 명령을 함께 두면 다음 실행에서도 같은 기준을 재사용할 수 있다. OpenAI의 공식 Codex 활용 예시도 반복 워크플로를 스킬로 저장하고 필요한 작업을 CLI와 조합하는 방향을 소개한다. OpenAI의 Codex 활용 예시
최소 구조는 다음처럼 잡는다.
threads-project/
├── AGENTS.md
├── .agents/skills/
│ ├── threads-draft/
│ ├── threads-review/
│ └── threads-publish/
├── content/
│ ├── drafts/
│ └── published/
├── state/
│ └── publication-state.json
└── scripts/
├── validate-thread.mjs
└── publish-thread.mjs
AGENTS.md에는 계정 범위, 금지된 외부 쓰기, 검수 조건, 실패 시 행동을 적는다. 토큰과 쿠키는 이 파일이나 Git에 넣지 않고 환경 변수나 운영체제의 보안 저장소에서 읽는다.
스킬은 세 개로 나누는 편이 오래 간다
1단계. 작성 스킬
작성 스킬은 주제를 여러 게시물로 바꾸고 파일로 저장한다. 첫 게시물의 역할, 후속 게시물의 전개, 글자 수, 출처 표기, 링크 위치를 규칙으로 고정한다. 계정에 접근하지 않는 것이 핵심이다.
2단계. 검수 스킬
검수 스킬은 문장을 예쁘게 고치는 역할을 넘어 사실, 반복 표현, 게시물 연결, 링크, 이미지, 광고성 문구를 검사한다. 결과는 pass, needs_revision, blocked처럼 제한된 상태로 남긴다.
3단계. 발행 스킬
발행 스킬은 새 원고를 작성하지 않는다. approved 상태인 파일만 읽고 계정 ID, 원고 해시, 예약 시간, 중복 발행 기록을 확인한 뒤 외부 요청을 보낸다. 하나라도 다르면 발행하지 않고 멈춘다.
이 게시물은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
긴 원고를 여러 차례 검토하고 작업 흐름을 관리하는 데스크톱 환경을 함께 살펴보려면 Apple 아이맥의 현재 판매 정보를 확인할 수 있다.
Buffer 중심 방식과 Codex 중심 방식은 다르다
외부 예약 서비스는 계정 연결과 큐 관리를 대신해 준다. 반면 Codex를 중심에 두면 서비스보다 먼저 작업 상태와 검수 경계를 설계한다.
공식 API를 직접 연결하면 토큰 갱신, 예약, 중복 방지, 결과 확인을 직접 구현해야 한다. 브라우저 자동화는 화면 변화와 로그인 상태에 취약하다. 예약 서비스를 쓰더라도 어떤 원고가 승인됐는지와 실패한 단계를 Codex 프로젝트에 남겨야 한다.
| 방식 | Codex가 책임질 부분 | 운영상 주의점 |
|---|---|---|
| 예약 서비스 | 원고 선택, 승인, 요청 기록 | 서비스의 계정 연결·예약 정책 확인 |
| 공식 API | 원고 조립, 토큰, 예약, 중복 방지, 결과 확인 | 권한 만료와 API 변경을 직접 관리 |
| 브라우저 조작 | 화면에서 수행할 동작과 복구 | UI 변경·로그인·CAPTCHA에 취약 |
실제 실행 흐름
- 원고 저장: Codex가 지정 폴더에 초안을 만든다. 이 단계에서는 외부 요청을 금지한다.
- 결정적 검증: 게시물 구분자, 글자 수, 빈 게시물, 중복 ID, 링크 형식을 스크립트로 검사한다.
- 독립 검토: 별도 검토 작업이 사실과 흐름을 다시 읽고 필요하면
needs_revision으로 돌려보낸다. - 사람 승인: 첫 게시물, 외부 링크, 계정, 예약 시각을 사람이 확인하고 승인 시각과 원고 해시를 기록한다.
- 발행·readback: 승인된 해시와 일치할 때만 요청하고, 게시물 ID나 공개 조회 결과를 확인한다.
이 이미지는 실제 서비스 화면이나 API 응답이 아닌, Codex 운영 경계를 설명하기 위해 새로 생성한 개념 이미지다.
예약 발행에서 놓치기 쉬운 것
시간은 KST 같은 기준 시간대를 포함한 날짜·시간으로 저장한다. 서버가 UTC인데 문자열만 전달하면 발행일이 어긋날 수 있다.
네트워크 응답이 끊겼다고 같은 원고를 다시 보내면 중복 게시물이 생긴다. 계정 ID + 원고 해시 + 예약 시각을 멱등 키로 만들고, 성공 기록이 있으면 재전송하지 않는다.
권한 만료와 원고 오류도 구분한다. auth_failed, validation_failed, publish_failed를 나눠야 토큰 문제 때문에 원고를 다시 쓰거나, 내용 문제를 인증 재시도로 해결하는 실수를 피할 수 있다.
여러 계정을 운영한다면 기본 계정에 기대지 말고 발행 요청마다 계정 ID를 명시한다. 계정별 토큰·큐·로그도 분리한다.
Codex용 최종 체크리스트
- 원고가 지정 폴더에 있고 승인 상태인가
- 출처와 사실 확인 결과가 남아 있는가
- 원문을 참고했더라도 문장과 구조를 새로 썼는가
- 원문 사이트의 이미지나 파일을 재사용하지 않았는가
- 계정 ID와 예약 시간대가 명시돼 있는가
- 발행 전 중복 확인과 발행 후 readback이 있는가
- 토큰·쿠키·개인키가 원고와 로그에 들어가지 않았는가
- 실패 시 실패한 단계만 다시 실행할 수 있는가
마무리
Threads 발행 자동화의 핵심은 AI가 사람을 완전히 대신하는 데 있지 않다. Codex 프로젝트에 원고, 규칙, 검수 결과, 승인 기록, 발행 상태를 남겨 반복 작업을 줄이고 실수를 좁히는 데 있다.
원고 생성과 발행을 나누고, 그 사이에 결정적 검사와 사람 승인을 둔다. 외부 서비스나 공식 API는 마지막 전달 수단으로 선택한다. 그러면 예약 서비스가 바뀌거나 API 권한이 만료되어도 콘텐츠와 검수 기록은 프로젝트 안에 남는다.