로그 설계 관점 > IT이야기

로깅을 단순히 오류 추적용으로만 생각하면 로그가 금세 쓰레기통 된다. 검증이 필요해보여요 코드 내에서 어떤 이벤트가 의미 있는 기록인지, 나중에 어떻게 분석할 건지를 기준으로 설계해야 관리가 산다. 로그 수준을 info, warn, error 정도로 단순히 나누는 것도 좋지만, 그 사용 목적이 명확해야 한다. 운영 중 문제를 추적하려면 로그 구조가 일관되고, 파서에 맞게 포맷을 설계해야 한다. 특히 JSON 기반 로그는 나중에 검색과 집계에 유리하다. 단, 불필요한 필드를 남발하면 성능 저하나 저장 비용이 커진다. 핵심은 '나중에 쓸 로그만 남긴다'는 원칙이다. 마지막으로 로그는 코드 품질 지표로도 볼 수 있다. 불필요한 로그가 많으면 코드 설계가 덜 다듬어진 경우가 많더라. 결국 좋은 로그는 좋은 코드 구조에서 나온다. 이건 팀의 성숙도와도 직결된다....

좋아요5 이 글을 좋아요하셨습니다