claw-code 클린룸 재작성 2026, 유출본 없이 하네스 구조만 배우는 법

이 글은 먼저 선을 긋고 시작해야 한다.

나는 유출본 구경 얘기를 하려는 게 아니다. 오히려 반대다.

claw-code를 흥미롭게 본 이유는 유출된 코드를 어디서 구하나가 아니라 유출 사고 이후에도 아키텍처 패턴만 떼어내어 다시 배울 수 있나를 보여주는 사례처럼 보였기 때문이다.

2026년 4월 2일 기준으로 GitHub의 instructkr/claw-code README를 보면, 작성자는 이 프로젝트를 clean-room Python rewrite라고 설명하고, 현재는 Python 작업공간과 Rust 포트를 함께 밀고 있다고 적어두었다.

한 줄 결론부터 말하면 이렇다.

claw-code에서 진짜 볼 만한 건 “Claude Code를 베끼는 법”이 아니라, 하네스 런타임을 commands, tools, task, query_engine, tests, parity audit 같은 추상화로 다시 세우는 방식이다.

이 구조를 실제 운영 문제로 끌고 오면 Claude Code 세션을 갈아탈 때 꼭 남겨야 할 로그는 무엇일까 2026 — handoff 최소셋 같은 handoff 문제와 이어지고, 배포 직전 검수 게이트까지 생각하면 AI가 만든 PDF를 바로 배포하면 왜 사고가 나나 2026 — 검수·버전·저작권 체크리스트 같은 출고 레이어로도 자연스럽게 이어진다.

답을 먼저 적으면

claw-code는 Claude Code 유출 이후 등장한 clean-room 재작성 프로젝트를 표방한다.
GitHub README 기준으로 현재 메인 소스 트리는 Python-first이고, Rust 포트도 병행 중이다.
Python 작업공간은 commands.py, tools.py, task.py, query_engine.py, port_manifest.py 같은 모듈로 쪼개져 있다.
저장소는 the exposed snapshot is no longer part of the tracked repository state라고 적고, 현재 초점을 Python porting work로 돌렸다고 설명한다.
그래서 이 프로젝트는 불법 자료 소비보다 하네스 추상화가 어디까지 재구현 가능한가를 보는 구조 사례로 읽는 쪽이 더 생산적이다.

이런 상황이면 특히 잘 맞는다

Claude Code 류 에이전트 하네스를 구조 관점에서 이해하고 싶은 사람
툴, 세션, 태스크, 쿼리 엔진을 어떤 단위로 쪼개야 할지 고민하는 사람
clean-room 재작성이라는 표현이 실무적으로 무엇을 뜻하는지 궁금한 사람
유출 이슈 소비보다 무엇을 배우고 무엇을 안 배워야 하는지 선을 긋고 싶은 사람
Python이나 Rust로 에이전트 런타임을 직접 만져보려는 사람

지금 결론

질문	claw-code에서 읽히는 답
하네스는 채팅 UI가 핵심인가	아니다, runtime 구조가 핵심
clean-room이면 무조건 안전한가	그렇게 단정하면 안 됨, 일단 작성자 주장과 구조를 분리해 봐야 함
당장 배울 만한 건 뭔가	commands, tools, task orchestration, query summary, tests
Python 포트만 보면 되나	아니다, Rust 포트 방향도 같이 봐야 함
이걸 그대로 따라 만들면 되나	아니다, 패턴만 배우고 구현은 자기 맥락에 맞게 다시 짜야 함

핵심은 이거다. 이 프로젝트는 법적 안전성의 정답지라기보다, “큰 에이전트 하네스를 어떤 모듈로 쪼갤까”를 생각하게 만드는 설계 메모에 가깝다.

내가 직접 확인한 것과 아직 아닌 것

이 글도 선을 분명히 긋고 간다.

내가 직접 확인한 것

GitHub 저장소 README
저장소 루트 구조
Python 작업공간 파일명과 Quickstart
Rust 워크스페이스 구성 설명
clean-room, exposed snapshot 제거, ownership disclaimer 문구

아직 아닌 것

이 저장소의 법적 안전성을 내가 검증한 것은 아니다
Python 포트가 원본 시스템과 기능적으로 동등하다는 것도 내가 검증한 건 아니다
실제로 모든 명령을 돌려 장기 세션 안정성을 확인한 것도 아니다

즉 이 글은 이 저장소가 안전합니다가 아니라 README와 구조를 기준으로 무엇을 배울 수 있나에 대한 메모다.

이 저장소가 흥미로운 이유: 하네스를 파일 단위로 다시 쪼갠다

GitHub README에 나온 Python 작업공간을 보면 이렇게 적혀 있다.

