로그
로그는 프로그램에서 발생하는 이벤트에 대한 기록입니다. 클라이언트에서 할 수 있는 어떤 행동들이나, 상태가 변하였을 때 "디버깅"이나, "상태 관리"를 위하여 로그를 관리합니다.
어느 한 게임에서 유저가 게임 아이템을 샀는데 서버가 날라갔다면 유저는 게임 아이템을 샀다는 것을 어떻게 증명할 수 있을까요? 회사는 유저에게 보답을 해줄 수 있을까요? 로그가 없다면 힘듭니다.
우리는 모든 이벤트에서 로그를 찍을 수 있게 해 놓았다면 시간의 흐름에 따라서 원하는 것을 하고자 하기 편합니다.
로그에는 어떤것이 담겨있어야 할까요?
로그는 위에서 언급했듯이 "상태 관리"를 담아야 합니다. 그러다보니 시간 순이 중요해졌습니다. 위와 같은 상황을 방지하기 위해서도 날짜
와 시간
은 담기는게 좋습니다.
"상태 관리"이기 때문에 어떤 데이터가 변했을 때도 변하는 시점
과 어떤식으로 변했는지
남기는게 좋습니다.
"일정한 포맷"을 정해 놓아야 디버깅하기 훨씬 수월합니다. 각자의 일정한 포맷을 만들어 보는 것을 추천합니다.
로그의 중요도
로그의 중요도는 있으면 좋습니다. 에러를 발견하고 디버깅 하기 위해서 모든 로그를 읽을 때는 시간이 오래걸립니다.
그래서 로그의 중요도를 단계별로 나타내면 좋습니다. 해당 부문은 42서울 블로그에서 가져왔습니다.
보통 로그를 남길때 로그의 중요도에 따라 레벨을 부여한다.
- TRACE > DEBUG > INFO > WARN > ERROR > FATAL
TRACE
- 디버그 레벨이 너무 광범위한 것을 해결하기 위해서 좀 더 상세한 이벤트를 보여주기 위해 사용한다.
DEBUG
- 개발시 디버그하는 용도로 사용한다.
- 배포환경에서 INFO레벨로 올려서 사용하기도 한다.
INFO
- 상태 변경과 같은 정보성 메시지를 나타낸다.
- ERROR와 반대로 명확한 의도가 있는 로그들이 모두 INFO 레벨로 판단하자
- 예를 들어 서비스 동작에 관한 예로 사용자의 상태(등록, 휴면, 해지)를 얻는 API가 있는 경우 사용자 서비스의 findById 만으로 구현을 한다면 다음과 같다.
function action() {
const user = userService.findById(userId)
log.info("User is ${user.status} status (userId: $userId)")
return user.status
} catch (e) {
log.info("User is not exist (userId: $userId)")
return UserStatus.NOT_REGISTERED
}
WARN
- 프로그램의 실행에는 문제가 없지만, 향후 시스템 에러의 원인이 될 수 있는 경고성 메시지를 나타낸다.
- ex) 서버에 가해지는 부하가 한계값에 근접했을 때
ERROR
- 명확한 에러인 경우 남기자
- 서비스에 치명적이므로 나에게 알릴 수단이 필요하다 (ex. 슬랙)
FATAL
- 아주 심각한 에러가 발생한 상태를 나타낸다.
좋은 로그가 따로 있나요?
각자의 나름 기준이 있을 테지만 공통적으로 나타내는 부분들이 있습니다.
- 필요한 정보가 있으며
- 의미가 명확하며
- 편리하게 데이터를 얻을 수 있게끔
만드는 로그들이 좋은 로그라고 부를 수 있습니다.
로그를 찍었을 때 이제 겪는 문제들이 있을텐데, 필요한 정보가 없을 때가 있습니다. 왜 이 이벤트에는 넣었는데 저 이벤트에는 넣지 않았지? 라는 생각을 할 수도 있습니다. 어떨 때는 의미를 파악하기 어렵고 데이터가 어떤 것인지 몰라 오히려 생산성을 떨어뜨리는 경우도 있을 것입니다.
정말 간단한 3개의 특징이지만, 지키기 정말 어려운 규칙들이라고 생각합니다.
그래서 저는 간단하게라도 로그의 목표
를 설정하면 좋을 것이라고 생각합니다.
데이터베이스에서 ERD를 정의할 때 객체와 서비스의 관계를 생각해보듯이, 목표가 있는 로그를 정의하는게 좋다고 생각합니다. 하나의 로그에서도 다양한 각도에서 고민이 있으면 좋을 것 같습니다.
예로, 42서울 체크인 코드에서 "방문 기록"에 대한 로그를 검사합니다. 저는 방문기록에서도 여러 목적을 가질 수 있다고 생각합니다.
- 한 사람이 얼마나 많이 클러스터에 있었는지
- 해당 시간에 클러스터에 있던 사람은 누구인지
등 여러 목적을 가질 수 있으며, 이런 필터링에 대한 고민도 해보면 좋을 것 같습니다.
점점 나아가서는 일관성 있게 로그의 품질을 올려 믿을 수 있는 로그를 만들어야, 좋은 로그라고 하지 않을까 싶습니다.