에이전트 스스로가 하네스(Harness)를 관찰하고 개수하는 메커니즘을 퍼스널 AI에 통합하면 어떤 일이 벌어지며, 어떻게 폭주를 막으며 구현할 것인가

TL;DR

• 퍼스널 AI 에이전트에 메타 하네스 (Meta-Harness) (에이전트 스스로가 하네스를 관찰·개수하는 메커니즘)를 통합함으로써, 자율적으로 자기 개선을 수행하는 에이전트가 도래한다. ― 사용자의 행동과 생활에 대한 적응과 에이전트 자신의 능력 개선이 시간이 흐름에 따라 병행하여 진행된다. - 자기 개수가 가능한 강력함은 자기 파괴가 가능한 공포와 동일한 메커니즘에서 온다. 질문은 "사용할 것인가"가 아니라 "어떻게 제어할 것인가"이다. ―
  에이전트에게 자유를 주는 것이 아니라, 자유의 경계를 정의하는 설계가 필요해진다. - 자율적인 개선은 신호원(Signal source)과 개수 대상이 서로 다른 두 계통(선호도(Preference) 층 / 실행(Execution) 층)으로 나뉘며, 동일한 개수 루프로는 다루기 어렵다. 각각에 적합한 메커니즘을 구축해야 한다. - 폭주를 방지하는 것은 "규칙"이나 "프롬프트(Prompt)"가 아니라,
  데몬(Daemon)과 API 게이트를 통한 물리적인 경계 제어, 사용자 피드백의 구조적 회수, 그리고 코드 층의 변경에 대한 승인 게이트 ― 이 세 가지의 조합이다.

1. 퍼스널 AI 에이전트와 메타 하네스

AI 에이전트를 개인용으로 운용하기 위한 정보는 지난 1년 동안 급격히 풍부해졌다. Karpathy의 LLM Wiki, Obsidian + Claude Code, 하네스 엔지니어링(Harness Engineering), 각종 Skills와 MCP의 구현 등이다. 나 자신도 이것들을 한 차례 운용 테스트하였으며, 현재는 직접 제작한 메타 하네스를 통합한 퍼스널 AI 에이전트를 실운용하고 있다. 본 기사는 그 설계와 운용을 통해 확신을 얻고 있는 이론을 정리한 것이다.

하네스(Harness)란 무엇인가

**하네스 (Harness)**란 LLM 모델 외부에 있는 프롬프트(Prompt), 도구(Tool), 메모리(Memory), 워크플로우(Workflow), 액세스 제어(Access Control)의 총칭이다. 모델이 입력을 받아 출력을 내보내기까지 거치는 주변 장치 전부를 가리킨다. 동일한 모델이라도 하네스가 다르면 에이전트의 거동은 완전히 달라진다.

Claude Code나 Cursor를 사용한 코딩 태스크에서 AI 엔지니어가 손에 익히고 있는 것이 바로 이 하네스의 조정이다. CLAUDE.md / .cursorrules를 작성하고, MCP 서버를 추가하며, 허용할 도구를 제한하고, 컨텍스트(Context) 관리 규약을 정하는 것 ― 이 모든 것은 하네스의 튜닝(Tuning)이며, AI 엔지니어에게는 이미 알려진 작업이다.

메타 하네스 (Meta-Harness) ― 하네스를 개수하는 하네스

**메타 하네스 (Meta-Harness)**는 이 하네스를 에이전트 스스로가 관찰·개수하는 메커니즘을 가리킨다.

Stanford / MIT / KRAFTON의 Meta-Harness 논문 (Lee et al., arXiv:2603.28052)은 메타 하네스를 평가 함수(Evaluation function) 구동형 outer-loop 최적화 계통으로 정식화하고 있다. agent proposer가 prior candidates의 소스 코드와 실행 트레이스(Execution traces)를 파일 시스템(Filesystem)을 통해 참조하면서, 평가 함수를 신호원으로 삼아 하네스의 소스 코드 자체를 자동 탐색 및 재작성한다. 이것이 "모델이 하네스를 개수한다"라는 발상의 강력하고 구체적인 구현 사례이다.

