본문으로 건너뛰기

상담 분석은 AI 비서에게 — 설치형 Buzz와 서버리스 OpenAI dots로 카카오 상담 잇기

개울가 마을 그림 — 멀리 왼쪽에는 창문이 똑같이 늘어선 커다란 회색 공용 건물이 서 있고, 오른쪽 가까이에는 팀이 직접 지은 아담한 나무집이 있다. 돌다리 캐릭터가 개울에 걸친 채 편지 묶음을 나무집 창으로 건네고, 창 안에서는 헤드셋을 쓴 상담원과 작은 AI 에이전트(작은 로봇으로 그림)가 같은 둥근 탁자에 앉아 펼쳐 놓은 편지를 함께 들여다본다. 에이전트는 돋보기와 메모판을, 상담원은 펜을 들고 있다. 청록색 문 옆 고리에는 작은 열쇠가 걸려 있고, 몸 전체가 노란 말풍선인 손님이 왼쪽 앞에서 반갑게 손을 흔든다

그림으로 말하면 — 고객의 편지가 큰 공용 건물로 가지 않고 우리가 지은 집으로 옵니다. 열쇠는 우리가 갖고 있습니다. 집 안에서는 상담원과 AI 에이전트가 같은 탁자에 앉아 편지를 함께 읽습니다. 답장은 상담원이 씁니다.

🎬 Buzz가 어떤 메신저인지 영상으로 먼저 보시려면 — 요즘 가장 핫한 AI툴 Buzz, 클로드코드·코덱스를 한 팀으로 쓰는 법! (시민개발자 구씨). 사람과 AI 에이전트가 한 채널에서 일하는 모습을 직접 볼 수 있습니다.

이 글은 개발자(톡브릿지를 자체 시스템에 붙이는 분)를 위한 글입니다.

• Block이 공개한 오픈소스 팀 메신저 Buzz는 사람과 AI 에이전트가 같은 채널의 멤버로 함께 일하는 공간이고, 우리 서버에 직접 세울 수 있습니다. • 톡브릿지 CLI 1.3.1부터 카카오 상담을 Buzz 채널로 받을 수 있습니다. 아직 클로즈 베타라 CLI에서만 됩니다. 상담 1건이 스레드 하나가 되고, 스레드에 단 답은 고객에게 갑니다. • 상담 기록을 외부 SaaS(Software as a Service, 빌려 쓰는 클라우드 서비스)에 맡기지 않고 우리 메신저에 두고, 그 채널을 읽을 수 있는 AI 에이전트에게 분석을 맡기는 구성을 예시 장면으로 보여 드립니다. 그 대가로 치러야 하는 구축과 운영도 함께 적었습니다. 반대편 끝에 있는, 구축이 전혀 필요 없는 OpenAI의 AI 비서 dots에서도 톡브릿지 상담을 분석할 수 있다는 것을 실제 화면으로 확인했습니다.

이 편의 낱말 6개

  • 구축형 메신저(셀프호스팅) — 메신저 회사의 서버를 빌려 쓰지 않고, 우리 서버에 직접 설치해 운영하는 메신저. 대화 기록이 우리 데이터베이스에 쌓입니다.
  • 서버리스 AI 비서 — 우리가 서버를 세우지 않아도 제공사의 클라우드에서 돌아가는 AI 비서. 이 글에서는 OpenAI의 dots가 그 예입니다. 구축은 필요 없지만, 일은 제공사의 컴퓨터에서 합니다.
  • 릴레이(relay) — Buzz의 서버. 메시지를 받아 저장하고 채널 멤버에게 나눠 줍니다. Buzz를 구축한다는 말은 이 릴레이와 릴레이가 쓰는 저장소들을 띄운다는 뜻입니다. 이 릴레이에 가입된 사람을 이 글에서는 "릴레이 멤버"라고 부릅니다.
  • 게이트웨이 — 여러분 PC나 서버에서 도는 톡브릿지 CLI의 상주 프로그램. 카카오 상담을 Buzz 채널로 옮기고, 스레드에 달린 답을 카카오로 보냅니다.
  • 채널 멤버십 — 누가 어느 채널에 들어와 있는가. Buzz에서는 이것이 곧 읽을 수 있는 범위입니다. 사람이든 AI 에이전트든 같습니다. 릴레이에 가입하는 것과 채널에 들어가는 것은 별개의 단계입니다.
  • AI 에이전트 — 채널의 대화를 읽고 요청받은 일을 하는 프로그램. Buzz에서는 사람처럼 자기 이름과 키를 갖고 채널에 초대됩니다. 그림에서 작은 로봇으로 그린 것이 바로 이 에이전트입니다.

