하네스 엔지니어링: 런타임을 설계하기

2026년의 소프트웨어 엔지니어는 마구(馬具)를 만든다

올해 상반기, 소프트웨어 엔지니어링의 무게중심이 조용히 옮겨갔다. 무엇을 물어볼 것인가(프롬프트)도, 무엇을 보여줄 것인가(컨텍스트)도 아니다. 에이전트가 살아가는 환경 전체를 어떻게 설계할 것인가. 업계는 이것을 하네스 엔지니어링이라 부르기 시작했다.

모델은 그대로인데 점수가 18%p 벌어졌다

논쟁을 줄이는 가장 빠른 방법은 숫자다. Terminal-Bench 2.0 리더보드에는 2026년 2월 5일 같은 날 기록된 Claude Opus 4.6 결과가 여러 줄 올라와 있다. 모델은 동일하다. 벤치마크도 동일하다. 다른 것은 그 모델을 감싼 하네스뿐이다.

Meta-Harness에서 76.4%, Capy 75.3%, Droid 69.9%, Terminus 2 62.9%, 그리고 Claude Code 58.0%. 최고와 최저의 격차가 18.4%p다. 모델 세대 하나를 통째로 건너뛰는 크기의 차이가, 가중치를 한 비트도 바꾸지 않고 발생한다. 직전 세대인 Opus 4.5에서도 같은 현상이 있었다. Droid 63.1% 대 Claude Code 52.1%, 11.0%p 격차다.

이 숫자가 말하는 바는 단순하다. "우리 에이전트가 잘 못한다"는 문장에서 주어는 대개 모델이 아니다. 모델은 아마 괜찮다. 문제는 그 모델을 어떤 루프에, 어떤 도구와 함께, 어떤 검증 장치를 붙여 돌렸는가에 있다. 벤치마크 순위표를 볼 때 모델 이름만 읽고 에이전트 열을 읽지 않는 습관은, 이제 통계적으로 틀린 독법이다.

이 용어의 기원은?

용어의 계보는 놀랄 만큼 최근이다. 2026년 2월 5일, HashiCorp 공동창업자이자 Ghostty 터미널의 개발자인 미첼 하시모토가 자신의 AI 도입기를 정리하며 이렇게 썼다. "업계에서 널리 받아들여진 용어가 있는지 모르겠지만, 나는 이것을 하네스 엔지니어링이라고 부르게 됐다. 에이전트가 실수하는 것을 발견할 때마다, 그 실수를 다시는 하지 않도록 해결책을 엔지니어링하는 것이다."

그가 제시한 방법은 두 가지뿐이었다. 첫째, 암묵적 프롬프트를 개선하는 것. 즉 AGENTS.md를 고치는 것. 그는 Ghostty 저장소의 AGENTS.md를 예로 들며 "그 파일의 각 줄은 에이전트의 나쁜 행동 하나에 기반한다"고 적었다. 둘째, 실제로 프로그램된 도구를 만드는 것. 스크린샷을 찍는 스크립트, 필터링된 테스트를 돌리는 스크립트 같은 것들이다.

엿새 뒤인 2월 11일, OpenAI가 훨씬 극단적인 사례를 공개했다. 그리고 4월 2일, 마틴 파울러의 사이트에 비르기타 뵈켈러가 이 개념을 제어 이론의 언어로 재구성한 정식 아티클을 올렸다. 같은 시기 LangChain은 한 문장으로 정의를 못 박았다. Agent = Model + Harness. 모델이 아니면 전부 하네스다.

세 시대를 한 줄로 요약하면 이렇다. 프롬프트 엔지니어링은 무엇을 묻는지를 설계했고, 컨텍스트 엔지니어링은 모델이 무엇을 보는지를 설계했으며, 하네스 엔지니어링은 실행과 안전과 통제를 포함한 런타임 전체를 설계한다. 앞의 둘은 뒤의 하나에 포함된다.

