매일 밤 나의 OpenClaw 에이전트에 자기 개선 루프(Self-Improvement Loop)를 실행하며 배운 것들

지난달 나의 OpenClaw 에이전트는 계속해서 똑같은 실수를 반복했습니다. 헬스 체크(health check)를 실행하면 스크립트가 소리 없이 실패하고, 에이전트는 아주 자신 있게 "모든 시스템이 정상 작동 중"이라고 보고하곤 했습니다. 에이전트가 고장 난 것은 아니었습니다. 그저 결과로부터 배울 수 있는 메커니즘 없이, 설계된 대로—즉, 작업(task)을 실행하는 것—만 수행하고 있었을 뿐입니다.

그래서 저는 에이전트에 자기 개선 루프(self-improvement loop)를 구축했습니다. 매일 밤 새벽 2시가 되면, 격리된 OpenClaw 세션이 깨어나 전날의 실행 로그(execution logs)를 읽고, 무엇이 잘못되었는지 패턴을 식별하며, 에이전트의 메모리 파일(memory files)을 업데이트합니다. 인간의 개입(human in the loop)도, 재배포(re-deployment)도 없습니다. 그저... 학습할 뿐입니다.

제가 무엇을 만들었는지, 무엇이 고장 났는지, 그리고 실제로 무엇이 작동하는지 소개하겠습니다.

개인용 에이전트에게 자기 개선이 어려운 이유

기업용 AI 연구소들은 거대한 인프라를 통해 이 문제를 해결합니다. 강화학습 (Reinforcement Learning) 파이프라인, 전체 미세 조정 (Full Fine-tuning) 작업, 몇 주 동안 실행되는 A/B 테스트 프레임워크 등이 그것입니다. 크론 잡 (cron job)으로 실행되는 개인용 에이전트에게는 그런 방식이 선택지가 될 수 없습니다.

개인용 OpenClaw 설정을 위한 자기 개선 루프는 가벼워야 합니다. 몇 시간이 아니라 몇 초 내에 실행되어야 합니다. 다음 세션이 실제로 읽을 수 있는 일반 텍스트 파일에 기록해야 합니다. 그리고 결정적으로, 피드백 루프 문제(feedback loop problem)—닻(anchor)이 없다면 자신의 개선 로직을 스스로 다시 쓰는 에이전트가 엉뚱한 방향으로 치달을 수 있는 문제—를 피해야 합니다.

제가 내린 핵심적인 아키텍처 결정은 다음과 같습니다: 실행자(executor)와 비판자(critic)를 분리하는 것입니다. 메인 에이전트는 작업을 수행합니다. 별도의 격리된 세션은 무슨 일이 일어났는지 검토하고 변경 사항을 권장합니다. 메인 에이전트는 다음 실행 시 이를 적용합니다. 단일 세션이 심판이자 집행자가 되어서는 안 됩니다.

야간 크론(Nightly Cron): 실제로 실행되는 것

이것은 제가 매일 아침 미국 동부 표준시(ET) 기준 새벽 2시에 실행하도록 설정한 크론(cron)입니다:

