주요글: 도커 시작하기
Properties 클래스를 사용하여 다양한 종류의 어플리케이션에서 손쉽게 사용할 수 있는 범용적인 Configuration 클래스를 구현해본다.

설정 시스템은 왜 필요한가?

대부분의 어플리케이션은 올바르게 실행하기 위해서 몇 가지 설정을 해 주어야 한다. 예를 들어, 웹 서버를 개발할 경우 다음과 같은 질문에 답할 수 있어야 한다.

  • 몇 번 포트를 사용할 것인가? 80 포트? 또는 8080 포트? 아니면 그 외 다른 포트?
  • 웹 문서의 루트는 어느 디렉토리를 사용할 것인가?
  • 기본 문서를 index.html로 할 것인가? 또는 index.htm으로 할 것인가?
물론, 이 세 가지 질문 이외에 다른 많은 질문들이 떠오를 것이다. 여기서 이러한 질문을 던지는 주체는 바로 웹 서버 프로그램이다. 왜냐면, 웹 서버를 실행하기 위해서는 위와 관련된 정보를 반드시 알고 있어야 하기 때문이다. 그렇다면, 여러분은 웹 서버 프로그램에 위 질문에 대한 답을 제공할 수 있어야 한다. 가장 첫번째로 사용할 수 있는 방법은 다음과 같이 프로그램 코드에 직접 위 질문과 관련된 부분을 삽입하는 것이다.

public void run() {
   server = new ServerSocket(80);
   while(true) {
      socket = server.accept();
      new ProcessClient(socket).start();
   }
   .....
}

class ProcessClient implement Thread {
   private String documentRoot = "/user/madvirus/webroot";
   private String[] defaultDocument = new String[] { "index.html", "index.htm" };
   
   public void run() {
      ...
   }
}

이와 같은 방법의 장점은 프로그래밍하기가 매우 쉽다는 점이다. 하지만, 단점이 장점보다는 더 크다. 가장 큰 단점은, 포트 번호나 문서의 루트 디렉토리와 같은 설정 정보를 변경하기 위해서는 소스 코드를 재컴파일해야 한다는 점이다. 여기서 발생되는 또 다른 문제점은 개발시와 배포시에 사용되는 환경이 다르기 때문에, 배포시에 다시 한번 더 소스 코드를 재컴파일해야 하는 과정을 밟아야 한다는 점이다. 이것뿐만이 아니다. 일단 배포가 완전히 이루어졌다고 해도, 실제 어플리케이션을 사용하는 도중에 설정 값을 바꿔야 할 때가 있다. 이러한 경우, 최종 사용자들은 설정할 수 있는 방법이 없으므로, 개발자가 일일이 변경을 해 주어야 한다. 이는 매우 귀찮은 일이 될 수 있다.

이러한 단점을 없애기 위해서 많이 사용되는 방법중의 하나가 바로 설정 파일을 작성하는 것이다. 예를 들어, 아파치 웹 서버의 경우 다음과 같은 형태의 설정 파일을 사용하고 있다.

Port 80
ServerAdmin root@localhost

# ServerRoot: The directory the server's config, error, and log files
# are kept in.
ServerRoot /etc/httpd

# ErrorLog: The location of the error log file. If this does not start
# with /, ServerRoot is prepended to it.
ErrorLog logs/error_log

여기서, 아파치 웹 서버 관리자는 단순히 설정 파일의 특정한 값을 변경하고, 웹 서버를 재가동함으로써 변경된 값을 적용할 수 있다. 예를 들어, 포트 번호를 8080으로 변경하고자 할 경우 위의 Port 다음에 있는 80을 8080으로 변경한 후, 웹 서버를 재가동하면 된다. 여기서 '#'은 주석을 의미하며, 아파치 웹 서버는 '#'으로 시작되는 줄은 분석하지 않는다.

소스 코드에 직접적으로 입력하는 것에 비해서 상당히 진보된 형태임을 알 수 있다. 이 글에서는 java.util 패키지의 Properties 클래스를 사용하여 위와 비슷한 형태의 설정 파일로부터 설정 정보를 읽어오는 클래스인 Configuration 클래스를 작성할 것이다. 이 클래스를 사용함으로써 여러분은 좀 더 손쉽게 어플리케이션에 '설정가능한(configurable) 환경'을 제공할 수 있을 것이다.

설정파일의 형태

먼저 살펴볼 내용은 어플리케이션에서 사용할 설정 파일이다. Configuration 클래스가 인식할 수 있는 설정파일의 형태는 다음과 같다.

# 주석으로 처리되는 줄
key1=value1
key2=value2
.....

각각의 프로퍼티는 'key1=value1'의 형태로 저장된다. 여기서 등호(=)의 왼쪽에 있는 key1은 프로퍼티의 키에 해당하며 value1은 프로퍼티의 값에 해당한다. 아파치 웹 서버의 설정 파일과 마찬가지로 '#'으로 시작되는 줄은 주석으로 처리한다. 웹 서버를 위한 설정 파일의 경우 다음과 같은 형태를 지닐 것이다.

# 웹 서버가 사용할 포트 번호
webserver.port=8080

# 문서의 루트 디렉토리
webserver.root_directory=/home/madvirus/webroot/

# 기본적으로 읽어올 문서
webserver.default_document=index.html,index.htm

단지 웹 서버 뿐만 아니라 여러 곳에서 이러한 형태의 설정 파일을 손쉽게 사용할 수 있을 것이다. 예를 들면, 데이터베이스 커넥션 풀에서 사용할 JDBC 드라이버의 종류라든가 최대로 열수 있는 Connection의 개수 등을 이 설정 파일에서 지정할 수 있을 것이다. 위에서 예로든 설정 파일의 webserver.port=8080 부분을 보면 프로퍼티의 값이 문자열 뿐만 아니라 숫자가 될 수 있다는 것을 알 수 있다. 따라서, 우리가 작성할 Configuration 클래스는 String 타입 뿐만 아니라, int, double, boolean과 같은 타입을 처리할 수 있어야 한다.

java.util.Properties 클래스와 Config 인터페이스

이제 Configuration 클래스에서 핵심적인 역할을 하는 java.util 패키지에 있는 Properties 클래스에 대해서 알아보도록 하자. Properties 클래스는 프로퍼티의 지속적인(persistent) 집합을 나타내며, 프로퍼티의 목록을 스트림으로 저장되거나 스트림으로부터 읽어올 수 있다. java.util.Hashtable 클래스를 상속하고 있기 때문에 각각의 프로퍼티들은 <키, 값>의 형태로 저장되며, 또한 Hashtable의 put() 메소드를 사용하여 손쉽게 프로퍼티를 추가하거나 변경할 수 있다. (하지만, 프로퍼티의 값을 추가하거나 변경하는 것이 그리 좋은 방법은 아니다).

Properties 클래스에서 사용할 메소드는 getProperty()이며, 다음과 같은 두 가지 형태가 존재한다.

public String getProperty(String key)
public String getProperty(String key, String defaultValue)

첫번째 메소드는 key를 키값으로 갖는 프로퍼티가 있을 경우 그 값을 리턴하고, 없다면 null을 리턴한다. 두번째 메소드는 key를 키값으로 갖는 프로퍼티가 있을 경우 그 값을 리턴하고, 없다면 두번째 파리미터로 넘겨준 defaultValue를 리턴한다. getProperty() 메소드 이외에 다른 메소드에 대해 알고 싶다면 Java API 문서를 참조하기 바란다.

Config 인터페이스, AbstractConfiguration 클래스

앞에서 이 글의 목적은 다양한 어플리케이션에서 범용적으로 사용될 수 있는 설정 클래스를 작성하는 것이다. 범용적인 설정 클래스를 작성한다는 것은 여러 종류의 형태로 설정 정보를 입력 받을 수 있어야 한다는 것을 의미한다. 예를 들어, 로컬 파일이 아닌 RMI, HTTP, Corba와 같이 원격에 있는 자원을 사용하여 설정 내용을 읽어올 수 있어야 한다. 그렇다면 Configuration 클래스에서 이 모든 것을 다 처리할 것인가? 답은 '아니오'이다. Configuration 클래스는 단지 로컬에 있는 파일로부터 프로퍼티를 읽어오며, 원격으로부터 프로퍼티를 읽어오는 것은 RMIConfiguration, HTTPConfiguration 그리고 CorbaConfiguration과 같은 별도의 클래스에서 책임을 진다. 이들 클래스들은 모두 다른 자원으로부터 프로퍼티를 읽어오는 것이 다를 뿐 그들의 역할은 모두 같다. 이처럼 여러 개의 클래스들이 공통된 형태의 작업을 하는 경우에 주로 사용되는 것이 있다. 바로 상속이다. 이 절의 제목에서 사용된 AbstractConfig 클래스는 모든 종류의 Configuration 클래스들이 상속받는 추상 클래스이며, Config 인터페이스를 구현하고 있다. 즉, 다음과 같은 형태의 구조를 지닌다.


먼저 Config 인터페이스를 정의해보자. Config 인터페이스는 String, int, long, double, float 형의 프로퍼티의 값을 구해주는 메소드를 선언하고 있다. Config 인터페이스의 소스 코드는 다음과 같다.

package javacan.config;

public interface Config {
   public java.util.Properties getProperties();
   public String getString(String key);
   public int getInt(String key);
   public double getDouble(String key);
   public boolean getBoolean(String key);
}

Config 인터페이스는 보는 것 처럼 간단하다. 단순히 필요한 타입의 프로퍼티 값을 구해주는 네 개의 getXXX(key) 메소드를 정의하고 있다. Configuration 클래스의 사용자들은 Configuration, HTTPConfiguration, RMIConfiguration과 같은 클래스들의 구체적인 구현을 알 필요 없이 단지 Config 인터페이스를 통해서 필요한 프로퍼티의 값을 읽어오기만 하면 된다. 이제 AbstractConfiguration 클래스의 소스를 살펴보자.

package javacan.config;

import java.util.Properties;

public abstract class AbstractConfiguration implements Config {
   /**
    * 모든 속성값을 저장한다..
    */
   protected Properties props = null;
   
   public AbstractConfiguration() {
      // do nothing;
   }
   
   /**
    * 모든 속성 이름을 구한다.
    */
   public Properties getProperties() {
      return props;
   }
   
   /**
    * String 타입 속성값을 읽어온다.
    */
   public String getString(String key) {
      String value = null;
      value = props.getProperty(key);
      
      if (value == null) throw new IllegalArgumentException("Illegal String key : "+key);
      
      return value;
   }
   
   /**
    * int 타입 속성값을 읽어온다.
    */
   public int getInt(String key) {
      int value = 0;
      try {
         value = Integer.parseInt( props.getProperty(key) );
      } catch(Exception ex) {
         throw new IllegalArgumentException("Illegal int key : "+key);
      }
      return value;
   }
   
