하네스 엔지니어링 측정 2편 — Claude에 AGENTS.md 명시 인용했더니 fail-fast가 강해졌다

하네스 엔지니어링 측정 2편 — Claude AGENTS.md 명시 인용 결과

1편(어제)에서 N=1로 측정해서 결론을 냈다. “Codex가 fail-fast 약하다”가 아니라 “AGENTS.md 비우면 Codex도 Claude도 똑같이 약하다”였다.

지적이 들어왔다. N=1은 우연일 수 있다. Claude에 AGENTS.md 명시 인용을 직접 해본 적은 없었다.

12회 측정해서 다시 확인했다. 결론은 더 단단해졌다. 그리고 1편이 놓친 변수 하나가 새로 보였다.

요약: Codex × Claude × 하네스 0/강제 4 condition을 각 3회씩 12회 측정. 모델 효과는 거의 0(가로축 1.0 vs 1.0, 2.83 vs 2.5), 하네스 효과는 큼(세로축 1.0 → 2.5+). Claude도 AGENTS.md를 prompt에 명시 인용하면 fail-fast 1.0 → 2.5로 올라간다. 단 1편의 Claude 채점 “중”은 prompt position 효과(메인 세션 system prompt 자동 로드)였을 가능성이 새로 보였다.

1편이 명시한 5가지 한계 중 통제한 3가지

측정 1편 본문 끝에 한계 5가지를 적었다. 그 중 2편에서 통제 가능한 것은 3가지였다.

  • Sampling 우연 미통제 (N=1) → 12회 측정으로 분산 확인
  • Prompt position 미분리 → C3 격리 환경 추가로 부분 분리
  • Claude에 AGENTS.md 명시 인용 미측정 → C4 condition으로 직접 측정

나머지 2가지(컨벤션 vs 코드 품질, 일반화)는 이번에도 미해소다.

측정 setup, 4 condition × 3회 = 12회

같은 명세 verify_published_post()를 4 condition으로 각 3회씩 측정했다.

Condition 모델 하네스
C1 Codex 없음 (AGENTS.md 비움)
C2 Codex AGENTS.md 자동 로드
C3 Claude spec만, 격리 Task agent
C4 Claude AGENTS.md prompt에 명시 인용

C1·C2는 1편 setup 그대로다. C3·C4는 후보 B의 핵심 비교축이다.

C3는 1편의 Claude condition을 격리 환경으로 다시 측정한 셈이다. 1편에서는 메인 세션에서 작성됐을 가능성이 있어 prompt position 효과가 섞였을 수 있다.

C4는 처음 측정한다. AGENTS.md 내용을 Claude prompt에 직접 포함시켰다.

결과, 2×2 매트릭스

12회 raw 결과를 fail-fast 1=약, 2=중, 3=강 척도로 채점했다.

모델 \ 하네스 0 (없음) 강제 (있음)
Codex 1.0 (v1) 2.83 (v2)
Claude 1.0 (C3) 2.5 (C4)

가로축(모델 비교)을 보면 거의 차이가 없다. 1.0 vs 1.0, 2.83 vs 2.5.

세로축(하네스 비교)은 1.0에서 2.5~2.83으로 뛴다.

모델 효과보다 하네스 효과가 크다. 1편 결론이 12회 데이터로 강화됐다.

후보 B 핵심 발견, Claude도 명시 인용으로 강해진다

C3(Claude, spec만)은 3회 모두 fail-fast 약.

# C3 전형 패턴
actual_title = post.get("title", "")
actual_content = post.get("content", "")

silent default 2건. 타입 검증 0건.

C4(Claude, AGENTS.md 명시 인용)는 3회 평균 중-강.

# C4 run 3 패턴
if "title" not in fetched:
    raise KeyError(f"Blogger API response missing 'title' field for post_id={post_id}")
if "content" not in fetched:
    raise KeyError(...)

if actual_content is None:
    raise KeyError(f"Blogger API returned content=None for post_id={post_id}")

명시 KeyError raise 3건. None silent 변환 거부.

같은 모델, 같은 명세, 다른 prompt. AGENTS.md를 prompt에 명시 인용하면 Claude의 fail-fast가 1.0에서 2.5로 올라간다.

이게 1편 결론 “차이는 모델이 아니라 하네스”의 직접 입증이다.

새 발견, 1편 Claude 측정엔 prompt position 효과가 섞여 있었다

C3 (격리 Task agent, spec만) 결과가 1편 Claude condition(채점 “중”)보다 약하게 나왔다.

1편 Claude 측정은 메인 세션에서 작성됐을 가능성이 있다. 메인 세션에는 글로벌 CLAUDE.md가 system prompt로 자동 로드되어 있다.

격리 Task agent에는 그게 없다. spec만 받으면 fail-fast 약(1.0).

즉 1편의 “CLAUDE.md 자동 로드 → 중” 결과는 CLAUDE.md 내용 자체가 아니라 system prompt 위치 효과로 보인다.

이 경우 1편의 “약→중→강” 분포는 사실 “0 / system 위치 / user 위치”의 prompt position 차이로 해석된다.

물론 단정은 어렵다. C3 격리 환경이 1편 Claude 환경과 정확히 같은지 검증 안 됐다. 다음 측정에서 prompt position을 변수로 분리해야 한다.

Sampling 분산, 한계 #1 부분 해소

