Slack → Pantheon 컨텍스트 관리 구조

이 문서가 답하는 질문

"Slack → Pantheon을 거쳐 나누는 대화에서 컨텍스트 관리가 어떻게 되는가?"

메시지 흐름 개요

사용자 Slack 메시지
    ↓
Pantheon Socket Mode (bridge.py)
    ↓
페르소나 라우팅 (DM 채널 → 담당 페르소나 결정)
    ↓
Claude Code 세션 (페르소나별 독립 프로세스)
    ↓
도구 호출 (MCP: Linear, Notion, Calendar, Slack 등)
    ↓
Slack 응답

핵심: 각 페르소나는 독립적인 Claude Code 프로세스다. Jarvis DM과 Asurada DM은 서로 다른 세션이고, 내부적으로 컨텍스트를 공유하지 않는다.

세션 연속성 모델

스레드 = 세션

Pantheon은 Slack 스레드 단위로 세션을 유지한다.

스레드 T1에서 Jarvis와 5번 메시지를 주고받음
→ T1의 모든 이전 메시지가 6번째 메시지 시점의 컨텍스트 창에 포함됨

같은 스레드 안에서는 자연스러운 대화 연속성이 있다.

새 스레드 = 새 세션

최상위 DM 메시지는 새 세션을 시작한다. 이전 DM 스레드의 내용은 자동으로 이어지지 않는다.

스레드 T1: 지난주 Jarvis와 HAN-123 설계 논의
스레드 T2: 오늘 Jarvis에게 HAN-123 구현 요청
→ T2의 Jarvis는 T1의 내용을 모른다 (slack_read_thread로 명시적으로 읽지 않는 한)

n:m 관계: 스레드 × 페르소나

스레드(T)와 페르소나(P)는 n:m이다.

케이스 1: 한 스레드에 여러 페르소나

T1: 사용자 → Jarvis (설계 논의)
    사용자 → [Jarvis가 Asurada에게 DELEGATE]
    Asurada → 사용자 (구현 진행)
    사용자 → Raphael (리뷰 요청)

각 페르소나는 T1 스레드의 메시지를 볼 수 있지만, 서로의 세션 컨텍스트는 공유하지 않는다. Raphael이 응답할 때 Asurada가 T1에서 이미 결정한 내용은 T1 슬랙 메시지를 통해서만 알 수 있다.

케이스 2: 여러 스레드에 같은 작업 아이템

T1: Raphael ↔ 사용자  →  아키텍처 결정
T2: Asurada ↔ 사용자  →  구현 (T1 내용 모름)
T3: Nano ↔ 사용자     →  병렬 조사 (T1, T2 내용 모름)

같은 작업(HAN-123)이 세 스레드에 걸쳐 진행되지만, 세 페르소나 사이에 자동 연결은 없다.

케이스 3: 에이전트 간 직접 요청

Asurada → Raphael에게 Slack 메시지로 자문 요청

Raphael이 받는 컨텍스트는 Asurada가 Slack 메시지에 명시적으로 쓴 내용뿐이다. Asurada의 세션 히스토리는 전달되지 않는다.

컨텍스트 레이어별 접근성

레이어	현재 스레드 페르소나	다른 스레드 같은 페르소나	다른 스레드 다른 페르소나
현재 스레드 Slack 메시지	✅ 세션 컨텍스트	❌ 없음	❌ 없음
다른 스레드 Slack 메시지	`slack_read_thread` (URL 알면)	`slack_read_thread`	`slack_read_thread`
Auto Memory (MEMORY.md)	✅ 자동 로드	✅ 자동 로드	✅ 자동 로드
Linear 이슈	`get_issue`	`get_issue`	`get_issue`
Linear 댓글	`get_issue` 포함	`get_issue` 포함	`get_issue` 포함
hangman-docs 문서	`Read` (경로 알면)	`Read` (경로 알면)	`Read` (경로 알면)
다른 페르소나 세션 내부	❌ 불가	❌ 불가	❌ 불가

핵심: 페르소나 세션 내부 컨텍스트는 절대 공유되지 않는다. 외부 저장소(Slack 메시지, Linear, 파일)로 기록된 것만 다른 페르소나가 접근할 수 있다.

