완전한 AI 자동화 소프트웨어 개발이 존재해야 하는가에 대한 논쟁이 마침내 불붙었습니다. 그 발단은
@yetone이 유지보수하는 magpie 였는데, 동료들은 이를 "패스트푸드식 서비스"이자 "사용하기엔 너무 위험하다"고 비판했습니다.
대부분의 사람들은 AI 자동화 소프트웨어 개발이 대세라는 데 동의합니다. 그렇다면 magpie 는 이를 어떻게 실천하고 있을까요? 저는 magpie 를 클론해서 지난 10 일간의 2,862 개 커밋을 분석하고, OpenClaw 와 비교해 보았습니다.
https://x.com/wquguru/status/2109458639501271530
19 일 만에 1204 개의 버전
magpie 는 Claude Code, Codex, Gemini CLI 같은 코딩 에이전트를 어떤 모델이나 구독 서비스든 연결해 주는 로컬 LLM 게이트웨이입니다. 9 월 22 일 첫 커밋부터 오늘까지, 단 19 일 만에 9,474 개의 스타를 받았습니다. 2,862 개의 커밋 중 yetone 의 계정이 85% 를 차지하며, 커뮤니티 PR 383 개가 병합되었습니다.
태그(버전에 해당) 수는 19 일 만에 1,204 개에 달했고, 하루 평균 60 개 이상의 버전이 나온 셈입니다. 사람이 수동으로 유지할 수 있는 속도가 아니죠. 반면 OpenClaw 는 첫 19 일간 1,423 개의 커밋이 있었고, 그중 99% 는 Peter Steinberger 본인이 직접 제출했으며 태그는 약 10 개였습니다.
magpie 는 커밋 수가 두 배 정도지만, 버전 수는 백 배 이상 많습니다.
제가 알아내고 싶었던 것은 단 하나였습니다. 이 프로젝트에서 AI 는 정확히 어떻게 루프를 완성하는가?
라우팅 테이블과 실수 노트
magpie 의 CLAUDE.md 는 딱 두 파일만 참조합니다. AGENTS.md 와 LESSONS.md 입니다.
AGENTS.md 는 라우팅 테이블입니다. 스스로 규칙을 작성하지 않고, 에이전트에게 작업 전에 어떤 문서를 참고해야 하는지만 알려줍니다. 서브시스템을 수정하기 전에는 docs/subsystems/ 를 확인하고, 코드를 작성하거나 리뷰할 때는 docs/code-standards.md 를 따르며, 커뮤니티 PR 을 리뷰할 때는 docs/contributors.md 를 보라고 지시합니다.
LESSONS.md 의 첫 문장이 앞서 던진 질문에 답을 줍니다.
magpie 의 코드는 에이전트가 작성, 리뷰, 병합 및 릴리스합니다. (magpie's code is written, reviewed, merged, and released by agents)
작성, 리뷰, 병합, 릴리스 모두 에이전트가 처리합니다. 사람의 감독 없이도 왜 무너지지 않을까요? 답은 이 파일에 있습니다. 479 줄 분량의 이 파일은 사실상 '실수 노트'이며, 매일 밤 에이전트가 작성합니다.
매일 밤 에이전트는 그날의 모든 커밋을 리뷰하며 다음 세 가지 상황에 집중합니다.
- 어떤 수정 사항이 다시 재작업되었는가?
- 애초에 병합되지 말았어야 할 것은 무엇인가?
- 어떤 검증이 너무 허술했는가?
발견된 각 문제마다 규칙과 이유를 기록하고, 증거로 커밋 및 이슈 번호를 첨부합니다. 예를 들면 다음과 같습니다.
수정 완료라고 선언하기 전에, 보고자가 사용한 실제 화면에서 보고자의 정확한 사례를 재현하라.
834 번 이슈는 4 번이나 재작업되었다(v0.1.920 → .925 → .931 → .938). 매번 스크린샷에 보이는 에이전트만 수정했을 뿐이다. Seen 1× (2026-10-05).
834 번 이슈는 네 번이나 재작업되었고, 매번 스크린샷에 나온 에이전트만 고쳤습니다. 그래서 만들어진 규칙은 이렇습니다. 수정 완료라고 하기 전에, 보고자가 사용하는 인터페이스에서 문제를 정확히 재현하라.
핵심은 마지막 줄인 Seen 1× 입니다. 같은 교훈이 서로 다른 날짜의 리뷰에서 세 번 등장하면, LESSONS.md 에서 code-standards.md 로 이동하여 경험에서 비롯된 절대 규칙이 됩니다. 이후 모든 PR 리뷰는 이 규칙들을 항목별로 대조해 확인해야 합니다.
이미 8 개의 규칙이 이런 방식으로 승격되었습니다. 예를 들어 유사한 버그는 한꺼번에 수정하기(10 월 5 일, 6 일, 7 일에 각각 한 번씩 적발됨), main 브랜치에서 실패하는 테스트는 즉시 수정해야 할 버그로 간주하기, 병합 전에 무엇을 어느 커밋에서 테스트했는지 명확히 밝히기 등이 있습니다.
물론 실수 노트에는 잘한 일도 기록됩니다. Done right 로 표시되어, 에이전트가 "이건 하지 마라"뿐만 아니라 "대신 이렇게 해라"까지 읽을 수 있게 합니다.
실수 노트는 10 월 6 일 새벽에 도입되었다
이 시스템은 처음부터 설계된 것일까요? LESSONS.md 의 커밋 히스토리를 확인해 보니, 첫 버전은 10 월 6 일 오전 3 시 10 분에 생성된 커밋 303819c5 였습니다.
하루 전인 10 월 5 일, magpie 는 168 개의 버전을 릴리스했습니다.
LESSONS.md 의 첫 버전은 바로 그날을 기록했습니다. 220 개의 커밋과 약 170 개의 릴리스 중, 대략 40 개는 당일이나 전날 릴리스된 버전을 수정하는 것이었습니다. CI 는 거의 항상 다음 푸시에 의해 취소되었습니다. Linux 에서만 실패하는 테스트가 v0.1.877 부터 v0.1.892 까지 계속 빨간불이었지만 아무도 알아채지 못했습니다.
51 시간 동안 294 개의 태그가 달리면서 완료된 실행이 하나도 없었다. (294 tags in 51 hours meant no CI run could complete)
그래서 첫 버전에는 이런 규칙이 추가되었습니다. 태그를 달기 전에 해당 커밋의 CI 가 완료되고 성공(green)해야 한다. 새로운 푸시로 인해 취소된 실행은 인정하지 않는다.
첫째 날 168 개, 둘째 날 42 개, 셋째 날 15 개로 릴리스가 줄어들더니 이후 15~26 개 사이에서 안정되었습니다.
회의를 열거나 공지를 보내지 않았습니다. 야간 리뷰가 문제를 찾아내어 실수 노트에 규칙을 추가했고, 작업 중인 에이전트들이 이를 읽어 릴리스 속도를 늦춘 것입니다.
따라서 최근 문제가 있다고 지적된 하루 20 여 개의 릴리스는 사실 브레이크를 밟은 후의 속도였습니다.
PR 승인 기준
다음으로 실제 PR 을 살펴보겠습니다.
code-standards.md 에는 6 가지 승인 기준이 나열되어 있습니다. 병합이나 릴리스 전에 모두 통과해야 합니다. 3 개 플랫폼 컴파일이나 샌드박스 테스트 같은 일반적인 검사를 제외하면, 보통의 프로젝트에서는 보기 드문 3 가지가 있습니다.
- 회귀 테스트(Regression Test): 기존 코드를 다시 넣었을 때 새 테스트가 명시적으로 실패해야 하며, 어떤 동작이 잘못되었는지 짚어내야 합니다. 컴파일 오류나 건너뛴 테스트는 인정되지 않습니다.
- 실제 사용(Real Usage): 벤더 통합을 변경하는 경우, 실제 계정, 설정, API 응답으로 검증해야 합니다. 테스트되지 않은 기능은 그 위에 무언가를 구축하거나 사용자에게 사용 가능하다고 안내할 수 없습니다.
- 실행하지 않은 검사는 반드시 목록에 포함:
실행하지 않은 검사는 반드시 '미실행(not run)'으로 기재하며, 절대 누락하지 않는다. (Checks not performed must be listed as not run, never omitted)
무작위로 #1339 를 골라 병합 전에 남긴 코멘트를 확인해 보았습니다.
Red 체크는 회귀 테스트를, Break 체크는 테스트가 이를 잡아내는지 확인하기 위해 의도적으로 코드를 망가뜨리는 것을 의미하며, 마지막 줄의 Not run 은 실제 하드웨어에서 테스트하지 않았음을 뜻합니다.
병합 명령어에는 --match-head-commit <reviewed sha> 가 포함됩니다. 리뷰 중에 누군가 푸시하면 병합이 실패하므로, 리뷰되지 않은 코드가 유입되지 않습니다.
Human in the Loop
물론 사람도 여전히 일부 작업에 참여합니다. 최소한 다음 영역들입니다.
- 제품 의사결정: "의도적인 결정을 뒤집지 마라." 스크롤 동작이나 버튼 커서 같은 요소는 PR 로 임의로 변경할 수 없습니다.
- 보안 게이트: 위험성 검사에 걸리면 메인테이너의 승인을 기다려야 합니다.
- 커뮤니티 제안: 474 개의 커밋 제목이 X 나 Discord 의 제보자를 언급합니다. 예: X 의 JonahFu, Discord 의 Jeremy.Zhou.
요약하자면, 사람은 방향을 관리하고 관문을 지키며, 작성, 리뷰, 병합, 릴리스는 에이전트가 담당합니다.
yetone 이 무언가 숨기고 있을까?
여기까지 읽고 나면 이런 의문이 생길 수 있습니다. yetone 이 무언가 숨기고 있는 건 아닐까? 저도 궁금해서 더 파고들었습니다.
실제로 레포지토리에 없는 내용들이 몇 가지 있었습니다.
- 야간 리뷰가 어떻게 트리거되는지는 문서화되어 있지 않습니다. 4 개의 워크플로우 중 스케줄링된 것은 없었습니다.
- LESSONS.md 업데이트 7 회의 시간을 추출해 보니 03:10, 03:49, 00:23, 23:46, 03:48, 14:24, 05:26 이었습니다. 시간이 들쭉날쭉해서 cron 작업보다는 로컬에서 수동으로 실행했거나 커스텀 스크립트를 쓴 것처럼 보였습니다.
- 야간 리뷰에 사용된 프롬프트도 없습니다. 어떤 에이전트를 썼는지, 세션을 몇 개 병렬로 돌렸는지 전혀 기록되어 있지 않습니다.
그 과정에서 두 가지를 추가로 발견했습니다.
첫째, 이 방법론에는 커뮤니티 기여가 포함되어 있습니다. 서브시스템 문서화와 시맨틱 변경 리뷰는 커뮤니티 멤버 Junjie Zhou 의 PR #889 를 통해 도입되었습니다. code-standards.md 상단의 두 표는 커밋 926bcaa3 에서 Junjie Zhou 가 Discord 에 제안한 6 가지 리뷰 규칙 덕분이라고 명시되어 있습니다.
둘째, yetone 과 에이전트의 상호작용이 커밋에 그대로 보존되어 있습니다. 52 개의 커밋 제목에 yetone 의 원본 발언이 괄호 안에 담겨 있습니다.
1(the owner: This is too ugly)2(the owner: Why is this a native selector instead of our abstract ComboBox?)3(the owner: Why did this come back again? Didn't we say it should only appear on hover? Always appearing is too ugly)4(owner: During pr-preview, sometimes there's no data to test. Can you help create some fake data?)
대부분 한 줄짜리 불평이고, 나머지는 에이전트가 채워 넣어 커밋 본문이 수백 단어에 달하는 경우도 많습니다. 가짜 데이터를 요청한 부분은 나중에 CI 녹화에 사용되는 목(mock) 데이터 세트가 되었습니다.
사람이 무엇이 잘못되었는지 짚어주고, 에이전트가 이를 검증 가능한 변경 사항으로 바꿉니다. 이 수십 개의 커밋 제목이 그 어떤 문서보다 방법론을 잘 설명해 줍니다.
직접 구축하고 싶다면
라우팅 테이블은 누구나 작성할 수 있습니다. 진짜 따라 해야 할 가치는 실수 노트 시스템입니다. LESSONS 항목은 다음과 같은 형태입니다.
1**<한 줄 규칙>**2- <어떤 커밋/이슈가 문제를 일으켰고, 결과는 무엇이었는가>3- <수정 커밋>4- Done right: <올바르게 수행한 예시>5- Seen N× (YYYY-MM-DD, YYYY-MM-DD).
에이전트가 매일 밤 그날의 커밋을 리뷰하게 하되, 재작업, 잘못된 병합, 부실한 검증만 찾도록 합니다. 같은 문제가 서로 다른 날짜에 세 번 나타나면 코드 표준으로 옮깁니다. 승인 단계에서는 회귀 테스트, 실제 사용 여부, 미실행 항목을 커밋 본문과 PR 코멘트에 나열합니다.
레포 전체를 검토하면서 가장 인상 깊었던 것은 Seen 3× 임계값이었습니다. 실수를 기록하고 에이전트가 시작할 때 이를 읽으며, 같은 오류를 세 번 반복하면 절대 규칙으로 승격됩니다. "세 번이면 끝"이라는 격언(혹은 삼진아웃)을 완벽하게 구현한 셈입니다.
마무리하며...
1 년 전, 심지어 6 개월 전만 해도 모델의 성능이 프로덕션 수준의 자동화에 도달하는 경우는 드물었습니다. 하지만 지금은, 특히 Opus 5.5 가 등장한 이후로 우리는 분명히 봅니다. 미래가 이미 도착했다는 것을요.
이 글을 쓰니 200 일 넘게 자체적으로 반복 개선해 온 에이전트, @yuanhao 의 Yoyo 가 떠오릅니다. https://yoyo-gasp.yolog.dev/ 역시 꼭 확인해 볼 만합니다.
