우선 오해를 하나 바로잡고 가겠습니다

「자기 개선하는 AI 팀」이라고 하면, AI가 자신의 가중치(Weights)를 스스로 업데이트하며 학습해 나가는 모습을 상상하기 쉽습니다. 하지만 그렇지 않습니다.

실제 서비스 중인 모델은 누군가의 세션으로부터 자신의 가중치를 마음대로 써 내려가지 않습니다. 즉, self-improving(자기 개선) ≠ self-learning(자기 학습) 입니다.

그렇다면 무엇이 「개선」되는 것일까요? 개선되는 것은 모델 외부에 있는 시스템——STATE 파일, Skill, 평가 루프(Evaluation loop)——입니다. 모델 본체는 스테이트리스(Stateless) 상태를 유지합니다. 그 주변에 지견이 복리로 쌓여가는 것입니다.

모델은 스테이트리스이지만, 그 주변의 시스템은 그렇지 않습니다.

이 한 문장이 앞으로 이야기할 모든 내용의 출발점입니다.

전체상: 4층 아키텍처

자기 개선 루프는 대략 4개의 층으로 돌아갑니다.

포인트는 Layer 1의 모든 출력이 위로 흘러가 채점·증류(Distillation)되고, Layer 3~4에서 기억으로 돌아간다는 것입니다. 내일의 실행은 어제 연마된 Skill과 기억을 계승한 상태에서 시작된다. 이것이 「복리」의 정체입니다.

모델을 구분해서 사용하기 (비용 라우팅)

이 부분이 구현에서 가장 효과적임에도 불구하고 의외로 간과되기 쉬운 부분입니다.

모든 단계에 최강 모델을 사용해서는 안 됩니다.

자기 개선 루프를 실무에서 돌리고 있는 팀의 정석은, 태스크의 복잡도에 따라 모델을 라우팅(Routing)하는 구성입니다.

역할	사용하는 모델	하는 일
오케스트레이터 (Orchestrator)	최상위 모델 (예: Fable 5)	여러 날에 걸친 계획, 서브 에이전트(Sub-agent)로의 위임, 시각적인 성과 확인
...

이유는 단순합니다. 상위 모델은 토큰 단가가 높기 때문입니다. Fable 5는 Opus 4.8의 약 5배 단가(input $10 / output $50 per 1M tokens)입니다. 이 가격에 걸맞은 것은 「며칠 연속으로 자율 실행하는」 오케스트레이션 용도이지, lint 수정 같은 잡무에 사용하는 것은 돈 낭비입니다.

자기 개선을 성립시키는 4가지 부품

구성 요소는 이것뿐입니다. 반대로 말하면, 이 4가지만 갖춰지면 모델은 무엇이든 상관없습니다.

1. 실행 로그가 남을 것

무엇을 했고, 무엇에 실패했는가. 이것이 없으면 증류할 재료가 없습니다. 성공뿐만 아니라 실패의 기록이 본체입니다.

2. 평가기 (독립 검증이 핵심)

자기 비판(Self-criticism)을 시키면 채점이 관대해집니다. 인간과 마찬가지입니다.

구현상의 요점은, 만드는 자와 검증하는 자를 나누는 것입니다.

• 만드는 에이전트는 자신의 추론 과정을 전부 보고 있음
• 검증하는 에이전트에게는 성과물과 채점 기준만 보여줌 (추론 과정은 보여주지 않음)

Anthropic의 엔지니어도 "Fable 5에서는 검증 서브 에이전트가 자기 비판보다 성능이 잘 나오는 경향이 있다"라고 보고했습니다. 독립된 검증자를 붙인 구성이 파이프라인 개선을 대폭 진전시켰다는 실험 결과도 있습니다.

평가기의 내용은 모델의 채점에 국한되지 않습니다. 테스트가 통과하는지, lint가 clean한지 역시 훌륭한 평가기입니다. 오히려 기계적으로 판정할 수 있는 것은 그쪽이 더 저렴하고 확실합니다.

# Claude Code의 /goal은 「달성 조건」을 평가기로 사용할 수 있음
/goal all tests in test/auth pass and the lint step is clean
# 비대화형으로도 실행 가능
...

3. 증류 대상 파일

채점 결과에서 추출한 교훈을 다시 쓰는 곳. AGENTS.md, Skill, decisions.md와 같이, 다음 세션이 반드시 참조하는 파일입니다.

4. 다음 세션이 그것을 읽어들이는 메커니즘

다시 써두어도 다음 세션이 읽지 않으면 의미가 없습니다. 세션 기동 시 증류된 파일을 반드시 로드한다——여기까지 포함되어야 비로소 루프가 완성됩니다.

다른 AI에서도 응용할 수 있는가 → 할 수 있다

위의 4가지 부품을 보면 알 수 있듯이, **이 메커니즘은 모델 비의존적(Model-agnostic)**입니다.

Codex든 Gemini든, 다음이 갖춰지면 동일한 원리가 성립합니다.

• 실행 로그가 남는다
• 평가기가 있다 (테스트, lint, 다른 모델의 채점 등 무엇이든 상관없음)
• 증류 대상 파일이 있다 (AGENTS.md 등에 해당)
• 다음 기동 시 그것을 읽어들인다

특정 모델의 기능에 의존하는 부분은 사실 어디에도 없습니다. 똑똑함의 복리는 모델이 아니라 하네스(Harness) 측에 쌓이기 때문입니다.

구현의 함정: 자기 개선 루프(Self-improving loop) × 신뢰 경계(Trust Boundary)

마지막으로, 실제 운영 환경(Production)에서 돌릴 때 절대로 밟아서는 안 될 지뢰를 하나 소개합니다.

