한 봇이 채널마다 다른 두뇌를 쓰게 하는 법 — OpenClaw의 Sessions 메뉴

오픈소스 AI 어시스턴트 OpenClaw를 집 서버에 올려 쓰면서 브라우저 관리 화면(Control UI)을 들여다봤다. 여러 메뉴 중 가장 실용적으로 와닿은 건 Sessions(세션) 탭이었다. 한 대의 에이전트가 텔레그램·디스코드·예약 작업·웹 대시보드를 동시에 상대하다 보면, "지금 이 대화는 어느 맥락의 대화인가"가 곧바로 문제가 된다. 더 나아가 어떤 대화에는 똑똑하고 비싼 모델을, 어떤 대화에는 빠르고 싼 모델을 쓰고 싶어진다. 이 글은 그 문제와 OpenClaw가 고른 답(세션 키 + 세션별 오버라이드)을 따라간다.

배경 — 에이전트는 여러 대화 맥락을 동시에 산다

사람과 일대일로 대화하는 챗봇은 대화 맥락이 하나다. 하지만 메신저·예약 작업·웹 화면을 한꺼번에 상대하는 AI 에이전트는 다르다. 텔레그램에서 코드 리뷰를 도와주는 와중에, 디스코드의 다른 대화에 답하고, 매일 아침 cron(정해진 시각에 자동 실행되는 예약 작업)으로 뉴스를 요약하고, 백그라운드로 띄운 하위 에이전트(sub-agent, 특정 작업을 위임받아 따로 도는 보조 에이전트)가 긴 작업을 돌린다. 이 모든 대화가 하나의 기록에 뒤섞이면 맥락이 엉킨다.

다이어그램 설명. 이 그림은 에이전트 한 대가 실제로는 여러 개의 독립된 대화 맥락을 동시에 안고 산다는 걸 보여준다. 왼쪽의 에이전트 하나에서 텔레그램 메시지 대화, 디스코드 채널 대화, 예약 작업, 백그라운드 하위 에이전트, 웹 대시보드의 새 대화가 각각 독립된 마디로 갈라져 세로로 늘어서 있다. 위 마디 하나하나를 OpenClaw는 세션(session)이라 부른다 — 메시지 기록·토큰 사용량·모델 설정을 따로 들고 있는 하나의 대화 단위다. 핵심은 "에이전트 하나 = 대화 하나"가 아니라는 점이다. 흔한 오해가 "봇이 한 대니까 기억도 하나로 합쳐져 있겠지"인데, 그렇게 합치면 텔레그램에서 한 말이 디스코드 답변에 새어 나오는 맥락 누수가 생긴다. 그래서 무슨 가치인가 — 세션을 쪼개 두면 각 채널·작업이 서로의 대화에 오염되지 않고 독립적으로 흘러간다.

핵심 문제 — 세션을 못 가르면 생기는 두 가지 사고

세션이라는 단위가 없거나, 있어도 한데 뭉뚱그리면 두 가지 사고가 난다. 하나는 맥락이 섞이는 사고, 다른 하나는 모든 대화에 같은 모델을 강제로 쓰는 사고다.

다이어그램 설명. 이 그림은 세션을 제대로 가르지 못했을 때 갈라지는 세 가지 실패를 보여준다. 맨 위에서 "모든 대화를 한 맥락·한 모델로 처리"하는 단순 방식이 세 갈래로 터진다. 첫째, 한 채널에서 한 말이 다른 채널 답변에 새어 나오는 맥락 오염이다. 둘째, 매일 아침 한 줄짜리 알림을 요약하는 일에도 코드 설계용 최상위 모델을 그대로 쓰는 낭비다 — 추론 능력이 강한 모델은 토큰당 비용이 수 배에서 수십 배까지 비싸다. 셋째, 지금 이 봇 안에 어떤 대화가 살아 있는지를 운영자가 들여다볼 창구가 없다는 통제 문제다. 가장 놓치기 쉬운 건 두 번째다 — "좋은 모델 하나로 통일하면 편하지"라는 생각이 실제로는 매달 청구서를 키운다. 그래서 무슨 가치인가 — 이 세 사고는 모두 "세션을 식별하고, 세션마다 다른 설정을 줄 수 있어야" 풀린다.

해결 방법 — 세션 키 + 세션별 오버라이드

OpenClaw는 이 문제를 두 개의 장치로 푼다. 하나는 모든 대화에 고유한 이름표를 붙이는 세션 키(session key)이고, 다른 하나는 그 세션에만 적용되는 오버라이드(override, 기본 설정을 그 세션에 한해 덮어쓰는 값)다. Control UI의 Sessions 탭은 이 두 가지를 사람이 눈으로 보고 손으로 바꾸게 해 주는 창구다.

