기획연재 1편 / 4부작

AI Agent의 성능은 모델보다 하네스에서 갈린다

Prompt Engineering·Context Engineering 다음에 왜 Harness Engineering이 필요한가

---

월요일 오전 9시, 마케터가 Agent에게 이렇게 요청했다고 가정해 보겠습니다.

지난주 캠페인 성과를 분석하고, 전환율이 떨어진 원인을 근거와 함께 리포트로 만들어줘. 다음 실험안은 자동화 설정으로 만들어줘. 내가 승인한 버전만 게시하고, 실제 실행은 자동화 엔진이 맡아.

Agent에는 성능 좋은 LLM이 연결되어 있습니다. 캠페인 지표를 읽는 분석 도구, 정책 문서를 찾는 Knowledge Base, 캠페인과 세그먼트 관계를 탐색하는 Knowledge Graph, 리포트를 만드는 도구도 갖춰져 있습니다.

데모에서는 잘 동작합니다. Agent가 몇 번의 도구 호출 끝에 그럴듯한 리포트를 만듭니다.

그런데 실제 운영에서는 이상한 일이 생깁니다.

• 지난주 수치가 아니라 지난달에 저장한 요약값을 사용합니다.
• 같은 분석 도구를 인자만 조금씩 바꿔 반복 호출합니다.
• 사용자가 지정하지 않은 다른 사이트 데이터까지 조회하려고 합니다.
• 필수 섹션이 빠졌는데도 "리포트 작성이 완료되었습니다"라고 답합니다.
• 자동화 설정은 승인·게시된 버전만 실행해야 하지만, Agent가 초안 상태의 설정을 곧바로 실행하려고 합니다.
• 중간에 타임아웃이 발생하자 처음부터 다시 시작하고, 같은 리포트를 두 개 만듭니다.
• 무엇을 근거로 어떤 결론을 냈는지 나중에 재현하기 어렵습니다.

이 문제를 해결하기 위해 시스템 프롬프트를 더 길게 써 봅니다.

"반드시 최신 데이터를 사용하세요."

"도구를 반복 호출하지 마세요."

"권한 밖 데이터는 조회하지 마세요."

"설정 변경 전에는 반드시 승인을 받으세요."

"완료 전에 결과를 검증하세요."

조금 나아질 수는 있습니다. 하지만 해결되지는 않습니다.

최신 데이터인지 판정하는 일, 조회 가능한 범위를 계산하는 일, 승인 여부를 확인하는 일, 같은 작업이 이미 실행됐는지 확인하는 일, 필수 섹션이 모두 있는지 검사하는 일은 모델이 잘 기억해 주기를 기대할 문제가 아니라 시스템이 강제해야 할 문제이기 때문입니다.

프로덕션 AI Agent의 성능은 "얼마나 그럴듯하게 답하는가"만으로 평가할 수 없습니다.

이 질문에 답하는 실행 환경이 Agent Harness입니다.

TL;DR · 4줄 요약

① Prompt Engineering은 모델에게 무엇을 지시할지 설계합니다.

② Context Engineering은 모델이 지금 무엇을 보게 할지 설계합니다.

③ Harness Engineering은 모델 호출 전, 사이, 후에 시스템이 무엇을 강제하고 기록할지 설계합니다.

④ 프로덕션 Agent의 품질은 모델 점수 하나가 아니라 완료율, 정책 준수, 복구 가능성, 추적 가능성, 비용의 결합으로 봐야 합니다.

앞선 연재에서 남은 질문: 도구가 준비됐다고 Agent가 일을 잘하는 것은 아니다

앞선 「프로덕션 AI Agent」 연재에서는 LLM에 Tool Calling만 붙인다고 Agent가 되지 않는 이유를 다뤘습니다. 챗봇의 출력은 사람이 읽고 거를 수 있는 답변이지만, 실행형 Agent의 출력은 고객 데이터를 바꾸거나 메시지를 발송하거나 자동화 흐름을 시작하는 결과로 이어집니다. 판단 오류가 즉시 부수효과가 됩니다.

그 연재의 2편 「실무에 AI Agent를 넣는 법: 쿠폰 발행으로 본 설정 Copilot 패턴」에서는 Agent가 고객 10만 명을 직접 판단·실행하는 대신 조건과 자동화 흐름을 제안하고, 시스템이 실행하는 구조를 살펴봤습니다.

이어진 「Agent 시대의 RAG 재설계」 연재에서는 문서는 KB에서, 관계는 KG에서, 현재 운영값은 Zero-Copy SQL/API에서 읽고, 온톨로지를 의미 지도이자 도구 계약으로 두는 구조를 살펴봤습니다.

이제 지식 도구는 준비됐습니다.

• 정책과 원문 근거를 찾는 KB
• 고객, 캠페인, 콘텐츠, 세그먼트의 관계를 탐색하는 KG
• 현재 매출, 전환율, 발송 수를 읽는 SQL/API
• 업무 개념과 제약을 정의하는 온톨로지
• 리포트, 위젯, 자동화를 만드는 도구

하지만 도구가 많아졌다고 Agent가 자동으로 좋아지지는 않습니다. 오히려 새로운 질문이 생깁니다.

