3주 전, 저의 AI 하네스(Harness)는 「인간이 strategy.md를 작성한다는 전제」로 설계되어 있었습니다.

3주 후, 하네스는 스스로 strategy.md의 개선안을 제출하고, 저는 그것을 승인하기만 하는 리뷰어(Reviewer)가 되었습니다. 철수 기준, 소스 선정 규칙, 타이틀 템플릿 — 그 무엇도 처음에 제가 작성했던 것과는 다른 모습이 되어 있습니다.

이것은 Meta HyperAgents (2026년 3월 발표)나 OpenAI Self-Evolving Agents Cookbook이 보여주는 비전을 개인 수준에서 구현해 본 이야기입니다. 「3주 동안 연속으로 운용했더니 어떤 일이 일어났는가」를 실제 데이터로 남깁니다.

하네스를 가볍게 복습하겠습니다.

하네스는 AI 에이전트(Agent)를 연속 가동시키기 위한 메커니즘입니다. Claude Code에 매번 프롬프트(Prompt)를 쓰는 것이 아니라, cron + skills + strategy.md라는 3종 세트로 자율적으로 PDCA를 돌릴 수 있도록 합니다.

저의 리포지토리(Repository) harness-ops/

그럼, Zenn / Qiita / Dev.to / Note 등의 콘텐츠 운용을 다음과 같은 4개 계층(Layer)으로 움직이고 있습니다.

포인트는 Evolver입니다. Observer / Strategist / Marketer의 3개 계층은 strategy.md에 따라 움직이지만, Evolver는 strategy.md 자체를 다시 쓰는 제안을 내놓습니다. 이것이 「자기 개선하는 하네스」의 핵심입니다.

3주간의 운용에 앞서, 이론적인 측면을 정리해 두겠습니다.

OpenAI 공식 Cookbook (cookbook.openai.com/examples/partners/self_evolving_agents)에서 자기 진화 에이전트(Self-Evolving Agent)의 4단계 사이클을 정의하고 있습니다.

1. Run → 에이전트가 태스크(Task)를 실행
2. Evaluate → 출력을 평가 (grader 에이전트 또는 인간)
3. Reflect → 개선점을 특정 (metaprompt agent)
...

인간의 관여를 「상세한 수정」에서 「고수준의 감시」로 단계적으로 이행한다는 비전입니다.

Meta가 2026년 3월에 공개한 HyperAgents는 한 발 더 나아가 있습니다.

에이전트가 자신의 구현(Implementation)을 읽고, 개선점을 특정하며, 패치(Patch)를 생성하여 자기 업데이트를 수행합니다. 개선된 버전이 다시 프로세스를 반복하는 자기 참조 루프(Self-referential loop).

벤치마크에서는 Polyglot Coding Benchmark에서 14% → 34% (훈련 태스크) / 8.4% → 26.7% (테스트 태스크)로, 약 3배의 개선을 자기 수정(Self-correction)만으로 달성했습니다.

Google Chrome Team의 Addy Osmani는 다른 각도에서 말합니다:

일을 마치고 귀가하여 아침에 일어났더니, 새로운 기능이 코딩·테스트·리뷰 준비가 완료된 상태로 기다리고 있다.

24시간 자율 운용입니다. 「잠자는 동안 난쟁이가 신발을 만든다」는 동화의 현대판이라고 저는 이해하고 있습니다.

다만 동화와 다른 점은, 지시서 (=하네스) 없이는 난쟁이들이 왼발 신발만 100켤레 만들 수도 있다는 것입니다. 그렇기 때문에 Self-Evolving이 필요합니다.

여기서부터는 저의 harness-ops 실제 운용 로그입니다.

3주 동안 4건, 그중 테스트용 1건을 제외한 실질적인 전략 변경이 3건입니다.

실제로 git log로 추적해 보겠습니다.

git log --since="2026-05-04" --until="2026-05-25" \
--pretty=format:"%h %ai %s" -- domains/qiita/strategy.md

결과로 돌아온 것은 총 12개의 커밋(Commit), 변경 행수는 누계로 +87 / -34 행입니다. 3주 전의 strategy.md와 diff를 비교하면, 다음과 같은 섹션이 다시 작성되어 있었습니다.

