"Agent Influence" 시리즈의 5부입니다. 이전 글 | 시리즈 시작

저는 예전에 LLM(Large Language Models)이 컨텍스트(Context) 내의 모든 것을 기억하고 그에 따라 실행할 것이라고 생각했습니다. 그러다 모델들이 망각하고, 선택적으로 흐름을 놓치며, 긴 작업 중에 환각(Hallucination)을 일으키고, 때로는 단순히 작업을 끝내기 위해 말을 지어내는 것을 목격했습니다. 그때부터 저는 아직 이름조차 붙이지 못한 무언가를 만들기 시작했습니다.

이번 주에 저는 "'에이전틱 하네스(agentic harness)'란 실제로 무엇인가?"라는 제목의 DEV Community 게시물을 읽었습니다. 게시물 자체는 짧았습니다. 하지만 한 댓글이 제가 만들어온 것에 더 나은 이름을 붙여주었습니다:

"제가 생각하는 그 살아남는 계층(surviving layer)은 에이전트가 매 세션마다 상속받는 일련의 고정된 규칙(standing rules)과 훅(hooks)입니다. 즉, 대화가 사라진 후에도 진실로 남아있는 것들입니다."

이 인용구는 FromZeroToShip의 글에서 가져온 것입니다. 이는 제가 몇 달 동안 만들어온 것, 즉 매 세션마다 주입되는 고정된 규칙을 가진 개인용 에이전트 거버넌스(governance) 시스템, 단일 대화보다 오래 지속되는 교정 메모리(correction memory), 그리고 에이전트가 완료를 보고한 후 요구되는 검증 스크립트(verification scripts)를 설명하고 있었습니다. 이 글의 제목은 그 살아남는 계층을 저만의 방식으로 줄여서 표현한 것입니다.

프롬프트는 그중 아주 작은 부분일 뿐입니다

대부분의 에이전트 설정 가이드는 프롬프트 엔지니어링(Prompt Engineering)에 집중합니다. 더 나은 지침을 작성하라, 예시를 추가하라, XML 태그를 사용하라 등등. 이것들은 유용하지만, 모두 프롬프트 작업이며, 프롬프트는 컨텍스트 윈도우(Context Window)가 초기화될 때 증발해 버리는 부분입니다.

하네스(Harness)는 다릅니다. 그것은 매 세션마다 파일로부터 에이전트의 규율(discipline)을 재구축하는 구조입니다. 하네스는 에이전트가 읽는 파일로서 존재하지만, 저의 현재 워크플로우에서는 에이전트가 수정하지 않습니다. 하네스가 다루는 경로 내에서, 그것은 "done"이 수용 가능한지, 혹은 루프(loop)를 계속해야 하는지와 같이 에이전트 자신의 추론(reasoning) 외부에서 결정을 내립니다.

만약 여러분이 Claude Code, Codex CLI, 또는 opencode를 사용한다면, 여러분은 이미 하네스를 가지고 있는 것입니다. 해당 도구들은 실행 계층(execution layer)인 도구 스키마(tool schemas), 컨텍스트 관리(context management), 그리고 권한 제어(permission controls)를 제공합니다. 이들은 "에이전트가 무엇을 할 수 있도록 허용되었는가?"라는 질문에 답합니다.

하지만 실행 계층의 하네스는 다른 질문에는 답하지 못합니다: "에이전트가 실제로 자신이 주장한 대로 수행했는가, 그리고 실수로부터 배웠는가?" 그것이 바로 거버넌스 계층(governance layer)입니다. 즉, 효과성을 위해 감사(audit)되는 규칙, 세션 전반에 걸쳐 지속되는 수정 사항, 그리고 모델에게 스스로를 채점하도록 요구하지 않는 완료 확인(completion checks)을 의미합니다. 도구들은 제어 프리미티브(control primitives)를 제공하지만, 여러분의 프로젝트에 특화된 규칙 감사, 수정 메모리, 그리고 완료 증거 루프(completion evidence loop)를 자동으로 형성해주지는 않습니다. 그것은 여러분이 직접 구축해야 합니다.