실질적 갭

갭 1: 세션 내 중간 추론의 손실

Asurada가 구현 중 여러 설계 옵션을 검토하고 최종 선택했다. 그 추론 과정이 세션 컨텍스트 안에만 있다. 다른 페르소나가 나중에 "왜 이 방식을 선택했나"를 물으면 대답할 수 없다.

완화책: 중요한 판단 근거는 Linear 댓글이나 PR description에 남긴다.

갭 2: 스레드 분산 추적 불가

HAN-123이 T1, T3, T7 세 스레드에 걸쳐 논의됐다. 티켓 댓글에 기록되지 않은 내용은 영구적으로 추적 불가능하다. Slack 검색으로 찾을 수 있지만, "T7에 관련 결정이 있다"는 사실을 아는 에이전트가 없으면 검색 시도 자체가 없다.

완화책: 관련 스레드 URL을 Linear 댓글에 기록한다.

갭 3: 페르소나 교체 시 컨텍스트 절단

T1에서 Jarvis → Asurada 교체가 일어났다. Jarvis의 세션 컨텍스트 (T1에서 Jarvis와 나눈 50개 메시지 분량의 추론) 중 Slack 메시지에 안 쓴 내용은 Asurada가 볼 수 없다. Asurada는 T1의 Slack 메시지(Jarvis가 응답으로 남긴 텍스트)만 본다.

완화책: 위임 시 DELEGATE CONTEXT에 핵심 결정 요약을 명시적으로 포함한다.

무엇이 실제로 유지되는가

영구적으로 유지 (모든 에이전트, 모든 스레드):
- Slack 메시지 텍스트 (스레드에 기록된 것)
- Linear 이슈 본문·댓글·첨부 파일
- hangman-docs 문서
- Auto Memory (MEMORY.md)

세션 종료 시 사라짐:
- 세션 컨텍스트 창 (추론 과정, 중간 결정)
- 도구 호출 결과 캐시

처음부터 공유 불가:
- 다른 페르소나의 세션 내부 상태

권장 패턴

1. Linear 티켓을 공유 앵커로

작업 아이템에 대한 중요한 결정은 반드시 관련 Linear 댓글로 남긴다.

형식: [페르소나] 결정 요약. 이유: 한 줄.
예: [raphael] API 설계: X 패턴 채택. 이유: Y 이유로 Z 대안 배제.

어떤 에이전트도 get_issue로 이 정보를 독립적으로 수집할 수 있다.

2. hangman-docs 링크를 티켓에

상세 분석·ADR은 hangman-docs에 작성 후 URL을 티켓 본문/댓글에 첨부한다. 에이전트가 경로를 추측할 필요 없이 티켓에서 바로 접근 가능하다.

3. 스레드 전환 시 명시적 핸드오프

페르소나가 바뀔 때 직전 결정 요약을 메시지에 포함시킨다. Asurada가 받는 DELEGATE CONTEXT에 "Jarvis + Raphael 논의 결과" 요약이 있으면 세션 공유 없이도 연속성이 생긴다.

4. 관련 스레드 URL 기록

중요한 논의가 여러 스레드에 분산될 경우, 관련 스레드 URL을 Linear 댓글에 남긴다.

현재 구조의 의도적 선택

이 구조는 설계 실수가 아니다.

격리: 각 페르소나는 자신의 작업 범위에만 집중한다. 다른 페르소나의 노이즈가 들어오지 않는다.
병렬성: 여러 페르소나가 독립적으로 동시에 작업할 수 있다.
명시성: 컨텍스트 전달이 명시적(CONTEXT 필드, 댓글 기록)이어야 한다는 강제가 불필요한 정보 전파를 막는다.

트레이드오프: 에이전트들이 외부 앵커(Linear, hangman-docs)에 기록하는 규율 없이는 컨텍스트 손실이 발생한다.

다음 단계

[ ] 에이전트 규율 명문화: "중요 결정 → 관련 티켓 댓글 기록" AGENTS.md 추가
[ ] DELEGATE CONTEXT 가이드 보강: 핵심 결정 요약 포함 패턴 예시 추가
[ ] 페르소나 교체 핸드오프 템플릿 정의 (선택)