C# 14의 새로운 필드 키워드

설정: 간단한 사람 모델

[0:12 - 1:07] 팀은 .NET 10과 Visual Studio 2026에서 실행 중인 콘솔 애플리케이션으로 시작합니다. 데모는 몇 가지 속성이 있는 Person 클래스에 중점을 둡니다:

public required string FirstName { get; set; }
public required string LastName { get; set; }
public int Age { get; set; }

public required string FirstName { get; set; }
public required string LastName { get; set; }
public int Age { get; set; }

또한, 네이밍 충돌이 발생하면 관련성 있는 비공개 필드가 지원하는 Demo 속성이 있습니다. 팀은 Program.cs에서 FirstName = "Tim" 및 LastName = "Corey"과 함께 인스턴스를 생성한 후 성, 나이, 데모 값을 출력합니다. 모든 것이 예상대로 출력됩니다: "Corey", 0 (기본 정수 값), 및 "test".

문제: 자동 속성이 잘못된 데이터를 허용함

[1:23 - 2:49] 팀이 null을 LastName에 할당할 때 문제가 발생합니다.:

p.LastName = null;

p.LastName = null;

LastName이 required으로 표시되고 비Nullable 문자열로 타이핑 되었지만 할당은 컴파일됩니다. required 수정자는 객체 초기화 동안 값이 제공되도록 강제할 뿐입니다; 이후에 누군가가 속성을 null로 설정하지 못하게 막지 않습니다. 결과는 런타임에서 오류 없이 빈 성으로 남습니다.

이는 데이터 무결성에 있어 실제적인 격차입니다. nullable 참조 지그재그를 통해 타입 시스템이 경고하지만, 이는 컴파일 타임 힌트일 뿐, 런타임 보호는 아닙니다. 귀하의 애플리케이션이 LastName 항상 유효한 문자열을 포함하고 있는지에 달려있다면, 자동 속성으로만 그 계약을 강제할 수 없습니다.

이전 해결책: 수동 백킹 필드를 가진 전체 속성

[2:58 - 4:19] C# 14 이전에 표준 솔루션은 자동 속성을 명시적인 백킹 필드를 가진 전체 속성으로 전환하는 것이었습니다:

private string _lastName;
public required string LastName
{
    get => _lastName;
    set => _lastName = value ?? throw new ArgumentNullException(nameof(LastName));
}

private string _lastName;
public required string LastName
{
    get => _lastName;
    set => _lastName = value ?? throw new ArgumentNullException(nameof(LastName));
}

Tim은 이것을 실행하여 예외가 올바르게 발생되는지 확인합니다: "값은 null일 수 없습니다. 매개변수 이름: LastName." 이 접근 방식은 효과적이지만, 개인 필드를 선언하고, 게터와 셋터를 둘 다 연결하고, 여러 줄에 걸쳐 속성 이름을 반복해야 합니다. 단일 검증 규칙에 대해, 그것은 많은 형식적 절차입니다.

이 경우 게터는 특별히 할 일이 없습니다; 그것은 필드를 변경 없이 반환합니다. 그러나 자동 속성 영역을 벗어나면 구문이 양쪽 절반을 요구하기 때문에, 여전히 명시적으로 작성해야 합니다. Tim은 새로운 기능의 동기를 이러한 장황함에 기인한다고 설명합니다.

C# 14 해결책: 필드 키워드

[4:23 - 5:47] C# 14는 중간 지점을 소개합니다. 자체적으로 비공개 백업 필드를 선언하는 대신, getter 또는 setter 내에서 컨텍스트 키워드 field을 사용하여 컴파일러 생성 백업 필드를 직접 참조합니다:

public required string LastName
{
    get;
    set => field = value ?? throw new ArgumentNullException(nameof(LastName));
}

public required string LastName
{
    get;
    set => field = value ?? throw new ArgumentNullException(nameof(LastName));
}

getter는 바디가 필요 없는 자동 구현 get;으로 남아 있습니다. setter는 검증 후 들어오는 value를 할당하기 위해 field를 사용합니다. 컴파일러는 표준 자동 속성과 마찬가지로 화면 뒤에서 백킹 필드를 생성하고 관리합니다.

데모 실행은 null 할당 시 동일한 ArgumentNullException를 생성합니다. 동작은 수동 백킹 버전과 동일하며, 일곱 줄에서 논리만 사용자 정의하는 집중된 블록으로 압축됩니다. 당신은 자동 속성 게터를 유지하고, 셋터에만 로직을 추가하며, 수동 필드 선언은 완전히 생략합니다.