이러한 발상은 코딩 에이전트 분야에서 이미 여러 구현체로 나타나고 있다. MaximeRobeyns/self_improving_coding_agent (SICA, arXiv:2504.15228)는 에이전트 스스로가 자신의 코드베이스를 편집하여 개선하는 설계로, SWE-Bench Verified에서 17%에서 53%로의 개선을 보고했다. neosigmaai/auto-harness는 2026년 4월 공개 예정인 오픈 소스 시스템으로, 벤치마크 실행으로부터 실패 사례를 자동으로 마이닝(Mining)하고, 하네스를 반복적 편집(Iterative edit)으로 최적화하며, 회귀(Regression)에 대해서는 게이트(Gate)로 방어한다. Terminal-Bench 2.0 및 tau-bench에 대응한다.

이들이 공통적으로 다루고 있는 것은 코딩이라는 **"평가 함수가 명확한 단일 도메인"**에 대한 자기 개수다. 코드가 동작하는지 여부, 테스트가 통과하는지 여부 ― 이진(Binary)적인 성패가 그대로 신호원이 되어 평가 함수로서 기능한다.

퍼스널 AI 에이전트로의 전이 ― 나의 예측

나의 예측 ― 그리고 구현상의 확신 ― 은, 이 「에이전트가 하네스(Harness)를 스스로 개수한다」라는 발상이 코딩이라는 폐쇄된 영역에서 퍼스널 AI 에이전트(Personal AI Agent)로 전이될 것이라는 점이다. 코딩 에이전트에서 실증된 메타 하네스(Meta-Harness)는 SICA나 auto-harness와 같은 형태로 오픈 소스화되고 있으며, 그 설계 사상이 개인용 AI 영역으로 유입될 가능성은 매우 높다.

왜 그렇게 예측하는가. 범용 AI 어시스턴트의 한계를 운용자라면 누구나 느끼기 시작했기 때문이다. 수동적인 프롬프트 튜닝(Prompt Tuning), CLAUDE.md / .cursorrules와 같은 정적인 설정 파일, 매 세션마다 다시 지시해야 하는 사용자의 취향 ― 이것들로는 개인의 워크플로우(Workflow), 관심 영역, 생활 사이클의 변화를 완전히 따라갈 수 없다. 전자를 포함함으로써 경년(経年)에 따른 적응 정밀도를 높이기는 쉬워지지만, 후자는 그 여지가 부족하다. 장기 운용에서 개인에 대한 적응 정밀도를 높이는 가장 유력한 경로 중 하나는 에이전트 스스로가 하네스의 일부를 관찰하고 개수할 수 있도록 하는 것이다. 이는 코딩 에이전트가 선행하여 보여준 방향성이며, 퍼스널 영역에서도 같은 방향으로 수렴할 개연성이 높다.

다만, 전이되는 과정에서 메타 하네스의 **메커니즘(Mechanism)**은 재구성된다. 코딩 에이전트가 의존했던 「평가 함수(Evaluation Function)가 명확한 단일 도메인」이 퍼스널 AI에서는 현시점에서 성립하기 어렵기 때문이다.

따라서 본 기사에서는 메타 하네스를 Lee et al.의 평가 함수 구동에 의한 정식화를 하나의 구체적인 사례로 포함하는 더 넓은 umbrella 개념으로 사용한다. 즉, AI 에이전트가 하네스 자체(프롬프트 템플릿, 워크플로우 정의, skill 구현, 툴 액세스 제어, 메타 파일 등)의 일부를 관찰하고 개수할 수 있도록 설계된 하네스 전반을 가리킨다. 신호원이 평가 함수이든, 사용자 피드백이든, tool 실행 로그이든, 이를 통해 에이전트가 자신을 둘러싼 하네스를 업데이트하는 구조는 모두 메타 하네스이다.

왜 이 넓은 정의를 채택하는지, 그리고 어떤 신호원에 어떤 메커니즘이 대응하는지는 제3장의 구현론에서 차례대로 밝혀 나갈 것이다. 본 장에서 짚고 넘어가야 할 점은, 「코딩에서 작동했던 발상이 퍼스널 영역으로 온다」, 「단, 메커니즘은 복수로 존재하게 된다」 ― 이 두 가지뿐이다.

2. 메타 하네스를 포함한 퍼스널 AI 에이전트에서 어떤 일이 일어나는가

실제로 메타 하네스를 포함한 퍼스널 AI 에이전트에서는 어떤 일이 일어날까. 이 장에서는 구체적인 사례를 곁들여 설명한다. 구현 단계까지 깊이 들어가지는 않고, 「사용자 입장에서 무엇이 일어나는가」만을 나열한다.

