블로그로 돌아가기

2026년 X 자동화: 정리 후 API에 남은 것들

2026년 2월에 X는 무료 API 요금을 종료하고, 4월에는 구독, 좋아요 및 인용을 Enterprise로 이전했으며, 5월에는 계정의 일일 게시물 한도를 50개로 줄였습니다. 어떤 작업이 개별 결제로 남아 있는지, 그 비용이 얼마인지, 어떤 두 개의 독립적인 한도를 먼저 설정할 것인지, 그리고 IP 회전이 어떤 행동도 추가하지 않는 이유를 분석합니다.

📅2026년 9월 15일
2026년 X 자동화: 정리 후 API에 남은 것들

X(구 Twitter)와의 작업을 자동화한 서비스나 에이전시가 있다면, 2026년은 규칙을 두 번 바꿨습니다. 2월에 플랫폼은 무료 API 요금제를 완전히 종료하고 새로운 개발자들을 개별 요금제로 전환했습니다. 4월에는 모든 셀프 서비스 요금제에서 구독, 좋아요 및 인용의 write 엔드포인트가 사라졌습니다. 이제 이들은 약 42,000달러부터 시작하는 Enterprise 계약에서만 사용할 수 있습니다. 5월에는 플랫폼이 계정 수준에서 한도를 줄였습니다: 인증되지 않은 프로필은 이전의 2400개에서 하루에 50개의 원본 게시물만 게시할 수 있습니다.

이제 실제로 남아 있는 것이 무엇인지, 작업당 비용은 얼마인지, 어떤 한도에 먼저 부딪히게 되는지, 그리고 프록시가 실제로 문제를 해결하는 곳과 그렇지 않은 곳을 분석해 보겠습니다.

무엇이 제거되었고 언제

변경 사항의 연대기는 다음과 같습니다:

  • 2026년 2월 — 무료 요금제가 종료되었습니다. 새로운 개발자에게 기본 모델은 사용량 기반 요금제입니다.
  • 2026년 4월 — follow, like 및 quote-post 엔드포인트가 모든 셀프 서비스 요금제에서 제거되었습니다. 무료 수준에서는 더 일찍 제거되었지만, 이제는 Enterprise를 통해서만 접근할 수 있습니다.
  • 2026년 6월 — 월 200달러의 레거시 Basic 요금제가 개별 요금제로 전환됩니다. Basic 및 Pro에 대한 새로운 구독은 열리지 않으며, 기존 계정은 접근을 유지합니다.
  • 2026년 5월 — 계정 수준의 한도가 줄어들었으며, 이는 API, 웹 및 모바일 애플리케이션에 대해 공통적입니다.

첫 번째 블록의 실질적인 결론: 자동 구독, 자동 좋아요 또는 타인의 게시물 인용을 중심으로 구축된 모든 제품은 합법적인 셀프 서비스 경로를 잃었습니다. 가격이 오른 것이 아니라, 정확히 잃었습니다. 차이는 본질적입니다: 가격 인상은 예산으로 해결할 수 있지만, 엔드포인트의 부재는 Enterprise 계약 외에는 아무것으로도 해결할 수 없습니다.

개별 요금제로 남은 것

현재 셀프 서비스는 네 가지 작업 그룹을 처리합니다: 게시물 게시, 게시물 및 피드 읽기, 제한된 시간 내의 답변 및 수신 동의를 한 사람에게 개인 메시지 보내기. 작업당 가격은 다음과 같습니다:

  • 0.015 $ — 일반 텍스트 게시물.
  • 0.20 $ — 링크가 포함된 게시물. 차이는 13배 이상이며, 이는 예산 계산에서 가장 과소평가된 항목입니다.
  • 0.005 $ — 한 게시물 읽기, 월 200만 읽기 한도.

스트리밍 및 전체 텍스트 아카이브 검색은 개별 요금제로는 사용할 수 없습니다 — 이는 Pro(남아 있는 경우) 및 Enterprise의 영역입니다. 레거시 Basic은 약 50,000개의 기록과 월 10,000~15,000개의 읽기를 제공하며, 검색 창은 7일입니다; Pro는 5000달러에 약 300,000개의 기록과 백만 개의 읽기를 제공하며 아카이브 및 스트리밍이 포함됩니다.

