[Design] Slack 세션 단위 결정: 스레드별 유지 vs 채널 단위 통합 — 채널 내 병렬성과 맞바꾸는 문제

[parkjs101]

요약

현재 Slack은 스레드마다 별도 chat session 을 만든다. 세션 수가 스레드 수만큼 늘어 관리가 어렵다는 지적이 있었다. 채널 단위로 접는 안을 검토했고, 그 대가와 대안을 정리해 결정을 요청한다.

핵심 트레이드오프: 채널 단위로 접으면 같은 채널 안에서는 응답이 순차 처리된다. 세션 키가 실행 스코프를 겸하는 구조에서 나오는 필연적 귀결이다.

이 문서는 독립 서브에이전트 감사를 거쳤고, 초안의 사실오류 5건을 반영해 수정했다. 특히 최초 권고(D안)는 감사 결과 그대로는 성립하지 않아 재작성했다.

1. 현재 구조

buildRemoteBindingKey (src/messaging/session-key.ts:34-39) 가 threadId 를 키에 넣는다.

jaw:slack:channel:C123                          ← 채널 최상위
jaw:slack:channel:C123:thread:1754983201.123456 ← 스레드마다 별개 키

이 키는 remote_session_bindings 의 PK(src/core/db.ts:105-107)이고, 키가 없으면 resolveOrCreateRemoteSession (src/core/chat-sessions.ts:122-142) 이 새 chat_sessions 행을 INSERT 한다. 스레드 1개 = 세션 1개 = 사이드바 항목 1개.

이 키가 동시에 결정하는 것

scopeForChatSession (src/orchestrator/scope.ts:52-53) 이 remoteKey 를 그대로 scope 로 반환한다. 그래서 세션 키는 세션만 정하지 않는다.

파생물	코드	의미
chat_sessions 행	chat-sessions.ts:137-140	대화 기록 분리
CLI 세션 버킷 <cli>:<model>:<scope>	src/agent/args.ts:194	vendor 대화 컨텍스트 분리
sessionLanes 실행 레인	src/orchestrator/session-lanes.ts:39-51	동시 실행 단위
isAgentBusy(scope)	src/agent/spawn.ts:467	busy 판정 단위

세션 키를 바꾸면 동시 실행 단위가 같이 바뀐다. 이게 이 이슈의 전부다.

2. 현재 최대 동시 병렬 응답 수

레인에 들어가는 턴의 상한은 multiSession.maxConcurrent

// src/orchestrator/session-lanes.ts:100-102
export const sessionLanes = new SessionLanes(
    () => settings["multiSession"]?.maxConcurrent ?? 1,
);

// src/orchestrator/session-lanes.ts:90-96
private pump(): void {
    const limit = positiveInt(this.readMaxConcurrent());
    while (this.active < limit) { ... }
}

active 는 프로세스 전역 카운터(session-lanes.ts:22)다.

출처	값
코드 기본값 (src/core/config.ts:348)	2
레거시 승계분 (config.ts:228)	1
multiSession.enabled=false	1 (scope가 전부 default 로 collapse, scope.ts:52)

단, 이건 전역 천장이 아니다 (감사 정정)

Telegram·Discord·heartbeat 턴은 sessionLanes 를 거치지 않는다. 레인에 계수되지도, 제한되지도 않는다.

$ rg -n 'sessionLanes' src/telegram/bot.ts src/discord/bot.ts src/memory/heartbeat.ts
(빈 결과)

• src/telegram/bot.ts:1073 — await orchestrateAndCollectData(...) 직접 호출
• src/discord/bot.ts:554 — await orchestrateAndCollect(...) 직접 호출
• src/memory/heartbeat.ts:225 — 동일

Slack만 admitSlackRun 이 감싼다 (src/slack/ingress.ts:249).
재진입 예외도 있다 — session-lanes.ts:27 의 if (this.runningScope.getStore() === scopeKey) return Promise.resolve().then(task); 는 active 를 올리지 않고 실행된다.

답

Slack 단독 활성 호스트에서 레인 경유 턴의 동시 실행 상한은 2. (이 조건은 messaging.enabledChannels: ["slack"] 인 현재 배포 형태와 일치한다.) Telegram/Discord/heartbeat를 함께 켜면 그 경로는 이 상한 밖에서 추가로 돈다.