1. 이런 순간이 있으셨나요​

카카오 상담을 팀 메신저로 받는 구성을 검토하다 멈추신 분들께 이런 말을 들었습니다.

💬 "Slack으로 받으면 편한 건 압니다. 그런데 고객 상담 기록이 외부 메신저 회사 서버에 쌓인다고 하니 보안 검토에서 막혔어요."

💬 "사내에 이미 AI 에이전트를 돌리고 있는데, 상담 내용을 보여 주려면 결국 복사해서 붙여 넣어야 하더라고요."

우리 팀에 맞는 상담 창구 고르기 편에서 저희는 Discord와 Slack을 첫 협업 창구로 고른 이유를 적고, 지원하는 메신저를 계속 넓혀 가겠다고 말씀드렸습니다. 그 뒤 처음 더한 메신저는 뜻밖에도 팀이 직접 세우는 쪽입니다.

쉽게 말해 Slack은 큰 건물에 세 든 사무실이고, Buzz는 우리 땅에 지은 사무실입니다. 열쇠를 우리가 갖는 대신 청소와 수리도 우리가 합니다. 이 글은 그 사무실에 카카오 상담을 들이고, 같은 방에 앉은 AI 에이전트에게 상담을 읽혀 분석을 맡기는 이야기입니다. 5절에서는 정반대로 사무실을 아예 짓지 않는 길, 요즘 한창 화제인 서버리스 AI 비서도 함께 보겠습니다.

2. Buzz는 어떤 메신저인가​

Buzz는 결제 회사 Block(Square를 만든 회사입니다)이 2026년 7월 21일에 공개한 팀 협업 공간입니다. 겉모습은 익숙합니다. 채널과 스레드, DM(다이렉트 메시지), 음성 회의, 파일 공유가 있고 코드 저장소와 자동화 워크플로우까지 한 화면에 들어 있습니다. 코드는 Apache 2.0 라이선스로 공개돼 있습니다.

익숙한 메신저와 갈리는 지점은 하나입니다. Buzz는 AI 에이전트를 봇이 아닌 멤버로 대합니다. 저장소 첫 화면의 문장이 "Agents are members, not bots."입니다. 에이전트도 사람처럼 자기 키(신원)를 받고, 채널에 초대되고, @멘션을 받으면 일하고, 한 일이 서명된 기록으로 남습니다. 사람을 채널에 넣는 방법과 에이전트를 넣는 방법이 같습니다. Claude Code, Codex, goose처럼 이미 쓰는 에이전트를 붙일 수 있고 특정 모델에 묶이지 않습니다.

왜 이런 걸 만들었는지는 Block 엔지니어링 블로그의 한 문장이 잘 보여 줍니다.

"Models can do the work now. Teams still need somewhere to do it together." (이제 일은 모델이 할 수 있다. 그래도 팀에는 그 일을 함께 할 자리가 필요하다.)

같은 글에서 Block은 팀이 에이전트의 신원과 대화 이력, 작업물을 특정 업체에 기대지 않고 직접 갖고 있어야 한다고 말합니다. 실제로 Block 안에서는 판단을 맡은 에이전트 하나가 더 싸고 빠른 에이전트 여럿에게 일을 나누고, 사람은 결과를 기다리지 않고 채널에서 중간에 방향을 고쳐 주는 식으로 쓴다고 합니다.

기술적으로는 Nostr라는 공개 프로토콜 위에서 돕니다. 메시지 하나, 반응 하나가 모두 서명된 이벤트이고, 릴레이라고 부르는 서버가 그 이벤트를 Postgres에 쌓습니다. 실시간 전달에는 Redis, 파일 보관에는 S3 호환 저장소(Amazon S3와 같은 방식으로 파일을 넣고 꺼내는 저장소)를 씁니다. 그래서 Buzz를 직접 구축한다는 말은 릴레이, Postgres, Redis, 파일 저장소 네 가지를 우리 서버에 띄운다는 뜻이 됩니다. 낯선 이름이 많지만 Docker Compose 파일 하나로 함께 뜨니, 설치보다는 운영이 더 큰 일입니다. Buzz 연결 절차만 먼저 보시려면 6절로 건너뛰셔도 됩니다.

설치는 공식 자료가 잘 정리돼 있어 링크로 대신합니다.

