Scoped Meta-Harness: 기업 AI 에이전트의 자기 개선 루프 설계 이론

AI 에이전트가 자신의 하네스(Harness)를 관측하고 개정 제안을 반환하는 메커니즘 — 메타 하네스 (Meta-Harness) — 는 코딩 에이전트와 퍼스널 AI 영역에서 구현이 진행되고 있으며, 설계 패턴으로서 윤곽이 드러나기 시작했다. Stanford / KRAFTON / MIT에 의한 Meta-Harness 논문 (Lee et al., 2026), UBC / Meta / Edinburgh 등에 의한 HyperAgents (Zhang, J. et al., 2026), Fudan / Peking University 등에 의한 Agentic Harness Engineering (AHE; Lin, J. et al., 2026)과 같은 프리프린트(preprint) 계통이 병행하여 진행되고 있으며, auto-harness나 SICA, HALO와 같은 오픈 소스 구현도 공개되어 있다. 이것들은 평가 함수가 명확하고, 개정 대상이 단일 프로세스 내에 닫혀 있는 영역에서 기능한다. 본고에서 다루는 것은 그 이론을 기업 AI 에이전트의 운용 환경으로 가져왔을 때 무엇이 변하는가에 대한 설계론이다.

본고의 주장은 다음과 같다. 메타 하네스의 골격 — 에이전트가 자신의 하네스를 관측하고 개선안을 제안하는 루프 — 는 운용 주체가 개인에서 기업으로 바뀌어도 유지할 수 있다. 하지만 설계상의 전제가 여러 축에서 반전된다. 무엇이 반전되며, 그것을 구조로서 어떻게 수용할 것인가가 본고의 주제이다.

필자는 전고에서 개인 AI 에이전트의 메타 하네스 구현을 다루었으나, 본고에서는 메타 하네스의 기업 도입 그 자체에 대한 설계론에 대해 논한다.

본고의 스코프 (Scope)

메타 하네스라는 용어는 연구 문맥과 운용 문맥 사이에서 의미가 흔들린다. 본고에서는 이를 명확히 정의해 둔다.

하네스 (Harness) 란, AI 모델이 입력을 받아 출력을 반환하기까지 통과하는 모든 주변 구조 — 프롬프트 (Prompt), 도구 정의 (Tool definition), 참조 데이터 (Reference data), 워크플로 (Workflow), 메타 파일 (Meta file), 가드레일 (Guardrail) — 를 가리킨다. 같은 모델이라도 하네스가 다르면 다른 에이전트가 된다.

메타 하네스 (Meta-Harness) 란, AI 에이전트 스스로가 자신을 둘러싼 하네스를 관측·평가하고 개정 제안을 반환하는 메커니즘을 가리킨다. AI가 직접 하네스를 다시 쓰는 것은 아니다. 본고에서는 관측·제안은 AI가 담당하고, 개정의 실행은 인간의 승인을 거쳐서야 비로소 반영되는 설계를 기업 운용에서의 기본형으로 한다.

본고가 다루는 대상은 AI 에이전트 주변의 하네스 층(프롬프트, 규칙 세트, 분류 체계, 스킬 정의, 평가 로직)의 자기 개선이다.

보충하자면, AI가 코드 변경안을 생성하고 인간의 승인을 거쳐 본번에 반영하는 운용 — Claude Code나 Codex CLI로 대표되는 PR 워크플로 — 는 이미 실전 운용에 들어가 있으며, 본고는 그것 자체를 부정하는 것이 아니다. 본고가 실용 영역에 있지 않다고 보고 대상 외로 두는 것은, Meta-Harness 논문의 outer loop에 대표되는 AI가 자신의 코드나 하네스를 완전히 자율적으로 개정해 나가는 시나리오를 기업의 업무 시스템 본체에 적용하는 형태이다. 이것은 현시점의 할루시네이션 (Hallucination) 제어로는 실용 영역에 있지 않다. 제약이라기보다는 현시점에서 지켜야 할 설계상의 대상 범위 설정이다. 근거는 본고 후반에서 다시 정리한다.

엔지니어의 책임 범위, 메타 하네스의 책임 범위

본론에 들어가기에 앞서, 기업 메타 하네스를 이야기할 때 가장 중요한 구분을 먼저 제시해 둔다. 시스템의 요건을 정하는 것은 엔지니어의 책임 범위이며, 정해진 요건의 범위 내에서 개선을 수행하는 것이 메타 하네스의 책임 범위이다.

