본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://fastcampus.info/4n8ztzq
안녕하세요 :)
오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 " 챌린지에 도전하는 스무번째 날입니다.
열아홉번째 날에는 왜 Http Session을 선택했나. Cookie, Http Session, JWT의 차이에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.
오늘 학습할 내용의 제목은,
Part 3. 채팅 서비스 핵심 기능 개발 > Ch 3. 채팅 프로젝트에 다이렉트 메시지와 그룹 메시지 추가 >
01. 이번 파트에서 채팅 프로젝트에 추가할 기능에 대한 소개와 스키마 설계
입니다.
💬 메시지: 채팅 서비스 핵심 기능 설계와 구현 준비
- 채팅 시스템을 진짜 서비스처럼 만들기 위해선, 단순한 메시지 송수신을 넘어서 연결 요청, 채널 시스템, 메시지 이력 관리까지 다양한 기능이 필요합니다. 이번 포스팅에서는 채팅 프로젝트의 다음 단계로 넘어가기 위한 핵심 기능들을 소개하고, 어떤 구조와 방식으로 구현할 것인지 정리해봅니다.
🧱 이번 챕터의 범위는?
- 이전 챕터에서는 사용자 등록, 로그인, 로그아웃, 세션 관리와 같은 기본 사용자 기능을 다뤘습니다. 이번 3번째 챕터에서는 드디어 본격적인 채팅 기능이 구현됩니다.
- 구현 예정 기능 요약:
- ✅ 연결 신청, 수락, 거부, 삭제 (양방향 친구 관계)
- ✅ 초대 코드 기반 연결 시스템
- ✅ 다이렉트 및 그룹 채널 생성
- ✅ 채널 참여 조건 제어 (연결 관계, 초대 코드)
- ✅ 채널 내 메시지 송수신
- ✅ 메시지 히스토리 요청 및 조회
- ✅ Fake Push 기능을 통한 오프라인 사용자 알림 처리
- 구현 예정 기능 요약:
🔗 사용자 간 연결 시스템
- 사용자는 다른 사용자에게 연결 요청을 보낼 수 있으며, 상대는 이를 수락하거나 거부할 수 있습니다. 연결이 성립되면 서로의 친구 목록에 등록되며, 이후 언제든지 연결 해제도 가능합니다.
- 📌 연결 특징
- 양방향 관계로 동작 (A↔B)
- 연결 대기 목록: 수락 전 요청을 따로 관리
- 최대 1000명까지 연결 허용
- 📌 연결 특징
- 또한, 연결은 초대 코드 기반으로도 가능합니다. 사용자는 자신의 초대 코드를 확인한 뒤, 이를 외부에서 공유함으로써 다른 사용자가 나에게 연결을 요청할 수 있는 비공개 인바이트 기반 시스템도 지원합니다.
🏠 채널 시스템 도입
- 지금까지는 모든 사용자가 같은 공간에서 채팅하는 구조였지만, 이번 챕터부터는 채널(Channel)이라는 개념이 도입됩니다.
- ✉️ 다이렉트 채팅 채널
- 연결된 사용자 간 1:1 채널 생성
- 👥 그룹 채팅 채널
- 최대 100명까지 참여 가능
- 연결된 사용자만 참여 가능
- 초대 코드를 통한 외부 사용자 참여 허용
- ✉️ 다이렉트 채팅 채널
- 채널에 참여한 사용자는 해당 채널의 초대 코드를 확인하고, 다른 사용자를 초대할 수 있는 권한도 갖습니다.
📁 메시지 히스토리 조회 기능
- 채널에 입장하면 이전에 오간 메시지를 확인할 수 있어야 합니다. 하지만 메시지가 많아질 경우, 모든 데이터를 한 번에 전달하는 건 서버와 클라이언트 모두에게 부담이 됩니다.
- 그래서 다음과 같은 구조로 설계합니다:
- ✅ 클라이언트가 히스토리를 범위 요청 방식으로 조회
(예: 메시지 ID 150~250 사이 요청) - ✅ 서버는 요청 범위에 따라 메시지를 전달
- ✅ 한 번에 최대 100개까지 요청 가능
- ✅ 클라이언트가 히스토리를 범위 요청 방식으로 조회
- 그래서 다음과 같은 구조로 설계합니다:
- 이 방식은 확장성과 유연성을 고려한 선택으로, 모바일 환경이나 대용량 채팅에도 안정적으로 대응할 수 있습니다.
📦 데이터베이스 스키마 확장
- 기존에는 사용자(user)와 메시지(message) 테이블만 있었지만, 이제 다음과 같은 테이블이 추가됩니다:
| 테이블 | 설명 |
| connection | 사용자 간 연결 관계 (요청자, 수락자, 상태 등 포함) |
| channel | 채널 정보 (타이틀, 초대 코드, 참여자 수) |
| user_channel | 사용자의 채널 참여 기록 및 읽은 메시지 위치 등 |
- 복합키를 사용하는 테이블도 생기는데, 사용자 연결 정보는 (user_id1, user_id2) 조합으로 관리됩니다. 중복 관계(1-2와 2-1) 방지를 위해 서버에서 일관성을 직접 관리하게 됩니다.
🚨 오프라인 사용자 알림 - Fake Push
- 현재 프로젝트는 콘솔 기반 클라이언트라 실제 푸시 알림을 보낼 수 없습니다.
- 하지만 푸시 시스템 구조 자체는 미리 구현해 둡니다:
- 서버에서 푸시 메시지를 푸시 서비스로 전달
- 실제 전송은 없지만 로그로 기록
- 나중에 FCM, APNS 등의 실제 푸시 서버로 확장 가능
- 이런 설계는 지금은 단순하지만, 실서비스 전환 시 무리 없이 연결할 수 있는 유연성을 줍니다.
- 이번 챕터는 단순히 기능을 구현하는 단계를 넘어, 채팅 시스템의 기본 골격을 설계하는 작업이었습니다.
- 많은 선택지 중에서 우리는:
- 복잡한 기능도 사용자에게는 단순하게 보이도록
- 확장 가능한 구조를 지금부터 준비
- 불확실한 미래 기능(Fake Push 등)도 미리 인터페이스 설계
- 이러한 결정이 가능한 이유는 단 하나, “어떤 문제를 해결하려는가?”를 명확히 했기 때문입니다. 그리고 그것이 시스템 설계의 본질이라 믿습니다.
