7. 작은 배치로 작업하기
정의
작은 배치로 작업하기(Working in small batches) 는 피드백 루프가 중요한 모든 규율의 필수 원칙입니다. 작은 배치는 특정 개선이 원하는 효과를 낼지 빠르게 가설을 검증하고, 아니면 방향을 바꾸거나 가정을 재검토하게 해줍니다.
린 제품 관리의 일부이며, 가치 흐름 가시성·팀 실험·고객 피드백 가시성과 함께 소프트웨어 딜리버리 성과와 조직 성과를 예측합니다.
AI 시대에 이 역량은 더욱 중요해졌습니다. DORA 연구: 작은 배치는 AI 도입이 제품 성과에 미치는 긍정 효과를 증폭하고, AI의 조직 마찰에 대한 중립적 효과를 순긍정으로 바꿉니다.
이점
- 변경에 대한 피드백 시간을 줄여 문제 분류·교정이 쉬워진다.
- 효율과 동기를 높인다.
- 매몰 비용 오류(sunk-cost fallacy)를 막는다.
- AI 도입의 안전망: AI 도입은 종종 딜리버리 불안정성 증가로 이어진다. 작은 배치는 이 위험에 대한 핵심 대응으로, AI의 속도가 혼돈이 아니라 가치로 이어지게 한다.
구현 방법
새 기능을 계획할 때 독립적이고 짧은 시간에 완료 가능한 작업 단위로 쪼갭니다. 각 기능/배치는 애자일의 INVEST 원칙을 따르는 것이 좋습니다.
- Independent — 다른 배치와 독립적이어서 순서 무관하게 작업·배포·검증
- Negotiable — 반복 가능하고 피드백에 따라 재협상
- Valuable — 이해관계자에게 사용 가능하고 가치 제공
- Estimable — 범위를 쉽게 추정할 정보 존재
- Small — 몇 시간에서 이틀 정도 안에 완료
- Testable — 테스트·모니터링·검증 가능
이상적으로 개발자는 하루에 최소 한 번, 여러 개의 작은 릴리스 가능 변경을 trunk에 체크인해야 합니다.
AI 시대의 핵심
AI는 큰 코드 블록을 빠르게 생성하는 데 능하지만, 큰 변경은 리뷰·테스트·통합이 어렵습니다. 작은 배치를 강제하면 개발자의 초점이 원시 코드 생성에서 사려 깊은 분해와 검증으로 이동합니다. AI 도구가 대규모 PR을 생성하도록 유도하는 유혹을 피하세요. 기계 생성 코드는 줄당 인지 부하가 사람이 쓴 코드보다 높을 수 있습니다.
유용한 기법
- API/서비스 계층에서 시작하고 UI가 아니라 서비스/API 계층에서 개발한다.
- 다크 런칭(dark launching): 사용자에게 보이지 않고 프로덕션에 변경을 배포.
- 기능 토글(feature toggle): 구성 설정 기반 조건문으로 동작을 켜고 끈다.
- 추상화 브랜치(branch by abstraction): long-lived 브랜치를 만들지 않고, 추상화 계층을 두어 기존 구현과 새 구현을 전환하면서 trunk 위에서 큰 규모 변경을 점진적으로 개발·배포한다.
배치는 프로덕션에 배포되고 피드백 검증이 시작될 때 완료됩니다.
흔한 함정
- 충분히 작게 쪼개지 않음. 기능 상태와 무관하게 코드를 커밋하고, 개별 기능은 며칠을 넘기지 않게 한다. 일주일 이상 걸리는 배치는 너무 크다.
- 작게 나눴다가 다시 묶어서 하류로 보냄. 이는 결함·적합성에 대한 피드백을 지연시킨다.
측정 방법
- 애플리케이션 기능이 잦은 릴리스를 지원하도록 분해되는가? (릴리스 가능 빈도, 팀별 편차, 큰 기능으로 인한 지연 여부)
- 기능이 개발자가 일주일 이내에 완료할 수 있게 조각화되는가? (완료 비율, 완료 전 커밋·릴리스 가능 여부)
- MVP가 정의되어 팀 목표로 설정되는가?
측정은 조직 프로세스 이해, 낭비 감소 목표 설정, 개발 프로세스 복잡성 축소에 달려 있습니다.
출처
이 글은 DORA의 Working in small batches를 요약한 것입니다. 원문 © Google LLC, CC BY 4.0.