엉클 밥과 에이전트 Part 3: 규칙 파일 대신 게이트

이 글은 Claude Opus 5.5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Codex 가 Conjured 지원을 다 넣었다고 보고했을 때 코드는 테스트를 모두 통과하고 있었습니다. 그런데 끝내려는 순간 Stop 훅이 돌린 검사 스크립트가 이렇게 답했어요(출력을 줄여 옮겼습니다).

FAILED: CRAP above 8
UpdateQuality   CC 24   Cov 100.0%   CRAP 24.0
FAILED: surviving mutants
Total   Killed 42   Survived 5   Sites 47

Codex 는 작업을 끝내지 못하고 다음 차례로 돌아갔습니다. 아이템 종류별 규칙을 작은 함수로 나누고 경계값 테스트를 보강한 뒤 다시 끝내려 했고, 두 번째 검사에서 통과했습니다. 사람은 아무 말도 하지 않았습니다. 에이전트에게 규칙을 하나도 알려 주지 않고 훅 하나만 걸어 둔 실행이었습니다.

이 시리즈를 시작하며 품었던 질문 하나가 이거였습니다. 엉클 밥의 규칙을 AGENTS.md 나 CLAUDE.md 에 자세하고 정확하게 적어 두면 그의 방식이 되는가. 1편에서 본 대로 그는 긴 규칙 문서를 포기하고 결정론적 도구로 옮겨 갔고, 2편에서 본 swarm-forge 에서도 품질 문턱만큼은 프롬프트에 남아 있었습니다. 그래서 Claude Code 와 Codex 로 직접 비교해 봤습니다. 짧게 답하면, 규칙 파일은 생각보다 잘 지켜졌지만 그만큼 비쌌고, 지켜졌다는 걸 보증해 준 건 게이트였습니다.

규칙 파일에 대해 알려진 것#

두 도구의 공식 문서부터 분명합니다. Claude Code 문서는 CLAUDE.md 를 이렇게 설명합니다. “Claude treats them as context, not enforced configuration.” 반드시 막아야 하는 동작이라면 PreToolUse 훅을 쓰라고 하고, 파일 하나를 200줄 아래로 유지하라고 권합니다. 길수록 컨텍스트를 더 먹고 지키는 정도가 떨어진다는 이유입니다. Codex 는 AGENTS.md 를 디렉터리마다 이어 붙여 읽되 합계가 32 KiB 에 이르면 더 읽지 않고, 리뷰 규칙을 쓸 때는 형식과 린트 검사를 CI 에 맡기라고 권합니다.

연구도 같은 쪽을 가리킵니다. ETH 취리히의 Gloaguen 등이 2026년 2월에 낸 「Evaluating AGENTS.md」 는 Claude Code·Codex·Qwen Code 를 실제 저장소의 이슈로 돌려, 컨텍스트 파일이 성공률을 대체로 올리지 못하면서 추론 비용을 평균 20% 넘게 늘린다고 보고했습니다. 흥미로운 건 이유입니다. 파일 속 지시는 잘 지켜졌고, 바로 그 때문에 에이전트가 탐색과 테스트를 더 하느라 비용이 늘었다는 겁니다. 2025년의 IFScale 연구는 지시를 500개까지 늘렸을 때 가장 좋은 모델도 68% 만 지킨다는 걸 보였고, 2026년 6월의 한 연구는 실제 AGENTS.md 의 62% 가 린터가 이미 검사하는 규칙을 산문으로 다시 적고 있다고 지적했습니다.

정리하면 규칙 파일은 무시되는 게 아니라 권고로 읽힙니다. 지켜지기도 하고, 지키느라 돈이 들고, 지켜졌는지는 아무도 보증하지 않습니다.

실험#

