로그 데이터 정의하기 - 커머스 PM의 기획일지

로그(log)는 왜 필요한가

현재 제가 담당하고 있는 제품의 어드민(백오피스)은 정말 다양한 자유로운 기능이 있지만, 그에 비해 로그 데이터는 제대로 기록되지 않고 있습니다. 아주 오래전부터 소수의 인원이 제품을 만들어왔고 그랬기 때문에 서로에 대한 신뢰를 바탕으로 서비스가 운영되고 있었습니다.

 

사실 고객의 데이터가 수정됐다면 로그가 남아야 하는 것이 당연한데, 그렇지 않은 게 많았던 상황입니다. (일부 중요한 데이터를 기준으로 로그가 기록되고 있긴 하지만 통일된 정책은 없습니다.)

 

건강한 제품을 만들어나가려면 PM인 저도 로그를 어떻게 기록할지 생각하며 백오피스를 기획해야 한다는 생각이 들었습니다. 그런 이유로 이번에 관련 자료들을 찾아보고 글로 정리하게 되었습니다.

 

 

 

로그(log)란?

로그의 유래와 의미

재미있는 사실은 로그는 정말로 log(통나무)에서 그 의미가 유래됐다고 합니다. 배의 앞 부분에서 통나무를 띄워서 배의 끝까지 도달하는데 걸린 시간을 측정하여 배의 속력을 측정하는 것으로부터 비롯되었다고 합니다. 그 외에도 로그북에서 항해의 세부 사항, 날씨 조건, 여정 중 발생한 사건 등을 기록했다고 합니다.

 

여기서 '로그'라는 단어가 무언가 기록할 때 사용되며 웹상의 활동의 정의하는 것에도 사용이 된 것인데요, 사용자가 서비스를 사용하기 시작하면 '로그'인, 사용자가 서비스 이용을 마치면 '로그'아웃을 하는 것에도 사용이 되지요. 

 

로그 데이터의 종류

1. 시스템 로그: 프로그램의 버그나 OS 레벨에서 시스템 이벤트를 추적하기 위해 남긴다.
2. 서비스 로그: 운영하는 서비스의 KPI 같은 지료를 분석하거나 유저의 VoC에 대응하기 위하여 남긴다.

 

 

로그 데이터 형태

로그 데이터가 기록된 내용을 보면 대략적으로 아래와 같은 형태로 저장되는데요 (회사 자료라 다 모자이크가 된 점..^^ 양해 부탁드립니다.) 어떻게 보면 그냥 DB랑 차이점이 뭔데? 라고 생각할 수도 있을 것 같습니다.

 

실제로 저희 개발 팀장님은 저에게 "DB에 기록하지 말고, 로그를 남겨야 한다"라고 하셨지요. (그 말이 계기가 되어 제가 이렇게 리서치를 해보고 있습니다 ㅎ)

 

처음에는 그게 그거 아닌가? 라고 생각했습니다. 개발을 잘 알지 못하는 저로서는 똑같이 DB에 기록된 것처럼 보였기 때문이죠. 하지만, 저장된 데이터를 자세히 보면 그 차이가 이해 갔습니다.

 

예를 들어, 상품DB 테이블의 구조는 아래처럼 구성될 수 있습니다.

product_name	product_id	category_id	pla_price	cus_price
보로로친구들_12개입	00000001	12341234	10000	14000
보로로친구들_24개입	00000002	12341234	18000	23000

 

 

한 칸에 한 개의 데이터만 저장되지요. 꼭 그래야하는 건 아니지만, 데이터베이스의 데이터를 잘 관리하려면 '정규화'라는 법칙을 따라야 하기 때문입니다 (한 칸에 한 개의 데이터를 저장해야하는 것은 제 1정규화입니다). 정규화가 뭔지는 이 글의 주요 주제에서 벗어나기 때문에 자세한 설명은 생략하도록 하겠습니다. 제가 읽었던 글 중 정규화에 대하여 쉽게 설명해 준 글을 추천하자면 데이터리안 블로그의 알아두면 쓸데있는 데이터 모델링 (1) 정규화 글을 추천드립니다.)

 

하지만, 제가 위에서 첨부해 놓은 로그 데이터는 아래처럼 구성되어 있습니다 (위의 테이블 구조에 따른 예시일 뿐, 실제 데이터는 아닙니다.)

manager_id	endPoint	request	msg
hojourney	abc/de/fg	{"chkProductId":"000000001","modiCategory":"false","modiPlaPrice":"false","modiCusPrice":"12000"}	소비자가 변경
hojourney	abc/de/fg	{"chkProductId":"000000002","modiCategory":"11111111","modiPlaPrice":"false","modiCusPrice":"false"}	카테고리 변경

 

즉, 한 칸에 여러 데이터가 저장될 수 있지요. (참고로 이렇게 대괄호({}) 쌍점(:)으로 여러 데이터들이 기록되는 형태는 JSON 형식이라고 합니다.) 이런 형태가 아닌 단순한 텍스트 형식으로만 저장되기도 합니다.

 

좋은 로그란

그렇다면 대체 로그를 어떻게 남기는 것이 좋을까요? 이에 대하여 참고하면 좋을 기준이 있어서 가져왔습니다.

1. 필요한 정보가 있다.
2. 의미가 명확하다.
3. 편리하게 데이터를 얻을 수 있다.

(참고: 넥슨 컴퍼니 왓 스튜디오 전효준 님의 '좋은 로그란 무엇인가?')

 

 

사실 이러한 내용들은 개괄적인 것이고, 아마 데이터를 어떻게 관리하는지는 서비스에 따라 다를 것 같습니다. 제가 위에 제시한 경우도 답이 아닌 것이죠. 저희의 경우는 백오피스에서 관리자의 액션을 저장하여 추가 VoC를 대응하기 위했기 때문에 manager_id를 따로 기록하였습니다. 여러분은 어떻게 정의하실 것 같나요?

 

글에 대한 피드백 환영합니다 :)