{
  "name": "nightly-self-improvement",
  "schedule": { "kind": "cron", "expr": "0 2 * * *", "tz": "America/New_York" },
...

프롬프트는 의도적으로 제약되었습니다. 에이전트에게 추상적으로 "스스로를 개선하라"고 요구하는 것이 아니라, 특정 패턴을 증거와 함께 특정 파일에 작성하도록 요구합니다. 그것이 고정점(anchor)입니다. 출력물은 메인 에이전트가 다음에 확인할 수 있는 어딘가로 전달됩니다.

메모리 계층 (Memory Layer): 서로 다른 역할을 하는 세 가지 파일

자기 개선 시스템은 각기 다른 목적을 가진 세 가지 파일을 사용합니다:

memory/YYYY-MM-DD.md — 가공되지 않은 일일 로그 (raw daily log). 모든 세션은 여기서 발생한 일을 기록합니다. 이는 검토(review)를 위한 입력값이 됩니다.

~/self-improving/memory.md — 축적된 교훈 (accumulated lessons). 야간 검토(nightly review) 과정에서 보관할 가치가 있는 것을 발견하면 여기에 기록합니다. 이는 메인 에이전트가 세션 시작 시 읽는 파일입니다. 신호(signal)는 높고 노이즈(noise)는 낮습니다.

~/self-improving/corrections.md — 최근 수정 사항 (recent fixes). 에이전트가 실수하고 제가 이를 바로잡을 때, 여기에 기록합니다. 야간 검토는 이를 읽고 동일한 실수가 반복되는지 확인합니다. 만약 반복된다면, 그 수정은 구조적으로 충분하지 않았다는 뜻입니다. 단순한 상기(reminder)가 아니라 설정(config) 변경이 필요합니다.

제가 배운 규칙은 다음과 같습니다: 수정 사항은 (제가 인지했을 때) 즉시 corrections.md에 기록합니다. 야간 크론(nightly cron)은 2주 동안 3회 이상 발생하는 반복적인 수정 사항을 memory.md로 승격시킵니다. 일회성 실수는 corrections.md에 머물다가 결국 정리(pruned)됩니다.

스스로를 검토하는 프롬프트

다음은 제가 야간 검토 세션에서 실제로 사용하는 프롬프트입니다. 이는 격리된 서브 에이전트(sub-agent)에서 실행됩니다:

당신은 야간 검토 에이전트(Nightly Review Agent)입니다. 당신의 임무는 에이전트의 행동 패턴을 찾아내고 개선 사항을 권장하는 것입니다.

다음 파일들을 읽으세요:
...

이 프롬프트에는 아첨 방지(anti-sycophancy) 조항이 내장되어 있습니다: "더 많은 크론 잡(cron jobs)이나 에이전트를 추가하라고 권장하지 마십시오." 저는 두 번째 검토 세션에서 47개의 예약된 작업이 실행되어야 한다는 제안을 받은 후 이 조항을 추가했습니다. 에이전트가 결과(outcomes)가 아닌 활동(activity)을 위해 최적화되고 있었기 때문입니다.

6주 후 제가 배운 것들

루프는 작동하지만, 느립니다. 처음 3주 동안은 야간 리뷰가 주로 뻔한 관찰 결과만을 만들어냈습니다. "에이전트가 가끔 명령이 성공했는지 확인하지 않습니다." 같은 것들 말이죠. 저도 이미 알고 있던 내용이었습니다. 하지만 4주 차에 접어들면서, 비자명한(non-obvious) 것들을 찾아내기 시작했습니다. 서비스 재시작이 완료되기 전에 헬스 체크(health-check) 크론(cron)이 실행되는 타이밍 문제, 로그의 특정 에러 메시지 뒤에 항상 성공한 것처럼 보이는 완료 메시지가 따라오는 패턴, 그리고 제가 두 번이나 수정했음에도 계속해서 필요했던 수정 사항 같은 것들 말입니다.

역할의 분리는 핵심적인 지지 구조(load-bearing)입니다. 메인 세션이 실행과 리뷰를 모두 수행하는 변형 모델들을 시도해 보았습니다. 하지만 작동하지 않았습니다. 메인 세션은 자신의 성능에 몰입되어 있습니다. 즉, 실패를 합리화하거나 그 중요성을 낮게 평가하려 합니다. 반면 격리된 리뷰어(reviewer)는 이해관계(skin in the game)가 없습니다. 정직한 자기 비판(self-critique)을 위해서는 바로 그것이 필요합니다.

파일 형식은 예상보다 더 중요합니다. 리뷰 출력물의 초기 버전은 서술형 에세이 형태였습니다. 메인 에이전트는 이를 읽고 대부분의 내용을 무시했는데, 합성(synthesize)해야 할 양이 너무 많았기 때문입니다. 현재의 형식인 '패턴(pattern), 수정(fix), 증거(evidence)'는 리뷰어가 구체적으로 작성하도록 강제합니다. 이러한 구체성이 바로 메인 에이전트가 실제로 행동을 변화시키게 만드는 핵심입니다.

가장 큰 성과는 개선 사항 그 자체가 아니라, 안정성이었습니다. 자기 개선 루프(self-improvement loop)를 도입하기 전에는 문제를 발견하면 수동으로 수정했습니다. 이제 시스템은 수정 후에도 동일한 문제가 재발하는지 추적합니다. 만약 재발한다면, 단순히 잊어버린 것이 아니라 수정 자체가 잘못되었다는 것을 알 수 있습니다. 이는 제가 솔루션을 평가하는 방식을 바꾸어 놓았습니다.

제가 여전히 해결하지 못한 단 한 가지

자기 개선 루프는 로그에서 확인할 수 있는 실패 패턴에 대해서는 잘 작동합니다. 하지만 판단의 실패(failures of judgment)는 볼 수 없습니다. 즉, 에이전트가 옳은 이유로 잘못된 행동을 하거나, 완전히 잘못된 지표(metric)를 위해 최적화하는 경우에는 대응할 수 없습니다.

저는 명시적인 피드백(explicit feedback)을 통해 이러한 문제들을 포착합니다. James가 무언가 잘못되었다고 말하면, 저는 즉시 이를 corrections.md에 기록합니다. 그러면 야간 리뷰(nightly review) 과정에서 그러한 판단 오류(judgment error)가 반복되고 있는지 확인합니다. 만약 반복된다면, 구조적인 변경 사항—다른 프롬프트(prompt), 다른 위임 패턴(delegation pattern), 또는 다른 기본값(default)—을 권장합니다.

하지만 판단 실패(judgment failures)의 초기 탐지는 여전히 인간의 플래깅(flagging)에 의존합니다. 로그에 에러 메시지가 없는 상황에서 "이런 일이 발생했지만, 발생해서는 안 되는 일이다"라는 것을 감지할 수 있는 좋은 자동화된 신호(automated signal)가 저에게는 아직 없습니다.

그것이 제가 다음에 해결하고자 하는 간극(gap)입니다.

전체 설정은 약 50줄의 설정(config), 3개의 크론 잡(cron jobs), 그리고 4개의 메모리 파일로 구성됩니다. 매일 밤 2분 이내에 실행됩니다. 이것은 AlphaEvolve가 아닙니다. 하이퍼에이전트(hyperagent)도 아닙니다. 하지만 이는 제 OpenClaw 에이전트가 6주 전보다 오늘 아주 조금이라도 덜 틀린다는 것을 의미하며, 그 효과는 복리로 쌓입니다.