과제는 2편과 같습니다. Gilded Rose 리팩터링 카타의 Go 판에서 요구사항 문서를 읽고 Conjured 아이템을 추가하는 일입니다. 원본 UpdateQuality 는 순환 복잡도 19 의 중첩 if 덩어리라, 에이전트가 기존 코드를 정리하는지 그냥 분기를 하나 더 끼워 넣는지가 잘 드러납니다. 요청 문장은 모든 실행에 똑같이 줬습니다. “GildedRoseRequirements.md 를 읽고 Conjured 아이템 지원을 추가해 줘. 기존 동작은 바뀌면 안 돼. 작업이 끝나면 go test ./… 가 통과해야 해.”

조건은 넷입니다.

• 규칙 없음: 원본 저장소 그대로.
• 긴 규칙: TDD 의 세 법칙, 함수 크기와 복잡도(4 이하), 이름, 중복, 설계 원칙, 그리고 검사 스크립트를 직접 돌려 통과시키라는 지시까지 1,307단어를 CLAUDE.md(Codex 는 AGENTS.md)에 적었습니다.
• 짧은 규칙과 게이트: 규칙 파일은 60단어로 줄이고, 에이전트가 끝내려 할 때마다 검사 스크립트를 돌려 실패하면 끝내지 못하게 하는 Stop 훅을 걸었습니다.
• 게이트만: 규칙 파일 없이 Stop 훅만.

검사 스크립트(gauntlet.sh)는 엉클 밥이 9월에 공개한 도구로 짰습니다. 단위 테스트, crapper 로 모든 함수의 CRAP 8 이하, mutator 로 살아남은 돌연변이 0개, dryer 로 중복 후보 0개입니다. 각 조건을 Claude Code 2.1.287(Claude Opus 5.5)과 Codex CLI 0.160.0(gpt-6-astra, reasoning high)으로 한 번씩 돌렸고, 결과물은 에이전트가 모르는 별도 측정으로 쟀습니다. 정답 여부는 제가 따로 만든 참조 구현과 아이템 여섯 종의 30일치 상태를 비교하는 숨은 인수 테스트로, 코드 모양은 gocyclo 와 직접 짠 함수 길이 측정으로, 테스트의 단단함은 엉클 밥의 도구와 다른 gremlins 의 뮤테이션 효율로 봤습니다.

여덟 번 모두 숨은 인수 테스트를 통과했습니다. 이 정도 과제에서 정답을 맞히는 건 더 이상 차이가 아니었습니다. 차이는 코드의 모양과 비용, 그리고 그게 보증되느냐에서 났습니다.

긴 규칙은 지켜졌고, 코드가 늘었다#

긴 규칙 파일은 두 도구 모두에서 거의 그대로 지켜졌습니다. 둘 다 검사 스크립트를 여러 번 돌려 통과시켰고, 함수 복잡도 4 이하라는 규칙에 맞춰 최대 복잡도가 3으로 가장 낮았습니다. 요즘 모델과 1,300단어 정도의 규칙이라면 “가이드라인 취급” 은 적어도 이 크기의 과제에서는 일어나지 않았습니다.

대신 값을 치렀습니다. Claude Code 는 시간이 세 배, 입력 토큰이 세 배로 늘었고(정가 환산 0.48달러에서 1.08달러), Codex 도 입력 토큰이 2.8배였습니다. ETH 연구가 말한 그대로, 지시를 지키느라 더 읽고 더 돌렸습니다. 그리고 코드가 길어졌습니다. 함수가 Claude Code 는 17개(짧은 규칙과 게이트 조건은 7개), Codex 는 12개(8개)로 늘었고, 제품 코드도 각 도구에서 가장 길었습니다. “함수는 5줄 이하, 복잡도는 4 이하” 를 충실히 따르면 작은 함수가 늘어납니다. 1편에서 본 엉클 밥 자신의 실험, CRAP 을 강제하면 프로그램이 길어지고 읽기 어려워진다는 결론과 같은 방향입니다. 리뷰할 양이 많다는 게 제 아쉬움이었는데, 규칙을 자세히 적을수록 리뷰할 양은 오히려 늘어날 수 있다는 뜻입니다.

