(자막)[NDC19] 좋은 로그란 무엇인가?: 좋은 로그를 위해 고려해야 할 것들

넥슨 컴퍼니 왓 스튜디오 전효준 : 좋은 로그를 위해 고려해야
할 것들 좋은 로그란 무엇인가?

할 것들 좋은 로그란 무엇인가? 안녕하세요

할 것들 좋은 로그란 무엇인가? 좋은 로그란 무엇인가에 대해 발표하게 된 왓 스튜디오의 전효준입니다.

www.hyojun.me [email protected] devinjeon NDC18 〈야생의땅: 듀랑고〉의 데이터 엔지니어링 이야기 :
로그 시스템 구축 경험 공유 넥슨 왓 스튜디오의 백엔드 엔지니어 주로 데이터와 DevOps 엔지니어링을 담당 전효준

로그 시스템 구축 경험 공유 넥슨 왓 스튜디오의 백엔드 엔지니어 주로 데이터와 DevOps 엔지니어링을 담당 전효준 먼저 간단하게 제 소개를 하자면

로그 시스템 구축 경험 공유 넥슨 왓 스튜디오의 백엔드 엔지니어 주로 데이터와 DevOps 엔지니어링을 담당 전효준 이전에 두 곳의 스타트업을 거쳐서 지금 왓 스튜디오로 오게 되었는데요.

로그 시스템 구축 경험 공유 넥슨 왓 스튜디오의 백엔드 엔지니어 주로 데이터와 DevOps 엔지니어링을 담당 전효준 백엔드 엔지니어로서 여러 가지를 하고 있지만

로그 시스템 구축 경험 공유 넥슨 왓 스튜디오의 백엔드 엔지니어 주로 데이터와 DevOps 엔지니어링을 담당 전효준 주로 데이터 엔지니어링과 데브옵스 영역을 담당하고 있고요.

로그 시스템 구축 경험 공유 넥슨 왓 스튜디오의 백엔드 엔지니어 주로 데이터와 DevOps 엔지니어링을 담당 전효준 작년 NDC에서는 로그 시스템 구축에 대한 이야기를 했었던 경험이 있습니다.

들어가기에 앞서 • 발표 내용을 기록하시느라 흐름을 놓치실 수 있기에,
발표 자료는 아래 링크에서 자막과 함께 공개 예정입니다 :) https://hyojun.me/~ndc19

들어가기에 앞서 • 발표 내용을 기록하시느라 흐름을 놓치실 수 있기에,
발표 자료는 아래 링크에서 자막과 함께 공개 예정입니다 :) https://hyojun.me/~ndc19 들어가기에 앞서, 발표 자료는 아래 링크에서 자막과 함께 공유드릴 수 있도록 하겠습니다.

오늘 이야기 1. ‘좋은 로그’란 무엇인가? 2. ‘좋은 로그’를 위해
고려해야 할 것들 3. 로그 품질 관리를 위해 해야 할 것들

고려해야 할 것들 3. 로그 품질 관리를 위해 해야 할 것들 그럼 본격적으로 발표를 시작해볼 텐데요.

고려해야 할 것들 3. 로그 품질 관리를 위해 해야 할 것들 오늘 이 발표에서는 먼저 좋은 로그란 무엇인가에 대하여 이야기하고

고려해야 할 것들 3. 로그 품질 관리를 위해 해야 할 것들 이를 위해 고려해야 할 것들,

고려해야 할 것들 3. 로그 품질 관리를 위해 해야 할 것들 그리고 지속적인 품질관리를 위해 해야 할 것들에 대해 이야기할 예정입니다.

Chapter 1. ‘좋은 로그’란 무엇인가?

Chapter 1. ‘좋은 로그’란 무엇인가? 첫 번째로, “좋은 로그란 무엇인가?”에
대해 이야기하기 전에

‘로그(Log)’에 대한 정의 • 이벤트(Event)에 대한 기록(Record) • 이 발표에서는
‘서비스 로그’를 대상으로 합니다. • 서비스 수준에서 일어나는 상태변화나 유저의 행동에 대한 기록들 • 예) 유저의 입장 및 퇴장, 아이템 구매, 획득 및 사용 등

‘서비스 로그’를 대상으로 합니다. • 서비스 수준에서 일어나는 상태변화나 유저의 행동에 대한 기록들 • 예) 유저의 입장 및 퇴장, 아이템 구매, 획득 및 사용 등 먼저 로그에 대한 정의를 한번 내려보겠습니다.

‘서비스 로그’를 대상으로 합니다. • 서비스 수준에서 일어나는 상태변화나 유저의 행동에 대한 기록들 • 예) 유저의 입장 및 퇴장, 아이템 구매, 획득 및 사용 등 로그는 어떤 이벤트에 대한 기록이라고 정의해볼 수 있는데요.

‘서비스 로그’를 대상으로 합니다. • 서비스 수준에서 일어나는 상태변화나 유저의 행동에 대한 기록들 • 예) 유저의 입장 및 퇴장, 아이템 구매, 획득 및 사용 등 여기서 다시 용도에 따라 크게 두 가지로 나눠보면

‘서비스 로그’를 대상으로 합니다. • 서비스 수준에서 일어나는 상태변화나 유저의 행동에 대한 기록들 • 예) 유저의 입장 및 퇴장, 아이템 구매, 획득 및 사용 등 프로그램의 버그나 OS 레벨에서 시스템 이벤트를 추적하기 위해 남기는 시스템 로그와

‘서비스 로그’를 대상으로 합니다. • 서비스 수준에서 일어나는 상태변화나 유저의 행동에 대한 기록들 • 예) 유저의 입장 및 퇴장, 아이템 구매, 획득 및 사용 등 우리가 운영하는 서비스에 대하여 KPI와 같은 지표를 분석하기 위해 남기거나

‘서비스 로그’를 대상으로 합니다. • 서비스 수준에서 일어나는 상태변화나 유저의 행동에 대한 기록들 • 예) 유저의 입장 및 퇴장, 아이템 구매, 획득 및 사용 등 유저의 CS에 대응하기 위해 남기는 서비스 로그로 나눠볼 수 있습니다.

‘서비스 로그’를 대상으로 합니다. • 서비스 수준에서 일어나는 상태변화나 유저의 행동에 대한 기록들 • 예) 유저의 입장 및 퇴장, 아이템 구매, 획득 및 사용 등 오늘 이 발표에서는 ‘서비스 로그’를 대상으로 이야기해보려 합니다.

‘좋은 로그’에 대한 정의

‘좋은 로그’에 대한 정의 그렇다면 오늘 주제인 ‘좋은 로그’에 대해서
한번 이야기해보겠습니다.

‘좋은 로그’에 대한 정의 1. 필요한 정보가 있다. 먼저 필요한
정보가 있고,

‘좋은 로그’에 대한 정의 1. 필요한 정보가 있다. 2. 의미가
명확하다. 의미가 명확하고

명확하다. 3. 편리하게 데이터를 얻을 수 있다. 편리하게 원하는 데이터를 얻을 수 있다. 간단하게 이 세 가지를 좋은 로그로 정의해봤는데요.

명확하다. 3. 편리하게 데이터를 얻을 수 있다. 이것만 보면 참 간단한데... 이것만 보면 참 간단한데 현실은 그렇지 않은 경우가 많았습니다.

겪어봤을 만한 문제들 • 필요한 정보가 없다. 예) 꼭 필요하면
없더라, 왜 이 이벤트에는 있는데 저 이벤트에는 없지?

없더라, 왜 이 이벤트에는 있는데 저 이벤트에는 없지? 다른 로그들은 다 있는데 꼭 필요한 로그가 없거나

없더라, 왜 이 이벤트에는 있는데 저 이벤트에는 없지? 로그가 남긴 하는데 꼭 필요한 정보가 포함되지 않은 경우도 많았고요.

없더라, 왜 이 이벤트에는 있는데 저 이벤트에는 없지? • 의미를 파악하기 어렵다. 예) 이 이벤트(또는 항목) 이름은 대체 무슨 의미지? 이름이 가지는 의미가 다른 콘텐츠의 이름과 충돌한다거나

없더라, 왜 이 이벤트에는 있는데 저 이벤트에는 없지? • 의미를 파악하기 어렵다. 예) 이 이벤트(또는 항목) 이름은 대체 무슨 의미지? 이름으로 정확히 무슨 로그인지 파악하기 힘든 경우도 있었습니다.

없더라, 왜 이 이벤트에는 있는데 저 이벤트에는 없지? • 의미를 파악하기 어렵다. 예) 이 이벤트(또는 항목) 이름은 대체 무슨 의미지? • 편리하게 데이터를 얻을 수 없다. 예) 값에 여러 데이터가 함께 포함되어 있어서 매번 가공 처리를 해야하는 경우

없더라, 왜 이 이벤트에는 있는데 저 이벤트에는 없지? • 의미를 파악하기 어렵다. 예) 이 이벤트(또는 항목) 이름은 대체 무슨 의미지? • 편리하게 데이터를 얻을 수 없다. 예) 값에 여러 데이터가 함께 포함되어 있어서 매번 가공 처리를 해야하는 경우 또는 여러 가지 데이터가 한 항목에 포함되어 있어서

없더라, 왜 이 이벤트에는 있는데 저 이벤트에는 없지? • 의미를 파악하기 어렵다. 예) 이 이벤트(또는 항목) 이름은 대체 무슨 의미지? • 편리하게 데이터를 얻을 수 없다. 예) 값에 여러 데이터가 함께 포함되어 있어서 매번 가공 처리를 해야하는 경우 특정 데이터를 얻기 위해서 매번 가공 처리를 해야 한다든지

없더라, 왜 이 이벤트에는 있는데 저 이벤트에는 없지? • 의미를 파악하기 어렵다. 예) 이 이벤트(또는 항목) 이름은 대체 무슨 의미지? • 편리하게 데이터를 얻을 수 없다. 예) 값에 여러 데이터가 함께 포함되어 있어서 매번 가공 처리를 해야하는 경우 이런 생산성을 떨어뜨리는 여러 가지 문제들이 많이 발생했습니다.

없더라, 왜 이 이벤트에는 있는데 저 이벤트에는 없지? • 의미를 파악하기 어렵다. 예) 이 이벤트(또는 항목) 이름은 대체 무슨 의미지? • 편리하게 데이터를 얻을 수 없다. 예) 값에 여러 데이터가 함께 포함되어 있어서 매번 가공 처리를 해야하는 경우 로그를 다루다 보면 이런 문제들을 자주 겪게 되는데요

왜 항상 비슷한 문제를 겪을까?

왜 항상 비슷한 문제를 겪을까? 왜 이런 문제들을 겪을까 하고
생각해보면

왜 항상 비슷한 문제를 겪을까? • 로그에 대한 작업 우선순위가
일반적으로 높지 않음 로그를 추가하거나 변경하는 작업들의 우선순위가 일반적으로 높지 않았고

일반적으로 높지 않음 • 설계에 대한 충분한 고민 없이 일단 남기는데 집중 때문에 설계에 대한 충분한 고민 없이 일단 남기는데 집중을 하게 되는 경우가 많았습니다.

일반적으로 높지 않음 • 설계에 대한 충분한 고민 없이 일단 남기는데 집중 • 무엇을 고려해야 할지 모름 막상 고민을 해봐도 무엇을 고려해야 할지 모르는 경우가 많고

일반적으로 높지 않음 • 설계에 대한 충분한 고민 없이 일단 남기는데 집중 • 무엇을 고려해야 할지 모름 • 합의된 규약이 없음 어떻게 로그를 설계하는지에 대해서 합의된 규약도 없다는 것

일반적으로 높지 않음 • 설계에 대한 충분한 고민 없이 일단 남기는데 집중 • 무엇을 고려해야 할지 모름 • 합의된 규약이 없음 • 로그 품질을 지속적으로 관리하지 않음 그리고 로그 품질관리의 부재가 결국 이런 문제들을 심화시켰습니다.

문제점을 충분히 인식했을 때쯤에는 ... • 필요한 데이터를 얻지 못하거나,
큰 비용이 들게 됨 • 이미 지나간 시간의 정보를 찾는 것은 불가능하거나 힘듦 → 로그는 그때 그 상황을 기록하는 유일한 정보

큰 비용이 들게 됨 • 이미 지나간 시간의 정보를 찾는 것은 불가능하거나 힘듦 → 로그는 그때 그 상황을 기록하는 유일한 정보 이걸 충분히 인식했을 때쯤에는

큰 비용이 들게 됨 • 이미 지나간 시간의 정보를 찾는 것은 불가능하거나 힘듦 → 로그는 그때 그 상황을 기록하는 유일한 정보 로그는 이미 지나간 시간의 정보이기 때문에 다시 찾기 불가능하거나

