리눅스 서버에서 서비스가 이상하거나 장애가 발생했을 때, 로그를 한 번만 보고 끝내기 어려운 경우가 있습니다. 서비스를 재기동했는데 정상적으로 올라오는지, 테스트 요청을 보냈을 때 로그가 새로 찍히는지, 에러가 반복되는지 실시간으로 확인해야 할 때가 있습니다.
이럴 때 자주 사용하는 명령어가 tail -f입니다.
tail -f는 로그 파일의 마지막 부분을 보여주면서, 새 로그가 추가되면 계속 이어서 보여주는 명령어입니다. 장애 대응 중에는 “이전에 에러가 있었는지”도 중요하지만, “지금도 계속 발생하는지”를 보는 것이 더 중요할 때가 많습니다.
이번 글에서는 리눅스 서버에서 tail -f로 실시간 로그를 확인하는 방법과, 로그가 안 찍힐 때 함께 확인해야 할 프로세스, 포트, 요청 흐름을 정리합니다.
tail -f는 언제 사용할까?
tail -f는 로그 파일 끝을 계속 따라가면서 새로 추가되는 내용을 보여줍니다.
기본 형태는 아래입니다.
tail -f 로그파일예를 들어 애플리케이션 로그를 실시간으로 보고 싶다면 이렇게 입력합니다.
tail -f /app/logs/service.log이 명령어는 한 번 실행하고 끝나는 명령어가 아닙니다.
로그 파일을 계속 따라가면서 새로 추가되는 내용을 보여줍니다.
그래서 이런 상황에서 자주 씁니다.
- 서비스 재기동 후 기동 로그 확인
- 테스트 요청 후 로그가 찍히는지 확인
- 에러 로그가 반복되는지 확인
- 사용자 접속 시 로그가 남는지 확인
- 배포 후 애플리케이션 로그 확인
- 외부 API 호출 시 응답 로그 확인
- 장애 재현 중 로그 변화 확인로그를 볼 때 cat부터 실행하면 큰 로그 파일이 한꺼번에 출력되어 확인이 어려울 수 있습니다. 최근 로그와 큰 로그 파일을 안전하게 보는 기본 흐름은 아래 글에서 먼저 정리했습니다.
https://opsnote.tistory.com/20
가상의 운영 상황 예시
예를 들어 웹 서비스에서 500 오류가 발생했다고 가정해보겠습니다.
[상황]
- 사용자 화면에서 500 오류 발생
- 서비스 프로세스는 떠 있는 것으로 보임
- 포트도 LISTEN 상태로 확인됨
- 테스트 요청을 보내면 실제 애플리케이션 로그가 찍히는지 확인 필요이 상황에서 tail -f를 사용하면 요청 시점에 로그가 새로 찍히는지 바로 볼 수 있습니다.
한쪽 터미널에서는 로그를 봅니다.
tail -n 100 -f /app/logs/service.log다른 터미널에서는 테스트 요청을 보냅니다.
curl http://localhost:8080/health요청 시점에 로그가 찍힌다면, 적어도 요청이 애플리케이션까지 도달했을 가능성이 있습니다.
반대로 요청을 보냈는데 애플리케이션 로그가 전혀 찍히지 않는다면, 앞단 웹서버, 포트, 라우팅, 서비스 경로, 로그 경로를 추가로 확인해야 합니다.
1단계. 기본 사용법 확인하기
가장 기본은 아래입니다.
tail -f /app/logs/service.log실행하면 파일의 마지막 부분이 출력되고, 이후 새 로그가 생기면 화면에 계속 표시됩니다.
종료할 때는 아래 키를 누르면 됩니다.
Ctrl + C초보 운영자일 때 tail -f를 실행해놓고 빠져나오는 방법을 몰라 당황하는 경우가 있습니다.
Ctrl + C만 기억하면 됩니다.
tail -f는 멈춘 것이 아니라 새 로그를 기다리고 있는 상태일 수 있습니다. 화면이 조용하다고 해서 명령어가 고장난 것은 아닙니다.
2단계. 최근 100줄부터 보고 실시간으로 따라가기
장애 상황에서는 새 로그만 보는 것보다, 직전 로그도 조금 보고 이어서 보는 것이 좋을 때가 있습니다.
그럴 때는 -n 옵션과 같이 씁니다.
tail -n 100 -f /app/logs/service.log의미는 이렇습니다.
최근 100줄을 먼저 보여주고,
그다음부터 새로 찍히는 로그를 계속 보여준다.아래처럼 써도 동작합니다.
tail -f -n 100 /app/logs/service.log개인적으로는 장애 상황에서 아래 형태를 더 추천합니다.
tail -n 100 -f /app/logs/service.log왜냐하면 에러가 방금 전부터 시작됐을 수도 있기 때문입니다.
새 로그만 보면 바로 직전 에러 흐름을 놓칠 수 있습니다.
3단계. 서비스 재기동 후 로그 확인하기
서비스를 재기동할 때 tail -f는 꽤 유용합니다.
다만 운영 서버에서 서비스 재기동은 영향이 있는 작업입니다.
먼저 재기동이 필요한 상황인지, 담당자 공유가 필요한지, 자동 기동 설정은 정상인지 확인한 뒤 진행해야 합니다.
한쪽 터미널에서는 로그를 열어둡니다.
tail -n 100 -f /app/logs/service.log다른 터미널에서는 서비스 상태를 확인합니다.
systemctl status example-app재기동이 필요한 상황이라면 영향 범위 확인 후 진행합니다.
systemctl restart example-app로그 창에서는 서비스가 정상적으로 기동되는지 확인합니다.
확인할 내용은 대략 이런 것들입니다.
- 기동 시작 로그가 찍히는지
- 에러 없이 정상 기동되는지
- 포트 바인딩 오류가 없는지
- DB 연결 오류가 없는지
- 설정 파일 오류가 없는지
- 같은 에러가 반복되는지
- 서비스가 반복적으로 재시작되는지서비스를 재기동했는데 로그가 아예 안 찍힌다면, 로그 경로가 다르거나 서비스가 정상적으로 실행되지 않았을 수도 있습니다.
서버나 서비스를 재기동하기 전에는 CPU, 메모리, 디스크, 프로세스, 포트, 자동 기동 설정을 함께 확인하는 것이 좋습니다. 재기동 전 체크리스트는 아래 글에서 따로 정리했습니다.
https://opsnote.tistory.com/19
4단계. 테스트 요청을 보내면서 로그 확인하기
서비스가 떠 있는 것처럼 보여도, 실제 요청이 들어왔을 때 로그가 찍히는지 확인해야 할 때가 있습니다.
한쪽 터미널에서 로그를 봅니다.
tail -f /app/logs/service.log다른 터미널에서 curl로 테스트 요청을 보냅니다.
curl http://localhost:8080/health응답 코드만 확인할 수도 있습니다.
curl -o /dev/null -s -w "%{http_code}\n" http://localhost:8080/health이때 로그에 요청 기록이 찍히면, 애플리케이션까지 요청이 도달했을 가능성이 있습니다.
반대로 curl 요청을 보냈는데 로그가 전혀 안 찍힌다면 아래를 의심해야 합니다.
- 요청이 앞단 웹서버에서 막힘
- 포트가 다름
- 애플리케이션 경로가 다름
- 서비스가 해당 요청을 로그로 남기지 않음
- 로그 파일 경로가 다름
- 로그 레벨 설정상 기록되지 않음로그가 안 찍힌다는 것은 “문제가 없다”는 뜻도 아니고, “무조건 서비스가 죽었다”는 뜻도 아닙니다.
요청 흐름과 로그 경로를 같이 봐야 합니다.
5단계. 에러만 보고 싶을 때 grep과 같이 쓰기
로그가 너무 많이 올라오면 필요한 에러를 찾기 어렵습니다.
그럴 때는 grep과 같이 사용할 수 있습니다.
tail -f /app/logs/service.log | grep -i "error"ERROR, Error, error를 구분하지 않고 찾고 싶을 때 -i 옵션을 씁니다.
여러 키워드를 같이 보고 싶다면 이렇게도 볼 수 있습니다.
tail -f /app/logs/service.log | grep -i -E "error|exception|fail|timeout"다만 주의할 점이 있습니다.
grep으로 필터링하면 해당 키워드가 없는 로그는 화면에 나오지 않습니다.
즉, 전체 흐름을 놓칠 수 있습니다.
그래서 처음에는 전체 로그를 보고, 에러가 너무 많거나 로그가 너무 빠르게 올라올 때만 필터링하는 것이 좋습니다.
환경에 따라 tail -f | grep 출력이 바로바로 안 보이는 것처럼 느껴질 때도 있습니다. 그럴 때는 아래처럼 line buffering 옵션을 검토할 수 있습니다.
tail -f /app/logs/service.log | grep --line-buffered -i "error"단, --line-buffered 옵션은 환경에 따라 지원 여부가 다를 수 있습니다.
6단계. 여러 로그를 동시에 보고 싶을 때
서비스에 로그 파일이 여러 개 있을 수 있습니다.
예를 들어 이런 식입니다.
service.log
error.log
access.log이럴 때 여러 파일을 한 번에 볼 수도 있습니다.
tail -f /app/logs/service.log /app/logs/error.log특정 패턴의 로그를 볼 수도 있습니다.
tail -f /app/logs/*.log다만 로그 파일이 너무 많으면 화면이 복잡해질 수 있습니다.
처음에는 필요한 파일만 지정해서 보는 것이 좋습니다.
장애 상황에서는 “많이 보는 것”보다 “필요한 로그를 정확히 보는 것”이 더 중요합니다.
7단계. 로그 파일이 교체될 때는 tail -F도 고려하기
운영 서버에서는 로그가 일정 크기 이상 커지면 logrotate 같은 설정에 의해 로그 파일이 교체될 수 있습니다.
이때 단순 tail -f는 기존 파일을 계속 보고 있어서 새 파일로 이어지지 않는 경우가 있습니다.
이럴 때는 대문자 F 옵션을 사용할 수 있습니다.
tail -F /app/logs/service.log소문자 -f와 대문자 -F는 비슷해 보이지만 차이가 있습니다.
tail -f
→ 현재 열고 있는 파일을 계속 따라감
tail -F
→ 파일이 교체되거나 다시 생성되어도 이름 기준으로 다시 따라감로그 로테이션이 있는 운영 환경에서는 tail -F가 더 편할 때가 있습니다.
처음 배우는 단계에서는 tail -f를 먼저 익히고, 로그 로테이션 환경에서는 tail -F도 알아두면 좋습니다.
로그 파일이 계속 커지거나 logrotate 설정이 제대로 되어 있는지 확인해야 한다면 아래 글도 함께 보면 좋습니다.
8단계. tail -f에서 로그가 안 찍힐 때 확인할 것
tail -f를 보고 있는데 로그가 안 찍히면 무조건 서비스가 죽었다고 판단하면 안 됩니다.
다음 항목을 같이 확인해야 합니다.
- 로그 파일 경로가 맞는지
- 서비스가 실제로 요청을 받고 있는지
- 요청이 애플리케이션까지 도달했는지
- 로그 레벨 설정이 맞는지
- 다른 로그 파일에 찍히는지
- 서비스 프로세스가 떠 있는지
- 포트가 LISTEN 상태인지
- logrotate로 파일이 교체된 것은 아닌지
- 로그 파일 권한 문제는 없는지같이 볼 수 있는 명령어는 아래입니다.
ps -ef | grep example-appss -lntp | grep ':8080'curl http://localhost:8080/health로그 파일 존재 여부와 크기도 확인합니다.
ls -lh /app/logs/service.log로그 경로가 틀렸다면 tail -f를 아무리 보고 있어도 아무것도 찍히지 않습니다.
서비스 프로세스가 없거나 포트가 열려 있지 않다면 로그 이전에 서비스 상태부터 확인해야 합니다.
9단계. /var/log를 볼 때는 디스크도 같이 확인하기
운영 서버에서는 로그 파일이 /var/log 아래에 쌓이는 경우가 많습니다.
tail -f로 로그를 보고 있다가 같은 에러가 빠르게 반복된다면, 로그 파일이 계속 커질 수 있습니다.
이때는 /var 용량도 함께 확인하는 것이 좋습니다.
df -h /vardu -xhd1 /var/log 2>/dev/null | sort -h/var가 꽉 차면 로그 기록 실패, 서비스 오류, 패키지 설치 실패 같은 문제가 생길 수 있습니다.
/var에는 로그뿐 아니라 캐시, 스풀, 서비스 데이터도 함께 쌓일 수 있습니다. /var 용량이 찼을 때 확인하는 순서는 아래 글에서 따로 정리했습니다.
https://opsnote.tistory.com/68
10단계. tail -f 사용할 때 주의할 점
tail -f는 편하지만, 운영 서버에서 사용할 때 몇 가지 주의할 점이 있습니다.
- 로그가 너무 빠르게 올라오면 중요한 내용을 놓칠 수 있음
- 명령어가 계속 실행되므로 종료는 Ctrl + C로 해야 함
- 여러 터미널에서 많이 켜두면 화면이 복잡해짐
- 민감 정보가 화면에 표시될 수 있음
- 로그 경로를 잘못 보면 아무것도 안 찍히는 것처럼 보일 수 있음
- grep으로 필터링하면 전체 흐름을 놓칠 수 있음
- logrotate 이후 기존 파일만 보고 있을 수 있음특히 실제 로그에는 내부 IP, 도메인, 계정명, 토큰, 세션 정보가 포함될 수 있습니다.
외부 공유 화면이나 블로그 이미지에는 실제 로그를 그대로 올리지 않는 것이 좋습니다.
예시를 사용할 때는 아래처럼 마스킹하거나 문서용 값을 사용합니다.
IP: 203.0.113.10
도메인: example.com
토큰: [MASKED]
계정명: user0111단계. 장애 상황에서 tail -f 확인 순서
초보 운영자 기준으로는 아래 순서로 보면 좋습니다.
1. 로그 파일 위치 확인
2. 로그 파일 크기 확인
3. 최근 100줄 먼저 확인
4. tail -f로 실시간 로그 확인
5. 테스트 요청 보내기
6. 요청 시점에 로그가 새로 찍히는지 확인
7. 에러 키워드 확인
8. 프로세스와 포트 상태 같이 확인
9. logrotate 여부 확인
10. 필요하면 /var 용량도 확인명령어로 정리하면 아래처럼 볼 수 있습니다.
ls -lh /app/logs/service.log
tail -n 100 /app/logs/service.log
tail -n 100 -f /app/logs/service.log
curl http://localhost:8080/health
ps -ef | grep example-app
ss -lntp | grep ':8080'
df -h /var12단계. 실무 보고 예시
로그를 실시간으로 확인 중이라면 이렇게 정리할 수 있습니다.
서비스 재기동 후 tail -f로 애플리케이션 로그를 실시간 확인 중입니다.
기동 로그는 정상적으로 출력되고 있으며, 추가 요청 시 ERROR 발생 여부를 확인하겠습니다.테스트 요청과 같이 확인했다면 이렇게 쓸 수 있습니다.
서버 내부에서 curl 테스트를 진행하면서 tail -f로 로그를 확인했습니다.
요청 시점에 애플리케이션 로그가 정상적으로 기록되는 것을 확인했으며,
현재 추가 에러 여부를 모니터링 중입니다.로그가 안 찍힐 때는 이렇게 정리할 수 있습니다.
tail -f 기준 요청 시점의 애플리케이션 로그가 확인되지 않습니다.
로그 경로, 서비스 프로세스 상태, 포트 LISTEN 여부를 추가 확인하겠습니다.에러가 반복될 때는 이렇게 정리할 수 있습니다.
tail -f로 실시간 로그 확인 중 동일 ERROR 로그가 반복 출력되는 것을 확인했습니다.
발생 시각과 요청 조건을 기준으로 원인 범위를 확인하고 있으며,
필요 시 로그 증가에 따른 /var 용량 영향도 함께 점검하겠습니다.이렇게 쓰면 단순히 “로그 확인 중”보다 훨씬 상황이 명확합니다.
정리하면
tail -f는 리눅스 서버에서 실시간 로그를 확인할 때 자주 쓰는 명령어입니다.
기본 형태는 아래입니다.
tail -f 로그파일최근 로그를 먼저 보고 이어서 확인하려면 아래처럼 씁니다.
tail -n 100 -f 로그파일로그 파일이 로테이션될 수 있는 환경에서는 아래 옵션도 알아두면 좋습니다.
tail -F 로그파일초보 운영자라면 이 문장만 기억해도 좋습니다.
장애 상황에서는 tail -f로 로그가 새로 찍히는지 확인하고, 프로세스와 포트 상태도 같이 봅니다.
로그가 안 찍힌다고 바로 서비스 장애로 단정하면 안 됩니다.
로그 경로가 다른지, 요청이 실제로 들어오는지, 프로세스가 떠 있는지, 포트가 열려 있는지 함께 확인해야 합니다.
tail -f는 “지금 로그가 새로 들어오는지”를 보는 데 좋고, tail과 less는 “이미 쌓인 로그를 확인하는 데” 더 적합합니다.
최근 로그를 빠르게 보거나 큰 로그 파일을 천천히 확인하는 방법은 아래 글에서 이어서 볼 수 있습니다.
https://opsnote.tistory.com/20
리눅스 서버 로그 확인할 때 cat부터 치지 말고 tail과 less로 안전하게 보는 법
리눅스 서버에서 장애가 나거나 서비스가 이상할 때 가장 많이 확인하는 것 중 하나가 로그입니다. 그런데 초보 운영자일 때는 로그 파일을 확인하려고 바로 cat 명령어를 실행하는 경우가 있습
opsnote.tistory.com
로그에서 특정 에러만 빠르게 찾고 싶다면 grep으로 키워드를 좁혀보는 것이 좋습니다.
https://opsnote.tistory.com/24
리눅스 서버 로그에서 에러 찾을 때 grep만 믿지 말고 앞뒤 흐름까지 확인하는 법
리눅스 서버에서 장애가 발생했을 때 로그 파일을 열어보면 생각보다 내용이 많습니다. 처음에는 tail이나 less로 로그를 확인하지만, 로그가 길면 눈으로 ERROR, Exception, timeout 같은 키워드를 찾는
opsnote.tistory.com
로그 파일이 계속 커질 때 바로 비우지 않고 확인하는 순서는 아래 글에서 정리했습니다.
https://opsnote.tistory.com/7
리눅스 서버 로그 파일이 계속 커질 때 바로 비우지 말고 확인하는 법
리눅스 서버에서 디스크 용량 부족 알림이 발생했을 때, 원인이 로그 파일인 경우가 많습니다. 특히 /var/log 아래 시스템 로그나 애플리케이션 로그가 계속 커지면 시간이 지날수록 디스크 사용
opsnote.tistory.com
'리눅스' 카테고리의 다른 글
| 리눅스 서버 큰 로그 파일 vi로 열지 말고 less로 안전하게 보는 법 (0) | 2026.05.25 |
|---|---|
| 리눅스 서버 로그 확인할 때 전체 열지 말고 tail -n으로 최근만 보는 법 (0) | 2026.05.25 |
| 리눅스 서버 로그 확인할 때 cat부터 치지 말고 tail과 less로 안전하게 보는 법 (0) | 2026.05.21 |
| 리눅스 서버 재기동 전 바로 껐다 켜지 말고 확인해야 할 체크리스트 (0) | 2026.05.20 |
| 리눅스 서버 접속이 안 될 때 netstat보다 ss로 포트 확인하는 이유 (0) | 2026.05.19 |