Molayo

© 2026 Molayo

Zenn헤드라인2026. 06. 02. 22:57

당신의 CLAUDE.md는 현재 어느 레벨인가요? ── 지시가 '먹힐 때'와 '먹히지 않을 때'를 가르는 L0–L7

요약

CLAUDE.md와 같은 지시 시스템이 에이전트의 수행 능력에 미치는 영향을 'Instruction systems capability ladder(L0-L7)' 프레임워크로 분석합니다. 지시가 컨텍스트 내에서 희석되는 소프트 채널의 한계를 설명하고, 더 정교한 harness 구축의 중요성을 강조합니다.

핵심 포인트

  • 에이전트의 성능은 모델 자체보다 harness(외골격)에 의해 결정됨
  • 지시 전달 경로는 소프트, 하드, 셀프 라이팅 채널로 구분됨
  • CLAUDE.md는 소프트 채널로 작동하여 부하 시 지시가 희석될 수 있음
  • L0-L7 사다리를 통해 지시 시스템의 정교함을 측정 가능

CLAUDE.md (또는 AGENTS.md)에 "테스트를 작성한 후 커밋해줘"라고 적어두었는데, 긴 태스크를 수행하는 도중에 슬그머니 무시당한── 그런 경험, 없으신가요? 짧은 태스크에서는 따르는데, 복잡해지면 따르지 않습니다. 변덕스럽게 보이는 이 동작에는 사실 제대로 된 이유가 있습니다.

cleverhoods 씨가 제시한 **"Instruction systems capability ladder"**라는 프레임워크가 이를 하나의 척도로 설명해 줍니다. 지시 시스템(=에이전트의 harness)을 L0부터 L7까지 8단계로 나열한 것입니다. 이를 이해하면 "우리 CLAUDE.md는 왜 가끔 말을 안 들을까"라는 모호한 고민이, "지금 우리는 L5 단계에 있으니 말을 안 듣는 것이 당연하다. L6로 올라가면 해결된다"라는 구체적인 설계 판단으로 바뀝니다.

참고로 미리 말씀드리자면, L0–L7은 공식 규격이 아니라 이 저자가 제창하는 하나의 모델입니다. 다만, 나중에 살펴보겠지만 "왜 먹히고/안 먹히는지"에 대한 설명력이 매우 높습니다. 순서대로 살펴보겠습니다.

우선: 에이전트의 한계는 이미 모델의 외부에 있다

지난 1년간 몇 번이고 반복되어 온 이야기부터 시작하겠습니다. 같은 모델이라도 Claude Code나 Codex 안에서 구동하면, 단순한 채팅 화면보다 명백히 더 똑똑하게 행동합니다. 왜 그럴까요?

정답은 '모델의 똑똑함'이 아니라, 모델을 둘러싼 외골격(exoskeleton) = harness에 있습니다. Sebastian Raschka는 "Components of a Coding Agent"에서 코딩 에이전트의 강점의 정체는 도구 사용(tool use)・컨텍스트 관리(context management)・기억(memory)・권한(permission)・실행 피드백(execution feedback)・장시간 세션 지속성을 책임지는 **발판(harness)**이지, 단일 next-token 생성 그 자체가 아니라고 정리했습니다. harness를 "제대로 실행함(execution) / 계속 실행함(state) / 안정적으로 실행함(governance)"의 세 층위로 파악하는 관점도 있지만, 용어는 달라도 가리키는 대상은 같습니다.

즉, 경쟁의 중심은 "어떤 모델을 선택할 것인가"에서 "어떤 harness를 구축할 것인가"로 옮겨갔습니다. L0–L7은 그 harness를 "어디까지 정교하게 만들었는가"를 측정하는 눈금입니다.

지시가 먹히느냐 아니냐는 "어느 채널을 통하는가"에 의해 결정된다

이 프레임워크의 가장 핵심적인 부분입니다. 저자는 지시가 전달되는 경로를 3가지 채널로 나눕니다.

  • 소프트 채널 (soft channel): 규칙이 모델의 컨텍스트 윈도우(context window) 안에서 주의력(attention)을 다투며 경쟁합니다. 부하가 높아지면 희석됩니다 (decay under load). 따라서 확률적으로만 작동합니다.
  • 하드 채널 (hard channel): 강제 기제가 컨텍스트 외부에서 결정론적으로 작동합니다. 긴 태스크에서도 희석되지 않습니다.
  • 셀프 라이팅 채널 (self-writing channel): 에이전트가 스스로 지시를 작성합니다. 사용자의 신호가 아니라, 태스크 완료를 트리거로 삼습니다.

