[C# 14 / .NET 10] 2025년 11월 C# 14 탄생

2025년 11월 기다리던 C#의 14번째 version과 .NET 10이 출시되었습니다. 새로움은 늘 기대로 가득한 채 변화를 맞이하게 하지만 그만큼 새롭게 알아야 할 것들이 생겨나게 마련이고 그런 이유로 새로운 것을 찾아보기 위한 여정을 지금부터 시작하고자 합니다.

 

다른 언어도 모두 마찬가지 겠지만 Software개발을 위해서는 그 맞는 개발환경을 갖추어야 할 것입니다. C# 역시 이 과정이 필요하므로 우선 Visual Studo 2026과 Visual Studio Code를 사용해 개발환경을 만들어볼 것입니다.

향후 개발 도구의 명칭은 Visual Studio 2026를 VS2026으로 Visual Studio Code를 VSCode로 지칭하고자 합니다.

 

하지만 개발환경을 갖춘다고 아무것도 모른채로 바로 시작할 수 있는 것은 아니니 .NET에 대한 기본적인 개념을 잡고 가야 할 것입니다. 사실 .NET이란걸 단편적으로는 설명할 수 없고 대신 여러 가지 얘기가 나와야 하는데, 그렇다고 해서 복잡한 얘기를 할 필요는 전혀 없습니다. 단순히 기본적인 개념을 잡는 것으로 시작해 VS2026과 VSCode를 사용하여 C# 14와 .NET 10을 대상으로 한 예제를 만들어 봄으로서 한 걸음씩 나아갈 것입니다.

1. 개발환경 설정

 

Programming을 하려면 당연히 그에 맞는 개발도구를 갖추고 있어야 합니다. 물론 notepad와 같은것만으로도 불가능한 것은 아니지만 작업의 효율성은 극히 떨어질 것입니다.

 

C#을 위해 사용할 수 있는 대표적인 개발도구로는 당연 VS2026이나 VSCode를 그 예로 들 수 있습니다. 물론 이외에도 jetBrains사의 Rider등을 사용할 수 있지만 VS2026와 VSCode 외에 다른 개발도구에 관해서는 따로 언급하지 않을 것입니다.

 

VS2026은 이것 하나만으로 정말 많은 작업을 수행할 수 있으며 대부분의 .NET개발자가 사용하는 개발도구이기도 합니다. 하지만 많은 것을 수행할 수 있는 만큼 VSCode에 비해 크고 복잡한 구조를 가진다는 단점이 있습니다. 뿐만 아니라 대부분의 작업에서 자체적인 mechanism을 제공함으로써 뒷단에 발생하는 많은 동작을 감추고 있고, 그 결과로 드러나는 것만 개발자에게 보여주는 경향이 있습니다. 이러한 동작방식은 숙련된 개발자에게는 상당한 편리함을 제공해 주지만 학습을 시작하고자 하는 초보개발자에게는 오히려 세부적인 동작원리를 감추게 됨으로써 학습효과를 저해하는 결과를 가져다줄 수 있습니다.

 

극단적으로 설명하자면 사실 project의 설정이나 code file을 편집하기 위해서는 반드시 VS2026과 같은 개발도구가 필요한 것은 아닙니다. 이미 언급했듯 notepad만으로도 code를 작성할 수 있고 dotnet command-line 도구를 사용하여 해당 file을 compile하고 실행할 수 있습니다. 개발도구는 단지 이러한 과정에서 직접 처리해야만 하는 수많은 작업과정을 대신해 주는 도구의 역할만을 해줄 뿐입니다.

 

1) 학습을 위한 적절한 도구와 project type

 

Programming을 처음 시작하는 경우, 사용할 가장 좋은 개발도구는 code의 입력과 설정과정을 적절하게 도와주면서도 뒷편에서 발생하는 동작을 감추지 않는 것입니다. 개인적으로 현재 시점에서 이러한 조건에 가장 부합해 있는 개발도구가 바로 VSCode라고 판단됩니다. 아직 어떤 개발도구를 사용할지 결정하지 않았다면 VSCode를 강력히 권장합니다.

VSCode는 권장사항일뿐 이미 익숙하게 사용하고 있거나 소속되어 있는 Team에서 사용 중인 별도의 개발도구가 있는 경우 해당 도구를 계속할 수 있습니다. Programming에서 개발도구의 선택범위는 제한이 없으므로 특정 개발도구의 사용을 고집할 필요는 없습니다.

 

.NET에서 생성할 수 있는 Application유형은 Desktop수준부터 Web에 이르기까지 매우 다양합니다. 단순히 C# Programming을 경험하기 위한 것이라 해도 예제를 위한 Project를 특정 Application 유형으로 생성해야 하는데, 이를 위해 특별한 경우가 아니면 모두 Console Application Project Teamplate을 사용할 것입니다. Console Application은 학습에 불필요한 Code를 수반하지 않으면서 학습에만 집중할 수 있게 하는 가장 좋은 Application유형이라 말할 수 있습니다.

 

(1) Visual Studio Code

 

VSCode는 Microsoft에서 개발된 가벼우면서도 훌륭한 성능을 제공하는 code editor이며 무엇보다 cross-platform에 해당하므로 Windows는 물론 macOS나 Ubuntu, Red Hat과 같은 Linux에서도 실행할 수 있습니다. 이렇게 다양한 platform을 지원하게 됨으로써 자연스럽게 cross-platform app을 개발하는 데 사용되고 있으며 Hardware 역시 기존 x86 processor뿐만 아나라 ARM까지도 지원함으로써 Apple Silicon 계열 및 Surface Laptop, 심지어 Raspberry Pi 등 ARM을 기반으로 한 다양한 장치에서도 실행하고 관련 App을 개발할 수 있습니다.

 

뿐만 아니라 .NET/C#차원을 넘어 다양한 언어와 개발보조를 위한 수많은 확장기능까지 원하는 대로 설치하여 활용할 수 있습니다. 이중에서 .NET/C#개발자에게 가장 중요한 C# Dev Kit이 존재하는데 이 확장도구는 일반적인 VSCode를 .NET/C#개발을 위한 최적의 도구로 전환시켜 줌으로써 VSCode를 훌륭한 .NET/C#개발을 위한 도구로서 활용할 수 있습니다.

C# Dev Kit에 관한 더 자세한 사항은 아래 link를 참고하시기 바랍니다.
https://devblogs.microsoft.com/visualstudio/announcing-csharp-dev-kit-for-visual-studio-code/

 

VSCode는 엄밀히 말해 범용으로 다양하게 활용될 수 있지만 현재 개발분야에서 가장 강력한 지원체계를 갖고 있는 분야가 바로 Web개발입니다. 아직까지는 web분야외에 mobile이나 desktop분야에서 해당 platform의 전용개발도구에 밀리는 경향이 있지만  그럼에도 불구하고 전 세계에서 가장 인기 있는 code editor로 자리 잡고 있습니다.

 

(2) GitHub Codespaces

 

GitHub Codespaces는 VSCode에 기반한 개발환경으로서 겉으로 보이에는 이 둘 사이에 거의 차이점이 없어 보일 수 있습니다. 그러나 Web상에서 구동된다는 근본적인 이점을 가지고 있으므로 web browser가 있고 internet에 접속할 수만 있다면 어디서든 접근가능한 Cloud개발을 경험해볼 수 있습니다. Git repository와 내장된 command-line interface 및 확장기능 역시 그대로 지원하므로 VSCode와 동일하게 code를 편집하고 실행할 수 있으며 다양한 device상에서 test 역시 가능합니다. 하지만 무료인 VSCode와는 달리 정말 쓸모 있는 code editor로서 유용하게 사용하려면 license비용을 지불해야 합니다.

