관찰 가능성이 사건 원인을 설명하지 못하는 이유
관찰 가능성(Observability) 도구는 시스템에서 ‘무슨 일이 일어나고 있는지’를 실시간으로 보여주지만, ‘왜 그런 일이 발생했는지’와 근본 원인을 설명하지 못한다는 점을 지적한다. 인프라 메트릭과 별도로 존재하는 배포 이력, 고객 지원 사례, 변경 기록 등을 수작업으로 연결해야 하는 조사 과정의 비효율성을 강조하며, 운영 비용 증가의 주요 원인으로 분석한다.
지난 1년 동안 비슷한 대화를 30번도 넘게 들었다. 엔지니어링 VP나 선임 SRE가 자신의 관찰 가능성 스택을 설명한다. 구축한 대시보드, 세밀하게 조정한 알림, 수개월 동안 완성한 Datadog나 Grafana 설정을 자랑한다. 그러고 나서 최근 발생한 주요 장애를 이야기한다. 알림이 몇 초 만에 울렸고, 대시보드가 정확히 어디서 성능이 떨어지는지 보여줬는데도 팀은 원인을 파악하는 데 2~3시간을 소비해야 했다는 것이다.
가장 자주 듣는 표현은 대략 이렇다. “우리는 모든 것을 볼 수 있다. 다만 설명할 수 없을 뿐이다.” 보는 것과 설명하는 것 사이의 이 간극은 파고들 가치가 있다. 이는 운영 분야에서 조용히 가장 비용이 많이 드는 문제 중 하나가 되었기 때문이다.
관찰 가능성이 답하도록 설계된 질문
관찰 가능성 도구는 본래 목적에 매우 뛰어나다. 시스템 내부에서 일어나는 일을 드러낸다. 지연 시간 급증, 오류율, 자원 고갈, 의존성 실패 등을 실시간으로 대규모로 보여준다. 이 능력은 기본 중의 기본이다. 이것이 없다면 고객이 알려줄 때까지 문제가 발생한 줄도 모른다.
하지만 관찰 가능성은 특정 질문, 즉 ‘지금 시스템 내부에서 무슨 일이 일어나고 있는가?’에 초점을 맞춰 만들어졌다. 이 질문에는 잘 답한다. 반면 ‘왜 이런 일이 일어나는가, 무엇이 이를 촉발했는가?’라는 질문은 대부분 그 범위를 벗어난다. 두 질문은 비슷하게 들리지만 완전히 다르다.
‘무슨 일이 일어나고 있는가’는 인프라 계층, 즉 메트릭, 트레이스, 로그에 존재한다. 관찰 가능성 스택이 이를 포착한다. ‘왜 일어나는가’는 대개 인프라 밖에 있다. 이틀 전에 배포된 코드, 알림이 울리기 전에 급증한 지원 큐, 지난 스프린트에서 엔지니어링이 승인한 변경 기록 등이다. 그 맥락은 텔레메트리에 포함되지 않았고, 원래부터 포함될 의도도 없었다.
수정에 앞서는 조사 과정
고객에게 영향을 주는 장애가 발생하면, 그 원인을 설명해줄 정보는 거의 한 곳에 모여 있지 않다. 엔지니어링은 인프라 신호를 본다. 시스템이 무엇을 하고 있는지는 알지만, 어떤 고객이 영향을 받았는지, 모니터링 알림이 울리기 전에 고객들이 무엇을 보고했는지는 모른다. 지원팀은 고객이 기술 용어로 표현하지 못한 증상을 평이한 언어로 적은 사례와 불만을 가지고 있다. 지원팀은 종종 엔지니어링보다 먼저 문제를 인지하지만, 배포 이력은 그들이 검색할 수 있는 시스템이 아니다.
Jira나 CI/CD 파이프라인 어딘가에는 언제 무엇이 변경되었는지, 타임스탬프, 작성자, 범위가 기록되어 있다. 그 기록은 지원 사례나 이상 징후를 알지 못한다. 따라서 누군가는 이 모든 것을 수작업으로 연결해야 한다. 고객 불만을 읽고, 배포 이력과 대조하며, 여러 시스템을 동시에 머릿속에 담아 패턴이 드러날 때까지 유지한다. 이것이 실제 조사 과정이다. 문제를 해결하는 것이 아니라