.npmignore 파일에서 한 줄이 빠졌다.

그 한 줄 때문에 59.8MB짜리 소스맵 파일이 npm에 올라갔고, 그 안에는 1,906개의 TypeScript 파일, 512,000줄의 원본 코드가 고스란히 담겨 있었다. Anthropic이 수년간 쌓아올린 AI 코딩 에이전트의 설계도가, 빌드 도구의 기본 설정 하나 때문에 세상에 나온 것이다.

2026년 3월 31일, AI 업계 최대의 “비자발적 오픈소스” 사건이 벌어졌다.

하지만 이 코드를 실제로 열어보면, 진짜 놀라운 건 유출 자체가 아니다. 그 안에 담긴 설계 철학이다. Claude가 똑똑한 게 아니라, Claude를 감싸는 하네스(Harness)가 똑똑한 것이다.

TL;DR
- 2026.3.31 — Claude Code v2.1.88 npm 패키지에 소스맵 포함 배포
- 512,000줄 TypeScript 전체 복원 가능
- KAIROS(상시 데몬), Dream System(자기치유 메모리), 멀티에이전트 오케스트레이션 등 미공개 기능 발견
- 핵심 교훈: 앞으로 대세는 LLM 자체가 아니라 LLM을 감싸는 하네스 엔지니어링

이 글은 뉴스 기사가 아니다. 유출된 코드를 직접 따라가며 분석한 개발자의 보고서다. 유출 경위부터 내부 아키텍처, 숨겨진 기능, 그리고 “하네스가 왜 모델보다 중요한가”까지 — 순서대로 풀어보겠다.


사건 개요 — .npmignore 한 줄이 만든 역대급 유출

2026년 3월 31일, 무슨 일이 벌어졌나

3월 31일 새벽, 보안 연구자 Chaofan Shou(@shoucccc)가 뭔가 이상한 걸 발견했다. Anthropic의 공식 npm 패키지 @anthropic-ai/claude-code v2.1.88에 소스맵 파일이 포함되어 있었다. 이 59.8MB짜리 .map 파일 하나가, Anthropic의 Cloudflare R2 스토리지에 있는 원본 소스 아카이브를 직접 가리키고 있었다.

그의 X(트위터) 포스트는 순식간에 2,880만 뷰를 기록했다.

타임라인을 정리하면 이렇다:

시각 (UTC) 사건
3/31 00:21 v2.1.88 npm 배포 (소스맵 포함)
3/31 수시간 내 Chaofan Shou가 X에 공개
3/31 03:29 Anthropic이 패키지 철회
4/1 GitHub에서 8,100개 복제본에 DMCA 요청 (이후 96개로 축소)

약 3시간의 노출. 하지만 인터넷에서 3시간은 영원과 같다.

소스맵이 뭔데 이런 일이 생겼나

개발을 안 해본 분들을 위해 간단히 설명하면 이렇다.

개발자가 작성한 원본 코드(TypeScript)는 배포 전에 압축하고 난독화한다. 읽을 수 없게 만드는 것이다. 그런데 개발 중에 디버깅을 하려면 “압축된 코드의 이 줄이 원본 코드의 어디에 해당하는지” 알아야 한다. 그 매핑 정보를 담은 파일이 소스맵(.map)이다.

문제는 Claude Code가 사용하는 Bun 런타임의 번들러가 기본적으로 소스맵을 생성한다는 것이다. 릴리스 팀이 .npmignore에서 *.map 파일을 제외하지 않았고, 소스맵이 npm 패키지에 그대로 실려 나갔다. 그러니까 이건 해킹이 아니다. 빌드 도구의 기본 설정을 맹신한 인적 오류다.

# .npmignore에 이 한 줄만 있었어도...
*.map

확산 — GitHub 역사상 가장 빠른 저장소

소스가 공개된 후 벌어진 일은 가히 전례가 없었다.

