[Architecture] 아키텍처 (Architecture)

클린 아키텍처

아키텍처 (Architecture)

• 시스템을 구축했던 사람들이 만들어낸 시스템의 형태로 그 모양은 아래 3가지 방식에 따라 정해짐
  1. 시스템을 컴포넌트로 분할하는 방법
  2. 분할된 컴포넌트를 배치하는 방법
  3. 컴포넌트가 서로 의사소통하는 방법
• 소프트웨어 아키텍트 : 아키텍처를 설계해내는 프로그래머
  • 다른 프로그래머만큼 코드를 많이 작성하진 않지만 프로그래밍 작업에 지속적으로 참여함
  • 나머지 팀원들이 생산성을 극대화할 수 있는 설계를 하도록 방향을 이끔
• 시스템 아키텍처는 시스템의 동작 여부와는 거의 관련이 없다.
  • 아키텍처가 형편없어도 시스템은 잘 동작하는 경우도 많다.
  • 아키텍처가 안 좋으면 운영보다는 배포, 유지보수하는 과정에서 어려움을 겪는다.
• 아키텍처의 주된 목적 : 시스템의 생명주기를 지원하는 것
  • 좋은 아키텍처는 시스템을 쉽게 이해, 쉽게 개발, 쉽게 유지보수, 쉽게 배포하게 해줌
• 아키텍처의 궁극적 목표
  • 시스템 수명과 관련된 비용 최소화
  • 프로그래머의 생산성을 최대화

 

개발

• 팀 구조에 따라서 아키텍처 관련 결정도 차이가 난다.
  • 팀 개발자가 5명 정도의 작은 규모라면, 잘 정의된 컴포넌트, 인터페이스가 없더라도 효율적으로 협력하여 모노리틱 시스템을 개발 할 수 있다.
  • 이런 경우엔 개발 초기에 아키텍처 관련 제약들이 오히려 방해가 된다고 여길 수 있다.
  • 모노리틱 프로그램 (monolithic program) : 단일 코드 트리 구조의 프로그램으로 컴포넌트 단위로 분리되지 않고 여러 기능이 하나로 결합된 형태
• 만약 7명씩 구성된 5팀인 경우라면
  • 시스템을 신뢰할 수 있고 안정된 인터페이스를 갖춘, 잘 설계된 컴포넌트 단위로 분리하지 않으면 개발이 진척되지 않음.
  • 5개의 컴포넌트로 발전될 가능성이 높다 (팀당 1개)
  • '팀별 단일 컴포넌트' 아키텍처가 시스템 배포, 운영, 유지보수의 최적일 가능성은 거의 없다.
  • 하지만 일정에 쫓겨서 일하면 결국 이 아키텍처로 귀착됨.

 

배포

• 개발 초기 단계에선 배포 전략을 거의 고려하지 않는다.
• 따라서 개발하기는 쉬워도 배포하기는 어려운 아키텍처가 만들어질 수 있다.
• 만약 개발 초기에 '마이크로 서비스 아키텍처'를 적용해서 개발을 한다면 개발 시에는 편하지만 배포할 시기에는 너무 많은 마이크로 서비스를 발견할 수도 있다.
  • 개발 초기에 배포 전략을 고려했다면 다른 결정을 내렸을 것이다.

 

운영

• 아키텍처가 운영에 미치는 영향을 다른 케이스에 비해서 덜 극적이다.
• 대다수의 어려움은 단순히 하드웨어를 더 투입해서 해결할 수 있다.

 

유지보수

• 유지보수는 모든 측면에서 봤을 때 소프트웨어 시스템에서 비용이 가장 많이 든다.
• 새로운 기능을 계속 개발하고 뒤따라서 결함이 발생하고, 그 결함을 수정하는데 엄청난 인적 자원이 소모된다.
• 유지보수의 가장 큰 비용은 '탐사'와 이로 인한 위험부담에 있다.
  • 탐사 : 기존 소프트웨어에 새로운 기능을 추가하거나 결함을 수정할 때, 소프트웨어를 파헤쳐서 어디를 고치는게 최선인지 그리고 어떤 전략을 쓰는게 최적일지를 결정할 때 드는 비용
  • 이런 변경사항을 반영할 때 의도치 않게 결함이 발생할 수 있으며, 이로 인한 위험부담 비용이 추가됨.
• 신중한 아키텍처를 만들면 이 비용을 크게 감소시킬 수 있다.
  • 시스템을 컴포넌트로 분리, 안정된 인터페이스를 두어 서로 격리한다.
  • 이를 통해 미래에 추가될 기능에 대한 길을 밝혀 둘 수 있을 뿐만 아니라 의도치 않은 장애가 발생할 위험을 크게 줄일 수 있다.