같은 buzz.xyz에서 Block이 직접 운영하는 무료 커뮤니티에 들어갈 수도 있습니다. 다만 Block의 지원 페이지는 그쪽 대화가 종단간 암호화되지 않으며 운영·보안·법적 필요가 있을 때 Block이 내용에 접근할 수 있다고 밝힙니다. 상담 기록을 우리 쪽에 두려는 이 글의 목적과는 길이 다르니, 아래에서는 직접 구축한 릴레이를 전제로 이야기하겠습니다.

3. 빌린 땅과 우리 땅, 무엇이 다른가​

같은 상담이 어디에 쌓이느냐의 차이입니다. 표로 먼저 놓고 하나씩 풀어 보겠습니다.

Slack · Discord (SaaS형)Buzz 직접 구축 (구축형)
상담 기록이 쌓이는 곳메신저 회사 서버우리 서버의 데이터베이스
톡브릿지와 잇는 방법센터의 설치 버튼(코드 없음) 또는 CLICLI 게이트웨이만 (클로즈 베타)
미리 준비할 것워크스페이스 하나서버 · 도메인 · TLS 인증서 · 백업
AI 에이전트봇·앱으로 연결채널 멤버로 초대 (자기 신원·서명 기록)
상담 마무리 명령(cs-close 등)있음아직 없음
기업용 기능(보존 정책 · 유출 방지 · 감사 연동)성숙함아직 1.0 이전, 컴플라이언스 체계 없음
장애가 나면메신저 회사 몫우리 팀 몫

구축형을 찾는 팀이 가장 먼저 보는 것은 상담 기록이 쌓이는 곳입니다. 고객이 카카오톡으로 보낸 문장이 외부 SaaS를 거치지 않고 우리 데이터베이스에 남습니다. 보안 검토에서 "외부 메신저에 고객 데이터가 쌓인다"는 이유로 막혔던 팀이라면 이 한 줄로 이야기가 달라질 수 있습니다.

상담이 쌓이는 그 채널에 팀의 AI 에이전트가 이미 멤버로 앉아 있을 수도 있습니다. 그러면 상담 내용을 에이전트에게 보여 주려고 복사해 붙여 넣을 필요가 없어집니다. 4절의 예시 장면이 이 이야기입니다.

대가도 분명합니다. 서버를 세워야 하고, 세운 뒤에는 계속 돌봐야 합니다. 직접 구축 안내서들은 Linux 서버 2코어·4GB 메모리 정도를 최소로 잡고, 도메인과 HTTPS, 매일 밤 데이터베이스 백업, 주기적인 업데이트를 권합니다(외부 가이드 기준입니다). 장애가 나면 새벽에 일어나는 사람도 우리 팀입니다.

톡브릿지 쪽에서도 할 일이 하나 늘어납니다. Slack·Discord는 센터의 설치 버튼만 누르면 저희 쪽 서버가 상담을 옮겨 주지만, Buzz는 지금 CLI 게이트웨이로만 연결됩니다. 게이트웨이를 여러분 PC나 서버에 계속 띄워 두셔야 합니다.

Buzz 자체도 아직 젊습니다. 출시 석 달이 안 됐고, 워크플로우 승인 기능 일부와 모바일 앱이 진행 중이며, 권한은 채널 멤버십 단위로만 나뉩니다. 한 리뷰어는 지금의 Buzz를 "Slack 대체품보다는 작고 격리된 에이전트 실험실"로 시작하라고 권했습니다. 기업 신원 관리나 데이터 보존 정책 같은 영역에서는 Slack이 훨씬 앞서 있다는 평가도 함께 남겼고, 저희도 그 말에 동의합니다.

메신저를 우리 서버에 두었다고 모든 데이터가 안에 머무는 것은 아닙니다. 채널에 들어온 AI 에이전트가 외부 회사의 언어 모델을 부른다면, 에이전트가 분석하는 순간 상담 내용은 그 모델 회사로 갑니다. 상담에 개인정보가 섞인다면 에이전트가 어떤 모델을 쓰는지, 그 회사의 데이터 보관 정책은 어떤지까지 함께 보셔야 합니다. 사내에서 돌리는 모델을 붙이는 팀이라면 이 걱정이 줄어듭니다.