수시간 만에 GitHub에 수십 개의 미러 저장소가 생겼다. 그중 Claw Code는 유출된 코드를 기반으로 한 오픈소스 프레임워크로, 2시간 만에 50,000 스타를 찍으며 GitHub 역사상 가장 빠른 성장 속도를 기록했다. 이후 100,000 스타를 돌파했다.

claurst라는 프로젝트는 더 흥미롭다. 유출된 소스를 직접 참조하지 않고, AI 에이전트가 행동 명세만 추출한 뒤 별도의 AI가 Rust로 클린룸 재구현했다. 1984년 Phoenix Technologies의 IBM BIOS 클린룸 엔지니어링 선례를 현대적으로 재현한 셈이다.

Anthropic의 대응 — 과잉 대응 논란까지

Anthropic은 초기에 GitHub에서 약 8,100개의 저장소에 대해 DMCA 테이크다운을 요청했다. 문제는 이 과정에서 관련 없는 저장소까지 삭제됐다는 것이다. TechCrunch가 이를 보도했고, Anthropic은 “의도보다 넓은 범위를 포함했다”며 96개로 축소했다.

공식 입장은 이랬다:

“민감한 고객 데이터나 인증 정보는 노출되지 않았습니다. 보안 침해가 아닌 릴리스 패키징 과정의 인적 오류입니다.”

Paul Smith(Anthropic 최고상업책임자)는 “매우 빠른 릴리스 사이클의 일부”라고 설명했다. 솔직한 해명이었지만, 그 사이 인터넷은 이미 코드를 구석구석 뜯어보고 있었다.

한 가지 더 우려스러운 점: 유출 직후 공격자들이 내부 npm 패키지명을 도용한 타이포스쿼팅(typosquatting) 공격을 시도한 것으로 보고됐다. 3월 31일 00:21~03:29 UTC 사이에 설치한 사용자는 주의가 필요하다.


유출된 코드 속으로 — 클로드 코드의 내부 아키텍처

여기서부터가 진짜다. 뉴스 기사들은 “51만줄이 유출됐다”까지만 말한다. 하지만 그 51만줄 안에 뭐가 있는지를 말하는 글은 거의 없다. 코드를 따라가 보자.

에이전트 루프 — 놀라울 정도로 단순하다

Claude Code의 핵심 루프를 한 문장으로 요약하면 이렇다:

“맥락을 수집하고, 행동하고, 결과를 검증한다.”

User Input → messages[] → LLM → Response → Tool Decision → Execute → Verify → Loop

이게 전부다. 정말로.

모델이 언제 도구를 호출할지, 언제 멈출지를 결정한다. 코드는 모델이 요청한 것만 실행한다. 이 구조가 단순하다고 느껴진다면, 정확히 맞다. 에이전트 루프 자체는 단순해야 한다. 복잡성은 루프 안이 아니라, 루프를 감싸는 하네스에 있다.

이 “감싸는 것”이 뭔지가 바로 다음에 나온다.

QueryEngine — 46,000줄의 심장

QueryEngine.ts는 Claude Code에서 가장 큰 단일 파일이다. 46,000줄. 단순한 API 호출 래퍼가 아니라, 완전한 실행 엔진이다.

이 엔진이 하는 일을 순서대로 나열하면:

  1. 메시지 정규화 및 검증
  2. 시스템 프롬프트 빌딩 (캐시 인식 경계 포함)
  3. API 요청 (베타 기능 포함)
  4. 스트림 이벤트 처리
  5. 도구 호출 + 권한 검사
  6. 도구 결과 주입 → 루프 복귀
  7. 토큰 및 비용 추적
  8. 세션 히스토리 기록

여기서 가장 주목할 부분은 캐시 인식 시스템 프롬프트 설계다. 시스템 프롬프트를 “캐시 가능한 정적 부분”과 “매번 바뀌는 동적 컨텍스트”로 분리한다. 도구 정의나 기본 지침 같은 건 캐시하고, 현재 날짜나 작업 컨텍스트 같은 건 매번 새로 넣는 것이다. 이 단순한 분리만으로 API 호출 비용이 극적으로 줄어든다.