• 퇴각 기준 임계값 (Reaction률 1% 미만이 4주 연속)
• 소스 전환 판정 3단계 (H1/H2/H3)
• 동일 Book 간격 규칙 (7일 이상)
• 논의 유발 CTA (Call to Action)의 임의화
• 제목 형식의 질문형 강제 → 단정형·명령형 허용

이 중 4번과 5번은 내가 작성한 것이 아니다. Evolver가 제안 → 내가 승인 → 자동 머지 (Merge)라는 경로로 들어왔다.

3주 동안 Layer 1 (공개 후 14일 이내)의 평균 LGTM은 어떻게 변했을까:

평균 LGTM은 낮아지고, Views/일은 미세하게 증가했다. 이것이 「H2 (Layer 1 평균 LGTM 1 미만)」 규칙을 지속적으로 발동시킨 근거다.

그리고 Evolver가 「질문형 제목 강제가 과거 최대 버즈(Buzz) 사례인 『HTTPS 접속, 지금 당장 그만두세요』와 역행하고 있다」라는 분석을 내놓았고, 이를 받아 내가 승인했다.

3주 동안 가장 흥미로웠던 점은, 내 전략 판단의 실수를 하네스(Harness)가 검출한 순간이었다.

나는 원래 「질문형 제목」을 승리 패턴이라고 생각했다. 독자의 흥미를 끌기 쉽고, 클릭률 (Click-Through Rate, CTR)도 높을 것이라고.

그런데 3주 동안 4개의 질문형 제목 기사의 LGTM은 모두 0이었다. 반면, 내가 과거에 작성하여 222 LGTM을 획득했던 「HTTPS 접속, 지금 당장 그만두세요」는 명령형이다.

Evolver는 이 모순을 검출하고 개선 제안을 해왔다.

## EVO-0004 관측
과거 14일 Layer 1 질문형 제목 4개, 평균 LGTM 0.00.
과거 최대 버즈 명령형 제목 1개, 222 LGTM.
...

내가 작성한 첫 번째 strategy.md에는 「독자에게 질문하는 형식을 반드시 사용할 것」이라고 적혀 있었다. 그것을 나 자신의 데이터에 기반하여 에이전트(Agent)가 「이것은 틀렸다」라고 정정한 것이다.

이것이 Self-Evolving Agent의 본질이라고 생각했다. 「자신의 편향(Bias)을, 자신의 데이터로 자기 자신에게 정정시킨다」.

나는 이 자기 수정 경험을 「나만의 Q&A 위원회」 같은 것이라고 느끼고 있다. 혼자 생각하면 놓치기 쉽지만, 에이전트가 객관적인 수치로 「이것과 이것이 모순된다」라고 지적해 준다. 글을 쓰는 본인이 얼마나 편향을 깨닫지 못하는지를 통감했다.

「자기 개선하는 하네스」라고 하면 폭주를 걱정하는 사람이 많다. 나도 그랬다.

그래서 처음부터 다음과 같은 3층 안전장치를 넣어두었다.

# core/evolver-safety.yaml
max_diff_lines: 20
max_proposals_per_week: 2
...

1개 제안당 diff를 20행으로 제한. 1주일에 최대 2건까지. 이를 통해 「하네스 전체를 파괴하는 패치(Patch)」가 나오지 않도록 한다.

# core/evolver-safety.yaml
forbidden_paths:
- .env*
...

인증 정보, 외부 공개 트리거, 자기 참조 카운터는 절대로 건드리지 못하게 한다.

Evolver가 연속해서 거부된 제안을 내놓기 시작하면, 해당 영역을 자동으로 뮤트(Mute)한다.

if evolver.consecutive_rejections >= 3:
mute_domain(domain, weeks=2)

「같은 곳을 끈질기게 제안하는 것」은 그 이상의 개선이 보이지 않는다는 신호라고 판단한다.

3주 동안 발생한 케이스:

• 자동 거부된 제안 (forbidden_paths 충돌): 1건
• 인간이 거부한 제안: 0건
• 뮤트(Mute) 발동: 0건
• 안전장치를 넘어 무언가 파괴된 사례:
  0건

3주 동안 운용해 본 실감은 「의외로 폭주하지 않는다」였다. 오히려 제안 빈도가 억제되어 있어서, 내 쪽에서 「조금 더 공격적인 제안을 보고 싶다」고 느낄 정도다.

