ClawSweeper란 무엇인가 2026 – Codex로 GitHub 이슈를 닫기 전에 proposal-only와 snapshot 검증을 둬야 하는 이유

GitHub 이슈가 수천 개 쌓인 저장소를 보면 마음이 좀 묘해진다.

처음엔 “언젠가 정리해야지”라고 생각한다.

그다음엔 “이건 사람이 할 일이 아닌데?”라고 생각한다.

그리고 AI 에이전트를 쓰는 사람은 바로 위험한 생각을 한다.

그럼 Codex한테 오래된 이슈를 다 읽고 닫게 하면 되지 않을까?

여기서 잠깐 멈춰야 한다.

AI가 이슈를 읽는 건 괜찮다.

AI가 닫아도 될 이슈를 제안하는 것도 괜찮다.

하지만 AI가 바로 이슈를 닫기 시작하면, 그때부터는 자동화가 아니라 운영 리스크다.

OpenClaw의 ClawSweeper가 흥미로운 이유가 여기에 있다.

ClawSweeper는 “AI가 GitHub 이슈를 닫는다”는 자극적인 이야기가 아니다.

오히려 반대다.

핵심은 AI가 바로 닫지 못하게 만드는 구조다.

공식 README 기준으로 ClawSweeper는 openclaw/openclaw의 issue와 PR을 검토하는 보수적 maintainer bot이다.

한 open item마다 markdown report를 만들고, 유용할 때 Codex automated review comment를 남기며, 근거가 강할 때만 close를 제안한다.

그리고 review lane은 proposal-only다.

닫는 건 apply lane의 별도 일이다.

이 분리가 핵심이다.

이 글은 ClawSweeper를 “신기한 봇”으로 소개하는 글이 아니다.

TECHTAEK식으로 보면 이건 Codex 자동화를 운영에 붙일 때 필요한 안전장치 샘플이다.

먼저 결론

ClawSweeper의 핵심은 자동 close가 아니다.

핵심은 proposal-only -> snapshot 검증 -> apply -> audit 흐름이다.

AI가 판단을 만들고, 그 판단을 markdown record로 남기고, GitHub 상태가 바뀌지 않았는지 다시 확인하고, 닫을 수 있는 좁은 조건에서만 apply한다.

이 구조가 없으면 AI 유지보수 자동화는 너무 쉽게 위험해진다.

단계	ClawSweeper식 의미	운영자가 배울 점
Review	Codex가 issue/PR을 읽고 판단 기록 생성	AI 판단은 먼저 제안으로만 남긴다
Record	items/<number>.md 같은 markdown artifact 저장	나중에 사람이 감사할 수 있어야 한다
Snapshot	GitHub item의 상태 hash를 기록	apply 전에 원본이 바뀌었는지 확인한다
Apply	변경 없는 high-confidence proposal만 close	실행은 판단과 분리한다
Audit	live GitHub 상태와 record를 비교	자동화 자체도 검증 대상이다

이건 블로그 운영에도, Obsidian 정리에도, GitHub issue triage에도 그대로 쓸 수 있다.

AI에게 바로 삭제, 이동, close를 맡기지 말고 먼저 proposal을 만들게 한다.

그다음 사람이 보거나, 별도 apply 단계가 검증한 뒤 실행한다.

느려 보이지만 이게 빠른 길이다.

자동화 사고 한 번 나면 그걸 수습하는 시간이 훨씬 길다.

ClawSweeper가 하는 일

ClawSweeper 공식 README는 이 도구를 OpenClaw 유지보수용 보수적 bot으로 설명한다.

대상은 openclaw/openclaw 저장소의 open issue와 PR이다.

ClawSweeper는 각 item을 읽고, 현재 main 기준으로 판단하고, markdown report를 만든다.

그리고 close가 가능하다고 판단하면 바로 닫는 게 아니라 proposed_close 같은 상태로 기록한다.

이후 apply lane이 별도로 실행된다.

apply lane은 기존 report를 읽고, 저장된 snapshot이 현재 GitHub item과 여전히 맞는지 확인한 뒤에만 실제 GitHub comment나 close를 수행한다.

대략 구조는 이렇다.

GitHub open issue/PR
        |
        v
Planner: review 대상 선정
        |
        v
Shard review: Codex가 proposal 작성
        |
        v
Markdown record: decision, evidence, risks, snapshot hash
        |
        v
