다른 에이전트들을 감사하는 4번째 에이전트를 추가했습니다. 제 전략가(Strategist)가 3주 동안 미루고 있는 것을 잡아냈습니다.

저는 3계층 에이전트 하네스(harness)를 구축하고 이를 "자율적(autonomous)"이라고 불렀습니다. Observer는 데이터를 수집했습니다. Strategist는 주제를 선정했습니다. Marketer는 기사를 작성했습니다. 그들은 모두 제 규칙이 담긴 파일인 strategy.md를 따랐습니다. 크론(cron) 작업은 매주 월요일 09:00에 실행되었고, 점심시간쯤이면 기사들이 올라왔습니다. 저는 스스로가 매우 영리하다고 느꼈습니다.

그러다 3주 동안의 제 Strategist 로그를 읽으며 무언가를 발견했습니다. 동일한 후퇴 기준("만약 반응률(Reaction rate)이 4주 연속 1% 미만으로 유지되면, 전략을 수정하라")이 3주 연속으로 미뤄지고 있었습니다. 매주 Strategist는 "데이터 불충분, 다음 주에 관찰"이라고 적고 넘어가 버렸습니다. 규칙은 존재했습니다. 데이터도 존재했습니다. 하지만 규칙은 한 번도 실행되지 않았습니다.

3계층 하네스는 이를 잡아낼 수 없었습니다. 왜냐하면 세 계층 모두 strategy.md가 시키는 대로 정확히 수행하고 있었기 때문입니다. 버그는 에이전트들에게 있는 것이 아니었습니다. 버그는 규칙 자체에 있었고, 하네스 내의 그 어떤 것도 규칙을 살펴보도록 설계되지 않았습니다.

저는 Evolver라고 불리는 4번째 계층을 추가했습니다. Evolver는 첫 번째 실제 제안에서, 제 Strategist가 숨어있던 바로 그 규칙에 대한 디프(diff)를 제출했습니다.

세 계층은 자율적인 부분이 아니었습니다

제가 자율적이라고 불렀던 아키텍처는 다음과 같았습니다. Observer는 매일 실행되어 GA4 수치를 article-performance.jsonl에 덤프(dump)했습니다. Strategist는 매주 월요일 아침에 실행되어 strategy.md를 읽고 그 주의 주제 5개를 선정했습니다. Marketer는 각 주제를 기사로 변환하여 발행 대기열에 넣었습니다. 세 가지 역할, 세 가지 크론(cron) 작업, 예측 가능한 동작이었습니다.

이 과정을 빠르게 만든 비결은 의도적으로 Strategist(전략가)에게서 WebSearch(웹 검색) 기능을 제거했다는 점입니다. WebSearch 기능이 있는 Strategist는 실행당 20분 동안 방황하며, 제 실제 콘텐츠 라이브러리와 일치하는 주제 대신 최근 뉴스에 맞춘 주제를 고르기 시작했습니다. WebSearch를 제거하자 사이클이 20분에서 3분으로 단축되었습니다. 이전 포스트가 Strategist를 더 빠르게 만드는 것에 관한 것이었다면, 이번 포스트는 그것에 책임을 묻는(accountable) 것에 관한 것입니다.

그 세 가지 레이어(layer)가 할 수 없었던 단 한 가지는 strategy.md를 다시 쓰는 것이었습니다. 그들은 매주 월요일에 이 파일을 읽고 그에 따랐습니다. 만약 규칙이 잘못되었다면, 그들은 잘못된 규칙을 따랐습니다. 규칙을 변경할 수 있는 유일한 방법은 인간인 제가 주간 검토(weekly review) 중에 규칙 업데이트가 필요함을 알아차리는 것뿐이었습니다. 그리고 제가 병목 현상(bottleneck)이었습니다. 저는 적어도 3주 동안 후퇴 기준(retreat criteria)에 주의를 기울이지 않고 있었습니다.

로그에서 나타난 미루기(procrastination)의 모습

패턴을 원문 그대로 볼 때 더 정직하게 드러나기 때문에, 제 자신의 Strategist 로그를 인용하겠습니다.

Evolver를 추가하기 3주 전의 로그입니다:

