# '반복을 피하라'는 규칙이 아니다 — 사고 현장에서만 나오는 구체성

> 에이전트 운영 규칙은 미리 설계하는 것이 아니다. 사고 현장에서만 얻을 수 있는 구체성이 있다.

---

OpenClaw를 처음 세팅하던 날, AI 에이전트 Elon의 AGENTS.md에 운영 규칙을 미리 써두려 했다.

"반복적인 보고를 피할 것." "판단이 필요한 작업은 신중하게." "스킬은 적절히 사용할 것."

쓰고 나서 다시 읽어봤다. 다 맞는 말이었다. 그리고 전부 쓸모없는 말이었다.

## 뽀짝이의 9일 — 절대 규칙 0개에서 14개로

뽀짝이는 지피터스 AI스터디의 운영비서 에이전트다. 운영 에피소드 20편이 공개되어 있었고, 그걸 읽으면서 규칙이 어떻게 탄생하는지 들여다볼 수 있었다.

운영 첫날 절대 규칙 수: **0개**.

9일 후:

**14개**.

14개 전부 실제 사고에서 나왔다.

```javascript
새벽 아침 브리핑 발송 사고 →
  "아침 브리핑은 KST 08:30~09:30 사이에만 발송. 이 시간 외 절대 금지"

같은 오류를 15번 보고한 사고 →
  "동일 이슈는 최초 1회만 보고. 해결됐다고 할 때까지 스킵"
```

사고가 나기 전에는 이 규칙들이 필요한지조차 몰랐다. 문제가 발생하고 나서야 "이 상황에서 정확히 무엇을 해야 하는가"가 명확해진다.

## "반복을 피하라"와 "최초 1회만"의 차이

두 문장을 에이전트 입장에서 읽어보자.

**"반복적인 보고를 피할 것"** — 지금 이 보고가 반복인가, 아닌가? 에이전트가 판단해야 한다. 판단하는 순간 해석이 달라진다. 10번이 반복인가, 3번이 반복인가.

**"동일 이슈는 최초 1회만 보고"** — 판단할 게 없다. 같은 이슈인지만 확인하면 된다.

추상 원칙은 방향이다. 구체 규칙은 실행 지시다. 에이전트에게 방향을 주면 해석이 생기고, 해석이 생기면 실수가 생긴다.

좋은 규칙의 조건은 하나다. **해석할 여지가 없어야 한다.** 구체적 조건(언제, 무엇을, 어떻게)이 없는 문장은 규칙이 아니라 원칙이다.

---

## 뽀짝이 경험에서 우리 시스템에 가져온 것

에피소드 20편을 읽으면서 세 가지 패턴이 보였다. 그걸 우리 AGENTS.md에 절대 규칙으로 추가했다.

### R001: 판단이 개입되는 작업은 서브에이전트에게 위임하지 않는다

뽀짝이가 서브에이전트에게 이미지 카드 제작을 맡겼다가 전량 재작업한 사건이 있었다. 흰색 배경이어야 했는데 보라색으로 나왔다.

"더 비싼 모델로 바꾸면 해결된다"고 생각했는데 아니었다. **서브에이전트는 메인 에이전트의 SOUL.md도, MEMORY.md도, 쌓인 판단 맥락도 가져가지 않는다.** 모델이 아무리 좋아도 맥락이 없으면 처음 만난 사람처럼 일한다.

코드 수정, API 호출, 데이터 조회처럼 **맥락 없이도 실행할 수 있는 것**은 위임할 수 있다. 디자인, 글쓰기, 스타일 판단처럼 **본체의 기억이 필요한 것**은 위임하면 안 된다.

### R002: 모든 스킬의 description은 구체적 요청 예시를 포함해야 한다

스킬이 있어도 description이 부정확하면 에이전트가 그 스킬을 "모르는" 것과 같다.

OpenClaw에서 스킬은 description을 기준으로 매칭된다. "무언가를 도와주는 스킬"이라고 써있으면, 에이전트는 어떤 상황에서 이 스킬을 써야 하는지 판단하지 못한다.

description에 "경쟁사 분석 요청 시 사용. 예: '경쟁사 A의 최근 전략을 조사해줘'"처럼 구체적인 요청 예시가 있어야 매칭이 제대로 된다. **스킬 존재 여부가 아니라 description 품질이 스킬의 실제 가용성을 결정한다.**

### R003: 절대 규칙은 구체적 조건(언제·무엇을·어떻게)을 포함해야 한다

R001, R002가 나오면서 세 번째 규칙이 자연스럽게 따라왔다.

AGENTS.md에 규칙을 추가할 때 형식 기준이 필요했다. "언제, 무엇을, 어떻게"가 없는 문장은 규칙 목록에 올리지 않는다. 원칙 메모와 절대 규칙 목록을 분리해서 관리한다.

---

## 규칙은 운영이 시작된 후에 만들 수 있다

여기서 딜레마처럼 보이는 게 있다. 규칙은 사고가 나야 만들 수 있는데, 사고가 나면 이미 늦은 것 아닌가.

그렇지 않다. 사고가 나야 규칙의 **구체성**을 얻을 수 있다는 얘기지, 모든 사고를 직접 겪어야 한다는 얘기가 아니다.

### 다른 팀의 사고도 재료가 된다

뽀짝이의 에피소드를 통해 우리는 직접 사고를 내지 않고 R001, R002, R003을 가져올 수 있었다. 다른 팀의 사고가 우리 규칙의 재료가 됐다. 운영 기록이 공개되어 있으면 그 실수도 공유된다.

운영 전에 쓴 규칙은 대부분 원칙 수준에 머문다. 에이전트가 실제로 판단해야 하는 순간에 작동하는 규칙은, 그 판단 상황을 — 직접 또는 간접으로 — 경험한 후에야 쓸 수 있다.

> 규칙은 설계하는 게 아니라 운영에서 발굴하는 것이다.
> "~를 피하라"는 좋은 말이다. 그건 원칙이지 규칙이 아니다.

For the site tree, see the [root Markdown](https://slashpage.com/openclaw.md).