큰 비용이 들게 됨 • 이미 지나간 시간의 정보를 찾는 것은 불가능하거나 힘듦 → 로그는 그때 그 상황을 기록하는 유일한 정보 없는 정보를 다른 데이터로부터 채워줘야 하는데 이 또한 꽤나 번거로운 작업이 될 수 있습니다.

큰 비용이 들게 됨 • 이미 지나간 시간의 정보를 찾는 것은 불가능하거나 힘듦 → 로그는 그때 그 상황을 기록하는 유일한 정보 • 대부분 미래에 기존 설계 구조를 바꾸는 것은 많은 비용이 발생 → 기존에 적재된 모든 로그를 새로운 구조로 변환하는 것은 사실상 비현실적 또한 미래에 기존 로그 설계구조를 바꾸는 것은 많은 비용을 발생시킬 수 있는데요.

큰 비용이 들게 됨 • 이미 지나간 시간의 정보를 찾는 것은 불가능하거나 힘듦 → 로그는 그때 그 상황을 기록하는 유일한 정보 • 대부분 미래에 기존 설계 구조를 바꾸는 것은 많은 비용이 발생 → 기존에 적재된 모든 로그를 새로운 구조로 변환하는 것은 사실상 비현실적 예를 들어, 단순히 로그 항목의 이름을 바꾸는 것도 기존 적재된 로그에도 모두 적용시켜주어야 하는데요.

큰 비용이 들게 됨 • 이미 지나간 시간의 정보를 찾는 것은 불가능하거나 힘듦 → 로그는 그때 그 상황을 기록하는 유일한 정보 • 대부분 미래에 기존 설계 구조를 바꾸는 것은 많은 비용이 발생 → 기존에 적재된 모든 로그를 새로운 구조로 변환하는 것은 사실상 비현실적 만약에 기존 로그에 대한 항목 이름의 변경을 포기하게 되면

큰 비용이 들게 됨 • 이미 지나간 시간의 정보를 찾는 것은 불가능하거나 힘듦 → 로그는 그때 그 상황을 기록하는 유일한 정보 • 대부분 미래에 기존 설계 구조를 바꾸는 것은 많은 비용이 발생 → 기존에 적재된 모든 로그를 새로운 구조로 변환하는 것은 사실상 비현실적 집계 시 매번 변경일자 전과 후의 항목 이름이 다르다는 것을 고려해야만 합니다.

큰 비용이 들게 됨 • 이미 지나간 시간의 정보를 찾는 것은 불가능하거나 힘듦 → 로그는 그때 그 상황을 기록하는 유일한 정보 • 대부분 미래에 기존 설계 구조를 바꾸는 것은 많은 비용이 발생 → 기존에 적재된 모든 로그를 새로운 구조로 변환하는 것은 사실상 비현실적

이 발표를 준비한 이유 • 초기 ‘좋은 로그’의 필요성에 대한
인식이 부족했던 것에 대한 아쉬움

인식이 부족했던 것에 대한 아쉬움 사실 저 또한 이런 ‘좋은 로그’에 대한 인식이 부족했었고

인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. 실제로 이 발표를 준비하면서도 느낀 것이지만

인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. 구체적으로 무엇을 고민해야 하는지 참고할만한 자료를 찾기 힘들었습니다.

인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. 로그 시스템을 구축하고, 로그를 설계해보고 서버에 로그를 추가하는 작업부터

인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. 로그 데이터들로 분석 업무도 해보면서 알게 되었지만

인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. • 새로운 프로젝트를 시작할 때에는, 이런 내용을 복기하기 힘듦 결국 새로운 프로젝트를 시작할 때는, 이런 내용을 다시 떠올리기 힘들었습니다.

인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. • 새로운 프로젝트를 시작할 때에는, 이런 내용을 복기하기 힘듦 • 로그를 다루는 여러 동료들 모두가 공감대를 형성하며, 함께 고민해야 달성할 수 있는 가치 • 공유가 필요하다!

인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. • 새로운 프로젝트를 시작할 때에는, 이런 내용을 복기하기 힘듦 • 로그를 다루는 여러 동료들 모두가 공감대를 형성하며, 함께 고민해야 달성할 수 있는 가치 • 공유가 필요하다! 때문에 한번 정리가 필요하다는 생각이 들었는데요.

인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. • 새로운 프로젝트를 시작할 때에는, 이런 내용을 복기하기 힘듦 • 로그를 다루는 여러 동료들 모두가 공감대를 형성하며, 함께 고민해야 달성할 수 있는 가치 • 공유가 필요하다! 정리를 하면서 다시 느끼게 된 것은

인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. • 새로운 프로젝트를 시작할 때에는, 이런 내용을 복기하기 힘듦 • 로그를 다루는 여러 동료들 모두가 공감대를 형성하며, 함께 고민해야 달성할 수 있는 가치 • 공유가 필요하다! 결국 좋은 로그에 대해 모두가 함께 공감대를 형성하고,

인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. • 새로운 프로젝트를 시작할 때에는, 이런 내용을 복기하기 힘듦 • 로그를 다루는 여러 동료들 모두가 공감대를 형성하며, 함께 고민해야 달성할 수 있는 가치 • 공유가 필요하다! 같이 고민해야 달성할 수 있는 가치라는 것입니다.

인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. • 새로운 프로젝트를 시작할 때에는, 이런 내용을 복기하기 힘듦 • 로그를 다루는 여러 동료들 모두가 공감대를 형성하며, 함께 고민해야 달성할 수 있는 가치 • 공유가 필요하다! 그래서 이 발표가 저 같은 엔지니어뿐만 아니라

인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. • 새로운 프로젝트를 시작할 때에는, 이런 내용을 복기하기 힘듦 • 로그를 다루는 여러 동료들 모두가 공감대를 형성하며, 함께 고민해야 달성할 수 있는 가치 • 공유가 필요하다! 여기 와계신 다양한 직군, 다양한 입장을 가진 사람들이 함께 고민해보는 좋은 자리가 되었으면 합니다.

Chapter 2. ‘좋은 로그’를 위해 고려해야 할 것들 1. 필요한
정보가 있는 로그 2. 의미가 명확한 로그 3. 편리하게 데이터를 얻을 수 있는 로그 4. 그 외 다른 관점에서 고려해봐야 할 것들

정보가 있는 로그 2. 의미가 명확한 로그 3. 편리하게 데이터를 얻을 수 있는 로그 4. 그 외 다른 관점에서 고려해봐야 할 것들 지금까지 좋은 로그가 무엇인지, 이게 왜 필요하고 왜 발표를 하게 되었는지 말씀드렸는데요.

정보가 있는 로그 2. 의미가 명확한 로그 3. 편리하게 데이터를 얻을 수 있는 로그 4. 그 외 다른 관점에서 고려해봐야 할 것들 이번에는 좋은 로그를 위해 고려해야 할 것들에 대해

정보가 있는 로그 2. 의미가 명확한 로그 3. 편리하게 데이터를 얻을 수 있는 로그 4. 그 외 다른 관점에서 고려해봐야 할 것들 이전에 얘기했던 세 가지의 정의로 주제를 나눠서 이야기해보려 합니다.

정보가 있는 로그 2. 의미가 명확한 로그 3. 편리하게 데이터를 얻을 수 있는 로그 4. 그 외 다른 관점에서 고려해봐야 할 것들 각각의 주제마다 평균적으로 세 가지 내용이 있는데

정보가 있는 로그 2. 의미가 명확한 로그 3. 편리하게 데이터를 얻을 수 있는 로그 4. 그 외 다른 관점에서 고려해봐야 할 것들 몇몇은 간단하게, 몇몇은 강조해서 설명드릴 예정입니다.

앞으로 나올 단어들 • 로그 - 이벤트에 대한 기록 •
항목 - 로그에 포함될 각각의 데이터 time player_id player_class player_level … … … … … … … … … … … PlayerGotItem

항목 - 로그에 포함될 각각의 데이터 time player_id player_class player_level … … … … … … … … … … … PlayerGotItem 먼저 앞으로 나올 단어들에 대해서 미리 정의를 하고 가자면

항목 - 로그에 포함될 각각의 데이터 time player_id player_class player_level … … … … … … … … … … … PlayerGotItem 로그는 이벤트에 대한 기록이고요.

항목 - 로그에 포함될 각각의 데이터 time player_id player_class player_level … … … … … … … … … … … PlayerGotItem 항목은 이런 이벤트의 종류마다 포함되어야 하는 각각의 데이터들을 뜻합니다.

항목 - 로그에 포함될 각각의 데이터 time player_id player_class player_level … … … … … … … … … … … PlayerGotItem 예를 들어 ‘플레이어의 아이템 획득’ 로그를 아래와 같이 테이블로 표시해보면

항목 - 로그에 포함될 각각의 데이터 time player_id player_class player_level … … … … … … … … … … … PlayerGotItem 발생 시간, 플레이어 아이디, 직업, 레벨 등을 각각의 항목으로 생각하시면 됩니다.

Chapter 2-1. 필요한 정보가 있는 로그를 위해 고려할 것들

Chapter 2-1. 필요한 정보가 있는 로그를 위해 고려할 것들 다시
돌아와서, 필요한 정보가 있는 로그를 위해 고려할 것들입니다.

목표가 있는 로그

목표가 있는 로그 첫 번째는, 로그에는 목표를 먼저 정의해볼 필요가
있다는 것인데요.

목표가 있는 로그 간단하게 먼저 그 과정을 이야기해보면

목표가 있는 로그 1. 목표를 한 문장으로 정의 예) 재방문율
집계가 필요하다. 먼저 “유저의 재방문율 집계가 필요하다”와 같이 목표를 한 문장으로 정의해보고

집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. 두 번째로는 이런 목표를 위해 다양한 각도의 고민을 해보는 것입니다.

집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. 그 예로, 아까 재방문율에 대해서

집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. “추후에 국가별, 레벨별, 직업별 필터링이 필요할 것이다”라는 생각을 해볼 수 있습니다.

집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. 3. 목표에 따라 남겨야 할 이벤트와 그 항목들을 정의 • 목표들의 우선순위에 따라, 점진적으로 항목을 추가하는 방향도 고려

집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. 3. 목표에 따라 남겨야 할 이벤트와 그 항목들을 정의 • 목표들의 우선순위에 따라, 점진적으로 항목을 추가하는 방향도 고려 마지막은 이렇게 정의된 목표에 따라

집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. 3. 목표에 따라 남겨야 할 이벤트와 그 항목들을 정의 • 목표들의 우선순위에 따라, 점진적으로 항목을 추가하는 방향도 고려 어떤 로그들과, 어떤 항목들이 있어야 하는지 정의해보는 것입니다.

집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. 3. 목표에 따라 남겨야 할 이벤트와 그 항목들을 정의 • 목표들의 우선순위에 따라, 점진적으로 항목을 추가하는 방향도 고려 목표가 명확해지면 로그의 의도를 명확히 할 수 있고

집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. 3. 목표에 따라 남겨야 할 이벤트와 그 항목들을 정의 • 목표들의 우선순위에 따라, 점진적으로 항목을 추가하는 방향도 고려 구체적으로 필요한 이벤트들과 항목을 정의할 수 있습니다.

집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. 3. 목표에 따라 남겨야 할 이벤트와 그 항목들을 정의 • 목표들의 우선순위에 따라, 점진적으로 항목을 추가하는 방향도 고려 추가적으로 목표가 있다면 우선순위를 파악할 수 있기 때문에

집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. 3. 목표에 따라 남겨야 할 이벤트와 그 항목들을 정의 • 목표들의 우선순위에 따라, 점진적으로 항목을 추가하는 방향도 고려 우선순위에 따라 점진적으로 로그 개선이 가능하기도 합니다.

일관성 • 일관성이란? • 같은 구성요소에 대하여 같은 항목들을 가지는
것

것 두 번째는 일관성입니다.

것 여기서 말하는 일관성이란, 같은 구성요소에 대해 같은 항목을 가지는 것인데요.

것 • 구성요소의 예) → ‘플레이어의 아이템 획득’ 이벤트의 경우, 플레이어와 아이템이라는 구성요소를 가진다.

것 • 구성요소의 예) → ‘플레이어의 아이템 획득’ 이벤트의 경우, 플레이어와 아이템이라는 구성요소를 가진다. 구성요소라 함은, 서비스를 구성하는 각각의 요소를 말하는 것입니다.

것 • 구성요소의 예) → ‘플레이어의 아이템 획득’ 이벤트의 경우, 플레이어와 아이템이라는 구성요소를 가진다. 예를 들어, ‘플레이어의 아이템 획득’이라는 이벤트에 대해서는 플레이어와 아이템이 구성요소가 됩니다.

