들어가며
안녕하세요. ABC Platform 팀에서 메시 징 플랫폼(이하 MessagingHub)을 만들고 있는 송재욱입니다. 메시징은 이제 거의 모든 서비스에서 요구되는 기본 스펙인데요. 이번 글에서는 그중에서도 ‘채팅’에 초점을 맞춰 이야기해 보겠습니다.
서비스에는 여러 종류의 채팅이 있습니다. 상호작용을 통해 답을 얻는 챗봇, 고객 상담을 위한 문의형 채팅, 1:1 채팅과 그룹 채팅까지. 모두 같은 채팅이지만 요구 사항에 따라 세부 스펙과 구현 방식은 달라집니다. 그렇다면 서비스를 추가할 때마다 채팅을 매번 새롭게 만들어야 할까요?
채팅을 필요로 하는 도메인이 늘어날수록 사양은 더욱 다양해집니다. 이를 개별적으로 대응하다 보면 연동 포인트는 늘어나고, 복잡도는 기하급수적으로 증가하며, 이는 개발 비용과 리소스 낭비로 이어집니다. 작은 요구 사항 하나를 반영하기 위해 여러 시스템을 함께 수정해야 하는 상황도 발생합니다.
MessagingHub는 이러한 문제를 해결하기 위해 MessagingHub에 채팅 기능을 추가해 채팅을 플랫폼화했습니다. 특정 도메인에 의존하지 않는 독립성을 확보하고, 어느 서비스에든 도입할 수 있는 이식성과 범용성을 갖추는 것을 목표로 설계했습니다.
채팅 플랫폼은 채팅 그 자체에 집중하는 단순함을 유지해야 합니다. 동시에 외부 도메인이 요구하는 다양한 요건을 일반화하여 재사용 가능한 구조로 흡수할 수 있어야 합니다. MessagingHub는 바로 이 원칙 위에서 만들어졌습니다.
이 글에서는 MessagingHub의 채팅 플랫폼이 어떤 기능을 갖추고 어떤 정책 기반으로 작동하는지, 아키텍처는 어떻게 구성했는지, 연동 도메인과 채팅의 역할 및 책임을 어떤 관점으로 분리했는지를 설계 원칙과 구축 사례 중심으로 다루겠습니다.
MessagingHub 도입 현황
MessagingHub는 현재 일본의 음식 배달 서비스에서 기반 기술인 메시징 및 채팅 플랫폼으로 사용되고 있습니다. 그중 채팅은 사용자·배달·CS·가게 도메인에서 ‘챗봇’과 ‘문의형 채팅’으로 운영되고 있습니다. 이후 더 여러 도메인으로 업무 영역을 확장해 나갈 계획입니다.
챗봇과 문의형 채팅 각 유형을 간단히 소개하겠습니다.
챗봇
챗봇의 서비스 화면은 다음과 같습니다. 공개된 웹 URL을 통해 연동 측 서비스에서 웹뷰로 서비스됩니다.
챗봇 시나리오 생성 및 배포 등의 관리 작업은 아래와 같이 관리자 페이지에서 운영합니다.
문의형 채팅
서비스 사용자가 문의하기 위해 MessagingHub 채팅 클라이언트에 접속하면 상담원이 매칭되며 문의형 채팅이 진행됩니다. 다음은 채팅 클라이언트 접속 화면 예시입니다.
상담원은 자신에게 매칭된 사용자와 채팅하며 문의를 해결합니다. 이때 채팅 서비스 연동 측에서 상담에 필요한 서비스 정보와 상담 운영에 도움이 되는 이전 상담 이력 등의 추가 정보를 상담원에게 제공합니다. 다음은 문의형 채팅에서 사용자와 상담원이 채팅하는 예시 화면입니다.
MessagingHub 채팅 플랫폼의 기본 정책
이제 MessagingHub 채팅 플랫폼의 기본 정책을 소개하겠습니다.
인증과 사용자 식별 정책
MessagingHub는 사용자 정보를 직접 관리하지 않습니다. ‘이 사용자가 채팅 서비스에 연결해도 되는가?’를 검증하는 책임은 전적으로 연동 시스템에 있습니다. 다음은 인증 과정을 나타낸 그림입니다.
연동 측이 사용자 인증을 완료한 뒤 MessagingHub에 연결 토큰(connection token)을 요청해 받아서 이 토큰을 클라이언트에게 전달합니다. 클라이언트는 이 토큰으로 웹소켓에 연결합니다. 인증을 거치지 않은 직접 접근은 허용되지 않습니다. 사용자의 로그인·회원 가입·권한 같은 도메인 인증은 연동 시스템이 책임지며, 토큰 검증과 이후 연결 관리는 MessagingHub가 책임집니다.
여러 도메인에서 각기 다른 사용자가 접속하기 때 문에 사용자를 식별하는 기준도 필요합니다. 이에 MessagingHub에서는 연동 측을 구분하는 도메인 정보와 연동 측 사용자 식별 정보를 조합한 client ID를 사용합니다. 채팅 화면에 표시할 닉네임, 프로필 이미지, pushToken 등은 연동 측이 전달하며, 변경 시에도 연동 측이 갱신해야 최신 상태로 반영됩니다.
서비스 컨텍스트와 채팅방 유형 관련 정책
MessagingHub 채팅에서 서비스 컨텍스트란 ‘어떤 역할끼리 대화할 수 있는지’를 정의하는 크로스 도메인 단위입니다. 예를 들어 드라이버와 CS(customer service) 상담원 간 채팅은 Driver2CS, 소비자와 CS 상담원 간 채팅은 Consumer2CS가 됩니다. 채팅방 유형으로는 1:1 대화(USER_DIRECT), 그룹 채팅(USER_GROUP), 상담 전 챗봇(INQUIRY_CHATBOT), 고객–상담원 1:1(INQUIRY_CHAT) 등이 있습니다. 서비스 컨텍스트가 ‘어떤 역할 조합의 대화인지’를, 채팅방 유형이 ‘어떤 구조의 대화인지’를 각각 결정하며, 이 둘의 조합으로 채팅방 생성·참여·메시지 허용을 제어합니다.
채팅 흐름 정의
채팅방은 생성 후 크게 ‘WAIT·PENDING → 대화 시작 시 SERVICE → 종료 시 DISABLE·BLOCK(메시지 작성 불가)’ 순서로 상태가 전환됩니다.
데이터 보관 및 삭제 정책
기본적으로 대화 메시지와 개인 정보가 포함될 수 있는 관련 데이터는 모두 안전하게 암호화해 저장합니다. 저장된 데이터는 두 가지 경로로 삭제됩니다. 첫 번째로 채팅방의 모든 참여자가 해당 채팅방을 나간(삭제한) 시점에 진행되는 즉시 삭제가 있습니다. 두 번째로 연동 측 요구 사항에 따라 보관 기간을 설정한 뒤 이에 맞춰 오래된 데이터를 자동으 로 삭제하도록 설정해 삭제하는 경로가 있습니다.
MessagingHub 채팅 플랫폼의 아키텍처 및 작동 흐름
MessagingHub 아키텍처
MessagingHub의 전체 아키텍처는 다음과 같습니다.
이 구성은 MessagingHub가 하나의 모놀리식 채팅 서버가 아니라, 관심사별로 도메인을 분리한 시스템이라는 것을 보여줍니다. 각 컴포넌트마다 책임 도메인이 있고 데이터도 도메인에 한정되는 형태의 명확한 R\&R을 갖도록 구성하고 있습니다. 채팅 관점에서 주요 컴포넌트의 역할을 살펴보면 다음과 같습니다.
- 사용자 연결 관리(connection-manager): 클라이언트의 웹소켓(WebSocket) 연결을 관리합니다. 연결 토큰 검증 후 소켓 세션을 유지하고, 사용자별 연결 상태를 추적합니다. 챗봇 시나리오의 SOFT STOP 상태 처리 시 사용 중인 시나리오의 연결 정보를 수집하는 역할도 이곳에서 담당합니다.
- 채팅 비즈니스(chat-app): 채팅 비즈니스의 핵심으로 메시지 송수신과 채팅방 생성·상태 전이, 읽음 처리 등 채팅의 주요 로직을 수행합니다. 커맨드 단위로 동작이 정의되어 있어 챗봇·문의형 채팅·1:1 채팅·그룹 채팅에 필요한 기능을 조합하여 처리합니다.
- 메시지 라우터(message-router): 채팅 서버가 생성한 메시지를 수신자에게 라우팅합니다. 수신 대상의 연결 상태와 위치를 파악하여 적절한 사용자 연결 관리 컴포넌트로 메시지를 전달하며, 채팅 서버와 연결 서버 사이에서 메시지 흐름을 중계하는 역할을 담당 합니다.
- 알림(notification-app): 메시지 수신 대상이 오프라인이거나 앱이 백그라운드 상태일 때 푸시 알림을 발송합니다. 연동 측이 전달한
pushToken을 기반으로 작동하며, 채팅방별 푸시 설정에 따라 알림 발송 여부를 제어합니다. - 어드민(admin-hub): 챗봇 시나리오 편집·배포, 상담원 계정 및 역할 관리, 서비스 컨텍스트·이벤트·웹훅 설정, 모니터링 대시보드, 통계 등 운영 전반을 담당합니다.
각 컴포넌트는 이벤트 기반으로 느슨하게 결합돼 있어, 특정 기능의 변경이 다른 컴포넌트에 미치는 영향이 최소화됩니다. MessagingHub 아키텍처의 전체 구성과 메시징 관점의 상세한 설명은 메시징 시스템 톺아보기 글을 참고하세요.
채팅 커맨드 흐름
저희는 MessagingHub 채팅의 동작을 제어하는 단위로 ‘커맨드(command)’를 정의해 사용하고 있습니다. 아래는 채팅 흐름과 구조를 이해할 수 있도록 저희가 정의한 커맨드의 흐름을 대략적으로 나타낸 것입니다.
MessagingHub 채팅은 크게 챗봇, 상담 채팅, 1:1 채팅, 그룹 채팅과 같은 기능을 지원할 수 있습니다. 공통 커맨드는 채팅 전반에서 사용하는 기능을 정의하고 있으며, 챗봇과 상담 채팅의 경우 필요에 따라 각 기능을 세분화하여 구현했습니다. 즉, 필요한 기능을 레고처럼 조합해서 비즈니스 요구 사항을 만족시킬 수 있도록 구성했습니다.
채팅 데이터 구조
지금까 지 채팅의 작동 흐름을 살펴봤다면, 이제 이 흐름을 뒷받침하는 데이터 구조를 살펴보겠습니다. 채팅 데이터의 스키마를 컴팩트하게 그려보면 다음과 같습니다. 크게 채팅 비즈니스의 핵심인 채팅 관련 데이터를 저장하는 chat DB와 채팅 서비스를 운영 및 관리하기 위한 데이터를 저장하는 chat_operation DB로 나뉩니다.
주요 테이블의 역할 및 관계
chat_user 테이블은 client_id로 유일하게 식별하며, 채팅 시작 시점에 생성 또는 갱신합니다. chat_room 테이블은 채팅방 단위의 유일성을 스키마 레벨에서 보장합니다. 이 두 테이블을 중심으로 chat_member 테이블에는 누가 어느 채팅방에 참여하는지 연결하는 데이터를 담고, chat_room_meta 테이블에는 채팅 참여자마다 다른 상태(읽음 위치, 푸시 설정, 입력 제한, 채팅방 상태 등)를 담고 관리합니다.
chat_log 테이블은 대화 메시지를 저장하는 테이블로 채팅방과 1:N으로 연결되는 메시지 엔티티입니다. 메시지 본문은 자동 암호화해 저장하고, prev_chat_log_id로 메시지 간 순서를 보장합니다. 채팅방의 메시지 범위를 나타내는 chat_room 테이블의 first_chat_log_id와 last_chat_log_id, 참여자의 열람 범위와 읽음 위치를 나타내는 chat_room_meta 테이블의 start_chat_log_id와 last_seen_chat_log_id의 관계를 통해 안 읽은 메시지 수를 산출합니다. 연동 측이 전달하는 메타데이터(system_data, search_data, user_details, descriptions 등)는 모두 JSON 컬럼으로 저장되며, MessagingHub는 이 값을 해석하지 않고 보관과 전달만 합니다. 이외에도 chat_schedule(예약 작업) 테이블, chat_event_record(이벤트 이력) 테이블, webhook_event_record(웹훅 호출 기록) 테이블 등으로 이벤트와 이력을 관리합니다.
chatbot 테이블 등 챗봇 관련 테이블은 계층적 데이터 모델의 실제 스키마이며, service_context 테이블이 채팅 허용 관계와 보관 기간을, chat_event 테이블이 서비스 컨텍스트별 이벤트 메시지 정책(트리거 타입, 운영 시간, 메시지 내용)을, webhook 테이블이 서비스 컨텍스트별 웹훅 설정을 관리합니다.
챗봇
이체 챗봇 유형을 보다 자세히 살펴보겠습니다.
데이터 구조
아래 왼쪽 그림은 챗봇 데이터 간의 관계를 보여줍니다. 챗봇 관리자는 관리자 페이지의 편집 툴을 이용해 여러 개의 챗봇을 관리할 수 있습니다. 챗봇은 미리 설정한 시나리오를 따라 사용자에게 메시지를 전달합니다. 챗봇의 기본 응답은 선택지와 답변으로 구성되며, 답변을 동적으로 표시할 수 있는 웹훅 기능도 선택해서 사용할 수 있습니다.
왼쪽 그림의 각 박스의 색에 맞춰서 오른쪽 그림을 해석해 보면, 이 데이터 구조로 다양한 형태의 챗봇 시나리오를 상당히 자유롭게 표현할 수 있다는 것을 알 수 있습니다.
챗봇 시나리오 배포와 상태 관리
챗봇의 시나리오 상태는 WAIT(챗봇 연결 대기 상태) → SERVICE (챗봇과 서비스 중인 상태) → SOFT STOP (새로운 챗봇 시나리오 배포 후 하위 호환을 위해 이전 버전을 지원하는 상태) → DISABLE (챗봇이 종료된 상태) 순서로 전이됩니다.
SOFT STOP 상태는 새로운 시나리오 배포 시 아직 이전 시나리오를 사용하고 있는 사용자의 사용자 경험이 저하되지 않도록 일정 기간 이전 시나리오를 유지하기 위한 상태입니다. 새 시나리오를 배포하면 기존 SERVICE 시나리오는 자동으로 SOFT STOP 상태로 전이돼 기존 사용자의 대화를 유지하며, 신규로 접속하는 새 사용자에게는 가장 최근에 배포한 최신 시나리오를 서비스합니다.
SOFT STOP 상태의 처리 과정을 도식화하면 아래 그림과 같습니다.
- 새로운 시나리오(파란색 동그라미)가 배포됩니다.
- 새 시나리오는 SERVICE 상태가 되고, 이전 시나리오는 하위 호환 서비스를 위해 SOFT STOP 상태가 됩니다.
- SOFT STOP 상태(빨간색 동그라미)를 모니터링하며 최종 종료 처리를 하기 위한 스케줄러를 구동합니다.
- SOFT STOP 상태의 시나리오가 아직 사용되고 있는지 확인하기 위해 주기적으로 이벤트를 발행합니다.
- 사용자 연결 관리 서버 그룹에서 이벤트를 수신합니다.
- 챗봇 사용자들이 사용 중인 시나리오 연결 정보를 취득합니다.
- 채팅 서버에서도 확인할 수 있도록 공유 자원에 연결 정보를 보 관합니다.
- 스케줄러를 통해 발행된 이벤트의 결과인 연결 상태를 체크합니다.
- SOFT STOP 시나리오가 더 이상 사용되고 있지 않다면 종료 처리하고 스케줄러 동작을 멈춥니다.
문의형 채팅
다음으로 문의형 채팅을 살펴보겠습니다.
메타데이터
문의형 채팅에서는 상담원이 사용자의 메타데이터(도메인 내에서 정의된 상담을 위한 기본 정보)를 알아야 합니다. 연동 측에서는 아래와 같은 정보를 자유롭게 정의한 뒤 채팅방이 생성될 때 필요한 정보를 전달해 상담원이 상담하는 데 도움을 줄 수 있습니다.
- 검색 데이터: 상담원이 채팅을 검색할 때 쓰는 정보
- 사용자 상세 데이터: 상담원에게 보여줄 사용자 정보
- 커스텀 데이터: 상담원 화면에 표시할 커스텀 정보
- 이벤트 데이터: 설문 링크 또는 웹훅을 위한 정보
- 상담 기본 데이터: 채팅방에 함께 표시할 설명 정보
- 채팅방 설정 데이터: 채팅방 이름, 앱 푸시 제목 등의 설정 정보
- 추적 데이터: 연동측에서 시스템적으로 매핑하여 채팅방을 특정할 수 있는 정보
생명 주기
문의형 채팅방은 PENDING(상담원 매칭 대기) → SERVICE(채팅 진행) → DISABLE(채팅 종료) → BLOCK(채팅 재개 불가)으로 상태가 전이됩니다.
PENDING(상담원 매칭 대기)
채팅방 생성 요청이 들어오면 먼저 상담 운영 시간 여부를 확인합니다. 운영 시간 외라면 안내 이벤트 메시지를 발송하고 채팅방을 대기 상태로 유지하고, 운영 시간 내라면 상담원 매칭을 시작합니다. 매칭 가능 조건은 상담원이 온라인 상태이면서 최대 동시 채팅 수를 초과하지 않는 경우입니다. 상담원의 온라인·오프라인 상태는 본인이 직접 전환할 수 있습니다. 매칭 우선순위는 요구 사항에 따라 조정 가능하며, 현재는 해당 사용자와 이전에 상담을 진행했던 이력이 있는 상담원이 존재할 경우 우선 매칭하고, 없다면 상담 수가 가장 적은 상담원에게 매칭합니다. 일정 시간 내 매칭되지 않으면 매칭 실패 안내를 발송하고 채팅방을 DISABLE 상태로 전환합니다.
SERVICE(채팅 진행)
상담원이 매칭되면 매칭 완료 이벤트를 발송하고 채팅방을 SERVICE 상태로 전환합니다. 상담원 화면은 채팅방 목록과 채팅 내용·사용자 정보로 3분할한 레이아웃으로 구성했습니다. 상담원은 연동 측이 전달한 사용자 정보를 확인하면서 대화할 수 있고, 과거 채팅 이력 조회, 메모 작성, 검색 데이터 기반 검색, 수동 종료 등의 기능을 사용합니다. 상담원 화면에 표시하는 사용자 정보와 검색 메타데이터는 모두 연동 측이 제공한 정보입니다. MessagingHub는 이 데이터를 표시할 뿐 의미를 해석하지 않으므로 도메인이 달라져도 상담원 화면 구조는 동일하게 유지됩니다. 또한 매니저 권한을 가진 상담원은 진행 중인 채팅을 다른 상담원에게 전환할 수도 있습니다.
상담 진행 중에는 사용자 입력 시간 초과 여부를 모니터링합니다. 사용자가 일정 시간 동안 입력하지 않으면 종료 예고 메시지를 발송하고 이후 다시 일정 시간 응답이 없으면 채팅방을 자동 종료합니다. 상담원이 수동으로 종료하는 것도 가능하며, 어느 경우든 DISABLE 상태로 전환됩니 다.
이 단계에서는 웹훅을 통해 외부 시스템도 연계할 수 있습니다. 웹훅을 등록해 놓으면 상담원 매칭 시 등록된 웹훅 설정에 따라 웹훅 호출을 트리거합니다. 이때 상담원 정보, 대기 시간(매칭 시간 − 채팅방 생성 시간), 채팅 링크, 그 외 연동 측이 지정한 커스텀 데이터 등을 개별 설정으로 제어해 전달합니다.
DISABLE(채팅 종료)
채팅방이 종료되면 종료 이벤트가 발생합니다. 관리자 페이지에서 개별 설정한 웹훅 정보를 참고해 이벤트 데이터(채팅 시간, 종료 시간 등)를 연동 측에 전달합니다. 이 상태에서는 채팅방 복구 가능 여부를 판단하기도 합니다. 연동 측이 재연결 기능을 허용한 경우 사용자에게 "채팅 재연결" 버튼을 노출하며, 영업시간 내라면 상담원 매칭을 재시도하고 영업시간 외라면 안내 메시지를 노출합니다. 재연결이 허용되지 않으면 BLOCK 상태로 전환합니다.
BLOCK(채팅 재개 불가)
최종 상태로 채팅방 재연결이 불가능하며 더 이상 상태 전이가 일어나지 않습니다. 연동 측 시스템에서 더 이상 채팅을 재개하지 않고자 할 때 시스템 간 호출을 통해서만 이 상태로 전이할 수 있습니다.
채팅 플랫폼 설계 시 고려 사항
할 수 있는 것과 할 수 없는 것을 명확히 정의
채팅 플랫폼을 설계할 때 가장 먼저 확인해야 할 것은 ‘플랫폼이 제공하는 것’과 ‘연동 측이 직접 해야 하는 것’의 경계를 정하는 일입니다.
MessagingHub가 할 수 있는 것은 다음과 같습니다.
- 채팅 전반의 정책 수립 및 구현
- 챗봇, 일반 채팅(1:1, 그룹), 문의형 채팅 지원
- CS 상담원 운영 환경 제공 (계정 관리, 모니터링, 매칭 로직 등)
- 채팅 데이터 관리
- 채팅 클라이언트(ChatWeb) 제공
- 어드민을 통한 운영 제어와 통계
- 연동 시 설정을 통한 동작 커스터마이징 지원
이처럼 채팅 비즈니스 전반은 MessagingHub가 책임집니다.
한편 플랫폼이 할 수 없는 것은 명확합니다. MessagingHub는 연동 측 도메인의 비즈니스 정보를 직접 알 수 없습니다. 예를 들어 사용자의 연동 측 도메인 내 인증이나 연동 측만이 알고 있는 사용자 및 도메인 데이터는 MessagingHub가 결정하거나 책임질 수 없는 영역입니다. 또한 도메인별 커스텀 가능한 설정값을 결정하는 것도 모두 연동 측이 결정할 사항입니다.
플랫폼 프로덕트는 대개 여러 연동 도메인의 이해관계자들과 엮이기 때문에 이런 부분을 명확히 정리하지 않으면 회색 영역이 발생합니다. 이는 곧 비용 낭비로 이어질 수 있기 때문에 사전에 잘 정리하는 것이 좋습니다.
채팅 클라이언트를 웹으로 만든 이유
MessagingHub의 채팅 클라이언트 구현체인 ChatWeb은 네이티브 앱 SDK가 아니라 웹으로 제공하고 있습니다. 이는 단순한 기술 선택이 아니라 범용 채팅 플랫폼으로서의 전략적 판단입니다. 사용자로서 익숙하게 느껴지는 것과는 달리, 채팅 서비스는 만드는 관점에서 살펴보면 아래와 같이 정책이나 구현 방향 등 고려해야 할 사항도 많고 합의하며 조정해야 할 부분도 많습니다.
- 웹소켓 연결 관리
- 채팅방 유형별 생성·조회·삭제 정책
- 실시간 메시지 송수신과 읽음 처리
- 커서 기반 페이징과 프리로딩
- 타이핑 인디케이터
- 이미지 업로드 및 뷰어
- 앱 푸시와 인앱 알림
- 챗봇 시나리오 실행
- 상담원 매칭·전환·종료 이벤트
- 운영 시간 안내, 설문 조사, 공지 팝업
- 커스텀 운영 설정 적용
이외에도 수많은 비즈니스 로직이 화면과 긴밀하게 얽혀 있습니다. 만약 이 모든 스펙을 연동 측의 앱 클라이언트가 매번 이해하고 직접 구현해야 한다면 새로운 도메인을 연동할 때마다 동일한 채팅 비즈니스를 각 네이티브 플랫폼별로 반복 구현해야 하는 비용이 발생합니다. 정책을 변경하거나 새로운 기능을 추가할 때에도 모든 연동 측 앱이 각자 업데이트해야 하므로 배포 주기가 길어지고, 구현 차이로 인한 동작 불일치도 피하기 어렵습니다. 사실상 연동 대상이 늘어날 때마다 커뮤니케이션 비용이나 서비스 품질 보증 등의 문제가 기하급수적으로 증가할 것입니다.
ChatWeb을 웹으로 제공하는 방식은 이 문제를 근본적으로 해결합니다. 연동 측 클라이언트는 WebView 또는 iframe에서 ChatWeb URL에 접속해 Channel Messaging API를 통해 연결에 필요한 최소한의 정보만 전달하면 됩니다. 이후의 모든 채팅 비즈니스는 ChatWeb이 MessagingHub 서버와 직접 주고받으며 처리합니다. 연동 측 앱은 ‘채팅이 필요한 시점에 ChatWeb을 구동하고, 필요한 정보를 넘기고, 발생한 이벤트(채팅방 생성, 페이지 이동, Close 등)를 받아서 처리하는 것’까지만 담당합니다.
이 구조의 실질적인 이점은 세 가지입니다.
- 첫째, MessagingHub가 채팅 정책을 변경하거나 새로운 기능을 추가할 때 ChatWeb만 배포하면 모든 연동 측 에 즉시 반영됩니다. 따라서 앱을 새로 빌드하거나 스토어에 릴리스할 필요가 없습니다.
- 둘째, 연동측 개발자는 복잡한 채팅 프로토콜이나 비즈니스 로직을 학습할 필요 없이, ChatWeb을 구동하는 페이로드 구조와 몇 가지 이벤트 메시지만 이해하면 연동을 완료할 수 있어 진입 장벽이 낮아집니다.
- 셋째, 어떤 플랫폼(iOS, Android, Flutter, React Native, 웹 등)이든 웹을 통해 동일한 채팅 경험을 제공할 수 있어 플랫폼 독립성이 확보됩니다.
채팅 플랫폼과 연동하는 방법
채팅 플랫폼과 연동하기 위해서는 ChatWeb 연동과 시스템 연동, 두 가지를 연동해야 합니다.
ChatWeb 연동
연동 클라이언트와 ChatWeb 사이의 통신에는 Web API의 Channel Messaging API를 활용합니다. 연동 클라이언트가 MessageChannel의 포트를 생성해 ChatWeb에 전달하면, 이후 양방향 통신이 가능해집니다. 연동 측에서 ChatWeb URL을 로드한 후 필요한 정보를 전달하면 이후 채팅 비즈니스 절차는 ChatWeb이 담당합니다.
채팅 연결 상태는 INIT → SOCKET_CONNECTED → MH_CONNECTED → MH_STARTED_CHAT 순서로 전이되며, 각 단계가 변경될 때마다 RECEIVE_CONNECTION_STATUS가 연동 측으로 전송됩니다. 이 외에도 페이지 이동(RECEIVE_NAVIGATE), 채팅방 생성(RECEIVE_CREATE_CHAT_ROOM), ChatWeb 닫기(RECEIVE_CLOSE) 등의 이벤트가 연동 측에 전달돼 앱 수준의 UX 제어가 가능합니다.
시스템 연동
연동 측 서버는 MessagingHub가 제공하는 SDK를 통해 통신합니다. SDK 연동이 여의치 않은 경우라면 protobuf 스키마로 직접 gRPC 통신을 할 수도 있습니다. MessagingHub SDK에 대한 자세한 사항은 앞서 발행된 질문에 대처하는 어느 플랫폼 개발자의 이야기 글을 참고하세요.
마치며
MessagingHub를 만들면서 깊이 고민했던 부분은 비단 기술 영역에 국한되지 않았습니다. 당장 드러나지는 않더라도 플랫폼 프로덕트로서 경계를 일관적으로 유지하는 일 또한 플랫폼의 미래를 위해 꼭 해야 하는 고민이고 결단이었기 때문입니다. 매번 ‘이번 한 번만 연동 측의 도메인 지식을 코드에 넣으면 빠르게 끝난다’는 유혹을 받았지만 그때마다 ‘이것이 범용 플랫폼의 비전에 부합하는가?’를 되물으며 방향을 바로잡아야 했습니다.
MessagingHub가 지향하는 바는 명확합니다. ‘어떤 도메인이든 메시징이 필요하면 MessagingHub를 사용하라.’ 이 비전은 플랫폼 프로덕트로서의 경계를 얼마나 일관적으로 지켜내느냐에 달려 있으며, 지금까지 살펴본 설계·정책·데이터·연동 구조는 그 경계를 지키기 위한 구체적인 실천입니다.
마지막으로 지금까지 MessagingHub를 만들어 오며 작성했던 글을 소개합니다. MessagingHub에 관심이 생기셨거나 플랫폼 개발에 관심 있으시다면 참고해 보시기를 바라며 이만 마치겠습니다.
