설계와 아키텍쳐란 ?

• 결론은 아키텍쳐와 설계는 아무 차이가 없음

  • 아키텍쳐 는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 사용 e.g. 집의 형태, 외관, 입면도, 공간, 방의 배치 등
  • 설계는 저수준의 구조 또는 결정사항 등을 의미할 때 e.g. 콘센트, 전등 스위치, 전등의 위치 등

• Software Architecture 의 목표

  • 필요한 시스템을 만들고 유지보수하는 데 투입되는 비용을 최소화

• 토끼와 거북이’에서 토끼는 자신의 능력을 과신하고 잠을 자버림

  • 이와 유사하게, 개발자도 자신의 능력을 믿고 나중에 코드를 고친다든, 유지보수보다 기능 출시가 우선이라는 등의 과신이 있는데, 이런 상태로는 엉망진창인, 유지보수가 전혀 되지 않는, 생산성이 떨어지는 코드가 되버림
  • 애초부터 이런 마음가짐을 고치지 않으면 재설계한다 하더라도 같은 실수를 반복하고, 스스로에 대한 과신을 버린 후, 올바른 아키텍쳐를 적용해야지 생산성이 높은, 유지보수 가능한 코드를 작성할 수 있다.

두 가지 가치에 대한 이야기

• 소프트웨어 시스템은 서로 다른 두 가지 가치를 제공함 → 행위(behavior)와 구조(structure)

• 행위

  • 기계의 수익 창출 / 비용의 절약

• 아키텍쳐

  • Soft(부드러운) ware(제품) 이라는 뜻에서 알 수 있듯, 기계의 행위를 쉽게 변경할 수 있음 → 즉, 소프트웨어는 반드시 부드러워야 함 / 변경하기 쉬워야 함
  • 변경에 드는 어려움은 변경의 범위에만 비례해야 하고, 변경의 형태와는 관련이 없어야 함

• 아이젠하워 매트릭스

  중요함 & 긴급함	중요함 & 긴급하지 않음
  중요하지 않음 & 긴급함	중요하지 않음 & 긴급하지 않음

  행위 는 긴급하지만 중요하지 않고 아키텍쳐 는 긴급하지 않지만 중요함

  해당 분류에 대한 우선순위는 아래와 같음

  1. 긴급하고 중요함
  2. 긴급하지는 않지만 중요한
  3. 긴급하지만 중요하지 않은
  4. 긴급하지도 중요하지도 않은

  하지만, 때때로 3.을 최우선순위로 격상시키는 경우가 발생 → 이런 때에 중요도가 높은 아키텍쳐가 무시되고 중요도가 낮은 기능을 선택하게 됨

한 줄 요약

<aside> 💡 아키텍쳐가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다.

</aside>