AI 작업에 '운영 규칙'을 세워라 — 작업 전·중·후, 하나의 규칙, 증거 기반 완료 보고
에이전트에게는 ‘지시’가 아니라 ‘운영 규칙’이 필요하다
AI 에이전트에게 자율성을 줄수록, 매번 즉흥적으로 지시하는 방식은 무너진다. 필요한 건 그때그때의 지시가 아니라 모든 작업이 통과하는 운영 규칙(operating rules) 이다. 위 그림의 세 줄이 그 골격이다 — (1) 작업 전·중·후 규칙, (2) 엔지니어링 위생을 하나의 규칙으로 묶기, (3) 증거 기반 완료 보고. 하나씩, 왜 그리고 어떻게 세우는지 본다.
이 글은 최근 정리한 Ouroboros 3부작과 훅 라이프사이클 논의의 실전 착지점이다.
규칙 1. 작업 전·중·후를 나눠서 규칙을 만든다
AI 작업은 하나의 덩어리가 아니라 생애 단계(lifecycle) 를 가진다. 각 단계에 걸리는 규칙이 다르다.
| 단계 | 걸어야 할 규칙 | Claude Code의 자리 |
|---|---|---|
| 작업 전 | 목표·제약·성공기준 확인, 불명확하면 질문, 산출물 종류 확정 | 계획 모드, UserPromptSubmit/PreToolUse 훅 |
| 작업 중 | 편집마다 lint/typecheck, 위험 명령 차단, 스펙 대조 | PostToolUse(Write/Edit) 훅 |
| 작업 후 | 증거 기반 완료 보고, 남은 위험 명시 | Stop 훅, 완료 보고 형식 |
여기서 중요한 구분: 어떤 규칙은 프롬프트(CLAUDE.md)로, 어떤 규칙은 코드(훅)로. 앞 글에서 정리한 대로, 프롬프트는 에이전트가 따르려 노력하는 것이고 훅은 구조적으로 강제되는 것이다. “위험 명령 차단” 같은 규칙은 노력에 맡기지 말고 PreToolUse 훅으로 못 박아야 한다.
규칙 2. 브랜치·커밋·리뷰·문서 동기화·승인 기준을 ‘하나의 운영 규칙’으로 묶는다
이 다섯을 따로따로 그때그때 지시하면, 에이전트는 매번 다르게 행동하고 일관성이 무너진다. 하나의 운영 규칙으로 묶어 단일 진실 원천을 만든다:
- 브랜치: 기본 브랜치에서 바로 작업하지 않는다 — feature/fix 브랜치를 먼저 딴다
- 커밋: 논리 단위마다, 메시지에 근거를 담아. 작은 커밋이 곧 되감기 가능한 이벤트 로그다
- 리뷰: 구현한 에이전트가 아니라 깨끗한 컨텍스트의 서브에이전트가 검토(배심원 독립성)
- 문서 동기화: 코드가 바뀌면 관련 문서·CLAUDE.md도 같은 PR에서 갱신
- 승인 기준: “됐어 보임”이 아니라 검증 명령이 통과해야 승인
이걸 하나로 묶는 이유는 Ouroboros가 21개 워크플로를 스킬로 결정화한 이유와 같다 — 좋은 워크플로는 매번 프롬프트로 반복하지 말고 규칙(또는 스킬)으로 결정화하라. 한 곳에 있어야 에이전트가 바뀌어도 기준이 남는다.
규칙 3. 완료 보고에 변경 파일·검증 결과·남은 위험을 반드시 포함시킨다
가장 중요한 규칙. 에이전트의 “완료했습니다”는 그 자체로는 증거가 아니다 — Ouroboros의 원칙 II “완료는 승인이 아니다” 그대로다. 완료 보고를 세 항목의 증거로 강제한다:
- 변경 파일: 무엇을 건드렸나 (diff 범위)
- 검증 결과: 각 수용 기준별 검증 명령 + 실제 출력. 실행 못 한 검증은 “미실행”으로 명시(실행한 척 금지)
- 남은 위험: 알려진 한계·엣지 케이스 최소 한 줄
“Done”이라는 한 마디로 끝나면 safe-but-wrong이 그대로 통과한다. 이 형식이어야 표류가 걸러진다.
바로 쓰는 CLAUDE.md 운영 규칙 템플릿
세 규칙을 압축한 스니펫. 프로젝트 CLAUDE.md에 넣어 두면 모든 세션에 적용된다:
## AI 작업 운영 규칙
### 작업 전
- 복잡한 작업은 목표/제약/성공기준을 확인하고, 추측이 남으면 질문한다
- 산출물의 종류(도구/문서/스크립트)를 착수 전에 확정한다
### 작업 중
- 코드 변경 후 lint + typecheck + 관련 테스트 (실패 시 진행 중단)
- 위험 명령(push/배포/마이그레이션/.env)은 사전 확인
- 3단위마다 스펙과 대조해 표류 점검
### 작업 후 (완료 보고 형식)
- 변경 파일 목록 (diff 범위)
- 수용 기준별 검증 명령 + 출력 원문 (미실행은 "미실행"으로 명시)
- 남은 위험/알려진 한계 1줄 이상
### 엔지니어링 위생 (하나의 규칙)
- 기본 브랜치 직접 작업 금지 → feature/fix 브랜치
- 논리 단위 커밋, 메시지에 근거 포함
- 리뷰는 깨끗한 컨텍스트의 서브에이전트로
- 코드 변경 시 관련 문서/CLAUDE.md 동기화
프롬프트로 둘 것 vs 코드로 강제할 것
운영 규칙을 세울 때 마지막 판별 질문 하나: “이건 확률적으로 지켜져도 되나, 결정론적으로 보장돼야 하나?”
- 프롬프트(CLAUDE.md)로 충분: 완료 보고 형식, 커밋 메시지 스타일, 질문 습관 — 노력으로 지켜도 되는 것
- 코드(훅/권한)로 강제: 위험 명령 차단(
PreToolUse훅), 편집 후 자동 포맷(PostToolUse훅), push/설치 승인(settings.jsonallow/ask) — 반드시 지켜져야 하는 것
내 실제 ~/.claude/settings.json도 이 이중 구조다 — 위생·보고 규칙은 CLAUDE.md에, 위험 명령 검사·자동 포맷·컨텍스트 주입은 훅에. 중요한 규칙일수록 프롬프트에서 코드로 옮긴다.
한 줄 결론
AI에게 자율성을 줄수록 감독은 줄어든다. 그 빈자리를 운영 규칙이 대신 감독해야 한다. 작업 전·중·후로 나누고, 엔지니어링 위생을 하나로 묶고, 완료를 증거로 닫아라. 그림의 세 줄은 그 최소 골격이고, 나머지는 당신의 워크로드가 채운다.
출처 · 관련 글
- 첨부 이미지: 사용자 제공(AI 작업 운영 규칙 3항목).
- 완료 보고·”완료는 승인이 아니다”·배심원 독립성의 근거: Ouroboros 3부작 정리 (원 저장소 Q00/ouroboros 실측 분석 기반).
- 작업 전·중·후 = 훅 라이프사이클, 프롬프트 vs 코드 강제: 훅으로 보는 하네스의 깊이 (Claude Code Hooks 공식 문서 기반).
- Claude Code 훅 공식 문서: https://code.claude.com/docs/en/hooks
참고: 위 템플릿은 규범적 제안이며, 프로젝트 규모에 맞춰 취사선택하라. 빠른 일회성 스크립트에 전체를 적용하는 것은 과잉이다.