2.1 사용자의 행동과 생활에 에이전트가 적응해 나간다

퍼스널 AI 에이전트는 여러 데이터 소스(Data Source)에 접속한다. 스케줄, 메일, Notion / Obsidian의 메모, 브라우저 히스토리, 건강(health) 데이터. 이것들을 단순한 「검색 가능한 아카이브(Archive)」로 취급하는 것이 기존의 Second Brain 방식이라면, 메타 하네스를 포함한 에이전트는 여기서 한 발짝 더 나아간다.

축적된 정보로부터 에이전트는 사용자의 프로젝트나 생활 사이클을 파악한다. 무엇을 안고 있는지, 언제 집중하는지, 무엇을 피하고 싶어 하는지, 어느 요일에 어떤 경향의 작업이 많은지. 이러한 파악을 통해 에이전트가 제공하는 거동은 다음과 같다.

스케줄 직전의 사전 알림과 관련 todo의 자동 추출. 회의 30분 전에 해당 회의에 필요한 사전 정보를 정리하여 제시한다. 몇 시에 무엇이 필요한지를 사용자가 지시하기 전에 준비한다. 추출된 todo 중 대행 가능한 것 ― 회의록 draft, 메일 답장 초안, 리서치 요약, 문서의 차이점 정리 ― 은 자동으로 진행한다.

더 나아가면, 사용자의 생활 사이클 분석 결과로부터 그 사람에게 최적화된 하루 / 일주일 스케줄을 제안하게 된다. 집중력이 높은 시간에는 깊은 작업(Deep Work)을, 낮은 시간에는 가벼운 작업을 수행하도록 하는 단순화를 넘어, 과거의 실행 로그로부터 「실제로 무엇이 진척되었는지」, 「무엇이 뒤로 밀렸는지」를 바탕으로 다음 주를 제안한다.

여기까지는 정적인 구현만으로도 어느 정도 실현 가능하다. 메타 하네스가 진정으로 효과를 발휘하는 지점은 사용자 피드백을 통해 에이전트가 하네스 자체를 다시 써 내려간다는(Rewrite) 점에 있다.

사용자가 이러한 태스크의 결과물을 확인하고 피드백을 보내면, 여기서 **메타 하네스 루프 (Meta-Harness Loop)**가 작동하기 시작한다. 에이전트는 피드백을 받아 근본 원인을 식별하고, 태스크를 실행하는 AI 에이전트의 정의 그 자체를 다시 쓴다. 구체적으로는 대상 에이전트의 메타 파일 (Meta-file) — 실행 시간, 기동 간격, 입력 프롬프트 템플릿 (Input Prompt Template), 출력 포맷 (Output Format), 참조하는 skill의 집합 — 을 수정함으로써 다음번 이후의 거동을 변화시킨다.

"제안의 입도가 너무 세밀하다"라는 말을 들으면 정보량에 대한 지정을 다시 쓰고, "출력 타이밍이 좋지 않다"라는 말을 들으면 기동 시간 그 자체를 다시 쓰며, "이런 종류의 리서치는 요청이 있을 때만 해줬으면 좋겠다"라는 말을 들으면 해당 에이전트의 기동 조건과 입력 프롬프트를 다시 쓴다. 에이전트가 직접 LLM의 가중치 (Weights)를 다시 쓰는 것이 아니라, 자신을 둘러싼 하네스 (Harness)의 설정을 사용자 피드백을 신호원으로 삼아 재구성해 나가는 것이다.

이는 전장에서 umbrella 개념으로 정의한 메타 하네스의 전형적인 동작이다. 신호원은 사용자 피드백 (정성적) 이며, Lee et al.이 사용한 평가 함수 구동 방식의 outer-loop와는 다르지만, "에이전트가 자신의 하네스를 관찰하고 개수한다"라는 골격은 완전히 동일하다. 중요한 점은, 훈련 (Training)이 아니라 선언과 다시 쓰기를 통해 alignment (정렬)가 움직인다는 점이다. 단 한 번의 피드백으로 메타 파일이 다시 써지고, 이후의 행동이 지속적으로 변한다. 즉, 다음번 다시 쓰기가 발생하기 전까지 그 변경 사항은 문맥의 일부로서 계속 남게 된다.