미리 자신의 시나리오를 계산하세요. 하루에 20개의 고객 계정에 30개의 링크가 포함된 게시물을 게시하는 콘텐츠 에이전시는 게시물 게시에만 하루에 120달러를 지출합니다 — 월 3600달러. 본문에 링크가 없는 동일한 양은 월 270달러입니다. 여기서 게시물 구조는 요금제 선택보다 비용에 더 큰 영향을 미칩니다.

두 개의 다른 한계: 애플리케이션 한계와 계정 한계

여기서 가장 자주 실수합니다. X에서는 두 개의 독립적인 한계가 작동하며, 이는 서로 다른 개체에 대해 계산됩니다.

첫 번째 — 애플리케이션 및 토큰 한계. 이는 슬라이딩 윈도우에서 엔드포인트의 전형적인 속도 한계입니다:

  • 신규 게시물 검색 — 사용자당 15분에 300 요청 및 애플리케이션당 450 요청;
  • 게시물 생성 — 사용자당 15분에 100 요청 및 애플리케이션당 하루에 10,000 요청;
  • 피드 읽기 — 사용자당 15분에 900 요청;
  • 게시물 삭제 — 사용자당 15분에 50 요청;
  • 개인 메시지 — 계정당 하루에 최대 1440개.

창은 첫 번째 요청에서 시작되며, 정각이 아닙니다. 초과 시 HTTP 429와 오류 코드 88이 발생하며, x-rate-limit-reset 헤더에는 리셋 순간의 유닉스 타임스탬프가 포함됩니다. 이는 요청을 반복할 수 있는 유일한 신호입니다: 고정된 간격으로 맹목적인 재시도는 쿼터를 소모하고 차단을 연장합니다.

두 번째 — 계정 자체의 한계. 2026년 5월부터 인증되지 않은 프로필은 하루에 약 50개의 원본 게시물, 200개의 답변, 400개의 구독 및 500개의 개인 메시지로 제한됩니다. 핵심: 이 카운터는 공통적입니다. 공식 API, 웹 인터페이스 또는 모바일 애플리케이션에서 온 행동은 모두 동일한 카테고리에 포함됩니다.

여기서 산업에서 프록시가 충분히 크게 언급되지 않는 점이 있습니다: IP 변경은 이 한계를 움직이지 않습니다. 엔드포인트 한계는 애플리케이션의 토큰과 사용자 컨텍스트에 연결되어 있으며, 행동 한계는 계정 자체에 연결되어 있습니다. 주소 회전은 하루에 게시물을 추가하지 않습니다. 우리는 2026년 Reddit API 한계와 프록시의 역할 예제를 통해 동일한 결론을 논의했습니다: 프록시는 접근성과 지리적 분포를 담당하며, 쿼터는 아닙니다.

프록시가 정말 필요한 곳

프록시가 X 작업에 필요하지 않다는 의미는 아닙니다. 단지 그들의 역할이 다르며, 정확히 다음과 같이 정의됩니다:

  1. 지리적 접근성과 지역적 제공. 트렌드, 지역 피드, 제한된 국가에서 플랫폼에 접근. 여기서는 필요한 지역의 실제 IP가 중요합니다 — 주거용 프록시는 실제 사용자와 동일한 ASN의 트래픽과 다르지 않은 일반 가정용 ISP의 주소를 제공합니다.
  2. 인프라 격리. 다양한 고객의 계정을 관리하는 에이전시는 동일한 네트워크 컨텍스트에서 세션을 혼합해서는 안 됩니다. 한 고객이 제한을 받으면 다른 고객은 이를 느끼지 않아야 합니다. 규칙은 간단하며, 우리는 “하나의 프록시 — 하나의 계정” 원칙에 대한 자료에서 이를 자세히 논의했습니다.
  3. 채널 안정성. 긴 피드 읽기 작업은 한계보다 네트워크 중단에 더 자주 부딪힙니다. 예측 가능한 지연이 있는 전용 채널은 재시도를 줄이고 소모된 쿼터를 줄입니다.
  4. 모바일 시나리오 작업. 프로세스가 모바일 클라이언트의 행동에 의존하는 경우, 이동통신 사업자의 주소는 데이터 센터 주소보다 플랫폼에 더 자연스럽게 보입니다. 이러한 작업을 위해 모바일 프록시를 사용합니다.

정직한 정의는 다음과 같습니다: 프록시는 “어디서 얼마나 신뢰할 수 있는지”에 대한 문제를 해결하지만, “얼마나 많은 작업이 허용되는지”에 대한 문제는 해결하지 않습니다. 반대의 것을 약속하는 판매자는 실현되지 않을 기대를 판매하고 있습니다.

