고수들이 절대 가르쳐 주지 않는 C/C++ 프로그래밍 팁 #5 A/S - 로깅 라이브러리 기본 개념

Posted at 2007.07.26 15:00 // in S/W개발/고절가주팁 // by 김윤수


고절가주팁 다섯번째 글에 대한 A/S 글입니다. 저번 글에서 제가 나름대로 생각하는 로깅 라이브러리 요구사항을 나열해 봤는데요, 몇 몇 분께서 또 고려해 볼만한 요구사항을 얘기해 주셔서 한 번 다시 정리해 보고, 어떤 식으로 그런 요구 사항을 만족시킬 수 있을지 개략적인 방안을 생각해 보려고 합니다.

제가 제안했던 로깅 라이브러리 요구사항은 다음과 같습니다.

1. 어떤 모듈, 어떤 소스 파일의 어느 함수, 어느 위치에서 발생한 정보인지 출력할 것. 주로 디버깅 시에 유용함
2. 로깅 정보가 다양한 목적지로 저장 또는 전송될 수 있을 것
3. 모듈별로 로깅을 활성화 또는 비활성화할 수 있을 것
4. 로깅의 상세한 정도를 조정할 수 있을 것
5. 아주 상세한 디버깅 정보들은 Production 시스템에서는 자동으로 제외될 것
6. 모듈별 로깅 활성화나 로깅의 상세한 정도는 실행시에도 조정할 수 있을 것

이 것외에 몇 몇 분이 제안하신 추가적인 요구사항은 다음과 같습니다.

7. 원격지로 로깅을 전송할 때 암호화/복호화을 수행할 것
8. 로그를 기록할 때 날짜와 시간을 기록할 것
9. 로그를 날짜별, 시간별로 다른 파일로 기록할 것
10. 로그 파일이 지정된 크기를 넘을 경우 자동으로 다른 파일에 기록을 시작할 것
11. 반복되는 로깅 정보를 축약해서 기록할 것

이 요구사항들을 한 번 찬찬히 들여다 보니 몇 가지 기본적인 개념을 뽑아낼 수 있을 것 같습니다.

(Log Source) ----------------------------------------> (Log Sink)
                     ^                       ^              ^
                     |                       |              |
             (Log Formatter)           (Log Filter)  (Logging Policy)

요구사항 1.의 로깅을 발생한 위치는 Log Source 라는 개념으로 매핑할 수 있을 것이고, 요구사항 2.의 다양한 목적지는 Log Sink 라는 개념으로 매핑할 수 있을 것 같습니다. 음... 그리고, 요구사항 3.의 모듈별로 로깅을 활성화하는 것이라던지 요구사항 4.의 로깅의 상세한 정도를 조정한다던지 요구사항 5.의 상세한 디버깅 정보가 Production 시스템에서는 자동으로 제외될 것이라던지 요구사항 11.의 반복되는 로깅 정보를 축약할 것이라던지 하는 것은 Log Filter 개념으로 매핑할 수 있을 것 같습니다. 그리고, 마지막으로 요구사항 1.이나 요구사항 8.에서 어떤 정보를 로그에 기록할 것인가 하는 것은 Log Formatter 개념에 매핑될 수 있을 것입니다.

그 외에 요구사항 7.의 원격지로 로그를 전송할 때 암호화/복호화하는 것, 요구사항 9.의 로그를 날짜별, 시간별로 기록하는 것, 로그 파일이 지정된 크기를 넘을 경우 다른 파일에 기록하는 것 등은 모두 Log Sink 가 나름의 로그를 저장(또는 전송)하는 Logging Policy 를 가지고 있으면 될 것으로 생각합니다.

이런 Log Source, Log Sink, Log Formatter, Log Filter, Logging Policy 등의 개념으로 일반화해 놓고 필요에 따라 Log Filter 또는 Log Formatter 를 중간에 끼워 넣고 빼고 할 수 있게 하고, 각각의 Log Filter 또는 Log Formatter 는 서로 서로 연결되게 해 놓으면 상당히 flexible 한 로깅 라이브러리가 될 것 같습니다. 이렇게 하면 여기에 제안되었던 요구사항 외에 추가적인 요구사항이 있더라도 쉽게 지원할 수 있는 로깅 라이브러리가 될 것입니다. 여러분은 어떻게 생각하시나요 ?

또, 요구 사항을 자세히 들여다 보니 몇 가지 질문이 떠오릅니다.

1. 요구사항 3. 과 관련하여 모듈이라는 걸 어떤 단위로 정의해야 하는 걸까요 ? 로깅 라이브러리를 사용하는 S/W 내에 모듈 구조가 flat 한 구조인 걸 가정해야할까요 ? 아니면 계층적인 구조를 가정해야 할까요 ? 계층적인 구조라면 상위 모듈의 로깅을 활성화/비활성화시키면 그 안에 포함된 모듈에 대한 로깅은 어떻게 작동해야 할까요 ?
2. 로깅의 상세한 정도는 어떻게 나누어야 할까요 ? 그냥 1 ~ 255 정도로 나눌까요 ? 아니면 몇 가지 잘 알려진 수준을 두는 것으로 할까요 ?
3. 암호화/복호화, 로깅 정보 축약, 날짜별/시간별 별도 파일 기록, 일정 크기를 넘을 때 다른 파일로 기록하는 등을 로깅 라이브러리 자체에서 구현하도록 할 까요 ? 아니면 별도의 Extension Mechanism 을 두고 로깅 라이브러리 사용자가 직접 구현하도록 할까요 ?

