성능 튜닝

~10 min · performance, speed, optimization

Level 0Apprentice

0 XP0/101 lessons0/10 achievements

0/120 XP to next level120 XP to go0% complete

레버 8 개

CI 더 빨리 하려면 대략 우선 순위로 다음 중 하나 이상 공격:

Job 병렬화 — 독립 작업을 병렬 job 으로 wall-clock 감소.
적극 caching — install, build output, Docker layer, 모델 weight.
더 큰 runner 사용 — CPU 바인드 step 에 코어 두 배가 종종 시간 절반. 선형 비용, sub-linear 시간? 승리.
해당 안 되는 거 skip — paths filter, 조건 job.
Concurrency cancel-in-progress — 오래된 run kill.
PR 에 더 작은 test subset — PR 엔 smoke, main 엔 full.
더 빠른 설치 도구 — uv vs pip, pnpm vs npm, cache 된 docker buildx.
Test sharding — 느린 suite 를 runner 간 분할.

추측 말고 측정

최적화 전에 run timeline 봐. 가장 긴 step 이 후보. GitHub 의 run 페이지가 step 별 기간 보여줌; gh run view --log 가 raw 타이밍. 최악 최적화, 재측정, 반복.

Code

gh run 타이밍 — bottleneck 찾기·bash

# Most recent run id
run=$(gh run list -L 1 --json databaseId --jq '.[0].databaseId')

# Per-job duration
gh api repos/:owner/:repo/actions/runs/$run/jobs \
  --jq '.jobs[] | {name, started_at, completed_at}'

# Or: look at the run summary in the UI; per-step durations are shown.

External links

GitHub — Workflow run usage

Exercise

가장 느린 workflow 골라. 최근 10 run 의 timeline 가져와. p95 지배하는 단일 step 식별. 거기에 8 레버 중 하나 적용. 5 run 더 후 재측정.

Progress

Progress is local-only — sign in to sync across devices.

← PreviousWorkflow 디버깅 Next →CI 모니터링

이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

🔔 답글 알림 (로그인 필요)

로그인 — 댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.