주요글: 도커 시작하기
반응형
오픈 소스 프로젝트인 Log4j를 이용하여 자바 어플리케이션에서 빠르고 효과적인 로그 서비스를 구축할 수 있다.

Log4j

오늘날 프로젝트에서 많이 사용되는 웹서버, 어플리케이션 서버, DBMS를 비롯한 대부분의 상업용 어플리케이션은 그 어플리케이션에서 발생하는 사건들을 기록하기 위해 로그를 남기고 있다. 특히, 경험많은 개발자들은 로깅은 어플리케이션 개발 및 유지보수에 있어 중요한 요소임을 지적한다. 실제로 로그 기록을 남김으로써 몇가지 장점을 얻을 수 있다. 무엇보다도 로그는 어플리케이션이 실행되는 동안의 정확한 상황과 상태 정보를 제공한다. 둘째로, 로그 출력을 파일이나 DB와 같은 곳에 기록하여 나중에 로그 결과를 분석할 수 있다. 마지막으로, 개발 기간 중에 로그 패키지를 문제 검사 툴로 사용할 수도 있다.

카테고리, 어펜더 그리고 레이아웃

Log4j는 세 개의 주요 컴포넌트를 갖고 있다.

  • 카테고리(Category)
  • 어펜더(Appender)
  • 레이아웃(Layouts)
개발자는 메시지 타입과 우선순위에 따라 메시지를 기록하고 런타임에 이 메시지들의 포맷을 어떻게 작성하고 어디에 출력할지를 제어할 수 있도록 하기 위해 이 세개의 컴포넌트를 함께 사용한다. 이 세 가지 컴포넌트에 대해 차례대로 알아보도록 하자.

카테고리 계층(Category hierarchy)

몇몇 로깅 API 중 가장 좋은 장점은 특정한 기준에 따라 로그를 기록할지의 여부를 결정할 수 있다는 점이다. 이것은 로그에 기록될 모든 문장은 로깅 API 개발자가 정해 놓은 기준에 따라 분류된다는 것을 의미한다.

Log4j 역시 org.apache.log4j.Category 클래스를 통해서 이러한 분류 기준을 제시하고 있다. Category 클래스는 org.apache.log4j 패키지의 핵심 클래스이며, 카테고리를 나타낸다. 카테고리는 이름을 가진 개체이다. 카테고리의 이름은 자바의 패키지 이름과 비슷한 구조를 갖는다. 즉, 카테고리 이름은 com.javacan과 같은 형태를 가진다. 이 이름에 따라 카테고리는 부모 카테고리와 자식 카테고리로 구분된다. 예를 들어, com.javacan의 부모 카테고리의 이름은 com 이며, 이름이 com.javacan.article인 카테고리는 com.javacan의 자식 카테고리가 되는 것이다. 따라서, 카테고리 사이에는 계층이 형성된다.

계층의 가장 상위에 있는 카테고리를 루트 카테고리라고 하며, 루트 카테고리는 다음과 같은 특징을 갖고 있다.

  • 루트 카테고리는 항상 존재한다.
  • 이름을 사용하여 루트 카테고리를 읽어올 수 없다.
Category 클래스의 static 메소드인 getRoot() 메소드를 사용하여 루트 카테고리를 구할 수 있다. static 메소드인 getInstance() 메소드는 모든 다른 카테고리의 인스턴스를 생성한다. getInstnace() 메소드는 원하는 카테고리의 이름을 파라미터로 입력받는다. Category 클래스의 몇몇 기본 메소드는 다음과 같다.

package org.apache.log4j;

public class Category {

   // Creation & retrieval methods:
   public static Category getRoot();
   public static Category getInstance(String name);

   // printing methods:
   public void debug(String message);
   public void info(String message);
   public void warn(String message);
   public void error(String message);

   // generic printing method:
   public void log(Priority p, String message);

   .......
}

카테고리마다 org.apache.log4j.Priority 클래스에 정의된 값을 사용하여 우선순위를 지정할 수 있다. 현재 Priority 클래스에는 FATAL, ERROR, WARN, INFO, DEBUG의 5개의 우선순위가 정의되어 있다. 나열한 순서대로 우선 순위가 낮아진다. 겉으로 보기에는 제한된 집합을 갖도록 한 이유는 정적인 우선순위 집합보다 더욱 더 유연한 카테고리 계층을 만들 수 있도록 하기 위해서이다. 하지만, Priority 클래스를 상속받아서 자신만의 우선순위를 정의할 수도 있다.

