#Backend

도메인에 의존하지 않는 채팅 플랫폼은 어떻게 만들었을까?

Summary

매번 새로 만드는 채팅은 그만! 어떤 도메인도 수용하는 '범용 채팅 플랫폼' 설계 전략

네이티브 SDK를 과감히 버리고 웹을 선택한 MessagingHub의 아키텍처와 도메인 독립 설계기

다양한 서비스 환경에서 채팅 기능을 파편화 없이 통합 제공하기 위한 플랫폼화 전략을 다룹니다. 도메인 독립성을 유지하면서도 복잡한 챗봇 및 상담 시나리오를 유연하게 처리할 수 있는 컴포넌트 구조와 운영 효율 극대화 방법을 소개합니다.

01도메인 지식을 배제하고 채팅 본연의 기능에 집중한 '관심사 분리' 설계
02레고처럼 조립하여 비즈니스 요구사항을 처리하는 '커맨드(Command)' 기반 로직
03앱 배포 없이 실시간 기능 업데이트가 가능한 웹 기반 클라이언트(ChatWeb) 전략
04이전 버전 사용자를 배려하며 안전하게 신규 시나리오를 배포하는 'SOFT STOP' 메커니즘
05상담원 매칭부터 생명 주기 관리까지 일반화된 문의형 채팅 정책 구현

RECOMMENDATION

사내 여러 서비스에 공통 채팅 인프라를 제공해야 하는 플랫폼 엔지니어나, 확장성 높은 시스템 아키텍처 설계를 고민하는 시니어 개발자에게 추천합니다.

The Problem

새로운 서비스 도메인이 추가될 때마다 채팅 기능을 중복으로 개발하면서 발생하는 연동 포인트 증가, 시스템 복잡도 상승 및 개발 리소스 낭비 문제를 해결하고자 했습니다.

The Solution

특정 도메인에 의존하지 않는 독립적인 메시징 플랫폼인 'MessagingHub'를 구축하고, 관심사에 따라 컴포넌트(연결 관리, 비즈니스, 라우터 등)를 분리한 이벤트 기반 아키텍처를 도입했습니다. 또한 네이티브 SDK 대신 웹 기반 클라이언트(ChatWeb)를 제공하여 플랫폼 이식성을 높였습니다.

The Result

일본의 음식 배달 서비스 내 사용자, 배달, CS, 가게 도메인에서 챗봇 및 문의형 채팅으로 운영 중이며, 도메인별 개별 구현 없이도 공통 플랫폼을 통해 범용적인 채팅 기능을 제공할 수 있게 되었습니다.

Trade-off

플랫폼의 범용성을 위해 도메인별 특화된 비즈니스 로직 처리를 포기해야 했으며, 이에 따라 사용자 인증 및 데이터 유효성 검증의 책임이 연동 시스템에 부여되어 추가적인 시스템 간 연동 및 통신 오버헤드가 발생할 수 있습니다.

Key Concepts

Concept · 01

도메인 독립성 (Domain Independence)

시스템이 특정 비즈니스 도메인의 세부 정보를 알지 못해도 기능을 수행할 수 있도록 설계된 상태입니다.

인증 및 사용자 식별 책임을 연동 시스템에 위임하여 플랫폼 범용성 확보
연동 측 데이터는 JSON 컬럼으로 단순 보관 및 전달만 수행하여 플랫폼 내 종속성 제거

Concept · 02

SOFT STOP 상태

새로운 버전 배포 시 기존 시나리오를 즉시 종료하지 않고, 기존 사용자의 세션이 끝날 때까지 유지하는 하위 호환성 지원 상태입니다.

기존 사용자의 UX를 해치지 않으면서 자연스러운 버전 전환 유도
스케줄러와 이벤트를 통해 실시간 연결 정보를 확인하고 사용자가 0일 때 최종 종료 처리

Concept · 03

Channel Messaging API

서로 다른 브라우징 컨텍스트 간에 직접적인 양방향 메시지 송수신을 가능하게 하는 웹 표준 API입니다.

네이티브 앱의 웹뷰와 ChatWeb 간의 데이터 통신 및 이벤트 전송에 활용
채팅방 생성, 페이지 이동 등의 상태를 연동 클라이언트에 실시간으로 전달

Continue reading · same source

More from 라인

View all posts from 라인

도메인에 의존하지 않는 채팅 플랫폼은 어떻게 만들었을까?

Summary