그래서 어떻게 고르면 될까요. 상담 기록이 어디에 있느냐가 도입 조건이라면 구축형을 검토할 만합니다. 그 조건이 없다면 Slack이나 Discord가 훨씬 빠르고 편합니다. 둘 중 하나만 고를 필요도 없습니다. CLI 게이트웨이는 Slack·Discord·Buzz·웹훅으로 같은 상담을 함께 보낼 수 있어서, Buzz를 시험하는 동안 기존 창구를 그대로 켜 두셔도 됩니다.

4. 예시 장면 — 상담 채널을 읽는 AI 에이전트에게 분석 맡기기​

구성은 이렇습니다.

톡브릿지 게이트웨이는 #카카오-상담 채널(이하 상담 채널)에 상담을 올립니다. 팀이 Buzz에 미리 등록해 둔 분석 에이전트는 이 채널의 멤버라서 상담을 읽을 수 있습니다. 분석을 시키고 답을 받는 일은 #상담-분석이라는 별도 채널(이하 분석 채널)에서 합니다. 왜 굳이 채널을 나누는지는 장면 다음에 말씀드리겠습니다.

○○베이커리의 어느 오후를 예로 들어 보겠습니다(가상의 가게와 고객입니다). 이 가게는 분석 에이전트에게 "분석봇"이라는 이름을 붙여 두었습니다. 상담 채널에는 상담마다 고객 식별자(Ab3d_x9Kq2Lm처럼 생긴 문자열)를 적은 글이 하나씩 올라오고, 그 글의 스레드에 고객의 메시지가 차례로 달립니다. 고객 메시지도 실제로는 톡브릿지 봇 이름으로 올라오는데, 아래에서는 알아보기 쉽게 "고객"이라고 적었습니다.

#카카오-상담
 ├ 톡브릿지 봇: Ab3d_x9Kq2Lm
 │   └ 고객: 내일 케이크 픽업 시간을 3시로 바꿀 수 있나요?
 │   └ 매니저: 네, 3시로 바꿔 두었습니다.
 ├ 톡브릿지 봇: Qe7Zp_41sTvw
 │   └ 고객: 어제 받은 케이크가 뭉개져 왔어요. 환불 되나요?
 │   └ 매니저: 죄송합니다. 상태를 볼 수 있게 사진 한 장 보내 주시겠어요?
 └ 톡브릿지 봇: mN2c-8RyLx0a
     └ 고객: 주문 취소하고 싶어요

#상담-분석
 매니저: @분석봇 오늘 #카카오-상담에서 환불·취소 문의만 골라 고객별로 한 줄씩 정리해 줘.
         아직 답이 안 나간 건 따로 표시하고.
 분석봇: 오늘 환불·취소 문의는 2건입니다.
         · Qe7Zp_41sTvw 배송 중 파손으로 환불 요청. 매니저가 사진을 요청했고 고객 답을 기다리는 중
         · mN2c-8RyLx0a 주문 취소 요청. 아직 답이 나가지 않았습니다 (14:02 수신)
 매니저: @분석봇 mN2c-8RyLx0a 에 보낼 답 초안 써 줘. 취소 규정은 #운영-공지에 있어.
 분석봇: 초안입니다.
         "안녕하세요, ○○베이커리입니다. 제작에 들어가기 전 주문은 바로 취소해 드릴 수 있어요. …"

매니저는 초안을 읽고 문장을 조금 고친 뒤, 상담 채널의 mN2c-8RyLx0a 스레드에 직접 답글로 붙입니다. 그 답글이 카카오로 나갑니다.

분석봇은 상담 채널을 읽기만 하고, 말은 분석 채널에서 합니다. 고객에게 나간 글은 매니저가 상담 스레드에 직접 쓴 것뿐입니다. 초안은 에이전트가 쓰고, 보낼지 말지는 사람이 정합니다.

분석봇이 #운영-공지의 취소 규정을 참고할 수 있었던 것은 그 채널에도 멤버로 들어가 있어서입니다. 반대로 분석봇을 상담 채널에 넣지 않으면 분석봇은 상담을 한 줄도 볼 수 없습니다. Buzz에 들어온 에이전트는 자기가 멤버인 채널을 읽고 그 기록을 바탕으로 일합니다. 무엇을 읽게 할지는 그 에이전트에게 어떤 채널 권한을 주느냐로 정해집니다. 상담을 다룰 에이전트와 다루지 않을 에이전트를 멤버십으로 가르는 것이 가장 간단한 데이터 최소화입니다.

