Claude Code 소스 유출 이슈를 보면 왜 모델보다 하네스 엔지니어링이 더 중요해 보이는지 알 수 있다

Claude Code 소스 유출 이슈를 보면 왜 모델보다 하네스 엔지니어링이 더 중요해 보이는지 알 수 있다

최근 Reddit과 X를 통해 Claude Code 소스가 npm 레지스트리의 map 파일을 통해 노출됐다는 이야기가 퍼졌다. 이 이슈는 보안 관점에서도 별도로 볼 가치가 있지만, 에이전트 엔지니어링 관점에서도 꽤 흥미로운 힌트를 준다.

보통 이런 사건이 생기면 사람들은 먼저 이렇게 묻는다.

• 어떤 모델을 썼나
• 프롬프트가 어땠나
• 시스템 프롬프트나 튜닝이 얼마나 대단했나

그런데 관련 구현이나 이를 바탕으로 재구성된 프로젝트 구조를 보면, 정작 눈에 들어오는 건 모델 호출부보다 세션, 작업, 권한, 툴, 런타임 계층이다. 다시 말해 Claude Code 같은 도구가 강하게 느껴지는 이유는 모델 자체도 있겠지만, 그 모델을 감싸는 하네스(harness) 가 꽤 두껍기 때문이라는 점이 더 선명하게 보인다.

이 글은 Reddit에 올라온 Claude Code 소스 유출 이슈와, 이를 바탕으로 공개된 instructkr/claw-code 구조를 보면서 왜 좋은 모델보다 좋은 하네스가 체감 성능을 더 크게 바꾸는지 정리한 글이다.

여기서 말하는 하네스는 무엇인가

하네스는 단순한 wrapper가 아니다. 모델 앞뒤에 붙는 전체 운영 구조에 가깝다.

예를 들면 아래 같은 것들이다.

• 세션 구조
• 작업 그래프
• 권한 모델
• 도구 호출 계층
• transcript / history 관리
• 실행 런타임
• 실패 후 복귀 경로

즉, 모델이 답을 만드는 두뇌라면 하네스는 그 두뇌가 실제로 일을 하게 만드는 작업장에 가깝다.

이번 이슈에서 진짜 흥미로운 지점

표면적으로 이 사건은 “소스가 노출됐다”는 보안 이슈다. 하지만 엔지니어 입장에서 더 흥미로운 건 소스나 구조를 볼 때 어디가 두꺼운가다.

실제로 claw-code 쪽에서 눈에 띄는 파일 이름들은 대체로 이런 것들이다.

• session_store.py
• task.py, tasks.py
• permissions.py
• tool_pool.py, tools.py
• runtime.py, remote_runtime.py
• transcript.py, history.py
• command_graph.py, bootstrap_graph.py
• execution_registry.py
• query_engine.py

이 파일 목록은 그냥 “모델 API 한 번 호출하는 CLI”의 모양이 아니다. 오히려 작업을 받아서, 쪼개고, 권한을 판단하고, 도구를 고르고, 상태를 남기고, 다시 이어가는 시스템의 모양에 더 가깝다.

여기서 중요한 건 단순히 파일 개수가 많다는 사실이 아니다. 중심 관심사가 모델 호출부보다 작업 운영 계층에 더 가깝게 보인다는 점이다.

왜 이 구조가 중요하냐

좋은 에이전트는 말을 잘하는 시스템보다 일을 안정적으로 계속할 수 있는 시스템일 때 더 강하게 느껴진다.

예를 들어 사용자가 체감하는 유능함은 보통 이런 데서 나온다.

• 한 번에 끝나지 않는 작업을 잃지 않는다
• 중간에 실패해도 어디서 멈췄는지 보인다
• 같은 작업을 여러 번 시켜도 품질 편차가 덜하다
• 필요한 도구를 적절한 타이밍에 잘 고른다
• 위험한 작업은 적절히 멈춘다
• 결과와 근거가 같이 남는다