저의 현재 설정에서, 이러한 확인 절차들은 별도로 강제되는 실행 경계(execution boundary)라기보다는 프로세스 요구 사항(process requirements)에 가깝습니다.

이러한 분리는 중요합니다. 또 다른 댓글 작성자인 CAI가 표현했듯이: "루프(loop)는 다음에 무엇을 할지 결정합니다. 하네스는 그것이 실제로 일어났는지 여부를 결정합니다."

달리 말하자면: 만약 결과물을 만들어내는 동일한 시스템이 그 작업이 완료되었는지 여부까지 결정한다면, 여러분은 회계 부서 안에 감사관을 두고 있는 것과 같습니다. 숫자를 작성한 손과 검토하는 손이 같기 때문에 숫자는 아무 문제 없어 보일 것입니다.

두 가지 측면: 센서(sensors)와 가이드(guides)

저는 규칙만으로 에이전트(agent)를 고칠 수 있다고 생각하곤 했습니다. 규칙을 더 추가할수록 왜 에이전트가 더 멍청해지는지에 대한 제 글에서, 저는 정리 과정 없는 규칙 추가에 반대하는 논리를 펼쳤습니다. 하지만 저는 문제의 절반만 보고 있었습니다. 신뢰할 수 있는 제어를 위해서는 규칙만으로는 충분하지 않습니다. 저는 에이전트에게 무엇을 할지 알려주는 268개의 규칙을 가지고 있었습니다. 하지만 그 규칙들이 실제로 작동하는지 확인하는 스크립트(script)는 단 하나도 없었습니다. 에이전트는 규칙을 읽고, 고개를 끄덕이고, 다음 세션에서 똑같은 실수를 반복하며 계속해서 같은 잘못을 저질렀습니다.

Viktor라는 댓글 작성자는 하네스(harness)를 두 부분으로 나누었습니다: 센서(sensors) (피드백 - 테스트, 린터(linters), 완료 확인(done-checks))와 가이드(guides) (피드포워드(feedforward) - 에이전트가 행동하기 전에 읽는 규칙). 센서만 구축하면 에이전트가 실수는 잡아내지만, 이를 피하는 법을 배우지는 못합니다. 가이드만 구축하면 규칙이 실제로 작동하는지 알 수 없습니다. 견고한 설계에서는 이 두 부분이 동일한 권한을 공유해서는 안 됩니다.

제 설정에서 가이드는 에이전트가 읽는 지침 파일(instruction files)에 존재합니다 - "X가 발생하면, Y를 하라." 센서는 에이전트가 완료를 보고한 후에 제가 실행하도록 요구하는 스크립트입니다 - "예상했던 파일이 실제로 변경되었는가?" 동일한 에이전트가 직접 확인하는 가이드는 자기 숙제를 스스로 채점하는 규칙과 같습니다.

이 프레임워크는 제 설정에만 국한된 것이 아닙니다. jugeni라는 작가도 유사한 구분을 제시했습니다: 콘텐츠(content, 단계로 묶인 지식)와 컨트롤(control, 게이트(gates)로 묶인 증거 규율).

완료 확인(Done-check)은 독립적이어야 합니다

하네스(harness)의 센서(sensors) 절반은 그 무엇보다 중요한 단 하나의 임무를 수행합니다. 바로 에이전트(agent)의 작업이 실제로 완료되었는지 결정하는 것입니다. 여기서 데이터는 불편한 진실을 드러냅니다. 이전 글에서 저는 수개월간의 운영을 통해 시스템 내의 증거 유형을 측정했습니다. 그 결과, 모든 증거 항목의 68%가 에이전트에 의해 자기 보고(self-reported)되었습니다. 이 자기 보고 계층에서는 독립적으로 확인된 실패 결과가 0건 발생했습니다. 즉, 에이전트의 자체 보고가 독립적인 소스에 의해서도 확인되는 컴플라이언스(compliance, 준수) 실패를 드러낸 사례가 단 한 건도 없었다는 의미입니다.

검토된 증거 기록에서 독립적인 소스들은 182개의 위반 신호(violation signals)를 생성했습니다. 그중 5개는 더 엄격한 정의에 따라 실제 위반으로 확인되었습니다. 182개의 신호 전체와 확인된 5개의 위반 사례 모두 에이전트의 자기 보고가 아닌, 독립적인 소스에서 발생했습니다.

