15장 아키텍처란?

태그

비어 있음

날짜

2024년 8월 1일

소프트웨어 어키텍트는 코드를 탈피하고 고수준에 문제만 집중하는 것이 아니다. 소프트웨어 아키텍트는 코드와 동떨어져서는 안 된다. 소프트웨어 시스템의 아키텍처란 시스템을 구축했던 사람들이 만들어낸 시스템의 형태다.

💡

이러한 일을 용이하게 만들기 위해서는 가능한 한 많은 선택지를, 가능한 한 오래 남겨두는 전략을 따라야 한다. 

형편없는 아키텍처는 운영은 괜찮지만 배포, 유지보수, 개발 과정에서 어려움을 겪는다. 

아키텍처의 주된 목표 : 시스템의 생명주기를 지원하는 것  

시스템의 수명과 관련된 비용 최소화, 프로그래머의 생산성 최대화 

🔎 개발

팀 구조가 다르면 아키텍처도 다르다.

소규모 팀 → 모노리틱 아키텍처

아키텍처 관련 제약이 방해가 된다고 여길 수 있음

여러 팀으로 구성된다면 안정된 인터페이스를 갖춘 잘 설계된 컴포넌트로 분리된 환경이 아니면 개발이 진척되지 않는다. 

⇒ 팀 별 단일 컴포넌트 아키텍처가 배포, 운영, 유지보수에 최적이 아니지만 일정에 쫓기는 팀이라면 이 아키텍처로 귀착될 것이다. 

소프트웨어 아키텍처는 배포 비용을 줄이기 위해 시스템을 쉽게 배포할 수 있어야 한다.

안정화된 인터페이스 때문에 마이크로 아키텍처를 차용했지만

수많은 마이크로 서비스들의 연결과 작동순서를 결정하는 과정에서 오작동이 발생할 가능성이 있다.

⇒ 배포문제를 초기에 고려했다면 더 적은 서비스를 사용하고 이들을 하이브리드 형태로 융합해 좀 더 통합된 도구를 사용하여 상호 연결을 관리

아키텍처가 운영에 미치는 영향은 다른것들에 비해 적다.

하드웨어 자원을 더 투입해서 문제를 해결할 수 있다.

좋은 소프트웨어 아키텍처는 시스템을 운영하는 데 필요한 요구도 알려준다.

유즈케이스, 기능, 시스템의 필수 행위 들을 개발자에게 인식되게 함. 

소프트웨어 시스템에서 비용이 가장 많이 든다.

결함을 수정할 때 , 기능을 추가할 때 탐사로 인한 비용

⇒ 신중하게 아키텍처를 만들면 이 비용을 줄일 수 있다.

컴포넌트 분리,  인터페이스로 격리 

💡

이러한 일을 용이하게 만들기 위해서는 가능한 한 많은 선택지를, 가능한 한 오래 남겨두는 전략을 따라야 한다. 

열어 둬야 할 선택 사항 ?

중요치 않은 세부사항

소프트웨어는 정책과 세부사행으로 분해할 수 있는데 시스템의 가치는 정책에 있다.

db, 웹, 서버, 프레임워크, 통신 프로토콜은 세부사항이다. 

아키텍트가 세부사항을 정책과 무관하게 만들 수 있게 시스템을 구축한다면 세부사항을 결정하는 일을 미룰 수 있다. 

⇒ 더 맣은 정보를 얻을 수 있고 제대로 된 결정을 내릴 수 있다.

⇒ 더 많은 실험을 해볼 수 있고 더 많은 것을 시도할 수 있다. 

1960년대에 초기에 입출력 장치와 코드를 결합했을 때 장치 종속성이 문제가 되었다.

데이터 무결성이 중요한 문제로 나타났고 자기 테이프로 해결하였다.

더 나아가 입출력 장치를 소프트웨어 함수로 추상화 했다.

동일한 프로그램을 아무런 변경 없이 카드에서 읽고 쓰고 테이프에서도 읽고 쓸 수 있게 되었다. 

우리가 당연하게 생각하고 있던 장치 독립성이 이런 원칙으로 인해 보장되었고 발전해왔던 거구나

처음에 원론적인 이야기들이 더 잘 와닿았다.

세부사항을 정책으로부터 신중하게 가려내기

표