컴퓨터 시스템에서 장애가 발생하면 사용자가 보는 오류 메시지만으로는 원인을 정확하게 파악하기 어려운 경우가 많다.

사용자에게는 단순히 프로그램이 멈추거나 시스템이 재부팅된 것으로 보이지만, 실제로는 그보다 앞서 장치 오류, 서비스 상태 변화, 드라이버 문제, 네트워크 이상 등이 발생했을 수 있다.

이때 중요한 역할을 하는 자료가 시스템 로그다.

로그에는 이벤트가 발생한 시간, 관련 서비스, 장치 상태, 오류 코드, 프로그램 정보 등이 기록될 수 있기 때문에 장애 발생 전후의 상태를 시간 순서로 추적하는 데 활용할 수 있다.

그러나 로그 분석의 목적은 오류 메시지를 하나 찾아내는 것이 아니다.

중요한 것은 여러 기록을 연결하여 무엇이 먼저 변했고, 그 변화가 이후 어떤 증상으로 이어졌으며, 실제 장애와 반복적으로 연결되는지를 확인하는 것이다.

1. 로그 기반 장애 분석의 기본 개념

로그 기반 장애 분석은 장애와 관련된 시스템 기록을 수집하고 시간 순서에 따라 비교하면서 원인 후보를 추적하는 방법이다.

장애가 발생한 순간의 오류만 확인하는 것보다 그 이전에 어떤 상태 변화가 있었는지를 함께 확인하는 것이 중요하다.

예를 들어 시스템이 15시에 갑자기 재부팅되었다면 단순히 재부팅 기록만 확인할 것이 아니라,

• 14시 50분 장치 오류 발생
• 14시 53분 저장장치 응답시간 증가
• 14시 56분 드라이버 오류
• 14시 59분 서비스 응답 지연
• 15시 재부팅

과 같이 장애 이전의 흐름을 구성해 볼 필요가 있다.

이렇게 해야 장애가 발생한 시점과 장애를 유발했을 가능성이 있는 변화가 언제 시작되었는지를 구분할 수 있다.

2. 로그에서 먼저 확인해야 할 정보

로그를 분석할 때는 모든 기록을 처음부터 읽는 것보다 장애와 관련된 핵심 정보를 먼저 정리하는 것이 효율적이다.

주요 확인 항목은 다음과 같다.

• 이벤트 발생 시간
• 이벤트 종류
• 오류 코드
• 관련 장치
• 관련 서비스
• 관련 프로세스
• 오류의 심각도
• 동일 오류의 반복 여부
• 장애 전후의 상태 변화
• 최근 변경 사항과의 관계

특히 발생 시간과 관련 구성요소를 먼저 확인하면 분석 범위를 좁히는 데 도움이 된다.

3. 시간 순서로 로그를 재구성한다

로그 분석에서 가장 중요한 정보 가운데 하나가 시간이다.

장애 원인을 추적할 때는 다음과 같은 흐름으로 기록을 재구성할 수 있다.

정상 상태

→ 경고 또는 상태 변화

→ 성능 변화

→ 오류 발생

→ 서비스 이상

→ 장애 발생

→ 복구

이렇게 시간축을 만들면 각각의 사건이 어떤 순서로 발생했는지 확인할 수 있다.

예를 들어 응용프로그램 오류가 먼저 기록되고 저장장치 오류가 나중에 기록되었다면 단순히 저장장치 오류를 원인으로 판단하기보다 두 사건의 관계를 추가로 조사해야 한다.

따라서 시간 순서는 원인을 확정하는 증거가 아니라 원인 후보의 선후관계를 판단하는 중요한 단서로 활용해야 한다.

4. 장애 직전 로그를 집중적으로 확인한다

장애가 발생한 순간의 오류보다 장애 직전에 나타난 경고나 상태 변화가 더 중요한 경우가 있다.

예를 들어 다음과 같은 흐름이 나타났다고 가정해 보자.

저장장치 응답시간 증가

→ I/O 관련 경고

→ 파일 접근 지연

→ 응용프로그램 오류

→ 서비스 중단

이 경우 서비스 중단이라는 최종 증상만 보는 것보다 그 이전에 저장장치와 I/O 영역에서 어떤 변화가 있었는지를 확인하는 것이 원인 추적에 도움이 된다.

다만 장애 직전에 발생한 로그라고 해서 반드시 원인은 아니다.

장애가 시작되면서 연쇄적으로 발생한 2차 오류일 수도 있기 때문이다.

따라서 장애 직전 로그는 다른 데이터와 함께 검증해야 한다.

5. 하나의 로그보다 여러 로그를 연결한다