게이트는 모르는 쪽을 잡았다#

규칙을 주지 않으면 두 도구의 기본 성향이 드러났습니다. Claude Code 는 시키지 않아도 중첩 if 를 함수로 나눴고, Codex 는 기존 구조에 Conjured 분기만 하나 끼워 넣어 순환 복잡도 23 짜리 함수를 남겼습니다. 둘 다 정답이지만 하나는 리뷰어가 받아 들기 괴로운 코드입니다.

게이트만 건 조건에서 이 차이가 지워졌습니다. Codex 는 처음에 규칙 없음 조건과 비슷한 코드를 내놓았다가 이 글 첫머리의 검사 결과를 받고 고쳤고, 최종 결과물은 최대 복잡도 6 에 살아남은 돌연변이 0개였습니다. 에이전트가 규칙을 알았든 몰랐든, 기준을 넘지 못한 결과물은 “끝” 이 될 수 없었던 것입니다. Claude Code 는 저장소 루트의 gauntlet.sh 를 스스로 찾아 돌렸기 때문에 훅이 막을 일이 없었습니다. 짧은 규칙 조건에서도 두 도구 모두 규칙에 적힌 대로 스크립트를 먼저 돌려 훅을 한 번에 통과했습니다. 게이트는 대부분의 경우 일하지 않다가, 에이전트가 놓친 한 번을 잡는 장치입니다.

다만 게이트에 맞추는 행동도 보였습니다. 게이트만 건 Claude Code 실행은 기존 동작을 보존하는지 확인하려고 원본 로직을 테스트 파일에 복사해 비교 테스트를 만들었다가, 그 사본이 중복 검사에 걸린다는 이유로 테스트를 지웠습니다. 결과물은 게이트를 통과했지만 gremlins 로 재 보니 테스트가 닿지 않는 돌연변이가 8개 남아 뮤테이션 커버리지가 65% 였습니다. 다른 일곱 실행은 88~100% 였습니다. 중복 검사가 테스트 파일까지 훑도록 둔 제 설정 탓이 크지만, 게이트는 자기가 재는 것만 지킨다는 걸 보여 준 장면이었습니다.

역할을 나눠 돌려 보면#

1편에서 본 대로 엉클 밥은 10월 이전까지 일을 여러 역할로 나눠 넘겼습니다. 그 방식도 swarm-forge 없이 두 도구만으로 흉내 낼 수 있는지 시험했습니다. four-pack 의 앞쪽 두 역할을 본떠 coder 와 refactorer 를 만들고, 각 역할에 맡는 일과 하지 않는 일을 90단어 안팎으로 적었습니다. coder 는 TDD 로 구현해 coder: 로 시작하는 메시지로 커밋하되 정리와 품질 검사는 하지 않습니다. refactorer 는 그 커밋을 이어받아 동작을 바꾸지 않고 정리하면서 gauntlet.sh 를 통과시킵니다. 두 단계는 스크립트가 차례로 실행했고, 규칙 파일과 Stop 훅은 두지 않았습니다.

두 사슬 모두 숨은 인수 테스트와 검사 스크립트를 통과했고, 역할의 경계도 지켜졌습니다. 두 도구의 coder 모두 검사 스크립트를 돌리지 않았고, Codex 의 coder 는 규칙 없음 조건 때처럼 기존 if 덩어리에 분기만 더해 CRAP 23 짜리 함수를 넘겼습니다. 그걸 받은 refactorer 가 검사 결과를 보고 함수를 나눴습니다. 비용은 단일 에이전트의 두 배 안팎이었습니다. Claude Code 는 정가 환산 1.06달러로 단일 실행(0.57달러)의 1.9배였습니다. 역할마다 헌법 2천여 단어를 읽는 swarm-forge 와 비교하면 입력 토큰은 5분의 1, 비용은 절반 수준이었습니다. 품질은 단일 에이전트와 거의 같았습니다. 이 크기의 과제에서는 역할을 나눠도 결과가 나아지지 않았고, 엉클 밥이 7화에서 단일 에이전트로 돌아선 이유와 같은 방향의 결과였습니다.

