728x90
사이드 프로젝트 채팅 시스템 설계 Q&A – 안드로이드 개발자 & 백엔드 협업 노트
현재 진행 중인 사이드 프로젝트(⚽ 경기 기반 채팅 앱)에서
안드로이드 개발자(기획)와 백엔드 개발자가 주고받은 채팅 설계 관련 Q&A 내용을 정리했습니다.
프로젝트 깃허브: https://github.com/Mirandalaw/gooner
Q&A 목록
Q1) 1:1 채팅인가요? 그룹 채팅인가요?
A: 그룹 채팅입니다.
- 경기 시작 1시간 전부터 입장 가능, 종료 후 1시간까지 채팅 유지
- 경기별 채팅방이 하나씩 열리고, 그 안에서 여러 명이 대화
Q2) DAU(일일 활성 사용자 수)는 몇 명까지 고려하고 있나요?
A: 아직 구체적인 수치는 정해지지 않았습니다.
- 규모에 따라 개발 방향이 달라질 수 있으므로 추후 논의 필요
Q3) 채팅방 인원 제한이 있나요?
A: 현재는 없음
- Socket 통신으로 발생 가능한 문제를 서버 측에서 체크해볼 예정
Q4) 어떤 기능이 포함될 예정인가요? 첨부파일도 가능한가요?
A:
- 첨부파일은 비포함 (저장 시스템 없음)
- 기획 중 기능들:
- 명령어 기반 챗봇 기능
- 경기 이벤트(득점/시작/종료) 브로드캐스트 메시지
- UI상 특정 메시지 구분 출력 등
Q5) 메시지 길이 제한이 있나요?
A: 길이 제한을 두는 방향으로 생각 중입니다.
- 추후 메시지를 저장하게 될 경우 DB 구조, 소켓, 클라이언트 처리 범위 고려 필요
Q6) 종단 간 암호화를 적용하나요?
A: 현재 저장 기능이 없기 때문에 적용하지 않음
Q7) 채팅 이력은 얼마나 보관할 예정인가요?
A: 현재는 서버/클라이언트 모두 저장 X
- 클라이언트는 입장~퇴장 사이에 메모리 상에서만 보관 예정
- 향후 DB 저장 도입 시 재논의
정리 포인트
항목 | 현재 설계 |
---|---|
채팅 타입 | 경기별 그룹 채팅 |
메시지 저장 | 없음 (메모리 내 유지) |
파일 전송 | 미포함 |
암호화 | 없음 |
클라이언트 처리 | 채팅방 활성 상태에서 메모리 캐싱 |
서버 처리 | 소켓 통신 → 즉시 브로드캐스트 |
확장 예정 기능 | 챗봇, 브로드캐스트, 메시지 구분 렌더링 등 |
반응형
'백엔드 개발 > API · 아키텍처 설계' 카테고리의 다른 글
SOLID 원칙 완벽 이해와 실전 적용: 리팩토링 전후 코드로 배우는 객체 지향 설계 전략 (0) | 2025.05.22 |
---|---|
UserFactory로 객체 생성 책임을 분리한 이유 – SRP 기반 설계 적용기 (0) | 2025.05.09 |
Procedural 구조에서 Use Case 구조로, 내가 구조를 다시 짠 이유 (0) | 2025.05.08 |
[MSA] API Gateway는 왜 필요한가? – 인증, 보안, 확장성 중심의 설계 가이드 (0) | 2025.04.24 |
Update API는 한 번에 처리할까? 필드별 나눠 처리할까 (0) | 2024.01.02 |