품질을 희생하지 않으면서 딜리버리 속도를 어떻게 높이나요?

Question

Accepted Answer

속도와 품질은 한 스프린트보다 긴 어떤 기간에서도 **서로 반대가 아닙니다** — 당신을 빠르게 만드는 것들(작은 배치, 자동화, 빠른 피드백)이 바로 당신을 안전하게 지키는 것들입니다. 진짜 적은 "품질"이 아니라 **큰 배치, 수작업 노동, 긴 피드백 루프**입니다. 그것들을 공격하세요.

## 속도는 실제로 어디서 오는가

- **더 작은 배치 크기.** 더 작은 PR과 더 작은 릴리스는 더 빠르게 리뷰되고, 더 잘 테스트되며, 더 깔끔하게 rollback됩니다. 대부분의 느림은 타이핑이 아니라 큐잉입니다.
- **진행 중 작업 줄이기.** 끝내는 것이 시작하는 것을 이깁니다. 높은 WIP는 컨텍스트 스위칭과 멈춘 리뷰를 만듭니다; 그것을 제한하면 처리량이 올라갑니다.
- **게이트 자동화하기.** CI, 테스트, 린팅, 원클릭 배포는 조용히 시간을 잡아먹고 인적 오류를 부르는 수작업 단계를 제거합니다.
- **피드백 루프 단축하기.** 트렁크 기반 개발, 기능 플래그, 빠른 파이프라인은 결함을 몇 주가 아니라 몇 분 만에 찾게 해줍니다.

## 제가 쓰는 프레임워크

1. **먼저 측정하기** — DORA 지표로(배포 빈도, 리드 타임, 변경 실패율, MTTR). 이들은 당신이 빨라지면서 *동시에* 안전해졌는지, 아니면 그냥 빨라지기만 했는지를 보여줍니다.
2. **병목 찾기** — 보통 리뷰 큐, flaky한 수동 QA 단계, 또는 느린 환경. 모든 것이 아니라 그 하나의 제약을 최적화하세요.
3. **인간 승인 게이트가 아니라 자동화로 품질 보호하기.** 테스트와 플래그는 안전하게 빨리 가게 해줍니다; 승인 위원회는 지연만 더합니다.

## 트레이드오프와 함정

- 테스트를 줄이는 것은 며칠을 사고 **incident와 재작업**으로 몇 달을 치릅니다 — 잘못된 절약입니다.
- **관측성** 없이 빠르게 가는 것은 눈을 가리고 출시하는 것입니다; 속도를 모니터링 및 쉬운 rollback과 짝지으세요.
- "빠르게 움직여라"가 **되돌릴 수 없는 결정**(스키마, 공개 API)의 설계를 건너뛰는 핑계가 되지 않게 하세요. 되돌릴 수 있는 것은 빠르게; 일방향 문은 신중하게.
- 국소 최적화를 경계하세요 — 병목이 이틀짜리 리뷰 대기라면 빠른 IDE는 도움이 안 됩니다.

## 왜 중요한가

대부분의 팀은 속도를 위해 품질을 거래해야 한다고 믿어, 안전하게 느끼려고 느려지고는 둘 다 얻지 못합니다. **엔지니어링 규율이 팀을 빠르게 만든다**는 것을 보여줄 수 있는 Tech Lead는 지속 가능한 속도를 풀어냅니다 — incident와 tech debt 더미로 붕괴하는 대신 복리로 쌓이는 종류의 속도를.