리눅스 서버 로그 확인할 때 cat부터 치지 말고 tail과 less로 안전하게 보는 법

리눅스 서버에서 큰 로그 파일을 cat으로 열지 않고 tail과 less 명령어로 최근 로그와 에러 로그를 안전하게 확인하는 방법을 설명하는 대표 이미지

 

리눅스 서버에서 장애가 나거나 서비스가 이상할 때 가장 많이 확인하는 것 중 하나가 로그입니다. 그런데 초보 운영자일 때는 로그 파일을 확인하려고 바로 cat 명령어를 실행하는 경우가 있습니다.

작은 파일이라면 괜찮습니다. 하지만 운영 서버의 로그 파일은 수십 MB, 수백 MB, 많으면 GB 단위로 커져 있는 경우도 있습니다. 이런 파일을 무심코 cat으로 열면 터미널에 로그가 한꺼번에 쏟아지고, 필요한 내용을 찾기도 어려워집니다.

이번 글에서는 리눅스 서버에서 로그를 확인할 때 cat부터 치지 않고, tail과 less로 최근 로그와 큰 로그 파일을 안전하게 확인하는 방법을 정리합니다.

로그 볼 때 cat부터 치면 불편한 이유

cat은 파일 내용을 한 번에 출력하는 명령어입니다.

 

cat /var/log/messages

 

파일이 짧으면 괜찮습니다. 하지만 로그 파일이 크면 문제가 됩니다.

예를 들어 로그가 몇십만 줄이라면 cat을 실행하는 순간 터미널에 내용이 계속 쏟아집니다. 그러면 필요한 에러 위치를 찾기도 어렵고, 터미널 화면도 금방 로그로 가득 찹니다.

운영 서버에서는 아래 문제가 생길 수 있습니다.

- 필요한 에러 위치를 찾기 어려움
- 터미널 화면이 로그로 가득 참
- 파일이 크면 출력이 오래 걸림
- 복사하거나 확인하기 불편함
- 실수로 민감한 로그를 그대로 노출할 수 있음

 

그래서 운영 서버에서는 로그 전체를 한 번에 보는 것보다, 최근 로그부터 조금씩 확인하는 것이 안전합니다.

가상의 운영 상황 예시

예를 들어 웹 서비스에서 500 오류가 발생했다고 가정해보겠습니다.

[상황]
- 사용자 화면에서 500 오류 발생
- 애플리케이션 로그 확인 필요
- 로그 파일 크기 1.8GB
- 장애 발생 시각은 14:20 전후로 추정

 

이 상황에서 바로 아래처럼 실행하면 불편합니다.

 

cat /app/logs/service.log

 

로그가 너무 크면 화면에 내용이 계속 쏟아지고, 정작 장애 시각 근처의 에러를 찾기 어렵습니다.

이럴 때는 먼저 파일 크기를 확인하고, 최근 로그를 tail로 본 뒤, 필요하면 less로 검색하는 흐름이 좋습니다.

1단계. 로그 파일 크기부터 확인하기

로그를 열기 전에 파일 크기를 먼저 확인하면 좋습니다.

 

ls -lh /app/logs/service.log

 

예시입니다.

-rw-r--r-- 1 app app 1.8G May 21 10:20 service.log

 

이렇게 1.8GB짜리 로그라면 cat으로 여는 것은 피하는 게 좋습니다.

큰 로그 파일은 아래처럼 확인하는 편이 안전합니다.

 

tail -n 100 /app/logs/service.log

 

또는 위아래로 이동하면서 봐야 한다면 less를 사용합니다.

 

less /app/logs/service.log

 

운영 서버에서는 파일 크기를 보고 명령어를 선택하는 습관이 중요합니다.

2단계. 최근 로그만 볼 때는 tail 사용하기

최근 로그를 확인할 때는 tail을 사용합니다.

 

tail /var/log/messages

 

기본적으로 tail은 파일의 마지막 부분을 보여줍니다. 로그는 보통 아래로 계속 쌓이기 때문에, 최근 상황을 확인할 때 유용합니다.

최근 100줄만 보고 싶다면 이렇게 씁니다.

 

tail -n 100 /var/log/messages

 

애플리케이션 로그라면 예를 들어 이렇게 볼 수 있습니다.

 

tail -n 100 /app/logs/service.log

 