이것은 두 자가 서로 다른 일을 병행하고 있다는 이야기가 아니다. 같은 "기업 AI 에이전트를 건전하게 운용한다"라는 하나의 연속된 설계 문제가 있으며, 그 안에서 어디서부터 어디까지가 인간이 맡아야 할 책임이고, 어디서부터가 자동화에 맡겨질 책임인지를 구분하는 것이다. 경계선이 명확해지면 양자의 관계성도 자연스럽게 결정된다.

이 구분은 전고에서 논한 퍼스널 AI 에이전트의 구현론에서 제시한 원칙 — "하네스는 경계를 정의한다. 에이전트는 그 경계 내에서 자율한다" — 를 기업 문맥으로 가져온 결과이다.

엔지니어 (사내 엔지니어, 외부 수탁 엔지니어, Forward Deployed Engineer 계열의 직능 등, 조직에 따라 호칭은 다양하지만 본고에서는 편의상 "엔지니어"라고 총칭한다)의 책임 범위에는 다음이 포함된다.

AI 에이전트의 담당 태스크, 이용 도구, 참조 데이터, 출력처 — 즉 에이전트의 직무 범위 그 자체의 정의
여러 부서로부터의 요청이나 업무상의 피드백을 집약하여 시스템 요구사항(System Requirements)으로 구체화하는 작업
어디를 메타 하네스(Meta-Harness)의 개선 대상으로 할 것인지, 어디를 건드리지 않게 할 것인지에 대한 경계 설계
개선 제안의 평가 기준, 배포(Deploy) 조건, 승인 권한의 계층 설계

메타 하네스의 책임 범위는 엔지니어가 사전에 선언한 경계 내부에 닫혀 있는, 매우 한정적인 영역이다.

구조화된 신호(도구 실행 로그, 정량적 메트릭스(Metrics), A/B 테스트 결과 등)를 관측한다
관측 결과로부터 정의된 개선 대상(프롬프트(Prompt), 스킬 정의, 분류 체계 등)에 대한 개선안을 생성한다
개선안을 승인 파이프라인(Approval Pipeline)으로 보낸다

이 책임 범위의 경계선을 처음에 고정함으로써, 후속 논의에서 반복적으로 나타나는 의문 — "누가 요구사항의 발산을 억제하는가", "어떤 기능을 구현할지는 누가 결정하는가" — 이에 대해 통일된 답을 내놓을 수 있다. 이것들은 엔지니어의 책임 범위에 속하는 판단이며, 메타 하네스에 위임해야 할 판단이 아니다. 메타 하네스는 엔지니어가 정한 경계 내부에서 기능하는 메커니즘으로서 설계하는 것이 바람직하며, 경계 그 자체를 움직이는 권한은 부여하지 않는 것이 좋다.

이 전제 하에, 기업용 메타 하네스의 설계 요구사항을 구체화한다.

기업용 메타 하네스의 설계 요구사항

기업 AI 에이전트의 메타 하네스는 세 가지 요구사항을 충족해야 한다.

1. Bounded — 개선 스코프를 사전에 닫을 것

에이전트에는 명확한 직책이 할당되며, 개선 대상은 직책 내에서의 정밀도 향상(정답률, 실패율, 응답 시간, 오판율)으로 한정된다. 스코프의 확대 — 스코프 크립(Scope Creep) — 를 방지하는 것 자체가 요구사항이 된다.

이 요구사항은 설계의 방향성 그 자체를 규정한다. Bounded 된 개선 루프는 신호원(Signal Source), 개변 대상, 평가 기준을 사전에 모두 정의하지 않으면 작동할 수 없다. "우선 운용을 시작하고 상황을 보면서 조정한다"라는 운용 방침은 기업 맥락에서는 성립하지 않는다. 사전에 모든 경계를 선언하는 설계 비용은, 운용 시작을 위한 임계값으로서 처음에 지불해야 할 비용이 된다.

그리고 이 설계 비용을 지불하는 것은, 전절에서 언급했듯이 엔지니어이다.

2. 신호원은 관측 가능하고 구조화된 데이터로 한정될 것

메타 하네스의 자동 루프에 직접 태울 수 있는 신호는, 관측 가능하고 사전에 구조화된 신호로 한정된다. 구체적으로는 다음과 같다.

