메타데이터는 한 마디로 말하면 데이터의 데이터다. 메타데이터는 주로 데이터를 문서화하거나 디자인이나 컴파일 타임, 로딩이나 런타임
시에 원하는 동작을 수행할 수 있도록 하는 데 사용된다. 이런 메타데이터의 활용 방법에 대해서는 다음 부부터 자세히 알아볼
것이다. 여기에서는 자바와 닷넷 진영에서의 메타데이터 활용 기법들이 어떻게 변화되어 왔는지와 각 기법의 특징들에 대해 알아본다.
자바와 닷넷은 태초부터 끝없는 경쟁을 반복해오며 엎치락뒤치락하는 기술들이다. 애당초 닷넷이 자바의 설계를 본 따는데 성공했으며, 그 이후에는 다시 자바가 닷넷을 따라잡는 식이었다. 메타데이터 활용 기술 또한 그렇다.
이번에는 닷넷이 닷넷프레임워크 1.0에서 어트리뷰트라는 기능을 제공하여 개발자들에게 박수를 받았고, 머지않아 자바 또한 어노테이션을 통해 메타데이터 활용 기술을 제공했다. 그렇게 엎치락뒤치락하다가 최근에는 오히려 자바의 어노테이션 기술이 닷넷의 어트리뷰트보다 많이 쓰이는 상황이 되어가고 있다.
어쨌든 개발자 입장에서 두 기술이 끊임없이 경쟁하며 발전하는 것을 바라보는 일은 유쾌한 일이다. 이제 닷넷의 어트리뷰트와 자바의 어노테이션 그리고 그 이전의 메타데이터 활용 기법들에 대해 알아보자.
닷넷프레임워크에서 어트리뷰트 기능을 지원하기 이전에 COM이나 COM+에서도 어트리뷰트와 유사한 기법들이 사용되기는 하였으나, 제대로 된 어트리뷰트를 제공하기 시작한 것은 닷넷 프레임워크 1.0 버전부터다.
닷넷의 어트리뷰트는 기존의 COM+ 기반에서 애플리케이션의 트랜잭션 설정과 풀링 등의 메타데이터를 런타임 시에 활용하던 기존 방법에서 한 단계 발전된 형태의 기법이다.
기존의 COM+ 기법이 어트리뷰트를 별도의 설정 저장소에 저장하는 방법을 사용했었다. 반면에 닷넷프레임워크의 어트리뷰트에서는 어트리뷰트를 프로그램 내에 직접 저장할 수 있다.
빌트인 어트리뷰트
닷넷의 어트리뷰트는 프레임워크에서 기본으로 제공하는 빌트인 어트리뷰트와 사용자가 직접 정의하여 사용할 수 있는 커스텀 어트리뷰트로 나뉜다.
이중에서 빌트인 어트리뷰트는 클래스의 트랜잭션을 선언하는 데 사용하는 어트리뷰트부터 웹서비스 바인딩 정보와 웹 메소드를 매핑하는 데 사용할 수 있는 어트리뷰트까지 다양하다. 빌트인 어트리뷰트의 종류와 이름에 대해서는 특집 4부를 참조하길 바란다.
커스텀 어트리뷰트
어트리뷰트도 하나의 클래스로 취급되기 때문에 개발자가 직접 새로운 어트리뷰트를 생성할 수 있다. 또, 필드나 메소드 등을 가지거나 상속도 가능하다. 커스텀 어트리뷰트는 클래스를 생성할 때와 같은 방법으로 하는데, 이때 어트리뷰트임을 구분해 주기 위해 어트리뷰트 이름 앞에 ‘Attribute’를 추가해 주면 된다.
하드코딩 된 특수한 애플리케이션이 아닌 이상 대부분의 프로그램은 외부에서 설정을 할 수 있는 방법을 선택한다. 고정된 기능은 코드로 제공하되 사용자마다 또는 환경마다 변화가 필요하다면 이를 외부의 설정을 위한 리소스로 독립시키고 이를 빌드 또는 런타임 시 읽어서 활용하는 것 이다.
프로퍼티 파일
자바에서 가장 먼저 사용된 설정방식은 프로퍼티 파일을 이용하는 것이다. 단순한 키와 값의 조합인 자바 프로퍼티 파일은 그 사용이 직관적이고 손쉽게 활용할 수 있다는 장점 때문에 초기에 많이 사용된 방법이다. 하지만 키와 밸류 값만으로 구분되는 일차원적인 구조는 복잡한 설정을 만들기에는 부족하다는 약점을 드러냈다.
한 가지 약점이 더 있었다. 바로 프로퍼티 파일의 값이나 구성을 검증하는 것이 번거롭다는 것이었다. 단순 텍스트 파일이기 때문에 편집을 하다 실수를 하더라도 편리하게 검증해 낼 수 있는 방법이 없었다. 그러니 코딩 중에 자칫 잘못하면 검증하는 데 시간을 빼앗겨 배보다 배꼽이 더 큰 상황들도 생길 수 있었던 것이다.
XML 활용
프로퍼티 파일의 단점을 보완하기 위해 찾아낸 방법은 바로 XML. 강력한 계층형 문서구조와 호환성을 자랑하는 XML이 그 뒤를 잇게 되었다. XML은 텍스트 파일인 프로퍼티 파일과 달리 파서나 에디터 등을 이용하기 때문에 문법에 대한 검증이 쉽다.
더불어 구성내용도 DTD나 스키마(Schema)와 같은 방식을 이용하여 값이나 순서, 필수조건, 타입 등에 대한 검증도 가능해졌다.
자바는 표준 API를 통해서 XML 문서의 작성과 파싱, 검색 등을 지원하기 시작했고 이에 따라 자바로 개발된 설정파일은 당연히 XML로 작성되는 분위기가 조성되었다. 차츰 프로퍼티 파일을 통한 설정만을 지원하던 초기 WAS들은 깔끔한 XML 설정을 지원하는 WAS에 비해서 뒤떨어진 것으로 인식되었다.
분위기가 이렇게 흘러가니 이를 만회하기 위해서 거의 모든 종류의 서버와 프레임워크들이 앞 다퉈 XML형태로 설정을 전환하기 시작했다.
게다가 표준 기술인 엔터프라이즈 서버도 핵심 설정은 모두 XML 포맷을 사용했다. 또 ANT와 같은 빌드 스크립트조차 그 구조로 XML을 택하기까지 했다. 하지만, XML 또한 만능은 아니었다.
처음에는 사람이 눈으로 손쉽게 읽고 편집할 수 있는 텍스트 기반의 깔끔한 문서구조라는 장점을 내세우며 인기몰이를 했던 XML이지만 날로 갈수록 복잡한 문서구조와 장황한 태그의 사용 등으로 인해 점차 직접적인 편집이 어려워지기 시작했다. EJB 설정과 같은 경우 간단한 엔터프라이즈 빈 하나를 사용하기 위해서 길게는 수백 라인의 XML을 작성해야했다.
그야말로 개발자들에게는 지옥이었다. 오죽하면 XML Hell이라고 까지 불렀겠는가. 방대한 태그와 어트리뷰트 구조를 모두 기억하기도 힘들어짐에 따라 XML 설정 파일을 만들고 편집하기 위해서라도 점차로 GUI환경의 설정을 지원하는 IDE의 필요성이 절실히 대두되게 되었다.
● XML 단점에 대한 두 가지 반응
XML의 단점에 대한 반응은 두 가지로 나타났다. 하나는 XML 문서의 설계 자체에 문제가 있다는 시각에서 비롯된 것이었다. 좀 더 간결한 구성과 지능적인 디폴트값의 사용을 내세우는 쪽이다.
하이버네이트와 스프링 같은 오픈소스 프로젝트는 그 설정이 기본적으로 XML을 사용하기는 하지만 기존의 EJB나 스트럿츠와 같은 지저분한 XML이 아닌 꼭 필요한 정보만 간결하게 설정하는 것이 가능하도록 XML문서 구성자체를 발전시켰다. 이로써 굳이 IDE나 상용 툴의 도움을 받지 않고도 설정을 관리해나가는 것이 편리할 수 있다는 것을 보여주었다.
반대로 XML을 버리고 다른 형태의 설정방식을 택하는 부류가 있다. 바로 자바 어노테이션을 이용한 방식과 자바 클래스 자체를 이용한 두 가지 방식이다.
xDoclet
XML과 자바 어노테이션의 사이쯤에서 오픈소스 코드 생성 엔진인 xDoclet이 등장하게 되었다. 자바 소스코드에 메타데이터를 더하여 JavaDoc에 특수한 태구를 추가할 수 있도록 만들어진 xDoclet은 어노테이션이 자바에서 기본으로 제공되고 있는 지금도 많이 쓰이고 있는 기술 중 하나이다.
아직 현업에서는 자바EE5 이전 버전이 많이 쓰이고 있는 탓이다. xDoclet에 대한 좀 더 자세한 내용은 잠시 뒤 CoverStory Plus에서 살펴보자.
자바 어노테이션
자바EE5부터 어노테이션은 자바 표준 언어에 포함되었다. 때문에 안정적인 타입 지원과 클래스의 메타정보와 연계될 수 있다는 장점을 내세워 XML 설정을 굉장히 빠르게 대치해나가고 있다.
어노테이션은 XML이 가지지 못한 간결함과 동시에 설정 내용과 연계되는 클래스나 메소드 등에 직접 삽입되기 때문에 설정과 구현을 긴밀하게 연동해서 볼 수 있다는 장점을 가지고 있다. 또한 별도의 파서를 적용하지 않고도 간단히 런타임 시에 활용할 수 있다는 편리함을 내세우고 있다.
하지만 어노테이션을 반대하는 측의 여러 가지 비판에도 여전히 시달려야 했다. 첫째는 메타정보와 소스의 결합자체를 못마땅해 하는 측이다. 메타데이터는 그 자체로 코드에 독립적이어야 하며 한 곳에 모여져서 애플리케이션의 구성을 한눈에 알 수 있어야 바람직하다는 주장이다.
어노테이션이나 기타 유사한 메타정보 기술은 메타정보가 바뀔 때마다 컴파일을 다시 해 줘야 한다는 단점이 있다. 따라서 소스가 함께 제공되지 않는 제품의 경우에는 어노테이션을 사용하기 어렵다는 것이다.
둘째로 XML이 가지고 있는 막강한 검증기능의 부재다. 코드를 이용해서 검증하는 것이 가능하다고는 하지만 DTD나 스키마를 이용하여 정보 구성을 검증하는 XML에 비하면 훨씬 불편하기 때문이다.
그래서 어노테이션 기반의 설정이 빠르게 인기를 얻고 있음에도 불구하고 여전히 XML 설정을 고집하는 기술과 개발자들이 많다.
자바클래스의 활용
어노테이션이냐 XML이냐를 두고 자바진영이 논쟁을 하고 있는 사이 루비와 같은 동적 스크립트 기반 언어들이 새로운 형식의 설정 모델을 제시하며 등장했다. 그것은 바로 애플리케이션 코드 자체를 설정으로 사용하는 것이다.
스크립트 언어는 별도의 빌드 과정이 없기 때문에 소스코드와 설정용 파일이 구지 구분되지 않아도 된다. 게다가 언어의 문법은 XML보다도 훨씬 강력해서 복잡한 설정구조와 조건 등을 표현해 내기도 훨씬 수월하다.
이런 영향을 받아서인지 자바쪽에서도 자바클래스 자체를 이용한 설정방식이 조금씩 등장하고 있다.
대표적으로 스프링프레임워크의 서브프로젝트인 스프링 자바콘피그(Spring JavaConfig)가 있다. 스프링 자바콘피그는 스프링의 창설자인 로드 존슨(Rod Johnson)의 아이디어에서 출발하여 최근 개발되고 있는 기술이다. 이 기술은 스프링의 빈 설정을 XML이나 어노테이션이 아닌 자바 코드자체를 통해서 제공하는 기능을 가지고 있다.
이렇게 설정용 파일이 아닌 프로그램 코드 자체를 통해서 설정하는 방식이 본격적으로 등장하기 시작하면 앞으로는 아마 XML과 어노테이션, 자바코드 또는 별도의 스크립트 언어코드를 이용한 설정방식의 3파전이 시작될지도 모르겠다. @
* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.
출처 : ZDNet Korea
자바와 닷넷은 태초부터 끝없는 경쟁을 반복해오며 엎치락뒤치락하는 기술들이다. 애당초 닷넷이 자바의 설계를 본 따는데 성공했으며, 그 이후에는 다시 자바가 닷넷을 따라잡는 식이었다. 메타데이터 활용 기술 또한 그렇다.
이번에는 닷넷이 닷넷프레임워크 1.0에서 어트리뷰트라는 기능을 제공하여 개발자들에게 박수를 받았고, 머지않아 자바 또한 어노테이션을 통해 메타데이터 활용 기술을 제공했다. 그렇게 엎치락뒤치락하다가 최근에는 오히려 자바의 어노테이션 기술이 닷넷의 어트리뷰트보다 많이 쓰이는 상황이 되어가고 있다.
어쨌든 개발자 입장에서 두 기술이 끊임없이 경쟁하며 발전하는 것을 바라보는 일은 유쾌한 일이다. 이제 닷넷의 어트리뷰트와 자바의 어노테이션 그리고 그 이전의 메타데이터 활용 기법들에 대해 알아보자.
 | 닷넷의 어트리뷰트 프로그래밍 |  |
