최근 Claude Code 이야기는 기술 뉴스라기보다 거의 기술 구경거리처럼 번졌습니다. 알려진 시작점은 Anthropic의 공개 npm 패키지에 디버깅 관련 파일이 실수로 포함됐고, 사람들이 source map을 따라 내부 소스 코드를 빠르게 복원했다는 것이었습니다. 이후 GitHub에 mirror repository까지 등장하면서 커뮤니티 확산 속도가 매우 빨랐습니다.

하지만 제가 이 사건에서 기록해 둘 가치가 있다고 느낀 부분은 가십 자체가 아닙니다. 오히려 상위권 AI 코딩 도구가 어떤 엔지니어링 기반 위에서 동작하는지 일부가 드러났다는 점입니다. 평소 Claude Code를 쓰면서 “전체적인 손맛이 좋다”고 말하지만, 그 사용감이 모델 자체에서 얼마나 오고, 모델 밖의 시스템 설계에서 얼마나 오는지는 쉽게 보이지 않습니다.

저도 Claude Code를 장기간 유료로 사용해 왔습니다. 코드를 쓰고, 글을 쓰고, 블로그를 만들고, 작업 흐름을 정리할 때 터미널 창 여러 개를 동시에 띄우는 일이 흔합니다. 그래서 이번에 궁금했던 것은 “Anthropic이 실수했는가”가 아니라 이미 좋은 사용성을 검증받은 AI coding 제품이 모델을 어떻게 실제 도구로 길들였는가였습니다.

사실부터 정리하자

먼저 확인 가능한 사실부터 분리할 필요가 있습니다. Axios 보도에 따르면 Anthropic은 내부 소스가 공개 패키지에 포함된 것은 인정했지만 고객 데이터나 자격 증명은 유출되지 않았다고 설명했습니다. 또 제가 직접 확인했던 당시 npm 공개 버전 목록에서는 논란이 집중된 2.1.88 버전이 보이지 않았고 바로 앞뒤 버전만 남아 있었습니다.

npm view @anthropic-ai/claude-code versions --json

당시 확인한 목록의 마지막 부분은 다음과 같았습니다.

[
  "2.1.87",
  "2.1.89"
]

이 작은 디테일만으로도 몇 가지는 읽을 수 있습니다. 적어도 “존재하지 않았던 버전을 인터넷이 만들어 냈다”는 이야기는 아니었고, 사건 이후 배포 측에서 정리 작업이 있었을 가능성이 있습니다. 반면 온라인에서 돌던 “1900개 이상의 파일”, “50만 줄이 넘는 TypeScript”, “몇 시간 만에 몇 개의 star와 fork” 같은 숫자는 저는 확정적 사실보다 공개 분석의 규모 참고치로 보는 편이 낫다고 생각합니다. 이런 수치는 너무 빨리 변하기 때문에 글에 고정해 두면 바로 낡습니다.

더 흥미로운 것은 여러 공개 분석이 같은 결론을 가리킨다는 점입니다. Claude Code의 안정적인 사용감은 모델만 강해서 나오는 것이 아니라 모델 바깥의 harness가 두껍게 설계돼 있기 때문이라는 겁니다. 모델을 엔진이라고 보면 실제 제품을 안전하고 지속적으로 움직이게 하는 것은 조향, 브레이크, 계기판, 제한 장치, 차체 같은 주변 시스템입니다. AI 코딩 도구를 깊게 볼수록 모델 점수만 비교해서는 설명이 부족해집니다.

시스템 프롬프트: 계층적 조립

첫 번째로 배울 만한 점은 system prompt가 거대한 한 덩어리의 문장이 아니라 계층형 조립 시스템에 가깝다는 것입니다. 공개된 여러 분석을 보면 Claude Code는 정적 system prompt 하나로 모든 것을 처리하기보다 전역 규칙과 사용자별 컨텍스트를 분리하는 구조를 사용합니다. 위쪽에는 모든 사용자에게 공통인 행동 제약이 들어갑니다. 없는 사실을 만들지 말 것, 함부로 파일을 삭제하지 말 것, 전용 도구가 있으면 우선 사용할 것, 과도한 설계를 피할 것, 사용자가 요구하지 않은 기능을 몰래 추가하지 말 것 같은 규칙입니다. 아래쪽에는 프로젝트의 CLAUDE.md, 사용자 선호, 연결된 MCP, repository 상태 같은 동적 정보가 들어갑니다.