2.2 에이전트가 자신의 능력을 지속적으로 개선함

또 다른 계통은 사용자가 피드백을 보내지 않더라도 에이전트가 자율적으로 개선해 나가는 거동이다. 신호원은 tool의 실행 로그 (Execution Log) 이다. 어떤 skill이, 어떤 인자 (Argument)로, 몇 번 성공하고 몇 번 실패했는가. 실패했을 경우 어떤 에러가 반환되었는가. 이것들이 객관적인 실행 기록으로서 축적된다.

여기서 파생되는 거동은 다음과 같다.

토큰 비용 (Token Cost) 및 실행 시간의 절감: 동일한 태스크를 더 적은 단계로 완수할 수 있도록 skill 정의나 처리 플로우 (Process Flow)를 업데이트한다.

정답률 향상: tool 실행 에러나 사용자 지시 준수 실패를 집계하여, 근본 원인에 대응하는 수정을 가한다.

온디맨드 앱 (On-demand App)의 지속적 개선: 사용자 태스크를 완수하기 위해 생성한 script를 운용 중에 계속해서 다듬는다. 일회성 생성물이 아니라, 운용 중에 성장해 나가는 구현체다.

두 가지 구체적인 예를 제시한다.

구체적 사례 1: 하네스 내부의 불일치를 자기 수복함

나는 구현상 daemon이 제공하는 API의 사양을 업데이트할 때가 있다. 새로운 인자를 추가하거나, 응답 형식을 바꾸거나, 에러의 구조화를 바꾸는 등 어떠한 사양 변경을 가한 시점이다. 이 API를 호출하는 skills의 기술 — AI 에이전트가 "이 API는 이렇게 호출한다"라고 참조하고 있는 문서 — 는 본래 동시에 업데이트되어야 하지만, 어느 날 나는 그 업데이트를 누락했다.

에이전트 측에서 보면, skills의 기술에 따라 API를 호출하지만, API는 새로운 사양으로 동작하고 있으므로 인자 에러 (Argument Error)가 반환된다. 에이전트는 에러 메시지를 읽고, 메시지에 포함된 사양 정보를 바탕으로 올바른 호출 형식을 추정하여 재시도한다. 최종적으로는 호출이 성공하고 태스크는 완수된다.

여기까지는 특수한 거동이 아니다. 에러 → 분석 → 재시도는 현대의 에이전트가 일상적으로 수행하고 있는 일이다. 중요한 것은 그다음부터였다.

나는 자신의 skills 업데이트 누락을 잊은 채 며칠 동안 이 daemon을 계속 운용했다. 당연히 동일한 에러가 하루에도 몇 번씩 반복해서 발생하고 있었다. 에이전트는 매번 에러를 읽고, 매번 올바른 형식을 추정하며, 매번 재시도한다. 즉, 하나의 태스크를 수행할 때 불필요하게 2~3회 더 tool을 호출하게 되는 것이다. 비용도 실행 시간도 커지고 있었다.

이때 일간 자기 개선 프로세스가 이를 포착했다. 개선용 에이전트는 tool 실행 로그를 집계하여 특정 API에서 에러가 만성적으로 발생하고 있음을 탐지했다. 에러 로그를 정밀 조사하여 에러 내용과 빈도의 패턴으로부터, skills의 기술과 API의 실제 사양 사이에 지속적인 불일치가 있음을 특정했다. 개선용 에이전트는 나에게 skills의 수정안 — API의 최신 실행 형식 예시를 새로운 기술로 교체한다는 내용 — 을 제시했다. 나는 그것을 승인했다.

이후로는 동일한 에러가 거의 발생하지 않게 되었다. 에이전트(Agent)는 첫 시도부터 올바른 형식으로 API를 호출하게 되었고, tool 재시도 비용은 사라졌다.

여기서 일어나고 있는 것은, 에이전트가 에러를 「그 자리에서 극복하는」 것이 아니라, 에이전트를 둘러싼 하네스(Harness, skills의 기술)를 영구적으로 다시 작성함으로써 동일한 에러가 두 번 발생하지 않는 구조를 만드는 점이다. 전자는 에이전트의 통상적인 동작이며, 후자가 메타 하네스(Meta-Harness)의 동작이다. 일간 개선 프로세스는 「여러 차례의 실행을 가로질러 관찰한다」는 아우터 루프(Outer Loop) 위치에 있기 때문에, 만성적인 드리프트(Drift)를 탐지하여 영구적인 수정을 가할 수 있다.