도구 실행 로그(성패, 에러 코드, 실행 시간, 호출 패턴)
벤치마크 스코어(정답률, F1, 레이턴시(Latency) 등 정의된 정량적 메트릭스)
A/B 테스트나 섀도 배포(Shadow Deployment)의 결과(버전 간의 정량적 비교)
구조화된 사용자 조작(Good/Bad 버튼, A/B 선호 클릭, 출력의 채택/기각/편집 조작 로그)
명문화된 규칙 위반 시그널(사내 규약이나 SLA의 임계값 초과, 컴플라이언스 체커(Compliance Checker)로부터의 자동 탐지)

이것들은 AI가 직접 읽어 들여 개선안을 생성할 수 있다. 반면, 자유 기술 형식의 피드백이나 조직 내 여러 부서로부터의 요청을 어떻게 집약할 것인가와 같은 문제는 메타 하네스의 자동 루프 외부에서 다룬다. 왜 그렇게 되는지는 후단의 「메타 하네스가 기능하는 조건」에서 논한다.

3. 개변 가능 영역은 극도로 좁을 것

AI 에이전트 주변의 데이터는 가변성(Mutability)의 관점에서 두 가지로 나뉜다.

Type A (Append-only이며 위조 불가능한 데이터): 이력, 로그, 판단 기록, 계약, 거래 데이터, 의사록, 지식 베이스(Knowledge Base), 도구 실행 트레이스(Trace), 승인/기각 판단 로그. 사후에 정당성을 검증할 수 있는 상태로 남겨져야 하는 감사 및 컴플라이언스 대상 데이터의 대부분이 여기에 해당한다.

Type B (AI에 의한 개변 제안의 기점이 될 수 있는 데이터): 에이전트의 행동 규칙, 스킬 정의, 프롬프트 템플릿(Prompt Template), 워크플로우(Workflow) 정의, 에러 처리 절차, 분류 체계. 에이전트의 거동을 규정하는 메타 파일군.

기업 운용에서는 많은 데이터가 Type A 측에 편중되어 있다. 기업 데이터의 상당수가 감사 요구사항과 운용 요구사항 때문에 위조 불가능하게 취급되어야 하기 때문이다. 그 결과, 메타 하네스의 Type B는 극히 제한적이 된다 — 위의 제한적인 리스트 안에 수렴한다. 개선 대상 영역이 좁다는 것은, 그 좁은 영역 안에서 무엇을 어떻게 설계할 것인가가 매우 정밀하게 요구된다는 의미이기도 하다.

이 Type A / Type B 구분은 본고 전체를 통해 참조되는 설계 개념이며, 후속 논의(스코프 설계, 승인 파이프라인, 개변 제안의 범위)는 모두 이 2가지 분류를 기반으로 한다.

Scoped Meta-Harness: 2층 스코프 설계

지금까지의 설계 요구사항을 구현으로 옮기면, 기업용 AI 에이전트의 메타ハーネス (Meta-Harness)는 2층 스코프 설계 (2-layer scope design) 로 구성된다.

Layer 1: 에이전트 본체의 스코프. 이 에이전트가 어떤 태스크 (Task)를 담당하는가. 어떤 도구 (Tool)를 사용할 수 있는가 (읽기 전용인가 쓰기 가능인가). 어떤 데이터를 참조하는가. 출력은 어디로 전달하는가. 에이전트의 '직무 범위'에 대한 정의.

Layer 2: 개선 루프의 스코프. 메타ハーネス (Meta-Harness)가 무엇을 신호원 (Signal source)으로 삼는가. 무엇을 개변 제안할 수 있는가 (프롬프트, 규칙 세트, 분류 체계, 스킬 정의 등). 어디에는 절대로 손대지 못하게 할 것인가 (시스템 아키텍처, 업무 코드 본체, 인사 정보 등). 벤치마크 (Benchmark)는 어떻게 정의할 것인가.

이 2개 층은 일치해야만 한다. 이것이 Scoped Meta-Harness 설계의 가장 중요한 원리이다.

Layer 1에서 'API 에러 분석 에이전트'라고 정의했는데, Layer 2의 개선 루프가 기업 시스템 전체를 관측할 수 있는 상태라면, 개선 제안은 필연적으로 경계를 넘게 된다. "이 에러의 본질은 인증 플로우 (Auth flow) 설계에 있다. Auth0에서 Cognito로의 이전을 권장한다"와 같은 제안이 에러 로그 분류 에이전트의 개선 루프에서 올라온다. 기술적으로는 타당하더라도, 운영 관점에서 즉시 그 제안이 수용될 가능성은 거의 제로에 가까우며, 토큰 (Token)을 낭비하는 것으로 끝날 뿐이다.

스코프의 선언은 설계 시점에 고정한다

