10분 이내에 마스터하는 C# 10과 .NET 6의 전역 사용

반복 문제

[0:17 - 1:50] Tim은 새 .NET 6 콘솔 앱을 시작하고 Data 폴더에 PersonModel 클래스를 만듭니다. Program.cs에서 해당 클래스를 참조하려면 파일 상단에 예상되는 using GlobalUsings.Data; 줄이 필요합니다. 또한 PersonModel도 필요한 두 번째 클래스를 추가하려면 해당 파일 상단에 동일한 using 줄을 추가해야 합니다. 여섯 개의 클래스가 있는 경우, 동일한 가져오기가 여섯 번 작성됩니다.

이것이 바로 global using가 설계된 상황입니다. 전체 프로젝트가 의존하는 네임스페이스, 타입 또는 정적 클래스는 한 번 선언하고 각 파일에 대해 다시 설명할 필요 없이 모든 파일에서 사용할 수 있게 만들 수 있습니다.

전역 범위로 사용 승격

[1:50 - 2:24] 구문은 기존 지시문 앞에 있는 단일 키워드입니다:

global using GlobalUsings.Data;

global using GlobalUsings.Data;

프로젝트의 .cs 파일 어디에나 배치된 한 줄이 동일 프로젝트의 다른 모든 파일에서 GlobalUsings.Data을 사용할 수 있도록 합니다. 이전에 PersonModel를 위해 자체 using 줄이 필요했던 다른 클래스들은 더 이상 필요하지 않습니다; 타입이 자동으로 해결됩니다. 범위는 프로젝트 경계에서 멈추므로, 형제 프로젝트에서 클래스 참조는 여전히 일반 프로젝트 참조와 함께 자체 전역 또는 파일별 사용이 필요합니다.

이것이 하지 않는 것은 타입이 어디서 오는지 숨기는 것입니다. 컴파일러는 여전히 PersonModel을 해당 네임스페이스로 해결합니다; 네임스페이스는 단순히 미리 가져온 것입니다. 런타임 시의 동작은 파일 맨 위에 같은 사용을 작성하는 것과 동일합니다.

하나의 파일에서 사용 중앙 집중화

[2:24 - 3:32] 글로벌 사용 지시문을 임의의 파일에 뿌리는 것은 기술적으로 유효하지만 운영상으로는 혼란스러울 수 있습니다. 새로운 팀원이 명확한 임포트 없이 PersonModel이 해결되는 것을 본다면, 프로젝트를 grep하여 어디에서 글로벌로 설정되었는지 찾아야 합니다. 진화하는 관례는 모든 전역 사용을 프로젝트 루트의 단일 파일에 유지하는 것입니다, 예를 들어 Usings.cs 또는 GlobalUsings.cs와 같은 예측 가능한 이름의 파일에:

// Usings.cs at the project root
global using GlobalUsings.Data;
global using System.Text.Json;
global using System.Collections.Concurrent;

// Usings.cs at the project root
global using GlobalUsings.Data;
global using System.Text.Json;
global using System.Collections.Concurrent;

파일에는 다른 것이 포함되어 있지 않습니다. 프로젝트에 합류한 사람은 글로벌로 사용 가능한 것이 무엇인지 보려면 딱 한 곳을 보면 됩니다. 이는 최근 C# 릴리스에서 도입된 파일 스코프 네임스페이스 및 기타 식을 줄이는 기능과 접점이 되며, 모두 프로젝트 상용구를 더 쉽게 빠르게 읽을 수 있도록 합니다.

메서드 수입을 위한 전역 사용 정적

[3:32 - 4:50] 전역 사용 지시문은 이전에 추가된 정적 형태의 사용과 결합됩니다. 이 조합은 전체 프로젝트에서 정적 클래스 멤버의 클래스 접두사를 생략할 수 있게 만듭니다. Tim이 보여주는 동기 케이스는 Console.WriteLine입니다:

global using static System.Console;