이는 평범한 자동 속성 (한 줄, 검증 없음)과 전체 속성 (7줄 이상, 완전 제어) 사이의 유용한 중간 단계를 제공합니다. 로직이 셋터만을 다룰 때, 더 이상 게터도 다시 작성하는 통사적 비용을 지불하지 않아도 됩니다.

셋터 가드로 나이를 검증하기

[6:16 - 7:39] field이 null 확인에만 제한되지 않음을 보여주기 위해 팀은 Age 속성에 범위 검사를 추가합니다:

public int Age
{
    get;
    set
    {
        if (value > 0 && value < 120)
            field = value;
    }
}

public int Age
{
    get;
    set
    {
        if (value > 0 && value < 120)
            field = value;
    }
}

여기에서 셋터는 합리적 범위를 벗어난 값을 조용히 무시합니다. -5을 할당하면 조건이 실패하고 field이 절대 작성되지 않기 때문에 Age의 기본값인 0으로 유지됩니다. 팀은 예외를 던질 수도 있지만 조용한 접근 방식은 설정자 본문에 필요한 모든 논리를 포함할 수 있음을 보여주는 반면, 여전히 저장을 위해 field에 의존합니다.

패턴은 광범위하게 적용됩니다: 숫자 범위를 제한하거나, 문자열에서 공백을 자르거나, 케이스를 정규화하거나, 속성이 설정될 때마다 원하는 변환을 적용합니다.

기존 필드 변수와의 명명 충돌

[7:39 - 9:43] Tim은 고의적인 예외 사례를 소개합니다. 데모 클래스에는 문자 그대로 field이라는 이름의 개인 멤버가 있습니다:

private string field = "test";

private string field = "test";

C# 14가 활성화되면, 컴파일러는 속성 접근자 내에서 field을 변수보다는 키워드로 취급합니다. 즉, field을 참조하는 속성은 문자열 멤버가 "test"를 포함하는 대신 그 속성 뒤의 숨겨진 저장소(비어 있음)에서 조용히 읽습니다. 출력은 컴파일 오류 없이 빈 문자열로 변경되며, 경고만 발생합니다.

두 가지 해결책이 있습니다. this.field을 접두사로 붙이면 컴파일러에게 키워드가 아니라 클래스 수준 멤버를 의미한다는 것을 알립니다. 또는 @field 이스케이프는 동일한 방식으로 작동합니다:

// Both refer to the instance variable, not the keyword
string demo => this.field;
string demo => @field;

// Both refer to the instance variable, not the keyword
string demo => this.field;
string demo => @field;

팀의 강력 추천은 C# 14로 업그레이드 할 때 field라는 모든 변수를 새로 명명하는 것입니다. IDE에서 "모두 이름 변경"을 빠르게 수행하면 모호함이 영구적으로 제거됩니다. 충돌은 속성 접근자 내부에서만 발생합니다; 생성자와 메서드는 기대한대로 변수 이름을 field로 해석합니다. 해당 컨텍스트에는 암시적 백업 저장소가 없기 때문입니다.

마무리: 더 적은 보일러플레이트, 동일한 제어

[10:04 - 10:28] field 키워드는 일상적인 C# 코드의 실질적인 차이를 메웁니다. 하나의 보호 절이나 변환을 필요로 하는 속성은 이제 수동 백킹 필드로 전체를 다시 쓰지 않아도 됩니다. 로직이 필요한 접근자만 사용자 정의하고 다른 것은 표준 자동 구현으로 남겨둡니다.

결론

[10:28 - 10:35] 요약: C# 14의 field 키워드는 모든 속성 접근자 내의 암시적 백업 저장소에 대한 직접 액세스를 제공합니다. 셋터 검증, 게터 변환, 또는 둘 다 추가하기 위해 사용하며, 사용자 정의가 필요 없는 부분에 대해 자동 속성 구문을 버리지 않습니다.

업그레이드하기 전에 코드베이스에서 field라는 모든 변수를 검색하여 새 이름으로 바꿉니다. 그 하나의 예방 조치는 이 기능이 소개하는 유일한 실제 문제를 피합니다. 그 외, 대부분의 개발자가 이미 모델을 구조화하는 방식에 자연스럽게 맞는 간편한 보일러플레이트 축소입니다.

예제 팁: setter만 검증할 필요가 있는 경우, getter를 바디가 없는 평범한 get;로 남겨두십시오. 컴파일러는 자동 속성 게터로 이를 처리하며, 아무 것도 추가하지 않는 핀호환 return 문을 작성하지 않으므로 합니다.

전체 비디오를 그의 YouTube 채널에서 시청하고 C# 언어 기능에 대한 추가 통찰력을 얻으세요.