이 질문은 검색기나 모델 하나의 문제가 아닙니다. 실행 환경의 문제입니다.

Agent Harness는 모델을 감싸는 '실행 환경'이다

Harness라는 단어는 원래 장비를 몸에 고정하고 힘을 안전하게 전달하는 장치를 뜻합니다. Agent Harness도 역할이 비슷합니다. 모델의 능력을 제한하려는 장치가 아니라, 그 능력이 실제 업무 시스템 안에서 올바르게 사용되도록 전달하는 장치입니다.

조금 더 들여다보면, harness는 본래 말이나 소를 수레·쟁기에 잇는 마구(馬具)에서 온 말입니다. 마구는 동물의 힘을 실제 일로 전달하고, 동시에 마부가 방향과 속도를 통제하게 해 줍니다. 여기서 "(바람·물 같은 힘을) 통제해 유용하게 쓴다"는 동사 용법(harness the wind)이 파생됐고, 소프트웨어에서는 테스트 대상 시스템을 실행·제어하는 골격 코드를 test harness라 부르며 이 계보가 이어졌습니다. Agent Harness도 같은 맥락으로, 모델이라는 '엔진'의 힘을 실제 제품 실행으로 전달하면서 그 방향을 통제하는 장치를 가리킵니다.

가장 간단하게 표현하면 다음과 같습니다.

Agent = Model + Harness

여기서 Model은 추론하고 다음 행동을 제안합니다. Harness는 그 제안을 실제 제품 실행으로 바꾸기 전에 필요한 컨텍스트를 구성하고, 권한과 정책을 확인하고, 도구를 실행하고, 결과를 상태에 반영하고, 실패를 복구하고, 완료를 검증하고, 전 과정을 기록합니다.

따라서 Harness는 단순한 "프롬프트 래퍼"가 아닙니다. 모델 바깥에서 다음 책임을 맡는 런타임입니다.

이 구조에서 중요한 구분이 하나 있습니다.

모델은 실행을 제안하고, 시스템이 실행 가능성을 판정한다.

모델이 update_campaign이라는 도구와 올바른 JSON 인자를 만들었다고 해서 캠페인을 바꿀 권한까지 생기는 것은 아닙니다. 모델이 "필요한 근거를 모두 확인했다"고 말해도 실제로 필수 근거가 존재한다는 뜻이 아닙니다. Tool Call과 실행 권한은 다릅니다.

Harness는 모델의 말을 믿지 않기 위해 존재하는 것이 아닙니다. 모델이 잘할 수 있는 판단과 시스템만이 강제할 수 있는 계약을 분리하기 위해 존재합니다.

하네스에는 사전 가이드와 사후 센서가 함께 있어야 한다

하네스는 모델 앞에 규칙을 세우는 장치만도, 모델 뒤에서 로그를 모으는 장치만도 아닙니다. 한 번의 실행을 신뢰하려면 행동 전에 경계를 제시하는 가이드(Guide)와 행동 후에 결과를 외부 신호로 확인하는 센서(Sensor)가 함께 있어야 합니다.

구분	역할	캠페인 리포트 사례
Guide · 사전/진행 중	가능한 행동의 범위와 예산을 제한	허용 Source, Tool allowlist, 유효 Scope, 출력 계약, 최대 호출 수, 승인 필요 여부
Sensor · 실행 후	제안과 실제 결과의 차이를 외부 신호로 확인	Tool Receipt, 원본 수치 재계산, Evidence 현재성, Schema 결과, 정책 판정, 비용·지연
Bounded Feedback	센서 결과로 필요한 부분만 교정하고 종료	형식 오류 1회 교정, 일시 오류 제한 재시도, 근거 부족 시 NEEDS_REVIEW, 예산 소진 시 중단

가이드만 있으면 "모델이 지시를 잘 지켜 주기"에 의존하게 됩니다. 센서만 있으면 사고가 난 뒤에야 문제를 발견합니다. 좋은 Harness는 둘을 연결하되, 피드백이 무한 반복되지 않도록 횟수, 시간, 비용, 정지 조건을 명시합니다.

하네스의 핵심은 모델을 통제하는 규칙의 수가 아니라, 제안과 현실 사이의 차이를 외부 신호로 닫는 구조입니다.

같은 모델인데 결과가 다른 이유

하네스가 없는 Agent와 있는 Agent를 비교하면 차이가 분명해집니다.

상황	하네스가 약한 Agent	하네스가 있는 Agent
소스 선택	모델이 이름이 비슷한 소스를 임의 선택	세션 권한과 사용자 선택 범위에서만 소스 구성
컨텍스트	대화 전체와 검색 결과를 계속 누적	현재 단계에 필요한 정보만 로드하고 오래된 맥락은 축약·교체
상태	대화 메시지로만 진행 상황을 추정	계획·완료 단계·도구 결과·승인 상태를 구조화해 저장
도구 호출	형식이 맞으면 바로 실행	스키마·범위·위험도·예산·승인을 확인한 뒤 실행
재시도	실패하면 같은 요청을 처음부터 반복	실패 유형에 따라 제한적으로 재시도하고 멱등성으로 중복 방지
완료 판정	모델이 "완료"라고 말하면 종료	필수 산출물·스키마·근거·정책 조건을 외부 검증기로 확인
운영	마지막 답변만 남음	실행 경로·소스·도구·비용·오류·승인·결과를 Trace로 기록

