최근 외부 유입 채널을 다각화하기 위해 총 6개의 SNS 채널을 운영하고 있다. 그중 스레드는 원래 내 우선순위에서 3순위 정도에 머물러 있었다. 하지만 텍스트 기반 플랫폼 특성상 개발 관련 콘텐츠를 공유하기에 아주 적합하다는 판단이 들었고, 제대로 외부유입을 만들어보기 위해 자동화 작업을 시작했다.

처음에는 관리 효율을 위해 기존 서드파티 툴이나 반자동 방식을 고민하기도 했다. 하지만 플랫폼에 종속되기 싫었고 불필요한 비용을 줄이고 싶어 결국 서드파티 방식을 모두 기각하고 메타의 공식 Threads API를 직접 연동하는 완전 자동화 방식을 선택했다.

서드파티 대신 공식 Threads API 자동 발행을 선택한 이유

스레드는 다른 플랫폼처럼 단순히 RSS만 연결해 두면 끝나는 편리한 자동화 방식을 지원하지 않는다. 결국 메타의 공식 API를 직접 호출하는 방식이 필수적이었다. 이를 위해 Google Apps Script 환경에서 작동하는 Threads_자동발행.gs 파일을 새로 작성했다.

공식 API를 연동할 때 주의해야 할 점은 스레드의 독특한 발행 메커니즘이다. 스레드에 글을 올리려면 먼저 콘텐츠를 담을 컨테이너를 생성한 뒤, 약 30초의 대기 시간을 거쳐 실제 발행을 요청하는 2단계 발행 구조를 거쳐야 한다. API 호출 한 번으로 끝나지 않는 이 구조를 코드로 구현하느라 초반에 꽤나 애를 먹었다.

다행히 Apps Script의 대기 함수를 활용해 컨테이너 생성 후 안전하게 대기했다가 미디어를 발행하는 로직을 완성했다. 이로써 외부 서비스의 도움 없이 내 환경에서 직접 스레드로 콘텐츠를 보낼 수 있는 SNS API 연동의 뼈대를 갖추게 되었다.

60일의 덫, 장기 토큰 만료를 극복하는 자동 갱신 설계

API 연동을 하면서 가장 골치 아픈 부분은 단연 인증 토큰 만료 문제였다. 스레드 API는 보안상 60일의 유효 기간을 가진 장기 토큰을 사용한다. 만약 이 토큰을 제때 갱신해주지 않으면 60일 뒤에 잘 작동하던 자동 발행 파이프라인이 아무런 경고도 없이 조용히 끊겨버리는 대참사가 발생한다.

매번 캘린더에 적어두고 수동으로 토큰을 갱신하는 방식은 언젠가 반드시 까먹을 실패 패턴이었다. 그래서 장기 토큰 교환 및 갱신 함수를 완전히 독립된 모듈로 분리하여 설계했다. 그리고 Apps Script 시간 트리거 기능을 활용해 45일 주기로 토큰을 알아서 갱신하도록 자동 갱신 로직을 구현했다.

이렇게 설계해 두면 유효 기간이 보름이나 남은 시점에 매번 새로운 60일짜리 토큰으로 교체되므로 무중단 시스템을 유지할 수 있다. 이러한 단기 및 장기 토큰 갱신과 자동 갱신 설계 패턴은 비단 스레드뿐만 아니라 카카오나 네이버 등 다른 SNS API 연동 시에도 그대로 재사용할 수 있는 귀중한 기술적 자산이 되었다.

도달률 저하를 막기 위한 훅 문장 재가공

자동 발행 코드가 다 완성되었다고 해서 바로 발행할 수 있는 것은 아니었다. 스레드 알고리즘 특성상 성의 없이 원문 링크만 띡 던지는 포스트는 단순 재게시로 취급되어 사용자 피드에 노출되는 도달률이 급격히 줄어드는 리스크가 존재했다.

이를 방지하기 위해 발행할 원본 데이터에서 제목과 핵심 키워드를 추출해 매력적인 숏폼 형태의 훅 문장으로 재가공하는 buildThreadsHook_() 함수를 따로 만들었다. 링크만 공유하는 대신 독자의 시선을 사로잡을 수 있는 짧은 도입부를 먼저 배치하고 링크를 덧붙이는 구조다.

이렇게 콘텐츠 가공 로직까지 분리해 두니 API 자동 발행의 기계적인 느낌을 지우고 유기적인 도달을 유도할 수 있는 준비를 마칠 수 있었다. 사소해 보이지만 자동화 파이프라인에서 실제 트래픽 성과를 가르는 핵심적인 한 끗 차이라고 생각한다.

이제 코드는 모두 완벽하게 준비되었다. 남은 단계는 진경이가 메타 개발자 앱 등록을 마치고 Threads Tester 승인을 받은 뒤, 최종적으로 계정 소유자만 수행할 수 있는 OAuth 인증 절차를 완료하는 것이다. 실제 연동이 시작되기 전까지 계정 소유자의 승인 대기 상태이지만, 이번 삽질을 통해 탄탄한 API 갱신 아키텍처를 손에 넣은 것 같아 매우 뿌듯하다.