측정과 DORA

"빠르게 가면 품질이 떨어진다" — 이거 정말일까? DORA 연구가 데이터로 증명한 건 정반대야. 최고 성과 팀은 더 빠르면서 동시에 더 안정적이야.

소프트웨어 업계에는 **"새것 숭배(Novelty Bias)"**가 있어. 새 프레임워크가 나오면 다들 뛰어들지. "이번엔 진짜 다르다"며. 이력서 주도 개발(Resume-Driven Development) — 새 기술을 이력서에 쓰고 싶어서 프로젝트에 도입하는 거야. 팀 생산성이나 제품 품질과는 아무 관련 없는데. 진짜 공학자라면 "이 기술이 왜 더 나은가?"를 트위터 트렌드가 아니라 증거로 판단해야 하잖아. 새것에 열광하기 전에, 기존의 것이 왜 문제인지를 먼저 측정해야 해.

그런데 뭘 측정해야 할까? 기능적 요구사항은 쉬워. 문제는 비기능적 요소 — 성능, 확장성, 유지보수성, 배포 용이성 같은 거야. 기능이 아무리 훌륭해도 배포에 6개월 걸리고, 변경할 때마다 장애가 나면 그 소프트웨어는 실패거든. DORA 연구가 제시하는 네 가지 지표 — 배포 빈도, 변경 리드타임, 변경 실패율, 평균 복구 시간 — 이것들이 소프트웨어 팀의 생산성을 가장 잘 반영해.

여기서 핵심 발견이 나와. **안정성(Stability)**과 **처리량(Throughput)**은 트레이드오프가 아니야. "빠르게 vs 안전하게"는 거짓 이분법이거든. 작은 변경을 자주 배포하면 각 변경의 위험이 줄어들어. 6개월치 변경을 한 번에 배포하는 것과, 하루에 여러 번 작은 변경을 배포하는 것 중 어느 쪽이 문제 원인을 찾기 쉬울까? 당연히 후자지. 제대로 된 공학적 실천법 — 자동화 테스트, CI/CD, 작은 배치 — 을 적용하면 속도와 안정성을 동시에 얻을 수 있어.

그렇다면 우리는 어떤 전문가가 되어야 할까? Farley는 React 전문가, Java 전문가가 아니라 **"학습과 발견의 전문가"**가 되라고 해. 복잡성 관리, 빠른 피드백 루프, 점진적 변경 — 이런 원칙은 프레임워크가 바뀌어도 변하지 않거든. 5년 전의 React 지식은 쓸모가 줄었지만, 5년 전에 배운 모듈화 원칙은 여전히 유효해. 우리의 진짜 전문성은 특정 API를 외우는 게 아니라, 복잡한 문제를 분해하고 가설을 세우고 검증하는 능력이야.

---

정리

2장 읽고 기억할 거 세 가지:

1. 새 기술에 뛰어들기 전에, 기존 문제를 먼저 측정하라. 증거 없이 기술을 도입하는 건 유행 추종이지 공학이 아니야.
2. 안정성과 처리량은 트레이드오프가 아니다. 작은 변경을 자주 배포하면 속도와 안정성을 동시에 높일 수 있어. DORA 연구가 이걸 데이터로 증명했어.
3. 특정 기술 스택이 아니라 "학습과 복잡성 관리"의 전문가가 되어라. 프레임워크는 바뀌지만, 추상화와 모듈화 원칙은 영원해.