GitHub Codespaces에 관한 더 자세한 사항은 아래 link를 참고하시기 바랍니다.
https://github.com/features/codespaces

 

(3) Visual Studio

 

Visual Studio는 desktop뿐만 아니라 Web분야까지 다양한 유형의 application을 개발할 수 있는 IDE라고 할 수 있습니다. 그러나 현재는 Windows운영체제에 한정되어 있으므로 macOS나 Linux상에서는 사용할 수 없다는 단점이 있습니다. 물론 VS2026을 사용해 cross-platform을 위한 Android와 iOS의 mobile app개발을 시작할 수 있지만 각각의 platform을 위한 compile을 위해서는 여전히 해당 platform상에서의 개발환경을 필요로 합니다.

 

본래 macOS에서 .NET을 위한 Visual Studio가 존재했었습니다. 하지만 .NET 8부터 더 이상 공식적으로 지웒하지 않게 되었으며 현재로서는 Visual Studio가 아닌 macOS용 VSCode를 사용하는 것이 대안으로 제시되고 있습니다. 또는 Paralles와 같은 가상화를 통해 Windows용 Visual Studio를 사용하는 방법도 있습니다. macOS용 Visual Studio의 지원종료에 관한 내용은 아래 link에서 확인할 수 있습니다.
https://devblogs.microsoft.com/visualstudio/visual-studio-for-mac-retirement-announcement/

 

2) Windows에서의 Linux Application개발

 

Windows에서 Linux를 대상으로한대상으로 한 Application개발에는 WSL를 빼놓을 수 없습니다. WSL(Windows Subsystem for Linux)은 개발자들이 cross-platform개발을 위해 사용할 수 있는 가장 강력한 도구라 할 수 있습니다. 가상화나 별도의 OS를 설치할 필요 없이 Windows안에서 일반적인 Linux환경을 직접 구동시킬 수 있는 것인데 이를 통해 VS2026과 같은 Windows작업환경을 벗어나지 않으면서 Linux를 대상으로한 .NET Application을 직접 test 하고 build 하고 debuging 할 수 있습니다. 즉, Windows상에서 filesystem이나 대소문자구분, 권한, 경로문자와 같은 Linux의 고유한 특징 및 기능 등을 사전에 검토하여 Linux호환 .NET Code를 작성하는 것이 가능한 것입니다.

 

WSL자체가 Linux kernel을 기반으로 하는 Linux를 구동시키는 것이기 때문에 .NET Application을 실제 Linux상에서 실행시키는 것이라 볼 수 있으며 이는 Linux를 대상으로 배포하고자 하거나 Linux Shell에서 Application의 동작을 직접 확인해 보고자 할 때 유용하게 사용할 수 있습니다. 실제 Linux와 동일한 환경이므로 curl, grep, awk, sed, bash과 같은 Linux개발도구를 직접 사용할 수 있고 심지어 다른 개발도구나 의존성을 설치하기 위한 apt 등의 package manager를 사용할 수도 있습니다.

Windows상에서 WSL을 설치하는 자세한 방법은 아래 link를 참고하시기 바랍니다.
https://learn.microsoft.com/en-us/windows/wsl/install

 

3) .NET 10의 지원 Platform

 

.NET 10은 아래 Platform을 지원하고 있으므로 해당 Platform을 대상으로 한 Application을 개발하고 배포할 수 있습니다.

OS	Version
Windows	Windows 10(1607 이후), Windows 11(22000 이후), Windows Server(2012R2 SP1 이후), Nano Server(2019 이후), Microsoft Surface Pro 11, Surface Laptop 7과 같은 Windows ARM기기 지원
Linux	Alpine Linux 3.22, Azure Linux 3.0, CentOS Stram 9/10, Debian 12/13, Fedora 42, openSUSE Leap 15.6, Redhat Linux 9/10, SUSE Enterprise Linux 15.6, Ubuntu 22.04/24.04/25.04
Android	최소 API 21 이상, Version 12, 12.1, 13, 14, 15
iOS	iOS 12.2
Mac	macOS 14/15

지원가능한 OS 및 Version에 관한 가장 최신의 정보는 아래 link를 참고해 주시기 바랍니다.
https://github.com/dotnet/core/blob/main/release-notes/10.0/supported-os.md

 

또한 .NET의 모든 version은 Windows의 자동 Update를 통해 최신상태를 유지할 수 있습니다.

 

4) VS2026 내려받고 설치하기

 

많은 .NET개발자들이 사용하는 가장 주된 개발도구라 함은 단연코 Visual Studio라고 할 수 있습니다. 같이 사용하게 될 VSCode는 범용이지만 Visual Studio는 오로지 .NET을 위한 전용의 개발도구라 할 수 있습니다. 향후 만들게 될 많은 예제는 VSCode만으로도 작성이 가능하겠지만 가능하다면 Visual Studio도 같이 사용해 볼 것을 권장합니다.

 

Visual Studio중에서 가장 최신의 version은 2025년 11월 출시한 Visual Studio 2026(이하 VS2026)이며 .NET10을 공식적으로 지원하는 유일한 개발도구이기도 합니다. Visual Studio는 Professional, Enterprise와 같이 여러 version이 존재하는데 2014년 10월부터 학생이나 open source 기여자, 개인에 한해 무료로 제공되고 있는 Community Edition도 존재합니다. Community는 Professional과 거의 비슷한 기능을 제공하면서도 무료로 배포되고 있으므로 학습을 위한 목적으로 가장 알맞은 Visual Studio version이라 할 수 있습니다. 향후 예제를 만드는 경우에도 Community Edition을 사용할 것이며 그중에서 가장 최신 version인 Visual Studio 2026를 사용할 것입니다.

 

VS2026은 아래 link를 통해 내려받을 수 있습니다.

https://visualstudio.microsoft.com/downloads/

 

내려받은 file을 실행하고 잠시 기다리면 다음과 같은 화면을 볼 수 있습니다.

 

위 화면의 Workloads에서 학습에 필요한 아래 항목을 선택합니다.

 

① ASP.NET and web development
② .NET disktop development

 

1번은 기본적인 web개발을 위한 것이며 2번은 console app을 포함한 일반적인 응용 program개발을 위한 것입니다.

 

위의 항목을 선택한 뒤 Install button을 click 하고 관련항목이 설치될 때까지 잠시 기다려 줍니다. 설치가 완료되고 처음 VS2026을 실행하면 다음과 같이 login화면이 나오게 되는데

 

만약 Microsoft계정이 있다면 해당 계정을 통해 login하면 되고 없다면 새로운 계정을 생성할 수 있습니다.(굳이 login을 하지 않더라도 하단의 'Skip and add accounts later.'를 선택하면 별도의 login 없이 VS2026을 사용할 수는 있으나 기능의 완전한 사용을 위해 login을 권장합니다.)

 

해당 과정을 넘기면 그 뒤로 기본적인 환경설정화면이 나오게 되는데 여기서는 Development Settings에 C#이나 General을 선택하고 Color theme부분에는 원하는 색상의 theme를 선택합니다. 모든 설정이 완료되고 나면 'Start Visual Studio'를 click 해 VS2026을 실행합니다.

 

5) VSCode 내려받고 설치하기

 

