AI Agent는 모델만으로 만들어지지 않는다 — Harness Engineering (1)

정~말 오랜만에 AI 글을 쓰는데, 

몇 년 전부터 지금까지 아니 앞으로도

AI 분야는 유행이 정말 빠르다.

 

처음에는 Prompt Engineering 이야기를 했고, 어느 순간부터 Context Engineering이라는 표현이 자주 보이기 시작했다.

그리고 AI Agent가 본격적으로 쓰이면서 Harness Engineering이라는 표현도 눈에 띄게 등장하기 시작했다.

 

사실 Harness라는 개념 자체가 갑자기 2026년에 생겨난 것은 아니다.

Anthropic은 이미 2025년 11월 장시간 작업하는 Agent를 위한 effective harness를 다뤘고,

OpenAI는 2026년 1월 Codex의 핵심 실행 구조를 설명하면서 이를 Codex harness라고 명시했다.

이후 2월에는 아예 “Harness engineering”이라는 제목의 글을 공개했다.

 

https://openai.com/ko-KR/index/harness-engineering/

하네스 엔지니어링: 에이전트 우선 세계에서 Codex 활용하기

 

그래서 지금 와서 보면 아주 따끈따끈한 신조어라고 하기는 어렵다.

그런데 오히려 그래서 한 번쯤 다시 정리할 필요가 있다고 생각했다.

Claude Code, Codex 같은 Coding Agent를 비롯해 Agent가 실제 업무에 깊숙이 들어오기 시작하면서 이제는 단순히 “어떤 LLM을 사용했는가?”만으로 Agent의 성능을 설명하기 어려워지고 있기 때문이다.

 

같은 좋은 모델을 사용해도 어떤 Agent는 몇 시간짜리 작업을 끝까지 수행하는 반면, 어떤 Agent는 파일 몇 개를 읽다가 엉뚱한 방향으로 빠진다.

 

도대체 이 차이는 어디에서 오는 걸까?

 

그 답을 이해하기 위해 필요한 개념이 바로 Harness다.

 

---

좋은 LLM을 쓰면 좋은 Agent가 되는 것 아닌가?

처음 LLM을 사용할 때는 구조가 굉장히 단순했다.

사용자가 질문을 입력하면 모델이 답을 생성한다.

 

사용자
  ↓
Prompt
  ↓
LLM
  ↓
Response

 

 

이 구조에서는 모델 자체의 성능이 정말 중요하다.

어떤 모델이 추론을 더 잘하는지, 코드를 더 잘 만드는지, 더 긴 Context를 처리할 수 있는지가 결과 품질에 직접적인 영향을 준다.

그런데 Agent는 조금 다르다.

예를 들어 Coding Agent에게 이런 요청을 했다고 생각해보자.

 

"이 프로젝트에서 로그인할 때 발생하는 버그를 찾아서 수정해줘."

 

LLM이 해야 할 일은 단순히 답변을 생성하는 것이 아니다.

프로젝트 구조를 살펴보고, 파일을 찾고, 코드를 읽고, 원인을 추론하고, 코드를 수정하고, 테스트까지 실행해야 한다.

하다가 테스트가 실패하면 다시 코드를 읽고 수정해야 할 수도 있다.

 

사용자 요청
    ↓
   LLM
    ↓
파일 검색
    ↓
파일 읽기
    ↓
원인 추론
    ↓
코드 수정
    ↓
테스트 실행
    ↓
 실패?
 ↙     ↘
Yes     No
 ↓       ↓
다시 수정  완료

 

여기까지 오면 LLM은 시스템의 일부일 뿐이다.

LLM에게 어떤 파일을 보여줄지, 어떤 명령을 실행할 수 있게 할지, 실행 결과를 어떻게 다시 모델에게 전달할지, 위험한 명령은 어디까지 허용할지 등을 모델 바깥의 소프트웨어가 관리해야 한다.

바로 이 부분이 Harness를 이해하는 출발점이다.

---

Harness란 무엇인가?

Harness는 원래 마구나 안전벨트처럼 무언가를 붙잡거나 제어하기 위한 장치를 뜻한다.

AI Agent에서의 의미도 꽤 비슷하다.

LLM 혼자서는 현실 세계의 파일을 수정하거나 터미널 명령어를 실행할 수 없다.

pytest를 실행해야겠다.

 

라고 LLM이 판단하더라도 실제 명령어를 실행하는 것은 LLM 자체가 아니다.

 

LLM의 출력을 읽고 명령을 실행한 뒤, 그 결과를 다시 LLM에게 전달하는 시스템이 필요하다.

OpenAI는 Codex를 설명하면서 Harness를 Codex 경험의 기반이 되는 핵심 Agent Loop와 실행 로직을 제공하는 부분이라고 표현한다.

2026년에 공개된 Coding Agent 11종의 소스코드를 분석한 연구에서는 범위를 조금 더 넓혀 Harness를

LLM을 Loop, Tools, Context Management, Safety Controls, Orchestration 등을 통해 외부 세계와 연결하는 Runtime

으로 정의한다.

아직 Harness의 범위에 대한 완전히 통일된 산업 표준이 있는 것은 아니다.

 

하지만 큰 틀에서 보면 다음처럼 이해하면 편하다.

 

              ┌───────────────┐
              │      LLM      │
              │   "두뇌"       │
              └───────┬───────┘
                      │
       ┌──────────────▼──────────────┐
       │         Agent Harness       │
       │                             │
       │  Agent Loop                 │
       │  Context Management         │
       │  Tools                      │
       │  Memory / Skills            │
       │  Permissions / Guardrails   │
       │  Evaluation / Observability │
       └──────────────┬──────────────┘
                      │
              ┌───────▼───────┐
              │   Environment │
              │ Files / Shell │
              │ Browser / API │
              └───────────────┘

 

한마디로 줄이면,

Model이 생각하는 방법을 개선하는 것이 Model Engineering이라면, 그 Model이 실제로 일을 잘할 수 있도록 환경을 설계하는 것이 Harness Engineering이라고 볼 수 있다.

 

---

그렇다면 Harness 안에는 뭐가 들어갈까?

Harness를 이해할 때 가장 먼저 봐야 할 것은 Agent Loop다.

1. Agent Loop — Agent의 심장

일반적인 챗봇은 보통 한 번의 요청과 한 번의 응답으로 끝난다.

하지만 Agent는 그렇지 않다.

예를 들어 Codex가 버그를 고치는 과정에서는 다음 행동을 판단하고, Tool을 실행하고, 결과를 다시 확인하는 과정이 계속 반복된다.

Think
  ↓
Action
  ↓
Observation
  ↓
Think
  ↓
Action
  ↓
Observation
   ...

 

OpenAI 역시 Agent Loop를 Codex CLI의 핵심 로직으로 설명하고 있다.

사용자의 입력, 모델, 그리고 모델이 호출하는 Tool 사이의 상호작용을 오케스트레이션하는 역할이다.

 

Codex가 파일을 찾고, 읽고, 수정하고, 테스트하는 동안 모델과 실행 환경 사이의 요청이 여러 차례 왕복한다.

우리가 화면에서 보는 것은 하나의 작업이지만 내부에서는 수십 번의 Model ↔ Tool 상호작용이 발생할 수 있다.

---

2. Context — Agent가 지금 무엇을 알고 있는가

그다음 중요한 것이 Context다.

LLM은 프로젝트의 모든 것을 알고 있는 것이 아니다.

Agent가 버그를 수정해야 한다면

• 사용자의 요청
• 시스템 지침
• 프로젝트 구조
• 관련 소스코드
• 이전 Tool 실행 결과
• Git 변경 사항
• 테스트 결과

등 필요한 정보를 모델에게 적절히 보여줘야 한다.

문제는 Context Window가 무한하지 않다는 점이다.

작업이 길어질수록 Tool 실행 결과와 대화 기록이 계속 쌓인다.

따라서

 

지금 이 순간 모델이 판단하는 데 무엇이 필요한가?

 

