모니터링은 대시보드 하나가 아니었다: 숫자를 보는 RUM, 신호를 읽는 AI 스킬

내부 비공개 저장소와 협업 도구에서 진행한 작업을 바탕으로 썼다. 조직과 서비스를 식별할 수 있는 이름, 채널, 주소, 티켓 번호는 걷어냈고 수치는 맥락을 해치지 않는 범위에서 근삿값으로 표현했다.

체크아웃 성능을 1초 아래로 줄이려다 만난 세 개의 벽은 이런 문장으로 끝났다.

로컬 실험의 숫자는 운영 사용자의 분포가 아니다. 최종 효과는 운영 환경의 실사용자 모니터링(Real User Monitoring, RUM)으로 확인해야 한다.

쓰기는 쉬운 문장이었다. 실제로 옮기려니 바로 다음 질문이 생겼다.

운영에서 무엇을 봐야 하지?

기존에도 대시보드는 있었다. 서버의 응답 시간과 오류율을 보여줬고, 체크아웃 주소로 들어오는 요청도 검색할 수 있었다. 그런데 Android WebView에서 반복되던 document.cookie 접근을 줄인 뒤 그 대시보드를 봐도 눈에 띄는 변화가 없었다.

처음에는 수정 효과가 작았나 싶었다. 조금 더 들여다보니 문제는 효과의 크기가 아니었다. 내가 고친 곳과 보고 있던 계기판이 서로 다른 층을 측정하고 있었다.

그날은 결국 두 종류의 모니터링을 만들었다.

브라우저 안에서 일어난 성능 변화를 확인하는 RUM 대시보드
고객 제보, 오류 알림, 배포와 변경 이력 사이의 약한 신호를 모으는 읽기 전용 AI 스킬

하나는 숫자를 보고, 다른 하나는 맥락을 읽는다. 처음에는 서로 다른 작업이라고 생각했다. 만들고 나니 둘은 같은 질문에 답하고 있었다.

무슨 일이 일어났을 때, 다음 판단에 필요한 증거를 어떻게 미리 준비할 것인가?

TL;DR

서버 애플리케이션 성능 모니터링(Application Performance Monitoring, APM)은 서버 구간을 잘 보여주지만, 클라이언트 메인 스레드에서 줄어든 비용까지 대신 말해주지는 않는다.
브라우저 성능 개선은 RUM에서 같은 사용자군, 같은 화면, 같은 배포 버전을 기준으로 Long Task와 화면 로딩 시간 등을 비교해야 한다.
효과 검증 지표와 회귀 감시 지표는 목적이 다르다. 전자는 변경이 실제로 빨라졌는지 묻고, 후자는 사용자가 다시 느려지거나 깨진 화면을 만나는지 감시한다.
1시간 동안 데이터가 없다고 계측이 실패한 것은 아니다. 트래픽, 샘플링, 화면 진입 방식과 집계 구간부터 확인해야 한다.
Slack, Jira, GitHub 같은 운영 맥락은 RUM과 다른 종류의 신호를 가진다. 읽기 전용 AI 스킬은 흩어진 신호를 모아 후보와 근거를 제시할 수 있다.
AI가 장애를 선언하거나 자동으로 메시지를 보내게 하지는 않았다. 관측 범위, 임계값, 개인정보 제외 규칙과 최종 판단의 경계를 사람이 정했다.
장애 예측 스킬은 아직 예측기가 아니다. 채점 가능한 가설을 반복해서 만들고 검증하기 시작한 실험에 가깝다.

시작은 `document.cookie`였다

체크아웃 화면의 Android WebView 성능을 다시 추적하다가 예상하지 못한 비용을 찾았다. 네트워크 요청도, React 렌더도 아니었다. 브라우저 메인 스레드에서 document.cookie를 읽는 작업이 여러 번 반복되고 있었다.

document.cookie는 겉으로는 문자열 프로퍼티 하나를 읽는 것처럼 보인다.

const cookie = document.cookie;

