로그를 읽는 순서가 복구 속도를 좌우하는가?

장애 발생 후 "무엇이 언제 깨졌는가"를 찾아내는 방식은 크게 두 가지다. 하나는 뒤섞인 로그를 시간순으로 정렬해 사건의 순서를 따라가는 방법(타임라인 복원), 다른 하나는 여러 시스템의 로그에서 패턴을 연결해 인과관계를 도출하는 방법(로그 상관 분석)이다. 우리는 이 분석 리서치에서 두 기법의 실제 작동 원리와 적용 조건을 뜯어봤다.

핵심 판단:

  • 단일 호스트·서비스 장애는 타임라인 복원만으로 충분하지만, 분산 시스템의 연쇄 장애는 타임라인 + 상관 분석 병행이 필수다.
  • 타임라인 복원은 "언제"를 답하고, 상관 분석은 "왜"를 답한다.
  • 로그 통합 플랫폼 없이 상관 분석을 수작업으로 하면 재현 시간이 3배 이상 늘어난다.
  • 타임스탬프 편차(시계 동기화 오차)가 10초 이상이면 두 기법 모두 신뢰도가 떨어진다.
  • 선택은 장애의 범위(단일 vs. 분산)와 로그 보관 정책에 따라 결정된다.

시간순 정렬만으로 원인을 찾을 수 있는가?

타임라인 복원은 단일 시스템 내에서 이벤트의 순서를 재구성하는 기법이다. 파일 생성, 프로세스 실행, 네트워크 통신, 메모리 할당 같은 모든 활동을 타임스탬프 기준으로 정렬하면, 사건의 선후관계가 명확해진다. 예를 들어 "애플리케이션 시작 10초 후 데이터베이스 쿼리 실패"라는 패턴을 발견할 수 있다.

하지만 이 방식은 단일 호스트 내 국소적 인과관계만 보여준다. API 게이트웨이의 타임라인, 백엔드 서버의 타임라인, 데이터베이스의 타임라인이 각각 존재할 때, 이들 간의 "누가 누구를 기다렸는가" "누가 먼저 실패했는가"는 타임라인 정렬만으로는 파악할 수 없다. 타임라인 분석의 기본 원리에 따르면 단일 장비 내 파일 접근·생성·삭제 흔적만 정렬해도 상당 부분의 인과관계를 재구성할 수 있지만, 이는 폐쇄된 시스템에서만 성립한다.

분산 환경에서는 각 노드의 타임라인을 먼저 생성한 후, 그 타임라인들 사이의 관계를 찾아야 한다. 이 단계를 건너뛰면 진단은 "A 서버에서 오류가 일어났다"는 수준에 머문다.

여러 호스트의 로그를 한 줄로 엮는 방법은?

로그 상관 분석은 서로 다른 시스템의 로그 이벤트들 사이의 관계를 찾아내는 작업이다. API 게이트웨이가 백엔드 서버로 요청을 보내면, 게이트웨이 로그에는 "요청 발송"이, 백엔드 로그에는 "요청 수신"이 기록된다. 두 로그의 타임스탬프, 요청 ID, 클라이언트 IP 등을 대조하면 "이 게이트웨이의 요청이 저 백엔드에서 처리되었다"는 관계를 확립할 수 있다.

로그 상관 분석의 기본 원칙에 따르면, 이 과정은 다음과 같이 진행된다:

  1. 타임스탬프 윈도우 설정: 예를 들어 "±2초 이내에 발생한 이벤트"를 같은 사건으로 묶는다.
  2. 필드 매칭: 요청 ID, 세션 ID, 사용자 ID 등 공통 필드로 연결한다.
  3. 패턴 규칙 적용: "요청 발송 → 처리 → 응답 반환"이라는 순차 패턴이 맞는지 검증한다.
  4. 이상 탐지: 요청은 발송됐는데 응답이 없거나, 타임스탬프 순서가 뒤바뀐 경우를 플래그한다.

