Ⅱ-12. 컴퓨터 시스템 로그 기반 이상징후 분석

컴퓨터 시스템에서 발생하는 장애는 갑자기 나타나는 것처럼 보이지만, 실제로는 장애 발생 이전에 여러 형태의 이상 기록이 남는 경우가 많다.

로그는 이러한 변화를 시간 순서대로 확인할 수 있는 핵심 자료이며, 장애 발생 후 원인을 분석하는 것뿐만 아니라 장애 전조를 찾고 장애가 확대되기 전에 대응하는 데에도 활용할 수 있다.

그러나 로그 분석은 단순히 ERROR, FAIL, TIMEOUT과 같은 오류 문구를 찾는 작업이 아니다.

중요한 것은 정상 상태에서 어떤 로그가 반복되었고, 장애가 발생하기 직전에는 그 패턴이 어떻게 달라졌는지를 확인하는 것이다.

1. 시스템 로그의 역할

로그는 시스템에서 발생한 이벤트를 시간과 함께 기록한 데이터다.

운영체제, 서버, 데이터베이스, 네트워크 장비, 애플리케이션, 보안 시스템 등 다양한 계층에서 생성된다.

로그에는 일반적으로 다음과 같은 정보가 포함될 수 있다.

• 발생 시간
• 이벤트 유형
• 오류 코드
• 발생한 구성요소
• 프로세스 또는 서비스 정보
• 접속 정보
• 처리 결과
• 오류 메시지
• 이벤트 심각도

로그 분석의 핵심은 개별 기록 하나를 보는 것이 아니라 시간의 흐름 속에서 사건이 어떻게 연결되었는지를 확인하는 것이다.

2. 주요 로그의 종류

시스템에서는 여러 계층에서 서로 다른 로그가 생성된다.

대표적으로 다음과 같다.

운영체제 로그

프로세스 종료, 서비스 중단, 디스크 오류, 메모리 관련 오류, 시스템 재부팅 등의 기록을 확인할 수 있다.

특정 오류가 반복되거나 이전에는 거의 나타나지 않던 이벤트가 증가한다면 장애 전조 가능성을 검토할 수 있다.

서버 로그

서버에서는 서비스 상태, 프로세스 오류, 자원 부족, 연결 실패 등의 정보가 기록된다.

특정 프로세스의 오류가 장애 직전 반복되거나 서비스 재시작 횟수가 증가한다면 CPU, 메모리 등의 자원 데이터와 함께 분석할 수 있다.

데이터베이스 로그

접속 오류, 쿼리 실패, 잠금, 트랜잭션 오류, 연결 지연 등의 정보가 기록될 수 있다.

데이터베이스 로그의 변화는 데이터베이스 자체의 문제뿐만 아니라 CPU, 메모리, 저장장치, 네트워크 등의 문제와 연결되어 나타날 수도 있다.

네트워크 로그

연결 실패, 세션 종료, 재전송, 지연, 인터페이스 오류 등의 이벤트를 확인할 수 있다.

특정 시간대에 오류가 집중되거나 여러 장비에서 동시에 유사한 오류가 발생한다면 개별 장비의 문제인지 네트워크 계층의 공통 문제인지 구분해야 한다.

애플리케이션 로그

프로그램 오류, 예외 발생, 요청 실패, 응답 지연 등의 정보가 기록될 수 있다.

특정 오류 코드가 장애 발생 전에 반복된다면 과거 장애 기록과 비교하여 전조 패턴으로 활용할 수 있다.

3. 정상 로그와 이상 로그를 구분해야 한다

모든 오류 로그가 장애 전조인 것은 아니다.

운영환경에서는 일시적인 네트워크 오류나 사용자의 잘못된 요청처럼 정상적인 운영 과정에서도 오류 로그가 발생할 수 있다.

따라서 로그 분석에서는 먼저 정상 운영 시 어떤 로그가 어느 정도 발생하는지를 파악해야 한다.

예를 들어 하루에 수십 번 발생하는 특정 경고가 실제 서비스에 아무런 영향을 주지 않는다면 해당 로그 자체만으로 장애 전조라고 판단하기 어렵다.

반대로 평소에는 발생하지 않던 오류가 짧은 시간 동안 반복되거나 여러 시스템에서 동시에 나타난다면 이상징후로 볼 가능성이 높아진다.

4. 반복되는 로그를 확인해야 한다

하나의 오류보다 같은 오류가 반복되는 것이 더 중요한 정보가 될 수 있다.