global using static System.Console;

중앙 집중식 usings 파일에 있는 그 한 줄로, 프로젝트의 어디에서나 Console.WriteLine("hello")이 간단히 WriteLine("hello")가 됩니다. 수학 도우미(전역 using static System.Math를 사용하여 접두사 없이 Sqrt(x)를 쓸 수 있음) 및 코드베이스에서 많이 사용하는 다른 정적 클래스에도 동일한 패턴이 적용됩니다.

이것이 Tim이 가장 조심하는 형태입니다. 클래스 접두사의 떨어짐은 메서드가 명확할 때 읽기 용이성이 증가하며, 동일한 이름으로 메서드를 노출하는 두 정적 클래스가 있으면 혼란의 원인이 될 수 있습니다. 단순 WriteLine 호출을 보고 있는 독자는 소스 맥락을 보기보다는 중앙 파일을 신뢰해야 합니다.

글로벌 임포트가 서로 충돌할 때

[4:50 - 5:14] 네임스페이스의 전체 요점은 같은 짧은 이름의 타입이 충돌하지 않도록 하는 것입니다. 네임스페이스를 전역으로 가져오는 것은 한 번에 모든 프로젝트에서 그 버퍼를 제거합니다. 만약 GlobalUsings.Data 네임스페이스에 Data 클래스가 포함되어 있고 System.Data도 전역으로 임포트하는 경우, 이제 모든 파일이 구분해야 합니다. 비용은 충돌이 발생한 곳에서 나타나는 것이 아니라 나중에 영향을 받게 될 어떤 미래의 파일에서 드러납니다.

Tim의 지침은 전역 사용을 신중하게 사용하고, 프로젝트가 일반적으로 의존하는 네임스페이스를 선호하며, 전역 사용 정적으로 특히 신중할 것을 권장합니다. 합리적인 시작점은 어느 파일에서도 가져오는 네임스페이스입니다; 그 이후로 목록을 늘리는 것은 코드 검토가 필요합니다.

요약: 덜어지는 의식, 동일한 행동

[5:14 - 5:33] 전역 사용은 프로젝트의 수명 전체에 걸쳐 대가를 치르는 작은 기능입니다. 다섯 줄의 중복된 가져오기가 더 이상 실려 있지 않은 모든 파일은 실제 코드를 더 빨리 엽니다, 공유 네임스페이스에 대한 편집은 여러 곳이 아닌 하나의 위치에서 이루어집니다. 타입 별칭 및 더 넓은 사용 형태에 들어가는 동일한 주의가 여기에 적용됩니다: 읽기 용이성이 확실한 경우 사용하는 것이 좋으며, 중앙 파일이 다음 개발자가 한번에 스캔할 수 있을 만큼 작게 유지합니다.

결론

[5:14 - 5:33] 글로벌 사용은 파일마다 사용 줄을 프로젝트 전체 지시문으로 대체하며, 전역 사용 정적 변형은 정적 멤버 호출에서 클래스 접두사를 떨어트리고, 프로젝트의 루트에 단 하나의 Usings.cs 파일이 유지 가시성을 쉽게 만듭니다. 이 기능은 선택적으로 사용 가능하고 추가적이므로 기존 코드베이스에 채택하는 것은 점진적입니다.

예시 팁: .csproj에서 <ImplicitUsings>enable</ImplicitUsings>를 통해 암시적 usings를 켜면, SDK는 여러분이 직접 작성하지 않아도 System, System.Linq, System.Collections.Generic 같은 전역 사용 집합을 자동으로 추가합니다. 프로젝트별 가져오기에 대해 자신만의 Usings.cs와 쌍을 이루면 모든 파일의 상단이 눈에 띄게 짧아집니다.

그의 YouTube 채널에서 전체 비디오를 시청하고 10분 훈련 시리즈를 통해 현대 C# 프로젝트 구조에 대한 추가적인 통찰력을 얻어보세요.