일하는 ai

20. DM 대화 섞일 때 dmScope부터 바꾸기

16 min read

-

여러 사람이 DM으로 OpenClaw에게 말을 거는데, 가끔 남의 맥락이 섞여 들어온 것처럼 보이는 답변이 나오면 모델이 갑자기 이상해진 게 아니라 세션 묶음 방식을 먼저 의심하는 편이 맞다. OpenClaw 공식 세션 문서 기준으로 direct message는 기본값에서 main 세션으로 묶일 수 있고, 이 상태를 그대로 두면 여러 사용자가 같은 대화 문맥을 공유하게 된다.

이 문제는 복잡한 디버깅보다 설정 한 줄이 더 중요하다. 핵심은 지금 DM이 어떻게 묶이고 있는지 확인하고, 다중 사용자 환경이면 session.dmScope를 per-channel-peer 또는 per-account-channel-peer로 바꾸는 것이다. 공유 inbox를 쓰는 운영자라면 이 글 하나만 알아도 사고 확률이 크게 줄어든다.

먼저 결론만 보면

  • 기본 dmScope: "main"은 한 사람만 쓰는 개인 비서형 환경에는 편하다.
  • 하지만 여러 사람이 DM을 보낼 수 있으면, 기본값 그대로 둘수록 문맥 혼선 위험이 커진다.
  • 공식 문서는 다중 사용자 inbox에서 per-channel-peer를 권장한다.
  • 계정이 여러 개면 per-account-channel-peer가 더 안전하다.
  • 같은 사람이 여러 채널에서 들어오면 session.identityLinks로 묶는 방식까지 같이 봐야 한다.
flowchart LR
A[여러 사용자가 DM 전송] --> B{dmScope가 main 인가?}
B -- 예 --> C[같은 메인 세션 공유]
C --> D[문맥 혼선 또는 정보 노출 위험]
B -- 아니오 --> E[보낸 사람 단위로 세션 분리]
E --> F[대화 맥락 안정화]
F --> G[security audit로 재검증]

칠판 치트시트

  1. DM을 한 사람만 쓰는지, 여러 사람이 쓰는지 먼저 구분한다
  2. 여러 사람이 쓰면 dmScope: "main" 유지가 위험해질 수 있다
  3. 보통은 per-channel-peer, 다중 계정이면 per-account-channel-peer가 안전하다
  4. 변경 후 openclaw security audit로 다시 확인한다
  5. remote mode면 실제 세션 기준은 gateway host다

왜 이런 문제가 생기나

공식 Session Management 문서에 따르면 OpenClaw는 direct chat을 기본적으로 agent:<agentId>:<mainKey> 형태의 메인 세션으로 다룰 수 있다. 이 기본값은 한 사람이 계속 같은 비서와 대화하는 환경에는 자연스럽다. 이전 대화를 이어받기 쉽고, 맥락도 길게 유지할 수 있기 때문이다.

문제는 이 기본값이 다중 사용자 inbox와 만나면 생긴다. 같은 문서의 Secure DM mode 설명처럼, Alice와 Bob이 모두 같은 에이전트에게 DM을 보내는 환경에서 dmScope가 main이면 두 사람이 같은 세션 맥락을 공유할 수 있다. 그 상태에서 Bob이 “우리가 아까 무슨 얘기했지?”라고 물으면, 의도치 않게 Alice 쪽 맥락이 섞일 가능성이 생긴다.

공식 security audit 문서도 이 점을 따로 경고한다. 여러 DM 발신자가 메인 세션을 공유하면 audit가 secure DM mode를 권장하고, 공유 inbox 운영이라면 session.dmScope="per-channel-peer" 또는 상황에 따라 per-account-channel-peer로 바꾸라고 안내한다.

어떤 값을 고르면 되나

선택은 복잡해 보이지만, 실제로는 운영 구조만 보면 된다.

1) 한 사람만 쓰는 개인 비서형

이 경우에는 기본 main이 오히려 편하다. 여러 채널에서 들어오는 대화를 길게 이어받는 연속성이 중요하고, 다른 사람과 문맥이 섞일 걱정이 거의 없기 때문이다.