예를 들어 특정 프로세스에서 다음과 같은 현상이 반복된다고 가정해 보자.

프로세스 오류 → 자동 재시작 → 다시 오류 → 다시 재시작

개별 오류만 보면 일시적인 문제처럼 보일 수 있다.

그러나 동일한 패턴이 반복된다면 프로세스 자체의 문제나 해당 프로세스가 의존하는 시스템에 문제가 있을 가능성을 조사해야 한다.

따라서 로그 분석에서는 다음 항목을 확인할 수 있다.

• 동일 오류 발생 횟수
• 발생 간격
• 특정 시간대 집중 여부
• 동일 프로세스 반복 여부
• 오류 이후 재시작 여부

5. 로그 발생 빈도의 변화

평소와 비교하여 특정 로그의 발생 빈도가 증가하는 것도 중요한 이상징후가 될 수 있다.

예를 들어 평소 하루에 몇 번 발생하던 연결 실패 로그가 특정 시간부터 수백 건으로 증가했다면 단순한 개별 오류가 아니라 시스템 상태가 변화했을 가능성을 검토해야 한다.

이때는 단순히 총 발생 건수만 확인하지 말고 다음을 함께 분석해야 한다.

• 시간당 발생 건수
• 분당 발생 건수
• 증가 시작 시점
• 증가 속도
• 특정 이벤트와의 동시 발생 여부

즉, 로그의 양이 아니라 로그 발생 패턴의 변화를 확인하는 것이다.

6. 로그의 시간 순서를 재구성해야 한다

장애 원인을 분석할 때 가장 중요한 정보 중 하나가 시간이다.

예를 들어 다음과 같은 로그가 발생했다고 가정할 수 있다.

네트워크 연결 지연
→ 데이터베이스 연결 실패
→ 애플리케이션 요청 실패
→ 서비스 응답시간 증가
→ 서비스 오류 발생

각 로그만 따로 보면 서로 다른 문제처럼 보일 수 있다.

그러나 발생 시간을 순서대로 정렬하면 하나의 장애 전파 과정으로 연결될 가능성을 확인할 수 있다.

따라서 로그 분석에서는 무슨 로그가 발생했는가뿐만 아니라 어떤 로그가 먼저 발생했는가를 확인해야 한다.

7. 여러 시스템의 로그를 함께 분석해야 한다

하나의 시스템 로그만 보면 원인을 잘못 판단할 수 있다.

예를 들어 애플리케이션에서 데이터베이스 연결 실패가 발생했다면 애플리케이션 자체의 문제일 수도 있지만 데이터베이스, 네트워크 또는 인증 시스템의 문제일 수도 있다.

따라서 장애 분석에서는 필요에 따라 다음 로그를 시간 기준으로 함께 비교해야 한다.

• 서버 로그
• 운영체제 로그
• 데이터베이스 로그
• 네트워크 로그
• 애플리케이션 로그
• 인증 시스템 로그

여러 시스템에서 같은 시간대에 관련 이벤트가 발생했다면 개별 시스템의 문제보다 공통된 원인이나 장애 전파 가능성을 검토할 필요가 있다.

8. 로그의 동시 발생을 분석해야 한다

로그가 같은 시간대에 여러 시스템에서 동시에 발생하는 것도 중요한 단서가 될 수 있다.

예를 들어 여러 서버에서 동시에 네트워크 연결 오류가 발생했다면 각각의 서버가 동시에 고장났다고 보기보다 공통 네트워크 경로 또는 공유 인프라의 문제를 먼저 확인하는 것이 합리적일 수 있다.

반대로 특정 서버에서만 오류가 반복된다면 해당 서버의 구성요소나 해당 서버에만 존재하는 의존관계를 확인해야 한다.

따라서 로그 분석에서는

“어디에서 발생했는가?”

뿐만 아니라

“어디에서 동시에 발생했는가?”

를 확인해야 한다.

9. 로그의 순서와 장애 전파를 연결한다

로그는 장애 전파 과정을 추적하는 데에도 활용할 수 있다.

예를 들어 다음과 같은 순서가 반복적으로 확인된다면 장애의 전파 경로를 추정할 수 있다.

저장장치 오류
→ I/O 지연 증가
→ 데이터베이스 처리 지연
→ 애플리케이션 응답 지연
→ 사용자 요청 실패

이러한 분석을 통해 최초 이상징후와 최종 서비스 장애 사이의 관계를 확인할 수 있다.

