모든 애노테이션은 기본적으로 Annotation 인터페이스를 확장하며, 이로 인해 자바에서 애노테이션은 특별한 형태의 인터페이스로 간주된다. 하지만 자바에서 애노테이션을 정의할 때, 개발자가 명시적으로 Annotation 인터페이스를 상속하거나 구현할 필요는 없다. 애노테이션을 @interface 키워드를 통해 정의하면, 자바 컴파일러가 자동으로Annotation 인터페이스를 확장하도록 처리해준다.
애노테이션과 상속
애노테이션은 다른 애노테이션이나 인터페이스를 직접 상속할 수 없다.
오직 java.lang.annotation.Annotation 인터페이스만 상속한다.
따라서, 애노테이션 사이에는 사실상 상속이라는 개념이 존재하지 않는다.
@Inherited
애노테이션을 정의할 때 @Inherited 메타 애노테이션을 붙이면, 애노테이션을 적용한 클래스의 자식도 해당 애노테이션을 부여 받을 수 있다.
단 주의할 점으로 이 기능은 클래스 상속에서만 작동하고, 인터페이스의 구현체에는 적용되지 않는다.
@Inherited 가 클래스 상속에만 적영되는 이유
1. 클래스 상속과 인터페이스 구현의 차이
클래스 상속은 자식 클래스가 부모 클래스의 속성과 메서드를 상속받는 개념이다. 즉, 자식 클래스는 부모 클래스의 특성을 이어받으므로, 부모 클래스에 정의된 애노테이션을 자식 클래스가 자동으로 상속받을 수 있는 논리적 기반이 있다.
그에 반해, 인터페이스는 메서드의 시그니처만을 정의할 뿐, 상태나 행위를 가지지 않기 때문에, 인터페이스의 구현체가 애노테이션을 상속한다는 개념이 잘 맞지 않는다.
2. 인터페이스와 다중 구현, 다이아몬드 문제
인터페이스는 다중 구현이 가능하다. 만약 인터페이스의 애노테이션을 구현 클래스에서 상속하게 되면 여러 인터페이스의 애노테이션 간의 충돌이나 모호한 상황이 발생할 수 있다.
이제 애노테이션의 기본적인 내용들은 모두 알아보았다. 이런 애노테이션을 어떻게 잘 활용할 수 있는지 예제를 통해 알아보자.
애노테이션 활용 - 검증기
각종 클래스의 정보들을 검증(validation) 하는 기능을 만들어보자.
package annotation.validator;
public class Team {
private String name;
private int memberCount;
public Team(String name, int memberCount) {
this.name = name;
this.memberCount = memberCount;
}
public String getName() {
return name;
}
public int getMemberCount() {
return memberCount;
}
}
package annotation.validator;
public class User {
private String name;
private int age;
public User(String name, int age) {
this.name = name;
this.age = age;
}
public String getName() {
return name;
}
public int getAge() {
return age;
}
}
package annotation.validator;
import static util.MyLogger.log;
public class ValidatorV1Main {
public static void main(String[] args) {
User user = new User("user1", 0);
Team team = new Team("", 0);
try {
log("== user 검증 ==");
validateUser(user);
} catch (Exception e) {
log(e);
}
try {
log("== team 검증 ==");
validateTeam(team);
} catch (Exception e) {
log(e);
}
}
private static void validateUser(User user) {
if (user.getName() == null || user.getName().isEmpty()) {
throw new RuntimeException("이름이 비었습니다.");
}
if (user.getAge() < 1 || user.getAge() > 100) {
throw new RuntimeException("나이는 1과 100 사이여야 합니다.");
}
}
private static void validateTeam(Team team) {
if (team.getName() == null || team.getName().isEmpty()) {
throw new RuntimeException("이름이 비었습니다.");
}
if (team.getMemberCount() < 1 || team.getMemberCount() > 100) {
throw new RuntimeException("회원수는 1과 100 사이여야 합니다.");
}
}
}
User 객체의 이름과 나이를 검증한다.
Team 객체의 이름과 나이를 검증한다.
여기서는 값이 비었는지 검증하는 부분과 숫자의 범위를 검증하는 2가지 부분이 있다.
코드를 잘 보면 뭔가 비슷한 것 같으면서도 User, Team 이 서로 완전히 다른 클래스이기 때문에 재사용이 어렵다.
그리고 각각의 필드 이름도 서로 다르고, 오류 메시지도 다르다. 그리고 검증해야 할 값의 범위도 다르다.
이후에 다른 객체들도 검증해야 한다면 비슷한 검증 기능을 계속 추가해야 한다.
이런 문제를 애노테이션을 사용해서 해결해보자.
package annotation.validator;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Range {
int min();
int max();
String message() default "범위를 넘었습니다.";
}
User, Team 에 검증용 애노테이션 추가
package annotation.validator;
public class User {
@NotEmpty(message = "이름이 비었습니다.")
private String name;
@Range(min = 1, max = 100, message = "나이는 1과 100 사이여야 합니다.")
private int age;
public User(String name, int age) {
this.name = name;
this.age = age;
}
public String getName() {
return name;
}
public int getAge() {
return age;
}
}
package annotation.validator;
public class Team {
@NotEmpty(message = "이름이 비었습니다.")
private String name;
@Range(min = 1, max = 999, message = "회원수는 1과 999 사이여야 합니다.")
private int memberCount;
public Team(String name, int memberCount) {
this.name = name;
this.memberCount = memberCount;
}
public String getName() {
return name;
}
public int getMemberCount() {
return memberCount;
}
}
검증기 추가 개발
package annotation.validator;
import java.lang.reflect.Field;
public class Validator {
// team, user
public static void validate(Object obj) throws Exception{
Field[] fields = obj.getClass().getDeclaredFields();
for (Field field : fields) {
field.setAccessible(true);
if (field.isAnnotationPresent(NotEmpty.class)) {
String value = (String)field.get(obj);
NotEmpty annotation = field.getAnnotation(NotEmpty.class);
if (value == null || value.isEmpty()) {
throw new RuntimeException(annotation.message());
}
}
if (field.isAnnotationPresent(Range.class)) {
long value = field.getLong(obj);
Range annotation = field.getAnnotation(Range.class);
if (value < annotation.min() || value > annotation.max()) {
throw new RuntimeException(annotation.message());
}
}
}
}
}
package annotation.validator;
import static util.MyLogger.log;
public class ValidatorV2Main {
public static void main(String[] args) {
User user = new User("user1", 0);
Team team = new Team("teamA", 0);
try {
log("== user 검증 ==");
Validator.validate(user);
} catch (Exception e) {
log(e);
}
try {
log("== team 검증 ==");
Validator.validate(team);
} catch (Exception e) {
log(e);
}
}
}
자바 기본 애노테이션
@Override, @Deprecated, @SuppressWarnings와 같이 자바 언어가 기본으로 제공하는 애노테이션도 있다.
참고로 앞서 설명한 @Retention, @Target도 자바 언어가 기본으로 제공하는 애노테이션이지만, 이것은 애노테이션 자체를 정의하기 위한 메타 애노테이션이고, 지금 설명한 내용은 코드에 직접 사용하는 애노테이션이다.
@Override
package java.lang;
import java.lang.annotation.*;
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.SOURCE) // 컴파일 시점에만 사용하는 애노테이션이다.
public @interface Override {
}
메서드 재정의가 정확하게 잘 정의되었는지 컴파일러가 체크하는데 사용한다.
@Override 애노테이션을 사용하면 자바 컴파일러가 메서드 재정의 여부를 체크해준다. 만약 문제가 있다면 컴파일을 통과하지 않는다.
@Deprecated
@Deprecated 는 더 이상 사용되지 않는다는 뜻이다. 이 애노테이션이 적용된 기능은 사용을 권장하지 않는다.
deprecation: 사용이 권장되지 않는(deprecated) 코드를 사용할 때 발생하는 경고를 억제
unchecked: 제네릭 타입과 관련된 unchecked 경고를 억제
serial: Serializable 인터페이스를 구현할 때 serialVersionUID 필드를 선언하지 않은 경우 발생하는 경고를 억제
rawtypes: 제네릭 타입이 명시되지 않은(raw) 타입을 사용할 때 발생하는 경고를 억제
unused: 사용되지 않는 변수, 메서드, 필드 등을 선언했을 때 발생하는 경고를 억제
정리
자바 백엔드 개발자가 되려면 스프링, JPA 같은 기술은 필수로 배워야 한다. 그런데 처음 스프링이나 JPA 같은 기술을 배우면, 기존에 자바 문법으로는 잘 이해가 안되는 마법 같은 일들이 벌어진다.
이러한 프레임워크들은 리플렉션과 애노테이션을 활용하여 다음의 "마법 같은" 기능들을 제공한다
의존성 주입 (Dependency Injection): 스프링은 리플렉션을 사용하여 객체의 필드나 생성자에 자동으로 의존성을 주입한다. 개발자는 단순히 @Autowired 애노테이션만 붙이면 된다.
ORM (Object-Relational Mapping): JPA는 애노테이션을 사용하여 자바 객체와 데이터베이스 테이블 간의 매핑을 정의한다. 예를 들어, @Entity , @Table , @Column 등의 애노테이션으로 객체-테이블 관계를 설정한다.
AOP (Aspect-Oriented Programming): 스프링은 리플렉션을 사용하여 런타임에 코드를 동적으로 주입하고, @Aspect, @Before, @After 등의 애노테이션으로 관점 지향 프로그래밍을 구현한다.
설정의 자동화: @Configuration, @Bean 등의 애노테이션을 사용하여 다양한 설정을 편리하게 적용한다.
트랜잭션 관리: @Transactional 애노테이션만으로 메서드 레벨의 DB 트랜잭션 처리가 가능해진다.
이러한 기능들은 개발자가 비즈니스 로직에 집중할 수 있게 해주며, 보일러플레이트(지루한 반복) 코드를 크게 줄여준다.
하지만 이 "마법"의 이면에는 리플렉션과 애노테이션을 활용한 복잡한 메타프로그래밍이 숨어 있다.프레임워크의 동작 원리를 깊이 이해하기 위해서는 리플렉션과 애노테이션에 대한 이해가 필수다. 이를 통해 프레임워크가 제공하는 편의성과 그 이면의 복잡성 사이의 균형을 잡을 수 있으며, 필요에 따라 프레임워크를 효과적으로 커스터마이징하거나 최적화할 수 있게 된다.
스프링이나 JPA 같은 프레임워크들은 이번에 학습한 리플렉션과 애노테이션을 극대화해서 사용한다. 리플렉션과 애노테이션을 배운 덕분에 여러분은 이런 기술이 마법이 아니라, 리플렉션과 애노테이션을 활용한 고급 프로그래밍 기법이라는 것을 이해할 수 있을 것이다. 그리고 이러한 이해를 바탕으로, 프레임워크의 동작 원리를 더 깊이파악하고 효과적으로 활용할 수 있게 될 것이다.
결론적으로, 자바 백엔드 개발자가 되기 위해 스프링과 JPA를 배우는 과정에서 리플렉션과 애노테이션은 더 이상 어렵고 낯선 개념이 아니라, 프레임워크의 동작 원리를 이해하고 활용하는 데 필수적인 도구임을 알게 될 것이다. 이러한 도구들을 잘 활용하면 개발자로서 한 단계 더 성장하게 될 것이며, 복잡한 문제 상황도 잘 해결할 수 있는 강력한 무기를 얻게 될 것이다.