Layer 1의 스코프는 운영 시작 전에 명시적으로 선언되어야 하며, 구조화된 설정 파일 (TOML이나 YAML 등의 스키마가 포함된 정의 파일)로서 고정된다. 담당 태스크, 허가된 도구, 참조 데이터, 출력처, 각 I/O의 제약 사항 — 이것들을 설계 시점에 모두 작성해야 한다. 나중에 에이전트에게 새로운 도구나 새로운 직책을 "편리하니까"라는 이유로 추가해 나가는 운영 방식은 구조적으로 스코프를 용해시킨다.

이는 미학의 문제가 아니라 성능의 문제이기도 하다. Berkeley Function Calling Leaderboard (Patil et al., 2025, ICML)를 핵심으로 하는 일련의 연구들은 도구의 수가 늘어날수록 LLM의 올바른 도구 선택 정확도가 급락한다는 것을 반복해서 보여주었다. Gan & Sun (2025)의 RAG-MCP는 MCP 풀 규모의 확대에 따른 도구 선택 정확도의 단조 감소를 독립적으로 입증하였으며, 선택지의 증가가 단순히 토큰 소비의 문제가 아니라 선택 정확도 그 자체의 문제임을 명시하고 있다. 구체적으로, 해당 논문의 MCP stress test에서 베이스라인 기법 (Blank Conditioning)의 도구 선택 정답률은 도구 후보 수의 증가에 따라 13.62%까지 저하되었으며, retrieval 기반의 도구 선택 도입을 통해 43.13%로 3배 이상 개선됨이 나타났다. 나아가 해당 논문의 position 100 이후 평가에서는 선택 실패가 성공을 상회하는 영역으로 진입함이 보고되었으며, 도구 수의 확대가 단순한 토큰 소비 문제를 넘어 선택 정확도 자체를 파괴하는 현상이 정량적으로 확인되었다. Zhang, K. et al. (2026)은 의미적으로 유사한 distractor 도구가 존재하는 상황에서는 도구 추가 자체가 정확도를 떨어뜨리는 "tool-use tax"로 작용함을 정식화하였고, 도구 확장이 예상치 못한 문맥에서 다른 도구의 선택을 방해하는 기제를 보여주었다. Anthropic의 내부 측정에서도 58개의 도구 정의는 약 55,000 토큰을 소비하며, 선택지가 늘어남에 따라 정답률이 저하된다. LiveMCPBench (arXiv:2508.01780)를 통한 독립적인 검증에서는 12개의 프론티어 LLM을 실제 환경의 MCP 태스크로 평가한 결과, Claude-Sonnet-4가 78.95%의 태스크 성공률에 도달한 반면, 대부분의 모델은 30~50% 범위에 머물렀으며, 실패의 약 절반이 도구 검색 단계의 오류에 기인한다고 보고되었다.

이러한 사실들은 Layer 1 설계에 대해 엄격한 요구를 던진다. "만약을 위해 사용할 수 있는 도구를 늘려두자", "언젠가 필요할 것 같으니 직책을 넓혀두자"라는 설계 판단은, 현재 사용되지 않는 선택지가 언젠가 사용하게 될 선택지의 정확도를 확실하게 떨어뜨린다. 스코프의 넓이는 그 자체로 비용이다.

그리고 Layer 2(개선 루프, Improvement Loop)는 이 Layer 1의 선언을 엄격히 따른다. 개선 에이전트(Improvement Agent)는 자신이 개선 대상으로 삼는 에이전트의 선언 파일을 가장 먼저 읽고, 그곳에 기재된 담당 태스크, 허가된 도구, 참조 데이터의 범위 내에서만 개선 제안을 수행한다. 스코프 외의 에러, 스코프 외의 개선 대상, 스코프 외의 도구 추가 — 이들은 구조적으로 제안이 불가능하도록 개선 에이전트의 프롬프트(Prompt)와 액세스 제어(Access Control) 양쪽 모두에서 차단한다.

케이스 스터디: API 에러 분류 에이전트

구체적인 사례로 살펴보자. 운영 환경의 API 에러 로그를 지속적으로 분류하고, 근본 원인 가설을 제시하는 에이전트를 설계한다.

Layer 1 설계 (설계 시 고정):

태스크: 운영 API 에러 로그로부터 기정 패턴 분류 및 근본 원인 가설 제시
사용 도구: 로그 검색, 스택 트레이스(Stack Trace) 분석, 변경 이력 참조 (모두 Read-only)
참조 데이터: 최근 30일간의 에러 로그, 기지 장애 DB, 배포 이력
출력 대상: 온콜(On-call) 엔지니어의 Slack 채널

