게놈 패턴: 실제로 스스로를 개선하는 에이전트 루프를 구축하는 방법

대부분의 "자율 에이전트 (autonomous agents)"는 while 루프 안에 들어있는 단 하나의 프롬프트에 불과합니다. 이들은 실행되고, 표류하며, 어제의 실수를 반복하고, 학습한 내용에 대한 기억을 전혀 유지하지 못합니다. 하루가 지나면 더 나아진 에이전트를 얻는 것이 아니라, 그저 더 지친 상태의 동일한 에이전트를 마주하게 될 뿐입니다.

우리는 azena에서 몇 달 동안 다른 패턴을 프로덕션 환경에서 실행해 왔으며, 이를 구체적으로 설명하고자 합니다. 왜냐하면 이 방식은 부끄러울 정도로 단순하기 때문입니다: 프레임워크 없음, 4개의 마크다운 (markdown) 파일, 그리고 하나의 규율. 우리는 템플릿을 오픈 소스로 공개했습니다 — azena-ai/self-improving-loop — 하지만 파일 자체보다 아이디어가 더 중요하므로, 전체 내용을 여기에 담았습니다.

핵심 아이디어: 에이전트는 게놈 (genome) 위에서 실행된다

에이전트는 고정된 프롬프트 위에서 실행되지 않습니다. 에이전트는 게놈 (genome) 위에서 실행됩니다. 즉, 에이전트가 직접 읽고 다시 쓰는 버전 관리된 전략 파일입니다.

매 사이클 ("틱 (tick)")마다 루프는 한 가지 일을 수행합니다: 단 하나의 가장 가치 있는 움직임을 선택하고, 이를 실행하며, 그것이 실제로 작동했는지 검증한 다음, 학습한 내용을 자신의 지침에 다시 통합합니다. 게놈은 v001 → v002 → v003…으로 진행되며, 각 단계의 상승은 에이전트가 스스로의 생각을 바꾼 것에 대한 감사 가능한 기록이 됩니다.

마지막 부분이 핵심입니다. 정적인 프롬프트는 미션이 바뀌는 순간 현실과 충돌합니다. 반면 게놈은 루프가 이를 편집할 수 있도록 허용되어 있기 때문에, 변화를 _흡수_합니다.

한 장의 그림으로 보는 루프

flowchart TD
  A([Tick fires]) --> B[Read genome + levers + lessons]
  B --> C[Pick the single highest-value lever]
...

내부 루프에는 인간이 없습니다. 인간은 미션을 설정하고 아침에 차이점 (diffs)을 검토합니다. 그것이 규칙입니다.

4개의 파일, 그 중 3개는 루프가 편집함

파일	역할
`genome.md`	진화하는 전략 + 상태 (strategy + state): 미션, 현재 집중 사항, 증명된 것, 다음 단계. 루프는 학습하면서 이것을 변이 (mutates) 시킵니다. 버전 관리됨.
...
틱 (tick) 자체는 단순한 상태 머신 (state machine)입니다:

read(genome, levers, lessons)
lever  = highest_value_open(levers)
result = act(lever)            # 작고, 배포 가능한 (small, shippable)
...

파일 기반 메모리가 컨텍스트 윈도우 (context window)보다 뛰어난 이유

컨텍스트 윈도우 (context window)는 휘발적이고 작습니다. 압축(compaction), 재시작, 또는 충분히 긴 실제 시간(wall-clock)의 간격이 생기면 증발해 버립니다. 따라서 "상태(state)"가 컨텍스트 안에 머무는 에이전트는 자신이 어디에 있었는지를 말 그대로 잊어버립니다.