를 결정하는 것도 Harness의 중요한 역할이 된다.

여기서 최근 자주 이야기되는 Context Engineering과 연결된다.

Anthropic은 Context Engineering을 단순히 좋은 Prompt를 작성하는 것을 넘어, 추론 시점에 모델에게 들어갈 정보 전체를 선별하고 유지하는 작업으로 설명한다.

 

개념을 거칠게 구분하면 이렇게 볼 수 있다.

 

Prompt Engineering	모델에게 어떻게 말할까?
Context Engineering	모델에게 무엇을 보여줄까?
Harness Engineering	모델이 어떤 환경에서 어떻게 일하게 할까?

Context Engineering은 Harness Engineering과 경쟁하는 개념이라기보다 Harness를 잘 만들기 위해 필요한 중요한 영역 중 하나라고 보는 편이 자연스럽다.

 

---

3. Tools — 생각만 하는 AI를 행동하는 AI로

Agent가 ChatGPT 같은 일반적인 LLM 서비스와 가장 크게 달라지는 부분 중 하나다.

모델에게 Tool을 연결하면 할 수 있는 일이 급격하게 늘어난다.

예를 들어 Coding Agent라면

파일 검색
파일 읽기
파일 수정
Shell 명령 실행
Git
Test
Browser
MCP
외부 API

 

등을 사용할 수 있다.

중요한 것은 Tool의 개수만 많다고 좋은 것이 아니라는 점이다.

모델에게 Tool의 역할을 어떻게 설명할지, 어떤 상황에서 사용할 수 있도록 할지,

Tool의 실행 결과를 어떤 형태로 반환할지 같은 부분도 모두 Agent 성능에 영향을 준다.

즉 Tool을 붙이는 것 자체보다 Tool을 모델이 잘 사용할 수 있도록 만드는 인터페이스 설계가 중요하다.

---

4. Sandbox와 실행 환경 — Agent에게 작업실을 만들어주는 일

Coding Agent에게 아무리 좋은 LLM을 붙여도 실제 파일을 만질 수 없다면 코딩을 완료할 수 없다.

그래서 Agent에게는 일종의 작업실이 필요하다.

파일 시스템이 있고,

Shell을 실행할 수 있고,

필요하다면 패키지를 설치하거나 프로그램을 실행할 수 있는 환경이다.

 

여기서 Sandbox가 등장한다.

Sandbox는 1)Agent가 실제 명령을 실행할 수 있게 하면서도

2) 시스템 전체에 무제한으로 접근하지 못하도록 실행 영역을 제한하는 역할을 한다.

 

OpenAI의 현재 Agent 구조에서도 Harness와 Sandbox를 별개의 계층으로 분리하는 방식이 제시되어 있다.

Harness가 Agent Loop와 Tool을 관리하고, Sandbox가 실제 파일과 명령 실행을 담당하는 형태다.

OPEN AI 제공 이미지

OPEN AI 제공 이미지

 

이 부분은 Agent가 단순한 데모를 넘어 실제 서비스로 갈수록 중요해진다.

---

5. Permission과 Guardrail — AI에게 어디까지 맡길 것인가

Agent에게 능력을 주는 순간 또 다른 문제가 생긴다.

예를 들어 Coding Agent가 다음 작업을 할 수 있다고 생각해보자.

 

git push
rm -rf ...
DROP TABLE ...
kubectl delete ...

 

Tool을 사용할 수 있다는 것은 그만큼 사고를 칠 수도 있다는 뜻이다.

그래서 Harness에는 보통

• Tool 실행 승인
• 접근 가능한 파일 범위
• 위험 명령 제한
• 네트워크 접근
• 인증 정보 관리
• Human-in-the-loop
• 실패 횟수 제한

등의 제어 장치가 필요해진다.

Agent의 성능을 높이는 것만큼 Agent가 어디까지 행동할 수 있는지를 제한하는 것도 Harness Engineering의 영역인 셈이다.

---

6. Evaluation과 Observability — 일을 시켰으면 확인도 해야 한다

사람에게 개발 업무를 맡겼다고 생각해보자.