하지만 동기 API다. MDN의 Document.cookie 문서도 프로세스 간 쿠키 읽기나 입출력이 발생할 때 메인 스레드를 막아 성능 문제가 생길 수 있다고 설명한다. 데스크톱 브라우저에서는 작게 보이던 비용이 특정 Android WebView에서는 크게 튀었다. 긴 장바구니로 체크아웃에 진입한 한 실기기 트레이스에서는 누적 비용이 수백 ms까지 늘었다.

호출부 하나가 비싼 게 아니었다. 여러 유틸리티와 오래된 호환 계층이 같은 작업 안에서 쿠키 문자열 전체를 반복해서 읽는 구조가 문제였다.

수정 방향은 단순했다.

// 실제 구현을 단순화한 예시다.
let cachedCookie: string | undefined;

export function readCookieForCurrentTask() {
  if (cachedCookie !== undefined) {
    return cachedCookie;
  }

  cachedCookie = document.cookie;

  queueMicrotask(() => {
    cachedCookie = undefined;
  });

  return cachedCookie;
}

실제 구현은 쓰기 경로에서 캐시를 명시적으로 무효화하고, 기존 쿠키 서비스들이 공통 캐시를 사용하도록 연결했다. 캐시를 오래 유지하면 서버의 Set-Cookie나 직접 쓰기를 놓칠 수 있으므로, 같은 JavaScript 작업 안의 중복 읽기만 합치고 곧바로 버리는 쪽을 택했다.

이 수정은 작은 최적화처럼 보이지만 검증 범위는 작지 않았다.

공통 쿠키 서비스를 우회해 document.cookie를 직접 읽고 쓰는 곳이 있는지 정적 검색
인증, 세션, 로그아웃처럼 쿠키 정합성에 민감한 흐름 확인
쓰기 직후 읽기와 삭제 직후 읽기 테스트
기존 쿠키 직렬화 결과를 바꾸지 않았는지 회귀 테스트
Android WebView 실기기에서 수정 전후 트레이스 비교

로컬과 스테이징 환경에서 눈에 띄던 긴 작업은 줄었다. 이제 운영에서 효과를 확인하면 될 것 같았다.

그런데 기존 성능 대시보드는 거의 움직이지 않았다.

APM이 틀린 게 아니라 질문이 틀렸다

기존 대시보드는 체크아웃 서버 요청의 응답 시간을 중심으로 구성돼 있었다. 서버가 요청을 받고 응답을 돌려줄 때까지의 분포를 보기에는 적절했다.

하지만 이번에 줄인 것은 서버 시간이 아니었다.

장바구니에서 결제하기 선택
  ↓
클라이언트 라우팅
  ↓
WebView 메인 스레드에서 자바스크립트 실행
  ↓
쿠키 읽기 반복
  ↓
체크아웃 화면 렌더

수정 지점은 세 번째와 네 번째였다. 서버 APM은 이 구간을 직접 측정하지 않는다. Single Page Application(SPA)의 소프트 내비게이션이라면 화면을 옮길 때마다 새로운 문서 요청이 생기는 것도 아니다. 서버의 GET /checkout 표본이 적은 것도 이상하지 않았다.

대시보드가 틀린 값을 보여준 게 아니다. 내가 서버 계기판을 보면서 브라우저 메인 스레드가 얼마나 가벼워졌는지 묻고 있었다.

이를 구분하고 나니 관측 도구의 역할이 선명해졌다.

묻고 싶은 것	우선 볼 곳
서버가 응답하는 데 얼마나 걸렸나	APM, 서버 트레이스
API 호출이 느리거나 실패했나	APM, 네트워크 리소스
브라우저 메인 스레드가 오래 막혔나	RUM Long Task
사용자가 화면을 보기까지 얼마나 걸렸나	RUM View, Web Vitals
화면이 깨졌거나 자바스크립트 오류가 늘었나	RUM Error, Sentry
여러 제보와 변경 이력이 같은 문제를 가리키나	운영 채널과 이슈의 상관관계

모니터링을 추가하기 전에 먼저 해야 할 일은 위젯을 고르는 것이 아니었다. 내가 확인하려는 변화가 어느 실행 층에서 일어나는지 적는 것이었다.

효과 검증과 회귀 감시는 다른 일이다

RUM 대시보드를 만들면서 한 번 더 질문이 섞였다.

