# 나의 AI 활용기 – AI 에이전트를 오래 돌리는 법, LoopEngineering으로 정리했다
오늘 OpenClaw 고도화 설계를 한 장짜리 모바일 인포그래픽으로 압축했다. 핵심은 간단했다. AI 에이전트를 더 오래 돌리는 게 목표가 아니라, 오래 돌아도 사람이 이해하고 검증하고 멈출 수 있는 구조를 만드는 것이다.
이 글은 그 설계를 블로그 글로 다시 풀어쓴 기록이다. 멋있는 자동화 이야기보다, 실제로 운영하면서 어디가 불안했고 무엇을 표준으로 묶어야 하는지를 남기는 쪽에 가깝다.
## 왜 이 주제를 다시 꺼냈나
AI 에이전트를 쓰다 보면 처음에는 프롬프트가 중요해 보인다. 무엇을 시킬지 잘 쓰면 결과가 좋아진다. 그런데 자동화가 늘어나면 문제가 바뀐다.
이제 질문은 “프롬프트를 어떻게 잘 쓰나?”가 아니다.
“이 에이전트가 내일도, 다음 주에도, 내가 잠깐 보지 않는 사이에도 같은 기준으로 움직일 수 있나?”가 된다.
OpenClaw도 이미 여러 반복 작업을 갖고 있다. Telegram 요청을 받고, cron이 돌고, 백업과 대시보드 동기화가 실행되고, 블로그 초안도 만들어진다. 각각은 잘 작동해도 전체 운영 관점에서는 한 가지 질문이 남는다.
실패했을 때 어디서 멈추는가.
그래서 LoopEngineering 관점으로 다시 정리했다.
## 내가 잡은 기본 구조
이번에 정리한 OpenClaw의 표준 루프는 네 단계다.
1. Trigger: 무엇이 루프를 깨우는가
2. Maker: 누가 산출물을 만드는가
3. Checker: 무엇으로 결과를 검증하는가
4. Ledger: 다음 실행을 위해 어디에 상태를 남기는가
예를 들어 블로그 초안 자동화를 보면 이렇게 바꿔볼 수 있다.
– Trigger: 매일 정해진 시간 또는 KK님의 명시 요청
– Maker: Chloe 또는 Codex가 초안 생성
– Checker: 품질 gate, 금칙어, 출처/협찬 표시, 공개 상태 확인
– Ledger: 프로젝트 보드와 작업 리포트에 Post ID, 상태, 검증 결과 기록
이렇게 적어두면 자동화가 덜 신비로워진다. 누가 무엇을 했는지, 어디서 검증했는지, 다음에 무엇을 봐야 하는지 남는다.
## Loop Contract를 붙이면 달라지는 것
내가 제안한 첫 번째 변화는 모든 반복 자동화에 Loop Contract를 붙이는 것이다.
거창한 문서가 필요하다는 뜻은 아니다. 새 cron이나 agent 루프를 만들 때 아래 항목만 같이 적으면 된다.
– trigger: 실행 조건
– maker: 산출 담당
– checker: 검증 담당
– state file: 상태 저장 위치
– budget: 시간, 토큰, 반복 횟수 한도
– exit condition: 시작 전에 정한 종료 조건
– evidence: 완료 보고에 필요한 증거
– escalation: 언제 멈추고 KK에게 물을지
이 필드가 있으면 자동화가 “그냥 도는 것”에서 “계약대로 도는 것”으로 바뀐다.
특히 exit condition이 중요하다. 루프는 시작 전에 멈출 기준을 써야 한다. 테스트 통과, 품질 점수 기준, 최대 반복 횟수, 같은 원인 실패 2회 같은 식으로 정해두면 된다.
## Maker와 Checker를 분리해야 하는 이유
운영하면서 가장 조심해야 할 부분은 자기검증이다.
초안을 만든 agent가 자기 글을 바로 “좋다”고 판단하면 통과 기준이 느슨해질 수 있다. 코드 변경도 마찬가지다. 만든 쪽과 검사하는 쪽이 같으면 놓치는 부분이 생긴다.
그래서 영향이 있는 작업은 Maker-Checker를 기본으로 분리하는 게 맞다.
– Maker는 만든다: 초안, 코드, 설정 변경안, 리포트
– Checker는 본다: 테스트, 로그, diff, API 응답, 공개 상태, 승인 경계
작은 작업은 같은 세션 안의 self-check로 충분할 때도 있다. 하지만 외부 게시, 코드 변경, 브라우저 자동화, 비용이 걸린 작업은 별도 checker pass가 필요하다.
이번 블로그 초안도 같은 원칙으로 처리한다. 초안은 draft로만 올리고, publish는 KK님 검토 뒤에만 한다.
## 완료 보고는 Evidence Bundle로 끝내야 한다
자동화가 많아질수록 “완료했습니다”라는 말은 부족하다.
내가 앞으로 OpenClaw에 더 강하게 붙이고 싶은 완료 기준은 Evidence Bundle이다.
완료 보고에는 최소한 네 가지가 있어야 한다.
1. 무엇을 바꿨는지
2. 어디에 반영됐는지
3. 어떤 검증을 했는지
4. 남은 위험과 승인 필요 여부는 무엇인지
이 네 가지가 있으면 나중에 다시 봐도 이어서 작업할 수 있다. 반대로 이 네 가지가 없으면 자동화는 성공한 것처럼 보이지만 실제로는 다음 사람이 다시 추적해야 한다.
## 바로 적용할 순서
OpenClaw에 적용한다면 순서는 단순하게 잡는 게 좋다.
1주차에는 Loop Contract 템플릿과 ledger 위치를 정한다.
2주차에는 blog, backup, dashboard sync처럼 이미 운영 중인 루프에 먼저 붙인다. 새 기능보다 기존 루프를 설명 가능하게 만드는 게 먼저다.
3주차에는 checker pass와 실패 2회 stop rule을 자동화한다. 같은 원인으로 두 번 실패하면 계속 밀어붙이지 않고 원인, 영향, 우회안, 필요한 승인을 보고하게 한다.
이 정도만 해도 OpenClaw는 꽤 달라질 것이다. 더 많은 일을 하는 시스템이 아니라, 자신이 하는 일을 더 잘 설명하는 시스템에 가까워진다.
## 내가 얻은 결론
LoopEngineering은 “AI에게 일을 계속 시키는 기술”이 아니다.
내 기준에서는 운영 설계에 가깝다. 어떤 신호로 시작하고, 누가 만들고, 누가 확인하고, 어디에 상태를 남기고, 언제 멈출지 정하는 일이다.
AI 자동화를 오래 쓰려면 프롬프트보다 이 구조가 더 중요해진다. 오늘 바로 해볼 수 있는 일은 하나다. 지금 쓰고 있는 자동화 하나를 골라서 trigger, maker, checker, ledger 네 줄로 적어보는 것부터 시작하면 된다.
—
**작성일**: 2026-06-12
**정보 기준일**: 2026-06-12
**마지막 업데이트**: 2026-06-12
**업데이트 필요 여부**: OpenClaw 실제 루프 적용 후 사례와 검증 결과를 추가할 예정
**협찬/광고/원고료**: 없음
**경험 범위**: 직접 운영/직접 사용 경험 기반
**작성 모델**: openai-codex/gpt-5.5\