에러 메시지를 설계의 일부로 심어두는 것 또한 이 메커니즘을 성립시키기 위한 전제 조건이다. 에러 메시지는 사용자에게 보내는 통지가 아니라, 미래의 에이전트에게 전달하는 지시서로서 기능한다. 에이전트는 「실패했으니까 멈춘다」가 아니라 「실패한 원인과 수정 방법이 기록되어 있으니까 고친다」는 동작을 하게 된다.

구체적 사례 2: 온디맨드 앱 ― 스크립트의 범용성을 경년(經年)적으로 획득해 나간다

또 다른, 더 넓은 형태로 일어날 수 있는 동작을 보여주고자 한다. 이것은 온디맨드 앱(On-demand App) ― 사용자의 의뢰를 받아 에이전트가 생성하고, 운용하면서 다듬어 나가는 도구 ― 의 자기 개선 사례이다.

예를 들어 사용자가 에이전트에게 "지정한 종목의 주가를 취득하여, 간단한 분석을 매일 보내달라"고 의뢰했다고 가정하자. 에이전트는 Python 스크립트를 생성하고, 이를 실행하기 위한 skills 기술을 만들어 daemon의 스케줄러에 등록한다. 처음 며칠 동안은 지시된 대로 특정 종목의 취득이 문제없이 작동한다.

하지만 운용해 나가는 과정에서 사용자는 "다른 종목도 체크하고 싶다", "어떨 때는 거래량만 알고 싶다", "결산 발표 후의 움직임을 보고 싶다"와 같이 당초의 지시 범위를 넘어서는 사용법을 시작한다. 최초의 스크립트는 특정 종목·특정 정보 취득에 특화된 구현이었기 때문에, 이러한 응용에는 대응하기 어렵다. 인자(Argument)가 고정되어 있거나, 대응하는 정보 축이 한정되어 있거나, 예상치 못한 케이스에서 핸들링 능력이 떨어지는 식이다. 에이전트는 그 자리에서는 skill의 사용법을 바꾸거나 인자를 시도하며 버티지만, 근본적으로 스크립트의 설계가 현재의 유스케이스(Use Case)에 맞지 않으므로 에러는 단속적으로 계속 발생한다.

여기서 자기 개선 프로세스가 효과를 발휘한다. 개선용 에이전트는 tool 실행 로그로부터 스크립트에 대한 호출 패턴이 당초의 설계를 넘어 확장되고 있다는 점, 그리고 그 패턴으로 인해 에러가 다발하고 있다는 점을 탐지한다. 그리고 단일 종목·특정 정보에 고정된 구현을 사용자가 실제로 수행해 온 호출 패턴에 대응할 수 있는 범용적인 구현으로 다시 작성할 것을 제안한다. 즉, Python 스크립트 본체와 그것을 호출하는 skills의 기술 양쪽을 동시에 수정한다. 사용자가 승인하면, 이후에는 그 확장된 능력을 가진 스크립트가 daemon 상에서 계속 동작한다.

여기서도 메타 하네스의 본질은 「에러를 그 자리에서 고치는 것」이 아니다. 여러 차례의 실행을 가로질러 관찰하고, 에이전트가 영구적으로 가지는 능력(스크립트와 그것을 구동하는 skill 정의)을 관찰된 사용 패턴에 맞춰 재정의하는 것에 있다. 단발적인 버그 수정은 통상적인 Claude Code 계열의 동작으로 완결되지만, 여기서 일어나고 있는 것은 에이전트의 능력 경계 자체를 다시 쓰는 것이다.

이 스크립트가 해결하는 과제의 레퍼토리는 시간과 함께 넓어진다. 리스트는 고정된 것이 아니라, 사용자가 새로운 질문을 던지고 새로운 사용법을 시도할 때마다 자기 개선 루프가 그것을 흡수해 나간다. 에이전트가 온디맨드로 도구를 만들고, 그것을 운용하면서 다듬어 나간다 ― 이것이 온디맨드 앱이라 부르는 동작의 본질이다.

