안녕하세요 makeviibe 입니다.
최근 사용자 커스터마이징 요소가 포함된 소셜 플랫폼의 백엔드 구조를 설계하며, 다음과 같은 요청에 맞닥뜨렸습니다.
“사용자가 가진 커스터마이징 리소스를 서버에서 모두 내려주는 방식으로 구성해 주세요.”
요청만 보면 자연스럽게 들리지만, 실제로 구조를 짜고 데이터를 구성해보니 몇 가지 우려가 생겼습니다.
🔸 왜 서버가 모든 걸 내려주면 곤란할까?
리소스 데이터를 서버가 매번 내려주는 방식은 아래와 같은 문제를 만들 수 있습니다:
- 중복 전송: 동일한 리소스를 매번 내려주면 불필요한 트래픽 발생
- 속도 저하: 응답 용량 증가 → 초기 로딩 지연
- 버전 관리 어려움: 리소스가 바뀔 때마다 서버도 함께 수정해야 함
- 클라이언트 캐시 미활용: 클라이언트 측 최적화 포인트를 놓치게 됨
🔸 우리는 이렇게 설계했습니다
makeviibe는 고민 끝에, 서버는 '무엇을 갖고 있는지'만 전달하고,
실제 리소스(이미지, 모델 등)는 클라이언트가 별도로 로딩하는 방식으로 구조를 정리했습니다.
- 클라이언트는 공용 리소스를 앱 내에 포함하거나 CDN에서 불러오고
- 서버는 해당 사용자가 보유한 리소스 ID만 내려줍니다
- 클라이언트는 이 ID를 기반으로 필요한 리소스만 렌더링
🔍 어떤 점이 더 나았을까?
💡 느낀 점
단기적으로는 서버가 많은 데이터를 내려주는 방식이 편할 수 있지만,
장기적 관점에서는 클라이언트와 서버의 역할 분리가 더 이롭다는 걸 다시금 확인했습니다.
- 서버는 “사용자가 어떤 리소스를 가졌는지”만 알려주고
- 클라이언트는 “그걸 어떻게 표현할지”를 결정하는 것
이 단순한 기준이 프로젝트 전체의 안정성과 속도를 좌우할 수 있습니다.
makeviibe 팀은 앞으로도 작은 설계 하나에도 고민을 담고,
그 결과를 기록으로 남기며 더 나은 서비스를 만드는 기반을 만들어가겠습니다.
'개발일지' 카테고리의 다른 글
| Socket.IO vs WebSocket – 같은 듯 다른 두 실시간 통신 기술 (1) | 2025.07.15 |
|---|---|
| “방에 입장했는데 아무도 안 보여요” – 실시간 공간에서 사용자 정보를 받아오는 방식 (2) | 2025.07.15 |
| 실시간 채팅 시스템, 왜 서버가 필요할까? – 구조와 아키텍처 설계까지 (2) | 2025.07.15 |
| 💬 실시간 채팅 시스템 개발기 – Socket.IO + NestJS + React 조합으로 방 기반 메시징 구현하기 (0) | 2025.07.15 |
| SNS 로그인 구현, 어디까지 해봤니? (2) | 2025.07.15 |