11-4. 하네스 엔지니어링과 도구 계층
한 줄 요약: 하네스를 에이전트의 런타임 기판으로 이해하고, 도구·권한·MCP·실행 표면·관측 가능성을 위험과 기능 기준으로 설계·개선할 수 있다.
학습 목표
- 하네스의 책임 목록(작업 명세, 컨텍스트 선택, 도구 접근, 메모리, 상태, 관측, 실패 귀인, 검증, 권한)을 설명할 수 있다.
- 에이전트 도구를 기능과 위험 기준으로 분류하고, 프로젝트에 맞는 도구 구성을 설계할 수 있다.
- MCP로 외부 시스템을 도구로 노출할 때 스키마·인증·최소 권한·감사 로그가 왜 필요한지 설명할 수 있다.
- 실행 표면(로컬 CLI, IDE, CI headless, 클라우드 샌드박스)별로 권한·관측·개입 가능성이 어떻게 달라지는지 판단할 수 있다.
- 프론트엔드 검증 도구(Playwright, DevTools, Storybook, Lighthouse)를 하네스에 연결하는 구성을 설계할 수 있다.
배경: 왜 이것이 존재하는가
11-1에서 에이전트를 모델-하네스-환경 시스템으로 분해했고, 같은 모델이 하네스에 따라 다른 결과를 낸다는 근거(Polar)도 봤다. 이 문서는 그 하네스를 열어 본다.
왜 개발자가 하네스 내부를 알아야 하는가? 하네스를 직접 만들 일은 드물지만, 구성할 일은 매일 있기 때문이다. 어떤 MCP 서버를 붙일지, 어떤 명령을 allowlist에 넣을지, 서브에이전트에 어떤 도구를 줄지, CI에서 headless로 돌릴지 — 이 결정들이 전부 하네스 구성이며, 결과 품질과 안전에 모델 선택만큼 영향을 준다. 비유하자면 JVM을 만들 일은 없어도 힙 크기와 GC 설정은 운영자가 하듯, 하네스의 동작 모델을 알아야 구성 결정에 근거가 생긴다.
역사적 맥락도 짚을 만하다. 에이전트 개선의 초기 접근은 프롬프트 수정에 집중했다. 그러나 프롬프트만으로는 도구가 없어서 못 하는 일, 권한이 없어서 못 보는 것, 피드백이 없어서 모르는 실패를 해결할 수 없다. 최근 흐름은 프롬프트·도구·미들웨어·메모리·검증·trace를 함께 개선하는 방향으로 이동했고, 이 활동에 하네스 엔지니어링(harness engineering)이라는 이름이 붙었다. AI Harness Engineering 연구는 하네스를 파운데이션 모델 에이전트의 런타임 기판(runtime substrate)으로 정의한다 — 모델이 저장소를 관찰하고, 도구를 호출하고, 피드백을 받아 다음 행동을 결정하게 하는 실행 환경 전체라는 뜻이다.
핵심 개념
하네스의 책임 목록
하네스가 지는 책임을 나열하면, 이 Phase의 문서들이 사실 하네스 책임의 항목별 해설이었음이 드러난다.
| 책임 | 내용 | 심화 문서 |
|---|---|---|
| 작업 명세(task specification) | 목표·제약·성공 조건을 받는 인터페이스 | 11-2 |
| 컨텍스트 선택(context selection) | 매 추론에 무엇을 보여 줄지 결정, 압축 포함 | 11-3 |
| 도구 접근(tool access) | 어떤 행동 수단을 어떤 스키마로 노출할지 | 이 문서 |
| 메모리(memory) | 세션을 넘는 지식의 저장과 회상 | 11-3 |
| 작업 상태(task state) | 진행 상황·계획·중간 산출물의 추적 | 이 문서 |
| 관측 가능성(observability) | 무엇을 읽고 실행했는지의 기록 | 11-5 |
| 실패 귀인(failure attribution) | 실패가 어느 계층에서 왔는지 구분 지원 | 11-5 |
| 검증(verification) | 결과 확인 수단의 제공과 강제 | 11-5 |
| 권한(permissions) | 행동별 허용·승인·차단의 경계 | 11-6 |
| 비결정성 관리 | 재시도, 체크포인트, 롤백 | 이 문서 |
| 사람 개입 기록 | 어디서 사람이 끼어들었는지의 추적 | 11-5 |
핵심 통찰: 이 책임들은 모델에게 맡길 수 없는 것들이다. 모델은 자신의 컨텍스트가 오염됐는지 모르고, 자신의 권한을 스스로 제한할 수 없으며, 자신의 보고가 사실인지 보증할 수 없다. 신뢰 경계 바깥의 구조가 필요하고, 그것이 하네스다. 백엔드로 치면 애플리케이션 코드에게 자기 자신의 rate limiting과 감사 로그를 맡기지 않고 인프라 계층에 두는 것과 같은 원리다.
도구 계층: 기능과 위험의 2축 분류
에이전트의 능력은 곧 도구 집합이다. Pi가 보여 주듯 Read/Write/Edit/Bash 네 개면 루프는 성립한다 — 그중에서도 Bash 하나가 사실상 만능이다(테스트 실행, git, 패키지 설치, curl까지). 그래서 도구 설계의 질문은 "무엇이 필요한가"보다 "만능 도구를 어떻게 분해하고 제한하는가"에 가깝다. 도구를 기능과 위험의 2축으로 분류하면:
| 도구 | 기능 | 주요 위험 | 기본 권한 권고 |
|---|---|---|---|
| 파일 읽기 | 관찰 | secret 파일 노출 | 허용 (secret 경로 제외) |
| 파일 쓰기/편집 | 변경 | 의도 밖 파일 수정 | workspace 내 허용, 밖 차단 |
| shell | 만능 | 파괴적 명령, 네트워크, 설치 스크립트 | 명령 패턴별 allowlist + 승인 |
| package manager | 의존성 | install script 실행, 공급망 | 승인 필요 |
| browser automation | UI 검증·조작 | 세션·쿠키 접근, 외부 사이트 행동 | 대상 도메인 제한 |
| screenshot/DevTools | 관찰 | 화면 내 민감 정보 | 허용 |
| MCP 커넥터 | 외부 시스템 | 커넥터별 상이(아래 절) | 도구별 개별 판단 |
| issue tracker / design tool | 맥락 공급 | 외부 데이터의 injection 경로 | 읽기 허용, 쓰기 승인 |
| log/monitoring | 운영 맥락 | PII 노출 | 읽기 허용 |
두 가지 설계 원칙이 이 표를 관통한다.
첫째, 관찰과 변경을 분리한다. 읽기 도구는 넓게, 쓰기 도구는 좁게. 11-2의 "탐색·계획은 읽기 전용 루프"가 하네스 수준에서는 도구 집합의 차등으로 구현된다.
둘째, 도구 정의는 프롬프트다. 11-1의 더 깊이에서 봤듯 도구의 이름·설명·파라미터 스키마는 모델이 읽는 텍스트다. 설명이 모호한 도구는 오용되고, 도구가 너무 많으면 선택 자체가 오류원이 되며 컨텍스트 예산도 잠식한다. MCP 서버를 붙일 때 도구 40개가 딸려 온다면, 그중 실제 쓰는 3개만 노출하는 것이 정확도와 예산 양쪽에 이득이다.
MCP: 도구 노출의 표준화와 그 대가
MCP(Model Context Protocol)는 외부 시스템을 에이전트의 도구·리소스로 노출하는 개방 프로토콜이다. 구조는 단순하다: MCP 서버가 도구 목록(이름, 설명, JSON Schema)과 실행 엔드포인트를 제공하고, 하네스(클라이언트)가 이를 모델의 도구 집합에 편입한다. 전송은 로컬 프로세스(stdio) 또는 원격(HTTP)이다. 표준화의 이득은 명확하다 — 커넥터를 하네스마다 다시 만들지 않아도 되고, issue tracker·디자인 도구·DB·사내 API가 균일한 방식으로 에이전트에 연결된다.
대가는 새로운 신뢰 경계다. MCP 서버를 붙인다는 것은 다음을 동시에 하는 것이다.
- 행동 공간 확장: 에이전트가 할 수 있는 일이 늘어난다. 그 일에는 실수로 할 수 있는 일도 포함된다.
- 컨텍스트 경로 확장: 도구가 반환하는 데이터가 컨텍스트에 들어온다. 외부 데이터는 prompt injection의 운반체가 될 수 있다(11-3의 신뢰 계층).
- 자격 증명 위임: 서버가 사용하는 토큰의 권한이 사실상 에이전트의 권한이 된다.
그래서 API를 에이전트 도구로 노출할 때의 체크리스트는 API 게이트웨이 설계와 닮는다.
- 스키마를 좁게: "임의 쿼리 실행"이 아니라 "이슈 검색", "이슈 코멘트 작성"처럼 의도 단위로. 넓은 도구는 모델의 오용도, 공격자의 악용도 쉽다.
- 최소 권한 인증: admin 토큰이 아니라 필요한 스코프만 가진 토큰. 쓰기가 필요 없으면 읽기 전용 토큰.
- rate limit과 비용 상한: 에이전트는 루프에서 같은 도구를 수십 번 호출할 수 있다.
- 파괴적 작업에 dry-run: 삭제·대량 변경 도구는 미리 보기 모드를 기본으로.
- 감사 로그: 누가(어느 세션이) 언제 무엇을 호출했는지. 사고 조사와 비용 귀인의 전제다.
작업 상태와 비결정성 관리
여러 루프에 걸친 작업에서 하네스는 상태를 관리해야 한다. 잘 만든 하네스가 제공하는 장치들:
- 계획·태스크 추적: 에이전트가 세운 계획을 구조화해 표시하고, 완료 여부를 추적한다. 사람의 개입 지점(계획 검토)을 UI로 만드는 장치이기도 하다.
- 체크포인트와 롤백: 편집 전 상태를 저장해 실패 시 되돌린다. Git 위에서 도는 에이전트에게는 커밋·worktree가 자연스러운 체크포인트다 — Phase 7에서 세운 "커밋은 되돌릴 수 있는 단위"라는 모델이 에이전트 운영에서 안전장치로 재등장한다.
- 재시도 정책: 비결정적 시스템에서 단순 재시도는 유효한 전략이지만, 같은 컨텍스트에서의 재시도는 같은 오류로 수렴하기 쉽다. 실패 원인을 요약해 컨텍스트를 재구성한 재시도가 더 효과적이다.
실행 표면: 같은 에이전트, 다른 위험
같은 하네스도 어디서 실행되느냐에 따라 권한·관측·개입 가능성이 다르다. 이 축을 놓치면 "로컬에서 안전했던 구성"이 무인 환경에서 사고가 된다.
| 실행 표면 | 사람 개입 | 격리 | 전형적 용도 | 하네스에 요구되는 것 |
|---|---|---|---|---|
| 로컬 CLI (대화형) | 실시간 승인 가능 | 낮음 (내 머신, 내 자격 증명) | 일상 개발 작업 | 승인 흐름, 명령 allowlist |
| IDE 통합 | 실시간, diff 뷰 중심 | 낮음 | 편집 중심 작업 | 편집 가시성, 부분 수락 |
| CI headless | 없음 (사후 검토만) | CI runner 격리 | 자동 리뷰, 반복 태스크 | 엄격한 allowlist, 산출물은 PR로만 |
| 클라우드 샌드박스 | 비동기 검토 | 높음 (전용 VM/컨테이너) | 병렬 위임, 신뢰 낮은 코드 | 네트워크 정책, 결과 반출 통제 |
핵심 규칙: 사람의 실시간 개입 가능성이 낮아질수록, 같은 안전 수준을 유지하기 위해 하네스의 사전 통제(샌드박스, allowlist, 검증 게이트)가 강해져야 한다. 대화형에서는 위험한 명령을 사람이 승인 단계에서 거르지만, headless에서는 거를 사람이 없으므로 애초에 실행 불가능해야 한다. 이는 운영에서 익숙한 원리다 — 수동 배포에서는 운영자가 최종 방어선이지만, 자동 배포에서는 파이프라인의 게이트가 그 역할을 대신해야 한다.
신뢰하지 않는 코드와의 조합도 이 축에서 판단한다. 낯선 오픈소스 저장소를 에이전트로 분석하는 작업은 로컬 CLI가 아니라 격리 샌드박스의 일이다. 저장소 안의 악성 지시문이나 install script가 로컬 자격 증명에 닿을 수 있기 때문이다(11-6).
프론트엔드 검증 도구를 하네스에 연결하기
프론트엔드 팀의 하네스 구성에서 가장 수익이 좋은 투자는 검증 도구 연결이다. 에이전트의 루프 품질은 피드백 신호의 품질이므로(11-1), 프론트엔드 고유의 신호를 루프 안으로 가져오는 것이 목표다.
- Playwright: e2e 테스트 실행 + 스크린샷·trace 생성. "브라우저에서 확인했다"를 기계 검증으로 바꾸는 1차 도구. 헤드리스 실행이 가능해 모든 표면에서 동작한다.
- 브라우저 조작 도구(browser automation): 하네스의 브라우저 도구 또는 브라우저 MCP로 에이전트가 직접 페이지를 열고, 조작하고, 콘솔·네트워크를 읽는다. 테스트로 굳히기 전의 탐색적 검증과 버그 재현에 유용하다.
- Storybook: 컴포넌트 상태를 URL 하나로 고립시켜 준다. "이 컴포넌트의 error 상태를 확인하라"가 앱 전체 플로우 재현 없이 가능해져 에이전트의 검증 비용이 급감한다. 스토리가 곧 기계가 소비 가능한 UI 상태 명세라는 점에서 11-3의 agent-ready 문서이기도 하다.
- visual regression: 스크린샷 비교로 의도치 않은 시각 변화를 잡는다. 에이전트의 리팩터링 작업에서 "동작 보존"의 시각 버전을 기계화한다.
- Lighthouse / axe: 성능·접근성 점수를 명령 한 줄의 숫자로 만든다. 에이전트가 자기 변경의 성능·접근성 영향을 루프 안에서 확인할 수 있게 된다.
- bundle analyzer: 번들 크기 변화를 수치로. "의존성 추가가 번들에 미친 영향 보고"를 성공 조건에 넣을 수 있게 한다.
연결 방식은 단순할수록 좋다. 대부분은 npm script(pnpm test:e2e, pnpm lighthouse)로 충분하며, 지시문에 명령과 해석 방법을 문서화하면 에이전트가 알아서 실행한다. MCP가 필요한 것은 구조화된 상호작용(브라우저 조작, DevTools 프로토콜 접근)이 필요한 경우다.
실무 관점
하네스 구성의 흔한 실수
- 도구 최대주의: 쓸 수 있는 MCP 서버를 다 붙인다. 결과는 도구 선택 오류 증가, 컨텍스트 예산 잠식, 공격 표면 확대다. 도구는 현재 작업 유형이 요구하는 최소로 시작해 필요할 때 추가한다.
- 권한 관성: 승인 프롬프트가 귀찮아 전체 자동 허용으로 바꾼다. 대화형 표면의 안전 모델은 사람의 승인을 전제하므로, 이 전환은 사실상 headless 위험을 대화형 편의로 감수하는 것이다. 올바른 해소는 전면 허용이 아니라 자주 쓰는 안전한 명령의 allowlist 등록이다.
- 검증 없는 자동화 확대: 로컬에서 잘 되니 CI 자동 실행으로 승격하면서, 로컬에서 사람이 하던 계획 검토·diff 리뷰의 대체물(자동 게이트)을 만들지 않는 것. 표면 이동은 통제의 재설계를 동반해야 한다.
- 하네스 개선의 감 의존: "이 지시문을 넣으니 좋아진 것 같다"에서 멈추는 것. 아래의 관측 기반 개선 루프로 대체한다.
하네스도 반복 개선의 대상이다
하네스 구성은 한 번의 설정이 아니라 지속 개선 대상이다. Agentic Harness Engineering 연구(참고 자료)는 이 개선을 관측 주도 루프로 정식화한다: 에이전트의 실행 trace를 관찰하고 → 반복되는 실패 패턴을 찾고 → 하네스 변경(도구 추가, 지시문 수정, 권한 조정)을 가설로 세우고 → 변경의 예측과 실제 결과를 비교한다. 팀 수준의 실천으로 번역하면:
- 에이전트 실행 리포트(11-5)를 쌓는다.
- 주기적으로 실패·재작업 사례를 모아 귀인한다: 명세 문제였나, 컨텍스트 부족이었나, 도구가 없었나, 권한이 막았나.
- 가장 잦은 원인 하나에 대한 하네스 변경을 하고, 같은 작업 유형에서 재발 여부를 본다.
"에이전트가 Storybook 상태를 확인 못 해 UI 버그를 놓친다"가 반복되면 Storybook 실행·스크린샷 도구를 연결하는 식이다. 이 루프는 11-5의 평가 세트와 결합할 때 완성된다.
얼마나 투자할 것인가
하네스 엔지니어링에도 수확 체감이 있다. 개인·소규모 팀의 실용 순서:
- 0단계 (필수): 저장소 지시문 + 검증 명령 문서화. 비용 반나절, 효과 즉시.
- 1단계: 명령 allowlist 정리, Playwright 연결, 작업 명세 템플릿. 비용 1~2일.
- 2단계: 반복 작업용 skill/커스텀 명령, 필요한 MCP 1~2개, 실행 리포트 관례화.
- 3단계 (팀 규모에서): CI headless 태스크, 평가 세트, 감사 로그 체계.
각 단계는 앞 단계의 실패 데이터가 정당화할 때 진행한다. 0단계 없이 3단계를 하는 것 — 지시문도 없는 저장소에 MCP를 다섯 개 붙이는 것 — 이 전형적인 역순 투자다.
더 깊이
하네스는 어디까지 개입해야 하는가: 미니멀리즘 논쟁
하네스 설계에는 긴장이 있다. 하네스가 많이 개입할수록(컨텍스트 자동 주입, 강제 워크플로, 구조화된 계획 단계) 평균 품질은 안정되지만, 모델의 능력이 오를수록 개입이 오히려 천장이 될 수 있다. Pi류 미니멀 하네스의 설계 철학은 "모델에게 최소 도구와 최대 자유를 주고, 확장은 사용자가 필요에 따라"이며, 제품형 하네스는 "안전과 UX를 위해 구조를 내장"하는 쪽이다. 어느 쪽이 옳은가는 모델 세대와 작업 위험도의 함수다 — 모델이 강해질수록 미니멀 쪽이, 작업이 위험할수록 구조 쪽이 유리해진다. 실무 함의: 하네스의 구조적 개입(강제 계획 단계, 자동 컨텍스트 주입)이 특정 모델 세대의 약점 보완이라면, 모델 업그레이드 시 그 개입이 여전히 순이득인지 재검토할 가치가 있다.
MCP의 프로토콜 구조
MCP를 조금 더 열어 보면, 서버가 노출하는 것은 도구(tools)만이 아니다. 리소스(resources: 모델이 읽을 수 있는 데이터 — 파일, 문서, 스키마)와 프롬프트(prompts: 재사용 가능한 지시 템플릿)도 있다. 도구가 "행동"이라면 리소스는 "컨텍스트 공급"이고 프롬프트는 "작업 명세 템플릿"이다 — 하네스 책임 목록의 세 항목이 프로토콜의 세 프리미티브로 대응된다. 인증은 원격 서버에서 OAuth 기반으로 표준화가 진행되어 왔으며, 로컬 stdio 서버는 프로세스 권한을 그대로 물려받는다는 점이 중요하다. 로컬 MCP 서버는 "내 계정 권한으로 도는 임의 코드"이므로, 서버 자체의 공급망(누가 만들었고 무엇을 실행하는가)이 검토 대상이다.
trace 수집 지점으로서의 model API boundary
Polar 연구의 방법론은 하네스 관측에 유용한 관점을 준다. 하네스 내부를 수정하지 않고 모델 API 경계 — 하네스가 모델에 보내는 요청과 응답 — 에서 trace를 수집하면, 어떤 하네스든 블랙박스로 관찰할 수 있다. 이 경계에는 모든 것이 지나간다: 시스템 지시문, 도구 정의, 컨텍스트 구성, 모델의 도구 호출 결정. 팀이 프록시 게이트웨이를 두고 이 경계를 기록하면 하네스·도구를 바꿔도 일관된 관측점이 유지되며, 비용 계측(토큰 사용량)과 감사(무엇이 외부 모델로 나갔는가)도 같은 지점에서 해결된다. LLM 게이트웨이가 API 게이트웨이의 지위를 얻어 가는 이유다.
정리
- 하네스는 모델이 관찰·행동·피드백 루프를 돌게 하는 런타임 기판이며, 작업 명세·컨텍스트·도구·메모리·상태·관측·귀인·검증·권한이라는, 모델 자신에게 맡길 수 없는 책임을 진다.
- 도구 설계의 축은 기능과 위험이다: 관찰 도구는 넓게, 변경 도구는 좁게, shell은 allowlist로 분해하고, 도구 정의 자체가 프롬프트임을 기억한다.
- MCP는 도구 노출을 표준화하지만 행동 공간·injection 경로·자격 증명 위임을 함께 확장하므로, 좁은 스키마·최소 권한 토큰·dry-run·감사 로그를 기본으로 한다.
- 실행 표면이 무인화될수록(CI headless, 클라우드) 사람의 실시간 개입이 사라지므로 샌드박스·allowlist·검증 게이트가 하네스의 책임으로 이동한다.
- 하네스 구성은 실행 trace와 실패 귀인에 근거해 반복 개선하는 대상이며, 투자 순서는 지시문·검증 명령 → allowlist·Playwright → skill·MCC → CI·평가 세트다.
확인 문제
- 팀이 디자인 도구·이슈 트래커·사내 DB·Slack·클라우드 콘솔까지 MCP 서버 5개를 모든 개발자의 에이전트에 기본 연결하기로 했다. 이 결정의 비용과 위험을 하네스 관점에서 분석하고 대안을 제시하라.
정답과 해설
비용·위험: ① 컨텍스트 예산 — 서버 5개의 도구 수십 개 정의가 매 세션 고정 지출이 되고, 도구 선택 오류율이 올라간다. ② 공격 표면 — 이슈 트래커·Slack이 반환하는 외부 텍스트는 prompt injection 운반체가 될 수 있고, 그 순간 에이전트가 가진 나머지 도구(DB, 클라우드 콘솔)가 공격의 실행 수단이 된다. 넓은 도구 집합은 injection의 피해 반경을 곱으로 키운다. ③ 자격 증명 — 각 서버 토큰의 권한 합집합이 에이전트 권한이 된다. 클라우드 콘솔 쓰기 권한이 있다면 파괴적 행동이 가능해진다. 대안: 작업 유형별 프로파일로 분리(프론트엔드 구현 작업에는 디자인 도구+이슈 트래커 읽기만), 각 서버는 최소 스코프 토큰으로, 쓰기 도구는 승인 필수로, DB·클라우드처럼 위험한 것은 기본 미연결로 두고 필요한 세션에만 명시적으로 연결한다.
- 로컬 대화형에서 잘 동작하던 "dependency 업데이트 검토 에이전트"를 매일 밤 CI에서 자동 실행하도록 옮기려 한다. 표면 이동으로 무엇이 달라지며, 하네스에 어떤 통제를 추가해야 하는가?
정답과 해설
달라지는 것: 사람의 실시간 개입이 사라진다. 로컬에서는 에이전트가 pnpm install(install script 실행 위험)이나 예상 밖 명령을 실행하려 할 때 사람이 승인 단계에서 걸렀지만, headless에서는 거를 사람이 없다. 또한 관측이 사후적이 되므로 실행 기록이 없으면 사고 조사가 불가능하다. 추가할 통제: ① 격리 — CI runner 안에서도 네트워크는 레지스트리 등 필요 대상만 허용, secret은 주입하지 않거나 읽기 전용 최소로. ② allowlist — 실행 가능 명령을 명시적 목록으로 제한하고 그 외는 실행 불가(승인 대기가 아니라 차단). ③ install script 통제 — --ignore-scripts 기본, 필요 패키지만 예외. ④ 산출물 경로 제한 — 직접 push가 아니라 PR 생성까지만 허용하고 병합은 사람이. ⑤ 실행 로그·도구 호출 기록을 아티팩트로 보존. 원칙: 대화형에서 사람이 하던 통제 각각에 대해 기계적 대체물을 만들고 나서 무인화한다.
- 에이전트가 UI 변경 작업에서 "테스트 통과"만 확인하고 실제 화면이 깨진 것을 놓치는 일이 반복된다. 관측 주도 하네스 개선 루프를 적용해 이 문제를 해결하는 과정을 설계하라.
정답과 해설
① 관측: 실행 리포트에서 실패 사례들을 모아 귀인한다 — 에이전트가 실행한 검증 명령 목록을 보면 jsdom 기반 단위 테스트만 있고 실제 렌더링 확인이 없다. 이는 모델의 추론 실패가 아니라 하네스의 검증 수단 부재다. ② 가설과 변경: "브라우저 수준 피드백 신호를 루프에 넣으면 놓침이 줄 것이다" — Playwright를 연결하고(pnpm test:e2e, 스크린샷 생성 포함), 작업 명세 템플릿의 UI 작업 성공 조건에 "관련 화면 스크린샷 첨부"를 추가하고, 지시문에 명령을 문서화한다. 컴포넌트 단위 확인이 잦으면 Storybook + 스크린샷으로 검증 비용을 더 낮춘다. ③ 예측-결과 비교: 같은 유형의 UI 작업 몇 건에서 화면 깨짐 놓침이 재발하는지, 에이전트가 스스로 스크린샷을 찍어 확인하는지 리포트로 확인한다. 재발하면 성공 조건 강제(스크린샷 없으면 미완료)나 visual regression 도입으로 강화한다.
참고 자료
- AI Harness Engineering: A Runtime Substrate for Foundation-Model Software Agents (arXiv:2605.13357) — 하네스의 책임 목록(명세·컨텍스트·도구·메모리·상태·관측·귀인·검증·권한)의 1차 출처.
- Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses (arXiv:2604.25850) — trace 관측 → 변경 → 예측-결과 비교의 하네스 개선 루프.
- Polar: Agentic RL on Any Harness at Scale (arXiv:2605.24220) — model API boundary에서의 trace 수집 관점과 하네스별 성능 차이의 근거.
- Model Context Protocol 공식 문서 — tools/resources/prompts 프리미티브, transport, 인증·보안 모델.
- Pi — Read/Write/Edit/Bash 코어 + extension·skill 확장이라는 미니멀 하네스 설계의 실물.
- Playwright, Lighthouse, Storybook — 프론트엔드 검증 신호를 하네스 루프에 공급하는 1차 도구들.