일관성 • 일관성이 없는 경우의 예) time player_id player_class player_level
… … … … … … … … … … … PlayerGotItem PlayerUsedItem time player_id player_class … … … … … … … … … • 두 이벤트 모두 플레이어에 대한 로그 • 하지만 플레이어에 대한 항목 구성이 다름

… … … … … … … … … … … PlayerGotItem PlayerUsedItem time player_id player_class … … … … … … … … … • 두 이벤트 모두 플레이어에 대한 로그 • 하지만 플레이어에 대한 항목 구성이 다름 일관성이 없는 경우는 보시다시피

… … … … … … … … … … … PlayerGotItem PlayerUsedItem time player_id player_class … … … … … … … … … • 두 이벤트 모두 플레이어에 대한 로그 • 하지만 플레이어에 대한 항목 구성이 다름 ‘플레이어의 아이템 획득’ 로그와 ‘플레이어의 아이템 사용’ 로그가 있을 때

… … … … … … … … … … … PlayerGotItem PlayerUsedItem time player_id player_class … … … … … … … … … • 두 이벤트 모두 플레이어에 대한 로그 • 하지만 플레이어에 대한 항목 구성이 다름 두 이벤트 모두 플레이어에 대한 로그이지만

… … … … … … … … … … … PlayerGotItem PlayerUsedItem time player_id player_class … … … … … … … … … • 두 이벤트 모두 플레이어에 대한 로그 • 하지만 플레이어에 대한 항목 구성이 다름 아이템 획득 로그에는 플레이어의 아이디와 직업, 레벨 항목들이 존재하는데

… … … … … … … … … … … PlayerGotItem PlayerUsedItem time player_id player_class … … … … … … … … … • 두 이벤트 모두 플레이어에 대한 로그 • 하지만 플레이어에 대한 항목 구성이 다름 아이템 사용 로그에는 플레이어의 아이디와 직업 항목들만 있는 경우인데요.

… … … … … … … … … … … PlayerGotItem PlayerUsedItem time player_id player_class … … … … … … … … … • 두 이벤트 모두 플레이어에 대한 로그 • 하지만 플레이어에 대한 항목 구성이 다름 만약 두 로그 모두 플레이어에 대해 같은 구성의 항목을 가지고 있다면 일관성이 있는 것이고

… … … … … … … … … … … PlayerGotItem PlayerUsedItem time player_id player_class … … … … … … … … … • 두 이벤트 모두 플레이어에 대한 로그 • 하지만 플레이어에 대한 항목 구성이 다름 더 나아가서는 한 구성요소에 대해 같은 의미의 항목은 같은 이름을 사용하는 것 또한

… … … … … … … … … … … PlayerGotItem PlayerUsedItem time player_id player_class … … … … … … … … … • 두 이벤트 모두 플레이어에 대한 로그 • 하지만 플레이어에 대한 항목 구성이 다름 일관성이 있다고 이야기할 수 있습니다.

믿을 수 있는 로그

믿을 수 있는 로그 다음은 믿을 수 있는 로그에 대한
이야기입니다.

믿을 수 있는 로그 1. 로그가 의도한 시점에서 발생했을 것이라는
믿음 여기서 말하는 믿음의 첫 번째 의미는 로그가 의도한 시점에서 잘 발생했을 것이라는 믿음인데요.

믿음 버그로 인해 유실되었다거나

믿음 본래 설계와는 다른 시점에서 로그가 발생하는 상황이 일어나지 않아야 한다는 것을 의미합니다.

믿음 2. 의도한 대로 데이터가 남았을 것이라는 믿음 • 의도한 것과 다른 데이터가 남을 수 있는 가능성 • 어뷰징에 의한 변조 가능성 다음은 의도한 대로 데이터가 남았을 거라는 믿음입니다.

믿음 2. 의도한 대로 데이터가 남았을 것이라는 믿음 • 의도한 것과 다른 데이터가 남을 수 있는 가능성 • 어뷰징에 의한 변조 가능성 단순 실수로 인해 플레이어의 아이디 항목에 아이디가 아닌 다른 값이 들어간다거나

믿음 2. 의도한 대로 데이터가 남았을 것이라는 믿음 • 의도한 것과 다른 데이터가 남을 수 있는 가능성 • 어뷰징에 의한 변조 가능성 유저의 어뷰징에 의해서 로그가 변조되는 경우가 없어야 한다는 것인데요.

믿음 2. 의도한 대로 데이터가 남았을 것이라는 믿음 • 의도한 것과 다른 데이터가 남을 수 있는 가능성 • 어뷰징에 의한 변조 가능성 이러한 신뢰가 깨진다면

믿음 2. 의도한 대로 데이터가 남았을 것이라는 믿음 • 의도한 것과 다른 데이터가 남을 수 있는 가능성 • 어뷰징에 의한 변조 가능성 결국 그 로그는 쓸 수 없게 되거나 다루는데 많은 시간이 필요하게 될 수 있습니다.

믿음 2. 의도한 대로 데이터가 남았을 것이라는 믿음 • 의도한 것과 다른 데이터가 남을 수 있는 가능성 • 어뷰징에 의한 변조 가능성 3. 100%는 아니더라도 납득할 수 있는 수준의 믿음을 위한 노력이 필요 물론 유실이나 변조, 실수 등에 대해 기술적 한계나 다른 이유로 100%를 달성하기는 어렵더라도

믿음 2. 의도한 대로 데이터가 남았을 것이라는 믿음 • 의도한 것과 다른 데이터가 남을 수 있는 가능성 • 어뷰징에 의한 변조 가능성 3. 100%는 아니더라도 납득할 수 있는 수준의 믿음을 위한 노력이 필요 우리가 납득할 수 있는 수준까지의 노력이 필요합니다.

여기까지 정리 • 필요한 정보가 있는 로그를 위해 고려할 것들
• 목표가 있는 로그 • 일관성 있는 로그 • 믿을 수 있는 로그 여기까지 필요한 정보가 있는 로그를 위해 고려해볼 것들 세 가지를 살펴보았습니다.

여기까지 정리 • 필요한 정보가 있는 로그를 위해 고려할 것들
• 목표가 있는 로그 • 일관성 있는 로그 • 믿을 수 있는 로그 이제 로그에 필요한 정보를 잘 담기 위한 준비가 어느 정도 되었다면

Chapter 2-2. 의미가 명확한 로그를 위해 고려할 것들

Chapter 2-2. 의미가 명확한 로그를 위해 고려할 것들 의미를 좀더
잘 파악할 수 있도록 하기위해 고려해볼 것들을 알아볼 차례입니다.

이름에 대한 합의와 규약

이름에 대한 합의와 규약 첫 번째로 고려해야 할 것은 이름에
대한 합의와 규약입니다.

이름에 대한 합의와 규약 여기서 말하는 이름은 이벤트의 이름뿐만 아니라
항목에 대한 이름도 포함됩니다.

이름에 대한 합의와 규약 • 의미를 충분히 표현할 수 있어야
함 당연하겠지만 이름은 의미를 충분히 표현할 수 있어야 합니다.

함 • 나중에 이벤트 또는 항목의 이름을 바꾸는 것은 큰 비용이 발생할 수 있음 앞서 말했듯이 추후에는 기존의 이벤트 이름이나 항목의 이름을 바꾸는 것만으로도

함 • 나중에 이벤트 또는 항목의 이름을 바꾸는 것은 큰 비용이 발생할 수 있음 큰 비용이 발생할 수 있기 때문에

함 • 나중에 이벤트 또는 항목의 이름을 바꾸는 것은 큰 비용이 발생할 수 있음 • 때문에, 길더라도 구체적인 이름을 사용 • 다른 의미와 혼동될만한 가능성을 피할 수 있다. • 미래에 들어가는 이름과 의미가 충돌할 가능성을 낮출 수 있다. 길더라도 구체적인 이름을 사용하여

함 • 나중에 이벤트 또는 항목의 이름을 바꾸는 것은 큰 비용이 발생할 수 있음 • 때문에, 길더라도 구체적인 이름을 사용 • 다른 의미와 혼동될만한 가능성을 피할 수 있다. • 미래에 들어가는 이름과 의미가 충돌할 가능성을 낮출 수 있다. 다른 의미와 혼동될 만한 가능성을 줄이고

함 • 나중에 이벤트 또는 항목의 이름을 바꾸는 것은 큰 비용이 발생할 수 있음 • 때문에, 길더라도 구체적인 이름을 사용 • 다른 의미와 혼동될만한 가능성을 피할 수 있다. • 미래에 들어가는 이름과 의미가 충돌할 가능성을 낮출 수 있다. 미래에 추가되는 콘텐츠, 기능 등으로 인해

함 • 나중에 이벤트 또는 항목의 이름을 바꾸는 것은 큰 비용이 발생할 수 있음 • 때문에, 길더라도 구체적인 이름을 사용 • 다른 의미와 혼동될만한 가능성을 피할 수 있다. • 미래에 들어가는 이름과 의미가 충돌할 가능성을 낮출 수 있다. 이름이 가지는 의미가 다른 개념과 충돌할 가능성을 낮추는 것이 중요합니다.

함 • 나중에 이벤트 또는 항목의 이름을 바꾸는 것은 큰 비용이 발생할 수 있음 • 때문에, 길더라도 구체적인 이름을 사용 • 다른 의미와 혼동될만한 가능성을 피할 수 있다. • 미래에 들어가는 이름과 의미가 충돌할 가능성을 낮출 수 있다. • 이름을 정의하기 위한 최소 규약(Naming convention) 정의

함 • 나중에 이벤트 또는 항목의 이름을 바꾸는 것은 큰 비용이 발생할 수 있음 • 때문에, 길더라도 구체적인 이름을 사용 • 다른 의미와 혼동될만한 가능성을 피할 수 있다. • 미래에 들어가는 이름과 의미가 충돌할 가능성을 낮출 수 있다. • 이름을 정의하기 위한 최소 규약(Naming convention) 정의 또한 모두가 어느 정도 일관화된 방식으로 이름을 짓기 위해 최소한의 규약이 필요합니다.

이름에 대한 합의와 규약 • 이벤트 이름 1. 파스칼 표기법(단어의
첫문자를 대문자로 시작하는 표기법)을 따른다. 2. 이벤트의 구성요소들과 상태 변화 또는 행동에 대한 내용을 모두 포함한다. 예) 플레이어의 아이템 획득 → PlayerGotItem 구성요소 - Player, Item 행동 – Get(Got) • 항목 이름 1. 스네이크 표기법(단어를 밑줄로 구분하는 방법)을 따른다. 예) player_level ... (중략) 예제

첫문자를 대문자로 시작하는 표기법)을 따른다. 2. 이벤트의 구성요소들과 상태 변화 또는 행동에 대한 내용을 모두 포함한다. 예) 플레이어의 아이템 획득 → PlayerGotItem 구성요소 - Player, Item 행동 – Get(Got) • 항목 이름 1. 스네이크 표기법(단어를 밑줄로 구분하는 방법)을 따른다. 예) player_level ... (중략) 예제 이 규약에 대해서 간단하게 예시를 들어보자면

첫문자를 대문자로 시작하는 표기법)을 따른다. 2. 이벤트의 구성요소들과 상태 변화 또는 행동에 대한 내용을 모두 포함한다. 예) 플레이어의 아이템 획득 → PlayerGotItem 구성요소 - Player, Item 행동 – Get(Got) • 항목 이름 1. 스네이크 표기법(단어를 밑줄로 구분하는 방법)을 따른다. 예) player_level ... (중략) 예제 이벤트와 항목의 이름에 대해서 어떤 표기법을 사용할 것인지

첫문자를 대문자로 시작하는 표기법)을 따른다. 2. 이벤트의 구성요소들과 상태 변화 또는 행동에 대한 내용을 모두 포함한다. 예) 플레이어의 아이템 획득 → PlayerGotItem 구성요소 - Player, Item 행동 – Get(Got) • 항목 이름 1. 스네이크 표기법(단어를 밑줄로 구분하는 방법)을 따른다. 예) player_level ... (중략) 예제 어떤 내용이 꼭 포함되어야 하는지에 대한 내용들이 정의되어 있어야 합니다.

이벤트를 구별하는 기준 ‘퀘스트의 시작’, ‘퀘스트의 종료’ vs ‘퀘스트 상태
업데이트’

업데이트’ 다음으로는 이벤트를 구별하는 기준입니다.

업데이트’ 퀘스트의 시작과 종료를 각각의 이벤트로 구별하는 것과

업데이트’ 이것을 ‘퀘스트 상태 업데이트’라는 하나의 이벤트로 만드는 것의 차이에 대한 이야기인데요.

