로그에 답이 있다. 다만 충분히 빨리 찾지 못할 뿐이다.

Source: Dev.to

3주 전, 우리가 함께 일하는 팀 중 하나가 결제(체크아웃) 장애를 겪었습니다. 원인은 40분 전에 배포된 잘못된 데이터베이스 쿼리였으며, 그 쿼리는 전체 기간 동안 CloudWatch 로그에 타임스탬프와 스택 트레이스와 함께 명확히 남아 있었습니다.
알림이 발생한 뒤 22분 만에 그 원인을 찾았습니다.
그 이유는 엔지니어가 로그를 찾는 위치를 잘못 잡았기 때문이었습니다. 체크아웃 서비스는 CloudWatch에 로그를 남기지만, 체크아웃으로 라우팅되는 API 게이트웨이는 Elasticsearch에 로그를 남깁니다. 콜을 받고 있던 엔지니어는 어느 로그가 어느 곳에 있는지 기억하지 못했습니다. 그래서 먼저 Elasticsearch에서 8분을 검색했지만 관련 로그를 찾지 못했고, CloudWatch로 전환해 쿼리 문법을 맞추는 데 6분, 시간 창을 좁혀 특정 오류를 찾는 데 또 8분을 소비했습니다.
총 22분. 로그 라인은 처음부터 그 자리 있었던 겁니다.

이 이야기는 나쁜 엔지니어나 나쁜 도구에 대한 것이 아니라, 사고 데이터가 서로 소통하지 못하는 여러 플랫폼에 흩어져 있을 때 발생하는 문제에 대한 이야기입니다.
마지막 사고의 근본 원인은 알림이 울린 뒤 몇 분 안에 로그에 있었을 가능성이 높습니다. 엔지니어가 20분 뒤에 찾은 이유는 먼저 잘못된 플랫폼을 검색했기 때문이죠.

세 개의 로깅 플랫폼을 운영하기로 누가 결정한 건 아닙니다. 서로 다른 팀이 2년에 걸쳐 서로 다른 도구를 선택하면서 자연스럽게 생긴 현상이며, 어느 순간 체크아웃은 CloudWatch에, 결제는 Elasticsearch에 로그를 남기게 되고, 이를 연결해줄 지도는 없게 됩니다.

사고 발생 시 로그 검색은 평소 디버깅과 전혀 다릅니다. 한 달에 한 번 쓰는 문법으로 쿼리를 추측하고, 아직 정확히 정의되지 않은 문제를 찾으려 애쓰는 와중에 Slack은 상태 업데이트를 요구합니다.

Steadwing은 6개의 지원 로깅 플랫폼—CloudWatch, Elasticsearch, Loki, GCP Logging, Mezmo, Scalyr—을 동시에 검색합니다. 알림 타임스탬프, 최근 배포, 메트릭 이상치를 기준으로 범위를 잡아 13~22분 걸리던 수작업 탐색을 약 30초로 단축합니다.

하나의 로깅 플랫폼으로 마이그레이션할 필요는 없습니다. 그 프로젝트는 1년이 걸리며 대부분의 팀이 끝내지 못합니다. 필요한 것은 사고가 발생했을 때 기존 플랫폼들을 하나의 시스템처럼 검색할 수 있게 하는 것입니다.

보통 이런 상황이 어떻게 발생하는지 살펴보면, 처음엔 AWS를 사용하므로 CloudWatch에 로그를 남기고, 데이터 팀이 애플리케이션 이벤트에 대한 전체 텍스트 검색이 필요해 Elasticsearch를 도입하고, 플랫폼 팀이 가볍고 Grafana와 잘 맞는 Loki를 추가하고, GCP에서 동작하는 몇몇 서비스는 GCP Cloud Logging을 사용하게 됩니다.

네 개의 로깅 플랫폼을 운영하기로 회의실에서 결정한 적은 없습니다. 2년에 걸쳐 점진적으로 도입되었고, 그때가 되면 각 플랫폼마다 서비스, 보존 정책, 쿼리 언어, 그리고 이를 다루는 사람이 달라집니다.

Dash0의 2025년 분석이 이를 정확히 짚고 있습니다: “로그가 서로 연결되지 않은 도구에 흩어져 있으면 조사 속도가 느려지고 중요한 신호가 잡음에 묻힌다.” 하지만 “하나의 플랫폼으로 통합한다”는 일반적인 조언은 여러 분기에 걸친 마이그레이션을 요구하고, 대부분의 팀이 끝내지 못합니다. 또한 현재 진행 중인 사고에는 전혀 도움이 되지 않습니다.

