GitLab.com의 요청 속도 제한이 변경됨
요약
글래드하우스(GitLab)와 GitHub의 API 사용 시 GraphQL을 활용하는 것이 효율적입니다. REST API 대비 필드를 제한하고 타입 간 데이터를 결합하여 요청 횟수와 토큰량을 동시에 줄일 수 있습니다. 다만, 대규모 조직 환경에서는 서버에 큰 부담을 주거나 예상치 못한 DB 쿼리 폭증이 발생할 수 있으므로 운영팀과의 사전 협의가 필수적입니다.
핵심 포인트
- GraphQL은 REST 대비 효율적으로 데이터 요청 가능
- 대규모 API 사용 시 서버 부하 및 비용 고려 필요
- 비인증 접근에 대한 제한 강화 추세 확인
- 오픈소스 보상 시스템 도입 시 악용 방지 대책 필요
LLM으로 GitLab이나 GitHub를 다룬다면 GraphQL API를 쓸 수 있을 때 바로 활용하는 게 좋음. 사람이 쓰기에는 끔찍하지만, 에이전트에는 이보다 더 적합한 API가 있을까 싶을 정도임.
GitHub REST API는 이슈 JSON 10개 정도만 읽어도 컨텍스트 창이 꽉 찰 수 있지만, GraphQL로 반환 필드를 제한하면 같은 토큰 예산으로 수백 개를 읽을 수 있음. 타입 간 데이터를 한 번에 결합할 수도 있어, 요청 횟수와 응답 토큰량을 동시에 줄일 수 있음.
대규모 자체 호스팅 GitHub Enterprise 운영팀과 긴밀하게 일하고 있음. 데이터를 소비하는 쪽에는 좋은 조언이지만, 서버에는 쉽게 큰 부담을 줄 수 있음. 요청하는 필드가 단순한 테이블 조회인지, 내부적으로 git 실행까지 유발하는지 겉으로는 알기 어려움.
요청 제한이 이런 비용을 더 잘 반영해야 한다고 할 수는 있지만, 실제 시스템은 그렇지 않음. 최근 GitHub의 안정성 문제도 이와 무관하지 않을 듯함.
REST 응답 때문에 컨텍스트 창이 꽉 차는 건 이미 해결된 문제임. 에이전트는 응답을 파일에 저장한 뒤 jq나 rg로 필요한 내용을 찾음.
에이전트는 생각보다 똑똑하며, 강화학습 환경에서 여러 세대에 걸쳐 개선돼 왔음. 컨텍스트 창을 터뜨리는 에이전트는 출시 단계까지 살아남지 못함.
적어도 GitHub의 사용량 한도는 쿼리 내용에 따라 달라짐. GitHub와 직접 협업했는데, 충분히 복잡한 조직을 대상으로 GraphQL 쿼리를 보내면 응답을 받기도 전에 앱의 시간당 한도를 소진할 수 있음.
개발자 약 200명 규모의 조직에 GitLab을 호스팅하면서 모노레포가 제대로 작동하지 않는 것도 봤음. GitLab 팀이 확인해 준 바로는 우리 환경에서 페이지 조회 한 번에 DB 쿼리 5만 개가 실행됐음. GraphQL 요청을 쏟아붓기 전에 운영팀과 상의하기 바람.
별개로 GitHub GraphQL API는 수년간 방치된 상태임. 최소한 REST API와 기능 동등성은 유지되지 않고 있어서, 필요한 작업을 하려면 REST API를 써야만 하는 경우가 꽤 있음.
내 에이전트는 gh CLI를 쓰는데, GraphQL의 장점은 여러 번의 CLI 호출이 필요한 작업을 쿼리 하나로 구성할 수 있다는 건가?
놓치기 쉬운 핵심은 비인증 요청은 시간당 60회지만 무료 요금제는 5,000회라는 것임. 60회는 형편없지만, 초당 1회를 조금 넘는 5,000회면 충분히 괜찮음.
Docker가 비인증 이미지 내려받기를 제한한 것과 같은 맥락으로 봄. 인증 없이 무엇이든 이용하던 시대는 이미 지나갔으며, 비인증 접근을 원한다면 직접 미러를 운영하면 됨.
이런 사업은 처음부터 인증을 요구하고 유료 전환으로 용량을 확충했어야 함. 무료 요금제가 유료 이용자의 사용 경험을 해치면 결국 자해 행위가 됨.
무료 이용을 더 지원하려면 유료 이용도 늘려야 함. 나중에 도입하면 이용자들이 반발하지만, 처음부터 시행하면 당연하게 받아들여짐.
수집 대상 저장소에 수익을 배분하면 스트리밍 서비스처럼 창작자에게 보상하고 오픈소스 프로젝트의 자금을 마련할 수 있을 것임. 그런 방향으로 가는 듯한데, GitHub와 차별화할 강력한 요소가 될 수 있음.
처음에는 정말 좋은 아이디어라고 느꼈음. 프로젝트에 접근하는 쪽이 비용을 내고 인기 있는 FOSS 개발자가 보상받으면 이해관계가 훨씬 잘 맞아떨어질 것임.
다만 곧바로 봇이 제도를 악용할 것 같다는 생각도 듦. 보상금을 타내려고 GitLab에 가짜 저장소를 대량 생성할 가능성이 큼.
아이디어는 좋지만, 안내문을 그렇게 읽지는 않았음. 오히려 오픈소스 프로젝트에 불리한 지침으로 보임.
의도한 이용자가 아닌 곳에서 트래픽이 오면 프로젝트를 비공개로 바꿔 익명 접근을 모두 막거나, 더 높은 한도를 위해 Premium 또는 Ultimate로 업그레이드하라고 안내함.
수익 배분을 발표한 지 3분이면, 보상금만 노리고 만든 저장소와 반복 수집 봇이 쏟아질 것임.
이제 중요한 보도자료까지 Claude로 쓰는 건가 싶음.
본문을 GPTZero의 AI 판별기에 넣었더니, 전체가 100% AI 작성물이라고 매우 높은 확신으로 판정함. 글 전체에 대해 그렇게 확신하는 결과는 처음 보는 것 같음.
글이 수정됐는지는 모르겠지만, 익숙한 Claude 특유의 문체는 느껴지지 않음. 복잡하게 꼬인 문장이나 비유, 상담하듯 말하는 표현, “~가 아니라” 식 구문, “load bearing” 같은 표현도 보이지 않음.
우리 회사 임원들도 Claude로 작성한 이메일을 보내고 있음. 웃기기는 하지만 예상 밖의 일은 아님.
Firefox 언어가 프랑스어라 프랑스어 버전이 자동으로 나왔는데, 도무지 이해하기 어려웠음. 문장마다 뜻이 불분명하고 문장 사이의 연결도 없었음.
이 조치가 AI 수집 때문에 도입됐다는 해석에는 동의하지 않음. AI 수집은 명분이고 실제 목적은 구독과 매출 확대임. AI 수집 대응은 이미 해결된 문제이며, 그럴듯한 구실로 보일 시점에 시행했을 뿐임.
인증 정보가 없는 요청은 IP당 시간당 60회라니, 분당 1회인 셈임.
평균으로는 그렇지만, 표현상으로는 토큰 버킷 같은 방식일 수 있음. 60회를 빠르게 요청한 다음, 버킷이 다시 찰 때까지 잠시 차단되는 식임.
정확히는 요청 60회가 주어지고, 1초 만에 모두 쓰든 시간을 나눠 쓰든 선택할 수 있다는 뜻에 가까움.
수집기는 요청마다 다른 IP를 쓰므로 수집 방지에는 도움이 되지 않음.
IPv6를 쓰면 훨씬 더 많이 요청할 수도 있음.
LLM의 데이터 수집 때문에 도입한 조치로 추측함.
아마 그렇겠지만, 요청 제한이나 차단 대신 코드 최적화와 페이지 전체 캐싱에도 집중해 주면 좋겠음.
봇과 광고가 없는 새로운 비상업적 인터넷이 필요함. 광고를 더 보여주려고 끝없이 스크롤하게 만드는 대신, 돈을 낼 만큼 흥미롭게 설계된 소셜 미디어에 이용료를 내는 형태임.
지금은 불가능해 보일 수 있지만, 정말 불가능한 건 현 상태를 계속 유지하는 것임. 인터넷이 사회에 끼치는 피해는 날로 커지는 반면 경제적·사회적 가치는 줄어들고 있음.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기