AI 에이전트에게 GitHub 작업을 맡겼다가 계정이 정지된 경험과 재발 방지책

AI 에이전트에게 GitHub의 작업을 맡기고 있었는데, 어느 날 계정이 동결(정지)되었습니다.

본문에서는 무슨 일이 일어났는지, 어떻게 이의를 제기했는지, 그리고 같은 일을 겪지 않기 위해 무엇을 바꿀 것인지 정리합니다.

AI 에이전트에게 '모든 것을 처리해 달라'고 부탁하기 시작한 분들이 미리 알아두면 좋을 이야기입니다.

무슨 일이 일어났나

하던 작업

제 자신의 공개 리포지토리 15개를 AI 에이전트(Claude Code)에게 수정하도록 했습니다.

내용은 버그 수정, 테스트 추가, 문서 정리 등입니다.

수정된 결과를 다른 AI가 채점하고 점수가 오를 때까지 고치는 과정을 여러 번 반복했습니다.

AI 에이전트는 작업을 작게 나누어 '서브 에이전트'에게 분배할 수 있습니다.

이번에는 리포지토리별로 서브 에이전트를 하나씩 할당하여 15개를 동시에 작동시켰습니다.

각각의 에이전트가 수정 내용을 push하고, PR(풀 리퀘스트)을 생성하며, CI(자동 테스트) 결과를 확인합니다.

하루 동안 일어난 일

돌아보면, 하루 사이에 다음과 같은 일이 벌어졌습니다.

PR을 약 50개 정도 생성
각각의 PR에 여러 번 push
CI 결과를 수십 초 간격으로 API를 통해 확인
실패한 CI 재실행

이 모든 것은 자신의 리포지토리 내에서의 작업이었습니다.

남에게 폐를 끼칠 의도는 전혀 없었습니다.

다만, 인간의 수작업으로는 불가능한 양과 속도였던 것은 분명합니다.

갑작스러운 403 에러

수정 과정의 5주차를 진행하던 중, GitHub API가 모두 다음 오류를 반환하기 시작했습니다.

HTTP 403 "Sorry. Your account was suspended"

브라우저로 계정에 접속하면 다음과 같이 표시되었습니다.

Access to your account has been suspended due to a violation of our Terms of Service.

'이용 약관(Terms of Service)을 위반했기 때문에 계정이 정지되었습니다.'라는 의미입니다.

어떤 규정을 위반했는지는 적혀 있지 않았습니다.

동결부터 이의 제기까지의 시간 순서

날짜와 시간은 일본 시간 기준입니다.

날짜 및 시간	사건
10/8 (목) 낮~심야	AI 에이전트를 이용해 15개 리포지토리의 수정을 여러 번 반복. PR은 하루에 약 50개 정도
...
동결된 기간은 약 6일간이었습니다.

동결 사실을 인지하고 이의를 제기하는 것까지는 반나절가 걸렸습니다.

밤늦게 알게 된 점, 로그인 제한이 걸린 점, 이의 제기 양식을 찾는 데 어려움을 겪은 것이 이유입니다.

GitHub는 심사 기간에 대해 공지하고 있지 않습니다.

사용자들의 보고를 보면, 며칠 만에 복구된 사람도 있고 몇 주가 걸린 사람도 있는 것 같습니다.

동결 중에는 그 계정으로는 아무것도 할 수 없다고 생각하는 것이 좋을 것 같습니다.

이번 경우는 주말을 끼고 6일간이었습니다.

동결되면 어떤 점이 불편한가

계정이 동결되면, 해당 계정으로는 아무것도 할 수 없습니다.

생각했던 것보다 영향 범위가 넓어서 다음 항목들이 모두 멈췄습니다.

리포지토리와 PR: 외부에서 보이지 않게 되었습니다. 사라진 것이 아니라, 동결된 상태입니다. -
GitHub Pages 사이트: 같은 계정으로 공개했던 사이트도 볼 수 없게 되었습니다. -
Zenn 아티클 업데이트: Zenn을 GitHub 리포지토리와 연동했기 때문에, 아티클 추가나 수정이 불가능해졌습니다. -
주기 실행 태스크: GitHub를 사용하는 자동화된 작업은 매번 실패하게 되었습니다.

하나의 계정에 여러 가지 것을 올리고 있으면, 멈췄을 때 모든 것이 함께 멈춥니다.