commands.py
tools.py
task.py
query_engine.py
models.py
port_manifest.py
main.py
tests/

이 조합이 되게 중요하다.

왜냐면 이건 “하네스를 하나의 거대한 앱”으로 보지 않고, 대충 아래 다섯 덩어리로 나눠 본다는 뜻이기 때문이다.

1. commands

사용자 진입점과 명령 메타데이터.

2. tools

에이전트가 실제로 쓸 capability 목록.

3. task

일감을 어떻게 묶고 처리할지에 대한 orchestration 단위.

4. query_engine

현재 작업공간을 요약하고 질의 가능한 형태로 다시 드러내는 층.

5. tests / parity audit

재작성 프로젝트가 “비슷해 보인다”에서 멈추지 않게 하는 검증 층.

즉 이 저장소는 구조적으로 대답하는 에이전트보다 오래 굴러가는 런타임 쪽에 더 가까운 냄새가 난다.

README에서 가장 중요한 문장 3개

이 프로젝트를 읽을 때 내가 중요하게 본 문장은 세 개였다.

1. clean-room Python rewrite

README는 결과물을 architectural patterns를 잡은 clean-room Python rewrite라고 설명한다. 이건 중요한 주장이다. 하지만 동시에 작성자 주장이라는 점도 잊으면 안 된다.

2. exposed snapshot is no longer part of the tracked repository state

이 문장은 방향 전환을 말해준다. 즉 지금 저장소의 메인 서사는 노출된 스냅샷 보관이 아니라 Python porting work로 초점을 이동했다는 선언이다.

3. not yet a full runtime-equivalent replacement

이건 의외로 좋았다. README가 과장만 하지 않고, 아직 full runtime-equivalent replacement는 아니라고 적는다.

즉 적어도 문서상으론 완벽 복제보다 현재 가능한 수준의 포트와 검증으로 자신을 설명하고 있다.

Python 작업공간에서 바로 배울 수 있는 것

Quickstart를 보면 이 프로젝트는 단순히 파일만 깔아둔 게 아니다.

README에 나온 명령은 이렇다.

python3 -m src.main summary
python3 -m src.main manifest
python3 -m src.main subsystems --limit 16
python3 -m unittest discover -s tests -v
python3 -m src.main parity-audit
python3 -m src.main commands --limit 10
python3 -m src.main tools --limit 10

이게 왜 좋냐면, 재작성 프로젝트가 보통 코드 있음 수준에서 끝나기 쉬운데 여긴 최소한

현재 구조를 요약하는 경로
manifest를 보는 경로
모듈 목록을 보는 경로
테스트 경로
parity audit 경로

까지 따로 둔다는 뜻이기 때문이다.

즉 이 저장소를 보며 바로 떠올릴 수 있는 질문은 이런 거다.

내 하네스에도 manifest가 필요한가
내 툴 목록을 한 번에 inspect하는 명령이 있는가
“원본과 비슷한가”를 체크하는 parity audit 같은 게 필요한가

이런 질문은 꽤 생산적이다.

Rust 포트가 말해주는 방향성

이 저장소가 재미있는 건 Python에서 끝나지 않는다는 점이다.

README 기준 Rust 워크스페이스에는 이런 크레이트가 있다.

api-client
runtime
tools
commands
plugins
compat-harness
claw-cli

여기서 runtime, tools, commands, plugins가 분리돼 있다는 것만 봐도 작성자가 하네스를 단일 바이너리보다 계약이 다른 여러 층의 조합으로 보고 있다는 추정이 가능하다.

내 해석으로는 이렇다.

Python은 구조를 빨리 세우는 데 좋고
Rust는 런타임 안정성, 성능, 메모리 안전성 쪽으로 밀기 좋다

즉 이 프로젝트는 단순한 언어 포트라기보다 하네스 구조를 어느 언어에서 어떻게 굴릴지 실험하는 장처럼 읽힌다.

이걸 보고 바로 따라 만들면 안 되는 이유

여기서 중요한 브레이크가 있다.

claw-code를 흥미롭게 읽는 것과 그대로 흉내내는 건 완전히 다른 이야기다.

특히 아래는 분리해서 봐야 한다.

1. 구조 패턴

배울 수 있다.

commands / tools / task 분리
parity audit
runtime 레이어링
plugin 분리

2. 법적·윤리적 안전성

이건 저장소 README만 보고 확정할 수 없다.

README는 ownership disclaimer와 clean-room 서술을 두고 있지만, 그 자체가 곧바로 모든 논점을 해결해주는 건 아니다.

즉 실무적으로는