인그레스 레인(src/slack/ingress.ts:180-205)은 동시성 상한이 아니다 — 같은 키의 이벤트를 순서대로 흘리는 직렬화일 뿐이고, 키가 다르면 무제한 진입한다.

즉 스레드가 30개여도 Slack 동시 응답은 2개이고 나머지는 대기한다.

3. 선택지

A안 — 현행 유지 (스레드마다 세션)

얻는 것: 스레드별 독립 실행(상한 내), 스레드별 CLI 컨텍스트 격리, 작은 오배송 표면.
잃는 것: 세션 수가 스레드 수만큼 증가. vendor 세션도 같이 증가. 스레드 간 맥락 공유 불가.

B안 — 채널 단위로 접기

얻는 것: 세션 수 = 채널 수. 채널 내 스레드가 하나의 대화 맥락 공유.

잃는 것: 같은 채널 안에서 병렬 응답 불가. scope 가 채널 단위가 되고 sessionLanes 는 스코프별로 tail 을 체이닝하므로(session-lanes.ts:39-51) 같은 채널의 턴은 무조건 순차다. 스레드1이 3분 작업을 돌면 스레드2는 3분 뒤에 답을 받는다.

인그레스 레인 키만 스레드로 남겨도 해소되지 않는다 — sessionLanes 가 별도 레이어다. (slackIngressLaneKey 가 buildRemoteBindingKey 를 재사용하므로, 바인딩을 접으면 인그레스 레인도 같이 접힌다.)

C안 — 세션은 채널, 실행은 스레드 (감사 결과 재평가: 유력 후보)

초안은 이 안을 "세션 목록만 예뻐지는 절충"으로 기각했으나, 감사 결과 그 기각이 틀렸다.

1. scope와 session은 이미 별개 파라미터다 — resolveOrcScope (scope.ts:57-61)가 둘을 따로 받고, Slack은 preResolvedScope 로 이미 독립 주입한다(src/slack/ingress.ts:239-241).
2. DB 히스토리 블록은 scope가 아니라 chatSessionId 로 키잉된다 — buildHistoryBlock(currentPrompt, workingDir, chatSessionId, ...) (src/agent/spawn.ts:791, 호출 :1351). 따라서 C안에서 새 스레드의 첫 턴은 resume가 아니므로 shouldBuildHistoryBlock 이 true가 되고(src/agent/prompt-context.ts:21-22), 에이전트는 채널의 스레드 간 히스토리를 받는다.
3. 버킷은 scope로 키잉되므로(src/agent/args.ts:194) 동시 스레드는 서로 다른 버킷을 쓴다 — "같은 vendor 세션에 두 턴" 문제가 발생하지 않는다.

즉 C안은 채널 단위 세션 수 + 스레드별 병렬성 + 스레드 진입 시 교차 맥락을 동시에 준다.

진짜 대가: 첫 턴 이후에는 vendor 측 컨텍스트가 스레드별로 갈린다(교차 맥락은 DB 히스토리 경유로만).
설계 제약: 스레드 scope가 isRemoteBindingScope (scope.ts:29-31, startsWith('jaw:'))와 충돌하면 안 된다 — 충돌 시 바인딩 키로 오인된다.

D안 — A안 유지 + 유휴 스레드 세션 회수

초안의 설계는 틀렸다. 감사가 두 가지를 지적했다.

1. 바인딩만 지우면 세션 목록이 줄지 않는다. 목록은 chat_sessions 기준이고 바인딩은 LEFT JOIN 이다(chat-sessions.ts:45-55). 바인딩 없는 세션도 그대로 나온다. CASCADE 는 반대 방향으로만 걸려 있다(db.ts:110). → deleteChatSession (chat-sessions.ts:188)을 호출해야 하고, 그러면 deleteMessagesStmt.run(sessionId) (:195)로 해당 스레드의 DB 대화 기록이 삭제된다. "CLI 컨텍스트 손실"이 아니라 기록 파괴다.
2. 스레드 히스토리 프리페치가 맥락을 복구하지 못한다. 프리페치 클레임은 owner generation 으로 키잉된 인메모리 1회성이다(src/slack/thread-tracker.ts:158-160). 바인딩 회수는 scopeGenerations 를 올리지 않으므로 클레임이 살아남아 재주입이 안 된다(src/slack/bot.ts:816). → 회수 시 bumpScopeSessionGeneration(scope) (src/agent/session-persistence.ts:46)를 같이 호출해야 한다.