동일한 게시물의 댓글 작성자인 Edu Peralta는 이를 정확하게 표현했습니다:

"'완료(done)'를 모델 자신의 의견으로 취급하는 하네스는 해당 모델의 모든 사각지대(blind spot)를 그대로 물려받게 됩니다."

저는 조사할 가치가 있는 패턴을 관찰했습니다. 여러 목소리가 이를 지적했습니다. 두 편의 기사, 위 게시물의 댓글 작성자 한 명, 그리고 저의 N=1 데이터가 이를 뒷받침합니다:

이러한 패턴을 확인한 것은 검증되는 동시에 놀라운 일이었습니다. 이는 독립적인 샘플들(두 편의 기사, 한 명의 댓글 작성자, 저의 데이터)은 아니지만, 패턴 자체는 조사할 가치가 있습니다. 모델에게 완료되었는지 묻는 완료 확인(done-check)은 그 자체로 독립적인 완료 확인이 아닙니다. 그것은 모델이 자신의 출력물(output)을 스스로 평가하는 것에 불과합니다.

해결책은 더 똑똑한 루브릭이 아니라, 주장(claim)의 사각지대를 공유하지 않는 메커니즘입니다. 종료 코드(exit code), git diff, 파일 존재 여부 확인 같은 것입니다. 결정론적(deterministic) 주장의 경우—파일이 변경되었는지, 테스트가 통과했는지—LLM 판단에 의존하지 않는 검사가 LLM 판단에 의존하는 검사보다 속이기 어렵습니다. 왜냐하면 종료 코드는 서술(narration)을 읽지 않기 때문입니다.

루프는 성공이 아닌 종료 지점이 필요하다

센서/가이드 프레임워크(sensors/guides framework)는 '하네스 검사는 어떻게 작동하는가'에 답합니다. 하지만 두 번째 질문, 즉 에이전트가 작업을 수행할 수 없을 때는 무슨 일이 발생하는지에 대해서는 답하지 않습니다.

FromZeroToShip은 그 결과를 날카롭게 묘사했습니다. “정직한 종료 지점(honest exit)이 없는 루프는 실패하는 것이 아니라 방황하고, 방황하는 에이전트는 실패하는 것보다 더 비쌉니다.”

저는 제 시스템에서도 이를 목격했습니다. 저는 서브 에이전트가 메인 에이전트의 작업을 검토하는 리뷰 루프를 실행합니다. 지난주에는 코드 리팩터링 작업에 대해 6라운드를 실행했는데, 각 라운드마다 더 작은 발견 사항(finding)을 생성했습니다. 5라운드가 되자 발견 사항은 미적인 수준이었지만, 루프가 “충분히 좋다”고 말할 방법이 없었습니다. 제가 수동으로 중단시켰습니다. 에이전트는 실패하지 않았습니다. 방황했을 뿐입니다. 정직한 실패 종료 지점(honest failure exit)이 없으면, 루프는

교정 메모리 (Correction memory). 세션 전반에 걸쳐 지속되는 계층형 시스템(나의 에러 노트 기사)입니다. 에이전트가 실수를 하면, 그 교정 사항은 하나의 규칙(rule)으로 추출됩니다. 다음 세션에서 그 규칙은 이미 존재합니다. 에이전트에게 다시 상기시켜 줄 필요가 없습니다. 하네스(harness)가 이를 주입(inject)하기 때문입니다.

검증 스크립트 (Verification scripts). 에이전트가 완료를 보고한 후에 제가 요구하는 프로그램들입니다. 예상된 파일이 변경되었는가? 테스트 스위트(test suite)를 통과했는가? 체크포인트(checkpoint)가 실제로 실행되었는가? 이들은 실행될 때 종료 코드(exit code)를 내보냅니다. 현재 저의 설정에서 이 요구사항은 프로세스 제약(process constraint)이지, 별도로 강제되는 실행 경계(execution boundary)는 아닙니다.

이 구성 요소들은 함께 매 세션마다 에이전트의 규율(discipline)을 재구축합니다. 에이전트는 새로 시작하지만, 하네스는 그렇지 않습니다.