Apply lane: snapshot 재확인
        |
        v
Comment/close or keep open
        |
        v
Audit: live state와 record 비교

이 흐름에서 중요한 건 “AI가 똑똑하다”가 아니다.

“AI가 틀릴 수 있다고 가정한 구조”다.

좋은 자동화는 AI를 믿어서 강한 게 아니다.

AI가 틀려도 회복할 수 있게 만들어서 강하다.

닫을 수 있는 이유가 좁다

ClawSweeper README의 guardrails가 특히 좋다.

close proposal을 낼 수 있는 조건이 좁게 정해져 있다.

공식 README 기준으로 대표 조건은 아래와 같다.

close proposal 조건	의미
현재 main에 이미 구현됨	요구사항이 이미 반영되어 있음
현재 main에서 재현되지 않음	버그가 더 이상 확인되지 않음
core보다 ClawHub skill/plugin이 맞음	저장소 범위가 아님
canonical issue/PR로 대체됨	중복 또는 superseded 상태
이 source repo에서 actionable하지 않음	여기서 처리할 수 없는 요청
incoherent해서 조치 불가	정보가 너무 부족하거나 모순됨
60일 이상 stale이고 검증 데이터 부족	오래됐고 재현 근거가 부족함

그리고 maintainer가 작성한 item은 자동 close 대상에서 제외한다.

나머지는 keep open이다.

이 설계가 중요하다.

AI 자동화는 “무엇을 할 수 있나”보다 “무엇을 못 하게 막나”가 더 중요할 때가 많다.

특히 이슈 닫기, 댓글 달기, label 변경, PR close 같은 작업은 외부 사용자에게 보인다.

한 번 잘못 닫으면 기분 문제가 아니라 신뢰 문제가 된다.

그래서 close reason은 넓으면 안 된다.

좁고, 설명 가능하고, 나중에 재검토 가능해야 한다.

proposal-only가 왜 중요한가

proposal-only는 말 그대로 제안만 만드는 단계다.

이 단계에서 Codex가 판단을 한다.

하지만 GitHub를 mutate하지 않는다.

댓글도 닫기도 label 변경도 하지 않는 구조가 기본이다.

ClawSweeper README는 review lane이 proposal-only라고 설명한다.

그리고 review shard는 item별 decision, evidence, suggested comment, runtime metadata, GitHub snapshot hash를 markdown record로 만든다.

이 말은 자동화의 첫 산출물이 “실행”이 아니라 “증거 기록”이라는 뜻이다.

이게 진짜 포인트다.

많은 AI 자동화가 실패하는 이유는 너무 빨리 실행하기 때문이다.

읽자마자 닫고, 판단하자마자 이동하고, 요약하자마자 삭제한다.

그럼 사람이 나중에 확인할 때 남는 게 없다.

“왜 닫았지?”

“어떤 근거였지?”

“그때 이슈 내용이 지금과 같았나?”

이 질문에 답이 없으면 운영자는 결국 자동화를 끄게 된다.

proposal-only는 자동화를 믿기 위한 중간 지대다.

AI가 판단하고, 사람이나 별도 apply가 실행한다.

snapshot hash는 조용하지만 강력하다

GitHub issue와 PR은 살아있는 객체다.

누군가 댓글을 달 수 있다.

작성자가 재현 정보를 추가할 수 있다.

maintainer가 label을 바꿀 수 있다.

PR branch가 업데이트될 수 있다.

그런데 AI가 오전 10시에 판단한 내용을 오후 2시에 그대로 apply하면 문제가 생길 수 있다.

그 사이에 맥락이 바뀌었을 수 있기 때문이다.

그래서 snapshot 검증이 필요하다.

ClawSweeper는 item review record에 GitHub snapshot hash를 남기고, apply 단계에서 저장된 review가 여전히 유효한지 확인한다.

README의 safety model도 snapshot changes가 apply를 막는다고 설명한다.

이건 작은 디테일처럼 보이지만 사실 운영 자동화의 핵심이다.

자동화는 “그때 맞았던 판단”을 “지금 실행해도 되는 판단”으로 착각하면 위험하다.

snapshot 검증은 이 착각을 막는다.

내 식으로 풀면 이렇다.