두 Agent가 같은 모델을 사용해도 실제 품질은 크게 달라질 수 있습니다. 모델은 한 번의 판단을 만듭니다. Harness는 그 판단이 올바른 입력을 받고, 허용된 행동만 하며, 실패를 수습하고, 검증된 결과로 끝나도록 보장합니다.

그래서 프로덕션 Agent의 성능을 다음처럼 다시 정의할 필요가 있습니다.

Agent 성능 = 제약 안에서 일을 끝내는 능력

여기서 제약은 부가 조건이 아닙니다. 권한, 정책, 시간, 비용, 데이터 최신성, 승인, 출력 계약이 모두 성능의 일부입니다. 정책을 어기고 빠르게 끝낸 Agent는 성능이 좋은 Agent가 아닙니다. 답은 맞지만 어떻게 만들었는지 설명할 수 없는 Agent도 프로덕션에 적합하지 않습니다.

Prompt·Context·Harness·Loop Engineering은 무엇이 다른가

최근 Agent를 설명할 때 Prompt Engineering, Context Engineering, Harness Engineering, Loop Engineering이라는 표현이 함께 등장합니다. 이름이 비슷해 보이지만 설계 대상이 다릅니다.

구분	핵심 질문	주로 설계하는 것	캠페인 리포트 예시
Prompt Engineering	모델에게 무엇을 어떻게 지시할 것인가	역할, 목표, 제약 설명, 출력 지침	"전환 하락 원인을 근거와 함께 설명하라"
Context Engineering	모델이 지금 무엇을 보게 할 것인가	문서, 도구 결과, 메모리, 예시, 요약, 컨텍스트 예산	지난주 수치, 당시 정책, 관련 캠페인·세그먼트 관계
Harness Engineering	모델 호출 전·사이·후에 시스템이 무엇을 강제할 것인가	상태, 권한, 도구 실행, 승인, 재시도, 검증, 비용, 로그	허용 소스만 조회하고, 자동화 설정은 검증·승인·게시하며, 실행은 Runtime에 위임
Loop Engineering	여러 실행을 시간에 걸쳐 어떻게 반복·배분할 것인가	일정, 이벤트, 작업 큐, 다중 Agent, Maker/Checker, 장기 상태	매주 실행하고 이전 결과·피드백을 다음 주 실행에 반영

이 구분에서 자주 생기는 오해가 있습니다.

오해 1. 좋은 프롬프트가 있으면 하네스가 필요 없다

프롬프트는 행동을 유도할 수 있지만, 권한을 강제할 수는 없습니다. "다른 조직의 데이터를 보지 마라"는 문장보다 서버가 허용 범위의 교집합만 실행하는 코드가 강합니다. "중복 발송하지 마라"는 문장보다 업무 멱등성 키와 Execution Receipt가 강합니다. 언어 지시와 시스템 강제는 다른 계층입니다.

오해 2. 컨텍스트를 많이 넣으면 Agent가 안정된다

컨텍스트가 많아지면 필요한 정보를 놓치지 않을 가능성도 커지지만, 오래된 정보, 상충하는 규칙, 무관한 도구 결과가 함께 들어가면서 초점이 흐려질 수 있습니다. 컨텍스트는 저장소가 아니라 모델이 지금 사용하는 제한된 실행 자원입니다. 이 자원을 어떻게 구성하고 교체할지가 Context Engineering이고, 어떻게 예산을 집행할지가 Harness의 역할입니다.

오해 3. Agent Loop가 곧 Harness다

Agent가 Think → Act → Observe를 반복하는 루프는 Harness 안의 일부일 수 있습니다. 하지만 Harness는 그 루프를 둘러싼 실행 환경입니다. 루프가 어떤 도구를 요청하더라도 권한을 확인하고, 비용을 추적하고, 완료 조건을 외부에서 검증하는 것은 Harness의 책임입니다.

Loop Engineering은 한 단계 더 위의 문제입니다. 한 Agent 실행을 안전하게 만드는 것이 Harness라면, 여러 실행과 Agent를 시간에 걸쳐 시작, 분배, 검증하는 제어면이 Loop입니다. 이 연재의 4편에서 이어서 다룹니다.

Agent Framework와 Agent Harness는 같은 것이 아니다

"LangGraph를 쓰면 하네스가 생기는 것 아닌가요?"라는 질문도 자주 나옵니다.

프레임워크는 하네스를 구현하는 데 도움을 주는 도구 상자입니다. 상태 그래프, 도구 래퍼, 메모리 모듈, 체크포인트, 스트리밍, Human-in-the-loop 같은 기본 부품을 제공합니다.

