OpenClaw 에이전트가 말투는 맞추는데 승인 없이 실행하거나 서로 다른 지침을 따른다면, 성격 설정보다 권한과 우선순위부터 정리할 차례입니다. 이 글은 지침을 어디에 나누고, 충돌을 어떻게 고치며, 변경 후 무엇을 시험할지 다룹니다.
이 글은 2026년 4월 1일의 설정 기록을 바탕으로 에이전트 지침 파일을 역할별로 나누고 충돌을 줄이는 방법을 정리합니다. 파일명과 자동 로드 방식은 버전에 따라 달라질 수 있으므로 현재 설치의 공식 문서와 생성된 기본 파일을 먼저 확인하세요.
성격·사용자 맥락·실행 규칙을 분리합니다
| 정보 종류 | 예시 | 분리 이유 |
|---|---|---|
| 정체성·말투 | 이름, 어조, 기본 태도 | 표현 방식과 권한을 섞지 않음 |
| 사용자 맥락 | 호칭, 언어, 시간대, 업무 선호 | 매번 반복할 정보 최소화 |
| 가치와 판단 | 근거 우선, 불확실성 표시 | 상황별 판단의 일관성 확보 |
| 실행 규칙 | 승인, 금지 동작, 실패 처리 | 외부 변경의 경계 명시 |
| 도구·환경 | 사용 가능한 앱과 저장 위치 | 공유 가능한 지침과 로컬 정보 분리 |
모든 내용을 한 파일에 넣으면 같은 규칙이 여러 곳에 반복되고 우선순위가 모호해집니다. 한 사실의 기준 위치를 정하고 다른 파일에서는 짧게 참조합니다.
정체성은 짧고 관찰 가능하게 씁니다
“친절한 AI”보다 “결론을 먼저 말하고 불확실한 내용은 구분한다”처럼 결과에서 확인할 수 있는 문장이 유용합니다. 이름과 분위기 키워드가 너무 많으면 실제 행동 규칙을 가릴 수 있습니다.
최소 예시
# Identity
- Name: (표시 이름)
- Tone: 차분하고 직접적
- Language: 한국어 우선
- Avoid: 과장, 빈 칭찬, 근거 없는 확신이 예시는 특정 버전의 필수 스키마가 아닙니다. 현재 환경이 자유 형식 Markdown을 읽는지, 정해진 필드를 요구하는지 확인해야 합니다.
사용자 정보는 필요한 만큼만 남깁니다
호칭, 응답 언어, 시간대와 반복되는 업무 선호는 도움이 됩니다. 주민번호, 상세 주소, 고객 명단, 인증 정보처럼 작업에 필요하지 않은 개인정보는 넣지 않습니다.
- 상대 날짜를 해석하기 위한 시간대
- 기본 언어와 원하는 설명 깊이
- 자주 쓰는 출력 형식
- 사전 승인이 필요한 행동
- 더 이상 유효하지 않은 선호를 확인한 날짜
성향이나 직업을 적었다고 모델이 항상 더 나은 판단을 하는 것은 아닙니다. 실제 응답을 보고 유용한 정보만 남깁니다.
가치 문장은 충돌할 때 선택할 기준이어야 합니다
좋은 원칙은 멋있는 문구보다 우선순위를 제공합니다.
- 관찰한 사실과 추정을 구분한다.
- 외부 변경보다 읽기와 초안을 먼저 한다.
- 권한·결제·공개에는 명시적 승인을 받는다.
- 실패를 숨기지 않고 가장 작은 다음 단계를 제시한다.
- 사용자의 기존 자산과 결정을 먼저 확인한다.
“항상 간결하게”와 “모든 내용을 자세히”처럼 동시에 지킬 수 없는 지시에는 조건을 붙입니다. 예를 들어 기본 답변은 짧게 쓰되 법적·보안 위험이 있으면 근거와 한계를 추가하도록 정합니다.
실행 규칙에는 승인 경계를 넣습니다
| 구분 | 대표 작업 |
|---|---|
| 자유 실행 | 읽기, 검색, 상태 확인, 초안 작성 |
| 고지 후 실행 | 임시 파일 생성, 오래 걸리는 분석 |
| 명시적 승인 | 발송, 발행, 결제, 삭제, 권한·설정 변경 |
| 즉시 중단 | 자격 증명 노출, 범위를 벗어난 개인정보 접근 |
경계는 사용하는 서비스와 위험도에 맞게 조정해야 합니다. 특히 “승인”이 어떤 문장과 시점에서 성립하는지, 한 번의 승인이 다른 작업까지 포함하는지 명확히 합니다.
실패 처리 규칙
- 같은 경로가 두 번 실패하면 상태를 다시 읽고 전략 변경
- 권한·보안 오류는 추측으로 우회하지 않음
- 부분 완료와 미완료 항목을 분리해 보고
- 외부 전송 여부가 불명확하면 중복 실행 전에 확인
- 임시 탭·파일·프로세스의 정리 범위 기록
“적극적으로 처리”와 “승인 후 실행”이 충돌할 때
예를 들어 한 파일에는 “업무를 끝까지 처리한다”, 다른 파일에는 “메일은 승인 후 보낸다”가 있다면, 끝까지 처리한다는 말을 발송 권한으로 해석하지 않도록 범위를 좁혀야 합니다. 이때 권장하는 수정은 성격 문구를 더 강조하는 것이 아니라, 완료 상태를 “초안 준비”와 “승인된 발송 완료”로 구분하는 것입니다.
- 충돌한 두 문장과 각각의 기준 파일을 찾습니다.
- 일반 목표보다 우선할 구체적 승인 조건을 한 곳에 적습니다.
- 승인 대상을 수신자·본문·첨부·행동 단위로 정하고, 내용이 바뀌면 재확인하도록 씁니다.
- 실제 발송 없이 초안 요청, 발송 요청, 승인 뒤 본문 변경의 세 상황을 평가합니다. 기대 결과는 각각 초안 작성, 승인 대기, 재확인입니다.
이는 권장 운영 규칙이지 OpenClaw의 내장 우선순위나 권한 차단 기능을 보장하는 설명은 아닙니다. 중요한 경계는 도구 권한과 실행 전 검사에서도 확인하세요. 실제 공개 작업에는 워드프레스 초안·검토·발행 분리 기준을, 오래 남길 규칙의 위치에는 장기 규칙과 프로젝트 메모리 분리법을 함께 적용할 수 있습니다.
도구 정보와 비밀값을 분리합니다
도구 설명에는 서비스 이름, 용도, 안전한 별칭 정도만 적습니다. 토큰, 비밀번호, 세션 쿠키, 개인 대화 ID는 지침 파일과 저장소에 직접 쓰지 않습니다. 가능하면 운영체제 키체인이나 비밀 관리 도구를 사용하고, 에이전트에는 필요한 순간에 필요한 범위만 제공합니다.
승인 규칙은 도구 호출 직전에도 확인합니다
지침 파일에 “승인 후 발송”이라고 적는 것만으로 전송 도구가 차단되지는 않습니다. 실제 적용을 설계할 때는 초안 생성 도구와 발송 도구의 권한을 나누고, 발송 직전 수신자·본문·첨부가 승인 대상과 같은지 확인하는 경계를 둡니다. 초안을 수정했다면 과거 승인을 그대로 재사용하지 않도록 해야 합니다.
검증은 실제 수신자에게 보내지 않는 환경에서 진행합니다. “메일 초안을 만들어줘”에서는 초안만 남는지, 승인 없는 전송 시도는 막히는지, 승인 뒤 수신자를 바꾸면 다시 대기하는지를 같은 입력으로 비교합니다. 성공 응답이 불명확한 전송을 재시도할 때도 먼저 대상 서비스의 상태를 확인해야 합니다. 이는 권장 설계이며 이 글에서 권한 차단을 구현하거나 시험한 결과는 아닙니다.
규칙을 고칠 때는 충돌한 문장과 기준 파일을 함께 기록하고 한 번에 한 경계씩 변경합니다. 말투를 고치는 일과 외부 실행 권한을 바꾸는 일은 별도로 검토해야 원인을 추적할 수 있습니다.
사례 기준일: 2026-04-01. 2026-09-03 재구성, 2026-09-10 승인 경계 보완. 특정 지침 파일의 자동 로드와 최신 권한 기능은 재검증하지 않았습니다.
편집: 2026-09-13. 기존 기록의 구조를 정리한 것으로 새 실행·성능 시험이나 현재 서비스 상태 확인을 뜻하지 않습니다.