@NoArgsConstructor 액세스 레벨을 PROTECTED로 하는 이유

개발자로서 엔티티 클래스를 생성할 때, 저는 습관적으로 @NoArgsConstructor 어노테이션을 사용해 왔습니다.

하지만 왜 사용하는지, 그리고 액세스 레벨을 왜 특정 값으로 설정하는지 명확히 알지 못한 채 사용해 왔습니다.

이번 글에서는 @NoArgsConstructor의 역할과 액세스 레벨을 PROTECTED로 설정하는 이유를 정리해 보겠습니다.

 

@NoArgsConstructor란?

@NoArgsConstructor 어노테이션은 Lombok 라이브러리에서 제공하는 기능으로, 기본 생성자를 자동으로 생성해 주는 역할을 합니다.

 

@NoArgsConstructor의 액세스 레벨

@NoArgsConstructor 어노테이션에는 다양한 액세스 레벨을 설정할 수 있습니다. 이들은 다음과 같습니다:

• PUBLIC
• PROTECTED
• DEFAULT
• MODULE
• PRIVATE

이 많은 속성 중 왜 PROTECTED를 사용하는 것일까요? 주된 이유는 프록시(proxy) 때문입니다.

 

프록시 객체

프록시 객체는 엔티티 조회 시 지연 로딩(lazy loading)을 사용할 때 만들어집니다. 지연 로딩의 결과로 반환되는 것은 원본 엔티티가 아니라 원본 엔티티를 상속한 프록시 객체입니다. 프록시 객체는 실제로 해당 엔티티를 조회할 때 원본 엔티티를 참조하여 원본 엔티티에 접근할 수 있게 해 줍니다.

이 과정에서 프록시 객체는 기본 생성자를 사용하여 원본 엔티티를 생성합니다. 만약 기본 생성자가 PRIVATE로 설정되어 있다면 프록시 객체는 이를 호출할 수 없으므로 오류가 발생하게 됩니다. 따라서 기본 생성자의 접근 제어자는 PROTECTED 또는 PUBLIC 이어야 합니다.

친절하게 인텔리제이에선 public, protected만 사용하라고 나옵니다.

 

그럼 PUBLIC은 왜 안될까?

주로 캡슐화와 객체의 올바른 사용을 보장하기 위함입니다.

 

만약 기본 생성자의 접근 제어자를 PUBLIC으로 한다면, 의도하지 않은 사용을 방지할 수 없고, 오류가 발생했을 때 자신의 코드를 역추적해서 찾는 불상사가 일어날 수 있습니다.

그래서 PROTECTED는 최소한의 접근 제어자로, 외부에서는 직접 접근할 수 없고 상속 관계나 같은 패키지 내에서는 접근이 가능하여 프록시 객체가 정상적으로 동작할 수 있게 합니다.