📚 kotlin Spring JAP 어노테이션

어노테이션 왜 이렇게 쓰는 거야?

package com.example.notesimple.domain

import jakarta.persistence.*
import java.time.LocalDateTime

@Entity
@Table(name = "notes")
class Note(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long? = null,

    @Column(nullable = false, length = 200)
    var title: String,

    @Lob // 대용량
    @Column(nullable = false)
    var content: String? = null,
) : BaseEntity()

@MappedSuperclass
abstract class BaseEntity(
    @Column(nullable = false, updatable = false)
    val createdAt: LocalDateTime = LocalDateTime.now(),

    @Column(nullable = false)
    var updatedAt: LocalDateTime = LocalDateTime.now()
)

1. 어노테이션이 덥혀 있는데 이렇게 사용하는 이유는 뭐야?
2. 어노테이션 구조가 대략적으로 어떻게 되어 있는거야?
3. import jakarta.persistence.* 이렇게 모든걸 다 임포트 하면 메모리 최적화는 실패하는거 아냐?
4. abstract class BaseEntity 로 정의한다음 상속하는 이유는? 그냥 클래스로 만들면 안되는거야?

---

1. 어노테이션이 덥혀 있는데 이렇게 사용하는 이유는 뭐야?

   JPA에서 어노테이션은 코드 자체에 메타데이터를 추가하여, 코드가 특정 방식으로 동작하도록 프레임워크나 라이브러리에 지시하는 역할을 합니다. XML 설정 파일을 사용하는 것보다 간결하고, 코드와 설정이 함께 있어 가독성과 유지보수성이 향상됩니다.

   각 어노테이션의 역할을 살펴보겠습니다:

   • @Entity: 이 클래스가 데이터베이스 테이블과 매핑되는 JPA 엔티티임을 나타냅니다. JPA 관리 하에 있는 객체가 됩니다.
   • @Table(name = "notes"): 엔티티가 매핑될 데이터베이스 테이블의 이름을 notes로 지정합니다. 지정하지 않으면 클래스 이름(대소문자 구분 방식은 구현체에 따라 다름)을 따릅니다.
   • @Id: 이 필드가 엔티티의 기본 키(Primary Key)임을 나타냅니다.
   • @GeneratedValue(strategy = GenerationType.IDENTITY): 기본 키의 생성 전략을 지정합니다. IDENTITY는 데이터베이스가 기본 키 생성을 담당하도록 위임하는 방식입니다(예: MySQL의 AUTO_INCREMENT, PostgreSQL의 SERIAL).
   • @Column(nullable = false, length = 200): 필드를 데이터베이스 컬럼에 매핑합니다.
     • nullable = false: 이 컬럼이 NOT NULL 제약 조건을 갖도록 합니다.
     • length = 200: 문자열 타입 컬럼의 최대 길이를 200으로 지정합니다.
   • @Lob: "Large Object"의 약자로, 대용량 데이터를 저장하는 필드에 사용됩니다. 데이터베이스에서는 CLOB (문자열) 또는 BLOB (바이너리) 타입으로 매핑됩니다. content 필드가 매우 긴 텍스트를 저장할 수 있음을 나타냅니다.
   • @MappedSuperclass: 이 어노테이션이 붙은 클래스는 엔티티가 아니며, 데이터베이스 테이블과 직접 매핑되지 않습니다. 대신, 이 클래스를 상속하는 엔티티 클래스들이 이 클래스에 정의된 필드와 매핑 정보를 상속받게 됩니다. 공통 필드(여기서는 createdAt, updatedAt)를 여러 엔티티에서 재사용하기 위해 사용됩니다.
   • @Column(nullable = false, updatable = false) (BaseEntity의 createdAt):
     • updatable = false: 엔티티가 한번 생성된 후에는 이 컬럼의 값이 데이터베이스에서 업데이트되지 않도록 합니다. 최초 생성 시각을 기록하는 용도로 적합합니다.

   결론적으로, 어노테이션은 ORM (Object-Relational Mapping) 프레임워크인 JPA에게 클래스와 필드를 어떻게 데이터베이스 스키마에 매핑하고 관리할지에 대한 "지침"을 제공하는 것입니다.