게놈 (genome) 파일은 내구성이 있고 경계가 없습니다. 루프는 수많은 틱 (tick), 재시작, 요약 (summarization) 과정을 거치며 며칠 동안 실행될 수 있으며, 여전히 자신이 정확히 어디에 있는지 알고 있습니다. 왜냐하면 "자신이 어디에 있는지"가 기억되는 것이 아니라 기록되기 때문입니다. 컨텍스트가 요약되어 사라지더라도, 다음 틱은 그저 게놈을 다시 읽고 계속 진행할 뿐입니다. 컨텍스트가 아닌 디스크에 상태를 저장한다는 이 단 하나의 결정이, 수다스러운 데모를 일주일 동안 생존할 수 있는 무언가로 탈바꿈시킵니다.

타협할 수 없는 요소: 게이트 (gates)

여기는 모두가 건너뛰는 부분이지만, 자율성을 무모한 것이 아닌 안전한 것으로 만드는 핵심적인 부분입니다.

자율 루프의 신뢰성은 오직 검증 (verification) 수준에 달려 있습니다. 게이트 (gate)는 커밋 (commit)을 하기 _전_에 반드시 통과해야 하는 체크 항목입니다. 게이트 검증에 실패하면 루프는 다른 레버 (lever)를 선택하기 위해 되돌아갑니다. 결코 "어쨌든 커밋"하기 위해 앞으로 나아가지 않습니다.

최소한의 게이트는 세 단계이며, 순서가 중요합니다:

타입 체크 (Typecheck) 통과. 실제 체크를 실행합니다. 이를 head/tail로 파이프라인 (pipe) 처리하지 마십시오. 파이프는 종료 코드 0을 반환하며, 수많은 에러 위에서도 기쁘게 "OK"를 출력할 것입니다.
빌드 (Build) 통과. 많은 번들러 (bundlers)는 타입 에러가 있음에도 불구하고 타입을 제거하고 빌드를 성공적으로 마칩니다. 따라서 1단계는 선택 사항이 아닙니다.
로그가 아닌 아티팩트 (artifact)를 검증하십시오. 이것이 팀들이 건너뛰는 부분입니다. "배포에 성공했다"는 사실은 페이지가 렌더링되거나, 엔드포인트 (endpoint)가 응답하거나, 파일이 비어 있지 않다는 증거가 아닙니다.

세 번째 포인트는 자율 루프에서 가장 비용이 많이 드는 버그 유형입니다. 바로 쓰레기를 생성하면서 성공을 보고하는 단계입니다. 조용히 빈 SPA 셸 (shell)만 내뱉는 프리렌더 (prerender). "실행되었지만" 단 하나의 행(row)도 건드리지 않은 마이그레이션 (migration). 그러므로 실제 아티팩트의 구체적인 속성을 단언 (assert)하십시오:

# "build OK"를 믿지 마십시오 — 증명하십시오
test "$(grep -c '<div id="root"></div>' dist/index.html)" -eq 0   # 빈 껍데기가 아님을 확인
test "$(wc -c < dist/index.html)" -gt 50000                          # 실제 콘텐츠가 포함되어 있는지 확인

유령과 싸우지 않기 위한 한 가지 주의사항: 당신이 건드리지 않은 부분에서 발생한 일시적인 실패(네트워크 깜빡임, 콜드 스타트 (cold start))는 회귀 (regression)가 아닙니다. 게이트 (gate)를 한 번 더 실행해 보십시오. 만약 결정론적 (deterministically)으로 실패한다면, 그것은 실제 문제입니다.

루프가 이미 스스로에게 가르쳐준 교훈들

이것들은 실제 운영 (production) 실행을 통해 일반화된 실제 사례들입니다. 이 패턴의 핵심은 이 목록이 _스스로 성장한다_는 점입니다. 루프는 시행착오를 겪는 즉시 이 목록에 내용을 추가합니다:

배포하기 전에 검증하십시오. 빌드 (build) 단계는 조용히 실패하여 빈 껍데기만 남길 수 있습니다. 배포하기 _전_에 출력이 비어 있지 않고 정확한지 단언 (assert)하십시오.
하나의 발견을 파괴적인 전수 조사로 확대하지 마십시오. 단 하나의 이상해 보이는 매치 (match)가 사이트 전체의 찾기 및 바꾸기 (find-and-replace)를 수행하라는 명령은 아닙니다. 먼저 의도를 확인하십시오.
현실이 작업의 전제와 모순될 때는 보고하십시오 — 맹목적으로 실행하지 마십시오. 작업 내용이 "작은 수정"이라고 되어 있는데 구조적으로 중요한 재작성 (rewrite)이 필요하다는 것을 발견했다면, 무작정 밀고 나가는 대신 이를 표면화하십시오.
서버가 필요한 도구는 스스로 서버를 시작하지 않습니다. 서버를 올리고, 기다린 후에 체크를 실행하십시오. connection refused 메시지가 쏟아지는 것은 "모든 것이 고장 났다"는 뜻이 아니라 "아무도 듣고 있지 않다"는 뜻입니다.

이것들이 AI 전용 규칙이 아니라는 점에 주목하십시오. 이것들은 신중한 엔지니어의 운영 규칙입니다. 다만 차이점은 루프가 한 번의 대가를 치른 후 스스로를 위해 이 규칙들을 작성했다는 것입니다.

틱(tick)당 하나의 레버

마지막 원칙이자 과소평가하기 쉬운 것: 틱(tick)당 하나의 레버 (one lever per tick). 작고 배포 가능한 단위는 모든 변경 사항을 검토 가능하게 만들고, 모든 실패의 롤백 (roll back) 비용을 저렴하게 유지합니다. 자율 에이전트 (autonomous agent)를 사용할 때의 유혹은 "시간을 아끼기 위해" 한 번에 다섯 가지 일을 하게 만드는 것입니다. 그러지 마십시오. 검증된 한 가지를 배포하고 멈추는 하나의 틱이, 검증 불가능한 다섯 가지를 배포하는 하나의 틱보다 가치 있습니다. 이 리듬 (cadence)이 안전 난간 역할을 합니다.

시작하기

직접 시도해보고 싶다면, 진심으로 단 네 개의 파일과 오후 시간 정도면 충분합니다:

repo에서 네 개의 *.template.md 파일을 복사하여 프로젝트에 넣습니다.
genome.md에 당신의 **미션 (mission)**과 첫 번째 집중 과제를 작성합니다.
levers.md에 순위가 매겨진 백로그 (backlog)를 시드 (seed)로 채웁니다.
loop-prompt.md를 에이전트 (agent)에게 전달하고, 한 번의 틱 (tick)을 실행한 뒤 다음 틱을 예약하도록 지시합니다.
매일 아침 차이점 (diffs)을 검토합니다. 게놈 (genome)이 진화하는 과정을 지켜보세요.

이 방식은 에이전트가 **자신의 다음 차례를 예약 (schedule its own next turn)**하고 **git에 커밋 (commit to git)**할 수 있는 곳이라면 어디에서나 작동합니다. 저희는 Claude Code 내부에서 이를 실행하고 있지만, 이 패턴의 어떤 부분도 Claude에 특화된 것은 아닙니다.

저희는 azena에서 독일의 미텔슈탄트 (Mittelstand, 중소기업)를 위한 맞춤형, EU 주권 AI 시스템을 구축하며 생계를 유지하고 있으며, azena Dev Academy에서 이 기술을 가르치고 있습니다. 이 루프 (loop) 패턴은 저희 자신의 자동화 시스템이 밤새도록 실행해 두어도 될 만큼 신뢰할 수 있어야 한다는 필요성에서 탄생했습니다. 만약 이것으로 무언가를 구축하신다면, 게놈이 어떻게 진화했는지 꼭 듣고 싶습니다.

템플릿, 문서, 그리고 몇 가지 재사용 가능한 기술들은 모두 이곳에서 MIT 라이선스로 제공됩니다: github.com/azena-ai/self-improving-loop.