이벤트를 구별하는 기준 • ‘〈상태〉의 시작’, ‘〈상태〉의 종료’ • 상태의
시작과 종료를 이벤트로 분류하는 구조 • 의미적으로 명확하게 구분이 가능하지만, 이벤트 종류가 많아질 수 있음. • 시작과 완료 시 항목 구성의 차이가 큰 경우에 적합 PlayerStartedQuest PlayerCompletedQuest 예) time quest_id player_id a b c … … … … … … time quest_id player_id d e f … … … … … …

시작과 종료를 이벤트로 분류하는 구조 • 의미적으로 명확하게 구분이 가능하지만, 이벤트 종류가 많아질 수 있음. • 시작과 완료 시 항목 구성의 차이가 큰 경우에 적합 PlayerStartedQuest PlayerCompletedQuest 예) time quest_id player_id a b c … … … … … … time quest_id player_id d e f … … … … … … 먼저 시작과 종료를 서로 다른 이벤트로 만드는 경우를 살펴보면

시작과 종료를 이벤트로 분류하는 구조 • 의미적으로 명확하게 구분이 가능하지만, 이벤트 종류가 많아질 수 있음. • 시작과 완료 시 항목 구성의 차이가 큰 경우에 적합 PlayerStartedQuest PlayerCompletedQuest 예) time quest_id player_id a b c … … … … … … time quest_id player_id d e f … … … … … … 아래 예제와 같이 시작과 종료 각각의 테이블로 나뉜다고 보시면 됩니다.

시작과 종료를 이벤트로 분류하는 구조 • 의미적으로 명확하게 구분이 가능하지만, 이벤트 종류가 많아질 수 있음. • 시작과 완료 시 항목 구성의 차이가 큰 경우에 적합 PlayerStartedQuest PlayerCompletedQuest 예) time quest_id player_id a b c … … … … … … time quest_id player_id d e f … … … … … … 저도 사실 처음에는 모든 로그를 이런 방식으로 각각의 이벤트로 만들었는데요.

시작과 종료를 이벤트로 분류하는 구조 • 의미적으로 명확하게 구분이 가능하지만, 이벤트 종류가 많아질 수 있음. • 시작과 완료 시 항목 구성의 차이가 큰 경우에 적합 PlayerStartedQuest PlayerCompletedQuest 예) time quest_id player_id a b c … … … … … … time quest_id player_id d e f … … … … … … 이런 경우 의미 단위로 명확하게 이벤트를 구분할 수 있지만

시작과 종료를 이벤트로 분류하는 구조 • 의미적으로 명확하게 구분이 가능하지만, 이벤트 종류가 많아질 수 있음. • 시작과 완료 시 항목 구성의 차이가 큰 경우에 적합 PlayerStartedQuest PlayerCompletedQuest 예) time quest_id player_id a b c … … … … … … time quest_id player_id d e f … … … … … … 결과적으로 여러 콘텐츠나 기능이 추가되면서 이벤트 종류가 급격하게 많아질 수 있다는 것을 고려해야 합니다.

시작과 종료를 이벤트로 분류하는 구조 • 의미적으로 명확하게 구분이 가능하지만, 이벤트 종류가 많아질 수 있음. • 시작과 완료 시 항목 구성의 차이가 큰 경우에 적합 PlayerStartedQuest PlayerCompletedQuest 예) time quest_id player_id a b c … … … … … … time quest_id player_id d e f … … … … … …

시작과 종료를 이벤트로 분류하는 구조 • 의미적으로 명확하게 구분이 가능하지만, 이벤트 종류가 많아질 수 있음. • 시작과 완료 시 항목 구성의 차이가 큰 경우에 적합 PlayerStartedQuest PlayerCompletedQuest 예) time quest_id player_id a b c … … … … … … time quest_id player_id d e f … … … … … … 아래 예제처럼 시작에는 a, b, c 항목이 존재하고 종료에는 d, e, f 항목이 존재하는 것과 같이

시작과 종료를 이벤트로 분류하는 구조 • 의미적으로 명확하게 구분이 가능하지만, 이벤트 종류가 많아질 수 있음. • 시작과 완료 시 항목 구성의 차이가 큰 경우에 적합 PlayerStartedQuest PlayerCompletedQuest 예) time quest_id player_id a b c … … … … … … time quest_id player_id d e f … … … … … … 항목 구성의 차이가 클 때 좀 더 적합한 구조라고 생각하시면 됩니다.

이벤트를 구별하는 기준 • ‘〈상태〉 업데이트’ • 로그 항목에서 상태변화의
종류를 알 수 있는 구조 • 아래의 경우에 좀 더 편리하게 분석할 수 있음 1. 같은 구성요소에 대해 상태만 변한다. 2. 항목 구성이 거의 비슷하다. 3. 이력의 변화가 중요하다. time quest_id player_id action … … … start … … … complete PlayerUpdatedQuest 예)

종류를 알 수 있는 구조 • 아래의 경우에 좀 더 편리하게 분석할 수 있음 1. 같은 구성요소에 대해 상태만 변한다. 2. 항목 구성이 거의 비슷하다. 3. 이력의 변화가 중요하다. time quest_id player_id action … … … start … … … complete PlayerUpdatedQuest 예) 다음은 시작과 종료를 하나의 이벤트로 묶고

종류를 알 수 있는 구조 • 아래의 경우에 좀 더 편리하게 분석할 수 있음 1. 같은 구성요소에 대해 상태만 변한다. 2. 항목 구성이 거의 비슷하다. 3. 이력의 변화가 중요하다. time quest_id player_id action … … … start … … … complete PlayerUpdatedQuest 예) 이런 상태변화를 구분할 수 있는 값을 항목으로 만드는 경우입니다.

종류를 알 수 있는 구조 • 아래의 경우에 좀 더 편리하게 분석할 수 있음 1. 같은 구성요소에 대해 상태만 변한다. 2. 항목 구성이 거의 비슷하다. 3. 이력의 변화가 중요하다. time quest_id player_id action … … … start … … … complete PlayerUpdatedQuest 예) 예제를 보시면 업데이트라는 이벤트로 묶고 ‘action’이라는 항목으로 시작과 종료를 구분하는데요.

종류를 알 수 있는 구조 • 아래의 경우에 좀 더 편리하게 분석할 수 있음 1. 같은 구성요소에 대해 상태만 변한다. 2. 항목 구성이 거의 비슷하다. 3. 이력의 변화가 중요하다. time quest_id player_id action … … … start … … … complete PlayerUpdatedQuest 예) 이렇게 같은 구성요소에 대해 상태만 변하고

종류를 알 수 있는 구조 • 아래의 경우에 좀 더 편리하게 분석할 수 있음 1. 같은 구성요소에 대해 상태만 변한다. 2. 항목 구성이 거의 비슷하다. 3. 이력의 변화가 중요하다. time quest_id player_id action … … … start … … … complete PlayerUpdatedQuest 예) 담는 항목들의 구성이 거의 차이가 없을 때

종류를 알 수 있는 구조 • 아래의 경우에 좀 더 편리하게 분석할 수 있음 1. 같은 구성요소에 대해 상태만 변한다. 2. 항목 구성이 거의 비슷하다. 3. 이력의 변화가 중요하다. time quest_id player_id action … … … start … … … complete PlayerUpdatedQuest 예) 그리고 상태 변화의 이력이 중요한 경우에 좀 더 적합한 경우라고 볼 수 있습니다.

이벤트를 구별하는 기준 • 한 이벤트가 억지로 여러 가지 이벤트를
포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음

포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음 앞서 말씀드렸던 것은 퀘스트의 시작과 종료뿐만 아니라

포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음 재화의 사용 또는 획득, 플레이어의 접속과 종료 등 다양한 케이스에서 생각해볼 수 있는데요.

포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음 중요한 것은, 어느 것이 적합할 것인지 판단하는 것입니다.

포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음 이전 예제에서는 묶는 것이 좀 더 좋은 경우라고 말씀드렸지만

포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음 반대로 하나의 이벤트가 억지로 여러 가지 이벤트를 포괄하지 않는 것 또한 중요합니다,

포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음 특정 이벤트에 대한 내용이 변경될 때 유연한 대처가 어렵고

포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음 결국 이름이 가지는 의미가 불명확해지거나

포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음 데이터 타입이나 표현 방법을 통일하게 되면서

포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음 데이터를 상세하게 남기지 못하는 문제가 발생할 수 있기 때문입니다.

표현력 • 약간의 데이터 용량 절감을 위해 축약된 표현을 사용하지
않는다. • 저장 비용은 크지 않고, 경우에 따라 압축이 가능하다. • 득보다 실이 많을 수 있다. • 경우에 따라 데이터 타입에 대한 고려 또한 필요 예) 소수점 표현, 숫자 범위

않는다. • 저장 비용은 크지 않고, 경우에 따라 압축이 가능하다. • 득보다 실이 많을 수 있다. • 경우에 따라 데이터 타입에 대한 고려 또한 필요 예) 소수점 표현, 숫자 범위 다음은 표현력에 대한 이야기입니다.

않는다. • 저장 비용은 크지 않고, 경우에 따라 압축이 가능하다. • 득보다 실이 많을 수 있다. • 경우에 따라 데이터 타입에 대한 고려 또한 필요 예) 소수점 표현, 숫자 범위 첫 번째는 약간의 데이터 용량 절감을 위해 굳이 축약된 표현을 사용하지 않는 것입니다.

않는다. • 저장 비용은 크지 않고, 경우에 따라 압축이 가능하다. • 득보다 실이 많을 수 있다. • 경우에 따라 데이터 타입에 대한 고려 또한 필요 예) 소수점 표현, 숫자 범위 스토리지 비용, 즉 저장비용은 크지 않고 경우에 따라서는 로그 시스템상에서 압축이 가능하기 때문입니다.

않는다. • 저장 비용은 크지 않고, 경우에 따라 압축이 가능하다. • 득보다 실이 많을 수 있다. • 경우에 따라 데이터 타입에 대한 고려 또한 필요 예) 소수점 표현, 숫자 범위 오히려 축약된 표현을 사용함으로써 생산성의 저하가 발생할 수 있습니다.

않는다. • 저장 비용은 크지 않고, 경우에 따라 압축이 가능하다. • 득보다 실이 많을 수 있다. • 경우에 따라 데이터 타입에 대한 고려 또한 필요 예) 소수점 표현, 숫자 범위 두 번째는 데이터 타입에 대한 이야기입니다.

않는다. • 저장 비용은 크지 않고, 경우에 따라 압축이 가능하다. • 득보다 실이 많을 수 있다. • 경우에 따라 데이터 타입에 대한 고려 또한 필요 예) 소수점 표현, 숫자 범위 예를 들어 소수점 단위가 중요한 경우나, 실제 값에 들어갈 숫자의 범위에 따라

않는다. • 저장 비용은 크지 않고, 경우에 따라 압축이 가능하다. • 득보다 실이 많을 수 있다. • 경우에 따라 데이터 타입에 대한 고려 또한 필요 예) 소수점 표현, 숫자 범위 기술적으로 필요한 데이터 타입이 다를 수 있다는 것을 고려해야 합니다.

빈 값의 의미를 명확하게 • 빈 값은 다양하게 해석될 수
있음 • 해당 항목에 대한 정보가 아예 존재하지 않는 경우 • 실제 값이 빈 값이 경우 • 명확하게 하는 것에 의의

있음 • 해당 항목에 대한 정보가 아예 존재하지 않는 경우 • 실제 값이 빈 값이 경우 • 명확하게 하는 것에 의의 마지막으로 빈 값에 대한 이야기입니다.

있음 • 해당 항목에 대한 정보가 아예 존재하지 않는 경우 • 실제 값이 빈 값이 경우 • 명확하게 하는 것에 의의 실제로 빈 값이라는 것은 해당 정보가 아예 존재하지 않는 경우일 수도 있고

있음 • 해당 항목에 대한 정보가 아예 존재하지 않는 경우 • 실제 값이 빈 값이 경우 • 명확하게 하는 것에 의의 값이 실제로 빈 값일 수 있기 때문에 여러가지 의미로 해석될 수 있습니다.

있음 • 해당 항목에 대한 정보가 아예 존재하지 않는 경우 • 실제 값이 빈 값이 경우 • 명확하게 하는 것에 의의 때문에 이런 빈 값들의 의미를 명확하게 할 필요성이 있습니다.

여기까지 정리 • 의미가 명확한 로그를 위해 고려할 것들 •
이름에 대한 합의와 규약 • 이벤트를 구별하는 기준 • 표현력 • 빈 값의 의미를 명확하게 지금까지, 의미가 명확한 로그를 위해 필요한 것들을 이야기해보았는데요.

Chapter 2-3. 편리하게 데이터를 얻기 위해 고려할 것들

Chapter 2-3. 편리하게 데이터를 얻기 위해 고려할 것들 여기까지 오늘
발표 내용의 반쯤 왔는데