수정하면 여전히 유효한 안이다: TTL 초과 + isAgentBusy(scope) false 인 jaw:slack:%:thread:% 만 회수, 채널 최상위는 제외.

4. B안 선택 시 같이 봐야 하는 것 — mid-run 주입 (런타임 조건부)

초안은 이를 "기본값"이라 했으나 틀렸다. 주입은 활성 런타임이 jwc 일 때만 일어난다.

// src/agent/spawn.ts:698-701
export function canSteerAgent(scopeKey: string): boolean {
    const run = activeMainProcesses.get(scopeKey);
    return run?.meta.cli === 'jwc' && jawRuntimesByScope.get(scopeKey)?.busy === true;
}

기본 CLI 는 codex-app 이다(src/cli/registry.ts:271, 이 호스트 설정도 "cli": "codex-app"). canSteerAgent 가 false 면 gateway.ts:95 의 if (!canSteerAgent(ctx.scopeKey)) return queue(); 로 떨어지고, 큐 항목은 자기 target 을 들고 있으므로(src/agent/spawn/queue.ts:531) 자기 스레드로 답한다.

jwc 런타임에서는 실재하는 위험이다: spawn.ts:716 → jwc-runtime.ts:174 (streamingBehavior:'steer')로 돌고 있는 턴에 주입되고, settleOnce(meta?.requestId, 'steered') (spawn.ts:720)라 주입된 메시지는 자기 답을 받지 못한다. collect 병합도 runItems[0].target 으로만 답한다(queue.ts:511-512, 522-527).

→ B안의 선행 조건은 런타임 조건부이며, codex-app 호스트에서는 순차 큐잉으로 degrade 되어 라우팅은 정확하다.

5. 인접 이슈 (중복 방지)

• 인바운드 턴 응답이 DM 대신 lastActive 공개 채널로 배달된다 (동시 턴 경합) #474 (open) — 인바운드 턴 응답이 lastActive 로 오배송. 본 이슈와 가장 인접하며, sendChannelOutput 의 전역 폴백은 그쪽 소관이다. 턴 주소 고정은 이미 랜딩했다(src/messaging/send.ts:360-363, commit ab33fc74).
• 하트비트 리포트가 지정 채널이 아니라 lastActive 스레드로 배달된다 #437 / 리마인더·web-ai 알림·alert 에스컬레이션도 같은 lastActive 오배송을 탄다 #438 — 하트비트·리마인더 목적지 고정 (allowActiveFallback).
• devlog/260825_lastactive_misrouting/ (status: active) 가 이 계열을 담당한다.

본 이슈는 세션 키 단위 결정만 다루며 위 폴백 설계를 중복하지 않는다.

한편 답장 target 자체는 안전하다 — 이벤트에서 만들어 클로저로 유지되고(src/slack/bot.ts:409-490), 결과 수집은 requestId 로 필터된다(src/orchestrator/collect.ts:55). 다만 이 필터는 양쪽 값이 모두 있을 때만 동작하며, Slack 은 항상 공급하므로 현재는 성립한다.

6. 권고 (감사 반영 후 수정됨)

C안과 D안(수정본)을 동급 후보로 놓고, C안을 우선 검토한다.

• 초안은 D안을 1순위로 권고했으나, 감사 결과 D는 회수 대상을 잘못 지정했고(세션 행이 아니라 바인딩) 맥락 복구가 발화하지 않는다. 고칠 수 있지만 대가가 초안이 말한 것보다 크다(대화 기록 삭제).
• C안은 채널 단위 세션 수와 스레드별 병렬성을 동시에 준다. 초안의 기각 근거였던 "scope 계약을 바꿔야 한다"와 "맥락 공유를 못 얻는다"가 둘 다 코드상 사실이 아니었다.
• B안의 대가(채널 내 순차 응답)는 실재하고 되돌리기 어렵다. 교차 스레드 맥락 공유가 진짜 요구일 때만 선택할 값이다.

7. 결정 요청