without snapshot	with snapshot
AI가 판단한 뒤 시간이 지나도 그대로 실행	실행 직전 원본 상태 재확인
새 댓글이나 수정 내용을 놓칠 수 있음	바뀐 item은 apply 차단
왜 틀렸는지 사후 추적 어려움	review record와 live state 비교 가능
빠르지만 불안정	조금 느리지만 감사 가능

이 구조는 GitHub에만 쓰는 게 아니다.

Obsidian inbox 자동 정리에도 쓸 수 있다.

블로그 backlog drop에도 쓸 수 있다.

트레이딩 watchlist 삭제에도 쓸 수 있다.

원본이 바뀔 수 있는 모든 자동화에는 “판단 시점”과 “실행 시점”을 분리해야 한다.

Codex Automations와 연결되는 지점

OpenAI Codex Automations 문서는 recurring task를 background에서 자동화할 수 있다고 설명한다.

결과가 있으면 inbox/Triage에 findings를 남기고, 없으면 task를 archive할 수 있다.

또 Git repository에서는 automation을 local project 또는 별도 worktree에서 실행할 수 있다.

worktree를 쓰면 unfinished local work와 자동화 변경을 분리할 수 있다.

이 부분이 ClawSweeper와 맞물린다.

ClawSweeper 같은 유지보수 자동화는 “한 번 실행하고 끝”이 아니다.

계속 돌아야 한다.

새로운 issue가 생긴다.

old issue가 stale해진다.

PR 상태가 바뀐다.

comment가 추가된다.

그래서 scheduling과 background run이 자연스럽다.

하지만 Codex Automations 문서도 보안 모델을 분명히 말한다.

automations는 unattended로 돌아가며 default sandbox settings를 사용한다.

full access background automation은 elevated risk를 가진다.

그래서 ClawSweeper식 설계는 더 중요해진다.

자동화가 background에서 돈다면 더더욱 proposal-only가 먼저다.

자동화가 write 권한을 갖는다면 더더욱 apply lane이 분리되어야 한다.

자동화가 GitHub item을 닫는다면 더더욱 snapshot 검증이 필요하다.

작은 팀이 베껴야 할 구조

ClawSweeper 전체를 그대로 베끼기는 부담스럽다.

하지만 패턴은 작게 가져올 수 있다.

처음부터 GitHub App, 100 shard, dashboard heartbeat까지 만들 필요는 없다.

작은 팀이나 개인 프로젝트라면 아래 5단계만 해도 충분하다.

단계	최소 구현
1. read-only scan	issue/PR/backlog를 읽기만 한다
2. proposal file	markdown으로 닫기/보류/질문 필요 판단을 남긴다
3. narrow reasons	close/drop/move 가능 이유를 5개 이하로 제한한다
4. snapshot marker	title/body/comment count/updated_at/hash 같은 변경 감지값을 남긴다
5. manual apply	처음엔 사람이 보고 실행한다

이 정도면 자동화라고 부르기 민망할 정도로 소박하다.

근데 이 소박함이 좋다.

처음부터 “AI가 다 닫아줘”로 가면 사고 난다.

처음엔 “AI가 닫아도 될 후보만 말해줘”로 시작해야 한다.

그다음 운영자가 false positive를 본다.

틀린 제안이 얼마나 나오는지 확인한다.

close reason을 줄인다.

snapshot 검증을 더한다.

그다음에야 apply automation을 붙인다.

자동화는 속도보다 신뢰를 먼저 쌓아야 한다.

Obsidian과 블로그 운영에 적용하면

내 볼트 기준으로 바로 적용 가능한 곳도 있다.

예를 들어 블로그 backlog는 계속 쌓인다.

중복 글감도 생긴다.

이미 발행한 글과 너무 가까운 아이디어도 있다.

예전에는 이런 걸 사람이 눈으로 보고 drop하거나 refresh로 바꿨다.

ClawSweeper식으로 바꾸면 이렇게 된다.

blog-idea-sweeper
  1. backlog 글감을 읽는다
  2. 기존 발행 글과 유사도를 본다
  3. drop/refresh/publish 후보를 markdown proposal로 남긴다
  4. 이유는 좁게 제한한다
  5. 사람이 approve하면 status를 바꾼다

닫을 수 있는 이유도 좁게 잡는다.

proposal	허용 이유
drop	이미 같은 제목/검색 의도의 글이 발행됨
refresh	기존 글이 있고 새 정보만 보강하면 됨
publish	중복 낮고 공식 출처가 확보됨
hold	출처가 약하거나 최신 확인 필요
merge	두 아이디어가 같은 글로 합치는 게 낫다

