로그시스템 (Log System)에 대한 고찰

프로그래밍/프로그래밍 메모장 2006/09/16 00:35
로그 시스템에 대한 고찰
- 이 글의 ... 해야 된다 라는 형태의 문구는 기본적으로 '나의 생각은 이렇게
하는 것이 좋을 것 같다' 라는 의미로 받아주기 바랍니다.
언제나 정확한 답은 없다고 생각합니다. 다만 이런 방법도 있다는 것이죠.


- by Xevious7(황의범) 2006년 9월16일
들어가는 이야기.

로그(Log) 하면 먼저 떠오르는 것은 통나무  >>.<<
왜냐? 그 이름도 유명한 울티마 사실은 내가 제일 좋아하는 게임이다.
중학교때 이게임을 처음할때 사전찾아가면서 외웠던 단어들 중에 하나가 바로 이 log
통나무이다. 그외에도 가릭(garlic, 마늘) 같은 마법시약의 재료라든지 래들(ladle,국자)
같은 14세기 영국의 기초물품이라든지 , 볼륩튜어스(voluptuous, 관능적인 매혹적인)
같은 인간에 대한 묘사 형용사라든지 , 중학교 수준에서는 접하기 힘든 단어들을
이 게임에서 많이 알게 되었던 기억이있다. Apple 컴퓨터는 가장 사고 싶었던 물품목록
이었다.

[그림] 통나무집. 울티마(Ultima Online) Second Age
                                           - 99년 플레이했던 나의 실제 스크린샷을 편집

애플사의 한잎베어진 사과 도안 난 이 도안의 사과가 과장된 것으로 생각했다.
하지만 포틀랜드 공항에서 어떤 종인지는 모르겠지만 정말 이 도안과 똑같은
사과를 사먹었다. 우리나라 사과는 움푹파인 부분의 곡선이 완만하지만 그곳의
사과는 애플사의 로고처럼 상당하게 꺽여들어간다. 로고의 모양은 미국의 사과를
본뜬 거였다. 과장이라고 생각했는데 과장이 아닌 모양를 그대로 도안한거였다.!
그러나 맛은 정말 최악의 맛이였다. 왜 그들이 사과를 구워먹는지 확실히 알수있었다.
그냥 먹기엔 너무나 맛없는 사과였다.
일본 사과도 맛없긴 마찬가지이다. 가장 맛있는 사과는 우리나라 사과이다.!



로그의 의미와 로그를 만드는 이유

로그 하면 젤 먼저 떠오르는게 통나무라고 하여도...
컴퓨터 세계에서의 로그라 하면 이 통나무와는 관계없는 기록을 의미하는 것이다.
원래 컴퓨터가 나오지 전까지로 본다면 로그는 항해일지나 실험일지를 의미하는
말로 쓰여졌다.

airlog : 항공일지
decklog : 항해일지

컴퓨터세계에서 로그는 어떤 시스템의 기록을 의미한다.
왜 기록을 남기는가?  나중에 그것을 보고 분석하고 통계내고 그 정보를 바탕으로
무엇인가를 판단하고 처리하기 위함이다
. 이 원래의 의미를 정확히 파악을 해야
비로서 우리는 제대로 된 로그시스템을 만들 수 있는 것이다.

로그가 남았지만 나중에 그것을 보지도 않고 분석도 하지않고 사용조차 하지
않을 거라면 로그를 남기는 것은 무의미 하다.

로그 시스템의 디자인.

다시 말하면 로그 시스템의 디자인의 첫번째는 로그로 남길 기록에 대해서
매우 신중하게 그리고 철저하게 고민할 필요가 있다.

로그로 남길 속성에 대해서 고찰하라.
    - 시간에 따라 측정할 수 있는 속성인가.
         (로그는 시간의 시점에 따른 기록임을 상기하라)
    - 시간에 따라 변경되는 속성인가?
        (항상 같은 값이라면 로그로 남길 필요가 없다.)
    - 나중에 반드시 참조되는 속성인가?
       (나중에 보지 않을 속성이라면 로그로 남길필요가없다.)