코드를 작성했다고 해서 바로 배포하지 않는다.

테스트도 하고 코드 리뷰도 한다.

Agent도 마찬가지다.

예를 들어

 

로그인 버그를 수정했습니다.

 

라고 Agent가 말한다고 해서 정말 수정됐다고 믿을 수는 없다.

실제 테스트를 돌려보고,

기존 기능이 깨지지는 않았는지 확인하고,

필요하다면 다시 수정하도록 해야 한다.

 

Implement
   ↓
 Test
   ↓
 Fail ──────→ Implement
   ↑             │
   └─────────────┘

 Pass
   ↓
 Done

 

 

여기에 실행 과정의 Trace나 Tool 호출 기록까지 남기면 Agent가 실패했을 때 어디에서 잘못 판단했는지 추적할 수도 있다.

그래서 최근 Agent 플랫폼에서 Evaluation과 Observability가 별도 기능으로 계속 강조되고 있다.

OpenAI 역시 Agents SDK에 Guardrails와 Tracing을 핵심 구성요소로 포함하고 있다.

---

사실 회사에서 신입 개발자에게 일을 맡기는 것과 비슷하다

여기까지 읽으면 Harness라는 말이 상당히 거창해 보일 수 있다.

그런데 개인적으로는 신입 개발자에게 일을 맡긴다고 생각하면 가장 쉽게 이해된다.

아무리 실력이 좋은 개발자를 데려와도

"우리 서비스 좀 알아서 고쳐주세요."

 

라고 말한 뒤 아무것도 제공하지 않으면 일을 제대로 하기 어렵다.

프로젝트 문서도 줘야 하고,

개발 환경도 만들어줘야 하고,

DB 접근 권한도 설정해야 하고,

테스트 방법도 알려줘야 하고,

회사 코딩 규칙도 알려줘야 한다.

그리고 작업이 끝나면 리뷰도 한다.

Agent도 거의 똑같다.

회사에서 개발자에게AI Agent에서는

 

업무 지시	Prompt / Instruction
업무 자료	Context
개발 도구	Tools
개발 PC	Sandbox
회사 매뉴얼	AGENTS.md / Skills
접근 권한	Permission
업무 기록	Memory / State
코드 리뷰	Evaluation
반복적인 업무 과정	Agent Loop

이렇게 놓고 보면 Harness Engineering이 왜 필요한지 조금 더 명확해진다.

좋은 사람을 뽑는 것과 좋은 업무 환경을 만드는 것은 서로 다른 문제다.

마찬가지로 좋은 LLM을 선택하는 것과 좋은 Agent를 만드는 것도 완전히 같은 문제는 아니다.

---

그런데 왜 Harness가 갑자기 중요해졌을까?

가장 큰 이유는 단순하다.

 

모델이 실제로 일을 할 수 있을 만큼 좋아졌기 때문이다.

 

초기의 LLM은 대부분 한두 번의 추론으로 끝나는 작업에 사용됐다.

글을 요약하거나,

문장을 분류하거나,

질문에 답하는 방식이다.

이때는 좋은 Prompt와 좋은 Model이 상당히 중요했다.

 

그런데 현재 Agent는 수십 번, 때로는 수백 번 Tool을 사용하며 장시간 작업한다.

Context를 관리해야 하고,

실패하면 복구해야 하고,

파일과 상태를 유지해야 하며,

위험한 작업은 막아야 한다.

결국 모델 바깥의 시스템이 훨씬 커질 수밖에 없다.

그리고 실제 사례에서도 이 차이가 나타나고 있다.

---

 

그렇다면 모델보다 Harness가 더 중요하다는 뜻일까?

여기서는 조금 조심할 필요가 있다.

그렇지는 않다.

Model과 Harness 중 하나만 중요하다고 보는 것은 지나치게 단순한 해석이다.

기본적인 추론 능력, Coding 능력, Tool-use 능력 자체가 부족한 모델을 좋은 Harness만으로 완전히 해결할 수는 없다.

반대도 마찬가지다.