Layer 2 설계:

신호원(Signal Source): 분류 결과에 대한 온콜 엔지니어의 채택 여부, 근본 원인 가설의 검증 채택률 (모두 구조화된 정량적 신호)
개변 제안 가능 영역: 에러 패턴 분류 체계, 근본 원인 규칙 세트(Rule Set), 입력 프롬프트
개변 불가능 영역: API 코드 본체, 인프라 구성, Slack 알림 규칙 본체, 신규 도구 추가, 신규 데이터 소스 추가
벤치마크: 분류 정확도, 가설 채택률, 오분류율의 추이

이 설계에서 본질적으로 수행하고 있는 것은, '에이전트가 보는 데이터 범위'와 '메타 하네스(Meta-Harness)가 개선 대상으로 삼는 범위'를 의도적으로 일치시키고, 그 외의 개변 경로를 구조적으로 차단하는 것이다.

스코프를 나누지 않고 동일한 에이전트를 작동시키면, AI는 "이 에러 패턴이 빈번하게 발생하는 것은 인증 아키텍처의 설계 미스입니다. Auth0로부터의 탈피를 권장합니다", "에러 핸들러의 설계를 전면 리팩터링(Refactoring)해야 합니다"와 같이, 운영 관점에서는 즉시 거부될 제안을 출력한다. 이는 AI의 판단이 틀린 것이 아니다. 그러한 제안이 발생하는 구조를 하네스 설계 단계에서 이미 포함시켜 버린 것이 구조적인 원인이다.

이 설계 문제는 진단형 에이전트에 국한되지 않는다. 영업 통화 녹취록에서 의사 결정권자·예산·도입 시기를 추출하여 CRM에 기록하는 추출형 에이전트, 계약서를 요약하여 조항 리스크를 평가하는 평가형 에이전트, 사내 지식으로부터 FAQ 후보를 생성하는 생성형 에이전트 등, 어떤 경우라도 Layer 2의 스코프를 나누지 않으면 AI는 "애초에 이 CRM의 필드 구성이 부적절하므로 재설계해야 합니다"와 같은 월권 제안을 반환한다. 태스크의 형식이 다르더라도 구조적 실패는 동일한 지점에서 발생한다. Scoped Meta-Harness는 에이전트의 유형에 의존하지 않는 범용 설계 원리로 기능한다.

개선과 사양 변경의 구별

여기서 Scoped Meta-Harness를 운용할 때 결정적으로 중요한 구분을 도입한다. 개선(Improvement)과 사양 변경(Spec Change)은 별개의 것으로 취급되어야 한다.

개선(Improvement): 설계 시 선언된 Layer 1 스코프 내부에서 정확도·효율·정답률·오판율을 향상시키는 작업. 프롬프트 템플릿 수정, 스킬 설명문 정교화, 에러 핸들링 로직 조정, 분류 카테고리 세분화 — 이것들은 개선이다.

사양 변경(Spec Change): Layer 1 스코프 자체를 변경하는 작업. 새로운 도구의 추가, 새로운 데이터 소스로의 연결, 에이전트의 담당 태스크 확장, 출력 대상 추가 — 이것들은 사양 변경이다.

메타 하네스가 다루는 것은 개선뿐이다. 사양 변경은 메타 하네스의 자동 루프 안에서 발생해서는 안 된다.

왜인가? 사양 변경을 허용하면 개선 루프는 무한히 스코프를 확장할 수 있게 된다. 어느 시점에 "이 에러를 해결하기 위해서는 새로운 API를 호출할 수 있어야 한다"라는 제안이 통과되면, 그 API가 새로운 신호원이 되고, 새로운 에러 패턴이 관측 대상이 되며, 이를 해결하기 위해 또 새로운 역량(Capability)이 필요하게 되는 — 이러한 연쇄가 멈추지 않게 된다. 개선 루프는 표면적으로는 지속적으로 '개선'을 이어가고 있지만, 에이전트의 실체는 원래의 설계로부터 완전히 괴리되어 간다. 전절에서 언급한 도구 수 증가에 따른 정확도 저하는 이러한 확장이 일어날 때마다 누적적으로 겹쳐진다. 사양 변경을 포함한 자기 개선은 장기적으로 구현을 발산(Divergence)시키고, 에이전트 자체의 신뢰성을 파괴할 가능성이 있다.