Chapter 2-3. 편리하게 데이터를 얻기 위해 고려할 것들 다음은 우리가
실제로 로그를 사용하게 될 때

Chapter 2-3. 편리하게 데이터를 얻기 위해 고려할 것들 좀 더
편리하게 로그를 다룰 수 있도록 하기 위해 고려할 것들입니다.

로그 형식 • 서비스 로그는 특정 항목에 대한 접근이 필요한
경우가 많음 • 필요한 요소 • 컴퓨터가 읽기 쉽도록 구조화된 형식 • 사람이 읽을 수 있는 형식 • 일반적으로 많이 쓰이는 형식 • JSON, key/value { "type":"PlayerGotItem", "player_id":"jeonhyojun", "time":"2019-04-26T……", "item_id":"1a2b3c4d5e6f", ... } JSON

경우가 많음 • 필요한 요소 • 컴퓨터가 읽기 쉽도록 구조화된 형식 • 사람이 읽을 수 있는 형식 • 일반적으로 많이 쓰이는 형식 • JSON, key/value { "type":"PlayerGotItem", "player_id":"jeonhyojun", "time":"2019-04-26T……", "item_id":"1a2b3c4d5e6f", ... } JSON 첫 번째로는, 실제로 로그가 어떤 형식으로 기록되는 것이 좋은지에 대한 이야기인데요.

경우가 많음 • 필요한 요소 • 컴퓨터가 읽기 쉽도록 구조화된 형식 • 사람이 읽을 수 있는 형식 • 일반적으로 많이 쓰이는 형식 • JSON, key/value { "type":"PlayerGotItem", "player_id":"jeonhyojun", "time":"2019-04-26T……", "item_id":"1a2b3c4d5e6f", ... } JSON 서비스 로그는 특정 항목에 대한 접근이 필요한 경우가 많고

경우가 많음 • 필요한 요소 • 컴퓨터가 읽기 쉽도록 구조화된 형식 • 사람이 읽을 수 있는 형식 • 일반적으로 많이 쓰이는 형식 • JSON, key/value { "type":"PlayerGotItem", "player_id":"jeonhyojun", "time":"2019-04-26T……", "item_id":"1a2b3c4d5e6f", ... } JSON 이를 집계하거나 검색하는 일이 많기 때문에

경우가 많음 • 필요한 요소 • 컴퓨터가 읽기 쉽도록 구조화된 형식 • 사람이 읽을 수 있는 형식 • 일반적으로 많이 쓰이는 형식 • JSON, key/value { "type":"PlayerGotItem", "player_id":"jeonhyojun", "time":"2019-04-26T……", "item_id":"1a2b3c4d5e6f", ... } JSON 컴퓨터가 읽기 쉽도록 구조화된 형식임과 동시에 어느 정도는 사람이 읽을 수 있는 형식이 필요합니다.

경우가 많음 • 필요한 요소 • 컴퓨터가 읽기 쉽도록 구조화된 형식 • 사람이 읽을 수 있는 형식 • 일반적으로 많이 쓰이는 형식 • JSON, key/value { "type":"PlayerGotItem", "player_id":"jeonhyojun", "time":"2019-04-26T……", "item_id":"1a2b3c4d5e6f", ... } JSON 일반적으로는 오른쪽 보기와 같이 키와 값의 쌍으로 이루어진 JSON이라는 형식이 사용됩니다.

메타데이터 사용에 대한 충분한 고민 • 메타데이터란? • 서비스를 구성하는
정보에 대하여, 식별자와 그 상세정보가 매핑된 데이터

정보에 대하여, 식별자와 그 상세정보가 매핑된 데이터 다음은 메타데이터 사용에 대한 이야기입니다.

정보에 대하여, 식별자와 그 상세정보가 매핑된 데이터 여기서 메타데이터란, 서비스를 구성하는 어떤 정보에 대해서 식별자와 그 상세정보가 매핑된 데이터인데요.

정보에 대하여, 식별자와 그 상세정보가 매핑된 데이터 퀘스트 아이디(식별자) 최소 요구 레벨 … tutorial_1 … … tutorial_2 … … … … … 퀘스트 메타데이터 { "type":"PlayerUpdatedQuest", "player_id":"jeonhyojun", "quest_id":"tutorial_1", "time":"2019-04-24T……", ... } 예) 로그

정보에 대하여, 식별자와 그 상세정보가 매핑된 데이터 퀘스트 아이디(식별자) 최소 요구 레벨 … tutorial_1 … … tutorial_2 … … … … … 퀘스트 메타데이터 { "type":"PlayerUpdatedQuest", "player_id":"jeonhyojun", "quest_id":"tutorial_1", "time":"2019-04-24T……", ... } 예) 로그 예를 들면, 오른쪽에 보시는 바와 같이

정보에 대하여, 식별자와 그 상세정보가 매핑된 데이터 퀘스트 아이디(식별자) 최소 요구 레벨 … tutorial_1 … … tutorial_2 … … … … … 퀘스트 메타데이터 { "type":"PlayerUpdatedQuest", "player_id":"jeonhyojun", "quest_id":"tutorial_1", "time":"2019-04-24T……", ... } 예) 로그 퀘스트 아이디가 있고 다른 정보들이 매핑되어있는 테이블을 메타데이터라고 할 수 있습니다.

정보에 대하여, 식별자와 그 상세정보가 매핑된 데이터 퀘스트 아이디(식별자) 최소 요구 레벨 … tutorial_1 … … tutorial_2 … … … … … 퀘스트 메타데이터 { "type":"PlayerUpdatedQuest", "player_id":"jeonhyojun", "quest_id":"tutorial_1", "time":"2019-04-24T……", ... } 예) 로그 로그에서 이 메타데이터를 사용한다는 것은

정보에 대하여, 식별자와 그 상세정보가 매핑된 데이터 퀘스트 아이디(식별자) 최소 요구 레벨 … tutorial_1 … … tutorial_2 … … … … … 퀘스트 메타데이터 { "type":"PlayerUpdatedQuest", "player_id":"jeonhyojun", "quest_id":"tutorial_1", "time":"2019-04-24T……", ... } 예) 로그

정보에 대하여, 식별자와 그 상세정보가 매핑된 데이터 퀘스트 아이디(식별자) 최소 요구 레벨 … tutorial_1 … … tutorial_2 … … … … … 퀘스트 메타데이터 { "type":"PlayerUpdatedQuest", "player_id":"jeonhyojun", "quest_id":"tutorial_1", "time":"2019-04-24T……", ... } 예) 로그 로그에는 퀘스트 상세정보를 남기지 않고 퀘스트 아이디만 기록하여

정보에 대하여, 식별자와 그 상세정보가 매핑된 데이터 퀘스트 아이디(식별자) 최소 요구 레벨 … tutorial_1 … … tutorial_2 … … … … … 퀘스트 메타데이터 { "type":"PlayerUpdatedQuest", "player_id":"jeonhyojun", "quest_id":"tutorial_1", "time":"2019-04-24T……", ... } 예) 로그 실제로 로그를 사용할 때는 메타데이터를 참조하여 나머지 정보를 얻는 방식인데요.

메타데이터 사용에 대한 충분한 고민 • 메타데이터의 남용은 관리 이슈와
생산성 저하를 유발 • 메타데이터가 많아지면 관리하기 힘들어짐 • 집계 시마다 로그 외의 다른 데이터를 참조해야 함 • 때문에 본래 목표를 위한 기본적인 데이터는 로그 항목에 포함하는 것이 좋다.

생산성 저하를 유발 • 메타데이터가 많아지면 관리하기 힘들어짐 • 집계 시마다 로그 외의 다른 데이터를 참조해야 함 • 때문에 본래 목표를 위한 기본적인 데이터는 로그 항목에 포함하는 것이 좋다. 로그에 존재하는 대부분의 정보를 메타데이터로 만들게 되면

생산성 저하를 유발 • 메타데이터가 많아지면 관리하기 힘들어짐 • 집계 시마다 로그 외의 다른 데이터를 참조해야 함 • 때문에 본래 목표를 위한 기본적인 데이터는 로그 항목에 포함하는 것이 좋다. 메타데이터가 많아질수록 관리하기 힘들어지고

생산성 저하를 유발 • 메타데이터가 많아지면 관리하기 힘들어짐 • 집계 시마다 로그 외의 다른 데이터를 참조해야 함 • 때문에 본래 목표를 위한 기본적인 데이터는 로그 항목에 포함하는 것이 좋다. 집계 시마다 메타데이터를 참조해야 합니다.

생산성 저하를 유발 • 메타데이터가 많아지면 관리하기 힘들어짐 • 집계 시마다 로그 외의 다른 데이터를 참조해야 함 • 때문에 본래 목표를 위한 기본적인 데이터는 로그 항목에 포함하는 것이 좋다. 경우에 따라 메타데이터가 변경된 이력도 고려해야 할 수 있기 때문에

생산성 저하를 유발 • 메타데이터가 많아지면 관리하기 힘들어짐 • 집계 시마다 로그 외의 다른 데이터를 참조해야 함 • 때문에 본래 목표를 위한 기본적인 데이터는 로그 항목에 포함하는 것이 좋다. 관리 이슈와 생산성 저하를 일으킬 수 있습니다.

생산성 저하를 유발 • 메타데이터가 많아지면 관리하기 힘들어짐 • 집계 시마다 로그 외의 다른 데이터를 참조해야 함 • 때문에 본래 목표를 위한 기본적인 데이터는 로그 항목에 포함하는 것이 좋다. 따라서 본래 정의했던 로그의 목표에 꼭 필요한 데이터라면 로그에 포함하는 것이 좋습니다.

메타데이터 사용에 대한 충분한 고민 • 메타데이터 사용의 적절한 예
• 정적 데이터가 과도하게 많고, 정의했던 로그의 목표에 필요하지 않은 경우 → 목표에 꼭 필요한 데이터라면 로그의 항목으로 구성하는 게 좋다. • 변경 주체가 서비스 제공자에게 있는 경우에 한하여 사용 • 메타데이터가 불가피하게 많아질 경우 → 시스템에서 메타데이터를 효율적으로 관리하고 사용할 수 있는 도구가 필요

• 정적 데이터가 과도하게 많고, 정의했던 로그의 목표에 필요하지 않은 경우 → 목표에 꼭 필요한 데이터라면 로그의 항목으로 구성하는 게 좋다. • 변경 주체가 서비스 제공자에게 있는 경우에 한하여 사용 • 메타데이터가 불가피하게 많아질 경우 → 시스템에서 메타데이터를 효율적으로 관리하고 사용할 수 있는 도구가 필요 좀 더 구체적으로 이야기해보면

• 정적 데이터가 과도하게 많고, 정의했던 로그의 목표에 필요하지 않은 경우 → 목표에 꼭 필요한 데이터라면 로그의 항목으로 구성하는 게 좋다. • 변경 주체가 서비스 제공자에게 있는 경우에 한하여 사용 • 메타데이터가 불가피하게 많아질 경우 → 시스템에서 메타데이터를 효율적으로 관리하고 사용할 수 있는 도구가 필요 어떤 구성요소에 대해 거의 변하지 않는 정적인 데이터가 과도하게 많고

• 정적 데이터가 과도하게 많고, 정의했던 로그의 목표에 필요하지 않은 경우 → 목표에 꼭 필요한 데이터라면 로그의 항목으로 구성하는 게 좋다. • 변경 주체가 서비스 제공자에게 있는 경우에 한하여 사용 • 메타데이터가 불가피하게 많아질 경우 → 시스템에서 메타데이터를 효율적으로 관리하고 사용할 수 있는 도구가 필요 이런 데이터들이 이전에 정의했던 로그의 목표에 필요하지 않은 경우에는

• 정적 데이터가 과도하게 많고, 정의했던 로그의 목표에 필요하지 않은 경우 → 목표에 꼭 필요한 데이터라면 로그의 항목으로 구성하는 게 좋다. • 변경 주체가 서비스 제공자에게 있는 경우에 한하여 사용 • 메타데이터가 불가피하게 많아질 경우 → 시스템에서 메타데이터를 효율적으로 관리하고 사용할 수 있는 도구가 필요 메타데이터를 만들어 사용하는 것이 좋은데요.

• 정적 데이터가 과도하게 많고, 정의했던 로그의 목표에 필요하지 않은 경우 → 목표에 꼭 필요한 데이터라면 로그의 항목으로 구성하는 게 좋다. • 변경 주체가 서비스 제공자에게 있는 경우에 한하여 사용 • 메타데이터가 불가피하게 많아질 경우 → 시스템에서 메타데이터를 효율적으로 관리하고 사용할 수 있는 도구가 필요 반대로 로그의 목표에 필요한 데이터라면 자주 참조될 데이터이기 때문에