좋은 모델을 가져와도 필요한 Context가 없거나, Tool이 엉망이거나, 작업 환경이 제대로 구성되지 않았다면 모델의 능력을 제대로 끌어낼 수 없다.

그래서 저는 다음 식으로 보는 것이 가장 이해하기 쉽다고 생각한다.

좋은 Agent
=
좋은 Model
×
좋은 Harness

 

덧셈보다 곱셈에 가깝다.

둘 중 하나가 심하게 부족하면 전체 성능도 크게 떨어진다.

그리고 여기서 또 하나 중요한 점이 있다.

Harness는 복잡할수록 좋은 것도 아니다.

 

Anthropic도 2026년 Harness 실험을 설명하면서 Harness의 각 구성 요소는 결국 “현재 모델이 스스로 할 수 없는 것이 무엇인가”에 대한 가정을 담고 있다고 지적한다.

모델이 개선되면 과거에 필요했던 복잡한 보조 구조가 오히려 불필요해질 수도 있다. 실제로 Anthropic은 Opus 4.6으로 모델이 개선된 뒤 기존 Harness의 일부 구조를 제거하며 단순화하는 실험을 진행했다.

 

따라서 Harness Engineering을

LLM 주변에 기능을 최대한 많이 붙이는 것

 

으로 이해하면 안 된다.

오히려 핵심은

현재 모델이 실제 업무를 안정적으로 완료하는 데 필요한 최소한의 환경을 찾는 것

 

에 가깝다.

이 부분은 이후 글에서 직접 실험해볼 예정이다.

---

Prompt 다음은 Context, 그다음은 Harness일까?

Prompt Engineering → Context Engineering → Harness Engineering을 보면 마치 새로운 용어가 이전 것을 대체하는 것처럼 보인다.

하지만 실제로는 범위가 점점 넓어졌다고 보는 것이 더 적절하다.

Harness Engineering
│
├── Agent Loop
├── Tools
├── Execution Environment
├── Safety / Permission
├── Evaluation
│
└── Context Engineering
      │
      └── Prompt Engineering

 

물론 이것이 공식적인 표준 계층 구조라는 뜻은 아니다.

개념을 이해하기 위한 단순화다.

초기 LLM 개발에서는

“무슨 말을 해야 좋은 답을 얻을까?”

가 중요했다.

 

Agent 시대에는

“어떤 정보를 보여주고, 어떤 Tool을 제공하고, 어떤 환경에서 일하게 하며, 결과를 어떻게 검증할까?”

까지 고민의 범위가 넓어진 것이다.

Harness Engineering이라는 표현이 중요한 이유도 여기에 있다고 생각한다.

 

 

 

---

이제 Agent를 볼 때 모델 이름만 보면 안 된다

Claude Code, Codex, Gemini CLI 같은 Agent를 비교하면 자연스럽게 이런 질문을 하게 된다.

어떤 모델을 쓰지?

 

물론 중요한 질문이다.

하지만 이제는 한 가지 질문을 더 해볼 필요가 있다.

그 모델을 둘러싼 Harness는 어떻게 설계되어 있지?

 

어떻게 Context를 관리하는지,

어떤 Tool을 제공하는지,

작업 도중 실패를 어떻게 복구하는지,

Memory나 Skill은 어떻게 유지하는지,

어떤 Sandbox와 Permission 구조를 사용하는지,

Agent가 자신의 결과를 어떻게 검증하는지.

이런 요소들이 실제 Agent 경험을 만드는 또 하나의 중요한 축이 되고 있다.

 

최근에는 실제로 Claude Code, Codex CLI, Gemini CLI, OpenHands, Hermes 등 여러 Coding Agent의 Harness 자체를 비교 분석하는 연구까지 등장했다.

앞으로 Agent 경쟁을 볼 때 모델 Benchmark만큼이나 이런 구조를 보는 일이 재미있어질 것 같다.

 

---

 

오랜만에 AI와 함께

AI 정보 글을 써봤고, 곧 이어서 (2), (3)편 까지 실습을 담아서 작성해보려고 한다.