하지만 어떤 소스를 볼 수 있는지, 어떤 도구가 고위험인지, 몇 번까지 호출할 수 있는지, 어떤 실행에 승인이 필요한지, 실패 시 무엇을 보존할지, 무엇을 완료로 볼지는 프레임워크가 자동으로 정해 주지 않습니다. 그 계약을 설계하는 일이 Harness Engineering입니다.

다음처럼 구분하면 이해하기 쉽습니다.

프레임워크를 선택하는 것은 구현 방식을 선택하는 일입니다. Harness를 설계하는 것은 실행 계약을 선택하는 일입니다.

같은 프레임워크를 사용해도 한 팀은 모든 도구를 한 Agent에게 열어 두고, 다른 팀은 읽기, 쓰기, 외부 전송, 삭제를 분리하고 승인 정책과 비용 상한을 둡니다. 두 시스템의 프로덕션 품질은 전혀 다릅니다.

하네스의 일곱 가지 구성요소

하네스 구현은 제품마다 다르지만, 프로덕션 Agent라면 대체로 다음 일곱 가지 책임을 가져야 합니다.

1. Context Manager — 지금 무엇을 보여줄 것인가

Context Manager는 모델이 현재 단계에서 봐야 할 정보를 구성합니다.

• 사용자 요청과 시스템 지침
• 선택된 KB, KG, 분석 소스
• 현재 작업에 필요한 도구 설명
• 이전 단계의 구조화된 결과
• 장기 메모리 중 지금 필요한 항목
• 남은 토큰, 시간, 비용 예산

핵심은 "가능한 모든 정보를 넣는 것"이 아닙니다. 현재 결정에 필요한 최소 충분 컨텍스트를 만드는 것입니다.

캠페인 리포트 Agent가 전환 하락 원인을 분석하는 단계라면 지난주 성과, 비교 기간, 당시 정책, 관련 세그먼트 변화는 필요합니다. 반면 과거의 모든 캠페인 대화와 사용자의 모든 선호를 한꺼번에 넣을 필요는 없습니다.

Context Manager가 약하면 Agent는 중요한 근거를 놓치거나, 오래된 규칙을 현재 규칙처럼 사용하거나, 도구 설명이 많아질수록 잘못된 도구를 선택합니다.

2. State & Memory — 어디까지 했고 무엇을 남길 것인가

상태와 메모리는 같지 않습니다.

• Workflow State는 지금 어느 단계인지, 어떤 도구가 성공했는지, 어떤 승인이 대기 중인지 기록합니다.
• Session State는 현재 대화와 열린 리포트, 선택한 소스, 사용자 입력을 이어 줍니다.
• Durable State는 실행이 중단돼도 복구해야 하는 체크포인트와 산출물을 보존합니다.
• Memory는 세션을 넘어 재사용할 사용자 선호, 반복 절차, 과거 피드백을 저장합니다.

이 구분이 없으면 대화 기록이 곧 상태가 됩니다. Agent는 긴 메시지에서 "아마 이 단계까지 했을 것"이라고 추정해야 하고, 재시작할 때 이미 실행한 도구를 다시 호출할 수 있습니다.

프로덕션 시스템에서는 상태가 프롬프트 안에만 있어서는 안 됩니다. 모델은 상태를 읽을 수 있지만, 상태의 최종 소유자는 시스템이어야 합니다.

3. Orchestrator — 다음 행동과 정지 조건을 관리한다

Orchestrator는 요청을 어떤 흐름으로 보낼지 결정합니다.

• 단일 답변으로 끝낼지
• KB 검색, KG 탐색, SQL 분석 중 무엇을 사용할지
• 전문 하위 Agent에 위임할지
• 여러 결과를 어떤 순서로 합칠지
• 근거가 부족하면 다시 조회할지
• 어느 시점에 사람에게 질문할지
• 언제 중단하거나 완료할지

여기서 중요한 것은 Agent에게 무한한 자율성을 주는 것이 아닙니다. 선택 가능한 경로와 예산, 최대 반복 횟수, 정지 조건을 명시하는 것입니다.

"필요할 때까지 계속 검색하라"는 지시는 운영 규칙이 아닙니다. "최대 세 종류의 소스를 조회하고, 필수 근거가 없으면 INSUFFICIENT_EVIDENCE로 종료한다"가 운영 규칙입니다.

4. Tool Executor — 요청과 실행을 분리한다

모델은 도구 호출 요청을 만듭니다. Tool Executor는 그 요청을 실제 실행으로 바꿉니다.

Tool Executor가 확인해야 할 것은 함수 이름과 JSON 문법만이 아닙니다.

• 입력 스키마가 맞는가
• 허용된 도구인가
• 요청 범위가 사용자 권한 안에 있는가
• 호출 횟수와 비용 상한을 넘지 않았는가
• 쓰기 또는 외부 전송인가
• 같은 요청이 이미 실행됐는가
• 타임아웃과 재시도 정책은 무엇인가
• 결과를 어떤 타입과 오류 코드로 돌려줄 것인가

이 계층이 있어야 "Tool Call"과 "실행 권한"을 분리할 수 있습니다.

5. Permission·Guardrail·Human-in-the-loop — 자율성의 경계를 정한다

Agent에게 필요한 것은 모든 도구에 대한 자유가 아니라, 업무에 필요한 만큼의 제한된 권한입니다.