자체 에이전트를 만들고 있다면, 이 패턴은 오늘 당장 적용할 수 있다.

43개 도구의 플러그인 아키텍처

Claude Code에는 43개의 도구(Tool)가 있다. 파일 읽기, 코드 편집, 웹 검색, 서브 에이전트 생성까지 — 각각이 독립적인 모듈이다.

인상적인 건 모든 도구가 동일한 인터페이스를 구현한다는 것이다:

도구 = 입력 스키마(Zod 검증) + 권한 모델 + 실행 로직 + 프레젠테이션 레이어
카테고리 도구 예시
코어 BashTool, FileReadTool, FileWriteTool, FileEditTool, GlobTool, GrepTool
WebFetchTool, WebSearchTool
에이전트 AgentTool, SkillTool, TeamCreateTool, SendMessageTool
태스크 TaskCreateTool, TaskUpdateTool, TaskListTool
실험적 SleepTool, ScheduleCronTool, REPLTool

왜 이렇게 설계했을까? 모든 도구가 같은 계약을 따르면, 새로운 도구를 추가하는 비용이 거의 0에 수렴하기 때문이다. 인터페이스만 맞추면 된다. 그리고 순환 의존성을 방지하기 위해 지연 로딩을 사용한다:

const getTeamCreateTool = () => require(...)

43개 도구를 관리하면서도 코드가 깔끔하게 유지되는 비결이 여기에 있다.

시스템 프롬프트 — 가장 중요한 “코드”

코드를 따라가면서 가장 인상 깊었던 부분이다. Claude Code에서 시스템 프롬프트는 그냥 “모델에 넣는 지시문”이 아니다. 가장 중요한 코드다.

프롬프트가 모듈별로 분리되어 있고, 상황에 따라 동적으로 조합된다. 도구 정의, 행동 규칙, 안전 제약, 출력 포맷이 모두 프롬프트로 제어된다. 이건 “프롬프트 엔지니어링”이 아니다. “프롬프트 아키텍처”다.

구체적으로 보면:
- 도구 제약, 리스크 제어, 출력 명세가 한 프롬프트에 모듈식으로 구성된다
- 캐시 인식 경계를 활용해 정적/동적 부분을 분리한다
- 44개의 피처 플래그가 어떤 프롬프트 모듈을 포함할지 결정한다

“AI를 잘 쓰려면 프롬프트를 잘 써야 한다”는 말은 많이 들었을 것이다. Claude Code를 보면 그 말의 진짜 의미를 알게 된다. 프롬프트를 “잘 쓰는 것”이 아니라, 프롬프트를 설계하는 것이다.

메모리 시스템 — MEMORY.md와 자기치유 메모리

Claude Code의 메모리 시스템은 전통적인 RAG(Retrieval-Augmented Generation)와 완전히 다른 접근을 한다.

핵심은 MEMORY.md라는 파일이다. 이 파일은 항상 컨텍스트에 로드되는데, 여기에 모든 지식을 담지 않는다. 대신 줄당 150자 이하의 포인터만 담는다. 실제 지식은 별도의 토픽 파일에 분산 저장되어 있고, 필요할 때만 가져온다.

MEMORY.md (항상 로드, 포인터만)
  ├── user_role.md (필요 시 로드)
  ├── feedback_testing.md (필요 시 로드)
  ├── project_auth_rewrite.md (필요 시 로드)
  └── reference_linear.md (필요 시 로드)

왜 이렇게 했을까? 컨텍스트 윈도우는 비싸기 때문이다. 모든 걸 벡터 DB에 넣고 매번 검색하는 것보다, 가벼운 인덱스를 항상 들고 다니면서 필요한 것만 꺼내오는 게 훨씬 효율적이다.

