goldtag

기본 설정을 의심하라 — 모델과 하네스의 과적합이 당신의 에이전트를 느리게 만든다 이 시리즈의 3편에서 흥미로운 사실을 언급했다. Terminal Bench 2.0에서 Claude Opus 4.6은 Claude Code — 자신이 훈련된 하네스 — 안에서 33위였지만, 다른 하네스에서는 5위권으로 올라갔다. 이 숫자가 의미하는 바를 제대로 소화하지 않고 넘어갔다. 4편에서 Anthropic의 아키텍처를, 5편에서 실전 가이드를 다루면서, 가장 반직관적이고 실전적으로 중요한 인사이트를 놓쳤다. 기본 하네스를 그대로 쓰는 것이 최적이 아닐 수 있다. 이 글에서 그 이야기를 마무리한다. 과적합은 어떻게 발생하는가 프론티어 코딩 모델은 자신의 하네스 안에서 후훈련(post-training)된다. Claude는 Claude Code 환경에서, Codex 모델은 Codex 환경에서 수천 시간의 코딩 작업을 수행하며 최적화된다. 이 과정에서 모델은 특정 하네스의 패턴에 적응한다. Claude Code가 도구를 호출하는 방식 에러를 반환하는 형식 컨텍스트를 구성하는 순서 파일 편집 도구의 인터페이스 모델은 이 특정 환경에서의 성능을 극대화하도록 훈련된다. 문제는 극대화가 일반화를 보장하지 않는다 는 것이다. 머신러닝에서 과적합(overfitting)이란, 훈련 데이터에 너무 잘 맞춰져서 새로운 데이터에 대한 성능이 오히려 저하되는 현상이다. 모델-하네스 관계에서도 같은 일이 일어난다. 모델이 기본 하네스의 특이점(quirk)에까지 적응하면서, 다른 구성에서의 잠재력이 묻힌다. 구체적 사례: Codex와 apply_patch OpenAI의 Codex 모델이 apply_patch 라는 파일 편집 도구에 극도로 결합된 사례가 있다. Codex 모델을 다른 하네스(OpenCode)에서 사용하려 했을 때, 별도의 apply_patch 도구를 추가해야 했다. 모델이 그 특정 도구 인터페이스 없이는 파일 편집을 제대로 수행하지 못했기 때문이다. 모델이...

하네스 엔지니어링 활용편 — 내 프로젝트에 당장 적용하는 법 개념을 이해했고(3편), Anthropic의 구현을 살펴봤다(4편). 이제 남은 질문은 하나다. 내 프로젝트에 어떻게 적용하는가? 이 글에서는 하네스 엔지니어링을 실무에 활용하는 구체적인 방법과, 이 패러다임이 가져올 개발자 역할의 변화를 다룬다. 원칙 1: 실패에서 시작하라 Mitchell Hashimoto의 원칙이자, HumanLayer 팀이 독립적으로 같은 결론에 도달한 것. 이상적인 하네스를 미리 설계하려 하지 마라. 에이전트가 실패할 때마다, 그 실패를 구조적으로 방지하는 장치를 추가하라. HumanLayer 팀의 표현: "출하 편향을 가져라. 에이전트가 실제로 실패한 경우에만 하네스를 건드려라." 이것은 TDD(Test-Driven Development)의 사고방식과 닮아 있다. 실패하는 테스트를 먼저 만들고, 그것을 통과시키는 코드를 작성하는 것처럼 — 에이전트가 실패하는 패턴을 관찰하고, 그것을 방지하는 하네스 요소를 추가한다. ETH Zurich의 연구가 이 원칙을 뒷받침한다. 138개 에이전트 설정 파일을 테스트한 결과: LLM이 생성한 설정 파일: 성능 저하 + 비용 20% 이상 증가 사람이 작성한 설정 파일: 겨우 4% 개선 코드베이스 개요, 디렉터리 목록: 아무 도움도 안 됨 에이전트는 저장소 구조를 스스로 충분히 탐색한다. 보편적으로 적용되는 최소한의 지침만 투입하면 된다. 원칙 2: 적게 넣어라 하네스 엔지니어링에서 가장 반직관적인 원칙이다. 더 많은 규칙, 더 많은 도구, 더 많은 에이전트가 항상 더 나은 결과를 만들지 않는다. Vercel의 사례: 초기에 모든 도구를 제공했지만, 도구를 줄이자 오히려 성능이 향상됐다. MCP 서버를 많이 연결하면? 도구 정의 자체가 시스템 프롬프트의 토큰을 소비한다. 200K 컨텍스트 윈도우가 MCP 도구가 너무 많으면 실제로는 70K밖에 안 될 수 있다. HumanLayer의 해...