닷넷프레임워크에서 어트리뷰트 기능을 지원하기 이전에 COM이나 COM+에서도 어트리뷰트와 유사한 기법들이 사용되기는 하였으나, 제대로 된 어트리뷰트를 제공하기 시작한 것은 닷넷 프레임워크 1.0 버전부터다.
닷넷의 어트리뷰트는 기존의 COM+ 기반에서 애플리케이션의 트랜잭션 설정과 풀링 등의 메타데이터를 런타임 시에 활용하던 기존 방법에서 한 단계 발전된 형태의 기법이다.
기존의 COM+ 기법이 어트리뷰트를 별도의 설정 저장소에 저장하는 방법을 사용했었다. 반면에 닷넷프레임워크의 어트리뷰트에서는 어트리뷰트를 프로그램 내에 직접 저장할 수 있다.
빌트인 어트리뷰트
닷넷의 어트리뷰트는 프레임워크에서 기본으로 제공하는 빌트인 어트리뷰트와 사용자가 직접 정의하여 사용할 수 있는 커스텀 어트리뷰트로 나뉜다.
이중에서 빌트인 어트리뷰트는 클래스의 트랜잭션을 선언하는 데 사용하는 어트리뷰트부터 웹서비스 바인딩 정보와 웹 메소드를 매핑하는 데 사용할 수 있는 어트리뷰트까지 다양하다. 빌트인 어트리뷰트의 종류와 이름에 대해서는 특집 4부를 참조하길 바란다.
커스텀 어트리뷰트
어트리뷰트도 하나의 클래스로 취급되기 때문에 개발자가 직접 새로운 어트리뷰트를 생성할 수 있다. 또, 필드나 메소드 등을 가지거나 상속도 가능하다. 커스텀 어트리뷰트는 클래스를 생성할 때와 같은 방법으로 하는데, 이때 어트리뷰트임을 구분해 주기 위해 어트리뷰트 이름 앞에 ‘Attribute’를 추가해 주면 된다.
| 자바 어노테이션의 탄생 | |
하드코딩 된 특수한 애플리케이션이 아닌 이상 대부분의 프로그램은 외부에서 설정을 할 수 있는 방법을 선택한다. 고정된 기능은 코드로 제공하되 사용자마다 또는 환경마다 변화가 필요하다면 이를 외부의 설정을 위한 리소스로 독립시키고 이를 빌드 또는 런타임 시 읽어서 활용하는 것 이다.
프로퍼티 파일
자바에서 가장 먼저 사용된 설정방식은 프로퍼티 파일을 이용하는 것이다. 단순한 키와 값의 조합인 자바 프로퍼티 파일은 그 사용이 직관적이고 손쉽게 활용할 수 있다는 장점 때문에 초기에 많이 사용된 방법이다. 하지만 키와 밸류 값만으로 구분되는 일차원적인 구조는 복잡한 설정을 만들기에는 부족하다는 약점을 드러냈다.
한 가지 약점이 더 있었다. 바로 프로퍼티 파일의 값이나 구성을 검증하는 것이 번거롭다는 것이었다. 단순 텍스트 파일이기 때문에 편집을 하다 실수를 하더라도 편리하게 검증해 낼 수 있는 방법이 없었다. 그러니 코딩 중에 자칫 잘못하면 검증하는 데 시간을 빼앗겨 배보다 배꼽이 더 큰 상황들도 생길 수 있었던 것이다.
XML 활용
프로퍼티 파일의 단점을 보완하기 위해 찾아낸 방법은 바로 XML. 강력한 계층형 문서구조와 호환성을 자랑하는 XML이 그 뒤를 잇게 되었다. XML은 텍스트 파일인 프로퍼티 파일과 달리 파서나 에디터 등을 이용하기 때문에 문법에 대한 검증이 쉽다.
더불어 구성내용도 DTD나 스키마(Schema)와 같은 방식을 이용하여 값이나 순서, 필수조건, 타입 등에 대한 검증도 가능해졌다.
자바는 표준 API를 통해서 XML 문서의 작성과 파싱, 검색 등을 지원하기 시작했고 이에 따라 자바로 개발된 설정파일은 당연히 XML로 작성되는 분위기가 조성되었다. 차츰 프로퍼티 파일을 통한 설정만을 지원하던 초기 WAS들은 깔끔한 XML 설정을 지원하는 WAS에 비해서 뒤떨어진 것으로 인식되었다.
분위기가 이렇게 흘러가니 이를 만회하기 위해서 거의 모든 종류의 서버와 프레임워크들이 앞 다퉈 XML형태로 설정을 전환하기 시작했다.
게다가 표준 기술인 엔터프라이즈 서버도 핵심 설정은 모두 XML 포맷을 사용했다. 또 ANT와 같은 빌드 스크립트조차 그 구조로 XML을 택하기까지 했다. 하지만, XML 또한 만능은 아니었다.
처음에는 사람이 눈으로 손쉽게 읽고 편집할 수 있는 텍스트 기반의 깔끔한 문서구조라는 장점을 내세우며 인기몰이를 했던 XML이지만 날로 갈수록 복잡한 문서구조와 장황한 태그의 사용 등으로 인해 점차 직접적인 편집이 어려워지기 시작했다. EJB 설정과 같은 경우 간단한 엔터프라이즈 빈 하나를 사용하기 위해서 길게는 수백 라인의 XML을 작성해야했다.
그야말로 개발자들에게는 지옥이었다. 오죽하면 XML Hell이라고 까지 불렀겠는가. 방대한 태그와 어트리뷰트 구조를 모두 기억하기도 힘들어짐에 따라 XML 설정 파일을 만들고 편집하기 위해서라도 점차로 GUI환경의 설정을 지원하는 IDE의 필요성이 절실히 대두되게 되었다.
● XML 단점에 대한 두 가지 반응
XML의 단점에 대한 반응은 두 가지로 나타났다. 하나는 XML 문서의 설계 자체에 문제가 있다는 시각에서 비롯된 것이었다. 좀 더 간결한 구성과 지능적인 디폴트값의 사용을 내세우는 쪽이다.
하이버네이트와 스프링 같은 오픈소스 프로젝트는 그 설정이 기본적으로 XML을 사용하기는 하지만 기존의 EJB나 스트럿츠와 같은 지저분한 XML이 아닌 꼭 필요한 정보만 간결하게 설정하는 것이 가능하도록 XML문서 구성자체를 발전시켰다. 이로써 굳이 IDE나 상용 툴의 도움을 받지 않고도 설정을 관리해나가는 것이 편리할 수 있다는 것을 보여주었다.
반대로 XML을 버리고 다른 형태의 설정방식을 택하는 부류가 있다. 바로 자바 어노테이션을 이용한 방식과 자바 클래스 자체를 이용한 두 가지 방식이다.
xDoclet
XML과 자바 어노테이션의 사이쯤에서 오픈소스 코드 생성 엔진인 xDoclet이 등장하게 되었다. 자바 소스코드에 메타데이터를 더하여 JavaDoc에 특수한 태구를 추가할 수 있도록 만들어진 xDoclet은 어노테이션이 자바에서 기본으로 제공되고 있는 지금도 많이 쓰이고 있는 기술 중 하나이다.
아직 현업에서는 자바EE5 이전 버전이 많이 쓰이고 있는 탓이다. xDoclet에 대한 좀 더 자세한 내용은 잠시 뒤 CoverStory Plus에서 살펴보자.
자바 어노테이션
자바EE5부터 어노테이션은 자바 표준 언어에 포함되었다. 때문에 안정적인 타입 지원과 클래스의 메타정보와 연계될 수 있다는 장점을 내세워 XML 설정을 굉장히 빠르게 대치해나가고 있다.
어노테이션은 XML이 가지지 못한 간결함과 동시에 설정 내용과 연계되는 클래스나 메소드 등에 직접 삽입되기 때문에 설정과 구현을 긴밀하게 연동해서 볼 수 있다는 장점을 가지고 있다. 또한 별도의 파서를 적용하지 않고도 간단히 런타임 시에 활용할 수 있다는 편리함을 내세우고 있다.
하지만 어노테이션을 반대하는 측의 여러 가지 비판에도 여전히 시달려야 했다. 첫째는 메타정보와 소스의 결합자체를 못마땅해 하는 측이다. 메타데이터는 그 자체로 코드에 독립적이어야 하며 한 곳에 모여져서 애플리케이션의 구성을 한눈에 알 수 있어야 바람직하다는 주장이다.
어노테이션이나 기타 유사한 메타정보 기술은 메타정보가 바뀔 때마다 컴파일을 다시 해 줘야 한다는 단점이 있다. 따라서 소스가 함께 제공되지 않는 제품의 경우에는 어노테이션을 사용하기 어렵다는 것이다.
둘째로 XML이 가지고 있는 막강한 검증기능의 부재다. 코드를 이용해서 검증하는 것이 가능하다고는 하지만 DTD나 스키마를 이용하여 정보 구성을 검증하는 XML에 비하면 훨씬 불편하기 때문이다.
그래서 어노테이션 기반의 설정이 빠르게 인기를 얻고 있음에도 불구하고 여전히 XML 설정을 고집하는 기술과 개발자들이 많다.
자바클래스의 활용
어노테이션이냐 XML이냐를 두고 자바진영이 논쟁을 하고 있는 사이 루비와 같은 동적 스크립트 기반 언어들이 새로운 형식의 설정 모델을 제시하며 등장했다. 그것은 바로 애플리케이션 코드 자체를 설정으로 사용하는 것이다.
스크립트 언어는 별도의 빌드 과정이 없기 때문에 소스코드와 설정용 파일이 구지 구분되지 않아도 된다. 게다가 언어의 문법은 XML보다도 훨씬 강력해서 복잡한 설정구조와 조건 등을 표현해 내기도 훨씬 수월하다.
이런 영향을 받아서인지 자바쪽에서도 자바클래스 자체를 이용한 설정방식이 조금씩 등장하고 있다.
대표적으로 스프링프레임워크의 서브프로젝트인 스프링 자바콘피그(Spring JavaConfig)가 있다. 스프링 자바콘피그는 스프링의 창설자인 로드 존슨(Rod Johnson)의 아이디어에서 출발하여 최근 개발되고 있는 기술이다. 이 기술은 스프링의 빈 설정을 XML이나 어노테이션이 아닌 자바 코드자체를 통해서 제공하는 기능을 가지고 있다.
이렇게 설정용 파일이 아닌 프로그램 코드 자체를 통해서 설정하는 방식이 본격적으로 등장하기 시작하면 앞으로는 아마 XML과 어노테이션, 자바코드 또는 별도의 스크립트 언어코드를 이용한 설정방식의 3파전이 시작될지도 모르겠다. @
| |||||||||||||||
| |||||||||||||||
|
* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.
출처 : ZDNet Korea
'Development' 카테고리의 다른 글
| 현장에서 마주칠 수 있는 10가지 타입의 프로그래머 (1) | 2008.01.02 |
|---|---|
| Trac을 Windows에서 쉽게 설치하여 사용하기 (3) | 2007.12.18 |
| 개인정보 취급방침 (1) | 2007.11.20 |
| Windows Dll 파일 설명 (34) | 2007.11.19 |
| [프로그래밍 최적화 ⑤] 임베디드 프로그래밍 최적화 기법 (0) | 2007.11.15 |