꿀벌 커뮤니티 프로젝트에서 로그 시스템을 담당하고 있는데, 문득 개발자분들이 생각하는 이상적인 로그는 무엇이고 단순히 시스템 이벤트를 확인하기 위한 용도로만 사용되는지..
뭐 이런저런 궁금증이 생겨서 '로그' 라는 것에 대해서 알아가보려고 한다.
1. 로그(Log)란 무엇인가?
사전적인 의미 " 로그(log)는 소프트웨어 혹은 하드웨어 서비스들이 지속적으로 만들어내는 시스템 이벤트의 기록이다. "
이 포스트에서는 '서비스 로그'에 대해서 글을 작성할 것이다.
서비스 로그란?
이벤트에 대한 기록을 하는 로그 특성을 가지고,
서비스 수준에서 일어나는 상태변화나 유저의 행동에 대한 기록을 의미한다. (ex. 유저의 입장 및 퇴장, 아이템 구매, 획득 및 사용 등)
여담으로 로그는 IT 서비스에서 발생하는 서비스 로그 뿐만 아니라, 서비스에 대하여 KPI와 같은 지표를 분석하기 위한 시스템 로그로 사용되기도 하고 유저의 CS에 대응하기 위해 남기는 서비스 로그로도 사용될 수 있다.
로그에 대한 사전적인 의미를 알아보았는데, 그렇다면 코드에도 좋은 코드 나쁜 코드로 나누어 지는데 로그도 그런게 없을까? 당연히 있다.
좋은 로그?
필요한 정보가 있다.
의미가 명확하다.
편리하게 데이터를 얻을 수 있다.
글로 보면 좋은 로그를 의미하는 특성들이 매우 쉽게 느껴질 것이다. 하지만 좋은 로그를 구현하는데 있어서 여러 문제점들이 있다.
간단하게 겪어봤을 만한 문제를 언급하려고 한다.
겪어봤을 만한 문제
먼저, 필요한 정보가 없다. 다른 로그들은 다 있는데 꼭 필요한 로그가 없거나, 로그가 남긴 하는데 꼭 필요한 정보가 포함되지 않은 경우
두 번째, 의미를 파악하기 어렵다. 이름을 가지는 의미가 다른 콘텐츠의 이름과 충돌한다거나, 이름으로 정확히 무슨 로그인지 파악하기 힘든 경우
세 번째, 편리하게 데이터를 얻을 수 없다. 값에 여러 데이터가 포함되어 있어서 특정 데이터를 얻기 위해 매번 가공 처리를 해야하는 경우
위와 같은 문제점들이 왜 발생할까에 대해서 우리는 인지하고 있어야 한다.
1. 로그에 대한 작업 우선순위가 일반적으로 높지 않다. 2. 설계에 대한 충분한 고민 없이 일단 남기는데 집중 3. 무엇을 고려해야 할지 모름 4. 합의된 규약이 없음
2. '좋은 로그'를 위해 고려해야 할 것들
앞서 좋은 로그에 대해서 간략하게 작성하였는데, 그 부분들에 대해서 좀 더 자세히 볼 것이다.
간략하게 용어 설명을 하면
로그 - 이벤트에 대한 기록
항목 - 로그에 포함될 각각의 데이터
노랑칸이 로그에 들어갈 각각의 데이터 즉, 항목
이제 좋은 로그를 위해 고려할 것들에 대해서 작성할 것이다.
첫 번째, 필요한 정보가 있는 로그를 위해 고려할 것들
로그에는 목표를 먼저 정의해볼 필요가 있다.
아래는 목표를 정의하는 과정이다.
1. 목표가 있는 로그
(1) 목표를 한 문장으로 정의
ex) 재방문율 집계가 필요하다.
(2) 하나의 지표에 대해서 다양한 각도의 고민
ex) 재방문율 집계시 '국가별', '레벨별', '직업별' 필터링이 필요할 것이다.
(3) 목표에 따라 남겨야 할 이벤트와 그 항목들을 정의
ex) 목표들의 우선순위에 따라, 점진적으로 항목을 추가하는 방향도 고려
이렇듯 목표가 명확해지면 로그의 의도를 명확히 할 수 있고, 구체적으로 필요한 이벤트들과 항목을 정의할 수 있다.
2. 일관성
여기서 말하는 일관성이란, 같은 구성요소에 대해 같은 항목을 가지는 것이다.
구성요소는 서비스를 구성하는 각각의 요소를 의미하는데, 간단하게 예를 들면
'플레이어의 아이템 획득' 이벤트가 발생
플레이어와 아이템이라는 구성요소를 가진다.
이렇듯 로그에 대한 일관성이 없을 경우에는 어떤 플레이어가 무엇을 획득하고 사용했는지, 또는 누가 어떤 아이템을 획득했는지에 대한 정보가 담겨있지 않아서 파악하기 힘들어 진다.
이러면 로그를 남기는 의미가 없어질 뿐더러 나쁜 로그라고 할 수 있다.
[추가 예시] 사용자의 행동 로그에서 inference 시도 로그 / 데이터 업로드 로그 두 가지가 있다고 하면, 만약 'inference 시도 로그'는 사용자에 대한 정보 중 사용자 id, 사용자 레벨 두 가지를 기록하고, '데이터 업로드 로그'는 사용자 id, 사용자 닉네임 두 가지를 기록하면 일관성이 없는 로그로 판단. 사용자에 대한 로그라면 일관된 항목들을 기록해야함
3. 믿을 수 있는 로그
(1) 로그가 의도한 시점에서 발생
버그로 인해 유실되었다거나, 본래 설계와는 다른 시점에서 로그가 발생하는 상황이 일어나지 않아야 한다.
(2) 의도한 대로 데이터가 남았을 것
단순 실수로 인해 해당 유저의 데이터가 아닌 다른 유저의 데이터가 항목에 들어간다던지, 유저의 어뷰징에 의해서 로그가 변조되지 않아야 한다.
두 번째, 의미가 명확한 로그를 위해 고려할 것들
1. 이름에 대한 합의와 규약
의미를 충분히 표현할 수 있어야 한다.
나중에 이벤트 또는 항목의 이름을 바꾸는 것은 큰 비용이 발생할 수 있다.
기더라도 구체적인 이름을 사용
이름을 정의하기 위한 최소 규약 정의
모두가 어느 정도 일관화된 방식으로 이름을 짓기 위해 최소한의 규약이 필요하다.
이름에 대한 합의와 규약 예시
세 번째, 편리하게 데이터를 얻기 위해 고려할 것들
1. 로그 형식
서비스 로그는 특정 항목에 대한 접근이 필요한 경우가 많음
일반적으로 많이 쓰이는 형식
JSON, key/value
서비스 로그는 특정 항목에 대한 접근이 필요한 경우가 많고, 이를 집계하거나 검색하는 일이 많기 때문에 컴퓨터가 읽기 쉽도록 구조화된 형식임과 동시에 어느 정도는 사람이 읽을 수 있는 형식이 필요하다.
2. 메타데이터 사용에 대한 충분한 고민
메타데이터란? 서비스를 구성하는 정보에 대하여, 식별자와 그 상세 정보가 매핑된 데이터를 의미한다.
위의 사진을 예로 들면, 퀘스트 아이디에 대한 로그 정보들이 매핑되어있는 테이블을 메타데이터라고 할 수 있다.
로그에서 메타데이터를 사요한다는 것은, 로그에는 퀘스트 상세정보를 남기지 않고 퀘스트 아이디만 기록하여 실제로 로그를 사용할 때는 메타데이터를 참조하여 나머지 정보를 얻는 방식이다.
※ 메타데이터의 주의점
메타데이터의 남용은 관리 이슈와 생산성 저하를 유발
메타데이터가 많아지면 관리하기 힘들어진다.
집계 시마다 로그 외의 다른 데이터를 참조 해야한다.
※ 메타데이터 사용의 적절한 예
정적 데이터가 과도하게 많고, 정의했던 로그의 목표에 필요하지 않은 경우
목표에 꼭 필요한 데이터라면 로그의 항목으로 구성하는 것이 좋다.
변경 주체가 서비스 제공자에게 있는 경우에 적합하다.
메타데이터가 불가피하게 많아질 경우
시스템에서 메타데이터를 효율적으로 관리하고 사용할 수 있는 도구를 사용하는 것을 권장한다.