더 인상적인 건 메모리의 4단계 통합 프로세스다:

  1. Orient — 현재 상태 파악
  2. Gather — 관련 메모리 수집
  3. Consolidate — 모순 제거, 병합
  4. Prune — 오래되거나 불필요한 메모리 정리

메모리를 “저장”하는 게 아니라 “통합”한다. 이 차이가 장기적으로 에이전트의 품질을 결정한다.

멀티 에이전트 오케스트레이션 — AI의 마이크로서비스

Claude Code의 Coordinator Mode는 하나의 Claude가 여러 Claude를 부리는 구조다.

코디네이터가 워커 에이전트를 생성하고, 각 워커는 격리된 컨텍스트에서 독립적으로 실행된다. 워크트리(worktree) 기반으로 병렬 코드 작업이 가능하고, 에이전트 간 메시지 라우팅과 공유 스크래치패드를 통해 협업한다.

재밌는 점은 워커의 권한이 제한된다는 것이다. 워커는 다른 워커를 만들거나(TeamCreate), 삭제하거나(TeamDelete), 직접 메시지를 보내는 것(SendMessage)이 불가능하다. 코디네이터만 이 권한을 가진다. 마이크로서비스 아키텍처에서 서비스 간 직접 통신을 제한하고 API 게이트웨이를 두는 것과 같은 패턴이다.

그리고 터미널 UI가 React + Ink로 만들어져 있다는 것도 눈에 띈다. 게임 엔진에서 사용하는 렌더링 기법을 터미널 UI에 적용한 것이다. 여러 에이전트가 동시에 작업하는 상태를 실시간으로 보여주려면, 이 정도의 UI 프레임워크가 필요했을 것이다.


숨겨진 미래 — KAIROS와 Dream System

코드를 분석하면서 가장 흥미로웠던 부분은 아직 출시되지 않은 기능들이다. 피처 플래그 뒤에 숨어 있지만, 완전히 구현된 상태다.

KAIROS — 항상 켜져 있는 백그라운드 데몬

KAIROS는 소스 코드에서 150회 이상 참조되는 미출시 기능이다. 이름은 고대 그리스어로 “적절한 순간”을 뜻한다. chronos(순차적 시간)와 대비되는 개념으로, 스케줄이 아닌 맥락에 따라 개입 여부를 판단하는 자율 에이전트다.

작동 방식이 독특하다:

  • 주기적으로 <tick> 프롬프트를 수신한다
  • 매 tick마다 행동할지 조용히 있을지를 스스로 결정한다
  • 노트북을 닫아도 계속 실행된다
  • GitHub 웹훅을 구독하여 저장소 이벤트를 모니터링한다
  • append-only 일일 관찰 로그를 기록한다

가장 인상적인 설계 제약은 15초 블로킹 예산이다. 셸 커맨드가 15초 이상 실행되면 자동으로 백그라운드 태스크로 전환한다. 사용자의 작업 흐름을 절대 방해하지 않겠다는 설계 의도가 명확하다.

KAIROS는 Claude Code를 “세션 기반 도구”에서 “항상 켜져 있는 개발 환경”으로 전환시키려는 Anthropic의 비전을 보여준다. 코드의 내부 주석에 따르면, 2026년 4~5월 출시가 계획되어 있었다.

autoDream — 유저가 쉬는 동안 기억을 정리하는 AI

인간은 잠을 자는 동안 하루의 기억을 정리하고 통합한다. Claude Code의 autoDream은 이 과정을 모방한 기능이다.

사용자가 자리를 비운 유휴 시간에, forked subagent가 메모리 통합 작업을 수행한다:

  • 관찰 로그를 병합한다
  • 논리적 모순을 제거한다
  • 모호한 인사이트를 확정 사실로 변환한다
  • 결과를 토픽 파일과 MEMORY.md로 증류한다

여기서 핵심적인 안전 장치가 두 가지 있다. 첫째, forked subagent에서 실행되기 때문에 메인 에이전트의 사고 흐름(train of thought)을 오염시키지 않는다. 둘째, read-only bash 접근만 허용된다. 메모리를 정리하는 과정에서 실수로 코드를 수정하는 일은 없다.

