TL;DR

• 새로운 모델 세대가 나올 때마다, 자신이 에이전트에게 부여하고 있는 지시 자산을 점검하고 있다. 이번에는 25개 항목·4,023행이 대상이었다 (2026-08-04 실측).
• 공식 가이드는 "명시적인 검증 지시는 삭제해 주세요"라고 명시한다. 가장 삭제 후보로 보였던 것은, 내가 사고가 날 때마다 덧붙여 왔던 검증 계열의 규칙군이었다. 해당 표현을 grep 했더니 히트 2건, 둘 다 오검출이었다 (당일, 점검 착수 시점).
• 삭제 작업을 하려 시작했으나, 실제로 발견한 것은 3개의 공백(위임의 기동 판정 / 디스크에 쓰는 결과물의 길이 / effort 축). 삭제는 총 0건.
• 게다가 공식이 권장하는 스니펫 2개는 이미 CLI 측의 system prompt에 구현되어 있었다.
• 세대 gate는 항목을 추가하는 작업인 동시에, 하네스(Harness)가 앞서 나간 부분을 덜어내는 작업이기도 하다.

이 기사는 그 점검의 모든 기록과, 사용한 25개 규칙의 카탈로그이다. 발췌본으로는 3개를 전문 게재한다.

지시 자산은 감쇠한다

에이전트에게 전달하는 문장 ── 규칙, 프롬프트, 스킬의 절차서 ── 는 작성 시점의 모델을 향해 쓰여 있다. 모델이 바뀌면 같은 문장이 다른 방식으로 작용한다.

나는 이를 4가지 클래스로 나누어 생각하고 있다.

감쇠하는 것은 2번째뿐이며, 그 부분만을 정기적으로 재검토한다. 이를 세대 gate라고 부르며, 연 24회, 12일 정도 소요하여 진행하고 있다. 지난번은 4개월 전이었다.

해야 할 일은 3가지가 있다.

• 회귀 측정 (Regression Testing) ── 동결된 실험 환경을 신규 모델로 재실행하여, 구세대에서 차이가 났던 항목이 사라졌는지 확인한다. "장치로 강제했던 행동이 모델의 기본값에 흡수되었는가"를 찾아내는 검출기.
• 발견 측정 (Discovery Testing) ── 신규 모델의 초기 몇 세션은 이탈 로그를 기록하며 실행한다. 회귀 측정이 알려진 실패 모드를 지키는 것이라면, 새로운 종류를 포착하는 것은 이것이다.
• 점검 (Inventory) ── 1, 2의 실측을 근거로 문장 지시를 쳐낸다.

이번에 쓰는 것은 3번째이다.

Opus 4.8 → Opus 5에서 무엇이 바뀌었나

공식 가이드를 일문과 영문 모두 가져와 대조했다 (역어의 차이는 없었다).

새롭게 언급되기 시작한 것이 5가지.

방향이 반전된 것이 2가지. 이 부분이 가장 효과가 컸다.

작년의 내가 "더 많이 위임하게 하자"라고 생각하며 쓴 문장이, 올해는 반대로 작용한다. 이것이 문장 지시의 감쇠가 나타나는 구체적인 모습이다.

더 이상 언급되지 않는 것도 4가지 있었다 (리터럴한 지시 준수, 프론트엔드의 기본 스타일 등). 다만 이것은 언급이 사라진 것이지, 부정된 것은 아니다. 따라서 이에 의존한 기술은 그대로 남겨두었다. 이곳을 "사라졌다 = 무효가 되었다"라고 해석하면 근거 없는 삭제가 시작된다.

두려워했던 충돌에 grep을 적용했다

가장 두려웠던 것은 이 문장이다.

프롬프트에 명시적인 검증 지시("자명하지 않은 태스크에는 최종 검증 단계를 포함할 것", "서브 에이전트를 사용하여 검증할 것")가 포함되어 있는 경우에는,

삭제하십시오. 같은 일이, 별도의 검증 단계를 추가하는 레거시 하네스(Legacy Harness)의 스캐폴딩(Scaffolding)에도 적용됩니다.

