서버 로그에서 먼저 찾아야 할 패턴들

서버에서 뭔가 이상할 때 로그를 펼치면 수백 줄이 쏟아진다. 전부 읽을 수는 없으니 어떤 키워드로 필터링할지 미리 알아두는 게 중요하다.

에러 레벨 키워드부터

sudo journalctl -n 200 | grep -iE 'error|fatal|exception|oom|killed'

FATAL은 앱이 시작조차 못 했다는 뜻이다. OOM Killer가 보이면 메모리 부족으로 프로세스가 강제 종료된 것이다. uncaughtException이나 unhandledRejection은 Node.js 앱의 치명적 에러다. 이 키워드들이 나오면 그 전후 10줄을 같이 봐야 맥락이 잡힌다.

nginx 액세스 로그 상태 코드 분포

sudo awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

응답 코드별 빈도를 보면 전체 요청 중 500대 에러 비율을 바로 알 수 있다. 특정 시간대에 에러가 몰렸다면 그 시간대 배포 로그와 같이 본다.

배포 후 렌더링 결과 확인

Next.js 같은 SSR 앱은 배포 뒤에 실제 HTML이 제대로 나오는지 확인한다.

curl -s https://example.com | grep -Ei 'title|description|canonical|og:|twitter:'

meta 태그들이 예상한 값으로 나오는지 보는 빠른 방법이다. 빌드 에러 없이 배포됐어도 SSR이 제대로 동작하지 않으면 빈 태그가 나올 수 있다.

빌드 에러는 빌드 로그에서

런타임 에러가 아니라 빌드 에러라면 서버 로그에는 아무것도 안 나온다. 빌드 단계가 성공했는지 별도로 확인해야 한다.

npm run build 2>&1 | grep -E 'Error|Warning|error TS'

sitemap과 RSS 응답 확인

curl -s https://example.com/sitemap.xml | head -20

배포 후에 sitemap이 새 콘텐츠를 포함하는지, RSS 피드가 정상 응답하는지 확인하면 콘텐츠 전달까지 온전한지 알 수 있다. 200이 아닌 응답이 오거나 XML 파싱 에러가 보이면 앱 라우팅이나 빌드 결과에 문제가 있는 것이다.