실무개발·2026년 2월 18일
Streaming SSR: 점진적 페이지 렌더링으로 체감 속도 개선
SSR 페이지가 데이터 로딩 때문에 3초간 빈 화면을 보여주고 있었다. Streaming SSR로 준비된 부분부터 먼저 보여주니 체감 속도가 극적으로 개선됐다.
#Streaming SSR#React#Next.js#Performance
개발과 기술에 대한 이야기를 기록합니다.
SSR 페이지가 데이터 로딩 때문에 3초간 빈 화면을 보여주고 있었다. Streaming SSR로 준비된 부분부터 먼저 보여주니 체감 속도가 극적으로 개선됐다.
API 라우트 만들고, fetch 호출하고, 로딩 상태 관리하고... 폼 하나 처리하는 데 너무 많은 코드가 필요했는데, Server Actions로 획기적으로 줄었다.
Server Component에서 함수를 props로 전달했더니 에러가 났다. 직렬화 경계를 이해하고 나니 RSC의 진짜 패턴이 보였다.
공개 API를 운영하다 보면 예상치 못한 대량 요청에 시달릴 수 있다. Rate Limiting과 API Key 관리로 API를 보호하는 방법을 정리했다.
admin/user 두 역할로 시작했는데, 요구사항이 복잡해지면서 RBAC만으로 부족해졌다. ABAC까지 고려한 권한 설계를 정리했다.
서비스가 3개로 늘어나면서 각각 로그인을 구현하는 게 지옥이었다. SSO로 한 번의 인증으로 모든 서비스에 접근하게 만든 이야기.
비밀번호 찾기가 CS의 절반을 차지했는데, Passkey를 도입하니 비밀번호 자체가 필요 없어졌다. 근데 구현이 생각보다 복잡했다.
블로그 이미지가 전체 페이지 용량의 80%를 차지하고 있었다. 포맷 변환과 반응형 이미지로 로딩 속도를 극적으로 개선한 이야기.
오프라인에서도 앱이 돌아가게 만들고 싶었는데, Service Worker의 캐싱 전략을 제대로 이해하고 나니 가능해졌다.
CSV 파일을 파싱하는 동안 UI가 완전히 멈췄다. Web Worker로 무거운 연산을 분리하니 UI가 부드럽게 유지됐다.
lodash 하나 import했을 뿐인데 번들에 전체 라이브러리가 들어갔다. Tree Shaking이 제대로 작동하게 만드는 법을 정리했다.
번들 크기가 2MB를 넘어가면서 초기 로딩이 5초나 걸렸다. Lazy Loading과 Code Splitting으로 필요한 코드만 불러오니 2초로 줄었다.
SQLite는 모바일에서만 쓰는 줄 알았는데, Turso와 Litestream 덕분에 프로덕션 웹 서비스에서도 진지하게 쓸 수 있게 됐다.
운영 중인 테이블에 컬럼을 추가했다가 서비스가 5분간 멈췄다. 무중단으로 스키마를 변경하는 전략을 배운 이야기.
검색 기능이 필요할 때마다 Elasticsearch를 써야 하나 고민했는데, PostgreSQL의 Full-Text Search만으로도 충분한 경우가 많았다.
단순 SELECT만 쓰다가 JSONB, CTE, Window Function을 알게 되니 SQL 한 줄로 해결되는 것들이 급격히 늘었다.
Redis를 단순 캐시로만 쓰고 있었는데, 세션 관리, 실시간 랭킹, Pub/Sub, Rate Limiting까지 가능한 만능 도구였다.
매번 수동으로 빌드하고 배포하다가 실수로 버그를 프로덕션에 올렸다. GitHub Actions로 자동화한 후 그런 실수가 사라졌다.
이미지와 정적 파일을 서버에서 직접 서빙하면 트래픽이 몰릴 때 서버가 위험해진다. S3 + CloudFront 조합으로 정적 파일 서빙을 분리하는 방법을 정리했다.
세 플랫폼 다 써봤는데, 가격, 속도, 기능 각각 장단점이 확실했다. 프로젝트 상황별로 어디를 써야 하는지 정리했다.