여러분들은 이런 질문들에 대해 어떤 답변을 가지고 계신가요 ?

다음 글에서는 이런 질문들에 대해 답변해 보고, 로깅 라이브러리 설계 작업을 시작해 보도록 하겠습니다. 고절가주팁이 쭉~ 갈 수 있도록 많은 관심 부탁드리고, 혹시 잘못된 부분이나 보완할 부분이 있으면 언제라도 알려주세요.

제 글이 유익하셨다면 오른쪽 버튼을 눌러 제 블로그를 구독하세요. ->
블로그를 구독하는 방법을 잘 모르시는 분은 2. RSS 활용을 클릭하세요.
RSS에 대해 잘 모르시는 분은 1. RSS란 무엇인가를 클릭하세요.

신고
  1. rein

    2007.07.26 17:45 신고 [수정/삭제] [답글]

    1. 모듈이란 단위는 java나 python 처럼 팩키지에 가까운 개념이 있지 않는한 쉽게 끊어서 나타내기는 힘들다고 생각합니다. 차라리 개별 서브 시스템 단위에서 논리적으로(쉽게 말해서 사용자 정의에 떠넘기기) 표현하는 단위를 찾아서 설계하는 수밖에 없다고 생각합니다 - 물론 이렇게 사용자에게 떠 넘기려면 설정 파일? 형식이 유연해야할것입니다.
    Apache project에서 진행되고있는 로거 프로젝트인 log4j의 C++버젼인 log4cxx에서도 그냥 사용자가 자바 팩키지스러운 포맷으로 모듈을 정의할 수 있게 해주고 있습니다.
    (예를 들어 <logger='subsystem1'/> <logger='subsystem1.module_group1'/> 하는 식으로요)

    2. 로깅 수준이 너무 많으면 실제로 사용하는데 어렵지 않을까 라고 생각합니다. 256단계의 구분을 사용자가 기억하고 적용하기는 괴롭지않을까요 :) 실제로 많은 경우에 로깅 수준은 Trace(or Debug?), Info., Warn., Error, Fatal 정도인 것 같습니다. (PHP나 apache같은 시스템을 놓고 보면)

    3. 이 부분은 log sinker 들의 인터페이스를 제공하고, 해당 인터페이스를 구현한 클래스를 추가하기 쉽게 하면 어떨까 합니다. 암호화나 log rotation같은 부분을 기본적으로 제공하기는 너무 라이브러리가 방대해지지 않을까요.
    물론 일차(?)적으로 라이브러리를 완성한 후에 붙이기 쉬운 상태에서 계속 붙여가는 형식이라면 가능할듯도 합니다만은.

    • 김윤수

      2007.07.26 22:01 신고 [수정/삭제]

      우선 코멘트 감사합니다. 세가지 질문에 대해서 거의 저와 비슷한 생각을 하고 계신 것 같습니다. 물론 이런식으로 결정하려면 숨겨져 있는 비기능적요구사항을 명확히 해야하는 것이겠지만... 지금 제가 생각하고 있는 것도 rein 님과 거의 비슷합니다.

  2. 어쩌다가..코더

    2007.07.27 02:10 신고 [수정/삭제] [답글]

    수고하십니다. ^^;
    좋은 글과 리플이 많이 나오는 군요. 많은 눈팅이 되는 것같습니다..
    저번에 로그 보안 처리에 대한 얘기를 약간만 더 해 보겠습니다.ㅎㅎ
    제가 느껴본 바로는 로그 암호화도 암호화 알고리즘 선정 문제, 운영 문제 등등 이
    있는 것 같습니다. 왜냐하면 모든 회사가 금감원 권장 수준의 보안 처리를 할 환경이
    안 되는 영세 업체가 많기 때문이죠. (아니면 IT 의사 결정 담당자가 왜 보안이
    필요한지 조차도 모르는 경우가 다수입니다.)
    그리고 원격지 로그라는 문제와, 로그 정보 자체가 원격지 사용자의 "개인 정보"라는
    점이 매우 중요하기 때문입니다. 만약 '누출'된다면 고객사(물론 상업용 프로그램일 경우)
    에게 치명적인 적인 동시에 제공 업체에게도 큰 타격이 되기 때문이죠...-_-;
    (잘못하면 사표 쓸지도ㅋㅋ)

  3. 초보플머

    2015.06.02 06:56 신고 [수정/삭제] [답글]

    정말 대단하십니다. 다른 사람들의 요구사항까지 추가해서.. 정리 해주시다니.. 대단하십니다 ^^

    항상 도움되는글 잘 보고 가고 있습니다. 감사합니다.

댓글을 남겨주세요.