도구는 최소한 다음처럼 구분할 수 있습니다.

• Read
• Write
• External Write
• Destructive

위험도가 높아질수록 더 강한 정책이 필요합니다. 특정 범위 밖 실행 금지, 민감정보 차단, 최대 대상자 수, 예산 상한, 승인 필요, 이중 검토 같은 규칙입니다.

사람의 승인은 실패를 인정하는 장치가 아닙니다. 모델이 잘 판단하더라도 조직이 최종 책임을 져야 하는 지점에 두는 정상적인 제어 노드입니다.

중요한 원칙은 단순합니다.

Agent는 범위를 요청할 수 있지만, 범위를 부여할 수는 없다.
Agent는 실행을 제안할 수 있지만, 승인 상태를 만들 수는 없다.

6. Reliability & Budget — 실패를 제한하고 복구한다

Agent는 모델 오류뿐 아니라 네트워크 오류, 도구 타임아웃, 부분 실패, 외부 API 제한, 긴 실행 시간, 비용 폭증을 만납니다.

따라서 Harness에는 다음이 필요합니다.

• 단계별 timeout과 전체 실행 deadline
• 오류 유형별 bounded retry
• exponential backoff와 circuit breaker
• 멱등성 키와 중복 실행 방지
• 체크포인트와 이어서 실행
• 부분 결과 저장
• dead-letter와 사람에게 에스컬레이션
• 최대 모델 호출, 도구 호출, 토큰, 비용 상한

여기서 "재시도"는 무조건 다시 모델을 부르는 것이 아닙니다. 입력 형식 오류라면 한 번 교정할 수 있고, 일시적 네트워크 오류라면 같은 요청을 재실행할 수 있습니다. 권한 거부나 근거 부족은 재시도한다고 해결되지 않습니다. 오류 유형을 분류하고 각각에 맞는 정책을 두는 것이 설계입니다.

비용도 운영 후 확인하는 청구서가 아니라 실행 중 강제하는 제약입니다. Agent가 하위 Agent를 계속 만들고 검색을 반복하면, 답변 품질보다 먼저 비용과 지연이 무너질 수 있습니다.

7. Verification & Observability — 완료를 외부 신호로 증명한다

Agent가 "잘했습니다"라고 말하는 것은 검증이 아닙니다.

완료 조건은 가능한 한 모델 밖에서 확인해야 합니다.

• JSON Schema와 필수 필드
• 숫자 범위와 enum
• 원본 데이터 재조회
• 정책 엔진 판정
• KG 관계와 온톨로지 규칙
• 실제 테스트 실행
• 필수 Evidence 존재 여부
• 사람 승인 상태
• 다운스트림 시스템의 성공 응답

Observability는 이 검증 과정을 포함해 전체 실행을 볼 수 있게 합니다.

• 어떤 Agent와 모델이 선택됐는가
• 어떤 소스와 도구를 사용했는가
• 어떤 입력과 스코프로 실행됐는가
• 어디서 실패하고 재시도했는가
• 어떤 근거로 결론을 만들었는가
• 토큰, 시간, 비용은 얼마나 들었는가
• 누가 승인했고 무엇이 실제로 변경됐는가

일반 애플리케이션 로그가 "무슨 오류가 났는가"를 설명한다면, Agent Trace는 한 단계 더 나아가 왜 이 실행 경로를 선택했는가를 설명해야 합니다.

좋은 하네스의 실행 흐름

앞의 요소를 하나의 실행으로 연결하면 다음과 같습니다.

의사코드로 줄이면 다음과 같습니다.

resolvedScope = resolveScope(serverSession)
context = assembleContext(request, resolvedScope, budget)

proposal = model.decide(context)

validated = validate(
  proposal,
  scope=resolvedScope,
  toolPolicy=toolPolicy,
  budget=budget
)

if validated.requiresApproval:
  return PENDING_APPROVAL

result = executeIdempotently(validated)

state = persist(state, result)
verification = verify(state, outputContract, evidencePolicy)

return finalize(state, verification, trace)

이 흐름에서 모델은 매우 중요합니다. 하지만 모델이 모든 책임을 갖지는 않습니다. 권한, 실행, 상태, 검증, 감사는 시스템이 소유합니다.

하네스 엔지니어링은 시스템 설계와 무엇이 다른가

여기까지 읽으면 이런 생각이 들 수 있습니다.

"상태 관리, 재시도, 타임아웃, 승인, 감사 로그라면 원래 백엔드 시스템에서 하던 일 아닌가?"

맞습니다. Harness Engineering의 상당 부분은 우리가 이미 알고 있는 시스템 설계입니다.

• 상태 머신
• 작업 큐
• 트랜잭션과 outbox
• 멱등성
• 권한 검사
• rate limit
• timeout과 retry
• circuit breaker
• 감사 로그
• 모니터링과 SLO

새로운 이름 때문에 완전히 새로운 분야처럼 느낄 필요는 없습니다.

다만 실행 핵심에 LLM이 들어오면서 기존 설계를 그대로 복사할 수 없는 부분이 생깁니다.