채널을 나눈 데는 이유가 있습니다. 톡브릿지 게이트웨이는 상담 스레드에 달린 답글을 누가 썼는지 가리지 않고 카카오로 보냅니다. 상담원이 쓰든 에이전트가 쓰든 같습니다. 그래서 상담 스레드 안에서 "@분석봇 이 고객 요약해 줘"라고 부르면 그 문장이 고객에게 갑니다. 분석봇이 그 스레드에 요약을 달아도 요약문이 고객에게 갑니다. 상담 채널에 들어간 에이전트는 그 채널에 글을 쓸 수도 있으니, 분석은 분석 채널에서만 한다는 규칙을 팀 안에서 미리 정해 두셔야 합니다.

에이전트를 Buzz에 등록하고 채널에 넣는 방법은 Buzz 쪽 문서를 따르시면 됩니다. 사람을 초대하는 것과 같은 절차입니다.

5. 구축이 필요 없는 반대편, OpenAI dots​

Buzz를 들여다보던 무렵 반대 방향에서도 큰 소식이 나왔습니다. OpenAI가 9월 29일 DevDay에서 개인 AI 비서 dots를 공개했습니다. ChatGPT 안에 이름을 붙여 두고 쓰는 상시형 비서이고, 하나하나를 dot이라고 부릅니다. OpenAI의 설명을 옮기면 dot은 OpenAI가 운영하는 자기 클라우드 컴퓨터와 브라우저를 갖고, 사용자가 정한 목표를 백그라운드에서 이어서 처리합니다. 대화는 ChatGPT와 Slack, Microsoft Teams에서 이어 갈 수 있고, 플러그인으로 4,000개가 넘는 앱에 연결된다고 합니다. 지금은 ChatGPT Pro와 Business Premium 요금제에 첫 dot이 포함되는 방식으로 열려 있습니다(2026년 10월 기준).

Buzz와 나란히 놓으면 둘은 거의 정반대 자리에 서 있습니다.

Buzz (설치형)OpenAI dots (서버리스)
돌아가는 곳우리 서버의 릴레이OpenAI 클라우드, dot마다 클라우드 컴퓨터 하나
구축서버 · 도메인 · 백업 필요필요 없음. 요금제만 있으면 됨
상담 기록이 머무는 곳우리 데이터베이스분석할 때 OpenAI 쪽으로 건너감
일하는 에이전트팀이 고른 에이전트(Claude Code · Codex · goose 등)를 채널 멤버로GPT 기반 개인 비서 dot
톡브릿지와 잇는 방법CLI 게이트웨이 (클로즈 베타)ChatGPT 앱에서 플러그인(MCP) 연결 한 번
드는 비용서버비와 운영 시간ChatGPT Pro · Business Premium 요금제

톡브릿지 쪽에서 보면 dots를 위해 새로 만든 것은 없습니다. 톡브릿지는 이미 MCP(Model Context Protocol, AI 앱이 외부 도구를 불러 쓰는 표준 방식)로 ChatGPT에 연결됩니다. dot에서 톡브릿지를 쓰려면 ChatGPT 앱에서 톡브릿지를 플러그인(MCP)으로 연결하기만 하면 됩니다. dot은 계정에 연결해 둔 플러그인을 그대로 쓰기 때문입니다. 그래서 dot에게 "톡브릿지 대화 분석해 줘"라고 말하면 같은 연결로 상담방을 조회하고 기록을 읽습니다. 정말 그런지 저희도 직접 맡겨 봤습니다.

OpenAI dot에게 톡브릿지 상담 분석을 맡긴 실제 화면. 왼쪽 대화 창에서 사용자가 "진행해죠 톡브릿지 대화분석"이라고 보내자, dot이 톡브릿지에 연결된 상담방을 확인해 분석하겠다고 답한 뒤 연결된 브랜드 1개, 진행 중 상담방 3개와 기록 108개, 9월 15일부터 10월 6일까지의 기간, 수신·발신·삭제·연결 종료 건수를 정리하고, 최근 대화가 실제 고객 문의보다 연동 테스트였다는 점과 추가로 확인할 점을 번호를 매겨 적었다. 오른쪽에는 "내 dot의 컴퓨터" 창이 열려 있고, dot이 쓰는 클라우드 컴퓨터의 바탕화면과 브라우저가 보이며 아래에 "사용자의 dot이 제어 중입니다"와 "제어권 가져오기" 버튼이 있다

