TL;DR

• 이전에 작성했던 .claude/ 의 자기 개선 루프(log → review → amend → eval)를 그 이후로도 계속 돌렸습니다. 실행 로그 83개, 규칙 수정(amendment) 20개 - 어느 날 amendment의 change_type을 전부 세어보니, 「깎아내기(削る)」, 「순서 바꾸기(並び替える)」가 0개였습니다. 20개 모두가 「더하기」 혹은 「강화하기」였습니다 - 원인은 스키마(schema)에 있었습니다. 로그에 실패 항목(corrections)은 있는데, 효과가 있었다는 것을 쓰는 항목이 없습니다. 실패만을 입력하는 루프는 금지만 출력할 수밖에 없습니다 - corrections와 대칭되는 wins(성과 로그)를 추가하여, 「3회 재발 → 금지」의 반대 방향으로 「3회 재현 → 할 일 승격」의 배선을 구축했습니다.
• 전작은 공개 53일 만에 조회수 94회였습니다. 본작에는 day30의 판정일과 비교 기준을 처음부터 심어두었으며, 결과가 어느 쪽이든 후속편에서 작성하겠습니다.

지난번 줄거리와 그 이후의 숫자

지난번에 저는 .claude/ 의 유통기한이 다 되어버리는 문제라는 글을 썼습니다. 워크플로우(workflow) 완료 시마다 JSON 로그를 생성하고, 5개가 쌓이면 review가 발화하며, 3회 재발한 issue는 규칙 파일에 amend됩니다. 규칙을 정적으로 써두고 끝내는 것이 아니라, 관찰하며 계속해서 다시 쓰는 메커니즘에 대한 이야기입니다.

먼저 전작의 성적을 적어두자면, 공개 후 53일 동안 조회수는 94회였습니다. 메커니즘에 대한 이야기는 쓸 수 있어도, 전달되지는 않았습니다. 이 기사는 그 양쪽 모두의 연속된 이야기입니다.

그 이후로도 루프는 계속 돌아갔습니다. 숫자만 나열하겠습니다.

• 실행 로그: 83개
• review 리포트: 12개
• amendment: 20개
• 이 8주 동안 신설한 규칙 게이트(rule gate): 5개

마지막 한 줄이 오늘의 주인공입니다. 신설한 5개는 날짜순으로 나열하면 다음과 같습니다.

전부 브레이크입니다. 엔진이 단 하나도 없습니다.

각각 단독으로 보면 올바른 규칙입니다. 실제로 vacancy-gate는 레드 오션에 뛰어들 뻔한 기사 1개를 막아냈고, record-vs-reality는 「한 번도 발송되지 않은 뉴스레터」를 「매주 도착합니다」라고 쓰려 했던 사고에서 탄생했습니다. 멈춰서 다행이었던 장면은 분명히 있었습니다.

다만, 8주 동안 브레이크가 5개 늘어나는 동안 외부로 나가는 성과물의 수는 늘어나지 않았습니다. 규칙은 늘어나고, 시스템은 정교해지며, 커밋(commit)은 진행됩니다. 하지만 숫자는 움직이지 않습니다.

중간부터 저는 이것을 「교칙」이라고 부르게 되었습니다.

amendment를 20개 세어보니 「깎아내기」가 0개였다

지난 기사에서 저는 이렇게 썼습니다.

change_type은 8가지 유형으로 정의해 두었습니다. 「더하기」뿐만 아니라 「순서 바꾸기」, 「깎아내기」도 선택할 수 있도록 했습니다. 이것이 나중에 효과를 발휘합니다.

회수하겠습니다. 20개의 amendment의 change_type을 실제로 계산한 결과는 다음과 같습니다.

instruction_addition 10개 (지시 추가)
instruction_strengthening 5개 (기존 지시 강화)
workflow_change 2개 (플로우 변경)
...

「깎아내기」 버튼은 반년 동안 단 한 번도 눌리지 않았습니다. 선택할 수 있게 해두기만 했을 뿐, 선택할 이유가 루프의 어디에서도 발생하지 않습니다. 규칙 파일은 일방향으로 계속 비대해집니다.

게다가 amend의 내용을 보면, 20개 모두가 「~하지 마라」, 「~를 반드시 확인해라」 계열입니다. 「이것이 효과가 있었으니 매번 수행해라」라는 amendment는 단 하나도 없습니다.

원인은 스키마에 있었다

왜 금지만 나오는가. 로그의 스키마(schema)를 재검토했더니 답은 그곳에 적혀 있었습니다.

로그에 기록되는 품질 시그널(quality signals)은 다음과 같습니다.

