스스로 고치고, 그 고침마저 정리하는 harness

agent랑 일하다 보면 같은 실수를 또 마주칠 때가 있어요. 잘못된 명령어 형태, 오래돼서 안 맞는 instruction, permission을 우회하던 임시방편, 진작에 알았어야 할 검색 경로 같은 것들이요. 한 session이 알아채고, 당장 급한 문제만 고친 뒤 넘어가요. 그리고 일주일 뒤 다른 session이 똑같은 실수를 반복해요. 그때 얻은 교훈이 시스템의 일부가 된 적이 없으니까요.

3B는 이걸 아키텍처 문제로 봐요.

friction은 단순히 기분의 문제가 아니에요. 데이터죠. agent가 tool의 함정을 밟거나, 잘못된 가정을 하거나, 빠진 rule을 발견하거나, permission에 막혔다면, 그 순간의 맥락이 아직 생생할 때 붙잡아 두고 싶은 거예요.

아플 때 바로 붙잡아요

붙잡는 창구는 일부러 여러 agent가 같이 쓰도록 만들었어요.

Codex, AGY, Claude 모두 runtime에 상관없이 같은 스크립트를 쓸 수 있어요.

node scripts/report-friction.js --target <type> --severity <sev> --description "..."

이 스크립트는 target과 severity를 검증하고, [FRICTION] 블록을 만든 뒤, 공용 buffer writer를 거쳐 .agents/buffer.md에 덧붙여요. buffer는 최종 저장소가 아니에요. 붙잡아 두는 대기열이죠.

이 구분이 중요해요. friction을 session 끝까지 미뤄두면, agent가 정확히 어떤 식으로 실패했는지 잊어버릴 수 있어요. 반대로 곧장 영구 rule로 박아 넣으면, 시스템이 단 하나의 짜증에 과하게 맞춰져 버려요. buffer는 그 관찰을 잠시 머물게 해줘요. /wrap이 나머지 session 맥락과 함께 처리할 수 있을 때까지요.

`/wrap`이 관찰을 패턴으로 바꿔요

/wrap을 돌리는 동안, friction 분석 단계가 buffer 항목을 읽어요. 구조화된 관찰로 파싱하고, 비슷한 관찰끼리 묶은 뒤, .agents/friction-log.json을 업데이트하죠.

관찰 하나가 곧바로 rule이 되지는 않아요. 기본 경로는 반복을 요구해요. 같은 종류의 friction이 충분히 여러 번, 충분히 여러 session에 걸쳐 나타나야 해요. 그래야 한 번의 실수가 아니라 진짜 패턴이라는 게 증명되죠. 심각한 사고는 이 대기 기간을 건너뛸 수 있지만, 평범한 friction은 고침을 받을 자격을 직접 벌어야 해요.

여기가 핵심적인 규율이에요. 스스로 개선하는 harness는 두 가지 나쁜 본능을 동시에 눌러야 하거든요.

“그냥 워크플로 짜증일 뿐”이라며 friction을 무시하기.
모든 짜증을 곧바로 rule로 만들어 버리기.

3B는 그 양극단 사이에 서 있어요. 기억할 가치가 있는 건 전부 붙잡되, 반복되거나 당장 손볼 만큼 심각한 것만 승격시켜요.

정책과 메커니즘을 일부러 나눴어요

friction 시스템에는 두 가지 lifecycle 설명이 있어요.

거버넌스 관점은 단순해요. observation -> accumulating -> ready -> resolved. 이게 정책 이야기예요. 언제 패턴이 고침을 고려할 만큼 무르익었는지, 언제 고침을 archive로 보낼 수 있는지 말해주죠.

운영 관점은 더 풍부해요. /wrap이 실제 워크플로를 돌려야 하니까요. 여기엔 proposed, applied, verified, dismissed, ineffective, strengthened 같은 상태가 들어가요. 이게 메커니즘 이야기예요. 사람이 적용, 나중에, 기각, 강화, 되돌리기를 말했을 때 무슨 일이 벌어지는지 설명하죠.

언뜻 보면 lifecycle 모델이 둘이라는 게 표류처럼 보일 수 있어요. 그런데 이 경우엔 나누는 게 쓸모 있어요. 4단계 모델은 rule을 만드는 사람과 거버넌스를 위한 거예요. runtime 상태 기계는 session 엔진을 위한 거고요. 하나는 왜 패턴이 졸업해야 하는지 설명하고, 다른 하나는 그 졸업을 어떻게 실행하는지 설명해요.

고침은 제안될 뿐, 조용히 적용되지 않아요

