모든 개발자가 알아야 할 5가지 기본 .NET CLI 명령

dotnet --info로 환경 점검하기

[0:31 - 1:25] Tim은 프로젝트 명령을 실행하기 전에 개발 환경을 확인하는 것부터 시작합니다. 단독으로 사용된 dotnet 명령어는 CLI가 설치되어 있고 경로에서 접근 가능함을 확인하지만, dotnet --info는 더 나아갑니다:

dotnet --info

dotnet --info

이는 기기마다 설치된 모든 SDK 및 런타임 버전을 운영 체제 세부 정보 및 활성 아키텍처와 함께 출력합니다. Tim은 .NET 10에서 이를 보여주지만, 명령은 모든 버전에서 동일하게 작동합니다. 설치된 내용을 아는 것은 버전 불일치를 디버깅하거나 CI 서버가 로컬 설정을 반영하는지 확인할 때 특히 유용합니다.

명령 1: dotnet build

[2:16 - 3:44] 첫 번째 명령은 프로젝트를 실행하지 않고 컴파일합니다:

dotnet build

dotnet build

프로젝트 디렉터리에서 이것을 실행하면 .csproj 파일을 읽고, 종속성을 해결하며 컴파일된 출력을 bin 폴더에 생성합니다. Tim은 컴파일이 실행과 별개의 단계라고 지적합니다. 이 분리는 코드가 깨끗하게 컴파일되는지 확인하고 싶을 때, 저장소에 푸시하거나 빌드 서버에 넘길 때 중요합니다.

.NET SDK는 빌드 과정에서 종속성을 해결하며 누락된 NuGet 패키지를 끌어오고 모든 참조된 어셈블리가 있는지 확인합니다. 이 단계에서 무언가 실패하면 오류 메시지가 문제에 직접적으로 지적합니다. 예를 들어 참조 누락, 문법 오류, 또는 타겟 프레임워크 불일치에 대한 것을 가리킵니다. 애플리케이션을 실행하기 전에 이러한 문제를 잡는 것은 전반적인 개발 사이클에서 시간을 절약합니다.

명령 2: dotnet run

[3:44 - 5:42] build이 컴파일에서 멈추는 반면, run은 다음 단계로 나아가 애플리케이션을 실행합니다:

dotnet run

dotnet run

이는 프로젝트를 (필요한 경우) 컴파일한 뒤 결과 출력을 실행합니다. 콘솔 애플리케이션의 경우, 이는 터미널에서 실행한다는 것을 의미합니다. 웹 프로젝트인 경우, 내장된 Kestrel 서버가 시작되고 애플리케이션이 로컬 URL에서 이용 가능하게 됩니다.

Tim은 이를 웹 애플리케이션과 함께 시연하며, 실행 중인 사이트에 브라우저를 통해 이동하여 모든 것이 올바르게 로드되는지 확인합니다. build과 run의 주요 차이점은 run이 실시간 상호작용 결과를 생성한다는 것입니다. 활발한 개발 중에는 이 명령을 가장 자주 사용하여 변경 사항을 테스트하고 그 영향을 확인할 것입니다.

명령 3: dotnet watch

[5:42 - 7:06] 애플리케이션을 중지하고, 변경을 가하고, 다시 시작하는 것은 금방 지루해집니다. watch 명령어는 이 사이클을 제거합니다:

dotnet watch

dotnet watch

이것은 실행 프로세스를 파일 감시기에 래핑합니다. 소스 파일에 변경 사항을 저장할 때, CLI가 수정을 감지하고 자동으로 애플리케이션을 다시 컴파일하고 새로 고칩니다. ASP.NET Core로 구축된 웹 애플리케이션의 경우, Razor 파일, CSS 및 C# 코드에 대한 변경 사항이 수동 재시작 없이 브라우저에 나타납니다.

Tim은 페이지를 편집하고, 저장하고, 즉시 업데이트가 반영되는 핫 리로드 동작을 시연합니다. 이러한 빠른 피드백 루프는 UI 작업 중에 소소한 조정이 자주 발생하는 상황에서 가치가 큽니다. 중지-편집-재빌드-실행 주기를 반복하는 대신, 코드에 집중하고 다른 도구를 도맡아 해결하도록 할 수 있습니다.