• 정적 데이터가 과도하게 많고, 정의했던 로그의 목표에 필요하지 않은 경우 → 목표에 꼭 필요한 데이터라면 로그의 항목으로 구성하는 게 좋다. • 변경 주체가 서비스 제공자에게 있는 경우에 한하여 사용 • 메타데이터가 불가피하게 많아질 경우 → 시스템에서 메타데이터를 효율적으로 관리하고 사용할 수 있는 도구가 필요 로그에 직접 값을 포함하는 것이 좋습니다.

• 정적 데이터가 과도하게 많고, 정의했던 로그의 목표에 필요하지 않은 경우 → 목표에 꼭 필요한 데이터라면 로그의 항목으로 구성하는 게 좋다. • 변경 주체가 서비스 제공자에게 있는 경우에 한하여 사용 • 메타데이터가 불가피하게 많아질 경우 → 시스템에서 메타데이터를 효율적으로 관리하고 사용할 수 있는 도구가 필요 여기서 로그의 목표를 정의하는 것의 중요성을 다시 한번 강조 드리고 싶습니다.

• 정적 데이터가 과도하게 많고, 정의했던 로그의 목표에 필요하지 않은 경우 → 목표에 꼭 필요한 데이터라면 로그의 항목으로 구성하는 게 좋다. • 변경 주체가 서비스 제공자에게 있는 경우에 한하여 사용 • 메타데이터가 불가피하게 많아질 경우 → 시스템에서 메타데이터를 효율적으로 관리하고 사용할 수 있는 도구가 필요 또한 메타데이터로 만들 것들은 당연히 유저나 다른 환경에 의해서 변경되지 않고

• 정적 데이터가 과도하게 많고, 정의했던 로그의 목표에 필요하지 않은 경우 → 목표에 꼭 필요한 데이터라면 로그의 항목으로 구성하는 게 좋다. • 변경 주체가 서비스 제공자에게 있는 경우에 한하여 사용 • 메타데이터가 불가피하게 많아질 경우 → 시스템에서 메타데이터를 효율적으로 관리하고 사용할 수 있는 도구가 필요 서비스 제공자만 변경할 수 있어야 하고요.

• 정적 데이터가 과도하게 많고, 정의했던 로그의 목표에 필요하지 않은 경우 → 목표에 꼭 필요한 데이터라면 로그의 항목으로 구성하는 게 좋다. • 변경 주체가 서비스 제공자에게 있는 경우에 한하여 사용 • 메타데이터가 불가피하게 많아질 경우 → 시스템에서 메타데이터를 효율적으로 관리하고 사용할 수 있는 도구가 필요 서비스가 성장하면서 메타데이터가 불가피하게 많아질 경우에는

• 정적 데이터가 과도하게 많고, 정의했던 로그의 목표에 필요하지 않은 경우 → 목표에 꼭 필요한 데이터라면 로그의 항목으로 구성하는 게 좋다. • 변경 주체가 서비스 제공자에게 있는 경우에 한하여 사용 • 메타데이터가 불가피하게 많아질 경우 → 시스템에서 메타데이터를 효율적으로 관리하고 사용할 수 있는 도구가 필요 결국 메타데이터를 효율적으로 관리하고 사용하기 위한 도구가 필요할 것입니다.

문맥 식별자와 고유 식별자 • 문맥 식별자(Context identifier) • 하나의
행동으로 일어난 여러 개의 로그는 같은 문맥 식별자를 갖게 함 • 인과관계나 선후관계를 파악하는 데 도움을 준다.

행동으로 일어난 여러 개의 로그는 같은 문맥 식별자를 갖게 함 • 인과관계나 선후관계를 파악하는 데 도움을 준다. 다음은 문맥 식별자와 고유 식별자입니다.

행동으로 일어난 여러 개의 로그는 같은 문맥 식별자를 갖게 함 • 인과관계나 선후관계를 파악하는 데 도움을 준다. 문맥 식별자는, 하나의 행동으로 일어난 여러 로그들은 같은 식별자를 가지게 하는 것인데요.

문맥 식별자와 고유 식별자 • 문맥 식별자(Context identifier) { "type":"PlayerExpUp",
"context_id": "1a2b3c4d5e", ... } → 문맥 식별자로 검색 “이 플레이어가 경험치를 어떤 경로로 획득했을까?” 예를 들어, 유저가 경험치 획득한 로그를 보고 어떤 경로로 획득했는지 궁금하다면

문맥 식별자와 고유 식별자 • 문맥 식별자(Context identifier) { "type":"PlayerExpUp",
"context_id": "1a2b3c4d5e", ... } → 문맥 식별자로 검색 “이 플레이어가 경험치를 어떤 경로로 획득했을까?” 해당 로그와 같은 문맥 식별자를 가지고 있는 다른 로그를 찾아볼 수 있습니다.

{ "type": "PlayerUpdatedQuest", "context_id": "1a2b3c4d5e", "action": "complete", ... } 문맥
식별자와 고유 식별자 • 문맥 식별자(Context identifier) “이 플레이어가 경험치를 어떤 경로로 획득했을까?” “퀘스트 완료를 통해 획득했구나!” { "type":"PlayerExpUp", "context_id": "1a2b3c4d5e", ... } → 문맥 식별자로 검색 → 인과관계 확인가능

{ "type": "PlayerUpdatedQuest", "context_id": "1a2b3c4d5e", "action": "complete", ... } 문맥
식별자와 고유 식별자 • 문맥 식별자(Context identifier) “이 플레이어가 경험치를 어떤 경로로 획득했을까?” “퀘스트 완료를 통해 획득했구나!” { "type":"PlayerExpUp", "context_id": "1a2b3c4d5e", ... } → 문맥 식별자로 검색 → 인과관계 확인가능 만약 퀘스트 완료 로그와 같은 문맥 식별자를 가졌다면

{ "type": "PlayerUpdatedQuest", "context_id": "1a2b3c4d5e", "action": "complete", ... } {
"type":"PlayerExpUp", "context_id": "1a2b3c4d5e", ... } 문맥 식별자와 고유 식별자 • 문맥 식별자(Context identifier) “이 플레이어가 경험치를 어떤 경로로 획득했을까?” “퀘스트 완료를 통해 획득했구나!” → 문맥 식별자로 검색 → 인과관계 확인가능 퀘스트를 완료함으로써 경험치를 얻었다는 것을 확인할 수 있습니다.

"type":"PlayerExpUp", "context_id": "1a2b3c4d5e", ... } 문맥 식별자와 고유 식별자 • 문맥 식별자(Context identifier) “이 플레이어가 경험치를 어떤 경로로 획득했을까?” “퀘스트 완료를 통해 획득했구나!” → 문맥 식별자로 검색 → 인과관계 확인가능 물론 로그의 발생 시간으로 어느 정도 유추가 가능하지만

"type":"PlayerExpUp", "context_id": "1a2b3c4d5e", ... } 문맥 식별자와 고유 식별자 • 문맥 식별자(Context identifier) “이 플레이어가 경험치를 어떤 경로로 획득했을까?” “퀘스트 완료를 통해 획득했구나!” → 문맥 식별자로 검색 → 인과관계 확인가능 문맥 식별자를 활용하면, 더 정확하게 인과관계나 선후관계를 파악할 수 있습니다.

"type":"PlayerExpUp", "context_id": "1a2b3c4d5e", ... } 문맥 식별자와 고유 식별자 • 문맥 식별자(Context identifier) “이 플레이어가 경험치를 어떤 경로로 획득했을까?” “퀘스트 완료를 통해 획득했구나!” → 문맥 식별자로 검색 → 인과관계 확인가능 또한, 대규모 집계 시에 큰 도움을 주기 때문에 꼭 넣는 것을 추천드립니다.

문맥 식별자와 고유 식별자 • 고유 식별자(Unique identifier) • 중복
로그를 쉽게 식별할 수 있음 • 특정한 로그 하나를 기준으로 잡기 편리함

로그를 쉽게 식별할 수 있음 • 특정한 로그 하나를 기준으로 잡기 편리함 다음은 고유 식별자입니다.

로그를 쉽게 식별할 수 있음 • 특정한 로그 하나를 기준으로 잡기 편리함 하나의 로그에 대한 고유한 식별자로 생각하시면 되는데요.

로그를 쉽게 식별할 수 있음 • 특정한 로그 하나를 기준으로 잡기 편리함 각각의 유일한 식별자를 가지게 된다면

로그를 쉽게 식별할 수 있음 • 특정한 로그 하나를 기준으로 잡기 편리함 시스템상 오류로 인한 중복 로그를 쉽게 식별할 수 있을 뿐만 아니라

로그를 쉽게 식별할 수 있음 • 특정한 로그 하나를 기준으로 잡기 편리함 특정 로그를 기준으로 집계가 필요한 경우

로그를 쉽게 식별할 수 있음 • 특정한 로그 하나를 기준으로 잡기 편리함 여러 개의 필터 조건 없이 하나의 로그를 특정하기 편리해집니다.

여기까지 정리 • 편리하게 데이터를 얻기 위해 고려할 것들 •
로그 형식 • 메타데이터 사용에 대한 충분한 고민 • 문맥 식별자와 고유 식별자 여기까지 편리하게 데이터를 얻기 위해 고려할 것들로 세 가지를 이야기해봤는데요.

Chapter 2-4. 다른 관점에서 생각해볼 것

Chapter 2-4. 다른 관점에서 생각해볼 것 마지막으로는, 지금까지와 약간 다른
관점에서 생각해야 할 것들입니다.

서비스에 줄 수 있는 영향 • 배보다 배꼽이 큰 경우가
있을 수 있음 • 기술적인 한계를 해결하거나, 또는 적절한 타협점을 찾아야 함 • 예) 로그에 필요한 값을 채우는 것이 서버에 과도한 부하를 일으킬 수 있는 경우 → 서버에서 캐싱 하거나 또는 메타데이터를 활용하거나 • 예) 모든 유저에 대하여 n초마다 발생하는 로그 → 샘플링하거나, 변경 시에만 남기거나

있을 수 있음 • 기술적인 한계를 해결하거나, 또는 적절한 타협점을 찾아야 함 • 예) 로그에 필요한 값을 채우는 것이 서버에 과도한 부하를 일으킬 수 있는 경우 → 서버에서 캐싱 하거나 또는 메타데이터를 활용하거나 • 예) 모든 유저에 대하여 n초마다 발생하는 로그 → 샘플링하거나, 변경 시에만 남기거나 첫 번째는 로그도 로그지만 서비스에 줄 수 있는 영향을 생각하지 않을 수 없다는 것입니다.

있을 수 있음 • 기술적인 한계를 해결하거나, 또는 적절한 타협점을 찾아야 함 • 예) 로그에 필요한 값을 채우는 것이 서버에 과도한 부하를 일으킬 수 있는 경우 → 서버에서 캐싱 하거나 또는 메타데이터를 활용하거나 • 예) 모든 유저에 대하여 n초마다 발생하는 로그 → 샘플링하거나, 변경 시에만 남기거나 예를 들어 로그에 필요한 값을 채우는 것이 서버에 과도한 부하를 일으키거나

있을 수 있음 • 기술적인 한계를 해결하거나, 또는 적절한 타협점을 찾아야 함 • 예) 로그에 필요한 값을 채우는 것이 서버에 과도한 부하를 일으킬 수 있는 경우 → 서버에서 캐싱 하거나 또는 메타데이터를 활용하거나 • 예) 모든 유저에 대하여 n초마다 발생하는 로그 → 샘플링하거나, 변경 시에만 남기거나 모든 유저에 대해 n초마다 발생하는 로그가 필요한 경우를 생각해볼 수 있는데요.

있을 수 있음 • 기술적인 한계를 해결하거나, 또는 적절한 타협점을 찾아야 함 • 예) 로그에 필요한 값을 채우는 것이 서버에 과도한 부하를 일으킬 수 있는 경우 → 서버에서 캐싱 하거나 또는 메타데이터를 활용하거나 • 예) 모든 유저에 대하여 n초마다 발생하는 로그 → 샘플링하거나, 변경 시에만 남기거나 전자의 경우, 서버에서 캐싱 하여 기술적으로 해결하는 방법과

있을 수 있음 • 기술적인 한계를 해결하거나, 또는 적절한 타협점을 찾아야 함 • 예) 로그에 필요한 값을 채우는 것이 서버에 과도한 부하를 일으킬 수 있는 경우 → 서버에서 캐싱 하거나 또는 메타데이터를 활용하거나 • 예) 모든 유저에 대하여 n초마다 발생하는 로그 → 샘플링하거나, 변경 시에만 남기거나 메타데이터를 활용하는 방법으로 서버의 부담을 낮추고,