가이드, 센서, 그리고 나머지 네 층

하네스를 구체적으로 뜯어보면 대략 여섯 개 층이 나온다.

가이드는 행동 이전에 개입한다. AGENTS.md, 룰 파일, 스킬, 설계 문서, 도메인 용어집. 센서는 행동 이후에 개입한다. 린터, 타입체커, 테스트, 검증 스크립트, LLM-as-judge. 이 둘이 조종 루프를 만든다.

에이전트 루프는 계획, 실행, 검증, 수정의 순환이다. 여기서 중요한 것은 순환 그 자체가 아니라 경계 조건이다. 재시도를 몇 번까지 허용할 것인가, 예산을 얼마나 쓰면 멈출 것인가, 어떤 판단이 필요할 때 사람에게 올릴 것인가.

메모리는 상태를 컨텍스트 창 바깥으로 꺼낸다. 진행 상황 파일, 실행 계획, 의사결정 로그, 그리고 git. 권한은 자율성의 반경을 그린다. 도구 예산, 쓰기 범위, 승인 게이트, 샌드박스. 관측 가능성은 하네스 자신을 디버깅 가능하게 만든다. 툴 호출 트레이스, 비용과 재시도 추적, 이상 상황에서 끊어지는 트립 와이어.

여기서 흔한 오해 하나를 짚고 넘어가자. 하네스는 프롬프트 파일의 다른 이름이 아니다. LangChain의 정의를 따르면 시스템 프롬프트, 도구와 MCP, 파일시스템과 샌드박스와 브라우저 같은 번들 인프라, 서브에이전트 스폰과 모델 라우팅 같은 오케스트레이션 로직, 컴팩션과 린트 체크를 강제하는 훅과 미들웨어가 전부 하네스다. 마크다운 파일 한 장은 그중 가장 싸고 가장 잘 썩는 부품일 뿐이다.

앞에서 막을 것인가, 뒤에서 잡을 것인가

뵈켈러의 기여는 이 난잡한 목록에 제어 이론의 축을 그은 것이다. 축은 두 개다.

첫 번째 축은 시간이다. 가이드는 피드포워드 제어다. 에이전트가 행동하기 전에 개입해서 첫 시도에 옳을 확률을 높인다. 센서는 피드백 제어다. 행동한 뒤에 관측해서 스스로 교정하게 만든다. 두 번째 축은 실행 방식이다. 계산적 통제는 CPU가 돌리는 결정적 장치로, 밀리초에서 초 단위로 끝나고 결과를 신뢰할 수 있다. 추론적 통제는 GPU가 돌리는 확률적 장치로, 느리고 비싸고 비결정적이지만 의미적 판단을 한다.

이 2x2에서 가장 중요한 규칙은 비대칭성이다. 피드백만 있는 에이전트는 같은 실수를 영원히 반복한다. 피드포워드만 있는 에이전트는 자기 규칙이 먹혔는지 영원히 모른다. 두 축을 함께 채워야 루프가 닫힌다.

그리고 센서에는 한 가지 트릭이 있다. 에러 메시지를 사람이 아니라 LLM이 읽는다고 가정하고 다시 쓰는 것이다. "console.log 대신 logger.info({event: 'name', ...data})를 사용하세요"처럼 수정 방법까지 담은 린트 메시지는, 사실상 실패 시점에 정확히 주입되는 프롬프트다. 뵈켈러는 이것을 "좋은 종류의 프롬프트 인젝션"이라고 표현했다.

파울러의 글이 제어 이론을 끌어온 데는 이유가 있다. 하네스는 사이버네틱 거버너, 즉 조속기처럼 작동한다. 제임스 와트의 원심 조속기는 증기기관이 빨라지면 추가 벌어지고, 벌어진 추가 밸브를 닫아 속도를 떨어뜨린다. 목표를 설정하는 것은 사람이고, 매 순간 밸브를 조작하는 것은 기계다. 하네스도 똑같다. 사람의 일은 밸브를 직접 잡는 것이 아니라 조속기를 설계하고 개선하는 것이다.

