사전 점검
시작하기 전에 확인할 것
인증 방식과 API 키 관리부터 봅니다. 사용자와 채널을 어떻게 모델링할지, 메시지 이력을 얼마나 보관할지도 초기에 정합니다. 이 세 가지가 나중에 구조를 좌우합니다.
-
인증과 키
API 키 발급과 환경 분리
애플리케이션별 키를 따로 발급하고, 개발·스테이징·운영 환경의 키를 섞지 않습니다. 클라이언트에 노출되는 키와 서버에서만 쓰는 키의 역할을 먼저 나눠 두면 이후 권한 설계가 단순해집니다.
-
모델링
사용자와 채널을 어떻게 나눌지
상담 1:1, 그룹, 오픈채널은 처음부터 다른 목적입니다. 사용자 식별자를 앱의 계정 체계와 맞춰 두면 이후 프로필·알림·차단 정책을 붙일 때 다시 손대지 않아도 됩니다.
-
정책
메시지 이력 보관 기간 정하기
이력을 얼마나 보관할지는 비용과 검색 경험에 모두 영향을 줍니다. 업무 요건, 감사 요구, 사용자 기대를 함께 놓고 기간과 검색 범위를 초기 결정으로 못 박아 두세요.
SDK와 API, 어디서 시작할까
메신저형 화면을 빠르게 만들려면 SDK가 출발점입니다. 자체 디자인 시스템이 있거나 특수한 흐름이 필요하면 Chat API를 직접 호출합니다. 아래 두 갈래를 나눠 두고, 프로젝트 성격에 따라 고르세요.
SDK 경로
SDK로 빠르게 붙이기
대화 목록, 방 화면, 입력창, 상태 관리를 직접 만들지 않아도 됩니다. SDK의 컴포넌트는 읽음 표시와 전송 확인처럼 놓치기 쉬운 신호를 미리 처리해 두기 때문에, 화면을 단기간에 완성하면서도 상태 불일치를 줄일 수 있습니다. 플랫폼별 지원 범위는 문서에서 확인하세요.
- 메신저형 화면이 필요한 경우 기본 화면 구성으로 바로 시작할 수 있습니다.
- 모바일 앱과 웹 클라이언트를 같은 상태 모델로 다루기 좋습니다.
- 핵심 화면은 SDK로, 특수 흐름은 API로 나눠 쓰는 조합도 흔합니다.
API 경로
API로 세밀하게 제어하기
자체 디자인 시스템이 있거나 특수한 비즈니스 로직이 필요하면 Chat API를 직접 호출합니다. 화면과 상태를 직접 그리는 대신, 메시지 전송·조회·이력 검색을 모두 내가 설계한 흐름 안에서 처리할 수 있습니다.
- UI 통제
- 완전 제어
- 학습 곡선
- 설계 부담 큼
- 적합한 경우
- 특수 흐름 · 자체 디자인
실시간 신호는 화면이 아니라 상태에서 결정됩니다
읽음 표시, 전송 확인, 접속 상태는 사용자 경험을 좌우하는 핵심 신호입니다. 그룹채널의 순서 보장, 오픈채널의 동시 접속 처리도 함께 봐야 합니다. 이 동작을 콘솔과 앱 사이에서 일관되게 맞추는 게 운영 안정성으로 이어집니다.
읽음 · 전송
표시와 확인 신호를 같은 이벤트 흐름에서 처리
접속 상태
온라인·오프라인 변화를 채널 멤버십과 함께 확인
순서 보장
그룹채널 메시지 순서를 서버 기준으로 유지
- 읽음 표시 동기화 그룹채널 A
- 접속 상태 전이 사용자 세션
- 전송 확인 회신 모바일 클라이언트
레퍼런스
샘플 코드와 레퍼런스
문서에는 각 기능의 호출 예시와 레퍼런스가 함께 제공됩니다. 처음에는 샘플 코드를 그대로 돌려 동작을 확인한 뒤, 자체 요구에 맞게 수정하는 편이 빠릅니다. 막히는 지점은 문의로 알려주시면 안내드립니다.
SDK로 대화 화면 구성하기
대화 목록과 방 화면을 SDK의 기본 컴포넌트로 조립하는 예시입니다. 실제 코드를 붙이기 전에 반드시 환경별 키와 사용자 ID 발급 방식이 문서와 일치하는지 확인하세요.
- 1 애플리케이션 키로 클라이언트 초기화
- 2 사용자 ID 등록 후 세션 연결
- 3 채널 목록 조회 후 방 화면 마운트
- 4 이벤트 핸들러 등록 (읽음 · 전송)
메시지 전송 흐름 이해하기
전송 요청이 서버를 거쳐 채널 멤버에게 어떻게 도착하는지 순서를 따라가면 실시간 신호가 어디서 어긋나는지 찾기 쉬워집니다. 실패 응답이 돌아왔을 때 재시도와 사용자 알림을 어떻게 나눌지도 미리 정해 두세요.
- 요청 경로
- 클라이언트 → 서버 → 채널
- 실패 처리
- 재시도와 오류 안내 분리
- 확인 신호
- 서버 수신 · 클라이언트 반영
사용자·채널 초기화 순서
사용자 등록과 채널 생성 순서를 바꾸면 이후 메시지 이력이나 멤버 목록이 다르게 나올 수 있습니다. 처음 만드는 환경에서 순서대로 한 번 돌려 보고, 작업 순서를 팀 문서에 남겨 두는 것이 안전합니다.
- 애플리케이션 준비 후 사용자 등록을 먼저 실행합니다.
- 채널을 만들 때 유형(그룹·오픈·1:1)을 명확히 지정합니다.
- 초기화 완료 후 실제 메시지를 하나 보내 상태를 확인합니다.
AI 연동
AI 기능 연동
상담 자동화를 붙이려면 채팅 이력을 AI가 읽을 수 있어야 합니다. Sendbird의 AI 솔루션은 같은 대화 데이터 위에서 동작하도록 설계되어, 별도 봇 데이터를 따로 관리하는 부담을 줄입니다. 기존 채팅 흐름을 만들었다면 AI 연동은 데이터 소스를 한 번 더 연결하는 단계로 생각하면 됩니다.
- 같은 대화 이력을 AI가 읽도록 참조를 연결합니다.
- 자동 응답이 언제 상담원에게 넘어갈지 기준을 정합니다.
- 봇이 남긴 이력도 사람 상담원이 그대로 이어받도록 합니다.
배포
테스트와 배포
개발 환경과 운영 환경의 키를 분리하고, 배포 전 대화 흐름을 시나리오별로 점검합니다. 상담원 개입 경로도 함께 테스트해야 실제 운영에서 문제가 안 생깁니다.
-
환경
키와 데이터 채널을 분리합니다
개발·스테이징·운영에 쓰는 키와 애플리케이션 ID를 따로 만들고, 배포 전에 각 환경에서 같은 대화 흐름이 재현되는지 확인합니다. 테스트 환경에서 실제 사용자 데이터를 불러오지 않도록 주의하세요.
-
시나리오
대화 시나리오를 시나리오별로 점검합니다
신규 상담, 이어지는 대화, 파일 첨부, 알림 지연처럼 실제 운영에서 발생하는 흐름을 각각 한 번씩 돌려 봅니다. 자동 응답이 끼어드는 구간도 함께 테스트해야 상담원 인계가 자연스럽습니다.
-
개입
상담원 개입 경로도 검증합니다
자동 응답에서 사람 상담원으로 전환되는 경로, 상담원이 이전 이력을 그대로 보는지, 인계 이후 클라이언트 화면이 어떻게 바뀌는지를 함께 봅니다. 이 경로가 끊기면 실제 운영에서 가장 먼저 문제가 드러납니다.
기술 질문
자주 묻는 기술 질문
실제로 통합을 진행하며 자주 나오는 질문을 모았습니다. 더 깊은 내용은 상담 문의로 남겨 주시면 담당자가 확인 후 안내드립니다.
SDK와 API 중 뭘 먼저 봐야 하나요?
화면 완성이 급하면 SDK, 제어가 중요하면 API부터 보세요. 둘을 같이 쓰는 것도 자연스러운 선택입니다. 핵심 화면은 SDK로 만들고, 특수 흐름만 API로 처리하는 방식이 초기 구축에서 가장 부담이 적습니다.
메시지 이력 보관 기간은 어떻게 정해야 하나요?
업무 요건과 감사 요구, 사용자 기대를 함께 놓고 결정합니다. 상담 품질 확인을 위해 최근 이력을 오래 두는 편이 좋은 서비스도 있고, 개인정보 최소 보관을 우선하는 서비스도 있습니다. 초기에 정한 기간은 이후 조정이 어려우니 실제 운영 인력과 함께 검토하세요.
상담 자동화를 붙이려면 무엇부터 준비해야 하나요?
먼저 기존 채팅 흐름이 정상 동작하는지 확인합니다. 그 다음 상담원이 개입해야 하는 조건과 자동 응답이 다뤄도 되는 범위를 나눠 두면, 연동 이후에도 실제 운영에서 혼란이 줄어듭니다.
어떤 문서부터 순서대로 보면 되나요?
인증과 키 관리 → 사용자·채널 모델 → SDK 컴포넌트 → 실시간 이벤트 → 샘플 코드 순서로 보면 사고 흐름이 자연스럽습니다. 각 단계의 레퍼런스는 해당 장에서 함께 제공되니, 앞 단계를 마친 뒤 다음 장으로 넘어가는 편이 좋습니다.
문서로 안 풀리는 문제는 담당자에게 문의하세요
SDK 연동, 요금제 안내, AI 상담 자동화까지 이어지는 전체 흐름은 담당자와 함께 그리는 편이 빠릅니다. 문의를 남기시면 확인 후 순차적으로 안내드립니다.
- 지원 시간
- 평일 09:00 – 18:00 (주말 및 공휴일 휴무)
- 오시는 길
- 서울특별시 강남구 선릉로 514, 17층 (06162)