LINE 「도메인에 의존하지 않는 채팅 플랫폼은 어떻게 만들었을까?」 리뷰 — 사용자를 모르는 채팅 플랫폼, 웹으로 만든 클라이언트, SOFT STOP으로 갈아 끼우는 챗봇 시나리오

원문: 도메인에 의존하지 않는 채팅 플랫폼은 어떻게 만들었을까? — LY Corporation Tech Blog, 송재욱(ABC Platform), 2026-04-01

한 줄 요약

챗봇, 문의형 상담, 1:1, 그룹 채팅은 모두 “채팅”이지만 도메인마다 스펙이 다르고, 개별 대응하면 연동 포인트와 복잡도가 기하급수로 는다. MessagingHub는 채팅을 플랫폼화하면서 경계를 명확히 그었다. 사용자 정보를 직접 관리하지 않고(인증은 연동 측, 플랫폼은 연결 토큰만 발급), 누가 누구와 대화할 수 있는지는 서비스 컨텍스트(Driver2CS, Consumer2CS)로 정의하며, 컴포넌트를 연결 관리·채팅 비즈니스·메시지 라우터·알림·어드민으로 나눠 이벤트로 느슨하게 잇고, 동작은 커맨드 단위로 조합한다. 클라이언트는 네이티브 SDK가 아니라 웹(ChatWeb)이라 정책이 바뀌면 ChatWeb만 배포하면 모든 연동 측에 반영된다. 챗봇 시나리오는 새 버전 배포 시 옛 버전을 SOFT STOP으로 두고 사용자가 없어질 때까지 유지한다. 일본 음식 배달 서비스의 사용자·배달·CS·가게 도메인에서 운영 중이다.

기본 정책: 무엇을 하지 않는가

• 인증과 식별. “이 사용자가 채팅에 연결해도 되는가”는 전적으로 연동 시스템의 책임이다. 연동 측이 인증을 마친 뒤 MessagingHub에 연결 토큰을 요청해 클라이언트에 주고, 클라이언트는 그 토큰으로 웹소켓에 붙는다. 사용자 식별은 도메인 정보 + 연동 측 사용자 식별자를 조합한 client ID다.
• 서비스 컨텍스트. “어떤 역할끼리 대화할 수 있는가”를 정의하는 크로스 도메인 단위. 컨텍스트마다 채팅 허용 관계, 보관 기간, 이벤트 메시지 정책(트리거, 운영 시간, 내용), 웹훅이 설정된다.
• 흐름. 채팅방은 WAIT/PENDING → SERVICE → DISABLE/BLOCK으로 전이한다.
• 데이터. 메시지와 개인정보 가능성이 있는 데이터는 암호화 저장하고, 보관 기간 만료와 연동 측 요청 두 경로로 삭제한다.

아키텍처: 관심사별 분리와 커맨드

모놀리식 채팅 서버가 아니라 도메인별 컴포넌트다.

컴포넌트	책임
connection-manager	웹소켓 연결, 토큰 검증, 세션 유지, 사용자별 연결 상태
chat-app	메시지 송수신, 채팅방 생성·상태 전이, 읽음 처리. 커맨드 단위로 챗봇·문의·1:1·그룹 기능을 조합
message-router	수신자의 연결 상태·위치를 파악해 적절한 connection-manager로 전달
notification-app	오프라인·백그라운드 수신자에게 연동 측이 준 pushToken으로 푸시, 채팅방별 설정으로 제어
admin-hub	시나리오 편집·배포, 상담원 계정·역할, 컨텍스트·이벤트·웹훅 설정, 모니터링, 통계

컴포넌트는 이벤트 기반으로 느슨하게 결합되어 한 기능의 변경이 다른 곳에 미치는 영향을 줄인다. 동작 제어 단위는 커맨드로, 공통 커맨드 위에 챗봇·상담용을 세분화했다.

데이터는 chat_user(client_id로 유일), chat_room(채팅방 유일성을 스키마에서 보장), chat_log(1:N 메시지, 본문 자동 암호화, prev_chat_log_id로 순서 보장), 챗봇 계층 테이블, service_context, chat_event, webhook이다.

챗봇: SOFT STOP