   /**
    * double 타입 속성값을 읽어온다.
    */
   public double getDouble(String key) {
      double value = 0.0;
      try {
         value = Double.valueOf( props.getProperty(key) ).doubleValue();
      } catch(Exception ex) {
         throw new IllegalArgumentException("Illegal double key : "+key);
      }
      return value;
   }
   
   /**
    * boolean 타입 속성값을 읽어온다.
    */
   public boolean getBoolean(String key) {
      boolean value = false;
      try {
         value = Boolean.valueOf(props.getProperty(key)).booleanValue();
      } catch(Exception ex) {
         throw new IllegalArgumentException("Illegal boolean key : "+key);
      }
      return value;
   }
}

AbstractConfiguration 클래스는 Config 인터페이스의 각 메소드를 구현하고 있다. 또한, 각각의 프로퍼티는 멤버 변수인 props에 저장되어 있다고 가정한다. props는 Properties 클래스이며 각각의 getXXX(key) 메소드는 내부적으로 이 Properties를 사용한다. 여기서 주의할 점은 getXXX()에 throws 구문을 통해서 예외를 던지지 않고 RuntimeException의 한 종류인 IllegalArgumentException을 발생한다는 것이다. 이는 자바에서는 상위 클래스에 있는 메소드를 오버라이딩(overriding) 할 경우 throws 구문을 변경할 수 없기 때문에 그렇게 한 것이다. AbstractConfiguration 클래스의 소스 코드를 보면 AbstractConfiguration 클래스는 자체적으로 Properties 클래스를 초기화하지 않는다는 것을 알 수 있다. 이러한 프로퍼티의 초기화는 AbstractConfiguration 클래스를 상속한 Configuration이나 HTTPConfiguration과 같이 실제로 특정 자원(예를 들면, 로컬 파일)으로부터 프로퍼티 목록을 읽어오는 클래스에서 이루어진다.

Configuration 클래스의 구현

Configuration 클래스는 로컬 파일로부터 설정 정보를 읽어와서 Properties 객체를 초기화한다. 로컬 파일을 읽어오는 방법에는 여러 가지가 있을 수 있으나, 여기서는 CLASSPATH에 있는 파일로부터 설정 정보를 읽어올 것이다. CLASSPATH에 있는 파일을 읽어오기 위해서는 ClassLoader 클래스의 getSystemResource() 메소드를 사용하면 된다. 예를 들어, CLASSPATH에 있는 javacan.properties 파일을 읽고자 한다면, 다음과 같은 코드를 사용하면 된다.

java.net.URL dbURL = ClassLoader.getSystemResource("javacan.properties");
File fileName = new File(dbURL.getFile());

예를 들어, 현재 환경변수 CLASSPATH의 값이 다음과 같다고 해 보자.

CLASSPATH=/home/madvirus/config/

이 경우 javacan.properties 파일은 /home/madvirus/config 디렉토리에 위치하면 된다.

ClassLoader.getSystemResource() 메소드는 현재 사용되는 클래스로더에 따라 다른 형태로 구현될 수 있다. 자바2에서 기본적으로 사용되는 클래스로더의 경우, getSystemResource() 메소드는 CLASSPATH로부터 자원을 읽어온다. 이제 CLASSPATH에 있는 javacan.properties 파일을 읽어올 수 있게 되었다. 이제 남은 것은 그 파일로부터 프로퍼티 목록을 읽어와서 Properties 클래스의 인스턴스를 생성하는 것이다. 이에 대한 설명은 Configuration 클래스의 소스 코드를 본 이후에 계속하도록 하자.

package javacan.config;

import java.io.*;

public class Configuration extends AbstractConfiguration {
   
   /**
    * 설정 파일의 이름을 저장한다.
    */
   private String configFileName;
   
   public Configuration() throws ConfigurationException {
      initialize();
   }
   
   /**
    * 필요한 초기화를 한다.
    */
   private void initialize() throws ConfigurationException {
      java.net.URL dbURL = ClassLoader.getSystemResource("javacan.properties");   
      if (dbURL == null) {
         File defaultFile = new File(System.getProperty("user.home"), "javacan.properties");
         configFileName = System.getProperty("javacan.config.file", defaultFile.getAbsolutePath());
      } else {
         File fileName = new File(dbURL.getFile());
         configFileName = fileName.getAbsolutePath();
      }
      
      try {
         File configFile = new File(configFileName);
         if ( ! configFile.canRead() ) 
            throw new ConfigurationException( "Can't open configuration file: " + configFileName );
         
         props = new java.util.Properties();
         FileInputStream fin = new FileInputStream(configFile);
         props.load(new BufferedInputStream(fin));
         fin.close();
      } catch(Exception ex) {
         throw new ConfigurationException("Can't load configuration file: "+configFileName);
      }
   }
}

Configuration 클래스의 소스를 보면, 단지 생성자와 initialize() 메소드만 정의되어 있다. initialize() 메소드는 CLASSPATH에 있는 javacan.properties 파일로부터 프로퍼티 정보를 읽어온 후 상위 클래스의 멤버인 props에 저장한다. 여기서 눈여겨 볼 부분은 바로 Properties의 load() 메소드를 사용하는 부분이다. Properties 클래스의 load() 메소드는 파라미터로 넘겨준 InputStream으로부터 자동으로 프로퍼티 목록을 만들어낸다. 따라서 개발자가 파일을 분석한 후 일일이 각각의 프로퍼티를 Properties에 추가해줄 필요가 없다.

이제 마지막으로 ConfigurationException 클래스에 대해서 알아보자. 이 클래스는 이름에서도 알 수 있듯이 예외 클래스이며, 다음과 같이 간단하게 정의되어 있다.

package javacan.config;

public class ConfigurationException extends Exception {

   public ConfigurationException() {
      super();
   }

   public ConfigurationException(String s) {
      super(s);
   }
}

테스트

이제 모든 "설정가능한" 어플리케이션을 만들기 위한 모든 준비가 끝났다. Configuration 클래스의 사용법은 다음과 같이 매우 쉽다.

Config conf = new Configuration();
int val1 = conf.getInt("port");
String email = conf.getString("admin_email");

실제로 Configuration 클래스가 올바르게 동작하는 지 테스트하기 위해서는 프로퍼티 목록을 저장하고 있는 설정 파일이 필요하다. 테스트에서 사용할 설정 파일 javacan.properties는 다음과 같다.

webserver.hostname=www.javacan.com
webserver.document_root=/home/madvirus/webroot
webserver.port=8080

이 파일은 CLASSPATH에 위치해야 한다. 예를 들어, 이 파일이 /home/madvirus/conf/ 디렉토리에 있다면, CLASSPATH에 /home/madvirus/conf 디렉토리를 추가해주어야 한다. 이제 테스트를 위한 Test 클래스를 작성해보자. Test 클래스는 다음과 같다.

import javacan.config.*;

public class Test {

   public static void main(String[] args) {
      try {
         Config conf = new Configuration();
         System.out.println("webserver.hostname:"+conf.getString("webserver.hostname") );
         System.out.println("webserver.document_root:"+conf.getString("webserver.document_root") );
         System.out.println("webserver.port:"+conf.getInt("webserver.port") );
      } catch(ConfigurationException ex) {
         ex.printStackTrace();
      }
   }
}

Test 클래스를 실행하면 다음과 같이 결과가 출력될 것이다.

[webmaster@server madvirus]$ java Test
webserver.hostname:www.javacan.com
webserver.document_root:/home/madvirus/webroot
webserver.port:8080
[webmaster@server madvirus]$

문제점

Configuration 클래스가 사용하기 쉽다는 장점은 있으나, 몇 가지 문제점을 갖고 있다.

첫번째 문제점은 Configuration 클래스의 인스턴스를 생성할 때 마다 매번 설정 파일을 읽어온다는 점이다. 실제로 설정 파일이 변경되는 경우는 극히 드물며, 따라서 설정 내용이 필요할 때 마다, 매번 설정 파일을 읽어온다는 것은 비효율적이다.

두번째 문제점은 여러 개의 파일로부터 설정 정보를 읽어올 수 없다는 점이다. 이는 Configuration 클래스를 조금만 변경하면 손쉽게 개선할 수 있을 것이다. 단, 여러 파일로부터 설정 정보를 읽어올 경우 서로 다른 파일에 있는 프로퍼티가 같은 키값을 가질수도 있기 때문에, 키값이 겹치지 않도록 하기 위한 별도의 방법을 사용해야 한다.

세번째 문제점은 설정 파일만으로는 각 프로퍼티 간의 관계를 알 수 없다는 점이다. 물론, 엄밀히 말해서 이것이 문제점이 되지는 않는다. 현재 나와 있는 대부분의 어플리케이션의 설정 파일은 여기서 작성한 설정 파일과 비슷한 형태로 되어있으며, 현재까지 이러한 형태의 설정 파일이 문제가 된 적은 거의 없다. 하지만, 각 프로퍼티 간의 관계를 명시적으로 표시할 수 있다면 설정 파일을 관리하는 것이 지금보다 훨씬 더 간단하고 수월해질 것이다.

네번째 문제점은 세번째 문제점과 유사한 것으로 프로퍼티들의 집합이라는 개념이 존재하지 않는다는 것이다. 예를 들어, 채팅서버와 웹 서버의 프로퍼티를 하나의 설정 파일에 저장할 수 있으며, 이러한 경우에 채팅서버와 관련된 프로퍼티와 웹 서버와 관련된 프로퍼티를 별도의 집합으로 지정할 수 있다면, 훨씬 더 명료하게 설정 파일을 관리할 수 있을 것이다.

이러한 문제점 중에 몇 가지는 XML을 이용하여 손쉽게 해결할 수 있다. 나중에 기회가 된다면 XML을 이용한 설정에 대해서 알아볼 것이다.

결론

이 글에서는 java.util.Properties 클래스를 이용하여 설정 파일로부터 손쉽게 프로퍼티를 읽어오는 것에 대해 알아보았다. Configuration 클래스는 CLASSPATH에 있는 자원으로부터 프로퍼티를 읽어 매우 손쉽게 어플리케이션의 여러 프로퍼티를 설정할 수 있도록 해준다. 비록 몇 가지 문제점이 있긴 하지만, 여러분 스스로 조금만 노력한다면 그러한 문제를 어렵지 않게 해결할 수 있을 것이다.

관련링크:
XML과 XML 관련 기술에 대해서 간략하게 알아보며, 자바와 XML 사이의 관계에 대해서 알아본다.

XML은 무엇인가?