이는 이번에 가장 크게 느낀 점입니다.

원인으로 추정되는 것

GitHub 규정에는 자동화에 대한 규칙이 있습니다.

'Acceptable Use Policies(사용 적합성 정책)'에는 금지 항목으로 다음과 같은 내용이 있습니다.

과도한 자동 대량 활동(excessive automated bulk activity)
자동적인 수단을 통해 서버에 과도한 부담을 주는 행위(undue burden on our servers through automated means)

이번 작업은 자신의 리포지토리만을 대상으로 한, 진지한 수정이었습니다.

그래도, 짧은 시간에 대량의 PR과 push와 API 호출을 반복했기 때문에 기계적으로는 '지나친 자동화된 활동'으로 보였을 가능성이 있습니다.

또 하나 고려할 수 있는 것은 계정 소유 방식입니다.

GitHub 이용 약관에서는 무료 계정은 1인당 1개로 제한하고 있습니다.

다만, 자동화 전용의 '머신 계정(machine account)'은 개인 계정과 별도로 1개만 가질 수 있습니다.

자동화를 위해 별도의 계정을 만들었다면, 이 규정에 맞는지 확인해 보는 것이 안심입니다.

신고 절차

정지 화면에 있는 'contact support'를 통해 지원팀에 연락할 수 있습니다.

실제로 제가 진행한 절차는 다음과 같습니다.

복구 신청 전용 양식(GitHub 공식 페이지 'GitHub Appeal and Reinstatement'에서 열 수 있음)을 엽니다.
로그인할 수 없는 경우, 먼저 '로그인 불가' 창구에서 이메일 주소를 확인합니다.
신청 유형을 선택합니다.
무엇을 했는지 솔직하게 작성하여 보냅니다.

신청에는 두 가지 종류가 있습니다.

Reinstatement(복구): 지적된 부분을 수정했으니, 원래대로 돌려달라는 요청 -
Appeal(이의 제기): 위반하지 않았다고 반박하는 요청

이번에는 양이 너무 많았다는 점에 대한 짐작이 있었기 때문에 '복구'를 선택했습니다.

본문에는 다음 내용을 영어로 작성했습니다.

AI 에이전트를 사용하여 자신의 리포지토리를 수정했다는 점
타인의 리포지토리에는 아무것도 기여하지 않았다는 점
단시간에 대량의 작업을 진행한 것이 남용으로 보였을 수 있다는 점
앞으로는 양과 속도를 조절하겠다는 내용

보내자마자 티켓 번호가 포함된 자동 회신이 도착했습니다.

지원팀이 바빠서 시간이 걸린다는 내용이었습니다.

같은 신청을 여러 번 보내면 오히려 늦어질 수 있습니다.

추가 정보는 도착한 이메일에 답장하는 방식으로 보냈습니다.

몇 시간 후, 담당자로부터 'GitHub를 어떻게 사용할 예정인지 알려달라'는 회신이 왔습니다.

부정 사용을 감지하는 시스템에 걸렸기 때문에 사람의 손으로 확인하고 있다는 설명도 덧붙여져 있었습니다.

그래서 다음 내용을 답변했습니다.

개인 개발자로서, 범용적인 개발 도구를 공개 리포지토리에 만들고 있다는 점
Zenn 블로그와 작은 정적 사이트도 이 계정으로 공개하고 있다는 점
AI 에이전트는 자신의 리포지토리만 조작하며, PR 병합은 스스로 판단한다는 점
한 번에 너무 많이 작동시킨 것에 대한 사과와 향후 구체적인 상한선 설정
사용 중인 GitHub 계정은 이것 하나뿐이라는 점

그 5일 후에 '제한을 해제했습니다'라는 연락이 와서 원래대로 사용할 수 있게 되었습니다.

'사용 방법'을 물어보면, 어떤 용도의 계정인지, 어떻게 자동화하고 있는지, 앞으로 어떻게 조절할 것인지를 구체적으로 답변하는 것이 좋을 것 같습니다.

재발 방지책

여기부터가 본론입니다.

AI 에이전트에게 GitHub를 맡길 때의 규칙을 다음과 같이 변경하기로 했습니다.

GitHub 공식 문서 'REST API 사용 모범 사례(Best Practices)'에 있는 권장 사항도 반영했습니다.

