STEP 01
채팅 인터페이스를 버리고 Agent로 간다
진지한 코딩에서는 대화창만으로 부족하다고 본다. 그의 최소 Agent 정의는 LLM에 외부 행동 루프가 붙어 파일을 읽고, 프로그램을 실행하고, HTTP 요청을 보낼 수 있는 상태다.
01
대규모 시스템이 아니라 개인 개발자의 손에서 출발한 방법
원문은 OpenAI가 큰 팀의 체계적 방법을 대표한다면, Mitchell Hashimoto는 개인 개발자의 소박한 지혜를 대표한다고 대비한다. 그가 Harness Engineering을 설명하는 방식은 조직도보다 작업대에 가깝다.
Who is Mitchell?
인프라를 선언으로 바꿔 온 사람
HashiCorp 공동 창업자이며 Terraform, Vagrant, Packer의 창작자로 소개된다. HashiCorp를 떠난 뒤에는 Zig로 터미널 에뮬레이터 Ghostty를 처음부터 만들고 있다고 원문은 설명한다.
스스로를 “만드는 행위 자체를 좋아하는 software craftsman”으로 묘사하며,
원문은 그가 AI 회사의 지분을 보유하지 않는다는 점도 함께 언급한다.
2026 · 02 · 05
AI 경험을 말하기 전에, 글은 직접 썼다고 먼저 밝힌다
「My AI Adoption Journey」의 첫 문단에서 그는 이 글이 자신의 손과 자신의 말로 쓰였다고 명시한다. 원문은 이 선언 자체를 2026년의 업계 분위기를 보여주는 장면으로 읽는다.
Terraform
Vagrant
Packer
Ghostty
Zig
Infrastructure as Code
이 장의 출발점은 AI 낙관론도 비관론도 아니다.
의심하면서 사용하고, 사용하면서 경계를 측정하는 태도다.
Harness는 믿음의 결과가 아니라 반복된 검증의 결과로 만들어진다.
02
여섯 단계 AI 채택 프레임워크
Mitchell의 경로는 “써보니 좋았다 → 바로 위임했다”는 흐름과 다르다. 특히 두 번째 단계에서 이미 자신이 끝낸 일을 Agent에게 다시 시키는 비효율을 감수한다. 목적은 시간을 아끼는 것이 아니라 Agent의 실제 능력 경계를 몸으로 배우는 것이다.
STEP 02
자기 일을 Agent에게 다시 시킨다
이미 손으로 끝낸 작업을 Agent에게 다시 수행시킨다. 원문이 강조하는 가장 고통스럽고 중요한 단계다. 절약이 아니라 관찰을 위해 같은 일을 두 번 한다.
이 단계가 이후의 위임과 Harness 설계에 필요한 행동 모델을 만든다.
STEP 03
퇴근 전 마지막 30분을 Agent에게 준다
자신이 자리를 비운 뒤에도 조금씩 진척될 수 있도록 하루의 마지막 시간을 Agent 실행에 사용한다.
STEP 04
‘이길 수 있는 일’부터 외주화한다
Agent의 능력에 대한 신뢰가 쌓인 뒤 성공 확률이 높은 일을 위임한다. 동시에 데스크톱 알림은 끈다. 컨텍스트 전환 비용이 너무 크기 때문이다.
STEP 05
Harness를 공학화한다
실제 실패를 규칙과 도구로 고정하는 단계다. 원문은 이 지점을 Harness Engineering이라는 개념의 핵심 기원으로 본다.
STEP 06
Agent를 항상 실행 상태로 둔다
백그라운드에서 늘 Agent가 일을 처리하게 한다. Mitchell은 빠른 응답보다 느리더라도 품질이 높은 모델을 선호하며 30분 이상의 처리 시간도 받아들인다고 원문은 설명한다.
사람이 먼저 수행
정답과 작업 과정을 이미 알고 있다
→
Agent에게 다시 수행시킴
결과보다 실패 패턴과 능력 경계를 관찰한다
대부분은 1단계에서 4단계로 뛰어간다.
Mitchell은 2단계의 ‘쓸모없어 보이는 일’을 오래 한다.
효율을 늦추는 시간이 나중의 자동화를 안전하게 만드는 지식이 된다.
03
핵심 방법론 — 실패가 규칙을 호출한다
Mitchell의 정의는 매우 짧다. Agent가 실수한 것을 발견하면 같은 실수가 다시 일어나지 않도록 지속 가능한 해결책을 공학화한다.
Agent의 실수
→
원인 관찰
→
영구 해결책
→
미래 실행 전체에 적용
Trigger-driven
미리 상상하지 않는다. 실제 오류가 규칙을 만든다.
Engineered
Prompt를 조금 고치는 데서 끝내지 않고 지속 가능한 장치로 만든다.
Cumulative
한 번의 개선이 이후 모든 Agent 실행에 복리처럼 작동한다.
규칙 파일 — AGENTS.md
나쁜 행동을 발견할 때마다 무엇을 하지 말아야 하는지, 또는 어떤 프로젝트 고유 절차를 따라야 하는지 규칙으로 남긴다.
- 행동을 설명한다
- 프로젝트 지식을 남긴다
- Agent가 읽고 판단하게 한다
프로그래밍된 도구 — 물리적으로 틀릴 수 없게
스크린샷 도구, 필터 테스트, 검증 메커니즘 같은 보조 도구를 만들어 잘못된 선택 자체를 어렵거나 불가능하게 만든다.
- 행동을 강제한다
- 검증을 자동화한다
- 규칙 파일의 권고를 프로그램 수준의 경계로 바꾼다
한쪽은 말이고 다른 한쪽은 울타리다.
규칙은 방향을 알려주고, 도구는 경계를 실제로 만든다.
Harness는 두 층이 함께 있을 때 더 단단해진다.
04
Ghostty의 AGENTS.md — 실패가 쌓여 문서가 된 살아 있는 표본
원문은 Ghostty 저장소의 실제 파일을 Harness가 자라나는 방식의 사례로 든다. 평범해 보이는 각 줄은 Agent가 실제로 밟았던 함정을 뒤늦게 봉합한 결과다.
ghostty/
├── AGENTS.md # build, test, structure, formatting
├── inspector/
│ └── AGENTS.md # C API, imgui demo, macOS flags
└── .agents/commands/
└── gh-issue # Nu script
루트 규칙 파일이 담는 것
zig build, zig build test 같은 빌드 명령,
디렉터리 구조, 포맷 규칙이 들어간다.
특히 전체 테스트가 느리므로 -Dtest-filter로 대상 테스트를 실행하라고 알려주는 식으로,
Agent가 코드만 보고는 알기 어려운 프로젝트 고유의 시행착오가 규칙이 된다.
Issue / PR 직접 생성 금지
원문은 위반 요청 시 일부러 우스꽝스러운 자기비하 문구가 담긴 파일을 diff에 만들도록 하는 장난스러운 방어 규칙까지 소개한다. 목적은 파괴적 행동을 규칙 단계에서 막는 데 있다.
Inspector 전용 AGENTS.md
C API 참조 위치, imgui demo 사용법, macOS 특수 빌드 flag, “이 패키지에는 단위 테스트가 없다”는 정보까지 하위 시스템에 맞게 더 구체적으로 적는다.
/gh-issue 명령
Nu script가 GitHub issue를 Markdown으로 가져와 진단, 근본 원인 설명, 해결책 제안을 돕는다. 단 직접 코드를 쓰지는 못하게 막는다. 원문은 Mitchell이 하루 5회 이상 사용한다고 설명한다.
이 사례의 핵심은 유머가 아니다.
실제로 일어난 위험한 행동을 규칙으로 기억하고 다음 실행의 선택지에서 제거하는 ‘방지 장치’다.
규칙 파일은 정적 문서가 아니다
원문은 Mitchell의 설명을 인용해 파일의 각 줄이 나쁜 Agent 행동에 기반하고, 그 규칙들이 대부분의 문제를 거의 해결했다고 전한다. 파일은 한 번 완성되는 문서가 아니라 상호작용을 통해 계속 자라는 공학 산출물이다.
05
이해하지 못한 코드는 내보내지 않는다
AI에 많은 일을 맡기더라도 Mitchell의 경계는 분명하다. 구현을 Agent가 채우더라도 구조와 데이터 흐름과 상태 관리에 대한 이해와 책임은 사람이 가진다.
Software Architect + Bowling with Bumpers
자신의 역할을 software architect로 두고, 코드 구조·데이터 흐름·상태 관리를 설계한 뒤 세부 구현을 Agent에게 맡긴다. 원문의 비유는 ‘가드레일이 있는 볼링’이다. 레인을 잘 만들면 공을 던지는 방식이 조금 달라도 홈통으로 빠지지 않는다.
Agent가 잘하는 일과 약한 일
강점 · Refactoring
원문은 Agent의 리팩터링 능력을 거의 완벽하다고 평가한다.
강점 · Fill-in Coding
주어진 구조 안에서 구현 세부를 채우는 작업.
강점 · Rapid UI Prototype
빠른 UI 프로토타이핑.
약점 · High-level Architecture
상위 수준의 구조 결정.
약점 · Performance-oriented Data Structure
성능 중심 데이터 구조 설계.
약점 · Zig Support
원문은 Zig 지원이 약하다고 보고 Rust/Python으로 먼저 작성시킨 뒤 사람이 Zig로 옮기는 우회법을 소개한다.
≈50%
AI 사용 공개 PR
Ghostty가 AI 사용 여부 공개를 의무화한 뒤 약 절반의 PR에서 AI 사용을 밝힌 것으로 서술된다.
6mo
AI 이전 문제 PR 간격
원문은 문제가 있는 PR이 대략 6개월에 한 번 수준이었다고 설명한다.
2wk
AI 이후 문제 PR 간격
AI 이후에는 약 2주에 한 번으로 늘어 커뮤니티 신뢰가 ‘기본 신뢰’에서 ‘기본 거절’로 바뀌었다고 서술한다.
리뷰어가 보고 싶은 것은 AI의 답변이 아니다.
원문에서 Mitchell은 AI 출력 자체를 잡음으로 보고,
기여자가 왜 그렇게 판단했는지 자신의 사고를 보여주기를 요구한다.
Agent가 코드를 대신 쓸수록 사람에게 남는 것은 이해와 책임이다.
생성의 출처보다 중요한 것은 그 결과를 설명하고 판단할 사람이 있는가다.
06
왜 이처럼 단순한 방법이 강한가
원문은 Mitchell과 OpenAI의 공통점을 한 문장으로 묶는다. 두 팀 모두 완벽한 Harness를 먼저 설계하지 않았다. 실제 사용에서 실패를 만나고, 그 실패를 반복해서 구조로 바꾸었다.
OpenAI — 조직적 축적
다섯 원칙은 5개월의 실험에서 나왔다. 관측성, 아키텍처 계층, Garbage Collection 같은 대규모 팀의 장치가 함께 성장했다.
Mitchell — 개인적 축적
Ghostty의 AGENTS.md는 Agent와의 수많은 충돌에서 자랐다.
복잡한 인프라 없이도 실제 실패를 기록하는 규율만으로 개인화된 Harness를 만들 수 있다.
빈 파일에서 시작
미래의 실패를 미리 상상해 규칙을 채우지 않는다.
실패를 기다린다
실제 Agent 행동이 무엇을 보완해야 하는지 알려준다.
한 줄 또는 한 도구 추가
같은 실패가 반복되지 않도록 영구 장치로 만든다.
시간이 지나면 Harness가 된다
원문은 약 3개월 뒤 그 파일 자체가 자신의 환경에 맞춘 Harness가 된다고 설명한다.
Simon Willison 공유
Pragmatic Engineer 심층 보도
Martin Fowler 팀 프레임워크 확장
누구나 즉시 시작할 수 있는 단순성
실패를 미리 상상하지 말고, 실제로 드러난 구멍을 영구히 막는다
7장의 마지막 권고는 이것이다. 파일이 길어지는 것 자체를 두려워하기보다, 실제로 겪은 실패가 다시 일어나지 않도록 규칙을 축적한다. 원문은 그 축적을 개인의 ‘해자’가 깊어지는 것으로 표현한다.
복잡한 방법은 전문가만 따라 할 수 있지만,
“실수하면 하나를 고친다”는 규율은 누구나 오늘 시작할 수 있다.
단순함이 약한 것이 아니라, 지속할 수 있기 때문에 강하다.
실수는 실패의 기록이기도 하지만
다음 실패를 막을 수 있는 재료이기도 하다.
한 번의 잘못을 한 줄의 규칙으로 바꾸고,
한 줄의 규칙을 다음 작업의 경계로 바꾼다.
그렇게 쌓인 Harness는 거창한 설계도가 아니다.
사람이 Agent와 부딪히며 남긴 관계의 역사다.
완벽하게 시작하는 것보다
같은 실수를 두 번 하지 않는 것이 더 강한 공학이다.
이 웹페이지는 첨부 문서 《Harness Engineering》의 §07
「Mitchell Hashimoto：每次犯错加一条规则 / Mitchell Hashimoto: One Mistake, One Rule」
(PDF 33–37쪽)에만 근거해 재구성했다.
38쪽에서 §08이 시작되는 것을 확인해 7장의 범위를 분리했다.
원문의 인물 소개, 여섯 단계 채택 프레임워크, 실수 기반 방법론,
Ghostty의 AGENTS.md와 명령 구조, 코드 이해 원칙, AI 사용 공개 정책,
OpenAI와의 비교 및 마지막 권고를 원문 맥락 안에서 보존했으며 외부 자료를 이용한 검증·정정·확장은 수행하지 않았다.