Poor Logging Practice: Use of a System Output Stream

전용 로깅 기능 대신 Console.Out 또는 Console.Error를 사용하면 프로그램의 동작을 모니터링하기가 어렵습니다.

예제 1: 개발자가 배우는 과정에서 작성하는 첫 .NET 프로그램은 다음과 같습니다.

public class MyClass {
  ...
    Console.WriteLine("hello world");
  ...
}

대부분의 프로그래머가 .NET의 수많은 노하우와 세부 사항을 배우게 되지만 상당수의 프로그래머가 이 첫 수업에 집착한 나머지 Console.WriteLine()을 사용하여 표준 출력에 대한 메시지를 쓰는 것을 그만두지 않습니다.

문제는 표준 출력이나 표준 오류에 직접 쓰는 것이 구조화되지 않은 형식의 로깅으로 이용되는 일이 잦다는 점입니다. 구조화된 로깅 기능은 로깅 수준, 단일 서식, 로거 ID, 타임스탬프 및 무엇보다 중요한, 로그 메시지를 올바른 위치에 보내는 기능 등의 기능을 제공합니다. 시스템 출력 스트림 사용이 로거를 올바로 사용하는 코드와 혼합되면 잘 기록되긴 했지만 중요한 정보가 누락된 로그가 생성됩니다.

개발자는 구조화된 로깅의 필요성을 폭넓게 이해하지만 상당수가 "운용 전" 개발 단계에서 시스템 출력 스트림을 계속 사용합니다. 검토 중인 코드가 초기 개발 단계를 지난 경우, Console.WriteLine 사용이 발견되면 이는 구조화된 로깅 시스템으로 옮겨가는 도중 실수한 것일 수 있습니다.

전용 로깅 기능 대신 os.Stdout 또는 os.Stderr를 사용하면 프로그램의 동작을 모니터링하기가 어렵습니다.

예제 1: 일반적으로 개발자가 배우는 과정에서 작성하는 첫 Go 프로그램은 다음과 같습니다.

...

func foo(){
    fmt.Println("Hello World")
}

대부분의 개발자가 Go의 수많은 노하우와 세부 사항을 배우게 되지만 일부는 fmt.Println()을 사용하여 표준 출력에 메시지를 쓰는 것을 그만두지 않습니다.

문제는 표준 출력이나 표준 오류에 직접 쓰는 것이 구조화되지 않은 형식의 로깅으로 이용되는 일이 잦다는 점입니다. 구조화된 로깅 기능은 로깅 수준, 단일 서식, 로거 식별자, 타임스탬프 및 로그 메시지를 올바른 위치로 보내는 기능과 같은 기능을 제공합니다. 시스템 출력 스트림 사용이 로거를 올바로 사용하는 코드와 혼합되면 잘 기록되긴 했지만 중요한 정보가 누락된 로그가 생성됩니다.

구조화된 로깅은 널리 사용되지만 여전히 시스템 출력 스트림을 "프로덕션 전" 개발에 사용하는 개발자가 많습니다. 검토 중인 코드가 초기 개발 단계를 지난 경우, os.Stdout 또는 os.Stderr 로깅은 구조화된 로깅 시스템으로 옮겨가는 도중 실수한 것일 수 있습니다.

전용 로깅 기능 대신 process.stdout 또는 process.stderr를 사용하면 프로그램의 동작을 모니터링하기가 어렵습니다.

예제 1: 초기 Node.js 개발자가 stdin에서 읽고 다시 stdout에 쓰기 위해 작성할 수 있는 간단한 프로그램은 다음과 같습니다.

process.stdin.on('readable', function(){
    var s = process.stdin.read();
    if (s != null){
      process.stdout.write(s);
    }
});

대부분의 프로그래머가 특히 JavaScript 및 Node.js의 수많은 노하우와 세부 사항을 배우게 되지만 상당수의 프로그래머가 이 첫 수업에 집착한 나머지 process.stdout.write()를 사용하여 표준 출력에 메시지를 쓰는 것을 그만두지 않습니다.

문제는 표준 출력이나 표준 오류에 직접 쓰는 것이 구조화되지 않은 형식의 로깅으로 이용되는 일이 잦다는 점입니다. 구조화된 로깅 기능은 로깅 수준, 단일 서식, 로거 ID, 타임스탬프 및 무엇보다 중요한, 로그 메시지를 올바른 위치에 보내는 기능 등의 기능을 제공합니다. 시스템 출력 스트림 사용이 로거를 올바로 사용하는 코드와 혼합되면 잘 기록되긴 했지만 중요한 정보가 누락된 로그가 생성됩니다.

개발자는 구조화된 로깅의 필요성을 폭넓게 이해하지만 상당수가 "운용 전" 개발 단계에서 시스템 출력 스트림을 계속 사용합니다. 검토 중인 코드가 초기 개발 단계를 지난 경우, process.stdout 또는 process.stderr 사용이 발견되면 이는 구조화된 로깅 시스템으로 옮겨가는 도중 실수한 것일 수 있습니다.

전용 로깅 기능 대신 print 또는 println를 사용하면 프로그램의 동작을 모니터링하기가 어렵습니다.

