2.1 KiB
2.1 KiB
에이전트 세션 ID 중복 충돌 분석 보고서
본 보고서는 multi-agent-mux 오케스트레이션 환경에서 동일 언어 모델 계열(Claude 및 Cline)의 서로 다른 역할 에이전트들이 동일한 세션 ID를 공유하게 된 문제를 정의하고, 이에 대한 실질적인 해결 방법을 제안합니다.
1. Problem Definition (문제 정의)
1.1 현상
- 현재 프로젝트 세션 데이터베이스(
.mam/agent-sessions.yaml)를 확인한 결과, 역할이 다른 에이전트들이 동일한 고유 세션 ID를 공유하고 있습니다:- Claude 계열:
planner와reviewer-a가 동일한 대화 ID (7ef1095f-4533-44be-ba9a-07260328f5ff)를 공유 - Cline 계열:
developer와reviewer-b가 동일한 대화 ID (1783574535923_z770y)를 공유
- Claude 계열:
1.2 원인
- 세션 정보 공유 방식의 한계: Claude Code 및 Cline CLI는 동일 프로젝트 디렉터리 내에서 실행될 때 기본적으로 가장 최근에 생성되었거나 활성화된 로컬 세션 ID(캐시 파일)를 상속 및 공유하도록 설계되어 있습니다.
- 동시 구동 시의 경쟁 상태 (Race Condition): 최초 온보딩 시 스크립트가 여러 에이전트를 거의 동시에(
tmux new-session병렬 실행) 띄우는 과정에서, 각 세션이 독자적인 신규 UUID를 발급받지 못하고 로컬의 마지막 활성 세션 정보로 진입점이 묶여버렸습니다.
1.3 영향 및 부작용
- 컨텍스트 오염 (Context Contamination): 기획자(Planner)가 지시 수행 중 출력한 생각과 로그가 리뷰어(Reviewer A)의 화면에도 실시간으로 노출되는 등 역할 격리가 무너집니다.
- 락 충돌 (Lock Conflict): 동일한 대화 히스토리 파일(
*.jsonl또는*.db)에 두 에이전트 프로세스가 동시에 쓰기(Write) 작업을 시도하면서 데이터 유실 및 동작 지연이 발생합니다. - 검증의 객관성 상실: 리뷰어가 본래의 독립적 검수 목적을 잃고, 개발/기획 세션의 편향된 맥락을 공유하게 됩니다.