만약 주어진 카테고리가 할당된 우선순위를 갖고 있지 않다면, 카테고리 계층도에서 할당된 우선순위를 갖고 있는 가장 가까운 상위 카테고리로부터 우선순위를 상속받는다. 따라서 루트 카테고리가 할당된 우선순위를 갖고 있을 경우 결과적으로 모든 카테고리를 그 우선순위를 상속받게 된다.

로깅 요청은 카테고리 인스턴스의 출력 메소드 중의 하나를 호출하면 된다. 출력 메소드는 다음과 같다.

  • error()
  • warn()
  • info()
  • debug()
  • log()
출력 메소드는 로깅 요청의 우선순위를 결정한다. 예를 들어, cat가 카테고리 인스턴라고 할 경우, cat.info("....")는 INFO 우선순위로 로깅을 요청한다. 만약 현재 요청한 로깅의 우선순위가 카테고리의 우선순위와 같거나 높으면 그 로깅 요청이 가능하다고 말한다. 그렇지 않을 경우 그 요청은 불가능하다고 한다.

다음은 로깅 요청의 가능/불가능 여부가 어떻게 처리되는 지를 보여주는 예이다.

// 이름이 "com.foo"인 카테고리 인스턴스를 구한다.
Category cat = Category.getInstance("com.foo");

// 카테고리의 우선순위를 설정한다.
cat.setPriority(Priority.INFO);

// WARN >= INFO 이기 때문에, 이 요청은 가능하다.
cat.warn("Low fuel level.");

// DEBUG < INFO 이기 때문에, 이 요청은 불가능하다.
cat.debug("Starting search for nearest gas station.");

// 이름이 "com.foo.Bar"인 카테고리의 인스턴스를 생성한다.
// 이 카테고리는 이름이 "com.foo"인 카테고리를 상속받는다.
// 따라서 이 카테고리 인스턴스는 INFO 우선순위를 갖는다.
Category barcat = Category.getInstance("com.foo.Bar");

// INFO >= INFO 이므로, 이 요청은 가능하다.
barcat.info("Located nearest gas station.");

// DEBUG < INFO 이므로, 이 요청은 불가능하다.
barcat.debug("Exiting gas station search");

같은 이름을 사용하여 getInstance() 메소드를 호출하면 항상 같은 카테고리 오브젝트에 대한 레퍼런스를 리턴한다. 따라서, 일단 특정한 이름을 갖는 카테고리 인스턴스를 설정하면, 그 인스턴스의 레퍼런스를 전달할 필요 없이 프로그램내의 어떤 곳에서든지 그 카테고리의 인스턴스를 읽어올 수 있다. 특정한 순서없이 카테고리를 생성 및 설정할 수 있다. 자식 카테고리를 생성한 이후에 부모 카테코리를 찾고 연결할 수 있다. Log4j 환경은 일반적으로 어플리케이션을 초기화할 때 설정하며, 특히 설정 파일을 읽어오는 시점에서 설정하는 경우가 많다.

Log4j에서 카테고리의 이름은 그 카테고리의 인스턴스를 생성할 때 사용한 클래스의 완전한 이름과 같에 짓는 것이 유용하고 카테고리를 정의하는 직관적인 방법이다. 로그에는 카테고리를 생성할 때 사용한 이름이 기록되기 때문에, 카테고리의 이름이 클래스의 이름과 같도록 하는 방법은 로그 메시지의 출처를 구분하는 데 도움을 준다. 이러한 방법이 일반적으이만, 이러한 방법 이외에도 다양한 방법을 사용하여 카테고리의 이름을 지을 수 있다. Log4j는 가능한 카테고리의 집합을 제한하고 있지 않으며, 개발자는 카테고리의 이름을 원하는 대로 지을 수 있다.

어펜더와 레이아웃