XML! XML! XML! 만약 여러분이 IT 세상의 흐름과 함께 하고 있다면 XML에 대한 많은 것들에 대해서 들어보았을 것이며, 이제 막 개발자의 세계에 발을 들여놓았다 하더라도 적어도 한번 정도는 'XML'이란 단어를 들어보았을 것이다. 현재 마이크로소프트, 썬 마이크로시스템즈, 오라클, IBM과 같은 IT 분야를 대표하는 대부분의 기업들은 XML을 분석(parsing)하고 변환(transformation)할 수 있는 여러 도구들을 제공하고 있으며, 최근에 각 기업이 내 놓고 있는 제품들은 XML을 여러 형태로 사용하고 있다. 이러한 XML 영역의 증가추세는 앞으로 더욱 가증될 것으로 예상된다. 이번 Article에서는 초보 개발자 뿐만 아니라 아직까지 XML이 무엇인지에 대해서 자세하게 알지 못하는 개발자들을 위해 XML이 무엇인지, 어디서 XML을 사용하는지 그리고 XML을 왜 사용하는 지에 대한 전반적인 내용을 간략하게 알아볼 것이다.

XML의 정의

XML은 'Extensible Markup Language'이다. 우리말로 하자면 '확장가능한 마크업 언어' 정도가 될 것이다. XML은 앞서 나온 SGML과 마찬가지로 다른 언어를 정의할 때 사용되는 메타언어(metalanguage)이다. 하지만, XML은 SGML 보다 훨씬 더 간단하다. 또한, 오늘날 가장 많이 사용되고 있는 마크업 언어인 HTML의 확장성이 거의 없는 반면에 XML은 거의 무한의 확장성을 갖고 있다. 이러한 XML의 확장성은 XML이 문법(grammar)이나 '태그집합(tag set)'을 규정하지 않은 마크업 언어이기 때문에 가능하다. 간단히 비교를 하기 위해 HTML과 비교해보자. 현재 나와 있는 HTML 규약은 사용자가 사용할 수 있는 태그 및 속성의 종류를 제한하고 있다. 다시 말해서, HTML은 미리 정의된 태그 집합과 문법을 갖고 있다. 예를 들어, HTML에서 <table> 태그를 사용할 수는 있지만, <furniturelist> 태그를 사용할 수는 없다. HTML 문서를 사용하는 어플리케이션(거의 웹 브라우저일 것이다)에 대해 <table> 태그는 특정한 의미를 지니며 표의 시작을 나타낼 때 사용되는 반면에, <furniturelist> 태그는 HTML 문서를 사용하는 어플리케이션에 대해 어떤 의미도 갖지 않으며 웹 브라우저는 이 태그를 처리하지 않고 무시할 것이다. 이는 HTML을 정의할 때, HTML 규약에 사용가능한 태그 집합을 정의했기 때문에 그렇다. 따라서 새로운 태그를 추가하거나 불필요한 태그를 삭제하기 위해서는 새로운 버전의 HTML 규약을 발표해야만 한다. 또한, HTML은 언어에 정의된 태그의 올바른 사용법을 정의한 '문법(grammar)'을 갖고 있다. 예를 들어, <tr> 태그는 반드시 <table> 태그에 중첩되어야 하며, <table> 태그는 width, border, cellpadding과 같은 속성의 값을 지정할 수는 있지만 type이라는 속성을 지정할 수는 없다.

반면에 XML은 미리 정의된 태그 집합이나 문법을 규정하고 있지 않기 때문에 HTML과는 달리 완전한 확장성을 가진다. XML 문서 작성자는 원하는 태그를 사용할 수 있으며, 태그에 원하는 속성을 지정할 수 있으며, 원하는 형태로 태그를 중첩시킬 수 있다. 즉, 자신만의 태그 집합과 문법을 만들 수 있다는 것이다. 예를 들어 다음의 간단한 XML 문서를 살펴보자.

<?xml version="1.0" encoding="euc-kr"?>
<furniture-list>
    <table type="B" class="보급형">
        <productName>XX 책상</productName>
        <drawer>4</drawer>
        <hasBookshelf>true</hasBookshelf>
        <hasLamp>true</hasLamp>
        <target>학생</target>
        <price>130000</price>
    </table>
    <chair class="고급형">
        <productName>듀오 의자</productName>
        <target>모두</target>
        <price>35000</price>
    </chair>
    <bed>
        <productName>에이스 침대</productName>
        <size>2</size>
        <target>모두</taget>
        <price>280000</price>
    </bed>
</furniture-list>

예제 XML 문서를 보면 HTML과는 많이 다르다는 것을 알 수 있다. 여기서 사용된 <table>, <size>, <target>과 같은 태그는 문서 작성자가 만든 것이며, 각 태그간의 중첩 관계 역시 작성자에 의해 구성된 것이다. 이것이 바로 XML의 힘이다. 여러분은 XML 규약이 요구하는 일반적인 구조에 따라 XML 문서를 만드는 한, 다양한 방법으로 데이터의 내용을 정의할 수 있으며, 이에 따라 데이터를 표현하는 데 있어 HTML로는 불가능한 유연성을 갖게 된다.

이러한 XML의 유연성은 XML의 가장 큰 장점중의 하나이면서 동시에 단점이 되기도 한다. 한 가지 목적을 위해 여러 다양한 방법을 사용할 수 있기 때문에, 데이터의 표현과 변환을 처리하기 위한 많은 다른 규약들이 존재하며, 이러한 규약을 통해서 XML은 유연성에 의해 발생하는 단점을 보완하고 있다. 실제로 XML 기술이라고 하면, 단순히 XML을 의미하기 보다는 XML 및 XML 관련 기술을 의미하는 경우가 더 많다.

XML을 HTML과 비교할 때, 또 하나의 큰 차이점은 XML은 표현(presentation)을 위한 데이터가 아닌 내용을 위한 데이터라는 점이다. HTML의 경우 <code>와 <strong>은 그 태그의 값이 각각 프로그래밍 코드와 강조된 것이라는 것을 나타내는 내용 기반의 태그인 반면에 <b>와 <i>는 태그는 내용을 어떻게 출력하라는 표현에 중점을 태그이다. 즉, 표현과 내용이 하나의 문서에 혼합되어 있는 것이다. 따라서, XML 문서를 작성할 때 표현을 어떻게 할 것인가에 대해서는 전혀 생각할 필요가 없으며, 단지 내용을 어떻게 XML 문서로 나타낼 것이가엔 대해서만 생각하면 된다.

XML에 대해서 이해하기 위해서는 XML 뿐만 아니라 XML 관련 기술에 대해서도 이해하고 있어야 한다. 이제부터 XML과 관련된 기술들에 대해 간단하게 알아보도록 하자.

XML

XML은 모든 XML 관련 기술의 핵심이다. XML은 핵심 언어 자체를 정의하고 메타데이터 타입의 구조를 정의한다. XML에 기반한 모든 다양한 기술을 통해서 개발자와 콘텐트 관리자들은 데이터 관리와 전송 측면에 있어서 전에 없던 유연성을 제공받게 되었다. 현재 1.0 규약의 권고안(Recommendation)이 나온 상태이다. XML 1.0 규약은 http://www.w3.org/TR/REC-xml에서 참조할 수 있다.

XML 문서는 처리 지시어(Processing Instruction; PI)와 DTD(Document Type Definition; 문서 타입 정의)를 가질 수 있다. PI는 XML 문서를 사용하는 어플리케이션이 특정한 작업을 하도록 지시하는 일종의 명령어이다. DTD는 XML 문서에서 사용할 태그가 따라야 할 문법(사용가능한 태그, 사용가능한 속성, 가능한 태그의 중첩)을 정의한다. 즉, XML 문서는 DTD에 의해 제약받게 된다. 만약 XML 문서가 DTD를 참조하고 있다면, 그 문서는 반드시 DTD에서 지정한 문법에 지정되어 있는 태그와 속성만을 사용해야 하며, DTD에 정의되어 있는 순서대로 각 태그의 순서를 지켜야 하며, DTD에 정의된 중첩 순서대로 각 태그의 중첩 순서를 정해주어야 한다. DTD를 통해서 XML 문서는 모호함을 없앨 수 있게 된다. 예를 들어, 앞의 예제 XML 문서에서 <table> 태그가 책상을 의미하는지 혹은 표를 의미하는지, 그리고 class 속성이 가질 수 있는 값이 어떤 것이 있는 지 어떻게 결정할 수 있는가? DTD를 통해서 이러한 결정들을 쉽게 할 수 있게 된다. 또한, DTD는 XML을 사용하여 데이터를 주고 받는 어플리케이션 사이에서 중요한 역할을 한다. 왜냐면, 두 어플리케이션은 서로를 이해하기 위해서 각 시스템 사이에 협의된 포맷팅(formatting)과 구문을 필요로 하며, DTD가 바로 이러한 것을 제공하기 때문이다.

참고로, DTD는 XML 형식이 아닌 그것만의 규약을 갖고 있다. 예를 들면 DTD는 다음과 같은 형태로 구성되어 있다.

<!ELEMENT furniture-list (table | chair | bed)+>
<!ELEMENT table (productName, drawer, hasBookshelf, hasLamp, target, price) >
<!ATTLIST tale
            type CDATA #REQUIRED
            class (보급형, 고급형) "보급형">
<!ELEMENT productName #PCDATA>
<!ELEMENT drawer #PCDATA>
.....

완전히 XML과 다른 형태로 XML 문서의 문법을 지정하는 것을 알 수 있다. 이에 따라 DTD는 몇 가지 한계점을 갖고 있으며, 이는 다음과 같다.

  • 계층(hierarchy) 개념이 없다. (즉, 개층 개념이 없다!)
  • 이름공간을 유연하게 처리하기 어렵다.
  • XML 문서 사이에 연관성을 줄 수 있는 방법을 갖고 있지 않다.
이러한 한계점이 발생하게 된 원인은 DTD 규약을 처음 작성할 때 지금처럼 많은 곳에서 XML이 사용될 것이라고 예상하지 못했기 때문이며, 따라서 지금처럼 한계를 갖게 되는 것은 어쩌면 당연한 것이다. 하지만, 이러한 한계점은 개발자들을 괴롭히는 요인이 되기도 한다. 따라서 이러한 한계점을 없애야 할 필요성이 생겼으며, 그것들을 해결하기 위해 나온 규약이 바로 XML 스키마(Schema)이다. XML 스키마에 대해서는 잠시 뒤에 알아보기로 하자.

이름공간(Namespace)