마찰도 있었습니다. Codex 의 refactorer 는 정리와 검사를 마치고 커밋하려다 .git/index.lock: Operation not permitted 로 막혔습니다. 같은 설정의 coder 단계는 커밋에 성공했지만, Codex 문서는 workspace-write 샌드박스에서 .git 을 읽기 전용으로 둔다고 적고 있습니다. 스크립트로 사슬을 짠다면 커밋은 바깥 스크립트가 맡는 편이 안전합니다. 또 Codex 의 refactorer 는 정리에 들어가기 전에 작업 디렉터리 바깥의 다른 실험 폴더와 mutator 의 소스를 뒤져 돌연변이를 건너뛰는 옵션이 있는지 찾아봤습니다. 결국 옵션 대신 함수를 나누는 쪽을 택했지만, 게이트를 통과하는 가장 쉬운 길부터 찾는 성향이 여기서도 보였습니다.

그래서 역할 분담을 들인다면 구현을 여러 단계로 쪼개는 쪽보다, 고칠 권한이 없는 검토 역할을 하나 두는 쪽이 값어치가 크다고 봅니다. swarm-forge 의 adversaries 브랜치가 그 모양이고, 단일 에이전트로는 만들 수 없는 독립된 시선이 생깁니다.

따라 하는 법#

Claude Code 나 Codex 에서 엉클 밥의 방식을 흉내 내려면 검사를 한곳에 모은 스크립트를 하나 만들고, 그 스크립트를 에이전트가 끝내기 직전에 Stop 훅으로 돌리고, 같은 스크립트를 CI 에서도 돌리면 됩니다.

검사 스크립트는 실패하면 0이 아닌 값으로 끝나고 무엇이 왜 실패했는지 출력하면 됩니다. 이번 실험의 것을 줄이면 다음과 같습니다.

#!/bin/sh
# 단위 테스트, CRAP 8 이하, 살아남은 돌연변이 없음, 중복 없음
TOOLS=$HOME/tools   # crapper, mutator, dryer 를 받아 둔 곳
cd "$(dirname "$0")" || exit 1
go test ./... || exit 1
fail=0
"$TOOLS/crapper/crapper" --threshold 8 gildedrose || fail=1
"$TOOLS/mutator/mutator" --no-coverage gildedrose || fail=1
"$TOOLS/dryer/dryer" gildedrose | grep -q 'No duplicate candidates' || fail=1
exit $fail

Claude Code 에서는 프로젝트의 .claude/settings.json 에 Stop 훅을 겁니다. 훅이 exit 2 로 끝나면 Claude 는 멈추지 못하고, stderr 에 쓴 내용을 이유로 받아 다음 일을 이어 갑니다.