이번 쿠키 최적화가 실제 사용자를 빠르게 만들었는가?
이후 체크아웃이 다시 느려지거나 깨지는가?

둘 다 모니터링이지만 필요한 지표와 보는 방식이 다르다.

효과 검증

효과 검증은 가능한 한 실험에 가깝게 본다.

변경 전과 변경 후의 배포 버전을 나눈다.
Android WebView처럼 효과가 예상되는 사용자군을 고정한다.
같은 체크아웃 화면을 비교한다.
트래픽 차이를 줄이기 위해 같은 요일과 비슷한 시간대를 본다.
중앙값 하나보다 p75와 p95 분포를 함께 본다.

여기서 중요한 것은 전체 사용자의 평균이 아니다. 데스크톱과 모바일 웹, iOS와 Android, 일반 브라우저와 WebView를 전부 섞으면 특정 환경에서만 발생하던 개선이 희석될 수 있다.

이번 수정의 가설은 구체적이었다.

Android WebView의 체크아웃 진입에서
반복되는 동기 쿠키 읽기를 줄이면
긴 Long Task의 꼬리 구간이 낮아질 것이다.

그러므로 첫 비교 대상은 전체 페이지 로딩 평균보다 Android WebView의 Long Task p95였다. 다만 p95만으로 결론 내리지 않고 p75와 표본 수를 함께 보기로 했다.

회귀 감시

회귀 감시는 실험보다 경보에 가깝다.

Long Task의 개수나 총 지속 시간이 갑자기 늘었는가?
화면 로딩 시간과 LCP의 꼬리 구간이 이전 기준선을 벗어났는가?
자바스크립트 오류가 함께 증가했는가?
특정 운영체제나 WebView 버전에만 변화가 몰렸는가?
새 배포 직후부터 변화가 시작됐는가?

효과를 검증할 때는 작은 차이를 정확히 비교하고 싶다. 회귀를 감시할 때는 사용자가 실제로 불편을 겪을 만한 큰 변화에 빨리 반응하고 싶다. 같은 위젯을 공유할 수는 있어도, 임계값과 해석은 같을 수 없다.

이 구분 없이 대시보드를 만들면 숫자는 많아지지만 다음 행동은 정해지지 않는다.

그래서 RUM에서 무엇을 봤나

이미 Datadog Real User Monitoring(RUM)에는 사용자 상호작용, 리소스, Long Task를 수집하는 설정이 들어가 있었다. WebView 여부와 원본 사용자 에이전트(User-Agent)도 공통 컨텍스트로 붙고 있었다. 새 계측 코드를 바로 넣기 전에, 기존 데이터로 답할 수 있는 범위를 먼저 확인했다.

화면은 다음처럼 구성했다.

1. Long Task 지속 시간

메인 스레드를 오래 점유한 작업의 분포를 본다.

p75: 측정값 중 느린 상위 25%가 시작되는 경계 확인
p95: 느린 기기와 나쁜 조건에서 생기는 꼬리 구간 확인
시계열: 배포 시점 전후로 분포가 바뀌었는지 확인
운영체제별 분리: Android에 변화가 집중되는지 확인

p95만 보면 표본이 적을 때 한두 건에 크게 흔들린다. p75만 보면 정말 느린 사용자의 문제가 가려질 수 있다. 둘 중 하나를 고르기보다 둘의 역할을 나눴다.

2. 화면 로딩 시간

사용자가 해당 화면에 진입한 뒤 로딩 완료로 판단되기까지의 시간을 본다. 다만 SPA의 화면 경계가 RUM의 View와 정확히 맞는지 먼저 확인해야 한다. 자동 View 추적이 제품의 라우팅 구조를 제대로 나누지 못한다면 숫자를 보기 전에 수동 View 또는 커스텀 타이밍이 필요하다.

3. Largest Contentful Paint

Largest Contentful Paint(LCP)는 가장 큰 콘텐츠가 표시된 시점을 나타낸다. 다만 Datadog의 페이지 성능 문서에 따르면 LCP는 초기 View에서만 보고된다. 장바구니에서 체크아웃으로 이동하는 SPA 소프트 내비게이션의 주 지표로 삼을 수는 없다. 체크아웃을 처음부터 여는 진입 경로에서는 보조 지표로 보고, 장바구니에서 이동하는 경로는 Long Task와 View Loading Time을 중심으로 보기로 했다.

