한국어 | English

Peer 세션 구조

왜 Peer인가

AGS에서 여러 세션을 사용하는 이유는 단순히 병렬 처리량을 늘리기 위해서만이 아닙니다.

각 세션은 다음을 독립적으로 가질 수 있습니다.

• 기존 대화 문맥
• 담당 범위
• 작업 디렉터리
• 사용 모델과 실행 설정
• 조사와 판단의 누적 결과
• 별도의 검증 책임

이 독립성을 유지한 채 서로 필요한 정보만 전달하는 구조가 Peer 협업입니다.

예시 조직

                  ┌──────────────┐
                  │  Lead / 총괄 │
                  └──────┬───────┘
                         │
             ┌───────────┴───────────┐
             ▼                       ▼
      ┌──────────────┐       ┌──────────────┐
      │ 구현 담당     │◀─────▶│ DB / 조사 담당│
      │ Codex         │       │ Claude Code  │
      └──────┬───────┘       └──────────────┘
             │
             ▼
      ┌──────────────┐
      │ 독립 감사     │
      │ separate ctx │
      └──────────────┘

DB 담당이 API 구현에 영향을 주는 조건을 발견하면 구현 담당에게 직접 보낼 수 있습니다. 구현 담당은 자신의 기존 코드 문맥에서 판단합니다. 감사 담당은 구현자의 사고 흐름을 그대로 이어받는 대신 결과와 근거를 별도의 문맥에서 다시 확인할 수 있습니다.

Session Board

Peer를 찾기 위한 기본 수단입니다.

현황판에는 대략 다음 정보가 유지됩니다.

• host
• session ID
• 작업 디렉터리
• 현재 업무 한 줄 요약
• 갱신 시각

현황판은 실시간 메시징 채널이 아닙니다. 상대를 찾은 뒤 실제 협업 내용은 PEER 메시지로 보냅니다.

직접 통신

Peer 메시지에는 다음과 같은 내용을 보낼 수 있습니다.

• 질문
• 발견한 조건
• 산출물 위치
• 검증 근거
• 감사 요청
• 차단 사유
• 작업 결과

총괄을 모든 메시지의 강제 중계점으로 만들 필요가 없습니다.

필요한 두 담당자가 직접 통신하고, 총괄은 목표와 전체 상태를 관리할 수 있습니다.

역할 분리

Peer 구조는 역할의 의미를 선명하게 만드는 데 유리합니다.

예:

역할	책임
총괄	목표·범위·우선순위·최종 상태
구현	코드 변경과 직접 검증
조사	외부 조건·문서·데이터 확인
감사	구현과 독립된 검토
복구 담당	실패 원인에 따른 새 접근

같은 세션이 모든 역할을 수행할 수도 있지만, 위험하거나 복잡한 작업에서는 분리된 세션이 독립 검증의 가치를 높입니다.

Subagent도 함께 사용할 수 있다

Peer 구조가 subagent 사용을 배제하는 것은 아닙니다.

하나의 Peer 세션이 내부적으로 subagent를 사용해 자신의 담당 업무를 병렬화할 수 있습니다.

즉 다음 두 계층은 공존할 수 있습니다.

Peer Session A
 ├── subagent 1
 └── subagent 2

Peer Session B
 ├── subagent 1
 └── subagent 2

AGS의 관심사는 이 상위 세션들이 서로 어떤 책임과 근거를 가지고 협업하는가에 있습니다.