시나리오와 전제: 왜 데몬을 독일 노드에 두나요?
OpenClaw는 daemon 상주가 일반적이고, leanvps 독일 노드는 전용 물리 Mac에 가깝습니다. EU 처리 요구가 있으면 프랑크푸르트가 엔지니어링 기본 착지가 되기 쉬우나, 리전만으로 컴플라이언스가 성립한다는 뜻은 아닙니다(DPA·하위 처리자·DPIA 등 병행).
관련: 독일 노드 Git p95 매트릭스, Mac mini M4 임대 경험 · 콘솔 · 도움말
설치와 데몬 기준선(원격 Mac)
콘솔에서 독일 인스턴스를 받았고, 서비스는 관리자가 아닌 전용 계정으로 실행한다고 가정합니다.
- 승인된 경로로 설치·버전을 변경 기록에 남김.
- 비밀키·토큰은 키체인 또는
0600설정 디렉터리, 셸 히스토리 제외. - LaunchDaemon / LaunchAgent 등록, 크래시 백오프·부팅 자동 기동.
- stdout/stderr는 로테이션 디버그 로그, 감사 로그와 분리.
- 요금제에서 메모리 확인 — 다중 스택이면 24GB 검토.
유럽 본토 아웃바운드: 도메인 화이트리스트는 어떻게 적용하나요?
「유럽 본토 아웃바운드」는 독일 인스턴스의 외부 발신 연결입니다. 목적지를 열거하고, 네트워크 기본 거부 후 앱 계층에서 OpenClaw·플러그인으로 한 번 더 조입니다.
- 네트워크: Git·레지스트리·모델 API 등 명시 호스트만 허용, 신규 도메인은 티켓.
- 앱: HTTP 프록시·아웃바운드 플러그인과 방화벽 목록을 단일 YAML로 맞춰 이중 직연결 방지.
- 관측: 거부는 카운트만(URL 쿼리 미기록).
독일 리전 안내는 독일 구매 가이드, 다른 글은 블로그 목록을 참고하세요.
감사 로그: 「데이터 최소화」에 맞춘 실행 가능한 관행(법적 단정 아님)
GDPR 맥락의 데이터 최소화는 통상 필요한 개인정보만 처리한다는 취지입니다. 아래는 운영에 옮긴 엔지니어링 관행이며 특정 조문 충족을 보장하지 않습니다(법무와 정렬).
- 프롬프트·응답 전문 비저장 기본: 길이·해시·태그로 대체, 분석 시만 짧게 샘플링 후 만료.
- 구조화 감사: 시각, request id, 도구명, 허용 호스트, 상태코드, 지연 버킷 — stderr 전문은 감사 테이블에 넣지 않음.
- TTL·삭제 런북: prod/staging 구분, 백업 정리 포함.
- 보내기 2차 승인을 티켓과 연계.
컴플라이언스 관점 점검 목록(인쇄용)
- 인스턴스 리전 = 계약 「하위 처리자·리전」.
- daemon 전용 비루트, 권한·umask 재점검.
- 화이트리스트·방화벽 동일 버전으로 변경 저장소 반영.
- 감사 테이블 기본 전문 컬럼 없음, 민감 컬럼 잘림·가명 근거.
- TTL·자동 삭제·백업 정리가 운영 캘린더에 있음.
- 차단 훈련 기록(시각·담당).
- 온콜에 도움말 링크.
- 신규 모델 공급자 등 DPIA/TIA 재검토 시점을 법무와 합의.
자주 묻는 질문(FAQ)
그렇습니다. npm/PyPI/Git/모델 API 호스트를 미리 넣고 신규는 티켓·스테이징 검증. 거부는 알람, 재시도 폭주 방지.
request id·도구 경계·지연·오류 분류로 대부분 충분합니다. 재현 시에만 짧게 샘플 업, 티켓 종료 후 기준선 복귀.
아닙니다. 리전은 토폴로지의 한 부분이고, 계약·기술·조직 통제가 함께합니다. 본문은 운영 관행이지 결론이 아닙니다.
설정 diff·신규 아웃바운드 확인 → 카나리 → 전면. 업그레이드 후 화이트리스트·로그 스키마 기본값 덮임 여부 재점검.