#Backend

LINE 앱의 다자간 대화 기능 통합

LINE 앱의 다자간 대화 기능 통합
01

Summary

라인의 '중복 단톡방' 딜레마, 15%에서 0.78%로 해결한 비결

사용자 혼란은 줄이고 서버 리소스는 살린 LINE의 대규모 채팅 시스템 통합기

라인 메신저의 핵심인 '방'과 '그룹' 기능을 하나로 통합한 대규모 백엔드 전환 사례를 소개합니다. 기능 파편화와 리소스 낭비 문제를 해결하기 위해 도입한 새로운 '그룹 대화' 모델과 이를 무중단으로 이관하기 위한 기술적 전략을 다룹니다.

  • 01서로 다른 스토리지와 API를 사용하던 두 채팅 모델을 '그룹 대화'로 단일화
  • 02이중 읽기(Dual Read)와 API 라우터 설계를 통한 점진적이고 안정적인 시스템 전환
  • 03동일 구성원 대화방 생성 시 '힌트'를 제공하여 중복 생성률을 20배 가까이 개선
  • 04기존 그룹 전용이었던 앨범, 노트 기능을 모든 다자간 대화로 전면 확대
  • 05수년에 걸친 장기 프로젝트를 통해 사용자 스트레스를 최소화한 무중단 마이그레이션

RECOMMENDATION

대규모 트래픽이 발생하는 서비스에서 레거시 시스템을 통합하거나 데이터 마이그레이션을 준비 중인 백엔드 엔지니어에게 강력히 추천합니다. 사용자 경험을 보호하면서 시스템 효율을 극대화하는 점진적 전환 전략의 정석을 보여줍니다.

The Problem

라인은 일시적 목적의 '여러 명과의 대화(Room)'와 장기적 목적의 '그룹(Group)'을 별도로 운영했으나, 사용자들이 두 기능의 차이를 인지하기 어려워하고 기능 불일치로 인한 불편을 겪었습니다. 또한 동일 구성원의 대화방이 중복 생성됨에 따라 대화 목록이 지저분해지고 서버 리소스가 낭비되는 문제가 지속되었습니다.

The Solution

기존 그룹 모델을 기반으로 한 통합 모델인 '그룹 대화'를 도입하고, 이중 읽기(Dual Read)와 API 라우터를 활용해 이전 API와 호환성을 유지하며 점진적인 마이그레이션을 수행했습니다. 신규 대화 생성 시 동일 구성원의 기존 방이 있을 경우 힌트를 제공하는 UI를 추가하고, 모든 대화에서 앨범과 노트 기능을 사용할 수 있도록 통합했습니다.

The Result

동일한 구성원으로 중복 생성되는 대화방의 비율이 기존 15%에서 0.78%로 약 20배 가까이 대폭 감소하는 성과를 거두었습니다. 파편화되어 있던 API와 스토리지를 통합하여 시스템 복잡도를 낮추고 서버 및 클라이언트의 리소스 사용 효율을 개선했습니다.

Trade-off

본문에 구체적인 기술적 제약은 명시되지 않았으나, 수년에 걸친 장기 프로젝트로서 기존 서비스의 중단 없이 데이터 정합성을 유지하기 위해 이중 읽기 및 배치 처리 등 복잡한 마이그레이션 과정을 감수해야 했습니다. 또한 사용자가 변화에 스트레스를 받지 않도록 점진적 전환을 선택하면서 빠른 기능 통합보다는 안정성에 더 큰 비중을 둔 것으로 판단됩니다.

03

Key Concepts

Concept · 01

이중 읽기 (Dual Read)

새로운 시스템으로 전환하는 과정에서 신구 API 및 스토리지를 동시에 사용하여 데이터의 연속성과 정합성을 보장하는 기술적 전략입니다.

  • 기존 그룹 API와 신규 그룹 대화 API 간의 호환성을 유지하기 위해 도입
  • 데이터 마이그레이션 완료 후 점진적으로 신규 API로의 완전 전환을 유도
Concept · 02

API 라우터 (API Router)

클라이언트의 요청을 분석하여 적절한 버전의 API나 스토리지로 전달함으로써 시스템 간의 차이를 투명하게 메워주는 중계 계층입니다.

  • 그룹 API와 그룹 대화 API 사이의 사양 차이를 처리하는 역할 담당
  • 클라이언트 측의 대대적인 수정 없이 서버 로직 변경만으로 시스템 통합 지원
Concept · 03

그룹 대화 (Group Chat)

일시적 대화방의 편의성과 장기적 그룹의 강력한 기능을 결합하여 새롭게 정의한 라인의 통합 채팅 모델입니다.

  • 초대 즉시 참여와 승인 후 참여 방식을 사용자 선택제로 통합
  • 모든 다자간 대화에서 앨범, 메모 등 고급 기능의 일관된 제공 가능