CLAUDE.md의 규칙이 "먹힐 때도 있고 안 먹힐 때도 있는" 이유는 그것이 소프트 채널에 올라타 있기 때문입니다. 주의력 경쟁에 참여하고 있는 이상, 긴 문맥이나 높은 부하 상황에서는 패배합니다. 변덕을 부리는 것이 아니라, 구조상 그렇게 될 수밖에 없습니다.

L0–L7: harness 능력의 사다리 (Ladder)

3가지 채널을 8단계로 할당한 것이 바로 이 사다리입니다.

등급이름대략적인 내용채널
L0System모델 + 벤더 주입 기본 설정만 존재소프트
L1Primer단일 루트 지시 파일 (입구가 하나)소프트
L2Composite사용자 설정과 프로젝트 설정을 분리소프트
L3Scoped경로에 종속되어 조건부로 발화하는 규칙소프트
L4Delegated스킬 = 에이전트가 필요할 때 호출하는 절차소프트
L5Abstracted격리된 문맥을 가진 서브 에이전트소프트
L6Governed컨텍스트 외부의 hook / gate / deny를 통한 강제하드
L7Adaptive태스크 완료 후 에이전트가 지시를 직접 작성자기 기술 (self-describing)

많은 팀이 L1~L5 중 어딘가에 머물러 있습니다. CLAUDE.md

CLAUDE.md를 정돈하고, 규칙을 경로(path)별로 나누고, 기술(skill)을 분리하여 서브 에이전트(sub-agent)에게 넘기는 것──이 모든 것은 "좋은 일"이지만, L0~L5는 모두 동일한 물리 법칙 위에서 움직이고 있다. 저자의 표현을 빌리자면 "run on the same physics"이다. 즉, 아무리 다듬어도 결국 컨텍스트 내의 주의력(attention)을 뺏기기 위한 싸움이며, 확률적으로 실패할 수 있다.

두 개의 벽이야말로 이 프레임워크의 본질

래더(ladder)에는 단순히 한 단계가 아닌 두 개의 단층이 존재한다.

제1의 벽: L5 → L6 (확률 → 확정)

첫 번째 단층은 소프트 채널(soft channel)과 하드 채널(hard channel)의 경계이다. 저자의 예시가 그대로 적용된다. CLAUDE.md에 작성한 테스트 규칙은 "따를 때도 있고, 따르지 않을 때도 있다 (sometimes it follows, sometimes it doesn't)". 반면, 테스트가 실패했을 때 git push를 막는 PreToolUse 훅(hook)은, 모델이 무엇을 생각하든 상관없이 실행된다. 긴 작업 과정에서 흐려지는 일도 없다.

이 지점은 내가 이전에 썼던 ClickHouse 운영기(記)와 직결된다. 그 글의 핵심은 "빠르고 자동화된 '판단의 벽'이, 거짓말을 하는 에이전트를 신뢰할 수 있는 존재로 바꾼다"였다. 그 '벽'이야말로 이 프레임워크에서 말하는 L6 = 하드 채널 그 자체인 것이다. 부탁(소프트)이 아니라 집행(하드). 확률을 확정으로 바꾸는, 처음이자 가장 큰 단계이다.

제2의 벽: L6 → L7 (읽기 → 쓰기)

다음 단층은 "사람이 작성한 지시를 읽는 것"과 "에이전트가 지시를 작성하는 것"의 경계이다.

혼동하기 쉬운 것이 이른바 "메모리 기능"이다 (여기서는 L6.5라고 부른다). 사용자가 "이것 좀 기억해둬"라고 명시적으로 저장한다. 편리하지만, 작성한 것은 인간이며, 읽어올 때는 다시 소프트 채널로 돌아간다. 진정한 L7은, 에이전트 스스로가 "이것은 저장할 가치가 있는 궤적이다"라고, 권유받지 않아도 스스로 깨닫고 작성하는 단계까지 나아간다.

L7은 어떤 모습인가──Hermes Agent

