1. 문제 분해: 서브세션은 채팅을 늘리는 것이 아니다
(1) 신분·권한: 컨테이너 UID/GID와 호스트에서 편집한 설정 소유자가 다르면 자식 프로세스가 openclaw.json을 열지 못해 EACCES가 납니다. Gateway는 떠 있는데 spawn만 연속 실패하는 형태입니다. (2) 도구 계약: minimal·messaging 프로필은 runtime·filesystem 도구를 의도적으로 뺍니다. Telegram 등에서「Tool not found」가 나와도 곧바로 모델 탓만 하지 마세요. (3) thinking·무응답: 하트비트·크론이 띄우는 자식 에이전트에 thinking을 켜 두면, 모델에 따라 사용자용 텍스트가 reasoning에 남고 announce에는 빈 문자열만 올 수 있습니다. (4) fallback 고착: 주 모델이 잠깐 실패한 뒤 fallback이 설정에 쓰이고, 복구 후에도 예비 모델만 고정되는 경우가 있습니다. 수동 롤백과 세션 스냅샷 정리가 필요합니다.
2. 증상 매트릭스
| 징후 | 우선 의심 | 최소 확인 |
|---|---|---|
| spawn 로그 EACCES | 파일 소유·권한 | 컨테이너 UID, 마운트 읽기 전용 |
| 도구 비활성·오류 | tools.profile 과소 | coding/full로 임시 전환해 재현 소멸 여부 |
| 크론 성공인데 채널 무음 | thinking·빈 announce | 해당 잡에서 thinking off, announce 길이 |
| 주 모델이 예비에 고정 | 설정에 fallback 기록 | openclaw.json 백업·diff |
3. 다섯 단계: 재현에서 운영으로
1단계: 동일 채널·라우팅·모델로 재현 경로를 고정합니다. 2단계: spawn 진입점에서 실제 uid/gid와 설정 실경로를 로그합니다. 3단계: 필요한 도구 그룹을 명시적 체크리스트로 만듭니다. 4단계: 예약 작업용 설정 조각을 분리합니다(thinking off, 출력 상한, announce 템플릿). 5단계: 원격 Mac·Docker에서 Gateway 재시작 후 첫 spawn을 검증합니다.
운영 전환 시에는「전부 full 프로필로 때우기」를 피해야 합니다. 일시적으로 full을 켜 재현이 사라지는지 본 뒤, 필요한 최소 도구 집합만 남기고 보안 면을 다시 좁힙니다. 팀 내에 동일한 docker-compose·launchd plist·볼륨 마운트 절차를 문서로 고정하면, 신입이 와도 spawn 실패 원인을 같은 순서로 좁힐 수 있습니다.
4. 점검 항목
- 설정 디렉터리 마운트 시 프로세스 사용자와 소유자 일치 또는 entrypoint에서
chown. - 무인 작업은 thinking off, 전후 로그로 빈 출력률 비교.
- 페일오버 테스트 전 마지막으로 안정적이었던
openclaw.json사본 보관.
5. 원격 Mac으로 옮길 시점
| 신호 | 제안 |
|---|---|
| 무거운 그래픽·다중 spawn을 한 노트에 | 게이트웨이·추론 분리 |
| 고정 공개 엔드포인트 24/7 | 전용 노드·모니터링 |
| 팀 공유 Gateway·스킬 | 쿼터·감사용 별도 기기 |
6. FAQ
Q: MCP와 충돌? 스키마 토큰 합이 커집니다. 다중 서브에이전트 시 Gateway 리로드 순서도 확인하세요. Q: 로컬만 됨? 경로·권한·환경 변수 차이가 대부분입니다. Q: full 프로필 상시? 진단용만, 배포는 최소 도구면.
MCP 스킬과 sessions_spawn을 함께 쓸 때는 Gateway 재시작 후 스킬 디렉터리 스냅샷이 갱신되는지, 자식 세션에 동일한 PATH가 전달되는지까지 확인하세요. 호스트에만 있는 바이너리를 자식이 호출하면 로컬 대화에서는 되고 spawn에서는 실패하는 차이가 납니다. 이런 경우 로그에 ENOENT가 남는지 함께 보세요.
디버깅 시 ① spawn 종료 코드·지연, ② 대화 vs 자식 세션 도구 차이, ③ announce 문자열 길이를 함께 기록하세요. ③이 항상 0인데 ①이 성공이면 thinking·템플릿을 의심합니다. spawn·권한 수동 개입이 주당 3회를 넘으면 프롬프트보다 환경 고정(entrypoint, launchd, 전용 노드)을 먼저 검토합니다.
7. 분석: 서브에이전트는 운영 문제다
단일 세션 데모와 달리 spawn·라우터·다채널을 쓰면 실패는「모델 환각」에서「프로세스 권한·도구 미로드·출력 미전달」로 바뀝니다. 자식 프로세스가 늘어날수록 명시적 계약이 필요하고, 이는 마이크로서비스의 설정 드리프트와 같은 패턴입니다. 팀이 개인 노트북에서만 디버깅하면「내 환경에서는 된다」를 제품 상태로 착각하기 쉽습니다.
노트북 단독 운용은 한계가 있습니다. 덮개를 닫으면 장시간 게이트웨이가 끊기고, 사용자마다 경로가 달라지며, 그래픽 작업과 추론이 통합 메모리를 나눠 씁니다. 모델만 바꿔서는 해결되지 않습니다. Apple Silicon 원격 Mac은 Metal·장시간 백그라운드에 맞고, 시간제 요금으로 spawn 토폴로지를 검증한 뒤 고정 장비를 살지 결정할 수 있습니다. 무거운 Gateway·spawn을 일상 창작 기기에서 떼어내고, 감사 가능·재시작 가능한 환경을 원한다면 MACGPU 원격 Mac 임대는 무한 chown과 프롬프트 수정보다 총소유비용에서 유리한 경우가 많습니다.