지금 꼭 로그를 쌓아야할까?

로그란

과거에 나에겐 로그란 디버깅 도구? 방법 정도였다.

토이프로젝트를 하면서 로그는 잘돌아가나? 지켜보는 도구이자

사용자들이 잘 쓰고 있나 지켜보는 용도였다.

그러다가 회사 일을 할때나 조금 더 묵직한 서비스를 만들때

점점 로그는 신규기능과 동시에 챙겨야하는 중요한 부분이 되었다.

하지만 새 프로젝트를 하면 기능 추가와 유지보수로 바쁘기 때문에

로그 기반이나 로그 방식, 표준화된 에러 리포트를 놓치기 쉽다.

그럼에도 로그는 정말 중요하다. 노력대비 얻는 것이 크기 때문인데.

신규기능의 이용활성도, 응답속도,

사용자의 오묘한 이용패턴과 변수 파악, 이럴리가 없는데 에러 포착,

기능개선, 추후 유지보수등등 매우 쓸모가 있기 때문이다.

서버나 웹이나 모바일 환경등등 로그의 형태가 다르고

종류가 많기 때문에 단정짓기는 어렵지만 ..

최소한 서버 단 로그는 반드시 남기는게 필요하다고 본다.

이제 그러면 얼마나/자주/자세히 로그를 남기는지가 고민될 것이다.

로그 걱정 하나

일반적으로 로그 시스템을 구축하려고 하지만

서비스 초반에는 로그가 양이 별로 많지 않다.

따라서 ELK, Datadog 이런거 아니더라도

RDBMS에 쌓아도 무리가 없다. 로그가 월 100만건 넘지 않는다면

일상적인 조회, 통계에 전혀 문제가 없다.

디비는 생각보다 강력해서 시간순서로 쌓인 데이터에 대한 쿼리는 빠르고

SQL을 할줄 안다면 누구나 현재/과거 지표를 뽑기 편하다.

요즘은 MySQL, PostgreSQL도 JSON 지원이 잘되어서

로그 전용 디비를 따로 둘 필요도 없다.

다소 데이터 공간 낭비가 있지만 업데이트 내역(before/after, prev/next)까지

남긴다면 사용자의 시간순 경험을 replay 할 수 있고

버그 파악이나 고객 장애 파악에 도움이 된다.

로그 형식

서비스 형태, 지원기기, 이벤트 단위에 따라 다르겠지만

초기엔 '거의 모든 사용자의 행동'을 로그남기는 걸 추천한다.

이벤트 단위라면 mixpanel, amplitude등 서비스도 있고

마케팅용 써드파티도 많지만 결국엔 디비 조회를 찾게된다. (큰회사나 작은회사 모두)

모바일이나 게임쪽은 상당한 로그를 남기는 것으로 유명한데

웹서비스나 SaaS쪽은 아직 로그 사례가 많이 없는듯 하다.

결론

• 귀찮아도 로그 잘 쌓아야한다.
• 로그도 계획하고 개선해야한다.
• 디비에 쌓아도 서비스 초창기에는 괜찮다. (백만건 이하)
• (통계 용도가 아니더라도) 어차피 서비스가 성장하면 사용자의 모든 내역을 기록해야한다.