핵심 판단
OpenClaw 기능을 백과처럼 나열하지 않고, 오늘 맡길 일과 열면 안 되는 권한을 먼저 가르는 실전 지도.
- 아래 목차에서 필요한 절차만 골라 읽으면 됩니다.
OpenClaw 소개가 「할 수 있는 일」 나열로 끝나면, 독자는 권한을 전부 연 뒤에야 위험을 만납니다. 필요한 질문은 기능 목록이 아니라 오늘은 어디까지만 열지입니다.
역량 지도를 외우게 하지 않습니다. 관측 없이 열면 안 되는 경계와, 산출물 품질을 재는 방법을 남깁니다. 데모에서 잘 된 권한 세트를 프로덕션에 복사하지 마세요. 데모는 사람 옆에서 돌아가고, 프로덕션은 밤새 돌아갈 수 있습니다.
공식 문서의 기능 표를 인쇄해 체크하는 대신, 허용 세 문장과 금지 세 항목만 먼저 채우세요. 그다음 문서에서 오늘 허용과 겹치는 기능만 켭니다. 겹치지 않는 기능은 보류 목록으로 미룹니다.
보류 목록이 계속 늘어나면 호기심이 아니라 범위 붕괴 신호입니다. 끄지 못한 통합이 있으면 새로 열지 마세요. 요약이 틀렸다고 쓰기 권한을 주는 순간, 범위 문장은 장식이 됩니다.
외부 채널을 열 때는 채널 텍스트에 시크릿이 없는지 템플릿으로 검사하세요. 채널은 편리하지만 백업과 미리보기라는 두 번째 저장소입니다. 도구를 더 사기 전에 되돌림 비율부터 보세요.
OpenClaw가 맡기 쉬운 일
읽기/요약, 알림, 승인 요청, 제한된 경로의 초안 작성처럼 실패해도 저장소가 안 바뀌는 일부터입니다. 결제, 삭제, 프로덕션 배포, 고객 PII가 섞인 작업은 첫 범위에서 빼세요.
권한을 열기 전에 적을 세 문장
- 어떤 디렉터리를 읽을 수 있는가
- 어떤 명령을 실행할 수 있는가
- 외부로 무엇을 보낼 수 있는가
세 문장이 비어 있으면 데모 성공이 곧바로 권한 확장으로 이어집니다.
💡 Tip: 새 통합을 켤 때는 「무엇을 할 수 있는가」보다 실패 시 어떤 권한이 남는지를 한 줄로 적으세요.
관측이 없으면 운영이 아니다
최소 관측은 실패율, 지연, 비용, 인증 실패 알림입니다. 성공 로그만 보이면 감시가 죽은 줄 모릅니다. 주 1회 의도적 실패를 넣어 알림이 오는지 확인하세요.
⚠️ 주의: 관측 없이 쓰기와 외부 채널을 같이 열지 마세요. 사고 원인을 찾기 전에 변경이 퍼집니다.
범위 문장 예시
오늘 이 에이전트는 {경로}를 읽고, {명령 집합}만 실행하며, {채널}로는 승인 요청만 보낸다. 금지: {삭제/결제/프로덕션 배포}.
템플릿을 채운 뒤에만 새 MCP/통합을 추가합니다. 추가할 때마다 금지 목록도 같이 갱신하세요.
단계적으로 여는 순서
- 읽기 전용과 요약만 허용
- 로그/알림이 실제로 오는지 확인
- 제한된 경로에만 쓰기 개방
- 외부 채널은 중단 경로가 준비된 뒤 연결
한 번에 여러 통합을 켜면 어떤 변경이 사고를 냈는지 모릅니다.
산출물 품질을 재는 법
사람이 되돌린 변경 비율, 동일 과제 재실행 시 결과 변동, 도구 호출 형식 오류 횟수, 예산 대비 유용한 완료 작업 수를 봅니다. 「체감으로 좋다」는 교체 근거가 아닙니다.
오늘 확인하면 충분한 상태
범위 문장이 팀 채널에 있고, 실험 키 hard limit이 걸려 있으며, 의도적 실패 알림이 한 번이라도 왔고, 금지 목록에 삭제/결제가 명시돼 있으면 첫날의 최소치는 닫힌 것입니다.
기능 목록을 읽기 전에 할 일
공식 문서의 기능 표를 인쇄해 체크하지 마세요. 오늘은 허용 세 문장과 금지 세 항목만 채웁니다. 그다음 문서에서 오늘 허용과 겹치는 기능만 켭니다. 겹치지 않는 기능은 「다음에」목록으로 미룹니다. 다음 목록이 열 개를 넘으면 이미 범위가 thrashing 중입니다. thrashing이면 모델이 아니라 범위가 문제입니다.
읽기 작업으로 시작했는데 쓰기로 번지는 전형적인 경로는 「요약이 틀려서 파일을 고치게 시킴」입니다. 요약이 틀리면 입력을 보강하거나 사람이 고칩니다. 틀렸다고 쓰기 권한을 주는 순간, 범위 문장은 장식이 됩니다.
외부 채널을 열 때는 채널에 남는 텍스트에 시크릿과 고객 로그가 없는지 템플릿으로 검사하세요. 채널은 편리하지만 백업과 미리보기라는 두 번째 저장소입니다. 관측 알림도 채널로 보낼 때 본문을 짧게 유지합니다.
산출물 품질 지표가 나빠지면 통합을 더 사지 마세요. 되돌림 비율이 높을 때는 입력 패킷(로그, 재현 단계, 관련 파일)을 먼저 고칩니다. 통합을 늘리면 실패 지점이 늘어날 뿐입니다.
보류 목록을 닫는 규칙
다음에 켤 기능이 세 개를 넘으면 이번 주 허용 문장을 다시 씁니다. 목록이 늘어나는 것은 호기심이 아니라 범위 붕괴 신호입니다. 끄지 못한 통합이 있으면 새로 열지 않습니다.
오늘 열지 않을 것을 먼저 고른다
기능을 고르기 전에 금지부터 고르면 범위가 단순해집니다. 삭제, 결제, 프로덕션 배포, 고객 PII가 섞인 메일 발송은 첫 주에 넣지 않습니다. 금지 목록이 없으면 허용 목록은 금방 팽창합니다.
실무에서 자주 실패하는 패턴은 「요약만」이라고 열어 두고, 요약이 틀릴 때마다 쓰기를 잠깐씩 허용하는 것입니다. 잠깐이 모여 상시 쓰기가 됩니다. 요약 품질이 안 나오면 입력을 보강하고, 그래도 안 되면 사람이 고칩니다. 권한으로 품질을 사지 마세요.
MCP나 외부 도구를 추가할 때는 도구가 반환하는 텍스트가 어디에 저장되는지 확인합니다. 메모리/스킬/채널에 자동 저장되면 시크릿 검사 규칙을 같이 넣어야 합니다. 도구 추가와 저장 정책을 분리해 두면 나중에 끄기 쉽습니다.
출처와 링크
조사 기준: 2026년 7월. 통합 이름보다 허용/금지 문장을 먼저 고정하세요.
FAQ
자주 묻는 질문
모든 기능을 첫날에 켜도 되나요?
권하지 않습니다. 읽기 전용과 관측부터 열고, 쓰기와 외부 채널은 산출물이 안정된 뒤에 추가하세요.
관측 도구가 없어도 운영할 수 있나요?
짧은 로컬 실험은 가능합니다. 무인/원격/쓰기가 붙으면 실패율과 비용 알림 없이 운영하지 마세요.
범위 문장은 어디에 두나요?
팀 채널 고정 메시지나 런북 상단이면 됩니다. 허용 경로/명령과 금지(삭제/결제/배포)를 같은 블록에 적으세요.
품질이 들쭉날쭉하면 모델을 올리나요?
먼저 입력(로그, 재현 단계, 관련 파일)이 부족한지 보세요. 입력이 빈약한 채 모델만 올리면 비용만 늘 수 있습니다.
새 통합을 켤 때 무엇을 적나요?
실패 시 어떤 권한이 남는지 한 줄과, 끄려면 어디를 닫는지 한 줄을 적습니다. 기능 소개만 남기지 마세요.
이 글에서 다루지 않는 것은?
버전별 전체 메뉴 나열과 버튼 클릭 순서입니다. 오늘은 어디까지만 열지와 품질을 재는 방법만 다룹니다.