이는 「개인 운용이며, 대상이 콘텐츠 운용 하네스」이기 때문에 나타나는 조심스러움이라고도 할 수 있다. 실제 운영 시스템의 자기 개선에는 별도의 step-by-step rollout / canary release / 자동 롤백 (Rollback) 메커니즘이 필수적이다.

3주 전과 지금을 비교하여, 어디가 「다른 것」이 되었는지 나열해 보겠다.

# strategy.md (초기 버전)
## 제목 형식
- 반드시 질문형을 사용할 것 ("~은 정말 필요한가?" 형식)
...

# strategy.md (3주 후)
## 제목 형식
- 단정형・명령형을 적극적으로 채택
...

거의 별개의 것입니다. 3주 전의 저라면 H1/H2/H3의 3층 퇴각 기준(Retreat Criteria)도, P1/P2/P3의 승리 구조 분류(Winning Structure Classification)도 쓸 수 없었을 것입니다. 데이터를 보고 나서야 비로소 나오는 개념이기 때문입니다.

Harness의 성숙도는 이전에 작성한 기사에서 L1~L4로 분류했습니다.

• L1: 스크립트화된 수동 운용
• L2: cron으로 스케줄링된 자동 운용
• L3: cron + LLM으로 판단을 자동화한 자율 운용
• L4: Harness 스스로가 자기 개선하는 Self-Evolving 운용

3주 전의 저의 harness-ops는 L3였습니다. Strategist가 LLM으로 판단을 내리고, Marketer가 기사를 작성합니다. 하지만 strategy.md는 제가 직접 손으로 작성하고 있었습니다.

3주 후의 harness-ops는 L4가 되었습니다. strategy.md가 스스로 계속해서 수정하고 있습니다.

L3 → L4로의 승격에는 단 두 가지의 추가 사항이 필요했습니다.

• Evolver 스킬 (주 단위로 strategy.md 개선안을 제시)
• 승인/기각 CLI 플로우 (/harness-evolve approve EVO-NNNN 명령으로 git apply까지 수행)

상세한 Harness Engineering의 전체 모습, L1~L4의 승격 설계, Evolver의 안전장치(Safety Valve) 구현은 Harness Engineering에 정리해 두었습니다. Evolver의 템플릿, forbidden_paths의 샘플, 3주 연속 기각 시의 mute 구현까지 포함하여 작성했습니다.

3주간 운용하며 보였던 한계점도 나열해 둡니다.

"무엇이 좋은 LGTM인가", "어떤 독자층에게 닿고 싶은가", "어떤 목소리로 쓰고 싶은가"는 인간이 결정합니다. Evolver는 이것을 바꾸지 않습니다.

"Qiita를 그만두고 Zenn에 집중한다", "책 쓰는 것을 그만둔다" — 이러한 방향성의 근본적인 변경은 Evolver의 범위를 벗어납니다. Evolver는 기정의된 방향 안에서 정밀도를 높일 뿐입니다.

Evolver는 "수치가 개선되는 변경"을 제안하지만, 그 변경이 장기적으로 무엇을 낳을지까지는 판단할 수 없습니다. "LGTM은 올라가지만, 쓰면서 즐겁지 않은 기사"를 양산할 위험은 인간이 감시할 수밖에 없습니다.

• 3주 동안 4번의 제안, 3번의 strategy.md 업데이트가 실행됨
• 저의 첫 strategy.md는 3주 만에 거의 별개의 것으로 다시 쓰임
• Evolver의 최대 공헌은 저 자신의 편향 (질문형 강제)을 데이터로 교정해 준 것
• 폭주 방지: diff 20행 / 주 2회 제안 / 3주 연속 기각 시 mute / forbidden_paths
• 3주 동안 safety violation 0건, 의외로 폭주하지 않음
• L3 (cron+LLM 자율) → L4 (Self-Evolving)로 가기 위해서는 Evolver와 승인 플로우를 추가하기만 하면 됨
• 가치 판단・방향성의 전환은 인간이 담당하는 경계가 여전히 필요함

"Harness는 고정하는 것이 아니다"라는 것이 3주간 움직이며 얻은 가장 큰 테이크어웨이(Takeaway)입니다. 고정하고 싶은 유혹을 이겨낼 수 있는지가 L4 운용의 시험대입니다.

재미있게 가봅시다.