시나리오 상태는 WAIT → SERVICE → SOFT STOP → DISABLE이다. 새 시나리오를 배포하면 기존 SERVICE는 자동으로 SOFT STOP이 되어 이미 대화 중인 사용자의 경험을 유지하고, 신규 접속자에게는 최신을 서비스한다. 종료 판정은 스케줄러가 주기적으로 이벤트를 발행 → 연결 관리 서버 그룹이 사용자들의 시나리오 연결 정보를 취득해 공유 자원에 보관 → 스케줄러가 그 결과를 확인 → 아무도 안 쓰면 종료하고 스케줄러를 멈춘다. 배포와 하위 호환을 상태 기계로 푼 것이다.

문의형 채팅: 메타데이터와 생명 주기

상담원은 도메인 정보를 알아야 하는데 플랫폼은 그것을 모른다. 그래서 연동 측이 채팅방 생성 시 자유롭게 정의한 메타데이터를 넘긴다. 검색 데이터(상담원이 채팅을 찾을 때), 사용자 상세, 커스텀 표시 데이터, 이벤트 데이터(설문 링크·웹훅), 상담 기본 데이터, 채팅방 설정(이름, 푸시 제목), 추적 데이터(연동 측이 채팅방을 특정하는 매핑).

생명 주기는 PENDING(운영 시간 확인, 시간 외면 안내 이벤트 후 대기, 시간 내면 상담원 매칭) → SERVICE(매칭 이벤트, 3분할 상담원 화면, 사용자 입력 타임아웃 모니터링으로 종료 예고 후 자동 종료, 매칭 시 웹훅) → DISABLE(종료 이벤트와 채팅 시간 등을 웹훅으로 전달) → BLOCK(재개 불가 최종 상태, 시스템 간 호출로만 전이).

설계 고려: 경계와 웹 클라이언트

할 수 있는 것과 없는 것. 플랫폼은 채팅 정책, 세 유형 지원, 상담원 운영 환경(계정, 모니터링, 매칭), 데이터 관리, 클라이언트 제공, 어드민, 설정 기반 커스터마이징을 책임진다. 반면 연동 측 도메인의 비즈니스 정보는 알 수 없다. 여러 이해관계자와 엮이는 플랫폼에서 이것을 정리하지 않으면 회색 영역이 생기고 비용 낭비로 이어진다.

ChatWeb. 웹소켓 연결 관리, 유형별 정책, 실시간 송수신·읽음, 커서 페이징·프리로딩, 타이핑 인디케이터, 이미지, 푸시·인앱 알림, 시나리오 실행, 매칭·전환·종료 이벤트, 운영 시간·설문·공지, 커스텀 설정까지 수많은 로직이 화면과 얽혀 있다. 네이티브 SDK면 도메인마다, 플랫폼마다 반복 구현해야 한다. 웹이면 연동 측은 WebView나 iframe에서 ChatWeb URL을 열고 Channel Messaging API로 최소 정보만 넘기면 된다. 이점은 셋. 정책 변경 시 ChatWeb만 배포하면 앱 빌드·스토어 릴리스 없이 즉시 반영, 연동 개발자는 페이로드와 몇 개 이벤트만 알면 됨, iOS·Android·Flutter·React Native·웹 어디서든 같은 경험. 연결 상태는 INIT → SOCKET_CONNECTED → MH_CONNECTED → MH_STARTED_CHAT으로 전이하며 단계마다 RECEIVE_CONNECTION_STATUS를 보낸다. 서버 간 연동은 SDK 또는 protobuf gRPC.

읽고 남는 질문

• 웹 클라이언트의 대가(네이티브 대비 성능, 오프라인, 키보드·스크롤 같은 UX 디테일, WebView 버전 파편화)를 어떻게 감당하는지가 없다. “전략적 판단”이면 그 비용도 있어야 균형이 맞는다.
• prev_chat_log_id로 순서를 보장한다면 동시 전송 시 체인 충돌은 어떻게 푸는지, 그리고 대규모 그룹 채팅에서 message-router의 팬아웃 규모와 성능이 궁금하다(다른 글 “톺아보기”에 있을 수 있다).
• 서비스 컨텍스트가 크로스 도메인 단위라면, 새 도메인이 붙을 때 컨텍스트 정의 외에 코드 변경이 정말 없는지, 커맨드를 새로 추가해야 했던 사례가 있는지.

한 줄로 가져가기

범용 플랫폼의 첫 설계는 기능이 아니라 “무엇을 모르기로 할 것인가”다. 사용자를 모르고, 도메인 정보를 모르고, 대신 토큰·컨텍스트·메타데이터·웹훅으로 그것들이 들어올 자리를 만들면, 클라이언트까지 웹 하나로 모든 도메인에 꽂을 수 있다.