있을 수 있음 • 기술적인 한계를 해결하거나, 또는 적절한 타협점을 찾아야 함 • 예) 로그에 필요한 값을 채우는 것이 서버에 과도한 부하를 일으킬 수 있는 경우 → 서버에서 캐싱 하거나 또는 메타데이터를 활용하거나 • 예) 모든 유저에 대하여 n초마다 발생하는 로그 → 샘플링하거나, 변경 시에만 남기거나 후자의 경우에는 샘플링하거나 값이 변경될 때에만 남기는 방향으로

있을 수 있음 • 기술적인 한계를 해결하거나, 또는 적절한 타협점을 찾아야 함 • 예) 로그에 필요한 값을 채우는 것이 서버에 과도한 부하를 일으킬 수 있는 경우 → 서버에서 캐싱 하거나 또는 메타데이터를 활용하거나 • 예) 모든 유저에 대하여 n초마다 발생하는 로그 → 샘플링하거나, 변경 시에만 남기거나 적절한 타협점을 찾는 것이 중요합니다.

할 수 있는 것부터 • 남기지 않고 있었거나, 잘못 남겨진
데이터는 깔끔히 포기한다. • 현 상황에서 최선의 방향을 찾는다. • 앞으로의 개선 방향을 논의한다.

데이터는 깔끔히 포기한다. • 현 상황에서 최선의 방향을 찾는다. • 앞으로의 개선 방향을 논의한다. 두 번째는 할 수 있는 것부터 하는 것인데요.

데이터는 깔끔히 포기한다. • 현 상황에서 최선의 방향을 찾는다. • 앞으로의 개선 방향을 논의한다. 이미 없거나, 잘못 남겨진 데이터는 쿨하게 포기하고

데이터는 깔끔히 포기한다. • 현 상황에서 최선의 방향을 찾는다. • 앞으로의 개선 방향을 논의한다. 현재 상황에서 최선의 방향을 찾는 것과

데이터는 깔끔히 포기한다. • 현 상황에서 최선의 방향을 찾는다. • 앞으로의 개선 방향을 논의한다. 앞으로의 개선 방향을 논의하는 것이 중요합니다.

정리 좋은 로그를 위해 고려해야 할 것들 7. 빈 값의
의미를 명확하게 8. 로그 형식 9. 메타데이터 사용에 대한 충분한 고민 10. 문맥 식별자와 고유 식별자 11. 서비스에 줄 수 있는 영향 12. 할 수 있는 것부터 1. 목표가 있는 로그 2. 일관성 3. 믿을 수 있는 로그 4. 이름에 대한 합의와 규약 5. 이벤트를 구별하는 기준 6. 표현력

의미를 명확하게 8. 로그 형식 9. 메타데이터 사용에 대한 충분한 고민 10. 문맥 식별자와 고유 식별자 11. 서비스에 줄 수 있는 영향 12. 할 수 있는 것부터 1. 목표가 있는 로그 2. 일관성 3. 믿을 수 있는 로그 4. 이름에 대한 합의와 규약 5. 이벤트를 구별하는 기준 6. 표현력 지금까지 총 12가지의 내용을 이야기했는데요.

의미를 명확하게 8. 로그 형식 9. 메타데이터 사용에 대한 충분한 고민 10. 문맥 식별자와 고유 식별자 11. 서비스에 줄 수 있는 영향 12. 할 수 있는 것부터 1. 목표가 있는 로그 2. 일관성 3. 믿을 수 있는 로그 4. 이름에 대한 합의와 규약 5. 이벤트를 구별하는 기준 6. 표현력 다소 많아 보일 수 있지만

의미를 명확하게 8. 로그 형식 9. 메타데이터 사용에 대한 충분한 고민 10. 문맥 식별자와 고유 식별자 11. 서비스에 줄 수 있는 영향 12. 할 수 있는 것부터 1. 목표가 있는 로그 2. 일관성 3. 믿을 수 있는 로그 4. 이름에 대한 합의와 규약 5. 이벤트를 구별하는 기준 6. 표현력 처음부터 완벽하게 만드는 것은 힘들기 때문에

의미를 명확하게 8. 로그 형식 9. 메타데이터 사용에 대한 충분한 고민 10. 문맥 식별자와 고유 식별자 11. 서비스에 줄 수 있는 영향 12. 할 수 있는 것부터 1. 목표가 있는 로그 2. 일관성 3. 믿을 수 있는 로그 4. 이름에 대한 합의와 규약 5. 이벤트를 구별하는 기준 6. 표현력 할 수 있는 것부터 시작하는 것을 다시 한번 강조 드리고 싶습니다.

Chapter 3. 로그 품질 관리

Chapter 3. 로그 품질 관리 오늘 발표의 마지막 내용인 로그
품질 관리입니다.

품질 관리가 필요한 이유 • 이벤트와 항목들은 서비스가 성장할수록 점점
많아진다. • 계속해서 변경과 특이사항들이 발생할 것이다. • 점점 더 많은 사람들이 데이터로부터 의사결정을 하게 될 것이다.

많아진다. • 계속해서 변경과 특이사항들이 발생할 것이다. • 점점 더 많은 사람들이 데이터로부터 의사결정을 하게 될 것이다. 다들 겪어보셨겠지만, 이벤트와 각각의 항목들은 서비스가 성장할수록 점점 많아지고

많아진다. • 계속해서 변경과 특이사항들이 발생할 것이다. • 점점 더 많은 사람들이 데이터로부터 의사결정을 하게 될 것이다. 계속해서 변경과 특이사항이 발생합니다.

많아진다. • 계속해서 변경과 특이사항들이 발생할 것이다. • 점점 더 많은 사람들이 데이터로부터 의사결정을 하게 될 것이다. 반면에 많은 사람들이 데이터로부터 의사결정을 하게 되면서

많아진다. • 계속해서 변경과 특이사항들이 발생할 것이다. • 점점 더 많은 사람들이 데이터로부터 의사결정을 하게 될 것이다. 로그의 품질관리가 중요한 이슈로 나타나게 되는데요.

품질관리를 위해 필요한 것들

품질관리를 위해 필요한 것들 때문에, 지금까지 이야기했던 것들을 바탕으로

품질관리를 위해 필요한 것들 지속적으로 로그의 품질을 개선하고 관리하기 위해
필요한 것들을 이야기해보려 합니다.

서비스 구성요소별 로그 관리 • 특정 구성요소에 대한 로그를 쉽게
파악할 수 있음 • 로그에 존재하는 항목의 일관성을 유지하는 데 도움 예) 플레이어의 아이템 획득 이벤트의 경우 플레이어와 아이템이라는 구성요소를 가진다. 플레이어의 공통 항목 - 아이디, 레벨, 최근 접속 시간 … 등 아이템의 공통 항목 - 종류, 아이템 레벨, 최대 내구도 … 등

파악할 수 있음 • 로그에 존재하는 항목의 일관성을 유지하는 데 도움 예) 플레이어의 아이템 획득 이벤트의 경우 플레이어와 아이템이라는 구성요소를 가진다. 플레이어의 공통 항목 - 아이디, 레벨, 최근 접속 시간 … 등 아이템의 공통 항목 - 종류, 아이템 레벨, 최대 내구도 … 등 첫 번째로는 서비스 구성요소 별로 로그와 그 공통항목을 관리하는 것입니다.

파악할 수 있음 • 로그에 존재하는 항목의 일관성을 유지하는 데 도움 예) 플레이어의 아이템 획득 이벤트의 경우 플레이어와 아이템이라는 구성요소를 가진다. 플레이어의 공통 항목 - 아이디, 레벨, 최근 접속 시간 … 등 아이템의 공통 항목 - 종류, 아이템 레벨, 최대 내구도 … 등 예제와 같이, 플레이어와 아이템에 관련된 로그가 어떤 것들이 있는지 정리하고

파악할 수 있음 • 로그에 존재하는 항목의 일관성을 유지하는 데 도움 예) 플레이어의 아이템 획득 이벤트의 경우 플레이어와 아이템이라는 구성요소를 가진다. 플레이어의 공통 항목 - 아이디, 레벨, 최근 접속 시간 … 등 아이템의 공통 항목 - 종류, 아이템 레벨, 최대 내구도 … 등 그리고 구성요소들에 대해 공통항목을 관리하는 것입니다.

파악할 수 있음 • 로그에 존재하는 항목의 일관성을 유지하는 데 도움 예) 플레이어의 아이템 획득 이벤트의 경우 플레이어와 아이템이라는 구성요소를 가진다. 플레이어의 공통 항목 - 아이디, 레벨, 최근 접속 시간 … 등 아이템의 공통 항목 - 종류, 아이템 레벨, 최대 내구도 … 등 서비스의 특정 구성요소에 관련된 로그들을 쉽게 파악할 수 있고

파악할 수 있음 • 로그에 존재하는 항목의 일관성을 유지하는 데 도움 예) 플레이어의 아이템 획득 이벤트의 경우 플레이어와 아이템이라는 구성요소를 가진다. 플레이어의 공통 항목 - 아이디, 레벨, 최근 접속 시간 … 등 아이템의 공통 항목 - 종류, 아이템 레벨, 최대 내구도 … 등 로그의 일관성을 유지하는 데 도움이 됩니다.

로그의 문서화 • 다음 내용에 대한 기록이 필요하다. • 로그의
목표와 의미 • 로그의 정확한 발생 시점 • 각 항목들의 의미와 데이터 타입 • 항목의 추가/변경/삭제 이력 • 특이사항 기록(발생 일시, 내용) • 로그가 사용되는 곳 • 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음 • 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음

목표와 의미 • 로그의 정확한 발생 시점 • 각 항목들의 의미와 데이터 타입 • 항목의 추가/변경/삭제 이력 • 특이사항 기록(발생 일시, 내용) • 로그가 사용되는 곳 • 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음 • 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음 다음으로는 문서화에 대한 이야기입니다.

목표와 의미 • 로그의 정확한 발생 시점 • 각 항목들의 의미와 데이터 타입 • 항목의 추가/변경/삭제 이력 • 특이사항 기록(발생 일시, 내용) • 로그가 사용되는 곳 • 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음 • 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음 기본적으로, 로그가 어떤 목표와 의미를 가지고, 어떤 시점에 발생하는지

목표와 의미 • 로그의 정확한 발생 시점 • 각 항목들의 의미와 데이터 타입 • 항목의 추가/변경/삭제 이력 • 특이사항 기록(발생 일시, 내용) • 로그가 사용되는 곳 • 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음 • 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음 항목의 추가, 변경, 삭제 이력에 대한 정보가 필요합니다.

목표와 의미 • 로그의 정확한 발생 시점 • 각 항목들의 의미와 데이터 타입 • 항목의 추가/변경/삭제 이력 • 특이사항 기록(발생 일시, 내용) • 로그가 사용되는 곳 • 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음 • 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음 또한 로그 유실과 같은 특이사항에 대한 내용이 기록되어야 하고

목표와 의미 • 로그의 정확한 발생 시점 • 각 항목들의 의미와 데이터 타입 • 항목의 추가/변경/삭제 이력 • 특이사항 기록(발생 일시, 내용) • 로그가 사용되는 곳 • 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음 • 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음 이런 특이사항이 발생했을 때 어떤 지표에 영향이 있는지 파악하기 위해

목표와 의미 • 로그의 정확한 발생 시점 • 각 항목들의 의미와 데이터 타입 • 항목의 추가/변경/삭제 이력 • 특이사항 기록(발생 일시, 내용) • 로그가 사용되는 곳 • 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음 • 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음 로그가 어떻게 사용되고 있는지에 대한 정보가 정리되어야 합니다.

목표와 의미 • 로그의 정확한 발생 시점 • 각 항목들의 의미와 데이터 타입 • 항목의 추가/변경/삭제 이력 • 특이사항 기록(발생 일시, 내용) • 로그가 사용되는 곳 • 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음 • 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음 문서화가 되어있지 않다는 것은 정말 큰 생산성의 저하로 다가올 수 있습니다.

목표와 의미 • 로그의 정확한 발생 시점 • 각 항목들의 의미와 데이터 타입 • 항목의 추가/변경/삭제 이력 • 특이사항 기록(발생 일시, 내용) • 로그가 사용되는 곳 • 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음 • 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음 더욱더 중요한 것은, 문서가 지속적으로 업데이트되고 관리되어야 한다는 것입니다.

로그 유실 모니터링 • 믿을 수 있는 로그 • 로그
유실에 대한 빠른 대응 • 특이사항 기록 • 버그 또는 시스템 이슈로 인해 유실된 경우 • 언제, 얼마나, 어떤 데이터가 유실되었는지 기록

유실에 대한 빠른 대응 • 특이사항 기록 • 버그 또는 시스템 이슈로 인해 유실된 경우 • 언제, 얼마나, 어떤 데이터가 유실되었는지 기록 다음은 로그 유실 모니터링입니다.

