이 기사에서 알 수 있는 것

• GitHub Actions + Claude API + X API v2를 이용한
  X(Twitter) 운영 완전 자동화 시스템의 전체상 - AI 트윗 생성 시 페르소나를 무너뜨리지 않는 프롬프트 (Prompt) 설계
• 인플루언서 분석을 트윗 생성에 자동으로 피드백하는 메커니즘
• 팔로우 백 (Follow-back) 비율 스코어링을 통한 효율적인 팔로우 전략
• JSON 파일 + git commit을 이용한 데이터베이스가 필요 없는 상태 관리 패턴

실제로 가동 중인 시스템이므로, 모두 실제 경험을 바탕으로 한 내용이다.

시스템 전체상

Node.js 스크립트 12개, GitHub Actions 워크플로우 10개로 구성되어 있다. 하루의 타임라인은 다음과 같다.

07:30 패턴 게시 (tips/learning 계열)
08:00 AI 캐주얼 트윗
10:00 Zenn 기사 공개 + X 알림
...

주간 태스크로서, 월요일에는 인플루언서 분석, 일요일에는 계정 성장 분석이 실행된다.

전체 아키텍처 (Architecture)는 다음과 같다.

GitHub Actions (cron)
├── 트윗 게시 (1일 최대 8회)
│ ├── casual-tweet.js … AI 생성 일상 트윗
...

페르소나 설정 기술

AI로 트윗을 생성하면, 그대로 두었을 때 "AI스러운" 느낌이 나온다. "아침 커피를 마시며 오늘의 개발 계획을 세우고 있습니다."와 같은 식이다. 이를 방지하기 위해 프롬프트 (Prompt) 설계에 상당히 공을 들였다.

인격 정의를 프롬프트에 주입하기

casual-tweet.js의 프롬프트에서는 페르소나를 구체적으로 작성하고 있다.