대부분의 기사에서 반응률(Reaction rate)이 0%로 지속되고 있습니다. 제목 전략이 1인칭 및 수치 중심 프레임워크로 전환되었습니다. 4주 연속 1% 미만일 경우 전략 검토가 필요합니다 (현재 3주 연속, 다음 주에 결정 예정).

다음 주:

반응률이 아직 4주 연속 1% 미만에 도달하지 않았으나, 주간 트렌드 데이터가 불충분합니다. 다음 주까지 관찰하십시오.

이 두 문장이 전체 실패 모드(failure mode)를 보여줍니다. 규칙은 "4주 연속"이라고 명시했습니다. Strategist는 1% 미만의 데이터를 3주 연속 확보했습니다. Strategist는 4주 차를 결정 주간으로 취급하는 대신, 상황을 계속 "여전히 관찰 중"이라고 기술했고 시계는 결코 앞으로 나아가지 않았습니다. 후퇴 기준이 에이전트가 무기한으로 미룰 수 있는 방식으로 구조화되어 있었던 것입니다.

제가 직접 article-performance.jsonl에서 실제 수치를 계산해 보았을 때, 상황은 훨씬 더 처참했습니다. 지난 4주 동안 발행된 24개의 기사를 살펴보면: 총 조회수 812회, 총 반응(reactions) 4회, 총 댓글(comments) 7회였습니다. 반응률(Reaction rate)은 0.49%로, 임계값(threshold)의 절반 수준이었습니다. 참여율(Engagement rate, 반응 및 댓글 합계)은 1.35%였습니다. 규칙대로라면 몇 주 전에 이미 실행되었어야 했습니다. 하지만 하네스(harness) 내에 "이 규칙이 실제로 작동하고 있는가"를 질문하는 역할을 하는 계층(layer)이 없었기 때문에 결코 실행되지 않았습니다.

네 번째 계층: Evolver란 무엇인가

그래서 저는 네 번째 크론 잡(cron job)을 추가했습니다. 이것은 월요일의 Observer/Strategist/Marketer 체인과는 별개로, 토요일 09:00에 실행됩니다. 다른 세 에이전트와 달리, 이 에이전트는 웹 검색(WebSearch) 기능이 활성화되어 있습니다. 이 에이전트의 임무는 기사를 쓰는 것이 아닙니다. 전략 파일(strategy file)을 읽고, 지난 몇 주간의 결정 로그(decision logs)를 읽은 뒤, strategy.md에 대한 차이점(diffs)을 제안하는 것이 임무입니다.

각 제안은 하나의 파일로 생성됩니다: domains/<name>/data/evolution/EVO-NNNN.md. Evolver는 다음 다섯 가지 섹션을 채웁니다.

• Observation (관찰) — 데이터에서 발견한 내용
• Proposal (제안) — 평이한 산문 형태로 작성된 규칙 변경 사항
• Rationale (근거) — 변경을 정당화하는 내부 데이터 및 외부 참조 자료
• Expected impact (예상 영향) — 적용 시 개선될 것으로 기대되는 사항
• Diff (차이점) — strategy.md에 대한 실제 diff 블록

이 diff 블록이 핵심적인 부분입니다. Evolver는 단순히 영어로 된 제안을 작성하는 것이 아닙니다. 리포지토리(repo)에 바로 반영될 수 있는 정확한 패치(patch)를 작성합니다. harness-evolve.sh라는 작은 CLI 도구는 이 diff 블록을 추출하고, git apply --check를 실행하며, 제안 내용을 본문으로 하여 커밋(commit)하는 방법을 알고 있습니다. 적용(apply) 단계에는 어떠한 LLM도 관여하지 않습니다. LLM은 제안하고, 셸(shell)이 적용합니다.

이러한 분리는 의도적인 것입니다. 제안은 창의적이어야 하지만, 적용은 기계적이어야 합니다. 적용 단계가 기계적일 때, 깨끗하게 성공하거나 혹은 명확하게 실패할 것이라고 신뢰할 수 있습니다. "에이전트가 패치를 적용하려고 시도했는데 중간에 이상한 일이 발생했다"와 같은 상황은 발생하지 않습니다.

