# [[Built-in Quality]]

## 📌 Brief Summary
Built-in Quality는 SAFe(Scaled Agile Framework) 환경에서 여러 팀이 지속적으로 가치를 전달하는 데 필요한 속도와 신뢰성을 확보하게 해주는 핵심적이고 기초적인 관행이다 [1]. 이는 수동 테스트 실행을 단순히 스크립트로 대체하는 것을 넘어서는 개념으로, 자동화된 테스트, 리팩토링, 체계적인 동료 검토(Peer Review) 등을 포괄한다 [1, 2]. 이 관행은 조직이 자동화를 확장하기 전에 필수적으로 갖추어야 할 코드 품질의 전제 조건으로 작용한다 [2].

## 📖 Core Content
* **핵심 관행으로서의 Built-in Quality**: Built-in Quality는 리팩토링, 자동화된 테스트, 그리고 체계적인 동료 코드 리뷰(Peer Review)를 포함하는 조직적 필수 요건이다 [2]. 특히 SAFe 환경에서의 자동화 테스트는 근본적인 Built-in Quality 관행으로 간주된다 [1].
* **완료의 정의(Definition of Done, DoD)를 통한 공식화**: 자동화된 테스트 요구사항을 DoD에 포함시킴으로써 품질에 대한 약속을 공식화할 수 있다 [3]. '모든 관련 자동화 테스트가 통과하고 새로운 테스트가 새 기능을 커버한다'는 것을 타협 불가능한 DoD 기준으로 삼으면, 배포 압박 속에서도 팀이 품질을 타협하는 것을 방지할 수 있다 [3].
* **표준화된 체크리스트 활용**: Built-in Quality 체크리스트나 템플릿을 사용하면, 애자일 릴리스 트레인(ART) 내 모든 팀에서 테스트에 대한 '완료(done)'의 의미를 일관되게 표준화하는 데 도움을 받을 수 있다 [3].

## ⚖️ Trade-offs & Caveats
Built-in Quality 관행을 통해 탄탄한 코드 품질 기반을 다지지 않은 채 자동화를 성급하게 확장(scaling)하려 하면 심각한 부작용이 발생할 수 있다 [2]. 품질 기반을 건너뛴 팀들은 자신들이 구축한 테스트 스위트가 보호해야 할 대상인 프로덕션 코드만큼이나 깨지기 쉽고(brittle) 유지보수하기 어려운 상태로 전락하는 것을 자주 겪게 된다 [2]. 결과적으로, 견고한 품질 기초 위에 구축되지 않고 취약한 코드베이스 위에 자동화가 덧붙여진다면 흐름 효율성(Flow Efficiency)과 배포 성공률(Deployment Success Rates)이 모두 악화되는 결과를 초래하게 된다 [2].

---
*Last updated: 2026-05-03*