다만, 이러한 구분을 실무에서 항상 명확하게 긋기는 어렵다. 경계가 모호해지는 전형적인 사례 3가지를 들어보겠다.

분류 카테고리의 세분화. 에러 분류 체계에서 "인증 에러"를 "OAuth 토큰 만료", "세션 만료", "권한 부족"으로 나누는 제안을 가정해 보자. 기존의 신호원(Error Log)과 기존의 참조 데이터(Error Pattern DB) 내부에서 새로운 구분이 성립한다면 이는 개선(Improvement)이다. 하지만 새로운 구분을 성립시키기 위해 인증 플로우의 트레이스 데이터(Trace Data)가 새로 필요해진다면, 이는 새로운 신호원의 추가 — 즉, 사양 변경(Specification Change)에 해당한다. 표면적으로는 "분류를 세분화했을 뿐"으로 보일지라도, 구현의 전제 조건이 바뀌었다면 사양 변경이다.

Few-shot 예시의 교체 및 추가. 프롬프트(Prompt)에 포함되는 예시의 질을 높이는 것은 개선이지만, 예시가 새로운 데이터 카테고리(지금까지 에이전트가 다루지 않았던 유형)를 포함하여 결과적으로 에이전트가 "이것도 자신의 담당 범위다"라고 해석하도록 바뀐다면, 이는 직무 범위의 암묵적인 확장으로서 사양 변경에 해당한다. Few-shot은 단순한 예시처럼 보이지만, 에이전트의 판단 범위를 선언하는 기능적 측면이 있기 때문에 여기에는 세심한 주의가 필요하다.

도구 기술(Tool Description)의 편집. AHE 논문에서 개정 대상으로 명시하고 있는 영역이며, 메타ハーネス(Meta-Harness) 연구에서 가장 활발하게 논의되는 개정 경로 중 하나이다. 동일한 도구의 호출 방식을 명확히 하는 것은 개선이지만, 기술 변경을 통해 "호출해도 좋은 상황"에 대한 해석이 넓어지는 경우 — 예를 들어 "읽기 전용 쿼리에 사용한다"를 "데이터 확인 전반에 사용한다"로 고쳐 쓰는 경우 — 실질적으로 행동 규칙의 변경이며, 사양 변경의 경계에 걸치게 된다.

이러한 경계 사례들을 통해 알 수 있는 것은, 판정 기준이 **"문면상의 변경이 작은가"가 아니라 "변경 후에 에이전트가 접하는 신호원·참조 데이터·출력 범위가 확장되는가"**라는 한 점으로 수렴된다는 것이다. 개선 에이전트의 자문은 더 정확하게 다음과 같이 바뀔 수 있다: "이 변경은 Layer 1에서 선언된 I/O 경계를 전혀 움직이지 않고 구현 가능한가?" 이를 충족하지 못하는 제안은 개선 루프(Improvement Loop) 밖으로 격상시킨다.

이 자문을 개선 에이전트의 프롬프트 레벨에서 명문화하여, I/O 경계의 차분을 구조적으로 평가할 수 있도록 한다. 제안이 이 경계 조건을 충족하지 않을 경우, 개선 에이전트는 제안을 수행하지 않고, 대신 "이것은 스코프 확장 요구사항이며, 인간에 의한 사양 판단이 필요함"이라고 플래그(Flag)를 세우는 것에 그친다.

사양 변경의 판단은 인간 — 엔지니어와 업무 책임자 — 가 개선 루프 밖에서 수행한다. 서두의 역할 분담에 따르면 이는 당연한 귀결이다. 새로운 Capability(역량)가 정말 필요한지, 그 추가가 다른 에이전트나 업무에 어떤 영향을 미치는지, 도구 수의 증가로 인해 기존 스킬 선택 정밀도가 어떻게 변화하는지, 컴플라이언스(Compliance) 영향은 어떠한지 — 이들은 개선 루프의 스코프를 넘어선 경영·운영 판단이며, AI가 자율적으로 결정해야 할 사항이 아니다.

메타ハーネス가 기능하는 조건

지금까지 메타ハーネス는 "관측 가능하고 구조화된 신호가 있으며, 명확한 평가 기준이 있을 때" 기능하는 메커니즘임을 서술해 왔다. 역으로 말하면, 그 조건이 갖춰지지 않은 곳에서는 메타ハーネス를 억지로 작동시키려 해도 발산(Divergence)하게 된다.

