모니터링을 믿었는데 왜 또 장애가 났는가
1 views
# 모니터링을 믿었는데 왜 또 장애가 났는가
## 알고 있는 것과 모르는 것 사이
새벽에 호출을 받은 적이 있다. 결제 API가 느려졌다는 보고였다. 대시보드를 열어보니 CPU는 한가했고 메모리에도 여유가 있었다. 5xx 그래프는 평탄했고 데이터베이스 슬로우 쿼리 로그도 조용했다. 모든 지표가 녹색이었다. 그런데 사용자는 결제 버튼을 누른 채 8초를 기다리고 있었다.
이런 밤은 한두 번이 아니었다. 우리는 모니터링을 충실히 했다고 믿었지만, 모니터링은 미리 정의한 질문에만 답할 수 있다. 정의되지 않은 질문 앞에서 대시보드는 침묵한다. 그 침묵은 정상이 아니라, 우리가 그 질문을 한 번도 던진 적이 없다는 신호다.
운영의 본질은 도구의 다과가 아니라 질문의 정밀도에 있다.
## 두 단어의 계보
모니터링(Monitoring)은 라틴어 *monere*에서 유래했다. '경고하다', '상기시키다'라는 뜻이다. 어원이 이미 본질을 드러낸다. 모니터링은 알고 있는 위험에 대해 경고하는 장치다. 임계치를 정하고 그 선을 넘으면 알람을 울린다. 디스크가 90%를 넘거나, 응답 시간이 300ms를 초과하거나, 5분간 에러율이 1%를 넘으면.
여기에는 한 가지 전제가 깔려 있다. 우리가 무엇을 감시해야 하는지 이미 알고 있다는 전제. 시스템이 단순했던 시절에는 이 전제가 합당했다. 모놀리식 애플리케이션, 한 대의 데이터베이스, 정해진 트래픽 패턴. 장애 모드는 유한했고 예측 가능했다.
관찰가능성(Observability)은 1960년대 제어공학자 루돌프 칼만이 정의한 용어다. 시스템의 외부 출력만으로 내부 상태를 얼마나 추론할 수 있는가. 이것이 원래의 정의였다. 소프트웨어 업계가 이 단어를 빌려온 것은 시스템이 더 이상 단순하지 않게 된 이후다. 수십 개의 마이크로서비스, 비동기 메시지 큐, 캐시 계층, 외부 API 의존성. 장애 모드는 무한에 가까워졌다.
차이는 단순하다. 모니터링은 "내가 정한 질문에 답하라"고 말한다. 관찰가능성은 "내가 아직 떠올리지 못한 질문에 답할 준비가 되어 있어라"고 요구한다.
## 도구의 함정
여기서 흔한 오독이 발생한다. 메트릭, 로그, 트레이스라는 세 기둥을 갖추면 관찰가능성이 완성된다는 오독. 벤더의 카탈로그가 이 오독을 부추긴다. APM, 로그 집계, 분산 트레이싱, 프로파일러. 도구 목록은 길어지고 청구서는 무거워지지만 새벽의 호출은 여전히 온다.
도구를 들였다고 능력이 생기지는 않는다. 망원경을 산다고 천문학자가 되지 않는 것과 같다. 관찰가능성은 도구의 집합이 아니라 **시스템에 대해 임의의 질문을 던질 수 있는 상태**다. 핵심은 카디널리티다. 사용자 ID, 요청 ID, 세션 ID, 지역, 클라이언트 버전처럼 값의 종류가 많은 고카디널리티 데이터를 손실 없이 보존하고, 사후에 자유롭게 조합해 새로운 질문을 만들 수 있는가의 문제다.
대부분의 전통적 메트릭 시스템은 카디널리티 폭발 앞에서 무릎을 꿇는다. 그래서 정작 필요한 순간—"왜 안드로이드 14, 7.2.3 버전 앱을 쓰는 서울 강남 지역 사용자만 결제가 느린가"—에 답할 수 없다. 이 질문은 장애가 발생한 다음에야 떠오르기 때문에 미리 대시보드를 만들어둘 수도 없다.
OpenTelemetry가 2020년대 중반에 사실상의 표준으로 자리잡은 것은 이런 문제 의식의 결과다. 벤더에 종속되지 않은 형태로 텔레메트리를 수집하고, 메트릭·로그·트레이스를 단일한 컨텍스트로 묶어내는 시도. 이것은 도구의 진보라기보다 데이터를 잃지 않으려는 운영 철학의 진보에 가깝다.
## 비용이라는 현실
모든 데이터를 영원히 보존할 수는 없다. 분산 시스템이 하루에 생산하는 텔레메트리는 종종 비즈니스 데이터의 수십 배에 달한다. 트레이스 한 건이 수백 개의 스팬을 만들고, 각 스팬은 수십 개의 속성을 갖는다. 비용은 선형이 아니라 폭발적으로 증가한다.
그래서 실무에서는 표본추출(sampling)이 필연이다. 머리에서 자르는 head-based sampling과 꼬리에서 자르는 tail-based sampling이 있다. 후자가 더 정확하지만 더 비싸다. 어떤 트레이스를 살릴 것인가—에러를 포함한 트레이스, 지연이 비정상적으로 긴 트레이스, 특정 사용자의 트레이스—라는 결정 자체가 운영자의 가설을 반영한다.
여기에 모순이 있다. 모르는 질문에 답하기 위해 관찰가능성을 추구하지만, 데이터를 표본화하는 순간 "어떤 질문이 중요한가"라는 가설을 미리 세워야 한다. 완전한 관찰가능성은 경제적으로 불가능하다. 우리는 늘 어떤 맹점을 안고 운영한다.
이 사실을 인정하는 것이 성숙한 운영의 출발점이다. 무한한 관찰을 약속하는 도구는 거짓말을 하고 있거나, 청구서로 진실을 알려줄 것이다.
## 다시, 그 새벽의 결제 API
앞서의 새벽으로 돌아간다. 결국 우리는 분산 트레이스를 따라가 원인을 찾았다. 결제 서비스가 호출하는 외부 PG사 SDK가 특정 카드사 응답을 받을 때 내부적으로 DNS 재조회를 시도하고 있었다. 일부 노드의 DNS 캐시 TTL 설정이 비정상이었고, 그것이 응답 시간의 대부분을 차지했다. CPU도, 메모리도, 애플리케이션 에러도 이 문제를 보여주지 않았다. 트레이스의 한 스팬, *dns.lookup*이라는 이름의 작은 구간만이 진실을 말했다.
이 사건이 가르친 것은 두 가지다.
첫째, 우리는 시스템의 경계를 잘못 알고 있었다. PG사 SDK는 우리 코드처럼 행세했지만 그 안에 우리가 모르는 의존성이 살아 있었다. 시스템의 진짜 경계는 조직도가 그어주지 않는다. 런타임이 그어준다.
둘째, 우리가 만들어둔 대시보드의 모든 항목은 과거의 장애에서 배운 것들이었다. CPU 그래프는 CPU가 문제였던 시절의 유산이고, 메모리 알람은 OOM으로 죽었던 어느 새벽의 기억이다. 우리는 늘 마지막 전쟁을 준비하지만, 다음 전쟁은 다른 모습으로 온다.
## 모니터링과 관찰가능성의 자리
이쯤에서 "모니터링은 낡았고 관찰가능성이 미래다"라는 흔한 결론을 경계할 필요가 있다. 둘은 대체 관계가 아니다.
모니터링은 여전히 필요하다. 알려진 위험에 대한 알람, SLO 기반의 에러 버짓 추적, 인프라 헬스체크. 이런 것들은 24시간 깨어 있는 보초가 되어준다. 보초가 없으면 운영자는 잠들 수 없다. 모니터링은 알려진 미지수(known unknowns)를 다룬다.
관찰가능성은 알려지지 않은 미지수(unknown unknowns)를 다룬다. 사고가 났을 때 임의의 차원에서 데이터를 잘라보고, 가설을 세우고, 검증하는 능력. 이것은 대시보드의 개수가 아니라 데이터의 결합 가능성에 달려 있다.
좋은 운영 체계는 두 층위를 모두 갖춘다. 위층에는 소수의 정제된 SLI/SLO와 알람이 있고, 아래층에는 풍부하고 결합 가능한 원시 텔레메트리가 있다. 위층이 울리면 아래층으로 내려가 답을 찾는다. 위층만 있는 조직은 답을 찾지 못하고, 아래층만 있는 조직은 무엇을 찾아야 할지 모른다.
## 질문의 기술
결국 이 모든 논의는 한 가지로 수렴한다. 운영자의 가장 중요한 역량은 도구 운용이 아니라 질문을 설계하는 능력이다.
좋은 질문은 차원을 가진다. "느리다"가 아니라 "어떤 사용자가, 어떤 경로로, 어떤 시간대에, 어떤 버전에서 느린가". 좋은 질문은 가설을 포함한다. "X가 원인이라면 Y가 관찰되어야 한다"는 형태다. 그리고 좋은 질문은 반증 가능하다. 관찰 결과로 가설을 폐기할 수 있어야 한다.
이것은 과학자의 태도다. 시스템 운영은 본질적으로 경험과학에 가깝다. 통제된 실험실이 아니라 살아 움직이는 프로덕션을 관찰하며, 가설을 세우고 데이터를 수집하고 검증한다. 차이가 있다면 실험 대상이 매출을 발생시키고 있다는 점뿐이다.
도구는 이 과정을 돕는다. 그러나 도구가 질문을 대신 만들어주지는 않는다. 어떤 AIOps도, 어떤 자동 이상탐지도 "왜 이 일이 일어났는가"라는 질문의 무게를 운영자에게서 덜어주지 못한다. 알고리즘은 이상치를 가리킬 수 있지만, 그것이 *왜* 이상한지는 사람이 답해야 한다.
## 닫으며
모니터링은 알고 있는 것을 확인하는 행위다. 관찰가능성은 모르는 것을 발견하는 능력이다. 전자는 어제의 장애로 만들어지고, 후자는 내일의 장애를 위해 준비된다. 둘 다 필요하고, 둘 다 충분하지 않다.
운영자의 자리는 그 사이에 있다. 어제의 교훈을 알람으로 굳히되, 내일의 미지에 대해 질문할 여백을 남겨두는 자리. 도구로 문제를 감추지 않고, 질문으로 문제를 드러내는 자리.
다음 새벽의 호출은 또 다른 얼굴로 올 것이다. 그때 우리가 가진 무기는 더 많은 대시보드가 아니라 더 정밀한 질문이다. 그리고 그 질문에 답할 수 있도록 데이터를 잃지 않고 보존해둔 한 사람의 운영자다.
> 知之爲知之, 不知爲不知, 是知也.
> 아는 것을 안다 하고, 모르는 것을 모른다 하는 것, 그것이 앎이다. — 『논어』 위정
운영의 시작은 그 자리에 있다.