Threads API 자동 게시기: 승인 없이 하루 10개를 올릴 때 넣은 안전장치

회사 Threads 계정에 올릴 글을 매번 제가 승인하다가, 어느 날 승인을 없애기로 했습니다. 하루 10개 안팎을 사람 손 없이 올리는 구조를 하루 만에 만들었고, 이 글은 승인이라는 안전장치를 빼는 대신 무엇을 넣었는지에 대한 기록입니다.

글을 쓰는 쪽과 올리는 쪽을 둘로 나눈 구조

처음에는 글을 쓰는 세션이 곧바로 API를 부르게 할 생각이었습니다. 그러면 글을 쓰다 실수한 순간 그 실수가 바로 공개됩니다. 그래서 둘을 나눴습니다.

글 쪽은 AI 세션이 맡습니다. 매일 그날 올릴 글 10개를 써서 큐 파일에 넣습니다. 항목은 글 id, 본문, 올릴 시각, 소재 출처이고, 날짜마다 파일 하나입니다.

올리는 쪽은 외부 라이브러리 없이 내장 모듈만 쓰는 작은 Node 스크립트입니다. 10분마다 예약 실행으로 돌면서 큐를 읽고, 올릴 때가 된 글 하나만 올립니다. 글을 고치는 일은 하지 않고 읽기만 합니다.

올릴 시각은 정각 간격으로 두지 않았습니다. 09:12, 10:41, 11:58처럼 분 단위를 들쭉날쭉하게 잡았고, 글 사이 간격은 30분 이상입니다.

심사 없이 내 계정에만 게시되는 개발 모드

Meta 개발자 사이트에서 앱을 만들었습니다. 사용 사례는 Threads API 액세스이고, 권한은 threads_basic과 threads_content_publish 둘만 붙였습니다. 글을 지우는 threads_delete는 일부러 붙이지 않았습니다. 자동으로 도는 시스템이 지울 수 있게 하고 싶지 않았기 때문입니다.

앱을 개발 모드로 둔 채 제 계정을 Threads 테스터로 등록하고 초대를 수락했습니다. 앱 심사 없이 제 계정에는 게시할 수 있었고, 이건 직접 해 보고 확인한 사실입니다.

게시는 두 단계입니다. 먼저 미디어 컨테이너를 만들고, 그 컨테이너를 게시합니다. 두 호출 모두 200으로 확인했습니다. 올린 글은 응답으로 받은 id로 다시 읽어 같은 글인지 대조할 수 있습니다.

한도는 하루 게시 250개, 답글은 따로 1,000개입니다. 하루 10개는 한도의 4%이니 한도 때문에 막힐 일은 없습니다.

토큰은 채팅이 아니라 권한 600 파일로 받았습니다

앱 설정의 사용자 토큰 생성기에서 장기 토큰을 받았습니다. 유효 기간은 60일이고, 갱신은 발급 24시간 뒤부터 만료 전까지만 됩니다.

토큰을 채팅에 붙이면 대화 기록에 값이 영구히 남습니다. 그래서 빈 템플릿 파일을 만들어 권한을 600으로 두고, 거기에 붙여 넣게 했습니다. 읽은 뒤에는 값을 출력하지 않고 길이와 앞뒤 몇 글자로만 확인했습니다.

한 가지 주의할 점이 있습니다. Threads는 일부 호출에서 토큰을 주소의 쿼리로 받습니다. 요청 주소를 로그에 그대로 찍으면 토큰이 로그에 남으므로, 게시기는 주소 전체를 기록하지 않고 올린 글의 id와 링크만 남깁니다.

승인을 대신하는 안전장치 아홉 개

승인이 사라지면 잘못된 글을 막을 사람이 없습니다. 그래서 게시기가 스스로 멈출 수 있는 지점을 코드에 넣었습니다.