이건 모델 자체의 언어 능력만으로는 잘 설명되지 않는다. 오히려 세션 구조, task 구조, permissions, transcript, runtime 같은 계층이 받쳐줘야 가능하다.

좋은 에이전트는 보통 모델보다 바깥이 더 두껍다

이건 Claude Code만의 얘기가 아니다. OpenClaw를 운영하거나 다른 코딩 에이전트를 같이 굴려봐도 비슷한 결론에 도달한다.

강한 에이전트 시스템은 보통 아래 계층이 두껍다.

1. 세션 계층

• 지금 무슨 일을 하고 있는지
• 어디까지 진행했는지
• 실패하면 어디서 다시 시작할지
• 이전 판단 근거가 무엇인지

이게 없으면 모델이 좋아도 긴 작업은 금방 흐려진다.

2. 작업 계층

• 어떤 일을 하나의 task로 볼지
• 무엇을 병렬로 돌릴지
• 무엇은 직렬로 묶어야 하는지
• 누가 최종 결과를 종합할지

이게 없으면 모델은 긴 채팅창 안에서 그때그때 반응하는 수준에 머무르기 쉽다.

3. 권한 계층

• 어느 파일을 읽을 수 있는지
• 어떤 도구를 쓸 수 있는지
• destructive action은 언제 막을지
• 외부 전송은 언제 승인받을지

이게 없으면 에이전트는 강한 게 아니라 그냥 위험해진다.

4. 도구 계층

• 파일 읽기/쓰기
• 검색
• 테스트 실행
• 상태 점검
• 브라우저 사용
• 메시지 전달

이게 잘 붙어야 모델이 “아는 척”이 아니라 실제로 일을 전진시킬 수 있다.

왜 사람들은 모델이 핵심이라고 오해하나

이유는 단순하다. 사용자가 겉으로 보는 건 답변이기 때문이다.

보통은 이렇게 느낀다.

• 답변이 자연스럽다
• 코드가 그럴듯하다
• 설명이 길고 좋다
• 작업을 잘 이해하는 것 같다

그래서 자연스럽게 “모델이 좋아서 그렇구나”라고 생각하게 된다. 물론 일부는 맞다. 하지만 운영해 보면 같은 모델이어도 아래 차이가 훨씬 크게 체감된다.

• 툴이 실제 작업 수준으로 연결돼 있는가
• 세션이 작업 단위로 분리돼 있는가
• 실패 후 다시 이어갈 수 있는가
• 병렬 작업이 질서 있게 돌아가는가
• transcript와 history가 유지되는가
• 권한 경계가 안정적으로 작동하는가

즉, 사용자가 느끼는 유능함은 모델의 문장 품질만이 아니라 구조의 일관성에서 많이 온다.

claw-code 구조가 보여주는 것

instructkr/claw-code 레포를 보면, 가장 눈에 띄는 건 모델을 감싼 작업 구조다.

예를 들어:

• command_graph.py, bootstrap_graph.py
  • 단순 명령 실행이 아니라, 초기화와 실행 흐름이 그래프 구조로 나뉘어 있음을 암시한다.
• execution_registry.py
  • 어떤 실행이 어떻게 등록되고 추적되는지가 중요하다는 뜻이다.
• session_store.py
  • 세션이 일회성 입력창이 아니라 상태를 가진 단위라는 뜻이다.
• permissions.py
  • 권한은 부가 옵션이 아니라 시스템 핵심이라는 뜻이다.
• tool_pool.py, tools.py
  • 모델이 직접 다 하는 게 아니라 도구 선택과 호출 구조가 중요하다는 뜻이다.
• transcript.py, history.py
  • 좋은 에이전트는 결과만이 아니라 작업 흔적을 관리해야 한다는 뜻이다.
• runtime.py, remote_runtime.py
  • 로컬/원격 실행 환경을 따로 보는 런타임 설계가 중요하다는 뜻이다.

