애노테이션은 애물단지다. 사용하기 편리해보이는 듯 하지만 이를 이용하도록 라이브러리나 프레임워크를 만든다면, 일반적인 자바의 타입 구조를 활용해서 만드는 것보다 몇배의 수고가 들어간다. 애노테이션은 타입 정보가 아니기 때문에 정보를 읽고 활용하려면 리플렉션 API를 사용해야 한다. 게다가 상속이나 구현을 통해서 정보가 전이되지도 않는다. 메타 애노테이션도 마찬가지다.

애노테이션을 이용해서 코드를 작성하도록 뭔가 만들어보려면 그래서 이런 애노테이션의 제약에 일정한 관례를 부여해야 한다.

스프링을 보자면,

컴포넌트 스캔에서는  클래스의 메타 애노테이션을 모두 뒤져서 @Component가 어느 단계라도 존재하면 빈 후보로 선택한다. 그래서 @Configuration만 달아도 스캔된다. @Configuration 애노테이션의 정의를 보면

@Component
public @interface Configuration {

처럼 @Component가 메타 애노테이션으로 달렸으니까.

그런데 메타 애노테이션에 뭔가 존재한다고 이게 자동으로 애노테이션에 상속되는 것이 아니니, 메타 애노테이션에 뭔가 있는지 알려면 리플렉션을 이용해서 계속 뒤져야 한다.  클래스와 인터페이스로 계층구조를 만들어면 타입정보가 상속되기 때문에 손쉽게 타입 체크를 하거나 다형성을 활용할 수 있는 것과 대조된다. 게다가 정해진 규칙도 없으니 만든 사람이 정한 규칙을 모르면 헷갈린다.

그래서 Josh Bloch은 인터페이스로 타입 정보를 넣을 수 있는데다 애노테이션을 사용하지 말라고 이펙 자바 2에서 경고하기도 했다.

또 다른 문제는 수퍼 메소드나 수퍼 클래스, 인터페이스 등에 붙은 애노테이션 정보가 자신에게도 적용되냐 이거다. 당연히 애노테이션에는 상속 개념이 없으니 될지 안될지는 그걸 활용하는 프레임워크나 라이브러리 개발자가 어떤 식으로 애토네이션 정보를 찾아가느냐에 달렸다. 수퍼에 있으면 상속을 하는지, 서브에도 달렸으면 오버라드를 하는지, 결합해서 새로운 조합을 만드는지, 에러를 내는지 등등은 순전히 개발자 맘이다.

@Transactional이나 @RequestMapping등을 생각해보면 될 것이다. @Transactional에 대체(fallback) 룰이 적용되는 것이지 @RM에서 상속시 서브 메소드/타입의 애노테이션 정보가 수퍼 것을 오버라이드하는지 어쩌고의 여부는 토스3 같은 쓸데 없어 보이는 것까지 다 다루는 하드코어 스프링 책을 보지 않으면 알기 쉽지 않을 것이다.

애노테이션에는 일관성도 없고 사용방식도 멋대로기 때문에 상당히 불편하다. API Doc을 종일 들여다 보면서 개발해야 실수 하지 않고 겨우 개발이 가능한 위험한 라이브러리를 다루는 느낌이다.

그래도 타입 정보를 이용하기 보다는 관례와 대충대충을 사랑하는 개발자들의 입맛에 잘 맞게 때문에 계속 사용될 듯 하다. 자바 코드는 무늬만 놔두고 애노테이션만 왕창 넣어서 사용하는 프로그래밍 방법이 나올지도 모르겠다. 요즘 작성하는 하이버네이트 엔티티 클래스에선 애노테이션이 나머지 코드보다 양이 많다. Lombok으로 G/S까지 없앴으니 필드 뿐인데 거기에 관계 정보, 매핑 정보, 스키마 정보, 검증 정보 등의 코드와 XML등을 대체해준다는 각종 메타 정보가 듬뿍 달라 붙는다.

애노테이션은 이제 DSL로 사용되는 것 같다.  새로운 애노테이션 종류가 나오면 새로운 언어를 익히는 마음으로 문법과 용법(usage) 등을 익혀야 할 것이다.

내가 애노테이션 정보를 직접 가져와 사용할 필요가 있을 때는 스프링에 있는 AnnotationUtils의 findAnnotation() 메소드를 애용한다. 이 메소드는 @RequestMapping을 비롯한 여러 애노테이션을 다룰 때 사용된다. 메소드/타입 정보와 애노테이션을 파라미터로 받아서 메소드/타입에 해당 애노테이션이 있는지 찾아 있으면 그 정보를 돌려준다. 없으면 수퍼 타입/메소드에 애노테이션이 있는지 Object까지 올라가면서 몽땅 뒤진다.

그래서 이 findAnnotation()을 사용해서 애노테이션 정보를 다루는 기능은 수퍼 클래스/메소드에 동일한 타입의 애노테이션이 있는 경우 마치 오버라이딩한 것처럼 보인다. 수퍼에만 있으면 그걸 사용하는데 서브에도 또 있으면 먼저 발견하니까 수퍼는 그냥 무시하기 때문에 그렇게 보일 뿐이지 상속되는 거나 오버라이드 되는 건 아니다.

대충 스프링에는 이런 오버라이딩 비스무리한 관계가 있지만 모든 애노테이션에 대해서 다 그렇다고 볼 수는 없고, 애노테이션 정보를 메소드와 타입 레벨의 것을 조합되서 사용되기도 하고, 조합했을 때 OR로 하기도 하고 AND로 하기도 하고, 모든 가능한 조합을 다 만들기도 하고, 한쪽을 배제하고 다른 쪽의 정보를 우선하기도 한다. 꼼꼼하게 애노테이션을 이용하는 프레임워크가 아니면 잘못 사용해도 에러를 내지도 않는다. 아무튼 애물단지다.

오늘의 결론은 "애노테이션을 사용하도록 프레임워크나 라이브리를 만드는 개발자들은 애노테이션 사용 방법에 대해서 문서 좀 제대로 만들란 말이야!"

맨날 소스 뒤져가며 어떻게 사용해야 할지 찾기 정말 피곤해.

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha