멀티채널 세션 분리 (Multichannel Session Management)
Slack·텔레그램 등 여러 채널에서 에이전트와 작업할 때, 업무 맥락이 섞이지 않도록 세션을 의도적으로 분리하는 실전 패턴. Slack 스레드와 텔레그램 토픽이 각각 독립 세션을 형성하며, DM은 주제를 바꾸면 맥락이 섞이는 함정이 있다.
문제: 맥락 오염
같은 대화 공간(DM)에서 서로 다른 작업을 번갈아 시키면:
DM: "대시보드 만들어줘" → [차트 색상 코드 논의...]
"아 그리고 업무일지도 써줘"
→ 차트 색상이 업무일지 마무리 문단에 나타날 수 있음
agent-session-architecture에서 정의한 “채팅 컨텍스트 = 세션 1개” 원칙의 역설 — 하나의 세션에 이것저것 넣으면 구조적으로 섞인다.
해결 원칙: 작업 단위마다 대화 공간(세션)을 분리한다.
Slack 세션 분리: 채널 + 스레드 2단계
채널별 분리
채널마다 독립 세션이 생성된다. 서로 다른 성격의 작업을 채널로 구분:
| 채널 | 세션 용도 |
|---|---|
#021-뽀짝이-업무방 | 직접 지시·작업 요청 |
#뽀짝이-알림 | 자동화 보고 수신 |
#02-ai스터디강의 | 팀 운영 논의 |
#커뮤니티-알림 | CS 알림 처리 |
채널이 다르면 맥락이 구조적으로 섞이지 않는다.
스레드별 분리 (킬러 기능)
같은 채널 안에서도 스레드마다 독립 세션:
[채널 본문] → 채널 세션 (여러 작업 공유 안 됨)
[스레드 A] → 스레드 A 세션 (대시보드 작업 전용)
[스레드 B] → 스레드 B 세션 (업무일지 작업 전용)
“대시보드 수정해줘”는 스레드 A에서, “업무일지 써줘”는 스레드 B에서 → 절대 섞이지 않는다.
황금 규칙: 새 작업은 새 스레드에서 시작.
텔레그램 세션 분리: 토픽 그룹
텔레그램은 채널 구조가 없지만 Forum Topics으로 동등한 효과를 낼 수 있다.
설정 절차 5단계
- 새 그룹 생성 + 봇 초대
- Chat History → “Visible” 변경 → 슈퍼그룹 자동 전환 (토픽은 슈퍼그룹에서만 작동)
- 그룹 설정 → Topics 토글 켜기
- 토픽 생성 (예: 리서치 / 개발 / 콘텐츠 / 잡담)
- 봇을 Admin으로 설정 (Privacy Mode 우회 — 모든 토픽 메시지 수신)
토픽별 세션 키: agent:main:telegram:group:-100...:topic:N
고급: 토픽별 다른 에이전트
한 그룹 안에서 토픽마다 다른 에이전트를 연결할 수 있다:
{
"channels": {
"telegram": {
"groups": {
"-1001234567890": {
"topics": {
"3": { "agentId": "researcher" },
"5": { "agentId": "coder" }
}
}
}
}
}
}각 토픽이 다른 워크스페이스·기억·성격의 에이전트와 연결 → 코드 리뷰와 수강생 조회가 구조적으로 섞이지 않음. (출처: bbojjak-openclaw-multichannel-session-lesson15)
Slack vs 텔레그램 비교
| 항목 | Slack | 텔레그램 |
|---|---|---|
| 분리 단위 | 채널 + 스레드 | 그룹 + 토픽 |
| 최소 세션 단위 | 스레드 | 토픽 |
| DM 세션 | 메인 1개 (함정!) | 메인 1개 (함정!) |
| 에이전트 분리 | bindings 설정 | topics.agentId 설정 |
Slack 채널 = 텔레그램 토픽 (기능 대응 관계)
Slack 스레드 ≠ 텔레그램에 대응 개념 없음 (토픽이 최소 단위)
DM 함정
Slack과 텔레그램 모두 DM은 메인 세션 하나에 합쳐진다. 주제를 바꿀 때마다 이전 맥락이 남아 섞인다.
대응 방법:
- Slack: 새 스레드로 시작
- Telegram: 해당 토픽으로 이동
- DM에서 불가피하게 계속해야 한다면: “이전 주제 끝. 새 주제 시작” 명시적 선언
ZeroCho 실사용에서도 텔레그램 그룹/토픽 운용 품질이 도구 선택의 핵심 변수로 언급된다. 즉 기능 비교표보다도, 채널/토픽에 이미 축적된 운영 맥락이 전환 비용을 크게 좌우한다. (출처: yt-zerocho-hermes-openclaw-comparison-2026)
권장: DM은 최후의 수단. 가능하면 채널/토픽에서 작업.
bindings — 채널→에이전트 명시 매핑
gateway-architecture의 bindings 설정으로 채널별 담당 에이전트를 명시:
{
"bindings": [
{
"match": { "channel": "slack", "teamId": "T04..." },
"agentId": "뽀짝이"
},
{
"match": { "channel": "telegram", "peer": { "kind": "group", "id": "-100..." } },
"agentId": "뽀야"
}
]
}Gateway가 bindings를 보고 자동 라우팅. Slack 메시지 → Slack으로 답장 / 텔레그램 → 텔레그램으로 답장. 에이전트가 “어디로 보낼까?” 판단 불필요.
실전 습관 체크리스트
| 상황 | 행동 |
|---|---|
| 같은 프로젝트 | 같은 채널/토픽에서 이어가기 |
| 다른 프로젝트 | 다른 채널/토픽으로 이동 |
| Slack에서 새 작업 | 새 스레드 시작 |
| Telegram에서 새 작업 | 해당 토픽으로 이동 |
| 긴 작업 | sessions_spawn 서브에이전트 위임 |
| DM에서 주제 변경 | ”이전 주제 끝” 명시적 선언 |
관련 개념
- agent-session-architecture — 세션 분리의 이론적 기반 (채팅 컨텍스트=세션 1개 원칙)
- gateway-architecture — bindings 설정으로 채널→에이전트 자동 라우팅
- multi-agent-team-design — 토픽별 agentId = 멀티에이전트 채널 분리 실전
- subagent-orchestration — 긴 작업 → sessions_spawn 위임 원칙
소스
- bbojjak-openclaw-multichannel-session-lesson15
- yt-zerocho-hermes-openclaw-comparison-2026 (텔레그램 그룹/토픽 운용 품질과 전환 비용의 실사용 사례)