VSCode는 지난 몇년동안 가장 빠르게 발전한 code editor일 것입니다. 만약 자신의 Coding작업에 VS2026을 사용하기로 결정했다 하더라도 VSCode를 반드시 사용해 보길 권장합니다. 실제 어떤 걸 사용할지는 Visual Studio나 VSCode를 모두 사용해 본 다음에 결정해도 충분할 것입니다.

 

VSCode를 설치하고 사용하기 위해서는 몇가지 사전 절차가 필요한데 가장 중요한 VSCode부터 내려받고 설치하는 것으로 시작합니다.

 

VSCode는 아래 link에서 내려받을 수 있습니다.

https://code.visualstudio.com/

 

VSCode는 내려받고 설치가능한 version으로 안정화 version과 insider version을 제공하고 있는데 insider는 다음 version에 대한 미리 보기로 update주기가 잦으며 최신의 VSCode를 사용할 수 있지만 대신 안정성은 안정화 version에 비해 떨어질 것입니다. 특별한 경우가 아니라면 안정화 version을 내려받는 것이 좋습니다.

 

VSCode의 설치에 대한 자세한 guide는 아래 link에서 찾아 볼 수 있습니다.

 

https://code.visualstudio.com/docs/setup/setup-overview

 

VSCode와 함께 .NET SDK도 설치할 필요가 있습니다. 가장 최신 version은 .NET 10으로 만약 위에서 VS2026을 설치했다면 이미 .NET 10 SDK가 설치되어 있을 것이므로 이 과정은 넘어가도 좋습니다. 만약 그렇지 않다면 아래 link에서 .NET 10 SDK를 내려받아 설치합니다.

 

https://dotnet.microsoft.com/en-us/download

경우에 따라 .NET8, .NET9, .NET10등 다수의 .NET version이 설치되어 있을 수 있습니다. 이러한 경우는 아무런 문제가 되지 않으며 project를 build 할대 어떤 걸 사용할지 직접 정할 수 있습니다. 참고로 .NET8, .NET9, .NET10 version이 2025 이후로도 계속 지원되는 version에 해당합니다.

 

.NET SDK를 설치하고 나면 VSCode를 위해 'C# Dev Kit'확장기능을 설치합니다. 이를 위해 VSCode를 실행하고 Extensions를 선택하거나 View -> Extensions menu를 선택하고 'C#'을 입력하면 확장기능목록에 C# Dev Kit이 나오게 됨을 알 수 있습니다. 여기서 해당 항목을 선택해 확장기능을 설치합니다.

 

(1) 다른 확장기능 설치

 

VSCode에서 사용가능한 수많은 확장기능 중에는 'C# Dev Kit' 이외에 C#개발에 도움을 줄 수 있는 다른 확장기능이 존재합니다. 기본적으로 아래와 같은 확장기능을 추가로 설치하면 C#을 위한 VSCode로서 그 효율성을 향상할 수 있습니다.

C# Dev Kit (ms-dotnettools.csdevkit)	Microsoft의 공식 C#확장기능으로서 C#/.NET개발에서는 필수입니다. Solution Explorer를 통해 Code를 관리를 지원하며 통합된 단위 TEST 탐색 및 실행기능으로 Code를 test할 수도 있습니다. 이 밖에 C#개발에 필요한 다양한 기능을 지원하고 있으므로 C#개발경험을 향상시킬 수 있습니다.
C# (ms-dotnettools.csharp)	C#에 특화된 기능을 제공하기 위한 것으로 IntalliSense와 code탐색, debugging기능 지원등을 통해 더 빠르고 안정적인 C#개발경험을 제공합니다. 'C# Dev Kit'을 설치했다면 해당 확장기능은 따로 설치할 필요 없습니다.
IntelliCode for C# Dev Kit (ms-dotnettools.vscodeintellicode-csharp)	C#(TypeScript나 JavaScript등 기타 다른 언어 포함)언어를 위한 AI 지원 개발기능을 제공합니다.
ilspy-vscode (icsharpcode.ilspy-vscode)	MSIL로 구성된 assembly를 decompile하기 위한 것으로 가장 최신의 .NET뿐만 아니라 .NET Framework, ,NET Core, .NET Standard등에서도 사용할 수 있습니다.

 

또한 VS확장기능은 VSCode안에서 뿐만 아니라 Terminal에서도 아래 명령을 통해 설치할 수 있습니다.

명령	설명
code --list-extensions	설치된 확장기능 나열
code --install-extension </extension id>	지정한 id의 확장기능 설치 (ex : code --install-extension ms-dotnettools.csdevkit)
code --uninstall-extension	지정한 id의 확장기능 삭제

2. NET

 

.NET은 개발초기 단계에서부터 현재에 이르기까지 .NET Framework나 .NET Standard, .NET Core와 같은 platform의 등장을 통해 발전해 왔었음을 알 수 있습니다. .NET Framework시기부터 함께해 온 개발자라면 .NET의 역사에 익숙하겠지만 그렇지 않은 개발자도 있을 것입니다. 과거가 중요하지 않다는 말은 아니지만 굳이 여기서 .NET의 역사를 되짚어 볼 생각은 없습니다. 만약 이러한 것이 관심이 있다면 아래 Link를 통해 간략히 확인해 보실 수 있습니다.

 

[.NET/C#] - [C# 12와 .NET 8] 2. C#

 

1) .NET의 지원체계

 

.NET의 생명주기와 관련된 version은 크게 3가지로 나누어 볼 수 있습니다. 하나는 LTS(Long-Term Support)이고 다른 하나는 STS(Standard-Term Support)이며 나머지 하나는 Preview입니다. 그리고 이들 각각은 아래와 같은 지원가능한 주기를 갖고 있습니다.

Release	Support
LTS	GA(General Availability)이후 3년간 또는 다음 LTS가 발표된 이 후 1년중 더 긴쪽으로 지원되는 version입니다. 지원기간 동안 보안과 안정성에 관한 patch가 지속적으로 이루어집니다.
STS	GA이후 2년간 또는 다음 STS 나 LTS가 발표된 이 후 1년중 더 긴쪽으로 지원되는 version입니다. 지원기간 동안 보안과 안정성에 관한 patch가 지속적으로 이루어집니다.
Preview	공개 TEST용으로 사전에 신규기능이나 기술에 접근해 보고자 하는 개발자를 위한 version입니다. Preview자체가 실제 지원되는 version은 아니지만 어떤 Preview 또는 RC(Release Candidate)의 경우 Go Live로 결정되어 Microsoft에서 정식 제품으로 지원되는 경우도 있습니다. 그러나 만약 Preview를 통해 Application을 개발한 뒤에 바로 Go Live로 전환되었다 하더라도 가능한한 빠른 시간안에 migration을 진행해야 합니다.

STS는 경우에 따라 'Current'라고 표기되기도 합니다.

2025년 9월 Microsoft는 현재 STS의 지원기간이 18개월에서 24개월로 늘어날 수 있음을 공지한 바 있습니다. 관련된 내용은 아래 link를 참고하시기 바랍니다.
https://devblogs.microsoft.com/dotnet/dotnet-sts-releases-supported-for-24-months/

.NET STS releases supported for 24 months - .NET Blog

가능한한 주기적인 Patch를 통해 .NET의 최신상태를 유지하시기 바랍니다. 예를 들어 .NET Runtime 10.0.0 version이 설치되어 있고 이후 10.0.1 version이 release 되었다면 지속적인 지원을 받기 위해 10.0.1을 설치하는 것이 좋습니다. 이러한 update는 매달 둘째 주 화요일인 Patch Tuesday에 release 됩니다.

 

