🛠️ Multi-Agent Mux Loop (`/multi-agent-mux-loop`) 미해결 최적화 분석서 (`OPTIMIZATION.md`)

본 문서는 /multi-agent-mux-loop 스킬 및 오케스트레이션 스크립트(run_loop.sh)의 향후 개선 및 강제를 위해 아직 반영되지 않고 남아있는 미해결 최적화 항목들을 정리한 문서입니다. (해결 완료된 이슈 1~5 및 8은 제거되었습니다.)

1. ⚠️ 미구현 절차 및 프로토콜 (Remaining Discrepancies)

현상: MULTI_AGENT_RULES.md 1장 규약에는 "개발 팀장이 리뷰어의 타당하지 않은 피드백을 거부하고 명확한 이유를 회신할 수 있다"고 명시되어 있음.
문제점: run_loop.sh는 리뷰어의 NOT PASS 피드백 전체를 Creator에게 일방적으로 주입할 뿐, Creator가 특정 피드백을 거부하거나 반론을 제기하여 상호 조율하는 이의제기 채널이 코딩적으로 구현되어 있지 않음.
해결 방안: Creator 교정 단계 프롬프트에 반론 작성 템플릿을 허용하고, 반론 발생 시 Planner/Reviewer에게 재검토를 요청하는 이의제기 브랜칭 로직 설계.

현상: 동일 작업 트리에서 다수의 run_loop.sh 스크립트가 병렬 기동될 경우 SQLite DB 갱신 경합 및 YAML 데이터 오염이 일어날 수 있음.
문제점: 단순 PID 파일 존재 여부만 체크할 경우, PID Rollover(프로세스 ID 재사용) 또는 mkdir과 PID 기록 사이의 생성 창(Grace Window)에서 살아있는 락을 타 프로세스가 훔쳐가는 "락 도난(Live-lock theft)" 현상 발생.
해결 방안:
1. 락 소유자 레코드를 단순 PID에서 PID + 시작시각(lstart) + 워크스페이스 3중 구조로 결합하여 PID 재사용을 결정적으로 차단.
2. mkdir 직후 생성 창 유예 대기(Sleep Grace Period)를 부여하여 락 도난 방지.
3. ps CLI 부재 시 Fails-Open(락 무시) 대신 Fails-Safe(락 존중 + 경고) 로 전환하여 DB/YAML 오염 원천 방지.

현상: 오케스트레이터(Antigravity)가 평상시에는 Main Creator로서 코드 및 문서를 직접 집필해야 하지만, /multi-agent-mux-loop 슬래시 커맨드/스킬이 인보크된 상황에서도 이를 인지하지 못하고 에이전트들에게 위임하는 대신 직접 수정을 시도하는 지침 이탈 발생.
문제점: 오케스트레이터의 파일 직접 수정 권한을 무조건 뺏으면(1번 방안 부작용) 일반 작업이 불가능해지고, 자연어 지침에만 의존하면 슬래시 커맨드 호출 시 위임을 건너뛰는 모순 발생.
해결 방안:
- 평상시 (일반 요청): 오케스트레이터가 Main Creator로서 소스 및 마크다운 파일 직접 작성/수정 도구(write_to_file, replace_file_content)를 자유롭게 사용하여 단독 구현 수행.
- /multi-agent-mux-loop 호출 시 (스킬 활성화 상태): 스킬 인터셉터 가드(Guardrail)가 작동하여 직접 수정 도구 호출을 거부(Interception)하고, **"슬래시 커맨드가 인보크되었으므로 직접 수정을 중단하고 run_loop.sh를 실행하여 위임하십시오"**라는 에러를 반환해 run_loop.sh 자율 위임 실행을 코딩적으로 강제.