ClawSweeper
OpenClaw 프로젝트에서 50개의 Codex를 병렬로 돌려 이슈와 PR을 주기적으로 깊게 스캔하고, 이미 해결됐거나 의미 없는 항목만 보수적으로 닫는 유지보수 자동화 봇.
개요
openclaw/clawsweeper는 코드 생성 보조보다 한 단계 뒤의 오픈소스 유지보수 노동 을 자동화하는 시스템이다. 대상은 openclaw/openclaw 저장소이며, 각 이슈/PR마다 개별 마크다운 리뷰 기록을 만들고, 충분히 강한 근거가 있을 때만 close를 제안하거나 적용한다.
2026-04-26 기준 확인한 저장소 메타데이터:
- Stars 616 / Forks 59
- 주 언어: JavaScript
- 기본 브랜치:
main - 라이선스: MIT
- 최근 업데이트: 2026-04-26T00:58:47Z
README와 이 공유한 설명을 합치면 현재 운영 이미지는 다음과 같다.
- 50개 Codex를 병렬 실행
- 이슈/PR을 24시간 파이프라인으로 깊게 스캔
- 이미 구현됨 / 재현 불가 / 의미 없음 / 잘못된 저장소 대상 / 오래된 불충분 제보 등을 정리
- 하루 동안 약 4,000개 이슈를 정리 했고, 여전히 수천 개가 파이프라인에 남아 있음
- 병목은 모델 품질보다 GitHub rate limit와 운영 파이프라인 처리량 에 더 가까움
어떻게 동작하나
ClawSweeper는 review 단계와 apply 단계를 분리한다.
Review 단계
- planner가 due item을 고르고 50개 shard로 분배
- 각 shard가 open item의 본문, 댓글, 타임라인, 관련 중복 이슈를 모아 compact context 생성
- Codex가 소스, 문서, 테스트, git history, 인접 코드까지 읽고 판단
- 각 항목마다
items/*.md형태의 리뷰 기록 생성 - high-confidence일 때만
proposed_close로 표시
Apply 단계
- review 결과가 바뀌지 않았는지 다시 확인
- 안전 조건을 통과한 항목만 close/comment 반영
- maintainer가 직접 쓴 항목은 자동 종료 대상에서 제외
즉, “AI가 마음대로 닫는 봇” 이 아니라 리뷰-제안-적용을 분리한 보수적 유지보수 파이프라인 에 가깝다.
왜 중요한가
이 프로젝트의 핵심은 AI가 더 많은 코드를 쓰는 데 있지 않다. 오히려 개발자가 오랫동안 수동으로 떠안아 온 이슈 분류, 재현 가능성 확인, 중복 탐지, stale triage 같은 잡무를 자동화한다는 점이 더 중요하다.
해석대로, 이건 AI가 코딩 보조를 넘어 오픈소스 운영면(maintenance layer) 으로 들어온 사례다. 특히 의미 있는 지점은 다음과 같다.
- 병렬 Codex를 단일 기능 호출이 아니라 지속 운영형 maintainer fleet 로 쓴다.
- 결과를 별도 SaaS 대시보드가 아니라 README를 실시간 업데이트하는 방식 으로 공개해, GitHub 자체를 운영 콘솔처럼 사용한다.
- 진짜 희소 자원은 코드 작성 능력보다 과거 이슈를 읽고 걸러내는 인간의 시간 이라는 점을 드러낸다.
close 정책
README 기준 close 허용 범주는 꽤 좁다.
- 이미
main에 구현됨 - 현재
main에서 재현되지 않음 - core가 아니라 ClawHub skill/plugin에 더 적합
- duplicate 또는 canonical issue/PR로 대체됨
- 이 저장소에서 actionable하지 않음
- 지나치게 incoherent함
- 60일 이상 지난 stale issue인데 검증 정보가 부족함
이 정책은 대량 자동화 시스템이면서도 open item을 닫는 비율을 낮게 유지 하는 방향으로 설계되어 있다.
관점 해석
ClawSweeper는 앞으로의 오픈소스 운영이 다음처럼 바뀔 가능성을 보여준다.
- 사람 maintainer는 직접 triage를 전부 하지 않고, AI가 만들어 준 review artifact를 승인하는 쪽으로 이동
- bug report 작성과 close comment 생성 자체가 AI-to-AI 루프로 이어질 수 있음
- 대규모 저장소의 병목은 model intelligence보다 queue orchestration / rate limiting / evidence management 로 이동
- 코딩 에이전트 경쟁은 IDE 안 코드 생성보다, 저장소 전체의 운영 자동화 스택 을 누가 더 잘 만들 수 있느냐로 확장됨
OpenClaw 쪽에서는 이 프로젝트가 openclaw 의 대규모 오픈소스 운영 부담을 Codex fleet로 흡수하는 사례로 읽힌다. 즉 멀티 에이전트가 제품 기능만이 아니라 프로젝트 유지보수 자체를 소비 하기 시작한 셈이다.