실무에서는 기본 tail보다 tail -n 100처럼 줄 수를 지정해서 보는 경우가 많습니다.

최근 50줄만 보기  → tail -n 50 로그파일
최근 100줄만 보기 → tail -n 100 로그파일
최근 300줄만 보기 → tail -n 300 로그파일

 

처음부터 너무 많이 보기보다, 최근 100줄 정도부터 확인하는 것이 좋습니다.

3단계. 서비스 테스트 중에는 tail -f 사용하기

서비스를 재기동하거나 테스트 요청을 보내면서 로그가 새로 찍히는지 보고 싶을 때가 있습니다.

그럴 때는 tail -f를 사용합니다.

 

tail -f /app/logs/service.log

 

tail -f는 로그 파일 끝부분을 보여주고, 새로운 로그가 추가되면 계속 이어서 보여줍니다.

예를 들어 서비스 재기동 후 로그를 보고 싶다면 한 터미널에서 아래 명령어를 실행합니다.

 

tail -f /app/logs/service.log

 

그리고 다른 터미널에서 테스트 요청을 보냅니다.

 

curl http://localhost:8080

 

그러면 요청 시점에 로그가 새로 찍히는지 확인할 수 있습니다.

다만 tail -f는 계속 실행되는 명령어입니다. 종료하려면 아래 키를 누르면 됩니다.

Ctrl + C

 

초보 운영자일 때 tail -f를 켜놓고 종료 방법을 몰라 당황할 수 있는데, Ctrl + C로 빠져나오면 됩니다.

4단계. 로그 파일이 교체될 수 있으면 tail -F도 알아두기

운영 서버에서는 로그 파일이 logrotate에 의해 교체될 수 있습니다.

이때 tail -f는 기존 파일을 계속 보고 있을 수 있습니다. 로그 파일이 교체된 뒤에도 같은 파일명 기준으로 계속 따라가고 싶다면 tail -F를 사용할 수 있습니다.

 

tail -F /app/logs/service.log

 

간단히 구분하면 이렇습니다.

tail -f → 현재 열고 있는 파일을 계속 따라감
tail -F → 파일이 교체되어도 같은 파일명 기준으로 다시 따라감

 

로그 로테이션이 있는 환경에서는 tail -F가 더 편할 때가 있습니다.

로그 파일이 계속 커지거나 로테이션이 제대로 되는지 확인해야 한다면 아래 글도 함께 보면 좋습니다.

https://opsnote.tistory.com/7

리눅스 서버 로그 파일이 계속 커질 때 바로 비우지 말고 확인하는 법

 

5단계. 큰 로그 파일은 less로 열기

로그 파일이 큰데 위아래로 이동하면서 보고 싶을 때는 less를 사용합니다.

 

less /app/logs/service.log

 

less는 파일 전체를 터미널에 한 번에 뿌리는 방식이 아니라, 화면 단위로 넘겨보는 방식입니다. 그래서 큰 로그 파일을 볼 때 cat보다 훨씬 편합니다.

less 안에서 자주 쓰는 키는 이 정도만 알아도 됩니다.

Space       다음 화면으로 이동
b           이전 화면으로 이동
위/아래 방향키  한 줄씩 이동
/검색어      검색
n           다음 검색 결과
N           이전 검색 결과
G           파일 맨 아래로 이동
g           파일 맨 위로 이동
q           종료

 

예를 들어 로그 안에서 ERROR를 찾고 싶다면 less로 파일을 연 뒤 아래처럼 입력합니다.

/ERROR

 

그다음 n을 누르면 다음 ERROR 위치로 이동합니다.

종료는 q입니다.

처음 less를 쓰면 종료를 몰라서 당황할 수 있는데, q만 기억하면 됩니다.

6단계. tail과 less는 언제 다르게 쓸까?

처음에는 tail과 less가 헷갈릴 수 있습니다.

간단히 나누면 이렇게 보면 됩니다.

최근 로그만 빠르게 보고 싶다
→ tail -n 100

새로 찍히는 로그를 실시간으로 보고 싶다
→ tail -f 또는 tail -F

큰 로그 파일을 위아래로 이동하면서 보고 싶다
→ less

로그 안에서 검색하면서 보고 싶다
→ less에서 /검색어

 

예를 들어 장애가 방금 발생했다면 먼저 이렇게 봅니다.

 

tail -n 100 /app/logs/service.log

 

