A Sensible Default is a practice, language, framework or tool adopted as the default choice for an engineering team.
'분별력 있는 기본값'은 개발팀이 채택한 루틴, 언어, 프레임워드 등의 기본 기술 스택을 의미한다.
Engineers are still empowered to choose other technology where necessary, but alternatives need to be justified in relation to their advantages over the Sensible Default.
개발자들은 적재적소에 맞는 기술을 고르면서 즐거워진다. 그러나 대안책은 반드시 '분별력 있는 기본값'보다 더 나은 이점이 있을 때만 사용되어야 한다.
The motivations and context behind decisions become difficult to track, and it becomes difficult for team members, both new and existing, to keep track of them as projects develop.
선택의 배경에 있던 동기와 맥락은 추적하기 어려워지고, 프로젝트가 진행될수록 현재 있는 멤버들에게도 다시 떠올리기 어려워진다.
Therefore, once debated, discussed and dissected, technology choices that become the Sensible Default should be documented for future reference, using something like Architecture Decision Records (ADRs).
따라서, '분별력 있는 기본값'을 선택하는 토론이 끝났다면 반드시 문서화하여 기록해야 한다. 이는 추후 Architecture Decision Records(ADRs) 와 같이 사용될 수 있다. (역자 참고 - An architectural decision record (ADR) is a document that captures an important architectural decision made along with its context and consequences.)
Many times when I explain the concept of Sensible Defaults, I’m challenged by engineers who believe that by setting defaults I’m reducing the scope of innovation and experimentation.
내가 '분별력 있는 기본값'을 역설하면 많은 개발자들은 그로 인해 개발팀 내의 혁신과 실험이 줄어들 거라고 반박한다.
To ensure a team doesn’t end up in this situation, I encourage the use of innovation or free development time. During this time, engineers are free to use whatever technology they like to build non-mission critical applications.
팀 내의 이런 상황을 막기 위해서 나는 자유롭게 개발할 수 있는 기간을 준다. 이 시간동안 개발자들은 비즈니스적인 이득과는 상관 없이 원하는 기술을 무엇이든 사용해볼 수 있다.
However, Sensible Defaults are just that - defaults. They’re the first choice, not the only choice, and deviations are still possible, providing we make these choices consciously.
그러나 '분별력 있는 기본값'은 결국 - 기본일 뿐이다. 이 도구들은 첫 번째 선택일 뿐, 최종 선택이 아니다. 우리의 선택을 좀더 신중하게 만들어줄 일탈은 언제든 가능하다.