Log4j는 카테고리에 기반하여 로깅 요청의 가능/불가능 여부를 결정하는 기능 뿐만 아니라, 로깅 요청을 다중의 어펜더(appender)에 출력할 수 있다. 여기서 어펜더는 출력의 목적지를 나타낸다. 현재 콘솔, 파일, GUI 컴포넌트, 원격 소켓 서버, NT 이벤트 로거 그리고 원격 유닉스 시스로그 데몬으로 연결되는 어펜더가 존재한다.

카테고리는 다중의 어펜더를 참조할 수 있다. 카테고리에 들어온 각각의 가능한 로깅 요청은 그 카테고리에 있는 모든 어펜더에 전달되며, 뿐만 아니라 카테고리 계층의 상위에 있는 어펜더에도 전달된다. 즉, 어펜더는 카테고리 계층으로부터 상속된다. 예를 들어, 루트 카테고리에 콘솔 어펜더를 추가했다면, 모든 가능한 로깅 요청은 적어도 콘솔에 로그 메시지를 출력할 것이다. 만약 C라고 불리는 카테고리에 파일 어펜더를 추가했다면, C와 C의 자식 카테고리에 대한 가능한 로깅 요청은 콘솔과 파일에 메시지를 출력할 것이다.

출력 목적지 뿐만 아니라 출력 형식도 변경할 수 있다. 각각의 어펜더는 그 어펜더에 출력될 메시지의 형식을 있으며, 이는 그 어펜더와 특정 레이아웃(layout)을 관련시킴으로써 가능해진다. 레이아웃은 사용자가 지정한 값에 따라 로깅 요청의 포맷을 결정하고, 반면에 어펜더는 레이아웃을 통해 알맞은 포맷을 갖춰서 나온 것을 그것의 목적지에 출력한다. Log4j의 표준 배포판에 있는 PatternLayout은 사용자가 C 언어의 printf() 함수와 비슷한 변환 패턴에 따라 출력 포맷을 지정할 수 있도록 해준다.

예를 들어, 변환 패턴이 %r [%t]% -5p %c - %m%n 인 PatternLayout은 다음과 비슷한 결과를 출력한다.

176 [main] INFO org.foo.Bar - Located nearest gas station.

위의 출력 결과는 다음과 같다.

  • 첫번째 필드는 프로그램이 시작한 이후 경과한 시간(1/1000초 단위)을 나타낸다.
  • 두번째 필드는 로그 요청을 한 쓰레드를 나타낸다.
  • 세번째 필드는 로그의 우선순위를 나타낸다.
  • 네번째 필드는 로그 요청과 관련된 카테고리의 이름을 나타낸다.
나머지는 로그에 기록할 메시지이다.

Log4j의 설정

Log4j 환경은 프로그래밍 내에서 직접 설정할 수 있다. 하지만, 설정 파일을 사용함으로써 훨씬 더 유연하게 Log4j 환경을 설정할 수 있다. 현재, XML과 자바의 프로퍼티 형식을 사용하여 설정 파일을 작성할 수 있다.

간단한 어플리케이션을 통해서 설정 파일을 이용하여 Log4j 환경을 설정하는 것에 대하여 알아보자. 먼저 다음은 Log4j를 사용하는 간단한 어플리케이션인 TestLog4j 이다.

import com.foo.Bar;

import org.apache.log4j.Category;
import org.apache.log4j.BasicConfigurator;

public class TestLog4j {
    
    // cat는 이름이 "TestLog4j"인 카테고리 인스턴스를 가리키기 된다.
    static Category cat = Category.getInstance(TestLog4j.class.getName());
    
    public static void main(String[] args) {
        // 콘솔에 로깅하는 간단한 Configuration을 설정
        BasicConfigurator.configure();
        
        cat.info("Entering application.");
        Bar bar = new Bar();
        bar.doIt();
        cat.info("Exiting application.");
    }
}

위 코드에서 사용하는 com.foo.Bar 클래스는 다음과 같다.

package com.foo; 
 
import org.apache.log4j.Category; 
 
public class Bar { 
    static Category cat = Category.getInstance(Bar.class.getName()); 
     