원심 조속기(ca. 1788). 목표는 사람이, 매 순간의 교정은 기계가 한다. Photo: Andy Dingley, CC BY 3.0, via Wikimedia Commons

사람이 코드를 한 줄도 쓰지 않은 저장소

가장 극단적인 데이터 포인트는 OpenAI에서 나왔다. 2026년 2월 11일, 기술 스태프 라이언 로포폴로가 공개한 필드 리포트다.

한 팀이 5개월 동안 사람이 코드를 단 한 줄도 손으로 쓰지 않고 제품의 내부 베타를 만들어 출시했다. 애플리케이션 로직, 테스트, CI 설정, 문서, 관측 가능성, 내부 툴링까지 모든 줄을 Codex가 썼다. 결과는 약 100만 줄, PR 약 1,500건. 엔지니어 3명으로 시작해 7명으로 늘어나는 동안 처리량은 오히려 늘었고, 1인당 하루 평균 3.5개의 PR을 열고 병합했다. 팀의 추정으로는 수작업 대비 약 10분의 1의 시간이 들었다.

여기서 배울 것은 숫자가 아니라 그들이 겪은 실패다.

첫째, 거대한 AGENTS.md는 실패한다. 팀은 "하나의 큰 AGENTS.md" 접근을 시도했다가 예측 가능한 방식으로 깨졌다고 적었다. 컨텍스트는 희소 자원이라 거대한 지침 파일이 정작 코드와 작업을 밀어냈고, 모든 것이 중요하다고 적힌 문서에서는 아무것도 중요하지 않았으며, 획일적인 매뉴얼은 "낡은 규칙들의 무덤"이 되었다. 그래서 그들은 AGENTS.md를 백과사전이 아니라 목차로 취급했다. 컨텍스트에 삽입되는 파일은 약 100줄이고, 실제 지식은 구조화된 docs/ 디렉터리에 산다. 설계 문서, 실행 계획, 제품 스펙, 참조 문서가 각각 색인을 갖고, 전용 린터와 CI 작업이 이 지식 베이스의 신선도와 상호 링크를 기계적으로 검증한다.

둘째, 문서만으로는 일관성이 유지되지 않는다. 그들은 각 비즈니스 도메인을 Types에서 Config, Repo, Service, Runtime, UI로 흐르는 고정된 레이어로 나누고, 인증이나 텔레메트리 같은 횡단 관심사는 Providers라는 단 하나의 명시적 인터페이스로만 들어오게 했다. 그리고 이 규칙을 문서가 아니라 Codex가 직접 만든 커스텀 린터와 구조 테스트로 강제했다. 커스텀 린트이기 때문에 에러 메시지를 자신들이 작성했고, 그 메시지에 수정 지침을 담아 에이전트 컨텍스트에 주입했다. 그들의 표현은 정확하다. "문서화가 부족한 경우 규칙을 코드로 승격한다."

셋째, 에이전트가 읽지 못하는 지식은 존재하지 않는 지식이다. 슬랙 스레드에서 합의한 아키텍처 패턴은, 에이전트가 검색할 수 없다면 3개월 뒤 입사한 신입이 모르는 것과 똑같이 시스템에 존재하지 않는다. 그래서 그들은 코드베이스를 사람이 아니라 에이전트의 가독성에 최적화했다. 워크트리별로 앱을 부팅하게 만들고, Chrome DevTools Protocol을 에이전트 런타임에 연결해 DOM 스냅샷과 스크린샷을 찍는 스킬을 만들었으며, 워크트리마다 임시 관측 스택을 띄워 LogQL로 로그를, PromQL로 메트릭을 쿼리하게 했다. 그러자 "서비스 시작을 800ms 안에 끝내라" 같은 프롬프트가 실행 가능해졌다.