4. 자바스크립트 오류

성능 수정이 기능 정합성을 깨지 않았는지 확인하는 방어 지표다. 캐시를 넣고 숫자가 빨라졌더라도 인증이나 결제 흐름의 오류가 늘었다면 성공이 아니다.

최종적으로는 다음 조합을 같은 화면에서 보도록 했다.

Android WebView
  + 체크아웃 View
  + 배포 버전

Long Task p75 / p95
화면 로딩 시간 p75 / p95
LCP p75 / p95 (초기 진입만)
자바스크립트 오류 수

화려한 대시보드는 아니었다. 하지만 각 숫자가 어떤 질문에 답하는지는 설명할 수 있었다.

한 시간 동안 데이터가 없었다

대시보드를 만들고 최근 1시간을 열었는데 일부 위젯이 비어 있었다.

여기서 바로 “계측이 안 된다”고 결론 내리기 쉽다. 실제로는 최근 4시간과 하루 범위로 넓히자 데이터가 나타났다. 체크아웃 진입은 전체 페이지 트래픽에 비해 적고, Android WebView 조건까지 묶었으니 짧은 시간창의 표본이 부족했던 것이다.

이 경험으로 운영 성능을 볼 때 확인할 순서를 정했다.

이벤트가 전혀 수집되지 않는가?
필터가 실제 필드와 맞는가?
View 이름과 라우트 경계가 기대한 대로 잡히는가?
표본이 생길 만큼 시간 범위를 넓혔는가?
샘플링 비율과 배포 버전 분포는 어떤가?
p95를 해석할 만큼 표본 수가 충분한가?

빈 그래프도 정보다. 다만 “문제가 없다”는 정보인지, “아직 말할 수 없다”는 정보인지 구분해야 한다.

이번에는 후자였다.

그런데 숫자만으로는 장애를 발견하지 못한다

RUM 대시보드를 정리하던 같은 날, 개인용 로컬 스킬로는 전혀 다른 모니터링을 만들고 있었다.

고객 문의 채널에는 “화면이 하얗다”, “결제 단계에서 더 진행되지 않는다”, “같은 버튼을 눌러도 반응이 없다” 같은 메시지가 올라온다. 오류 알림 채널에는 특정 예외가 쌓인다. 배포 기록에는 직전에 무엇이 바뀌었는지가 남고, 이슈 추적 도구에는 비슷한 과거 장애가 있다.

문제는 각각의 신호가 혼자서는 약하다는 점이다.

고객 한 명의 제보는 개별 환경 문제일 수 있다.
오류 하나는 이미 알려진 잡음일 수 있다.
배포 하나는 장애의 원인이라는 뜻이 아니다.
과거 장애와 문장이 비슷하다고 같은 원인인 것도 아니다.

하지만 짧은 시간 안에 여러 고객이 같은 핵심 여정에서 막히고, 같은 구간의 오류가 늘었으며, 직전에 관련 코드가 배포됐다면 얘기가 달라진다.

사람은 이 상관관계를 잘 읽는다. 다만 하루 종일 모든 채널과 이슈, 배포를 동시에 보고 있을 수는 없다.

그래서 Codex에 두 종류의 읽기 전용 스킬을 만들었다.

지금 들어오는 신호를 묶는 장애 탐지 스킬
다음 주의 위험 후보를 미리 적고 나중에 채점하는 장애 예보 스킬

첫 번째 스킬: 흩어진 신호를 묶되 행동하지 않는다

장애 탐지 스킬은 정해진 고객 제보 채널과 오류 공유 채널을 읽는다. 마지막으로 확인한 시각 이후의 메시지만 가져오고, 짧은 시간창 안에서 같은 사용자 여정과 증상을 가리키는 신호를 묶는다.

판단 요소는 대략 다음과 같다.

