[번역] 소프트웨어 엔지니어를 위한 프론트엔드 시스템 디자인 개념 21가지

#99: 빠르고, 확장 가능하며, 안정적인 웹 앱을 만들기 위한 실용 가이드

뉴스레터 구독 시 시스템 디자인 플레이북을 무료로 받아보세요:

이 글 공유하기 추천 보상을 보내드립니다.

백엔드 개발을 하다가 오셨다면, 아마 프론트엔드를 "HTML, CSS, 그리고 약간의 JavaScript" 정도로 생각하실 겁니다. 하지만 솔직히 말하자면? 현대 프론트엔드 엔지니어링은 백엔드 시스템 디자인과 거의 비슷한 수준으로 발전했습니다.

API가 빠르고, 확장 가능하며, 안정적이어야 하는 것처럼, 프론트엔드 앱도 수백만 명의 사용자를 처리하고, 콘텐츠를 빠르게 로드하며, 관찰 가능하고 안전해야 합니다.

이 뉴스레터는 프론트엔드 시스템 디자인에 대한 빠른 소개입니다.

캐싱, 배포 파이프라인, 관찰 가능성, 보안처럼 여러분이 백엔드에서 이미 알고 있는 개념들이 브라우저에서 어떻게 적용되는지 살펴볼 것입니다.

이 글을 다 읽고 나면, 프론트엔드가 단순히 버튼과 폼에 관한 것이 아니라는 걸 알게 될 겁니다. 사용자의 브라우저에서 바로 실행되는 시스템을 구축하는 것입니다.

그럼 시작하겠습니다.

팀의 컨텍스트로 AI 코딩 능력 극대화하기 (스폰서)

AI 도구는 그들이 가진 컨텍스트만큼만 좋습니다. Unblocked는 여러분의 코드, 문서, 대화를 연결하여 Cursor, Claude, Copilot이 마침내 여러분의 최고 엔지니어처럼 시스템을 이해할 수 있게 합니다.

게스트 저자로 Shefali Jangid를 소개합니다.

그녀는 웹 개발자이자 기술 작가이며, 프론트엔드 아키텍처와 확장 가능한 것들을 만드는 것을 좋아하는 콘텐츠 크리에이터입니다.

그녀의 작업과 소셜을 확인해 보세요:

그녀는 웹 개발에 대해 글을 쓰고, UI 팁을 공유하며, 개발자들의 삶을 더 쉽게 만드는 도구를 만드는 일을 자주 하고 있습니다.

렌더링 & 전달 모델

가장 먼저 이해해야 할 것은 웹페이지가 사용자에게 어떻게 도달하는가입니다.

페이지를 빌드하고 로드하는 방식은 사이트가 얼마나 빠르고, 안정적이며, 부드럽게 느껴지는지에 영향을 미칩니다. 페이지를 미리 빌드하거나, 서버에서 렌더링하거나, 브라우저에서 빌드하거나, 이러한 접근 방식을 혼합할 수 있습니다.

웹 페이지를 빌드하는 것은 서버가 API 응답을 처리하는 것과 매우 유사합니다. HTML이 언제 어디서 생성되는지에 따라 트레이드오프가 달라집니다.

미리 빌드된 페이지부터 시작해서 완전히 동적인 페이지로 이동하겠습니다. 각각이 속도, 확장성, 콘텐츠 신선도에 어떻게 영향을 미치는지 살펴보겠습니다.

1. 정적 사이트 생성 (SSG)

SSG 이전에는 웹사이트가 두 가지 기본적인 방식으로 작동했습니다. 서버가 모든 요청에 대해 페이지를 빌드하거나, 브라우저가 클라이언트 측에서 빌드했습니다. 즉:

모든 요청이 페이지를 생성하기 위한 작업이 필요했습니다.
많은 사람이 동시에 방문하면 페이지가 느려질 수 있었습니다.
캐싱이 까다로워서 확장이 어려웠습니다.

SSG는 사이트를 배포할 때 HTML을 미리 빌드함으로써 이 문제를 해결합니다. 시스템은 빌드 프로세스 중에 데이터를 가져올 수 있으며, 동적 콘텐츠가 있는 페이지에서도 가능합니다. 즉, 모든 콘텐츠가 사용자가 방문하기 전에 정적 HTML 파일로 구워집니다.

빌드 프로세스 동안 프레임워크는 데이터 가져오기 코드를 실행하고, 데이터베이스를 쿼리하며, 각 라우트에 대한 완전한 HTML 파일을 생성합니다. 그런 다음 프레임워크가 이를 CDN이나 호스팅 제공업체에 업로드합니다.

사용자가 페이지를 요청하면 서버 측 처리나 클라이언트 측 데이터 가져오기를 기다릴 필요 없이 즉시 완전히 형성된 HTML 문서를 받습니다.

이것이 SSG를 사용자에게 매우 빠르게 만드는 이유입니다. 렌더링 지연이 없기 때문입니다. 트레이드오프는 콘텐츠가 변경되면 정적 파일을 업데이트하기 위해 재빌드하고 재배포해야 한다는 것입니다. 이것이 SSG가 자주 변경되지 않는 콘텐츠에 가장 적합한 이유입니다.

