기능 절제 원칙
기능은 기본적으로 붙이지 않습니다. 붙이는 순간이 아니라, 붙어 있는 내내 비용이 발생하기 때문입니다.
새 기능을 넣을지 말지 감이나 관성으로 정하지 않고, “왜 필요한가”에 답할 수 있을 때만 추가하는 것을 원칙으로 합니다.
기본값은 “붙이지 않는다”
섹션 제목: “기본값은 “붙이지 않는다””기능은 더하는 쪽이 아니라 빼는 쪽을 기본값으로 둡니다. 추가하려면 다음 질문에 답할 수 있어야 합니다.
- 이 기능이 없으면 사용자가 실제로 무엇을 못 하는가?
- 브라우저·OS·기존 화면 흐름이 이미 제공하는 기능과 중복되지 않는가?
- 이 기능을 유지·테스트·문서화하는 비용을 감수할 만한 가치가 있는가?
세 질문에 분명히 답하지 못하면 넣지 않습니다.
판단의 방향은 분기점 최소화와 같습니다. 기본은 최소, 근거가 있을 때만 추가한다.
플랫폼이 이미 제공하는 기능은 두지 않는다
섹션 제목: “플랫폼이 이미 제공하는 기능은 두지 않는다”브라우저·OS가 이미 제공하는 동작을 UI로 다시 만들면 중복 컨트롤이 됩니다. 대표적인 예가 수동 새로고침 버튼입니다.
- 브라우저 자체에 새로고침이 있고, 잘 설계된 화면은 액션 후 자동 재조회(re-fetch)·낙관적 업데이트로 최신 상태를 유지합니다.
- 따라서 대부분의 관리자 화면에서 새로고침 버튼은 불필요한 요소입니다.
예외 — 근거가 있을 때만
섹션 제목: “예외 — 근거가 있을 때만”다음처럼 사용자가 갱신 시점을 통제해야 하는 근거가 있을 때만 둡니다.
- 실시간 외부 데이터를 보는 화면(모니터링·로그·시세 등)에서 상시 폴링이 비싸 원할 때만 갱신하고 싶은 경우
- 작업 도중 데이터가 갑자기 바뀌면 곤란해 갱신 시점을 사용자가 통제해야 하는 경우
예외는 “습관”이 아니라 “근거”로만 정당화됩니다.
왜 비용 문제인가
섹션 제목: “왜 비용 문제인가”불필요한 기능은 추가 시점에 끝나지 않고, 수명 내내 테스트·문서·버그·인지 부하를 만들어 관리 비용이 됩니다.
대부분의 기능은 실제로 쓰이지 않는다
섹션 제목: “대부분의 기능은 실제로 쓰이지 않는다”- Standish Group(CHAOS, 2002): 기능 사용 빈도가 rarely 19% · never 45% — 약 64%가 거의/전혀 쓰이지 않음
- Pendo 기능 채택 리포트(2019, 600개사 이상 실사용 데이터): 기능의 약 80%가 거의/전혀 사용되지 않음, 상위 12% 기능이 일일 사용의 80%를 차지
안 쓰이는 기능도 비용은 계속 발생한다
섹션 제목: “안 쓰이는 기능도 비용은 계속 발생한다”- 유지보수는 소프트웨어 수명주기 비용의 60~80%(IEEE)를 차지하며, 전체로 보면 초기 개발비의 2~4배에 이릅니다.
- 즉 기능은 만들 때 한 번이 아니라, 존재하는 내내 비용을 발생시킵니다.
이 때문에 기능을 절제하는 것은 취향이 아니라 비용 관리입니다.
기능 절제 원칙의 목적
섹션 제목: “기능 절제 원칙의 목적”기능 절제 원칙은 꼭 필요한 기능만 남기고 불필요한 기능이 만드는 관리 비용을 걷어내기 위한 기준입니다.
관련 근거: Pendo 기능 채택 리포트 · 소프트웨어 유지보수 비용 비중 · 기능 부풀림(feature creep)