범용 툴이 닿기 어려운 지점이 바로 이 개별화된 부분이다. 범용 툴은 「많은 사용자가 공통적으로 원하는 기능」까지만 만들기 쉽다. 퍼스널 AI 에이전트의 강점은 사용자의 실제 사용 패턴을 계속 관찰하며, 「나만이 원하는 도구」를 경년적으로 다듬어 나가는 점에 있다.

2.3 다만, 강함은 제어 불능과 맞닿아 있다

여기까지 읽고 "이것은 갖고 싶다"라고 느꼈다면, 동시에 "이것은 무섭다"라고도 느꼈을 것이다.

에이전트가 자신의 행동 규칙을 다시 쓴다. skill의 구현을 다시 쓴다. Python 스크립트를 다시 쓴다. 일간·주간 cadence(주기)로 자율적으로 이것들이 진행된다.

무엇이 폭주할 수 있는가. 에이전트가 잘못된 피드백을 정답으로 간주하여 규칙을 잘못 업데이트(誤更新)한다. 개선용 에이전트가 진정한 원인을 오해하여 작동 중인 skill을 파괴한다. 자율 사이클이 사용자가 원하지 않는 방향으로의 최적화를 지속한다. 혹은, 이러한 현상을 사용자가 인지하지 못한다.

메타 하네스(Meta-Harness)가 강력한 이유는 에이전트가 자기 자신을 개수(改修)할 수 있기 때문이다. 하지만 '개수할 수 있다'는 것은 '파괴할 수 있다'와 동의어이다. 동일한 메커니즘이 이익과 붕괴를 모두 낳는다.

따라서 퍼스널 AI 에이전트에 메타 하네스를組み込む(組み込む, 포함시키다)는 질문은, "사용할 것인가 / 사용하지 않을 것인가"가 아니다. **"어떻게 제어할 것인가"**이다. 에이전트에게 자유를 주는 것이 아니라, 자유의 경계를 정의하는 것 ― 여기서부터가 메타 하네스의 구현론이다.

3. 구현론 ― 폭주시키지 않는 경계 설계

제2장에서 본 동작 ― 피드백을 통해 메타 파일이 다시 쓰여지며 지속적으로 행동을 바꾸는 에이전트, 하네스 내부의 불일치를 스스로 수정하는 에이전트, 운용하면서 다듬어져 가는 온디맨드(On-demand) 앱 ― 을 어떻게 폭주시키지 않고 구현할 것인가. 본 장은 이 구현론을 다룬다.

메타 하네스의 구현은 에이전트가 발을 들여놓을 수 있는 곳과 들여놓을 수 없는 곳을 기제(Mechanism)로서 정의하는 것에 귀결된다. "규칙으로 묶는다"라거나 "프롬프트로 지시한다"는 것만으로는 불충분하다. LLM 기반의 에이전트는 지시에 대해 확률적으로 행동하며, 일탈을 완전히 방지할 수 없다. 경계는 코드 측에서 물리적으로 강제할 필요가 있다.

하네스는 경계를 정의한다. 에이전트는 그 경계 안에서 자율한다.

이것이 본 장을 관통하는 테제(Thesis)이다.

3.1 개선은 두 계통 ― preference(선호) 층과 실행 층

제2장에서 본 동작을 정리하면, 자기 개선의 방향은 두 가지로 나뉜다.

2.1에서 다룬 "사용자 피드백을 신호원(Signal source)으로 삼아 에이전트의 행동 규칙 / 메타 파일을 다시 쓰는 동작"과, 2.2에서 다룬 "tool 실행의 에러나 실행 로그를 신호원으로 삼아, 에이전트의 능력 그 자체(skill 정의, 스크립트, MCP 구현)를 다시 쓰는 동작"이다.

양자는 동일한 하네스 안에서 병행하여 움직이지만, 신호원도 개수 대상도 다르기 때문에 별개의 메커니즘을 필요로 한다. 본 기사에서는 이 두 계통을 각각 preference 층 / 실행 층이라 부른다.

preference 층에서는 평가 함수 구동의 적용이 제한적이다

preference 층은 **"무엇을 해야 하는가"**를 보정하는 계통이다. 여기서 중요한 사실을 하나 지적해 두겠다. Lee et al.이 정식화한 평가 함수 구동의 outer-loop는 preference 층에는 그대로 적용하기 어렵다. 그 이유는 퍼스널 AI 에이전트가 처한 구조적 제약에 있다.

