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

리눅스 서버 로그에서 grep 명령어로 error, exception, timeout 키워드를 찾고 grep -C로 에러 앞뒤 흐름까지 확인하는 방법을 설명하는 대표 이미지

 

리눅스 서버에서 장애가 발생했을 때 로그 파일을 열어보면 생각보다 내용이 많습니다. 처음에는 tail이나 less로 로그를 확인하지만, 로그가 길면 눈으로 ERROR, Exception, timeout 같은 키워드를 찾는 것도 쉽지 않습니다.

이럴 때 자주 사용하는 명령어가 grep입니다.

grep은 파일 안에서 특정 문자열이 들어간 줄만 찾아주는 명령어입니다. 로그 파일에서 에러 메시지, 예외, 타임아웃 같은 키워드를 빠르게 찾을 때 많이 사용합니다.

하지만 grep 결과 한 줄만 보고 바로 원인을 단정하면 위험할 수 있습니다. 에러는 앞뒤 흐름을 함께 봐야 원인을 제대로 판단할 수 있는 경우가 많기 때문입니다.

이번 글에서는 리눅스 서버 로그에서 grep으로 에러 로그를 찾는 기본 방법과, grep -C로 에러 앞뒤 문맥까지 확인하는 순서를 정리합니다.

로그에서 grep을 쓰는 이유

운영 서버의 로그 파일은 짧지 않은 경우가 많습니다.

몇백 줄이면 그나마 괜찮지만, 서비스 로그는 금방 몇만 줄, 몇십만 줄까지 쌓일 수 있습니다.

이 상태에서 눈으로 에러를 찾으면 시간이 오래 걸립니다.

예를 들어 이런 상황입니다.

- 서비스가 갑자기 죽음
- 접속 요청이 실패함
- 배포 후 오류가 발생함
- 외부 API 연동이 실패함
- timeout 로그가 반복됨
- 500 오류가 발생했지만 원인 위치를 모름

 

이럴 때 로그 전체를 처음부터 끝까지 보는 것보다, 먼저 에러 키워드로 좁혀보는 것이 좋습니다.

단, grep은 “찾는 도구”이지 “원인을 확정하는 도구”는 아닙니다.

검색 결과를 보고 나서 앞뒤 로그, 발생 시각, 반복 여부를 함께 확인해야 합니다.

가상의 운영 상황 예시

예를 들어 애플리케이션에서 간헐적으로 500 오류가 발생했다고 가정해보겠습니다.

[상황]
- 사용자 화면에서 500 오류 발생
- 장애 발생 추정 시각은 14:20 전후
- 애플리케이션 로그 파일 크기는 800MB
- 전체 로그를 열어보기에는 내용이 너무 많음
- error, exception, timeout 키워드 확인 필요

 

이 상황에서 로그 전체를 처음부터 끝까지 읽는 것은 비효율적입니다.

먼저 최근 로그를 보고, 필요한 키워드로 범위를 좁히는 것이 좋습니다.

 

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

 

이렇게 하면 최근 500줄 안에서 에러와 예외, 타임아웃 관련 로그를 빠르게 찾을 수 있습니다.

 

로그를 확인할 때는 cat으로 전체 파일을 열기보다 tail, less, grep을 상황에 맞게 나누어 쓰는 것이 안전합니다. 기본적인 로그 확인 흐름은 아래 글에서 먼저 정리했습니다.

https://opsnote.tistory.com/20

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

 

1단계. grep 기본 사용법 확인하기

grep의 가장 기본 형태는 아래와 같습니다.

 

grep "ERROR" service.log

 

이 명령어는 service.log 파일 안에서 ERROR라는 문자열이 들어간 줄만 출력합니다.

예를 들어 애플리케이션 로그에서 에러를 찾고 싶다면 이렇게 볼 수 있습니다.

 

grep "ERROR" /app/logs/service.log

 

결과는 이런 식으로 나올 수 있습니다.