하네스 엔지니어링 적용편 — Anthropic은 AI 에이전트를 어떻게 설계했나 이전 글에서 하네스 엔지니어링의 개념과 구성 요소를 다뤘다. 이번에는 실전이다. Anthropic이 공식 엔지니어링 블로그에서 공개한 구체적인 아키텍처 패턴들과, OpenAI Codex 팀의 실험 결과를 바탕으로 하네스가 실제로 어떻게 적용되는지 살펴본다. 에이전트 루프의 기본 구조: Inner Loop 모든 AI 에이전트의 심장에는 에이전트 루프(Agent Loop) 가 있다. Claude Code에서는 이것을 queryLoop 라고 부른다. 본질적으로 while(true) 루프다. while (true) { 1. 컨텍스트 준비 (계획 모드 첨부파일, 작업 리마인더) 2. 모델 호출 (스트리밍 API 호출) 3. 도구 실행 (도구 호출 감지 → 스키마 검증 → 권한 확인 → 실행) 4. 계속 결정 (모델이 더 할 일이 있는가?) } 각 반복이 하나의 "사고 → 행동 → 관찰" 사이클이다. 모델이 생각하고, 도구를 호출하고, 결과를 관찰하고, 다시 생각한다. 도구 실행 흐름 은 이렇다: 모델이 출력에서 도구 호출을 생성 하네스가 도구 호출을 감지하고 텍스트 생성을 중지 입력을 스키마(Zod 검증 JSON Schema)에 대해 검증 권한 파이프라인 실행 (일반 규칙 → 도구별 체크 → 자동 분류기 → 사용자 승인 폴백) 도구 핸들러가 작업 실행 결과가 모델의 컨텍스트에 다시 주입 루프 계속 이것이 Inner Loop다. 대부분의 간단한 작업은 이 루프 안에서 완료된다. 하지만 복잡한 작업, 특히 여러 시간이 걸리는 장기 실행 작업에서는 이것만으로 부족하다. 컨텍스트 윈도우가 가득 차고, 모델의 추론 능력이 저하된다. Outer Loop: Ralph Loop 패턴 Anthropic이 장기 실행 작업을 위해 개발한 것이 Ralph Loop 패턴이다. 아이디어는 단순하다. 모델이 작업을 끝내려고 할...

하네스 엔지니어링이란 무엇인가 — AI 에이전트의 고삐를 설계하는 시대 이 시리즈의 1편에서 프롬프트 엔지니어링의 퇴장을 이야기했다. CLI 기반 도구가 등장하면서 정교한 프롬프트를 수작업으로 다듬는 행위의 가치가 줄어들고 있다고. 그런데 2026년 들어, 프롬프트 엔지니어링을 대체한 것이 단순히 "더 나은 도구"가 아니라는 걸 깨닫게 됐다. 프롬프트 엔지니어링 → 컨텍스트 엔지니어링 → 그리고 지금, 하네스 엔지니어링 이라는 완전히 새로운 패러다임이 자리잡고 있다. 이 글에서는 하네스 엔지니어링이 무엇인지, 왜 지금 이것이 중요한지, 그리고 어떤 구성 요소로 이루어져 있는지를 다룬다. 말에게 씌우는 마구, 에이전트에게 씌우는 하네스 하네스(Harness)는 원래 말에게 장착하는 마구를 뜻한다. 고삐, 안장, 등자 — 말의 강력한 힘을 억누르는 것이 아니라, 올바른 방향으로 전달하기 위한 장비다. AI에서 하네스는 정확히 같은 의미다. AI 에이전트의 강력한 능력을 올바른 방향으로 제어하고 전달하는 외부 시스템 전체. 공식으로 쓰면 이렇다. Agent = Model + Harness 모델이 아닌 모든 것이 하네스다. 시스템 프롬프트, 도구 정의, 샌드박스 환경, 오케스트레이션 로직, 피드백 루프, 메모리 관리, 미들웨어 훅. 에이전트를 감싸는 이 모든 것을 설계하는 행위가 하네스 엔지니어링이다. 왜 모델만으로는 부족한가 LLM은 본질적으로 이런 한계를 가진다. 세션 간 상태를 유지하지 못한다 코드를 직접 실행하지 못한다 실시간 정보에 접근하지 못한다 자기가 만든 결과물을 스스로 검증하지 못한다 ChatGPT와의 "대화"도 사실 기본적인 하네스의 산물이다. 이전 메시지를 추적하고, while 루프를 돌리는 것. 그 자체가 원시적인 하네스다. Anthropic은 이 한계를 직접 경험했다. Claude Opus 4.5에게 "claude.ai의 클론을 만들어라"라는 고수준 지시...