장치	하는 일
정지 파일	파일이 하나라도 있으면 아무것도 올리지 않습니다. 누구든 이 파일만 만들면 멈추고, 지우면 재개됩니다
하루 상한	하루 10개를 넘기면 거절합니다
중복 차단	같은 id, 같은 글 해시는 두 번 올리지 않습니다
직전 재확인	올리기 직전에 큐와 정지 파일을 다시 읽습니다
간격	30분 안에 연속으로 올리지 않습니다
늦은 글 건너뛰기	올릴 시각에서 3시간 넘게 밀린 글은 올리지 않습니다
실패 처리	실패하면 한 번만 다시 시도합니다
기록	올린 글의 id와 링크만 남기고 토큰은 어디에도 남기지 않습니다
첫 실행은 드라이런	올리지 않고 로그만 남기는 시험을 먼저 돌렸습니다

이 가운데 정지 파일이 가장 쓸모 있다고 봅니다. 「멈춰」라는 말 한마디를 파일 하나로 바꿔 둔 것이라, 세션이 누구든 그 파일만 만들면 됩니다.

글의 내용에 대한 규칙도 따로 정했습니다. 사실이 필요한 글은 검색 결과 요약이 아니라 공식 페이지 본문을 직접 확인합니다. 확인하지 못한 소식은 쓰지 않습니다. 겪지 않은 일을 겪은 것처럼 쓰는 경험담은 쓰지 않고, 누가 봇이냐고 물으면 부정하지 않습니다.

정정 지시가 실행이 끝난 뒤에 도착한 사고

「둘 다 올려」라고 지시했습니다. 그 직후 게시기가 두 글을 올리기 시작했고, 1분쯤 뒤에 「한 개만」이라는 정정이 왔습니다. 호출은 이미 끝난 뒤였고 둘 다 올라갔습니다.

잘못은 지시를 바꾼 데 있지 않습니다. 사람이 막을 틈이 생기기 전에 실행이 끝나는 구조였습니다. 되돌릴 수 없는 일은 실행 직전에 가장 최근 지시를 다시 읽어야 합니다. 게시기의 직전 재확인이 그래서 생겼고, 이제는 큐를 고치면 올리기 직전에 반영됩니다.

같은 파일을 둘이 쓰면 한쪽이 사라진다는 규칙

두 세션이 같은 날짜의 큐 파일에 시험 글을 넣다가 한쪽 글이 지워졌습니다. 그 뒤로 오늘치 큐는 글 쪽만 쓰고, 게시기는 읽기만 하기로 정했습니다. 파일 하나에는 쓰는 주인이 하나여야 합니다.

비슷하게, 사용자에게 같은 확인을 두 세션이 따로 보낸 일도 있었습니다. 같은 질문을 두 번 받으면 어느 답이 어느 질문에 대한 것인지 흐려집니다. 한 가지 일은 한쪽이 맡는 것으로 정리했습니다.

아직 하지 못한 일과 측정하지 못한 것

이미지와 동영상은 올리지 못합니다. Threads API가 공개 인터넷 주소를 요구하는데, 아직 그 주소를 마련하지 못했습니다.

토큰 갱신은 코드를 넣었지만 실제로 돌려 보지는 못했습니다. 만료 10일 전부터 새 토큰을 받아 파일을 다시 쓰도록 짰고, 파일은 임시 파일에 쓴 뒤 권한을 600으로 맞추고 이름을 바꾸는 순서라 중간에 깨지지 않습니다. 그런데 갱신 호출 자체는 한 번도 실행해 보지 않았습니다. 시험한 것은 만료까지 남은 기간을 보고 지금은 갱신하지 않는다고 판단하는 부분뿐입니다. 만료일도 토큰을 만든 날부터 60일로 계산한 추정이고, 공식 응답으로 확인한 값이 아닙니다. 첫 실제 갱신은 만료 전에 처음 일어나게 되니, 그전에 한 번 직접 시험해 볼 계획입니다.

컨테이너를 만든 뒤 게시하기까지 얼마나 기다리는 것이 좋은지도 공식 문서로 확인하지 못해서, 이 글에서는 단정하지 않습니다.

가장 중요한 것은 아직 모른다는 점입니다. 하루 10개가 적당한 양인지, 팔로워가 어떻게 반응하는지는 며칠 돌려 봐야 압니다. 지금까지 확인한 것은 막히지 않고 올라간다는 사실까지입니다.