~/posts/ai-workflow/agent-rules-in-repo.md

date:
tags: [ai, claude-code, workflow]
read: 4분

코드는 에이전트가, 머지는 내가

안녕하세요, 개발자 브론입니다. 지난 글에서 코드의 95% 이상을 Claude Code에 맡긴다고 썼는데요, 이번에는 그렇게 맡기면서도 제가 꼭 붙잡고 있는 일과, 그걸 저장소 규칙으로 적어 둔 방식을 공유하려고 합니다.

개발을 하면서 이제는 AI를 떼려야 뗄 수 없게 되었는데, 주변을 보면 AI를 쓰는 방식이 정말 다양하더라고요. 저도 다른 분들이 쓰는 걸 보고 바로 따라 해 보곤 합니다. 이 블로그와 개인 프로젝트를 하면서 어떻게 하면 AI를 더 잘 쓸 수 있을지 고민하며 매일 새 방식을 시도하고 있습니다. AI가 일자리를 뺏어 갈 거라는 걱정 반, AI와 함께 일하는 재미 반입니다. 제 방식을 공유하고 조언도 얻고 싶어서 이 글을 씁니다.

사람이 하는 일을 적어 두기

CLAUDE.md (web 저장소에서 인용, 작업 규칙 일부)
- push, PR 생성, 머지는 사람이 한다. 요청받지 않으면 커밋까지만 하고 멈춘다
- 작업 시작 전 `main`을 최신으로 받고 이슈 번호로 브랜치를 만든다
- 이슈 범위 밖의 변경은 하지 않는다. 필요해 보이면 제안만 한다
- 응답과 커밋 설명은 한국어로

에이전트가 할 일과 제가 할 일을 먼저 나눴습니다. 생산성으로는 에이전트를 따라갈 수 없으니, 비교우위로 따져 제가 맡는 게 나은 곳이 어디인지를 생각해 봤습니다. 제 답은 검수와 배포였습니다. 코딩은 아무리 빨리 한다 해도 에이전트보다 빠를 자신이 없더라고요. 그래서 코딩은 에이전트에게 맡기고, push와 PR, 머지는 제가 합니다. main에 머지하려면 빌드와 PR 제목 검사를 통과해야 합니다. 이 중에서도 머지만큼은 어느 프로젝트든 제가 합니다.

저는 겁이 많은 편이라 이런 안전장치를 할 수 있는 만큼 걸어 둡니다.

이슈 → 계획 → 승인

CLAUDE.md (web 저장소에서 인용, Forgejo (tea CLI) 절 일부, 줄임)
- 작업 시작: `tea issues <번호>`로 이슈를 읽고, 완료 조건 기준으로 계획을 먼저 보여준다
- 이슈 생성은 초안을 먼저 보여주고 승인받은 뒤에 한다
- PR 생성(`tea pulls create`)은 요청받았을 때만. 본문에 `closes #<번호>`
- 이슈·PR을 닫거나 삭제하지 않는다. 머지는 사람이 한다

이슈를 쌓기 전에 라벨부터 정했습니다. 우선순위(prio/low·mid·high)와 종류(type/bug·feature·infra·docs·chore) 라벨을 만들어 두고, 이슈 초안은 에이전트에게 맡겼습니다. 초안은 에이전트가 쓰고, 승인은 제가 합니다. 완전히 맡기기보다 틀이 있어야 지시하기도 관리하기도 편해서, 이슈 템플릿도 정해 두었습니다.

기능 템플릿에는 처음부터 완료 조건 칸이 있었습니다. 여기에 “이슈를 읽으면 완료 조건으로 계획을 먼저 보여 준다”는 규칙을 더했습니다. 에이전트는 계획을 내놓고, 저는 그 계획을 승인하거나 고칩니다. 이슈 → 계획 → 승인은 이렇게 돌아갑니다.

확인 못 한 것을 적게 하기

PR 템플릿에 “확인 방법” 칸이 있습니다.

.forgejo/pull_request_template.md (web 저장소에서 인용, 일부)
## 확인 방법
<!-- 직접 확인한 절차, 또는 리뷰어가 따라 할 절차 -->
1.

에이전트가 PR을 만들 때, 직접 확인하지 못한 것은 “확인하지 못함”이라고 적게 했습니다. 실제 PR에는 이렇게 남았습니다.

  • #34: “작성자는 버튼이 보이는 것까지만 확인했고, 클릭 동작은 확인하지 못함”
  • #8: “npm run dev로 모바일·데스크톱 폭, 라이트·다크 모드에서 화면 확인 (리뷰어 확인 필요)”
  • #19: “CSS를 HTML에 인라인하는 방법도 시험했지만, FCP가 0.1s 정도만 줄어서 넣지 않았습니다” — 안 한 것과 그 이유
  • #17: “알려진 문제” 절 — 폰트 CSS 380KB, 대비 미달 색. 다음 작업(#18·#21)에서 고침

이런 항목은 제가 직접 확인해 보고, 문제가 없으면 머지하고 문제가 있으면 다시 고쳐 달라고 합니다.

역할이 뒤집힌 곳

지금 개발하고 있는 서비스부터는 에이전트를 셋으로 나눴습니다. 총괄(HQ), 개발(DEV), 리뷰어(REVIEWER)입니다. 저는 총괄하고만 이야기합니다. 총괄이 개발에게 일을 나눠 주고, 개발이 끝나면 그 결과를 리뷰어에게 넘깁니다. 저는 계획을 승인하고, 리뷰까지 끝난 PR을 머지합니다.

이 블로그는 반대입니다. 글은 제가 쓰고, 리뷰는 에이전트가 합니다. 쓰는 중간중간 리뷰를 자주 받다 보니 push와 PR은 총괄에게 넘겼습니다. 그래도 머지는 여기서도 제가 합니다.

마무리

이렇게 처음부터 규칙(안전장치)을 자세히 정해 두고 개발을 시작한 건 이번이 처음이었습니다. 여기에는 여러 에이전트를 한 화면에 띄워 두고 일을 주고받게 해 주는 Herdr라는 도구의 영향이 컸는데, 이건 다른 글에서 따로 소개하겠습니다.

AI는 불과 몇 달 전과도 비교가 안 될 만큼 좋아졌습니다. 이제 중요한 건 AI를 같이 일하는 팀원으로 보고 역할을 어떻게 나누느냐인 것 같습니다. 코드를 맡길 때든 글을 봐 달라고 할 때든, 저는 머지만큼은 제 손에 두고 있습니다. 여러분은 어떻게 나누고 계신가요?

esc

// 최근 글