goldtag

Harness Engineering in Practice — How Anthropic Designs AI Agents The previous post covered the concept and components of harness engineering. This time, it's the real thing. Drawing on the concrete architecture patterns Anthropic published in their official engineering blog — along with experimental results from the OpenAI Codex team — let's look at how harnesses are actually applied in practice. The Basic Structure of an Agent Loop: The Inner Loop At the heart of every AI agent sits an agent loop . In Claude Code, it's called queryLoop . At its core, it's a while(true) loop. while (true) { 1. Prepare context (plan-mode attachments, task reminders) 2. Call the model (streaming API call) 3. Execute tools (detect tool call → validate schema → check permissions → execute) 4. Decide whether to continue (does the model have more to do?) } Each iteration is one "think, act, observe" cycle. The model thinks, invokes a tool, observes the resul...

What Is Harness Engineering — Designing the Reins for AI Agents In Part 1 of this series, I talked about the decline of prompt engineering. With CLI-based tools on the scene, the value of manually crafting elaborate prompts was fading. But as 2026 unfolded, I realized that what replaced prompt engineering wasn't simply "better tools." Prompt engineering gave way to context engineering, and now context engineering is giving way to an entirely new paradigm: harness engineering . In this post, I'll break down what harness engineering is, why it matters right now, and what its key components look like. A Harness for a Horse, a Harness for an Agent A harness originally refers to the tack fitted onto a horse. Bridle, saddle, stirrups — equipment designed not to suppress the horse's power, but to channel it in the right direction. In AI, the term means exactly the same thing. A harness is the entire external system that controls and directs an AI agent's power...

하네스 엔지니어링 적용편 — 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의 클론을 만들어라"라는 고수준 지시...

How AI Coding Changed Completely in 18 Months — Is Prompt Engineering Dead? In late November 2024, I used AI for the first time. Eighteen months later, the changes I've witnessed aren't just about better tools. The entire way of working has transformed — and the pace of that transformation is accelerating. At first, a new paradigm emerged roughly every six months. Then every three months. Now, something new drops almost every week. AI has moved past its infancy and entered a full-blown transition period. Standing in the middle of it, I thought it was worth looking back at these 18 months. The Past — Copy-Paste and Prompt Engineering The Chat Window Era To be precise, it started with asking ChatGPT about code. I'd paste a function or an error message, get a response, copy it, and move it to my editor. The novelty of asking AI instead of searching Google was refreshing, and I was genuinely impressed by the accuracy. But fundamentally, the workflow wasn't all that d...

AI 활용법, 1년 반 만에 완전히 바뀌었다 — 프롬프트 엔지니어링은 이제 필요 없을까? 2024년 11월 말, 처음으로 AI를 사용했다. 그로부터 1년 반. 그 사이에 일어난 변화는 단순한 도구의 발전이 아니었다. 일하는 방식 자체가 바뀌었고, 바뀌는 속도 자체가 가속되고 있다. 처음에는 6개월 단위로 새로운 패러다임이 등장했다. 그것이 3개월로 줄었고, 지금은 한 주가 멀다 하고 새로운 것이 쏟아진다. AI는 태동기를 지나 과도기에 접어들었다. 그리고 과도기의 한가운데에 서 있는 지금, 이 1년 반을 돌아보는 것이 의미가 있겠다는 생각이 들었다. 과거 — 복사 붙여넣기, 그리고 프롬프트 엔지니어링 대화창 시대 정확히 말하면 ChatGPT에 코드를 물어보는 것부터 시작했다. 함수 하나, 에러 메시지 하나를 붙여넣고 답변을 받아 복사해서 에디터에 옮기는 방식. 구글 검색 대신 AI에게 물어본다는 것 자체가 신선했고, 답변의 정확도에 꽤 놀랐다. 하지만 사용 방식은 본질적으로 검색과 다르지 않았다. 질문하고, 답변을 읽고, 수동으로 적용하는. 그 반복이었다. 그때는 이것만으로도 충분히 혁신적이라고 생각했다. 프롬프트 엔지니어링이라는 발견 몇 달이 지나자 한계가 보이기 시작했다. 같은 질문인데 어떻게 물어보느냐에 따라 답변의 질이 확연히 달라졌다. "이 코드 고쳐줘"라고 하면 대충 수정해주지만, 역할을 부여하고 맥락을 설명하고 출력 형식을 지정하면 전혀 다른 수준의 결과가 나왔다. 2025년 초, 프롬프트 엔지니어링을 본격적으로 학습하기 시작했다. 시스템 프롬프트 설계, 체인 오브 씽킹, 퓨샷 러닝, 역할 지정. 프롬프트 하나를 설계하는 데 코드를 작성하는 것만큼의 시간을 들이기도 했다. 실제로 효과가 있었다. 같은 모델이라도 프롬프트에 따라 주니어 개발자 수준의 답변과 시니어 개발자 수준의 답변을 오갔다. AI를 제대로 활용하려면 프롬프트 엔지니어링은 필수라고 확신했다. 그런데 그 확신은 오래가지 않았다. 프롬프트 엔지...