EVO-0003이 내 Strategist의 미루기 습관을 잡아냈다

Evolver의 세 번째 실제 제안인 EVO-0003은 위에서 설명한 것이었습니다. 이 제안서는 디스크에 저장되어 있으며, 저는 이 글을 쓰면서 그것을 다시 읽고 있습니다.

관찰(observation) 섹션에는 제 Strategist의 로그 두 개, 즉 "3주 연속 발생했으므로 다음 주에 결정하겠다"는 로그와 "데이터가 불충분하므로 다음 주에 관찰하겠다"는 로그가 모두 인용되었습니다. 그런 다음 article-performance.jsonl로부터 참여율(engagement rate)을 계산하여, 최소 4주 동안 임계값(threshold)을 초과했다는 사실을 보여주었습니다. 이어서 해당 제안서는 기존 규칙이 세 가지 측면에서 잘못되었다고 주장했습니다:

1. 공식이 명시되지 않았습니다. "반응률 (Reaction rate)"이 개별 기사 기준인지 아니면 합계 기준인지 불분명했습니다. 제 Strategist는 두 가지 방식 모두 계산할 수 있었기에, 이를 이유로 결정을 미뤄왔던 것입니다.
2. 주간 데이터가 부족할 때 트리거 조건인 "4주 연속"이라는 표현이 모호했습니다.
3. 트리거 발생 시의 조치("제목 및 관점 수정 제안")가 너무 추상적이어서, Strategist가 단 한 문장만으로 이를 수행하고 넘어가 버릴 수 있었습니다.

제안서는 해당 규칙을 다음과 같이 대체했습니다:

참여율 (Engagement rate) = (지난 4주간의 기사 반응 수 + 댓글 수의 합) / 조회수 합계. Strategist는 매주 이를 계산하고 로그에 기록해야 한다. 4주 연속 1.5% 미만일 경우, 다음 주의 기사 5개 중 최소 4개의 제목은 "숫자 + 1인칭 + 실패 서사" 형식을 따라야 한다. 추상적인 제목은 금지된다.

이는 20줄짜리 패치(patch)입니다. 차이점(diff)은 제안서 파일의 본문 아래에 있습니다. 저는 화요일 오후 14:04에 /harness-evolve approve EVO-0003 명령어를 통해 이를 승인했습니다. 셸(shell)은 strategy.md에 대해 git apply --index를 실행하고, 커밋(commit)을 생성하며, 제안서의 프론트매터(frontmatter)를 status: applied로 업데이트한 뒤 저에게 텔레그램(Telegram) 메시지를 보냈습니다. 그다음 월요일, Strategist는 새로운 규칙에 따라 실행되었고, 별도의 요청 없이도 로그에 1.35%의 참여율을 계산하여 기록했습니다. "데이터 불충분"이라는 문장은 더 이상 나타나지 않았습니다.

솔직히 말씀드리고 싶은 점은, Strategist(전략가)가 악의적이었던 것은 아니라는 사실입니다. 그렇다고 고장 난 것도 아니었습니다. Strategist는 미루기(deferral)가 허용되도록 설계된 규칙을 따르고 있었던, 완벽하게 유능한 에이전트였습니다. 그것은 규칙의 실패입니다. Evolver(진화기)의 역할은 규칙의 실패를 감지하는 것입니다. 왜냐하면 하네스(harness) 내의 다른 어떤 것도 그렇게 설계되지 않았기 때문입니다.

Self-Evolving Agents(자기 진화 에이전트)는 장난감이 아니기에 필요한 안전 경계 (Safety boundary)

4번째 레이어를 추가하기 전에 필요한 것

자신의 설정에 Evolver 스타일의 레이어를 추가하기 전에는 세 가지 실질적인 전제 조건이 필요하다고 생각합니다. 이 조건들이 없다면, 4번째 레이어는 그저 소음(noise)에 불과합니다.

