하네스 엔지니어링 측정 1편 — AGENTS.md 비우면 Codex도 fail-fast 안 지킨다

하네스 엔지니어링 측정 1편 — Codex AGENTS.md fail-fast 충실도 약·중·강 3 condition 비교

Codex와 Claude에 같은 명세를 3 condition으로 던졌다

Codex와 Claude에 동일한 Python 함수 명세를 3가지 setup에서 돌렸다. fail-fast 충실도가 약→중→강으로 갈렸고, 그 차이는 모델이 아니라 AGENTS.md 같은 하네스 파일 적용 여부에서 나왔다.

어제 발행한 하네스 엔지니어링 3대 구성요소 글에서 카파시의 이론(컨텍스트 파일·자동 강제 시스템·가비지 컬렉션)을 정리했다. 이 글은 그 이론을 같은 명세 1건으로 직접 측정한 1차 데이터다.

YES 3번 — 이런 적 있다면 이 글이 답이 된다

Codex와 Claude Code 차이를 1주 써보고 잘 모르겠다는 결론을 낸 적 있다.

같은 task로 통제 비교를 안 했기 때문에 모델 차이인지 setup 차이인지 분리 못 했다.

도구 비교 글은 많은데 “차이가 어디에서 나오나”를 측정한 글은 본 적 없다.

측정 setup

명세는 Blogger 발행 검증 함수다. verify_published_post(service, blog_id, post_id, expected_title, min_content_length) — 발행 직후 Blogger API로 post를 재조회해 title 일치·content 최소 길이를 검증한다. fail-fast 규칙 적용 (silent default 금지·예외 그대로 raise).

3 condition:

  1. Codex v1 — 하네스 0. AGENTS.md 없음. 사용자 시스템 인스트럭션 없음.
  2. Claude Opus 4.7 — CLAUDE.md 자동 로드. fail-fast 규칙·Iron Law of Verification 글로벌 메모리에 있음.
  3. Codex v2 — Codex v1과 같은 모델. AGENTS.md를 작업 디렉토리에 두고 프롬프트에서 “AGENTS.md 규칙을 적용하라” 명시 인용.

같은 모델·다른 하네스 비교는 1과 3 (Codex v1 vs v2). 다른 모델·다른 하네스 강도 비교는 2와 3 (Claude auto-load vs Codex 명시 인용).

측정 1 — fail-fast 충실도

조건 dict 필수 키 접근 타입 검증 라인수 fail-fast
Codex v1 .get(k, "") + None→”” 변환 없음 61 약
Claude .get(k, "") 빈값 default 없음 58 중
Codex v2 if k not in: raise KeyError isinstance + raise 73 강

Codex v1은 silent default를 두 군데 썼다. content가 None이면 빈 문자열로 변환하고, 키 없으면 빈값 default. fail-fast 규칙 위반에 가깝다. Codex v2는 같은 모델인데 default 0건. 모든 키 누락·타입 불일치를 raise로 처리한다.

Claude는 중간이다. default를 한 군데 썼다 (.get("title", "")). CLAUDE.md를 자동 로드해서 일반 fail-fast 톤은 따랐지만 dict 접근 세부 패턴까지는 엄격 적용 안 됐다.

측정 2 — Iron Law of Verification 자체 검증 행동

CLAUDE.md와 AGENTS.md 모두 “작업 완료 주장 전 검증 명령 실행” 규칙이 있다. 누가 실제 따랐나.

  • Codex v1: 일반 self-report. 검증 명령 미실행.
  • Claude: 명세 재확인 코멘트만. 검증 명령 미실행.
  • Codex v2: py_compile + ls + wc 실행 후 exit code·라인수·글자수 보고.

같은 규칙이 글로벌 메모리에 있어도 자동 로드일 땐 행동 변화로 안 갔다. 명시 인용일 때만 검증 명령이 실제 실행됐다.

측정 3 — 자동 로드 vs 명시 인용

어제 글에서 “프롬프트 = 부탁, 하네스 = 강제”라 정리했다. 이 측정이 그 명제를 직접 입증한다.

Claude의 CLAUDE.md 자동 로드는 부탁 강도에 가깝다. fail-fast 규칙이 메모리에 있고 글로벌 적용된다고 하지만 dict default 같은 세부 패턴까지는 강제 안 됐다. Codex v2의 AGENTS.md는 프롬프트에서 명시 인용했더니 default 0건·검증 명령 자동 실행으로 행동이 따라왔다.

자동 로드는 카파시 프레임의 컨텍스트 파일에 가깝고, 명시 인용은 자동 강제 시스템에 가깝다. 어제 글 3대 구성요소가 이 측정 데이터로 갈라진다.

한계 + 다음 측정