API 응답을 미리 준비하는 것과 같습니다. 누군가 요청하기 전에 힘든 작업이 완료됩니다.

왜 중요한가:

페이지가 매우 빠르게 로드됩니다.
수백만 명의 사용자를 쉽게 처리할 수 있습니다.
페이지가 처음부터 완전히 렌더링되므로 SEO가 더 좋습니다.

사용 사례: 문서 사이트, 마케팅 랜딩 페이지, 또는 사용자 액션이 아닌 배포를 통해 콘텐츠 업데이트가 발생하는 개인 블로그.

2. 증분 정적 재생성 (ISR)

정적 사이트 생성(SSG)은 빠르지만, 콘텐츠가 자주 변경되면 어떻게 될까요? 매번 전체 사이트를 재빌드하는 것은 번거로울 것입니다.

여기서 증분 정적 재생성(ISR)이 등장합니다.

페이지는 여전히 미리 빌드되지만, 전체 재배포 없이 자동으로 업데이트될 수 있습니다.

재검증 시간만 설정하면 됩니다. 그 기간이 지나면 다음 방문자가 전체 배포가 아닌 서버에서 해당 특정 페이지의 백그라운드 재빌드를 트리거합니다. 이전 버전이 즉시 로드되므로 사용자는 기다리지 않습니다. 재생성 후 새 버전이 캐시된 버전을 대체합니다. 이는 사이트 전체가 아닌 페이지별로 발생하므로 개별 페이지에 대해 서로 다른 재검증 간격을 설정할 수 있습니다.

만료 타이머가 있는 캐시된 API 응답과 같습니다. 사용자는 새로 고쳐질 때까지 이전 버전을 볼 수 있지만, 업데이트는 뒤에서 조용히 발생합니다.

왜 중요한가:

SSG만큼 빠르지만 콘텐츠가 신선하게 유지됩니다.
블로그나 전자상거래 사이트 같은 동적 웹사이트에 완벽합니다.
CDN과 함께 작동하므로 다운타임 없이 업데이트가 발생합니다.

사용 사례: 대부분의 콘텐츠(예: 설명 또는 이미지)는 정적이지만 가격이나 재고 정보와 같은 일부는 가끔 업데이트되는 전자상거래 제품 페이지.

ISR은 전체 재배포 없이 페이지를 신선하게 유지하며, 실시간 가격과 같은 실시간 데이터는 API에서 가져올 수 있습니다.

3. 서버 사이드 렌더링 (SSR)

서버 사이드 렌더링(SSR)은 반대 방식으로 작동합니다. 서버가 각 요청에 대해 페이지를 빌드합니다. 데이터를 가져오고, HTML을 생성하여 사용자에게 보냅니다.

대부분 정적인 페이지에 적합한 정적 사이트 생성(SSG)과 달리, SSR은 콘텐츠가 신선하거나 개인화되어야 할 때 유용합니다. 예를 들어, 대시보드, 사용자 프로필 또는 라이브 피드. 시스템이 페이지를 실시간으로 생성하므로 미리 빌드된 파일에 의존하는 대신 항상 최신 데이터를 표시합니다.

일반 API 엔드포인트처럼 생각하세요. 모든 것이 온디맨드로 계산됩니다.

왜 중요한가:

콘텐츠를 신선하게 유지하고 개인화하기 쉽습니다.
실시간 데이터나 개인화된 콘텐츠가 필요한 페이지에 완벽합니다.
참고: 트래픽이 많으면 SSR이 느려질 수 있습니다. 온디맨드로 각 페이지를 빌드하기 때문이지만, 캐싱이 로드와 속도의 균형을 맞추는 데 도움이 될 수 있습니다.

사용 사례: 소셜 미디어 피드, 관리자 대시보드, 또는 세션별로 콘텐츠가 달라지는 사용자별 페이지.

4. 클라이언트 사이드 렌더링 (CSR)

CSR은 서버 대신 브라우저가 대부분의 작업을 수행한다는 의미입니다. 서버는 기본 HTML 페이지와 약간의 JavaScript만 보냅니다. 그런 다음 브라우저가 데이터를 로드하고 즉시 페이지를 빌드합니다.

이 접근 방식은 풍부한 상호작용성, 실시간 업데이트 또는 사용자 작업에 따라 자주 변경되는 페이지가 필요할 때 유용합니다. 정적이거나 서버 렌더링된 페이지가 쉽게 처리할 수 없는 것들입니다.

원시 JSON을 보내고 클라이언트가 조립하도록 하는 것과 같습니다.

참고: 브라우저가 콘텐츠를 표시하기 전에 JavaScript를 다운로드하고 실행해야 하므로 첫 페이지 로드가 느릴 수 있습니다. 페이지가 브라우저에서 빌드되므로 검색 엔진이 즉시 보지 못할 수 있어 더 나은 SEO를 위해 사전 렌더링이나 서버 사이드 렌더링과 같은 추가 설정이 필요할 수 있습니다.