2. 어노테이션 구조가 대략적으로 어떻게 되어 있는거야?

   Java와 Kotlin에서 어노테이션은 그 자체로 특별한 종류의 인터페이스입니다. 어노테이션을 정의할 때는 @interface 키워드를 사용합니다 (Java 기준, Kotlin에서는 Java 어노테이션을 그대로 사용).

   어노테이션의 구조를 이해하기 위한 주요 요소는 다음과 같습니다:

   • 어노테이션 정의 (Annotation Definition):

     // 예시: @Column 어노테이션의 간략화된 정의 (실제 정의는 더 복잡함)
     @Target({ElementType.METHOD, ElementType.FIELD}) // 어노테이션을 적용할 수 있는 대상 (메소드, 필드 등)
     @Retention(RetentionPolicy.RUNTIME) // 어노테이션 정보를 언제까지 유지할 것인가 (RUNTIME 시점까지 유지)
     public @interface Column {
         String name() default "";
         boolean unique() default false;
         boolean nullable() default true;
         int length() default 255;
         // ... 기타 속성들
     }

   • 메타 어노테이션 (Meta-Annotations): 어노테이션을 정의할 때 사용되는 어노테이션입니다.

     • @Target: 해당 어노테이션이 어디에 사용될 수 있는지를 지정합니다. (예: ElementType.TYPE은 클래스/인터페이스, ElementType.FIELD는 필드, ElementType.METHOD는 메소드)
     • @Retention: 어노테이션 정보가 언제까지 유지될지를 지정합니다.
       • RetentionPolicy.SOURCE: 소스 코드에만 존재하며, 컴파일 시 사라집니다.
       • RetentionPolicy.CLASS: 컴파일된 클래스 파일에는 존재하지만, 런타임 시 JVM에서는 로드되지 않습니다. (기본값)
       • RetentionPolicy.RUNTIME: 컴파일된 클래스 파일에도 존재하며, 런타임 시 JVM에 의해 로드되어 리플렉션을 통해 조회할 수 있습니다. JPA 어노테이션들은 대부분 RUNTIME으로 지정되어 JPA 구현체가 런타임에 이 정보를 읽어 ORM 작업을 수행합니다.
     • @Documented: JavaDoc 생성 시 어노테이션 정보도 포함하도록 합니다.
     • @Inherited: 부모 클래스의 어노테이션이 자식 클래스에게도 상속되도록 합니다. (@MappedSuperclass와는 다른 개념으로, 주로 클래스 레벨 어노테이션에 적용)

   • 어노테이션 요소 (Annotation Elements/Attributes): 어노테이션 내에 선언된 메소드들입니다. 이 메소드들은 어노테이션 사용자에게 파라미터처럼 값을 전달받을 수 있게 해줍니다. 예를 들어 @Column(nullable = false)에서 nullable이 요소이고 false가 그 값입니다. default 키워드를 사용하여 기본값을 지정할 수 있습니다.

   JPA 어노테이션들은 jakarta.persistence 패키지에 정의되어 있으며, 대부분 @Retention(RetentionPolicy.RUNTIME)으로 설정되어 JPA 프로바이더(예: Hibernate)가 런타임에 이 메타데이터를 읽어 동적으로 SQL을 생성하고 객체-테이블 매핑을 처리합니다.

3. import jakarta.persistence.* 이렇게 모든걸 다 임포트 하면 메모리 최적화는 실패하는거 아냐?

   결론부터 말씀드리면, import jakarta.persistence.*와 같이 와일드카드(*) 임포트를 사용한다고 해서 런타임 메모리 최적화가 직접적으로 실패하거나 불필요한 클래스들이 메모리에 로드되는 것은 아닙니다.

   이유는 다음과 같습니다:

   • 컴파일 타임 처리: import 문은 컴파일러에게 클래스 이름을 찾을 경로를 알려주는 지시어입니다. 와일드카드 임포트는 컴파일러가 해당 패키지 내에서 필요한 클래스를 찾을 수 있도록 하는 편리한 방법일 뿐입니다.
   • 바이트코드: 컴파일이 완료되면, 생성된 바이트코드에는 실제로 코드 내에서 사용된 클래스들에 대한 참조만 포함됩니다. jakarta.persistence.*라고 임포트했더라도, 코드에서 @Entity, @Id 두 개만 사용했다면 바이트코드에는 이 두 클래스에 대한 참조만 들어갑니다. 패키지 내의 사용되지 않은 다른 모든 클래스들은 바이트코드에 포함되지 않습니다.
   • 클래스 로딩: JVM은 클래스가 실제로 필요할 때 (예: 해당 클래스의 객체를 생성하거나 정적 멤버에 접근할 때) 클래스 로더를 통해 메모리에 로드합니다. 와일드카드 임포트 자체가 사용하지 않는 클래스들까지 미리 로드하지는 않습니다.

   하지만 와일드카드 임포트에는 다른 고려사항이 있습니다:

   • 가독성 및 명확성: 어떤 클래스들이 사용되는지 임포트 목록만 보고 명확히 알기 어려워질 수 있습니다. 다른 패키지에 동일한 이름의 클래스가 있을 경우 이름 충돌의 가능성도 (이론적으로는) 존재합니다.
   • 빌드 시간: 아주 많은 클래스가 있는 패키지를 와일드카드로 임포트하고 그중 소수만 사용한다면, 컴파일러가 심볼을 찾는 데 약간의 추가 시간이 소요될 수 있지만, 현대적인 컴파일러에서는 이 영향이 미미합니다.
   • IDE 지원: 현대 IDE들은 사용하지 않는 임포트를 정리해주거나, 명시적 임포트를 자동으로 추가/관리해주는 기능이 잘 되어 있어 개발 편의성과 명확성 사이에서 균형을 잡을 수 있습니다.

   따라서 메모리 최적화 관점에서 와일드카드 임포트는 큰 문제가 되지 않습니다. 주로 코드의 명확성과 팀/회사의 코딩 컨벤션에 따라 사용 여부를 결정합니다. Spring Boot나 많은 라이브러리에서 관례적으로 JPA 어노테이션을 사용할 때 jakarta.persistence.* 와 같이 와일드카드로 임포트하는 경우가 흔합니다.