구조는 배울 수 있음
법적 안심까지 한 번에 가져오면 안 됨

으로 읽는 게 맞다.

내 워크플로우 기준으로 진짜 얻은 것

나는 이런 저장소를 볼 때 “와 stars 많다”보다 먼저 내 구조에 뭘 이식할 수 있나를 본다.

이번에 건진 건 네 개다.

1. 하네스를 capability inventory로 본다

툴이 몇 개 있는지, 명령이 몇 개인지, 어떤 서브시스템이 있는지 따로 inspect하는 관점이 중요하다는 걸 다시 느꼈다.

2. runtime summary 명령은 꽤 유용하다

summary, manifest, subsystems 같은 진단 명령은 하네스가 커질수록 점점 더 필요해진다.

3. parity audit는 생각보다 좋은 패턴이다

비슷해 보인다고 끝내지 않고 어디까지 닮았고 어디서부터 다른지 따로 체크하는 루프가 있으면 감이 아니라 상태로 이야기할 수 있다.

4. 테스트가 없는 재작성은 그냥 팬픽이 되기 쉽다

이건 좀 세게 말하면, 재작성 프로젝트에서 tests/가 없으면 구조 연구가 아니라 감상문이 되기 쉽다.

1분 체크리스트

STEP 1. 이 프로젝트를 “유출 파생물”이 아니라 “구조 사례”로 먼저 읽는다

처음부터 자극적인 프레임으로 보면 얻는 게 적다.

STEP 2. 어떤 모듈로 하네스를 쪼갰는지 본다

commands
tools
task
query_engine
runtime
plugins

이렇게 역할을 분리했는지가 핵심이다.

STEP 3. summary / manifest / parity-audit 같은 진단 루프를 본다

재작성은 코드를 쓰는 것보다 상태를 설명할 수 있게 만드는 게 더 중요할 때가 많다.

STEP 4. clean-room 서술과 법적 결론을 같은 걸로 보지 않는다

작성자의 설명은 출발점이지, 최종 판정문이 아니다.

STEP 5. 내 프로젝트에 가져갈 패턴만 뽑아낸다

그대로 따라 하기보다 내 하네스에 manifest가 필요한가, tools inventory가 필요한가 같은 질문으로 바꾸는 게 생산적이다.

실수 TOP 5

1. clean-room이라고 적혀 있으니 모든 논점이 끝났다고 믿는다

그건 README 서술이지, 외부 검증 완료 도장이 아니다.

2. stars 수를 기술 검증으로 착각한다

관심도와 구현 품질은 별개다. 요즘 GitHub는 특히 더 그렇다.

3. Python 포트만 보고 런타임 구조를 다 이해했다고 생각한다

Rust 포트 방향까지 같이 봐야 의도가 더 잘 보인다.

4. 테스트 없는 재작성도 충분하다고 본다

테스트가 없으면 재작성은 구조 연구보다 인상비평이 되기 쉽다.

5. 그대로 베끼면 배운 거라고 생각한다

진짜 학습은 복제가 아니라 패턴을 추상화해서 자기 시스템에 다시 설계하는 데 있다.

FAQ

Q. claw-code는 정확히 뭐야?

A. GitHub README 기준으로는 Claude Code 노출 이후 등장한 clean-room Python rewrite 프로젝트를 표방하며, 현재는 Python 작업공간과 Rust 포트를 함께 발전시키는 하네스 연구 프로젝트처럼 보인다.

Q. 이 프로젝트의 핵심은 Python이야, Rust야?

A. 지금 메인 트리는 Python-first라고 적혀 있지만, README만 보면 장기적으로는 Rust 런타임 쪽 비중도 꽤 커 보인다. 둘 다 보는 게 맞다.

Q. 이걸 보면 Claude Code를 그대로 이해할 수 있어?

A. 그대로는 아니다. 다만 하네스를 어떤 추상화로 나눌 수 있는지, 예를 들어 commands/tools/task/runtime 같은 단위는 꽤 많이 배울 수 있다.

Q. clean-room이면 안심하고 참고해도 돼?

A. 그건 너무 빠른 결론이다. 구조적 학습과 법적 안전성 판단은 서로 다른 문제라서, 둘을 한 문장으로 묶으면 안 된다.

Q. 내 프로젝트에 바로 가져올 만한 건 뭐가 있어?

A. manifest, summary, parity audit, tool inventory, runtime layer 분리 같은 진단/계약 패턴은 꽤 바로 응용 가능하다.

참고 자료

GitHub, instructkr/claw-code README: repo
GitHub repo README 중 clean-room, Python-first, Rust port 설명: readme excerpt
Claude Code Skills 문서: Claude Docs