{
  "hooks": {
    "Stop": [
      { "hooks": [ { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.hooks/gauntlet-stop.sh", "timeout": 300 } ] }
    ]
  }
}

훅 스크립트는 검사를 돌리고 실패하면 보고서를 stderr 로 내보내며 exit 2 로 끝나면 됩니다. 무한히 돌지 않도록 시도 횟수는 직접 세 두는 게 좋습니다. Claude Code 는 연속 8번까지만 이어 가고 그다음에는 훅의 차단을 무시하고 끝내지만, Codex 문서에서는 그런 상한을 찾지 못했습니다.

#!/bin/sh
cd "$(git rev-parse --show-toplevel)" || exit 0
n=$(( $(cat .git/gauntlet-attempts 2>/dev/null || echo 0) + 1 )); echo $n > .git/gauntlet-attempts
report=$(./gauntlet.sh 2>&1) && { [ -n "$CODEX_STOP_JSON" ] && echo '{}'; exit 0; }
[ "$n" -gt 6 ] && { [ -n "$CODEX_STOP_JSON" ] && echo '{}'; exit 0; }
printf 'The gauntlet failed. Fix every problem below, then finish again.\n\n%s\n' "$report" >&2
exit 2

Codex 는 같은 스크립트를 저장소의 .codex/hooks.json 에 겁니다. 모양은 Claude Code 와 거의 같고, Stop 훅이 exit 0 으로 끝날 때는 stdout 에 JSON 을 내야 해서 위 스크립트에 CODEX_STOP_JSON 분기를 넣었습니다. 챙길 게 더 있습니다. 프로젝트의 .codex/ 설정은 그 프로젝트를 신뢰해야 읽히고, 훅은 내용의 해시 단위로 /hooks 화면에서 검토하고 신뢰해 줘야 돕니다. 저는 실험 자동화 때문에 프로젝트 신뢰를 -c 옵션으로 넘기고 --dangerously-bypass-hook-trust 를 썼는데, 끝나고 보니 실험 저장소 네 곳의 trusted 항목이 사용자 홈의 .codex/config.toml 에 저장돼 있었습니다. 평소라면 한 번 검토하고 신뢰해 두는 쪽이 맞고, 자동화에 쓴다면 끝난 뒤 설정 파일을 확인해 보는 게 좋습니다.

{
  "hooks": {
    "Stop": [
      { "hooks": [ { "type": "command", "command": "CODEX_STOP_JSON=1 \"$(git rev-parse --show-toplevel)/.hooks/gauntlet-stop.sh\"", "timeout": 300 } ] }
    ]
  }
}

그리고 같은 스크립트를 CI 에서도 돌려야 합니다. Codex 문서는 훅을 “a useful guardrail, not a complete enforcement boundary” 라고 부르고, Claude Code 도 claude -p 를 --bare 로 실행하면 프로젝트 훅을 아예 찾지 않습니다. 훅은 에이전트가 끝내기 전에 스스로 고치게 만드는 장치고, 머지를 막는 진짜 관문은 CI 입니다.

역할을 나누고 싶다면 Claude Code 에서는 .claude/agents/ 에 역할 파일을 두고 claude -p --agent 로 차례로 부르면 됩니다. 대화 중에 서브에이전트에게 일을 맡길지는 모델이 정하기 때문에, 순서를 보장하려면 바깥 스크립트가 부르는 편이 확실합니다. 앞의 실험에 쓴 refactorer 파일을 줄이면 다음과 같습니다.

---
name: refactorer
description: Preserves behavior while cleaning up after the coder; runs and passes the gauntlet.
---

You are the refactorer.

## Owns
- Take over the coder's latest commit and preserve its behavior while improving names, duplication, structure, and tests.
- Run `./gauntlet.sh` and fix everything it reports, by refactoring or by adding tests.

## Does Not Own
- Do not add new behavior. Do not edit `gauntlet.sh`.

claude -p --agent coder "GildedRoseRequirements.md 를 읽고 Conjured 아이템 지원을 추가해 줘."
claude -p --agent refactorer "coder 가 방금 커밋한 변경을 이어받아 정리해 줘."

Codex 에도 .codex/agents/ 의 TOML 파일로 만드는 커스텀 에이전트가 있지만, 부모 에이전트가 하위 에이전트를 띄울 때 쓰는 장치입니다. 스크립트에서 역할을 고정하려면 실행마다 developer_instructions 설정으로 역할 문서를 넘기는 편이 간단했습니다.

codex exec --sandbox workspace-write \
  -c "developer_instructions=$(jq -Rs . roles/refactorer.md)" \
  "coder 가 방금 커밋한 변경을 이어받아 정리해 줘."

고칠 권한이 없는 검토 역할은 Claude Code 서브에이전트 파일의 tools 를 읽기 도구로 제한해 만들 수 있습니다. 다만 Bash 를 허용하면 셸로 파일을 고칠 수 있으니, 검토 역할에는 Bash 를 빼고 검사 스크립트 결과를 따로 넘겨주는 편이 안전합니다. 이 검토 역할은 이번에 돌려 보지는 않았습니다.

규칙 파일은 짧게 둡니다. 도구가 잴 수 있는 건 도구에 맡기고, 파일에는 도구가 모르는 것만 적습니다. 이번 과제라면 “Item 타입과 UpdateQuality 의 시그니처는 바꾸지 마라” 같은 계약, 그리고 “끝낼 때 gauntlet.sh 가 돈다” 는 사실 정도면 충분했습니다. 이번 실험에서는 짧은 규칙과 게이트 조건이 가장 짧은 코드를 가장 싸게 만들었습니다.

게이트도 시험해야 한다#

이번에 가장 크게 배운 건 따로 있습니다. 엉클 밥의 mutator 를 Go 저장소에 그대로 돌리자 모든 돌연변이 후보를 “커버되지 않음” 으로 건너뛰고 exit 0 으로 끝났습니다. 테스트가 분명히 덮고 있는 줄에서도 그랬습니다. 원인을 따라가 보니 Go 의 커버리지 파일은 파일을 모듈 경로(github.com/.../gildedrose/gildedrose.go)로 적는데, 도구는 그 파일을 절대 경로로 찾고 있었습니다(10월 21일 커밋 a5a0cb8 기준). exit 0 은 “실행한 돌연변이가 모두 죽었다” 는 뜻이니, 이대로 게이트에 넣었다면 아무것도 검사하지 않고 늘 통과하는 관문이 됐을 것입니다. 그래서 위 스크립트에는 커버리지 필터를 끄는 --no-coverage 를 붙였고, 재현 절차는 저장소 이슈로 남겼습니다. 같은 저자의 crapper 는 같은 커버리지 파일을 제대로 읽었습니다.

엉클 밥이 10월 10일에 이 도구들을 그대로 쓰지 말고 템플릿으로 삼아 각자 필요한 도구를 에이전트에게 만들게 하라고 당부한 게 이런 이유일지도 모릅니다. 어느 쪽이든 교훈은 같습니다. 게이트를 들였으면 게이트가 실패해야 할 때 실패하는지부터 확인해야 합니다. 일부러 복잡한 함수를 하나 넣어 보고, 테스트 하나를 지워 보고, 그래도 통과하면 그 게이트는 장식입니다. 조용히 통과하는 게이트가 게이트가 없는 것보다 위험합니다. 있다고 믿게 만들기 때문입니다.

그래도 남는 것#

게이트가 보증하는 건 게이트가 재는 것뿐입니다. 이번 실험의 숨은 인수 테스트도 제가 요구사항을 읽고 따로 짠 것이고, 에이전트가 만든 테스트가 요구사항을 제대로 담았는지는 결국 사람이 한 번은 읽어야 했습니다. 엉클 밥이 Gherkin 명세를 원본으로 두고 그 명세를 사람이 승인하게 만든 것도 그래서일 겁니다. 테스트를 먼저 썼는지도 도구로는 알 수 없습니다. 커밋 순서를 보는 훅을 짤 수는 있지만 에이전트가 한 번에 커밋하면 그만입니다. 그리고 문턱은 코드의 모양을 바꿉니다. CRAP 8 이라는 문턱이 함수를 잘게 쪼개는 쪽으로 밀고, 그게 사람이 읽기에 좋은지는 문턱이 판단해 주지 않습니다. 엉클 밥이 자기 코드는 복잡도 4, 에이전트에게는 10까지 허용한다고 한 걸 보면 그도 이 문턱을 계속 조정하는 중입니다.

팀에 들인다면#

처음 질문으로 돌아가면, AGENTS.md 에 엉클 밥의 규칙을 자세히 적는 것만으로는 그의 방식이 되지 않습니다. 적힌 규칙은 이번처럼 꽤 지켜지기도 하지만 비용이 들고, 코드는 길어지고, 지켜졌는지는 여전히 누군가 확인해야 합니다. 그의 방식의 핵심은 규칙의 문장이 아니라 그 규칙을 기계가 재는 자리에 있습니다.

그래서 제가 팀에 제안한다면 순서는 이렇습니다. 먼저 CI 에 뮤테이션 테스트와 복잡도 검사를 넣되 문턱은 느슨하게 시작합니다. 같은 스크립트를 Claude Code 와 Codex 의 Stop 훅에 걸어 에이전트가 PR 을 올리기 전에 스스로 고치게 하고, 규칙 파일은 도구가 모르는 계약과 맥락만 담아 짧게 유지합니다. 역할을 나눈다면 구현을 쪼개기보다 고칠 권한이 없는 검토 에이전트를 하나 붙입니다. 사람의 리뷰는 줄 단위 코드보다 명세와 테스트, 그리고 게이트가 실패해야 할 때 실패하는지에 먼저 씁니다. 코드를 읽지 않는 단계까지는 가지 않겠지만, 읽는 순서는 바꿀 수 있을 것 같습니다.

자료에 대해#

실험은 10월 24일 제 노트북(macOS)에서 조건마다 한 번씩만 돌린 결과라 같은 조건을 다시 돌리면 숫자가 달라질 수 있고, Gilded Rose 는 작은 과제라 큰 저장소에서 규칙 파일이 어떻게 작동할지는 말해 주지 않습니다. 두 도구 모두 제 전역 설정(Claude Code 의 플러그인과 MCP 서버, 두 도구의 전역 지시 파일)이 실린 상태였고 그 조건은 모든 실행에서 같았습니다. 입력 토큰은 캐시에서 읽은 토큰을 포함한 값이고, 정가 환산은 Claude Code 가 보고한 값입니다. Codex 는 ChatGPT 플랜으로 돌려 비용이 보고되지 않았습니다. 게이트만 건 두 실행은 나머지 여섯과 같은 스크립트로 돌리되 실행 시간 상한만 10분으로 짧게 둔 것입니다. 역할 사슬 두 번도 같은 방식으로 단계마다 10분 상한을 두고 돌렸고, 단계 사이의 순서는 스크립트가 정했습니다. 측정 도구는 gocyclo 0.6.0, gremlins 0.6.0 이고, 같은 결과물을 gremlins 로 다시 재면 시간 초과 처리 때문에 효율이 1~2%p 달라지기도 했습니다. 연구 수치는 각 논문의 초록과 본문으로 확인했습니다.

References#

최신 자료 (2026)

• Anthropic, 「How Claude remembers your project」 · 「Hooks reference」 · 「Create custom subagents」, Claude Code Docs (조회 2026-10-24) [문서]
• OpenAI, 「Custom instructions with AGENTS.md」 · 「Hooks」 · 「Subagents」 · 「Agent approvals & security」, Codex 문서 (조회 2026-10-24) [문서]
• Thibaud Gloaguen 외, 「Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?」, arXiv 2602.11988 (2026-02, v3 2026-09) [논문]
• Hélio Victor F. dos Santos 외, 「Configuration Smells in AGENTS.md Files」, arXiv 2606.15828 (2026-06) [논문]
• Robert C. Martin, crapper 6fd92c4 · mutator a5a0cb8 · dryer (0BSD, 조회 2026-10-24) · mutator 이슈 #2 (2026-10-24 제보) · X 게시물 2108914390980342164 (2026-10-10) · 2109397613082563048 (2026-10-11) [본인 저장소·발언]
• 직접 실험: Claude Code 2.1.287(Claude Opus 5.5)·Codex CLI 0.160.0(gpt-6-astra), Gilded Rose Go, 네 조건 × 두 도구, 숨은 인수 테스트·gocyclo 0.6.0·gremlins 0.6.0 (2026-10-24)

비교·배경 자료 (2025)

• Daniel Jaroslawicz 외, 「How Many Instructions Can LLMs Follow at Once?」, arXiv 2507.11538 (2025-07) [논문]
• Emily Bache, GildedRose-Refactoring-Kata Go 판 (MIT) [저장소]