2026-05-22 10:15:20 ERROR Failed to connect database
2026-05-22 10:15:21 ERROR Connection timeout

 

이렇게 보면 로그 전체를 열지 않아도 에러가 찍힌 줄만 빠르게 확인할 수 있습니다.

하지만 여기서 바로 “DB 문제다”라고 결론 내리면 안 됩니다.

에러 직전에 어떤 요청이 들어왔는지, 특정 배포 이후 발생했는지, 같은 오류가 반복되는지까지 확인해야 합니다.

2단계. 대소문자 때문에 안 잡힐 수 있습니다

처음에 아래처럼 검색했는데 결과가 안 나올 수 있습니다.

 

grep "ERROR" /app/logs/service.log

 

그런데 실제 로그에는 아래처럼 찍혀 있을 수도 있습니다.

Error
error
ERROR

 

기본 grep은 대소문자를 구분합니다.

그래서 ERROR만 찾으면 Error나 error는 놓칠 수 있습니다.

이럴 때는 -i 옵션을 사용합니다.

 

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

 

-i는 대소문자를 구분하지 않고 찾는 옵션입니다.

초보 운영자라면 일단 이렇게 기억하면 됩니다.

ERROR만 찾으면 놓칠 수 있다.
대소문자 상관없이 찾을 때는 grep -i를 쓴다.

 

3단계. 자주 찾는 에러 키워드 정리하기

장애 로그를 볼 때는 error만 찾지 않습니다.

상황에 따라 여러 키워드를 같이 봐야 할 때가 많습니다.

자주 보는 키워드는 이런 것들입니다.

error
exception
fail
failed
timeout
denied
refused
oom
killed
fatal
critical

 

예를 들어 timeout 관련 로그를 찾고 싶다면 아래처럼 확인합니다.

 

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

 

접속 거부 관련 로그를 찾고 싶다면 아래처럼 볼 수 있습니다.

 

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

 

권한 관련 로그를 찾고 싶다면 아래처럼 확인합니다.

 

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

 

메모리 부족이나 OOM 관련 로그를 찾을 때는 아래처럼 볼 수 있습니다.

 

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

 

로그마다 표현이 다르기 때문에 한 가지 키워드만 믿으면 안 됩니다.

서비스마다 ERROR 대신 WARN, Exception, failed, timeout처럼 다르게 남길 수 있습니다.

4단계. 여러 키워드를 한 번에 찾기

에러 키워드를 여러 개 한 번에 보고 싶을 때는 -E 옵션을 사용할 수 있습니다.

 

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

 

이 명령어는 아래 키워드가 들어간 줄을 찾습니다.

error
exception
fail
timeout

 

운영 로그를 볼 때는 아래 형태도 자주 씁니다.

 

grep -i -E "error|exception|fail|timeout|refused|denied" /app/logs/service.log

 

다만 키워드를 너무 많이 넣으면 결과가 많아져서 다시 보기 어려울 수 있습니다.

처음에는 핵심 키워드 몇 개만 넣고, 필요하면 범위를 좁히는 것이 좋습니다.

처음 검색: error|exception|timeout
추가 검색: refused|denied|failed
상황별 검색: 특정 API명, 특정 시간, 특정 요청 ID

 

5단계. 최근 로그에서만 grep하기

큰 로그 파일 전체를 대상으로 grep을 실행하면 결과가 너무 많이 나올 수 있습니다.

장애가 방금 발생했다면 전체 로그보다 최근 로그에서만 찾는 것이 더 빠를 때가 많습니다.

이럴 때는 tail과 grep을 같이 씁니다.

 

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

 

이 명령어는 최근 500줄 중에서 error가 들어간 줄만 보여줍니다.

여러 키워드를 같이 보고 싶으면 이렇게 씁니다.

 

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

 

이 방식이 좋은 이유는 간단합니다.