이 성립 조건은 코딩 에이전트의 자기 개선 연구를 통해 실증적으로도 뒷받침되고 있다. Robeyns et al.(2025)의 SICA는 SWE-Bench Verified라는 Ground Truth(정답지)가 확립된 영역에서 에이전트의 자기 개선을 17%에서 53%로 끌어올렸다. Agrawal et al.(2025)의 GEPA는 구조화된 텍스트 Feedback(실행 로그, 트레이스, 에러 메시지 등)이 스칼라 보상(Scalar Reward) 기반의 강화학습(RL)보다 더 효율적으로 프롬프트를 최적화할 수 있음을 보여주었다. 두 연구 모두 평가 함수가 Verifiable(검증 가능)하고 신호가 구조화되어 있다는 전제하에서의 결과이며, 본고가 기업 문맥에서의 필요 조건으로 정리하는 3가지 조건과 일치한다.

조건을 조금 더 구체화하면, 자동 루프가 성립하는 것은 다음 세 가지가 갖춰졌을 때이다.

신호가 구조화되어 있다: 성공/실패를 바이너리(Binary)로 취할 수 있고, 정량적 메트릭(Metric)이 정의되어 있으며, 선호 데이터(Preference Data)를 이산적으로 취할 수 있는 등
신호원의 역할이 단일한 문맥에 갇혀 있다: 신호의 발생원이 에이전트의 직무 범위와 일치하며, 다른 문맥의 신호가 혼입되지 않음
평가 기준이 사전에 명문화되어 있다: 무엇을 "개선"으로 판정할지가 릴리스(Release) 전에 결정되어 있음

이 3가지 조건이 갖춰지지 않은 영역 — 여러 부서로부터의 자유 기술(Free-text) 요구사항, 조직 간의 우선순위 조정, 업무 요건 그 자체의 정의 — 은 애초에 메타 하네스(Meta-Harness)의 스코프(Scope)가 아니다. 그것들은 엔지니어의 책임 범위로서 메타 하네스의 외곽에서 다루어야 한다.

이 점은 기업 도입 현장에서 솔직하게 인식할 필요가 있다. "기업용 메타 하네스를 도입했습니다"라고 주장하면서, 실체는 엔지니어가 자유 기술 피드백을 해석하고 구조화하여 개선 대상을 특정하는 운영 방식은, 본고의 정의에 따르면 좁은 의미의 메타 하네스가 아니다. 넓은 의미의 메타 하네스로 포함할 수는 있겠지만, Lee et al.의 논문에서 제시된 평가 함수(Evaluation Function) 기반의 outer loop가 자율적으로 돌아가는 것과는 자율성 수준에서 명확한 차이가 있다.

즉, 기업 AI 에이전트의 메타 하네스는 평가 기준과 관측 신호가 사전에 명확하게 정의된 영역에서만 자동화가 성립하는 메커니즘이다. 다음 절에서는 그 성립 조건을 만족하는 구체적인 구현 패턴을 제시한다.

메타 하네스 구현 패턴

지금부터는 기업 환경에서 실제로 메타 하네스를 구동하고 있거나, 구동할 수 있는 구체적인 구현 패턴 4가지를 소개한다. 모두 전절의 3가지 조건 — 구조화된 신호(Structured Signal), 문맥의 단일성(Singularity of Context), 명문화된 평가 기준 — 을 만족하는 케이스이다.

패턴 1: 도구 실행 에러의 자기 개선

가장 기본적인 구현 패턴이다. 에이전트가 이용하는 도구(API, 스크립트, CLI)의 실행 로그를 신호원(Signal Source)으로 삼아, 에러율이 높은 도구나 스킬의 정의 및 구현을 개선한다.

신호원:

도구 실행 로그 (성공 여부, 에러 코드, 인자(Argument) 패턴)
동일 에러의 발생 빈도와 컨텍스트(Context)

개선 에이전트의 동작:

일간·주간 단위로 실행 로그를 집계하여 에러율 임계치를 초과한 도구를 추출한다.
에러 패턴을 분류하고 근본 원인 가설을 세운다.
가설에 따라 개선안을 생성한다:
- 인자 사용법이 잘못된 경우 → 스킬 정의 파일(SKILL.md)의 기술 내용을 개정
- 예상치 못한 엣지 케이스(Edge Case) → 스크립트 본체나 에러 핸들링(Error Handling) 로직을 개정
- API 사양 변경에 대한 추종 누락 → 해당 API 호출부의 개정

배포 플로우(Deployment Flow):

