메타가 내 인스타그램 자동화를 차단한 그 밤—v1.5.0에서 재작성한 내용

Source: Dev.to

SNS 자동화 도구를 만들고 있다면, 봇 탐지와의 싸움은 작업의 일부분입니다. 이 글은 메타의 자동화 탐지 시스템이 제가 운영하던 인디 SaaS(GramShift) 중 하나인 인스타그램 계정을 잡아낸 날에 대한 사후 분석이며, 운영자 입장에서 실제 트리거 패턴이 어떻게 보였는지, 그리고 그에 대한 대응으로 v1.5.0에서 적용한 설계 재작성에 대해 다룹니다.
※ 사전에 밝혀두자면, 페이싱 엔진 내부에 있는 구체적인 임계값·확률·타이밍 분포는 제품의 핵심 경쟁력이며 의도적으로 공개하지 않습니다. 흥미로운 부분은 재작성의 구조이며, 정확한 수치는 비공개입니다.

먼저 저는 인스타그램이 아니라 제 로그에서 이벤트를 감지합니다. 진행 중인 사이클의 좋아요 수가 기대 범위보다 크게 떨어지고, 운영 로그에 action_blocked가 뜨기 시작합니다. 영향을 받은 계정을 브라우저에서 열어 로그인하면 대시보드에 다음과 같은 문구가 표시됩니다:

죄송합니다. 특정 행동을 수행할 수 있는 빈도를 제한하고 있습니다.

이는 영구 차단이 아니라 소프트 쿨다운이며, “잠시 동안 이 계정의 행동을 제한한다”는 의미입니다. 하지만 자동화를 계속한다면 차단이 점점 강해져 영구 차단으로 이어질 수 있습니다. 저는 즉시 해당 계정의 모든 기능을 비활성화하고 그대로 두었습니다.

이벤트 전 2주간의 사이클 로그를 살펴보니, 단일 원인이라기보다는 세 가지 “공격적인” 설정이 겹쳐진 형태였습니다:

• 사이클 간격이 너무 짧고, 변동 폭이 좁음
  간격은 무작위였지만 범위가 좁아 전체적으로 보면 빈도 분석에 의해 기계적인 패턴으로 인식됩니다.
• 일일 행동 총량이 암묵적인 상한에 근접
  업계에서는 인스타그램 참여 행동에 대한 일일 상한이 어느 정도 알려져 있습니다. 저는 매일 그 상한에 거의 닿는 수준으로, 휴식일 없이 운영하고 있었습니다.
• 밤중에 행동이 발생
  실제 사람은 잠을 잡니다. 잠을 자지 않는 계정은 탐지하기 쉬운 신호 중 하나입니다.

각각을 따로 보면 버틸 수 있을지 모르지만, 두 주 동안 동시에 세 가지가 겹치면 플래그가 붙게 됩니다. 이것이 교훈입니다— 이 종류의 도구에서는 개별 파라미터보다 파라미터 간 상호작용이 더 중요합니다.

소프트 쿨다운이 얼마나 지속되는지에 대한 공개 정보는 매우 다양합니다. “24시간에서 7일” 정도라고 얘기하는 경우가 많죠. 저는 계정을 며칠간 완전히 유예시켰고, 도구뿐 아니라 인간이 직접 로그인한 상태도 마찬가지였습니다. 다시 확인했을 때 경고는 사라졌고 피드도 정상으로 돌아왔습니다. (뒤돌아보면 올바른 판단이었습니다) 아직도 일정 기간은 더 면밀히 모니터링될 가능성이 있어, 재시작 전 설정을 크게 낮췄습니다.

재작성된 페이싱 레이어 구조 (구체적인 수치는 제외)

• 더 넓고 비기계적인 간격 분포
  고정 간격이나 좁은 무작위 구간은 탐지 가능한 리듬을 만들게 됩니다. 인간이 실제로 행동을 배분하는 방식에 가깝게 만드는 것이 목표입니다.
• 야간 시간대에는 강제 건너뛰기
  인간이 하지 않을 행동을 도구도 하지 않게 합니다.
• 사이클당 행동 수는 가변이며 실제 상한을 적용
  “벽에 부딪힐 때까지 무조건 좋아요” 같은 구조는 새 설계에서 허용되지 않습니다.
• 일일 사이클 수 상한
  사이클당 계산이 어떻게 나오든, 일일 총량은 제한되어 계정이 암묵적인 상한에 접근하지 않게 합니다.

단기적인 비용은 현실적입니다— 참여 기반 팔로워 증가 속도가 느려집니다. 하지만 대안(계정 차단, 팔로워 손실, 포스트 기록 손실)과 비교하면 그 차이는 크지 않습니다.

v1.5.0이 배포된 뒤, 새로운 인스타그램 계정을 도구에 onboarding 할 때 적용하는 운영자 측 규칙을 추가했습니다: 첫 2주는 명시적으로 저조하게 운용합니다. 슬로우 모드, 팔로우 기능 비활성, 낮 시간대만 사용, 최소 사이클 수 등으로 설정합니다. 이는 메타가 해당 계정을 “일반 사용자”로 분류하도록 만든 뒤, 공격성을 점차 높이기 위한 전략입니다.

가장 큰 교훈

SNS 자동화 도구에서 가장 중요한 KPI는 참여 효율성이 아니라 계정 수명입니다. 차단된 계정은 그 위에 쌓아온 모든 것을 잃게 됩니다. 플래그가 잡히기 어려운 설계가 빠르게 성장하는 설계보다 더 가치 있습니다. 마치 올바른 코드를 생성하는 느린 컴파일러가 잘못된 코드를 빠르게 생성하는 컴파일러보다 더 가치 있는 것과 같습니다.

이 분야에서 무언가를 만든다면, 올바른 사고 모델은 “다음 천 개의 좋아요를 최적화하는 것이 아니라, 1년 뒤에도 계정이 살아 있는지를 최적화한다”는 것입니다. 거의 모든 파라미터 결정이 그 관점에서 완전히 뒤바뀝니다.

혹시 비슷한 사후 분석을 해본 자동화·봇 인접 도구를 개발하고 계신 분이 계시다면 궁금합니다. “세 가지 공격적인 설정이 겹친” 패턴은 인스타그램을 넘어 스크래퍼, API 클라이언트, 그리고 패턴 탐지를 당하고 있는 모든 종류의 도구에서도 일반화될 가능성이 높아 보입니다.