「AI 에이전트로 개발을 자동화하고 있습니다」라는 이야기는 자주 보지만, 실제 리포지토리에서 무엇이 어느 정도의 빈도로 일어나고 있는지에 대한 생데이터(raw data)는 잘 나오지 않습니다. 이 기사에서는 20대 대상 커뮤니티 「Coelia」의 운영 기반을 지탱하는 3개 리포지토리의 PR 이력을 있는 그대로 공개합니다.

전제: 이 체제는 Claude Code / Codex를 「사령탑·실행 팔·체커」의 역할대로 나누어 운용하고 있으며, 인간(운영자)은 판정·기획·오프라인 이벤트에 집중하고, 생성·구현·측정·개선은 에이전트가 자율적으로 실행합니다.

숫자로 보는 운용 밀도

2026년 8월 3일 시점의 각 리포지토리 Issue·PR 번호의 진행 상황입니다.

또 다른 특징은 작성부터 머지까지의 시간입니다. PR의 메타데이터를 보면, 예를 들어 coelia-system의 배치(batch) 처리 수정 PR은 10:43:34 작성 · 10:43:40 머지(6초), 많은 기능 PR도 수 분~십수 분 내에 머지됩니다. 이는 정적 체크(lint·타입·아키텍처 검사)를 초고속의 pre-push 게이트에서 끝내고, 무거운 테스트는 라벨(label)이 트리거되는 CI로 분리하며, 리뷰는 독립적인 컨텍스트를 가진 AI 체커가 담당하는 분업의 결과입니다.

솔직히 말하면, 이 6초 머지 시점에는 커버리지 CI가 돌아가고 있지 않습니다. 무거운 테스트는 run-tests 라벨이 붙은 PR에서만 실행되므로, 라벨을 붙이지 않으면 통과하지 않고도 머지될 수 있습니다. 즉, 「main에 들어가기 전에 반드시 풀 커버리지를 통과한다」라고 단언할 수 있는 상태는 아니며, 라벨을 붙이는 운용을 사람이 지킨다는 전제가 남아 있습니다. 이 부분은 구조적으로 완전히 막지 못한 미해결된 트레이드오프(trade-off)입니다 (속도와 비용을 선택한 대가).

어느 하루의 PR 타임라인

콘텐츠 기반 리포지토리(coelia-harness)의 2026년 8월 3일, 실제 머지 이력을 시간 순서대로 나열합니다.

(콘텐츠 생성 수나 배포면의 내역은 운용 내부 정보이므로, 여기서는 종별로만 표기합니다.)

정기 루틴이라는 척추

이 타임라인은 임기응변적인 것이 아니라, cron처럼 트리거되는 정기 루틴의 집합입니다. PR 제목을 통해 역추적할 수 있는 주요 루틴은 다음과 같습니다.

• 아침 리서치·점심 리서치: 아이디어 백로그(backlog) 보충. 「a5 인접 업계의 고객 유치·체험 설계」와 같이 관점을 로테이션함
• 야간 생성 배치(batch): 다음 날 분량의 콘텐츠를 일괄 생성하여 결과물을 커밋(commit)까지 가져감
• 검수편 (05:45): 야간 배치의 결과물을 독립적으로 체크하고 실측 로그를 남김
• KPI 클로징 (00:10): 일일 측정값을 집계하여 대시보드 업데이트
• 게시 실행편: 예약 게시 실행 및 결과 기록

포인트는 루틴의 실행 결과와 학습 내용 모두 PR로서 Git에 안착한다는 점입니다. Slack 알림이나 채팅 로그로 사라져 버리는 정보를 만들지 않습니다. 「ops: 검수편 05:45 실측 로그」와 같은 PR이 매일 쌓이므로, 나중에 에이전트 스스로가 「어제의 자신」을 검색할 수 있습니다.

실패도 그대로 커밋된다

이 로그의 재미있는 점은 성공뿐만 아니라 실패의 기록도 동일한 입도로 남는다는 것입니다. 실제 PR 제목에서 몇 가지를 뽑아보았습니다.

• 브라우저 경유 동영상 업로드 불가 (6개 경로 실측) 및 note 투입 시의 3가지 함정을 증류
• CI 러너 외부 이전(Namespace)을 실측으로 기각하고 채택 여부를 Issue화
• 하네스 추종 워치가 수렴하지 않음 (동일 버전을 3개가 독립 검수) ── 기구 시정
• A/B 병행 허용 판단과 실패의 교훈을 증류

마지막 예시처럼, 하네스 자체의 설계 실수(동일한 업데이트를 3개의 루틴이 이중 삼중으로 검수하고 있었음)를 에이전트가 발견하여 기구 자체를 수정하는 PR(Pull Request)도 나옵니다. 자동화라는 그물의 올이 풀린 부분을 자동화 스스로가 꿰매고 있는 형국입니다.

이 밀도를 뒷받침하는 규율

로그만 보면 마법처럼 보이지만, 이를 지탱하는 것은 수수한 규율입니다. 자세한 내용은 각론 기사에 맡기고, 요점만 나열하겠습니다.

근원·상태·루프를 모두 엔진 외부에 두기: Git 파일 + 결정론적 스크립트(Deterministic script)가 정답이며, Claude/Codex 중 어느 쪽으로 조작하더라도 동일한 루프가 돌아감 -
PR은 묶고, 논점은 커밋(Commit)으로 나누기: CI 비용을 실측하여 불필요한 실행(run)을 줄임 (어떤 PR에서는 비용을 1/5로 절감). 단, 품질 기준(커버리지(Coverage)·lint·타입)은 절대 낮추지 않음 -
자기 보고로 완료하지 않기: 머지(Merge) 전에 독립 서브 에이전트의 더블 체크(S4라고 부르는 단계)를 거침 -
배움은 '학습의 사다리'를 통해 기계화까지 운반하기: 리뷰 지적 → 체커(Checker) 정의로 승격 → lint나 CI로의 기계화와 같이 단계적으로 인적 개입을 줄여나감

요약

• AI 에이전트 운용 리포지토리에서는,
  4일 만에 PR 번호가 116개 증가하는 밀도가 실제로 나타남 - 밀도의 원천은 '빠른 모델'이 아니라,
  정기 루틴 × Git 착지 × 독립 체크의 설계 - 실패의 실측 로그가 자산으로서 쌓이기 때문에, 운용 기간이 길어질수록 에이전트는 더 똑똑하게 움직임

다음 기사에서는 이 체제의 토대가 되고 있는 시스템 프롬프트 설계(엔지니어의 마음가짐 주입)와, 콘텐츠를 매일 양산하는 '루프 엔지니어링(Loop Engineering)'의 내용을 깊이 있게 다룹니다.

커뮤니티 운영과 커리어 설계 관련 발신은 obata-tomu.jp/articles 에서 확인하실 수 있습니다.

Discussion