1. 실행 핵심이 비결정적이다

전통적인 함수는 같은 입력이면 대체로 같은 경로를 실행합니다. LLM은 같은 요청에도 다른 계획, 다른 도구, 다른 인자를 선택할 수 있습니다. 그래서 결과만 검증해서는 부족하고, 의도와 실행 후보도 검증해야 합니다.

2. 문법적으로 맞아도 의미적으로 틀릴 수 있다

JSON Schema를 통과한 {"discountRate": 50}은 형식적으로 유효할 수 있습니다. 하지만 업무 정책상 허용되지 않는 할인율일 수 있습니다. customerId도 존재하지만 다른 테넌트의 고객일 수 있습니다.

Agent 시스템은 형식 검증을 넘어 의미, 관계, 정책을 검증해야 합니다.

3. 컨텍스트가 길어질수록 반드시 좋아지지 않는다

일반 메모리는 저장 용량이 늘어도 내용 자체가 의미적으로 흐려지지는 않습니다. Agent 컨텍스트는 다릅니다. 오래된 도구 결과, 상충하는 지침, 무관한 대화가 쌓이면 모델의 현재 판단이 흔들릴 수 있습니다.

컨텍스트는 단순 저장 공간이 아니라 품질이 퇴화할 수 있는 실행 자원입니다.

4. 피드백 루프가 오류와 비용을 함께 증폭할 수 있다

모델이 실패할 때마다 다시 모델을 호출하면 개선될 수도 있지만, 잘못된 전제를 유지한 채 같은 오류를 반복하거나 호출 비용만 늘릴 수도 있습니다. 재시도와 반성은 "많이"가 아니라 검증 가능한 외부 신호와 제한된 예산에 연결되어야 합니다.

5. 자기 확신과 완료 여부가 분리돼 있다

모델은 실제 근거가 부족해도 자신 있게 완료를 선언할 수 있습니다. 따라서 "Agent의 최종 답변"과 "시스템의 완료 상태"는 별도여야 합니다.

이 차이를 한 문장으로 정리하면 다음과 같습니다.

Harness Engineering은 익숙한 시스템 설계를, 비결정적이고 컨텍스트에 의존하며 자신 있게 틀릴 수 있는 실행 핵심에 적용하는 일입니다.

이 원칙을 제품에 옮기면: AI 인사이트 스튜디오의 다중 Harness 구조

저희가 AI 인사이트 스튜디오를 설계할 때도 문제는 "어떤 LLM을 붙일 것인가"에서 끝나지 않았습니다.

사용자는 한 화면에서 질문하고, 인사이트를 얻고, 리포트와 콘텐츠를 만들고, 그 결과를 자동화로 이어갑니다. 그러나 이 작업들을 하나의 범용 Agent와 하나의 실행 루프로 처리하지는 않습니다. 같은 Harness Core를 공유하되, 산출물과 완료 조건에 따라 서로 다른 Harness Profile을 적용하고, 실제 자동화 실행은 별도의 결정론적 Automation Runtime이 담당합니다.

하나의 제품 안에 서로 다른 실행 계약이 있다

실행 영역	Harness 또는 Runtime의 역할	대표 산출물·완료 조건
Conversation & Insight Harness	사용자 의도 해석, Source Chip 기반 Context 구성, KB·KG·Zero-Copy 분석, 전문 Agent 위임, Claim·Evidence 검증	대화 답변, 분석 인사이트, 검증 상태
Content & Artifact Harness	리포트·문서·위젯·캠페인 카피·FAQ를 구조화 출력으로 생성하고 브랜드·정책·근거·버전을 검증	Report/Document/Widget/Content Artifact
Automation Configuration Harness	자연어 목표와 인사이트를 조건·세그먼트·노드·스케줄·승인 정책을 가진 버전형 ProcessFlow로 변환하고, Zero-Copy 데이터로 시뮬레이션한 뒤 설정을 정제	검증·승인·게시된 Automation Definition
Deterministic Automation Runtime	게시된 자동화 버전의 노드와 분기를 그대로 실행하고, 각 노드의 상태·영수증·멱등성·재시도·부분 성공을 관리	Automation Run State, Execution Receipt
Automation Verification & Refinement Harness	예상 대상·비용·경로와 실제 실행 상태·성과를 비교하고, 설정 변경안을 만들어 다시 시뮬레이션·검증·승인·게시	Automation Definition vN+1

이 구조에서 중요한 점은 자동화를 만드는 일과 자동화를 실행하는 일이 다르다는 것입니다.

Automation Configuration Harness는 "전환율이 급락한 캠페인만 찾아 담당자에게 보고하고, 승인된 경우에만 후속 메시지를 발송하라"는 목표를 실제 시스템이 실행할 수 있는 설정으로 바꿉니다. Agent는 조건식, 대상 범위, 실행 노드, 승인 위치, 실패 정책을 제안하고, 시스템은 대상자 수, 예상 비용, 정책 위반, 충돌 가능성을 계산합니다. Agent는 그 결과를 바탕으로 설정을 다시 고도화합니다.