- 전체 로그를 다 뒤지지 않아도 됨
- 장애 직전 흐름을 빠르게 볼 수 있음
- 출력 결과가 너무 많아지는 것을 줄일 수 있음
- 최근 발생한 문제와 오래된 문제를 구분하기 쉬움

 

초보 운영자라면 처음부터 전체 파일에 grep을 걸기보다, 최근 로그 범위를 정해서 보는 습관이 좋습니다.

 

실시간으로 새 로그가 찍히는지 확인해야 한다면 tail -f를 함께 사용하면 좋습니다. 서비스 재기동이나 테스트 요청 후 로그가 새로 찍히는지 보는 방법은 아래 글에서 이어서 확인할 수 있습니다.

https://opsnote.tistory.com/21

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

 

6단계. grep 결과만 보고 바로 결론 내리면 안 됩니다

grep은 에러를 찾는 데 좋지만, 한 가지 단점이 있습니다.

검색된 줄만 보여주기 때문에 앞뒤 흐름을 놓칠 수 있습니다.

예를 들어 아래처럼 에러 한 줄만 보일 수 있습니다.

ERROR Failed to process request

 

이 줄만 보면 원인을 알기 어렵습니다.

바로 앞에 어떤 요청이 있었는지, 어떤 사용자 작업이 있었는지, 어떤 서비스 호출이 있었는지 봐야 할 수 있습니다.

이럴 때는 grep -C를 사용할 수 있습니다.

 

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

 

-C 3은 검색된 줄의 앞뒤 3줄을 같이 보여줍니다.

예를 들어 timeout이 발생한 줄의 앞뒤 5줄을 보고 싶다면 아래처럼 확인합니다.

 

grep -i -C 5 "timeout" /app/logs/service.log

 

이 기능은 꽤 유용합니다.

에러 한 줄만 보고 판단하지 않게 도와줍니다.

운영 로그에서는 에러 한 줄보다 “그 앞에 무슨 일이 있었는지”가 더 중요할 때가 많습니다.

7단계. grep -A, grep -B도 알아두기

grep -C는 앞뒤 로그를 함께 보여줍니다.

상황에 따라 앞쪽만 보거나 뒤쪽만 보고 싶을 수도 있습니다.

에러 뒤쪽 로그를 보고 싶을 때는 -A를 사용합니다.

 

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

 

에러 앞쪽 로그를 보고 싶을 때는 -B를 사용합니다.

 

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

 

간단히 정리하면 이렇습니다.

-C → 앞뒤 Context 확인
-A → After, 검색 결과 뒤쪽 확인
-B → Before, 검색 결과 앞쪽 확인

 

처음에는 -C만 알아도 충분합니다.

장애 상황에서는 에러 전후 흐름을 같이 보는 것이 가장 중요하기 때문입니다.

8단계. grep 결과가 너무 많을 때 줄이기

가끔 grep 결과가 너무 많이 나올 때가 있습니다.

예를 들어 error라는 단어가 너무 자주 찍히는 로그라면 화면이 금방 복잡해집니다.

이럴 때는 아래처럼 범위를 줄일 수 있습니다.

 

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

 

또는 특정 시간대 키워드와 같이 볼 수도 있습니다.

 

grep "10:15" /app/logs/service.log | grep -i "error"

 

이 명령어는 먼저 10:15가 들어간 줄을 찾고, 그중에서 error가 들어간 줄을 다시 찾습니다.

다만 로그 시간 형식은 서버마다 다릅니다.

먼저 로그가 어떤 형식으로 찍히는지 확인한 뒤 사용하는 것이 좋습니다.

예를 들어 로그 시간이 아래처럼 찍힐 수 있습니다.

2026-05-22 10:15:20
[2026-05-22 10:15:20]
May 22 10:15:20
10:15:20.123

 

시간 형식이 다르면 검색 키워드도 달라져야 합니다.

9단계. 파일 여러 개에서 grep하기

로그 파일이 여러 개로 나뉘어 있을 때도 있습니다.

