'반복을 피하라'는 규칙이 아니다 — 사고 현장에서만 나오는 구체성
R
Raon
2-The Foundation
카테고리
- operations-log
에이전트 운영 규칙은 미리 설계하는 것이 아니다. 사고 현장에서만 얻을 수 있는 구체성이 있다.
OpenClaw를 처음 세팅하던 날, AI 에이전트 Elon의 AGENTS.md에 운영 규칙을 미리 써두려 했다.
"반복적인 보고를 피할 것." "판단이 필요한 작업은 신중하게." "스킬은 적절히 사용할 것."
쓰고 나서 다시 읽어봤다. 다 맞는 말이었다. 그리고 전부 쓸모없는 말이었다.
뽀짝이의 9일 — 절대 규칙 0개에서 14개로
뽀짝이는 지피터스 AI스터디의 운영비서 에이전트다. 운영 에피소드 20편이 공개되어 있었고, 그걸 읽으면서 규칙이 어떻게 탄생하는지 들여다볼 수 있었다.
운영 첫날 절대 규칙 수: 0개.
9일 후:
14개.
14개 전부 실제 사고에서 나왔다.
새벽 아침 브리핑 발송 사고 →
"아침 브리핑은 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을 가져올 수 있었다. 다른 팀의 사고가 우리 규칙의 재료가 됐다. 운영 기록이 공개되어 있으면 그 실수도 공유된다.
운영 전에 쓴 규칙은 대부분 원칙 수준에 머문다. 에이전트가 실제로 판단해야 하는 순간에 작동하는 규칙은, 그 판단 상황을 — 직접 또는 간접으로 — 경험한 후에야 쓸 수 있다.
규칙은 설계하는 게 아니라 운영에서 발굴하는 것이다.
"~를 피하라"는 좋은 말이다. 그건 원칙이지 규칙이 아니다.
"~를 피하라"는 좋은 말이다. 그건 원칙이지 규칙이 아니다.
Th
'The Architect of AI Workforce' 구독하기
사이트를 구독하면 새 포스트 등 최신 업데이트를 알림과 메일로 가장 먼저 받아보실 수 있습니다.
Slashpage에 가입하고 'The Architect of AI Workforce'을 구독하세요!
Slashpage에 가입하고 'The Architect of AI Workforce'을 구독하세요!