반면 게시가 끝난 뒤의 Automation Runtime은 매 실행마다 모델에게 "다음에 무엇을 할까요?"라고 묻지 않습니다. 승인된 자동화 정의를 실행 가능한 계약으로 고정하고, Trigger → 조건 → 조회 → 분기 → 메시지, 리포트, 외부 액션의 순서를 결정론적으로 수행합니다. 자동화 안에 콘텐츠 생성이나 분류가 필요한 AgentNode가 있더라도, 그 노드의 입력, 출력, 예산, 도구, 실패 경계는 설정된 계약 안에 제한됩니다.

공통 Harness Core는 공유하고, Profile별 완료 계약을 다르게 둔다

서로 다른 Profile은 다음 공통 코어를 공유합니다.

공통 Harness Core	AI 인사이트 스튜디오의 제품 기능
Context & Scope	Source Chip, Canvas Context, 서버 권한 해석, 부모→자식 scope narrowing
Knowledge & Data	KB, KG, Ontology, Zero-Copy Analytics, MCP/A2A/HTTP/SQL Tool
State & Memory	Insight Session, Artifact State, Automation Definition State, 격리 Memory와 Skill
Execution Ledger	Automation Run/Node State, Query/Execution Receipt, 업무 멱등성 레코드, append-only Audit Event
Structured Contract	outputSchema, Node 입출력 계약, ProcessFlow 버전 계약
Guardrail & Approval	도구 위험 등급, 정책 엔진, 승인 인박스, DLP, 예산·호출 상한
Reliability	timeout, bounded retry, 업무 멱등성, Transactional Outbox, dead-letter, 부분 결과
Verification	Evidence/Trace, KG·온톨로지 검증, Run State·Receipt 검증, Completion Gate
Observability	SSE 타임라인, Agent/Automation Run Detail, Tool Audit, 비용·성과 지표

차이는 완료 조건입니다.

• 대화와 인사이트는 Claim이 Evidence로 뒷받침되고 사용자 질문에 답했을 때 완료됩니다.
• 콘텐츠는 스키마, 브랜드, 정책, 출처 계약을 통과하고 Artifact로 저장됐을 때 완료됩니다.
• 자동화 설정은 그래프 구조, 스코프, 예산, 승인, 시뮬레이션이 검증되고 특정 버전으로 게시됐을 때 완료됩니다.
• 자동화 실행은 게시된 버전의 필수 노드가 유효한 상태 전이를 거치고, 실제 부수효과의 Receipt와 최종 Run State가 확인됐을 때 완료됩니다.

Zero-Copy는 특히 자동화 엔진의 현재 상태 센서다

AI 인사이트 스튜디오에서 Zero-Copy는 분석 질의에도 사용되지만, 자동화 엔진에서는 더 직접적인 역할을 합니다. 자동화는 매 실행 시점의 대상자, 캠페인 상태, 동의 여부, 예산 잔액, 콘텐츠 상태를 기준으로 판단해야 합니다. 이것은 저장된 스냅샷이 아니라, 실행 직전의 현재 상태입니다.

그래서 Automation Runtime은 실행 직전에 서버가 해석한 스코프로 원본 semantic view·SQL/API를 조회하고, 다음 정보를 Run State와 Query Receipt에 남깁니다.

• 사용한 자동화 버전과 노드 버전
• effectiveScope와 권한 fingerprint
• 원본 조회의 asOf, source version, query hash
• 결정된 대상 수와 조건 판정 결과
• 실제 실행된 Command와 Execution Receipt
• 부분 성공, 재시도, dead-letter 상태

Zero-Copy 결과는 Agent의 기억이 아니라 실행 시점의 현실을 측정하는 센서입니다.

캠페인 사례에 적용하면

1. Conversation & Insight Harness가 KB 정책, KG 관계, Zero-Copy 성과 데이터를 조합해 전환 하락 원인을 분석합니다.

2. Content & Artifact Harness가 Claim, Evidence, 검증 배지가 포함된 리포트와 후속 콘텐츠를 만듭니다.

3. Automation Configuration Harness가 분석 결과를 조건, 노드, 스케줄, 승인 정책이 있는 ProcessFlow로 만들고 Zero-Copy로 시뮬레이션합니다. Automation Studio에서 편집하는 ProcessFlow가 게시되면 불변 Automation Definition vN이 됩니다.

4. Deterministic Automation Runtime은 Trigger가 발생할 때 vN을 고정해 실행하고, 실행 직전 Zero-Copy로 현재 대상, 동의, 예산, 상태를 다시 읽습니다. Query Receipt와 Execution Receipt는 Automation Run/Event Store에 저장하고, 리포트 Artifact에는 해당 Receipt의 참조만 연결합니다.

5. Automation Verification & Refinement Harness가 Node State, Receipt, 실제 성과를 검증합니다. 실행 중 승인 대기가 있으면 PENDING_APPROVAL로 멈추고, 완료 뒤 예상과 실제의 차이는 다음 설정 버전 후보의 근거가 됩니다.

이 편에서는 다섯 계층의 책임 경계만 고정합니다. 승인된 Command와 Receipt의 세부 계약은 3편에서, 생성 결과와 Automation Run을 완료로 인정하는 검증 계약은 4편에서 이어서 다룹니다.