명령 4: dotnet clean

[7:06 - 7:56] 빌드 산출물이 시간이 지남에 따라 bin 및 obj 디렉터리에 쌓입니다. 때로는 오래된 컴파일 파일이 최근 코드 변경이 적용되지 않거나 로컬에서는 빌드가 성공했지만 새 기기에서는 실패하는 혼란스러운 동작을 초래합니다. clean 명령어가 이에 대응합니다:

dotnet clean

dotnet clean

이를 실행하면 출력 디렉토리의 내용을 제거하여 후속 빌드가 처음부터 시작될 수 있게 합니다. Tim은 이것을 매번 실행해야 한다기보다는 문제 해결 도구로 설명합니다. 프로젝트가 예기치 않게 동작하고 캐시된 출력이 원인이라고 의심될 때, clean 후 build을 실행하여 진정한 새로운 컴파일과 함께 작업하고 있는지 확인합니다.

이 습관은 특히 버전 관리에서 브랜치를 전환할 때, 종속성을 새로운 주요 버전으로 업그레이드할 때, 또는 사라졌다 나타나는 간헐적인 빌드 경고를 해결할 때 유용합니다.

명령 5: dotnet publish

[7:56 - 9:01] 마지막 명령은 개발과 배포 사이의 격차를 메웁니다:

dotnet publish

dotnet publish

build이 로컬 디버깅에 적합한 출력을 생성하는 반면, publish은 배포 준비 패키지를 만듭니다. 컴파일된 어셈블리, 구성 파일, 정적 자산 및 필요한 런타임 구성 요소가 publish 폴더에 저장되어 서버에 바로 복사할 수 있습니다.

build과 publish의 차이는 일부 개발자를 당황하게 합니다. build 출력에는 개발 시 유용하지만 프로덕션에서는 불필요하고 가끔은 바람직하지 않은 디버깅 기호 및 참조가 포함됩니다. 배포 과정에서 이러한 추가 요소들은 제거되고 출력은 대상 환경에 맞게 구성됩니다. Docker에 배포하거나 클라우드 호스트에 업로드할 때, 게시된 출력이 최종 이미지나 릴리즈 패키지에 포함됩니다.

총정리: 다섯 가지 명령, 하나의 워크플로

[9:01 - 9:15] Tim은 다섯 가지를 모두 나열하며 마무리합니다: dotnet build, dotnet run, dotnet watch, dotnet clean, 그리고 dotnet publish. 세트로 받아들여, 이들은 컴파일에서 배포까지의 핵심 개발 루프를 커버합니다. 각각은 특정 목적을 갖고 있으며, 언제 이를 사용할지 아는 것은 IDE 버튼을 클릭하는 것만으로는 제공할 수 없는 수준의 통제력을 제공합니다.

결론

[9:15 - 9:30] 이 다섯 가지 CLI 명령은 개발 중 가장 자주 수행하는 작업을 해결합니다: 컴파일, 실행, 라이브-리로딩, 오래된 출력 제거, 및 릴리즈용 패키징. 모든 .NET 프로젝트 타입과 SDK가 지원하는 모든 운영 체제에서 작동합니다.

다음 번 터미널을 열 때, 로컬 기기에서든 컨테이너 내부에서든, 혹은 원격 서버에서든, 그래픽 인터페이스 없이도 전체 개발 사이클을 거칠 수 있는 어휘를 이미 가지게 됩니다.

팁 예시: clean와 build을 dotnet clean && dotnet build으로 단일 라인으로 연결할 수 있습니다. 이는 문제 해결에 걸리는 시간을 절약할 때 특히 유용한, 첫 단계부터 새롭게 컴파일이 보장되는 단일 단계가 됩니다.

전체 비디오를 그의 YouTube 채널에서 시청하여 .NET CLI 필수 사항에 대한 더 많은 통찰을 얻으세요.