AI 에이전트가 만든 20개 PR을 소급 계측했더니

초안. git에 올라가지 않는다(.gitignore: /.harness/drafts/). 숫자는 전부 .harness/baseline.md에서 재현 가능하다.

요약 (이력서용 한 줄)

프롬프트 및 로깅 훅을 구축해 AI 에이전트 작업의 재연성 및 오류 원인 추적 가능성 향상

근거가 되는 사실:

• 과거 20개 PR을 소급 계측 → 파이프라인 생략 10건, 모델 provenance 오기록 18건 발견
• 로깅 훅 + 자동 스탬프 게이트 구축 → 커밋의 모델 표기가 처음으로 사실과 일치
• 훅 회귀 테스트 12개, 하네스 실행을 막지 않는 async 설계

1. 잘 돌아가는데, 무슨 일이 있었는지는 모른다

도서관 관리 프론트엔드를 Claude Code 하네스로 만들었다. 디자인 스펙을 주면 4개 전문 에이전트(스펙 해석 → 컴포넌트 설계 → 구현 → QA)가 차례로 일하고, 이슈·브랜치·커밋·PR까지 나온다. 다섯 주 동안 PR 20개, 소스 7,922줄.

문제는 끝나고 나면 아무것도 안 남는다는 것이었다.

정확히는, 남긴 하는데 결론만 남는다. 실행마다 _workspace/에 4개 문서를 쓰고 다음 실행이 시작될 때 타임스탬프를 붙여 밀어낸다. 그렇게 쌓인 게 17개 디렉터리, 87개 파일, 14,866줄. 소스 코드의 1.88배다.

그리고 한 번도 다시 읽지 않았다.

읽을 이유가 없었기 때문이다. 거기 있는 건 “무엇을 만들었나”이지 “어떻게 만들어졌나”가 아니다. 얼마나 걸렸는지, 몇 번 실패했는지, QA가 몇 바퀴 돌았는지, 어떤 에이전트가 실제로 돌았는지 — 하나도 없다.

증상은 다른 데서 먼저 나타났다. src/components/README.md가 계속 커졌다. 150줄, 29.9KB. 저장소에서 가장 많이 수정된 파일(21커밋) 이 됐는데, 2위인 실제 소스 파일(lib/api/loans.ts, 9커밋)의 2.3배다.

뜯어보니 원인이 분명했다.

표는 컴포넌트 수(12→48개)에 정확히 비례해 정상 작동했다. 서사만 문서화 대상보다 2.8배 빠르게 자랐다. 실행 과정에서 나온 판단 근거가 갈 곳이 없어서 유일한 지속 문서로 흘러든 것이다.