
리눅스 서버에서 장애를 확인할 때 로그 파일을 열어보는 경우가 많습니다.
그런데 초보일수록 로그를 보자마자 cat으로 전체를 열거나, 큰 로그 파일을 처음부터 끝까지 보려고 하는 경우가 있습니다.
저도 처음에는 그렇게 했는데, 실제로는 로그 전체를 다 보는 것보다 최근 로그 몇 줄만 먼저 확인하는 편이 훨씬 빠르고 안전했습니다.
이럴 때 가장 먼저 쓰기 좋은 명령어가 tail -n입니다.
로그를 볼 때 전체부터 열지 않는 이유
장애 상황에서는 시간이 중요합니다.
로그 파일이 크면 클수록 전체를 다 열어보는 건 비효율적입니다.
특히 애플리케이션 로그나 웹 서버 로그는 몇 MB가 아니라 몇백 MB, 몇 GB까지 커지는 경우도 있어서 무턱대고 전체를 보면 필요한 내용을 놓치기 쉽습니다.
실무에서는 보통 이렇게 생각하면 편합니다.
- 지금 막 발생한 오류를 보고 싶다
- 최근 배포 직후 찍힌 로그를 보고 싶다
- 방금 테스트 요청 보낸 뒤 로그 반응을 보고 싶다
이럴 때는 최근 몇 줄만 먼저 확인하는 게 맞습니다.
tail -n 기본 사용법
가장 기본 형태는 아래와 같습니다.
tail -n 100 /var/log/messages
이 명령어는 해당 로그 파일의 마지막 100줄을 보여줍니다.
예를 들어 애플리케이션 로그라면 이렇게 볼 수 있습니다.
tail -n 50 /app/logs/service.log
tail -n 100 /app/logs/service.log
tail -n 200 /app/logs/service.log
보통은 50줄, 100줄, 200줄 정도부터 시작하면 충분합니다.
에러가 짧게 반복되는 로그라면 50줄만 봐도 되고, 스택트레이스가 길다면 100~200줄 정도가 더 편합니다.
언제 몇 줄을 보면 좋을까
저는 보통 아래처럼 나눠서 봅니다.
1) 가장 최근 반응만 빨리 보고 싶을 때
tail -n 20 service.log
아주 최근 상태만 빠르게 보는 용도입니다.
서비스가 살아 있는지, 마지막 줄에 에러가 찍혔는지 정도만 볼 때 유용합니다.
2) 장애 직전 흐름을 조금 더 보고 싶을 때
tail -n 100 service.log
가장 많이 쓰는 형태입니다.
직전 요청, WARN, ERROR, 재시작 흔적 등을 같이 보기 좋습니다.
3) 에러 메시지가 길게 찍혔을 때
tail -n 200 service.log
자바 예외처럼 로그가 길게 찍히는 경우에는 50줄만 보면 중간이 잘릴 수 있습니다.
이럴 때는 조금 넉넉하게 200줄 정도 보는 편이 낫습니다.
실제로는 이렇게 확인하면 편했다
예를 들어 사용자가 “방금 접속이 안 됐다”고 했다고 해보겠습니다.
그럴 때 저는 아래 순서로 봅니다.
tail -n 100 /app/logs/service.log
여기서 최근 에러 메시지가 보이면
- DB 연결 에러인지
- 포트 바인딩 실패인지
- 메모리 부족인지
- 애플리케이션 예외인지
대략 방향이 잡힙니다.
그리고 방금 보낸 요청과 함께 실시간으로 확인해야 하면 그때는 tail -f로 넘어갑니다.
즉 정리하면 이렇습니다.
- 처음 확인: tail -n
- 실시간 추적: tail -f
이 순서가 초보자 입장에서도 훨씬 덜 헷갈립니다.
초보자가 놓치기 쉬운 부분
1) 숫자를 너무 크게 주지 않기
tail -n 5000 service.log
이렇게 너무 크게 잡으면 결국 최근 로그만 본다는 장점이 줄어듭니다.
처음에는 50~200 정도로 시작하는 게 좋습니다.
2) 로그 파일 경로를 먼저 확인하기
파일 경로를 잘못 잡으면 엉뚱한 로그를 보게 됩니다.
특히 비슷한 이름의 로그가 여러 개 있을 때는 현재 서비스가 실제로 어떤 파일에 기록 중인지 먼저 확인하는 게 좋습니다.
3) 최근 로그만 보고 바로 결론 내리지 않기
최근 몇 줄은 방향을 잡는 데는 좋지만, 원인을 확정하는 데는 부족할 수 있습니다.
최근 로그에서 이상 징후를 발견한 뒤에는
- 실시간 추적은 tail -f
- 큰 로그를 안전하게 훑어볼 때는 less
처럼 다음 단계로 넘어가면 됩니다.
운영 서버에서 주의할 점
운영 서버에서는 로그를 “보기만” 해야 할 때가 많습니다.
그래서 초보일수록 아래를 기억해두면 좋습니다.
- 먼저 읽기 전용 성격의 명령어부터 쓴다
- 전체 파일을 무리하게 열지 않는다
- 필요한 범위만 확인한다
- 로그를 지우거나 옮기는 작업은 원인 파악 후에 한다
로그를 본다는 이유로 성급하게 파일을 건드리면 장애 원인을 놓칠 수 있습니다.
리눅스 서버에서 로그를 확인할 때는 처음부터 전체를 열기보다
tail -n으로 최근 로그 몇 줄만 먼저 확인하는 습관이 훨씬 실용적입니다.
특히 장애가 났을 때는 아래 정도만 빠르게 확인해도 다음 판단이 쉬워집니다.
- 최근 에러가 있는지
- 방금 보낸 요청 흔적이 있는지
- 재기동 직후 이상 로그가 찍혔는지
저도 예전에는 로그를 크게 열어놓고 헤맸는데,
요즘은 일단 tail -n 100부터 보는 쪽으로 많이 굳었습니다.
초보 운영자라면 이 습관 하나만 잡아도 로그 확인 속도가 꽤 빨라질 겁니다.
다만 로그를 볼 때는 한 번에 다 보려고 하기보다, 상황에 맞게 도구를 나누는 것이 좋습니다.
최근 로그 몇 줄만 빠르게 볼 때는 tail -n을 사용하고, 새로 들어오는 로그를 실시간으로 따라가야 할 때는 tail -f를 사용하면 좋습니다.
큰 로그 파일을 처음부터 끝까지 무리하게 열기보다, 필요한 범위부터 작게 확인하는 습관이 운영 서버에서는 훨씬 안전합니다.
실시간으로 로그가 새로 찍히는지 확인하는 tail -f 사용법은 아래 글에서 이어서 볼 수 있습니다.
https://opsnote.tistory.com/21
tail과 less를 상황에 따라 어떻게 나눠서 쓰면 좋은지는 아래 글에서 정리했습니다.
https://opsnote.tistory.com/20
로그 파일이 계속 커질 때 바로 비우지 않고 확인하는 순서는 아래 글에서 함께 보면 좋습니다.
https://opsnote.tistory.com/7
'리눅스' 카테고리의 다른 글
| 리눅스 서버 로그에서 에러 찾을 때 grep만 믿지 말고 앞뒤 흐름까지 확인하는 법 (0) | 2026.05.26 |
|---|---|
| 리눅스 서버 큰 로그 파일 vi로 열지 말고 less로 안전하게 보는 법 (0) | 2026.05.25 |
| 리눅스 서버 장애 났을 때 tail -f로 실시간 로그 확인하는 법 (0) | 2026.05.24 |
| 리눅스 서버 로그 확인할 때 cat부터 치지 말고 tail과 less로 안전하게 보는 법 (0) | 2026.05.21 |
| 리눅스 서버 재기동 전 바로 껐다 켜지 말고 확인해야 할 체크리스트 (0) | 2026.05.20 |