Blazor 처음부터: 1장 — Blazor란 무엇인가?

· 5분 읽기
Blazor .NET Web Development Series
Available in: 한국어 · English · Español · Français · Deutsch · Português · 日本語 · Русский · 中文 · العربية · हिन्दी · Polski · Türkçe · Bahasa Indonesia · Nederlands

Blazor 처음부터 시리즈의 1장에 오신 것을 환영합니다. 이 시리즈의 목적과 대상 독자를 설명한 소개 포스트를 놓치셨다면 먼저 읽어보세요 — 짧습니다.

이 챕터에서는 근본적인 질문에 답할 것입니다: Blazor란 무엇인가? 단순해 보이지만, 특히 “Blazor"가 수년에 걸쳐 약간씩 다른 의미를 갖게 되었기 때문에 답변에는 여러 층이 있습니다. 이 포스트가 끝날 때쯤 여러분은 Blazor가 무엇인지, .NET 생태계에서 어떻게 자리 잡는지, 다양한 렌더링 모델이 무엇인지, 그리고 왜 JavaScript 프레임워크 대신 이것을 선택할 수도 있는지 알게 될 것입니다.

간략한 역사

Blazor는 2017년경 Microsoft의 Steve Sanderson이 진행한 실험적 프로젝트로 시작되었습니다. 아이디어는 도발적이었습니다: WebAssembly를 사용하여 브라우저에서 C#을 실행하여 JavaScript의 필요성을 완전히 없애는 것이었습니다. 개념 증명이었으며, 이름은 Blazer와 Razor를 의도적으로 합친 것이었습니다 — Razor는 Blazor가 결국 위에 구축될 템플릿 엔진입니다.

실험은 Microsoft가 진지하게 받아들일 만큼 충분한 관심을 불러일으켰습니다. Blazor는 2019년 9월 ASP.NET Core 3.0의 일부로 출시되었으며, 처음에는 Blazor Server — 서버에서 C# 코드를 실행하고 실시간 SignalR 연결을 사용하여 브라우저에 UI 업데이트를 전송하는 모델이었습니다. Blazor WebAssembly는 ASP.NET Core 3.1의 일부로 2020년 5월에 뒤따라, 프레임워크에 진정한 클라이언트 측 실행을 가져왔습니다.

.NET 6과 7은 개발자 경험을 다듬었습니다. 그런 다음 2023년 11월에 출시된 .NET 8은 Microsoft가 풀스택 웹 UI라고 부르는 것으로 렌더링 모델을 근본적으로 재고했습니다. 정적 서버 사이드 렌더링, 스트리밍 렌더링, 인터랙티브 서버, 인터랙티브 WebAssembly, 그리고 새로운 Auto 모드가 단일 프로젝트의 동일한 지붕 아래 공존하게 되었습니다. .NET 9는 이 기반 위에 구축하고 거친 부분을 다듬었습니다.

오늘날 우리가 있는 곳이 바로 여기입니다.

Blazor가 실제로 무엇인가

핵심적으로, Blazor는 .NET을 위한 컴포넌트 기반 UI 프레임워크입니다. 컴포넌트로 UI를 구축합니다 — 상태를 유지하고, 이벤트에 반응하며, 더 큰 구조로 구성될 수 있는 C#과 HTML 마크업의 자기 완결적 조각들입니다. React나 Vue로 작업해본 적이 있다면 이 멘탈 모델이 익숙하게 느껴질 것입니다. 핵심 차이점은 JavaScript 대신 C#을 작성한다는 것입니다.

Blazor의 컴포넌트는 .razor 파일로 작성됩니다. .razor 파일은 ASP.NET MVC 뷰에서 이미 알고 있을 수 있는 Razor 구문을 사용하여 HTML 마크업과 C# 코드를 혼합합니다. 간단한 컴포넌트는 다음과 같습니다:

@page "/counter"