두 가지 간극이 남아 있습니다: 주장 게이팅 (claim gating) (에이전트가 검증을 실행하지 않고도 "검증 통과"라고 말할 수 있는 문제)과 정직한 실패 종료 지점 (honest failure exit) (아직 모든 경로에 연결되지 않음)입니다. 하네스는 완성되지 않았습니다. 하지만 이 구조가 바로 하네스를 매일 작업에 사용할 수 있을 만큼 신뢰할 수 있게 만드는 핵심입니다.

오늘 바로 할 수 있는 일

세 가지 구성 요소로 이루어진 하네스를 구축할 필요는 없습니다. 컨텍스트 리셋(context reset) 후에도 살아남는 하나의 결정론적(deterministic)인 체크 항목만 있으면 됩니다.

다음은 귀하의 에이전트 설정에 하네스 파일이 존재하는지 목록을 만들어주는 스크립트입니다:

#!/usr/bin/env python3
"""Harness Inventory - 프로젝트 내의 후보 하네스 파일 목록을 나열합니다.
참고: 이는 파일의 존재 여부만 확인합니다. 로딩 여부는 검증하지 않습니다.
...

CI 설정이나 보호된 브랜치(protected branches)에 대한 귀하만의 체크 항목을 추가하세요. 우선 상시 규칙 파일(standing rules file)을 만드는 것부터 시작하십시오. CLAUDE.md, AGENTS.md 또는 귀하의 에이전트 도구가 시작 시 로드하는 파일 무엇이든 좋습니다. 30분간의 실행 과제: 에이전트가 매 세션마다 한다고 주장하는 일 한 가지를 선택하세요. 그것이 실제로 일어났는지 확인하는 스크립트를 작성하세요. 에이전트가 "완료(done)"라고 말한 후에 그 스크립트를 실행하세요. 프롬프트가 아니라, 바로 그 스크립트가 귀하의 하네스의 시작입니다.

하네스(Harness)는 컨텍스트(Context)가 잊어버릴 때 살아남는 모든 것입니다. 프롬프트(Prompt)는 그중 가장 작은 부분에 불과합니다. 저는 에이전트가 실제로 주장한 바를 수행했는지 확인하는 하나의 스크립트(Script)로 시작했습니다. 그것이 제 하네스의 첫 번째 줄이었습니다. 만약 여러분이 오늘 무언가를 구축한다면, 그것이 여러분의 첫 번째 줄이 될 것입니다.

비하인드 스토리: 이 글이 어떻게 관리되었는가

이 글은 자기 보고(Self-report)가 실제 위반 사항을 전혀 잡아내지 못한다는 점을 논증합니다. 집필 과정에서 8차례의 검토 라운드와 문서화된 수정 기록이 생성되었으며, 이 모든 것은 초안 자체의 자기 평가(Self-assessment) 외부에서 발견되었습니다.

| 에이전트가 작성한 내용 |
| --- | --- |
| 댓글 작성자로 "Charles Solar" 기재 | 독립적 검토: 존재하지 않는 사용자임 | 속성 제거 |
| ... |

에이전트의 자기 평가(Self-assessment)는 이 중 단 하나도 잡아내지 못했습니다. 모든 문제는 독립적인 소스에 의해 발견되었습니다.

이 글은 개인용 에이전트 거버넌스(Governance) 시스템인 EQ OS를 구축하며 얻은 N=1 경험 보고서입니다. 인용된 모든 데이터(자기 보고 68%, 검증된 실패 0건, 위반 신호 182건, 확인된 위반 5건)는 수동 추정이 아니라, 수개월간의 운영 기간 동안 증거 데이터베이스(Evidence database)에 대해 결정론적 쿼리(Deterministic queries)를 실행하여 생성된 것입니다. 여기서 설명하는 하네스(Harness)는 연구용 시스템이며, 출시용 제품이 아닙니다. 설명된 "독립성(Independence)"은 현재 프로세스 제약(Process constraint)을 의미하며, 강제된 권한 격리(Permission isolation)를 의미하는 것은 아닙. 인용된 기사들은 2026년 7월 DEV Community에 게시되었습니다.