서로 다른 고객의 유사 제보가 여러 건인가?
로그인, 장바구니, 체크아웃, 결제처럼 핵심 여정이 막혔는가?
흰 화면, 무한 로딩, 반복되는 4xx·5xx처럼 장애성이 강한 표현이 있는가?
개발자가 재현했거나 기술 근거를 붙였는가?
서로 다른 채널의 증거가 같은 현상을 가리키는가?

반대로 다음은 기본적으로 제외한다.

한 고객에게만 발생한 상담 건
정책이나 사용법 문의
운영자가 바로 수정할 수 있는 단순 설정 문제
QA 환경에서만 재현되는 문제
이미 해결됐고 새 증거가 없는 문제

점수를 계산해 낮은 후보는 출력하지 않고, 일정 점수 이상일 때만 내게 근거 링크와 함께 알려준다. 더 높은 점수라고 해도 장애를 자동 선언하지는 않는다. “장애 채널 개설을 검토할 수준”이라고 표현할 뿐이다.

여기서 가장 중요한 설계는 탐지 로직이 아니었다. 하지 않을 일을 먼저 정한 것이었다.

Slack에 메시지를 쓰지 않는다.
Jira나 GitHub를 수정하지 않는다.
장애를 선언하지 않는다.
고객 이름, 연락처, 주문번호 같은 개인정보를 출력하지 않는다.
증거가 부족하면 추측으로 빈칸을 채우지 않는다.

첫 버전의 목표는 자동 대응이 아니라, 내가 놓칠 수 있는 신호를 읽기 쉬운 후보로 만드는 것이었다.

읽기와 쓰기의 권한 차이는 크다. 탐지 정확도를 아직 모르는 단계에서 자동 메시지와 장애 선언까지 연결하면, 작은 오탐도 조직 전체의 잡음이 된다. 반면 읽기 전용 후보는 사람이 근거를 열어보고 폐기할 수 있다.

두 번째 스킬: 예측이 아니라 채점 가능한 가설

장애 예보라는 이름은 조금 거창하다. 실제로 하는 일은 다음 주의 위험 후보를 미리 적는 것이다.

예정된 배포와 캠페인
최근 기본 브랜치에 합쳐진 큰 변경
과거 비슷한 장애가 반복된 영역
영향 범위가 큰 공통 모듈
현재 관측 가능성이 낮은 변경

각 후보는 반복 가능성, 예정된 노출, 변경 규모, 영향 범위, 관측 가능성, 불확실성으로 점수를 매긴다. 그리고 반드시 다음 항목을 남긴다.

어떤 영역이
어떤 조건에서
어떤 증상으로 실패할 수 있는가
그 주장이 맞았는지 나중에 무엇으로 판정할 것인가

예를 들어 “인증이 위험해 보인다”는 예보는 채점할 수 없다. 범위가 너무 넓고 결과를 무엇으로 확인할지도 없다.

다음처럼 적어야 한다.

특정 로그인 경로의 세션 처리 변경이 배포된 뒤
Android WebView에서 재로그인 루프가 증가할 수 있다.

판정:
- 해당 기간의 동일 증상 고객 제보
- 인증 오류율 변화
- 관련 배포의 롤백 또는 핫픽스 여부

기간이 지나면 맞음, 일부 맞음, 틀림, 판정 불가로 채점한다. 틀렸다면 왜 틀렸는지도 남긴다.

이 과정이 없는 장애 예보는 그럴듯한 문장 생성에 그친다. 많이 경고할수록 하나쯤 맞는 방식으로는 정확도를 알 수 없다.

그래서 아직 이 스킬을 “AI가 장애를 예측한다”고 부르지 않는다. 최소한 여러 번의 예보와 사후 채점이 쌓이기 전에는 확률도 말하지 않는다.

지금 만든 것은 예측 모델이 아니라 내 판단을 반증 가능한 형식으로 강제하는 기록 장치에 가깝다.

RUM과 AI 스킬은 무엇이 같았나

두 작업은 입력부터 다르다.

구분	RUM 대시보드	읽기 전용 AI 스킬
입력	브라우저 이벤트와 성능 수치	메시지, 이슈, 변경과 배포 맥락
잘 보는 것	시간, 분포, 오류 수, 환경별 차이	여러 약한 신호의 상관관계
약점	표본 편향, 잘못된 View 경계, 맥락 부족	오탐, 누락, 표현의 모호함
기본 출력	그래프와 수치	후보, 점수, 근거 링크
자동 행동	없음	없음
최종 판단	사람	사람