액면 그대로 받아들인다면, 나의 검증 계통 규칙 3개(총 640행)가 통째로 삭제 후보로 보입니다. 게다가 그것들은 전부 사고로부터 태어난 것들입니다.

• 병렬로 15시간 동안 실행했을 때 발견한 나의 오류 7건은, 모두 「읽지 않고 결정했다」였다
• 「빈 출력을 『해당 없음』으로 읽는다」를 3일 연속으로 범한 날이 있다

이것을 지우는 것은 두렵습니다. 다만, 두렵다는 감정은 근거가 아니기에, 측정해 보기로 했습니다.

grep -rn "최종검증\|검증단계\|만약을 위해\|재확인\|재검증\|double-check" ~/.claude/rules/*.md

히트(Hit)는 2건이었습니다.

• 외부 공개 전에 인간의 승인을 받으라는 기술(모델의 자기 재체크가 아님)
• 환경이 바뀌면 검사의 전제가 유효한지 확인하라는 기술(위와 동일)

둘 다 공식이 지시하는 「모델에게 자신의 출력을 재체크하게 하는 의식」은 아니었습니다. 두려워했던 충돌은, 문구 수준에서는 거의 존재하지 않았습니다.

이유는 나중에 알게 되었습니다. 나의 규칙은 사고로부터 태어났기에, 처음부터 「명령어로 측정하는」 형태로 작성되어 있었습니다. 「만약을 위해 확인하라」가 아니라 「wc -l로 다시 세어라」라고 적혀 있습니다. 전자는 모델에게 하는 부탁이고, 후자는 외부 세계의 측정입니다.

이 grep은 더 이상 재현되지 않는다

기사를 쓰면서, 공개 전 확인으로서 이 grep을 다시 한번 입력했습니다.

9건이 돌아왔습니다.

늘어난 7건의 내용은, 재고 조사(Inventory) 결과를 작성한 문장 그 자체였습니다. 「최종 검증 단계를 포함하라고 공식은 말하지만 본 규칙은 대상 외임」이라고 적은 행이 「최종검증」에 걸립니다. 「만약을 위해 재확인하는 계열은 삭제한다」라고 적은 행이 「만약을 위해」와 「재확인」 모두에 걸립니다.

만약을 위해, 커밋(Commit)된 상태까지 거슬러 올라가 동일한 grep을 적용해 보았습니다 ── 1건. 차이 나는 1건은 7월에 추가로 작성하고 아직 커밋하지 않았던 기술이었습니다.

「2건」이라는 숫자는, 측정한 시점에는 맞습니다. 하지만 지금 이 기사를 읽고 동일한 명령어를 나의 규칙에 입력해도, 그 숫자는 재현되지 않습니다.

이것은 자신의 규칙에 적혀 있는 함정 그 자체였습니다 ── 검사 자체가 부패한다. 어떤 검사가 통과하고 있었던 것은, 우연히 주변 상황이 그러했기 때문이며, 그 상황이 바뀌면 동일한 검사가 다른 것을 측정하기 시작합니다. 이번에는, 측정 결과를 기록한 행위가 측정 대상을 오염시켰습니다.

대책으로서 거창한 것은 필요 없고, 측정한 시점의 스냅샷(Snapshot)에 대해 측정하는 것이 옳습니다. 버전 관리 하에 있다면 git show HEAD:를 사이에 넣기만 하면 됩니다. 이번에는 넣지 않았습니다.

그래서 이 기사의 숫자에는, 전부 언제 측정했는지를 적어 두었습니다.

선긋기 한 줄

그래서 삭제가 아니라 선긋기의 명문화를 했습니다. 검증 계통 규칙의 서두에, 이것이 무엇이고 무엇이 아닌지를 선언하는 절을 추가했습니다. 내용은 한 줄도 깎지 않았습니다.

발췌 1 ── 검증 규칙의 서두에 배치한 사정 주석(전문)

본 rule의 사정 ── 기계적 gate(Gate)이지 「만약을 위한 재체크」가 아니다

공식 Opus 5 가이드는 「명시적인 검증 지시(자명하지 않은 태스크에는 최종 검증 단계를 포함할 것 / 서브 에이전트를 사용하여 검증할 것)는 삭제하라, 과도한 검증을 유발한다」라고 명시한다. 본 rule은 그 대상이 아니다. 구분은 하나:

모델이 이미 수행하고 있으며, 지시는 중복되어 비용만 늘리는 판정의 한 줄:

「그 검증은, 명령어의 출력이 근거가 되는가?」가 되지 않는 검증 지시는 쓰지 않는다. 게다가 공식은 "

「자신의 작업을 검증하기 위해 서브 에이전트(Sub-agent)를 사용하지 마라」고 명시한다 ── 검증을 추가하는 것 자체가 비용과 리스크를 동반한다는 점에서 같은 방향이다.

이 선긋기 자체는 공식적인 근거가 없다. 공식 문서에는 이 구분이 명시되어 있지 않으므로, 나의 해석이다. 그래서 반증 가능한 형태로 만들어 두었다 ── 검증의 전파 블록(propagation block)을 해제한 위임을 5회 실행했을 때, 테스트 미실행 상태로 「완료」라고 보고하는 경우가 단 1회라도 발생한다면, 이 선긋기는 안일한 것이다.

발견된 것은 3가지 공백

작업을 줄이는 것이라고 생각하며 시작했는데, 정작 나온 것은 부족한 것들이었다.

공백 1 ── 「애초에 위임할 것인가」에 대한 판정이 없었다

위임 프롬프트의 품질에 대해서는 4가지 세트(배경과 why / 진척의 근거 요구 / 일반해 강제 / 가독성의 전파)가 작성되어 있었다. 완료 조건을 기계적으로 측정할 수 있는 형태로 만들 것, 모니터링을 설치할 것, 뒷정리를 할 것까지 적혀 있었다.

「어떻게 위임할 것인가」만을 적어 두었다. 「애초에 위임할 것인가」를 판정하는 행은 단 한 줄도 없었다.

그 지점에 Opus 5의 「이전보다 적극적으로 위임한다」가 들어온다. 게다가 나에게는 과잉 위임의 실측 데이터가 이미 있었다 ── 9개를 병행 실행시켰을 때, 인터럽트(interrupt) 통지가 6회 발생했고, 그중 2개는 결과물 없이 멈춰 있었다. 가이드의 경고와 나의 실측치가 일치했다.

발췌 2 ── 새로 만든 「위임 기동 판정」(전문)

0. 위임 여부를 먼저 결정한다 (필수)

기본값은 「위임하지 않음」이다. Opus 5는 이전 모델보다 적극적으로 위임한다 (공식 명시). 방치하면 늘어나기 때문에, 기동 판정을 먼저 배치한다. 다음을

모두 만족할 때만 자식(child)을 생성한다:

• 크다 ── 자신이 도구 호출(tool call) 몇 번으로 끝낼 수 있는 작업은 위임하지 않는다.
• 독립적이다 ── 중간에 부모의 판단을 기다리는 설계라면, 그것은 분할되지 않은 병렬화의 이점일 뿐이다. 직렬로 흘려보내기만 한다면 부모가 처리하는 것이 더 빠르다 (spawn + 모니터링 + 검증의 비용이 추가됨).
• 자식을 생성해서는 안 되는 용도: 자신의 작업 검증 / 이중 체크 (공식 명시 ── 「서브 에이전트를 사용하여 자신의 작업을 검증하지 마라」). Opus 5는 스스로 자기 수정(self-correction)을 한다.
• 수는 최소한으로: 1개로 충분하다면 1개. 나열하기 전에 「이 분할이 정말로 독립적인가」를 한 번 더 자문한다.

실측: 9개 병행 실행 시 idle 통지 6회가 인터럽트가 되었고, 그중 2개는 결과물 없이 idle 상태였다. 모니터링과 뒷정리 비용은 애초의 기동 수에 비례한다 ── 가장 저렴한 대책은 세우지 않는 것이다. 또한 멈춘 3건의 원인은 범위가 아니라 태스크(task)의 형태였으므로, 기동 수를 줄이더라도 형태가 결정되어 있지 않으면 멈춘다.

공백 2 ── 디스크에 쓰는 파일의 길이

대화를 간결하게 하는 규율은 가지고 있었다. 「길이를 자기 판단에 맡기지 않는다」, 「결론을 첫 문장에」 등.

공식에서 이번에 언급한 것은 다른 축으로, 디스크에 쓰는 파일(리포트, Markdown, 요약)이 이전보다 길어진다는 것이다. 대화의 중언부언과는 별개로 작용한다.

이것은 이미 통증이 나타나고 있었다. 이 기사에서 정리하고 있는 규칙 자체만 해도, 가장 큰 것은 902행에 달한다. 읽히지 않게 된다면 본말전도다. 그래서 가독성 규칙의 8번째 항목으로 추가했다 ── 내용은 다 담되, 채우기용 절(section)·중복되는 요약·정형화된 서론으로 부피를 키우지 않는다.

공백 3 ── effort 축 (이것은 보류했다)

모델 선택 방식에 대해서는 어느 계층을 언제 사용할지를 적어 두었다. effort(추론량)의 축을 가지고 있지 않다. 그리고 Opus 5에서 권장 사항이 반전되어 있다.

이 부분은 적지 않고 보류했다. 이유는 단순하다. 내가 effort를 실측하지 않았기 때문이다. 공식에서도 「이전 모델로부터 이어받은 기본값은 독자적인 평가로 sweep(전수 조사)하라」고 말하고 있다. 숫자를 얻기 전에 규칙에 적으면, 근거 없는 지침이 하나 늘어날 뿐이다.

하네스(Harness)가 앞서 나가고 있었다

이것이 이번에 가장 의외였던 발견입니다.

공식 가이드는 권장 스니펫(snippet)을 2개 싣고 있다 ── 스코프(scope)를 멋대로 넓히지 않기 위한 한 단락과, 사소한 자기 수정을 그만두게 하는 한 단락. 둘 다 나의 규칙에는 없는 축이었다. 추가하려고 했다.

추가하기 전에, 지금 돌아가고 있는 세션의 system prompt를 읽었다. 둘 다 이미 포함되어 있었다.

즉, 가이드의 권장 사항은 이미 하네스(Harness) 측에 구현되어 있다. 여기서 규칙에 추가하는 것은 중복이며, '강조 표현을 약화시킨다'는 나의 방침에도 역행한다.

그래서 재고(Inventory) 절차 자체에 한 줄을 추가했다 ── 규칙에 추가하기 전에, 하네스가 이미 수행하고 있지 않은지 확인한다.

이것은 '프로바이더(Provider)가 진심으로 내놓는 것을 직접 만들지 않는다'라는 나의 오래된 판단 기준의, 지시 자산(Instruction Asset) 버전이었다. 직접 만든 장치가 플랫폼에 흡수되는 이야기는 전부터 해왔지만, 문장 지시에 대해서도 같은 일이 일어날 것이라고는 생각하지 못했다.

발췌 3 ── 재고 절차 자체 (전문)

③ 재고 (지시 자산의 가지치기, ①②의 실측을 근거로)

• 너무 세세한 절차 지시를 깎아내기 ── 공식: "기존 모델을 위한 skill은 지시가 너무 세세한 경우가 많아 출력 품질을 저하시킨다. 기본 성능이 더 좋다면 삭제를 검토하라"
• 강조 표현을 약화시키기 ── "CRITICAL: You MUST..." $\rightarrow$ "Use this tool when..."
• 신모델은 강한 표현에 오버트리거(Over-trigger)하는 강제 scaffolding(스캐폴딩)을 제거 ── "매 N 단계마다 요약하라" 등. 신모델은 기본적으로 품질 높은 진척 보고를 수행함
• 추론 에코(Reasoning Echo) 요구 감사 ── "사고 과정을 써 내려가라" 계열
• 검증 스캐폴딩(Verification Scaffolding) 감사 ── "최종 검증 단계를 두어라", "서브 에이전트로 검증하라", "만약을 위해 재확인하라" 계열. 신모델은 기본적으로 자기 검증 및 자기 수정을 수행하므로, 지시는 중복되어 비용만 증가시킴. 단, 기계 gate(명령의 출력이 근거가 되는 것)는 대상에서 제외
• 하네스 측의 선제적 구현을 뺄셈하기 ── 공식 가이드의 권장 스니펫이 이미 system prompt에 구현되어 있는 경우가 있음.
• 규칙에 추가하기 전에 "하네스가 이미 수행하고 있지 않은가"를 확인한다 ── 세대 gate는 추가하는 작업인 동시에 빼는 작업

재고 전체 기록 (25개)

대상으로 한 규칙 25개와 이번 판정 결과입니다. 삭제는 0건이었습니다. 행수는 모두 2026-08-04의 실측값입니다.

합계 4,023행 / 25개. 변경은 7개, 그중 삭제 0개, 보류 1개.

표를 보며 느낀 점

두 가지가 있습니다.

첫 번째. 행수의 분포가 극단적으로 치우쳐 있다. 상위 5개 항목이 2,023행 ── 전체의 정확히 절반입니다. 게다가 가장 큰 traps.md는 902행에 달하는데, 이는 "읽히지 않게 되면 본말전도"라는 임계값을 이미 한참 넘어선 느낌입니다. 공백 2로 더한 항목이 다음에 효과를 발휘하는 곳은 바로 여기일 것입니다.

두 번째. 사고로부터 태어난 규칙은 처음부터 기계 게이트(Machine Gate)의 형태를 띠고 있다. 상위에 있는 verify.md, accuracy.md, traps.md는 모두 그러하며, 그렇기에 삭제 후보가 되지 않았습니다. 역설적으로 말하면, 삭제할 수 있는 문장 지시를 가지고 있지 않았던 것은 내가 훌륭했기 때문이 아니라, 고통스러운 일을 겪은 횟수의 부산물입니다. 사고를 겪지 않고 작성한 규칙이 있었다면, 그것이 삭제 대상이 되었을 것입니다.

패배 조건

이 재고 조사가 잘못되었다는 것을 알 수 있는 시점은, 다음 현상이 관측될 때입니다.

• 기준(線引き)이 느슨했을 경우── 검증 전파 블록을 축약한 위임(delegation)을 5회 실행했을 때, 테스트를 실행하지 않은 채 "완료"라고 보고하는 경우가 단 1회라도 발생한다면, 기계적 게이트(gate)와 자기 재검토(self re-check)의 구분은 실무상 기능하지 않는 것입니다.
• 기동 판정(起動判定)이 효과가 없었을 경우── 판정을 도입한 이후의 병렬 세션에서, 결과물이 0개인 상태로 멈추는 사례가 다시 발생한다면, 원인은 기동 횟수가 아니라 태스크(task)의 형태에 있는 것이며, 이 추가 사항은 빗나간 것입니다.

확인일은 2026년 9월 30일입니다. 확신도는 적지 않았습니다 ── 1은 구조적으로 타당하다고 생각하지만, 아직 실측 데이터가 없습니다.

마치며

깎아내는 작업이라고 생각하며 시작했지만, 깎아낼 것이 없었습니다. 대신 3개의 빈틈을 발견했고, 그중 1개는 "실측이 없으므로 적지 않음"으로 보류했습니다. 재고 조사로서는 수수한 결과입니다.

하지만 수수했다는 사실 자체가 측정 결과라고 생각합니다. "공식에서 이렇게 말하니까 수정한다"라는 식으로 640행을 지우고 있었다면, 사고 2종류분에 대한 방어 기제가 조용히 사라졌을 것입니다. grep을 한 번 실행하는 것과, 두려운 채로 따르는 것의 차이였습니다.

다음 세대가 오면 다시 똑같은 일을 하겠습니다. 그때는 이번에 추가한 3개가 삭제 후보가 되어 있을지도 모릅니다.

올 사람에게만. 오지 않을 사람에게는, 아무 말도 하지 않습니다.

이런 운영 기록을 작성하고 있습니다. 괜찮으시다면 X와 Zenn을 부탁드립니다.

참고

Discussion