실시간 채팅 솔루션 (소스코드 / 설치 / 확장 세팅)

Next.js + PHP API + WebSocket(Node.js ws) + Redis Streams + MariaDB/MySQL 기반
운영 중인 사이트에 채팅 기능을 바로 붙일 수 있는 구조로 제공

데모 사용 안내

채팅 관리자와 채팅 데모는 서로 다른 브라우저 또는 시크릿 모드에서 열어야 합니다.
같은 브라우저에서 둘 다 열면 세션이 공유되어 관리자 계정으로 채팅 리스트 조회 시 데이터가 표시되지 않습니다.

가격(만원)

• STANDARD: 400 (소스코드 + 문서 제공, 설치 지원 없음)
• DELUXE: 500 (STANDARD + 설치/구동 세팅 포함)
• ENTERPRISE: 3000~ (대규모/확장형, 환경 진단 후 견적)

핵심 요약

• 구조 분리: 프론트(채팅/관리자) + API(PHP) + WS(Node) + Worker(PHP CLI)
• 비동기 저장: Redis Streams 기반, WS 즉시 응답 → Worker가 MySQL 저장
• 정합성: 권한/인증은 PHP API, 메시지 저장은 Worker가 책임
• 운영형: 관리자 대시보드 + 실시간 모니터링 포함

아키텍처

• 메시지 전송: 클라이언트 → WebSocket → Redis Stream(XADD) → 즉시 응답(2~3ms)
• 메시지 저장: Worker(XREADGROUP) → MySQL 저장 → 브로드캐스트(Pub/Sub)
• 확장성: Worker 다중 실행으로 처리량 분산(Consumer Group)

포함 구성(전체 스택)

• 사용자 채팅 웹(Next.js)
• 관리자 대시보드(Next.js)
• PHP API 백엔드(인증/권한/조회/운영 API)
• WebSocket 서버(ws)
• 메시지 저장 워커(PHP CLI, Redis Streams Consumer)
• OG 링크 미리보기 워커(PHP CLI)
• Redis 이벤트(Streams/Pub-Sub, 상태/카운터)
• DB 스키마(MySQL/MariaDB)
• 파일 저장(Local 또는 S3 선택)

사용자 기능

• 채팅방 목록: 최근 메시지/시간/안읽음 표시, 최신 대화 기준 정렬
• 목록 화면에서도 WS 유지 → 새 메시지 수신 즉시 갱신
• 채팅방 진입: 초기 메시지/멤버 로딩, 페이지네이션 지원
• 메시지 전송: 실시간 WS 전송, client_msg_id 기반 중복 방지/재전송 대응
• 전송 실패 UI 처리(재전송/상태 표시)
• 읽음 처리: last_read 기반, 수신 시 자동 읽음 반영(디바운스)
• 메시지 검색(키워드 기반)
• 파일/이미지 업로드: 정책 기반 제한(용량/개수/타입)
• 다운로드 권한 체크(채팅방 멤버만 허용)
• 미디어 모아보기: 이미지/파일/링크 탭 분리
• OG 링크 미리보기: 비동기 생성 후 실시간 반영
• 방 신고/메시지 신고(사유 선택 + 상세 입력)

관리자 기능

• 실시간 대시보드: 메시지/방 생성/신고 카운터 실시간 갱신
• 시스템 모니터링: WS 연결 수, 처리량, CPU/메모리, Redis/DB 상태
• 품질 지표: 실패 메시지/세션 길이/업로드 실패율 등 운영 지표
• 온라인 유저 리스트: 접속자 목록 + 실시간 변화 감지
• 채팅방 관리: 목록 조회/검색/필터/정렬
• 채팅방 상세: 멤버/메시지/첨부파일 조회
• 강제 퇴장(킥): 특정 유저/전체 강제 종료
• 메시지 관리: 관리자용 검색(방/발신자/기간/키워드/타입), 메시지 삭제
• 파일 관리: 첨부파일 목록/통계/다운로드/삭제
• 신고 관리: 리스트/상세/처리 상태 변경, 실시간 알림
• 회원 관리: 회원 목록/상세 조회
• 관리자 계정 관리: 생성/수정/비활성화
• 운영 설정: 설정 조회/저장

보안

• Rate Limiting: 사용자별 메시지/업로드 전송 제한
• 입력 검증: 메시지 길이, 타입, 인코딩 검증
• 파일 업로드: 이중 확장자 차단, MIME 타입 검증
• CORS: 명시적 도메인만 허용
• 중복 전송 방지: client_msg_id 기반 멱등성 보장

저장소 선택

• Local: 구축 간단, 백업/용량 정책 필요
• S3: 확장성 우수, IAM/버킷/CORS 설정 필요

동영상 업로드 안내

동영상 업로드는 대용량/트랜스코딩 이슈가 있어 S3 기반 구성을 권장합니다.

• 권장 구성: S3 + CloudFront + MediaConvert + Lambda
• 해당 구성은 환경별 비용/정책이 달라 커스텀 의뢰로만 진행합니다.

패키지 차이

• STANDARD: 소스 + 문서 제공(설치 지원 없음)
• DELUXE: 설치/구동 세팅 포함(WS/Redis/DB/스토리지/워커)
  + 운영 환경 최적화 세팅(Worker 데몬화, PHP-FPM 튜닝, 시스템 파라미터 조정)
• ENTERPRISE: 확장/분리/운영 최적화 포함(환경 진단 후 구성)

ENTERPRISE 확장 옵션

