# GLM spawn vs 순차작업 비교

> 발견일: 2026-03-01
> 검증: task-34.2 (3팀 라)
> 보고서: `/home/jay/workspace/memory/reports/task-34.2.md`

## 결론
OpenClaw의 `sessions_spawn`은 **이름과 달리 순차 실행**된다 (병렬 아님).
GLM-5 단독 순차 작업이 spawn보다 **더 효율적**이다. spawn 기능 사용을 중단하고 순차작업으로 전환.

## 검증 과정

### sessions_spawn 테스트
- 3팀 라 팀장이 OpenClaw `--agent main`에 작업 지시
- GLM-5 메인 에이전트가 `sessions_spawn`으로 3명 팀원 세션 생성:
  - 아누비스(백엔드), 이시스(프론트엔드), 호루스(테스터)
- 각 팀원 세션에 작업 배분 → `.done` 파일 생성으로 완료 감지

### 실측 결과
- **3명 모두 순차적으로 실행됨** (동시 병렬 아님)
- OpenClaw daily 로그에 3개 세션이 시간 순서대로 기록
- spawn 호출 후 각 세션이 하나씩 순서대로 완료
- `.done` 파일: `anubis.done`, `horus.done` 등 순차적으로 생성

### 원인 분석
- OpenClaw의 sessions_spawn은 세션을 **생성**하는 것이지 **병렬 실행**하는 것이 아닌 것으로 추정
- Z.AI 플랜 제약 또는 Gateway 내부 큐잉 메커니즘에 의한 순차 처리 가능성
- 공식 문서에 병렬 보장 여부 명시 없음

## spawn의 오버헤드
- 세션 생성/관리 오버헤드 발생
- 각 spawn 세션마다 시스템 프롬프트(AGENTS.md 등 ~40K tokens) 재로딩
- 결과 취합을 위한 추가 통신 필요
- **순차 실행인데 오버헤드만 추가** → 비효율

## 결정: 순차 단독 작업으로 전환

### 변경 전 (spawn)
```
라 팀장 → openclaw agent → GLM-5 메인
  → sessions_spawn → 아누비스(백엔드)
  → sessions_spawn → 이시스(프론트)
  → sessions_spawn → 호루스(테스터)
  → 완료 대기 → 결과 취합
```

### 변경 후 (순차 단독)
```
라 팀장 → openclaw agent → GLM-5 메인
  → 직접 순차 작업 (백엔드→프론트→테스트)
  → .done 파일 생성
라 팀장 → 결과 검토 → 보고
```

### 반영 파일
- `prompts/team_prompts.py` → `_build_glm_prompt()` 에서 spawn 지시 제거
- glm_message에 "spawn 기능 사용하지 말고 직접 순차적으로 작업을 수행하세요" 명시

## 향후 재검토 조건
- Z.AI 플랜 업그레이드로 진정한 병렬 실행 가능 시
- OpenClaw 버전 업데이트로 spawn 병렬 처리 지원 확인 시
- 대규모 독립 모듈 작업(10+ 파일)에서 spawn 병렬 효과 측정 가능 시