이름공간은 요소(element; 일반적으로 태그를 element라고 하며, 요소라고 번역한다)의 접두어(prefix)와 URI 사이의 매핑(mapping)이다. 이름공간은 일반적으로 태그가 속한 이름공간에 따른 이름 충돌 문제를 해결할 때 사용된다. 예를 들어, 앞의 XML 예제에서 <table>, <chair>, <bed> 태그가 상점에서의 판매 가격과 공장도 가격을 표시해야 한다고 해 보자. 이 경우 여러분은 어떤 태그를 사용할 것인가? 이미 <price> 태그가 사용되고 있기 때문에, <factory-price>와 같은 새로운 태그를 사용해야 할 것이다. 만약 할인가격이나 도매가격과 같은 또 다른 형태의 가격이 필요하다면? 필요한 만큼의 <xxx-price> 형식의 태그를 만들어야 할 것이다. 이름공간은 접두어를 사용하여 같은 이름을 갖는 태그를 사용할 수 있도록 해 줌으로써 이러한 문제점을 해결해준다. 예를 들어, 이름공간을 사용하면 상점 판매가, 공장도가격, 도매가격을 각각 <shop:price>, <factory:price>, <wholesale:price>의 태그로 표시할 수 있다. 즉, 같은 이름('price')을 가지는 세 개의 태그를 별도의 이름공간에 속하게 함으로써 충돌없이 같은 이름을 가진 태그(즉, 같은 의미를 갖는 태그)를 사용할 수 있는 것이다. 여기서 세미콜론 앞에 있는 이름이 접두어이며, 각 접두어는 특정한 URI와 연관되어 있다. 이름공간은 XML 문서에서 자주 사용고 있으며 XML 스타일쉬트, XML 스키마를 비롯한 많은 XML 관련 규약에서도 사용되고 있다. 이름 공간 관련 규약은 http://www.w3.org/TR/REC-xml-names/에서 참조할 수 있다.

XSL와 XSLT

XSL은 'Extensible Stylesheet Language'을 의미하며, 한 형식의 XML 데이터를 다른 형식으로 변환하고자 할 때 사용된다. 예를 들어, 하나의 XML 문서를 HTML, PDF, PS 형태로 변환해야 한다고 가정해보자. 이 경우 우리는 XML 문서를 일일이 복사하여 각 포맷에 알맞게 변환해야 할 것이다. XSL은 이렇게 일일이 복사할 필요없이, 이러한 종류의 작업을 수행해주는 스타일쉬트를 정의해주는 방식을 제공한다. 다시 말하면, XSL이 XML 데이터를 표현을 위한 포맷으로 변경해준다는 것이다. 앞에서 XML 문서는 내용을 위한 데이터라고 했던 점을 기억할 것이다. 그렇다면 XML 문서를 어떻게 웹 브라우저와 같은 클라이언트 프로그램에서 표현할 수 있을 것인가? 바로 XSL을 통해서 가능하게 되며, XSL은 내용과 표현을 완전히 분리해준다. 문서를 변환하기 위해 XSL 문서는 '포맷팅 객체(formatting object)'를 포함할 수 있다. 포맷팅 객체는 특정한 이름의 태그이며, 이 태그는 변환할 문서의 타입에 맞는 알맞은 내용으로 변경될 수 있다. 예를 들어 XML 문서를 PDF로 변환할 경우 포맷팅 객체에 해당하는 태그는 PDF에 알맞은 정보로 변경될 것이다.

XSLT는 'Extensible Stylesheet Language Transformation'를 의미하며, 포맷팅 객체가 아닌 완전한 텍스트 기반의 변환을 나타낸다. 일반적으로 XML 문서의 변환은 텍스트 위주로 이루어지기 때문에, 따라서 XSLT가 많이 사용된다.

XML 문서를 다른 형식으로 변환하는 것은 보통 XML 문서에 있는 특정 요소 A를 변환될 문서의 특정 요소 B로 바꾼다는 것을 의미한다. 이러한 변환을 처리하기 위해서는 어떤 요소를 변형할 지, 그리고 요소의 어떤 속성의 값을 처리할 지, 혹은 각 요소의 값에 따라 어떤 형식으로 변환할지를 결정할 수 있어야 한다. 이러한 요소의 선택 문제는 XPath를 통해서 이루어지며 XPath에 대해서는 잠시 뒤에 알아본다.

XSL 1.0 규약은 http://www.w3.org/TR/xsl/에서 참조할 수 있으며, XSLT 1.0 규약은 http://www.w3.org/TR/xslt에서 참조할 수 있다.

XML 스키마(Schema)

앞에서 DTD는 그 자체가 XML로 되어 있지 않으며, 뿐만 아니라 그에 따른 여러가지 한계점들이 발생한다고 하였다. DTD가 XML의 계층 구조를 공유하지 않는 다는 것은 이미 앞에서 DTD의 한계점에서 언급한 바 있다. 이 외에도 DTD는 XML과 같은 방법으로 데이터를 표시할 수 조차 없다. 반면에 DTD 이외에 XSL, XHTML, 이름공간 등의 다른 XML 관련 규약들은 그것의 목적을 표시하기 위해서 XML의 요소, 속성 등을 사용한다. 이러한 상황은 DTD를 다소 이상한 것으로 만들었으며, XML 문서를 어떻게 작성해야 한다는 것을 정의하기 위해 일반적으로 DTD를 사용하기 때문에 어떤 혼동을 일으키기도 했다.

XML 스키마는 XML 문서를 어떻게 작성해야 한다는 것을 정의하기 위해 XML 그 자체를 사용함으로써 DTD가 안고 있던 많은 한계점을 해결하였다. "데이터에 대한 데이터를 정의하는" 방법으로서 XML 그 자체를 사용함으로써 XML 스키마는 계층적 구조를 사용할 수 있으며, 확장성을 갖게 되었으며, 이름공간의 처리 역시 손쉽게 할 수 있게 되었다.

XML 스키마의 요구안을 http://www.w3.org/TR/NOTE-xml-schema-req에서 참조할 수 있다.

XPath

앞에서 XSLT에 대해서 언급할 때, XPath를 사용하여 변환할 대상을 선택하였다. XPath 규약은 XML 문서에 있는 특정한 항목을 어떻게 위치시킬지를 정의하고 있으며, XML 문서에 있는 어떤 '노드(node)'를 참조함으로써 이것을 하게된다. XPath는 XML 문서를 트리로 간주하며, 따라서 여기서 노드는 요소, 속성 또는 텍스트 데이터를 포함한 XML 데이터의 일부를 나타낸다. 실제로 노드를 위치시키기 위해서 XPath는 표현식을 사용한다. 이 표현식이 어떻게 구성되는 지에 대한 내용은 http://www.w3.org/TR/xpath에서 참고할 수 있다.

XQL

XQL은 'Extensible Query Language'를 의미하며, Query에서 알 수 있듯이 XQL은 XML 문서 형식을 사용하여 쉽게 데이터베이스 질의(query)를 표현할 수 있도록 하기 위해 설계된 질의 언어(query language)이다. XQL은 질의(query) 언어를 표현하기 위해 XPath 개념을 사용하고 있다. 왜 XPath 개념을 사용하는지 알아보기 위해 데이터베이스의 특정한 테이블로부터 데이터를 읽어오는 SQL 문장을 생각해보자.

select id, name, password from member_table where id = 'madvirus'

위의 SQL 문장을 보면 member_table이라는 테이블로부터 id 값이 madvirus인 행의 id, name, password 필드값을 읽어오는 것을 알 수 있다. 여기서 중요한 것은 id, name, password나 member_table과 같은 것들이 모두 XML 문서의 특정한 노드로간주될 수 있다는 점이다. (데이터베이스와 XML과의 매핑을 한번 생각해보면 그럴 것이라는 것을 알 수 있을 것이다). 또한, XQL은 질의의 결과 집합을 표준 XML을 사용하여 표시한다. 이때, XML 문서는 XQL에 특정한 태그 집합을 통해서 표현된다.

XSP

XSP라는 단어를 보면서 JSP나 ASP와 비슷한 기술이 아닐까라는 생각을 할 지도 모르겠다. 혹시 XSP가 JSP나 ASP와 비슷하게 서버사이드 스크립트 언어를 나타내는 것이 아닐까라고 생각했다면, 어느 정도 맞게 추측한 것이다. XSP는 'Extensible Server Pages'를 의미한다. XSP는 XML에 기반하고 있으며, 따라서 언어에 독립적이고 웹 페이지와 웹 사이트를 만드는 데 있어서 스크립트 언어 대신 사용될 수 있다. 표현과 내용의 구분에 있어 완전하지 못한 JSP에 비해, XSP는 완전하게 이 둘을 구분해준다. JSP는 JSP 페이지 내에 로직 부분을 담고 있는 반면에 XSP는 로직 부분을 로직쉬트(logicsheet)라는 것에 정의한다. 로직쉬트는 스타일쉬트와 비슷하며, 이를 통해 XSP는 표현의 내요을 완전히 분리해준다. 이러한 구분은 개발자들이 동적이나 동적으로 내용의 생성에만 집중할 수 있도록 해 주고, 반면에 XML과 XSL 제작자들은 XSP 페이지에 적용할 XSL 스타일 쉬트를 변경함으로써 표현과 스타일만을 처리할 수 있도록 해 준다.

XSP는 현재 웹 출판 프레임워크(Web Publishing Framework)인 아파치 코쿤(Cocoon)에 속해 있다. XSP에 대해 자세히 알고자 하는 사람은 http://xml.apache.org/cocoon/xsp.html을 참조하기 바란다.

지금까지 XML과 관련된 기술에 대해서 알아보았다. 이 외에도 XLink, XLL과 같은 많은 XML 관련 규약들이 존재하지만, 여기서는 자바와 관련해서 많이 사용되는 또는 사용될 기술들에 대해서만 알아보았다.

XML의 활용

XML을 어떻게 사용하는가

XML이 아무리 좋은 개념을 갖고 있다고 해도 개발자들이 익숙환 프로그래밍 환경에서 사용할 수 없다면 쓸모 없는 기술에 불과할 것이다. 다행스럽게도 프로그래밍에서 손쉽게 XML을 분석하고, 처리하고, 변환할 수 있도록 해주는 몇몇 API가 발표되었으며, 자바 개발자들은 이러한 API 중에서 알맞은 것을 선택해서 XML을 이용한 자바 프로그래밍을 손쉽게 할 수 있다. 이러한 API에는 SAX, DOM, JAXP, JDOM 등이 있다.

SAX

SAX는 'Simple API for XML'을 의미하며, 그 이름 그대로 XML을 위한 간단한 API를 제공한다. SAX는 XML 데이터를 분석하기 위한 이벤트 기반의 구조를 제공하며, 이러한 구조는 크게 문서를 읽어나가는 과정과 데이터를 사용할 수 있는 부분으로 분리된다. 이벤트는 XML 문서를 순차적으로 처리하는 동안 각 단계에서 발생하며, SAX는 각 이벤트가 발생할 때 호출되는 메소드를 정의하고 있다. 예를 들어, 한 요소의 여는 태그를 만날 경우 startElement() 메소드를 호출하며, 끝 태그를 만날 경우 endElement() 메소드를 호출한다.

SAX는 문서를 읽어나가는 과정에서 발생하는 이벤트를 위한 인터페이스 뿐만 아니라, 잘못된 문서나 비적격(non well-formed) 문서와 같이 XML을 분석하는 과정에서 발생할 수 있는 다양한 상황을 처리할 수 있도록 해 주는 에러와 경고 집합을 정의하고 있다.

DOM