STS와 LTS 간 지원기간에 대한 구분을 좀 더 명확히 확인하기 위해 아래 표를 참고해 주시기 바랍니다. 표에서 붉은색은 3년 녹색은 2년간의 지원기간을 의미합니다.

 

.NET 10의 지원기간 동안 .NET 8과 .NET 9는 한동안 지원이 계속 이루어질 수 있습니다. 그리고 .NET 10의 지원기간안에 .NET 11이 release 될 수 있습니다. 특별한 경우가 아니면 상위 .NET version은 하위 .NET version에 대한 호환성을 갖고 있으므로 만약 .NET 8이나 .NET 9로 개발된 Application이 있다면 Microsoft로부터의 지속적인 지원을 받을 수 있게 이를 현재 가장 최신 version의 .NET으로 전환할 것을 권장합니다. 그리고 이러한 전환방식은 향후 .NET 11이나 .NET 12가 발표되는 경우도 마찬가지입니다.

 

2) .NET의 지원체계와 관련된 용어

 

.NET의 생명주기는 사용되는 용어를 통해 그 지원 수준을 파악할 수 있습니다.

Release	Description
Preview	Preview라는 말이 붙으면 공식적으로 지원되지 않는 version으로 이해해야 합니다. 따라서 실제 Product수준의 Application개발대신 TEST나 사전 검토용으로만 사용되어야 합니다.
Go Live	GA동안에만 지원되는 것으로 그 이후에는 미지원상태로 전환됩니다. 따라서 가능한한 최신의 version으로 update해야 합니다. 보통 Release Candidate가 GA에 해당합니다.
Active	현재 .NET 10이 2025년 11월에서 2028년 5월까지 Active상태에 해당합니다. 이 기간동안 매달 bug와 보안관련 수정을 포함한 release가 이루어지므로 그에 맞춰 update를 유지해야 합니다.
Maintenance	생명주기의 마지막 6개월동안의 기간을 말하는 것으로 이때는 오로지 보안관련 수정만 이루어집니다. 본래 .NET 10의 지원기간은 2028년 11월까지인데 이 중 마지막 6개월을 제외한 기간만 Active로 잡히는 이유입니다. 또한 .NET 8과 .NET 9역시 조만간 maintenance상태로 진입할 것이므로 관련 Application Project가 존재한다면 이 기간동안 최신의 .NET Version으로 전환해야 합니다.
EOL	End of life로 지원이 더이상 이루어지지 않는 시기입니다. .NET 10은 2028년 11월이 넘어가게 되면 EOL에 도달하게 됩니다.

 

(1) EOL

 

End of life 또는 End of support라고 하는 EOL은 bug나 보안 patch, 기술지원등이 Microsoft에서 더 이상 지원되지 않는 것을 말합니다. .NET 10이 2025년 11월에 발표되면서 .NET 8을 제외한 이하 모든 .NET은 EOL에 도달하게 됩니다.

.NET 8	2025년 11월 기준 Active 상태이며 2026년 5월 maintenance상태로, 2026년 11월에 EOL에 도달하게 됩니다.
.NET 9	2025년 11월 기준 Active 상태이며 2026년 5월 maintenance상태로, 2026년 11월에 EOL에 도달하게 됩니다.
.NET 10	2028년 5월까지 Active 상태가 되며 그 다음 2028년 11월 EOL까지 maintenance상태에 있게 됩니다.
.NET 11	2026년 2월부터 2026년 11월까지 preview 상태에 있다가 그 다음부터 Active상태로 전환됩니다. 그리고 2028년 11월 EOL에 도달합니다.

 

모든 .NET version의 현재 상태와 EOL도달시기는 아래 link를 통해 더 자세히 확인할 수 있습니다.
https://github.com/dotnet/core/blob/main/releases.md

.NET 8과 .NET 9의 경우에는 2026년 11월 EOL에 도달하게 되는데 해당 version을 사용하는 project자체는 계속 운영할 수 있지만 보안 update가 더 이상 제공되지 않고 기술지원도 불가능하므로 신속히 새로운 .NET version으로 전환해야 합니다.

 

3) .NET Runtime과 SDK

 

Application을 standalone으로 build 하지 않는 한 .NET Runtime은 .NET Application을 실행하기 위해 필수로 OS에 설치되어 있어야 하는 최소한의 요구사항에 해당합니다. 반면 .NET SDK는 .NET Runtime과 함께 .NET Application을 build하기 위해 필요한 compiler 및 기타 다른 도구를 포함하고 있는 것입니다.

 

.NET Rumtime의 versioning은 semantic versioning의 규칙을 따르고 있어서 어떠한 대규모 변화의 발생 시 주 version이 증가하며 새로운 기능 및 기타 bug 수정의 경우에는 하위 version이 증가하게 됩니다. 하지만 .NET SDK의 versioning은 semantic versioning의 규칙을 따르고 있지 않으며 주와 부 version은 항상 .NET Runtime과 동일하게 유지됩니다. 다만 그 하위에 존재하는 부수적인 version번호만 SDK의 patch에 따른 증가값을 표시하고 있는데, 해당 version번호는 초기에 100부터 시작해서 첫 번째 숫자는 새로운 기능에 대한 변화를, 나머지 2개의 숫자는 bug나 보안 patch와 같은 변화를 나타냅니다.

	.NET Runtime	.NET SDK
초기상태	10.0.0	10.0.100
SDK Bug 수정	10.0.0	10.0.101
Runtime Bug 수정	10.0.1	10.0.101
SDK 기눙 수정	10.0.1	10.0.200

 

4) .NET 설치 관리

 

.NET Runtime의 경우 주 version에 대해서는 하위 version과 무관하게 호환성을 유지합니다. 예를 들어 .NET 10.0.0을 대상으로 개발된 project라 하더라도 향후 10.0.1이나 10.0.2와 같은 version이 나오는 경우 별다른 문제없이 무난하게 version을 update할 수 있습니다. 물론 단순 version상의 문제뿐 아니라 지속적인 관리를 위해서라도 꾸준히 update를 유지해야 할 필요가 있습니다.

 

.NET SDK의 경우도 마찬가지인데 초기 이전 version의 .NET SDK로 build한 project라 하더라도 향후 bug수정된 version의 SDK를 사용해 이전 project를 여전히 build할 수 있으며 심지어 주 version이 update된 11.0.100과 같은 경우에도 대부분의 경우 무리없이 판올림을 진행하여 build를 수행할 수 있습니다.

 

이러한 하위 호환성유지는 새로운 version의 .NET SDK가 설치된 경우라면 이전 version의 .NET SDK는 안전하게 삭제할 수 있다는 의미가 됩니다. 새로운 .NET SDK를 통해서도 이전 version의 모든 project를 build 할 수 있기 때문입니다.

 

현재 설치된 .NET SDK와 runtime을 보려면 아래 명령을 사용합니다.

dotnet --info

 

만약 SDK만 확인하려면 아래 명령을 사용하고

dotnet --list-sdks

 

Runtime이라면 아래 명령을 사용합니다.

dotnet --list-runtimes

 

만약 특정 SDK를 삭제하려 한다면 Windows 제어판의 'Programs and Features'에서 삭제할 수 있습니다.

 

5) .NET과 C#

 

.NET은 개발 Platform이고 C#은 개발언어에 해당합니다. 또한 C#은 .NET을 위한, .NET만을 위한언어로서 .NET과 아주 밀접하게 연결되어 있다 말할 수 있습니다.

 