service.log
service.log.1
service-error.log
access.log

 

현재 디렉터리의 .log 파일에서 에러를 찾고 싶다면 이렇게 볼 수 있습니다.

 

grep -i "error" *.log

 

하위 디렉터리까지 찾고 싶다면 -R 옵션을 사용할 수 있습니다.

 

grep -R -i "error" /app/logs/

 

다만 운영 서버에서 grep -R은 범위가 넓으면 시간이 오래 걸릴 수 있습니다.

처음부터 / 전체 같은 넓은 범위에 걸면 안 됩니다.

예를 들어 이런 명령어는 조심해야 합니다.

 

grep -R -i "error" /

 

이건 너무 넓습니다.

운영 서버에서는 필요한 로그 경로만 지정해서 확인하는 것이 안전합니다.

 

grep -R -i "error" /app/logs/
grep -R -i "timeout" /var/log/example-app/

 

검색 범위도 장애 대응의 일부입니다.

넓게 뒤지는 것보다, 의심 경로를 좁혀서 확인하는 것이 좋습니다.

10단계. 로그 파일이 너무 크면 먼저 크기부터 확인하기

로그가 매우 큰 경우에는 전체 파일에 바로 grep을 걸기 전에 파일 크기를 확인하는 것이 좋습니다.

 

ls -lh /app/logs/service.log

 

예시입니다.

-rw-r--r-- 1 app app 2.3G May 22 10:20 service.log

 

2GB가 넘는 로그라면 전체를 대상으로 반복 검색하기보다 최근 범위부터 확인하는 편이 좋습니다.

 

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

 

로그 파일이 계속 커지고 있다면 logrotate 설정도 확인해야 합니다.

로그 파일이 커지는 원인과 logrotate 확인 방법은 아래 글에서 따로 정리했습니다.

https://opsnote.tistory.com/7

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

 

11단계. /var/log 검색 시 디스크 상태도 같이 보기

운영 서버의 로그는 /var/log 아래에 쌓이는 경우가 많습니다.

/var/log 아래에서 반복 오류가 많이 찍히면 /var 용량이 빠르게 증가할 수 있습니다.

로그 검색 중 아래 상황이 보이면 디스크도 같이 확인하는 것이 좋습니다.

- 같은 ERROR가 초당 여러 번 반복됨
- access log가 매우 빠르게 증가함
- timeout 로그가 계속 쌓임
- debug 로그가 운영 환경에서 켜져 있음
- logrotate가 적용되지 않은 로그가 계속 커짐

 

확인 명령어는 아래처럼 시작할 수 있습니다.

 

df -h /var
du -xhd1 /var/log 2>/dev/null | sort -h

 

/var에는 로그뿐 아니라 캐시, 스풀, 서비스 데이터도 함께 쌓입니다. /var 용량이 찼을 때 어떤 경로를 먼저 확인해야 하는지는 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/68

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

 

12단계. 운영 서버에서 grep 사용할 때 주의할 점

grep은 조회 명령어라 비교적 안전한 편입니다.

그래도 운영 서버에서는 범위를 조심해야 합니다.

특히 아래는 주의하는 것이 좋습니다.

- 검색 범위를 너무 넓게 잡지 않기
- 큰 파일 전체에 무작정 반복 검색하지 않기
- 민감 정보가 포함된 로그를 그대로 공유하지 않기
- 실제 IP, 도메인, 계정명, 토큰은 마스킹하기
- grep 결과 한 줄만 보고 원인을 단정하지 않기
- 오래된 에러와 현재 장애를 혼동하지 않기

 

로그는 장애 원인을 찾는 단서일 뿐입니다.

grep으로 에러를 찾은 뒤에는 프로세스, 포트, 리소스 상태도 같이 봐야 할 수 있습니다.

 

서버 재기동을 고민 중이라면 로그 검색만 보고 바로 재기동하기보다 현재 상태를 함께 확인해야 합니다. 재기동 전 기본 체크리스트는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/19

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

 