const prompt = `REON이라는 30세 프리랜서 IT 컨설턴트의 트윗을 하나 써줘.
## REON은 이런 사람
- 고졸 IT 12년 경력의 베테랑. 프리랜서 컨설턴트
...

포인트는 "이런 사람"이라는 속성의 나열뿐만 아니라, 구체적인 에피소드를 넣는 것이다. "술을 좋아함"이 아니라 "금주와 해금을 반복함. 요산 수치 위험함"까지 작성한다. 이것만으로도 AI의 출력이 단번에 리얼해진다.

시간대별 토픽 풀 (Topic Pool)

아침에 술 이야기를 하거나, 심야에 프로젝트 이야기를 하면 위화감이 든다. 시간대별로 토픽 풀을 나누어 두었다.

const TOPIC_POOLS = {
morning: [
"아침 루틴·커피",
...

"안 좋은 예"를 명시하기

AI에게 "이렇게 해"라고 말하기만 하면, 미묘하게 어긋난 출력이 나온다. "이것은 안 됨"을 구체적으로 보여주는 것이 효과적이었다.

## 안 좋은 예 (금지)
"아침 커피를 마시며 오늘의 개발 계획을 세우고 있습니다." → AI 같음
"그래서 말인데, 결국 AI를 잘 다루는 놈이 이기는 거야" → 작위적인 고찰. 금지
...

안 좋은 예에 왜 안 되는지의 이유를 한 줄 덧붙이는 것이 중요하다. "AI 같음", "억지로 비즈니스로 전환" 등, NG 방향성을 전달함으로써 AI가 스스로 판단할 수 있게 된다.

인플루언서 분석의 피드백 루프

이 시스템에서 가장 흥미로운 부분이 바로 이 메커니즘이다. 주 1회, IT 계열 인플루언서의 트윗을 자동 분석하여 그 결과를 일상 트윗 생성 프롬프트에 주입한다.

분석 플로우

매주 월요일 10:00 (GitHub Actions)
↓
from:kensuu OR from:masason OR ... 로 검색
...

분석 프롬프트에서는 "고엔게이지먼트 (High Engagement) 패턴"과 "저엔게이지먼트 (Low Engagement) 패턴"을 모두 전달한다.

const scored = tweets
.filter((t) => t.authorFollowers > 0)
.map((t) => ({
...

트윗 생성으로의 자동 주입

casual-tweet.js와 trend-tweet.js는 실행 시 influencer-patterns.json을 읽어 들여, 최신 분석 결과를 프롬프트에 추가한다.

let influencerTips = "";
try {
const patterns = JSON.parse(fs.readFileSync(INFLUENCER_FILE, "utf-8"));
...

이렇게 함으로써 트윗의 질이 매주 개선됩니다. "단문이 인게이지먼트 (Engagement)가 높다", "질문 형식이 잘 팔린다"와 같은 지견이 자동으로 프롬프트 (Prompt)에 반영됩니다.

팔로우 백 (Follow-back) 비율 스코어링

좋아요와 팔로우를 무턱대고 하는 것은 효율이 떨어집니다. 팔로우 백을 해줄 것 같은 사람을 우선적으로 팔로우하는 메커니즘을 넣었습니다.

스코어링 로직

// 팔로워/팔로잉 비율이 1.0에 가까움 = 맞팔로우 경향
let followBackScore = Math.abs(1 - (followers / following));
// 엔지니어 계열 bio라면 스코어를 대폭 우대
...

생각하는 방식은 간단합니다. 팔로워 수와 팔로잉 수가 비슷한 사람(비율이 1.0에 가까운 사람)은 맞팔로우 경향이 강합니다. 여기에 더해, bio에 엔지니어 계열 키워드("엔지니어", "developer", "React", "프리랜서" 등)가 포함되어 있으면 스코어를 우대합니다.

필터링 조건

const MIN_FOLLOWERS = 100; // bot 제외
const MAX_FOLLOWERS = 10000; // 유명인 제외
// 팔로잉/팔로워 비율이 0.3~3.0 범위를 벗어나면 제외
...

팔로워 100명 미만은 bot 확률이 높고, 10,000명을 초과하면 팔로우 백을 해주지 않으므로 제외합니다. 비율이 극단적인 사람(팔로워 구매 또는 대량 팔로우)도 제외하고 있습니다.

레이트 리밋 (Rate Limit) 대응

X API의 레이트 리밋 (Rate Limit)에 걸리지 않도록 간격을 두고 있습니다.

좋아요 → 2초 대기 → 팔로우 → 10초 대기 → 다음 후보로

1회 실행 시 최대 10건. 하루 2회 실행하므로, 하루 최대 20개의 좋아요와 20개의 팔로우를 수행합니다. 이 정도 수준이라면 레이트 리밋에 걸린 적은 없습니다.

상태 관리를 git으로 하는 패턴

이 시스템에서는 데이터베이스를 전혀 사용하지 않습니다. 모든 상태를 JSON 파일로 관리하며, GitHub Actions 상에서 git commit을 함으로써 영속화하고 있습니다.

GitHub Actions 실행
↓
JSON 파일을 읽기 → 처리 → JSON 파일에 쓰기
...

롤링 윈도우 (Rolling Window)

이력이 무한히 늘어나지 않도록 파일마다 유지 건수를 설정하고 있습니다.

이 패턴의 장점은 3가지가 있습니다.

• 데이터베이스 셋업이 불필요 - JSON과 git만으로 완결 -
• 이력을 git log로 추적 가능 - 언제 무엇이 일어났는지 전부 파악 가능 -
• GitHub Actions만으로 완결 - 외부 서비스에 대한 의존성이 없음

단점은 동시 실행 시 컨플릭트 (Conflict)가 발생할 가능성이 있다는 점입니다. 워크플로 (Workflow)의 스케줄을 15분 이상 차이를 둠으로써 회피하고 있습니다.

기사의 다면적 전개

하나의 Zenn 기사로부터 3개의 콘텐츠를 자동 생성하고 있습니다.

Zenn 기사 (published: true로 작성하여 쌓아둠)
├── auto-publish.yml → published: true로 변경 + X 알림 트윗
├── qiita-crosspost.js → Claude API로 Qiita용으로 리라이트 (Rewrite) + 게시
...

Zenn 기사의 자동 공개

GitHub Actions가 매일 10:00에 실행되어, published: true인 기사를 하나 찾아 published: true로 다시 써서 push합니다. Zenn은 GitHub 연동을 통해 자동으로 반영되므로, 이것만으로 공개가 완료됩니다.

- name: Find and publish one unpublished article
run: |
FILE=$(grep -rl 'published: true' articles/ | head -1)
...

Qiita 크로스 포스트 (Crosspost)

Zenn 기사를 그대로 게시하는 것이 아니라, Claude API를 사용하여 Qiita용으로 리라이트 (Rewrite) 합니다. Zenn과는 독자층이 미묘하게 다르기 때문에 도입부를 바꾸거나, Zenn 고유의 표기법(:::message 등)을 Qiita용으로 변환합니다.

토픽 매핑도 자동으로 수행합니다.

const TAG_MAP = {
claudecode: "ClaudeCode",
ai: "AI",
...

스레드 변환

공개된 기사를 3~6개의 트윗 스레드 (Thread)로 변환하여 게시한다. 수요일과 토요일 20:00에 실행한다. 하나의 기사를 여러 번 타임라인에 노출함으로써 도달 범위 (Reach)를 넓히고 있다.

주의점과 배운 점

X API의 제한

X API는 검색 API (v2.search)는 사용할 수 있지만, 사용자 타임라인의 직접적인 취득은 플랜에 따라 제한된다. 인플루언서 분석에서는 from:username 검색 쿼리로 대체하고 있으나, 최근 7일 치 데이터만 가져올 수 있다는 점은 주의해야 한다.

AI 트윗의 품질 관리

생성된 트윗이 280자를 초과하는 경우에는 자동으로 폐기한다. "짧으면 짧을수록 좋다. 10~50자가 베스트"라고 프롬프트 (Prompt)에 작성해도 가끔 장문이 나오기 때문에, 안전장치로서 글자 수 체크는 필수적이다.

중복 제거

최근 트윗 이력을 프롬프트에 주입하여 중복을 방지하고 있다.

const recentTexts = log.tweets
.slice(-20)
.map((t) => t.text)
...

"최근 트윗"으로서 최근 20건을 보여줌으로써 동일한 화제를 반복하지 않게 한다.

GitHub Actions의 cron 정확도

GitHub Actions의 cron은 정확하지 않다. 5~15분의 오차는 흔히 발생한다. "12:00에 게시"라고 설정해도 12:10이 되는 일은 다반사다. 다만, SNS 운영에 있어서 이 정도의 오차는 문제가 되지 않는다.

요약

• GitHub Actions + Claude API + X API v2의 조합으로 X 운영을 완전 자동화할 수 있다.
• 페르소나 (Persona) 설계는 "속성"뿐만 아니라 "구체적인 에피소드"와 "잘못된 예시"를 프롬프트에 넣는 것이 효과적이다.
• 인플루언서 분석 → 프롬프트 주입의 피드백 루프 (Feedback Loop)를 통해 트윗 품질이 자동으로 개선된다.
• JSON 파일 + git commit으로 데이터베이스가 필요 없는 상태 관리를 할 수 있다.
• 하나의 기사로부터 3개의 콘텐츠 (Zenn / Qiita / X 스레드)를 자동 생성하는 것은 비용 대비 효과가 높다.

모든 스크립트는 100~200행 정도의 Node.js로 작성되었으며, 복잡한 작업은 아무것도 하지 않았다. 메커니즘을 만드는 부분에 Claude Code를 사용한다면, 반나절 정도면 동일한 것을 만들 수 있을 것이라 생각한다.