소프트웨어 아키텍처

좋은 소프트웨어 아키텍처의 목표란?

필요한 시스템을 만들고 유지하는데 투입되는 인력을 최소화 하는데 있다.

 

다시말해 설계 품질을 재는 척도는 고객의 요구를 만족시키는데 드는 비용을 재는 척도와 다름없다.

이 비용이 낮을 뿐 아니라 시스템의 수명이 다할 때까지 낮게 유지할수 있다면 좋은 설계라고 할 수 있다.  

 

 

현대의 대다수 개발자는 뼈 빠지게일한다. 

하지만 그들의 뇌는 잠에 취해 있다.

훌륭하고 깔끔하게 잘 설계된 코드가 중요하다는 사실을 알고 있는 바로 그 뇌가 잠자고 있다.

 

'코드는 나중에 정리하면 돼. 당장은 시장에 출시하는게 먼저야' 라고 생각한 개발자는 출시 후에도 절대로 태세를 전화하지 않는다. 왜냐하면 출시후에는 바로 다음에 만들어야할 새로운 기능이 기다리고 있기때문이다.

개발자가 속는 더 잘못된 거짓말은 '지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다' 라는 생각이다. 엉망으로 만들면 깔끔하게 유지할 때보다 항상 느리다. 빨리가는 유일한 방법은 제대로 가는 것이다.

 

---

 

소프트웨어의 두가지 가치, 행위behavior와 구조structure

 

행위

개발자는 이해관계자가 기능명세서나 요구사항문서를 구체화하고 만족하도록 기계에 코드를 구현하고 비그를 수정하는 일을 한다.

 

구조

소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어는 변경하기 쉬워야한다. 개발자는 이해관계자가 기능에 대한 생각을 바꾸면 이러한 변경사항을 간단하고 쉽게 적용할 수 있어야 한다. 

 

변경사항을 적용하는데 드는 어려움은

변경되는 범위scope에 비례하며, 변경사항의 형태shape와는 관련이 없어야 한다.

새로운 요청사항이 발생할 때마다 바로 이전의 변경사항을 적용하는 것보다 조금 더 힘들어지는데, 시스템의 형태와 요구사항의 형태가 서로 맞지 않기 때문이다.

---

 

행위는 긴급하지만 매번 높은 중요도를 가지는 것은 아니다.

반면 아키텍처는 중요하지만 즉각적인 긴급성을 필요로 하는 경우는 절대 없다.

 

상황에따라 우선순위를 매겨야 하겠지만 개발자가 흔히 저지르는 실수는 긴급하지만 중요하지 않은 항목을 중요하면서도 긴급하지 않은 기능을 구분하지 못하는것이다.

아키텍처의 중요성을 평가할만한 능력을 겸비하지 못한 소프트웨어 개발팀은,

팀이 해야할 기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 일을 책임지지 못하게 된다.

아이젠하워 매트릭스

---

 

인사팀 마케팅팀 영업팀 개발팀은 모두 각자 회사에서 가장 중요하다고 스스로 믿는 가치를 위해 투쟁한다.

아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다. 이러한 상황이 발생하도록 용납했다면, 이는 결국 소프트웨어 개발팀이 스스로 옳다고 믿는 가치를 위해 충분히 투쟁하지 않았다는 뜻이다.

 

아키텍처를 위해 투쟁해라!