하지 말아야 할 것

4월 변경 이후 일부 팀은 브라우저 자동화를 폐쇄된 엔드포인트의 대안으로 고려하고 있습니다. 이 해결책의 비용을 이해하는 것이 중요합니다.

X의 규칙은 모든 자동화를 공식 API를 통해 수행할 것을 요구합니다: 인터페이스 스크래핑, 브라우저 자동화 및 비공식 API는 사용 조건에 의해 금지됩니다. 플랫폼은 2023년부터 스크래핑과 소송 중이며, 2026년 3월에는 “비인증 행동”으로 인한 대규모 차단이 발생했습니다. 실무자들의 추정에 따르면, 자동 데이터 수집에 사용되는 계정은 차단되기까지 3일에서 14일 정도 살아남으며, 주소 회전은 이 기간을 본질적으로 늘리지 않습니다. 결정은 행동 및 핑거프린트 신호에 따라 이루어지며, 단순히 IP에 의해서만 결정되지 않습니다.

별도로: 최근 몇 달간의 트렌드는 플랫폼이 기술적 차단에서 법적 차단으로 점점 더 많이 전환하고 있다는 것입니다. 2026년 여름, X는 Nitter의 공개 프론트엔드를 종료할 것을 요구했습니다; 우리는 파싱에 대한 무기를 변경한 방법에 대한 자료에서 이를 논의했습니다. 인프라의 창의성은 더 이상 주요 위험 요소가 아니며 — 법률가의 편지가 되었습니다.

작업을 재구성하는 방법: 실용적인 순서

  1. 작업을 남은 것과 잃은 것으로 나누세요. 게시, 읽기, 답변 및 DM은 남아 있습니다. 구독, 좋아요, 인용은 Enterprise로 갔습니다. 두 번째 그룹에 기반한 모든 것은 최적화가 아니라 제품 모델의 변경이 필요합니다.
  2. 요금제가 아니라 작업별로 예산을 재계산하세요. 링크가 포함된 게시물을 별도로 계산하세요: 개당 0.20 $의 경우, 첫 번째 답변에서 본문 대신 링크를 꺼내면 월별 청구서가 몇 배로 바뀝니다.
  3. 자신의 속도 제한기를 설정하세요. 공식 한도보다 약간 낮게 설정된 토큰 버킷은 429를 잡고 그 결과를 처리하는 것보다 저렴합니다. 거부 사실에 따라 멈추지 말고, 미리 나가는 흐름을 조절하세요.
  4. 헤더에 따라 429를 처리하세요, 타이머가 아니라. x-rate-limit-reset을 읽고 지정된 순간까지 정확히 기다리세요.
  5. 클라이언트를 서로 다른 네트워크 컨텍스트로 분리하세요. 각 계정에 대해 별도의 프록시와 별도의 자격 증명 세트는 기본적인 위생으로, 어떤 제한이 있더라도 피해 범위를 제한합니다.
  6. API 한도와 별도로 계정 수준의 한도를 따로 모니터링하세요. 이들은 SMM 전문가의 수동 작업과 함께 계산됩니다. 사람이 애플리케이션에서 수동으로 게시물을 게시하면, 귀하의 스케줄러는 예상보다 적은 양을 받을 것입니다.

결론

2026년은 X를 저렴한 API 플랫폼에서 개별 요금제로 전환하고, 대규모 참여 작업은 기업 계약에만 접근 가능하게 만들었습니다. 나머지는 비용이 들고 제한된 범위 내에서 이루어집니다. 대부분의 팀에게 올바른 반응은 우회 경로를 찾는 것이 아니라, 남은 작업 세트에 맞게 프로세스를 재구성하고, 작업별 비용을 계산하며, 미리 자신의 트래픽을 제한하는 것입니다.

이 구조에서 프록시는 여전히 필요하지만 분명히 정의된 도구로 남습니다: 그들은 지리적 분포, 채널의 신뢰성 및 고객 계정 간의 격리를 제공합니다. 이러한 효과가 필요하다면 — ProxyCove의 주거용 주소는 대기 중인 포트에 대한 구독료 없이 트래픽에 대한 요금제로 문제를 해결합니다. 만약 쿼트를 우회할 수 있다고 약속받는다면 — 두 개의 한계에 대한 섹션을 다시 읽는 것이 좋습니다.