세션 키 — 모든 대화에 붙는 이름표

세션 키는 "이 대화가 무엇인지"를 한 줄로 식별하는 문자열이다. OpenClaw는 세션을 종류(kind)로 나누는데, 일상적으로 마주치는 건 1:1 개인 메시지(direct), 그룹·채널 대화(group), 예약 작업(cron), 하위 에이전트(spawn-child) 네 가지이고, 그 밖에 내부용 센티널인 global·unknown이 있다. 중요한 건 종류를 사람이 직접 고르는 게 아니라 대화가 어디서·어떻게 시작됐는지에 따라 자동으로 분류된다는 점이다 — 개인 DM이 오면 direct, 그룹/채널 메시지면 group, 예약된 cron 작업이 돌면 cron, 에이전트가 sessions_spawn 도구로 보조 일꾼을 띄우면 그 자식 세션이 spawn-child가 되는 식이다. 슬랙·디스코드의 스레드처럼 더 잘게 갈리면 키 끝에 :thread:<id> 같은 꼬리표가 붙는다.

다이어그램 설명. 이 그림은 Sessions 목록의 한 행이 펼쳐 보여 주는 컬럼들을 정리한 것이다. 한 행이 곧 하나의 세션이고, 왼쪽부터 키·레이블·종류·상태·런타임·업데이트됨·토큰·압축·오버라이드(생각수준·빠름·상세·추론)·작업 순으로 늘어선다. 눈여겨볼 점이 둘 있다. 첫째, 소속 에이전트와 채널은 따로 컬럼이 있는 게 아니라 키 문자열 안에 인코딩되어 있다 — agent:<에이전트>:<채널>:... 형태라, 키 컬럼 하나가 "누구 소속이며 어디서 들어왔는지"를 함께 담는다. 둘째, 현재 모델은 목록 컬럼에 없다 — 행을 펼치거나 채팅 헤더에 들어가야 보인다. 대신 자주 만지는 오버라이드(생각수준·빠름·상세·추론)는 목록에 인라인 드롭다운으로 박혀 있어 한자리에서 바로 바꾼다. 이렇게 메타데이터를 함께 묶어 두는 이유는, 운영자가 목록만 훑어도 "지금 어떤 대화가 비용을 많이 쓰는지(토큰), 어떤 대화가 오래 방치됐는지(업데이트됨), 지금 도는 중인지(상태)"를 바로 가려낼 수 있게 하기 위해서다. 한 가지 함정은 세션 키와 클라이언트 이름표를 헷갈리는 것이다 — openclaw-tui 같은 접속 클라이언트 표시 이름은 세션 키가 아니라서, 그걸로 세션을 지목하면 빗나간다. 그래서 무슨 가치인가 — 모든 대화에 식별 가능한 이름표가 붙고 핵심 상태가 한 줄에 모이니, 앞서 본 "지금 뭐가 떠 있는지 모르는" 통제 문제가 곧장 풀린다.

세션별 오버라이드 — 같은 봇, 대화마다 다른 두뇌

Sessions 탭의 진짜 핵심은 세션마다 다른 설정을 줄 수 있다는 것이다. 가장 자주 만지는 건 다섯 가지다 — model(어떤 LLM을 쓸지)은 채팅 헤더의 모델 선택기에서 바꾸고, thinking(생각수준, 깊게 추론할지), fast(빠름, 속도를 우선할지), verbose(상세, 자세한 출력을 낼지), reasoning(추론, 추론 강도)은 목록 화면에 인라인 드롭다운으로 바로 붙어 있다. (이 밖에 trace·elevated 같은 오버라이드 필드도 내부적으로 존재하지만 목록 컬럼으로는 노출되지 않는다.) 이 값들의 공통점은 한 번의 답변에만 적용되고 마는 게 아니라, 그 세션에 계속 붙어 있는 지속 설정이라는 것이다. 각 드롭다운에는 inherit 선택지가 있는데, 이걸 고르면 그 세션은 오버라이드를 비우고 부모격 기본 설정(에이전트 기본값 → 전역 기본값)을 그대로 따른다. 이 부모격 기본값은 Sessions 보드에 떠 있는 게 아니라 OpenClaw 설정 파일에 정의돼 있다 — 에이전트별 설정(agents.list[])을 먼저 보고, 그 항목이 없으면 전역 기본값(agents.defaults)으로 떨어진다. 즉 세션 오버라이드를 inherit으로 비우면 이 config 값으로 되돌아가는 것이다.

