이처럼 요구 사항을 수용하기 위해 때로는 아키텍처를 변경해야 할 때도 있습니다. 2장에서 설명했듯이, 아키텍처적으로 중요한 요구 사항은 반드시 아키텍처에서 처리해야 합니다. 이러한 요구가 제때 수용되지 않으면 나중에 아키텍처를 강제로 변경해야 할 수도 있습니다. 하지만 아키텍처적으로 중요한 요구 사항이란 비록 시스템 개발 및 유지 보수에 유용하게 사용할 수 있는 용어지만, 실제로는 해당 요구 사항이 얼마나 시스템에 영향을 미치는지 제대로 파악한 뒤에야 그것이 정말 아키텍처적으로 중요한지 알 수 있습니다.
즉, 시스템 변경이 아키텍처에 얼마나 영향을 미칠지는 어느 정도 작업을 진행한 뒤에야 알 수 있다는 것이 문제입니다. 이 딜레마를 해결하려면 아키텍처와 설계의 구분보다 변경 자체를 관리하는 데 집중해야 합니다. 이는 나중에 이 책에서 설명할 효과적인 소프트웨어 아키텍처가 변경의 유형1이 아니라 변경의 범위에 더 중점을 두는 이유입니다. 이는 아키텍처 변경뿐만 아니라 설계 변경에도 적용될 수 있습니다. 다시 말하자면 시스템의 변경 범위가 넓을수록 더 엄격하게 관리해야 하며, 아키텍처 팀은 이를 더욱 철저히 따라야 합니다. 반면에 아키텍처든 설계든 변경 범위가 좁을 때는 필요한 작업 정도를 팀의 상황에 맞게 적절하게 조정해야 합니다.