이걸 바로 자동 실행하면 안 된다.

처음엔 markdown review record만 쌓는다.

그 기록을 보면서 “AI가 어떤 글감을 너무 공격적으로 drop하는지” 확인해야 한다.

그다음 일부만 자동화한다.

예를 들어 hold는 자동으로 둬도 되지만, drop은 사람이 승인하게 한다.

이게 현실적인 운영이다.

GitHub issue triage에 적용하면

GitHub issue에 붙이면 구조는 조금 더 명확하다.

자동화 항목	처음 권장 설정
repo scan	read-only
close proposal	markdown artifact
comment draft	suggested comment만 저장
close action	manual apply
label action	처음엔 하지 않음
maintainer-authored item	자동 close 제외
changed snapshot	apply 차단

특히 maintainer-authored item 제외는 좋은 기본값이다.

유지보수자가 직접 남긴 meta issue나 roadmap issue는 일반 stale issue와 다르다.

AI가 “오래됐으니 닫자”고 판단하면 곤란하다.

운영에는 사람이 남긴 의도가 있다.

그 의도는 날짜만 보고 알 수 없다.

그래서 자동화는 사람의 권한과 맥락을 구분해야 한다.

위험한 자동화 신호

아래 신호가 있으면 아직 apply 자동화로 가면 안 된다.

신호	의미
close reason이 모호하다	판단 기준이 넓어서 오탐이 늘어남
evidence가 짧다	나중에 왜 닫았는지 설명 불가
원본 변경 감지가 없다	판단 이후 맥락 변화에 취약
apply와 review가 같은 단계다	실수하면 바로 외부 상태가 바뀜
maintainer/사용자 작성 item 구분이 없다	중요한 운영 item을 닫을 수 있음
실패한 review도 record로 남긴다	불확실한 결과가 정상 결과처럼 보임
dashboard가 없다	자동화 상태를 사람이 감시하기 어려움

AI 자동화는 성공할 때보다 실패할 때 설계가 드러난다.

잘 만든 자동화는 실패해도 조용히 멈추거나, 사람에게 근거를 준다.

못 만든 자동화는 실패하면서 일을 만든다.

그건 자동화가 아니라 업무 생성기다.

우리 그런 거 이미 충분히 많다.

ClawSweeper에서 특히 마음에 드는 부분

내 기준으로 ClawSweeper에서 가장 배울 만한 부분은 네 가지다.

첫째, README가 dashboard 역할을 한다.

별도 대시보드를 만들지 않아도 현재 queue, review outcomes, cadence, audit health, latest activity를 공개적으로 볼 수 있다.

이건 작지만 강하다.

자동화 상태가 README에 있으면 누구나 링크로 확인할 수 있다.

둘째, review와 apply가 분리되어 있다.

AI 판단과 GitHub mutation을 같은 단계에 두지 않는다.

셋째, snapshot 변경이 apply를 막는다.

판단 이후 원본이 바뀌면 실행하지 않는다.

넷째, audit이 자동화를 검증한다.

npm run audit은 live GitHub 상태와 generated record를 비교해 누락, stale, duplicate, protected proposed close 등을 확인한다.

자동화가 검증 대상이라는 인식이 좋다.

이 네 가지는 다른 AI 운영에도 그대로 쓸 수 있다.

블로그 발행 자동화도 마찬가지다.

발행 전에 preflight가 있고, review record가 있고, publish contract가 있고, 발행 후 sync가 있어야 마음이 편하다.

그냥 “AI가 올렸습니다”로 끝나면 나중에 털린다.

털린다는 말은 SEO, 링크, 메타, 중복, 출처, 상태 sync가 다 같이 엉킬 수 있다는 뜻이다.

표현이 좀 세지만, 경험상 맞다.

관련 글

Codex 자동화의 넓은 그림은 Codex for almost everything은 무엇을 바꾸나 2026에서 다뤘다.

MCP와 context budget은 When should Codex users disable MCP servers in 2026?를 보면 된다.

Gemini CLI, Codex, Claude Code의 역할분리는 Gemini CLI를 Codex·Claude Code 옆에 둘 때 무엇을 맡길까 2026에서 정리했다.

이번 글은 그중에서도 “AI가 운영 상태를 바꾸기 전에 어떤 안전장치를 둬야 하는가”에 초점을 맞춘다.