"quality_signals": {
"user_approved_first_try": false,
"total_corrections": 1,
...

corrections(무엇이 수정되었는가), errors(무엇이 실패했는가), issues(어느 단계에 문제가 있었는가). 전부 결함의 기록입니다. 유일한 양성 시그널은 user_approved_first_try: true이지만, 이것은 「수정이 없었다」는 부재의 기록일 뿐, 「무엇이 효과가 있었는가」에 대한 기록이 아닙니다.

즉, 이 루프가 최적화하고 있었던 것은 「내가 수정 지시를 내리지 않아도 되는 생산」이었지, 「결과물이 외부에서 효과를 발휘하는 것」과는 처음부터 연결되어 있지 않았다.

• 실패 → 수정 지시가 나옴 → corrections에 자동으로 남음 → 3회 반복 시 금지 규칙으로 승격
• 성공 → 아무 일도 일어나지 않음 → 어디에도 남지 않음 → 승격될 대상이 없음

실패는 저절로 울립니다. 수정 지시라는 형태로, 저쪽에서 찾아옵니다. 승리는 울리지 않습니다. 기사가 급증하거나, 구현이 비정상적으로 빨리 끝나더라도, 로그에 기록할 칸이 없다면 그대로 사라집니다.

증거가 하나 더 있었습니다. 83개의 로그에서 top-level key를 집계했더니, 스키마에 없는 필드가 멋대로 생겨나 있었습니다.

metrics 4회
notable_patterns 4회
outcomes 3회
...

기록하는 측(Claude 자신)이 「이것은 남겨두어야 한다」고 판단하여, 그 자리에서 칸을 발명하고 있었습니다. 하지만 정식 필드가 아니기에 review의 집계 대상이 되지 않습니다. 쓰고 버려지는 것입니다. 필요성은 4회 실증되었으나, 단지 시스템에 올라타지 못했을 뿐이었습니다.

마이너스가 제로가 될 뿐

부족한 점을 계속해서 없애다 보면 강해질 것이라고, 반년 동안 어딘가에서 굳게 믿고 있었습니다.

실제로 일어나는 일은 그렇지 않았습니다. 결함을 없애면, 열등했던 부분이 평범해집니다. 마이너스가 제로가 됩니다. 그것은 중요한 업무이지만, 제로를 플러스로 만드는 업무와는 별개입니다. 금지 규칙을 100개 쌓아도, 강점은 1mm도 자라지 않습니다.

이것은 이 루프에만 국한된 이야기는 아니라고 생각합니다. 에이전트의 검증 (verification)은 테스트가 통과하는지, lint가 통과하는지, 리뷰어가 거절하는지, 라는 **거절의 기제 (mechanism)**로서 설계되는 경우가 대부분입니다. 나쁜 작업을 걸러내는 게이트는 구축합니다. 효과적인 작업을 포착하여 증폭시키는 배선은 구축되지 않습니다.

이유 또한 구조적입니다. 거절은 수동적이어도 되지만 (실패 쪽에서 찾아오니까), 가점은 능동적이지 않으면 성립하지 않습니다 (승리는 사냥하러 가지 않으면 발견되지 않으니까). 그래서 자연스럽게 만들면, 누구의 루프든 교칙 제조기로 기울어지게 됩니다.

고친 배선

제가 한 일은 새로운 규칙을 추가하는 것이 아니라, 장부의 극성을 하나 늘리는 것이었습니다. 파일은 늘리지 않았습니다.

1. 스키마에 wins와 outcome을 추가

"wins": [
{
"what": "무엇이 효과적이었는가 (재현 가능한 조작으로서 한 문장)",
...

wins는 corrections의 거울상입니다. recurring 판정도 같은 메커니즘이며, 동일한 what이 3회 재현되면 「해야 할 일」로의 승격 후보가 됩니다. 금지 규칙의 승격과 완전히 대칭입니다.

outcome의 measured_at에는, 기록 시점에 미래 날짜 (공개 후 +30일 기준)를 넣습니다. 「나중에 숫자를 확인한다」는 것을 의지에 맡기지 않고, 큐 (queue)로 바꿉니다. 판정일이 된 로그는 review가 「판정 대기」로서 열거합니다.

kind는 3가지로 나누었습니다. 도달 방식의 승리 (reach), 만드는 방식의 승리 (craft), 박히는 방식의 승리 (product). 종류가 다른 강점을 동일한 장부에 올리기 위한 태그이며, 재현 테스트의 주기와 증폭 대상만이 종류별로 달라집니다. reach라면 동일한 형태를 3회 도출하고, craft라면 다른 프로젝트에서 동일 작업이 다시 저렴하게 수행되는지 확인하며, product는 의도적 재현이 어려우므로 3건의 방증으로 확정합니다.

2. log 시 「효과적이었던 것에 대한 자문」을 필수화

로그 기록 절차에 한 항목을 추가했습니다. 「이번에 명백히 잘 풀린 조작·패턴·판단이 있었는가? 없다면 빈 배열로 두어도 좋다. 단, 반드시 한 번은 자문할 것」.

실패는 자동으로 남기 때문에 자문이 필요 없습니다. 승리는 자문하지 않으면 남지 않습니다. 이 비대칭을 절차로 메웁니다.

3. amend에 「승격」과 「철거」를 추가

change_type에 두 가지를 추가했습니다.

• strength_promotion — 3회 재현된 wins를 OK 사례·필수 절차로서 규칙에 기록한다. 증거가 되는 숫자를 반드시 병기한다 (근거 없는 필수 절차는 그 자체로 다음 교칙이 되기 때문).
• gate_retirement — 장기간 발동되지 않았거나, 발동하더라도 대체 행동을 만들어내지 못하는 게이트의 철거.

함께 모니터링을 하나 추가했습니다. 최근 10개의 amendment 중 8개 이상이 제약 계열이라면 「교칙 양산으로 기울고 있음」이라고 경고를 보냅니다. 반년 전의 저라면 이것으로 검출되었을 것입니다.

4. eval에 스루풋 (throughput)의 부작용 체크를 추가

게이트를 추가한 수정(amendment) 평가에, "대상 이슈(issue)의 발생률이 낮아졌는가"에 더해 "적용 후 30일 동안, 외부로 나간 결과물의 수가 줄어들지 않았는가"를 필수 항목으로 추가했습니다.

이슈가 줄어들더라도 공개 본수가 줄어들었다면, 그것은 개선이 아니라 유해(HARMFUL) 후보입니다. 기존의 eval(평가)은 품질과 맞바꾸어 생산을 멈추게 하는 게이트를 계속해서 통과시켜 왔습니다.

5. 초기 재고를 거슬러 올라가 5건 생성하기

wins(승리 사례)가 0건이면 다음 review(검토)도 헛스윙하게 됩니다. 과거의 승리 사례를 거슬러 올라가 5건만 기록했습니다. X 게시물이 압도적으로 늘어났던 회차의 포맷, 여러 앱에서 반복했던 수작업을 스킬화하여 이후 동일 작업이 급감한 사례(craft형의 전례) 등. 모든 건에 next_test (재현을 위한 다음 한 수)를 붙여 두었습니다.

이 기사 자체가 첫 번째 실험입니다

이 기사의 집필 로그에는 처음부터 outcome(결과)을 심어 두었습니다.

"outcome": {
"metric": "pv",
"baseline": "이전 기사의 day30 실적",
...

베이스라인은 전작의 94회(53일 시점)입니다. 동일한 채널, 동일한 저자, 동일한 테마 계열의 속편이므로 조건은 어느 정도 갖춰져 있습니다. 수치가 오르든 떨어지든, 그 숫자는 wins(승리) 혹은 "flat(정체)"로서 장부에 기록되어 다음 review(검토)의 입력값이 됩니다.

즉, 이 기사는 가점 루프(加点 loop)에 던져 넣은 첫 번째 돌입니다. 결과가 어느 쪽으로 기울더라도 후속 보고를 쓸 수 있도록, 판정일마다 기사에 적어 두겠습니다.

설계 레벨의 교훈

반년 전의 교훈은 "올바른 규칙을 쓰는 것보다, 부패했을 때 알아차리는 메커니즘"이었습니다. 이번에는 그 연장선입니다.

• 검증 게이트는 기각(reject)만 할 수 있다.
  나쁜 작업을 걸러내는 배선과, 효과적인 작업을 증폭하는 배선은 별개이며, 후자는 의도적으로 설계하지 않으면 존재하지 않는다. 실패는 수동적으로 모이지만, 승리는 능동적으로 사냥해야만 한다. "기록하는 칸"과 "자문하는 절차"가 없다면 승리의 기록은 영원히 0인 채로 남는다.
• 단순히 "깎아내기"를 선택할 수 있게 만드는 것만으로는 깎이지 않는다. 제거든 승격이든, 트리거(trigger)와 증거를 둘 장소가 필요하다.
• 게이트의 평가에는 그것이 막아낸 사고의 수뿐만 아니라,
  막아버린 생산의 수를 포함해야 한다.

잘못된 부분이 전부 사라진 에이전트 운용의 도달점은 "결함 없는 평균"입니다. 그곳에는 강점이 없습니다. 금지로 방어하고, 공적으로 성장시킵니다. 장부는 양쪽의 극성을 모두 가지고 있지 않으면 한쪽 날개로만 계속 선회하게 됩니다.

후속 보고 약속

8월 월간 리뷰에서 이 배선이 첫 판정을 받게 됩니다. 확인할 것은 두 가지입니다. wins(승리) 장부에 신규 항목이 쌓였는지, 그리고 이 기사 자체의 outcome(결과)이 어떻게 나왔는지입니다.

"고쳤더니 효과가 있었습니다"로 끝나는 기사는 아마 되지 않을 것입니다. 반년을 돌리며 깨달은 것은 메커니즘은 반드시 어딘가에서 부패한다는 사실이기에, 다음에는 이 가점 루프가 어떻게 부패했는지를 쓸 가능성이 더 높습니다. 그것까지 포함하여 기록하겠습니다.

평소에는 개인 개발과 운용 설계를 자신의 현재 위치를 관측하는 축으로 삼아 블로그와 X에 쓰고 있습니다. 규칙을 늘리는 것보다 "자신의 루프가 무엇을 양산하고 있는가"를 관측하는 이야기에 관심이 있다면, X (@rkpg10)도 방문해 주세요.

Discussion