수작업으로 이를 수행하면 매우 느리다. 로그가 1,000만 줄이고 호스트가 10개라면, 전체 상관 관계를 손으로 구성하는 것은 비현실적이다. 따라서 상관 분석은 통합 로그 플랫폼(ELK, Splunk, Datadog 등)의 자동화 규칙에 의존하는 경향이 강하다.

타임라인 복원과 상관 분석, 언제 택할 것인가?

조건 타임라인 복원 우선 상관 분석 우선
장애 범위 단일 호스트, 단일 애플리케이션 마이크로서비스, 분산 시스템
로그 통합 비필수 필수 (수작업 시 시간 폭증)
진단 깊이 "무엇이 깨졌는가" "왜 깨졌는가" (인과관계)
타임스탬프 정확도 ±1초 이상 편차 허용 ±100ms 이내 동기 필요
재현 시간 2~4시간 4~8시간 (수작업) / 30분 (자동화)
필요한 기술 파일 시스템 분석, 로그 뷰어 상관 규칙 엔진, 시각화 도구

구글 지도의 2025년 데이터 손실 사건에서도 이 구분이 드러났다. 사용자의 타임라인 데이터가 사라졌을 때, 구글 엔지니어들은 먼저 각 컴포넌트(프론트엔드, 백엔드, 데이터베이스, 캐시)의 로그를 시간순으로 정렬해 "3월 7일 언제 데이터가 삭제되었는가"를 특정했다. 그 후 Import 기능 업데이트 → 백엔드 호출 → 데이터베이스 쓰기 → 동기화 실패라는 연쇄를 추적했다. 전자가 타임라인 복원, 후자가 상관 분석이었다.

이 두 기법을 언제 모두 써야 하는가?

실제로는 둘을 순차적으로 적용하는 것이 표준이다. 장애 신고 직후 타임라인 복원으로 "언제, 어느 시스템에서"를 빠르게 좁혀놓은 후, 상관 분석으로 "왜, 무엇이 트리거했는가"를 파고든다.

타임스탐프 편차가 크면(10초 이상) 두 기법의 신뢰도가 동시에 떨어진다. 이 경우 NTP(Network Time Protocol) 동기화를 먼저 점검하거나, 상관 분석의 윈도우를 넓혀야 한다. 예를 들어 "±2초"를 "±10초"로 설정하면 오탐이 증가한다.

로그 보관 정책도 중요하다. 타임라인 복원은 단일 호스트의 로그만 필요하므로 로컬 저장소의 로그로도 가능하지만, 상관 분석은 모든 관련 시스템의 로그를 중앙 집약해야 한다. 만약 마이크로서비스 아키텍처에서 일부 서비스의 로그만 보관하고 있다면, 상관 분석은 불완전해진다.

핵심 정리

  • 타임라인 복원: 단일 시스템 내에서 이벤트를 시간순으로 정렬해 사건의 선후관계를 파악하는 기법. 빠르지만 분산 환경에서의 인과관계는 보여주지 못한다.
  • 로그 상관 분석: 여러 호스트·서비스의 로그에서 공통 필드(요청 ID, 사용자 ID 등)와 타임스탬프 윈도우를 통해 이벤트 간 관계를 도출하는 기법. 정확하지만 수작업 시 3배 이상 시간이 걸린다.
  • 실무 전략: 단일 호스트 장애는 타임라인만, 분산 시스템 장애는 둘을 순차적으로 적용. 로그 통합 플랫폼 없으면 상관 분석의 재현 속도가 급격히 떨어진다.
  • 전제 조건: 타임스탬프 편차 ±10초 이상이면 두 기법 모두 신뢰도 저하. 각 호스트의 시계 동기화는 필수.
  • 선택 기준: 장애의 범위(단일 vs. 분산), 로그 보관 정책(중앙 vs. 분산), 타임스탬프 정확도에 따라 결정. 정답은 없으며, 스택과 환경에 따라 달라진다.

참고 자료

더 알아보기

장애 사후분석: 타임라인·근본원인·재발 방지의 방법론 — 이 주제의 종합 가이드