<h1>카운터</h1>
<p>현재 카운트: @currentCount</p>
<button @onclick="IncrementCount">클릭하세요</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

JavaScript는 보이지 않습니다. @onclick 지시자는 버튼 클릭을 C# 메서드에 연결합니다. @currentCount 표현식은 현재 값을 렌더링합니다. 상태가 변경되면 Blazor는 DOM에서 무엇을 업데이트할지 파악합니다.

그것이 핵심입니다. 그 외 모든 것 — 라우팅, 의존성 주입, 폼, HTTP 호출 — 이 컴포넌트 모델 위에 구축됩니다.

렌더링 모델

여기에 많은 혼란이 존재하므로 정확히 살펴보겠습니다. 오늘날 “Blazor"는 단일 배포 모델이 아닌 렌더링 모드의 계열을 의미합니다. 차이를 이해하는 것이 중요한 이유는 성능, 인프라 요구 사항, 그리고 컴포넌트가 할 수 있는 것과 없는 것에 영향을 미치기 때문입니다.

정적 SSR

가장 간단한 모드입니다. Razor 컴포넌트가 서버에서 HTML로 렌더링되고 그 HTML이 브라우저로 전송됩니다. 영구적인 연결도, WebAssembly도, 기본적으로 클라이언트 측 인터랙티비티도 없습니다. 이것은 본질적으로 Razor Pages가 하는 일이지만, 컴포넌트 모델을 사용합니다.

콘텐츠가 많은 페이지, 랜딩 페이지, 실시간 인터랙티비티가 필요 없는 모든 것에 사용하세요.

인터랙티브 서버

컴포넌트 코드가 서버에서 실행됩니다. 브라우저와 서버 사이에 SignalR WebSocket 연결이 설정됩니다. 버튼을 클릭하거나 입력 필드에 타이핑하면 이벤트가 WebSocket을 통해 서버로 전달되고, C#이 실행되며, 차이가 계산되고, DOM 업데이트가 브라우저로 다시 전송됩니다.

장점: 서버 리소스(데이터베이스, 파일 시스템, 시크릿)에 대한 완전한 접근. 빠른 초기 로드. 작은 다운로드 크기. WebAssembly 지원 없이도 브라우저에서 작동합니다.

단점: 모든 사용자 인터랙션이 서버 왕복을 필요로 하여 지연이 추가됩니다. 서버 리소스는 활성 연결 수에 따라 확장됩니다. 연결이 끊기면 앱이 저하됩니다.

비즈니스 앱, 내부 도구, 오프라인 기능보다 서버 측 데이터 접근이 더 중요한 앱에 사용하세요.

인터랙티브 WebAssembly

.NET 런타임이 브라우저에 다운로드되고 앱이 완전히 클라이언트에서 실행됩니다. 초기 다운로드 후, 앱은 완전히 오프라인으로 작동하고 모든 인터랙션이 즉각적입니다 — UI 로직을 위한 서버 왕복이 없습니다.

장점: 진정한 클라이언트 측 실행. 오프라인 작동. 앱 로드 후 서버 부하 감소.

단점: 더 큰 초기 다운로드(.NET 런타임 + 앱). 더 느린 첫 번째 로드. 서버 측 데이터에 접근하려면 API가 필요합니다.

오프라인 기능이 있는 앱, 즉각적인 반응성이 필요한 도구, UI에 서버 처리가 필요하지 않은 시나리오에 사용하세요.

Auto 모드

.NET 8에서 도입되었습니다. 앱은 인터랙티브 서버 모드로 시작합니다(빠른 초기 로드, WebAssembly 다운로드를 기다리지 않음). WebAssembly 파일이 백그라운드에서 다운로드되면 이후 방문은 자동으로 WebAssembly 모드로 전환됩니다.

이것은 서버 모드의 빠른 첫 번째 로드와 결국 WebAssembly의 완전한 클라이언트 측 실행을 모두 제공합니다. 이해하기 가장 복잡한 모델이지만 많은 앱에 실용적인 기본값입니다.