범용 에이전트 ― 코딩, 리서치, 고객 지원(Customer Support) ― 에는 모두 벤치마크(Benchmark)가 있다. SWE-Bench, AppWorld, AgentBench, tau-bench, Terminal-Bench. 벤더(Vendor)는 이러한 벤치마크에 대해 하네스를 최적화할 수 있다. 사용자가 받는 것은 누군가가 이미 튜닝을 마친 scaffold(scaffold)이다.

하지만 퍼스널 AI에는 공유 가능한 벤치마크가 없다. "나에게 좋은 AI"의 평가 함수는 나 자신 안에 있어 타인과 공유하기 어렵고, 시간과 함께 변한다. 벤더 측에서 하네스를 범용적으로 최적화하는 것은 구조적으로 어렵다. 최적화의 대상이 안정적이지 않기 때문이다. Lee et al.이 보여준 "동일 모델이라도 하네스에 따라 최대 6배의 성공률 차이"는 범용 에이전트에서는 벤더가 회수하지만, 퍼스널 AI에서는 사용자마다 잠든 채로 남게 된다.

이 잠든 잠재력을 회수하는 수단은, 사용자 스스로가 하네스(Harness)를 계속해서 작성하거나, 에이전트 스스로가 자기 개수(Self-repair)를 수행하게 하는 것 ― 즉, 메타 하네스(Meta-Harness)를 내장하는 것 ― 이 현실적인 경로가 된다. 전자는 선호도(Preference)의 변화, 기술(Skill)의 퇴화, 프로젝트의 단계(Phase) 전환을 계속해서 추적하기가 쉽지 않다. 결과적으로 후자가 실용적인 측면에서 중심이 되며, 선호도(Preference) 층의 신호원(Signal source)은 사용자 피드백이라는 정성적·비정상적(Non-stationary) 신호가 주축이 될 수밖에 없다. 샘플 수가 적기 때문에, 과거의 샘플로 미래를 최적화하는 평가 함수(Reward function) 구동 방식의 접근법을 축으로 삼기는 어렵다.

다만 여기서 오해를 피하고 싶다 ― 평가 함수 구동 방식의 발상이 선호도(Preference) 층에서 완전히 사용할 수 없다는 뜻은 아니다. 개별 태스크의 완수도, 특정 지시에 대한 추종도, 약속한 시간에 약속한 행동을 취했는지 여부와 같은 부분 평가는 어느 정도 측정할 여지가 있다. 실제로 강화학습 (RL) 연구에서는 보상 모델(Reward model)을 부분적인 인간 피드백으로부터 학습시키는 접근법이 진행되고 있다. 하지만, 그것들을 집약하여 선호도 (Preference) 층 전체를 구동할 수 있는 안정적인 평가 함수를 구축하는 것은 현재의 개인 운용 환경에서는 어렵다. 이것이 제1장에서 「umbrella 개념」을 채택한 이유이기도 하다. Lee et al.의 정식화는 메타 하네스의 한 형태일 뿐이며, 선호도 (Preference) 층을 다루기 위해서는 그것과 병렬하는 또 다른 루프 ― 사용자 피드백을 주 신호원으로 하는 루프 ― 가 필요하다.

실행층에는 평가 함수 구동을 한정적으로 적용할 수 있다

실행층은 **「그것을 올바르게 실행하고 있는가」**를 보정하는 계통으로, 여기에는 Lee et al.의 발상을 한정적으로 적용할 수 있다. 도구(Tool) 호출은 특정 기술(Skill) 단위로 충분한 샘플 수가 축적되고, 성패는 바이너리(Binary)로 해석되어 편차가 적으며, 사용자의 기분에 의존하지 않는다. "Skill A의 성공률은 95%, Skill B는 40%"와 같은 객관적인 메트릭(Metric)을 측정할 수 있다 ― 즉, 퍼스널 AI 내부에 국소적인 벤치마크(Benchmark)가 성립한다.

양자는 대립하지 않고 보완 관계에 있다. 동일한 하네스 안에서, 신호원과 개수 대상을 분리하여 두 계통의 루프를 병행하여 돌린다. 이것이 퍼스널 AI에서의 메타 하네스의 기본 구조다.