C#언어가 Application으로 실행되는 과정을 보면 우선 C# code를 C# Compiler가 CIL(Common Intermediate Language) 혹은 IL Code라고 하는 형태로 compile 합니다. 그 다음 .NET Runtime의 구성요소 중 하나인 CLR(Common Language Runtime)에서 해당 IL Code를 load 한 뒤 이를 다시 JIT(Just In Time) Compiler가 실제 동작중인 Machine의 OS와 CPU가 이해할 수 있는 기계어 code로 변환하여 code를 실행하게 됩니다.

 

.NET세계에서 많이 쓰이는 VB.NET이나 F#도 마찬가지로 각각의 언어에 맞는 compiler를 가지고 있고 이들도 compile 하게 되면 공통적으로 IL Code가 만들어지는데 그다음 실행까지의 과정은 어떤 언어든지 모두 동일한 순서와 방식으로 처리됩니다.

 

C#은 언어일 뿐이므로 실제 C#없는 .NET Project는 존재할 수 있지만 .NET아닌 C#은 존재할 수 없습니다. 이론적으로 현재 C#은 개방형 표준이기 때문에 누구나 다른 platform을 위한 C# Compiler를 만들 수 있지만 실제 그렇게 만들어진 사례는 아직 존재하지 않으며 사실 그렇게 해야 할 이유도 없습니다.

 

엄밀하 말하면 .NET세계에서 C#을 꼭 사용해야 하는 것은 아닙니다. 이미 언급했듯이 C#, F#, VB.NET은 Programming언어에 물과 하며 Microsoft 역시 이들 언어 모두를 지속적으로 지원하고 있습니다. 다만 C#은 이 중에서 가장 우세한 지원쳬계에 속해 있으며 관련 자료 역시 방대하게 존재하므로 오히려 다른 언어를 사용하는 것보다 C#이 훨씬 접근성이 높다고 말할 수 있습니다.

 

(1) IL

 

상술했듯 .NET은 2번의 compiler과정을 거치고 있습니다. 이 중 첫 번째가 Roslyn이라고 하는 C# compiler에서 C# Source code를 compile 하여 IL로 변환한 뒤 이를 EXE나 DLL의 Assembly형태로 저장하는 것입니다. IL code는 Assembly언어와 비슷한 구조를 가지지만 오로지 CoreCLR이라고 하는 .NET Virtual Machine상에서만 실행될 수 있습니다. 두 번째 Compile은 Runtime때 실행되는데, CoreCLR이 Assembly에서 IL Code를 load 하면 JIT Compiler가 이를 현재 Machine의 OS와 CPU가 해석할 수 있는 구조의 기계어로 compile 하게 됩니다. 그리고 이렇게 두 번의 Compile과정을 거치고 나면 비로소 Code를 실행하게 됩니다.

 

두번의 Compile과정(C# -> IL -> Machine Code)은 언뜻 생각해 보면 불합리해 보일 수 있지만 동일한 IL Code를 가지고 Windows는 물론 Linux나 macOS든 어떠한 OS platform상에서도 실행시킬 수 있다는 아주 큰 장점을 제공해 줄 수 있습니다. Microsoft는 그저 각 OS에 맞는 CoreCLR을 만들어두기만 하면 되고, 해당 OS의 CoreCLR에서 두 번째 Compile과정을 거쳐 실행가능한 기계어로 변환될 수 있습니다.

 

C#뿐만 아니라 기타 다른 어떠한 언어든지 관계없이 첫 단계의 Compile에서 IL Code를 생성하게 되는데 중간언어라는 특성상 해당 Code의 구조를 역해석하면 본래 언어로 만들어진 Source code로 되돌려 보는 것이 가능합니다. 실제 이것을 가능하게 만드는 여러 가지 tool도 존재하는데 JetBranins사의 DotPeek나 Microsoft사의 ILSpy 등이 있습니다.

 

두 번째 Compile은 Runtime때에 이루어지는데 이러한 방식은 OS 간 높은 실행률을 보장할 수 있지만 단점은 역시 성능입니다. 한 번의 Compile로 곧장 실행가능한 형태의 file을 만들어내는 다른 언어의 Application과는 아무래도 비교될 수밖에 없습니다. Microsoft도 이러한 문제를 인식하고 있고 따라서 이에 대한 대안으로 AOT(Ahead of time) Compile을 제시하고 있습니다. AOT에 관해서는 추후에 다시 언급하도록 하겠습니다.

CoreCLR의 원래 이름은 CLR이지만 이는 .NET Framework때 Windows전용으로 사용되는 것으로 .NET이 Cross-platform인 Core시대로 접어들면서 CoreCLR로 명칭이 변경되었습니다. 전체 모든 CLR을 지칭하는 경우는 CLRs이라고 표현하기도 합니다.

.NET Core는 Cross-platform으로 처음 등장한때에 사용되던 용어로 현재는 .NET만 공식적인 명칭으로 사용되고 있습니다.

Runtime은 Application실행되는 시점을 의미합니다.

 

6) .NET과 .NET Framework

 

.NET Framework는 2002년부터 시작한 .NET Platform의 공식명칭이었으며 그 밖에 다른 관련 Platform이 등장하였지만 현재는 이 명칭이 .NET 이라는 것으로 통일되었습니다.

 

.NET Framework와 .NET은 명칭이 비슷하다 보니 이를 혼재해 사용하는 경우도 있는데 이 둘은 엄밀히 다르며 다음과 같은 특징으로 나누어 볼 수 있습니다.

.NET Framework	.NET Framework 4.8 / C# 8.0까지만 지원되는 것으로 향후 그 어떠한 지원계획도 존재하지 않습니다. 사실상 Windows전용의 Platform이며 오로지 기존 .NET Framework를 대상으로 한 Application을 유지관리하기 위한 목적으로만 사용해합니다. 따라서 신규 Project에 적용해서는 안됩니다.
.NET	C# 8.0부터 현재의 C# 14까지 지원하는 것으로 향후 유지관리동안에 신규 Project에 사용할 수 있는 Platform입니다. Windows뿐만 아니라 Linux, macOS, Android등 다양한 OS를 지원하며 기존의 .NET Framework Application을 최신 version인 .NET으로 전환하고자 하는 경우에도 사용할 수 있습니다.

 

지금까지 C#과 .NET에 대한 간단한 개념들을 살펴봤습니다. 이론적인 부분은 여기까지 하기로 하고 이제 예제를 통해 실제 Application을 만들기 위한 과정을 하나씩 짚어가도록 하겠습니다.

3. 예제 따라 하기

 

우선 VS2026을 사용해 Console Appp정도의 간단한 Application을 만들어 보는 것으로 시작할까 합니다. 하지만 만약 Windows OS를 사용하지 않거나 VSCode만을 사용하기로 결정했다면 사실 이 과정은 건너뛰어도 괜찮습니다. 사실 앞으로의 예제는 대부분 VSCode를 사용하는 경우가 많을 테지만 기본적인 개념은 거의 동일하므로 VS2026에 대한 설명을 지나친다고 하더라도 크게 문제가 될 건 없습니다.

 

1) VS2026을 사용해 .NET Project 만들기

 

기본적인 예제를 빠르게 만들어 보는 것을 목표로 하므로 일부 세부적인 설명은 생략할 수 있습니다. 그러나 생략된 설명은 추후에 자세히 설명될 것이므로 일단 설명대로 따라해 .NET Project를 생성해 보시기 바랍니다.

 

VS2026을 실행한 후 첫 화면에서 왼쪽에 'Create a new project'를 선택합니다.

 

'All languages'에서 C#을 선택하고 'Search for templates'에서 'console'을 입력합니다.

 