따라서 로그 분석은 단순한 오류 검색이 아니라 장애가 어느 지점에서 시작되어 어느 방향으로 확대되었는지를 확인하는 과정으로 활용할 수 있다.

10. 오류 코드와 메시지를 그대로 원인으로 판단해서는 안 된다

로그에 기록된 오류 메시지는 중요한 단서이지만 반드시 근본 원인을 의미하는 것은 아니다.

예를 들어 애플리케이션에 Database Connection Failed라는 오류가 기록되었다고 해서 데이터베이스 자체가 고장났다고 단정할 수는 없다.

실제로는 다음과 같은 원인이 있을 수 있다.

• 네트워크 연결 장애
• 인증 실패
• 연결 수 제한
• 데이터베이스 과부하
• DNS 문제
• 방화벽 또는 접근정책 문제

따라서 로그에 기록된 오류는 현상과 원인을 구분하여 해석해야 한다.

이것이 로그 분석에서 가장 중요한 판단 중 하나다.

11. 장애 전조와 로그의 반복 패턴

로그는 장애가 발생하기 전에 반복되는 이상 패턴을 찾는 데 활용할 수 있다.

예를 들어 과거 장애 직전에 다음과 같은 패턴이 반복되었다고 가정해 보자.

경고 증가
→ 동일 오류 반복
→ 프로세스 재시작 증가
→ 응답시간 증가
→ 서비스 장애

이러한 패턴이 여러 장애에서 반복된다면 향후 동일한 변화가 발생했을 때 조기경보 기준으로 활용할 수 있다.

즉, 과거 로그는 단순한 기록이 아니라 향후 장애를 미리 판단하기 위한 기준 데이터가 될 수 있다.

12. 로그와 다른 모니터링 데이터를 함께 비교한다

로그만으로 장애 원인을 확정하기 어려운 경우가 많다.

따라서 로그를 CPU, 메모리, 저장장치, 네트워크, 응답시간 등의 운영 데이터와 함께 비교하면 판단의 정확도를 높일 수 있다.

예를 들어 다음과 같은 상황을 생각할 수 있다.

**CPU 사용률 증가

• 특정 프로세스 오류 증가
• 응답시간 증가**

이 경우 단순히 오류 로그만 확인하는 것보다 세 가지 데이터가 같은 시간대에 변화했다는 사실을 함께 보는 것이 중요하다.

따라서 로그 분석에서는 로그 자체의 의미뿐 아니라 다른 운영 데이터와 시간적으로 연결되는지를 확인해야 한다.

13. 로그 분석에서 오탐과 미탐을 줄여야 한다

로그 기반 이상탐지에서도 모든 오류를 경고 대상으로 설정하면 문제가 발생할 수 있다.

정상적인 상황에서 발생하는 오류까지 모두 경고하면 운영자가 너무 많은 알림을 받게 되고 실제 중요한 경고를 놓칠 수 있다.

반대로 중요한 이상 로그를 무시하면 장애 전조를 놓칠 수 있다.

따라서 로그 분석에서는 다음을 구분할 필요가 있다.

• 정상적으로 반복되는 로그
• 단순 경고
• 조사할 필요가 있는 이상 로그
• 실제 장애와 관련된 로그
• 장애 발생 직전에 반복되는 핵심 로그

좋은 로그 분석은 로그를 많이 찾아내는 것이 아니라 중요한 로그를 구분해내는 것이다.

14. 로그 기반 이상징후 분석의 실제 절차

실제 시스템에서는 다음과 같은 순서로 분석할 수 있다.

1. 주요 시스템과 서비스 선정
2. 관련 로그 종류 확인
3. 정상 상태의 로그 패턴 수집
4. 오류 및 경고 유형 분류
5. 발생 빈도와 시간대 분석
6. 반복되는 로그 확인
7. 로그 발생 순서 재구성
8. 여러 시스템의 로그 비교
9. CPU·메모리·네트워크 등 운영 데이터와 비교
10. 과거 장애 기록과 비교
11. 장애와 관련된 패턴 선별
12. 조기경보 기준 설정
13. 실제 운영환경에서 검증
14. 오탐·미탐 분석
15. 탐지 기준 개선

15. 로그 분석 결과를 장애 원인 분석에 활용한다

로그 분석의 최종 목적은 특정 오류 메시지를 찾는 것이 아니다.

로그를 통해 다음과 같은 질문에 답할 수 있어야 한다.