첫째, 기존의 세 가지 레이어가 다른 에이전트가 읽을 수 있는 결정 로그(decision logs)를 생성해야 합니다. 만약 당신의 Strategist(전략가)의 출력이 "성공적으로 실행됨, 테마 선정 완료"와 같다면, Evolver(진화기)가 찾아낼 수 있는 것은 아무것도 없습니다. 미루기(procrastination) 문제가 드러난 이유는 제 Strategist가 "현재 3주 연속 진행 중, 다음 주에 결정할 예정"과 같은 문구를 포함하여 구조화된 로그를 작성해 왔기 때문입니다. 에이전트의 추론(reasoning) 과정을 산문 형태로 포함하는 로그가 감사를 가능하게 만듭니다.

둘째, 규칙(rules) 자체가 텍스트 형태로 버전 관리(version control) 시스템에 있어야 합니다. strategy.md가 체크인된 마크다운(markdown) 파일인 이유는 Evolver가 git apply로 적용할 수 있는 디프 블록(diff block)을 생성해야 하기 때문입니다. 만약 당신의 규칙이 데이터베이스, SaaS 대시보드, 또는 수천 줄의 JSON 설정 파일에 들어 있다면, 패치(patch) 모델은 무너집니다. Git에 저장된 일반 마크다운이 가장 저렴하고 효율적인 경로입니다.

셋째, 사람이 매번 제안서 전체를 읽을 필요가 없는 인간 승인 채널(human approval channel)이 필요합니다. 저의 Telegram 알림에는 EVO-ID, 제목, 그리고 파일로 연결되는 한 줄짜리 링크가 포함되어 있습니다. 저는 제목이 궁금증을 유발할 때만 파일을 엽니다. 대부분의 경우 빠르게 승인하거나 짧은 이유와 함께 거절합니다. 만약 승인하는 데 제안서당 10분이 걸린다면, 저는 Evolver를 실행하는 것을 중단할 것입니다. 하지만 30초가 걸린다면, 저는 이를 무기한으로 실행할 것입니다.

4번째 레이어를 추가하지 않는다면 어떨까

4번째 레이어를 추가하고 싶지 않다면, 특정 질문을 던지는 주간 단위의 인간 검토(human review)를 통해 대부분의 이점을 확실히 얻을 수 있습니다. "에이전트들이 어떻게 하고 있는가"라고 묻는 것이 아닙니다. 그것은 제가 이전에 해왔던 방식이며, 미루기 문제를 잡아내지 못했습니다. 구체적인 질문은 다음과 같습니다: "strategy.md에 명시된 후퇴 기준(retreat criterion) 중 이번 주에 실제로 발동된 것이 있는가? 없다면, 왜 발동되지 않았는가?"

매주 금요일마다 이 질문을 가지고 10분 동안 깊이 생각하십시오. 그러면 제가 3주 동안 놓치고 있었던 것을 잡아낼 수 있을 것입니다. Evolver는 무엇보다도 그 질문을 던지게 만드는 강제 함수 (forcing function) 역할을 합니다. 이것이 반드시 에이전트 (agent)일 필요는 없습니다. 캘린더 알림이어도 상관없습니다.

저는 이것을 에이전트로 실행하는 것을 선호하는데, 그 이유는 제안된 결과물 (artifacts)들이 버전 관리 시스템 (version control)에 쌓이면서 제 규칙들이 어떻게 진화해 왔는지에 대한 기록이 되기 때문입니다. EVO-0001부터 EVO-0004까지는 "내가 좋은 아이디어라고 생각했던 것들, 나쁜 아이디어라고 생각했던 것들, 그리고 그 이유"에 대한 작은 역사를 형성합니다. 이 기록은 내년에 strategy.md를 처음부터 다시 작성할 때 매우 유용합니다.

아직 구축하지 않은 것

현재의 Evolver는 한 번에 하나의 도메인 (domain)만 감사합니다. 저의 네 가지 도메인 (devto, qiita, zenn, kenimoto-dev)에 대해 각각 서로 다른 버전의 strategy.md를 작성했으며, 대부분은 유사한 구조의 후퇴 기준 (retreat criteria)을 가지고 있습니다. 도메인 간 통합 Evolver (cross-domain Evolver)가 있다면 동일한 규칙 구조가 두 개의 도메인에서 실패하고 있다는 점을 감지하고 통합된 해결책을 제안할 수 있을 것입니다. 저는 아직 이것을 구축하지 않았습니다. 하지만 계획 목록에는 있습니다.