DOM은 'Document Object Model'을 의미한다. SAX가 단지 XML 문서의 데이터에 접근하기 위한 방법을 제공한다면, DOM은 그러한 데이터를 처리하는 방법을 제공하기 위해 설계되었다. DOM은 XML 문서를 트리 형태로 표현한다. 자바를 비롯한 프로그래밍 언어에서는 트리 구조를 쉽게 순회하고 처리할 수 있기 때문에, DOM 트리(XML 문서를 DOM으로 표현한 것을 DOM 트리고 부른다)를 쉽게 처리할 수 있다. SAX와 달리 DOM은 전체 XML 문서를 메모리에 읽어온 후에 DOM 트리를 구성하기 때문에, 한번 문서를 읽으면 매우 빠르게 전체 문서에 접근할 수 있다.

DOM이 전체 XML 문서를 메모리에 읽어온 후에 DOM 트리를 작성한다는 것이 빠르게 XML 문서의 각 요소에 접근할 수 있다는 장점을 제공하긴 하지만, 반면에 결정적인 단점을 제공하기도 한다. DOM은 XML 문서의 크기에 비례한 메모리를 필요로 하기 때문에, XML 문서의 크기가 커질수록 많은 메모리를 요구하게 된다. XML 문서의 매우 클 경우 이는 매우 많은 양의 시스템 자원을 사용하게 되며, 따라서 시스템의 전체적인 성능 저하 현상을 일으키기도 한다.

JAXP

JAXP는 썬이 자바에서 XML 분석을 위해 내 놓은 API이다. JAXP는 SAX와 DOM API를 대신하거나 완성시킨 것은 아니지만 JAXP는 자바 개발자들이 XML API를 좀더 쉽게 사용할 수 있도록 하기 위해 만든 편리한 메소드를 제공하고 있다. JAXP는 이름공간을 지원할 뿐만 아니라 SAX와 DOM 권고안을 따르고 있다. 또한, JAXP는 교체가능(pluggability) 계층을 통해서 XML을 따르는 모든 파서를 사용할 수 있도록 해 준다.

현재 EJB 1.1 규약과 Tomcat은 XML 형식의 설정 및 배치(deployment) 파일을 사용하고 있으며, 앞으로 나올 J2EE 1.3이나 J2SE 1.4에 JAXP가 추가될 것으로 예상된다.

JDOM

현재 나와 있는 XML API 중에서 자바 개발자들에게 가장 흥미를 끌고 있는 API가 있다면, 바로 JDOM이다. JDOM은 일반적으로 SAX와 DOM을 대체할 수 있는 자바 중심적이고 고성능의 API를 제공하고 있으며, DOM이나 SAX에 기반하지 않은 대신 개발자가 DOM의 특징 없이 트리 형태로 XML 문서를 처리할 수 있도록 해 준다. 또한 SAX와 같은 고성능을 제공하기 때문에 분석과 출력을 매우 빠르게 할 수 있도록 해 준다. 또한, DOM과 달리 속성이나 요소 집합을 나타내기 위해서 자바 2의 콜렉션 클래스를 사용한다. (참고로, DOM은 속성이나 요소 집합을 나타내기 위해서 Attributes 또는 Nodelist와 같은 별도의 클래스를 사용한다).

JDOM은 자바에 맞춰서 개발된 API이기 때문에, SAX나 DOM과 달리 자바에 최적화되어 있다. 그 하나의 예로 자바 2의 콜렉션 API를 사용하는 것을 들 수 있다. 또한, JDOM은 이미 증명된 자바 디자인 패턴에 따라 설계되었으며, 직접적으로 클래스의 인스턴스를 생성함으로써 JDOM의 구성 요소(요소, 주석, 속성, 기타 등등)를 생성할 수 있도록 하고 있다.

XML을 어디에 사용하는가

아직까지 XML을 미션 크리티컬한 어플리케이션에서 사용하지는 않고 있다. 하지만, 자바와 비교해보면 XML의 발전 속도는 매우 빠른 편이며, 점차적으로 XML을 사용하는 분야가 증가하고 있다. 실예로, 앞으로 나올 ASP+나 JSP 차기 버전의 경우 페이지 자체를 XML로 작성할 수 있도록 하고 있다. 또한, XML에 있어서 중요한 점은 자바와 찰떡궁합을 이룬다는 점이다. 이에 대해서는 이 Article의 마지막 부분에서 살펴볼 것이다.

XML을 현재 어느 분야에서 사용하고 있는 지에 대해서 살펴보도록 하자.

표현에서의 XML

XML의 가장 큰 장점은 내용과 표현을 분리한다는 점이다. 이는 오늘날과 같이 클라이언트의 종류가 다양한 환경에서 큰 힘을 발휘하게 된다. 예를 들어, 클라이언트의 종류가 웹 브라우저, 휴대전화와 같은 무선 기기, 자바 애플리케이션이라고 해보자. 기존의 방법을 사용하려면 각각의 클라이언트에 대해서 각각 HTML, WML 그리고 자바 애플리케이션에 알맞은 어떤 형태로 제공해야 한다. 내용이 변경되거나 표현부분이 변경되는 경우 모두 각각의 문서를 변경해주어야 한다. 내용을 변경하는 경우에도 이 각각의 문서를 변경해야 한다는 것은 매우 귀찮은 일일 수 있으며, 지원해야 하는 클라이언트의 종류가 세 가지 이상으로 늘어날 경우 이는 관리에 있어서 어려움을 제공하는 원인이 되기도 한다. 또한, 하나의 문서를 변경하기 위해서는 개발자와 페이지 디자이너가 모두 필요하다는 것도 문제가 된다.

XML을 사용하면 이러한 문제의 상당히 많은 부분을 해결할 수 있게 된다. 앞에서 XSL/XSLT에 대해서 설명할 때, XSL/XSLT는 한 형식의 문서를 다른 형식으로 변환해 준다고 하였다. 개발자는 단순히 내용을 저장하고 있는 XML 문서만을 생성하면 되며, 페이지 디자이너는 XML 문서를 HTML, WML 그리고 자바 애플리케이션에 알맞은 형태로 변환해주는 XSL/XSLT를 작성하기만 하면 된다. 만약 사용자가 웹 브라우저를 통해서 접속했다면 XML+HTML로 변환해주는 XSLT를 통해서 HTML 문서를 제공해주며, 휴대전화로 접속했다면 XML+WML로 변환해주는 XSLT를 통해서 WML 문서를 제공해줄 것이다. 즉, 하나의 XML 문서를 통해서 여러개의 표현을 만들어낼 수 있는 것이다. 현재 이러한 기능을 제공해주는 출판 프레임워크가 개발되고 있으며, 대표적인 아파치 코쿤을 예로 들 수 있다.

통신에서의 XML

어플리케이션 사이에서 정보를 주고 받기 위해서 XML을 사용할 수 있다. 각각의 어플리케이션은 자신만의 문서 형식을 작성할 필요가 없으며, 단지 두 어플리케이션이 알고 있는 DTD나 스키마에 맞춰서 XML 문서를 작성하기만 하면 된다. 뿐만 아니라 XML로 정보를 표현하기 때문에 특별한 어플리케이션에 종속되지 않으며 따라서 DTD를 따르는 모든 애플리케이션에서 같은 정보를 사용할 수 있게 된다. 또한, XML로 표현된 정보를 XSL/XSLT를 사용하여 손쉽게 어플리케이션에 특정한 형식으로 변환할 수도 있다.

이러한 XML의 응용 범위는 오늘날 인터넷 비니지스에 있어서 핵심으로 떠오르고 있는 B2B로 확장될 것으로 예상된다. 즉, 어플리케이션 사이에서 뿐만 아니라 기업간에 XML을 통해서 정보를 주고 받을 것이다. 이미 많은 곳에서 XML을 이용하여 기업간에 정보를 주고 받을 수 있는 어플리케이션을 개발하고 있으며 몇몇 제품은 이미 판매되고 있다. 오늘날 기업간에 정보를 주고 받을 때 주로 사용되는 EDI에 비해 XML은 더욱 더 다양한 형태로 정보를 주고 받을 수 있도록 해 준다.

설정에서의 XML

앞에서도 말했듯이 XML은 설정에 있어서 유용하게 활용할 수 있다. 이미 EJB 1.1 규약과 앞으로 정식으로 발펴될 EJB 2.0 규약에서 XML을 사용하여 설정 및 배치 기술자를 정의하고 있으며 서블릿 2.2 역시 XML을 사용하여 설정과 배치 부분을 기술하고 있다. 앞으로 이러한 설정 및 배치와 관련된 곳에서 XML의 사용범위는 점차적으로 증가할 것으로 예상된다.

자바 & XML

마지막으로 자바와 XML과의 관계에 대해서 간략하게 알아보자. 이 두 기술의 관계를 다음의 문구로 간단하게 표현할 수 있다.

Java + XML = Portable Code + Protable Data

자바의 이식성은 별다른 설명이 필요 없을 정도로 자명하다. 자바는 중간 코드인 바이트코드와 JVM을 통해서 거의 완벽한 이식성을 제공하고 있으며, 쓰레드와 Native 메소드와 같은 몇가지 문제점을 제외하고는 거의 모든 플랫폼에서 특별한 문제없이 같은 자바 코드를 사용할 수 있게 되었다.

XML의 이식성은 자바의 이식성보다 더욱 더 완벽에 가깝다. 자바를 실행하기 위해서 단지 플랫폼에 알맞은 JVM이 있으면 되듯이, XML을 사용하기 위해서는 표준 XML을 지원하는 파서, 처리기(Processor) 등이 있으면 된다. XML 데이터 자체는 플랫폼에 어떠한 플랫폼에도 영향을 받지 않는다.

자바는 XML을 사용할 수 있는 풍부한 API를 제공하고 있으며, 따라서 자바와 XML의 조화는 어플리케이션과 데이터에 있어서 완벽한 이식성을 제공해주며, 이는 앞으로 개발될 어플리케이션(특히 엔터프라이즈 어플리케이션)에서 큰 힘이 될 것이다.

XML 파서(Parser)와 처리기(Processor)

XML을 실제 어플리케이션 환경에서 사용하기 위해서는 XML을 분석할 수 있는 파서(parser)와 XSL/XSLT를 사용하여 XML을 변환할 수 있는 XML 처리기가 필요하다. 여기서는 XML을 분석하고 처리할 수 있도록 해 주는 파서와 처리기의 종류를 나열할 것이다.

파서

현재 사용할 수 있는 파서에는 다음과 같은 것들이 있다.

처리기(Processor)

현재 사용할 수 있는 처리기에는 다음과 같은 것들이 있다.

관련링크:
자바2에서 제공하는 기본적인 클래스로더에 대해서 알아본다.

클래스의 이름 공간