1. 동시에 작동시키는 것은 최대 2개까지

공식 문서에서는 API 요청은 동시가 아니라 '순차적'으로 보내는 것이 좋다고 권장하고 있습니다.

이번에는 15개의 서브 에이전트를 동시에 작동시키고 있었습니다.

GitHub에 작성하는 작업을 동시에 진행하는 것은 최대 2개로 제한합니다.

2. push는 '테스트가 통과된 후에 한 번'

AI 에이전트는 수정할 때마다 push하여 CI에서 확인하려고 하는 경향이 있습니다.

이를 중단하고, 로컬 환경에서 테스트와 lint가 통과한 후에 모아서 단 한 번만 push하도록 합니다.

CI 횟수가 줄어들기 때문에 GitHub의 부담도, 자신의 대기 시간도 줄어듭니다.

3. 작성 시 간격을 두기

공식 문서에서는 POST나 PUT 같은 쓰기 요청을 연속으로 보낼 때는 1초 이상 간격을 두는 것이 좋다고 권장하고 있습니다.

여기에 여유를 더해 다음과 같이 정했습니다.

PR 생성은 1분 이상 간격 유지
일일 상한선은 PR 10개, push 30회까지
상한선을 초과할 것 같으면 다음 날로 미루기

4. CI 결과는 '알림'으로 기다리기

CI 결과를 수십 초 간격으로 API를 통해 확인하는 것은 부담이 큰 방식입니다.

공식 문서에서도 폴링(polling, 반복적으로 확인하러 가는 것)보다 Webhook 같은 알림을 사용하는 것이 권장됩니다.

알림으로 기다릴 수 있을 때는 알림으로 기다리고, 정말로 확인할 필요가 있을 때만 2분 이상 간격을 두세요.

5. 오류가 발생하면 즉시 중단하기

GitHub는 너무 많이 사용하면 'secondary rate limit(2차 제한)'이라는 오류를 반환할 수 있습니다.

AI 에이전트는 오류가 나면 '고치려고' 재시도를 반복하는 경향이 있습니다.

여기서 계속 시도하다 보면 상황이 악화됩니다.

지시 파일에는 다음과 같이 작성합니다.

403, 429, 또는 'secondary rate limit' 오류가 발생하면, 재시도하지 말고 즉시 작업을 중단하고 보고하세요.

6. 작업을 며칠에 걸쳐 나누기

15개의 리포지토리를 하루 만에 고치려 하지 말고, 하루에 3~5개씩으로 나눕니다.

급하게 할 이유가 없다면 천천히 진행해도 아무 문제 없습니다.

7. 모든 것을 하나의 계정에 담지 않기

이번에는 도구의 리포지토리도, 블로그(Zenn)도, 수수께끼 풀이 사이트도 같은 계정에 올렸습니다.

정지되었을 때의 영향을 줄이기 위해 중요한 것들은 어디에 둘지 재검토합니다.

AI 에이전트에게 지시하는 예시

마지막으로, AI 에이전트를 위한 지시 파일(AGENTS.md 또는 CLAUDE.md 등)에 넣을 규칙의 예시입니다.

그대로 사용할 수 있도록 만들어 두었습니다.

## GitHub 사용량 제한
- GitHub에 작성하는 작업(push, PR, CI 재실행)은 동시에 2개까지로 합니다. 리포지토리는 순서대로 처리합니다.
- push는 현지에서 테스트와 lint가 통과한 후에, 하나의 PR당 원칙적으로 1회입니다.
...

요약

AI 에이전트는 인간에게 불가능한 양과 속도로 GitHub를 조작할 수 있습니다.
자신의 리포지토리 작업이라도 양이 너무 많으면 규정 위반으로 간주될 수 있습니다.
계정이 동결되면, 리포지토리뿐만 아니라 연동된 서비스까지 한꺼번에 멈춥니다.
'동시에 작동시킬 개수', 'push 횟수', '작성 간격', '오류로 중단' 등을 지시 파일에 정해 두세요.

AI 에이전트에게 맡기는 것은 매우 편리합니다.

다만, 맡기는 범위와 함께 '속도의 제한'도 정해 둘 필요가 있었습니다.

계정이 해제된 후에는 이 글의 재발 방지책을 지키며 조금씩 작업을 재개하고 있습니다.