다이어그램 설명. 이 그림은 한 에이전트의 기본 설정 위에 세션별로 다른 값을 덮어쓰는 구조를 보여준다. 맨 위 기본 설정에서 세 갈래로 내려가는데, 코드 리뷰 대화에는 비싼 추론 모델에 깊은 사고 모드를 켜 두고, 아침 뉴스 요약 예약 작업에는 빠르고 싼 모델에 속도 우선을 켜 두며, 가벼운 잡담 대화에는 아무 오버라이드 없이 기본값을 그대로 쓴다. 핵심 패턴은 "기본값 + 세션별 덮어쓰기"라는 계층 구조다 — 봇 전체 설정을 한 번 정해 두고, 특별 대우가 필요한 대화에만 예외를 얹는다. 빈 곳(잡담 대화)은 자동으로 기본값을 물려받으므로, 모든 세션을 일일이 설정할 필요가 없다. 놓치기 쉬운 점은 이 오버라이드가 지속된다는 사실이다 — Control UI 채팅 헤더에서 모델을 바꾸면 그 자리 한 번만이 아니라 그 세션 전체에 계속 적용된다(sessions.patch로 즉시 저장). 그래서 무슨 가치인가 — 같은 봇 한 대가 대화마다 다른 두뇌를 갖게 되어, 비싼 추론은 정말 필요한 대화에만 쓰고 나머지는 싸게 처리하니 품질과 비용을 동시에 잡는다.

모델을 갈아끼우는 흐름 — 채팅 헤더에서 즉시 반영

운영 중에 "이 대화는 더 똑똑한 모델이 필요하다"고 판단되면, 채팅 화면 위쪽 모델 선택기에서 바로 바꿀 수 있다. 다만 저장이 끝나기 전에 메시지를 보내면 옛 모델로 답할 수 있는데, OpenClaw는 이 경합을 막아 둔다.

다이어그램 설명. 이 그림은 모델을 바꾼 직후 메시지를 보낼 때의 순서 보장을 보여준다. 채팅 헤더에서 모델을 고르면 세션 설정 저장 요청이 먼저 나가고, 그 저장이 끝나야 메시지 전송으로 넘어간다. 가운데 갈림길이 핵심이다 — 저장이 끝났으면 바로 새 모델로 보내지만, 아직 저장 중인데 사용자가 메시지를 보내려 하면 저장이 완료될 때까지 전송을 붙잡아 둔다. 이 패턴을 둔 이유는 "방금 바꾼 모델인데 옛 모델로 답이 나오는" 혼란을 막기 위해서다. 함정은 이 보장이 없을 때다 — 모델 변경과 메시지 전송이 동시에 날아가면 둘 중 무엇이 먼저 처리될지 알 수 없어, 사용자는 분명 비싼 모델을 골랐는데 싼 모델이 답하는 일이 벌어진다. 그래서 무슨 가치인가 — 운영자가 모델을 바꾸는 순간 그 의도가 다음 답변에 확실히 반영되니, 세션별 모델 제어를 믿고 쓸 수 있다.

결과 — 무엇이 좋아졌나

세션 키와 세션별 오버라이드가 들어오면서 앞서 본 사고들이 이렇게 정리된다.

이전 (한 맥락 · 한 모델)	이후 (세션 키 + 세션별 오버라이드)
채널 간 대화가 한 기록에 뒤섞여 맥락 오염	세션 키로 대화마다 독립된 기록·설정 유지
간단한 작업에도 비싼 추론 모델을 획일 적용	대화별로 model·thinking·fast·reasoning을 따로 지정
지금 어떤 대화가 떠 있는지 운영자가 모름	Sessions 탭에서 키·모델·토큰·활동 시각을 한눈에
모델 변경이 한 번만 적용되거나 경합으로 빗나감	오버라이드는 세션에 지속, 저장 완료 후 전송 보장

정리하면, OpenClaw의 Sessions 메뉴는 "한 대의 봇이 채널·작업마다 다른 두뇌와 다른 기억을 갖게" 만드는 통제판이다. 코드 리뷰 대화에는 깊게 생각하는 비싼 모델을, 아침 뉴스 요약에는 빠르고 싼 모델을 붙여 두고, 잡담은 기본값에 맡긴 채 — 운영자는 목록 화면 하나로 어떤 대화가 살아 있고 얼마나 비용을 쓰는지 본다. 멀티 채널 에이전트에서 가장 먼저 무너지는 게 "맥락이 섞이고 비용이 새는" 지점인데, 세션이라는 단위를 명시적으로 다루는 이 설계가 바로 그 토대를 잡아 준다 — 화려한 대화 능력보다, 여러 대화를 흐트러뜨리지 않고 각자 다른 자원으로 굴리는 이런 "맥락 관리의 기초"가 사실 실용 에이전트의 진짜 전제 조건이다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.