이전 Article에서 설명하지 않은 것이 있어서 JDK에서 기본적으로 제공하는 클래스로더에 대해 알아보기 전에 알아볼 것이 있다. 바로 클래스의 이름 공간에 대한 것이다. 우선 클래스의 이름에 대해서 알아보자. 클래스의 완전한 이름은 패키지와 클래스 이름의 두 부분으로 구성된다. 예를 들어, Vector 클래스의 경우 패키지 이름 java.util과 클래스 이름 Vector가 합쳐져서 완전한 클래스 이름인 java.util.Vector로 구성된다. 이렇게 완전한 이름은 같은 이름을 가진 클래스를 구분할 때 사용한다. 예를 들면, Date 클래스의 경우 java.util과 java.sql의 두 패키지에 속해 있으며, 이 두 클래스를 동시에 사용하고자 할 경우에는 반드시 완전한 클래스 이름(즉, java.util.Date와 java.sql.Date)을 사용하여 구분해야 한다.

클래스의 이름과 관련해서 알아야 할 점이 또 하나 있다. 바로 클래스를 로딩한 클래스로더와 관련한 것이다. 하나의 JVM에서 여러개의 클래스로더를 사용하여 클래스를 로딩할 수 있다. 여기서 생각할 수 있는 점이 같은 클래스를 서로 다른 클래스로더가 로딩할 수 있다는 점이다. 이러한 예로 애플릿을 예로 들 수 있다. 현재 많이 사용하고 있는 웹 브라우저의 경우 각각의 애플릿마다 하나의 클래스로더를 사용하고 있다. 바꿔 말하면, A라는 애플릿과 관련된 클래스 집합을 A'이라고 하고, B라는 애플릿과 관련된 클래스 집합을 B'이라고 할 경우, A'과 B'을 로딩하는 클래스로더가 다르다는 것이다. 만약 A'과 B'에 모두 x.y.Z라는 클래스가 있는 데, A'에 있는 것과 B'에 있는 것이 서로 정의가 다르다고 해 보자. 이 경우, A' 애플릿을 로딩한 이후에 B' 애플릿을 로딩했다면, x.y.Z 클래스는 어떻게 처리될까? 클래스 이름 충돌 문제가 발생하지 않을까? 정답은 발생하지 않는다이다. 이유는 별도의 클래스로더가 x.y.Z를 로딩하기 때문이다. 실제로 자바에서의 클래스 이름은 클래스 이름 공간(name space)라는 개념으로 처리되면, 이 클래스 이름 공간은 다음의 형태로 구성된다.

(패키지, 이름, 클래스로더)

따라서, 제 아무리 같은 클래스라도 클래스로더가 다르면, JVM 내에서 다른 클래스로 처리된다. 필자 역시 예전에 이 부분을 미처 알지 못해서 애플릿 프로그래밍을 할 때에 실수를 한 적이 있다. 애플릿을 사용하여 인트라넷 환경의 엔터프라이즈 시스템을 개발하는 경우, 이 점에 특히 주의해야 할 것이다. 물론, 웹 브라우저의 버전이나 종류에 따라 클래스 로딩이 다르게 동작할 수 있다. 따라서, 하나의 어플리케이션에서 여러 개의 애플릿을 사용하는 경우에는 반드시 대상이 되는 웹 브라우저에서 철저하게 테스트해야 한다.

클래스로더

자바 2의 표준 런타임 라이브러리(jre/lib/rt.jar)는 기본적으로 몇 개의 클래스로더를 제공하고 있다. 이 클래스로더 중에서는 공개적으로 사용할 수 있는 것들이 있고, 공개되지 않고 런타임 라이브러리의 내부적으로만 사용되는 것들도 있다. 이번 Article에서는 이렇게 자바에서 기본적으로 제공하는 클래스로더에 대해서 알아보도록 하자.

java.net.URLClassLoader

URLClassLoader는 지정한 URL로부터 클래스를 로딩할 수 있도록 해 준다. 이 말은 올바른 URL을 사용하는 한, 파일 시스템, HTTP, FTP를 비롯한 모든 형태의 URL로부터 클래스를 로딩할 수 있다는 것을 의미한다. 여기서는 파일 시스템, HTTP, FTP를 통해서 클래스를 읽어오는 것에 대해 알아보자.

먼저, 파일 시스템으로부터 클래스를 로딩하는 것에 대해서 알아보자. URLClassLoader가 일반적으로 사용되는 경우는 파일 시스템으로부터 클래스를 읽어올 때이다. 예를 들어, /usr/classes 디렉토리에서 HelloWorld 클래스를 로딩해서 그 클래스의 인스턴서를 생성하고자 할 경우 다음과 같이 하면 된다.

  import java.net.URL;
  import java.net.URLClassLoader;
  
  public class FileSystemTest {
  
   public static void main(String[] args) throws Exception {
   URL[] urls = { new java.io.File("/usr/classes").toURL(); }
  
   URLClassLoader ucl = new URLClassLoader(urls);
  
   Class klass = ucl.loadClass("HelloWorld");
   Object obj = klass.newInstance();
   // obj를 사용하여 적절한 것을 한다.
   }
  }

위 코드를 보면, URLClassLoader를 생성할 때, URL의 배열을 생성자의 파라미터로 넘겨주는 것을 알 수 있다. URL 배열을 사용하는 것은 여러 개의 URL로부터 클래스를 로딩할 수 있다는 것을 의미한다. 일단 URLClassLoader를 생성하면, loadClass() 메소드를 사용하여 원하는 클래스를 로딩할 수 있고, 이어서 loadClass() 메소드의 리턴 결과인 Class 객체의 newInstance() 메소드를 사용하여 새로운 인스턴스를 생성해서 사용하면 된다. 만약 HelloWorld 클래스가 javacan.exam 패키지에 속한다고 하면, loadClass() 메소드는 다음과 같이 변경될 것이다.

  Class kalss = ucl.loadClass("javacan.exam.HelloWorld");

이 경우, URLClassLoader는 /usr/classes/javacan/exam 디렉토리에서 HelloWorld 클래스를 로딩할 것이다. URLClassLoader 클래스는 파일 시스템의 디렉토리 뿐만 아니라, URL로 Jar 파일이나 Zip 파일을 지정할 경우 자동적으로 Jar 파일과 Zip 파일로부터 클래스를 로딩한다. 이 경우, URL은 다음과 같이 변경될 것이다.

  URL[] urls = { new java.io.File("/usr/lib/madvirus.jar").toURL() };

HTTP 서버와 FTP 서버로부터 클래스를 로딩하는 것 역시 파일 시스템에서 클래스를 로딩하는 것 만큼이나 쉽다. 단지, URL을 다음과 같이 생성만 해 주면 된다.

  new URL("http", "www.hostname.com", "/lib/madvirus.jar")

이 URL을 URLClassLoader를 생성할 때 넘겨주면, URLClassLoader는 http://www.hostname.com/lib/madvirus.jar로부터 클래스를 로딩할 것이다. FTP 서버로부터 클래스를 로딩할 때는 다음과 같이 URL을 생성하면 된다.

  new URL("ftp", "user:password@www.hostname.com:", "/")

여기서 user와 password는 각각 FTP 서버에 연결할 때 사용하는 사용자 계정과 암호이다.

부트스트랩 클래스로더

부트스트랩 클래스로더는 전문적으로 말해서 클래스로더가 아니다. 왜냐면 부트스트랩 클래스로더는 JVM의 네이티브 코드 영역에 존재하며, Object와 같은 코어 자바 클래스를 VM에 로딩할 때 사용되기 때문이다. 부트스트랩 클래스로더는 sun.boot.class.path 프로퍼티에 지정되어 있는 값을 이용하여 자바 런타임 라이브러리를 찾는다. 이 값을 명시적으로 지정하지 않을 경우, [자바 2 디렉토리]/jre/lib/rt.jar 파일로부터 자바 런타임 클래스들을 로딩한다.

JDK 1.0이나 JDK 1.1.x 때부터 착실하게(?) 자바를 공부해왔던 개발자라면 누구나 [JDK디렉토리]/lib/classes.zip 파일을 CLASSPATH 환경변수에 추가해주었을 것이다. 하지만, 자바2에서 JDK 1.0이나 JDK 1.1.x 때와는 달리 CLASSPATH 환경변수나 명령행의 옵션인 -classpath에 자바 런타임 클래스들을 추가해줄 필요가 없다. 왜냐면, 부트스트랩 클래스로더가 자동적으로 읽어오기 때문이다.

sun.misc.Launcher$ExtClassLoader

ExtClassLoader는 익스텐션 클래스로더(extension classloader)라고도 불리며, 자바의 확장 클래스들을 로딩할 때 사용된다. ExtClassLoader는 URLClassLoader 클래스를 상속하며, java.ext.dirs 프로퍼티에서 지정한 디렉토리에 위치한 .jar 파일로부터 클래스를 읽어온다. 이 프로퍼티의 값을 명시적으로 지정하지 않으면, 기본적으로 [자바 2 디렉토리]/jre/lib/ext 디렉토리에 위치한 .jar 파일로부터 클래스를 읽어온다.

sun.misc.Launcher$AppClassLoader

AppClassLoader는 시스템 또는 어플리케이션 클래스로더라고 부르며, java.class.path 프로퍼티에 명시된 경로에서 코드를 로딩하는 클래스로더이다. ExtClassLoader과 마찬가지로 URLClassLoader를 상속하고 있다. CLASSPATH에 있는 각각의 디렉토리나 .jar 파일은 URL로 변환되어 AppClassLoader에 전달되며, AppClassLoader의 생성자에서는 이 URL들을 상위 클래스인 URLClassLoader 생성자에 전달한다.

ClassLoader.getSystemClassLoader() 메소드를 호출할 때, 이 클래스로더가 리턴된다. 개발자가 작성한 대부분의 클래스들은 이 클래스로더를 통해서 로딩된다. 또한, AppClassLoader는 ExtClassLoader를 부로 클래스로더 지정하고 있기 때문에, 어플리케이션에서 기본적으로(즉, AppClassLoader를 통해서) 익스텐션 디렉토리에 있는 Jar 파일로부터 클래스들을 읽어올 수 있다.

sun.applet.AppletClassLoader

이름에서도 알 수 있듯이, AppletClassLoader는 웹 브라우저가 웹 페이지에서 사용되는 애플릿의 바이트 코드를 다운로드 한 후, 그 애플릿을 실행하는 것을 목적으로 하는 클래스로더이다. AppletClassLoader는 URL을 사용하여 HTTP, FTP 또는 파일 시스템으로부터 클래스를 로딩하기 때문에, URLClassLoader를 상속하고 있다. 하지만, 많이 사용하고 있는 웹 브라우저인 IE나 Netscape의 경우, AppletClassLoader가 아닌 그 웹 브라우저만의 애플릿 클래스로더를 구현하고 있기 때문에, 브라우저마다 서로 다른 동작을 보일수도 있다.

java.security.SecureClassLoader

