server) 호랑이는 죽어서 가죽을 남기고, 개발자는 죽어서 로그를 남긴다.

 

호사유피, 개사유로

Feature

로그는 뭐지?

일지, 기록, 기록하다
- 네이버 사전

① ‘로그’(Log)는 컴퓨터나 서버(Server) 등에서 유저(User)의 플레이 정보를 시간에 따라 남기는 기록을 뜻한다. 
- 네이버 게임 용어 사전

로그란 언제 어떤 유저가 어떤 행동을 했는가 남기는게 로그다. console.log( ... )도 로그라 할 수 있다. 어찌되었든 서버가 어떤 행위를 기록하는 것이기 때문이다. 흔히들 우리가 말하는 '로그 찍어봐'는 디버깅 성향이 강한 로그에 해당한다. 

 

로그가 왜 필요할까?

1. 오류를 추적하는데 큰 도움을 준다.
2. 통계용 데이터로 활용할 수 있다.
3. 디버깅용으로 활용할 수 있다.
4. 간단하게 데이터를 저장할 수 있다.

로그는 어떤 개발이든 정말 중요한 데이터이다. 생각하고 싶지도 않지만 특히 로그는 예기치 않게 서버가 죽었을 땐, 동앗줄 같은 존재이다. 오류는 아무튼 발생한다. 그리고 슬프게도 발생하기 전엔 도대체 오류가 언제, 왜 나타나는지 그 누구도 알 수 없다... 오류가 발생하면 우린 수습을 해야하는데, 이때 로그는 어떤 오류가 발생했는지는 물론, 왜 발생했는지 오류를 파악하게 해주는 이정표인 셈이다. 

서버 급 다운 → db 로그를 살펴본다. → error 섹션 먼저 확인한다 → 메모리 오버 확인 (원인 파악) → 서버 스펙을 늘린다

오류 문의 접수 → 사용자가 문의한 시간대, 아이디 확인 → 로그인 히스토리 확인 → 세션을 추적해 오류 로그를 확인한다

오류추적 이외에도 로그는 다양하게 쓰인다. 유저의 행동을 추적해 통계용 데이터를 만들어 내거나, 개발할 때 디버깅용으로 사용하기도 한다. 또, db에 저장하긴 거시기하지만 저장하면 좋은 데이터들도 로그로 남기곤 한다. 

 

로그는 언제 필요할까?

로그가 왜 필요한지 알았으니, 한번 로그 파일을 남겨보자. 그럼 로그는 언제 남기면 좋을까? 나는 처음에 try-catch로 잡힐때 남기면 장땡이라고 생각했다. 때문에 별다른 액션은 상관하지 않고, response status code 500 에러가 발생할때만 로그파일을 생성하도록 해주었다. 이는 매-----우 위험한 방식이었다. (블로그에 쓰기도 부끄러움) 과연 500에서만 에러가 발생할까? 500으로 캐치가 안되고 급 죽었을땐? 운빨로 500으로 로그가 찍혔다고 해도 문제는 사라지지 않는다. 로그가 남기전 어떤 시나리오가 있었는지 체킹이 안되기 때문이다. 그러니 서버가 하는 행동을 거의다 기록한다고 생각하는게 좋다.

 

그렇담 서버는 어떤 행동을 할까 생각해보자. 계산, db 접근, 네트워킹 등등... 가장 중요한 액션은 바로 db query이다. 실제 서비스에 보여주거나 활용할 데이터가 있는 db에 액션을 가할땐 다 로그를 남긴다. 그래야 나중에 편하다. 워커를 생성하거나 사용할때에도 로그를 남기는게 좋다. 언제 늘어났고, 언제 사용했는지를 남기면 워커에서 생긴 오류인지 금방 확인 할 수 있을 것이다. 서버단에서 쉘 스크립트를 실행할 때에도 무조건, 무족권 로그를 남기자. 부모 try-catch단에서 error를 잡는건 말해뭐해 0순위이다.

 

access 로그를 남기는 것도 중요하다. 통계용으로도 사용될 수 도 있고, 언제 누가 왔다 갔는지 기록하는건 기본중에 기본이다. 이때 ip까지 기록하는게 좋다. 이 외에도 서비스 정책, 회사 회의 결과에 따라 로그의 범위는 무궁무진하게 커질수도 작아질 수 도 있다. 그러니 회의때 얼타지 말고 메모하자. 로그를 남길 케이스를 정리하고 보고해 피드백을 받자. 쪼렙의 자세를 잊지 말자... (나한테 하는 말임)

 

정리하자면 다음과 같은 상황에 로그를 남긴다. (더 있을 수 있음...)

1. db query sql
2. 부모 try-catch 단에 error
3. login 또는 access
4. shell script history
5. else action history

 

로그는 무엇을 어떻게 모을까?