“잠자는 동안 정리되는 기억” — 이 비유가 autoDream의 설계 의도를 정확히 설명한다.

Buddy System — 개발자 문화의 이스터에그

코드에서 발견된 가장 의외의 기능은 Buddy System이다. 18종의 가상 생물을 키우는 시스템이다.

  • 희귀도 등급: Common부터 Legendary까지
  • 1% 확률의 샤이니(Shiny) 변형
  • RPG 스탯: DEBUGGING, SNARK 등
  • Mulberry32 PRNG로 사용자 ID 기반 결정적 생성

피처 플래그(BUDDY)로 막혀 있지만 완전히 구현된 상태다. Ogler라는 드래곤이 사용자의 입력 박스 옆에 앉아서 가끔 말풍선으로 코멘트를 한다.

프로덕션 AI 도구에 타마고치를 집어넣은 것이다. Anthropic의 제품 문화를 엿볼 수 있는 디테일이다.


진짜 교훈 — 하네스가 모델보다 중요하다

사건 보도와 아키텍처 분석을 다 했으니, 이제 이 글의 핵심 메시지로 가자.

하네스 엔지니어링이란 무엇인가

AI 에이전트는 간단한 등식으로 표현된다:

Agent = Model + Harness

Model은 LLM이다. Claude, GPT, Gemini 같은 것.

Harness는 그 나머지 전부다. LLM을 감싸는 모든 코드, 설정, 실행 로직. 도구 오케스트레이션, 컨텍스트 관리, 권한 제어, 메모리 시스템, 비용 추적, 오류 복구, 관찰성(observability)…

Martin Fowler의 정의를 빌리면, 하네스는 “에이전트 실행 전체를 제어하는 런타임 오케스트레이션 레이어”다.

Claude Code의 512,000줄 중 LLM API를 직접 호출하는 코드는 극히 일부다. 나머지가 전부 하네스다.

Before & After: LLM 래퍼 vs 프로덕션 하네스

LLM API 래퍼 프로덕션 에이전트 하네스
역할 API 호출 추상화 에이전트 실행 전체를 제어하는 운영체제
범위 요청/응답 처리 도구, 권한, 메모리, 오류 복구, 비용 제어, 관찰성
상태 무상태 or 단순 히스토리 영구 세션, 메모리 계층, 태스크 그래프
안전성 없음 or 기본적 다계층 권한 파이프라인
확장성 단일 모델 호출 멀티에이전트 오케스트레이션

대부분의 AI 프로젝트가 왼쪽 열에서 시작한다. Claude Code는 오른쪽 열이 얼마나 깊을 수 있는지를 보여준다.

“2025년은 에이전트, 2026년은 하네스”

2025년은 AI 에이전트가 “작동한다”를 증명한 해였다. 2026년은 에이전트가 “안정적으로 작동한다”를 만드는 해다.

왜 이런 전환이 일어났을까? 모델이 기존 멀티에이전트 프레임워크가 제공하던 것의 ~80%를 흡수했기 때문이다. 에이전트 정의, 메시지 라우팅, 태스크 라이프사이클 같은 것들을 모델 자체가 처리하게 됐다.

남은 20% — 영속성(persistence), 결정적 재생(deterministic replay), 비용 제어, 관찰성, 오류 복구 — 가 바로 하네스의 영역이다. 그리고 이 20%가 프로덕션 환경에서의 성패를 결정한다.

Anthropic도 이걸 알고 있다. 그들 스스로 “진짜 해자(moat)는 Claude 모델이지, CLI 도구가 아니다”라고 말했다. 하지만 역설적으로, 개발자 경험을 결정하는 건 CLI 도구(하네스)다.

Claw Code와 claurst 같은 클린룸 재구현 프로젝트가 며칠 만에 등장한 것이 이를 증명한다. 아키텍처(하네스)는 재현 가능하다. 모델은 재현할 수 없다. 하지만 사용자가 매일 체감하는 건 아키텍처의 품질이다.

