Log 잘 남기기

Log를 잘 남기는 것에 대해 저 역시도 어려워하고 많은 사람들이 어려워합니다.

그래서 단순히 어려워하기 보다는 Log를 왜 남기고, 무엇을 Log로 남기고, 주의해야 할 것들은 무엇이 있을지 생각해 보았습니다.

Log를 남기는 이유

로그를 남기는 이유는 당연히 나중에 보기 위함입니다.

제가 그동안 로그를 봤던 상황들을 될돌아보니 크게 아래 4가지 상황이었습니다.

1. 서버 장애 대응
:트래픽 증가 또는 특정 이유로 장애가 난 경우 어떤 Exception이 어느 위치에서 나는지 등 문제의 원인을 파악하기 위해 봤습니다.

2. CS 문의에 대해 확인하기 위해
고객이 어떤 문제에 대해 문의를 해올 때 과거 해당 시점의 로그를 확인하여 당시 상황이 어땠는지 확인했었습니다.

3. 보안 공격 확인
회사 MySQL이 털린 적이 있습니다. 
이 때 어느 경로로 해커가 공격했는지 확인하기 위해 관련 어플리케이션 로그를 확인했었습니다.

4. 데이터를 기반해서 사용자 경험을 개선
사용자가 들어와서 어떤 행동을 많이 하는지에 대한 로그를 남기고 이를 시각화해서 마케팅 부서에서 사용하였습니다.
어플리케이션 레벨의 로그와 다를 수 있지만 이력을 남긴다는 점에서 로그의 범주로 보았습니다.

어떤 것을 Log로 남기고 무엇을 주의해야 할까

1. Exception Log
    - 장애 상황에서 쉽게 원인을 파악하고 조치를 취할 수 있어야 합니다.
    - 어떤 문제가 있는지 뿐만 아니라 문제가 발생한 위치에 대해서도 파악할 수 있도록 로그가 남겨져야 합니다. e.g. Stack Trace
    - 또 단순히 Stack Trace만 로그로 남기는 것이 아니라 문제 원인 파악에 도움이 되는 추가적인 정보(예를 들어 문제를 일으킨 사용자)도 함께 남기는 것이 좋습니다.
    - 추가로 JAVA의 경우 e.printStackTrace()가 아닌 Logger로 Stack Trace를 남기는 것이 좋습니다. 
        - 참고 글 : https://stackoverflow.com/questions/10477607/avoid-printstacktrace-use-a-logger-call-instead 
    - 문제를 미리 파악하기 위해 어플리케이션 내에 심각한 문제(예를 들어 500에러)가 발생하는 경우 slack 또는 메일 알림이 오도록 해 놓는 것이 좋습니다.
2. 비지니스 주요 로직 진행 상황
    - 고객 문의 또는 타부서 문의가 와서 과거에 어떤 일이 있었는지 확인 하는 일은 자주 있는 일입니다.
    - 이를 위해 주요 비지니스 로직에 대해 주요 정보를 로그로 남겨두어야 합니다.
    - 하지만 처음부터 너무 많은 로그를 남기는 것보다는 필요성이 명확한 경우에만 최소한으로 남기고 추후 필요한 경우에 추가하는 것이 더 좋은 방법입니다.
3. 사용자 행동 데이터
    - 비지니스 요구사항에 따라 달라집니다. 직접 관련 라이브러리를 개발할 수도 있지만 Google Analytics와 같은 외부 분석 툴을 사용하는 경우가 많습니다.

추가 주의할 점

1. 성능
로그를 남기는 것도 작업이기 때문에 결국 성능이 중요합니다. 불필요한 로그가 남발 된다면 성능에 악영향을 주게 됩니다. 
그래서 꼭 필요한 로그만 남기는 것이 필요하고, 로거를 선택할 때 성능적인 부분이 함께 고려가 되어야 합니다.

2. 민감한 정보는 남기지 않거나 비식별화하기
로그는 생각보다 보안에 취약합니다. 그렇기 때문에 민감한 정보(주민등록번호, 비밀번호 등)는 남기지 않거나 비식별화하는 것이 좋습니다.

3. 관리하게 쉽도록 하기
로그를 남기는 스타일이 참여하는 개발자마다 다 다를 수 있습니다.

또 로그를 남기는 것들 중 중복된 로직이 많습니다. (예를 들어 컨트롤러 차원에서 Exception 로그)
그래서 가능한 것들은 공통된 부분(JAVA의 경우 AOP 등)으로 분리하고 한꺼번에 처리될 수 있도록 하는 것이 좋습니다.