Claude Code 유출을 보고 제일 먼저 든 생각은 “와, 미래다”가 아니라 “아, 결국 이런 식으로 굴리는구나”였다. Anthropic은 이번 일을 릴리스 패키징 실수로 인한 소스 유출이라고 설명했고, 외부로 나온 건 Claude Code 제품 코드였지 고객 데이터나 자격 증명은 아니라고 했다. 공개된 규모도 대략 50만 줄, 거의 2천 개 파일 수준이었다.
이 글은 단순히 “유출이 있었다”는 차원을 넘어서, 그 유출에서 무엇이 실제로 확인됐고, 무엇은 합리적 추론이며, 무엇은 아직 미검증인지까지 포함해 정리한 버전이다. 아래 내용은 네가 준 본문과 데스크탑의 deep-research-report.md를 함께 반영해, 빠진 내용 없이 읽기 좋게 재구성한 완전판이다.
1. “욕하면 더 잘한다”는 밈은 반쯤만 맞다
유출 분석에 따르면 userPromptKeywords.ts 쪽에 frustration regex가 있었고, 패턴 안에는 wtf, this sucks, so frustrating, damn it 같은 표현이 들어간다. 적어도 Anthropic이 “사용자가 지금 빡친 상태인지”를 따로 감지하고 있었다는 건 맞다.
다만 여기서 바로 “욕설하면 Claude가 더 잘해진다”로 가면 과장이다. deep-research-report.md 기준으로 확인되는 건 어디까지나 욕설·좌절 표현을 감지하는 로직의 존재다. 별도 코드 뷰/토론에서는 이 값이 tengu_input_prompt 이벤트로 is_negative, is_keep_going 같은 플래그와 함께 로깅되는 흐름이 제시되지만, 공개된 범위 안에서 그 감지 결과가 모델 프롬프트나 응답 품질 개선 로직으로 직접 이어진다는 1차 증거는 확보되지 않았다.
즉, 더 정확하게 말하면 이건 “욕하면 더 잘한다”가 아니라, “욕하면 지금 사용자가 좌절 상태라는 신호를 시스템이 따로 감지하고 있었을 가능성이 높다” 정도다. 제품 분석, UX 개선, 이탈 예측 같은 용도로는 충분히 쓸 만한 신호지만, 성능 향상으로 직결된다고 단정하는 건 아직 이르다.
2. Undercover Mode는 루머가 아니라 코드에 대놓고 있었다
Undercover Mode는 루머가 아니라 코드에 대놓고 있었다. 주석부터가 “공개/오픈소스 저장소 기여용 안전 유틸리티”라고 적혀 있고, 내부 코드네임, 미출시 버전, 내부 프로젝트명, 심지어 “Claude Code”라는 말과 AI 정체, Co-Authored-By 같은 attribution까지 빼라고 지시한다. 더 재밌는 건 주석에 “모델은 자신이 어떤 모델인지도 알려주지 않는다”는 취지까지 들어 있다는 점이다.
이건 그냥 숨은 기능 하나가 아니라, 직원용 빌드와 외부용 빌드가 실제로 갈라져 있었다는 뜻에 가깝다. Undercover 경로 자체가 process.env.USER_TYPE === 'ant'로 묶여 있고, 코드 주석엔 외부 빌드에서는 이런 ant-only 분기가 dead-code elimination으로 통째로 날아간다고 적혀 있다. import 흔적에도 cli/handlers/ant.js, sessionDataUploader 같은 내부 전용 경로가 보인다. 같은 앱처럼 보여도 사내 dogfooding 빌드는 사실상 다른 종족이었다.
deep-research-report.md 쪽 정리를 보면 이 부분은 꽤 강하게 확인되는 사실이다. 실제로 UNDERCOVER MODE — CRITICAL이라는 지시문이 존재하고, 공개 오픈소스 저장소에서 커밋/PR 메시지에 내부 코드네임, 내부 리포/프로젝트명, Claude Code 언급, AI 흔적, Co‑Authored‑By 라인 등을 금지하는 규칙이 명시돼 있다고 정리돼 있다.
기술적으로도 이건 단순한 “알아서 조심해라”가 아니라,
- 커밋/PR 생성용 시스템 프롬프트에 언더커버 규칙을 주입하고
- 커밋 바닥글이나 공동작성자 표기 같은 AI 흔적을 출력 단계에서 제거하는 방식
으로 보인다.
이건 보안 측면에서는 이해가 된다. 내부 코드네임, 내부 링크, 사내 프로젝트명이 외부 오픈소스 저장소에 흘러나가면 그 자체로 정보 노출이기 때문이다. 하지만 동시에 오픈소스 커뮤니티에서 AI 사용 공개, 저작 기여 표기, 투명성을 요구하는 정책과 충돌할 수 있다. 그래서 이 기능은 기술적으로 흥미로운 동시에, 윤리적으로는 꽤 날카로운 지점이다.
3. 직원용 빌드와 외부용 빌드는 실제로 달랐다
Undercover만 따로 있는 게 아니라, 전체적으로 봐도 직원 전용 게이트가 실제로 들어가 있었다는 점이 더 중요하다. process.env.USER_TYPE === 'ant' 분기는 단순 장난이 아니라 여러 동작을 가르는 기준으로 보인다.
deep-research-report.md에 따르면 이 분기는 언더커버뿐 아니라 자동 모드 분류기(yolo classifier)나 텔레메트리 흐름에서도 관측된다. 예를 들어 프롬프트 추천 기능 로깅에서 USER_TYPE === 'ant'인 경우에만 suggestionText나 finalInput 같은 민감 데이터가 이벤트 페이로드에 포함될 수 있는 코드가 보인다고 정리돼 있다.
즉 같은 제품처럼 보여도 실제로는,
- 직원/내부 빌드에서만 켜지는 기능
- 직원 계정에서만 강해지는 로깅
- 외부 빌드에서는 dead-code elimination으로 사라지는 경로
가 함께 존재했을 가능성이 높다.
이건 꽤 현실적인 설계다. 내부 QA, 실험, dogfooding, 디버깅을 위해선 이런 분기가 필요하다. 하지만 외부 시선에서 보면 “같은 제품인데 왜 어떤 기능은 문서에도 없고, 어떤 동작은 사용자마다 다르게 보이냐”는 논란이 생기기 쉬운 구조이기도 하다.
4. 멀티에이전트는 마법이 아니라 구조였다
멀티에이전트도 이름만 거창한 게 아니라 실제 뼈대가 있었다. COORDINATOR_MODE가 켜지면 coordinator가 worker를 지휘하고, 내부 worker tool set에는 TEAM_CREATE, TEAM_DELETE, SEND_MESSAGE, SYNTHETIC_OUTPUT 같은 툴이 등장한다. worker는 scratchpad 디렉터리를 읽고 쓸 수 있고, 시스템 프롬프트에는 coordinator가 worker들에게 research, implement, verify를 분담시키라고 적혀 있다.
미래의 마법이라기보다, feature flag + worker tool 제한 + 공유 scratchpad + 시스템 프롬프트의 조합이다.
다만 여기서도 deep-research-report.md가 짚는 포인트가 중요하다. COORDINATOR_MODE 조건부 import 흔적 자체는 확인되지만, “Coordinator가 정확히 어떤 방식으로 여러 AI를 관리하고 작업을 분해하는지”를 완전히 펼쳐 보여주는 1차 근거는 제한적이다. 즉,
- 멀티에이전트 구조의 뼈대가 있었다는 건 상당히 그럴듯하고,
- 실제 상세 오케스트레이션 구현은 일부만 보였다고 보는 편이 정확하다.
그래서 이건 “완전히 허상은 아닌데, 모든 세부가 다 입증된 것도 아닌” 상태로 보는 게 맞다.
5. “AI 안에 AI 감시자”도 과장이 아니다
Anthropic 공식 설명대로 auto mode는 두 겹이다. tool output은 prompt-injection probe가 보고, 실제 action은 transcript classifier가 실행 전에 다시 본다. 공식 문서에는 이 분류기가 Sonnet 4.6에서 돌고, 읽기 전용 작업과 작업 디렉터리 편집은 분류기를 안 태우며, 분류기는 사용자 메시지와 도구 호출만 보고 Claude의 텍스트와 tool 결과는 제거된다고 적혀 있다. 그리고 차단이 3연속이거나 세션 누적 20회면 auto mode가 멈추고 다시 사람 승인 모드로 돌아간다.
이 부분은 deep-research-report.md 기준으로도 핵심 골격이 상당 부분 확인된다. yoloClassifier.ts는 auto mode 분류를 위해 <transcript>로 래핑된 내용을 만들고, sideQuery(stage1Opts)로 1단계 판정을 호출한 뒤 필요하면 2단계 판정까지 가는 구조를 가진다고 정리돼 있다. 요청 옵션에는 querySource: 'auto_mode', temperature: 0, max_tokens, thinking 설정 등이 포함되고, 캐시 컨트롤도 auto_mode 소스로 설정된다고 한다.
즉 이건 거의 전형적인 “AI가 다른 AI의 도구 사용을 감시하고 승인/거부하는 구조”다.
6. 3회 거부 후 자동 모드가 완전히 꺼진다기보다, 승인 모드로 폴백한다
이 부분은 밈처럼 퍼질 때보다 실제 구현 설명이 더 흥미롭다. 흔히 “3번 막히면 auto mode가 꺼진다”고 요약되지만, deep-research-report.md의 표현을 따르면 조금 더 정확한 해석은 이렇다.
DENIAL_LIMITS.maxConsecutive = 3가 명시돼 있고- 연속 거부가 임계치를 넘으면
- 완전히 끝나는 것보다는 prompting 기반 사용자 확인 흐름으로 폴백하도록 설계돼 있다.
즉 엄밀히는 “자동 모드가 영구 비활성화된다”기보다, 자동 승인 흐름이 중단되고 다시 사람 승인 모드로 넘어간다에 가깝다.
다만 별도로 autoModeCircuitBroken, GrowthBook 설정, enabled === 'disabled' 같은 흔적도 있어, 서버 플래그로 재진입을 막는 식의 더 강한 차단 정책도 일부 있었을 가능성은 있다. 이 대목은 단순한 UX가 아니라 안전과 가용성 사이의 설계 선택으로 보는 편이 맞다.
7. 서브에이전트도 혼자 새지 못하게 막아놨다
더 디테일한 포인트는 서브에이전트도 혼자 새지 못하게 막아놨다는 점이다. 공식 문서에는 서브에이전트를 만들기 전에도 분류기가 위임 내용 자체를 심사하고, auto mode 안에서는 서브에이전트가 frontmatter에 적어둔 자체 permissionMode도 무시되며, 끝난 뒤에는 결과 전체를 다시 검사한다고 적혀 있다.
멀티에이전트라고 해서 경비실을 한 번만 통과하는 구조가 아니었다.
이건 그냥 안전장치가 있는 정도가 아니라, 하위 에이전트 단위로 권한을 다시 좁히고, 시작 전·실행 중·결과 후를 각각 본다는 뜻이다. 요즘 멀티에이전트 데모들은 화려하지만, 실제 제품은 결국 이런 식으로 분권된 권한 + 반복 심사 위에서 굴러간다는 걸 보여준다.
8. anti-distillation 쪽은 더 업계스럽다
anti-distillation 쪽은 더 업계스럽다. 유출 분석에 따르면 ANTI_DISTILLATION_CC가 켜지면 요청에 anti_distillation: ['fake_tools'] 힌트를 넣고, 서버가 시스템 프롬프트에 decoy tool을 주입하게 되어 있었다. 누가 Claude Code API 트래픽을 녹화해서 경쟁 모델 학습 데이터로 쓰면 일부러 그 데이터를 오염시키겠다는 발상이다. connector-text summarization 같은 보호 장치도 같이 언급된다.
다만 이 부분은 deep-research-report.md 기준으로도 공식 문서보다는 유출 코드 분석 의존도가 높은 대목이고, 미러 저장소에 classifier 관련 .txt 프롬프트 파일이 빠져 있다는 이슈도 있어 세부 동작을 너무 단정적으로 쓰면 위험하다.
그래서 이건 “실제로 그런 방향의 방어 설계 흔적이 보인다” 정도로는 흥미롭지만, 세부 구현까지 확정 팩트처럼 밀어붙이기보다는 높은 개연성의 분석 포인트 정도로 두는 편이 안전하다.
9. KAIROS, Bridge류가 재밌는 이유는 “완전한 공상”이 아니라는 점이다
네가 예시로 든 KAIROS, Bridge류가 재밌는 이유는 “완전한 공상”이 아니라는 점이다. import 흔적만 봐도 KAIROS, KAIROS_BRIEF, bridgeEnabled, trustedDevice, UserGitHubWebhookMessage 같은 조각들이 보인다. 그런데 동시에 Anthropic은 이미 Remote Control, Channels, Scheduled Tasks, Agent SDK를 공식 문서로 공개하고 있다. 즉 “브라우저에서 로컬 Claude Code를 조종한다”, “외부 이벤트를 세션에 밀어 넣는다”, “주기적으로 다시 돌린다”는 방향은 유출로 처음 상상된 게 아니라, 이미 제품 로드맵 위에 올라와 있던 셈이다.
다만 여기서 deep-research-report.md는 구분을 더 엄격하게 한다.
- Bridge는 비교적 강하게 확인된다.
- Coordinator는 조건부 import 흔적까지는 확인되지만 상세 작동은 부분 확인이다.
- Kairos는 assistant mode 관련 흔적은 있으나, “자율 GitHub 감시 에이전트” 같은 구체 정의는 아직 미검증이다.
즉 이름 조각이 보인다고 해서 곧바로 완성된 기능 정의까지 확정하는 건 과하다. 하지만 반대로 말하면, 최소한 그런 방향의 실험/구성요소가 실제 코드 안에 존재했다는 건 충분히 흥미로운 사실이다.
10. Bridge / remote control은 가장 현실적이면서도 가장 무서운 축이다
특히 remote control/bridge 계열은 자극적으로 말하면 무섭고, 차분하게 보면 이미 공개된 기능이다. 공식 문서만 봐도 브라우저나 모바일에서 내 로컬 Claude Code 세션에 붙고, 로컬 파일시스템·MCP 서버·도구를 그대로 쓰게 만드는 구조가 설명돼 있다. 세션은 로컬에서 계속 돌고, 웹이나 앱은 그 세션의 창 역할만 한다. “웹에서 내 컴퓨터 Claude Code를 원격 조종한다”는 말이 아주 틀린 건 아니다.
deep-research-report.md는 이걸 더 구체적으로 적고 있다. /remote-control 커맨드가 존재하고, alias rc가 있으며, BRIDGE_MODE 기능 플래그로 숨김 처리될 수 있다. 연결 과정에서는 세션 URL 표시, QR 코드 토글, Ingress WebSocket을 통한 양방향 메시징이 코드 주석과 구현에서 확인된다고 정리돼 있다. 또 조직 정책 차원에서 allow_remote_control로 원격 제어를 차단할 수 있는 게이트도 존재한다고 한다.
즉 이건 단순한 상상이 아니라,
- 세션 URL
- QR 연결
- 웹소켓 ingress
- 조직 정책 게이트
까지 포함한 꽤 구체적인 원격 제어 아키텍처 흔적이다.
그래서 이 기능은 제품적으로는 엄청 편리하지만, 보안 측면에서는 질문이 바로 따라붙는다. 세션 URL은 어떻게 보호되는가, 토큰은 어떻게 발급/회수되는가, 중간자 공격이나 세션 탈취에 얼마나 강한가, 원격 세션이 로컬 파일시스템과 MCP 도구를 건드릴 수 있다면 감사/승인은 어떻게 남는가. 편의성과 공격 표면이 동시에 커지는 구조라는 점에서 가장 날카로운 기능 중 하나다.
11. 더 웃긴 건 네이티브 레이어였다
유출 분석에는 cch=00000 placeholder를 JS 밖의 Bun/Zig HTTP 스택에서 실제 해시로 바꿔, 서버가 “이 요청이 진짜 Claude Code 바이너리에서 온 건지” 확인하는 구조가 있었다는 설명이 나온다. 약간 DRM 같다. 이쯤 되면 AI 회사라기보다 그냥 빡센 상용 클라이언트 소프트웨어 회사다.
이 포인트가 웃기면서도 중요한 이유는, 많은 사람들이 AI 제품을 “웹앱 + API” 정도로 생각하지만 실제 상용 에이전트 도구는 그렇지 않다는 걸 보여주기 때문이다. 네이티브 런타임, 바이너리 검증, 세션 인증, 정책 게이팅 같은 건 전통적인 상용 클라이언트 소프트웨어가 해오던 일에 더 가깝다.
즉 겉으로는 자연어 인터페이스지만, 안쪽으로 들어가면 보안 제품 + 상용 데스크톱 클라이언트 + 개발 툴링 플랫폼 같은 성격이 동시에 섞여 있는 셈이다.
12. 운영 메모도 너무 현실적이었다
같은 분석에 따르면 auto-compaction 실패 루프 때문에 하루 약 25만 API 호출이 낭비된다는 주석이 있었고, 해결책은 실패 3번 연속이면 그 세션에서 compaction을 꺼버리는 서킷브레이커였다. 최상위 AI 제품도 결국 이런 식으로 산다.
이게 왜 재밌냐면, 바깥에서 보면 AI 회사는 늘 거대한 모델과 미래적인 UX로만 보이지만, 실제 운영은 결국
- 실패 루프
- 낭비되는 API 호출
- 임계치 넘으면 기능 꺼버리는 서킷브레이커
- 가용성과 비용 사이의 절충
같은 너무 평범한 소프트웨어 엔지니어링 문제 위에서 돌아가기 때문이다.
그래서 오히려 더 현실감이 있다. 미래는 늘 이렇게 온다. 거대한 이상을 말하면서도, 동시에 어딘가에서는 실패 카운터를 세고 있다.
13. Bash 보안도 생각보다 편집증적이다
분석에 따르면 모든 bash 명령은 23개 수준의 보안 검사와 Zsh 우회 대응을 거친다. =curl 같은 zsh equals expansion, zero-width space, IFS/null-byte 주입 같은 우회까지 따로 막고 있었다. 겉으론 그냥 “터미널 실행”처럼 보여도, 안쪽은 거의 보안 제품 느낌이다.
이건 에이전트형 코딩 도구의 본질을 잘 보여준다. 사용자가 실제로 무서워하는 건 모델이 헛소리하는 것보다도, 파일 수정과 셸 실행이 결합됐을 때 터질 수 있는 사고다. 그러니 제품이 성숙해질수록 중요한 건 단순한 모델 지능이 아니라,
- 무엇을 실행하게 할지
- 어떤 문자열을 위험하다고 볼지
- 셸 특유의 우회를 어디까지 막을지
- fail-open으로 갈지 fail-closed로 갈지
같은 보안 설계다.
이 지점에 오면 Claude Code는 단순한 채팅형 AI가 아니라 권한 있는 자동화 런타임에 더 가까워진다.
14. 그리고 제일 만우절다운 결말도 진짜였다
그리고 제일 만우절다운 결말도 진짜였다. /buddy는 유출 밈이 아니라 Anthropic 공식 changelog에 실제로 올라와 있다. 4월 1일 기능으로 “네가 코딩하는 걸 지켜보는 작은 creature”를 넣어놨다. 결국 Claude Code엔 정말로 다마고치가 들어간 셈이다.
이건 그냥 농담처럼 보이지만, 제품적으로 보면 꽤 영리한 레이어이기도 하다. 에이전트형 코딩 툴은 길고 건조한 세션을 만들기 쉽고, 사용자는 종종 “지금 이 도구가 살아 있는지”, “내 작업을 따라오고 있는지” 같은 감각을 원한다. /buddy 같은 요소는 그걸 가볍게 해결한다.
그러니까 만우절 같지만, 사실은 꽤 진지한 UX다.
15. 딥 리서치 보고서가 보여준 더 큰 그림
데스크탑의 deep-research-report.md를 보면, 이번 유출을 해석하는 더 보수적이고도 중요한 기준이 하나 반복해서 나온다. 바로 “파일이 존재한다”와 “실제 프로덕션에서 켜져 있었다”를 분리해서 봐야 한다는 점이다.
이건 정말 중요하다. 유출물 기반으로 재구성된 코드에서는,
- 어떤 기능이 실제 코드에 문자열/모듈 형태로 존재할 수 있고
- 하지만 기능 플래그(
feature('...'))로 감춰져 있을 수 있으며 - 번들러의 dead code elimination 때문에 특정 빌드에서는 통째로 빠졌을 수도 있다.
그래서 유출 코드를 볼 때는 늘 세 층을 나눠야 한다.
- 확인 가능한 사실: 실제 코드, 상수, 분기, 주석, import 흔적
- 합리적 추론: 이름과 구조를 바탕으로 한 설계 추정
- 미해결 질문: 프로덕션에서 실제로 켜졌는지, 누구에게 노출됐는지, 어떤 플랜에서 활성화됐는지
이 구분이 있어야 과장도 줄고, 동시에 진짜 흥미로운 포인트도 더 잘 보인다.
16. 결국 이번 유출에서 진짜 흥미로웠던 건 “마법이 아니라 소프트웨어”라는 점이다
이번 유출이 흥미로웠던 이유는 단순히 “소스가 샜다”가 아니었다. 오히려 더 재밌었던 건, 우리가 막연히 미래 기술처럼 상상하던 AI 코딩 에이전트가 실제로는 어떤 식으로 짜이고, 보호되고, 분리되고, 운영되는지가 꽤 구체적으로 드러났다는 점이다.
감정 감지, 내부/외부 빌드 분리, 멀티에이전트 오케스트레이션, 이중 안전장치, anti-distillation, remote control, 네이티브 검증, 서킷브레이커, 편집증적인 shell 보안까지. 이건 마법이라기보다 정교하게 누더기 붙인 현실의 소프트웨어에 더 가깝다.
그리고 그게 오히려 더 흥미롭다. 미래는 생각보다 번쩍이는 기술 한 방으로 오지 않는다. 이런 자잘하고 집요한 설계들의 합으로 온다.
Claude Code 유출이 보여준 건 “Anthropic이 비밀 병기를 감춰두고 있었다”는 것만이 아니다. 더 중요한 건, AI 코딩 에이전트라는 제품 범주 자체가 이미 굉장히 전통적인 소프트웨어 공학의 문제들 위에서 작동하고 있었다는 사실이다.
권한 관리, 로깅, 원격 제어, 정책 게이팅, 자동화 안전장치, 실험 플래그, 운영 비용, 내부 빌드 분기, 표기 규칙, 책임 분리. 이 모든 게 들어와야 비로소 “에이전트”가 제품이 된다.
그래서 이번 유출은 단순한 해프닝이 아니라, AI 제품이 어디쯤 와 있는지를 보여준 드문 창이었다. 겉으론 미래였지만, 속은 놀랍도록 현실적이었다.