다만 이 모드가 안전한 전제는 분명하다.

  • 실질 사용자 1명
  • pairing/allowlist가 좁게 관리됨
  • 다른 사람이 DM으로 들어올 가능성이 낮음

2) 여러 사람이 같은 에이전트에게 DM하는 공유 inbox

이 경우는 공식 문서 기준으로 per-channel-peer가 가장 먼저 볼 값이다. 같은 채널 안에서도 보낸 사람 단위로 세션을 끊어 문맥이 섞이지 않게 하는 방식이기 때문이다.

{
  session: {
    dmScope: "per-channel-peer",
  },
}

예를 들어 Telegram DM 두 명, Slack DM 두 명이 각각 들어오는 구조라면, 이 설정 하나만으로도 “누가 남긴 맥락인지”가 섞일 가능성이 크게 줄어든다.

3) 같은 채널 안에 계정이 여러 개인 환경

공식 세션 문서는 multi-account inbox라면 per-account-channel-peer를 권장한다. 같은 채널이라도 어느 계정으로 들어온 DM인지까지 구분해야 더 안전하기 때문이다.

{
  session: {
    dmScope: "per-account-channel-peer",
  },
}

이 구조는 예를 들어 같은 WhatsApp 계정이 아니라 default, biz, personal처럼 여러 계정을 돌리는 환경에서 특히 유용하다.

4) 같은 사람이 여러 채널에서 들어오는 경우

이때는 반대로 너무 잘게 쪼개져서 불편할 수 있다. 공식 세션 문서에서는 이런 경우 session.identityLinks를 써서 provider-prefixed peer id를 하나의 정체성으로 매핑하라고 설명한다.

즉, 안전하게 분리하되 “같은 사람은 같은 사람으로 이어받고 싶다”면 dmScope만 볼 게 아니라 identityLinks까지 같이 설계해야 한다.

실제 변경 순서

운영자는 아래 순서대로 하면 된다.

1) 먼저 현재 환경이 개인용인지 공유용인지 판정

아래 중 하나라도 맞으면 공유 inbox 쪽으로 보는 게 안전하다.

  • pairing 승인된 DM 발신자가 2명 이상
  • dmPolicy: "open" 또는 넓은 allowlist 사용
  • 여러 번호/계정에서 DM을 받을 수 있음
  • 운영자가 “이 채널은 나만 쓴다”를 확실히 말하기 어려움

이 기준은 공식 Session Management와 security audit 설명과도 맞는다.

2) ~/.openclaw/openclaw.json에서 session.dmScope 조정

예시는 가장 자주 쓰는 per-channel-peer 기준으로 보면 된다.

{
  session: {
    dmScope: "per-channel-peer",
  },
}

JSON5 형식이라 주석과 trailing comma를 허용한다는 점은 공식 Configuration Reference에도 나와 있다.

3) 필요한 경우 identityLinks까지 설계

운영자가 실제로 원하는 게 “아무나 다 한 세션”은 아니고 “같은 사람만 같은 맥락 유지”라면, 채널별 분리 뒤 필요한 사람만 identity mapping으로 다시 묶는 것이 안전하다.

이 순서를 반대로 가면 위험하다. 처음부터 다 묶어 놓으면 누가 누구인지 구분이 흐려지기 때문이다.

4) openclaw security audit로 재확인

openclaw security audit

공식 security 문서 기준으로 audit는 다중 DM 발신자가 메인 세션을 공유하는 구성을 감지하고, secure DM mode 권고를 보여준다. 설정을 바꾼 뒤 이 명령으로 다시 확인하면 “내가 의도한 분리”가 맞는지 검증하기 좋다.

상황별 바로 가기

이 문서는 DM 세션 분리 문제를 중심으로 다루지만, 실제 운영에서는 권한·전달·gateway 상태가 같이 얽히는 경우가 많다. 아래 링크를 같이 보면 문제를 더 빨리 자를 수 있다.

현장 미니 사례 3개

사례 A) 가족/팀원이 같은 봇에게 DM을 보내는 환경

  • 상황: owner 말고도 몇 명이 DM으로 물어본다.
  • 문제: 기본 main 세션이면 이전 사용자의 맥락이 다음 사용자에게 비칠 수 있다.
  • 처리: per-channel-peer로 전환 후 audit 확인
  • 사용자별 문맥이 안정적으로 분리됨

사례 B) 비즈니스 계정과 개인 계정을 같이 운영하는 환경

  • 상황: 같은 채널 종류지만 계정이 둘 이상이다.
  • 문제: sender만 보고 끊으면 계정 경계가 흐려질 수 있다.
  • 처리: per-account-channel-peer로 상향
  • 계정/채널/발신자 3축으로 세션이 더 안전하게 분리됨

사례 C) 같은 사람이 Telegram과 Slack 둘 다 쓰는 환경

  • 상황: 보안 때문에 분리했더니 이번엔 같은 사람 문맥이 너무 끊긴다.
  • 문제: 안전성은 좋아졌지만 연속성이 과하게 줄어듦
  • 처리: 기본은 분리 유지, 필요한 사용자만 identityLinks로 연결
  • 무분별한 공유 없이 필요한 연속성만 회복

remote mode에서 특히 더 조심해야 하는 이유

공식 세션 문서는 세션 상태의 source of truth가 gateway라고 설명한다. 즉, remote mode에서는 내 로컬 앱이나 브라우저가 아니라 gateway host 쪽 세션 store가 기준이다.

그래서 “내 맥에서는 대화가 따로 노는 것 같은데 서버에서는 섞인다” 같은 장면이 보이면, UI 감각보다 gateway 기준 설정과 실제 세션 상태를 먼저 봐야 한다. 이 문제를 로컬 체감으로만 판단하면 원인을 놓치기 쉽다.

이렇게 확인되면 거의 복구다

아래 4개가 맞으면, 운영 기준으로는 상당히 안정화된 상태로 봐도 된다.

  • 다중 사용자 DM에서 이전 사용자 맥락이 섞인 답변이 재현되지 않는다.
  • openclaw security audit가 secure DM mode 관련 경고를 줄이거나 해소한다.
  • 필요한 경우에만 identityLinks를 통해 같은 사람 맥락이 이어진다.
  • remote mode라면 gateway host 기준 설정과 실제 동작이 일치한다.

재발 방지 팁

  • “개인용 비서”에서 “공유 inbox”로 바뀌는 순간, 가장 먼저 dmScope를 다시 본다.
  • 여러 사람에게 pairing 승인을 늘리는 순간도 설정 재점검 시점으로 잡는다.
  • 같은 사람 연속성은 identityLinks로 회복하고, 기본값은 분리 쪽을 먼저 택한다.
  • 보안 점검 루틴에 openclaw security audit를 넣어 두면 운영 중 뒤늦게 바뀐 위험 구성을 빨리 잡을 수 있다.

한 줄 결론

DM 대화가 섞이는 문제는 모델 품질보다 세션 경계 설정 문제인 경우가 많다.
여러 사람이 DM을 보낼 수 있는 환경이라면 session.dmScope를 먼저 per-channel-peer 또는 per-account-channel-peer로 바꾸고, 필요한 연속성만 identityLinks로 복원하는 쪽이 가장 안전하다.

내부링크·다음글 연결 (10)

  1. 20. 운영아키텍처 규칙총정리
  2. 22. 텔레그램 그룹 협업 세팅 보안
  3. 23. node-run plaintext ws 보안에러 해결
  4. 32. HEARTBEAT_OK 반복응답 해결
  5. systemd 충돌) 해결
  6. 37. Scheduled reminder 떴는데 액션이 안 이어질 때
  7. 38. 14시 할일이 자동 실행 안 될 때
  8. 43. cron은 돌았는데 텔레그램 전달이 안 올 때
  9. 45. 채팅 URL 자동저장 안 될 때 inbox·hook부터 점검
  10. 🚀 OpenClaw 인덱스

다음 추천 읽기: 22. 텔레그램 그룹 협업 세팅 보안

※ 이 문서는 생성형 AI를 활용해 작성되었습니다.

그래프 뷰

백링크