리눅스

리눅스 서버 로그 확인할 때 전체 열지 말고 tail -n으로 최근만 보는 법

opsnote 2026. 5. 25. 13:37

리눅스 서버 로그 확인 시 tail -n으로 최근 로그만 보는 방법을 설명하는 opsnote 대표 이미지

 

리눅스 서버에서 장애를 확인할 때 로그 파일을 열어보는 경우가 많습니다.
그런데 초보일수록 로그를 보자마자 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