넷째, 자율성은 엔트로피를 만든다. Codex는 저장소에 이미 있는 패턴을 복제한다. 최적이 아닌 패턴까지 복제한다. 초기에 팀은 매주 금요일, 즉 주당 20%의 시간을 "AI 슬로프" 청소에 썼다. 당연히 확장되지 않았다. 대신 그들은 정기적으로 편차를 검사하고 리팩터링 PR을 여는 백그라운드 작업을 돌렸다. 대부분 1분 안에 리뷰되고 자동 병합된다. 그들의 비유가 좋다. 기술 부채는 고금리 대출이므로 한꺼번에 고통스럽게 갚는 것보다 매일 조금씩 갚는 편이 낫다. 가비지 컬렉션이다.

스트라이프는 어디까지를 코드로 못 박았나

스트라이프의 "미니언" 사례는 다른 각도를 보여준다. 2026년 2월에 공개된 이 사내 코딩 에이전트는 주당 1,000건 이상의 PR을 병합한다. 코드는 사람이 리뷰하지만 처음부터 끝까지 미니언이 쓴다.

주목할 부분은 블루프린트라는 개념이다. 미니언의 실행 경로는 순수한 에이전트 루프가 아니라, LLM 호출이 아예 없는 결정적 노드("설정된 린터 실행", "변경사항 푸시")와 에이전트 노드("작업 구현", "CI 실패 수정")를 코드로 엮은 워크플로다. 무엇을 모델의 판단에 맡기고 무엇을 코드로 못 박을지를 명시적으로 나눈 설계다.

또 하나는 피드백을 왼쪽으로 밀기다. CI에서 실패할 것이 확실한 검사는 CI까지 기다리지 않고 IDE와 pre-push 단계에서 잡는다. 백그라운드 데몬이 린트 규칙 휴리스틱을 미리 계산해 캐시해 두기 때문에 푸시 시점의 린트 수정은 대개 1초 안에 끝난다. 미니언은 푸시 전에 이 루프를 로컬에서 돌린다. 브랜치가 첫 시도에 CI를 통과할 확률을 올리기 위해서다. 여기에 400개가 넘는 내부 MCP 도구와 300만 개가 넘는 기존 테스트가 피드백 소스로 깔려 있다.

매일 기억을 잃는 팀을 굴리는 법

앤트로픽의 장기 실행 에이전트 연구는 또 다른 실패 모드를 다룬다. 컨텍스트 창을 여러 번 넘나드는 작업에서 에이전트는 매 세션마다 기억을 잃는다. 교대할 때마다 이전 교대의 기억이 삭제되는 엔지니어 팀을 상상하면 된다.

그들의 해법은 두 개의 에이전트다. 초기화 에이전트가 첫 실행에서 환경을 세팅한다. 개발 서버를 띄우는 init.sh, 진행 상황을 적는 progress 파일, 그리고 기능 목록을 담은 JSON 파일. 이후 코딩 에이전트는 매 세션 한 번에 하나의 기능만 붙잡고, 끝날 때 반드시 git 커밋과 진행 요약을 남겨 다음 세션이 깨끗한 상태에서 시작하게 한다.

디테일이 흥미롭다. 기능 목록을 마크다운이 아니라 JSON으로 둔 이유는, 실험 결과 모델이 마크다운보다 JSON 파일을 부적절하게 고쳐 쓸 확률이 낮았기 때문이다. 그리고 "테스트를 지우거나 수정하는 것은 용납할 수 없다"는 식의 강한 어조가 실제로 필요했다. 이것은 프롬프트 엔지니어링이 아니라 포맷 선택이라는 하네스 결정이다.

정리하면 그들이 잡은 실패 모드는 넷이다. 프로젝트 전체를 너무 일찍 완료 선언하는 것, 버그와 미기록 진행 상태를 남기고 세션을 끝내는 것, 제대로 검증하지 않고 기능을 완료로 표시하는 것, 앱 실행 방법을 매번 다시 알아내느라 토큰을 태우는 것. 넷 다 모델을 바꿔서 푼 게 아니라 환경을 바꿔서 풀었다.