왼쪽은 dot과 나눈 대화이고 오른쪽은 dot이 일하는 자기 클라우드 컴퓨터입니다. dot은 톡브릿지에 연결된 상담방을 조회해 기간과 수신·발신 건수를 묶고, 최근 대화가 실제 고객 문의가 아닌 연동 시험이었다는 것까지 알아봤습니다. 화면의 브랜드는 저희 개발용 브랜드이고 대화는 연동 시험 데이터입니다.

화면에서 재미있었던 것은 dot이 숫자만 세지 않았다는 점입니다. 삭제 기록 일부에 짝이 되는 원래 발신 기록이 없다거나, "묶음 일부실패"라는 문구는 시험용 문구라 실제 오류의 증거로 보기 어렵다는 식으로, 더 확인해야 할 곳을 스스로 골라 적었습니다. 4절의 분석봇에게 기대했던 일을 서버 한 대 세우지 않고 받아 본 셈입니다.

그렇다고 dots가 Buzz를 대신하지는 않습니다. 질문이 다릅니다. dot은 분석하는 동안 상담 기록을 OpenAI의 클라우드로 가져갑니다. 상담 기록이 외부로 나가면 안 되는 팀에게는 처음부터 맞지 않는 길입니다. OpenAI는 앱 연결을 끊어도 dot이 그 앱에서 이미 알게 된 내용은 지워지지 않는다고도 안내합니다. 반대로 서버를 세울 여력이 없고 상담 기록을 ChatGPT에서 다뤄도 괜찮은 팀이라면, 오늘 바로 시작할 수 있는 쪽은 dots입니다.

dot에게 분석만 맡기실 때는 규칙을 하나 먼저 걸어 두시길 권합니다. 톡브릿지 MCP에는 상담 조회뿐 아니라 답장 보내기와 상담 종료 같은 도구도 들어 있습니다. dot의 규칙(Custom Rules)에서 톡브릿지의 보내기·종료 동작을 "실행 전에 묻기"나 "막기"로 두면, 분석하다 고객에게 답장까지 보내는 일을 막을 수 있습니다. OpenAI는 사용자가 자리에 없을 때 dot이 알아서 하는 조사는 연결된 앱을 읽기 전용으로만 쓴다고 설명합니다. 다만 사용자가 직접 맡긴 일은 별도의 규칙과 승인 절차를 따르니, 그 규칙을 우리가 정해 두는 편이 안전합니다. 4절에서 상담 채널과 분석 채널을 나눈 것과 같은 이유입니다.

연결은 한 번이면 됩니다. ChatGPT 설정의 커넥터(앱·도구 추가) 메뉴에서 새로 추가를 누르고, MCP 서버 주소 https://mcp.talkbridge.io/mcp를 넣은 뒤 Google 계정으로 한 번 로그인하시면 됩니다. 따로 만들 키나 비밀번호는 없습니다. 자세한 화면은 AI 앱 연결 문서에 있습니다. 연결한 뒤 "내 파트너 정보랑 관리 중인 브랜드 알려줘"라고 물어 브랜드 목록이 나오면 준비가 끝난 것이고, 그다음부터는 dot에게도 같은 말로 일을 맡기시면 됩니다.

6. 준비물​

준비물어디서 확인
운영 중인 Buzz 릴레이 주소(wss://…)직접 구축한 릴레이. 2절 링크 참고
상담을 받을 Buzz 채널의 고유 ID(UUID)Buzz 앱의 채널 정보
Buzz 비밀키(nsec1…) — 릴레이 멤버이고 상담 채널을 관리할 수 있는 사람의 키톡브릿지 봇 신원을 만드는 데 한 번 쓰고, 저장하지 않습니다
톡브릿지 CLI 1.3.1 이상talkbridge --version
쓰기 권한(brand-write)이 있는 톡브릿지 시크릿키로 로그인, 브랜드 하나talkbridge whoami — Slack·Discord 연결과 같은 조건입니다
브랜드 채널키talkbridge whoami가 보여 주는 상담 가능 채널
카카오 채널 연결과 상담 활성화가 끝난 브랜드센터 설정 5단계
(분석용) Buzz에 등록한 AI 에이전트 하나Buzz 문서

Buzz 연결은 아직 클로즈 베타라서 톡브릿지 공식 문서에는 안내가 없습니다. 명령과 옵션은 talkbridge setup --help에서 확인하실 수 있습니다.

7. 따라하기​

1) 설정을 저장합니다.

talkbridge setup --buzz-relay wss://buzz.example.com \
  --buzz-key nsec1... \
  --buzz-channel 1a2b3c4d-0000-0000-0000-000000000000 \
  --buzz-brand <브랜드 채널키>

