이 글의 목차

OpenClaw를 홈서버에 설치한다면 CPU 사양보다 먼저 AI 개인비서의 권한 범위를 정하세요. 메신저에서 요청을 받고 파일·도구·브라우저를 사용하는 구조는 편리하지만, 대화할 수 있는 사람과 실제 작업을 실행할 수 있는 사람이 같은 범위인지 확인해야 합니다.

현재 OpenClaw 공식 보안 문서는 Gateway 하나를 신뢰 경계 하나로 설명합니다. 서로 적대적이거나 신뢰하지 않는 사용자를 같은 Gateway에 넣는 강한 다중 사용자 보안 경계로 보지 않으며, 필요하면 Gateway·자격 증명·OS 사용자나 호스트를 분리하도록 안내합니다. OpenClaw 신뢰 모델

챗봇과 개인 에이전트의 차이

답변만 하는 챗봇과 실제 파일이나 외부 계정을 변경하는 에이전트는 사고 범위가 다릅니다. ‘파일 정리해줘’라는 같은 문장도 추천 목록을 만드는지, 파일을 이동하는지, 영구 삭제하는지에 따라 필요한 통제가 달라집니다.

기능첫 실험에 적합한 범위확대 전 확인
문서 요약테스트 폴더 읽기개인정보·출처·외부 전송
파일 정리이동 계획 생성쓰기·삭제 권한, 백업
일정 관리별도 테스트 일정 조회초대·수정·취소 동작
메신저 응답내 계정의 테스트 대화외부 발송 대상과 확인
셸 실행좁은 테스트 작업실행 명령·파일·네트워크 범위

이 표는 OpenClaw의 기본 설정을 나타내는 것이 아닙니다. 내가 원하는 작업과 권한을 적기 위한 운영 계획입니다. 실제 설정 항목은 설치 버전의 공식 문서와 대조하세요.

1. 테스트 사용자와 데이터를 분리

처음부터 NAS 사진 전체, 개인 메일, 회사 저장소를 연결하면 어떤 자료가 읽히거나 바뀌었는지 파악하기 어렵습니다. 별도 작업 계정과 작은 테스트 폴더를 준비하고, 되돌릴 수 있는 데이터로 시작하세요.

컨테이너를 쓰더라도 호스트의 홈 디렉터리 전체나 Docker 소켓을 연결하면 권한이 크게 확대될 수 있습니다. Docker 홈서버 입문을 참고하되, 컨테이너라는 이름만으로 앱이 읽고 변경할 수 있는 범위가 좁다고 가정하지 마세요.

2. 누가 요청할 수 있는지 정하기

본인만 사용하는 개인비서인지, 가족이나 팀이 함께 쓰는지에 따라 대화 채널과 권한을 검토해야 합니다. 그룹 대화에 참여할 수 있는 사람, 직접 메시지를 보낼 수 있는 사람, 도구 실행이 허용되는 사람이 어떻게 연결되는지 확인하세요.

사용자 A의 대화에 나온 문서가 B에게도 보이면 안 되는 환경은 단순한 대화방 구분만으로 충분하지 않을 수 있습니다. 원본 파일, 계정, 토큰, 저장되는 대화 기록까지 경계를 정해야 합니다. 권한이 다른 사람들을 한 Gateway에서 운영하려면 공식 신뢰 모델의 범위와 실제 요구가 맞는지 먼저 보세요.

3. Gateway를 인터넷에 공개하기 전 점검

관리 화면과 일반 공개 웹사이트는 목적이 다릅니다. 먼저 로컬에서 동작을 확인하고, 원격 관리가 필요하면 허용된 사용자만 접근할 경로를 검토하세요. Tailscale 홈서버 접속처럼 개인용 경로를 사용할 수도 있습니다.

리버스 프록시를 붙였다는 사실만으로 인증이 완성되지는 않습니다. 원본 Gateway에 직접 접근할 수 있는지, 프록시가 전달한 사용자 정보와 원본의 인증이 맞는지 확인해야 합니다. 현재 공식 권장 구성은 OpenClaw hardened baseline을 참고하세요.