하네스도 배신한다

여기까지만 읽으면 하네스를 두껍게 쌓을수록 좋다는 결론이 나올 것 같다. 그렇지 않다. 반대 방향의 증거도 분명히 있다.

컨텍스트 자체가 비용이다. 앤트로픽의 컨텍스트 엔지니어링 원칙은 "원하는 결과의 확률을 최대화하는, 가능한 가장 작은 고신호 토큰 집합"을 찾으라고 말한다. 하네스를 쌓는 행위는 대개 토큰을 더 넣는 행위이므로, 이 원칙과 정면으로 충돌할 수 있다. 실제로 HumanLayer 팀은 변경마다 전체 테스트 스위트를 돌렸다가 통과한 4,000줄이 컨텍스트 창을 뒤덮어 방금 읽은 파일에 대해 환각을 일으키는 현상을 겪었고, 실패만 노출하는 방식으로 바꿔 해결했다. 센서를 붙이는 것과 센서 출력을 그대로 보여주는 것은 전혀 다른 문제다.

가이드는 지시대로 지켜지지 않는다. 뵈켈러는 센서 후속 실험에서, AGENTS.md나 스킬로 "센서를 정기적으로 확인하라"고 지시하는 방식이 "상당히 불안정했다"고 적었다. 에이전트가 왜 센서 검사를 건너뛰었는지, 왜 린트나 테스트를 직접 실행해 버렸는지를 "정말 여러 번" 물어야 했다고 한다. 결국 그는 마크다운 지시 대신 커스텀 사이드카 CLI와 도구 통합으로 강제하는 쪽으로 옮겨갔다. 교훈은 명확하다. 마크다운에 적힌 규칙은 제안이고, 훅과 도구에 박힌 규칙이 제약이다.

하네스는 모델에 과적합될 수 있다. 오늘의 코딩 에이전트는 모델과 하네스를 함께 두고 사후 훈련된다. 그래서 파일 편집 방식 하나만 바꿔도 성능이 떨어지는 현상이 관측된다. 충분히 지능적인 모델이라면 패치 방식 정도는 갈아탈 수 있어야 하는데, 하네스를 끼고 훈련한 결과 그 하네스에 최적화되어 버린 것이다. 이는 하네스 설계가 곧 락인 설계가 될 수 있다는 뜻이기도 하다.

행동 하네스는 여전히 미해결이다. 유지보수성 하네스는 기존 도구가 많아 상대적으로 쉽다. 아키텍처 적합성 하네스도 피트니스 함수라는 선례가 있다. 그러나 "이 애플리케이션이 기능적으로 원하는 대로 동작하는가"를 검증하는 하네스는, 현재로선 AI가 생성한 테스트 스위트가 초록불인지 확인하는 수준에 머문다. AI가 쓴 인수 테스트는 커버리지를 올리지만 단언이 빈약한 경우가 많아, 뮤테이션 테스트 같은 장치 없이는 초록불이 곧 신뢰가 되지 않는다.

벤치마크 비교 자체가 흔들린다. 하네스를 공개하지 않은 에이전트 비교는 의미가 없다는 문제 제기도 나왔다. 2026년 5월 발표된 한 논문은 모델을 고정한 채 하네스만 바꿔 Terminal-Bench 2 점수가 69.7%에서 77.0%로 움직인 사례, 표준화된 스캐폴드에서 45.9%를 받은 모델이 다른 하네스에서는 55.4%를 받은 사례, 검색 서브에이전트 하나를 추가하자 두 모델의 순위가 뒤집힌 사례를 함께 제시한다. 다만 반대 방향의 관측도 있다. Terminal-Bench 논문 자체는 모델 교체가 스캐폴드 교체보다 큰 효과를 낸 비교도 함께 보고한다. 즉 하네스가 항상 모델보다 중요하다는 명제는 과장이고, 정확한 명제는 "하네스를 명시하지 않은 성능 수치는 해석 불가능하다"에 가깝다.