로그의 정의에서 나왔듯이 [언제 어떤 유저가 어떤 행동을 했는가] 즉, 로그는 세 가지 데이터를 꼭 저장해야 의미있는 데이터이다.

1. datetime
2. who
3. action
4. +⍺ environment (플랫폼, 기기명, os 등등)

datetime 언제

datetime은 말 그대로, date(날짜)와 time(시간)을 함께 남기면 된다. 대부분의 라이브러리들이 기본적으로 지원한다.

 

who 누가 요청을 해서 액션을 취한 것인가

누가 요청을 한지 알기 위해선 각각의 request에 아이디를 부여해야한다. 마냥 랜덤이 아니라, 어떤 사람이 어떤 행동을 했는지 로드맵이 쭉 그려지도록, 추적이 가능하도록 해야한다. 보통 웹 서비스의 경우 로그인 아이디를 말머리에 남기거나, 세션 아이디를 남기기도 한다. 방법은 아래 블로그를 참고하자🤓

참고 CLS - Node.js 애플리케이션에서 Request ID 추적하기

테스트용 로그임

 

action 어떤 행동을 했는가

action은 말그대로 서버가 한 액션을 남기면 된다. 위 테스트용 로그 사진과 같이 sql을 남기거나, error 내용 또는 'try to access blah blah...'를 남길 수 있다. 아니면 후에 가공할 수 있도록 특정 규칙에 맞게 string을 남기거나. 아무튼 핵심 내용을 담으면 된다.

 

쁘라스 알파

4번 쁘라스 알파는 사내 규정을 따르자. 나같은 경우 로그가 너무 길어지는걸 방지하기 위해 서버단의 에러는 환경 정보를 저장하지 않고 있다. 환경 정보를 저장하는 경우는 프론트에서 버그 리포트를 보낼때 저장할 예정이다. 예를 들어 사내 프론트 라이브러리에서 오류가 발생할 땐, 사용자 아이디와 기기 정보, 환경 정보 등을 같이 넘겨준다던가, 버전 오류가 나 프레임워크를 실행하지 못 할 때 등등이 있다. (생각해 보니 단순 정보뿐만 아니라 버전 정보도 함께 다 체킹해야겠다. 나중에 서비스 스펙업할 때에도 좋은 자료가 될 듯)

 

나의  삽질 이야기

로그는 정말 중요하다. 앞서 말했든 오류는 예방도 중요하지만 수습을 얼만큼 빨리할 수 있느냐가 눈에 보이는 작업이기 때문에 로그는 정말 쩌어엉말 중요하다. 

 

나에겐 잊을 수 없는 기억이 있다. 입사한지 반년도 안되었을때 이야기이다. 회사 서비스의 래퍼런스용 프로젝트였는데, 나는 db설계와 서버, 배포를 담당했다. 기능 구현도 잘 되고, 팀원들끼리 qa했을땐 분명 문제없이 잘 돌아갔기 때문에 한시름 놓고 있었다. 또, 로그도 나름 morgan사용해 붙였으니 된거 아닌가?라는 위험한 생각을 했었다.

 

아니나 다를까 문제는 역시 qa때 안나오고 중요할 때 나왔다. (제발 qa때 나와달라구 ㅠㅠ) 외부 미팅에서 해당 프로젝트를 시연하던 도중 서버가 나가버린 것이다... 당시에 난 휴가중이라 바로 확인하지 못 했고, 저녁이 되어서야 '망했다'를 느꼈다. 회사 메신저로 장문의 사과 메시지를 남기고 어떻게든 수습하려 급급했던 그때 심정은...😨 로그를 찾고 찾아도 별다른 문제가 없었다. 웹서버 로그를 찾아도 별 문제 없이 돌아갔다. 위에 썼듯이 500에러만 잡는 엉성한 로그였기 때문에 로그 파일을 남겨도 말짱 도루묵인 것... 뭐야 뭐야 멘붕상태 빠져, 로컬에 다시 서버를 띄워 한참을 이것저것해서야 오류 원인을 발견했다.

 

감사하게도 상사분들과 대표님께서 신입인 나의 잘못을 너그럽게 받아주셔서 큰 문제없이 넘어갔지만, 개인적으로 팀원분과 대표님께 죄송스러웠다. 불행중 다행으로 아-주 중요한 미팅이 아니라 다행이었지, 투자사 미팅이었다면 정말... 아찔하다. 

 

실수를 계기로 더 발전하면 되는거니까... 멘붕상태에서도 로그와 로컬 서버를 돌리며 찾아낸 내 경험을 바탕으로 다음엔 안 그러면 된다. 이런 바보짓을 되풀이 하지말자는 마음으로 블로그에 정리해보았다.

 

아무튼 로그는 중요하다.

끝!