채팅 SDK와 Chat API
가장 기본이 되는 레이어입니다. SDK는 메신저형 화면과 상태 관리를 미리 제공해 빠르게 붙일 수 있고, Chat API는 자체 디자인과 로직에 맞춰 세밀하게 제어할 수 있습니다. 읽음 표시, 전송 확인, 그룹채널, 오픈채널 같은 기능이 여기에 포함됩니다. 대부분의 서비스는 이 레이어에서 시작합니다.
모바일 앱이라면 SDK로 화면과 상태 관리를 줄이고, 자체 UI 규칙이 강한 서비스라면 Chat API로 메시지 저장·정렬·전달 규칙을 직접 다루는 편이 맞습니다. 두 방식을 한 서비스 안에서 나눠 쓰는 팀도 많습니다. 예를 들어 고객센터 화면은 SDK로, 사내 운영 도구는 API로 붙이는 식입니다.
시작점 판단
- 화면과 상태 관리
- Channel SDK 기본 제공
- 메시지 저장·정렬 제어
- Chat API로 직접 구현
- 읽음 표시와 전송 확인
- 두 방식 모두 지원
- 그룹채널 · 오픈채널
- 채널 정책으로 분리
상담원 콘솔
개발자용 API만으로는 운영이 안 됩니다. 상담원이 대기열을 보고, 이력을 확인하고, 여러 채널을 한 화면에서 응대하려면 콘솔이 필요합니다. 앱 채팅과 콘솔이 같은 데이터를 쓰면 "앱에서 하던 대화를 그대로 이어받는" 흐름이 가능해집니다.
대기열과 이력을 한 화면에서
앱에서 들어온 문의와 챗봇이 넘긴 문의가 같은 대기열에 쌓입니다. 상담원이 되돌아가며 찾지 않아도, 앞선 대화가 그대로 붙어 있는 상태에서 응대를 시작할 수 있습니다.
배분 규칙
응대 중인 상담원 수와 대기 시간을 기준으로 문의를 나눕니다. 규칙은 운영 상황에 맞춰 조정합니다.
이력 조회
사용자별 대화와 처리 상태를 시간 순서로 봅니다. 같은 문의가 반복되면 원인을 찾기 쉬워집니다.
채널 통합
앱, 웹, 메신저 채널을 상담원 한 명이 함께 봅니다. 채널을 늘려도 응대 창은 하나로 유지됩니다.
권한 분리
상담원, 운영자, 관리자 역할을 나눠 조회 범위를 제한합니다. 민감한 대화는 접근 권한을 따로 둡니다.
반복 문의는 AI가 먼저 받습니다
복잡한 건은 사람에게 넘깁니다. 이때 AI가 대화 이력과 사용자 상태를 알아야 답이 엉키지 않습니다. Sendbird의 AI 솔루션은 채팅 인프라 위에서 동작하도록 설계되어, 별도 봇을 따로 운영하는 부담을 줄입니다.
상담 자동화가 목표라면 AI 에이전트를 채팅 위에 얹는 조합이 출발점이 됩니다. AI가 먼저 답하고, 확신이 낮은 문의만 상담원 대기열로 보내는 흐름을 만들 수 있습니다. 이때 어떤 문의를 자동 응대에서 제외할지 먼저 정해두면 운영이 흔들리지 않습니다.
옴니채널 구성
앱, 웹, 메신저 채널을 하나의 흐름으로 묶습니다. 사용자가 어디서 시작하든 같은 대화가 이어지게 하는 것이 목표입니다. 채널을 늘리는 것 자체보다, 이력과 맥락이 끊기지 않는 게 중요합니다.
앱에서 시작한 대화가 웹 상담으로 이어지는 흐름
음성·영상으로의 확장
텍스트 상담이 안정되면 통화 요구가 따라옵니다. Sendbird는 메시지와 통화를 함께 다루는 방향을 지원하고, 지연 요구가 까다로운 서비스에는 실시간 통신 전문 스택을 별도로 검토하도록 안내합니다. Agora, LiveKit 같은 도구가 이때 자주 비교됩니다.
통화를 붙이기 전에 정할 것이 있습니다. 어느 대화에서 통화로 넘어갈지, 끊긴 통화를 어떻게 다시 이을지, 통화 기록을 대화 이력 옆에 어떻게 남길지입니다. 이 세 가지가 정해지면 스택 선택이 훨씬 좁혀집니다.
관리와 보안 기능
사용자·채널 권한, 메시지 보관 정책, 감사 로그가 운영 단계에서 중요해집니다. 규제 산업에서는 보관 위치와 접근 통제가 추가 요구로 들어옵니다. 초기 설계에서 이 부분을 정해두면 나중에 구조를 바꾸는 비용을 줄입니다.
실제로 나중에 문제가 되는 지점은 대개 세 곳입니다. 누가 어떤 대화를 볼 수 있는지, 대화를 얼마나 오래 보관하는지, 누가 언제 무엇을 조회했는지입니다. 세 가지를 초기에 문서로 남겨두면 감사 대응과 운영 인수인계가 훨씬 가벼워집니다.
어떤 조합이 맞나
앱 커뮤니티가 중심이면 채팅 SDK와 콘솔 조합이 출발점이 됩니다. 상담 자동화가 목표면 AI 에이전트를 채팅 위에 얹습니다. 통신 채널 확장이 목표라면 Twilio, Vonage API Platform 같은 CPaaS와의 조합도 검토 대상입니다. PubNub처럼 실시간 데이터 동기화에 강한 도구가 필요한 경우도 있습니다.
커뮤니티 중심 앱
채팅 SDK + 상담원 콘솔
사용자끼리 대화가 오가는 앱이라면 채널 구조와 읽음 표시가 먼저입니다. 운영 인력이 같은 데이터를 보는 콘솔을 함께 붙이면 신고와 문의 대응이 한 흐름으로 정리됩니다.
상담 자동화 목표
채팅 위에 AI 에이전트
반복 문의 비중이 높다면 AI가 먼저 받고 사람에게 넘기는 구조가 맞습니다. 대화 이력에 접근할 수 있어야 답이 엉키지 않습니다.
채널 확장 목표
CPaaS 병행 검토
문자, 음성, 외부 메신저까지 한 번에 다뤄야 한다면 Twilio, Vonage API Platform 같은 CPaaS를 함께 비교합니다. 어디까지 Sendbird로 처리할지 먼저 정하는 편이 좋습니다.
도입 순서 잡기
한 번에 다 붙이기보다, 채팅 → 콘솔 → AI → 통화 순으로 단계를 나누는 팀이 많습니다. 각 단계에서 무엇을 검증할지 정해두면 이후 확장이 안정적입니다. 문의 페이지에서 현재 단계에 맞는 구성을 함께 논의할 수 있습니다.
도입 문의하기- 1 채팅부터 붙이고 읽음 표시와 전송 확인을 검증합니다 가장 먼저 사용자가 실제로 보는 화면입니다. 메시지 순서와 상태 표시가 기대대로 움직이는지 확인합니다.
- 2 콘솔을 열어 대기열과 이력이 같은 데이터를 보는지 확인합니다 앱에서 하던 대화를 상담원이 그대로 이어받을 수 있어야 합니다. 이 단계에서 권한 역할도 함께 정합니다.
- 3 AI 에이전트를 얹고 사람에게 넘기는 조건을 정합니다 자동 응대에서 제외할 문의 유형을 먼저 정해두면, 운영자가 결과를 예측할 수 있습니다.
- 4 통화 요구가 확인되면 음성·영상 스택을 검토합니다 지연 요구가 까다로운 서비스는 실시간 통신 전문 스택을 별도로 비교하는 편이 안전합니다.
자주 나오는 질문
채팅 SDK와 Chat API를 같이 쓸 수 있나요?
네. 화면이 정해진 영역은 SDK로, 자체 UI 규칙이 강한 영역은 API로 붙이는 식으로 나눠 쓸 수 있습니다. 두 방식이 같은 채널 데이터를 보므로 상담원 콘솔에서는 하나의 대화로 이어집니다.
AI 에이전트를 붙이려면 별도 봇을 운영해야 하나요?
아닙니다. AI 솔루션이 채팅 인프라 위에서 동작하도록 설계되어 있어, 대화 이력과 사용자 상태를 그대로 참조합니다. 별도 봇을 따로 운영하며 맥락을 맞추는 작업을 줄이는 것이 목적입니다.
통화 기능은 언제 검토하는 게 좋나요?
텍스트 상담이 안정된 뒤가 일반적입니다. 통화 연결 조건, 통화 기록을 대화 이력에 남기는 방식, 지연 허용 범위를 먼저 정하면 스택 선택이 좁혀집니다.
보관 정책과 권한은 언제 정해야 하나요?
첫 설계에서 정하는 편이 비용이 적습니다. 대화를 얼마나 보관하는지, 누가 조회할 수 있는지, 변경 기록을 어떻게 남기는지가 뒤에 구조를 바꾸는 원인이 됩니다.
더 구체적인 비교가 필요하면 고객 사례에서 실제 구성 사례를 확인하거나, 문의 페이지에서 현재 단계를 함께 정리할 수 있습니다.
지금 단계에 맞는 구성을 함께 정리합니다
채팅만 필요한지, 상담 자동화까지 갈지, 통화까지 확장할지에 따라 조합이 달라집니다. 현재 운영 상황과 목표 시점을 알려주시면 단계별로 정리해 드립니다. 평일 09:00–18:00에 응대하며, 주말과 공휴일은 운영하지 않습니다.