서비스 재기동 후 로그가 새로 찍히는지 보고 싶다면 아래처럼 봅니다.

 

tail -f /app/logs/service.log

 

지난 로그를 위아래로 보면서 원인을 찾고 싶다면 아래처럼 봅니다.

 

less /app/logs/service.log

 

상황에 따라 나눠 쓰면 로그 확인이 훨씬 편해집니다.

 

서버를 재기동하기 전에는 로그뿐 아니라 CPU, 메모리, 디스크, 포트, 자동 기동 설정도 함께 확인하는 것이 좋습니다. 재기동 전 기본 체크리스트는 아래 글에서 따로 정리했습니다.

https://opsnote.tistory.com/19

리눅스 서버 재기동 전 바로 껐다 켜지 말고 확인해야 할 체크리스트

 

7단계. 로그 파일 위치 확인하기

로그 파일 위치는 서버마다 다를 수 있습니다.

자주 보는 위치는 아래와 같습니다.

/var/log/
/app/logs/
/home/app/logs/
/data/logs/
/usr/local/tomcat/logs/

 

OS 로그는 보통 /var/log 아래에 많습니다.

 

ls -lh /var/log

 

애플리케이션 로그는 서비스 구성에 따라 다릅니다.

예를 들어 Tomcat이라면 아래 같은 경로를 볼 수 있습니다.

 

ls -lh /usr/local/tomcat/logs/

 

서비스별 로그 위치는 정해진 답이 없습니다.

운영 환경마다 다르기 때문에, 먼저 서비스 실행 경로나 설정 파일에서 로그 위치를 확인하는 것이 좋습니다.

8단계. 에러 로그만 찾고 싶을 때는 grep과 함께 보기

로그 전체가 너무 길면 grep과 함께 사용할 수 있습니다.

 

grep -i "error" /app/logs/service.log

 

최근 로그 중에서만 에러를 보고 싶다면 이렇게 볼 수 있습니다.

 

tail -n 300 /app/logs/service.log | grep -i "error"

 

error, exception, fail, timeout 같은 키워드를 같이 볼 수도 있습니다.

 

tail -n 500 /app/logs/service.log | grep -i -E "error|exception|fail|timeout"

 

다만 에러 한 줄만 보고 바로 원인을 단정하면 안 됩니다.

에러는 앞뒤 흐름이 중요할 때가 많습니다. 그래서 필요한 경우에는 에러 앞뒤 로그도 같이 봐야 합니다.

 

grep -i -C 3 "error" /app/logs/service.log

 

이 명령어는 error가 포함된 줄의 앞뒤 3줄을 같이 보여줍니다.

9단계. 로그에서 민감 정보는 조심하기

운영 로그에는 민감한 정보가 포함될 수 있습니다.

예를 들어 아래 정보가 들어 있을 수 있습니다.

- 실제 IP
- 내부 도메인
- 계정명
- 토큰
- 세션값
- 고객사명
- 파일 경로
- 요청 파라미터

 

로그를 외부에 공유할 때는 반드시 필요한 부분만 발췌하고, 민감한 정보는 가려야 합니다.

예시처럼 바꾸는 것이 좋습니다.

실제 IP: 203.0.113.10
내부 도메인: example.com
계정명: user01
토큰: [MASKED]

 

로그는 장애 분석 자료이지만, 그대로 공유하면 보안 문제가 될 수 있습니다.

10단계. 로그 확인할 때 초보자가 자주 하는 실수

로그를 볼 때 초보 운영자가 자주 하는 실수는 몇 가지가 있습니다.

- 큰 로그 파일을 cat으로 바로 열기
- tail -f를 켜놓고 종료 방법을 모름
- 로그 파일 경로를 모르는데 무작정 찾기
- 에러 한 줄만 보고 원인을 단정하기
- 실제 로그 원문을 그대로 외부에 공유하기
- 로그 크기를 확인하지 않고 전체 파일을 열기
- 장애 시각과 상관없는 오래된 로그만 확인하기

 

특히 에러 한 줄만 보고 바로 결론을 내리는 건 조심해야 합니다.

운영 로그는 앞뒤 흐름과 발생 시각이 중요합니다. 장애 발생 시각, 반복 여부, 같은 요청에서 발생한 흐름을 같이 봐야 합니다.

11단계. 장애 상황에서 로그 확인 순서