SecureClassLoader 클래스의 주요 목적은 JVM에 바이드코드를 로딩하고 사용하는 것에 대한 보안을 제어하는 것이다. 하지만, 이 클래스는 실제로 클래스 코드를 로딩할 수 있는 안전한 방법을 제공하지 않으며, 다른 클래스로더가 확장할 수 있는 베이스 클래스로서의 역할을 한다. 따라서 이 클래스는 자바 런타임 라이브러이에 있는 많은 클래스로더의 상위 클래스이며, 대표적인 것으로 URLClassLoader를 들 수 있다. 참고적으로, 이 클래스를 추상 클래스이기 때문에, 직접적으로 이 클래스의 인스턴스를 생성해서 사용할 수 없다.

java.rmi.server.RMIClassLoader

RMIClassLoader는 ClassLoader가 아니며, RMI 런타임 시스템에서 클래스의 로딩과 마샬링(marshaling)을 처리해주는 래퍼 클래스(warpper class)이다. 실제로, RMIClassLoader는 sun.rmi.serer.LoaderHandler 클래스와의 간단한 브릿지(bridge)이다. 실제 클래스의 로딩은 LoaderHandler 클래스의 이너(inner) 클래스로 존재하는 로더 클래스들을 통해서 이루어진다. 이 이너 로더 클래스는 URLClassLoader를 상속하고 있다. 실제로 엔터프라이즈 환경에서는 RMI와 관련된 부분에서만 이 클래스로더가 자동적으로 사용될 뿐, 이 클래스로더를 직접적으로 사용하는 경우는 거의 없다. 왜냐면, URLClassLoader 자체가 HTTP, FTP와 같은 URL을 통해서 클래스를 로딩할 수 있도록 해 주기 때문이다.

결론

이번장에서는 자바에서 기본적으로 클래스로더에 대해서 간단하게 알아보았다. 여러분은 이번 Article을 통해서 자바의 기본적인 클래스로더와 실제로 클래스들이 어떻게 JVM 내에서 서로 구분되는 지 알게 되었을 것이다. 다음 Article에서는 커스텀 클래스로더를 작성하는 것에 대해 알아볼 것이다.

관련링크:
동적인 클래스 로딩

자바는 동적으로 클래스를 읽어온다. 즉, 런타임에 모든 코드가 JVM에 링크된다. 모든 클래스는 그 클래스가 참조되는 순간에 동적으로 JVM에 링크되며, 메모리에 로딩된다. 자바의 런타임 라이브러리([JDK 설치 디렉토리]/jre/lib/rt.jar) 역시 예외가 아니다. 이러한 동적인 클래스 로딩은 자바의 클래스로더 시스템을 통해서 이루어지며, 자바가 기본적으로 제공하는 클래스로더는 java.lang.ClassLoader를 통해서 표현된다. JVM이 시작되면, 부트스트랩(bootstrap) 클래스로더를 생성하고, 그 다음에 가장 첫번째 클래스인 Object를 시스템에 읽어온다.

런타임에 동적으로 클래스를 로딩하다는 것은 JVM이 클래스에 대한 정보를 갖고 있지 않다는 것을 의미한다. 즉, JVM은 클래스의 메소드, 필드, 상속관계 등에 대한 정보를 알지 못한다. 따라서, 클래스로더는 클래스를 로딩할 때 필요한 정보를 구하고, 그 클래스가 올바른지를 검사할 수 있어야 한다. 만약 이것을 할 수 없다면, JVM은 .class 파일의 버전이 일치하지 않을 수 있으며, 또한 타입 검사를 하는 것이 불가능할 것이다. JVM은 내부적으로 클래스를 분석할 수 있는 기능을 갖고 있으며, JDK 1.1부터는 개발자들이 리플렉션(Reflection)을 통해서 이러한 클래스의 분석을 할 수 있도록 하고 있다.

로드타임 동적 로딩(load-time dynamic loading)과 런타임 동적 로딩(run-time dynamic loading)

클래스를 로딩하는 방식에는 로드타임 동적 로딩(load-time dynamic loading)과 런타임 동적 로딩(run-time dynamic loading)이 있다. 먼저 로드타임 동적 로딩에 대해서 알아보기 위해 다음과 코드를 살펴보자.

  public class HelloWorld {
     public static void main(String[] args) {
        System.out.println("안녕하세요!");
     }
  }

HelloWorld 클래스를 실행하였다고 가정해보자. 아마도, 명령행에서 다음과 같이 입력할 것이다.

  $ java HelloWorld

이 경우, JVM이 시작되고, 앞에서 말했듯이 부트스트랩 클래스로더가 생성된 후에, 모든 클래스가 상속받고 있는 Object 클래스를 읽어온다. 그 이후에, 클래스로더는 명령행에서 지정한 HelloWorld 클래스를 로딩하기 위해, HelloWorld.class 파일을 읽는다. HelloWorld 클래스를 로딩하는 과정에서 필요한 클래스가 존재한다. 바로 java.lang.String과 java.lang.System이다. 이 두 클래스는 HelloWorld 클래스를 읽어오는 과정에서, 즉 로드타임에 로딩된다. 이 처럼, 하나의 클래스를 로딩하는 과정에서 동적으로 클래스를 로딩하는 것을 로드타임 동적 로딩이라고 한다.

이제, 런타임 동적 로딩에 대해서 알아보자. 우선, 다음의 코드를 보자.

  public class HelloWorld1 implements Runnable {
     public void run() {
        System.out.println("안녕하세요, 1");
     }
  }
  public class HelloWorld2 implements Runnable {
     public void run() {
        System.out.println("안녕하세요, 2");
     }
  }

이 두 클래스를 Runnable 인터페이스를 구현한 간단한 클래스이다. 이제 실제로 런타임 동적 로딩이 일어나는 클래스를 만들어보자.

  public class RuntimeLoading {
     public static void main(String[] args) {
        try {
           if (args.length < 1) {
              System.out.println("사용법: java RuntimeLoading [클래스 이름]");
              System.exit(1);
           }
           Class klass = Class.forName(args[0]);
           Object obj = klass.newInstance();
           Runnable r = (Runnable) obj;
           r.run();
        } catch(Exception ex) {
           ex.printStackTrace();
        }
     }
  }

위 코드에서, Class.forName(className)은 파리미터로 받은 className에 해당하는 클래스를 로딩한 후에, 그 클래스에 해당하는 Class 인스턴스(로딩한 클래스의 인스턴스가 아니다!)를 리턴한다. Class 클래스의 newInstance() 메소드는 Class가 나타내는 클래스의 인스턴스를 생성한다. 예를 들어, 다음과 같이 한다면 java.lang.String 클래스의 객체가 생성된다.

  Class klass = Class.forName("java.lang.String");
  Object obj = klass.newInstance();

따라서, Class.forName() 메소드가 실행되기 전까지는 RuntimeLoading 클래스에서 어떤 클래스를 참조하는 지 알수 없다. 다시 말해서, RuntimeLoading 클래스를 로딩할 때는 어떤 클래스도 읽어오지 않고, RuntimeLoading 클래스의 main() 메소드가 실행되고 Class.forName(args[0])를 호출하는 순간에 비로서 args[0]에 해당하는 클래스를 읽어온다. 이처럼 클래스를 로딩할 때가 아닌 코드를 실행하는 순간에 클래스를 로딩하는 것을 런타임 동적 로딩이라고 한다.

다음은 RuntimeLoading 클래스를 명령행에서 실행한 결과를 보여주고 있다.

  $ java RuntimeLoading HelloWorld1
  안녕하세요, 1

Class.newInstance() 메소드와 관련해서 한 가지 알아둘 점은 해당하는 클래스의 기본생성자(즉, 파라미터가 없는)를 호출한다는 점이다. 자바는 실제로 기본생성자가 코드에 포함되어 있지 않더라도 코드를 컴파일할 때 자동적으로 기본생성자를 생성해준다. 이러한 기본생성자는 단순히 다음과 같이 구성되어 있을 것이다.

  public ClassName() {
     super();
  }

ClassLoader

자바는 클래스로더를 사용하고, 클래스를 어떻게 언제 JVM으로 로딩하고, 언로딩하는지에 대한 특정한 규칙을 갖고 있다. 이러한 규칙을 이해해야, 클래스로더를 좀 더 유용하게 사용할 수 있으며 개발자가 직접 자신만의 커스텀 클래스로더를 작성할 수 있게 된다.

클래스로더의 사용

이 글을 읽는 사람들은 거의 대부분은 클래스로더를 프로그래밍에서 직접적으로 사용해본 경험이 없을 것이다. 클래스로더를 사용하는 것은 어렵지 않으며, 보통의 자바 클래스를 사용하는 것과 완전히 동일하다. 다시 말해서, 클래스로더에 해당하는 클래스의 객체를 생성하고, 그 객체의 특정 메소드를 호출하기만 하면 된다. 간단하지 않은가? 다음의 코드를 보자.

  ClassLoader cl = . . . // ClassLoader의 객체를 생성한다.
  Class klass = null;
  try {
     klass = cl.loadClass("java.util.Date");
  } catch(ClassNotFoundException ex) {
     // 클래스를 발견할 수 없을 경우에 발생한다.
     ex.printStackTrace();
  }

일단 클래스로더를 통해서 필요한 클래스를 로딩하면, 앞의 예제와 마찬가지로 Class 클래스의 newInstance() 메소드를 사용하여 해당하는 클래스의 인스턴스를 생성할 수 있게 된다. 형태는 다음과 같다.

  try {
     Object obj = klass.newInstance();
  } catch(InstantiationException ex) {
     ....
  } catch(IllegalAccessException ex) {
     ....
  } catch(SecurityException ex) {
     ....
  } catch(ExceptionIninitializerError error) {
     ...
  }

위 코드를 보면, Class.newInstance()를 호출할 때 몇개의 예외와 에러가 발생하는 것을 알 수 있다. 이것들에 대한 내용은 Java API를 참고하기 바란다.

자바 2의 클래스로더

자바 2 플랫폼에서 클래스로더의 인터페이스와 세만틱(semantic)은 개발자들이 자바 클래스로딩 메커니즘을 빠르고 쉽게 확장할 수 있도록 하기 위해 몇몇 부분을 재정의되었다. 그 결과로, 1.1이나 1.0에 맞게 작성된 (커스텀 클래스로더를 포함한) 클래스로더는 자바 2 플랫폼에서는 제기능을 하지 못할 수도 있으며, 클래스로더 사용하기 위해 작성했던 코드를 재작성하는 것이 그렇게 간단하지만은 않다.

자바 1.x와 자바 2에서 클래스로더에 있어서 가장 큰 차이점은 자바 2의 클래스로더는 부모 클래스로더(상위 클래스가 아니다!)를 갖고 있다는 점이다. 자바 1.x의 클래스로더와는 달리, 자바 2의 클래스로더는 부모 클래스로더가 먼저 클래스를 로딩하도록 한다. 이를 클래스로더 딜리게이션 모델(ClassLoader Delegation Model)이라고 하며, 이것이 바로 이전 버전의 클래스로더와 가장 큰 차이점이다.

