로그에서 ERROR, WARN, INFO는 무슨 뜻일까? IT 운영자가 먼저 보는 로그 레벨 정리

IT 운영자가 로그를 확인할 때 자주 보는 ERROR, WARN, INFO, DEBUG, FATAL 로그 레벨의 의미를 실무 기준으로 정리했습니다. 장애 대응 시 로그 레벨을 어떻게 해석하고 우선순위를 판단해야 하는지 설명합니다.

 

IT 운영 업무를 하다 보면 장애 대응 과정에서 로그를 확인할 일이 많습니다.

 

사용자가 “오류가 났어요”, “화면이 안 열려요”, “저장이 안 됩니다”라고 문의하면 운영자는 먼저 발생 시간, 사용자, 메뉴, 오류 화면 등을 확인하고, 그다음 서버나 시스템 로그를 확인하게 됩니다.

 

이전 글에서는 IT 운영자가 장애 대응 시 왜 로그를 확인해야 하는지 정리했습니다.

 

이전 글: IT 운영자가 로그를 확인하는 이유｜장애 원인 분석의 첫 번째 단서

 

이번 글에서는 한 단계 더 들어가, 실제 로그에서 자주 보이는 ERROR, WARN, INFO, DEBUG 같은 로그 레벨이 각각 어떤 의미인지 정리해보겠습니다.

 

처음 로그를 보면 영어 메시지도 많고, 빨간색으로 ERROR가 찍혀 있으면 무조건 큰 장애처럼 느껴질 수 있습니다.
하지만 실제 운영 업무에서는 ERROR가 있다고 해서 반드시 전체 장애는 아니고, WARN이 있다고 해서 무시해도 되는 것도 아닙니다.

로그 레벨의 의미를 이해하면 장애 대응 시 어떤 로그를 먼저 봐야 하는지, 어떤 로그를 개발자나 외부 업체에 전달해야 하는지 판단하는 데 도움이 됩니다.

로그 레벨이란?

로그 레벨은 시스템에서 남기는 로그의 중요도를 구분하기 위한 기준입니다.

시스템은 실행 중에 여러 가지 기록을 남깁니다.

예를 들어 다음과 같은 기록이 있을 수 있습니다.

• 사용자가 로그인함
• 특정 메뉴를 조회함
• 파일 업로드가 성공함
• 배치 작업이 시작됨
• 외부 API 호출이 실패함
• DB 연결 오류가 발생함
• 필수값 누락으로 저장 실패함

이 모든 기록을 같은 중요도로 보면 운영자가 로그를 확인하기 어렵습니다.

그래서 로그에는 보통 중요도에 따라 레벨이 붙습니다.

대표적인 로그 레벨은 다음과 같습니다.

• DEBUG
• INFO
• WARN
• ERROR
• FATAL

회사나 시스템에 따라 사용하는 로그 레벨은 조금씩 다를 수 있지만, 운영 업무에서 가장 자주 보는 것은 INFO, WARN, ERROR입니다.

로그 레벨을 알아야 하는 이유

IT 운영자가 로그 레벨을 알아야 하는 이유는 장애 대응 우선순위를 판단하기 위해서입니다.

로그에는 정말 많은 정보가 남습니다.
특히 사용자가 많은 시스템이나 배치가 자주 실행되는 시스템은 몇 분 사이에도 많은 로그가 쌓일 수 있습니다.

이때 모든 로그를 처음부터 끝까지 볼 수는 없습니다.

운영자는 먼저 중요한 로그를 찾아야 합니다.

예를 들어 사용자가 저장 오류를 문의했다면, 해당 시간대의 ERROR 로그를 먼저 확인할 수 있습니다.

시스템이 느리다는 문의라면 ERROR뿐 아니라 WARN, 처리 시간 로그, 외부 응답 지연 로그도 함께 봐야 할 수 있습니다.

로그 레벨을 이해하면 다음을 판단하기 쉬워집니다.

• 이 로그가 단순 정보인지
• 주의가 필요한 상태인지
• 실제 오류인지
• 업무 영향이 있는지
• 개발자에게 전달해야 하는지
• 즉시 조치가 필요한지

즉, 로그 레벨은 장애 대응 시 “어디부터 봐야 할지” 알려주는 기준이 됩니다.

INFO 로그란?

INFO는 말 그대로 정보성 로그입니다.

시스템이 정상적으로 어떤 작업을 수행했다는 기록을 남길 때 주로 사용됩니다.

예를 들어 다음과 같은 로그가 INFO로 남을 수 있습니다.

2026-05-26 09:00:01 INFO  User login success userId=admin
2026-05-26 09:05:10 INFO  Order batch started
2026-05-26 09:05:30 INFO  Order batch completed count=120
2026-05-26 10:15:00 INFO  File upload success fileName=order_20260526.xlsx

INFO 로그는 보통 오류는 아닙니다.

운영자가 INFO 로그를 보는 이유는 시스템이 어떤 순서로 정상 처리되었는지 확인하기 위해서입니다.

예를 들어 배치가 정상적으로 실행되었는지 확인할 때 INFO 로그가 도움이 됩니다.

배치 시작 로그와 종료 로그가 모두 있다면 일단 작업이 실행되었고 종료되었다는 것을 알 수 있습니다.

또한 사용자가 “파일을 업로드했는데 반영이 안 됐다”고 문의했을 때, INFO 로그에서 업로드 성공 여부와 처리 건수를 확인할 수 있습니다.

즉, INFO 로그는 장애 원인을 직접 알려주는 로그라기보다 정상 처리 흐름을 확인하는 로그라고 볼 수 있습니다.

INFO 로그도 중요한 이유

INFO는 오류가 아니기 때문에 무시해도 된다고 생각할 수 있습니다.

하지만 운영 업무에서는 INFO 로그도 중요합니다.

왜냐하면 장애가 발생했을 때 정상 흐름이 어디까지 진행되었는지 확인할 수 있기 때문입니다.

예를 들어 주문 수신 배치가 실패했다고 가정해보겠습니다.

이때 INFO 로그를 보면 다음을 확인할 수 있습니다.

• 배치가 시작되었는지
• 몇 건을 처리했는지
• 어느 단계까지 진행되었는지
• 정상 종료 로그가 있는지
• 특정 파일을 읽었는지
• 특정 API를 호출했는지

만약 배치 시작 로그는 있는데 종료 로그가 없다면, 중간에 멈췄을 가능성이 있습니다.

반대로 시작 로그 자체가 없다면 스케줄러가 실행되지 않았을 수도 있습니다.

이처럼 INFO 로그는 문제의 흐름을 따라가는 데 도움이 됩니다.

WARN 로그란?

WARN은 Warning의 줄임말로, 경고성 로그입니다.

즉, 시스템이 완전히 실패한 것은 아니지만 주의가 필요한 상태를 의미합니다.

예를 들어 다음과 같은 상황에서 WARN 로그가 남을 수 있습니다.

2026-05-26 10:20:11 WARN  API response delayed responseTime=5000ms
2026-05-26 10:21:03 WARN  Retry file transfer retryCount=1
2026-05-26 10:22:15 WARN  Required optional value is empty
2026-05-26 10:25:40 WARN  Slow query detected elapsed=8000ms

WARN은 당장 업무가 완전히 중단된 상태는 아닐 수 있습니다.

하지만 반복되면 장애로 이어질 수 있는 신호일 수 있습니다.

예를 들어 외부 API 응답이 느리다는 WARN 로그가 반복된다면, 당장은 정상 처리되더라도 곧 Timeout 오류로 이어질 수 있습니다.

파일 전송 재시도 WARN이 계속 발생한다면, SFTP 연결이나 파일 권한 문제를 의심할 수 있습니다.

느린 쿼리 WARN이 반복된다면 특정 화면 조회 지연이나 DB 부하 문제로 이어질 수 있습니다.

즉, WARN은 “지금 당장 장애는 아닐 수 있지만 확인이 필요한 상태”라고 보면 됩니다.

WARN 로그를 무시하면 안 되는 이유

운영 업무에서는 ERROR 로그만 중요하게 생각하기 쉽습니다.

하지만 실제로는 WARN 로그를 잘 보는 것도 중요합니다.

WARN은 장애가 발생하기 전의 전조일 수 있기 때문입니다.

예를 들어 시스템이 갑자기 멈추기 전에 다음과 같은 WARN 로그가 반복될 수 있습니다.

• DB 연결 대기 시간이 길어짐
• 외부 API 응답 시간이 길어짐
• 파일 전송 재시도 발생
• 메모리 사용량 증가
• 특정 쿼리 실행 시간이 길어짐
• 배치 처리 건수가 평소보다 적음

이런 로그를 미리 확인하면 큰 장애로 이어지기 전에 조치할 수 있습니다.

운영 업무에서 중요한 것은 장애가 발생한 뒤에 조치하는 것뿐 아니라, 장애가 발생할 가능성을 미리 감지하는 것입니다.

그래서 WARN 로그는 운영 안정성 측면에서 중요한 의미가 있습니다.

ERROR 로그란?

ERROR는 실제 오류가 발생했음을 의미하는 로그입니다.

시스템이 어떤 작업을 정상적으로 처리하지 못했을 때 남는 경우가 많습니다.

예를 들어 다음과 같은 로그가 ERROR로 남을 수 있습니다.

2026-05-26 10:30:11 ERROR DB connection failed
2026-05-26 10:31:22 ERROR NullPointerException at OrderService
2026-05-26 10:32:05 ERROR File not found path=/upload/order.xlsx
2026-05-26 10:33:40 ERROR API request failed status=500

ERROR 로그는 운영자가 가장 먼저 확인해야 하는 로그 중 하나입니다.

하지만 중요한 점은 ERROR가 있다고 해서 항상 전체 장애는 아니라는 것입니다.

예를 들어 특정 사용자의 잘못된 입력으로 ERROR가 발생했을 수도 있고, 특정 주문번호에서만 데이터 조건 문제로 ERROR가 발생했을 수도 있습니다.

반면 전체 사용자가 같은 ERROR를 겪는다면 업무 영향도가 큰 장애일 가능성이 높습니다.

즉, ERROR 로그를 봤을 때는 단순히 “장애다”라고 판단하기보다 다음을 함께 확인해야 합니다.

• 언제 발생했는지
• 어떤 사용자에게 발생했는지
• 어떤 메뉴에서 발생했는지
• 특정 데이터에서만 발생했는지
• 반복 발생 중인지
• 업무 영향 범위가 어디까지인지
• 최근 배포나 설정 변경이 있었는지

ERROR 로그는 장애 분석의 핵심 단서이지만, 영향도 판단이 함께 필요합니다.

ERROR 로그를 볼 때 확인할 것

ERROR 로그를 볼 때는 단순히 ERROR라는 단어만 찾으면 안 됩니다.

오류 메시지와 전후 흐름을 함께 봐야 합니다.

확인해야 할 항목은 다음과 같습니다.

• 오류 발생 시간
• 사용자 ID
• 요청 URL 또는 메뉴
• 오류 메시지
• Exception 종류
• 관련 주문번호, 파일명, 데이터 키
• 오류 직전 INFO 또는 WARN 로그
• 동일 오류 반복 여부
• 오류 이후 정상 처리 여부

예를 들어 ERROR 로그 바로 앞에 WARN 로그가 반복적으로 있었다면, 그 WARN이 오류의 원인과 관련 있을 수 있습니다.

또한 ERROR 이후에 재시도 성공 로그가 있다면 실제 업무 영향은 크지 않았을 수도 있습니다.

반대로 ERROR가 반복되고 정상 종료 로그가 없다면 조치가 필요한 장애일 가능성이 높습니다.

운영자는 ERROR 한 줄만 보는 것이 아니라, 전후 로그를 함께 확인해야 합니다.

DEBUG 로그란?

DEBUG는 개발이나 상세 분석을 위해 남기는 디버깅용 로그입니다.

운영 환경에서는 DEBUG 로그가 꺼져 있는 경우도 많습니다.
DEBUG 로그는 내용이 매우 상세하고 양이 많기 때문에 운영 서버에서 항상 켜두면 로그 용량이나 성능에 영향을 줄 수 있습니다.

DEBUG 로그에는 다음과 같은 상세 정보가 남을 수 있습니다.

• 메서드 호출 정보
• 변수값
• 상세 파라미터
• 조건 분기 결과
• 내부 처리 단계

개발자가 원인을 분석할 때는 DEBUG 로그가 도움이 될 수 있습니다.

하지만 운영자가 일상적으로 장애 대응을 할 때는 INFO, WARN, ERROR를 먼저 보는 경우가 많습니다.

운영 환경에서 DEBUG 로그가 필요한 경우에는 담당 개발자나 업체와 협의해 일시적으로 활성화하는 방식으로 진행하기도 합니다.

FATAL 로그란?

FATAL은 시스템이 정상적으로 계속 동작하기 어려운 심각한 오류를 의미합니다.

모든 시스템에서 FATAL 로그를 사용하는 것은 아니지만, 사용한다면 ERROR보다 더 심각한 수준으로 볼 수 있습니다.

예를 들어 다음과 같은 상황에서 FATAL 로그가 발생할 수 있습니다.

• 애플리케이션 기동 실패
• 필수 설정 파일 누락
• DB 연결 완전 실패
• 서버 프로세스 종료
• 핵심 모듈 로딩 실패

FATAL 로그가 발생했다면 단순 기능 오류가 아니라 시스템 전체 서비스에 영향을 줄 수 있습니다.

운영자는 FATAL 로그가 확인되면 서비스 상태, 서버 상태, 최근 배포 여부, 설정 파일 변경 여부 등을 빠르게 확인해야 합니다.

로그 레벨별 의미 정리

운영 업무 기준으로 로그 레벨을 정리하면 다음과 같습니다.

로그 레벨의미운영자 관점

DEBUG	상세 분석용 기록	개발 분석용, 운영에서는 제한적으로 확인
INFO	정상 처리 정보	처리 흐름과 정상 실행 여부 확인
WARN	경고 상태	장애 전조 가능성, 반복 여부 확인 필요
ERROR	오류 발생	원인 분석 및 영향도 판단 필요
FATAL	심각한 오류	서비스 영향 가능성 높음, 즉시 확인 필요

처음 로그를 볼 때는 모든 로그를 완벽히 이해하려고 하기보다, 이 정도 기준으로 구분하는 것부터 시작하면 됩니다.

로그 레벨과 장애 영향도는 다를 수 있다

로그 레벨을 볼 때 가장 주의해야 할 점은 로그 레벨과 실제 장애 영향도가 항상 일치하지는 않는다는 것입니다.

예를 들어 ERROR 로그가 있어도 특정 사용자 한 명에게만 발생한 일회성 오류일 수 있습니다.

반대로 WARN 로그만 반복되고 있어도 전체 시스템 속도 저하나 장애 전조일 수 있습니다.

즉, 로그 레벨은 중요한 참고 기준이지만, 최종 판단은 업무 영향도와 함께 봐야 합니다.

운영자는 다음을 함께 확인해야 합니다.

• 전체 사용자 영향인지
• 특정 사용자만 영향인지
• 특정 메뉴만 영향인지
• 특정 데이터만 영향인지
• 반복 발생 중인지
• 업무 마감이나 출고 같은 중요한 시간대인지
• 임시 조치가 가능한지

운영 업무에서는 기술적인 심각도와 업무적인 심각도를 함께 판단해야 합니다.

실제 장애 대응에서 로그를 보는 순서

장애 대응 시 로그를 볼 때는 아래 순서로 확인하면 좋습니다.

첫 번째, 오류 발생 시간을 기준으로 로그 범위를 좁힙니다.

사용자가 알려준 발생 시간 또는 모니터링 알림 시간을 기준으로 해당 시간대 로그를 확인합니다.

두 번째, ERROR 로그를 먼저 확인합니다.

오류 메시지, Exception, 요청 URL, 사용자 ID 등을 확인합니다.

세 번째, ERROR 전후의 WARN 로그를 확인합니다.

오류가 발생하기 전에 경고성 로그가 반복되었는지 확인합니다.

네 번째, INFO 로그로 정상 처리 흐름을 확인합니다.

작업이 어디까지 진행되었고, 어느 단계에서 멈췄는지 파악합니다.

다섯 번째, 동일 오류가 반복되는지 확인합니다.

한 번 발생한 오류인지, 여러 사용자에게 반복되는 오류인지에 따라 대응 우선순위가 달라집니다.

여섯 번째, DB 데이터나 외부 연동 로그와 함께 비교합니다.

로그만으로 부족한 경우 SQL 조회나 API/SFTP 연동 로그를 함께 확인해야 합니다.

개발자나 업체에 로그를 전달할 때 주의할 점

운영자가 로그를 확인한 뒤 개발자나 외부 업체에 전달해야 할 때도 있습니다.

이때 로그 전체를 그대로 전달하기보다, 필요한 정보를 정리해서 전달하는 것이 좋습니다.

전달하면 좋은 항목은 다음과 같습니다.

• 오류 발생 시간
• 오류 발생 메뉴
• 사용자 ID
• 요청 URL
• 오류 메시지
• 관련 데이터 키
• 재현 가능 여부
• 동일 오류 반복 여부
• 업무 영향도
• 로그 일부

예를 들어 다음과 같이 전달할 수 있습니다.

“금일 10:32경 주문 조회 메뉴에서 특정 주문번호 조회 시 ERROR 로그가 발생했습니다. 로그상 NullPointerException이 확인되며, 동일 주문번호 기준으로 재현 가능합니다. 해당 데이터 조건 확인 부탁드립니다.”

또는

“재고 송신 배치 실행 중 WARN 로그가 반복된 후 Timeout ERROR가 발생했습니다. 외부 API 응답 지연 가능성이 있어 확인 요청드립니다.”

이렇게 전달하면 담당자가 원인을 파악하기 훨씬 쉽습니다.

단, 로그에 개인정보나 민감정보가 포함되어 있다면 반드시 마스킹해야 합니다.

사용자 전화번호, 이메일, 고객정보, 주문 상세정보, 인증 토큰 등이 그대로 노출되지 않도록 주의해야 합니다.

운영자가 로그 레벨을 공부하는 방법

IT 운영직이나 SM팀 업무를 준비한다면 로그 레벨은 꼭 알아두는 것이 좋습니다.

처음에는 복잡한 로그 분석 도구보다 기본 개념부터 익히면 됩니다.

우선 INFO, WARN, ERROR의 차이를 이해해야 합니다.

그다음 자주 나오는 키워드를 익히면 좋습니다.

• Exception
• Timeout
• Connection
• Permission denied
• File not found
• Invalid parameter
• Duplicate key
• SQL Error
• Response code
• Retry
• Failed
• Success

이 키워드들은 운영 업무에서 자주 보게 됩니다.

또한 회사에서 사용하는 시스템별 로그 위치를 정리해두면 좋습니다.

• 웹서버 로그 위치
• WAS 로그 위치
• 배치 로그 위치
• 인터페이스 로그 위치
• SFTP 송수신 로그 위치
• API 요청/응답 로그 위치

운영 업무에서는 같은 유형의 오류가 반복되는 경우가 많기 때문에, 한 번 확인한 로그 위치와 키워드는 따로 정리해두는 것이 좋습니다.

IT 운영자에게 로그 레벨 이해가 중요한 이유

IT 운영자는 모든 오류를 직접 개발해서 수정하는 사람이 아닐 수 있습니다.

하지만 장애가 발생했을 때 문제의 위치를 빠르게 좁히고, 정확한 담당자에게 전달하는 역할을 해야 합니다.

이때 로그 레벨을 이해하고 있으면 장애 대응이 훨씬 쉬워집니다.

ERROR 로그를 보고 실제 오류 발생 여부를 확인할 수 있고, WARN 로그를 보고 장애 전조를 파악할 수 있습니다.
INFO 로그를 통해 정상 처리 흐름을 확인할 수 있고, DEBUG나 FATAL 로그가 어떤 의미인지도 구분할 수 있습니다.

로그를 잘 본다는 것은 단순히 기술 용어를 많이 아는 것이 아닙니다.

장애 상황에서 필요한 정보를 빠르게 찾고, 업무 영향도를 판단하고, 조치 방향을 정할 수 있다는 뜻입니다.

그래서 로그 레벨 이해는 IT 운영직의 기본 역량 중 하나라고 생각합니다.

마무리

로그에서 ERROR가 보인다고 해서 무조건 전체 장애라고 볼 수는 없습니다.
반대로 WARN만 있다고 해서 가볍게 넘겨도 되는 것도 아닙니다.

INFO는 정상 처리 흐름을 확인하는 데 도움이 되고, WARN은 장애로 이어질 수 있는 경고 신호가 될 수 있습니다.
ERROR는 실제 오류 발생을 의미하며, FATAL은 서비스에 큰 영향을 줄 수 있는 심각한 오류로 볼 수 있습니다.

중요한 것은 로그 레벨만 보는 것이 아니라, 발생 시간, 사용자, 메뉴, 데이터 조건, 반복 여부, 업무 영향도까지 함께 확인하는 것입니다.

IT 운영직이나 SM팀 업무를 준비하고 있다면 로그를 볼 때 먼저 INFO, WARN, ERROR의 의미를 구분하는 습관부터 들여보는 것이 좋습니다.

이전 글에서 정리한 것처럼 로그는 장애 원인 분석의 첫 번째 단서입니다.
그리고 이번 글에서 정리한 로그 레벨은 그 단서를 읽기 위한 기본 언어라고 볼 수 있습니다.

다음 글에서는 로그에서 자주 보이는 서버 오류인 500 오류와 503 오류의 차이를 IT 운영 실무 기준으로 정리해보겠습니다.