    public void doIt() { 
        cat.debug("Did it again!"); 
    } 

TestLog4j 에서, BasicConfigurator.configure() 메소드를 호출함으로써 다소 간단한 Log4j 셉업을 설정한다. 이 메소드는 루트 카테고리에 PatternLayout.TTCC_CONVERSION_PATTERN을 사용하는 PatternLayout을 사용하고 System.out에 출력하는 FileAppender를 추가한다. 현재, Log4j 1.0.4 버전에서TTCC_CONVERSION_PATTERN의 값은 다음과 같다.

%r [%t] %p %c %x - %m%n

TestLog4j.java의 출력 결과는 다음과 같다.

0 [main] INFO TestLog4j  - Entering application.  
30 [main] DEBUG com.foo.Bar  - Did it again!  
40 [main] INFO TestLog4j  - Exiting application.  

여기서 TestLog4j 클래스에서 BasicConfigurator.configure()를 호출함으로써 Log4j를 설정하기 때문에, Bar와 같이 다른 클래스에서는 단순히 org.apache.log4j.Category 클래스를 임포트하여 사용하기만 하면 된다.

TestLog4j 클래스를 실행할 때 마다 TestLog4j는 Log4j 환경을 매번 갖은 것으로 설정한다. 따라서 로그의 출력 결과도 매번 같은 곳(이 경우 콘솔)으로 전달된다. 하지만, Log4j 환경을 런타임에 설정하길 원하는 경우도 있을 것이다. 이는 설정 파일을 사용함으로써 가능해진다. 다음은 TestLog4j를 약간 변경하여 설정 파일을 사용하여 Log4j 환경을 설정하는 TestLog4j2 클래스의 소스 코드이다.

import com.foo.Bar;

import org.apache.log4j.Category;
import org.apache.log4j.PropertyConfigurator;

public class TestLog4j2 {
    
    static Category cat = Category.getInstance(TestLog4j2.class.getName());
    
    public static void main(String[] args) {
        // BasicConfigurator 대신 PropertyConfigurator 사용
        PropertyConfigurator.configure(args[0]);
        
        cat.info("Entering application.");
        Bar bar = new Bar();
        bar.doIt();
        cat.info("Exiting application.");
    }
}

TestLog4j2 클래스를 보면 PropertyConfigurator 클래스를 사용하여 설정 파일을 분석한 후 로깅을 설정하도록 하고 있다.

TestLog4j 클래스와 TestLog4j2 클래스가 거의 같은 결과를 출력하도록 해주는 예제 설정 파일을 살펴보자. 예제 설정 파일은 다음과 같다.

# 루트 카테고리의 우선순위를 DEBUG로 설정하고, 유일한 어펜더를 A1으로 설정
log4j.rootCategory=DEBUG, A1# A1을 System.out으로 출력하는 FileAppender로 설정
log4j.appender.A1=org.apache.log4j.FileAppender
log4j.appender.A1.File=System.out

# A1은 PatternLayout을 사용한다.
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n

위 내용을 test2.properties 파일로 저장한 후, 다음과 같이 TestLog4j2 클래스를 실행해보자.

java TestLog4j2 test2.properties

그러면 다음과 같은 결과가 출력될 것이다.

0    [main] INFO  TestLog4j2  - Entering application.   
10   [main] DEBUG com.foo.Bar  - Did it again!   
10   [main] INFO  TestLog4j2  - Exiting application.

출력 결과를 보면 앞의 TestLog4j의 출력 결과와 앞의 숫자를 제외한 나머지 부분은 완전히 같다는 것을 알 수 있다. 만약 com.foo 패키지에 속해 있는 컴포넌트의 출력을 보고 싶지 않다면, 다음과 같은 설정 파일을 만들면 된다.

log4j.rootCategory=DEBUG, A1
log4j.appender.A1=org.apache.log4j.FileAppender
log4j.appender.A1.File=System.out
log4j.appender.A1.layout=org.apache.log4j.PatternLayout

# ISO 8601 형식으로 날짜를 출력한다.
log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

# com.foo 패키지에서는 오직 WARN과 같거나 높은 우선순위를 같는 메시지만 출력한다.
log4j.category.com.foo=WARN

이 설정 파일을 test2-1.properties로 저장한 후 TestLog4j2를 다음과 같이 실행해보자.

java TestLog4j2 test2-1.properties

그러면 다음과 같은 결과가 출력된다.

2001-01-18 14:41:45,736 [main] INFO  TestLog4j2 - Entering application.   
2001-01-18 14:41:45,746 [main] INFO  TestLog4j2 - Exiting application.   

출력 결과를 보면 Bar와 관련된 로그 메시지가 출력되지 않는 것을 알 수 있다. com.foo.Bar 카테고리는 우선순위를 할당하지 않았기 때문에, com.foo 카테고리의 우선순위를 상속받으며, test2-1.properties 설정 파일에서 com.foo의 카테고리를 WARN으로 지정하였기 때문에 com.foo.Bar 카테고리는 WARN의 우순선위를 갖는다. Bar.doIt() 메소드에 있는 로그 문장은 DEBUG 우선순위를 갖고 있으며, DEBUG는 WARN 보다 우선 순위가 낮기 때문에, doIt()의 로그 요청은 처리되지 않는다.

이제 다중의 어펜더를 사용하는 설정 파일을 살펴보자.

log4j.rootCategory=debug, stdout, R

log4j.appender.stdout=org.apache.log4j.FileAppender
log4j.appender.stdout.File=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout

# 콜러의 파일 이름과 라인 번호를 출력하는 패턴
log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n

log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=example.log

log4j.appender.R.MaxFileSize=100KB
# 한 개의 백업 파일을 유지한다.
log4j.appender.R.MaxBackupIndex=1

log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n

이 내용을 test3.propeties 파일에 저장한 후, 'java TestLog4j2 test3.properties'을 실행해보자. 그럼 출력 결과는 다음과 같을 것이다.