초보 운영자 기준으로는 아래 순서가 가장 무난합니다.

1. 로그 파일 위치 확인
2. 파일 크기 확인
3. 최근 로그부터 확인
4. 필요하면 실시간 로그 확인
5. 에러 키워드 검색
6. 에러 앞뒤 흐름 확인
7. 민감 정보 가리고 공유

 

명령어로 정리하면 아래처럼 볼 수 있습니다.

 

ls -lh /app/logs/service.log
tail -n 100 /app/logs/service.log
tail -f /app/logs/service.log
less /app/logs/service.log
tail -n 500 /app/logs/service.log | grep -i -E "error|exception|fail|timeout"
grep -i -C 3 "error" /app/logs/service.log

 

/var/log 아래 로그를 볼 때는 디스크 용량도 함께 확인하는 것이 좋습니다. /var는 로그, 캐시, 스풀, 서비스 데이터가 함께 쌓이는 경로라서 용량이 차면 서비스에도 영향을 줄 수 있습니다.

https://opsnote.tistory.com/68

리눅스 서버 /var 용량이 찼을 때 위험한 이유와 안전한 확인 순서

 

12단계. 실무 보고 예시

로그를 확인한 뒤에는 이렇게 정리할 수 있습니다.

서비스 장애 관련하여 애플리케이션 로그를 확인했습니다.
최근 100줄 기준 ERROR 로그가 반복적으로 확인되며, 발생 시각은 10:25경부터입니다.
현재 에러 앞뒤 로그를 추가 확인하여 특정 요청 또는 외부 연동 지연 여부를 확인 중입니다.

 

실시간 로그 확인 중이라면 이렇게 쓸 수 있습니다.

서비스 재기동 후 tail -f로 로그를 실시간 확인 중입니다.
현재 기동 로그는 정상적으로 출력되고 있으며, 추가 요청 시 ERROR 발생 여부를 확인하겠습니다.

 

로그에 민감 정보가 있을 때는 이렇게 정리하면 좋습니다.

로그 내 실제 IP와 내부 도메인이 포함되어 있어 외부 공유용 자료에서는 해당 정보를 마스킹 후 전달하겠습니다.

 

이렇게 쓰면 단순히 “로그 봤습니다”보다 훨씬 실무적으로 보입니다.

정리하면

리눅스 서버에서 로그를 볼 때는 무조건 cat부터 치지 않는 것이 좋습니다.

작은 파일은 괜찮지만, 운영 서버의 로그 파일은 큰 경우가 많습니다.

최근 로그를 볼 때는 아래 명령어를 사용합니다.

 

tail -n 100 로그파일

 

실시간 로그를 볼 때는 아래 명령어를 사용합니다.

 

tail -f 로그파일

 

큰 로그 파일을 이동하면서 볼 때는 아래 명령어를 사용합니다.

 

less 로그파일

 

에러만 찾고 싶을 때는 아래처럼 확인할 수 있습니다.

 

grep -i "error" 로그파일

 

초보 운영자라면 이 문장만 기억해도 좋습니다.

로그를 볼 때는 처음부터 전체 파일을 다 열어보려 하지 말고, 상황에 맞게 tail과 less를 나눠서 사용하는 것이 좋습니다.

최근 로그만 빠르게 확인할 때는 tail을 사용하고, 큰 로그 파일을 이동하면서 천천히 볼 때는 less를 사용하면 좋습니다. 

 
특정 에러만 찾고 싶다면 grep으로 키워드를 좁혀보는 것도 함께 필요합니다.

 

로그 확인도 결국은 같습니다.

확인 → 판단 → 조치

 

로그가 실시간으로 찍히는지 확인하고 싶다면 tail -f를 사용할 수 있습니다.

https://opsnote.tistory.com/21

리눅스 서버 장애 났을 때 tail -f로 실시간 로그 확인하는 법

 

로그가 많아서 필요한 줄만 찾고 싶다면 grep으로 먼저 좁혀보는 방법도 함께 보면 좋습니다.

https://opsnote.tistory.com/24

리눅스 서버 로그에서 에러 찾을 때 grep만 믿지 말고 앞뒤 흐름까지 확인하는 법

 

로그 파일이 계속 커질 때 바로 비우지 않고 확인하는 순서는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/7

리눅스 서버 로그 파일이 계속 커질 때 바로 비우지 말고 확인하는 법