하나의 로그만으로는 장애의 전체 흐름을 설명하기 어려운 경우가 많다.

예를 들어 응용프로그램 로그에 “응답 실패”가 기록되었다고 하자.

이 기록만으로는 응용프로그램 자체의 문제인지, 저장장치 지연 때문인지, 네트워크 문제 때문인지 판단하기 어렵다.

따라서 다음과 같은 자료를 함께 비교할 수 있다.

• 시스템 이벤트
• 응용프로그램 로그
• 드라이버 로그
• 저장장치 상태
• CPU 사용률
• 메모리 상태
• I/O 응답시간
• 네트워크 상태
• 프로세스 상태
• 최근 변경 이력

서로 다른 자료에서 같은 시간대에 관련된 변화가 반복적으로 확인된다면 원인 후보를 좁히는 데 도움이 된다.

6. 로그와 성능 데이터를 시간축으로 연결한다

로그만 보면 “무슨 일이 발생했는가”를 알 수 있지만, 성능 데이터와 함께 보면 그 시점에 시스템 상태가 실제로 어떻게 변했는지를 확인할 수 있다.

예를 들어 다음과 같이 정리할 수 있다.

시간	로그	성능 데이터	관찰 내용
10:00	정상	정상 범위	정상 상태
10:12	경고 발생	응답시간 증가	상태 변화 시작
10:15	I/O 오류	I/O 지연 증가	저장장치 관련 이상
10:17	프로그램 오류	응답시간 급증	서비스 영향 발생
10:18	서비스 중단	데이터 수집 중단	장애 발생

이런 방식으로 보면 로그와 성능 데이터가 서로 독립적인 기록이 아니라 하나의 장애 흐름을 설명하는 자료가 될 수 있다.

다만 두 데이터가 같은 시간에 변화했다는 사실만으로 인과관계를 확정해서는 안 된다.

7. 반복되는 로그를 찾는다

동일한 오류가 반복적으로 발생한다면 중요한 조사 대상이 될 수 있다.

특히 다음과 같은 조건이 반복된다면 주의할 필요가 있다.

• 같은 장치에서 반복
• 같은 드라이버에서 반복
• 같은 서비스에서 반복
• 특정 프로그램 실행 후 반복
• 특정 시간대에 반복
• 동일한 성능 변화와 함께 반복
• 장애 발생 전 반복

반복성이 확인되면 단 한 번 발생한 우연한 오류보다 원인 후보로서의 가치가 높아질 수 있다.

하지만 로그 발생 횟수가 많다는 이유만으로 중요도가 높은 것은 아니다.

정상적인 시스템에서도 반복적으로 발생하는 경고가 있을 수 있고, 반대로 한 번만 발생했지만 실제 장애와 직접 연결된 중요한 오류일 수도 있다.

따라서 반복 횟수와 함께 장애와의 시간적 관계와 실제 영향을 확인해야 한다.

8. 오류 로그와 경고 로그를 구분해서 본다

로그의 심각도만 보고 중요도를 판단하면 안 된다.

오류로 기록된 이벤트라도 정상적인 예외 상황에서 발생할 수 있고, 경고로 기록된 이벤트가 실제 장애의 전조일 수도 있다.

따라서 다음과 같은 질문이 필요하다.

• 이 로그는 정상적인 운영에서도 발생하는가?
• 장애 발생 전에 반복되는가?
• 특정 성능 변화와 함께 나타나는가?
• 장애가 발생하지 않은 경우에도 같은 로그가 나타나는가?
• 해당 로그 이후 실제 서비스 영향이 발생했는가?

결국 중요한 것은 로그에 표시된 “ERROR”, “WARNING”이라는 단어 자체가 아니라 그 기록이 실제 시스템 상태와 어떤 관계를 가지고 있는가이다.

9. 로그가 없다는 사실도 신중하게 해석해야 한다

장애가 발생했는데 관련 로그가 보이지 않는 경우도 있다.

그렇다고 반드시 해당 이벤트가 발생하지 않았다고 판단해서는 안 된다.

가능한 원인은 다음과 같다.

• 로그 수집 수준이 낮음
• 로그 기록 기능이 비활성화됨
• 장애 발생 과정에서 로그 기록이 중단됨
• 로그 저장 공간 부족
• 다른 시스템에 기록됨
• 시간 범위가 잘못 설정됨
• 로그가 다른 형태로 기록됨

따라서 로그가 없다는 사실과 사건이 없었다는 사실은 동일하지 않다.

로그의 존재뿐 아니라 로그 수집 구조와 저장 상태도 함께 확인해야 한다.

10. 여러 시스템의 시간을 맞춰야 한다

