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

고절가주팁 다섯번째 글에 대한 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란 무엇인가를 클릭하세요.