개념
이 레슨의 경계 — 깊이가 아니라 시간축
관측을 다루는 레슨이 이 커리큘럼에 셋 있다. 셋은 같은 데이터를 보지만 보는 방향이 다르다.
| 레슨 | 묻는 질문 | 보는 단위 |
|---|---|---|
| m55 레슨 3 — 보고·로깅 설계 | 이 실패 하나의 원인이 무엇인가 | 실행 1건, 테스트 1건 (깊이) |
| m14 레슨 6 — 실패 추적 관측성 | 로그·메트릭·대시보드가 무엇이고 어떻게 읽는가 | 개념과 읽는 법 |
| m59 레슨 5 — 이 레슨 | 지난 30일 동안 무엇이 나빠지고 있는가 | 여러 실행에 걸친 추세 (시간) |
m14 레슨 7의 SLO 는 또 다른 축이다. 그쪽은 운영 중인 제품 의 품질을 사용자 관점에서 재고, 이 레슨은 테스트 실행 시스템 자체 의 건강을 재는 지표를 다룬다. 두 묶음을 한 대시보드에 섞으면 둘 다 읽히지 않는다.
추세로 보면 보이는 것이 달라진다. 실행 한 번의 결과는 "오늘 10건 실패"지만, 추세는 "실패가 2주 전 3건에서 10건으로 늘었고 그중 7건이 같은 테스트 묶음"을 보여준다. 전자는 트리아지 대상이고, 후자는 의사결정 대상 이다.
지표를 정의하는 규칙 — 지표 카드
지표가 쓸모없어지는 이유는 측정이 어려워서가 아니라 정의가 모호해서다. "통과율"은 세 사람이 세 가지로 계산한다. 그래서 지표마다 다섯 항목을 고정해 쓴다.
지표 카드 양식
이름 실행 완료 시간
정의 파이프라인 트리거부터 결과 게시까지의 경과 시간
분모·단위 실행 1회당 초. 대기·준비·실행·수집 구간으로 분해 가능
윈도우 최근 20회 실행의 p50 과 p90
제외 규칙 '환경 미준비' 로 중단된 실행, 사람이 취소한 실행
소유자 TestOps 당번
악화 판정 p90 이 3회 연속 목표를 20% 초과제외 규칙 이 특히 중요하다. 레슨 3에서 환경 미준비를 별도 상태로 기록하기로 한 이유가 여기서 회수된다. 제외 규칙이 없으면 환경 장애 하루가 한 달치 추세를 왜곡하고, 왜곡된 추세는 아무도 믿지 않게 된다.
무엇을 지표로 두는가 — 여섯 개로 시작한다
처음부터 20개를 만들면 아무도 안 본다. 여섯 개로 시작해 필요할 때 늘린다.
① 실행 완료 시간 (p50 / p90) — 평균을 쓰지 않는다. 평균은 긴 꼬리를 숨기고, 사람이 겪는 고통은 꼬리에서 온다. 구간별(대기·준비·실행·수집)로 쪼개 두면 느려질 때 원인을 바로 짚을 수 있다. 레슨 2의 병목 찾기가 이 분해를 쓴다.
② 통과율 — 분모를 명확히 한다. 격리된 테스트는 분모에서 빼고, 건너뛴 테스트는 별도로 센다. 통과율 하나만 보면 격리를 늘려 숫자를 올릴 수 있으므로 반드시 ③과 함께 본다.
③ 신뢰도(플래키율) — 레슨 4의 두 지표(테스트 단위·실행 단위)를 둘 다 올린다. 이 지표가 통과율의 해석을 결정한다. 통과율 97%에 플래키율 5%면, 실패 3%는 대부분 가짜라는 뜻이고 그 자동화는 결함을 못 잡고 있는 것이다.
④ 대기 시간 — 실행 요청이 설비를 기다린 시간. 설비 부족의 유일한 직접 증거이고, 테스트 로그에는 안 찍힌다. 증설 요청의 근거가 되는 숫자다.
⑤ 커버리지 추세 — 절대값보다 방향을 본다. 코드 커버리지든 요구사항·시나리오 커버리지든, 갑자기 떨어진 지점 이 신호다. 떨어짐의 흔한 원인은 커버리지 악화가 아니라 테스트 묶음이 일부 실패해 측정이 덜 됐거나, 격리가 늘었거나, 새 모듈이 테스트 없이 들어온 것이다. 그래서 커버리지 추세는 ③과 함께 읽어야 한다.
⑥ 트리아지 소요 시간 — 실패가 발생해 분류되기까지 걸린 시간. 운영 품질을 가장 정직하게 보여주는 지표다. 이 값이 길어지고 있으면 자동 분류(레슨 7)가 필요하다는 신호다.
여기에 환경 가용률(프리플라이트 통과율)과 격리 건수를 더하면 여덟 개가 되고, 그 정도가 한 화면에 들어가는 상한이다.
추세를 읽는 법 — 변화와 악화 판정
추세 대시보드의 목적은 숫자를 보여주는 것이 아니라 변화를 알아채는 것 이다. 사람은 매일 조금씩 나빠지는 것을 못 알아챈다. 그래서 판정 규칙을 기계에 맡긴다.
악화 판정 규칙 (예시)
실행 완료 시간 p90 이 3회 연속 목표의 120% 초과 → 당번 알림
통과율 7일 이동평균이 직전 7일보다 3%p 이상 하락 → 리뷰 안건
플래키율(실행) 실행당 가짜 실패가 2건 초과한 날이 3일 연속 → 플래키 정리 착수
대기 시간 p90 이 실행 시간의 20% 초과 → 용량 산정 재실행
커버리지 주간 측정값이 2%p 이상 하락 → 원인 확인(측정 실패 여부 먼저)
트리아지 소요 중위값이 4시간 초과 → 자동 분류 규칙 점검규칙을 쓸 때 두 가지를 지킨다. 첫째, 절대 임계보다 변화 임계를 쓴다. "통과율 95% 미만"은 조직마다 다르고 계속 조정해야 하지만, "직전 주 대비 3%p 하락"은 어디서나 의미가 같다. 둘째, 연속 조건을 붙인다. 하루치 변동으로 알림이 오면 알림을 끈다. 3일 연속이나 3회 연속을 붙이면 소음이 사라진다.
누가 보는가로 대시보드를 나눈다
한 화면에 모든 사람을 위한 숫자를 올리면 아무도 자기 화면을 갖지 못한다. 보는 사람의 질문이 다르면 화면도 달라야 한다.
| 보는 사람 | 묻는 질문 | 화면에 올릴 것 | 올리지 말 것 |
|---|---|---|---|
| 변경을 올린 개발자 | 내 변경이 뭘 깨뜨렸나 | 내 PR 의 결과, 실패 테스트와 바로 가는 링크, 격리 여부 | 월간 추세, 조직 전체 통과율 |
| TestOps 당번 | 오늘 무엇을 먼저 봐야 하나 | 미분류 실패 목록, 프리플라이트 결과, 대기 시간, 신규 플래키 후보 | 커버리지 절대값 |
| QA 리드 | 우리 자동화는 건강해지고 있나 | 6개 지표의 30일 추세, 격리 목록 크기, 트리아지 소요 | 개별 테스트 실패 상세 |
| 엔지니어링 리더 | 투자가 성과로 왔나, 무엇이 막혔나 | 완료 시간 추세, 신뢰도 추세, 용량 부족 근거, 품질 게이트 차단 건수 | 지표 정의의 세부사항 |
화면을 나눌 때의 실용 규칙이 하나 있다. 각 화면은 "그래서 지금 무엇을 하는가"라는 질문에 답할 수 있어야 한다. 당번 화면의 모든 항목은 오늘의 행동으로 이어지고, 리드 화면의 모든 항목은 이번 분기의 결정으로 이어진다. 행동으로 이어지지 않는 숫자는 화면에서 뺀다. 그 숫자가 틀렸다는 뜻이 아니라, 그 화면의 것이 아니라는 뜻이다.
추세를 가능하게 하는 데이터 — 실행 레코드
대시보드를 만들 수 없는 조직의 공통점은 도구가 없는 것이 아니라 데이터가 실행마다 사라지는 것 이다. CI 로그는 보관 기간이 지나면 없어지고, 리포트 HTML 은 추세로 집계할 수 없다. 추세를 보려면 실행 결과를 구조화된 레코드로 따로 남겨야 한다.
레코드 한 줄 = 테스트 실행 1건. 최소 열은 이렇다.
run_id 실행 식별자 (레슨 6의 상관 식별자와 동일)
test_id 테스트의 안정 식별자 (파일 경로 아닌 고유 ID 권장)
status pass / fail / flaky-pass / skipped / quarantined / env-not-ready
duration_ms 테스트 소요 시간
retry_count 재시도 횟수
queue_wait_ms 설비를 기다린 시간
runner 러너 또는 설비 종류 (셀프호스티드 / 클라우드 / 단말 모델)
env_coordinate 환경 좌표 해시 (레슨 3)
commit 커밋 식별자
triage_label product-defect / env-issue / test-defect / unknown (레슨 7)
triage_at 분류 시각 — 트리아지 소요 시간 계산용이 열들이 있으면 앞의 여섯 지표가 전부 쿼리 하나로 나온다. 반대로 status 에
flaky-pass 와 env-not-ready 가 없으면 ③과 제외 규칙이 불가능해진다. 지표를
먼저 정하고 그 지표가 요구하는 열을 레코드에 넣는 순서 로 설계하는 것이 맞다.
보관 정책은 두 층으로 둔다. 레코드(한 줄짜리 구조화 데이터)는 길게 — 1년 이상 둬도 용량이 작다. 아티팩트(스크린샷·비디오·트레이스)는 짧게 — 레슨 6에서 다룬다. 둘을 같은 정책으로 묶으면 추세를 잃거나 저장소가 터진다.
지표가 목표가 될 때 — 왜곡의 경로
지표에는 측정 대상을 바꾸는 성질이 있다. 흔히 발생하는 왜곡 세 가지를 미리 알고 막는다.
통과율 100%를 목표로 둔다. 통과율을 올리는 가장 빠른 방법은 테스트를 지우거나 격리하거나 단언을 약하게 만드는 것이다. 셋 다 품질을 낮추면서 숫자를 올린다. 그래서 통과율은 플래키율·격리 건수·커버리지와 함께 보고, 단독 목표로 두지 않는다.
커버리지 숫자를 목표로 둔다. 커버리지 80%를 목표로 걸면 커버하기 쉬운 코드부터 덮인다. 커버리지는 "덮이지 않은 중요한 영역을 찾는 도구"로 쓸 때 값이 있고, 목표로 쓸 때는 의미가 빠르게 빠진다. 추세와 급락 지점만 보는 것이 안전하다.
실행 시간만 목표로 둔다. 완료 시간을 줄이는 가장 쉬운 방법은 테스트를 덜 돌리는 것이다. 레슨 2의 감축 계획이 순서와 해제 조건을 요구하는 이유가 여기 있다. 완료 시간은 항상 "무엇을 돌린 상태에서의 시간"으로 기록해야 한다.
실무에서 왜 필요한가
자동화가 서서히 나빠지는 과정은 눈에 안 보인다. 어제보다 2% 느려지고, 플래키가 한 개 늘고, 격리가 하나 추가된다. 하루 단위로는 전부 무해하고, 반년 뒤에는 아무도 자동화를 안 본다. 추세 관측의 본질은 느린 악화를 사건으로 만드는 일 이다. 사건이 되면 사람이 대응하고, 사건이 되지 않으면 아무 일도 일어나지 않는다.
예산 대화에서도 추세가 유일하게 작동하는 자료다. "테스트가 느립니다"는 의견이고, "완료 시간 p90 이 12주간 18분에서 41분으로 늘었고, 그중 대기 시간이 3분에서 19분으로 늘었습니다"는 증거다. 설비 증설이든 인력 배치든, 승인되는 요청은 거의 항상 추세 그래프를 갖고 있다.
반대로 성과를 보일 때도 쓰인다. 플래키 정리에 한 스프린트를 썼을 때, 그 성과는 "열심히 했다"로는 설명되지 않는다. 실행당 가짜 실패가 3.1건에서 0.4건으로 떨어진 그래프가 그 스프린트의 가치를 증명하고, 다음 스프린트를 다시 받을 근거가 된다.