피드백 루프

통과율이 아니라 지연 시간이 핵심 지표야

대부분 팀은 CI를 잘못된 숫자에 맞춰 최적화해. 통과율(main 브랜치가 얼마나 자주 초록색인가)에 집착하지. 그것도 중요하긴 하지만 하위 지표일 뿐이야. 상위 지표는 피드백 지연 시간이야. 변경 사항을 푸시한 시점부터 뭐가 깨졌는지 깨닫는 시점까지 걸리는 시간을 말하지.

지연 시간이 왜 중요하냐면, 90분짜리 CI 실행은 그냥 느린 게 아니야. 컨텍스트 스위칭 비용이거든. 실행이 끝날 때쯤이면 넌 이미 다른 문제로 넘어갔고, 다른 브랜치를 시작했고, 점심을 먹으러 갔을 거야. 실패 알림이 도착하면 머릿속 모델을 다시 불러와야 해. 90분 실행의 실제 비용은 90분이 아니라 반나절에 가까워.

계층화된 피드백

실제 팀은 피드백을 여러 속도로 쌓아:

에디터 (초) — 타입 에러, 린트 경고, 포맷 문제. LSP와 저장 시 자동 포맷 기능이 커밋 전에 대부분 잡아줘.
사전 커밋 훅 (초) — 절대 CI까지 가면 안 되는 빠른 검사. 린트, 포맷, 오타.
CI (분) — 메인 테스트 묶음. 대부분은 10분 이하, 스모크 하위 묶음은 2분 이하가 목표야.
배포 전 (분) — 통합 테스트, 엔드투엔드 테스트, 성능 예산.
배포 후 (분~시간) — 프로덕션 스모크 테스트, 에러율 대시보드, 사용자 노출 관측.

계층이 빠를수록 실패를 처리하는 비용이 싸져. CI의 역할은 가능한 많은 피드백을 더 싼 계층으로 밀어내는 거야.

Code

사전 커밋 훅 설정 — 푸시 전 빠른 피드백·yaml

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v5.0.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
      - id: check-yaml
      - id: check-added-large-files
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.7.0
    hooks:
      - id: ruff
        args: [--fix]
      - id: ruff-format

Exercise

가장 최근 CI 실행을 엔드투엔드로 시간 재봐. 이제 분해해: 체크아웃이 얼마, 설치가 얼마, 실제 테스트가 얼마 걸리는지? 적어도 하나는 병목이야. 최적화 하나 골라서 (캐싱, 병렬 처리, 더 작은 스모크 하위 묶음) 절감되는 시간을 추정해봐.

통과율이 아니라 지연 시간이 핵심 지표야

계층화된 피드백

Code

External links

Exercise

Progress

댓글 0