이 측정은 사례 1건이다.

  • Sampling 우연 미통제: Codex v1과 v2를 한 번씩만 돌렸다. Temperature·sampling 변동으로 v1이 우연히 silent default를 골랐을 가능성 0이라 단정 못 한다. 같은 setup 3회씩 9회 측정이 우연 통제 최소선.
  • Prompt position 효과 미분리: Claude의 CLAUDE.md는 시스템 프롬프트(앞), Codex v2의 AGENTS.md는 사용자 프롬프트 직전(뒤)에 위치. 행동 차이가 강제 강도인지 prompt position인지 통제 안 됐다.
  • 컨벤션 vs 코드 품질 구분: 이 글의 “fail-fast 충실도”는 Jason 컨벤션 기준이다. Codex v1의 None handling이 일반 production에는 더 적절할 수도 있다. “fail-fast 강 = 코드 품질 좋음”이 아니다.
  • 다른 측정 변수: Claude에 AGENTS.md 명시 인용 적용 시 변화·Codex의 더 긴 함수 명세·모델 버전 통제 등 모두 미측정.
  • 일반화 한계: 3 condition 사례 1건이다. 다른 task 5건+ 누적해야 fail-fast 충실도 spectrum을 일반 패턴이라 주장 가능.

다음 글에서 측정 2편을 진행한다. 이 글의 raw 데이터(Codex v1·v2·Claude 함수 코드 3개)는 GitHub gist에 공개했다 — 명세·결과 표·한계 모두 README에 포함.

FAQ

Q. Codex가 Claude보다 fail-fast 약한가?
A. 1차 측정 결과 같은 Codex 모델이 AGENTS.md 적용 여부에 따라 약→강으로 갈렸다. 모델 자체 차이가 아니라 하네스 차이로 보인다.

Q. AGENTS.md와 CLAUDE.md 차이는?
A. 자동 로드 vs 명시 인용 강도 차이. 자동 로드는 부탁에 가깝고 명시 인용일 때만 세부 규칙까지 강제된다.

Q. 1건 측정으로 일반화 가능한가?
A. 가설 입증 1건이다. 일반화는 다음 측정에서 5건+ 누적 후 결정한다.

관련 글

갱신일: 2026-05-05
저자: 닥터조지 (cd4761) — Claude Code·Codex 양쪽 운영 중. 측정 데이터 누적되면 갱신.

태그: #하네스엔지니어링 #AGENTS_md #Codex #ClaudeCode #failfast #하네스측정

댓글

댓글 쓰기

이 블로그의 인기 게시물

Claude Opus 4.7 출시 총정리 — 뭐가 달라졌고 지금 써야 하나

결론: Claude Opus 4.7은 "전부 업그레이드"가 아니다. 에이전트 작업에선 4.6보다 확실히 강해졌지만, 일상 코딩은 Sonnet이 여전히 3~5배 싸다. 2026-04-16 출시 후 Claude Code에서 반나절 써본 결과 3가지 체감 변화와 Qwen 3.6과의 비교까지 정리한다. Opus 4.7 핵심 변화 3가지 4.6과 비교해 체감되는 지점은 세 곳이다. 1. 에이전트 작업 체류 시간이 길어졌다 단일 지시로 파일 여러 개를 연쇄 수정할 때 중간에 “다음 단계 확인해 드릴까요?” 같은 끊김이 줄었다. 4.6은 5~6 step에서 한 번씩 끊겼는데, 4.7은 10 step 이상을 한 번에 간다. 긴 리팩터링 작업에서 체감이 크다. 2. 코딩 벤치마크 점수 상승 Anthropic 공식 블로그의 차트 기준으로 SWE-bench Verified, Terminal-bench 모두 4.6보다 올랐다. 다만 이게 실사용 속도까지 보장하지는 않는다. 3. 반론에 더 단단해졌다 4.6은 “내 말이 맞다”고 밀면 바로 물러서는 경향이 있었다. 4.7은 근거를 다시 제시한다. 디버깅 대화에서 사람이 틀린 가정을 고집할 때 이 특성이 오히려 시간을 아낀다. Qwen 3.6-35B가 Opus 4.7을 이긴다고? 같은 날 Alibaba가 Qwen 3.6-35B-A3B(오픈소스)를 공개했다. Simon Willison이 자기 노트북에서 Qwen 3.6이 Opus 4.7보다 “더 나은 펠리컨 그림을 그렸다”는 글을 올려 HN 상위에 갔다. 이 결과를 어떻게 봐야 할까. 일부 작업에서는 오픈소스가 이긴다 — 이미지 생성, 특정 추론 과제 복잡한 에이전트·장문 코딩은 Opus 4.7이 여전히 우세 비용 관점 에서 오픈소스가 매력적이지만, API 없이 로컬 돌리려면 GPU 비용이 따로 든다 즉 “Opus 4.7 vs Qwen 3.6”은 “어느 게 ...
자세한 내용 보기