그리고 근본적인 질문 하나. 센서가 한 번도 울리지 않는다면, 그것은 품질이 높다는 뜻인가 아니면 탐지가 부실하다는 뜻인가. 테스트 커버리지와 뮤테이션 테스트가 테스트에 대해 해주는 일을, 아직 우리는 하네스에 대해 하지 못한다.

하네스를 걸 수 없는 코드베이스도 있다

파울러의 글에서 실무적으로 가장 아픈 대목은 harnessability, 즉 하네스 가능성이다.

강타입 언어로 쓰인 코드베이스는 타입체커라는 센서를 공짜로 얻는다. 모듈 경계가 명확한 코드베이스는 아키텍처 제약 규칙을 걸 수 있다. 반대로 이런 성질이 없는 코드베이스에서는 애초에 그 통제 장치를 만들 수가 없다. 그린필드 팀은 첫날의 기술 선택으로 통치 가능성을 결정한다. 문제는 레거시다. 하네스가 가장 필요한 곳에서 하네스를 짓기가 가장 어렵다.

OpenAI 팀이 "지루한 기술"을 선호하고, 범용 라이브러리를 가져오는 대신 동시성 헬퍼를 직접 구현한 것도 같은 맥락이다. 불투명한 업스트림 동작에 맞춰 추론하는 것보다, 에이전트가 저장소 안에서 전부 읽고 검증할 수 있는 코드를 두는 편이 쌌기 때문이다. 의존성 선택 기준에 "에이전트가 이것을 모델링할 수 있는가"라는 항목이 추가된 셈이다.

파울러는 여기서 한 걸음 더 나간다. 대부분의 기업은 API로 데이터를 노출하는 비즈니스 서비스, 이벤트 처리 서비스, 데이터 대시보드처럼 몇 개의 반복되는 서비스 유형이 전체의 80%를 차지한다. 이미 서비스 템플릿으로 성문화된 그 유형들이, 앞으로는 하네스 템플릿으로 진화할 수 있다는 것이다. 특정 기술 스택과 구조에 맞춰진 가이드와 센서 묶음을 통째로 상속받는 그림이다. 그렇게 되면 기술 선택의 기준 자체가 바뀐다. 이 스택을 고르는 이유가 "이미 쓸 만한 하네스가 있어서"가 되는 날이 온다.

Nouveau Larousse illustré(1898)의 마구 부품 도해. 하네스는 힘을 없애는 장치가 아니라 방향을 주는 장치다. Public Domain, via Wikimedia Commons

그래서 뭘 하면 되나?

지금까지의 사례를 실행 순서로 압축하면 이렇다.

1) 실패 로그를 남긴다. 하네스 엔지니어링의 출발점은 도구가 아니라 관찰이다. 에이전트가 같은 실수를 두 번 하면 그때가 하네스를 고칠 시점이다. 하시모토의 규율이 정확히 이것이다.

2) 가장 싼 통제부터 채운다. 순서는 대체로 계산적 센서, 계산적 가이드, 추론적 가이드, 추론적 센서다. 타입체커와 린터가 잡을 수 있는 것을 LLM 리뷰어에게 맡기는 것은 돈과 지연시간의 낭비다.

3) 에러 메시지를 다시 쓴다. 커스텀 린트를 만들었다면 메시지에 수정 방법을 넣는다. 센서 하나를 프롬프트 하나로 승격시키는 가장 값싼 방법이다.

4) AGENTS.md를 목차로 축소한다. 100줄 안팎으로 줄이고 나머지는 색인된 문서로 옮긴 뒤, 그 문서의 신선도를 CI로 검사한다. 지침 파일은 관리되지 않는 순간 부채가 된다.