유실에 대한 빠른 대응 • 특이사항 기록 • 버그 또는 시스템 이슈로 인해 유실된 경우 • 언제, 얼마나, 어떤 데이터가 유실되었는지 기록 비정상적인 로그 유실에 대해 감지할 수 있도록

유실에 대한 빠른 대응 • 특이사항 기록 • 버그 또는 시스템 이슈로 인해 유실된 경우 • 언제, 얼마나, 어떤 데이터가 유실되었는지 기록 실시간으로 유입 상황과 유실을 모니터링할 수 있어야 하며

유실에 대한 빠른 대응 • 특이사항 기록 • 버그 또는 시스템 이슈로 인해 유실된 경우 • 언제, 얼마나, 어떤 데이터가 유실되었는지 기록 버그 또는 시스템 이슈로 유실된 경우

유실에 대한 빠른 대응 • 특이사항 기록 • 버그 또는 시스템 이슈로 인해 유실된 경우 • 언제, 얼마나, 어떤 데이터가 유실되었는지 기록 언제, 얼마나, 어떤 데이터가 유실되었는지 기록할 필요가 있습니다.

로그 추가 및 변경의 프로세스화 1. 목표 정의 2. 관계자들의
의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포

의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 마지막으로 로그 추가 및 변경의 프로세스화입니다.

의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 1. 목표 정의 • 추가(또는 변경)의 목표를 구체적으로 정의 • 어떤 데이터가 필요한 것인지 정의

의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 1. 목표 정의 • 추가(또는 변경)의 목표를 구체적으로 정의 • 어떤 데이터가 필요한 것인지 정의 프로세스의 첫 번째 단계는 역시 목표를 정의하는 것입니다.

의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 1. 목표 정의 • 추가(또는 변경)의 목표를 구체적으로 정의 • 어떤 데이터가 필요한 것인지 정의 추가든 변경이든 목표를 정의하고

의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 1. 목표 정의 • 추가(또는 변경)의 목표를 구체적으로 정의 • 어떤 데이터가 필요한 것인지 정의 그에 따라 1차적으로 필요한 데이터를 정의하고 나면

의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 2. 관계자들과 의견을 종합하여 로그를 설계 • 관계자? • 지표를 보는 사람들 / 만드는 사람들(분석가) • 개발자(실제 로그에 대한 코드를 작성) • 이벤트 정의 • 지표를 어떻게 볼 것인지 다양한 각도로 고민 • 필요한 항목들을 더 구체적으로 정의 • 추가 가능 여부, 한계, 대안 • 우선순위 • 가까운 미래에 발생할 수 있는 다른 가능성 고민 • 합의된 내용을 기반으로 문서화

의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 2. 관계자들과 의견을 종합하여 로그를 설계 • 관계자? • 지표를 보는 사람들 / 만드는 사람들(분석가) • 개발자(실제 로그에 대한 코드를 작성) • 이벤트 정의 • 지표를 어떻게 볼 것인지 다양한 각도로 고민 • 필요한 항목들을 더 구체적으로 정의 • 추가 가능 여부, 한계, 대안 • 우선순위 • 가까운 미래에 발생할 수 있는 다른 가능성 고민 • 합의된 내용을 기반으로 문서화 두 번째로 필요한 것은 관계자들과 의견을 종합하여 실제로 로그를 설계하는 과정입니다.

의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 2. 관계자들과 의견을 종합하여 로그를 설계 • 관계자? • 지표를 보는 사람들 / 만드는 사람들(분석가) • 개발자(실제 로그에 대한 코드를 작성) • 이벤트 정의 • 지표를 어떻게 볼 것인지 다양한 각도로 고민 • 필요한 항목들을 더 구체적으로 정의 • 추가 가능 여부, 한계, 대안 • 우선순위 • 가까운 미래에 발생할 수 있는 다른 가능성 고민 • 합의된 내용을 기반으로 문서화 관계자라고 함은, 지표를 만드는 사람들뿐만 아니라 지표를 보는 사람들과

의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 2. 관계자들과 의견을 종합하여 로그를 설계 • 관계자? • 지표를 보는 사람들 / 만드는 사람들(분석가) • 개발자(실제 로그에 대한 코드를 작성) • 이벤트 정의 • 지표를 어떻게 볼 것인지 다양한 각도로 고민 • 필요한 항목들을 더 구체적으로 정의 • 추가 가능 여부, 한계, 대안 • 우선순위 • 가까운 미래에 발생할 수 있는 다른 가능성 고민 • 합의된 내용을 기반으로 문서화 실제 로그에 대해 코드를 작성하는 개발자를 모두 포함합니다.

의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 2. 관계자들과 의견을 종합하여 로그를 설계 • 관계자? • 지표를 보는 사람들 / 만드는 사람들(분석가) • 개발자(실제 로그에 대한 코드를 작성) • 이벤트 정의 • 지표를 어떻게 볼 것인지 다양한 각도로 고민 • 필요한 항목들을 더 구체적으로 정의 • 추가 가능 여부, 한계, 대안 • 우선순위 • 가까운 미래에 발생할 수 있는 다른 가능성 고민 • 합의된 내용을 기반으로 문서화 첫 번째 단계에서 정의했던 목표와 그 내용을 기반으로

의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 2. 관계자들과 의견을 종합하여 로그를 설계 • 관계자? • 지표를 보는 사람들 / 만드는 사람들(분석가) • 개발자(실제 로그에 대한 코드를 작성) • 이벤트 정의 • 지표를 어떻게 볼 것인지 다양한 각도로 고민 • 필요한 항목들을 더 구체적으로 정의 • 추가 가능 여부, 한계, 대안 • 우선순위 • 가까운 미래에 발생할 수 있는 다른 가능성 고민 • 합의된 내용을 기반으로 문서화 다양한 관계자들과 함께 우선순위와 한계, 대안, 설계 내용들을 취합하고 적절히 타협하여

의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 2. 관계자들과 의견을 종합하여 로그를 설계 • 관계자? • 지표를 보는 사람들 / 만드는 사람들(분석가) • 개발자(실제 로그에 대한 코드를 작성) • 이벤트 정의 • 지표를 어떻게 볼 것인지 다양한 각도로 고민 • 필요한 항목들을 더 구체적으로 정의 • 추가 가능 여부, 한계, 대안 • 우선순위 • 가까운 미래에 발생할 수 있는 다른 가능성 고민 • 합의된 내용을 기반으로 문서화 로그 설계를 구체화해야 합니다.

의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 3. 로그 추가 또는 변경 작업 4. 테스트 / QA • 의도한 시점에 제대로 발생하는지 확인 • 의도한 형태로 남는지 확인 • 값이 정확한지 확인 5. 배포

의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 3. 로그 추가 또는 변경 작업 4. 테스트 / QA • 의도한 시점에 제대로 발생하는지 확인 • 의도한 형태로 남는지 확인 • 값이 정확한지 확인 5. 배포 실제로 로그 추가 및 변경 작업을 한 뒤에는

의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 3. 로그 추가 또는 변경 작업 4. 테스트 / QA • 의도한 시점에 제대로 발생하는지 확인 • 의도한 형태로 남는지 확인 • 값이 정확한지 확인 5. 배포 실수를 방지하고 라이브에서 로그가 잘못 남지 않도록 여러 번의 테스트와 QA를 통해

의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 3. 로그 추가 또는 변경 작업 4. 테스트 / QA • 의도한 시점에 제대로 발생하는지 확인 • 의도한 형태로 남는지 확인 • 값이 정확한지 확인 5. 배포 의도한 시점에서 제대로 발생하는지 의도한 형태로 남는지, 값이 정확한지와 같은 부분들이

의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 3. 로그 추가 또는 변경 작업 4. 테스트 / QA • 의도한 시점에 제대로 발생하는지 확인 • 의도한 형태로 남는지 확인 • 값이 정확한지 확인 5. 배포 꼭 확인된 뒤에 라이브에 배포되어야 합니다.

효율적인 프로세스 진행을 위해 • 로그 설계 방식에 대하여 미리
합의된 최소한의 규약이 필요 • 자칫하면 비효율적으로 작동할 수 있는 프로세스 • 처음부터 모든 것을 충족할 수 없으므로, 점진적 개선이 필요 • 잘못 남겨진 로그는 이후 생산성을 크게 저하시키기 때문에 충분한 테스트와 QA 과정이 필요

합의된 최소한의 규약이 필요 • 자칫하면 비효율적으로 작동할 수 있는 프로세스 • 처음부터 모든 것을 충족할 수 없으므로, 점진적 개선이 필요 • 잘못 남겨진 로그는 이후 생산성을 크게 저하시키기 때문에 충분한 테스트와 QA 과정이 필요 이런 프로세스는 다소 비효율적으로 작동할 수 있습니다.

합의된 최소한의 규약이 필요 • 자칫하면 비효율적으로 작동할 수 있는 프로세스 • 처음부터 모든 것을 충족할 수 없으므로, 점진적 개선이 필요 • 잘못 남겨진 로그는 이후 생산성을 크게 저하시키기 때문에 충분한 테스트와 QA 과정이 필요 때문에 로그 설계 방식에 대해 이름 규약같은 미리 합의된 최소한의 규약들이 필요합니다.

합의된 최소한의 규약이 필요 • 자칫하면 비효율적으로 작동할 수 있는 프로세스 • 처음부터 모든 것을 충족할 수 없으므로, 점진적 개선이 필요 • 잘못 남겨진 로그는 이후 생산성을 크게 저하시키기 때문에 충분한 테스트와 QA 과정이 필요 처음부터 모든 것을 충족시킬 수 없으므로 점진적으로 개선이 필요하고

합의된 최소한의 규약이 필요 • 자칫하면 비효율적으로 작동할 수 있는 프로세스 • 처음부터 모든 것을 충족할 수 없으므로, 점진적 개선이 필요 • 잘못 남겨진 로그는 이후 생산성을 크게 저하시키기 때문에 충분한 테스트와 QA 과정이 필요 충분한 테스트와 QA 과정은 다시 한번 강조 드리고 싶습니다.

요약 • 품질관리를 위해 필요한 것들 • 서비스 구성요소별 로그
관리 • 로그의 문서화 • 로그 유실 모니터링 • 로그 추가 및 변경의 프로세스화

관리 • 로그의 문서화 • 로그 유실 모니터링 • 로그 추가 및 변경의 프로세스화 여기까지 품질관리를 위해 필요한 것들을 이야기했는데요.

관리 • 로그의 문서화 • 로그 유실 모니터링 • 로그 추가 및 변경의 프로세스화 이제 조금 마무리를 해보자면

관리 • 로그의 문서화 • 로그 유실 모니터링 • 로그 추가 및 변경의 프로세스화 긴 시간 동안 좋은 로그를 위해 고려해야 할 것들과

관리 • 로그의 문서화 • 로그 유실 모니터링 • 로그 추가 및 변경의 프로세스화 품질관리를 위해 필요한 것들에 대해 이야기했지만

마치며 • 가장 중요한 것은 ‘좋은 로그’에 대한 공감대를 형성하는
것 • 가장 어렵지만 필요한 것은, 서로 다른 입장에 대하여 열린 마음을 가지는 것 • 모든 것을 만족시킬 순 없지만, 할 수 있는 것부터 하는 것이 중요

것 • 가장 어렵지만 필요한 것은, 서로 다른 입장에 대하여 열린 마음을 가지는 것 • 모든 것을 만족시킬 순 없지만, 할 수 있는 것부터 하는 것이 중요 결국 가장 중요한 것은 ‘좋은 로그’에 대한 공감대를 형성하는 것입니다.

것 • 가장 어렵지만 필요한 것은, 서로 다른 입장에 대하여 열린 마음을 가지는 것 • 모든 것을 만족시킬 순 없지만, 할 수 있는 것부터 하는 것이 중요 다양한 사람들이 같이 고민해야 하는 만큼 서로 다른 입장에 대해서 열린 마음을 가지고

것 • 가장 어렵지만 필요한 것은, 서로 다른 입장에 대하여 열린 마음을 가지는 것 • 모든 것을 만족시킬 순 없지만, 할 수 있는 것부터 하는 것이 중요 할 수 있는 것부터 개선하는 것이 중요하다는 것을 이야기 드리면서

것 • 가장 어렵지만 필요한 것은, 서로 다른 입장에 대하여 열린 마음을 가지는 것 • 모든 것을 만족시킬 순 없지만, 할 수 있는 것부터 하는 것이 중요 이 발표를 마치겠습니다.

감사합니다.

(자막)[NDC19] 좋은 로그란 무엇인가?: 좋은 로그를 위해 고려해야 할 것들

(자막)[NDC19] 좋은 로그란 무엇인가?: 좋은 로그를 위해 고려해야 할 것들

More Decks by Hyojun Jeon

Other Decks in Programming

Featured

Transcript