문제 있는 변경은 단기적이라는 명목으로 시스템 아키텍처를 저해합니다. 사실 아키텍처에서 단기적인 변경이란 환상에 불과합니다. 단기적인 조치로 만든 새로운 구성 요소나 관계는 이후 다른 시스템 변경으로 제거되지 않는 한 계속 남아 있기 때문입니다.

실제로 이러한 변경은 나중에 정리되지 않을 때가 대부분입니다. 프로젝트에서 단기적인 변경은 자주 일어나며, 이러한 일은 계속 나타나는 경향이 있습니다. 의존성이 쌓이면 이후 변경하기 더욱 어려워지고, 이는 일정 압박을 가중시켜 더 많은 단기적 수정을 하게 되는 악순환을 초래합니다. 이처럼 단기적 변경은 결국 장기적으로 프로젝트를 망친다는 점에서 아이러니한 일입니다.

따라서 아키텍처 팀이 하는 역할 중 하나는 실제로는 그렇지 않은 단기적 변경을 지적하는 것입니다. 이를 효과적으로 하는 방법은 단기적 변경을 아키텍처적 관점에서 다시 바라보는 것입니다. 예를 들어 개발 팀이 “우리는 컴포넌트 A가 컴포넌트 B를 호출할 수 있게 간단히 변경하려고 합니다.”라고 말하면, 아키텍처 팀은 “하지만 이 변경 전에는 컴포넌트 A와 컴포넌트 B가 서로 독립적이며 상호 작용하지 않았습니다.”라고 지적할 수 있습니다.