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

설정: 간단한 사람 모델

[0:12 - 1:07] Tim은 .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 프로퍼티가 있으며, 이는 명명 충돌이 발생할 때 관련성이 있습니다. Tim은 Program.cs에서 FirstName = "Tim"과 LastName = "Corey"로 인스턴스를 생성한 다음, 성, 나이 및 데모 값을 출력합니다. 모든 것이 예상대로 출력됩니다: "Corey", 0 (기본 정수 값), 및 "test".

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

[1:23 - 2:49] 문제는 Tim이 생성 후 LastName에 null을 할당할 때 나타납니다.

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 체크에만 국한되지 않음을 보여주기 위해, Tim은 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으로 남습니다. Tim은 대신 예외를 던질 수 있지만, 조용한 접근은 setter 본문이 여전히 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;

Tim의 강력한 권고는 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# 언어 기능에 대한 추가 통찰력을 얻으세요.