왜 중요한가:

서버의 부담을 줄입니다.
앱을 더 상호작용적이고 반응적으로 만듭니다.
대시보드나 에디터처럼 사람들이 오랫동안 사용하는 앱에 가장 적합합니다.

사용 사례: Figma, Notion, Google Docs와 같이 매우 상호작용적이고 사용자가 오랫동안 페이지에 머무르는 복잡한 앱.

5. 하이브리드 렌더링

때로는 한 가지 접근 방식만으로는 충분하지 않습니다.

앱의 다른 부분은 다른 요구 사항을 가질 수 있습니다. 예를 들어, 일부 페이지는 대부분 동일하게 유지되지만 다른 페이지는 신선하거나 개인화된 데이터가 필요합니다. 여기서 하이브리드 렌더링이 등장합니다.

다양한 전략을 혼합합니다:

라이브 또는 개인화된 콘텐츠가 필요한 페이지에는 서버 사이드 렌더링(SSR),
거의 변경되지 않는 페이지에는 정적 사이트 생성(SSG),
많은 상호작용이 있는 섹션에는 클라이언트 사이드 렌더링(CSR).

미리 계산된 API 응답과 온디맨드 엔드포인트를 결합하는 것과 같습니다. 모두 동일한 시스템에서.

왜 중요한가:

모든 것의 장점을 얻습니다: 속도, 신선한 콘텐츠, 상호작용성.
각 페이지나 컴포넌트에 적합한 접근 방식을 선택할 수 있습니다.
필요한 곳에서 콘텐츠를 동적으로 유지하면서 서버 과부하를 줄입니다.

사용 사례: 전자상거래 플랫폼과 같은 대규모 앱은 종종 다양한 렌더링 전략을 결합합니다:

홈페이지와 카테고리 페이지는 속도를 위해 정적 생성을 사용합니다.
제품 페이지는 콘텐츠를 신선하게 유지하기 위해 증분 정적 재생성을 사용합니다.
사용자 계정 페이지는 개인화된 데이터를 위해 서버 사이드 렌더링을 사용합니다.
장바구니는 페이지 새로고침 없이 실시간 업데이트를 위해 클라이언트 사이드 렌더링을 사용합니다.

6. 콘텐츠 전송 네트워크 (CDN) & 엣지 전송

어떤 렌더링 방법을 선택하든 콘텐츠를 효율적으로 제공하는 것이 매우 중요합니다. CDN은 전 세계 서버에 정적 파일의 복사본을 보관합니다. 이를 통해 사용자는 메인 서버 대신 가까운 위치에서 파일을 다운로드할 수 있습니다.

이는 특히 글로벌 사용자에게 유용합니다. 예를 들어, 인도의 누군가가 미국에서 호스팅되는 사이트를 방문하면 CDN이 로컬 서버에서 콘텐츠를 전달하여 훨씬 빠르게 로드됩니다.

엣지 렌더링은 이 아이디어를 한 단계 더 발전시킵니다. 정적 파일을 제공하는 것뿐만 아니라 실제로 엣지에서 사용자에게 더 가까이 코드를 실행하거나 페이지를 빌드할 수 있어 지연 시간을 더욱 줄입니다.

사용자 근처에 캐시와 컴퓨팅 노드를 두는 것과 같아서 요청이 메인 데이터베이스 대신 가까운 서버로 갑니다.

왜 중요한가:

어디서나 더 빠른 로드 시간.
수백만 명의 사용자로 쉽게 확장 가능.
SSG, ISR, SSR 또는 하이브리드 설정과 완벽하게 작동합니다.

사용 사례: 모든 전 세계적으로 분산된 애플리케이션. The New York Times와 같은 미디어 사이트는 CDN을 사용하여 전 세계에 기사를 즉시 제공합니다.

성능 & 최적화

페이지가 어떻게 렌더링되는지 이해했으니, 다음 명백한 질문은 "실제로 얼마나 빠르게 로드되는가?"입니다.

가장 아름다운 앱도 열리는 데 너무 오래 걸리거나 사용 중에 지연되면 답답할 수 있습니다. 프론트엔드 시스템 디자인에서 속도는 정말 중요합니다.

자세히 살펴보겠습니다!

7. 웹 성능 메트릭

앱의 속도를 정말로 이해하려면 주의 깊게 지켜봐야 할 몇 가지 주요 메트릭이 있습니다:

TTFB (Time to First Byte): 요청 후 브라우저가 서버나 CDN에서 첫 번째 데이터를 받는 데 걸리는 시간.

FCP (First Contentful Paint): 텍스트, 이미지 또는 버튼과 같은 무언가가 화면에 처음 나타나는 순간으로, 사용자가 페이지가 로드되고 있음을 알 수 있습니다.

LCP (Largest Contentful Paint): 큰 이미지나 헤드라인과 같은 페이지의 주요 부분이 화면에 완전히 나타나는 데 걸리는 시간.