--buzz-key에는 릴레이 멤버인 사람의 Buzz 비밀키를 넣습니다. CLI는 이 키를 주인(owner)으로 삼아 톡브릿지 전용 봇 신원을 새로 만들고, 그 봇을 상담 채널에 봇 역할로 추가합니다. 이 봇은 분석 에이전트와 달리 상담을 옮겨 적기만 하는 톡브릿지 전용 계정입니다. 덕분에 Buzz 앱에는 상담 글이 여러분 이름 대신 봇 이름으로 올라옵니다. 사람 키는 봇을 만드는 데만 쓰고 설정에 남기지 않습니다. 봇 이름은 기본값이 "TalkBridge 상담"이고 --buzz-bot-name으로 바꿀 수 있습니다.

비밀키를 명령줄에 그대로 치면 셸 기록에 남습니다. talkbridge setup만 입력해 대화형 화면에서 "Outbound · Buzz"를 고르시면 옵션을 외울 필요도 없고 기록도 덜 남습니다.

확인: "buzz 봇 신원을 만드는 중..."에 이어 "✓ 저장 완료"와 Buzz: 채널 … · 봇 "TalkBridge 상담" 줄이 출력되면 된 것입니다.

2) 릴레이 접속을 확인합니다.

talkbridge buzz check

읽기만 하는 명령이라 채널에 아무것도 올리지 않습니다.

확인: 신원이 봇 이름으로 보이고 채널 조회가 성공하면 된 것입니다.

3) 게이트웨이를 띄웁니다.

talkbridge gateway restart
talkbridge gateway status

restart는 돌던 게이트웨이를 멈추고 새 설정으로 다시 띄웁니다. 처음 띄울 때도 그대로 쓰시면 됩니다. status는 실행 중 (pid …) — 로그: <경로> 한 줄만 보여 줍니다. 릴레이 연결에 실패해도 게이트웨이 자체는 계속 돌기 때문에, "실행 중"만 보고 끝내시면 안 됩니다.

확인: status가 알려 준 로그 파일을 열어 "buzz relay 연결됨"과 채널, 봇 이름이 적힌 줄이 보이면 된 것입니다.

4) 시험 상담을 보내 봅니다. 카카오톡에서 여러분 채널로 문의를 하나 보내 보세요.

확인: 상담 채널에 고객 식별자(Ab3d_x9Kq2Lm처럼 생긴 문자열)가 적힌 글이 새로 올라오고, 그 스레드에 방금 보낸 문의가 답글로 달리면 된 것입니다.

5) 사람이 답해 봅니다. 그 스레드에 답글을 답니다.

확인: 몇 초 안에 카카오톡에 답이 도착하면 된 것입니다. 게이트웨이는 Buzz의 새 답글을 3초마다 확인합니다.

6) 분석 에이전트를 붙입니다. Buzz에서 분석 에이전트를 #카카오-상담 채널의 멤버로 추가하고, #상담-분석 채널을 하나 만들어 그 에이전트를 함께 넣습니다. 그다음 4절처럼 #상담-분석에서 에이전트를 멘션해 오늘의 상담을 물어보세요.

확인: #상담-분석에 에이전트의 답이 달리고, #카카오-상담의 상담 스레드에는 아무것도 새로 달리지 않았으면 된 것입니다.

8. 이렇게 하면 막힙니다​

상담 스레드 안에서 에이전트를 부르는 경우. 4절에서 말씀드린 대로, 상담 스레드의 답글은 누가 썼든 고객에게 갑니다. 멘션 문장도, 에이전트의 분석도 마찬가지입니다. 팀원 모두가 "분석은 분석 채널에서"를 알고 있어야 합니다.

아직 클로즈 베타입니다. Buzz 연결은 CLI에서만 됩니다. 센터의 설치 버튼이나 공식 문서 안내는 아직 없고, Slack·Discord에 있는 cs-close·cs-memo·cs-who 상담 명령도 Buzz 스레드에서는 쓸 수 없습니다. 상담을 끝내야 할 때는 지금은 CLI의 talkbridge end-with-bot --channel <브랜드 채널키> --to <고객 식별자>처럼 상담 종료 명령을 써 주세요.

