풀스택 엔지니어 (B2B SaaS Web 개발자) - 2025.03 ~

Redis Stream 기반 실시간 알림 서버 개발 (멀티 테넌시, 20,000 msg/s 처리 규모)

• 배경

  알림 수단이 이메일에 국한되어 실시간성이 부족했고, 확인률이 10% 미만으로 저조함. 빠른 응답이 필요한 서비스 특성상 이메일의 지연성은 사용자 경험과 업무 효율을 저해함.

• 고민

  • 여러 서비스에서 공통으로 활용 가능한 중앙 집중형 알림 서버 필요.
  • 대량 메시지를 실시간 처리하면서도 장애나 부하에 강해야 함.
  • 단순 캐싱이 아닌 데이터 영속성(DB 저장) 과 확장성을 동시에 고려해야 함.

• 해결 방안

  • Redis Stream 기반으로 메시지를 수집 → Cassandra DB 저장 → WebSocket을 통한 사용자 실시간 전달 구조 설계.
  • 여러 서비스에서 생성되는 메시지를 알림 서버에서 통합 관리 가능하도록 구성.
  • Kubernetes 환경에서 멀티 Pod 확장 구조를 도입해 부하 대응.

• 성과

  • 알림 활성화 사용자 비율 10% → 50% 이상 증가.
  • 사용자-운영자 간 소통 지연을 1~2일 → 수 시간 이내로 단축.
  • 여러 서비스가 유기적으로 연동되는 확장형 실시간 알림 시스템 구축 및 운영.

Django Template → Next.js, React, DRF 기반 렌더링 최적화

• 배경

  Django Template 기반 SSR은 DOM까지 서버에서 렌더링하기 때문에 사용자 상호작용이 많은 페이지에서 불필요한 리렌더링이 발생. 스파이크 트래픽 시 서버 부하 증가 및 UX 저하 문제가 발생함.

• 고민

  • SSR과 CSR의 역할을 어떻게 구분할 것인지?
  • 서버 리소스 사용을 최소화하면서도 초기 페이지 로딩 속도는 보장해야 함.
  • 중복된 데이터 전달 방식을 줄이고 재활용 가능한 구조 필요.

• 해결 방안

  • 서버 렌더링이 필요한 초기 페이지는 SSR 유지.
  • 사용자 상호작용이 많은 부분은 React/Next.js 기반 CSR로 전환.
  • Django Template context 대신 DRF API로 데이터 제공 → 프론트엔드에서 렌더링.

• 성과

  • 서버 CPU 점유율 감소 및 스파이크 트래픽 대응 안정성 확보.
  • API 기반 데이터 재활용으로 중복 개발 최소화.
  • UX 개선 → 지연 없는 인터랙션 제공.

프론트엔드 상태 관리 개편

• 배경

  일부 React 페이지 최초 접근 시 5~6회 불필요한 리렌더링 발생. 그로 인해 API 중복 호출 및 서버 리소스 낭비 문제가 확인됨.

• 고민

  • 어떤 라이프사이클에서 불필요하게 상태가 변경되는지 추적 필요.
  • 개발 단계에서 렌더링 횟수를 가시적으로 추적할 수 있는 방법 고민.
  • 상태 관리 로직의 근본적 개편 필요.

• 해결 방안

  • 라이프사이클 및 렌더링 횟수를 추적하는 로깅 툴 도입.
  • 페이지·컴포넌트 단위로 렌더링 횟수 트래킹 후 최적화 작업 수행.
  • 상태 변경 로직을 재설계하여 불필요한 리렌더링 제거.

• 성과

  • 문제 페이지 리렌더링 횟수 5~6회 → 1회로 최적화.
  • API 호출 및 서버 리소스 사용량 대폭 감소.
  • 전체 리렌더링 비용 약 40% 절감.

API 성능 최적화 (DB Query 개선)