CLS (Cumulative Layout Shift): 이미지나 광고가 아직 로드 중일 때 텍스트나 버튼이 갑자기 이동하는 것처럼 로드하는 동안 페이지 레이아웃이 얼마나 흔들리는지 측정합니다.

이것들은 기본적으로 백엔드 시스템의 응답 시간, 처리량, 지연 시간의 프론트엔드 버전입니다. 이를 면밀히 주시하는 것이 중요합니다. 사용자는 몇 백 밀리초의 작은 지연도 알아챌 수 있습니다.

왜 중요한가:

사용자가 알아채기 전에 느린 페이지를 발견할 수 있습니다.
참여도를 높이고 이탈률을 줄입니다.
더 부드러운 경험을 위한 최적화를 안내하는 데 도움이 됩니다.

사용 사례: 전자상거래 사이트는 LCP(제품 이미지)와 CLS(체크아웃 중 레이아웃 이동 방지)를 최적화해야 합니다. 뉴스 사이트는 헤드라인을 빠르게 표시하기 위해 FCP에 집중합니다.

8. 지연 로딩

물론 빠른 페이지는 메트릭에 관한 것만이 아니라 스마트한 리소스 관리에 관한 것이기도 합니다.

페이지의 모든 것이 즉시 로드될 필요는 없습니다. 지연 로딩은 이미지, 비디오 또는 큰 컴포넌트와 같은 무거운 자산을 실제로 필요할 때만 로드하는 것을 의미합니다.

이는 Intersection Observer API나 조건부 import와 같은 기술을 사용하여 작동하며, 브라우저에 해당 리소스가 뷰에 들어오거나 사용자 상호작용에 의해 트리거될 때만 가져오도록 지시합니다.

사용자가 요청할 때만 API에서 추가 데이터를 가져오는 것과 같습니다.

왜 중요한가:

초기 로드 시간을 줄입니다.
페이지를 더 빠르고 부드럽게 느끼게 합니다.
즉시 모든 것이 필요하지 않은 사용자의 대역폭을 절약합니다.

사용 사례: Pinterest나 Instagram과 같은 이미지가 많은 사이트는 지연 로딩을 광범위하게 사용합니다. 스크롤하기 전까지 아래쪽 이미지는 로드되지 않습니다.

9. 서비스 워커 & 캐싱

로딩을 최적화한 후에는 서비스 워커와 캐싱을 사용하여 앱을 더 빠르고 안정적으로 만들 수 있습니다.

서비스 워커는 메인 웹 페이지와 별도의 스레드에서 실행되는 백그라운드 스크립트입니다. 네트워크 요청을 가로채고 중요한 파일이나 데이터를 캐시하여 앱을 더 빠르게 로드하고 오프라인에서도 작동하도록 도울 수 있습니다.

브라우저와 네트워크 사이의 스마트 중간 레이어로 생각하세요. 이미 캐시된 것이 있으면 다시 가져오는 대신 즉시 제공됩니다.

왜 중요한가:

반복 방문 속도를 높입니다.
서버의 부하를 줄입니다.
인터넷 연결이 좋지 않거나 없어도 앱을 사용할 수 있게 유지합니다.

사용 사례: Twitter Lite나 Starbucks PWA와 같은 프로그레시브 웹 앱은 핵심 UI와 최근 콘텐츠를 캐시하므로 사용자가 불안정한 모바일 네트워크에서도 탐색할 수 있습니다.

데이터 & 상태 관리

UI가 빠르게 로드되면 다음 단계는 그 뒤에 있는 데이터에 대해 생각하는 것입니다.

실제 앱에서 이 데이터(상태라고도 함)는 다양한 곳에서 올 수 있습니다:

일부는 단일 컴포넌트 내부에 있습니다(버튼과 같은 재사용 가능한 UI 조각),
일부는 앱 전체에서 공유됩니다,
그리고 다른 것들은 API에서 옵니다.

이 상태를 관리하는 방법은 앱의 속도, 안정성 및 확장성을 좌우할 수 있습니다.

10. 상태 관리 (로컬, 글로벌, 서버 캐시)

로컬 상태: 토글, 폼 또는 작은 상호작용과 같은 것에 사용되는 단일 컴포넌트 내부에 있는 데이터. 관리하기 쉽고 복잡성을 많이 추가하지 않습니다.

글로벌 상태: 사용자 정보나 테마 설정처럼 여러 컴포넌트나 페이지에서 공유되는 데이터. Redux, Zustand 또는 React Context와 같은 도구가 관리하는 데 도움이 됩니다.

서버 캐시: 자주 사용되는 API 데이터를 클라이언트에 저장하여 앱이 반복해서 가져올 필요가 없도록 하여 더 빠르게 만들고 서버 부하를 줄입니다.

데이터베이스 캐싱과 같습니다. 데이터가 어디에 있어야 하는지 결정함으로써 앱을 더 반응적이고 안정적이며 확장하기 쉽게 만들 수 있습니다.

왜 중요한가:

앱을 반응적으로 유지합니다.
불필요한 API 호출을 줄입니다.
앱이 성장함에 따라 확장을 더 원활하게 만듭니다.

사용 사례: 모달의 열림/닫힘 상태는 로컬 상태. 모든 컴포넌트에 영향을 미치는 테마 기본 설정(다크 모드)은 글로벌 상태. 여러 컴포넌트에서 표시되는 사용자 프로필 데이터는 서버 측 캐시.

11. 만료 기능이 있는 API 캐싱

캐싱은 컴포넌트 수준에서 멈추지 않습니다. API 응답을 메모리, IndexedDB(더 큰 데이터를 위한 브라우저 데이터베이스) 또는 localStorage(더 작은 키-값 데이터용)에 저장하고 만료 규칙을 설정하여 데이터가 신선하게 유지되도록 할 수 있습니다.

서버가 아닌 브라우저에 Redis 캐시 서버가 있는 것과 같습니다.

왜 중요한가:

사용자를 위해 데이터를 최신 상태로 유지합니다.
반복되는 서버 요청을 줄입니다.
앱을 더 빠르게 느끼게 합니다.

사용 사례: 뉴스 앱은 사용자가 오프라인에서 읽을 수 있도록 기사를 몇 분 동안 캐시할 수 있으며, 댓글은 최신 상태로 유지하기 위해 더 자주 새로고침됩니다. 마찬가지로 SaaS 대시보드는 사용자가 페이지에 있는 동안 차트 데이터를 캐시한 다음 나중에 돌아올 때 새로고침할 수 있습니다.

12. GraphQL vs REST (과다/과소 페칭 줄이기)

데이터를 가져오는 방법도 성능에 영향을 미칩니다.

REST: 때때로 너무 많은 데이터를 보내거나 충분하지 않아 앱이 추가 정보를 가져오거나 추가 요청이 필요하게 만들 수 있습니다.

GraphQL: 클라이언트가 필요한 데이터를 정확히 요청할 수 있는 API용 쿼리 언어로, 추가 또는 누락된 정보를 피합니다. 이는 데이터 과다 페칭이나 과소 페칭을 방지하고 불필요한 요청을 줄이는 데 도움이 됩니다.

백엔드에서 데이터베이스 쿼리를 최적화하여 더 빠르게 만들고 대역폭을 덜 사용하는 것과 같지만, 이것은 프론트엔드에서 발생합니다.

GraphQL은 클라이언트와 서버 사이에 하나의 엔드포인트로 위치합니다. 클라이언트가 필요한 데이터를 정확히 요청하면 서버의 GraphQL 레이어가 데이터베이스나 다른 API에서 해당 데이터를 수집한 다음 깨끗하고 정리된 응답을 다시 보냅니다.

이렇게 하면 여러 REST 호출 대신 하나의 유연한 요청을 만들어 더 빠르고 데이터 효율적입니다.

왜 중요한가:

특히 모바일 네트워크에서 대역폭을 절약합니다.
불필요한 요청을 줄입니다.
클라이언트 측 데이터 처리를 단순화합니다.

사용 사례: GraphQL은 GitHub와 같이 한 번에 여러 곳에서 데이터가 필요한 복잡한 앱에 가장 적합합니다. 하나의 GraphQL 쿼리로 여러 REST 호출 대신 단일 요청으로 풀 리퀘스트, 댓글 및 작성자 정보를 가져올 수 있습니다. REST는 더 간단하고 블로그나 캐싱에 의존하는 공개 API와 같이 안정적인 데이터가 있는 앱에 적합합니다.

13. 페이지네이션 전략 (커서 vs 오프셋)

큰 목록이나 테이블을 한 번에 모두 로드하는 것은 무거울 수 있습니다. 페이지네이션은 데이터를 관리 가능한 청크로 나누는 데 도움이 됩니다.

오프셋 페이지네이션: 페이지 번호나 레코드 수(예: ?page=2 또는 ?offset=20)를 사용하여 데이터를 가져옵니다. 간단하고 자주 변경되지 않는 목록에 적합합니다. 그러나 새 항목이 추가되거나 이전 항목이 제거되면 목록 순서가 이동합니다. 이로 인해 동일한 오프셋이 다른 항목을 반환하여 중복 또는 누락된 항목이 발생할 수 있습니다.

커서 페이지네이션: 포인터를 사용하여 마지막 항목이 끝난 위치를 표시하므로 다음 요청이 바로 그 다음부터 시작됩니다. 라이브 또는 자주 업데이트되는 데이터(소셜 피드 또는 채팅 메시지)에 더 안정적입니다. 데이터셋의 정확한 위치를 추적하기 때문입니다. 즉, 스크롤하는 동안 새 항목이 추가되거나 제거되더라도 중복을 보거나 항목을 놓치지 않습니다.

왜 중요한가:

대규모 데이터셋을 효율적으로 처리합니다.
속도 저하 및 성능 병목 현상을 방지합니다.
동적 목록을 안정적이고 일관되게 유지합니다.

사용 사례:

오프셋 페이지네이션: 관리 패널이나 제품 카탈로그와 같이 안정적인 데이터와 명확한 페이지 번호가 있는 데이터 테이블에 가장 적합합니다.

커서 페이지네이션: 소셜 미디어 타임라인, 알림 목록 또는 항목이 자주 추가되거나 제거되는 실시간 목록과 같은 무한 스크롤 피드에 이상적입니다.

14. 실시간 데이터 & 네트워킹 (WebSockets, SSE, Polling)

마지막으로 일부 앱은 채팅 앱, 대시보드 또는 알림과 같은 라이브 업데이트가 필요합니다. 실시간 데이터를 처리하는 방법이 중요합니다.

WebSockets: 클라이언트와 서버가 지속적으로 업데이트를 요청하지 않고도 실시간으로 양방향으로 메시지를 서로 보낼 수 있습니다.

서버 전송 이벤트 (SSE): 서버가 클라이언트에 실시간으로 업데이트를 푸시할 수 있지만 통신은 서버에서 클라이언트로 한 방향으로만 이루어집니다.

폴링: 클라이언트가 정기적으로 서버에 업데이트를 요청합니다. 설정하기 쉽지만 서버에 더 많은 부하를 줄 수 있습니다.

백엔드에서 이벤트 기반 시스템을 구축하는 것과 같지만 여기서는 브라우저에서 발생합니다.

왜 중요한가:

라이브 대시보드, 채팅 및 알림을 지원합니다.
상호작용성과 사용자 참여도를 향상시킵니다.
앱의 요구 사항에 맞는 올바른 전략을 선택할 수 있습니다.

사용 사례:

WebSockets: 채팅 앱(Slack), 멀티플레이어 게임, 협업 편집(Google Docs).

SSE: 라이브 알림, 주식 시세, 대시보드로 스트리밍되는 서버 로그.

폴링: 새 이메일 확인 또는 상태 업데이트와 같은 간단한 사용 사례.

아키텍처 & 확장성

앱이 성장함에 따라 복잡성을 관리하는 것이 기능을 작성하는 것만큼 중요해집니다. 프론트엔드 아키텍처는 코드에 관한 것만이 아니라 유지 관리 가능하고 확장 가능하며 예측 가능한 시스템을 구축하는 것입니다.

15. 마이크로 프론트엔드

여러 팀이 동일한 앱에서 작업할 때 빠르게 혼란스러워질 수 있습니다.

마이크로 프론트엔드는 각 팀이 앱의 일부를 별도로 빌드하고 배포할 수 있게 합니다. 예를 들어, 한 팀은 대시보드를 처리하고 다른 팀은 설정 페이지를 빌드합니다. 기술적으로 앱은 런타임에 결합되어 하나의 원활한 앱으로 작동하는 더 작은 프론트엔드 프로젝트로 나뉩니다.

모듈 페더레이션 기능(예: Webpack과 같은 도구)을 사용하면 이러한 별도 프로젝트가 프로젝트 전체에서 코드를 재빌드하거나 복제하지 않고도 브라우저에서 직접 코드(컴포넌트나 유틸리티 등)를 공유할 수 있습니다.

왜 중요한가:

팀이 기능을 더 빠르고 병렬로 개발할 수 있습니다.
번들 전체에서 중복된 코드를 줄입니다.
독립적인 배포 주기를 지원하므로 업데이트가 서로를 차단하지 않습니다.

사용 사례: 여러 팀이 다른 제품 영역에서 작업하는 대기업. 예를 들어, Zalando, IKEA, DAZN, Spotify와 같은 대기업은 마이크로 프론트엔드를 사용하여 각 팀이 앱의 자신의 부분을 자체적으로 빌드하고 릴리스할 수 있습니다.

16. 컴포넌트 기반 아키텍처 & 디자인 시스템

컴포넌트는 앱의 빌딩 블록입니다. 디자인 시스템은 이러한 컴포넌트가 팀과 프로젝트 전체에서 일관되고 재사용 가능하도록 보장합니다.

재사용 가능한 백엔드 모듈이나 라이브러리가 있는 것과 같지만 UI용입니다.

왜 중요한가:

UI를 예측 가능하고 유지 관리하기 쉽게 만듭니다.
페이지와 프로젝트 전체에서 코드 재사용을 장려합니다.
팀이 혼란을 만들지 않고 효율적으로 확장하는 데 도움이 됩니다.

사용 사례: 디자인을 일관되게 유지하기 위해 많은 제품이나 팀을 가진 회사에서 사용됩니다. Shopify의 Polaris나 IBM의 Carbon과 같은 오픈 소스 디자인 시스템은 즉시 사용 가능한 UI 컴포넌트, 스타일 및 가이드라인을 포함합니다.

소규모 스타트업도 이점을 얻습니다. 10-20개의 공유 컴포넌트 세트(버튼 및 모달 등)는 팀이 더 빠르게 빌드하고 UI를 일관되게 유지하는 데 도움이 됩니다.