시스템은 고침 초안을 잡을 수 있어요. diff를 준비할 수도 있고요. 증거와 반복 횟수, 영향받는 target, 제안하는 개선안까지 담은 패턴 카드를 보여줄 수도 있어요.

그래도 고침을 조용히 적용하지는 않아요.

이건 무게를 떠받치는 rule이에요. friction 고침은 settings, rule, hook, skill instruction을 건드릴 때가 많아요. 전부 control-plane 영역이죠. 잘못된 고침은 앞으로의 session을 더 나쁘게 만들 수 있어요. 그래서 시스템은 선택지를 내놔요. 적용, 기각, 나중에, 강화, 되돌리기. 사람은 계속 그 고리 안에 남아 있어요.

여기서 8편의 gate 이야기와 9편의 friction 이야기가 만나요. Gate B는 위험한 변경을 관장해요. friction lifecycle은 그런 변경 중 일부를 제안하고요. 제안은 똑똑할 수 있지만, 적용은 여전히 gate를 거쳐요.

검증은 반복에 관한 거예요

friction 고침은 patch가 들어갔다고 증명되는 게 아니에요.

그 실수가 더 이상 반복되지 않을 때 증명돼요.

패턴이 적용된 뒤, 이후 /wrap session들은 같은 패턴에 들어맞는 새 관찰이 있는지 지켜봐요. 같은 friction이 또 나타나면, 시스템은 적용 후 반복 횟수를 늘려요. 반복이 ineffective 임계값을 넘으면, 그 패턴은 해결됐다고 보지 않아요. 강화 경로로 넘어가죠.

이게 “rule을 추가했으니 끝”보다 나은 모델이에요. rule은 너무 약하거나, 너무 모호하거나, 너무 넓거나, 엉뚱한 target을 겨눌 수 있거든요. 반복이야말로 피드백 신호예요.

검증 기간이 반복 없이 지나가면, 패턴은 verified가 되고 결국 활성 log에서 빠져나가요.

harness는 스스로 가지치기도 해요

스스로 개선하는 시스템은 흉터 조직을 쌓아가는 경향이 있어요.

오래된 실패 하나하나가 알림 하나, hook 하나, rule 하나, 경고 하나를 더 남겨요. 처음엔 그게 더 안전하게 느껴져요. 그런데 결국 agent는 지금 문제를 푸는 것보다 옛 실수를 피하는 데 더 많은 context를 쓰게 돼요.

3B는 은퇴 경로로 거기에 맞서요.

해결되고 검증된 friction은 활성 log에서 archive로 옮겨갈 수 있고, 역사적 맥락으로 아직 쓸모가 있다면 나중에 knowledge로 갈 수도 있어요. 적용된 고침은 충분한 시간이 지나면 일몰 검토를 받을 수 있어요. 클러스터 감지 휴리스틱은 사용자가 너무 자주 기각하면 은퇴할 수 있고요. 구조적 고침이 실패를 기계적으로 불가능하게 만들면, 알려진 실패 유형 항목은 건너뛸 수 있어요.

마지막 생각이 중요해요. 모든 교훈이 prompt에 영원히 남을 자격이 있는 건 아니에요. pre-commit hook이 이제 그 나쁜 상태를 막아준다면, 그러지 말라고 기억하라는 경고는 군더더기일 수 있어요. 더 이상 빠질 수 없는 함정을 두고 기계가 계속 context를 지불할 이유는 없어요.

내가 가져다 쓸 부분

다시 쓸 만한 설계는 이 고리예요.

friction을 즉시 붙잡아요.
구조화된 관찰로 저장해요.
반복되거나 심각한 패턴만 승격시켜요.
증거와 함께 고침을 내놓고, 사람이 고르게 해요.
반복을 지켜보며 검증해요.
고침이 실패하면 강화하거나 되돌려요.
활성 휴리스틱이 비용값을 못 하게 되면 은퇴시켜요.

그 고리가 개별 스크립트 하나하나보다 중요해요.

교훈은 agent가 아플 때마다 스스로 rule을 마음대로 다시 쓸 수 있다는 게 아니에요. 교훈은 agent의 아픔이 관리되는 증거가 될 수 있다는 거예요. 일단 증거가 오래 남으면, 시스템은 무엇이 rule을 받을 만한지, 무엇이 hook을 받을 만한지, 무엇이 knowledge 항목을 받을 만한지, 무엇이 삭제될 만한지 판단할 수 있어요.

그게 바로 스스로 고치되, 모든 고침이 영원히 살아야 한다고 우기지 않는 harness예요.