대부분의 엔지니어링 팀에게 현실적인 상황은 로그가 여러 곳에 존재한다는 점이며, 문제는 이를 어떻게 해결하느냐가 아니라 P0 상황에서 이것이 의미 없게 만드는 방법을 찾는 것입니다.

엔지니어가 오류가 발생한 서비스에 대한 페이지를 받았을 때 일어나는 일

1. 어디서 찾아야 할지 파악

   • 어떤 서비스가 영향을 받았는가? 그 서비스는 어느 플랫폼에 로그를 남기는가? 여러 서비스가 연쇄적으로 실패한다면 로그가 두세 개의 플랫폼에 흩어져 있을 수 있습니다. 엔지니어가 기억하고 있으면 바로 알지만, 모르면 위키를 확인하게 되는데 위키가 최신인지 확신할 수 없습니다.

2. 쿼리 자체

   • CloudWatch Logs Insights, LogQL, Elasticsearch DSL, GCP Logging Query Language 등 각각 고유한 문법을 가지고 있습니다. 엔지니어는 한 달에 한 번 쓰는 언어로 쿼리를 작성하고, 필드명을 오타 검사하고, 결과를 기다리며, 아무것도 나오지 않으면 시간 창을 조정하고 다시 시도합니다. 미들웨어 연구에서는 “실제로 로그 설정을 만든 엔지니어만이 어떻게 쿼리해야 하는지 안다”고 직설적으로 말합니다.

3. 시간 범위

   • 알림이 2시 47분에 울렸지만 실제 문제는 2시 30분, 혹은 2시 00분에 시작됐을 수 있습니다. 엔지니어는 창을 잡고 기대합니다. 너무 좁으면 원인을 놓치고, 너무 넓으면 수천 줄의 무관한 로그를 스크롤하며 중요한 라인을 찾기 어렵습니다.

4. 맥락 없는 로그 검색

   • 엔지니어가 “timeout”, “500 error”, “connection refused” 같은 키워드를 검색창에 입력하고 관련 결과가 나오길 기대합니다. 하지만 가장 유용한 로그 검색은 이미 찾고자 하는 것이 무엇인지 안 경우에 일어납니다. 사고 중에는 아직 무엇을 찾아야 할지 모릅니다. 배포가 무엇을 바꿨는지, 어떤 메트릭이 언제 급등했는지, 어떤 알림이 어떤 서비스와 연관되는지 모르면 검색이 초점 없이 돌아갑니다.

이러한 이유로 일반적인 사고에서 로그 조사는 13~22분이 걸립니다. 도구가 느린 것이 아니라 인간이 플랫폼 파편화, 쿼리 문법, 시간 창 모호성, 맥락 부재를 동시에 해결해야 하기 때문입니다. 압박 속에서 Slack은 계속 업데이트를 요구합니다.

또 하나의 악순환

다중 엔지니어가 동시에 사고에 대응할 때, 두세 명이 각각 독립적으로 로그를 검색합니다. 엔지니어 A는 CloudWatch를 열고, 엔지니어 B도 CloudWatch를 엽니다. 서로 비슷한 쿼리를 약간 다른 파라미터로 실행하지만, 서로가 같은 작업을 하고 있다는 사실을 모릅니다.

누군가가 결국 관련 로그 라인을 찾으면 Slack에 붙여넣습니다. 그때까지 다른 엔지니어들은 이미 510분을 중복 검색에 소비한 것이죠. 팀 전체로 보면 1520분의 엔지니어링 시간이 한 번만 하면 되는 작업에 낭비됩니다.

이것은 협업 실패가 아니라 도구의 격차입니다. 로그 검색이 한 번만 자동으로 실행되고 결과가 모두에게 전달된다면 중복은 완전히 사라집니다.

Steadwing은 AWS CloudWatch, GCP Cloud Logging, Elasticsearch, Mezmo, Scalyr, Grafana Loki 등 6개의 로깅 플랫폼에 연결합니다.

조사가 트리거되면 하나씩 검색하지 않고, PagerDuty 알림 타임스탬프, GitHub 최근 배포 데이터, Datadog 메트릭 이상치를 활용해 모든 연결된 플랫폼을 동시에 쿼리합니다.

엔지니어는 플랫폼을 선택하지 않고, 쿼리를 작성하지 않으며, 시간 범위를 추측하지도 않습니다. 관련 로그 라인은 RCA에 타임스탬프