사람 키의 권한이 모자랄 때. 봇 신원을 만들려면 --buzz-key의 주인이 릴레이 멤버여야 합니다. 봇 만들기에 실패하면 CLI는 사람 키를 그대로 저장하고 안내를 띄웁니다. 그 상태로도 상담은 오가지만 상담 글이 본인 이름으로 올라갑니다. 릴레이 관리자에게 멤버 추가를 요청한 뒤 talkbridge buzz bot으로 봇 전환을 다시 시도하세요. 릴레이 멤버이긴 한데 상담 채널을 관리할 권한이 없으면, 봇은 만들어지지만 채널에 들어가지 못했다는 경고가 뜹니다. 이때는 Buzz 앱에서 봇을 채널에 직접 추가하시면 됩니다.

톡브릿지 키 조건이 맞지 않을 때. 시크릿키에 쓰기 권한이 없거나 키 하나에 브랜드가 여럿 묶여 있으면, 게이트웨이는 뜨지만 Buzz 연결만 조용히 꺼집니다. 경고는 게이트웨이 로그에만 남습니다. 3단계에서 로그를 꼭 열어 보셔야 하는 이유이기도 합니다.

게이트웨이가 꺼져 있을 때. 게이트웨이가 꺼져 있으면 상담이 채널로 들어오지 않고, 스레드에 단 답도 고객에게 가지 않습니다. 다시 켜면 밀린 답글을 이어서 보내지만, 1시간보다 오래된 답글은 뒤늦게 엉뚱한 때 도착하지 않도록 버립니다. 이 재시작 처리는 저희도 한 번 데었던 곳입니다. 시험하던 중 게이트웨이를 다시 켰더니 이미 보낸 답글 하나가 카카오로 한 번 더 나갔고, 그 뒤로 어디까지 보냈는지를 더 촘촘히 기록하도록 고쳤습니다. 노트북보다는 늘 켜져 있는 서버에 띄워 두시길 권합니다.

보내지 못한 답이 있을 때. 카카오 세션이 만료됐거나, 고객이 차단했거나, 상담 건수를 다 썼다면 답이 나가지 않습니다. 이때 게이트웨이는 조용히 넘어가지 않고 해당 스레드에 실패 안내를 남깁니다. 일시적인 네트워크 오류는 알아서 몇 번 다시 보내고, 게이트웨이를 재시작해도 그 재시도는 이어집니다. 상담 건수는 상담방이 열린 날 기준(KST)으로 세며, 같은 고객과 같은 날 여러 번 대화해도 1건입니다. 자세한 기준은 요금과 과금 문서에 있습니다.

9. 다음 단계​

Buzz를 처음 시험하신다면 Slack이나 Discord를 그대로 켜 둔 채 Buzz를 두 번째 수신처로 붙여 보세요. 같은 상담이 양쪽에 들어오니 Buzz가 손에 익을 때까지 고객을 놓치지 않습니다.

분석이 손에 익으면 에이전트가 읽을 채널을 조금씩 넓혀 보셔도 좋습니다. 운영 공지, 자주 묻는 질문 정리, 지난 상담 회고 채널에 분석 에이전트를 멤버로 넣으면, 같은 질문에도 근거를 더 갖춘 답을 내놓습니다. 어디까지 읽힐지는 언제나 멤버십으로 정하시면 됩니다.

서버를 세우지 않고 먼저 맛을 보고 싶으시면 dots부터 써 보셔도 됩니다. ChatGPT 앱에서 톡브릿지 플러그인(MCP)을 연결해 두셨다면 dot에게 "오늘 들어온 상담 정리해 줘"라고 말하는 것으로 시작됩니다. 분석이 쓸 만하다고 느껴지고 그 기록을 우리 쪽에 두고 싶어지면, 그때 Buzz를 세우셔도 늦지 않습니다.

톡브릿지가 고객의 카카오톡과 팀의 메신저 사이에 놓은 다리는 지금까지 남이 세운 메신저로만 이어졌습니다. 이번에 처음으로 여러분이 직접 세울 수 있는 오픈 메신저 Buzz로 가는 다리가 놓였습니다. 그리고 반대편 끝에서는 구축이 전혀 필요 없는 서버리스 AI 비서 dots에서도 톡브릿지 상담을 읽고 분석할 수 있다는 것을 확인했습니다. 상담 기록을 어디에 두고 누구에게 분석을 맡길지, 그 선택지가 양쪽으로 한 칸씩 넓어졌습니다.

톡브릿지 센터에서 카드 등록 없이 시작하실 수 있습니다 — 30일 동안 상담 3건이 무료입니다. https://console.talkbridge.io/ · 문서 https://api.talkbridge.io/ · 막히시면 help@talkbridge.io

참고​