이 구조는 실제 대규모 제품을 운영해 본 팀의 선택처럼 느껴집니다. 사용자가 많아지면 “개인화는 하고 싶지만 컨텍스트 비용은 낮추고 싶다”는 문제가 반드시 생깁니다. 정적 부분은 공유하고 캐시하기 쉽게 만들고, 동적인 부분만 사용자와 작업별로 불러오는 방식은 비싼 컨텍스트 예산을 현재 작업에 의미 있는 정보에 쓰게 해 줍니다.

이 구조는 최근 많은 개발자가 체감하는 또 다른 현상도 설명합니다. 왜 많은 MCP 도구를 한꺼번에 붙이는 것보다 skill처럼 필요할 때 능력을 불러오는 방식이 가벼울 수 있는가 하는 문제입니다. 공개 논의에서도 MCP tool definition 자체가 상당한 token 예산을 차지할 수 있다는 지적이 있었습니다. 도구를 많이 등록하면 모델이 실제 작업을 시작하기도 전에 컨텍스트 창이 도구 설명으로 채워질 수 있습니다. 결국 도구는 많다고 무조건 좋은 것이 아니라 무엇을 기본으로 넣고, 무엇을 필요할 때만 로드할지가 중요합니다.

권한 등급: “할 수 있는 것”과 “해도 되는 것”의 분리

두 번째로 엔지니어링 성숙도의 차이가 크게 느껴지는 부분은 실행 권한과 안전 판단을 하나의 agent에게 모두 맡기지 않는 것입니다. 공개 영상과 분석에서 반복해서 언급된 yoloClassifier 같은 개념은 이름과 달리 더 과감하게 실행하라는 뜻이 아닙니다. 실제 작업을 수행하는 main agent 바깥에서 별도의 판단 계층이 해당 작업을 허용할지 결정하는 구조에 가깝습니다. Allow, Soft Deny, Hard Deny처럼 단계별로 나누는 것은 결국 “할 수 있는가”와 “해도 되는가”를 분리하는 설계입니다.

저는 이 분리를 매우 중요하게 봅니다. AI 코딩 도구에서 큰 사고는 코드를 못 써서보다 너무 자신 있게 쓰고, 지우고, 사용자가 요구하지 않은 것까지 한 번에 바꿔서 생기는 경우가 많습니다. 모든 판단을 같은 agent에게 맡기면 사용감은 시원할 수 있지만 사고 비용이 커집니다. Claude Code 같은 도구를 사람들이 비교적 높은 권한으로 사용할 수 있는 데에는 이런 다층 신뢰 구조가 중요한 역할을 합니다. 사용자는 겉으로 한 agent와 협업하는 것처럼 보지만 뒤에는 “진짜로 선을 넘지 않게 하는 브레이크”가 있습니다.

실제 사용에서도 저는 모델 답변의 문장 품질보다 이 부분이 더 중요하다고 느끼게 됐습니다. 개발 도구에 대한 신뢰는 추상적인 말이 아닙니다. 권한을 조금 더 열어도 되는지, 여러 단계를 연속으로 맡겨도 되는지, 거의 마무리된 디렉터리를 넘겨서 계속 작업하게 해도 되는지의 문제입니다. 다음 순간 폴더를 통째로 지울까 걱정해야 하는 도구라면 아무리 똑똑해도 일상 workflow에 깊게 넣기 어렵습니다.

메모리: 기억하지 말아야 할 것을 알기

세 번째로 인상적인 부분은 메모리 시스템이 무엇을 기억할지가 아니라 무엇을 기억하지 않을지를 구분한다는 점입니다. 사용자 선호, 행동 피드백, 프로젝트 수준의 규칙, 외부 리소스 참조 같은 정보는 상대적으로 안정적이고 장기적으로 상호작용 품질에 영향을 주므로 memory에 적합합니다. 반면 코드의 현재 사실은 메모리로 고정하기 위험합니다. 함수가 몇 번째 줄에 있는지, 특정 모듈이 현재 어떤 구조인지 저장해 두면 refactor 직후부터 잘못된 정보가 됩니다.

