개인적 견해는 기울임꼴로 작성했다.
서문
아키텍처의 규칙은 동일하다.
현재의 소프트웨어는 과거와 동일한 것들로 구성되어 있다. 하드웨어는 더 작고 빨라졌지만 소프트웨어를 구성하는 것돌은 조금도 바뀌지 않았다. 아키텍처의 원칙은 보편적이며 시간이 지나더라도 변함이 없다.
앨런 튜링이 최초로 기계어 코드를 작성한 1946년에서 달라지지 않았다. 과거에는 규칙을 몰랐거나 어겼을 뿐이다. 이 책은 세월이 흘러도 변치 않는 그 규칙에 관한 것이다.
1부. 소개
1장. 설계와 아키텍처란?
설계와 아키텍처의 차이는?
설계와 아키텍처 둘 사이에는 아무런 차이가 없다. 설계를 저수준, 아키텍처를 고수준을 의미하는 용어로 자주 사용되지만 무의하다. 이 둘은 단절없이 이어진 직물과 같으며 개별로 존재할 수 없다. 고수준에서 저수준으로 가는 의사결정의 연속성만 존재한다.
목표
유지보수 비용을 최소화 하는 것이다. 아키텍처는 시스템을 구체화하는 중요한 설계 결정을 표현하며, 그 결정의 중요도는 변경에 드는 비용으로 측정된다.
결론
아키텍처를 심각하게 고민해야한다. 아키텍처를 고려할 수 있으려면 좋은 아키텍처가 지닌 속성을 알아야한다.
2장. 두 가지 가치
행위
- 이해관계자를 위해 수익을 창출하거나 비용을 절약하도록 해야한다.
- 기능 명세서나 요구사항 문서를 구체화할 수 있도록 도와야한다.
아키텍처
- 소프트웨어를 만든 이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서다.
- 변경사항을 적용하는데 드는 어려움은 변경되는 범위(scope)에 비례해야 하며, 형태(shape)와는 관련이 없어야한다.
아키텍처를 위한 투쟁
- 개발자도 이해관계자임을 명심하고 소프트웨어를 안전하게 보호해야 할 책임이 있다.
- 아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다.
거대 IT기업들을 생각해 보면 고객 중심에서 생각하지만 모든 걸 해결해 주지는 않는다. 예를 들면 제한적인 고객 서비스를 생각해 볼 수 있다. "이번엔 해드리겠습니다."는 없는 편이다. "매뉴얼을 참고해 주세요."식의 대응이 많다.
개인의 문제를 해결해 주기보다는 인터페이스를 사용자 친화적으로 만들거나 다수의 불편함을 해결할 수 있는 기능에 집중한다. 이것은 대기업의 횡포보다는 IT기업을 안정적으로 유지하기 위한 방어 수단이 아닐까.
그런 의미에서 AI의 파워는 강력하다고 생각한다. 기업 본질인 AI서비스에 집중하면 스스로 사용자 맞춤 서비스를 제공하니(?)
'기술도서' 카테고리의 다른 글
클린 아키텍처 요약 - 4부. 컴포넌트 원칙 (0) | 2024.06.30 |
---|---|
클린 아키텍처 요약 - 3부. 설계원칙 (3) (0) | 2024.06.29 |
클린 아키텍처 요약 - 3부. 설계원칙 (2) (3) | 2024.04.22 |
클린 아키텍처 요약 - 3부 설계원칙 (1) (0) | 2024.03.12 |
클린 아키텍처 요약 - 2부 벽돌부터 시작하기:프로그래밍 패러다임 (6) | 2024.02.26 |