문제는 이것이었다. Opus 5.5 이후의 모델은 계획을 세우고, 일을 나누고, 결과를 검증하는 일을 스스로 해낸다. 그런데 내 Claude Code 하네스(harness, AI 코딩 도구를 감싸는 규칙·훅·에이전트의 묶음으로, AI가 일하는 방식을 정하고 감시하는 틀)는 그 일을 한 번 더 하고 있었다. 일을 에이전트(agent, 특정 역할만 맡아 따로 띄우는 보조 AI)에게 넘기고, 그 결과를 훅(hook, 도구가 실행되기 전후에 자동으로 끼어들어 명령을 검사하거나 막는 작은 스크립트)으로 다시 검사했다. 같은 판단이 두 번 일어나니 작업은 느려지고, 틀릴 수 있는 자리도 둘로 늘었다. 그래서 하루 동안 하네스를 절반 가까이 덜어냈다. 에이전트 32종 가운데 26종을 보관하고, 그 일은 모델이 절차서를 읽고 직접 하게 했다. 남긴 훅은 증거 없는 완료를 막는 검문소와, 되돌릴 수 없는 사고를 막는 장치가 중심이다. 응답 언어처럼 세션의 바탕을 맞추는 훅 몇 개도 함께 남았다.
기준은 하나였다. "모델이 지금 혼자서도 하는 일인가." 그렇다면 따로 띄우거나 한 번 더 검사할 이유가 없다. 그런 에이전트는 보관했다. 에이전트가 들고 있던 절차는 버리지 않고 스킬(skill, 정해진 작업 절차를 적어 둔 문서로, 모델이 필요할 때 읽고 따른다)과 규칙으로 옮겼다. 일의 순서를 고정해 여러 에이전트를 차례로 띄우던 Workflow 스크립트 6개도 보관했다. Workflow 도구 자체는 남아 있어서, 밤에 사용자가 병렬 처리를 요청했을 때 한 번 썼다. 반대로 모델이 대신할 수 없는 일은 남겼다. 모델의 자기 보고를 믿지 않고 QA(품질 검증) 증거를 요구하는 검문소, 그리고 대량 삭제나 비밀 파일 커밋(commit, 변경 내용을 이력에 남기는 일)처럼 되돌릴 수 없는 사고를 막는 장치다. 사용자가 정한 것을 어기지 못하게 막는 장치(교차 리뷰를 꺼 두면 호출 차단, 요구 기능 삭제 차단 등)도 남겼다. 따로 떼어 실행하는 에이전트 6종(루프용 5종과 브라우저 QA 껍데기 1종)과, 세션의 바탕을 맞추는 훅 4개도 남겼다. 내 설정에서 뺀 것은 지우지 않고 보관 폴더로 옮겼다. 작업은 세 번에 나눠 했다. 낮에는 내 설정과 저장소(repository, 프로젝트 하나의 코드와 변경 이력을 담은 폴더) 29곳의 훅을, 저녁에는 옮긴 것이 맞는지를, 밤에는 낮에 빠진 저장소 안쪽을 정리했다.
모든 프로젝트에 적용되는 내 설정에서 에이전트 32종 중 26종과 Workflow 스크립트 6개를 보관했다. 훅 등록은 44개에서 19개로, 새 프로젝트에 깔아 주는 훅 템플릿은 32개에서 10개로 줄였다. 일부러 옮기지 않은 3종을 빼면, 에이전트가 하던 절차는 스킬과 규칙으로 옮겼다.
보관한 에이전트 26종의 본문을 살아 있는 스킬·규칙과 한 줄씩 대조했다. 세 곳은 빠진 것을 채웠고, 한 곳은 남아 있던 중복 문장을 걷어냈다. 그리고 긴 절차를 매번 읽히는 자리에서 필요할 때만 읽는 자리로 옮겼다.
저장소에도 그 저장소만의 훅과 에이전트를 따로 둘 수 있다. 낮의 훅 정리는 저장소 33곳 중 29곳에만 닿았고, 저장소 안의 에이전트는 그대로였다. 설정 폴더 152곳을 다시 세서, 빠졌던 저장소 4곳과 워크트리(한 저장소를 다른 폴더에 하나 더 꺼내 둔 작업 사본) 47곳의 훅을 정리했다. 저장소 8곳과 폴더 1곳에 있던 에이전트 43종 중 41종을 보관했다.
리드(lead, 사용자와 대화하는 메인 세션의 모델)는 계획·분배·검증을 스스로 할 수 있다. 그런데 하네스는 그 일을 에이전트에게 맡기고 훅으로 검사하는 방식으로 한 번 더 했다. 아래 그림 왼쪽처럼 리드 아래에 Workflow 스크립트, 역할별 에이전트, 훅이 겹겹이 놓여 있었다. 모델이 혼자 할 수 있는 판단을 여러 겹이 다시 한 셈이다. 그래서 가운데 겹을 걷어냈다. 이제 리드가 절차서를 읽고 직접 한다. 훅은 증거 없는 완료와 되돌릴 수 없는 사고를 막는 일을 중심으로 맡는다. 판단은 모델에게, 강제는 검문소에게 둔 구조다.
"모델이 이미 하는 판단을 하네스가 한 번 더 한다"
"판단은 모델에게, 강제는 검문소에게"
에이전트마다 하나만 물었다. "모델이 지금 혼자서도 하는 일인가." 계획을 세우는 일, 코드를 고치는 일, 버그를 잡는 일, 결과를 검토하는 일은 모델이 이미 직접 한다. 그래서 그 일을 맡던 에이전트 파일은 보관하고, 필요한 절차만 스킬과 규칙으로 옮겼다. 구현 담당처럼 모델이 따로 절차 없이도 하는 일은 옮기지도 않았다. 반대로 따로 떼어 실행하는 것 자체가 목적인 에이전트는 남겼다. 바깥 자료를 격리해서 읽는 트렌드 수집 담당이 그렇다. 만든 쪽이 자기 결과를 채점하지 못하게 따로 세운 적대적 비평 담당도 그렇다. 아래 막대는 최근 30일 동안 각 에이전트가 불린 횟수다.
자가개선·수확 루프에서 쓰는 5종이 남았다. 자가개선 분석, 트렌드 수집, 하네스 검증 단계 실행, 적대적 비평, 전수 감사다. 적대적 비평은 다른 작업에서도 만든 쪽과 떨어진 독립 반박을 맡는다. 여기에 브라우저 출력이 너무 클 때 쓸 수 있도록 브라우저 QA 에이전트를 하나 남겼다. 정책 문서는 이 경우도 내장 범용 에이전트로 넘기라고 적었으니, 이 1종은 정책과 어긋난 채 남아 있다. 다만 926줄이던 절차는 스킬로 옮겼다. 남은 파일은 그 스킬을 가리키기만 하는 48줄짜리 껍데기다.
계획·구현·버그 수정·코드 리뷰·QA 총괄 담당 등 26종을 보관했다. 에이전트처럼 잘못 보이던 안내 문서 1개도 함께 보관했다. 일부러 옮기지 않은 3종을 빼면, 절차는 스킬 26개의 문서 37건과 일부 규칙에 옮겨 적었다. 복사본은 두지 않았다.
일을 나누고 검증 순서를 고정하던 Workflow 스크립트 6개를 보관했다. 여러 작업을 동시에 띄우던 스킬 1개도 함께 보관했다. 30일 동안 Workflow 를 쓴 세션은 4,189개 중 8개였다.
훅이 사는 자리는 세 군데다. 첫째는 내 설정(홈 폴더에 있어 모든 프로젝트에 적용되는 설정)이다. 여기에 59개가 등록돼 있었다. 그중 15개는 Slack 연결 도구의 것이라 이 글에서는 빼고, 하네스 훅 44개를 다뤘다. 둘째는 새 프로젝트에 깔아 주는 템플릿 32개다. 셋째는 실제 프로젝트 33곳에 깔린 설치본이다. 세 자리 모두 같은 기준으로 걸렀다. 증거 없는 완료와 push(작업을 원격 저장소로 올리는 일)를 막는 검문소, 그리고 되돌릴 수 없는 사고를 막는 장치는 남겼다. "일은 이렇게 하라"고 일깨워 주던 훅은 보관했다. 다만 보관한 쪽에도 명령을 실제로 막던 검문소가 여럿 있었다. 정책이 남길 훅을 "QA 검문소와 안전 가드"로 좁게 정했기 때문이다. 축소 직전 등록돼 있던 것만 꼽으면 이렇다. 브라우저 저장소(localStorage) 사용 차단, 브라우저 자동화 세션 이름을 잘못 짓는 관용구 차단, 큰 코드 커밋에 설계 문서가 없으면 차단, Workflow 비용 확인, 팀 작업 계약 확인이 있다. 비신뢰 웹을 읽는 에이전트의 정의를 검사하던 보안 검문소 2종도 있다. 그리고 스킬 읽기 검문소가 있다(스킬 절차를 옮겨 만든 에이전트가 그 절차서를 실제로 읽었는지 대화 기록에서 확인하던 장치다). 이 강제는 이제 멈춰 세우는 검문소 없이 규칙 문장이나 모델의 판단에 맡겨졌다. 사용자가 정한 것을 어기지 못하게 막는 장치 5개는 남겼다(아래 표 셋째 줄). 예외로 남긴 것은 내 설정의 세션 환경 훅 4개다. 응답 언어나 권한 설정처럼 세션의 바탕을 맞추는 훅이라 남겼다(아래 표 마지막 줄). 내 설정과 템플릿에서 뺀 훅은 보관 폴더로 옮겼고, 저장소에 깔린 훅은 git(코드 변경 이력을 관리하는 도구)으로 지웠다.
| 남긴 훅이 하는 일 | 내 설정 (스크립트 18) | 프로젝트용 템플릿 (10) |
|---|---|---|
| 증거 검문소증거 없는 완료 선언과 하네스 파일 훼손을 막는다 | QA(품질 검증) 확인 목록 없이 완료를 선언하면 막기 · 등록된 훅 파일이 실제로 있는지 확인 · 규칙 파일 뒤에 부록을 덧붙이지 못하게 막기 · 규칙 본문 형식 검사 4 | push 전에 QA 증거 확인(공통·화면 QA 두 벌) · 작업 품질 검사 · 완료 주장 검사 · 배포 확인 표식 · 교차 리뷰(다른 AI 모델이 다시 검토하는 일) 검사 6 |
| 사고 방지 장치되돌릴 수 없는 사고를 막는다 | 대량 삭제 · 비밀 파일 커밋 · 관측 기록(세션 대화 기록) 변조 · 작업 폴더 경계 경고 · 브라우저 세션 일괄 종료와 명령 주입(외부 값이 명령으로 실행되게 끼워 넣는 공격) 5 | 비밀 파일 커밋 · 커밋 내용 속 비밀값 · 커밋 메시지의 AI 서명 3 |
| 사용자 결정 지키기사용자가 정한 것을 어기지 못하게 막는다 | 교차 리뷰를 꺼 두면 호출 차단 · 요구 기능을 지워서 "해결"하지 못하게 막기 · 건너뛴 테스트가 늘면 차단 · 자가개선 라운드 예산 · 에이전트를 부를 때 모델 지정 금지 5 | 타입 검사와 빌드를 통과해야 커밋 (웹 타입스크립트 전용) 1 |
| 세션 환경세션의 바탕을 맞춘다 | 프로젝트 권한 설정 자동 적용 · 한글 응답 알림 · 사용자 지적 감지 · 팀 작업 세션 표식(QA 확인 목록 검문소를 돕는다) 4 | 해당 없음. 세션 환경은 내 설정이 맡는다 |
규칙은 세션이 시작될 때마다 모델이 함께 읽는 지시 문서다. 규칙 안에 "이 일은 저 에이전트를 불러서 하라"는 문장이 남아 있으면 문제가 생긴다. 에이전트를 보관해도 모델이 계속 없는 에이전트를 찾는다. 그래서 규칙 52개를 전부 훑었다. 에이전트에게 일을 넘기는 방법만 적은 규칙 4개는 은퇴시켰다(더는 읽히지 않게 보관 폴더로 뺐다). 특정 도구를 쓸 때만 필요한 4개는 필요할 때만 읽는 폴더로 옮겼다. 15개는 에이전트에게 맡기라는 문장을 리드가 직접 하라는 문장으로 고쳐 썼다. 보관한 에이전트의 절차는 대부분 스킬에 옮겨 적었다. 스킬 26개, 문서 37건이다. 버그 수정 절차와 검증 명령처럼 일부는 규칙으로 들어갔다.
하네스를 줄이면 그 하네스를 재던 검사 도구도 함께 낡는다. 은퇴한 에이전트를 기준점으로 삼던 검사기나, 보관한 훅을 찔러 보던 점검기가 그대로면 판단이 꼬인다. "검사기가 깨진 것"을 "하네스가 깨진 것"으로 잘못 읽게 된다. 그래서 검사 도구 일곱 종을 새 구성에서 전부 다시 돌렸다. 다섯 종은 새 구성에 맞게 고쳤고, 두 종은 고칠 것 없이 통과했다. 고친 것 중 발표 내용 대조 검사기는 프로젝트 템플릿 쪽 기대 목록을 고치는 일이 남았다. 아래 수치는 모두 글을 쓰던 2026-10-03 밤에 실행한 결과다. "종료 코드 2"는 검문소가 명령을 막을 때 내는 차단 신호다.
| 검사 도구 | 무엇을 재나 | 지금 결과 | 고친 것 |
|---|---|---|---|
| 발표 내용 대조 검사기 | 발표(키노트)에서 "강제된다"고 말한 검문소들이 실제 하네스에 등록돼 있고, 규칙 위반 입력을 받으면 실제로 차단 신호(종료 코드 2)를 내는지 | 강제 확인 8/8 대조표에 오른 차단 검문소 8개 전부. 내 설정 훅 19개 중 나머지는 이 검사가 재지 않는다 | 내 설정 쪽 기대 목록에서 보관한 훅 3행(브라우저 저장소 차단 1, 감지 훅 2)을 지웠다. 8/8 은 그 뒤의 분모다. 프로젝트 템플릿 쪽은 그대로 둬서 보관한 템플릿 3종이 "빠진 것"으로 표시되므로, 그쪽을 고치는 일이 남았다 |
| 검문소 생존 점검기 | 차단 훅 7종에 위반 입력을 넣어 살아 있는지 | 7/7 통과 점검 입력이 없는 6종은 표시만 | 에이전트 호출을 검사하는 검문소 줄을 되살렸다. 남긴 에이전트 6종이 아직 그 길을 쓴다 |
| 측정 기록 감시기 | 수치를 시간순으로 쌓는 기록(원장)이 멈췄는지, 같은 값만 받는지, 비었는지를 가려내는지 | 자가 시험 6/6 | 바꾼 것 없음. 새 구성에서도 통과했다 |
| 경로·표식 계약 검사기 | 규칙·스킬·훅이 서로 가리키는 경로와 표식이 실제로 있는지 | 25/25 내 설정·프로젝트 양쪽 | 은퇴한 팀 총괄 에이전트를 기준점으로 삼던 항목을 지웠다 |
| 등록 대상 존재 검사기 | 설정에 등록된 훅의 대상 파일이 디스크에 실제로 있는지 | 등록 34 · 없는 파일 0 34 = 하네스 훅 19 + Slack 연결 도구 15 | 바꾼 것 없음. 보관으로 사라진 파일을 가리키는 등록이 0건이었다 |
| 새 프로젝트 설치 시험 | 새 프로젝트에 설치하면 허용 목록 10개만 깔리고, 은퇴 훅은 지워지고, 증거 없는 push 가 막히는지 | 종료 코드 2 설치본 11파일(검문소 9 + 보조 2) | 필수 목록을 공통 7개로, 웹 타입스크립트용은 커밋 전 검사 1개로 줄였다. 비어 버린 백엔드·Flutter·Supabase 분류는 지웠다 |
| 저장소 훅 정리기 | 33개 프로젝트의 설치본과 워크트리 47곳에서 허용 목록 밖의 훅을 등록과 파일 모두 지우는지 | 남은 것 0 저장소 33 · 워크트리 47 재검사 | 처음에는 git 이 수정된 파일 삭제를 거부했다. 그래서 8개 저장소에 51개 파일이 조용히 남았다. 실패를 숨기지 않게 고친 뒤(강제 옵션을 쓰고, 실패하면 멈추게) 다시 적용했다. 밤의 전수 재고에서는 처음 목록에서 빠졌던 깊이 3의 저장소 4곳과 워크트리를 찾아 같은 절차로 마쳤다(아래 '저장소 안쪽' 절) |
낮의 정리가 끝난 뒤, 정말 잘 옮겼는지 디스크에서 다시 확인했다. 보관한 에이전트 26종의 본문을 살아 있는 스킬·규칙 전체와 한 줄씩 대조했다. 영어 원문을 한글로 바꿔 적은 경우처럼 줄로 잡히지 않는 것도 있었다. 그런 것은 결과물 형식, 판정 규칙, 점검 목록 같은 산출 약속이 옮긴 곳에 있는지 항목별로 봤다. 결과는 "대부분 옮겨졌지만 네 곳은 손봐야 했다"였다. 세 곳은 빠진 것을 채웠고, 한 곳은 남아 있던 중복 문장을 걷어냈다.
옮겨 둔 자리도 문제였다. 규칙은 세션마다, 스킬의 첫 문서는 그 스킬을 부를 때마다 통째로 모델에 실린다. 긴 절차를 그 두 자리에 두면 읽기도 전에 컨텍스트(모델이 한 번에 볼 수 있는 분량)를 차지한다. 그래서 긴 절차는 별도의 절차서와 참고 문서로 옮겼다. 첫 문서에는 개요와 "어디를 읽으라"는 안내만 남겼다.
| 옮긴 방식 (보관 26종 = 6 + 17 + 3) | 에이전트 → 옮긴 곳 | 근거 |
|---|---|---|
| 원문 대부분을 옮김 6 | 문체 복제 → 문체 복제 스킬 절차서 94% · 버그 수정 → 에러 복구 89% · 결제 전문 → 결제 스킬 88% · 코드 리뷰 → 리팩토링 스킬 78% · QA 시나리오 작성 → QA 시나리오 생성 스킬 · QA 총괄 → QA 반복 스킬 63%. 남긴 브라우저 QA 도 926줄 절차의 93%가 브라우저 테스트 절차서에 있다 | 원문 줄 대부분(63~94%)이 그대로 남아 있다 (줄 단위 대조) |
| 약속 단위로 옮김 17 | 계획 수립 → 팀 작업의 계획 확정 · 계획 비평 → 제품 기획의 계획 시뮬레이션 통과·반려 판정 · 검증 → 작업 재검증의 완료 주장 분류·판정 규칙 · Figma 디자인 → 기획·디자인의 Figma 제작 순서 · 제품 관리·디자인·정보 구조·UX 리서치(사용자 경험 조사)·분석 5종 → 제품 기획의 산출 형식 11곳 · 브랜드 전략 → 브랜드 키트 · 마케팅 총괄 → 마케팅 계획 · 프론트엔드·백엔드 전문 → 각 규칙 · 화면 검수 → 기획·디자인의 블라인드 검수(만든 쪽 설명을 보지 않고 결과물만 보고 판단하는 검수) · 기능 테스트 실행·웹앱 테스트 실행·사용자 대리 → 각 스킬 + QA 검증 단계 규칙 | 문장은 한글로 바뀌었지만 출력 형식, 판정 규칙, 완료 점검 항목이 옮긴 곳에 전부 있다 |
| 일부러 안 옮김 3 | 탐색(내장 탐색 에이전트와 중복) · 글쓰기 · 구현 실행 본문. 셋 다 축소 전 기준으로 "이 이름으로 띄우라"는 문장이 스킬·규칙·훅에 한 곳도 없었다. 구현 실행 막대의 143회는 그런 고정 호출 없이 실제로 띄운 횟수다. 구현 실행이 지키던 증거 약속(종료 코드를 따로 받기, 검증 못 한 것은 따로 적기)은 에러 복구·각 분야 규칙·완료 검증 규칙에 이미 있다 | 기준 커밋에서 부르는 곳 0, 모델이 직접 하는 일 |
| 손본 곳 4 (에이전트 수가 아님) | ① 정보 구조 범용 템플릿 4종(구조 지도·분류 체계·이름 규칙·찾기 쉬움 평가)을 제품 기획 스킬의 참고 문서로 ② UX 리서치 템플릿 4종(발견 정리표·리서치 계획·휴리스틱 평가(사용성 원칙 목록으로 화면을 점검하는 방법)·인터뷰 가이드)도 같은 곳에. 둘 다 단독 요청이 닿도록 스킬 설명에 길을 냈다 ③ 백엔드 보안 점검 목록의 전역 예외 처리 항목 복원 ④ 스킬 안에 남아 있던 Workflow 정책 반복 3줄 제거(정책은 전역 지시 문서 한 곳에만) | 30일 동안 UX 리서치 담당이 14회, 정보 구조 담당이 5회 불려 쓰던 산출 형식이다 |
여기까지는 주로 내 설정 이야기였다. 그런데 하네스는 저장소 안에도 둘 수 있다. 저장소의 설정 폴더에 그 저장소만의 훅·에이전트·스킬을 넣으면 된다. "저장소 안쪽도 정리된 건가"라는 물음에 답하려고 이 폴더 152곳을 전부 다시 셌다. 답은 "아니오"였다. 낮의 훅 정리는 폴더 깊이 2까지만 훑어서, 깊이 3에 있는 저장소 4곳이 빠졌다. 워크트리 49곳은 아예 셈 밖이었다. 저장소가 직접 만든 에이전트 43종에는 손대지 않은 상태였다. 그래서 같은 기준을 저장소 안쪽까지 적용했다. 에이전트가 있는 저장소 8곳 중 7곳은 사용자가 병렬 처리를 요청해 Workflow 로 한 번에 돌렸고, 1곳은 직접 고쳤다. 정책은 Workflow 도구를 쓰지 않는 것이지만, 이때는 사용자가 직접 병렬 처리를 요청해서 썼다. 워크트리는 같은 입력에 늘 같은 결과를 내는 스크립트로 처리했다. 남긴 에이전트 2종은 요구 잠금(지켜야 할 문장이 특정 파일에 남아 있는지 세션이 끝날 때마다 확인하는 장치)에 묶여 옮기지 못했다.
| 찾은 것 | 한 것 | 근거와 판단 |
|---|---|---|
| 훅 정리에서 빠진 저장소 4 | 저장소 묶음 폴더 하나 아래의 3곳, 그리고 다른 저장소 안에 들어 있는 하위 저장소 1곳이다. 은퇴 훅 파일 105개와 등록 109건을 지우고 로컬 커밋 4건을 남겼다. 커밋된 상태에서 남은 것 0, 없는 대상을 가리키는 등록 0을 확인했다 | 낮의 29곳 목록이 폴더 깊이 2까지만 훑었다. 전수 감사 스크립트를 남겨 다음에는 깊이와 무관하게 센다 |
| 워크트리 49 | 46곳은 로컬 커밋했다(8월 자동 이슈 처리가 만든 것 37곳, 에이전트 작업용 9곳). 1곳은 설정 폴더가 git 제외 대상이라 디스크만 정리했고, 2곳은 할 일이 없었다. 파일 1,092개와 등록 1,105건을 지웠다. 커밋에 든 파일은 전부 훅 폴더와 설정 파일이고, 작업 중인 소스는 섞이지 않았다 | 워크트리는 그 폴더에서 세션이 열릴 때만 훅이 깨어나 평소엔 잠들어 있었다. 하지만 남겨 두면 다음 자동 이슈 처리가 옛 훅을 물려받는다. 아직 커밋하지 않은 작업물이 있어 워크트리 자체는 지우지 않았다 |
| 저장소가 만든 에이전트 43 → 보관 41 · 남김 2 | 저장소 8곳과 폴더 1곳에 있었다. 30일 동안 불린 횟수는 0이다(밤에 다시 센 대화 기록 4,267개 전수). 아직 부르는 곳이 있던 5종은 그 스킬의 참고 문서로 절차를 옮겼다(한 저장소의 후보 설계 스킬 3, 아이디어 접수 1, 코드 변경 요청 리뷰 1). 나머지 36종은 보관한 원문이 그대로 절차 문서 역할을 한다. 부르던 파일 15개(스킬 5, 운영 문서 10)의 지시는 리드가 직접 하라는 지시로 바꿨다. 과거 보고서와 코드 속 문자열은 역사 기록이라 그대로 뒀다. 한 저장소에서는 테스트용 고정 보고서(픽스처)의 줄 해시를 검사하는 검문소가 에이전트 경로를 읽고 있었다. 그래서 픽스처는 두고, 검사기에 옮긴 경로 대응표를 넣었다 | 남긴 2종은 신약 후보 설계 저장소의 에이전트다. 하나는 후보 세트의 통과·차단을 판정하는 검증자, 하나는 신약 연구 자료를 모으는 수집기다. 보관하려 했지만 막혔다. 그 저장소의 요구 잠금 4줄이 에이전트 파일의 경로 자체를 기준으로 쓴다(에이전트의 도구 목록 등을 지키는 줄이다). 파일을 옮기면 세션 종료 검사와 테스트가 확정적으로 깨진다. 요구 잠금은 사용자 승인 없이 고치지 않으므로 그대로 두었다. 패턴만 남긴 빈 파일로 검사를 통과시키는 방법도 쓰지 않았다. 그 저장소가 네 번 버린 "말에 건 잠금"이 바로 그런 꼼수이기 때문이다 |
| 은퇴한 에이전트를 가리키던 문서 4 | 저장소 4곳의 스킬과 메모다. 버그 수정 에이전트를 부르던 곳은 에러 복구 절차로 바꿨다. 코드 리뷰·QA 보조 에이전트 서술은 직접 수행으로 바꾸고, 교차 리뷰를 켜고 끄는 설정에 맞췄다. 보조 에이전트 메모에는 보관 사실을 적었다 | 외부 플러그인에 든 에이전트 5종과 과거 보고서·코드 문자열 속 언급은 우리 것이 아니거나 역사 기록이라 두었다 |
"모델이 이미 하는 판단을 하네스가 한 번 더 하면, 작업은 느려지고 틀릴 자리는 둘로 는다."
선은 깔끔하게 그어지지 않았다. 보관한 쪽에도 명령을 실제로 막던 검문소가 여럿 있었다. 그 강제는 이제 멈춰 세우는 검문소 없이 규칙 문장이나 모델의 판단에 맡겨졌다. "판단은 모델에게, 강제는 검문소에게"는 방향이고, 경계선은 아직 다 맞지 않았다.