개발자가 지금 당장 배울 것 5가지

유출된 코드에서 추출한, 자체 에이전트를 만들 때 적용할 수 있는 설계 패턴들이다.

1. 시스템 프롬프트 = 가장 중요한 코드

프롬프트를 하드코딩된 문자열로 취급하지 마라. 모듈별로 분리하고, 캐시 경계를 설정하고, 상황에 따라 동적으로 조합하라. Claude Code의 시스템 프롬프트는 도구 정의, 행동 규칙, 안전 제약, 출력 포맷을 모두 포함하는 아키텍처다.

2. 도구(Tool) 설계가 에이전트 품질을 결정한다

모든 도구에 동일한 인터페이스를 적용하라: 입력 스키마(Zod 같은 런타임 검증), 권한 모델, 실행 로직, 프레젠테이션 레이어. 이 계약이 일관되면 새 도구 추가 비용이 0에 수렴한다. Claude Code가 43개 도구를 깔끔하게 관리하는 비결이다.

3. 메모리는 “저장”이 아니라 “통합”이다

모든 걸 벡터 DB에 넣는 건 쉽지만 비효율적이다. 가벼운 포인터 인덱스(MEMORY.md)를 항상 들고 다니면서, 필요한 지식만 온디맨드로 가져오는 패턴을 고려하라. orient → gather → consolidate → prune의 4단계 통합 프로세스는 메모리 품질을 유지하는 핵심이다.

4. 에이전트 루프는 단순하게, 복잡성은 하네스에

핵심 루프를 복잡하게 만들지 마라. “맥락 수집 → 행동 → 검증”이면 충분하다. 권한 검사, 비용 추적, 오류 복구, 캐시 최적화 같은 복잡성은 루프를 감싸는 하네스 레이어에서 처리하라.

5. .npmignore를 확인하라

이번 사건의 가장 기본적인 교훈이다. 빌드 도구의 기본 설정을 맹신하지 마라. package.jsonfiles 필드를 명시적으로 설정하거나, .npmignore*.map을 추가하라. CI/CD 파이프라인에서 패키지 내용물을 자동 검증하는 단계를 넣어라.

// package.json — 화이트리스트 방식이 더 안전하다
{
  "files": ["dist/", "README.md", "LICENSE"]
}

프로덕션 하네스의 10가지 핵심 패턴

정리하자면, Claude Code가 보여준 프로덕션급 하네스의 패턴은 이렇다:

# 패턴 핵심
1 균일 도구 계약 43개 도구 모두 동일한 인터페이스
2 다계층 권한 파이프라인 일반 규칙 → 도구별 검사 → 자동 분류기 → 사용자 승인
3 자기치유 메모리 포인터 인덱스 + 토픽 파일 + 4단계 통합
4 캐시 인식 프롬프트 정적/동적 분리로 API 비용 최적화
5 스마트 컨텍스트 압축 토큰 예산 초과 시 지능적 히스토리 압축
6 지수 백오프 재시도 API 실패에 대한 견고한 복구
7 코디네이터-워커 패턴 멀티에이전트 작업 분배 및 결과 수집
8 피처 플래그 DCE 빌드 시점에 미사용 코드 완전 제거
9 실시간 비용 추적 토큰 및 달러 비용 모니터링 (11K줄 전용 모듈)
10 관찰성 OpenTelemetry + gRPC 기반 텔레메트리

이 10가지가 Claude Code의 하네스를 구성한다. 그리고 이것이 “AI 코딩 에이전트”와 “프로덕션 AI 코딩 에이전트”의 차이다.


마무리 — AI 에이전트 시대, 무엇을 만들 것인가

Claw Code가 며칠 만에 10만 스타를 찍은 것, claurst가 Rust로 클린룸 재구현에 성공한 것 — 이것이 의미하는 바는 명확하다. 하네스는 재현 가능하다.