4. 설치한 뒤 읽기 전용 감사 실행

공식 문서는 다음 감사 명령을 안내합니다. 현재 설치 버전이 지원하는 옵션은 도움말과 보안 CLI 문서로 확인하세요.

Terminal window
openclaw security audit

감사는 설정과 노출을 점검하는 출발점입니다. 경고가 없다고 연결한 모든 도구·플러그인·호스트가 안전하다는 뜻은 아닙니다. 자동 수정 옵션은 어떤 설정을 바꾸는지 확인한 뒤 별도로 사용해야 합니다. OpenClaw Security CLI

결과를 공개 게시판에 공유한다면 토큰, 사용자 식별자, 민감한 경로를 제거하세요. 먼저 자신의 실제 파일 접근·메신저 발송·브라우저 세션 범위와 감사 항목을 대조하는 편이 유용합니다.

5. 외부 문서는 사용자 명령이 아닙니다

개인비서가 읽는 웹페이지·메시지·문서는 외부 입력입니다. 그 안의 문장이 도구 실행이나 데이터 전송을 요구하더라도 원래 사용자의 허가를 확대하는 근거가 되어서는 안 됩니다.

예를 들어 문서 요약을 요청했는데 원문에 다른 폴더를 압축해 전송하라는 내용이 있다면, 요약 대상의 문장일 뿐 새 작업 요청으로 취급하면 안 됩니다. 중요한 변경은 작업 대상과 결과를 사용자가 확인할 수 있도록 구성하고, 서버·도구의 실제 권한도 제한하세요. ‘프롬프트에 조심하라고 적었다’와 ‘실제로 읽을 수 없는 파일’은 다른 보호 수준입니다.

로컬 모델이면 자료가 모두 로컬에 남나요?

모델 실행 위치와 도구의 외부 연결은 별개입니다. 로컬 모델을 사용해도 메신저, 검색, 원격 저장소, 외부 API로 자료가 나갈 수 있습니다. Ollama GGUF와 로컬·클라우드 구분을 함께 읽고 실행 경로를 도식화해보세요.

처음 도입할 때는 필요한 한 가지 작업만 허용하고, 모델·도구·계정·데이터 저장 위치를 목록으로 적는 것이 좋습니다. 최신 모델을 쓰는 것보다 실제로 연결한 경로를 아는 것이 운영에 도움이 됩니다.

권한을 늘리기 전 복구 시험

  1. 테스트 파일을 이동·수정한 후 원래 상태로 복원합니다.
  2. 허용하지 않은 사용자가 도구를 실행하지 못하는지 확인합니다.
  3. 외부 발송 작업의 대상과 내용을 검토할 수 있는지 확인합니다.
  4. 로그에 무엇이 남는지, 누가 읽을 수 있는지 확인합니다.
  5. Gateway를 멈췄을 때 진행 중 작업과 예약 작업 상태를 확인합니다.

좋은 데모 한 번과 지속적인 개인비서 운영은 다릅니다. 실패·취소·재시작 상황에서 어디까지 실행됐는지 확인할 수 있어야 권한을 확대할 근거가 생깁니다.

자주 묻는 질문

Docker로 설치하면 모든 위험이 격리되나요?

연결한 볼륨·소켓·계정·네트워크 권한에 따라 범위가 달라집니다. 격리 여부는 실제 설정으로 확인해야 합니다.

가족이 함께 쓰면 대화방만 나누면 되나요?

필요한 신뢰 경계에 따라 달라집니다. 공유 Gateway와 자격 증명으로 서로의 자료를 분리할 수 있는지 검토하고, 요구가 맞지 않으면 운영 경계를 나누세요.

security audit를 통과하면 바로 전체 파일 권한을 줘도 되나요?

감사 결과는 권한 확대의 자동 승인서가 아닙니다. 필요한 도구만 연결하고 실제 접근·변경·복원 시험을 거쳐 범위를 늘리세요.

참고 자료

2026년 10월 8일 확인. 설정과 지원 기능은 빠르게 바뀔 수 있으므로 설치 버전의 공식 문서와 실제 도구 권한을 대조하세요.

← 전체 글로 돌아가기