 INFO [main] (TestLog4j2.java:14) - Entering application.
DEBUG [main] (Bar.java:9) - Did it again!
 INFO [main] (TestLog4j2.java:17) - Exiting application.

뿐만 아니라 루트 카테고리에 두번째 어펜더를 할당했기 때문에, example.log 파일에 직접적으로 로그 내용이 출력된다. 이 파일의 크기가 100KB에 다다를 경우 자동적으로 example.log 파일은 example.log.1로 옮겨지고, example.log 파일에는 처음부터 로그가 저장되기 시작한다. 여기서 주목할 점은 로깅 기능을 변경하기 위해서 코드를 재 컴파일 할 필요가 없다는 점이다. 설정 파일만 변경함으로써 매우 쉽게 유닉스 시스로그 데몬에 로그를 출력할 수도 있고 모든 com.foo 출력을 NT 이벤트 로거에 전달할 수도 있다.

NDC(Nested Diagnostic Contexts)

오늘날 사용되는 웹 어플리케이션은 다중 클라이언트가 동시에 접근하는 것을 기본적으로 가정하고 있다. 이러한 시스템은 일반적으로 하나의 쓰레드가 하나의 클라이언트를 처리하도록 구현되어 있으며, 로그 시스템의 경우 다중 클라이언트가 접속한 것을 손쉽게 추적하고 더 나아가 디버깅할 수 있도록 구현되어야 한다. 이 경우 클라이언트마다 별도의 카테고리 인스턴스를 생성하도록 할 수 있다. 하지만, 이 방법은 클라이언트 수에 비례하여 카테고리의 인스턴스 개수가 증가할 뿐만 아니라 로깅을 관리하는 데 따른 오버헤드가 발생하게 된다.

또 다른 방법으로는 하나의 카테고리를 사용하여 모든 클라이언트의 로그 기록을 남기는 것이다. 이 때 각각의 로그 요청은 다른 로그 요청과 구별되는 고유의 표식을 가져야 한다. 이러한 고유의 표식을 지정할 수 있도록 하기 위해 Log4j는 org.apache.log4j.NDC 클래스를 제공한다. 참고로 NDC는 Nested Diagnostic Context의 약자이다. NDC 클래스는 다음과 같은 메소드를 제공하고 있다.

// diagnostic을 출력할 때 사용
public static String get();

// NDC에 있는 최상위에 있는 콘텍스트를 제거
public static String pop();

// 현재 쓰레드를 위한 diagnostic 콘텍스트 추가
public static void push(String message);

// 현재 쓰레드에 해당하는 diagnostic 콘텍스트 제거
public static void remove();

여기에 명시한 메소드 뿐만 아니라 그 외의 NDC 클래스에 정의된 다른 메소드 역시 static으로 정의되어 있다. 먼저 위에 나열한 메소드에 대해서 설명하기 전에 NDC 클래스를 이용하는 코드를 살펴보자.

import org.apache.log4j.Category;
import org.apache.log4j.PropertyConfigurator;
import org.apache.log4j.NDC;

public class TestNDC {
    
