블루스카이 API 리밋에 대하여

얼마 전 블루스카이, 엄밀히는 AT Protocol의 API 리밋 정책이 업데이트되었습니다. 이전까지는 비정상적인 이용에 대해 운영자 측이 경고를 한 정도였던 것으로 기억하는데, 이제 API rate limit이 명시가 된 것이죠. 10년도 더 전에 트위터를 쓰셨던 분들은 아시겠지만 조금만 폭트를 하면 더 이상 트윗을 할 수 없는, 즉 ‘리밋에 걸리는’ 경험을 하곤 했습니다. 2023년 9월 16일을 기점으로 블루스카이에서도 그러한 리밋이 설정된 것이죠. 하지만 자세히 읽어보면 사실상 예전 트위터의 리밋 기준보다도 훨씬 더 루즈한 기준이란걸 알 수 있습니다.

각각의 사용자는 (DID 기준으로, 쉽게 말해 계정 기준이라고 보시면 됩니다) 매 시간 최대 5,000점, 24시간 내 최대 35,000점을 사용할 수 있습니다. 그리고 다음과 같은 행위마다 점수가 차감됩니다.

• CREATE 타입: 3점
• UPDATE 타입: 2점
• DELETE 타입: 1점

예를 들어 한 계정에서 1시간에 최대 1,666개의 글을 작성할 수 있고, 하루에 최대 11,666개의 글을 작성할 수 있습니다. (조금 더 응용하면, 좋아요를 누르는 것도 CREATE 타입의 액션이기 때문에 1시간에 최대 1,000개의 글을 작성하고, 500개의 글에 좋아요를 누르고, 500개의 글을 지울 수 있습니다. (1,000 * 3 + 500 * 3 + 500 * 1 = 5000)) 즉 2초에 한 번씩 포스트를 올려야 리밋에 걸리는 셈인데, 사람이 글을 작성하는 경우라면 웬만하면 이 리밋에 걸릴 일은 없는 것이죠. 이것은 모든 계정을 팔로우하거나(블스 초창기에 이러한 계정들이 몇 있었습니다), 모든 첫 포스트에 좋아요를 누르는 등 (얼마 전까지 두세 계정이 이랬고 한 계정은 쿠폰과 관련된 상업용 계정이었죠) 자동화된 spammy한 액션들을 막기 위한 방침이라고 보시면 됩니다. 신경쓸 일이 거의 없죠.

하지만 자동화된 봇, 특히 실시간성을 가지는 봇을 다루는 개발자 분들의 경우 상황이 조금 다릅니다. 위와 같은 종류의 리밋이 문제가 되는 것은 아닙니다. 개발자들을 귀찮게 할 수 있어 주의해야하는 리밋은 다름이 아니라 아래와 같은 종류의 리밋들, 특히 그 중에서도 createSession였습니다. (참고로 아래의 리밋 규정들은 원래 8월에 업데이트된다고 공지되었지만, 블루스카이 팀 Daniel에 의하면 공지만 하고 적용하는걸 깜빡하는 바람에 9월 16일 새 규정과 동시에 적용되었다고 하네요. 띠용)

• 글로벌 리밋: IP 별로 3,000/5분
• updateHandle: DID 별로 10/5분, 50/일
• createAccount: IP 별로 100/5분
• createSession: handle 별로 30/5분, 300/일
• deleteAccount: IP 별로 50/5분
• resetPassword: IP 별로 50/5분

나머지 액션들은 사실 딱히 리밋을 넘길 일은 없습니다만, 보통 로그인할 때에 사용하는 createSession API는 사정이 다릅니다. createSession으로 인증 토큰을 받을 수 있는데, 보통 이 토큰은 2시간이 지나면 만료가 되고 더 이상 사용할 수 없습니다. 하지만 세션을 만드는 횟수에 딱히 제한이 없었기 때문에, 방만하게 코딩하여 한 번 코드를 실행할 때마다 매번 세션을 만들어도 큰 문제가 없었습니다. 그러던 것이 9월 16일 오전 시점에서 새 API 정책이 시행됨에 따라, 수많은 봇들이 1일 300회라는 createSession 횟수 제한을 넘겨버리는 바람에 먹통이 되어 버렸습니다. 실제로 제가 운영하는 챗봇 일레븐과 실시간 트렌드 봇도 이 리밋을 넘겨버렸고, 외국의 많은 봇 계정들도 이 리밋을 넘겨버린 것을 확인할 수 있었습니다.

• 블스 전체에 대해 10분마다 실시간 트렌드를 알려주는 Now Breezing도 createSession 리밋!
• 일본의 유명 챗봇인 아이짱도 createSession 리밋!
• 일본의 또 다른 챗봇인 Bluesky짱도 createSession 리밋!

그 외에도 봇들이나 클라이언트 등에서 비슷하게 createSession을 마구 쓰다가 리밋에 걸리는 경우가 속출했습니다. 이 리밋은 비밀번호를 브루트 포스, 즉 모든 경우의 수를 다 쏟아부어 때려맞추는 공격을 막기 위해 낮게 설정되었습니다. (Jaz 님의 포스트 참조)

그러면 효율적으로 세션을 다루기 위해서는 어떻게 해야할까요? 단순하게 생각하면 2시간마다 createSession을 돌리고, 그 때까지 인증 토큰을 저장해서 쓰면 되긴 합니다만, refreshSession을 사용하면 조금 더 AT Protocol의 의도에 맞게 토큰을 활용할 수 있습니다. (역시 Jaz 님의 포스트 참조)

AT Protocol에서 토큰은 두 종류가 있습니다.

1. Access token
   • API를 사용할 때 인증에 사용됩니다. (그래서 보통 코드를 작성할 때 빈번하게 사용하게 되는 토큰입니다.)
   • 2시간 동안 유효합니다.
2. Refresh token
   • 기존의 토큰들을 연장할 때 사용됩니다.
   • 2달 동안 유효합니다.

그리고 토큰을 생성하는 데에 아래와 같은 엔드포인트를 씁니다.

1. createSession
   • 핸들(혹은 이메일)과 비밀번호를 입력받습니다. (로그인이라고 생각하시면 됩니다.)
   • Access token과 refresh token을 반환합니다.
2. refreshSession
   • Refresh token을 입력받습니다. (헤더에 {“Authorization”: “Bearer ” + refresh_token}와 같은 형태로 입력합니다.)
   • Access token과 refresh token을 반환합니다.

즉, 한 번 createSession을 통해 access token과 refresh token을 얻으면 이를 따로 저장해두었다가 2시간 마다 refreshSession을 통해 access token을 연장하는 것을 최대 2달까지 반복하기만 하면 됩니다. refreshSession의 리밋은 3000/5분으로 createSession보다 훨씬 여유롭기 때문에 리밋에 걸려 하루동안 아무 것도 못할 일은 거의 사라지게 됩니다. 만약 리밋에 대해 미처 파악하지 못하여 createSession 리밋을 넘기게 된다면 이렇게 로직을 수정해보시길 바랍니다.

(참고로 리밋을 확인하기 위해서는 request의 response의 header를 확인해보시길 바랍니다. RateLimit-Remaining이 남은 횟수, RateLimit-Reset은 리밋을 넘겼을 시 해제되는 시각(UNIX timestamp), RateLimit-Policy는 리밋 기준으로 예컨대 3000;w=300은 300초=5분에 최대 3000회를 뜻합니다.)