FAQ

Q1. ClawSweeper는 그냥 GitHub issue 자동 close bot인가?

아니다.

공식 README 기준으로 ClawSweeper는 conservative maintainer bot이다.

review lane은 proposal-only이고, 실제 close는 apply lane에서 snapshot 검증 후 진행된다.

그래서 핵심은 자동 close가 아니라 감사 가능한 proposal과 안전한 apply 흐름이다.

Q2. Codex로 내 repo 이슈를 바로 닫게 해도 되나?

처음부터 바로 닫게 하는 건 비추천이다.

먼저 read-only scan과 markdown proposal만 만들게 하자.

false positive를 확인하고 close reason을 좁힌 뒤, 사람이 승인하는 apply 단계부터 붙이는 편이 안전하다.

Q3. snapshot hash는 꼭 필요한가?

GitHub item처럼 원본이 계속 바뀌는 대상이라면 필요하다.

AI가 판단한 시점과 실제 실행 시점 사이에 댓글, label, body, branch 상태가 바뀔 수 있다.

snapshot 검증이 없으면 오래된 판단을 현재 상태에 적용할 위험이 있다.

Q4. Codex Automations로 이런 흐름을 만들 수 있나?

가능한 방향이다.

OpenAI Codex Automations 문서는 recurring background task, Triage inbox, project/worktree 실행, skills 조합을 설명한다.

다만 unattended automation은 sandbox와 권한 리스크가 있으니 read-only 또는 worktree 격리부터 시작하는 편이 좋다.

Q5. 작은 개인 프로젝트도 이런 구조가 필요한가?

작게라도 필요하다.

특히 삭제, 이동, close, publish, 돈과 관련된 작업은 proposal-only가 좋다.

처음엔 review markdown만 만들어도 충분하다.

자동 실행은 그 기록의 품질이 쌓인 뒤에 붙이면 된다.

Q6. 제일 먼저 베낄 한 가지는 무엇인가?

proposal-only다.

AI에게 바로 실행시키지 말고, 먼저 “무엇을 왜 할지” markdown으로 쓰게 하자.

그 기록만 있어도 자동화의 신뢰도가 크게 올라간다.

공식 출처/참고 자료

• OpenClaw GitHub, openclaw/clawsweeper, ClawSweeper README, guardrails, dashboard, review lane, apply lane, safety model, audit 설명.
• OpenClaw ClawSweeper raw README, README.md, 저장소 설명 원문.
• OpenAI Developers, Codex Automations, recurring background task, Triage, worktree, sandbox, skills 조합, permissions/security model.
• OpenAI Developers, Codex best practices, Codex를 teammate처럼 설정하고 MCP, skills, automations, review를 운영하는 기준.
• Threads capture, CHOI OpenAI post, ClawSweeper 사례 포착 및 quick handoff 메모.

마무리

ClawSweeper를 보면서 제일 중요한 메시지는 이거다.

AI 자동화의 다음 단계는 “AI가 더 많이 하게 만들기”가 아니다.

“AI가 실행하기 전에 더 잘 기록하고, 더 좁게 판단하고, 더 안전하게 apply하게 만들기”다.

이 차이가 크다.

AI에게 유지보수를 맡길수록 사람의 역할이 사라지는 게 아니다.

사람의 역할은 실행자에서 운영 설계자로 바뀐다.

무엇을 제안하게 할지.

무엇을 절대 못 하게 할지.

어떤 근거를 남기게 할지.

언제 apply를 막을지.

어디에 audit trail을 남길지.

이 질문들이 답을 얻으면 자동화는 무섭지 않다.

오히려 든든해진다.

반대로 이 질문 없이 “AI야 알아서 닫아”라고 하면, 편한 건 처음 10분뿐이다.

그다음부터는 내가 만든 자동화를 내가 감시하는 이상한 직업이 생긴다.

우리는 일을 줄이려고 자동화하는 거지, 새 직업을 만들려고 자동화하는 게 아니다.

그래서 ClawSweeper의 진짜 교훈은 단순하다.

AI에게 바로 손을 대게 하지 말고, 먼저 흔적을 남기게 하자.

proposal-only부터 시작하자.

그다음 snapshot으로 확인하고, 좁은 apply로 실행하고, audit으로 자동화를 다시 검사하자.

이게 2026년 Codex 자동화의 꽤 현실적인 기준선이다.