- Razor Pages는 ASP.NET Core 기반의 페이지 중심 모델을 제공하며, MVC와 동일한 강력한 라우팅, 미들웨어 및 Razor 뷰 엔진을 공유합니다.
- 실제 프로젝트는 Pages 폴더, wwwroot, appsettings.json 및 Program.cs를 중심으로 구성되며, 이러한 파일에는 서비스, 미들웨어 및 오류 처리가 설정됩니다.
- Visual Studio, Rider, VS Code와 같은 도구는 모델, 뷰 및 Razor 구문의 개발, 디버깅, 탐색 및 리팩토링을 간소화합니다.
- ASP.NET Core는 Razor 앱을 IIS, Azure, 사용자 지정 서버 또는 Docker에 게시하는 과정을 간소화하여 확장 가능하고 반복 가능한 배포를 가능하게 합니다.
Angular와 ASP.NET Web API를 사용해 왔고 백엔드에서 C#의 매력을 느끼기 시작했다면, Razor Pages는 기존 JavaScript 지식을 버리지 않고도 프런트엔드에서 C#의 즐거움을 누릴 수 있는 매우 자연스러운 방법입니다. 완전히 다른 UI 스택으로 뛰어드는 대신, 익숙한 ASP.NET Core 환경을 유지하고, 서버 측 렌더링에 Razor 구문을 사용하며, 필요에 따라 JavaScript를 적절히 활용할 수 있습니다.
ASP.NET Core Razor Pages는 Microsoft에서 권장하는 .NET 기반 최신 웹 앱 구축 방식으로, 강력한 ASP.NET Core 파이프라인 위에 구축된 깔끔한 페이지 기반 모델을 제공합니다. Razor Pages는 크로스 플랫폼을 지원하며 Visual Studio, Visual Studio Code, JetBrains Rider와 같은 도구와 원활하게 연동되고, 소규모 프로토타입부터 프로덕션 수준의 데이터베이스 기반 애플리케이션까지 확장 가능합니다. 이 가이드에서는 실제 Razor Pages 앱의 구조, Program.cs 파일에서 모든 요소를 연결하는 방법, 정적 파일과 구성 설정, 그리고 도구 사용, 디버깅 및 배포 방법에 대해 자세히 살펴보겠습니다.
ASP.NET Core Razor Pages는 실제로 무엇이며 MVC와 어떻게 다른가?
Razor Pages는 ASP.NET Core의 기능으로, 컨트롤러 대신 페이지를 중심으로 웹 애플리케이션을 구축할 수 있게 해줍니다. 이를 통해 MVC와 동일한 기본 프레임워크를 사용하면서도 더 간단한 개념 모델을 제공합니다. 내부적으로는 컨트롤러 및 뷰와 동일한 라우팅, 미들웨어 및 호스팅 스택에서 실행되지만, 모든 것을 컨트롤러 클래스에 중앙 집중화하는 대신 각 페이지가 자체적인 동작을 처리합니다.
일반적으로 각 Razor 페이지는 마크업용 .cshtml 파일과 페이지의 C# 로직용 .cshtml.cs 파일, 이렇게 두 개의 파일로 구성됩니다. .cshtml 파일에는 Razor 구문(예: 반복문, 조건문, HTML 헬퍼)이 혼합된 HTML 코드가 포함되어 있으며, 코드 비하인드 .cshtml.cs 파일에는 OnGet, OnPost와 같은 핸들러 메서드, 모델 속성 및 페이지를 렌더링하거나 처리하는 데 필요한 모든 로직이 포함되어 있습니다.
Razor Pages 이전에는 ASP.NET에서 MVC 패턴이 주를 이루었는데, 이 패턴에서는 컨트롤러가 뷰를 반환하고 모든 요청을 액션 메서드를 통해 처리했습니다. MVC는 여전히 완벽하게 지원되며 강력한 규칙을 가진 검증된 패턴이지만, 많은 시나리오에서 Razor Pages가 더 빠르게 이해할 수 있습니다. 페이지를 로드하고 처리하는 코드가 별도의 컨트롤러에 숨겨져 있는 대신 마크업 바로 옆에 있기 때문입니다.
Razor Pages는 컨트롤러에서 벗어나 다른 방식으로 초점을 맞추지만, 여전히 동일한 Razor 뷰 엔진을 사용하며 동적 HTML 생성을 위해 HtmlHelper와 TagHelper를 모두 지원합니다. TagHelpers는 특히 유용합니다. 일반 HTML 태그에 다음과 같은 속성을 추가할 수 있기 때문입니다. asp-action, asp-controller or asp-route 따라서 수많은 URL을 수동으로 작성하거나 인라인 JavaScript를 입력하지 않고도 링크와 양식을 백엔드 엔드포인트에 연결할 수 있습니다.
이미 JavaScript를 알고 SPA 프레임워크를 사용해 본 경험이 있는 개발자에게 Razor Pages는 서버에서 렌더링되는 HTML을 사용하여 빠른 초기 로딩과 SEO를 구현하고, 필요에 따라 JavaScript 및 프런트엔드 라이브러리를 그 위에 추가하는 하이브리드 방식을 제공합니다. 특정 자바스크립트 프레임워크에 얽매이거나 반대할 필요가 없으며, 백엔드와 프런트엔드를 동일한 솔루션에 유지할 수 있어 배포 및 유지 관리가 간소화됩니다.
Razor Pages 웹 앱 생성 및 실행
Visual Studio, Visual Studio Code 또는 Rider를 사용하여 새 ASP.NET Core Razor Pages 프로젝트를 만들면 템플릿이 Program.cs, Pages 폴더, 구성 파일 및 정적 웹 루트를 포함하여 최소한의 완전한 애플리케이션을 구성합니다. 별도의 설정 없이 바로 사용할 수 있는 웹사이트가 제공되며, 이후 영화 카탈로그나 기타 데이터 기반 앱처럼 더욱 정교한 형태로 발전시킬 수 있습니다.
ASP.NET Core에서 HTTPS를 통해 앱을 실행하기 전에 운영 체제에서 신뢰하는 개발 인증서가 필요하며, 프로젝트를 처음 실행할 때 인증서를 신뢰할지 묻는 대화 상자가 나타날 수 있습니다. 해당 대화 상자가 나타나면 선택하세요. 가능 이는 사용자의 컴퓨터에서 HTTPS 트래픽에 로컬 개발 인증서를 사용하는 것에 동의한다는 것을 나타냅니다. 이는 브라우저 경고 없이 보안 엔드포인트를 제대로 테스트하는 데 필요합니다.
Windows, macOS 또는 Linux에서 Visual Studio Code를 사용하면 키를 눌러 앱을 실행할 수 있습니다. Ctrl 키+F5 디버깅 없이 실행하거나, 디버거를 연결하려면 실행 및 디버그 패널을 사용하십시오. VS Code를 처음 실행할 때 디버거 유형을 선택하라는 메시지가 나타날 수 있습니다. C#, .NET 5 이상 및 .NET Core 또는 다음과 같은 특정 발사 구성 C#: RazorPagesMovie [https] RazorPagesMovie .NET 버전 및 작업 영역 구성에 따라 다릅니다.
실행 후 기본 브라우저가 다음과 유사한 URL로 열립니다. https://localhost:<port>여기서 포트는 임의로 할당되거나 launchSettings.json에 지정되며, 현재 보고 있는 페이지는 Razor Pages 앱에서 제공하는 홈페이지입니다. 일부 템플릿에서는 대신 다음과 같은 내용이 표시됩니다. http://localhost:5001 또는 다른 항구; 핵심은 바로 이것입니다. localhost 이는 해당 컴퓨터가 외부 호스트가 아닌 사용자 자신의 컴퓨터임을 나타냅니다.
테스트가 완료되면 IDE에서 실행 중인 앱을 중지할 수 있습니다. Visual Studio Code에서는 실행 메뉴에서 디버깅 중지를 선택하거나, Ctrl+C를 누르세요. 변화+F5반면 Visual Studio for Mac에서는 디버그 > 디버깅 중지를 사용합니다. 이렇게 하면 해당 세션을 위해 시작된 Kestrel 웹 서버 인스턴스가 종료되고 다른 실행을 위해 포트가 해제됩니다.
프로젝트 구조 이해하기: 폴더 및 주요 파일
실제 Razor Pages 애플리케이션은 Pages, wwwroot, appsettings.json 및 Program.cs(이전 버전에서는 Startup.cs)와 같이 지속적으로 사용하게 될 몇 가지 중요한 폴더와 구성 파일을 중심으로 구성됩니다. 이러한 요소들을 편안하게 다룰 수 있게 되는 것은 매우 중요합니다. 왜냐하면 거의 모든 튜토리얼, 샘플 또는 제작 프로젝트에서 동일한 규칙을 사용하기 때문입니다.
Pages 폴더는 Razor Pages 프로젝트의 핵심으로, 모든 .cshtml 페이지와 해당 페이지의 .cshtml.cs 코드 비하인드 파일, 그리고 공유 레이아웃 및 부분 뷰를 포함합니다. 각 페이지 쌍(예: Index.cshtml 및 Index.cshtml.cs)은 앱에서 호출 가능한 엔드포인트를 나타내며, 밑줄로 시작하는 특수 파일(예: Index.cshtml.cs)도 있습니다. _Layout.cshtml여러 페이지에서 재사용되는 콘텐츠를 정의합니다.
레이아웃 파일은 일반적으로 다음과 같은 이름으로 불립니다. _Layout.cshtml`<script>` 태그는 상단 탐색 모음, 바닥글 및 저작권 표시와 같은 사이트의 테두리를 정의하고 각 페이지의 본문을 렌더링할 공간을 제공합니다. 레이아웃을 변경하면 해당 레이아웃을 사용하는 모든 Razor 페이지의 모양과 느낌에 즉시 영향을 미치므로 메뉴, 브랜딩 및 공유 스크립트 또는 스타일을 편집할 때 가장 먼저 찾는 곳입니다.
wwwroot 폴더는 CSS, JavaScript, 이미지 및 웹 서버에서 직접 제공할 수 있는 일반 HTML 파일을 포함한 정적 자산이 저장되는 지정된 웹 루트입니다. wwwroot 아래에 있는 모든 파일은 (정적 파일 구성에 따라) 브라우저에서 접근할 수 있으므로, 사이트 스타일시트, 클라이언트 측 라이브러리 및 마크업에서 참조되는 이미지를 저장하기에 적합한 위치입니다.
앱 설정은 일반적으로 다음 위치에 저장됩니다. appsettings.json (그리고 appsettings.Development.json과 같은 환경별 변형 파일도 포함되며, 이러한 파일에는 연결 문자열 및 기능 플래그와 같은 설정이 들어 있습니다.) ASP.NET Core의 구성 시스템은 이러한 파일을 로드하고 환경 변수 및 기타 공급자와 병합하여 코드에서 섹션을 강력한 형식의 옵션 클래스에 쉽게 바인딩할 수 있도록 합니다.
Program.cs와 ASP.NET Core 파이프라인
Program.cs 파일은 Razor Pages 앱의 진입점을 포함하고 있으며, 첫 번째 요청이 사이트에 도달하기 전에 웹 호스트, 서비스 및 미들웨어 파이프라인이 어떻게 구성되는지 정의합니다. 최신 ASP.NET Core 버전에서 Program.cs는 최상위 명령문을 사용하여 간소화된 "최소 호스팅" 모델을 사용합니다. WebApplicationBuilder 그런 다음 빌드 및 구성을 수행합니다. WebApplication 예.
Program.cs의 일반적인 패턴은 다음과 같이 시작합니다. var builder = WebApplication.CreateBuilder(args); 이는 일반적인 기본값으로 호스트를 설정한 다음 호출합니다. builder.Services.AddRazorPages(); Razor Pages를 의존성 주입 컨테이너에 등록합니다. 서비스 설정을 완료한 후, var app = builder.Build(); 이 과정을 통해 애플리케이션 객체가 생성되며, 생성된 객체에 미들웨어와 엔드포인트를 연결합니다.
오류 처리 및 보안 동작은 환경에 따라 크게 달라지므로 일반적으로 다음과 같은 환경 검사를 볼 수 있습니다. if (!app.Environment.IsDevelopment()) 실제 생산 환경에서 사용 가능한 기능을 구현하기 위해서입니다. 그러한 조건 안에서는 일반적으로 다음과 같은 것을 발견할 수 있습니다. app.UseExceptionHandler("/Error"); 처리되지 않은 오류를 전용 오류 페이지로 보내는 기능도 있습니다. app.UseHsts(); 이는 HTTP Strict Transport Security(HSTS)를 활성화하여 브라우저가 해당 도메인에 대해 항상 HTTPS를 사용하도록 지시합니다.
그런 다음 미들웨어 파이프라인은 다음과 같은 호출을 통해 구성됩니다. app.UseHttpsRedirection();, app.UseStaticFiles(); or app.MapStaticAssets();, app.UseRouting(); 및 선택적으로 app.UseAuthorization(); 이어서 엔드포인트 매핑이 나옵니다. HTTPS 리디렉션은 안전하지 않은 HTTP 요청을 HTTPS로 업그레이드하도록 강제하고, 정적 파일 미들웨어(또는 .NET 9의 최신 정적 자산 매핑)는 wwwroot에서 리소스를 직접 제공할 수 있도록 하며, 라우팅은 들어오는 각 URL을 처리할 엔드포인트를 결정합니다.
마지막으로, Razor Pages는 라우팅에 연결됩니다. app.MapRazorPages(); 선택적으로 연결됨 .WithStaticAssets(); 최신 템플릿에서는 정적 자산 최적화를 통합하고, 애플리케이션은 이를 사용하여 시작됩니다. app.Run();. 이 시점에서 앱은 구성된 포트에서 수신 대기하고 Kestrel 서버는 로컬 개발 환경이든 IIS, Azure App Service 또는 Docker와 같은 프로덕션 호스트이든 관계없이 실제 요청을 처리할 준비가 됩니다.
Razor Pages, 모델 및 뷰 모델을 실제 애플리케이션에서 활용하는 방법
모든 복잡한 Razor Pages 앱 뒤에는 데이터와 데이터 표시 방식을 나타내는 도메인 모델 및 뷰 모델 세트가 있습니다. 영화 카탈로그를 관리하든, 블로그를 운영하든, 비즈니스 대시보드를 운영하든 마찬가지입니다. 모델은 일반적으로 데이터베이스 엔티티와 밀접하게 매핑되는 반면, 뷰 모델은 특정 화면이나 사용자 흐름에 맞게 조정될 수 있으며, 여러 모델이나 미리 형식화된 값을 결합하여 더 쉽게 렌더링할 수 있습니다.
일반적인 개발 워크플로는 필드와 메서드 시그니처를 스텁으로 사용하는 간단한 C# 클래스로 시작하여, 캡슐화된 속성, 유효성 검사 특성 및 로직을 갖춘 적절한 모델로 점진적으로 발전시키는 것입니다. JetBrains Rider와 같은 도구는 의도된 작업을 통해 필드를 속성으로 자동 변환하고, 상속 계층 구조를 위한 파생 유형을 생성하며, 객체 모델을 개선함에 따라 다른 리팩토링을 적용하는 등 진화를 더욱 원활하게 만들어 줍니다.
상속과 인터페이스는 모델의 구조를 일관성 있게 유지하고 실제 비즈니스 규칙에 맞추는 데 도움이 되며, 특정 동작은 공유되지만 구현 방식이 다른 다형성을 가능하게 합니다. 예를 들어 기지가 있을 수 있습니다. ContentItem 파생된 유형 Movie, Series Documentary 클래스들은 각각 미묘한 차이가 있지만 앱 전체에서 사용되는 공통된 계약을 가지고 있습니다.
모델이 준비되면 Razor Pages 또는 MVC 뷰를 수동으로 만들거나 엔티티 목록 표시, 생성, 편집 및 삭제를 위한 페이지를 생성하는 스캐폴딩 도구를 사용하여 만들 수 있습니다. 스캐폴딩은 초기 개발 속도를 획기적으로 높여주고 라우팅, 모델 바인딩 및 유효성 검사가 올바르게 연결되도록 보장하며, 이후에는 사용자가 직접 마크업과 스타일을 적용하여 맞춤 설정할 수 있습니다.
.cshtml 파일에서 사용되는 Razor 구문은 강력한 형식의 모델 및 뷰 모델과 원활하게 결합되어 컴파일 시간 안전성을 유지하면서 HtmlHelpers 또는 TagHelpers를 사용하여 데이터를 표시하고, 루프 및 조건문을 실행하고, 링크 및 양식을 생성할 수 있습니다. C#과 마크업을 혼합하여 사용하는 이 방식은 많은 로직을 서버 측에서 처리하면서도 브라우저에서 깔끔한 HTML을 생성하여 CSS 및 JavaScript와 원활하게 연동되도록 합니다.
Rider에서 Razor 구문, TagHelper 및 탐색 기능을 사용하는 방법
Razor 구문은 HTML 위에 덧씌워진 가벼운 레이어로, 특정 시점에 실행됩니다. @ 이 기호가 나타나면 C# 표현식, 문장 또는 헬퍼 호출을 마크업에 직접 쉽게 삽입할 수 있습니다. 별도의 템플릿 언어를 작성하거나 자바스크립트를 곳곳에 삽입하지 않고도 항목 목록을 순회하고, 조건에 따라 요소를 표시하거나 숨기고, 값과 형식화된 날짜를 표시할 수 있습니다.
TagHelpers는 HTML의 자연스러운 확장처럼 느껴지며, 로 시작하는 특수 속성을 제공합니다. asp- 요소의 동작이나 출력을 수정하며, 종종 기존의 HtmlHelper 메서드를 대체하고 인라인 스크립트 연결의 필요성을 제거합니다. 예로 asp-action asp-controller 앵커 태그와 폼을 특정 액션으로 연결하거나 속성을 연결하려면 다음과 같은 작업을 수행합니다. asp-route-id URL에서 매개변수를 깔끔하게 전달하기 위해.
HTML 작업을 할 때는 IDE 지원이 매우 중요한데, Rider는 편집기 하단에 문서 구조 내 현재 위치를 보여주는 브레드크럼과 같은 유용한 기능을 제공합니다. 브레드크럼은 편집기 섹션의 환경 설정 또는 옵션에서 사용자 지정할 수 있으며, 중첩된 태그가 있는 긴 Razor 파일을 탐색하는 데 훨씬 수월하게 해줍니다.
MVC 프로젝트에서 Rider는 컨트롤러, 액션 및 뷰를 연결하는 규칙을 이해하므로 액션 결과에 마우스를 올리면 가능한 뷰 경로를 확인할 수 있습니다. Ctrl + 클릭 (또는 Cmd-클릭 macOS에서는 해당 .cshtml 파일로 바로 이동합니다. 단축키는 다음과 같습니다. Ctrl + B or 커맨드-B 솔루션 탐색기를 뒤지지 않고 코드베이스를 빠르게 탐색할 수 있는 방법을 제공합니다.
Rider는 Razor 전용 도구 외에도 HTML, CSS 및 JavaScript에 대한 다양한 의도 및 빠른 수정 기능을 제공하여 C# 백엔드와 동일한 IDE 내에서 깔끔하고 구조화된 클라이언트 측 코드를 작성할 수 있도록 지원합니다. 이러한 긴밀한 통합은 서버에서 렌더링되는 Razor 뷰 또는 페이지에 의존하는 복잡하고 상호작용적인 UI를 구축할 때 컨텍스트 전환을 크게 줄여줄 수 있습니다.
Razor Pages 및 ASP.NET Core 앱 디버깅
디버깅은 웹 개발에서 매일같이 이루어지는 작업이며, Razor Pages를 실행하는 ASP.NET Core 앱도 예외는 아닙니다. 따라서 IDE에서 강력한 디버깅 기능을 지원하는 것이 필수적입니다. Visual Studio와 Rider는 모두 Kestrel 프로세스에 연결하여 C# 코드를 단계별로 실행하고, 변수를 검사하고, 앱이 실행되는 동안 표현식을 평가할 수 있는 대화형 디버거를 제공합니다.
Windows용 Rider 디버거는 편집 및 계속 기능을 지원합니다. 이 기능을 사용하면 앱이 중단점에서 일시 중지된 상태에서 코드를 수정하고 전체 디버깅 세션을 다시 시작하지 않고도 변경 사항을 적용할 수 있습니다. 디버깅 실행 중에 작은 오류를 수정하거나 실험할 수 있는 기능은 특히 시작 시간이 상당한 대규모 프로젝트에서 문제 해결 속도를 크게 향상시킵니다.
ASP.NET Core에서 개발 환경으로 설정하면 기본적으로 개발자 예외 페이지가 자동으로 활성화되어 처리되지 않은 예외가 발생할 때마다 자세한 스택 추적, 요청 정보 및 진단 정보를 제공합니다. 이 보기 방식은 로컬 디버깅 시에는 매우 유용하지만, 앱과 환경에 대한 내부 정보를 유출할 수 있으므로 프로덕션 환경에서는 위험합니다.
민감한 정보를 보호하기 위해 프로덕션 및 테스트 환경에서는 일반적으로 개발자 예외 페이지를 비활성화하고 대신 구성된 예외 처리기 경로를 사용합니다. /Error서버 측에 실제 세부 정보를 기록하는 동안 사용자 친화적인 오류 화면을 표시합니다. 이 동작은 Program.cs 파일에서 환경 검사 및 호출을 통해 제어됩니다. UseExceptionHandler UseHsts.
상황이 정말로 엉망이 되고 튜토리얼과 실제 동작이 일치하지 않을 때는 Microsoft 또는 기타 공신력 있는 소스에서 제공하는 정상 작동 샘플과 프로젝트를 비교해 보는 것이 유용할 수 있습니다. 많은 공식 Razor Pages 튜토리얼에서는 완성된 샘플 프로젝트를 제공하여 사용자가 자신의 코드와 비교하고 누락된 구성, 오타 또는 잘못된 파일 위치를 찾아낼 수 있도록 합니다.
실제 ASP.NET Core Razor 앱 게시 및 배포
Razor Pages 앱을 배포할 때 비로소 이전에 구축하고 구성해 둔 모든 노력이 결실을 맺습니다. ASP.NET Core는 다양한 호스팅 환경과 워크플로에 맞는 여러 배포 옵션을 지원하기 때문입니다. Windows의 IIS, Docker의 Linux 컨테이너 또는 Azure App Service와 같은 관리형 플랫폼 중 어떤 것을 선호하든, 게시 프로세스는 MSBuild를 통해 구동하고 CI/CD 파이프라인에 통합할 수 있습니다.
Visual Studio와 Rider는 모두 애플리케이션을 패키징하고 Web Deploy(MSDeploy)를 사용하여 IIS에 배포하거나, 로컬 또는 네트워크 폴더에 복사하거나, FTP, FTPS 또는 SFTP를 통해 원격 서버로 직접 푸시할 수 있는 게시 프로필을 제공합니다. 게시 프로필을 생성하면 배포 설정이 인코딩되어 향후 게시 작업이 프로필을 선택하고 버튼을 클릭하거나 명령을 실행하는 것만큼 간단해집니다.
클라우드 시나리오의 경우 Azure App Service가 인기 있는 대상이며, IDE는 Azure 도구를 통합하여 프로젝트에서 바로 웹 앱을 생성하고 게시할 수 있도록 지원합니다. 이 과정에서도 내부적으로 MSBuild 및 MSDeploy를 활용합니다. 이 접근 방식은 로컬 환경과 클라우드 환경 간의 빌드 및 배포 일관성을 유지하며 Azure DevOps, GitHub Actions 또는 기타 CI 시스템에서 자동화할 수 있습니다.
Docker는 ASP.NET Core를 위한 또 다른 훌륭한 옵션으로, Razor Pages 앱을 컨테이너화하여 컨테이너를 지원하는 모든 환경에서 안정적으로 실행할 수 있도록 해줍니다. Rider와 Visual Studio를 사용하면 Dockerfile과 docker-compose 구성을 생성할 수 있으므로 로컬 환경이든 Kubernetes와 같은 오케스트레이터 환경이든 관계없이 컨테이너 내부에서 앱을 개발, 디버깅 및 배포하는 워크플로를 구현할 수 있습니다.
대상 플랫폼과 관계없이 게시 단계에서는 C# 코드를 컴파일하고, Razor 뷰를 번들링하고, 정적 자산을 복사하며, 설정에 따라 호스트 시스템에 공유 .NET 설치가 필요하지 않도록 자체 포함 런타임을 생성할 수도 있습니다. 이러한 번들링 과정을 통해 개발 프로젝트가 실제 사용자가 사용할 수 있는 배포 가능한 결과물로 변환됩니다.
개발 인증서와 Program.cs부터 Pages와 wwwroot, 디버깅 및 게시까지 이 모든 요소를 종합해 보면, Razor Pages는 C# 개발에 익숙하고 모든 상황에 단일 페이지 프레임워크를 전적으로 의존하기에는 아직 부담스러운 개발자에게 유지 관리가 쉽고 성능이 뛰어나며 사용하기 편한 실용적인 ASP.NET Core 웹 애플리케이션을 구축할 수 있는 방법을 제공합니다.