여러 시스템의 로그를 함께 분석할 때는 시간 동기화가 매우 중요하다.

예를 들어 서버에서는 10시 00분에 오류가 기록되고 네트워크 장비에서는 09시 59분에 관련 이벤트가 기록되었다고 하자.

두 시스템의 시간이 정확하게 동기화되어 있지 않다면 실제로는 동시에 발생한 사건을 잘못된 순서로 해석할 수 있다.

따라서 장애 분석에서는 가능하면 다음을 확인해야 한다.

• 시스템 시간
• 시간대 설정
• NTP 등 시간 동기화 상태
• 로그의 타임스탬프 기준
• 서버와 장비 사이의 시간 차이

시간이 맞지 않으면 로그를 정확하게 연결해도 잘못된 결론에 도달할 수 있다.

11. 로그를 장애 범위와 함께 분석한다

로그에 오류가 기록되었다고 해서 반드시 전체 시스템 장애를 의미하는 것은 아니다.

예를 들어 특정 애플리케이션에서 오류가 반복되지만 다른 서비스는 정상적으로 작동할 수 있다.

반대로 여러 서버에서 동일한 시간대에 유사한 오류가 발생한다면 공통 인프라나 공통 변경 사항을 조사할 필요가 있다.

따라서 로그 분석에서도 다음을 함께 확인해야 한다.

한 시스템만 발생했는가?

같은 서비스의 여러 시스템에서 발생했는가?

동일 네트워크의 여러 장비에서 발생했는가?

공통된 변경 이후 동시에 발생했는가?

이렇게 보면 로그를 단순한 개별 장비 기록이 아니라 장애의 영향 범위를 판단하는 자료로 활용할 수 있다.

12. 로그와 최근 변경 사항을 연결한다

장애가 발생하기 직전에 다음과 같은 변경이 있었다면 로그와 함께 비교할 필요가 있다.

• 운영체제 업데이트
• 드라이버 업데이트
• 응용프로그램 업데이트
• 보안 정책 변경
• 네트워크 설정 변경
• 하드웨어 교체
• 서비스 설정 변경

예를 들어 특정 드라이버 업데이트 이후 동일한 오류 로그가 반복적으로 발생한다면 해당 변경은 중요한 조사 대상이 된다.

그러나 변경 직후 발생했다는 이유만으로 원인이라고 확정해서는 안 된다.

변경과 장애 사이의 관계를 확인하려면 변경 전후의 로그, 성능 상태, 재현 여부를 함께 비교해야 한다.

13. 로그에서 원인과 결과를 구분한다

장애가 발생하면 하나의 원인이 여러 오류를 연속적으로 발생시킬 수 있다.

예를 들어 저장장치 오류가 먼저 발생한 후 다음과 같은 오류가 연쇄적으로 나타날 수 있다.

저장장치 오류

→ 파일 접근 실패

→ 서비스 오류

→ 응용프로그램 오류

→ 사용자 요청 실패

이때 마지막에 가장 많은 오류가 발생했다고 해서 응용프로그램이 근본 원인이라고 판단해서는 안 된다.

반대로 저장장치 오류가 있었다고 해서 무조건 저장장치가 최초 원인이라고 확정할 수도 없다.

따라서 로그 분석에서는 “이 오류가 이전 오류의 결과일 가능성은 없는가?”를 계속 확인해야 한다.

14. 로그 기반 원인 추적의 실제 절차

실제 장애가 발생했을 때는 다음과 같은 순서로 분석할 수 있다.

① 장애 발생 시각 확인

→ 사용자 증상과 서비스 중단 시점을 기록한다.

② 장애 전 구간 확보

→ 장애 직전 일정 시간의 로그와 성능 데이터를 확보한다.

③ 시간 동기화 확인

→ 여러 시스템의 시간 기준이 일치하는지 확인한다.

④ 관련 로그 분류

→ 시스템·드라이버·응용프로그램·네트워크 등으로 나눈다.

⑤ 시간 순서 재구성

→ 정상 → 경고 → 이상 → 오류 → 장애 → 복구 순서로 정리한다.

⑥ 성능 데이터 연결

→ CPU·메모리·I/O·네트워크 등의 변화를 같은 시간축에 배치한다.

⑦ 반복성 확인

→ 동일 오류가 과거에도 발생했는지 확인한다.

⑧ 정상 사례와 비교

→ 장애가 발생하지 않은 경우에도 같은 로그가 나타나는지 확인한다.

⑨ 원인 후보 설정

→ 시간 관계와 데이터에 근거해 원인 후보를 좁힌다.

⑩ 추가 검증