[그림] 로그시스템 디자인을 위한  메모의 예.
- 위의 그림은 로그시스템 디자인을 위해서 메모했던것으로 로그의 속성을
생각한 본 것이다. 위의 경우는 마인드맵 트리형태로 메모한 것이다. 디자인이라는것은
정형화 된 틀을 사용하는 것보다는 공부하는 방법론 처럼 자신에게 맞는
것을 찾아가는 것이 좋다고 생각한다. 어떤 창조적인 작업을 하는데 사용하는 메모는
그것을 하는 사람의 것이지 다른 사람의 것이 아니기 때문이다. 보통 정형화된 틀의
문서는 다른사람과의 의사소통을 위한 목적이 더 크다. 최종의 디자인 후에 그것을
외부와 의사소통을 위해서라면 그 의사소통 그룹에 맞게 표준적이고 정형적인 방법으로
다시 문서를 정리해야만 할 것이다. 예를들면 경영자 그룹쪽으로는 프리젠테이션의
형태로 비용과 기간 구축내용은 간단히 하는 형태의 촛점으로 아이디어를 표현해야
할 것이고 개발자그룹에게는 개발자그룹이 이해할수 있는 순서도 라직플로우
데이타항목을 잘 표현한 문서로 만들어야 될 것이다.
그러나 기초적인 디자인 단계에서의 메모즉 실제 구상하고 생각하는
단계에서는 이러한 틀이 모든것을 표현하지 못할뿐더러 창조적인 생각을 방해하게
된다.

다시 로그를 만드는 이유로 돌아가보자.
컴퓨터 시스템에서 로그를 남기는 구체적인 이유는 매우 여러가지 이유가 있겠지만
몇가지로 요약하면 다음과 같다.

  시스템의 보안에 대한 감시를 위해서
  시스템을 사용하는 사용자 패턴의 분석과 감시를 위해서
  시스템의 문제가 발생시 문제파악을 위한 자료를 위해서

위와 같은 이유로 보통 로그를 남긴다. 위와 같은 이유말고도 어떤 이유가 있어서
로그를 만들게 된다. 중요한 것은 그런 이유가 사라지면 로그도 줄어들거나 필요없게
디자인 되어야 된다. 이유가 없는데 로그를 남기는 것은 보지 않는 로그를
만드는 것과 같다.

로그 시스템 디자인에서 고려해야될 두번째는 로그의 이유가 사라지면
로그도 사라지도록 설계해야 된다.
이것을 구현하는 방법은 여러가지가 있겠지만 가장 손쉬운 방법은 로그생성시스템에
옵션을 처리할 수 있도록 하면 된다.
예를 들면 '전체로그:또는 상세로그설정' , '중간단계의로그: 핵심로그' , '로그없슴' 등..
형태로 단계를 나누어 로그를 생성할 수 있도록 설계해야 된다.

마지막으로 로그시스템 디자인에 있어서
세번째로 고려해야 할 것은 로그을 어떻게 이용할것가에
대한 것이다.
수많은 로그를 남겨도 그것을 가공하여 손쉽게 볼 수 있는 정책이
마련되어있지 않으면 로그의 활용은 미약해진다.
가장 간단한것은 테마별 또는 이벤트별 로그파일의 분리이다. 예를 들어 에러로그는
error.log에 접속로그 con.log 에 하는 형식이다.

또한 보다 더 많은 정보를 얻기 위해 , 접속시간별 접속수라든지 , 1일 통신량이라든지
통신상태의 변화라든지 , 아이피별 접속로그 분리라든지 시스템에 따라서 여러가지
형태로 디자인 할 수 있을 것이다.


이러한 로그시스템의 저장은 단순 파일시스템으로도 데이타베이스로도 구현할 수
있을 것이다. 구현은 나름이지만 파일시스템의 구현은 구현도 데이타베이스에 비해
쉽다고 볼수 있고 구현후 위의 것들을 다시 고려하여 수정도 편한 잇점이 있지만
정보를 검색하고 활용하는 측면에서는 즉 세번째 측면에서는 불리한 편이다.

만약 데이타베이스로 구현할 경우에는 초기디자인 후 수정에 따른 비용이 증가하고
구현의 어려움이 따르겠지만 유지보수가 훨씬 쉽고 데이타의 가공의 비용이
훨씬 줄어드는 잇점이 있다. 각각의 시스템의 특성에 따라서 어떤 것이 유리할지
판단하는 자세를 가져야 할 것이다. 데이타베이스가 무조건 더 좋다라든지
파일시스템으로 무조건 선택하는 것보다는 이 두가지의 장단점을 파악하고 그때
그때 시스템의 특성을 다시 파악하여 충분히 고려한후 구현을 해야 할 것이다.

프로그래머 뿐만아니라 모든 세계에서  어떤것 하나만이 옳다라고 하는 생각은
위험하다. 최대한 여러가지를 방법을 만들어 내고 그중에서 최선을 선택하려고
하는 유연한 사고가 더욱더 중요하다. 경험이 쌓일 수록 이러한 편견에 빠지기
쉽기 때문에 끊임없이 투명한 생각을 할 수 있도록 마음을 열어놓아야 한다.

참으로 어려운 일중에 하나이지만 , 그러한 투명한 생각을 가지려면 항상 겸손의
자세를 가져야 된다고 생각한다. From Xevious7
top

◀ PREV : [1] : [2] : [3] : [4] : [5] : [6] : [7] : [8] : [9] : .. [15] : NEXT ▶