행위

이해관계자가 기능명세, 요구사항을 구체화할 수 있도록 돕고
이러한 요구사항을 만족할 수 있도록 코드를 작성하는 것을 말합니다.

아키텍처

이해관계자가 기능에 대한 생각을 바꿀 경우 이런 변경사 항을 쉽게 적용할 수 있도록
변경에 대한 어려움은 변경되는 범위에 비례해야 하며
변경 사항의 형태와는 관련이 없도록 소프트웨어를 유지하는 것을 말합니다.

시스템의 형태와 요구사항의 형태가 맞지 않을 경우 복잡도가 증가합니다.
따라서 아키텍처는 형태에 독립적이어야 합니다.

아이젠하워의 중요성과 긴급성에 관한 매트릭스에 따르면
긴급한 문제가 중요한 문제일 경우는 드물고
중요한 문제가 긴급한 문제일 경우는 거의 없다고 합니다.

행위는
긴급하지만, 대체로 낮은 중요도를 가집니다.

아키텍처는
긴급하진 않지만, 높은 중요도를 가지는 경우가 많습니다.

이해관계자와 엔지니어는 흔히
긴급하지만 중요하지 않은 행위를 긴급하고 중요한 것으로 판단하고 공감하여
아키텍처를 무시하는 실수를 하게 됩니다.
그로 인해 시스템의 변경 비용은 점점 커지게 됩니다.

이해관계자에겐 현재 기능의 동작 여부가 미래의 유연성보다 더 중요합니다.
가까운 미래에 변경비용이 커서 현실적으로 적용할 수 없다고 대답한다면
시스템을 방치했다며 엔지니어에게 화를 낼 가능성이 높습니다.

아키텍처가 후순위가 되면 시스템을 개발하는 비용이 증가합니다.
이러한 상황이 발생하도록 용납했다면 이는 결국 소프트웨어 개발팀이
소프트웨어를 안전하게 보호해야 할 책임을 위해 충분히 투쟁하지 않았다는 뜻이되죠.

따라서 기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 일은 개발팀이 마땅히 책임져야 합니다.

끝.