13단계. 장애 상황에서 grep 확인 순서

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

1. 로그 파일 위치 확인
2. 로그 파일 크기 확인
3. 최근 로그 먼저 확인
4. error, exception, timeout 등 키워드 검색
5. 에러 앞뒤 줄 같이 확인
6. 반복 발생 여부 확인
7. 발생 시각과 장애 시각 비교
8. 프로세스, 포트, 리소스 상태 같이 확인

 

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

 

ls -lh /app/logs/service.log
tail -n 500 /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
grep -i -C 5 "timeout" /app/logs/service.log

 

필요하면 실시간 로그도 같이 확인합니다.

 

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

 

14단계. 실무 보고 예시

grep으로 에러 로그를 확인했다면 이렇게 정리할 수 있습니다.

애플리케이션 로그에서 error, exception, timeout 키워드를 기준으로 확인했습니다.
최근 500줄 기준 timeout 로그가 반복적으로 확인되어,
해당 시간대의 요청 흐름과 외부 연동 상태를 추가 확인하겠습니다.

 

에러 앞뒤 로그까지 확인했다면 이렇게 쓸 수 있습니다.

grep -C 옵션으로 에러 발생 전후 로그를 함께 확인했습니다.
에러 직전 특정 API 호출이 반복적으로 확인되어,
해당 연동 구간을 우선 확인하겠습니다.

 

로그에서 특이사항이 없을 때는 이렇게 정리할 수 있습니다.

최근 애플리케이션 로그 기준 error, exception, timeout 키워드는 확인되지 않았습니다.
서비스 프로세스 및 포트 상태를 추가 확인하겠습니다.

 

검색 범위를 좁혀 확인했다면 이렇게 쓸 수 있습니다.

장애 발생 추정 시각 기준으로 로그 범위를 좁혀 확인했습니다.
해당 시간대에 timeout 로그가 반복적으로 확인되어,
외부 연동 지연 여부를 추가 확인하겠습니다.

 

이렇게 정리하면 단순히 “로그 확인했습니다”보다 훨씬 명확합니다.

정리하면

리눅스 서버에서 로그 파일이 길 때는 눈으로 에러를 찾기보다 grep을 사용하는 것이 편합니다.

기본 명령어는 아래입니다.

 

grep "ERROR" service.log

 

대소문자 상관없이 찾으려면 아래처럼 씁니다.

 

grep -i "error" service.log

 

여러 키워드를 같이 찾으려면 아래처럼 확인합니다.

 

grep -i -E "error|exception|fail|timeout" service.log

 

최근 로그에서만 찾고 싶다면 아래처럼 볼 수 있습니다.

 

tail -n 500 service.log | grep -i "error"

 

에러 앞뒤 흐름까지 보고 싶다면 아래처럼 확인합니다.

 

grep -i -C 3 "error" service.log

 

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

로그에서 에러를 찾을 때는 grep으로 먼저 좁히되, 결과 한 줄만 보고 원인을 단정하지 않는 것이 좋습니다.

grep은 필요한 키워드를 빠르게 찾는 데 좋지만, 장애 로그는 발생 시각, 앞뒤 흐름, 반복 여부를 함께 봐야 합니다.  
그래서 에러 앞뒤 흐름까지 같이 확인해야 할 때는 grep -C 옵션을 함께 사용하면 좋습니다.

에러 앞뒤 로그까지 함께 확인하는 grep -C 사용법은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/25

리눅스 서버 로그에서 에러 한 줄만 보지 말고 grep -C로 앞뒤 흐름 확인하는 법

 

반대로 특정 키워드를 제외하고 보고 싶을 때는 grep -v를 사용할 수 있습니다.

https://opsnote.tistory.com/26

리눅스 서버 로그에서 정상 로그가 너무 많을 때 grep -v로 제외하고 확인하는 법

 

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

https://opsnote.tistory.com/7

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