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