→ 변경 이력, 장치 상태, 재현 테스트 등을 이용해 후보를 검증한다.

⑪ 원인과 결과 구분

→ 최초 원인인지 2차적으로 발생한 오류인지 확인한다.

⑫ 복구 후 재발 여부 확인

→ 동일 조건에서 문제가 다시 발생하는지 확인한다.

15. 로그 분석에서 흔히 발생하는 판단 오류

로그 기반 장애 분석에서는 다음과 같은 오류를 피해야 한다.

① 가장 마지막 오류를 원인으로 판단

장애가 발생하면서 연쇄적으로 생성된 2차 오류일 수 있다.

② ERROR 로그를 무조건 원인으로 판단

정상 운영에서도 발생하는 오류일 수 있다.

③ 가장 많이 발생한 로그를 가장 중요한 원인으로 판단

반복 횟수와 장애 영향은 같은 의미가 아니다.

④ 로그가 없으므로 문제가 없었다고 판단

수집 설정이나 기록 실패 가능성을 고려해야 한다.

⑤ 시간 순서만으로 인과관계를 확정

먼저 발생했다는 사실은 원인 가능성을 높이는 단서일 뿐 확정 증거는 아니다.

⑥ 하나의 시스템 로그만 보고 결론

다른 시스템·성능 데이터·변경 이력과 연결해야 한다.

이러한 판단 오류를 줄이는 것이 로그 분석의 정확도를 높이는 핵심이다.

16. 로그 분석의 한계

로그는 매우 중요한 장애 분석 자료지만 모든 문제를 설명해 주는 것은 아니다.

다음과 같은 경우에는 로그만으로 원인을 확인하기 어려울 수 있다.

• 로그 수집이 충분하지 않은 경우
• 장애와 동시에 시스템이 중단된 경우
• 하드웨어 오류가 정상적으로 기록되지 않은 경우
• 로그가 손상되거나 유실된 경우
• 여러 시스템의 시간이 일치하지 않는 경우
• 새로운 장애 유형이 발생한 경우
• 로그는 존재하지만 원인과 결과가 구분되지 않는 경우

따라서 로그는 성능 데이터, 하드웨어 상태, 네트워크 상태, 변경 이력, 진단 결과와 함께 사용해야 한다.

로그는 장애 원인을 자동으로 알려주는 자료가 아니라 원인을 추적할 수 있는 중요한 증거 중 하나라고 보는 것이 정확하다.

17. Ⅴ-1과 Ⅴ-2에서 Ⅴ-3으로 연결되는 구조

Ⅴ장의 앞부분을 연결해서 보면 각각의 역할이 분명해진다.

구분	핵심 질문
Ⅴ-1. 장애 진단 절차와 원인 추적	장애가 발생했을 때 어떤 순서로 원인을 좁혀갈 것인가?
Ⅴ-2. 하드웨어·소프트웨어 구분	원인 후보가 어느 영역에 있는지 어떻게 좁힐 것인가?
Ⅴ-3. 시스템 로그 기반 원인 추적	시간에 따라 어떤 사건이 먼저 발생했고 서로 어떻게 연결되는가?

즉 Ⅴ-1에서 전체 진단 절차를 만들고, Ⅴ-2에서 원인 영역을 좁히고, Ⅴ-3에서 로그를 이용해 시간축과 사건의 연결관계를 추적하는 구조가 된다.

18. 핵심 정리

로그 기반 장애 분석의 목적은 ERROR나 WARNING이라는 단어를 찾아내는 것이 아니다.

중요한 것은 장애 전후의 로그를 시간 순서로 재구성하고, 성능 데이터와 다른 시스템의 기록을 연결하여 무엇이 먼저 변했고 그 변화가 실제 장애와 어떤 관계를 가지고 있는지 확인하는 것이다.

특히 다음 세 가지를 기억할 필요가 있다.

장애 시점의 로그보다 장애 직전의 변화가 더 중요한 단서가 될 수 있다.

가장 먼저 기록된 이상이 반드시 근본 원인은 아니며, 가장 많이 발생한 오류가 반드시 가장 중요한 원인도 아니다.

로그는 단독으로 결론을 내리는 자료가 아니라 성능·하드웨어·네트워크·변경 이력과 연결하여 원인을 검증하는 증거다.

마지막으로 자신의 시스템을 생각해 보자.

장애가 발생했을 때 우리는 마지막으로 기록된 오류를 찾고 끝내고 있는가, 아니면 장애가 발생하기 전부터 어떤 변화가 시작되었는지를 추적하고 있는가?

그리고 서로 다른 시스템의 로그를 하나의 시간축으로 정확하게 연결할 수 있는 상태인가?