이하에서는 먼저 구현의 최상위 구성(daemon과 AI 에이전트, 3.2)을 기술하고, 이어서 두 루프가 공유하는 지식(Knowledge) 아키텍처(3.3-3.4), 선호도(Preference)의 선언(3.5), 자율 사이클(3.6), 두 계통의 피드백 루프(3.7, 3.8), 이들의 통합(3.9), 마지막으로 할루시네이션(Hallucination) 대책(3.10)을 다룬다.

3.2 전체 구성 ― daemon과 AI 에이전트

구현의 최상위 레이어에는 daemon과 AI 에이전트 두 존재가 있다.

daemon은 상주 서비스로서 백그라운드에서 동작하는 제어층이다. 역할은 다음과 같다.

• AI 에이전트의 기동·정지·스케줄링
• 에이전트가 이용할 수 있는 도구의 허용(Allow) / 차단(Disable) 제어
• 지식(Knowledge)에 대한 쓰기를 중개하는 API 제공 및 경로(Path) / 범위(Scope) 검증
• 실행 로그와 피드백의 추가 전용(Append-only) 보관
• 외부 시스템(Gmail, Notion, 브라우저 히스토리 등)과의 데이터 동기화

AI 에이전트는 daemon이 설정한 경계 안쪽에서 동작하는 사고층이다. daemon이 허가한 도구와 API만을 사용하여 정보를 수집하고, 판단하고, 행동한다. daemon에게 허가되지 않은 도구에는 손을 대지 않으며, daemon을 경유하지 않는 쓰기(Write)는 구조적으로 불가능하다.

이러한 분업은 본 장 서두의 테제(Thesis) ― "하네스는 경계를 정의한다. 에이전트는 그 경계 내에서 자율한다" ― 의 가장 직접적인 구현이다. daemon이 경계를 정의하고, AI 에이전트가 그 안쪽에서 자율한다. LLM의 지성이나 규율로 경계를 지키게 하는 것이 아니라, daemon의 코드와 API 게이트를 통해 구조적으로 지키게 한다.

이하에서는 daemon과 AI 에이전트가 공유하는 지식(Knowledge) 영역의 구조부터 기술한다.

3.3 지식 (Knowledge) 아키텍처 ― 6개 클래스 분할

지식 (Knowledge) 아키텍처의 설계 축으로서, 나는 토픽(Topic)이 아닌 (authority × lifecycle × mutability)의 삼축을 채택하고 있다. 누가 그 데이터를 작성하는가, 얼마나 자주 변하는가, 다시 써도 되는가 ― 이 삼축의 교차점에서 디렉터리를 나눈다.

토픽으로 나누면 충돌이 발생하기 쉽다. 예를 들어 「리포지토리(Repository)」라는 토픽은 개요(slow-change의 reference)와 일일 로그(append-only narrative)를 포함하지만, 양자는 읽기 빈도와 쓰기 패턴이 완전히 다르다. 같은 디렉터리에 공존시키면 코드 측면에서 「이 디렉터리의 내용물은 무엇인가」를 일괄적으로 다루기 어려워지며, 파일 단위의 예외 처리(Exception Handling)가 증식하게 된다. authority와 lifecycle로 나누면 주입 정책(Injection Policy)과 쓰기 잠금(Write Lock)을 디렉터리 단위로 일괄 선언할 수 있다. 즉, 새로운 이벤트 타입을 추가할 때는 「어떤 클래스를 상속받을지」를 선택하는 것만으로 충분하다.

이 삼축으로 개인 메타 하네스(Meta-Harness)를 나누면, 6개의 클래스가 나타난다.

디렉터리 구성은 다음과 같다.

~/.personal-agent/context/
├── _index.md # 6개 클래스의 내비게이션
│
...

구성상 중요한 점을 여섯 가지 보충한다.

_index.md의 역할: 각 디렉터리 직하의 _index.md는 해당 디렉터리가 무엇을 의미하고, 무엇을 관리하며, 어떤 파일 및 서브 디렉터리를 배치하고, 어떤 규약과 API 액세스 제어(Access Control)가 적용되는지를 기술하는 계약서이다. 에이전트는 디렉터리를 glob으로 탐색하는 것이 아니라, _index.md 파일 하나를 읽는 것만으로 토폴로지(Topology)를 파악한다. 이를 통해 리드 스톰(Read Storm)을 회피한다. _index.md를 단순히 자식 요소의 열거로 만들지 마라 ― 그것은 ls 명령어로 대체할 수 있다.