하단 template목록에서 가장 처음항목인 'Console App'을 선택하고 'Next'를 Click 합니다.

 

Project name에서 임의의 Project명을 입력하고 해당 Soluction(Project)가 저장될 경로를 Location에서 지정한 뒤 'Next'를 Click합니다.(저장위치와 Project명, Solution명은 자유롭게 설명할 수 있습니다. 예제에서는 기본값 그대로 사용하였습니다.)

 

Framework에서 '.NET 10 (Long Term Support)'를 설정합니다. 아마 대부분 기본적으로 선택가능한 '.NET 10'항목 하나만 존재할 테지만 만약 다른 version의 .NET SDK가 설치되어 있다면 .NET 9.0과 같이 다른 선택가능한 항목이 존재할 수 있습니다. 여기서 Enable container support, Do not use top-level statements 등 다른 설정은 그대로 남겨두고 'Create'를 Click한뒤 잠시 기다리면 다음과 같은 화면을 볼 수 있습니다.

 

처음 표시되는 code는 Program.cs file의 code로서 현재는 주석문 한 줄과 code 한 줄만이 존재하고 있습니다. Project생성 시 다른 option사항을 선택하지 않았다면 C# 9.0에서 도입된 top-level program기능을 사용하게 되므로 아주 간소화된 code만이 존재함을 알 수 있습니다.

 

이제 Code를 아래와 같이 간단히 수정해 봅니다.

// See https://aka.ms/new-console-template for more information
Console.WriteLine("안녕, C#");

 

(1) 예제를 Compile 하고 실행하기

 

상기와 같이 수정한 뒤 예제를 실행하기 위해 VS2026의 상단 Menu에서 Debug -> Start Without Debugging을 선택합니다. 그런 뒤 잠시 기다리면 다음과 같은 Console화면이 열리면서 예제가 실행될 것입니다.

Console화면의 색상이나 형태는 각 PC의 설정에 따라 조금씩 다르게 표시될 수 있습니다.

 

위 상태에서 임의의 key를 누르면 Console화면이 닫히고 VS2026 화면으로 되돌아갈 것입니다.

 

Solution Explorer에서 Project(예제에서는 ConsoleApp1)를 double click 하거나 Mouse오른쪽 button을 눌러 'Edit Project File'을 선택하면 아래와 같이 Project file(*csproj)의 내용이 표시될 것입니다. 아래 설정에 따라 현재 예제 Project는 .NET 10을 target으로 하고 있음을 알 수 있습니다.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
</Project>

 

대게 Project file의 명칭은 Project명을 따라가므로 예제와 같은 경우라면 Project file명은 'ConsoleApp1.csproj'가 될 것입니다.

 

(2) Visual Studio에서 Debugger사용하기

 

VS2026에서 Project를 실행하는 경우 상황에 따라 Debugger를 사용할지 여부를 선택할 수 있습니다. 만약 debugging이 필요하지 않은 경우라면 Debugger를 사용하지 않는 편이 훨씬 더 나을 것입니다. 왜냐하면 Debugger를 사용하게 되면 더 많은 Resource를 사용하면서 속도도 Debugger를 사용하지 않는 것보다 더 느리게 실행될 것이기 때문입니다.

 

또한 Debugger를 사용하게 되면 단 하나의 Project만 실행할 수 있다는 단점도 존재합니다. 만약 하나이상의 Project를 Debugger를 사용하면서 동시에 실행해야 한다면 그만큼 VS2026을 중복으로 실행해 각각의 Project를 개별적으로 실행해야 합니다.

 

그런데 현재 Project에서 Debugger사용하도록 Project를 실행하면 Console화면이 표시되었다가 결과를 확인하기도 전에 금방 닫혀버리는 경우가 있습니다. 이런 경우 VS2026의 Tools -> Options -> Debugging -> General Menu를 선택하고 오른쪽 설정항목에서 'Automatically close the console when debugging stops'부분이 설정되어 있는지 확인합니다. 만약 이 설정이 설정상태에 있다면 Check표시를 지워 설정을 해제하도록 합니다.

 

(3) VS2026에서 Solution에 Project추가하기

 

대다수 Project는 단일 Solution에 단일 Project만이 존재하는 경우가 거의 없습니다. 필요에 따라 또는 용도에 따라 여러 가지 Project로 나뉘는 경우가 많이 때문에 Solution에 Project가 추가되는 경우는 흔하다고 할 수 있습니다.

 

VS2026에서 Solution에 Project를 추가하기 위해 File -> Add -> New Project...를 선택합니다.

비슷한 Menu로 File -> New -> Project/Solution이 있으나 이 기능은 새로운 Project와 Solution을 추가하는 것입니다.

 

Add a new project 화면에서 Recent project templates밑에 Console App을 선택하고 Next를 눌러줍니다.

Configure your new project 화면에서는 사용할 Project이름과 Project가 생성될 위치를 지정합니다. (예제에서는 기본값 그대로 사용하였습니다.)

 

Additional information 화면에서는 현재 표시된 상태 그대로 사용하되 'Do net use top-level statements'만 check 해 줍니다.

이제 Create를 눌러 Project를 생성합니다.

 

새로운 Project의 Program.cs를 열어보면 이번에는 아래와 같이 Project명과 동일한 Namespace가 선언되었고 Program internal class 및 내부에 args 매개변수를 가진 정적 Main method가 포함되어 있는 걸 확인할 수 있습니다.

namespace ConsoleApp2
{
    internal class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello, World!");
        }
    }
}

 

위 상태에서 Project의 Namespace를 확인할 수 있도록 이전과 동일한 구문을 아래와 같이 추가해 줍니다.

static void Main(string[] args)
{
    string namespaceName = typeof(Program).Namespace ?? "이름없음";
    Console.WriteLine(namespaceName);
    Console.WriteLine("Hello, World!");
}

 

VS2026의 Solution Explorer에서 ConsoleApp1 Solution을 선택한 뒤 mouse오른쪽 button을 눌러 'Configure Startup Projects...'항목을 선택합니다.

 

그리고 'Solution 'ConsoleApp1' Property Pages화면에서 Startup Project를 Current selection으로 변경한 뒤 OK를 눌러 설정을 반영합니다.

 

그런 뒤 다시 Solution Explorer에서 ConsoleApp2 project를 선택(또는 Project내부에서 임의의 folder나 file을 선택해도 동일)하면 해당 Project명이 진하게 변경됨으로써 시작 Project로 설정되었음을 확인할 수 있습니다.

Solution Explorer에서 시작 Project로 바꾸고자 하는 Project명을 Mouse오른쪽 button으로 눌러 'Set as Startup Project'항목을 선택해도 동일한 기능을 수행할 수 있습니다.

 

이 상태에서 Project를 실행하면 다음과 같은 결과를 표시할 것입니다.

 

Visual Studio에서 Project를 실행하는 경우 해당 Application은 [Project명]\bin\Debug\net10.0 folder에 존재하는 Project file을 실행하게 됩니다. 하지만 VSCode(dotnet CLI)에서 Project를 실행하는 경우에는 VS20265과 다른 동작을 취하게 되므로 주의해야 합니다.

Solution을 생성한 뒤 Solution file확장자를 보면 기존의 sln에서 slnx로 변경되어 있음을 알 수 있습니다. sln은 해당 Solution만의 고유한 방식으로 장황하며 읽기 어려운 구조로 되어 있고 GUID(Globally Unique Identifiers)를 사용해 Solution에 포함된 다른 Project나 Component를 참조하고 있습니다. 하지만 slnx는 XML을 사용하는 방식으로 간단하면서도 상대적으로 읽기 쉬운 구조를 갖고 있습니다. 아마도 VS2026에서는 slnx가 기본 Solution file로 설정되어 있을 테지만 그렇지 않거나 다른 file을 기본 Solution file로 설정해야 한다면 Tools -> Options -> Projects and Solutions의 설정화면에서 General부분의 설정을 바꿔줄 수 있습니다.

 