그런데 만드는 순서는 거의 같았다.

먼저 질문을 한 문장으로 적는다.
관측 범위를 좁힌다.
포함할 신호와 제외할 잡음을 정한다.
판단 가능한 임계값을 둔다.
원본 증거로 돌아갈 링크를 남긴다.
자동 행동의 경계를 정한다.
결과를 나중에 다시 채점한다.

RUM에서 “Android WebView 체크아웃의 Long Task p95가 줄었는가?”라고 묻는 것과, 장애 탐지에서 “서로 다른 고객의 흰 화면 제보와 같은 구간의 오류가 함께 늘었는가?”라고 묻는 것은 데이터가 다를 뿐 구조는 같다.

둘 다 모든 것을 보려 하면 실패한다. 범위가 넓어질수록 숫자는 평균에 묻히고, 메시지는 잡음에 묻힌다.

모니터링은 많이 수집하는 일이 아니라 다음 판단에 필요한 범위로 좁히는 일이었다.

Claude와 Codex도 역할이 달랐다

이번 작업은 AI 도구 하나로 처음부터 끝까지 진행하지 않았다.

Claude Code와는 쿠키 캐시 구현의 긴 맥락을 이어갔다. 직접 접근하는 호출부를 찾고, 테스트를 보강하고, 스테이지에서 인증 흐름을 확인하고, 운영에서 어떤 RUM 지표를 봐야 하는지 정리했다. 구현과 검증이 여러 파일과 환경을 오가는 작업이라 앞선 결정과 남은 위험을 계속 기억하는 대화가 유용했다.

Codex에서는 반복해서 수행할 운영 판단을 로컬 스킬로 만들었다. 감시할 채널, 시간 범위, 상관관계 기준, 제외 규칙, 개인정보 제한, 읽기 전용 경계를 문서와 실행 규칙으로 고정했다. 한 번의 좋은 대답보다 다음 실행에서도 같은 제약을 지키는 것이 중요한 작업이었다.

둘을 나눈 기준은 “어느 AI가 더 좋은가”가 아니었다.

긴 구현 맥락을 따라가며 수정과 검증을 반복하는 일
반복할 판단 규칙을 작고 검토 가능한 도구로 고정하는 일

필요한 인지 모드가 달랐다.

그리고 어느 쪽에서도 가장 중요한 결정은 자동으로 나오지 않았다.

이번 수정의 성공을 어떤 지표로 볼 것인가
어떤 사용자군을 따로 볼 것인가
표본이 적을 때 결론을 보류할 것인가
어떤 신호를 장애 후보로 올릴 것인가
AI가 어디까지 읽고 어디서 멈출 것인가

이 경계를 정하는 일은 사람이 했다.

AI가 빨리 만들어준 것은 대시보드와 스킬 자체보다 판단을 반복할 수 있는 형태로 외부화하는 과정이었다.

아직 증명하지 못한 것

작업을 끝내고 보면 그럴듯한 체계가 생겼다. 그렇다고 이미 잘 동작한다고 말할 수는 없다.

RUM의 한계

짧은 시간창에는 Android WebView 체크아웃 표본이 부족했다.
SPA View 경계가 사용자가 체감하는 체크아웃 진입 구간과 정확히 같은지 더 확인해야 한다.
기존 지표만으로 쿠키 읽기 비용을 직접 분리할 수는 없다.
p95는 느린 사용자를 보여주지만 표본이 작으면 크게 흔들린다.
배포 전후의 트래픽 구성과 기기 분포가 달라지면 단순 비교가 왜곡된다.

필요하다면 다음 단계에서 체크아웃 진입 시작과 핵심 콘텐츠 표시 시점에 커스텀 타이밍을 넣어야 한다. 다만 계측 코드를 추가하기 전에 기존 RUM으로 어디까지 답할 수 있는지 먼저 보는 것이 맞다.

장애 탐지 스킬의 한계