Anthropic이 수년간 만든 아키텍처를 오픈소스 커뮤니티가 며칠 만에 재현했다. AI 에이전트의 경쟁 우위는 아키텍처 자체에 있지 않다. 모델과 데이터에 있다. 하지만 개발자 경험을 만드는 건, 그리고 에이전트가 프로덕션에서 안정적으로 동작하게 만드는 건, 하네스다.

“하네스 엔지니어링”이라는 새로운 역할이 등장하고 있다. 모델을 만드는 건 Anthropic, OpenAI, Google의 영역이다. 하지만 하네스를 만드는 건 모든 개발자의 영역이다.

Claude Code 소스 유출은 의도치 않게 이 사실을 512,000줄의 코드로 증명했다. LLM은 도구일 뿐이다. 그 도구를 어떻게 감싸느냐가, 앞으로의 대세다.

당신은 모델을 기다리는 사람인가, 하네스를 만드는 사람인가?


FAQ — 자주 묻는 질문

클로드 코드 소스코드 유출, 보안 위험이 있나요?

Anthropic은 “민감한 고객 데이터나 인증 정보는 노출되지 않았다”고 공식 확인했다. 유출된 것은 클라이언트 사이드 CLI 도구의 소스코드이며, 서버 사이드 코드나 모델 가중치는 포함되지 않았다. 다만 내부 API 엔드포인트 구조와 피처 플래그가 노출되어, Anthropic의 제품 로드맵이 간접적으로 공개된 셈이다.

유출된 코드를 사용해도 되나요?

아니다. 유출된 소스코드는 Anthropic의 지적 재산이며, Anthropic은 DMCA를 통해 적극적으로 저작권을 행사하고 있다. 직접 복사하거나 포크하는 것은 법적 위험이 있다. 다만 claurst처럼 “행동 명세만 참고한 클린룸 재구현”은 법적 선례(Phoenix Technologies v. IBM, 1984)에 따라 허용될 가능성이 있다.

하네스 엔지니어링이란 무엇인가요?

LLM을 감싸는 모든 코드, 설정, 실행 로직을 설계하는 분야다. 도구 오케스트레이션, 컨텍스트 관리, 권한 제어, 메모리 시스템, 비용 추적, 오류 복구 등이 포함된다. Martin Fowler가 정의한 “에이전트 실행 전체를 제어하는 런타임 오케스트레이션 레이어”를 설계하고 구현하는 것이 하네스 엔지니어링이다.

Claude Code의 KAIROS 기능은 언제 출시되나요?

소스 코드 내부 주석에 따르면 2026년 4월 초 티저, 5월 정식 출시가 계획되어 있었다. 다만 유출 사건 이후 일정이 변경될 가능성이 있다. KAIROS는 현재 process.env.USER_TYPE === 'ant'(Anthropic 직원 전용) 피처 플래그 뒤에 숨어 있다.

AI 에이전트를 만들 때 하네스 설계를 어디서 배울 수 있나요?

Martin Fowler의 Harness Engineering 아티클이 좋은 출발점이다. 실무적으로는 이 유출 사건을 계기로 만들어진 learn-claude-code 같은 오픈소스 학습 자료도 참고할 만하다. 핵심은 도구 시스템, 권한 모델, 메모리 아키텍처, 비용 제어부터 설계하는 것이다.

.npmignore와 .gitignore의 차이는 무엇인가요?

.gitignore는 Git이 추적하지 않을 파일을 지정한다. .npmignore는 npm에 패키지를 배포할 때 제외할 파일을 지정한다. .npmignore가 없으면 npm은 .gitignore를 대신 사용하는데, 소스맵 파일이 Git에는 추적되지만 npm에는 올리지 말아야 하는 경우 .npmignore를 별도로 관리해야 한다. 더 안전한 방법은 package.jsonfiles 필드로 포함할 파일만 화이트리스트 방식으로 지정하는 것이다.