2) bin과 obj folder

 

bin과 obj는 compiler에 의해 자동으로 생성되는 folder로서 obj는 각 source file을 compile 한 하나의 object file을 포함하고 있으며 bin은 App이나 class library로서 실행가능한 binary file을 포함하고 있는 folder입니다.

 

물론 해당 folder의 구조나 내부에 포함하고 있는 file들을 세부적으로 모두 알아야 할 필요는 없지만 어쨌건 상기 2개의 folder와 file은 Compiler가 Project를 build 할 때마다 임시적으로 생성한다는 점을 기억하시기 바랍니다. 원한다면 이들 folder를 삭제할 수 있지만 Project를 build 하는 과정을 거칠 때마다 folder는 다시 생성됩니다. 대개의 경우 bin과 obj를 가지고 뭔가를 해야 하는 경우는 거의 없기 때문에 현재는 이런 것이 있다는 정도만 알고 넘어가면 충분합니다.

위 folder안에 여러 file 중 '.g.'와 같이 중간에 g가 붙은 file을 볼 수 있는데 여기서 'g'는 generated를 의미합니다. 해당 파일은 build과정에서 새롭게 만들어지므로 file을 삭제하거나 file명을 변경하는 것은 무의미하며 그렇게 해야 할 이유도 없습니다.

 

bin과 obj는 수동적으로 삭제할 수 있지만 VS2026의 'Solution Explorer'에서 'clean'을 통해 삭제할 수도 있습니다. 이렇게 하려면 Project를 mouse오른쪽 button으로 눌러 'Clean'항목을 선택하기만 하면 됩니다. 이러한 동작은 dotnet CLI에서 'dotnet clean'명령한 것과 동일합니다.

 

3) Top-level Programs

 

예전에 .NET Project를 신규로 생성하는 경우 처음 시작되는 code는 다소 장황한 느낌이 있었습니다. 심지어 비교적 단순한 Console App을 생성하는 경우에도 한줄짜리 간단한 message를 출력하는것이 전부인데 간단한 동작과는 다르게 몇줄짜리 code가 기본으로 생성되곤 했습니다. 하지만 이러한 방식은 .NET 6이후부터 compiler가 필수적인 code를 대신 처리해 줌으로서 기본으로 시작되는 code의 양이 크게 간소화되기 시작했습니다.

 

.NET 5 또는 그전에서나 혹은 그 이후의 .NET Version이라 하더라도 Project생성 시 'Do net use top-level statements'항목을 선택했다면 Program.cs는 다음과 같은 형태로 만들어지게 됩니다.

using System;

namespace ConsoleApp1
{
    class Program
    {
        staic void Main(string[] args)
        {
            Console.WriteLine("Hello, World!");
        }
    }
}

 

하지만 .NET 6부터 Program class와 Main method는 compiler에 의해 자동으로 생성되어 개발자가 작성한 code를 감싸는 형태로 처리하게 되므로 주석과 code구문을 포함한 단 2줄만 Program.cs에 표시하게 되었습니다.

 

사실 top-level programs라는 기능은 .NET 5부터 도입된 것인데 이걸 Microsoft는 .NET 6에 와서야 Console App project의 template에 기본으로 적용하도록 하였으며 .NET 7부터 개발자의 선호도에 따라 직접 어떤 style로 시작할지 선택할 수 있도록 하였습니다. 따라서 top-level programs기능을 사용하고 싶지 않다면 VS2026의 경우 Project생성 시 'Do net use top-level statements'를 선택하면 되고 dotnet CLI를 사용하는 경우 '--use-program-main'이라는 option을 붙여주면 됩니다.

일반적인 경우라면 namespace는 project명과 동일하게 생성되지만 top-level programs기능을 사용하는 경우 namespace가 정의되지 않으므로 Program class는 암시적으로 이름이 없는 빈 namespace상에서 정의됩니다.

 

Top-level Programs은 compile과정에서 필연적으로 code가 수정되어야 하므로 다음 사항을 기억해야 합니다.

• Project에서 단 하나의 파일에만 적용할 수 있습니다.
• Namespace import를 위한 모든 using문은 file의 상단에 위치해야 합니다.
• Class나 기타 다른 type을 선언하는 경우 file의 하단에 위치해야 합니다.
• 주 진입함수의 Method이름인 Main은 직접적으로 사용할 수 없습니다. Main함수를 명시적으로 정의하고자 하는 경우에도 compile과정에서 <Main>$로 변경됩니다.

4) Global Namespace Import

 

만약 System namespace를 import 하고자 한다면 우리는 해당 file 상단에 다음과 같이 구문을 작성할 수 있습니다.

using System;

 

위와 같이 구현하면 System namespace에 속해있는 Console을 바로 사용할 수 있고 따라서

Console.WriteLine...

 

위와 같은 구문작성이 가능하게 됩니다. 하지만 이전에 만든 예제의 경우 'using System;'문을 사용하지 않았음에도 불구하고 Console.WriteLine...구문을 그대로 사용되었음을 볼 수 있습니다. 이런 것이 가능한 이유는 Project가 C# 10/.NET 6에서 도입된 Global Namespace Import라는 기능을 사용하고 있기 때문입니다.

 

VS2026의 Solution Explorer에서 obj -> Debug -> net10.0 folder를 순서대로 열어보면 '[Project명].globalUsings.g.cs'라는 file을 볼 수 있습니다.(예제에서는 'ConsoleApp1.GlobalUsings.g.cs') 이 file은 .NET 6부터 compiler에 의해 자동으로 생성되는 file로 Global Namespace Import의 기능을 수행하는 file입니다. 해당 file을 열어보면 다음과 같이 구현되어 있는데

// <auto-generated/>
global using System;
global using System.Collections.Generic;
global using System.IO;
global using System.Linq;
global using Systehttp://m.Net.Http;
global using System.Threading;
global using Systehttp://m.Threading.Tasks;

 

System과 같이 어느 Project에서나 적용되는 공통적인 일부 Namespace가 Impport 되어 있음을 알 수 있습니다. 이러한 구현은 Project내의 모든 code file에 적용되는 것으로 이 기능덕에 각 code file에서는 저마다 공통적으로 import 하는 반복적인 작업을 생략할 수 있게 되었습니다. 이 기능에 관한 더 자세한 사항은 추후에 다시 다룰 것입니다.

 

5) 예외를 통해 자동으로 생성된 Code 살펴보기

 

Top-level Programs기능은 본래 필요한 Code를 생략하는 것이 아니라 Compile과정에서 생성해 주는 방식으로 동작합니다. 다시 말해 Compile을 거쳐지 않으면 볼 수 없다는 얘기인데 대신 Runtime에서 예외를 일으키게 되면 숨겨진 Code를 확인할 수 있습니다.

Project의 Program.cs에서 다음과 같이 예외를 일으키는 구문을 추가합니다.

// See https://aka.ms/new-console-template for more information
Console.WriteLine("안녕, C#");
throw new Exception();

 

그리고 VS2026의 Debug -> Start Without Debugging를 선택해 Project를 실행합니다. 이때 Debugging으로 Project를 시작하지 않도록 주의해야 합니다. 예외가 발생하면 Debugger에 의해 예외가 다뤄지기 때문에 보려고 하는 결과를 제대로 살펴볼 수 없습니다.

 