이 점은 정말 중요합니다. “더 똑똑한 AI”를 이야기하면 흔히 더 많이 기억하게 만들면 된다고 생각합니다. 하지만 장기간 도구를 써 보면 잘못 기억하는 것이 기억하지 못하는 것보다 더 위험할 때가 많습니다. 선호와 판단은 memory에 두고, 코드 사실은 매번 실제 source를 읽게 하는 방식은 화려하지 않지만 매우 엔지니어링다운 선택입니다.

또 재미있는 부분은 모든 문제를 더 복잡한 retrieval system으로 밀어 넣지 않는다는 점입니다. 공개 분석에서는 Claude Code가 코드 검색에 여전히 텍스트 검색, 즉 grep 계열의 단순한 방법을 많이 활용한다는 이야기가 반복됐습니다. 모든 문제를 먼저 vector database, semantic index, 두꺼운 RAG로 보내지 않는다는 겁니다.

이 선택은 독립 개발자가 특히 볼 만합니다. 모든 단계가 가장 복잡한 버전으로 만들어질 필요는 없습니다. 모델이 강해질수록 불필요하게 복잡한 부분은 오히려 단순하게 유지할 가치가 커집니다.

여기까지 보면 이번 사건이 AI 코딩 시장에 던지는 메시지도 분명해집니다. 공개된 것은 단순히 “어떤 팀이 CLI를 어떻게 작성했는가”가 아닙니다. 이미 제품에서 검증된 하나의 방향을 볼 수 있게 됐습니다. 모델은 기반의 일부일 뿐이고 실제 경험 차이는 prompt system, tool boundary, safety mechanism, context compression, memory extraction, permission classification 같은 요소와 그것들을 하나의 workflow로 묶는 방법에서 만들어진다는 관점입니다.

그래서 저는 이번 사건이 오픈소스 커뮤니티와 후발 팀에 주는 가장 큰 가치가 “Claude Code를 1:1로 복제할 수 있게 됐다”는 데 있지 않다고 봅니다. 이전에는 추측할 수밖에 없었던 엔지니어링 의사결정을 실제에 더 가까운 형태로 비교할 수 있게 됐다는 점이 더 큽니다. 어떤 AI coding 도구는 기능 목록은 비슷한데 왜 Claude Code처럼 자연스럽지 않을까요. 빠진 것은 버튼 하나가 아니라 모델을 제품으로 길들이는 중간 계층일 수 있습니다.

물론 소스가 공개됐다고 해서 다음 달 바로 동급의 대체품이 쏟아지는 것은 아닙니다. 빌드 속도, 팀의 반복 주기, 모델과의 조합, 제품 판단은 디렉터리 구조를 복사한다고 생기지 않습니다. 구조를 따라 할 수 있어도 개발 리듬까지 복사할 수는 없고, 모듈 하나를 재현해도 짧은 기간에 수십 차례 제품을 밀어붙이는 실행력까지 얻는 것은 아닙니다.

그래도 독립 개발자에게 이 사건은 충분히 볼 가치가 있습니다. 앞으로 AI 코딩 도구의 경쟁이 단순히 “어느 모델이 더 강한가”만으로 결정되지 않는다는 점을 보여주기 때문입니다. 다음 단계의 경쟁은 harness engineering을 누가 더 잘하는가에 가깝습니다. agent의 도구, 권한, 메모리, 컨텍스트, 안전 경계를 더 안정적으로 orchestration하는 팀이 “질문에 답하는 모델”을 “매일 쓸 수 있는 개발 파트너”로 만들 가능성이 높습니다.

이런 “모델 바깥의 엔지니어링 계층”에 관심이 있다면 새 Codex는 무엇이 달라졌나: 이제 왜 개발 환경에 더 가까운가와 AI Agent Orchestration이란: 단일 Agent 다음에 왜 오케스트레이션이 중요한가도 이어서 볼 만합니다. 앞 글은 제품 계층에 가깝고, 뒤 글은 시스템 계층에 가깝습니다. 이번 Claude Code 사건과 자연스럽게 연결됩니다.

이런 AI coding 도구와 workflow 구조, 재사용 가능한 설정을 더 깊게 정리하는 글은 앞으로도 같은 주제 묶음 안에서 이어갈 생각입니다.