1. 세션 단위: A(현행) / B(채널) / C(세션=채널, 실행=스레드) / D(현행+회수, 수정본) 중 택 1
2. B안 선택 시 — 채널 내 순차 응답을 수용하는가?
3. D안 선택 시 — 회수 TTL 기본값(제안 72시간)과 대화 기록 삭제를 수용하는가?
4. multiSession.maxConcurrent 를 2에서 올릴 것인가? (별개 축이지만 체감 병렬성에 직결)

---

부록: 검증 환경

npm run typecheck → exit 0 (실측).

npm test → 작업트리 clean 상태에서 고유 실패 25건 + 요약줄 1 (PRD-* 10, P3-* 5, dispatch 6, sidecar-prune 2, 로드 실패 3파일 등). 회귀 판정은 이 baseline 대비 comm -13 비교로만 가능하며 "전체 통과"를 수용 기준으로 쓸 수 없다. npm test 는 tests/integration/ 을 제외한다.

감사: 독립 서브에이전트 1회(GO-WITH-FIXES, blockers=5). 지적 5건 모두 main 세션이 코드로 재확인 후 본문에 반영했다.

[parkjs101]

C안 보충 — "한 세션에서 서로 다른 스레드 2개가 동시에 응답 가능한가?"

가능하다. 다만 세 가지 단서가 붙고, 그중 하나는 본문에 없던 신규 리스크다.

왜 가능한가

동시 실행을 막는 두 관문이 모두 scope 기준이고, 어느 쪽도 chatSessionId 를 보지 않는다.