    static Category cat = Category.getInstance(TestLog4j2.class.getName());
    
    public static void logging(String uniqueId, String message) {
        NDC.push(uniqueId);
        cat.info(message);
        NDC.push(uniqueId+"-"+uniqueId);
        cat.info(message);
        NDC.pop();
        cat.info(message);
        NDC.pop();
    }
    
    public static void main(String[] args) {
        // BasicConfigurator 대신 PropertyConfigurator 사용
        PropertyConfigurator.configure(args[0]);
        
        cat.info("Entering application.");
        
        logging(args[1], "NDC test");
        
        cat.info("Exiting application.");
    }
}

위 코드를 TestNDC.java로 저장한 후, 컴파일 하자. TestNDC에서 사용할 설정 파일인 ndc.properties는 다음과 같다.

log4j.rootCategory=debug, stdout

log4j.appender.stdout=org.apache.log4j.FileAppender
log4j.appender.stdout.File=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout

log4j.appender.stdout.layout.ConversionPattern=NDC=[%x] Thread=[%t] - %m%n

위 설정 파일 내용에서 %x는 NDC의 현재 스택에 들어가 있는 콘텍스트 정보를 나타낸다. 이 정보는 NDC.push() 메소드를 사용하여 입력한다. 이제 다음과 같이 TestNDC 클래스를 실행해 보자.

java TestNDC ndc.properties uniID

실행 결과는 다음과 같을 것이다.

NDC=[] Thread=[main] - Entering application.    
NDC=[uniID] Thread=[main] - NDC test    
NDC=[uniID uniID-uniID] Thread=[main] - NDC test    
NDC=[uniID] Thread=[main] - NDC test    
NDC=[] Thread=[main] - Exiting application.

위 실행 결과를 보면 먼저 main() 메소드에서 호출한 cat.info() 메소드의 로그 결과에는 %x 부분이 없는 것을 알 수 있다. 이제 logging() 메소드 부분을 살펴보자. TestNDC 클래스는 logging() 메소드 내에서 NDC 클래스를 사용한다. 먼저 logging() 메소드는 NDC.push() 메소드를 호출하여 하나의 컨텍스트 정보를 저장한다. NDC 클래스는 이 정보를 스택을 나타내는 Stack 클래스를 사용하여 저장하며, 이 정보는 로그를 출력할 때 %x 부분에 표시된다. 출력 결과의 두번째 줄을 보면 %x 부분에 NDC.push() 메소드에 전달해준 컨텍스트 정보가 출력되는 것을 알 수 있다. 스택에 저장한 컨텍스트 정보는 NDC.pop() 메소드를 사용하여 차례대로 빼낼 수 있다.

이렇게 추가한 컨텍스트 정보는 각각의 쓰레드마다 별도로 저장된다. 즉, NDC 클래스는 그 클래스의 메소드를 호출한 각각의 쓰레드 마다 별도의 스택을 사용하며, 따라서 각각의 쓰레드는 서로 상대방의 컨텍스트 정보에 영향을 끼치지 않는다. 참고로 NDC 클래스는 "Pattern Languages of Program Design 3"의 "Patterns for Logging Diagnostic Messages" 부분의 Neil Harrison이 정의한 nested diagnostic contexts를 구현하였다.

결론

Log4j API의 장점 중의 하나는 로그를 관리하기 쉽다는 것이다. 일단 로그관련 문장을 코드에 삽입하면, 코드의 변경없이 설정 파일을 통해서 로그를 관리할 수 있다. 또한, 선택적으로 로그 요청의 가능/불가능 여부를 결정할 수 있으며, 사용자가 정의한 형식으로 다양한 출력 대상에 로그 메시지를 전달할 수 있다. 또한, NDC 클래스를 사용함으로써 좀더 분석이 용이한 로그를 기록할 수 있다.

관련링크:

+ Recent posts