www.hyojun.me [email protected] devinjeon NDC18 〈야생의땅: 듀랑고〉의 데이터 엔지니어링 이야기 : 로그 시스템 구축 경험 공유 넥슨 왓 스튜디오의 백엔드 엔지니어 주로 데이터와 DevOps 엔지니어링을 담당 전효준 먼저 간단하게 제 소개를 하자면
www.hyojun.me [email protected] devinjeon NDC18 〈야생의땅: 듀랑고〉의 데이터 엔지니어링 이야기 : 로그 시스템 구축 경험 공유 넥슨 왓 스튜디오의 백엔드 엔지니어 주로 데이터와 DevOps 엔지니어링을 담당 전효준 이전에 두 곳의 스타트업을 거쳐서 지금 왓 스튜디오로 오게 되었는데요.
www.hyojun.me [email protected] devinjeon NDC18 〈야생의땅: 듀랑고〉의 데이터 엔지니어링 이야기 : 로그 시스템 구축 경험 공유 넥슨 왓 스튜디오의 백엔드 엔지니어 주로 데이터와 DevOps 엔지니어링을 담당 전효준 백엔드 엔지니어로서 여러 가지를 하고 있지만
www.hyojun.me [email protected] devinjeon NDC18 〈야생의땅: 듀랑고〉의 데이터 엔지니어링 이야기 : 로그 시스템 구축 경험 공유 넥슨 왓 스튜디오의 백엔드 엔지니어 주로 데이터와 DevOps 엔지니어링을 담당 전효준 주로 데이터 엔지니어링과 데브옵스 영역을 담당하고 있고요.
www.hyojun.me [email protected] devinjeon NDC18 〈야생의땅: 듀랑고〉의 데이터 엔지니어링 이야기 : 로그 시스템 구축 경험 공유 넥슨 왓 스튜디오의 백엔드 엔지니어 주로 데이터와 DevOps 엔지니어링을 담당 전효준 작년 NDC에서는 로그 시스템 구축에 대한 이야기를 했었던 경험이 있습니다.
‘로그(Log)’에 대한 정의 • 이벤트(Event)에 대한 기록(Record) • 이 발표에서는 ‘서비스 로그’를 대상으로 합니다. • 서비스 수준에서 일어나는 상태변화나 유저의 행동에 대한 기록들 • 예) 유저의 입장 및 퇴장, 아이템 구매, 획득 및 사용 등 먼저 로그에 대한 정의를 한번 내려보겠습니다.
‘로그(Log)’에 대한 정의 • 이벤트(Event)에 대한 기록(Record) • 이 발표에서는 ‘서비스 로그’를 대상으로 합니다. • 서비스 수준에서 일어나는 상태변화나 유저의 행동에 대한 기록들 • 예) 유저의 입장 및 퇴장, 아이템 구매, 획득 및 사용 등 로그는 어떤 이벤트에 대한 기록이라고 정의해볼 수 있는데요.
‘로그(Log)’에 대한 정의 • 이벤트(Event)에 대한 기록(Record) • 이 발표에서는 ‘서비스 로그’를 대상으로 합니다. • 서비스 수준에서 일어나는 상태변화나 유저의 행동에 대한 기록들 • 예) 유저의 입장 및 퇴장, 아이템 구매, 획득 및 사용 등 여기서 다시 용도에 따라 크게 두 가지로 나눠보면
‘로그(Log)’에 대한 정의 • 이벤트(Event)에 대한 기록(Record) • 이 발표에서는 ‘서비스 로그’를 대상으로 합니다. • 서비스 수준에서 일어나는 상태변화나 유저의 행동에 대한 기록들 • 예) 유저의 입장 및 퇴장, 아이템 구매, 획득 및 사용 등 프로그램의 버그나 OS 레벨에서 시스템 이벤트를 추적하기 위해 남기는 시스템 로그와
‘로그(Log)’에 대한 정의 • 이벤트(Event)에 대한 기록(Record) • 이 발표에서는 ‘서비스 로그’를 대상으로 합니다. • 서비스 수준에서 일어나는 상태변화나 유저의 행동에 대한 기록들 • 예) 유저의 입장 및 퇴장, 아이템 구매, 획득 및 사용 등 우리가 운영하는 서비스에 대하여 KPI와 같은 지표를 분석하기 위해 남기거나
‘로그(Log)’에 대한 정의 • 이벤트(Event)에 대한 기록(Record) • 이 발표에서는 ‘서비스 로그’를 대상으로 합니다. • 서비스 수준에서 일어나는 상태변화나 유저의 행동에 대한 기록들 • 예) 유저의 입장 및 퇴장, 아이템 구매, 획득 및 사용 등 유저의 CS에 대응하기 위해 남기는 서비스 로그로 나눠볼 수 있습니다.
‘로그(Log)’에 대한 정의 • 이벤트(Event)에 대한 기록(Record) • 이 발표에서는 ‘서비스 로그’를 대상으로 합니다. • 서비스 수준에서 일어나는 상태변화나 유저의 행동에 대한 기록들 • 예) 유저의 입장 및 퇴장, 아이템 구매, 획득 및 사용 등 오늘 이 발표에서는 ‘서비스 로그’를 대상으로 이야기해보려 합니다.
겪어봤을 만한 문제들 • 필요한 정보가 없다. 예) 꼭 필요하면 없더라, 왜 이 이벤트에는 있는데 저 이벤트에는 없지? • 의미를 파악하기 어렵다. 예) 이 이벤트(또는 항목) 이름은 대체 무슨 의미지? • 편리하게 데이터를 얻을 수 없다. 예) 값에 여러 데이터가 함께 포함되어 있어서 매번 가공 처리를 해야하는 경우
겪어봤을 만한 문제들 • 필요한 정보가 없다. 예) 꼭 필요하면 없더라, 왜 이 이벤트에는 있는데 저 이벤트에는 없지? • 의미를 파악하기 어렵다. 예) 이 이벤트(또는 항목) 이름은 대체 무슨 의미지? • 편리하게 데이터를 얻을 수 없다. 예) 값에 여러 데이터가 함께 포함되어 있어서 매번 가공 처리를 해야하는 경우 또는 여러 가지 데이터가 한 항목에 포함되어 있어서
겪어봤을 만한 문제들 • 필요한 정보가 없다. 예) 꼭 필요하면 없더라, 왜 이 이벤트에는 있는데 저 이벤트에는 없지? • 의미를 파악하기 어렵다. 예) 이 이벤트(또는 항목) 이름은 대체 무슨 의미지? • 편리하게 데이터를 얻을 수 없다. 예) 값에 여러 데이터가 함께 포함되어 있어서 매번 가공 처리를 해야하는 경우 특정 데이터를 얻기 위해서 매번 가공 처리를 해야 한다든지
겪어봤을 만한 문제들 • 필요한 정보가 없다. 예) 꼭 필요하면 없더라, 왜 이 이벤트에는 있는데 저 이벤트에는 없지? • 의미를 파악하기 어렵다. 예) 이 이벤트(또는 항목) 이름은 대체 무슨 의미지? • 편리하게 데이터를 얻을 수 없다. 예) 값에 여러 데이터가 함께 포함되어 있어서 매번 가공 처리를 해야하는 경우 이런 생산성을 떨어뜨리는 여러 가지 문제들이 많이 발생했습니다.
겪어봤을 만한 문제들 • 필요한 정보가 없다. 예) 꼭 필요하면 없더라, 왜 이 이벤트에는 있는데 저 이벤트에는 없지? • 의미를 파악하기 어렵다. 예) 이 이벤트(또는 항목) 이름은 대체 무슨 의미지? • 편리하게 데이터를 얻을 수 없다. 예) 값에 여러 데이터가 함께 포함되어 있어서 매번 가공 처리를 해야하는 경우 로그를 다루다 보면 이런 문제들을 자주 겪게 되는데요
왜 항상 비슷한 문제를 겪을까? • 로그에 대한 작업 우선순위가 일반적으로 높지 않음 • 설계에 대한 충분한 고민 없이 일단 남기는데 집중 • 무엇을 고려해야 할지 모름 • 합의된 규약이 없음 • 로그 품질을 지속적으로 관리하지 않음 그리고 로그 품질관리의 부재가 결국 이런 문제들을 심화시켰습니다.
문제점을 충분히 인식했을 때쯤에는 ... • 필요한 데이터를 얻지 못하거나, 큰 비용이 들게 됨 • 이미 지나간 시간의 정보를 찾는 것은 불가능하거나 힘듦 → 로그는 그때 그 상황을 기록하는 유일한 정보 없는 정보를 다른 데이터로부터 채워줘야 하는데 이 또한 꽤나 번거로운 작업이 될 수 있습니다.
문제점을 충분히 인식했을 때쯤에는 ... • 필요한 데이터를 얻지 못하거나, 큰 비용이 들게 됨 • 이미 지나간 시간의 정보를 찾는 것은 불가능하거나 힘듦 → 로그는 그때 그 상황을 기록하는 유일한 정보 • 대부분 미래에 기존 설계 구조를 바꾸는 것은 많은 비용이 발생 → 기존에 적재된 모든 로그를 새로운 구조로 변환하는 것은 사실상 비현실적 또한 미래에 기존 로그 설계구조를 바꾸는 것은 많은 비용을 발생시킬 수 있는데요.
문제점을 충분히 인식했을 때쯤에는 ... • 필요한 데이터를 얻지 못하거나, 큰 비용이 들게 됨 • 이미 지나간 시간의 정보를 찾는 것은 불가능하거나 힘듦 → 로그는 그때 그 상황을 기록하는 유일한 정보 • 대부분 미래에 기존 설계 구조를 바꾸는 것은 많은 비용이 발생 → 기존에 적재된 모든 로그를 새로운 구조로 변환하는 것은 사실상 비현실적 예를 들어, 단순히 로그 항목의 이름을 바꾸는 것도 기존 적재된 로그에도 모두 적용시켜주어야 하는데요.
문제점을 충분히 인식했을 때쯤에는 ... • 필요한 데이터를 얻지 못하거나, 큰 비용이 들게 됨 • 이미 지나간 시간의 정보를 찾는 것은 불가능하거나 힘듦 → 로그는 그때 그 상황을 기록하는 유일한 정보 • 대부분 미래에 기존 설계 구조를 바꾸는 것은 많은 비용이 발생 → 기존에 적재된 모든 로그를 새로운 구조로 변환하는 것은 사실상 비현실적 만약에 기존 로그에 대한 항목 이름의 변경을 포기하게 되면
문제점을 충분히 인식했을 때쯤에는 ... • 필요한 데이터를 얻지 못하거나, 큰 비용이 들게 됨 • 이미 지나간 시간의 정보를 찾는 것은 불가능하거나 힘듦 → 로그는 그때 그 상황을 기록하는 유일한 정보 • 대부분 미래에 기존 설계 구조를 바꾸는 것은 많은 비용이 발생 → 기존에 적재된 모든 로그를 새로운 구조로 변환하는 것은 사실상 비현실적 집계 시 매번 변경일자 전과 후의 항목 이름이 다르다는 것을 고려해야만 합니다.
문제점을 충분히 인식했을 때쯤에는 ... • 필요한 데이터를 얻지 못하거나, 큰 비용이 들게 됨 • 이미 지나간 시간의 정보를 찾는 것은 불가능하거나 힘듦 → 로그는 그때 그 상황을 기록하는 유일한 정보 • 대부분 미래에 기존 설계 구조를 바꾸는 것은 많은 비용이 발생 → 기존에 적재된 모든 로그를 새로운 구조로 변환하는 것은 사실상 비현실적
이 발표를 준비한 이유 • 초기 ‘좋은 로그’의 필요성에 대한 인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. 구체적으로 무엇을 고민해야 하는지 참고할만한 자료를 찾기 힘들었습니다.
이 발표를 준비한 이유 • 초기 ‘좋은 로그’의 필요성에 대한 인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. 로그 시스템을 구축하고, 로그를 설계해보고 서버에 로그를 추가하는 작업부터
이 발표를 준비한 이유 • 초기 ‘좋은 로그’의 필요성에 대한 인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. • 새로운 프로젝트를 시작할 때에는, 이런 내용을 복기하기 힘듦 결국 새로운 프로젝트를 시작할 때는, 이런 내용을 다시 떠올리기 힘들었습니다.
이 발표를 준비한 이유 • 초기 ‘좋은 로그’의 필요성에 대한 인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. • 새로운 프로젝트를 시작할 때에는, 이런 내용을 복기하기 힘듦 • 로그를 다루는 여러 동료들 모두가 공감대를 형성하며, 함께 고민해야 달성할 수 있는 가치 • 공유가 필요하다!
이 발표를 준비한 이유 • 초기 ‘좋은 로그’의 필요성에 대한 인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. • 새로운 프로젝트를 시작할 때에는, 이런 내용을 복기하기 힘듦 • 로그를 다루는 여러 동료들 모두가 공감대를 형성하며, 함께 고민해야 달성할 수 있는 가치 • 공유가 필요하다! 때문에 한번 정리가 필요하다는 생각이 들었는데요.
이 발표를 준비한 이유 • 초기 ‘좋은 로그’의 필요성에 대한 인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. • 새로운 프로젝트를 시작할 때에는, 이런 내용을 복기하기 힘듦 • 로그를 다루는 여러 동료들 모두가 공감대를 형성하며, 함께 고민해야 달성할 수 있는 가치 • 공유가 필요하다! 정리를 하면서 다시 느끼게 된 것은
이 발표를 준비한 이유 • 초기 ‘좋은 로그’의 필요성에 대한 인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. • 새로운 프로젝트를 시작할 때에는, 이런 내용을 복기하기 힘듦 • 로그를 다루는 여러 동료들 모두가 공감대를 형성하며, 함께 고민해야 달성할 수 있는 가치 • 공유가 필요하다! 결국 좋은 로그에 대해 모두가 함께 공감대를 형성하고,
이 발표를 준비한 이유 • 초기 ‘좋은 로그’의 필요성에 대한 인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. • 새로운 프로젝트를 시작할 때에는, 이런 내용을 복기하기 힘듦 • 로그를 다루는 여러 동료들 모두가 공감대를 형성하며, 함께 고민해야 달성할 수 있는 가치 • 공유가 필요하다! 같이 고민해야 달성할 수 있는 가치라는 것입니다.
이 발표를 준비한 이유 • 초기 ‘좋은 로그’의 필요성에 대한 인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. • 새로운 프로젝트를 시작할 때에는, 이런 내용을 복기하기 힘듦 • 로그를 다루는 여러 동료들 모두가 공감대를 형성하며, 함께 고민해야 달성할 수 있는 가치 • 공유가 필요하다! 그래서 이 발표가 저 같은 엔지니어뿐만 아니라
이 발표를 준비한 이유 • 초기 ‘좋은 로그’의 필요성에 대한 인식이 부족했던 것에 대한 아쉬움 • 대부분 공유된 자료는 여기까지의 이야기 • 구체적으로 무엇을 고민해야 하는지에 대한 내용을 찾기 어려웠음. • 새로운 프로젝트를 시작할 때에는, 이런 내용을 복기하기 힘듦 • 로그를 다루는 여러 동료들 모두가 공감대를 형성하며, 함께 고민해야 달성할 수 있는 가치 • 공유가 필요하다! 여기 와계신 다양한 직군, 다양한 입장을 가진 사람들이 함께 고민해보는 좋은 자리가 되었으면 합니다.
Chapter 2. ‘좋은 로그’를 위해 고려해야 할 것들 1. 필요한 정보가 있는 로그 2. 의미가 명확한 로그 3. 편리하게 데이터를 얻을 수 있는 로그 4. 그 외 다른 관점에서 고려해봐야 할 것들 지금까지 좋은 로그가 무엇인지, 이게 왜 필요하고 왜 발표를 하게 되었는지 말씀드렸는데요.
Chapter 2. ‘좋은 로그’를 위해 고려해야 할 것들 1. 필요한 정보가 있는 로그 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 발생 시간, 플레이어 아이디, 직업, 레벨 등을 각각의 항목으로 생각하시면 됩니다.
목표가 있는 로그 1. 목표를 한 문장으로 정의 예) 재방문율 집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. 두 번째로는 이런 목표를 위해 다양한 각도의 고민을 해보는 것입니다.
목표가 있는 로그 1. 목표를 한 문장으로 정의 예) 재방문율 집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. “추후에 국가별, 레벨별, 직업별 필터링이 필요할 것이다”라는 생각을 해볼 수 있습니다.
목표가 있는 로그 1. 목표를 한 문장으로 정의 예) 재방문율 집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. 3. 목표에 따라 남겨야 할 이벤트와 그 항목들을 정의 • 목표들의 우선순위에 따라, 점진적으로 항목을 추가하는 방향도 고려
목표가 있는 로그 1. 목표를 한 문장으로 정의 예) 재방문율 집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. 3. 목표에 따라 남겨야 할 이벤트와 그 항목들을 정의 • 목표들의 우선순위에 따라, 점진적으로 항목을 추가하는 방향도 고려 마지막은 이렇게 정의된 목표에 따라
목표가 있는 로그 1. 목표를 한 문장으로 정의 예) 재방문율 집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. 3. 목표에 따라 남겨야 할 이벤트와 그 항목들을 정의 • 목표들의 우선순위에 따라, 점진적으로 항목을 추가하는 방향도 고려 어떤 로그들과, 어떤 항목들이 있어야 하는지 정의해보는 것입니다.
목표가 있는 로그 1. 목표를 한 문장으로 정의 예) 재방문율 집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. 3. 목표에 따라 남겨야 할 이벤트와 그 항목들을 정의 • 목표들의 우선순위에 따라, 점진적으로 항목을 추가하는 방향도 고려 목표가 명확해지면 로그의 의도를 명확히 할 수 있고
목표가 있는 로그 1. 목표를 한 문장으로 정의 예) 재방문율 집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. 3. 목표에 따라 남겨야 할 이벤트와 그 항목들을 정의 • 목표들의 우선순위에 따라, 점진적으로 항목을 추가하는 방향도 고려 구체적으로 필요한 이벤트들과 항목을 정의할 수 있습니다.
목표가 있는 로그 1. 목표를 한 문장으로 정의 예) 재방문율 집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. 3. 목표에 따라 남겨야 할 이벤트와 그 항목들을 정의 • 목표들의 우선순위에 따라, 점진적으로 항목을 추가하는 방향도 고려 추가적으로 목표가 있다면 우선순위를 파악할 수 있기 때문에
목표가 있는 로그 1. 목표를 한 문장으로 정의 예) 재방문율 집계가 필요하다. 2. 하나의 지표에 대해서 다양한 각도의 고민 예) 추후 재방문율 집계시 ‘국가별’, ‘레벨별’, ‘직업별’ 필터링이 필요할 것이다. 3. 목표에 따라 남겨야 할 이벤트와 그 항목들을 정의 • 목표들의 우선순위에 따라, 점진적으로 항목을 추가하는 방향도 고려 우선순위에 따라 점진적으로 로그 개선이 가능하기도 합니다.
일관성 • 일관성이란? • 같은 구성요소에 대하여 같은 항목들을 가지는 것 • 구성요소의 예) → ‘플레이어의 아이템 획득’ 이벤트의 경우, 플레이어와 아이템이라는 구성요소를 가진다. 예를 들어, ‘플레이어의 아이템 획득’이라는 이벤트에 대해서는 플레이어와 아이템이 구성요소가 됩니다.
일관성 • 일관성이 없는 경우의 예) time player_id player_class player_level … … … … … … … … … … … PlayerGotItem PlayerUsedItem time player_id player_class … … … … … … … … … • 두 이벤트 모두 플레이어에 대한 로그 • 하지만 플레이어에 대한 항목 구성이 다름
일관성 • 일관성이 없는 경우의 예) time player_id player_class player_level … … … … … … … … … … … PlayerGotItem PlayerUsedItem time player_id player_class … … … … … … … … … • 두 이벤트 모두 플레이어에 대한 로그 • 하지만 플레이어에 대한 항목 구성이 다름 일관성이 없는 경우는 보시다시피
일관성 • 일관성이 없는 경우의 예) time player_id player_class player_level … … … … … … … … … … … PlayerGotItem PlayerUsedItem time player_id player_class … … … … … … … … … • 두 이벤트 모두 플레이어에 대한 로그 • 하지만 플레이어에 대한 항목 구성이 다름 ‘플레이어의 아이템 획득’ 로그와 ‘플레이어의 아이템 사용’ 로그가 있을 때
일관성 • 일관성이 없는 경우의 예) time player_id player_class player_level … … … … … … … … … … … PlayerGotItem PlayerUsedItem time player_id player_class … … … … … … … … … • 두 이벤트 모두 플레이어에 대한 로그 • 하지만 플레이어에 대한 항목 구성이 다름 두 이벤트 모두 플레이어에 대한 로그이지만
일관성 • 일관성이 없는 경우의 예) time player_id player_class player_level … … … … … … … … … … … PlayerGotItem PlayerUsedItem time player_id player_class … … … … … … … … … • 두 이벤트 모두 플레이어에 대한 로그 • 하지만 플레이어에 대한 항목 구성이 다름 아이템 획득 로그에는 플레이어의 아이디와 직업, 레벨 항목들이 존재하는데
일관성 • 일관성이 없는 경우의 예) time player_id player_class player_level … … … … … … … … … … … PlayerGotItem PlayerUsedItem time player_id player_class … … … … … … … … … • 두 이벤트 모두 플레이어에 대한 로그 • 하지만 플레이어에 대한 항목 구성이 다름 아이템 사용 로그에는 플레이어의 아이디와 직업 항목들만 있는 경우인데요.
일관성 • 일관성이 없는 경우의 예) time player_id player_class player_level … … … … … … … … … … … PlayerGotItem PlayerUsedItem time player_id player_class … … … … … … … … … • 두 이벤트 모두 플레이어에 대한 로그 • 하지만 플레이어에 대한 항목 구성이 다름 만약 두 로그 모두 플레이어에 대해 같은 구성의 항목을 가지고 있다면 일관성이 있는 것이고
일관성 • 일관성이 없는 경우의 예) time player_id player_class player_level … … … … … … … … … … … PlayerGotItem PlayerUsedItem time player_id player_class … … … … … … … … … • 두 이벤트 모두 플레이어에 대한 로그 • 하지만 플레이어에 대한 항목 구성이 다름 더 나아가서는 한 구성요소에 대해 같은 의미의 항목은 같은 이름을 사용하는 것 또한
일관성 • 일관성이 없는 경우의 예) time player_id player_class player_level … … … … … … … … … … … PlayerGotItem PlayerUsedItem time player_id player_class … … … … … … … … … • 두 이벤트 모두 플레이어에 대한 로그 • 하지만 플레이어에 대한 항목 구성이 다름 일관성이 있다고 이야기할 수 있습니다.
믿을 수 있는 로그 1. 로그가 의도한 시점에서 발생했을 것이라는 믿음 2. 의도한 대로 데이터가 남았을 것이라는 믿음 • 의도한 것과 다른 데이터가 남을 수 있는 가능성 • 어뷰징에 의한 변조 가능성 단순 실수로 인해 플레이어의 아이디 항목에 아이디가 아닌 다른 값이 들어간다거나
믿을 수 있는 로그 1. 로그가 의도한 시점에서 발생했을 것이라는 믿음 2. 의도한 대로 데이터가 남았을 것이라는 믿음 • 의도한 것과 다른 데이터가 남을 수 있는 가능성 • 어뷰징에 의한 변조 가능성 유저의 어뷰징에 의해서 로그가 변조되는 경우가 없어야 한다는 것인데요.
믿을 수 있는 로그 1. 로그가 의도한 시점에서 발생했을 것이라는 믿음 2. 의도한 대로 데이터가 남았을 것이라는 믿음 • 의도한 것과 다른 데이터가 남을 수 있는 가능성 • 어뷰징에 의한 변조 가능성 결국 그 로그는 쓸 수 없게 되거나 다루는데 많은 시간이 필요하게 될 수 있습니다.
믿을 수 있는 로그 1. 로그가 의도한 시점에서 발생했을 것이라는 믿음 2. 의도한 대로 데이터가 남았을 것이라는 믿음 • 의도한 것과 다른 데이터가 남을 수 있는 가능성 • 어뷰징에 의한 변조 가능성 3. 100%는 아니더라도 납득할 수 있는 수준의 믿음을 위한 노력이 필요 물론 유실이나 변조, 실수 등에 대해 기술적 한계나 다른 이유로 100%를 달성하기는 어렵더라도
믿을 수 있는 로그 1. 로그가 의도한 시점에서 발생했을 것이라는 믿음 2. 의도한 대로 데이터가 남았을 것이라는 믿음 • 의도한 것과 다른 데이터가 남을 수 있는 가능성 • 어뷰징에 의한 변조 가능성 3. 100%는 아니더라도 납득할 수 있는 수준의 믿음을 위한 노력이 필요 우리가 납득할 수 있는 수준까지의 노력이 필요합니다.
이름에 대한 합의와 규약 • 의미를 충분히 표현할 수 있어야 함 • 나중에 이벤트 또는 항목의 이름을 바꾸는 것은 큰 비용이 발생할 수 있음 • 때문에, 길더라도 구체적인 이름을 사용 • 다른 의미와 혼동될만한 가능성을 피할 수 있다. • 미래에 들어가는 이름과 의미가 충돌할 가능성을 낮출 수 있다. 길더라도 구체적인 이름을 사용하여
이름에 대한 합의와 규약 • 의미를 충분히 표현할 수 있어야 함 • 나중에 이벤트 또는 항목의 이름을 바꾸는 것은 큰 비용이 발생할 수 있음 • 때문에, 길더라도 구체적인 이름을 사용 • 다른 의미와 혼동될만한 가능성을 피할 수 있다. • 미래에 들어가는 이름과 의미가 충돌할 가능성을 낮출 수 있다. 다른 의미와 혼동될 만한 가능성을 줄이고
이름에 대한 합의와 규약 • 의미를 충분히 표현할 수 있어야 함 • 나중에 이벤트 또는 항목의 이름을 바꾸는 것은 큰 비용이 발생할 수 있음 • 때문에, 길더라도 구체적인 이름을 사용 • 다른 의미와 혼동될만한 가능성을 피할 수 있다. • 미래에 들어가는 이름과 의미가 충돌할 가능성을 낮출 수 있다. 미래에 추가되는 콘텐츠, 기능 등으로 인해
이름에 대한 합의와 규약 • 의미를 충분히 표현할 수 있어야 함 • 나중에 이벤트 또는 항목의 이름을 바꾸는 것은 큰 비용이 발생할 수 있음 • 때문에, 길더라도 구체적인 이름을 사용 • 다른 의미와 혼동될만한 가능성을 피할 수 있다. • 미래에 들어가는 이름과 의미가 충돌할 가능성을 낮출 수 있다. 이름이 가지는 의미가 다른 개념과 충돌할 가능성을 낮추는 것이 중요합니다.
이름에 대한 합의와 규약 • 의미를 충분히 표현할 수 있어야 함 • 나중에 이벤트 또는 항목의 이름을 바꾸는 것은 큰 비용이 발생할 수 있음 • 때문에, 길더라도 구체적인 이름을 사용 • 다른 의미와 혼동될만한 가능성을 피할 수 있다. • 미래에 들어가는 이름과 의미가 충돌할 가능성을 낮출 수 있다. • 이름을 정의하기 위한 최소 규약(Naming convention) 정의
이름에 대한 합의와 규약 • 의미를 충분히 표현할 수 있어야 함 • 나중에 이벤트 또는 항목의 이름을 바꾸는 것은 큰 비용이 발생할 수 있음 • 때문에, 길더라도 구체적인 이름을 사용 • 다른 의미와 혼동될만한 가능성을 피할 수 있다. • 미래에 들어가는 이름과 의미가 충돌할 가능성을 낮출 수 있다. • 이름을 정의하기 위한 최소 규약(Naming convention) 정의 또한 모두가 어느 정도 일관화된 방식으로 이름을 짓기 위해 최소한의 규약이 필요합니다.
이름에 대한 합의와 규약 • 이벤트 이름 1. 파스칼 표기법(단어의 첫문자를 대문자로 시작하는 표기법)을 따른다. 2. 이벤트의 구성요소들과 상태 변화 또는 행동에 대한 내용을 모두 포함한다. 예) 플레이어의 아이템 획득 → PlayerGotItem 구성요소 - Player, Item 행동 – Get(Got) • 항목 이름 1. 스네이크 표기법(단어를 밑줄로 구분하는 방법)을 따른다. 예) player_level ... (중략) 예제
이름에 대한 합의와 규약 • 이벤트 이름 1. 파스칼 표기법(단어의 첫문자를 대문자로 시작하는 표기법)을 따른다. 2. 이벤트의 구성요소들과 상태 변화 또는 행동에 대한 내용을 모두 포함한다. 예) 플레이어의 아이템 획득 → PlayerGotItem 구성요소 - Player, Item 행동 – Get(Got) • 항목 이름 1. 스네이크 표기법(단어를 밑줄로 구분하는 방법)을 따른다. 예) player_level ... (중략) 예제 이 규약에 대해서 간단하게 예시를 들어보자면
이름에 대한 합의와 규약 • 이벤트 이름 1. 파스칼 표기법(단어의 첫문자를 대문자로 시작하는 표기법)을 따른다. 2. 이벤트의 구성요소들과 상태 변화 또는 행동에 대한 내용을 모두 포함한다. 예) 플레이어의 아이템 획득 → PlayerGotItem 구성요소 - Player, Item 행동 – Get(Got) • 항목 이름 1. 스네이크 표기법(단어를 밑줄로 구분하는 방법)을 따른다. 예) player_level ... (중략) 예제 이벤트와 항목의 이름에 대해서 어떤 표기법을 사용할 것인지
이름에 대한 합의와 규약 • 이벤트 이름 1. 파스칼 표기법(단어의 첫문자를 대문자로 시작하는 표기법)을 따른다. 2. 이벤트의 구성요소들과 상태 변화 또는 행동에 대한 내용을 모두 포함한다. 예) 플레이어의 아이템 획득 → PlayerGotItem 구성요소 - Player, Item 행동 – Get(Got) • 항목 이름 1. 스네이크 표기법(단어를 밑줄로 구분하는 방법)을 따른다. 예) player_level ... (중략) 예제 어떤 내용이 꼭 포함되어야 하는지에 대한 내용들이 정의되어 있어야 합니다.
이벤트를 구별하는 기준 • ‘〈상태〉의 시작’, ‘〈상태〉의 종료’ • 상태의 시작과 종료를 이벤트로 분류하는 구조 • 의미적으로 명확하게 구분이 가능하지만, 이벤트 종류가 많아질 수 있음. • 시작과 완료 시 항목 구성의 차이가 큰 경우에 적합 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 예) 그리고 상태 변화의 이력이 중요한 경우에 좀 더 적합한 경우라고 볼 수 있습니다.
이벤트를 구별하는 기준 • 한 이벤트가 억지로 여러 가지 이벤트를 포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음
이벤트를 구별하는 기준 • 한 이벤트가 억지로 여러 가지 이벤트를 포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음 앞서 말씀드렸던 것은 퀘스트의 시작과 종료뿐만 아니라
이벤트를 구별하는 기준 • 한 이벤트가 억지로 여러 가지 이벤트를 포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음 재화의 사용 또는 획득, 플레이어의 접속과 종료 등 다양한 케이스에서 생각해볼 수 있는데요.
이벤트를 구별하는 기준 • 한 이벤트가 억지로 여러 가지 이벤트를 포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음 중요한 것은, 어느 것이 적합할 것인지 판단하는 것입니다.
이벤트를 구별하는 기준 • 한 이벤트가 억지로 여러 가지 이벤트를 포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음 이전 예제에서는 묶는 것이 좀 더 좋은 경우라고 말씀드렸지만
이벤트를 구별하는 기준 • 한 이벤트가 억지로 여러 가지 이벤트를 포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음 반대로 하나의 이벤트가 억지로 여러 가지 이벤트를 포괄하지 않는 것 또한 중요합니다,
이벤트를 구별하는 기준 • 한 이벤트가 억지로 여러 가지 이벤트를 포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음 특정 이벤트에 대한 내용이 변경될 때 유연한 대처가 어렵고
이벤트를 구별하는 기준 • 한 이벤트가 억지로 여러 가지 이벤트를 포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음 결국 이름이 가지는 의미가 불명확해지거나
이벤트를 구별하는 기준 • 한 이벤트가 억지로 여러 가지 이벤트를 포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음 데이터 타입이나 표현 방법을 통일하게 되면서
이벤트를 구별하는 기준 • 한 이벤트가 억지로 여러 가지 이벤트를 포괄하지 않도록 함 • 특정 이벤트에 대한 내용이 변경될 수 있음 • 이벤트와 항목의 이름이 여러 가지 의미를 가지게 되어 불명확해질 수 있음 • 데이터 타입이나 표현 방법을 통일하게 되면서, 데이터를 상세하게 남기지 못할 수 있음 데이터를 상세하게 남기지 못하는 문제가 발생할 수 있기 때문입니다.
표현력 • 약간의 데이터 용량 절감을 위해 축약된 표현을 사용하지 않는다. • 저장 비용은 크지 않고, 경우에 따라 압축이 가능하다. • 득보다 실이 많을 수 있다. • 경우에 따라 데이터 타입에 대한 고려 또한 필요 예) 소수점 표현, 숫자 범위 다음은 표현력에 대한 이야기입니다.
표현력 • 약간의 데이터 용량 절감을 위해 축약된 표현을 사용하지 않는다. • 저장 비용은 크지 않고, 경우에 따라 압축이 가능하다. • 득보다 실이 많을 수 있다. • 경우에 따라 데이터 타입에 대한 고려 또한 필요 예) 소수점 표현, 숫자 범위 첫 번째는 약간의 데이터 용량 절감을 위해 굳이 축약된 표현을 사용하지 않는 것입니다.
표현력 • 약간의 데이터 용량 절감을 위해 축약된 표현을 사용하지 않는다. • 저장 비용은 크지 않고, 경우에 따라 압축이 가능하다. • 득보다 실이 많을 수 있다. • 경우에 따라 데이터 타입에 대한 고려 또한 필요 예) 소수점 표현, 숫자 범위 스토리지 비용, 즉 저장비용은 크지 않고 경우에 따라서는 로그 시스템상에서 압축이 가능하기 때문입니다.
표현력 • 약간의 데이터 용량 절감을 위해 축약된 표현을 사용하지 않는다. • 저장 비용은 크지 않고, 경우에 따라 압축이 가능하다. • 득보다 실이 많을 수 있다. • 경우에 따라 데이터 타입에 대한 고려 또한 필요 예) 소수점 표현, 숫자 범위 오히려 축약된 표현을 사용함으로써 생산성의 저하가 발생할 수 있습니다.
표현력 • 약간의 데이터 용량 절감을 위해 축약된 표현을 사용하지 않는다. • 저장 비용은 크지 않고, 경우에 따라 압축이 가능하다. • 득보다 실이 많을 수 있다. • 경우에 따라 데이터 타입에 대한 고려 또한 필요 예) 소수점 표현, 숫자 범위 두 번째는 데이터 타입에 대한 이야기입니다.
표현력 • 약간의 데이터 용량 절감을 위해 축약된 표현을 사용하지 않는다. • 저장 비용은 크지 않고, 경우에 따라 압축이 가능하다. • 득보다 실이 많을 수 있다. • 경우에 따라 데이터 타입에 대한 고려 또한 필요 예) 소수점 표현, 숫자 범위 예를 들어 소수점 단위가 중요한 경우나, 실제 값에 들어갈 숫자의 범위에 따라
표현력 • 약간의 데이터 용량 절감을 위해 축약된 표현을 사용하지 않는다. • 저장 비용은 크지 않고, 경우에 따라 압축이 가능하다. • 득보다 실이 많을 수 있다. • 경우에 따라 데이터 타입에 대한 고려 또한 필요 예) 소수점 표현, 숫자 범위 기술적으로 필요한 데이터 타입이 다를 수 있다는 것을 고려해야 합니다.
로그 형식 • 서비스 로그는 특정 항목에 대한 접근이 필요한 경우가 많음 • 필요한 요소 • 컴퓨터가 읽기 쉽도록 구조화된 형식 • 사람이 읽을 수 있는 형식 • 일반적으로 많이 쓰이는 형식 • 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", ... } { "type":"PlayerExpUp", "context_id": "1a2b3c4d5e", ... } 문맥 식별자와 고유 식별자 • 문맥 식별자(Context identifier) “이 플레이어가 경험치를 어떤 경로로 획득했을까?” “퀘스트 완료를 통해 획득했구나!” → 문맥 식별자로 검색 → 인과관계 확인가능 또한, 대규모 집계 시에 큰 도움을 주기 때문에 꼭 넣는 것을 추천드립니다.
서비스에 줄 수 있는 영향 • 배보다 배꼽이 큰 경우가 있을 수 있음 • 기술적인 한계를 해결하거나, 또는 적절한 타협점을 찾아야 함 • 예) 로그에 필요한 값을 채우는 것이 서버에 과도한 부하를 일으킬 수 있는 경우 → 서버에서 캐싱 하거나 또는 메타데이터를 활용하거나 • 예) 모든 유저에 대하여 n초마다 발생하는 로그 → 샘플링하거나, 변경 시에만 남기거나
서비스에 줄 수 있는 영향 • 배보다 배꼽이 큰 경우가 있을 수 있음 • 기술적인 한계를 해결하거나, 또는 적절한 타협점을 찾아야 함 • 예) 로그에 필요한 값을 채우는 것이 서버에 과도한 부하를 일으킬 수 있는 경우 → 서버에서 캐싱 하거나 또는 메타데이터를 활용하거나 • 예) 모든 유저에 대하여 n초마다 발생하는 로그 → 샘플링하거나, 변경 시에만 남기거나 첫 번째는 로그도 로그지만 서비스에 줄 수 있는 영향을 생각하지 않을 수 없다는 것입니다.
서비스에 줄 수 있는 영향 • 배보다 배꼽이 큰 경우가 있을 수 있음 • 기술적인 한계를 해결하거나, 또는 적절한 타협점을 찾아야 함 • 예) 로그에 필요한 값을 채우는 것이 서버에 과도한 부하를 일으킬 수 있는 경우 → 서버에서 캐싱 하거나 또는 메타데이터를 활용하거나 • 예) 모든 유저에 대하여 n초마다 발생하는 로그 → 샘플링하거나, 변경 시에만 남기거나 예를 들어 로그에 필요한 값을 채우는 것이 서버에 과도한 부하를 일으키거나
서비스에 줄 수 있는 영향 • 배보다 배꼽이 큰 경우가 있을 수 있음 • 기술적인 한계를 해결하거나, 또는 적절한 타협점을 찾아야 함 • 예) 로그에 필요한 값을 채우는 것이 서버에 과도한 부하를 일으킬 수 있는 경우 → 서버에서 캐싱 하거나 또는 메타데이터를 활용하거나 • 예) 모든 유저에 대하여 n초마다 발생하는 로그 → 샘플링하거나, 변경 시에만 남기거나 모든 유저에 대해 n초마다 발생하는 로그가 필요한 경우를 생각해볼 수 있는데요.
서비스에 줄 수 있는 영향 • 배보다 배꼽이 큰 경우가 있을 수 있음 • 기술적인 한계를 해결하거나, 또는 적절한 타협점을 찾아야 함 • 예) 로그에 필요한 값을 채우는 것이 서버에 과도한 부하를 일으킬 수 있는 경우 → 서버에서 캐싱 하거나 또는 메타데이터를 활용하거나 • 예) 모든 유저에 대하여 n초마다 발생하는 로그 → 샘플링하거나, 변경 시에만 남기거나 전자의 경우, 서버에서 캐싱 하여 기술적으로 해결하는 방법과
서비스에 줄 수 있는 영향 • 배보다 배꼽이 큰 경우가 있을 수 있음 • 기술적인 한계를 해결하거나, 또는 적절한 타협점을 찾아야 함 • 예) 로그에 필요한 값을 채우는 것이 서버에 과도한 부하를 일으킬 수 있는 경우 → 서버에서 캐싱 하거나 또는 메타데이터를 활용하거나 • 예) 모든 유저에 대하여 n초마다 발생하는 로그 → 샘플링하거나, 변경 시에만 남기거나 메타데이터를 활용하는 방법으로 서버의 부담을 낮추고,
서비스에 줄 수 있는 영향 • 배보다 배꼽이 큰 경우가 있을 수 있음 • 기술적인 한계를 해결하거나, 또는 적절한 타협점을 찾아야 함 • 예) 로그에 필요한 값을 채우는 것이 서버에 과도한 부하를 일으킬 수 있는 경우 → 서버에서 캐싱 하거나 또는 메타데이터를 활용하거나 • 예) 모든 유저에 대하여 n초마다 발생하는 로그 → 샘플링하거나, 변경 시에만 남기거나 후자의 경우에는 샘플링하거나 값이 변경될 때에만 남기는 방향으로
서비스에 줄 수 있는 영향 • 배보다 배꼽이 큰 경우가 있을 수 있음 • 기술적인 한계를 해결하거나, 또는 적절한 타협점을 찾아야 함 • 예) 로그에 필요한 값을 채우는 것이 서버에 과도한 부하를 일으킬 수 있는 경우 → 서버에서 캐싱 하거나 또는 메타데이터를 활용하거나 • 예) 모든 유저에 대하여 n초마다 발생하는 로그 → 샘플링하거나, 변경 시에만 남기거나 적절한 타협점을 찾는 것이 중요합니다.
정리 좋은 로그를 위해 고려해야 할 것들 7. 빈 값의 의미를 명확하게 8. 로그 형식 9. 메타데이터 사용에 대한 충분한 고민 10. 문맥 식별자와 고유 식별자 11. 서비스에 줄 수 있는 영향 12. 할 수 있는 것부터 1. 목표가 있는 로그 2. 일관성 3. 믿을 수 있는 로그 4. 이름에 대한 합의와 규약 5. 이벤트를 구별하는 기준 6. 표현력
정리 좋은 로그를 위해 고려해야 할 것들 7. 빈 값의 의미를 명확하게 8. 로그 형식 9. 메타데이터 사용에 대한 충분한 고민 10. 문맥 식별자와 고유 식별자 11. 서비스에 줄 수 있는 영향 12. 할 수 있는 것부터 1. 목표가 있는 로그 2. 일관성 3. 믿을 수 있는 로그 4. 이름에 대한 합의와 규약 5. 이벤트를 구별하는 기준 6. 표현력 지금까지 총 12가지의 내용을 이야기했는데요.
정리 좋은 로그를 위해 고려해야 할 것들 7. 빈 값의 의미를 명확하게 8. 로그 형식 9. 메타데이터 사용에 대한 충분한 고민 10. 문맥 식별자와 고유 식별자 11. 서비스에 줄 수 있는 영향 12. 할 수 있는 것부터 1. 목표가 있는 로그 2. 일관성 3. 믿을 수 있는 로그 4. 이름에 대한 합의와 규약 5. 이벤트를 구별하는 기준 6. 표현력 다소 많아 보일 수 있지만
정리 좋은 로그를 위해 고려해야 할 것들 7. 빈 값의 의미를 명확하게 8. 로그 형식 9. 메타데이터 사용에 대한 충분한 고민 10. 문맥 식별자와 고유 식별자 11. 서비스에 줄 수 있는 영향 12. 할 수 있는 것부터 1. 목표가 있는 로그 2. 일관성 3. 믿을 수 있는 로그 4. 이름에 대한 합의와 규약 5. 이벤트를 구별하는 기준 6. 표현력 처음부터 완벽하게 만드는 것은 힘들기 때문에
정리 좋은 로그를 위해 고려해야 할 것들 7. 빈 값의 의미를 명확하게 8. 로그 형식 9. 메타데이터 사용에 대한 충분한 고민 10. 문맥 식별자와 고유 식별자 11. 서비스에 줄 수 있는 영향 12. 할 수 있는 것부터 1. 목표가 있는 로그 2. 일관성 3. 믿을 수 있는 로그 4. 이름에 대한 합의와 규약 5. 이벤트를 구별하는 기준 6. 표현력 할 수 있는 것부터 시작하는 것을 다시 한번 강조 드리고 싶습니다.
품질 관리가 필요한 이유 • 이벤트와 항목들은 서비스가 성장할수록 점점 많아진다. • 계속해서 변경과 특이사항들이 발생할 것이다. • 점점 더 많은 사람들이 데이터로부터 의사결정을 하게 될 것이다. 다들 겪어보셨겠지만, 이벤트와 각각의 항목들은 서비스가 성장할수록 점점 많아지고
서비스 구성요소별 로그 관리 • 특정 구성요소에 대한 로그를 쉽게 파악할 수 있음 • 로그에 존재하는 항목의 일관성을 유지하는 데 도움 예) 플레이어의 아이템 획득 이벤트의 경우 플레이어와 아이템이라는 구성요소를 가진다. 플레이어의 공통 항목 - 아이디, 레벨, 최근 접속 시간 … 등 아이템의 공통 항목 - 종류, 아이템 레벨, 최대 내구도 … 등
서비스 구성요소별 로그 관리 • 특정 구성요소에 대한 로그를 쉽게 파악할 수 있음 • 로그에 존재하는 항목의 일관성을 유지하는 데 도움 예) 플레이어의 아이템 획득 이벤트의 경우 플레이어와 아이템이라는 구성요소를 가진다. 플레이어의 공통 항목 - 아이디, 레벨, 최근 접속 시간 … 등 아이템의 공통 항목 - 종류, 아이템 레벨, 최대 내구도 … 등 첫 번째로는 서비스 구성요소 별로 로그와 그 공통항목을 관리하는 것입니다.
서비스 구성요소별 로그 관리 • 특정 구성요소에 대한 로그를 쉽게 파악할 수 있음 • 로그에 존재하는 항목의 일관성을 유지하는 데 도움 예) 플레이어의 아이템 획득 이벤트의 경우 플레이어와 아이템이라는 구성요소를 가진다. 플레이어의 공통 항목 - 아이디, 레벨, 최근 접속 시간 … 등 아이템의 공통 항목 - 종류, 아이템 레벨, 최대 내구도 … 등 예제와 같이, 플레이어와 아이템에 관련된 로그가 어떤 것들이 있는지 정리하고
서비스 구성요소별 로그 관리 • 특정 구성요소에 대한 로그를 쉽게 파악할 수 있음 • 로그에 존재하는 항목의 일관성을 유지하는 데 도움 예) 플레이어의 아이템 획득 이벤트의 경우 플레이어와 아이템이라는 구성요소를 가진다. 플레이어의 공통 항목 - 아이디, 레벨, 최근 접속 시간 … 등 아이템의 공통 항목 - 종류, 아이템 레벨, 최대 내구도 … 등 그리고 구성요소들에 대해 공통항목을 관리하는 것입니다.
서비스 구성요소별 로그 관리 • 특정 구성요소에 대한 로그를 쉽게 파악할 수 있음 • 로그에 존재하는 항목의 일관성을 유지하는 데 도움 예) 플레이어의 아이템 획득 이벤트의 경우 플레이어와 아이템이라는 구성요소를 가진다. 플레이어의 공통 항목 - 아이디, 레벨, 최근 접속 시간 … 등 아이템의 공통 항목 - 종류, 아이템 레벨, 최대 내구도 … 등 서비스의 특정 구성요소에 관련된 로그들을 쉽게 파악할 수 있고
서비스 구성요소별 로그 관리 • 특정 구성요소에 대한 로그를 쉽게 파악할 수 있음 • 로그에 존재하는 항목의 일관성을 유지하는 데 도움 예) 플레이어의 아이템 획득 이벤트의 경우 플레이어와 아이템이라는 구성요소를 가진다. 플레이어의 공통 항목 - 아이디, 레벨, 최근 접속 시간 … 등 아이템의 공통 항목 - 종류, 아이템 레벨, 최대 내구도 … 등 로그의 일관성을 유지하는 데 도움이 됩니다.
로그의 문서화 • 다음 내용에 대한 기록이 필요하다. • 로그의 목표와 의미 • 로그의 정확한 발생 시점 • 각 항목들의 의미와 데이터 타입 • 항목의 추가/변경/삭제 이력 • 특이사항 기록(발생 일시, 내용) • 로그가 사용되는 곳 • 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음 • 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음
로그의 문서화 • 다음 내용에 대한 기록이 필요하다. • 로그의 목표와 의미 • 로그의 정확한 발생 시점 • 각 항목들의 의미와 데이터 타입 • 항목의 추가/변경/삭제 이력 • 특이사항 기록(발생 일시, 내용) • 로그가 사용되는 곳 • 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음 • 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음 다음으로는 문서화에 대한 이야기입니다.
로그의 문서화 • 다음 내용에 대한 기록이 필요하다. • 로그의 목표와 의미 • 로그의 정확한 발생 시점 • 각 항목들의 의미와 데이터 타입 • 항목의 추가/변경/삭제 이력 • 특이사항 기록(발생 일시, 내용) • 로그가 사용되는 곳 • 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음 • 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음 기본적으로, 로그가 어떤 목표와 의미를 가지고, 어떤 시점에 발생하는지
로그의 문서화 • 다음 내용에 대한 기록이 필요하다. • 로그의 목표와 의미 • 로그의 정확한 발생 시점 • 각 항목들의 의미와 데이터 타입 • 항목의 추가/변경/삭제 이력 • 특이사항 기록(발생 일시, 내용) • 로그가 사용되는 곳 • 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음 • 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음 항목의 추가, 변경, 삭제 이력에 대한 정보가 필요합니다.
로그의 문서화 • 다음 내용에 대한 기록이 필요하다. • 로그의 목표와 의미 • 로그의 정확한 발생 시점 • 각 항목들의 의미와 데이터 타입 • 항목의 추가/변경/삭제 이력 • 특이사항 기록(발생 일시, 내용) • 로그가 사용되는 곳 • 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음 • 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음 또한 로그 유실과 같은 특이사항에 대한 내용이 기록되어야 하고
로그의 문서화 • 다음 내용에 대한 기록이 필요하다. • 로그의 목표와 의미 • 로그의 정확한 발생 시점 • 각 항목들의 의미와 데이터 타입 • 항목의 추가/변경/삭제 이력 • 특이사항 기록(발생 일시, 내용) • 로그가 사용되는 곳 • 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음 • 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음 이런 특이사항이 발생했을 때 어떤 지표에 영향이 있는지 파악하기 위해
로그의 문서화 • 다음 내용에 대한 기록이 필요하다. • 로그의 목표와 의미 • 로그의 정확한 발생 시점 • 각 항목들의 의미와 데이터 타입 • 항목의 추가/변경/삭제 이력 • 특이사항 기록(발생 일시, 내용) • 로그가 사용되는 곳 • 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음 • 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음 로그가 어떻게 사용되고 있는지에 대한 정보가 정리되어야 합니다.
로그의 문서화 • 다음 내용에 대한 기록이 필요하다. • 로그의 목표와 의미 • 로그의 정확한 발생 시점 • 각 항목들의 의미와 데이터 타입 • 항목의 추가/변경/삭제 이력 • 특이사항 기록(발생 일시, 내용) • 로그가 사용되는 곳 • 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음 • 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음 문서화가 되어있지 않다는 것은 정말 큰 생산성의 저하로 다가올 수 있습니다.
로그의 문서화 • 다음 내용에 대한 기록이 필요하다. • 로그의 목표와 의미 • 로그의 정확한 발생 시점 • 각 항목들의 의미와 데이터 타입 • 항목의 추가/변경/삭제 이력 • 특이사항 기록(발생 일시, 내용) • 로그가 사용되는 곳 • 로그의 구조나 의미가 변경될 때 다른 지표에 대한 영향을 미리 파악할 수 있음 • 예) 어떤 대시보드에서 어떤 용도로 사용되고 있음 더욱더 중요한 것은, 문서가 지속적으로 업데이트되고 관리되어야 한다는 것입니다.
로그 추가 및 변경의 프로세스화 1. 목표 정의 2. 관계자들의 의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 1. 목표 정의 • 추가(또는 변경)의 목표를 구체적으로 정의 • 어떤 데이터가 필요한 것인지 정의 프로세스의 첫 번째 단계는 역시 목표를 정의하는 것입니다.
로그 추가 및 변경의 프로세스화 1. 목표 정의 2. 관계자들의 의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 1. 목표 정의 • 추가(또는 변경)의 목표를 구체적으로 정의 • 어떤 데이터가 필요한 것인지 정의 추가든 변경이든 목표를 정의하고
로그 추가 및 변경의 프로세스화 1. 목표 정의 2. 관계자들의 의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 1. 목표 정의 • 추가(또는 변경)의 목표를 구체적으로 정의 • 어떤 데이터가 필요한 것인지 정의 그에 따라 1차적으로 필요한 데이터를 정의하고 나면
로그 추가 및 변경의 프로세스화 1. 목표 정의 2. 관계자들의 의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 2. 관계자들과 의견을 종합하여 로그를 설계 • 관계자? • 지표를 보는 사람들 / 만드는 사람들(분석가) • 개발자(실제 로그에 대한 코드를 작성) • 이벤트 정의 • 지표를 어떻게 볼 것인지 다양한 각도로 고민 • 필요한 항목들을 더 구체적으로 정의 • 추가 가능 여부, 한계, 대안 • 우선순위 • 가까운 미래에 발생할 수 있는 다른 가능성 고민 • 합의된 내용을 기반으로 문서화
로그 추가 및 변경의 프로세스화 1. 목표 정의 2. 관계자들의 의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 2. 관계자들과 의견을 종합하여 로그를 설계 • 관계자? • 지표를 보는 사람들 / 만드는 사람들(분석가) • 개발자(실제 로그에 대한 코드를 작성) • 이벤트 정의 • 지표를 어떻게 볼 것인지 다양한 각도로 고민 • 필요한 항목들을 더 구체적으로 정의 • 추가 가능 여부, 한계, 대안 • 우선순위 • 가까운 미래에 발생할 수 있는 다른 가능성 고민 • 합의된 내용을 기반으로 문서화 두 번째로 필요한 것은 관계자들과 의견을 종합하여 실제로 로그를 설계하는 과정입니다.
로그 추가 및 변경의 프로세스화 1. 목표 정의 2. 관계자들의 의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 2. 관계자들과 의견을 종합하여 로그를 설계 • 관계자? • 지표를 보는 사람들 / 만드는 사람들(분석가) • 개발자(실제 로그에 대한 코드를 작성) • 이벤트 정의 • 지표를 어떻게 볼 것인지 다양한 각도로 고민 • 필요한 항목들을 더 구체적으로 정의 • 추가 가능 여부, 한계, 대안 • 우선순위 • 가까운 미래에 발생할 수 있는 다른 가능성 고민 • 합의된 내용을 기반으로 문서화 관계자라고 함은, 지표를 만드는 사람들뿐만 아니라 지표를 보는 사람들과
로그 추가 및 변경의 프로세스화 1. 목표 정의 2. 관계자들의 의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 2. 관계자들과 의견을 종합하여 로그를 설계 • 관계자? • 지표를 보는 사람들 / 만드는 사람들(분석가) • 개발자(실제 로그에 대한 코드를 작성) • 이벤트 정의 • 지표를 어떻게 볼 것인지 다양한 각도로 고민 • 필요한 항목들을 더 구체적으로 정의 • 추가 가능 여부, 한계, 대안 • 우선순위 • 가까운 미래에 발생할 수 있는 다른 가능성 고민 • 합의된 내용을 기반으로 문서화 실제 로그에 대해 코드를 작성하는 개발자를 모두 포함합니다.
로그 추가 및 변경의 프로세스화 1. 목표 정의 2. 관계자들의 의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 2. 관계자들과 의견을 종합하여 로그를 설계 • 관계자? • 지표를 보는 사람들 / 만드는 사람들(분석가) • 개발자(실제 로그에 대한 코드를 작성) • 이벤트 정의 • 지표를 어떻게 볼 것인지 다양한 각도로 고민 • 필요한 항목들을 더 구체적으로 정의 • 추가 가능 여부, 한계, 대안 • 우선순위 • 가까운 미래에 발생할 수 있는 다른 가능성 고민 • 합의된 내용을 기반으로 문서화 첫 번째 단계에서 정의했던 목표와 그 내용을 기반으로
로그 추가 및 변경의 프로세스화 1. 목표 정의 2. 관계자들의 의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 2. 관계자들과 의견을 종합하여 로그를 설계 • 관계자? • 지표를 보는 사람들 / 만드는 사람들(분석가) • 개발자(실제 로그에 대한 코드를 작성) • 이벤트 정의 • 지표를 어떻게 볼 것인지 다양한 각도로 고민 • 필요한 항목들을 더 구체적으로 정의 • 추가 가능 여부, 한계, 대안 • 우선순위 • 가까운 미래에 발생할 수 있는 다른 가능성 고민 • 합의된 내용을 기반으로 문서화 다양한 관계자들과 함께 우선순위와 한계, 대안, 설계 내용들을 취합하고 적절히 타협하여
로그 추가 및 변경의 프로세스화 1. 목표 정의 2. 관계자들의 의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 2. 관계자들과 의견을 종합하여 로그를 설계 • 관계자? • 지표를 보는 사람들 / 만드는 사람들(분석가) • 개발자(실제 로그에 대한 코드를 작성) • 이벤트 정의 • 지표를 어떻게 볼 것인지 다양한 각도로 고민 • 필요한 항목들을 더 구체적으로 정의 • 추가 가능 여부, 한계, 대안 • 우선순위 • 가까운 미래에 발생할 수 있는 다른 가능성 고민 • 합의된 내용을 기반으로 문서화 로그 설계를 구체화해야 합니다.
로그 추가 및 변경의 프로세스화 1. 목표 정의 2. 관계자들의 의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 3. 로그 추가 또는 변경 작업 4. 테스트 / QA • 의도한 시점에 제대로 발생하는지 확인 • 의도한 형태로 남는지 확인 • 값이 정확한지 확인 5. 배포
로그 추가 및 변경의 프로세스화 1. 목표 정의 2. 관계자들의 의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 3. 로그 추가 또는 변경 작업 4. 테스트 / QA • 의도한 시점에 제대로 발생하는지 확인 • 의도한 형태로 남는지 확인 • 값이 정확한지 확인 5. 배포 실제로 로그 추가 및 변경 작업을 한 뒤에는
로그 추가 및 변경의 프로세스화 1. 목표 정의 2. 관계자들의 의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 3. 로그 추가 또는 변경 작업 4. 테스트 / QA • 의도한 시점에 제대로 발생하는지 확인 • 의도한 형태로 남는지 확인 • 값이 정확한지 확인 5. 배포 실수를 방지하고 라이브에서 로그가 잘못 남지 않도록 여러 번의 테스트와 QA를 통해
로그 추가 및 변경의 프로세스화 1. 목표 정의 2. 관계자들의 의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 3. 로그 추가 또는 변경 작업 4. 테스트 / QA • 의도한 시점에 제대로 발생하는지 확인 • 의도한 형태로 남는지 확인 • 값이 정확한지 확인 5. 배포 의도한 시점에서 제대로 발생하는지 의도한 형태로 남는지, 값이 정확한지와 같은 부분들이
로그 추가 및 변경의 프로세스화 1. 목표 정의 2. 관계자들의 의견을 종합하여 로그를 설계 3. 로그 추가 또는 변경 작업 4. 테스트 / QA 5. 배포 3. 로그 추가 또는 변경 작업 4. 테스트 / QA • 의도한 시점에 제대로 발생하는지 확인 • 의도한 형태로 남는지 확인 • 값이 정확한지 확인 5. 배포 꼭 확인된 뒤에 라이브에 배포되어야 합니다.
효율적인 프로세스 진행을 위해 • 로그 설계 방식에 대하여 미리 합의된 최소한의 규약이 필요 • 자칫하면 비효율적으로 작동할 수 있는 프로세스 • 처음부터 모든 것을 충족할 수 없으므로, 점진적 개선이 필요 • 잘못 남겨진 로그는 이후 생산성을 크게 저하시키기 때문에 충분한 테스트와 QA 과정이 필요
효율적인 프로세스 진행을 위해 • 로그 설계 방식에 대하여 미리 합의된 최소한의 규약이 필요 • 자칫하면 비효율적으로 작동할 수 있는 프로세스 • 처음부터 모든 것을 충족할 수 없으므로, 점진적 개선이 필요 • 잘못 남겨진 로그는 이후 생산성을 크게 저하시키기 때문에 충분한 테스트와 QA 과정이 필요 이런 프로세스는 다소 비효율적으로 작동할 수 있습니다.
효율적인 프로세스 진행을 위해 • 로그 설계 방식에 대하여 미리 합의된 최소한의 규약이 필요 • 자칫하면 비효율적으로 작동할 수 있는 프로세스 • 처음부터 모든 것을 충족할 수 없으므로, 점진적 개선이 필요 • 잘못 남겨진 로그는 이후 생산성을 크게 저하시키기 때문에 충분한 테스트와 QA 과정이 필요 때문에 로그 설계 방식에 대해 이름 규약같은 미리 합의된 최소한의 규약들이 필요합니다.
효율적인 프로세스 진행을 위해 • 로그 설계 방식에 대하여 미리 합의된 최소한의 규약이 필요 • 자칫하면 비효율적으로 작동할 수 있는 프로세스 • 처음부터 모든 것을 충족할 수 없으므로, 점진적 개선이 필요 • 잘못 남겨진 로그는 이후 생산성을 크게 저하시키기 때문에 충분한 테스트와 QA 과정이 필요 처음부터 모든 것을 충족시킬 수 없으므로 점진적으로 개선이 필요하고
효율적인 프로세스 진행을 위해 • 로그 설계 방식에 대하여 미리 합의된 최소한의 규약이 필요 • 자칫하면 비효율적으로 작동할 수 있는 프로세스 • 처음부터 모든 것을 충족할 수 없으므로, 점진적 개선이 필요 • 잘못 남겨진 로그는 이후 생산성을 크게 저하시키기 때문에 충분한 테스트와 QA 과정이 필요 충분한 테스트와 QA 과정은 다시 한번 강조 드리고 싶습니다.
마치며 • 가장 중요한 것은 ‘좋은 로그’에 대한 공감대를 형성하는 것 • 가장 어렵지만 필요한 것은, 서로 다른 입장에 대하여 열린 마음을 가지는 것 • 모든 것을 만족시킬 순 없지만, 할 수 있는 것부터 하는 것이 중요 결국 가장 중요한 것은 ‘좋은 로그’에 대한 공감대를 형성하는 것입니다.
마치며 • 가장 중요한 것은 ‘좋은 로그’에 대한 공감대를 형성하는 것 • 가장 어렵지만 필요한 것은, 서로 다른 입장에 대하여 열린 마음을 가지는 것 • 모든 것을 만족시킬 순 없지만, 할 수 있는 것부터 하는 것이 중요 다양한 사람들이 같이 고민해야 하는 만큼 서로 다른 입장에 대해서 열린 마음을 가지고
마치며 • 가장 중요한 것은 ‘좋은 로그’에 대한 공감대를 형성하는 것 • 가장 어렵지만 필요한 것은, 서로 다른 입장에 대하여 열린 마음을 가지는 것 • 모든 것을 만족시킬 순 없지만, 할 수 있는 것부터 하는 것이 중요 할 수 있는 것부터 개선하는 것이 중요하다는 것을 이야기 드리면서
devinjeon
manfredsteyer
nano72mkn
mot_techtalk
ojun9
piyoppi
mackey0225
rmatsuoka
zakky21
pospome
yahiru
chimame
ivargrimstad
yeseniaperezcruz
colly
rocio
swwweet
geoffreycrofte
holman
mojombo
mongodb
jlugia
carmenintech
brianwarren
lauravandoore