12회 측정으로 condition별 분산을 봤다.

Condition 평균 분산
C1 (Codex 하네스 0) 1.0 0
C2 (Codex 자동 로드) 2.83 0.06
C3 (Claude 격리 spec만) 1.0 0
C4 (Claude 명시 인용) 2.5 0.25

하네스 0인 condition은 분산 0. 일관되게 약하다.

하네스 강제 condition은 분산 발생. C4가 가장 큼(0.25).

명시 인용 prompt도 sampling 영향 받는다. 단 평균은 안정적이라 결론 자체는 흔들리지 않는다.

N=1이 우연이었을 가능성은 12회로 통제됐다. 단 condition당 N=3은 통계 검증선(보통 N=9+)에 못 미친다. 평균은 안정적이지만 신뢰구간을 그릴 수 없다.

강해짐 ≠ 좋아짐

이 글에서 fail-fast 1.0 → 2.5를 “강해졌다”로 표현한다. 단 이게 production 코드 품질 향상이라는 보증은 어디에도 없다.

채점은 내 컨벤션 기준이다. fail-fast 강도가 무조건 좋다는 전제부터가 도메인마다 다르다.

UI 코드에서 모든 None을 raise로 처리하면 사용자 경험이 깨진다. 데이터 파이프라인에서 silent default는 다음 단계 오염을 만든다. 같은 fail-fast 패턴이 한쪽에선 좋고 한쪽에선 나쁘다.

이 글의 측정은 “AGENTS.md prompt가 모델의 fail-fast 패턴을 일치시킨다”까지만 보여준다. 그 일치가 코드 품질 향상인지는 외부 평가자(다른 시니어 개발자)가 블라인드 채점해야 보증된다. 측정 3편 후보다.

미해소 한계

  1. 컨벤션 vs 코드 품질: 여전히 내 컨벤션 기준. 외부 시니어 개발자 블라인드 채점 미도입.
  2. 일반화: task 1건(verify_published_post)에 한정. 다른 task 5건+ 누적해야 패턴 일반화 가능.
  3. Prompt position 정확 분리: C3·C4 비교로 가능성을 봤지만, 위치와 강제 강도를 동시에 통제한 측정은 없다.
  4. N=3 통계 약점: condition당 측정 횟수가 통계 검증선에 못 미친다.

이 4가지가 측정 3편 후보다.

메타, 이 글도 비교 프레임이다

이 글은 Codex와 Claude를 비교한다. “벤더 비교 프레임이 한계가 있다”고 말하는 글이 비교 프레임을 쓴다.

자기 모순이 아닌 메타 비판으로 작동하려면 두 가지가 명시돼야 한다.

첫째, 이 비교는 “어느 모델이 더 강한가”가 아니라 “모델 차이 vs 하네스 차이의 크기 비교”다. 결론은 후자가 크다는 것.

둘째, 이 결론은 내 setup의 통제 가능 변수만 다룬다. 채점축(내 컨벤션), task(1건), N(3회) 모두 한정적이다.

벤더 비교 글을 쓰거나 읽기 전에 본인 setup이 동등한지, 채점축이 명시적인지 봐야 한다. 측정 시리즈가 그걸 강제한다.

raw 데이터

같은 gist에 측정 2편 raw 파일 12개를 추가했다. 1편과 2편을 직접 비교 가능하다.

자주 묻는 질문

Q. Claude에 AGENTS.md를 명시 인용하면 fail-fast가 강해지는가?
A. 12회 측정 결과 fail-fast 점수가 1.0(spec만)에서 2.5(AGENTS.md 명시 인용)로 올라갔다. 같은 모델, 같은 명세, 다른 prompt 조건이다.

Q. Codex가 Claude보다 fail-fast 약한가?
A. 12회 측정 결과 모델 차이는 거의 없다. Codex 하네스 0 = 1.0, Claude 하네스 0 = 1.0. Codex AGENTS.md 자동 로드 = 2.83, Claude AGENTS.md 명시 인용 = 2.5. 차이는 하네스에서 나온다.

Q. 측정 1편의 한계는 어떤 것이 해소됐는가?
A. Sampling 우연(N=1) 한계는 12회 측정으로 부분 해소됐다. Claude 명시 인용 미측정은 C4 condition으로 직접 측정해 해소됐다. 컨벤션 vs 품질, 일반화 한계는 미해소.

Q. 1편 측정에서 새로 발견된 변수는?
A. Claude 격리 Task agent는 spec만 받으면 fail-fast 약(1.0)으로 채점된다. 1편의 Claude 측정 “중” 결과는 메인 세션 system prompt 자동 로드 효과가 섞였을 가능성이 있다. prompt position이 fail-fast 강도에 영향을 줄 수 있다.

Q. fail-fast 강해짐이 코드 품질 향상인가?
A. 이 측정만으로는 보증되지 않는다. 채점은 내 컨벤션 기준이다. fail-fast 강도가 production 코드 품질 향상인지는 외부 시니어 개발자 블라인드 채점이 필요하다. 측정 3편 후보다.

관련 글

갱신일: 2026-05-07
저자: Jason — 인프라 운영 8년, AI 자동화 도구 직접 개발해 사용 중. 측정으로 검증하는 글 위주.

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

댓글

댓글 쓰기

이 블로그의 인기 게시물

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 미리보기) ...
자세한 내용 보기