자바 2의 클래스로더 딜리게이션 모델에 대해 구체적으로 알아보기 위해 로컬파일시스템과 네트워크로부터 클래스를 읽어와야 할 필요가 있다고 가정해보자. 이 경우, 쉽게 로컬파일시스템의 jar 파일로부터 클래스를 읽어오는 클래스로더와 네트워크로부터 클래스를 읽어오는 클래스로더가 필요하다는 것을 생각할 수 있다. 이 두 클래스로더를 각각 JarFileClassLoader와 NetworkClassLoader라고 하자.

JDK 1.1에서, 커스텀 클래스로더를 만들기 위해서는 ClassLoader 클래스를 상속받은 후에 loadClass() 메소드를 오버라이딩하고, loadClass() 메소드에서 바이트코드를 읽어온 후, defineClass() 메소드를 호출하면 된다. 여기서 defineClass() 메소드는 읽어온 바이트코드로부터 실제 Class 인스턴스를 생성해서 리턴한다. 예를 들어, JarFileClassLoader는 다음과 같은 형태를 지닐 것이다.

  public class JarFileClassLoader extends ClassLoader {
     ...
     private byte[] loadClassFromJarFile(String className) {
        // 지정한 jar 파일로부터 className에 해당하는 클래스의
        // 바이트코드를 byte[] 배열로 읽어온다.
        ....
        return byteArr;
     }
     
     public synchronized class loadClass(String className, boolean resolveIt)
        throws ClassNotFoundException {
        
        Class klass = null;
        
        // 클래스를 로드할 때, 캐시를 사용할 수 있다.
        klass = (Class) cache.get(className);
        
        if (klass != null) return klass;
        
        // 캐시에 없을 경우, 시스템 클래스로더로부터
        // 지정한 클래스가 있는 지 알아본다.
        try {
           klass = super.findSystemClass(className);
           return klass;
        } catch(ClassNotFoundException ex) {
           // do nothing
        }
        
        // Jar 파일로부터 className이 나타내는 클래스를 읽어온다.
        byte[] byteArray = loadClassFromJarFile(className);
        klass = defineClass(byteArray, 0, byteArray.length);
        if (resolve)
           resolveClass(klass);
        cache.put(className, klass); // 캐시에 추가
        return klass;
     }
  }

위의 개략적인 코드를 보면, 시스템 클래스로더에게 이름이 className인 클래스가 존재하는 지 요청한다. (여기서 시스템 클래스로더 또는 primordial 시스템 클래스로더는 부트스트랩 클래스로더이다). 그런 후에, 시스템 클래스로더로부터 클래스를 읽어올 수 없는 경우 Jar 파일로부터 읽어온다. 이 때, className은 완전한 클래스 이름(qualified class name; 즉, 패키지이름을 포함한)이다. NetworkClassLoader 클래스 역시 이 클래스와 비슷한 형태로 이루어져 있을 것이다. 이 때, 시스템 클래스로더와 그 외의 다른 클래스로더와의 관계는 다음 그림과 같다.


위 그림을 보면, 각각의 클래스로더는 오직 시스템 클래스로더와 관계를 맺고 있다. 다시 말해서, JarFileClassLoader는 NetworkClassLoader나 AppletClassLoader와는 관계를 맺고 있지 않다. 이제, A라는 클래스가 내부적으로 B라는 클래스를 사용한다고 가정해보자. 이 때, 만약 A 클래스는 네트워크를 통해서 읽어오고, B라는 클래스는 Jar 파일을 통해서 읽어와야 한다면? 이 경우에 어떻게 해야 하는가? 쉽사리 해결책이 떠오르지 않을 것이다. 이러한 문제는 JarFileClassLoader와 NetworkClassLoader 간에 유기적인 결합을 할 수 없기 때문에 발생한다.

자바 2에서는 이러한 문제를 클래스로더 딜리게이션 모델을 통해서 해결하고 있다. 즉, 특정 클래스로더 클래스를 읽어온 클래스로더(이를 부모 클래스로더라고 한다)에게 클래스 로딩을 요청하는 것이다. 다음의 그림을 보자.


이 그림은 자바 2에서 클래스로더간의 관계를 보여주고 있다. 이 경우, NetworkClassLoader 클래스는 JarFileClassLoader가 로딩하고, JarFileClassLoader 클래스는 AppClassLoader가 로딩하였음을 보여준다. 즉, JarFileClassLoader는 NetworkClassLoader의 부모 클래스로더가 되고, AppClassLoader는 JarFileClassLoader의 부모 클래스로더가 되는 것이다.

이 경우, 앞에서 발생했던 문제가 모두 해결된다. A 클래스가 필요하면, 가장 먼저 NetworkClassLoader에 클래스로딩을 요청한다. 그럼, NetworkClassLoader는 네트워크로부터 A 클래스를 로딩할 수 있으므로, A 클래스를 로딩한다. 그런 후, A 클래스는 B 클래스를 필요로 한다. B 클래스를 로딩하기 위해 NetworkClassLoader는 JarFileClassLoader에 클래스 로딩을 위임(delegation)한다. JarFileClassLoader는 Jar 파일로부터 B 클래스를 읽어온 후 NetworkClassLoader에게 리턴할 것이며, 따라서 NetworkClassLoader는 Jar 파일에 있는 B 클래스를 사용할 수 있게 된다. 앞의 JDK 1.1에서의 클래스로더 사이의 관계에 비해 훨씬 발전적인 구조라는 것을 알 수 있다.

앞에서 말했듯이, 자바 2에서는 몇몇 클래스로더 메커니즘을 재정의하였다. 이 때문에, JDK 1.1에서의 클래스로더에 관한 몇몇개의 규칙이 깨졌다. 먼저, loadClass() 메소드를 더 이상 오버라이딩(overriding) 하지 않고, 대신 findClass()를 오버라이딩한다. loadClass() 메소드는 public에서 protected로 변경되었으며, 실제 JDK1.3의 ClassLoader 클래스의 소크 코드를 보면 다음과 같이 정의되어 있다.

  // src/java/lang/ClassLoader.java
  public abstract class ClassLoader {
      /*
       * The parent class loader for delegation.
       */
      private ClassLoader parent;
      
      protected synchronized Class loadClass(String name, boolean resolve)
      throws ClassNotFoundException
      {
          // First, check if the class has already been loaded
          Class c = findLoadedClass(name);
          if (c == null) {
              try {
                  if (parent != null) {
                      c = parent.loadClass(name, false);
                  } else {
                      c = findBootstrapClass0(name);
                  }
              } catch (ClassNotFoundException e) {
                  // If still not found, then call findClass in order
                  // to find the class.
                  c = findClass(name);
              }
          }
          if (resolve) {
              resolveClass(c);
          }
          return c;
      }
      ....
  }

위 코드를 보면 부모 클래스로더로부터 먼저 클래스 로딩을 요청하고, 그것이 실패할 경우(즉, catch 블럭)에 비로소 직접 클래스를 로딩한다. 여기서 그렇다면 부모 클래스는 어떻게 결정되는 지 살펴보자. 먼저 JDK 1.3의 ClassLoader 클래스는 다음과 같은 두 개의 생성자를 갖고 있다.

  protected ClassLoader(ClassLoader parent) {
      SecurityManager security = System.getSecurityManager();
      if (security != null) {
          security.checkCreateClassLoader();
      }
      this.parent = parent;
      initialized = true;
  }
  protected ClassLoader() {
      SecurityManager security = System.getSecurityManager();
      if (security != null) {
          security.checkCreateClassLoader();
      }
      this.parent = getSystemClassLoader();
      initialized = true;
  }

이 두 코드를 살펴보면, 부모 클래스로더를 지정하지 않을 경우, 시스템 클래스로더를 부모 클래스로더로 지정하는 것을 알 수 있다. 따라서 커스텀 클래스로더에서 부모 클래스로더를 지정하기 위해서는 다음과 같이 하면 된다.

  public class JarFileClassLoader extends ClassLoader {
     public JarFileClassLoader () {
        super(JarFileClassLoader.class.getClassLoader());
        // 다른 초기화 관련 사항
     }
     ....
     public Class findClass(String name) {
        // 지정한 클래스를 찾는다.
     }
  }

모든 클래스는 그 클래스에 해당하는 Class 인스턴스를 갖고 있다. 그 Class 인스턴스의 getClassLoader() 메소드를 통해서 그 클래스를 로딩한 클래스로더를 구할 수 있다. 즉, 위 코드는 JarFileClassLoader 클래스를 로딩한 클래스로더를 JarFileClassLoader 클래스로더의 부모 클래스로더로 지정하는 것이다. (실제로 커스텀 클래스로더를 구현하는 것에 대한 내용은 이 Article의 시리중에서 3번째에 알아보기로 한다).

JVM에서 부모 클래스로더를 갖지 않은 유일한 클래스로더는 부트스트랩 클래스로더이다. 부트스트랩 클래스로더는 자바 런타임 라이브러리에 있는 클래스를 로딩하는 역할을 맡고 있으며, 항상 클래스로더 체인의 가장 첫번째에 해당한다. 기본적으로 자바 런타임 라이브러리에 있는 모든 클래스는 JRE/lib 디렉토리에 있는 rt.jar 파일에 포함되어 있다.

결론

이번 Article에서는 자바에서 클래스 로딩이 동적으로 이루어지면, 클래스 로딩 방식에서는 로드타임 로딩과 런타임 로딩의 두 가지 방식이 있다는 것을 배웠다. 그리고 자바 2에서의 클래스로딩이 클래스로더 딜리게이션 모델(Classloader Delegation Model)을 통해서 이루어진다는 점과 이 모델에 자바 1.x에서의 클래스로딩 메커니즘과 어떻게 다르며, 어떤 장점이 있는 지 알아보았다. 다음 Article에서는 자바 2에서 기본적으로 제공하는 클래스로더에 대해서 알아보기로 한다.

  1. JunkMan 2013.05.10 09:51

    좋은 정보 감사합니다.

  2. bakgaksi 2015.03.03 03:21

    초보가 보기엔 무지막지 하네요 한... 6시간 동안 본듯. 그래도 무슨내용인지 모르겠어요 >.<

  3. 들개 2015.07.30 13:41

    다시봐도 정말 멋진 설명입니다. 최범균님 책보면서 jsp를 배웠었는데 ㅎㅎ.
    이렇게 지식공유해주시는 멋진 고수님들이 있어 정말 다행입니다.
    감사한 마음으로 봤습니다. 꾸벅.

  4. violet4795 2019.05.23 21:35 신고

    다른 글을 보며 왜? 라는 물음표를 띄우고 여기서 해결하네요 감사합니다.

+ Recent posts