전통적인 프론트엔드 설계는 “컴포넌트를 어떻게 나누고 재사용할까”에 집중했다. 하지만 이동욱이 지적하듯, 진짜 복잡도는 다른 곳에 있다. Google Docs 협업 편집에서 여러 사용자의 입력이 동시에 들어올 때, 커서 위치가 실시간으로 바뀌고 네트워크 지연이 있을 때 어떻게 사용자에게 끊김 없는 경험을 제공할 것인가? 이 질문은 단순한 컴포넌트 분할로는 답할 수 없다.
핵심은 상태의 원본 위치(로컬/서버/옵티미스틱), 데이터의 신선도 정책(어떤 데이터는 stale해도 되는가), 렌더링 전략(SSR/CSR/SSG), 오류 추적을 위한 텔레메트리, 그리고 사용자가 이해할 수 있는 흐름 설계다. 이 다섯 가지 축이 프론트엔드 시스템 디자인의 실질적 영역이다. 백엔드 시스템 디자인에 “트래픽, 저장소, 캐시, 샤딩”이 있다면, 프론트엔드에는 “상태, 데이터 흐름, 렌더링, 관측성, UX”가 있다.
근거
“상태의 원본을 어디에 둘지, 어떤 데이터는 stale해도 되는지, 어떤 화면은 SSR이 맞고 어떤 화면은 CSR로 격리해야 하는지, 문제가 생겼을 때 어떤 telemetry로 추적할지, 사용자가 이해할 수 있는 흐름으로 어떻게 구조화할지의 문제다.”
연결된 생각
- 20260528-frontend-system-design — 프론트엔드 시스템 디자인의 개념적 정의
- 20260528-ai-era-frontend-differentiation — 구조화 역량이 AI 시대에 차별점이 되는 이유