이건 그냥 “모델 앞에 CLI를 하나 붙였다” 수준이 아니다. 모델을 실제 작업 시스템으로 바꾸는 계층이 이미 중심부에 있다는 걸 보여준다.

모델보다 하네스가 성능을 더 바꾸는 순간들

내가 보기엔 아래 순간에는 특히 모델보다 하네스가 더 중요해진다.

긴 작업

한 번에 끝나지 않는 작업은 세션과 상태 관리가 핵심이다.

여러 단계 작업

읽기 → 수정 → 검증 → 요약처럼 흐름이 있는 작업은 task 구조가 중요하다.

실패가 잦은 환경

네트워크, 브라우저, 메시징, 백그라운드 프로세스가 섞이면 복구 설계가 중요하다.

여러 도구를 묶는 작업

모델 호출보다 도구 orchestration 품질이 체감 성능을 좌우한다.

권한이 예민한 작업

잘하는 것보다 안전하게 멈추는 게 더 중요해진다.

즉, 하네스는 부가 기능이 아니라 실전 성능을 결정하는 운영 계층이다.

그래서 Claude Code가 강하게 느껴지는 이유를 이렇게 본다

내 기준으로 Claude Code 같은 도구가 강하게 느껴지는 이유는 대충 이런 조합이다.

• 모델 자체의 기본 성능
• 긴 문맥을 다루는 인터페이스
• 세션/기록 관리
• 작업 단위 분리
• 도구 호출 구조
• 권한과 실행 방식
• transcript와 history가 주는 연속성

즉, “모델이 좋아서”만이 아니라 좋은 모델을 일하는 시스템 안에 잘 끼워 넣었기 때문에 강하게 느껴지는 거다.

이건 OpenClaw를 운영할 때도 거의 같다. 단순히 더 좋은 모델을 붙이는 것보다:

• 작업을 어떻게 분해할지
• 메인 허브와 작업기를 어떻게 나눌지
• 어떤 상태를 기록할지
• 실패하면 어디서 다시 시작할지
• 어떤 도구를 어떤 권한으로 부를지

이런 걸 먼저 정리하는 편이 체감 개선이 더 클 때가 많다.

내가 얻는 실전 교훈

이번 이슈를 보면서 다시 확인한 건 이거다.

1. 강한 에이전트는 모델보다 바깥이 두껍다

좋은 시스템일수록 session, task, permissions, tools, runtime, transcript 계층이 분명하다.

2. 유능함은 문장 품질보다 운영 구조에서 온다

말을 잘하는 것보다, 같은 일을 안정적으로 반복하는 구조가 더 중요하다.

3. 하네스가 약하면 모델 업그레이드 효과도 제한적이다

세션이 꼬이고 툴이 불안정하면 좋은 모델도 금방 체감 성능이 떨어진다.

4. 소스가 드러났을 때 진짜 배울 건 프롬프트보다 구조다

모델 호출부보다, 그 모델을 어떤 작업 흐름 속에 두었는지를 보는 편이 더 실무적이다.

마무리

Claude Code 소스 유출 이슈 자체는 보안 관점에서 별도로 봐야 한다. 하지만 에이전트 엔지니어링 관점에서는 한 가지를 더 선명하게 보여준다.

강한 에이전트의 핵심은 모델만이 아니다. 오히려 실전에서 체감 성능을 크게 바꾸는 건 아래다.

• 세션 구조
• 작업 그래프
• 권한 모델
• 도구 호출 계층
• transcript / history
• 실패 후 복귀 경로

그래서 앞으로 에이전트를 더 잘 만들고 싶다면, 모델 비교표만 보는 것보다 좋은 모델을 어떤 하네스 안에 넣을지를 먼저 설계하는 편이 훨씬 실용적이다.

결국 사람들은 모델을 기억하지만, 실제 성능 차이는 자주 하네스가 만든다.