저자가 "현재 출판물에서 볼 수 있는 가장 명확한 L7"로 꼽는 것이 Hermes Agent이다. 기사에 따르면 Hermes는 다음 4가지 조건에서 기술 추출(skill extraction)을 가동한다고 설명한다.

  • 5회 이상의 도구 호출(tool call)이 포함된
    성공한 태스크, 에러로부터의 복구, 사용자에 의한 수정, 새로운 워크플로우의 발견

포인트는 이 중 3가지는 "저장해야 할 순간이 일어났다는 것을 에이전트만이 알고 있다"는 점이다. 인간은 알아챌 수 없다. 따라서 에이전트 스스로가 작성할 수밖에 없다.

그리고 추출된 SKILL.md는 YAML 프론트매터(front matter) + "When to Use / Procedure / Pitfalls / Verification"라는 **정해진 형식(type)**에 맞춰진다. 여기서 내가 가장 좋아하는 문구가 등장한다.

Schema is the cheap version of supervision.
(스키마는 감독의 저렴한 대체물이다)

자유 기술 형식의 메모는 "에이전트가 작성하는 규율이 느슨해지는 속도와 마찬가지로 퇴화한다". 하지만 형식을 강제하면, 작성하는 시점에 규율이 작동한다. 구조 그 자체가 인간의 감시를 대신하여 품질을 보장한다. ──이것은 L6의 "훅이 확률을 확정으로 바꾼다"는 이야기의 셀프 라이팅(self-writing) 버전인 셈이다. 형식 = 집행.

개인적인 견해

이 프레임워크의 효용은 자신의 하네스(harness)를 진단할 수 있다는 점에 있다고 생각한다. 글을 다 읽었다면 한 번 시도해 보길 권한다.

  • 규칙을 CLAUDE.md에 적어두기만 함 → 대체로 L1~L2
  • 경로별로 구분하고 기술도 분리함 → L3~L4
  • 서브 에이전트에게 넘김 → L5
  • ……하지만, 훅(hook)으로 강제하고 있는 부분이 있는가? 없다면 아무리 다듬어도 천장은 L5이다. "효가 있다 없다"를 반복하는 문제는 고쳐지지 않는다.

그리고 중요한 것은, 모든 것을 L7까지 올릴 필요는 없다는 것이다. L0~L5로도 충분한 지시 사항은 산더미처럼 많다. 문제는, 확실히 작동하기를 원하는 제약 조건을 소프트 채널에 방치하고 있지는 않은가 하는 점이다. "테스트를 통과하지 못하면 push를 허용하지 않는다", "운영 디렉토리는 건드리지 못하게 한다"──이런 종류의 "절대로 어긋나서는 안 되는" 것들만 L6의 하드 채널로 끌어올려라. 그것이 가장 비용 효율적인 한 수이다.

한 가지 짚고 넘어가야 할 점도 있습니다. L0–L7은 저자 한 명이 제창한 모델이며, 업계 표준은 아닙니다. 레벨의 구분(특히 L4 스킬과 L5 서브에이전트(Sub-agent)의 경계)은 도구에 따라 모호해질 수 있으며, L6.5와 같은 중간 단계도 현실에서는 혼재되어 나타납니다. 그럼에도 불구하고, "왜 같은 지시가 먹히기도 하고 먹히지 않기도 하는가"를 이토록 명쾌하게 설명하는 척도는 제가 달리 알지 못합니다.

경쟁의 중심이 모델(Model)에서 하네스(Harness)로 옮겨갔다는 이야기는 몇 번이고 듣습니다. 하지만 그 하네스를 "어느 채널에, 어떤 제약(Constraint)을 실을 것인가"라는 해상도로 이야기할 수 있는 사람은 아직 많지 않습니다. 당신의 CLAUDE.md가 현재 몇 단계인지를 말할 수 있게 되는 것만으로도, 다음에 구축해야 할 곳이 한층 더 명확해질 것입니다.

참고

1차 정보를 우선적으로 나열합니다.

관련 정보 (harness란 무엇인가에 대한 보조선으로서):

  • Components of a Coding Agent — Sebastian Raschka
  • AI는 아무렇지도 않게 거짓말을 한다. 그런데도 ClickHouse는 백만 줄의 C++를 돌린다 (AI Watch) ── L6 「판단의 벽」의 현장판

이 기사는 「AI Watch」에도 게재되었습니다. 최첨단 AI를 기술적인 내용까지 일본어로 풀어내고 있습니다.

Discussion

AI 자동 생성 콘텐츠

본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0