• Redis Streams 기반 Worker 다중 실행(Consumer Group)
• RabbitMQ/Kafka 등 메시징 인프라 확장 고려 가능
• 멀티 리전/멀티 DC 운영 아키텍처 설계 옵션
• 메시지 중복 처리/멱등성 기반 안정적 전달 정책
• 룸/키 기준 순서 보장 설계(글로벌 순서는 환경 조건에 따라 제한)
• 대규모 샤딩 전략 및 백프레셔(backpressure) 설계 포함

확장 가이드

• 5,000+ 동접: t3a.xlarge 권장 (4 vCPU) + Worker 2~3개
• 10,000+ 동접: WS 서버 분리 + 로드밸런서 + Worker 스케일아웃
• ENTERPRISE에서 멀티노드 구성 지원

기술 스택

개발/테스트 환경

• Next.js 16.1 (React 19)
• PHP 8.3
• Node.js 20 LTS
• Redis 7.0
• MySQL 8.0

최소 지원 버전

• Next.js 16+ (React 19 필수)
• PHP 8.3+
• Node.js 18+
• Redis 5.0+ (Streams 지원)
• MariaDB 10.6+ / MySQL 8.0+

필수 환경

• PHP 8.3+ 기반 운영 사이트 (세션 로그인 기반)
• Node.js 18+ 구동 가능
• Redis 5.0+ 사용 가능 (Streams/Pub-Sub 지원)
• MariaDB 10.6+ / MySQL 8.0+ 사용 가능
• 리버스 프록시에서 WebSocket Upgrade 허용
• WS/Worker 상시 실행 가능 (systemd/PM2 권장)

세션/인증 중요 안내

• PHPSESSID 기반 연동
• 파일 세션 사용 시 Redis 세션 전환 필요할 수 있음

설치 불가/제약 대표 케이스

• Node.js 실행 제한, Redis 설치/접근 불가
• WS 포트/프록시 차단(WAF/Cloudflare)
• 상시 프로세스 운영 불가

별도 서버 구성 안내

기존 서버 환경이 요구사항과 맞지 않는 경우 (PHP 버전, Node.js 미지원 등),
별도 서버에 채팅 솔루션을 구성하고 기존 사이트와 연동하는 방식으로 진행 가능합니다.

• 채팅 서버: 별도 인스턴스에 WS/API/Worker/Redis 구성
• 기존 서버: 세션 공유 (Redis 세션) + API 연동
• 구성 예시: 기존 서버(웹사이트) ↔ 채팅 서버(chat.example.com)

이 경우 Redis 세션 공유 설정이 필요하며, DELUXE 이상 패키지에서 세팅 지원됩니다.

진행 절차(패키지별)

• STANDARD: 환경 확인 → 소스/문서 제공 → 구매자 설치/구동 → 운영 시작
• DELUXE: 환경 확인 → 설치/구동 세팅 → 핵심 기능 검증 → 인수
• ENTERPRISE: 사전 진단 → 범위/인프라 설계 → 구축/확장 세팅 → 성능 검증/인수

제외 항목

• 사이트별 커스텀 정책/기능
• 보안/인프라 정책으로 인한 추가 구성
• STANDARD는 설치/세팅 지원 제외

성능 테스트 요약 (1대 서버 단일 구성 기준)

테스트 환경

• 인스턴스: t3a.large (CPU 2, RAM 8GB)
• OS: Ubuntu 24.04
• Nginx + PHP-FPM + Redis + MySQL + WS + Worker 단일 서버
• Redis: 7.0.15
• MySQL: 8.0.44
• Redis Streams 기반 비동기 메시지 저장

k6 설정

• 시나리오: 8분 (2m 2m 2m 2m)
• 목표 TPS: 50~100
• WebSocket 유지 + 메시지 전송

[1,000 VU 결과]

k6 최종 요약 (완주)

• ws_msgs_sent: 25,713 (50.40/s)
• ws_msgs_received: 25,869 (50.70/s)
• ws_connecting p95: 691.7ms
• ws_ping p95: 8ms
• ws_sessions: 1,000
• 데이터 전송: sent 4.3MB / received 7.4MB

단일 서버(t3a.large)에서 1,000 동접 + 50 TPS를 안정적으로 처리하며, p95 ws_ping 8ms 수준으로 실시간 성능 유지.

[2,000 VU 결과]

k6 최종 요약 (완주)

• ws_msgs_sent: 25,299 (49.56/s)
• ws_msgs_received: 25,402 (49.76/s)
• ws_connecting p95: 464.02ms
• ws_ping p95: 10ms
• ws_sessions: 2,000
• 데이터 전송: sent 4.7MB / received 7.5MB

단일 t3a.large 환경에서 2,000 동접 + 50 TPS를 안정적으로 처리, p95 ws_ping 10ms 수준 유지.

[3,000 VU 결과]

k6 최종 요약

• ws_msgs_sent: 50,477 (98.75/s)
• ws_msgs_received: 55,652 (108.87/s)
• ws_connecting p95: 366.76ms
• ws_ping p95: 18ms
• ws_sessions: 3,000
• 데이터 전송: sent 5.0MB / received 8.4MB

단일 t3a.large 환경에서 3,000 동접을 안정적으로 유지했고, p95 ws_ping 18ms 수준으로 실시간 성능 유지.
(테스트 시나리오상 실제 전송률은 약 100 TPS 수준)

Redis Streams 기반 비동기 저장으로 응답 지연 최소화.
Worker 추가 시 처리량 선형 증가 가능.