📝 한줄 요약
지피터스에 사례글을 자동으로 써주는 write-post의 DEVLOG 자동 생성 아이디어를 보고, “이 로그를 글감이 아니라 에이전트 성장 재료로 쓰면 어떨까?”라는 생각에서 주간 회고 에이전트 삼체를 만들었습니다.
바쁘시면 이것만 읽어도 돼요:
write-post의 DEVLOG 자동 생성 방식에서 착안했습니다.제 경우에는 개발 로그를 사례글로만 쓰지 않고, 에이전트 운영 개선에 쓰고 싶었습니다.
그래서 지난 7일의 세션, cron 실행 이력, 에러 로그, 이전 회고를 읽는 주간 회고 에이전트
삼체를 만들었습니다.삼체는 매주
신규 발굴 / 기존 자동화 진단 / 작업 패턴 코칭세 가지 렌즈로 제 시스템을 점검합니다.결과는 옵시디언에 저장하고, 텔레그램으로 요약을 보내며, 마지막에는
즉시 / 보류 / 폐기결정을 묻도록 했습니다.
🎯 이런 분들께 도움돼요
AI 코딩 도구를 자주 쓰지만, 작업 기록이 그냥 흩어지는 분
자동화나 에이전트를 여러 개 만들었는데 무엇이 잘 굴러가는지 헷갈리는 분
매주 “내가 뭘 반복했고, 뭘 고쳐야 하지?”를 정리하고 싶은 분
에이전트를 단순 실행 도구가 아니라 조금씩 성장하는 운영 파트너로 만들고 싶은 분
😫 문제 상황
AI 코딩 도구를 쓰다 보면 결과물은 계속 생깁니다.
스크립트도 만들고, 스킬도 만들고, cron도 걸고, 에러도 고치고, 중간에 아이디어도 많이 나옵니다.
그런데 시간이 지나면 이런 질문이 남습니다.
지난주에 어떤 자동화를 만들었지?
같은 문제를 또 고치고 있지는 않나?
실패한 cron이 있는데 내가 놓치고 있지는 않나?
이번 주에 반복한 수작업은 스킬로 만들 수 있지 않을까?
지난번 회고에서 제안한 건 실제로 실행됐나?
처음에는 사람이 직접 기억하거나, 필요할 때 로그를 찾아보면 된다고 생각했습니다.
하지만 로그는 쌓이기만 하면 다시 안 보게 됩니다. 특히 AI와 같이 일하면 작업 속도가 빨라서, 며칠만 지나도 어떤 판단을 했는지 흐려집니다.
그래서 목표를 이렇게 잡았습니다.
“AI가 만든 작업 기록을, 다시 AI가 읽고, 다음 개선 방향을 제안하게 하자.”
💡 시작 계기
계기는 write-post라는 사례게시글 작성 도우미였습니다.
이 도구에는 AI 코딩 세션을 읽어서 DEVLOG를 자동 생성하는 흐름이 있었습니다. Claude Code, Codex, Gemini 같은 도구의 작업 기록을 모아서 “무슨 작업을 했는지” 개발 로그로 정리하는 방 식입니다.
이걸 보면서 방향을 조금 바꿔 생각했습니다.
“개발 로그를 글로 바꾸는 것도 좋지만, 이걸 운영 개선에 쓰면 더 재미있겠다.”
즉, DEVLOG가 사람에게 보여주는 작업 기록이라면, 삼체는 에이전트가 자기 운영을 돌아보는 회고 루프입니다.
🛠️ 만든 것: 삼체
삼체는 매주 한 번 실행되는 주간 회고 에이전트입니다.
이름은 내부적으로 self-improvement-scout라는 스킬로 되어 있고, 실제 운영에서는 삼체라고 부르고 있습니다.
삼체는 한 주 기록을 세 가지 렌즈로 봅니다.
1. 신규 발굴
반복된 수작업을 찾습니다.
예를 들면 이런 신호입니다.
같은 파일을 매번 비슷하게 확인한다
비슷한 검증을 수동으로 반복한다
여러 스크립트를 매번 순서대로 실행한다
같은 질문을 여러 번 한다
이런 것들은 새 스킬이나 파이프라인 후보가 됩니다.
2. 기존 자동화 진단
이미 만들어둔 자동화가 잘 돌고 있는지 봅니다.
여기서는 cron 상태, 실행 결과, 에러 로그를 봅니다.
중요한 건 단순히 “에러가 있다”가 아니라, 원인을 나누는 것입니다.
코드가 깨진 건지
모델 한도 때문인지
외부 API rate limit인지
스케줄은 돌았는데 산출물이 없는 건지
실패가 한 번인지, 며칠째 반복인지
이걸 나눠야 진짜 고칠 것과 그냥 재시도할 것을 구분할 수 있었습니다.
3. 작업 패턴 코칭
마지막은 제 작업 흐름을 봅니다.
예를 들면 “이번 주는 인프라 디버깅에 시간이 많이 갔고, 콘텐츠 발행은 줄었다” 같은 식입니다.
다만 단정적으로 평가하지 않게 했습니다.
대신 질문형으로 끝내게 했습니다.
예를 들면:
“이번 주에 인프라 정비가 많았는데, 의도한 기반 다지기였나요? 아니면 실제 산출물이 밀린 건가요?”
이 방식이 좋았던 이유는, 에이전트가 잔소리하는 느낌보다 같이 운영 회의를 하는 느낌에 가까웠기 때문입니다.
🔧 삼체가 읽는 기록
삼체는 매주 다음 자료를 봅니다.
지난 7일의 AI 작업 세션
Hermes insights
cron 실행 이력
에러 로그
이전 삼체 결과물 3~5개
도구 사용 패턴 로그
이전 삼체 결과물을 보는 이유가 중요했습니다.
매주 새로 시작하면 같은 제안을 반복하기 쉽습니다. 그래서 지난번에 나온 제안이 실행됐는지, 보류됐는지, 또 반복되는지를 추적하게 했습니다.
즉, 삼체는 매번 “새 회고”를 쓰는 게 아니라, 이전 회고와 이어지는 운영 기록을 만듭니다.
📅 실행 방식
현재 삼체는 매주 일요일 저녁에 실행되도록 설정했습니다.
정규 실행: 매주 일요일 20:30
실패 시 catch-up: 월요일 09:10
결과 저장: 옵시디언
30. 자원 상자/삼체/요약 보고: 텔레그램
실패 다음날 catch-up을 둔 이유는, AI 작업은 모델 한도나 외부 오류 때문에 한 번씩 실패할 수 있기 때문입니다.
실패를 “에이전트가 못했다”로 끝내지 않고, 다음날 다시 확인하게 했습니다.
📌 실제로 나온 회고 예시
최근 테스트 회고에서는 이런 식으로 정리됐습니다.
자동화 건강 상태
활성 cron 중 대부분은 정상이고, 일부는 HTTP 429 rate limit 때문에 실패한 것으로 분리했습니다.
이건 코드가 깨진 게 아니라 계정/모델 한도 문제이므로, “스킬 고장”이 아니라 “한도 스킵 또는 fallback 정책 필요”로 봐야 했습니다.
신규 발굴 후보
반복되는 댓글 작업이나 수동 검증 작업을 보고, 승인 큐나 별도 파이프라인 후보로 분리했습니다.
중요한 점은 무조건 새 스킬을 만들지 않았다는 겁니다. 이미 있는 스킬 안에서 흡수할 수 있으면 새로 만들지 않는 쪽으로 판단하게 했습니다.
작업 패턴 질문
그 주에는 인프라 정비와 에이전트 운영 쪽 작업이 많았고, 다른 산출물 작업이 상대적으로 줄었습니다.
삼체는 이것을 단정하지 않고 질문으로 남겼습니다.
“이번 주는 기반 다지기 스프린트였나요, 아니면 실제 산출물이 인프라 디버깅에 밀린 건가요?”
이 질문이 꽤 유용했습니다. 사람이 놓치는 흐름을 에이전트가 다시 비춰주는 느낌이었습니다.
🤔 만들면서 막혔던 부분
제일 어려웠던 건 “회고가 길어지는 것”이었습니다.
로그가 많으면 에이전트는 이것저것 다 말하고 싶어 합니다. 그러면 읽는 사람 입장에서는 피곤합니다.
그래서 원 칙을 넣었습니다.
근거 없는 제안 금지
없으면 “없음”이라고 쓰기
신규 스킬 억지로 만들지 않기
실시간 1회성 에러보다 반복되는 만성 문제에 집중하기
마지막에는 반드시 즉시 / 보류 / 폐기 결정 질문으로 끝내기
이렇게 제한을 두니 회고가 조금 더 운영 회의처럼 바뀌었습니다.
✅ 결과
아직 초기 버전이지만, 삼체를 만들고 나서 얻은 건 분명했습니다.
첫째, 작업 기록이 그냥 사라지지 않습니다.
둘째, 에러 로그가 단순 실패 목록이 아니라 개선 후보로 바뀝니다.
셋째, 지난주 제안이 이번 주에 다시 추적됩니다.
넷째, 에이전트가 단순히 명령을 수행하는 도구에서 “운영을 같이 보는 파트너”에 가까워집니다.
개인적으로 가장 좋았던 건, 회고가 글쓰기용 산출물이 아니라 다음 행동을 정하는 장치가 됐다는 점입니다.
🧩 배운 점
AI 에이전트를 성장시키려면, 더 많은 도구를 붙이는 것만으로는 부족했습니다.
필요한 건 루프였습니다.
실행한다
기록한다
기록을 다시 읽는다
반복과 실패를 찾는다
다음 실험을 정한다
다음 주에 다시 확인한다
사람이 매주 직접 하면 귀찮아서 빠질 수 있지만, 에이전트가 이걸 맡으면 운영 리듬이 생깁니다.
저에게 삼체는 “자동화 하나를 더 만든 것”이라기보다, 자동화들이 스스로 정리되고 개선될 수 있게 만드는 메타 자동화에 가깝습니다.
🚀 앞으로의 계획
다음 단계는 삼체가 제안한 것들이 실제로 실행됐는지 더 잘 추적하게 만드는 것입니다.
지금은 회고와 제안 중심이라면, 앞으로는 이런 식으로 발전시키고 싶습니다.
지난 제안의 실행 여부 자동 판정
반복 실패 자동 분류
새 스킬 후보와 기존 스킬 보강 후보 구분
“이번 주 즉시 할 일 1개”만 고르게 하는 운영 방식
최종 목표는 단순합니다.
제가 에이전트를 계속 개선하는 것이 아니라, 에이전트가 자기 기록을 보고 스스로 개선 방향을 제안하는 구조를 만드는 것.
이번 삼체는 그 첫 번째 실험입니다.