4. abstract class BaseEntity 로 정의한다음 상속하는 이유는? 그냥 클래스로 만들면 안되는거야?

   BaseEntity를 abstract class로 정의하고 @MappedSuperclass 어노테이션을 붙여 사용하는 주된 이유는 다음과 같습니다:

   • 공통 필드 재사용 및 중복 제거: 여러 엔티티 클래스에서 공통적으로 사용되는 필드들(예: createdAt, updatedAt 같은 생성/수정 시각 정보, createdBy, updatedBy 같은 생성/수정자 정보)을 한 곳에서 정의하고, 이를 상속받는 모든 엔티티가 해당 필드와 매핑 정보를 자동으로 갖도록 하기 위함입니다. 이를 통해 코드 중복을 줄이고 일관성을 유지할 수 있습니다.

   • @MappedSuperclass의 특성:

     • @MappedSuperclass로 지정된 클래스는 그 자체로 엔티티가 아닙니다. 즉, 데이터베이스에 BaseEntity라는 이름의 테이블이 생성되지 않습니다.
     • 이 클래스에 정의된 필드들은 이 클래스를 상속하는 자식 엔티티들의 테이블에 컬럼으로 포함됩니다.
     • JPA의 일반적인 엔티티 상속(@Inheritance 어노테이션 사용)과는 다릅니다. 엔티티 상속은 부모 클래스도 엔티티이거나, 특정 전략(단일 테이블, 조인 테이블 등)에 따라 테이블 구조가 결정됩니다. @MappedSuperclass는 단순히 매핑 정보만 상속합니다.

   • abstract 키워드를 사용하는 이유:

     1. 명확한 의도: BaseEntity는 독립적으로 인스턴스화되어 사용될 목적이 아니라, 오직 다른 엔티티들에게 공통 속성을 제공하기 위한 "템플릿"이나 "부분적인 정의"의 역할을 합니다. abstract 키워드는 이러한 의도를 명확히 나타냅니다. "이 클래스는 직접 객체로 만들 수 없고, 반드시 상속해서 사용해야 한다"는 의미를 부여합니다.
     2. 객체 생성 방지: abstract 클래스는 직접 new BaseEntity()와 같이 인스턴스화할 수 없습니다. @MappedSuperclass의 목적상 BaseEntity 객체를 직접 생성하여 JPA 컨텍스트에서 관리할 필요가 없으므로, abstract로 만들어 실수로라도 직접 인스턴스화하는 것을 막는 것이 좋습니다.

   그냥 클래스로 만들면 안되는거야? (non-abstract class)

   네, 기술적으로 BaseEntity를 abstract가 아닌 일반 클래스로 만들고 @MappedSuperclass를 붙여도 JPA는 동일하게 동작합니다. 즉, 자식 엔티티들은 BaseEntity의 필드들을 상속받아 자신의 테이블에 컬럼으로 갖게 됩니다.

   하지만 이렇게 할 경우:

   • BaseEntity가 일반 클래스이므로 new BaseEntity()로 객체 생성이 가능해집니다. 그러나 이 객체는 JPA 엔티티가 아니므로 영속성 컨텍스트에 의해 관리되거나 데이터베이스에 저장될 수 없습니다. 이러한 객체 생성이 의미가 없고 혼란을 야기할 수 있습니다.
   • 클래스 설계의 의도가 불분명해질 수 있습니다. abstract를 사용하면 "이것은 불완전한 정의이며, 상속을 통해 완성되어야 한다"는 메시지가 명확해집니다.

   따라서 @MappedSuperclass를 사용하는 클래스는 개념적으로나 설계적으로 abstract로 선언하는 것이 더 올바르고 일반적인 관례입니다. 이는 해당 클래스가 독립적인 엔티티가 아니라 공통 매핑 정보를 제공하기 위한 상위 클래스임을 명확히 하기 위함입니다.