• 최초 이상징후는 무엇이었는가?
• 언제부터 발생했는가?
• 어느 시스템에서 처음 나타났는가?
• 어떤 오류가 반복되었는가?
• 다른 시스템에서도 동시에 발생했는가?
• 장애는 어떤 순서로 전파되었는가?
• 최종 서비스 장애와 어떤 관계가 있는가?
• 과거 장애에서도 같은 패턴이 나타났는가?

이러한 질문에 답할 수 있다면 로그는 단순한 기록을 넘어 장애의 시간적 흐름을 재구성하는 분석 자료가 된다.

16. 로그 기반 이상징후 분석의 한계

로그가 많다고 해서 장애 원인을 항상 정확하게 찾을 수 있는 것은 아니다.

로그가 기록되지 않았거나 시간 정보가 서로 맞지 않으면 사건의 순서를 정확하게 판단하기 어렵다.

또한 서로 다른 시스템의 로그 형식이나 심각도 기준이 다르면 동일한 사건을 서로 다른 의미로 해석할 수도 있다.

따라서 로그 분석에서는 다음 사항도 확인해야 한다.

• 로그 누락 여부
• 시스템 간 시간 동기화
• 로그 보존기간
• 로그 형식의 일관성
• 로그 수준 설정
• 저장공간 부족 여부
• 중요한 이벤트의 기록 여부

특히 시스템 간 시간이 맞지 않으면 실제로는 연속적으로 발생한 사건이 서로 다른 순서로 보일 수 있다.

따라서 로그의 신뢰성을 먼저 확보한 후 분석해야 한다.

17. 로그 기반 이상징후 분석에서 확인할 핵심 질문

실제 시스템에 적용할 때는 다음 질문을 통해 판단할 수 있다.

1. 우리 시스템에서 장애 직전에 반복적으로 나타나는 로그는 무엇인가?
2. 정상 운영에서도 발생하는 로그와 실제 이상 로그를 구분할 수 있는가?
3. 특정 오류의 발생 빈도가 평소보다 증가하고 있는가?
4. 동일한 오류가 반복되고 있는가?
5. 여러 시스템에서 같은 시간대에 관련 로그가 발생했는가?
6. 최초 로그와 최종 장애 사이의 시간적 순서를 확인할 수 있는가?
7. 로그에 기록된 오류가 실제 원인인지 아니면 결과적인 현상인지 구분했는가?
8. CPU·메모리·네트워크·저장장치 데이터와 같은 시간대에 변화가 있었는가?
9. 과거 장애에서도 동일한 로그 패턴이 나타났는가?
10. 중요한 로그가 누락되지 않고 충분히 보존되고 있는가?
11. 로그에서 발견한 이상징후를 실제 대응으로 연결할 수 있는가?

18. 최종 판단 — 로그는 오류를 찾는 자료가 아니라 장애의 흐름을 재구성하는 자료다

컴퓨터 시스템 로그 분석에서 가장 중요한 것은 오류 메시지를 많이 찾는 것이 아니다.

중요한 것은 정상 상태에서 어떤 로그가 발생했고, 장애가 가까워지면서 무엇이 달라졌으며, 어떤 사건이 어떤 순서로 연결되었는지를 확인하는 것이다.

따라서 로그는 다음과 같은 흐름으로 분석할 필요가 있다.

정상 패턴 확인 → 이상 패턴 발견 → 반복성 확인 → 시간 순서 분석 → 여러 시스템 비교 → 다른 운영 데이터와 대조 → 장애와의 연관성 검증

그리고 여기서 한 단계 더 나아가야 한다.

과거 장애에서 반복적으로 확인된 로그 패턴을 조기탐지 기준으로 활용한다면 로그는 단순한 사후 분석 자료에서 사전 예방 자료로 역할이 확대될 수 있다.

결국 중요한 질문은

“장애가 발생한 뒤 어떤 오류가 남았는가?”

에서 끝나는 것이 아니라,

“장애가 발생하기 전에 어떤 로그가 먼저 변하기 시작했는가?”

를 찾아내는 것이다.

핵심정리

• 로그 분석의 핵심은 오류 문구 하나가 아니라 반복성·시간 순서·동시성·다른 데이터와의 관계를 분석하는 것이다.
• 과거 장애에서 반복된 로그 패턴은 향후 장애를 조기에 발견하기 위한 중요한 기준이 될 수 있다.

결국 로그는 장애가 발생한 뒤 원인을 찾는 기록이면서, 잘 분석하면 장애가 발생하기 전에 위험을 알려주는 데이터가 될 수 있다.