예제 1: 개발자가 배우는 과정에서 작성하는 첫 Kotlin 프로그램은 다음과 같습니다.

class MyClass {
    ...
        println("hello world")
    ...
    }
}

대부분의 프로그래머가 Kotlin의 수많은 노하우와 세부 사항을 배우게 되지만 상당수의 프로그래머가 이 첫 수업에 집착한 나머지 print 또는 println를 사용하여 표준 출력에 메시지를 쓰는 것을 그만두지 않습니다.

문제는 표준 출력이나 표준 오류에 직접 쓰는 것이 구조화되지 않은 형식의 로깅으로 이용되는 일이 잦다는 점입니다. 구조화된 로깅 기능은 로깅 수준, 단일 서식, 로거 식별자, 타임스탬프 및 무엇보다 중요한, 로그 메시지를 올바른 위치에 보내는 기능 등의 기능을 제공합니다. 시스템 출력 스트림 사용이 로거를 올바로 사용하는 코드와 혼합되면 잘 기록되긴 했지만 중요한 정보가 누락된 로그가 생성됩니다.

개발자는 구조화된 로깅의 필요성을 폭넓게 이해하지만 상당수가 "운영 전" 개발 단계에서 시스템 출력 스트림을 계속 사용합니다. 검토 중인 코드가 초기 개발 단계를 지난 경우, 표준 출력 또는 오류 스트림 사용이 발견되면 이는 구조화된 로깅 시스템으로 옮겨가는 도중 실수한 것일 수 있습니다.

전용 로깅 기능 대신 표준 출력 또는 표준 오류 방식을 사용하면 프로그램의 동작을 모니터링하기가 어렵습니다.

예제 1: 개발자가 배우는 과정에서 작성하는 첫 Python 프로그램은 다음과 비슷합니다.

sys.stdout.write("hello world")

대부분의 프로그래머가 Python의 수많은 노하우와 세부 사항을 배우게 되지만 상당수의 프로그래머가 이 첫 수업에 집착한 나머지, 표준 출력에 메시지를 쓰는 것을 그만두지 않습니다.

문제는 표준 출력이나 표준 오류에 직접 쓰는 것이 구조화되지 않은 형식의 로깅으로 이용되는 일이 잦다는 점입니다. 구조화된 로깅 기능은 로깅 수준, 단일 서식, 로거 ID, 타임스탬프 및 무엇보다 중요한, 로그 메시지를 올바른 위치에 보내는 기능 등의 기능을 제공합니다. 시스템 출력 스트림 사용이 로거를 올바로 사용하는 코드와 혼합되면 잘 기록되긴 했지만 중요한 정보가 누락된 로그가 생성됩니다.

개발자는 구조화된 로깅의 필요성을 폭넓게 이해하지만 상당수가 "운용 전" 개발 단계에서 시스템 출력 스트림을 계속 사용합니다. 검토 중인 코드가 초기 개발 단계를 지난 경우, sys.stdout 또는 sys.stderr 사용이 발견되면 이는 구조화된 로깅 시스템으로 옮겨가는 도중 실수한 것일 수 있습니다.

전용 로깅 기능 대신 Kernel.puts,Kernel.warn 또는 Kernel.printf를 사용하면 프로그램의 동작을 모니터링하기가 어렵습니다.

예제 1: 개발자가 배우는 과정에서 작성하는 첫 Ruby 프로그램에는 흔히 다음과 같은 기능이 포함됩니다.

...
puts "hello world"
...

대부분의 프로그래머가 Ruby의 수많은 노하우와 세부 사항을 배우게 되지만 상당수의 프로그래머가 이 첫 수업에 집착한 나머지 Kernel.puts을 사용하여 표준 출력에 메시지를 쓰는 것을 그만두지 않습니다.

문제는 표준 출력이나 표준 오류에 직접 쓰는 것이 구조화되지 않은 형식의 로깅으로 이용되는 일이 잦다는 점입니다. 구조화된 로깅 기능은 로깅 수준, 단일 서식, 로거 ID, 타임스탬프 및 무엇보다 중요한, 로그 메시지를 올바른 위치에 보내는 기능 등의 기능을 제공합니다. 시스템 출력 스트림 사용이 로거를 올바로 사용하는 코드와 혼합되면 잘 기록되긴 했지만 중요한 정보가 누락된 로그가 생성됩니다.

개발자는 구조화된 로깅의 필요성을 폭넓게 이해하지만 상당수가 "운용 전" 개발 단계에서 시스템 출력 스트림을 계속 사용합니다. 검토 중인 코드가 초기 개발 단계를 지난 경우, Kernel.puts,Kernel.warn 또는 Kernel.printf 사용이 발견되면 이는 구조화된 로깅 시스템으로 옮겨가는 도중 실수한 것일 수 있습니다.
회사의 정책에 따라 이러한 API를 사용할 수 없는 경우에는 로깅 시스템을 통해 정보를 시스템 출력 스트림으로 인쇄하는 방식으로 이를 여전히 해결할 수 있습니다.

예제 2: 다음 코드에서는 Logger 클래스를 사용하지만 시스템 출력 스트림에 정보를 기록합니다.

require 'logger'
...
logger = Logger.new($stdout)
logger.info("hello world")
...