레거시 개선하기) 로깅 전략을 만들어보자

업무중에 에러 리포팅을 받아서 무슨 일인지 파악하고자 우리 회사에서 쓰고 있는 한 서비스의 로그파일을 열어볼일이 있었다. 매일 새로운 로그파일이 만들어지는데 하루에 160mb정도의 로그파일이 생기고 있었다. 라인 수도 너무 많고 로그를 봐도 뭔가 명확하지 않았다. 개인적인 느낌으로는 별 실용성 없는 로그들만 쌓이고 있는  느낌.. 사실 여태까지도 느껴왔던 것인데 당장 눈앞에 닥친 일들을 해내는데에 급급해서 무시하고 있었는데 이대로는 안될 것 같아서 로깅 전략이(사실 로깅 전략 뿐만 아니라 여타 프로그래밍? 프로젝트? 규칙, 문서 같은게 없다.)  없는 우리 회사에 한번 같이 지키자고 제안할 전략을 만들어보려고 한다.

 

https://blog.lulab.net/programmer/what-should-i-log-with-an-intention-method-and-level/

위 사이트를 참고했습니다.

1. 로깅을 왜 할까..? 로그 수집의 목적을 명확히 하자

개발자로서의 로그 목적

• 서비스 동작 상태 파악
• 장애 파악 & 알림 ( 우리는 로그에 의거한 알림을 보내진 않으므로 알림은 빼놓고 생각하기로 하자 )

2. 로깅 라이브러리

우리는 로깅 라이브러리로 slf4j를 쓰고 있기 때문에 system의 print문으로 출력할지 로깅 라이브러리를 사용할지에 대해서는 고민할 필요가 없는 문제이고..

로깅 레벨 : 어떤 로그 레벨을 사용할까..?

많은 레벨을 사용하기보단 그냥 명확하게 INFO와 ERROR 두가지만 사용해서 전략을 세워보자. 두가지면 우리가 처음에 생각했던 개발자로서의 로그목적 두개를 각각 레벨하나씩에다 쓰는 것이다.

INFO

서비스의 동작상태를 확인하는 용도로 INFO 레벨을 사용하자. 우리 서비스의 시나리오가 제대로 흘러가고 있는지를 확인하는 용도

ERROR

서비스에 장애가 났는지를 알 수 있게 문제가 생기면 ERROR 레벨로 로그를 남기자. 만약 신뢰할 수 있는 로그 전략을 세워놓고 로깅 프레임워크를 구축해놨으면 에러레벨의 로그가 생기면 알림을 보내주는 것도 좋은 다음 단계일 것 같다.

3. 로그에 어떤 내용을 담을까..?

이제 회사에서 로그를 보면서 느낀점은 어떤 로그를 봐도 정확히 어떤놈의 문제인지가 정확히 파악되지 않는 경우가 꽤 있었다. 아마 로그를 작성을 할때 별 생각없이 개발자가 그걸 개발하고 있을 때는 바로바로 알 수 있으니까 대충 로그를 적었을 수 있다(물론 그게 나일 가능성이 높다). 

예를 들어 우리 회사의 서비스는 회사와 회사간의 문서 전송을 돕는 서비스이다. 그러면 문서 ID라는게 존재하고 특정 문서가 서비스 시나리오대로 흘러가다가 에러가 생길 수 있다. 이때 로그를 봤을 때 당연히 어떤 문서의 시나리오 흐름중에 로그가 발생한건지를 알 수 있게 문서 ID는 로그내용에 포함이 되어야한다.

반면 문서 전송을 제외하고 다른 성격의 시나리오가 있을 수도 있다. 그러한 시나리오에는 문서 ID라는 값이 없고 또 다른 무언가가 있을 수 있다.

여기서 도출되는 것이 로그에 어떤 내용이 담겨야 할지는 서비스의 시나리오 성격마다 다르다는 것이다.

그러면 나는 여기서 드는 생각이 우리 서비스에는 어떠어떠한 시나리오들이 있는지를 구분을 좀 해봐야한다는 생각이 들었다. 혹시 그러한 문서가 있나? 생각을 해봤는데 우리 회사는 문서가 굉장히 잘 안되어있고 개발자 간의 정보공유는 등한시 하는 경향이 있다. 그래서 우리 서비스의 시나리오 정의서? 같은 문서를 한개를 만들어야하겠다는 생각이 들었다.

 

먼저 우리 서비스에 대한 문서를 한개를 만들어보고 로그에 어떤 내용을 담을지는 그 이후에 정리를 해보자

---

우리 회사의 서비스를 개선하기 위한 뭔가 첫발을 내딛었다. 로깅 전략을 세워보려고 했는데 결국 우리 서비스에 대한 어떤 정의서같은 문서가 필요하단 것을 느끼게 된게 신기하다. 어떤 프로젝트의 뼈대가 되는 문서라는게 있어야된단걸 명확하게 느낀다.. 여기는 그런게 좀 부족하다..