여기서 제품의 핵심은 Agent를 "더 자유롭게" 만드는 것이 아닙니다.

생성과 판단에는 목적별 Harness를 적용하고, 자동화 실행은 게시된 설정대로 결정론적으로 수행하며, 실행 상태와 성과를 다시 설정 고도화의 근거로 돌려보내는 것입니다.

AI 인사이트 스튜디오는 KB, KG, 온톨로지, Zero-Copy 분석, Agent Builder, Automation Runtime, Artifact, Evidence/Trace를 이 책임 경계에 따라 연결하는 운영형 인사이트 워크스페이스입니다.

하네스 없이 프롬프트만 고치고 있다는 신호

다음 문제가 반복된다면 모델이나 프롬프트보다 하네스를 먼저 점검해야 합니다.

증상	프롬프트로만 해결하기 어려운 이유	필요한 하네스
같은 도구를 계속 호출한다	모델은 호출 이력과 비용을 정확히 계산하지 못할 수 있음	호출 예산, 중복 탐지, 정지 조건
가끔 권한 밖 ID를 요청한다	모델 출력은 권한 근거가 아님	서버 스코프 해석, 교집합 실행, fail-closed
재시도 후 중복 발송된다	모델은 이전 실행의 커밋 상태를 모를 수 있음	업무 멱등성 키, Execution Receipt 조회, 체크포인트
리포트 형식이 자주 깨진다	자연어 지시만으로 필수 필드를 보장하기 어려움	출력 스키마, 제한된 교정, 안전한 degrade
"완료"했지만 근거가 없다	자기평가와 외부 검증은 다름	Evidence 정책, 원본 재검증, 완료 게이트
대화가 길어질수록 성능이 떨어진다	컨텍스트에 오래된·무관한 정보가 누적됨	컨텍스트 예산, 요약, 단계별 재구성
장애 원인을 재현하기 어렵다	최종 답변만으로 실행 경로를 알 수 없음	Agent Trace, 구조화 로그, 비용·승인 감사

프로덕션 Agent 하네스 체크리스트

첫 번째 버전의 Harness를 설계할 때는 다음 질문부터 확인하면 좋습니다.

1. 모델의 출력은 실행 명령인가, 검증이 필요한 제안인가?

2. 조회와 실행 범위는 서버 세션과 정책으로 결정되는가?

3. 진행 상태가 대화문 밖의 구조화된 저장소에 남는가?

4. 도구마다 입력·출력 계약, 위험도, 승인 정책이 있는가?

5. 재시도 횟수와 전체 시간, 토큰, 비용 상한이 있는가?

6. 쓰기 작업은 멱등성과 중복 방지를 갖는가?

7. 완료 조건을 모델의 말이 아닌 외부 신호로 확인하는가?

8. 부분 실패와 부분 결과를 표현할 수 있는가?

9. 어떤 소스, 도구, Agent, 정책이 사용됐는지 Trace가 남는가?

10. 사람이 개입해야 할 지점과 책임자가 명확한가?

열 가지 모두 처음부터 완벽할 필요는 없습니다. 하지만 한 가지 원칙은 초기 버전부터 지키는 편이 좋습니다.

모델에게 맡긴 판단과 시스템이 강제하는 규칙을 코드와 데이터 구조에서 분리한다.

이 경계가 모호하면, 기능이 늘어날수록 모든 정책이 시스템 프롬프트에 쌓이고, 모든 상태가 대화 기록에 섞이며, 모든 오류가 "한 번 더 모델을 호출해 보자"로 처리됩니다. 데모는 빨리 만들 수 있지만 운영은 점점 어려워집니다.

모델은 엔진이고, 하네스는 제품의 실행 계약이다

Agent Harness라는 말이 완전히 새로운 시스템 설계 패러다임을 뜻하는 것은 아닙니다. 상태, 권한, 재시도, 멱등성, 승인, 로그는 오래전부터 중요했습니다.

하지만 LLM이 실행 경로를 동적으로 선택하는 순간, 이 익숙한 요소들은 선택 기능이 아니라 Agent의 핵심 품질이 됩니다.

프롬프트는 모델의 행동을 유도합니다. 컨텍스트는 모델이 판단할 재료를 제공합니다. 하네스는 그 판단이 실제 시스템에서 어떤 조건으로 실행되고, 실패하고, 복구되고, 검증되는지를 결정합니다.

그래서 더 좋은 모델을 기다리는 것만으로는 프로덕션 Agent가 완성되지 않습니다.

모델을 바꾸지 않고도 Agent의 품질을 높일 수 있는 가장 큰 지점은, 모델 주변의 실행 환경을 설계하는 데 있습니다.

다음 2편에서는 Harness의 정보 계층인 Context, State, Memory, Knowledge를 자세히 다룹니다. 긴 컨텍스트는 기억이 아닙니다. 대화 기록을 많이 넣는 것과, 실행 상태를 안전하게 보존하고, 필요한 지식을 필요한 순간에 가져오며, 세션을 넘어 유효한 기억을 남기는 것은 서로 다른 문제입니다.