17. 빌드 & 배포 파이프라인 (프론트엔드용 CI/CD)

프론트엔드 앱도 백엔드 서비스처럼 CI/CD(지속적 통합 및 지속적 배포) 파이프라인의 이점을 얻습니다. 이러한 파이프라인은 앱 빌드, 테스트 실행 및 업데이트 배포와 같은 단계를 자동으로 처리합니다.

간단히 말해서, 코드를 푸시할 때마다 CI/CD 도구가 아무것도 깨지지 않았는지 확인한 다음 안전하게 최신 버전을 릴리스하여 배포를 더 빠르고 안정적이며 수동 작업을 덜 필요로 합니다.

왜 중요한가:

배포 중 인적 오류를 최소화합니다.
빠르고 안정적인 릴리스를 가능하게 합니다.
확장 및 빈번한 업데이트를 훨씬 원활하게 만듭니다.

사용 사례: 정기적으로 업데이트되는 모든 앱에 적용됩니다. Vercel에 자동 배포하는 소규모 팀부터 하루에 수천 번 릴리스하는 Netflix와 같은 대기업까지. 업데이트를 빠르고 안전하며 안정적으로 유지합니다.

사용자 경험 & 안정성

사용자는 여러분의 아키텍처나 캐싱 전략에 관심이 없습니다. 그들은 앱이 빠르고 안정적이며 사용하기 쉽기를 원할 뿐입니다.

18. 접근성 (a11y) & 모바일 우선 디자인

접근성과 모바일 우선 디자인은 단순한 디자인 원칙이 아니라 시스템 수준의 고려 사항입니다. 접근성은 앱의 UI와 코드 구조가 보조 기술을 사용하는 사람들을 포함하여 모든 사람을 위해 작동하도록 보장합니다.

모바일 우선 디자인은 효율적인 레이아웃을 구축하고, 더 가벼운 자산을 로드하며, 주요 기능의 우선순위를 정하도록 강제하며, 이 모든 것이 성능, 확장성 및 전반적인 프론트엔드 아키텍처에 영향을 미칩니다.

왜 중요한가:

더 많은 사용자에게 도달합니다.
앱을 더 쉽고 즐겁게 사용할 수 있게 합니다.
기기 전체에서 일관된 경험을 보장합니다.

사용 사례: 정부 사이트(많은 국가에서 접근성이 법적으로 요구됨), 전자상거래 및 콘텐츠 플랫폼. 모바일 우선은 모바일이 주요 또는 유일한 기기인 개발도상국 시장의 앱에 필수적입니다.

19. 프로그레시브 웹 앱 (PWA) & 오프라인 우선

프로그레시브 웹 앱(PWA)은 네이티브 앱처럼 작동하는 웹 앱입니다. 오프라인에서 작동하고, 알림을 보내며, 기기에 설치할 수도 있습니다.

몇 가지 주요 기술을 사용합니다:

서비스 워커는 백그라운드에서 실행되어 HTML, CSS 및 API 응답과 같은 중요한 파일을 캐시합니다.
웹 앱 매니페스트는 앱이 설치될 때 어떻게 보이고 작동하는지 정의합니다.
그리고 HTTPS는 모든 것을 안전하게 유지합니다.

함께 이것들은 앱을 빠르고 안정적이며 설치 가능하게 만듭니다.

왜 중요한가:

사용자가 어디서나 앱에 액세스할 수 있습니다.
서버의 부하를 줄입니다.
안정성과 사용자 신뢰를 향상시킵니다.

사용 사례: 오프라인 액세스가 가치 있는 앱: Twitter Lite, Starbucks PWA, 현장 서비스 앱 및 뉴스 앱.

20. 보안 기본 사항 (XSS, CSRF, CSP, 인증)

보안 없이는 속도가 의미가 없습니다. 프론트엔드는 UI에 관한 것만이 아니라 앱의 첫 번째 방어선이기도 합니다.

XSS (크로스 사이트 스크립팅): 공격자가 악성 스크립트를 앱에 주입하는 것을 막습니다.

CSRF (크로스 사이트 요청 위조): 사용자의 동의 없이 공격자가 데이터를 변경하는 폼과 작업을 트리거하는 것으로부터 보호합니다.

CSP (콘텐츠 보안 정책): 악성 스크립트가 앱에서 실행되는 것을 방지하는 데 도움이 되는 규칙 세트.

인증: 사용자 토큰과 세션이 브라우저에서 안전하게 저장되고 처리되도록 합니다.

왜 중요한가:

사용자와 그들의 데이터를 보호합니다.
백엔드에 도달하기 전에 일반적인 공격을 방지합니다.
신뢰를 구축하고 규정 준수에 도움이 됩니다.

사용 사례: 민감한 데이터를 처리하는 모든 앱. 금융 앱은 엄격한 CSP 및 토큰 처리가 필요합니다. 소셜 플랫폼은 계정 탈취를 방지하기 위해 XSS를 방지해야 합니다. 전자상거래 사이트는 무단 구매를 방지하기 위해 체크아웃에서 CSRF 보호가 필요합니다.