동일한 앱에서 모드 혼합

.NET 8 이상에서는 전체 앱에 대해 단일 렌더링 모드에 고정되지 않습니다. 마케팅 랜딩 페이지는 정적 SSR일 수 있고, 인증된 대시보드는 인터랙티브 서버일 수 있으며, 데이터 시각화 위젯은 인터랙티브 WebAssembly일 수 있습니다. 프레임워크가 전환을 처리합니다.

이 시리즈에서는 인터랙티브 서버로 시작할 것입니다. 가장 간단하게 작동시킬 수 있고 가장 직관적인 멘탈 모델을 가지고 있기 때문입니다. 다른 모드는 진행하면서 탐색하겠습니다.

Blazor와 JavaScript 프레임워크 비교

React, Angular, 또는 Vue로 개발해본 적이 있다면 아마도 이 비교가 궁금할 것입니다.

유사점은 실재합니다. Blazor의 컴포넌트 모델은 의도적으로 React와 유사합니다. props(Blazor에서는 Parameters), 로컬 상태(@code 블록의 필드), 라이프사이클 훅, 그리고 동일한 단방향 데이터 흐름 / 이벤트 업 통신 패턴이 있습니다. React를 안다면 몇 시간 안에 익숙해질 것입니다.

핵심 차이점은 언어입니다. Blazor에서는 C#을 작성합니다. 비즈니스 로직, 유효성 검사 규칙, 데이터 모델을 Blazor 프론트엔드와 ASP.NET Core 백엔드 사이에 모두 공유할 수 있습니다. 이미 C#에 있는 User 클래스를 TypeScript에서 중복 작성할 필요가 없습니다.

생태계 격차는 실재하지만 좁혀지고 있습니다. npm 생태계는 방대합니다. UI 컴포넌트를 위한 NuGet 생태계는 더 작지만 상당히 성장했습니다. 특정 차트 라이브러리나 드래그 앤 드롭 위젯이 필요하다면 JavaScript에 더 많은 옵션이 있습니다. 하지만 대부분의 비즈니스 애플리케이션의 경우 .NET 세계에서 사용 가능한 것이 충분합니다.

JavaScript 상호 운용성은 필요할 때 존재합니다. Blazor는 C#에서 JavaScript를 호출하고 JavaScript에서 C#을 호출할 수 있게 합니다. .NET 래퍼가 없는 브라우저 API나 기존 JS 라이브러리를 사용하고 싶을 때 상호 운용이 가능합니다. 레이어를 추가하지만 고통스럽지는 않습니다.

솔직한 답변: 팀 전체가 JavaScript 개발자이고 SEO, 성능, npm 생태계가 중요한 공개 제품을 만들고 있다면 JavaScript를 고수하세요. 팀이 .NET 개발자이고, 내부 또는 비즈니스 애플리케이션을 만들거나, 프론트엔드와 백엔드 사이의 코드 공유가 중요하다면 Blazor는 설득력 있는 선택입니다.

따라하기 위해 필요한 것

이 시리즈의 나머지 부분을 위해 필요한 것:

  • .NET 9 SDK — dot.net에서 다운로드
  • IDE — Visual Studio 2022(Community 에디션 무료), C# Dev Kit 확장이 있는 VS Code, 또는 JetBrains Rider
  • C# 기초 지식 — 클래스, 속성, 인터페이스, async/await

그것뿐입니다. Node, npm, webpack 없음.

다음 편

2장에서는 첫 번째 Blazor 앱을 스캐폴딩하고, 프로젝트 구조를 살펴보며, 로컬에서 실행할 수 있는지 확인할 것입니다. 끝에는 작동하는 앱과 각 파일이 무엇을 하는지에 대한 명확한 그림을 갖게 될 것입니다.

거기서 뵙겠습니다.