TL;DR

  • Sensible Default는 특정 작업에서 우선 적용하되, 상황에 따라 재검토하고 바꿀 수 있는 실용적 기본값임.
  • 소프트웨어 개발의 사례로 버전 관리 사용, UI 로직과 도메인 로직 분리, 배포 파이프라인 자동화가 있음.
  • Best practice와 달리 Sensible Default는 모든 상황에서 반드시 따를 규칙이 아니라, 더 나은 대안이 있으면 그 이유를 설명하고 바꿀 수 있는 출발점임.
  • Thoughtworks는 Evan Bottcher가 James Ross와의 대화에서 얻은 이 용어를 바탕으로 실천 항목을 정리한 플레이북을 공개하고, 팀이 이를 새 작업의 기본값으로 활용하도록 함.
  • Thoughtworks는 기본값의 한계를 이해하고 상황에 따라 조정할 것을 강조하며, 이를 정기적으로 재평가하는 일이 Thoughtworks Technology Radar의 핵심임.

Sensible Default의 의미

  • Sensible Default는 어떤 종류의 작업을 수행할 때 이를 뒤집을 만한 맥락이 없다면 적용해야 하는 실천 방식임.
  • 소프트웨어 개발에서 Sensible Default의 사례는 버전 관리 사용, UI 로직과 도메인 로직 분리, 배포 파이프라인 자동화 등임.
  • 이 용어는 Best practice와 의도적으로 대비됨. Best practice라는 표현은 일반적으로 언제나 가장 좋은 실천 방식을 따라야 한다는 전제를 내포해 사람들이 꺼리는 경우가 있음.
  • Sensible Default는 새로운 맥락에서 재평가해야 하며, 상황이 달라지면 대체할 수 있고 대체해야 하는 방식임.

용어의 유래

  • Evan Bottcher가 Thoughtworks 안에서 이 용어를 널리 알렸으며, James Ross와 대화하던 중 이름을 얻음.
  • 이 표현은 찾고 있던 뉘앙스, 즉 검증된 출발점이라는 의미를 담고 있어 마음에 들었음.

환경에 강제적인 제약이 없다면 여러분이 따르기를 기대하는 실천 방식이 Sensible Default임. 이런 실천을 따르거나 더 나은 방식을 택하고, 다른 방식을 선택한 이유를 설명할 준비가 되어 있어야 함.

— Evan Bottcher

Thoughtworks의 활용과 재평가

  • Thoughtworks는 이후 이 개념을 폭넓게 활용했으며, 자사에서 사용하는 Sensible Default를 담은 플레이북도 공개함.
  • 새 작업을 시작할 때 이 기본값을 익히고 활용할 준비가 되어 있기를 기대함. 여러 상황에서 사용해 효과를 확인했기 때문에 자사의 기본값으로 삼은 항목임.
  • 팀은 기본값의 한계도 알고, 구체적인 상황에 따라 조정할지 판단할 수 있어야 함.
  • 열두 번째 애자일 원칙은 팀이 정기적으로 더 효과적으로 일하는 방법을 성찰하고, 그에 맞춰 행동을 조정한다고 밝힘.
  • Thoughtworks는 기본값을 정기적으로 재평가하며, 이것이 Thoughtworks Technology Radar의 핵심임.

다른 용례

  • 웹 검색을 통해 Steve Bennett가 Sensible Defaults를 다룬 글을 발견함. 이 글은 Evan이 James와 대화한 시기와 비슷한 때에 작성됨.
  • James가 이 글에서 이름을 얻었는지, 아니면 두 용례가 서로 독립적으로 나타났는지는 알 수 없음.