21. 관찰 가능성 & 오류 모니터링 (클라이언트 측)

모든 것이 잘 작동하더라도 프로덕션에서 여전히 문제가 발생할 수 있습니다. 그래서 관찰 가능성이 중요합니다.

프론트엔드 오류는 백엔드의 500 오류와 같습니다. 발생합니다. Sentry나 LogRocket과 같은 모니터링 도구는 다음을 추적하는 데 도움이 됩니다:

JS 예외: 앱이 실행되는 동안 JavaScript 코드에서 발생하는 오류.

성능 병목 현상: 앱을 느리게 하거나 지연시키는 부분.

오류로 이어지는 사용자 상호작용: 앱에서 버그나 충돌을 트리거하는 사용자의 작업.

이러한 도구는 앱에 작은 스크립트를 추가합니다. 문제가 발생하면 오류 메시지, 사용자가 수행한 작업 및 브라우저 세부 정보와 같은 정보를 수집합니다. 그런 다음 해당 데이터를 도구의 서버로 보내면 대시보드에서 문제를 확인하고 수정할 수 있습니다.

왜 중요한가:

문제를 더 빠르게 감지하고 해결합니다.
앱을 안정적이고 성능이 좋게 유지합니다.
전반적인 사용자 경험과 신뢰를 향상시킵니다.

사용 사례: 실제 사용자가 있는 프로덕션 앱에서 사용됩니다. SaaS 팀은 배포 직후 오류를 추적하고, 전자상거래 사이트는 체크아웃 문제를 확인하며, 세션 재생 도구는 지원 팀이 추가 버그 보고서 없이 사용자가 혼란스러워한 것을 볼 수 있도록 도와줍니다.

결론

프론트엔드 시스템 디자인은 기본적으로 백엔드 시스템 디자인이며, 단지 사용자의 브라우저에서 발생할 뿐입니다.

렌더링 방법, 캐싱 전략, 상태 관리, 아키텍처 및 보안과 같이 여러분이 내리는 모든 선택은 속도, 확장성 및 안정성에 영향을 미칩니다.

따라서 다음에 프론트엔드를 구축할 때 다음과 같이 자문해 보세요:

계산이 어디에서 일어나야 하는가? 서버에서, 클라이언트의 브라우저에서, 아니면 엣지에서?
데이터가 언제 최신 상태여야 하는가? 미리 빌드된, 캐시된, 아니면 실시간?
앱을 빠르고 안정적으로 유지하려면 어떻게 해야 하는가? 지연 로딩, 스마트 캐싱 또는 마이크로 프론트엔드?
이것을 어떻게 확장하는가? 아키텍처가 10배 트래픽을 처리할 수 있는가? 100배는?
이것을 어떻게 유지 관리하는가? 새로운 개발자가 아키텍처를 이해할 수 있는가? 팀이 독립적으로 작업할 수 있는가?

프론트엔드를 분산 시스템으로 생각하세요. 그렇게 다루면 사용자는 빠르고 부드러우며 원활한, 바로 그들이 기대하는 앱을 얻게 될 것입니다.

👋 이 뉴스레터를 작성해 주신 Shefali에게 감사드립니다!

그녀의 작업과 소셜을 확인하는 것도 잊지 마세요:

그녀는 웹 개발에 대해 글을 쓰고, UI 팁을 공유하며, 개발자들의 삶을 더 쉽게 만드는 도구를 만드는 일을 자주 하고 있습니다.

🚨 Design, Build, Scale 🚨

Design, Build, Scale 출시를 알리게 되어 기쁩니다!

(인기 있는 인터뷰 질문을 분석하는 3부작 뉴스레터 시리즈입니다.)

유료 회원 전용...

여러분이 얻게 될 것들:

실제 사례 연구의 고수준 아키텍처.
인기 있는 실제 시스템이 실제로 어떻게 작동하는지 깊이 있게 살펴봅니다.
실제 시스템이 확장성, 안정성 및 성능을 처리하는 방법.
현재 얻는 결과의 10배를 시간, 에너지 및 노력의 1/10로.

시작일: 2025년 11월

👉 여기를 클릭하여 가입 (60초 소요)

이 뉴스레터가 가치 있다고 생각되면 친구와 공유하고 아직 구독하지 않았다면 구독하세요. 그룹 할인, 선물 옵션 및 추천 보너스가 제공됩니다.

이 뉴스레터에 광고하고 싶으신가요? 📰

귀사가 180K+ 기술 독자에게 도달하고 싶다면 저와 함께 광고하세요.

이 뉴스레터를 지원해 주셔서 감사합니다.

이제 180,001명 이상의 독자가 있으며 181k에 매우 가깝습니다. 11월 21일까지 181k 독자를 확보하도록 노력합시다. 이 글을 친구들과 공유하고 보상을 받으세요.

여러분은 최고입니다.

블록 다이어그램은 Eraser로 제작되었습니다.

훌륭한 글입니다! 개발자에게 유용합니다.

정말 좋아요