Java에서 필드(field)와 프로퍼티(property)는 서로 다른 개념으로, 혼동하지 않도록 명확히 구분해야 한다.

필드(Field)

필드는 클래스 내부에 선언된 변수로, 객체의 상태를 저장하는 데이터 멤버이다. 일반적으로 다음과 같이 정의된다:

public class Person {
    private String email;
    private int age;
}

위 예제에서 email과 age는 Person 클래스의 필드이다. 보안과 캡슐화를 위해 대부분의 필드는 private 접근 제한자를 사용하며, 외부에서 직접 접근할 수 없도록 설계된다. 단, 변경 불가능한 상수는 public static final로 선언되기도 한다.

프로퍼티(Property)

Java에서는 공식적인 "프로퍼티" 타입이 존재하지 않지만, 관례적으로 getter와 setter 메서드 쌍을 통해 프로퍼티를 표현한다. 이는 JavaBean 규약에 기반한다.

예를 들어 다음 메서드 쌍은 email이라는 프로퍼티를 정의한다:

public String getEmail() {
    return email;
}

public void setEmail(String email) {
    this.email = email;
}

메서드 이름에서 get 또는 set을 제거한 나머지 부분이 프로퍼티 이름이 된다. 이때 두 번째 문자가 소문자라면 첫 번째 문자도 소문자로 변환한다. 예: getUserName() → userName, getURL() → URL.

실제 예시

다음 클래스를 살펴보자:

public class Account {
    private String userId;
    private String token;
    private final String systemId = "SYS-2024";

    public String getUserId() {
        return userId;
    }

    public void setUserId(String userId) {
        this.userId = userId;
    }

    public String getToken() {
        return token;
    }

    // setter 없음 → 읽기 전용 프로퍼티
    public String getSystemId() {
        return systemId;
    }

    public static final int ACTIVE = 1;
    public static final int INACTIVE = 0;
}

이 클래스는 다음과 같은 구성 요소를 가진다:

• 필드 4개: userId, token, systemId, 그리고 상수 ACTIVE, INACTIVE (정적 필드 포함)
• 프로퍼티 3개: userId (읽기/쓰기), token (읽기 전용, setter 없음), systemId (읽기 전용)

클라이언트 코드는 다음과 같이 프로퍼티를 통해 데이터에 접근한다:

Account acc = new Account();
acc.setUserId("user123");
String id = acc.getUserId();          // userId 프로퍼티 읽기
String sysId = acc.getSystemId();     // systemId 프로퍼티 읽기
int status = Account.ACTIVE;          // public static 필드 직접 접근

왜 프로퍼티를 사용하는가?

프로퍼티는 다음과 같은 장점을 제공한다:

• 캡슐화 강화: 필드를 외부로부터 보호하고, 유효성 검사나 로깅 등의 로직을 getter/setter에 삽입 가능
• 유연성 향상: 내부 구현이 변경되어도 외부 인터페이스 유지 가능
• 리플렉션 및 프레임워크 호환성: Spring, Jackson, JPA 등 많은 프레임워크가 JavaBean 규약을 기반으로 동작

따라서 가능한 한 모든 인스턴스 필드는 private로 선언하고, 외부 노출이 필요할 경우 프로퍼티(getter/setter)를 통해 제공하는 것이 권장되는 설계 원칙이다. 단, 변경 불가능한 상수는 예외적으로 public static final로 노출할 수 있다.

이러한 패턴은 특히 POJO, DTO, VO와 같은 데이터 전달 객체에서 널리 사용되며, Java EE 및 스프링 생태계에서 표준적인 관행으로 자리잡고 있다.