Project가 실행되면 다음과 같은 결과를 표시할 것입니다.

 

결과를 보면 인수의 전달을 위해 args라는 매개변수를 사용하고 있는 <Main>$이름의 Main method를 볼 수 있으며 해당 Mehtod는 Program Class안에 정의되었음을 알 수 있습니다. 이러한 부분은 Compiler에 의해 자동으로 생성된 것입니다.

 

6) Program class의 Namespace확인하기

 

이전에 top-level program에서의 Namespace는 이름이 없다고 언급한 적이 있는데 그것이 사실인지 확인해 보겠습니다.

 

Program.cs에서 예외처리한 구문 위에 아래의 구문을 추가합니다. 해당 구문은 Program class의 Namespace이름을 가져와 이를 화면에 표시하도록 합니다.

using System.Text;

Console.OutputEncoding = Encoding.UTF8;
Console.InputEncoding = Encoding.UTF8;

Console.WriteLine("안녕, C#");

string namespaceName = typeof(Program).Namespace ?? "이름없음";
Console.WriteLine(namespaceName);

throw new Exception();

예제에서 사용된 ??은 null 조건부 연산자로서 왼쪽 피연산자가 null인 경우 반환값을 오른쪽 값으로 대체하도록 하는 연산자입니다.

VS2026의 Code Editor는 code snippets라는 기능이 있어 일반적으로 사용되는 긴 문장을 짧은 글로 대체하여 입력할 수 있습니다. 예를 들어 'Console.WriteLine()'을 입력하고자 하는 경우 cw를 입력한 뒤 Tab이나 Enter key를 누르게 되면 자동으로 'Console.WriteLine()'가 입력된 뒤 괄호 안에 Cursor를 이동시켜 곧바로 화면에 표시하고자 하는 내용을 입력할 수 있는 상태가 됩니다. 좀 더 자세한 사항은 아래 link를 참고하시기 바랍니다.
https://learn.microsoft.com/en-us/visualstudio/ide/code-snippets?view=visualstudio

예제에서 사용된 Console.OutputEncoding과 Console.InputEncoding은 Console에 한글이 표시될 때 글자가 깨지는 현상을 방지하기 위해서 추가한 것입니다.

 

예제를 실행하면 아래와 같은 결과를 표시할 것입니다.

 

7) C# Code를 Project file 없이 실행하기

 

VS2026에서 Project를 생성하고 실행해 본 지금까지 예와 같이 C# Code file(.cs)은 물론 기타 여러 가지 file들이 하나의 Project안에 포함되어 있고 이를 관리하는 Project file이 필수적으로 필요하다는 것을 알 수 있습니다. 이런 Project file은 내부에서 target이 되는 .NET Runtime Version이나 nullability언어기능, global namespace import와 같은 어려가지 설정들을 포함하고 있으며 다른 Project나 Package의 참조정보를 가지고 있기도 합니다.

 

그런데 예제처럼 복잡하지 않은 아주 단순한 Console App만을 필요로 한다면, 게다가 기본적으로 적용되는 Project규칙의 대부분을 굳이 따로 설정하거나 바꿀필요가 없다면 Project단위의 관리는 오히려 Application을 만드는데 복잡한 절차만 더해지는 꼴이 될 수 있습니다.

 

다른 언어, 예를 들면 Python과 같은 언어의 경우 Project단위가 아니라 하더라도 아래와 같이 단일 file에 대한 실행방식을 지원하고 있습니다.

python app.py

 

(1) File-based apps

 

Microsoft는 이러한 문제를 해결하고자 C# 14에서 file-based apps라는 기능을 도입하게 되었습니다. 이 기능은 python과 비슷하게 단일 cs file로만 직접적으로 실행가능하도록 합니다.

dotnet run mycsapp.cs

 

단일 file로 Application을 만드는 경우에도 top-level 구문을 사용할 수 있기 때문에 Namespace와 Main을 따로 정의해야 하는 번거로움이 없으며 복잡한 Project구조를 따르지 않기 때문에 Application을 더욱 간단하고 빠르게 만들어낼 수 있습니다. 특히 C# 언어에 대한 학습이나 간단한 TEST가 필요할 때 손쉽게 사용가능한 유용한 방식이라 할 수 있습니다.

File-based apps기능을 사용할 때 file명은 굳이 Program.cs일 필요가 없습니다.

 

(2) File-based apps 만들기

 

우선 알아둬야 할 건 File-based app은 dotnet CLI 기능이므로 VS2026에서 만들 수 없다는 것입니다. 따라서 적당한 folder를 하나 만들고 여기서 VSCode와 같은 Code편집기로 임의의 cs file을 하나 생성한 뒤 필요한 file내용을 직접 작성합니다. 예제에서는 FileBasedApps folder에 test.cs라는 file을 만들어보았습니다.

 

File을 저장한 뒤 Windows Terminal이나 VSCode의 Terminal에서 FileBasedApps folder로 위치한 뒤 아래와 같은 명령을 사용해 file을 실행합니다.

dotnet run test.cs

 

잠시 기다리면 다음과 같은 결과를 표시할 것입니다.

현재까지 File-based apps는 하나의 file만을 지원합니다. 다수의 file에 대한 지원은 .NET 11에서 지원될 예정입니다.

 

(3) File-based apps에 대한 추가지원 기능

 

Project 없는 단일 cs file이라고 하더라도 외적인 기능을 지원해야 하는 경우가 있을 수 있습니다. 이럴 때는 특별한 지시자문자인 '#:'을 사용합니다.

 

예를 들어 특정 NuGet Package를 필요로 하는 경우 아래와 같이 NuGet참조를 추가할 수 있습니다.

#:package Newtonsoft.Json@13.0.3

using Newtonsoft.Json;

var obj = new { Name = "홍길동", Age = 30 };
string json = JsonConvert.SerializeObject(obj);
Console.WriteLine(json);

 

만약 외부의 Class Library를 참조해야 한다면 아래와 같이 사용할 수 있고

#:project ../MyLibrary/MyLibrary.csproj

 

특정 SDK를 지정해야 한다면 #:sdk를 사용하면 됩니다.

#:sdk Microsoft.NET.Sdk.Web

using System;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;

Console.WriteLine("ASP.NET Core SDK 로드 완료!");

SDK의 Version을 구분해야 한다면 @를 사용합니다. (#:sdk Microsoft.NET.Sdk.Web@11.1.0)

 

또한 MS Build 속성의 설정도 가능해서 C#언어의 Version을 다음과 같이 지정할 수도 있습니다.

#:property LangVersion=9.0

 

위와 같이 만들어진 cs file은 추후 필요하다면 아래 명령을 통해 완벽한 Project형태로 재생성할 수 있습니다.

dotnet project convert test.cs

 

배포가 필요하다면 그것 역시 가능한데

dotnet publish test.cs

 

다만 위와 같이 하는 경우 기본적으로 AOT Compile이 적용되므로 이를 끄고자 한다면 #:property를 통해 다음과 같이 설정해야 합니다.

#:property PublishAot=false

 

File-based apps에 관한 더 자세한 사항은 아래 link를 참고해 보시기 바랍니다.
https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/

Announcing dotnet run app.cs - A simpler way to start with C# and .NET 10 - .NET Blog

 

관련하여 동영상도 시청할 수 있습니다.
https://www.youtube.com/watch?v=98MizuB7i-w

 

감사합니다.