Layer 4의 '쓰기 대상(Write-back target)'을 실행 규칙 그 자체(AGENTS.md나 통제 문서)에 직접 연결하면 다음과 같은 상황이 발생합니다.

실패한 실행의 산물 ──쓰기(Write-back)──▶ 다음 회차의 「헌법」이 됨

외부에서 가져온 정보(Web, HTML, PDF, OCR 결과, GitHub Issue/PR 등)는 모두 신뢰할 수 없는 데이터이며 명령이 아니다라는 원칙을 세워두었다면, 이는 정면으로 충돌하게 됩니다. 프롬프트 인젝션(Prompt Injection)을 포함한 실행 결과가 그대로 다음 회차의 규칙으로 승격될 수 있기 때문입니다.

대책: 쓰기 게이트(Write-back Gate)를 인간이 통제한다

증류(Distillation) 결과를 곧바로 정규 규칙에 쓰게 하지 마세요. **대기 영역(Staging Area)**에 쓰게 해야 합니다.

git push를 인간만이 제어하는 것과 같은 발상입니다. 루프의 복리 효과는 거의 놓치지 않으면서, 통제권만은 사수할 수 있습니다. AI는 설계와 증류까지, 불가역적인 승격은 인간이 담당합니다. 이 선을 긋느냐 아니냐에 따라 자기 개선 시스템은 '알아서 똑똑해지는 자산'이 될 수도, '알아서 오염되는 부채'가 될 수도 있습니다.

자산을 유지하기: 재고 조사 게이트(Inventory Gate)

쓰기 게이트가 '입구'의 통제라면, 한번 승인하여 통과시킨 규칙이 시간이 흐름에 따라 부패하는 것은 입구 게이트만으로는 막을 수 없습니다.

승인된 규칙이라도 다음과 같은 문제가 발생합니다.

• 노후화(Obsolescence): 당시의 버그를 해결하기 위해 만든 규칙이, 코드가 변경되어 더 이상 맞지 않음에도 남아 있음
• 모순(Contradiction): 나중에 들어온 규칙이 이전 규칙과 충돌하여, AI가 어느 쪽을 따를지 도박을 해야 하는 상황이 됨
• 비대화(Bloating): 규칙이 늘어나 컨텍스트(Context)를 압박함. 프롬프트 캐시(Prompt Cache) 대상이라면 그대로 비용 증가로 이어짐

입구 게이트가 '플로우(Flow, 유입)'의 통제라면, 재고 조사는 '스톡(Stock, 재고)'의 통제입니다. 둘 다 없으면 자산을 유지할 수 없습니다.

'정기적'인 것보다 '발화 로그(Trigger Log) 기반'으로

재고 조사를 시간 기반(매달 수행 등)으로 설정하면 형식적으로 흐르기 쉽습니다. 바쁜 달에는 건너뛰게 되고, 결국 아무도 하지 않게 됩니다. 인간의 의지력에 의존하는 메커니즘은 취약합니다.

대신, 실행 로그에 「어떤 규칙이 실제로 발화(Fire)했는가」를 남깁니다. 여기서도 Layer 1의 로그가 효과를 발휘합니다. 일정 기간 발화하지 않은 규칙은 재고 조사 후보로 자동 추출됩니다. 트리거는 시간이 아니라 「규칙 수가 임계치를 초과함」, 「캐시 사이즈가 임계치를 초과함」, 「모순을 감지함」과 같은 이벤트로 설정합니다.

이렇게 하면 '감으로 하는 재고 조사'가 아니라 '데이터에 의해 후보가 올라오는' 방식이 됩니다. 인간은 판단만 합니다. 쓰기(Write-back)와 마찬가지로 비대칭 구조입니다. 즉, AI가 후보를 추출하고, 인간이 폐기 승인을 내리는 것입니다.

삭제가 아닌 「무효화(Invalidation)"

증류 대상이 append-only 설계라면, 물리적 삭제는 그 원칙을 깨뜨립니다. 재고 조사는 삭제가 아닌 tombstone(무효화 마크) 방식으로 처리합니다. 상태를 deprecated로 변경하고, 「왜 무효화했는지」를 남깁니다. git 히스토리가 있으므로 실수로 지워도 복구할 수 있습니다. 폐기 또한 승인 게이트를 통과해야 합니다. 재고 조사에서 지운 규칙이 사실은 필요했던 것이라는 회귀(Regression) 문제를 방지하기 위해서입니다.

규칙의 생애 주기는 다음과 같습니다.

★가 입구와 출구 양쪽에 있습니다. 넣는 것도 지우는 것도 인간의 승인을 거칩니다. 이 한 쌍이 있어야만 자기 개선 시스템이 '알아서 오염되는 부채'로 전락하지 않고, '알아서 똑똑해지는 자산'의 쪽에 머무를 수 있습니다.

요약

• 자기 개선(Self-improvement) ≠ 자기 학습(Self-learning). 개선되는 것은 모델이 아니라 하네스(Harness)다.
• 4개 계층(실행→검증→증류→쓰기)으로 순환하며, 내일이 오늘을 계승한다.
• 모델은 복잡도에 따라 라우팅(Routing)한다. 전부 최강 모델을 쓰는 것은 정확도 향상에 도움이 안 될 뿐더러 돈 낭비다.
• 부품(로그, 평가기, 증류 대상, 차기 로드 대상)이 갖춰지면 모델에 의존하지 않고 응용 가능하다.
• 쓰기 게이트(입구)만큼은 인간이 쥐어야 한다. 그렇지 않으면 신뢰 경계가 무너진다.
• 재고 조사 게이트(출구)를 통해 승인된 규칙의 부패도 막아야 한다. 넣는 것도 지우는 것도 승인제여야 한다.

똑똑함의 복리는 모델 내부가 아니라, 당신이 설계한 하네스 안에 쌓입니다.

Discussion