개선안을 개발 환경에 배포
과거 로그의 리플레이 테스트(Replay Test)를 통해 회귀(Regression)가 없는지 확인
섀도 배포(Shadow Deployment) 또는 A/B 테스트를 통해 운영 환경 영향을 측정
개선이 확인된 경우, 엔지니어 승인 → 클라이언트 승인 → 운영 배포

이 패턴은 Layer 1에서 허용된 도구 세트 자체를 바꾸는 것이 아니다(그것은 사양 변경 영역이다). 어디까지나 기존 도구의 호출 방식이나 주변 로직을 개선하는 데 그친다.

패턴 2: 챗봇의 구조화된 사용자 피드백

사내용 FAQ 봇이나 서포트 챗봇 등, 엔드 유저(End-user)로부터 직접 피드백을 받을 수 있는 영역이다. 전절의 3가지 조건이 가장 잘 갖춰진 대표적인 사례이다.

신호원:

각 응답에 대한 good / bad 버튼 조작
동일 질문에 대한 신구 버전 A·B의 선호 클릭
에스컬레이션(Escalation) 비율 (봇의 응답 후, 인간 오퍼레이터에게 인계된 비율)
평균 응답 시간, 컴플라이언스(Compliance) 위반 탐지율

개선 에이전트의 동작:

저평가된 응답 클러스터(Cluster)를 추출하고 공통 패턴을 특정한다.
프롬프트(Prompt), 응답 템플릿, 참조 지식(Knowledge) 취득 로직의 개선안을 생성한다.
후보 버전을 개발 환경에 생성한다.

배포 플로우(Deployment Flow):

신규 버전 후보를 섀도 배포(Shadow Deployment)로 구버전과 병행 실행한다.
일정 트래픽이 경과한 시점에서 메트릭(Metric)을 집계한다.
사전에 정의된 여러 메트릭 임계치(예: 정답률이 구버전 대비 +3% 이상, 에스컬레이션 비율이 악화되지 않음, 응답 시간이 허용 범위 내임, 컴플라이언스 위반율이 증가하지 않음)를 모두 만족하는지 판정한다.
기준을 만족하는 후보만이 차기 버전으로 승격된다.

이 패턴의 핵심은 신호가 구조화되어 있고(클릭 조작은 바이너리 또는 이산 선택임), 신호원의 역할이 단일하며(사용자로서의 조작일 뿐, 업무 요건에 대한 의견은 혼입되지 않음), 평가 기준이 사전에 정의되어 있다(릴리스 기준은 메트릭 임계치임)는 3가지 조건이 모두 성립한다는 점이다.

패턴 3: RAG 에이전트의 스킬 업데이트

시간이 지남에 따라 참조 데이터가 축적 및 업데이트되는 RAG(Retrieval Augmented Generation) 에이전트는 메타 하네스(Meta-Harness)가 활약할 수 있는 영역 중 하나이다. 데이터의 내용이나 구조가 변화함에 따라, 이를 취득하고 처리하는 스킬(Skill) 또한 업데이트가 필요해진다.

신호원(Signal Sources):

RAG 검색 결과와 최종 응답에 대한 정답률 (평가 세트 기준)
검색 히트율(Hit rate), 검색 결과 이용률 (검색은 되었으나 사용되지 않은 비율)
사용자로부터의 "해당하는 정보를 찾을 수 없었습니다" 유형의 구조화된 피드백
신규 추가된 데이터 카테고리의 통계

개선 에이전트(Improvement Agent)의 동작:

검색 정밀도 메트릭(Metrics)이 저하된 영역을 특정
원인 분류:
- 검색 쿼리 생성 프롬프트가 새로운 데이터 카테고리를 따라가지 못함 → 프롬프트 개정
- 스킬 정의에 작성된 검색 전략이 노후화됨 → SKILL.md 개정
- 청킹(Chunking)이나 리랭킹(Re-ranking) 로직이 부적절함 → 처리 스크립트 개정
개선안 생성

배포 플로우(Deployment Flow): 패턴 2와 마찬가지로, 평가 세트를 통한 자동 평가와 섀도 배포(Shadow deployment)를 결합한 단계적 릴리스.

이 패턴은 데이터의 증감 및 변화에 따라 지속적인 미세 조정(Fine-tuning)이 필요하며, 사람이 일일이 따라가기 현실적으로 어려운 영역에서 특히 가치를 가진다.

패턴 4: 분류·추출 태스크의 정밀도 개선

송장(Invoice)에서의 필드 추출, 서포트 티켓의 분류, 계약 조항의 카테고리화 등, 정답(Ground truth)을 (완벽하지는 않더라도) 얻을 수 있는 태스크이다.