다른 표현으로 올라온 같은 장애를 하나로 묶지 못할 수 있다.
반대로 비슷한 문장 때문에 서로 다른 문제를 같은 후보로 묶을 수 있다.
채널에 올라오지 않은 문제는 읽을 수 없다.
점수 임계값은 아직 충분한 오탐과 누락 사례로 보정되지 않았다.

장애 예보 스킬의 한계

아직 채점 이력이 충분하지 않다.
예정된 작업과 실제 배포가 달라질 수 있다.
과거 반복성이 없는 새로운 장애에는 약하다.
근거가 많은 영역만 계속 위험하게 평가하는 편향이 생길 수 있다.

결국 대시보드도, AI 스킬도 만들었다고 끝나지 않는다. 관측 결과가 틀렸을 때 규칙을 고치는 운영이 필요하다.

모니터링을 만들 때 남긴 체크리스트

이번 작업 뒤에는 새 모니터링을 만들 때 다음 질문부터 적어보려 한다.

질문

어떤 변경 또는 위험을 확인하려는가?
이 신호는 서버, 브라우저, 사용자 제보 중 어디에서 나타나는가?
효과 검증인가, 회귀 감시인가, 장애 탐지인가?

범위

어떤 화면과 사용자 여정인가?
운영체제, 앱, WebView, 배포 버전을 나눠야 하는가?
관측 시간창은 표본을 확보하기에 충분한가?

지표와 근거

평균보다 p75나 p95가 중요한가?
숫자와 함께 원본 이벤트로 돌아갈 수 있는가?
메시지 후보에 재현, 오류, 변경 이력 중 무엇이 붙어 있는가?

행동

어떤 변화에서 사람이 확인해야 하는가?
어떤 변화에서 배포 중단이나 롤백을 검토하는가?
AI와 자동화가 절대 수행하면 안 되는 행동은 무엇인가?

학습

이 판단이 맞았는지 언제 다시 볼 것인가?
오탐과 누락을 어디에 기록할 것인가?
임계값을 바꿀 근거가 쌓였는가?

체크리스트의 마지막이 “대시보드를 만들었는가”가 아닌 이유가 있다. 대시보드는 시작점일 뿐이다.

읽을 거리

모니터링은 보는 일이 아니라 다음 판단을 준비하는 일

예전에는 모니터링이라고 하면 대시보드를 띄워두고 숫자를 보는 장면부터 떠올렸다.

이번에는 반대 순서였다.

먼저 변경이 어느 층에서 일어났는지 구분했다. 서버 APM으로 보이지 않는 클라이언트 비용은 RUM에서 관측하도록 바꿨다. 효과 검증과 회귀 감시를 나눴다. 짧은 시간창의 빈 그래프 앞에서는 결론을 보류했다.

숫자 밖에서는 고객 제보와 오류, 배포 이력이 만나는 지점을 읽기 전용 스킬로 묶었다. AI가 장애를 선언하게 하는 대신 근거를 잃지 않는 후보를 만들게 했다. 다음 주의 위험은 예언하지 않고, 나중에 틀렸다고 말할 수 있는 문장으로 적게 했다.

그래서 지금의 결론은 이렇다.

모니터링은 대시보드 하나가 아니다.

APM은 서버가 요청을 처리하고 응답하는 데 걸린 시간을 말한다.
RUM은 사용자의 브라우저에서 일어난 시간을 말한다.
오류 추적 도구는 실패한 실행을 말한다.
고객 제보는 숫자가 놓친 체감을 말한다.
변경과 배포 기록은 왜 지금 달라졌는지 말한다.
AI 스킬은 흩어진 말들을 같은 판단 테이블 위에 올린다.

어느 하나가 전체를 대신하지 못한다. 중요한 것은 도구를 많이 붙이는 게 아니라, 각 도구가 답할 질문과 답하지 못할 질문을 아는 것이다.

장애 기록은 저장으로 끝나지 않는다고 썼다. 이번 작업을 지나며 한 문장을 더 붙일 수 있게 됐다.

관측도 수집으로 끝나지 않는다. 다음 판단을 더 빠르고 정확하게 만들 때 비로소 모니터링이 된다.