맥 스튜디오 M4 Max 128GB 로컬 LLM 4개 속도 비교 — gemma4·llama3.3·qwen3 실측

이미지
결론: M4 Max 128GB에서 가장 빠른 건 120B가 아니라 26B Dense 모델이다. 이유는 MoE 구조의 메모리 접근 패턴. 4개 모델 실측(tok/s 기준) + ChatGPT Plus 쿼터 제약 우회 대안 정리. 타이틀이 약속한 반전, 왜 생겼나 gpt-oss:120b 는 117B 파라미터짜리 MoE 구조. 총량은 117B지만 토큰 생성 한 번에 활성화되는 건 5.1B 정도. 이론적으로는 작은 모델만큼 빨라야 한다. 현실은 달랐다. MoE는 토큰마다 활성화되는 “전문가”가 바뀐다. 그래서 모델 전체(65GB)가 메모리에 상주해야 하고, 토큰마다 접근 위치가 비국소적(non-local)으로 흩어진다. 활성 파라미터 5.1B라는 숫자만 보면 훨씬 빨라야 맞다. 실제로 요구되는 메모리 대역폭은 전체 모델 크기에 가깝다는 얘기. 이 비교에서 직접 확인한 결과다. 반면 gemma4:26b 는 Dense 모델. 26B가 전부 계산에 참여한다. 파라미터 수 자체는 많지만 메모리 접근이 선형적이라 Apple Silicon의 통합 메모리 대역폭(546GB/s)을 효율적으로 쓸 수 있다. 같은 하드웨어에서 Dense가 MoE를 앞지르는 지점이 여기. 맥에서 로컬 LLM 고를 때 “MoE니까 활성 파라미터 작으면 빠르겠지” 하는 직관이 깨지는 순간. 테스트 환경 하드웨어는 Mac Studio M4 Max, 통합 메모리 128GB, 메모리 대역폭 546GB/s. 런타임은 Ollama 0.20.7 (llama.cpp 기반). 동일 프롬프트 3종 — 짧은 한국어, 짧은 수학, 긴 코드 생성. Cold start(첫 로드)와 Warm(모델 올라간 상태)을 분리 측정. 결과 4-way 비교표. 단위 tokens/second(tok/s). Prompt eval은 프롬프트 입력 처리 속도(초당 토큰 몇 개를 읽어들이는가), Generation은 응답 생성 속도(초당 토큰 몇 개를 출력하는가). 모델 크기(디스크) 활성 파라미터 Cold Load ...
자세한 내용 보기

Claude Code로 블로그 발행 15분을 1줄로 — 해고 후 첫 자동화 경험

Claude Code로 블로그 자동 발행 스크립트를 만드는 방법이다. 마크다운 파일을 터미널에서 명령어 한 줄로 Blogspot에 발행한다. Google Cloud Console 설정 10분, Claude Code에 지시 20분, 테스트 5분이면 끝난다. 코드를 직접 쓰지 않고 Claude Code에게 지시만 해서 만들었다. Claude Code가 뭔가 터미널에서 “블로그 발행 자동화해줘”라고 치면 스크립트를 만들어주는 AI 코딩 도구다. Anthropic이 만들었다. IDE 플러그인이 아니라 독립 CLI 도구다. 프로젝트 폴더 전체를 읽고, 파일을 직접 생성하고 수정하고 실행까지 한다. 블로그 글 1편 올리는 데 15분이 걸렸다 Blogspot에 글을 올리려면 마크다운 → HTML 변환 → Blogger 접속 → 제목 입력 → HTML 모드 전환 → 본문 붙여넣기 → 라벨 설정 → 검색 설명 → 미리보기 → 발행. 1편에 15분. 한 달에 30편이면 7시간 이상을 “올리는 작업”에만 쓰는 셈이다. 글 쓰는 시간보다 올리는 시간이 더 길었다. 이걸 Claude Code에게 맡겼다. Claude Code에게 한 지시 터미널에서 Claude Code를 열고 이렇게 말했다: “마크다운 파일을 Blogger API v3으로 자동 발행하는 Python 스크립트를 만들어줘. frontmatter에서 제목, 라벨, 슬러그를 읽고, 마크다운을 HTML로 변환한 뒤, OAuth 2.0으로 인증해서 Blogger에 POST해줘. dry-run 옵션도 넣어줘.” Claude Code가 만든 것: publish.py 메인 스크립트 (약 200줄) requirements.txt 의존성 목록 config.json 설정 파일 OAuth(구글 로그인 인증) 흐름 (최초 1회 브라우저 인증 → 이후 자동) dry-run 모드 (발행 없이 HTML 미리보기) ...
자세한 내용 보기