// src/orchestrator/session-lanes.ts:39-43 — scope 별 tail 체이닝
private enqueue<T>(scopeKey: string, task: () => Promise<T>): Promise<T> {
    const previous = this.sessionTails.get(scopeKey);
    ...
    this.sessionTails.set(scopeKey, tail);

// src/agent/spawn.ts:473-475 — busy 판정도 scope 기준
return activeMainProcesses.has(scopeKey)
    || runtimeForScope(scopeKey).busy
    || queueCtrl.isRetryPending(scopeKey);

C안은 scope 를 스레드 단위로 두므로 두 스레드의 tail 체인이 갈라지고 busy 판정도 독립이다. 세션(chatSessionId)만 채널 하나로 합쳐진다.

안	세션(기록)	scope(실행)	스레드 2개 동시
A (현행)	스레드별	스레드별	가능
B	채널	채널	불가
C	채널	스레드	가능

단서 1 — 전역 상한 2개는 그대로다

sessionLanes 의 active 는 프로세스 전역 카운터다(session-lanes.ts:90-96). scope 가 갈라져도 동시 실행 턴은 maxConcurrent 를 넘지 못한다. 스레드 5개가 동시에 말을 걸면 2개가 돌고 3개는 대기한다.

C안이 푸는 것은 "같은 채널이라서 무조건 줄서기" 이지 상한 자체가 아니다.

단서 2 — 맥락 공유는 "스레드 진입 시 1회"다

히스토리 블록은 chatSessionId 로 키잉되므로(src/agent/spawn.ts:791, 호출 :1351) 새 스레드의 첫 턴은 채널의 교차 히스토리를 받는다. 그러나 이후에는 vendor 세션이 scope 별로 갈리므로(<cli>:<model>:<scope>, src/agent/args.ts:194) 스레드1에서 방금 한 말이 스레드2로 실시간 전파되지는 않는다.

정확한 표현: "시작할 때 채널 맥락을 물려받고, 이후에는 각자 간다." B안의 "하나의 대화 맥락 공유"와는 다르다.

단서 3 — 같은 세션에 대한 동시 쓰기 (신규, C안 선택 시 확인 필요)

C안에서는 두 스레드가 같은 chatSessionId 로 동시에 insertMessage 를 하게 된다. 현재는 세션당 사실상 1턴만 돌아 발생한 적 없는 상황이다.

DB 계층은 안전하다(초기 우려를 코드로 확인 후 정정):

// src/core/db.ts:29-30
db.pragma('journal_mode = WAL');
db.pragma('busy_timeout = 5000');

better-sqlite3 는 동기식이라 단일 프로세스 내 쓰기가 직렬화된다. 잠금 경합은 발생하지 않는다.

실제 리스크는 읽기 쪽의 인터리빙이다. 세션 기준 조회가 ORDER BY id 이므로(db.ts:401, :553) 두 스레드의 메시지가 시간순으로 뒤섞인 하나의 시퀀스가 된다.

영향받는 지점:

1. buildHistoryBlock (spawn.ts:791) — 스레드2의 첫 턴이 물려받는 "채널 맥락" 에 스레드1의 진행 중 대화가 섞여 들어온다. 대체로 무해하나 의도한 것은 아니다.
2. getLatestAssistantContentForAgyResume (spawn.ts:859-863) — 최근 12건에서 첫 assistant 응답을 집는다. 동시 실행 시 다른 스레드의 답변을 집을 수 있다.

   const rows = getRecentMessages.all(workingDir || null, chatSessionId, 12) as RecentMessageRow[];
   const row = rows.find((msg) => msg.role === 'assistant' && ...);

   주석 자체가 "the replay is prepended to THIS run's prompt, so it has to come from this run's conversation" (spawn.ts:856-858) 이라고 명시한다 — 즉 세션당 1턴을 전제한 코드다. AGY 런타임 한정이지만, 같은 전제에 기대는 다른 지점이 있는지 C안 선택 시 전수 확인이 필요하다.

정리: C안의 진짜 비용은 "세션당 1턴" 가정에 기대는 코드의 전수 조사다. DB 잠금은 문제가 아니다.

---

_{본문 §3 C안 항목에 대한 보충. 세 단서 모두 코드로 확인했으며, 단서 3의 초기 가설(DB 잠금 경합)은 검증 과정에서 오류로 판명되어 실제 리스크(읽기 인터리빙)로 정정했다.}

[lidge-jun]

#520이 머지되면서(PR #531, 9f93490ec) 이 이슈의 선택지가 좁아졌습니다. 무엇이 닫혔고 무엇이 남았는지 정리합니다.

코드가 이미 답을 하나 골랐고, 그건 결함이었습니다

resolveSlackThreadTs의 || event.ts 때문에 최상위 메시지마다 세션 행이 생기고 있었습니다. 스레드별 키잉이 아니라 메시지별 키잉이었고, chat_sessions에는 eviction도 TTL도 상한도 없어서 한 DB가 186MB까지 갔습니다.

#520에서 고친 방식은 값 하나가 서로 다른 두 질문에 답하고 있었다는 걸 분리하는 것이었습니다.

• 답장이 어디로 가는가 — 최상위 메시지의 ts는 여기에는 맞는 답입니다(그 아래 스레드를 열어야 하니까).
• 이게 어느 대화인가 — 여기에는 틀린 답입니다. 그 스레드는 아직 존재하지 않습니다.

그래서 threadIsSynthetic 플래그가 붙고, buildRemoteBindingKey에서만 접힙니다. 공유 헬퍼인 normalizedThreadId에 넣으면 buildRemoteSessionKey도 같이 접히는데, 그건 deliveryTargetKey를 먹이므로 turn-delivery.ts:152-155가 명시한 불변식(스레드 답장과 채널 게시는 서로 다른 목적지다)이 깨집니다.

이 이슈에서 닫힌 것

스레드 없는 트래픽은 이제 채널 단위입니다. 세션 수가 메시지 수가 아니라 채널 수로 묶입니다. 이건 사실상 이 이슈가 말한 하이브리드가 결함 수정으로 들어온 셈입니다.

다만 공짜는 아니고, PR에 그대로 적어두었습니다.

• 한 채널의 최상위 트래픽이 두 지점에서 직렬화됩니다(session lane과 Slack ingress lane, 둘 다 같은 바인딩 키를 씁니다).
• midRunPolicy 기본값이 steer라서, 다른 사람의 최상위 메시지가 앞사람 답변 중인 턴을 steer합니다.
• 벤더 컨텍스트 버킷도 scope 키잉이라 채널의 최상위 턴들이 CLI 대화 하나를 공유합니다. 이게 비용이자 동시에 이 이슈가 원하던 채널 맥락 공유이기도 합니다.

진짜 스레드는 자기 세션과 자기 병렬성을 그대로 유지합니다.

남은 결정

1. 진짜 스레드는 여전히 스레드당 세션입니다

활성 스레드 30개면 세션 30개입니다. 이 이슈의 원래 불만 — 세션 수가 스레드 수만큼 늘어 관리가 어렵다 — 은 부분적으로만 해소됐습니다.

2. C안(세션은 채널, 실행은 스레드)의 메커니즘은 이미 프로덕션에 있습니다

mention-watch가 정확히 그걸 하고 있습니다. src/memory/heartbeat.ts의 mentionThreadPlacement 주석이 직접 말합니다:

Where a mention-watch answer runs: the thread's SESSION, its own SCOPE. Splitting the two is the point.

세션 id는 어느 히스토리를 읽고 쓸지 정하고, scope는 어느 실행 레인에서 돌지 정합니다. 이 둘은 이미 독립적으로 계산됩니다. inbound Slack에 일반화하려면:

1. 세션 바인딩 키는 채널 단위로, scope 키는 스레드 단위로 각각 만든다 (resolveOrcScope는 이미 scope와 session을 별도 입력으로 받습니다).
2. 주의할 점: 스레드 scope가 jaw:로 시작하면 orchestrator/scope.ts의 isRemoteBindingScope가 그걸 바인딩 키로 읽고 setActiveChatSession을 통해 세션을 가로챕니다. scope 이름 공간을 분리해야 합니다.
3. preResolvedScope는 이미 scope만 덮어씁니다(slack/ingress.ts). chatSessionId는 내부에서 파생되므로 1번이 여전히 필요합니다.

3. 답이 나오지 않은 질문 두 개

• 스레드 간 맥락 공유가 실제 요구사항인가. B와 C를 가르는 지점인데 #520은 어느 쪽 증거도 만들지 않았습니다.
• 세션 회수가 대화 기록 삭제를 의미해도 되는가. deleteChatSession은 메시지도 같이 지웁니다. #520은 그래서 기존 행을 회수하지 않고 그대로 남겼습니다 — Slack은 채널당 :thread: 행이 N개인데 어느 게 synthetic이었는지 디스크에 표시가 없어서, 자동 리바인드는 진짜 스레드의 히스토리를 채널에 붙일 수 있습니다.
• maxConcurrent. [Bug] DB retention residual: legacy tool_log 53MB + freelist 114.5MB, explicit maintenance missing #520 이후 오히려 더 급해졌습니다. 채널의 최상위 트래픽이 한 레인을 공유하므로 느린 턴 하나가 그 채널 전체를 막습니다.

배포 시 알아둘 것

#520이 나가면 각 채널의 최상위 대화가 빈 상태로 시작합니다. 이전 히스토리는 남겨진 세션들을 통해 여전히 접근 가능하고, 삭제되는 건 없습니다.

제안

이 이슈는 C안으로 좁혀서 열어두는 것을 권합니다. 메커니즘은 이미 있고 한 기능에서 검증됐으며, #520이 최상위 트래픽에 대해서는 이미 그 방향으로 갔습니다. 남은 건 진짜 스레드에 같은 분리를 적용할지, 그리고 위 2번의 scope 이름 공간 문제를 어떻게 풀지입니다.

[lidge-jun]

2026-09-05 라운드 2 정리입니다.

권고는 C안(세션은 채널, 실행 scope는 스레드)입니다. #520/#531 로 최상위 메시지마다 세션이 늘던 결함은 닫혔고, 이번 라운드 PR #536 이 그 공유 채널 세션에서 다른 사용자의 최상위 메시지가 진행 중인 턴을 steer/kill 하지 않도록 synthetic top-level 을 followup 으로 admit 합니다. 그러나 진짜 Slack 스레드는 여전히 스레드당 세션 1개입니다.

mention-watch 의 mentionThreadPlacement 가 session 과 scope 를 독립적으로 계산하는 선례를 이미 제공하므로, C안은 채널 단위 세션 수와 스레드별 병렬성을 함께 보존할 수 있습니다. 구현 전에 감사할 것 두 가지: 같은 chatSessionId 의 동시 읽기 인터리빙(AGY resume 가 다른 스레드의 응답을 집어오는지), 그리고 jaw: 로 시작하는 scope 가 isRemoteBindingScope(orchestrator/scope.ts) 에 걸려 세션을 가로채지 않도록 하는 namespace.

이 이슈는 C안 구현 또는 명시적 기각까지 open 으로 둡니다. maxConcurrent 는 별개 축이라 여기서 결정하지 않습니다.