5) 상태를 파일로 꺼낸다. 진행 요약, 기능 목록, 실행 계획, 의사결정 로그. 세션이 끊겨도 다음 세션이 이어받을 수 있어야 한다. git 커밋은 그 자체로 롤백 가능한 메모리다.

6) 피드백을 왼쪽으로 민다. CI에서 확실히 실패할 검사는 pre-push로, pre-push에서 잡을 수 있는 것은 에이전트 루프 안으로 당긴다.

7) 하네스 자체를 관측한다. 어떤 센서가 얼마나 자주 울리는지, 어떤 가이드가 무시되는지, 토큰과 비용이 어디서 새는지를 보지 못하면 하네스 개선은 감에 의존한다.

안티패턴도 함께 적어둔다. 지침 파일을 무한히 늘리는 것, 통과한 테스트 로그를 전부 컨텍스트에 붓는 것, 역할극 서브에이전트("프론트엔드 엔지니어", "백엔드 엔지니어")를 만드는 것. 서브에이전트의 진짜 가치는 역할 분담이 아니라 컨텍스트 격리, 즉 방화벽이다. 수만 토큰을 태워 탐색한 뒤 1,000~2,000 토큰의 요약만 부모에게 돌려주는 구조 말이다.

그래도 사람은 남는다

파울러 글의 마지막 문단이 이 논의의 윤리적 중심이다. 사람 개발자는 모든 코드베이스에 암묵적 하네스를 들고 온다. 300줄짜리 함수를 보면 느끼는 미적 거부감, "우리는 그렇게 안 한다"는 직관, 커밋에 내 이름이 박힌다는 사회적 책임감. 에이전트에게는 이 중 아무것도 없다. 어떤 관습이 하중을 견디는 기둥이고 어떤 관습이 그냥 습관인지 구분하지 못한다.

하네스는 그 암묵지를 외화하려는 시도다. 그리고 그 시도는 끝까지 갈 수 없다. 좋은 하네스의 목표는 사람의 개입을 없애는 것이 아니라, 사람의 개입이 가장 값진 곳으로 그것을 몰아주는 것이다.

OpenAI 팀의 결론도 같은 자리에 도착한다. "소프트웨어를 만드는 데는 여전히 규율이 필요하지만, 그 규율은 코드보다 스캐폴딩에서 더 많이 드러난다. 우리의 가장 어려운 과제는 이제 환경, 피드백 루프, 통제 시스템을 설계하는 일이다."

18.4%p는 그 문장의 다른 표현이다. 모델은 이미 충분히 똑똑할지 모른다. 우리가 아직 충분히 좋은 마구를 만들지 못했을 뿐이다.

---

검증 메모 (원문 출처 및 확인 상태)

직접 확인한 1차 출처

• 하시모토, "My AI Adoption Journey", 2026-02-05. https://mitchellh.com/writing/my-ai-adoption-journey

• OpenAI, Ryan Lopopolo, "Harness Engineering", 2026-02-11. 5개월/100만 줄/1,500 PR/1인당 3.5 PR/AGENTS.md 약 100줄 목차/Types→Config→Repo→Service→Runtime→UI/금요일 20% 정리→백그라운드 GC. https://openai.com/index/harness-engineering/

• Martin Fowler(집필 Birgitta Boeckeler), "Harness engineering for coding agent users", 2026-04-02(초기 메모 2026-02-17). https://martinfowler.com/articles/harness-engineering.html

• LangChain, "The Anatomy of an Agent Harness". https://blog.langchain.com/the-anatomy-of-an-agent-harness/

• Anthropic, "Effective harnesses for long-running agents". https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

• Terminal-Bench 2.0 리더보드, 2026-08-31 직접 조회. https://www.tbench.ai/leaderboard/terminal-bench/2.0

• Stripe, "Minions", 2026-02-09. "주당 1,000건 이상 PR 병합" 확인. https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents