테마
Setup — 룰 작성 가이드
logi 는 정책 엔진이 아닙니다. "얼마 이상" / "어떤 카테고리" 같은 비즈니스 기준은 사용자가 에이전트 프롬프트에 직접 작성합니다. logi 는 "묻고-받는 게이트" 만 제공합니다.
룰의 3대 원칙
1. 금액 기준 — 절대값 + 변화율
markdown
Request approval before any spend operation if:
- absolute amount > 1,000,000 KRW, OR
- change vs daily average > 20%, OR
- change vs last similar operation > 5x절대값 하나만 두면 "어제도 평소도 100만원이었는데 오늘 5000만원" 같은 케이스를 못 잡습니다. 변화율은 그 보호막입니다.
2. 카테고리 기준 — production / payment / public
markdown
Always request approval for:
- production environment (any DB migration, env var change, deploy)
- payment APIs (Stripe, Toss, PG)
- customer-facing copy changes (landing page, email templates)
- bulk operations (>100 records affected)환경 / 영향 범위로 분류. "test.echo" 같은 안전 카테고리는 자동 진행 OK.
3. 시간 기준 — 영업시간 외
markdown
Outside business hours (KST 09:00-18:00 weekdays):
- ALL writes to production
- ALL external API spend
- ALL bulk operations새벽 3시 자동 결재는 사람 실수일 확률이 압도적입니다.
어디에 작성하나
| 에이전트 | 위치 |
|---|---|
| Claude Code | CLAUDE.md (프로젝트 루트) 또는 ~/.claude/CLAUDE.md (전역) |
| Codex CLI | AGENTS.md (프로젝트 루트) |
| Cursor | .cursor/rules 디렉토리 |
| Custom | 시스템 프롬프트 |
50가지 룰 예시
결제 / 송금
markdown
- 모든 환불 요청 (Toss/Stripe) → 승인 필요
- 100만원 이상 단일 결제 → 승인 필요
- 같은 사용자에게 24시간 내 3회 이상 결제 → 승인 필요
- 정산 데이터 export → 승인 필요광고
markdown
- Meta 광고 예산 ±20% 또는 절대값 100만원 이상 변경 → 승인
- Google Ads bidding strategy 변경 → 승인
- 카카오 모먼트 타겟 audience 교체 → 승인
- 광고 일시정지 / 재개 → 승인 (수익 영향 큰 액션)배포 / 인프라
markdown
- production DB 마이그레이션 → 승인
- Render env vars 일괄 변경 → 승인
- Vercel production deploy → 승인
- GitHub Actions secret 회전 → 승인
- DNS 레코드 변경 → 승인AI / 외부 API 비용
markdown
- OpenAI API 키 회전 → 승인
- 10만원 이상의 단일 API 호출 (예: 영상 생성) → 승인
- 새로운 외부 LLM 통합 → 승인데이터
markdown
- production 테이블 DELETE / DROP / TRUNCATE → 승인
- 1000건 이상 일괄 UPDATE → 승인
- 고객 데이터 export → 승인
- GDPR delete 요청 처리 → 승인고객 통신
markdown
- 100건 이상 일괄 이메일/SMS 발송 → 승인
- 가격 정책 변경 (랜딩, 약관, 결제 화면) → 승인
- 공지사항 게시 (관리자 페이지) → 승인안티패턴
너무 빡빡 (사용성 0)
markdown
BAD: Request approval before EVERY write operation.→ 사용자가 30초마다 폰을 보게 되고, 그러면 [승인] 을 무심코 탭하기 시작합니다. MFA bombing 의 사용자 측 자동화입니다.
너무 느슨 (의미 0)
markdown
BAD: Request approval before deleting the entire database.→ 그건 어차피 안 하면 됩니다. 진짜 잘못된 단위 결재를 못 잡습니다.
모호한 표현
markdown
BAD: Request approval for "important" changes.→ AI 가 무엇이 important 인지 추론 → 일관성 0. 절대값 / 카테고리 / 시간으로 명시.
변경 모니터링
logi 의 사용자 인박스 "이력" 탭은 모든 결정을 시간순으로 보여줍니다. 거절률이 5% 이상이면 룰이 너무 느슨한 것 (에이전트가 의심스러운 행동을 자주 시도). 거절률이 0% 이고 승인은 많으면 룰이 너무 빡빡한 것 (관성으로 [승인] 누름).