1

단 한번도 아름다운 아키텍처를 경험해하지 못했기 때문에 책에 다루는 아키텍처를 읽으면서 부러웠다. 저런 아키텍처를 경험할 수 있으면 좋겠다고 막연하게 생각했다.

좋은 아키텍처로 개발을 진행해 보고 싶다는 생각만큼, 좋은 아키텍처를 알아보는 안목을 키우고 싶었다. 아키텍처를 분석하고 해석하는 방법을 엿볼 수 있어서 좋았다.

2

특정 챕터의 경우 아키텍처보다 기술적인 내용을 깊게 다루고 있고, 국내의 개발환경이 많이 다루기 때문에 독자 스스로 선별적으로 내용을 받아들이길 권한다.

---

[…] 다른 말로 아키텍처는 결과물이 가져야 하는 속성이 문제없이 포함될 수 있도록 만드는 시스템을 위한 계획이며, 이미 구축된 시스템의 설명서라 하루 있다.

[…] 왜냐하면 아키텍처는 트레이드 오프trade-off의 게임이기 때문에 이들 특징 중 어느 하나를 개선하면 다른 하나가 악하되어버리기 때문이다.

소프트웨어 아키텍처는 보통 하나의 다이어그램에 몇 가지의 다른 구조가 합쳐져 있는 레이어로 이루어진 계층 구조로 표현된다. 1970년대에 파나스Panas는 ‘계층 구조’라는 용어가 이미 일반적인 용어가 되었음을 지적하고, 그 뜻을 정확히 정의하였다. 또한 서로 다른 시스템의 설계에서 서로 다른 목적으로 쓰이는 구조에 대한 몇 가지 사례들도 제시했다(Parnas 1974). 아키텍처의 구조를 서로 다른 뷰를 가진 집합으로 설명하는 것은 이제 아키텍처 실무의 표준적인 방법이 되었다(클레멘츠Clements et al. 2003; IEEE 2000). 따라서 필자는 앞으로 ‘아키텍처’라는 용어를 시스템을 설계하고 구축하는 데 있어 구조를 서술하고, 주석이 달린 다이어그램과 기능 설명을 가리키는 말로 사용할 것이다.

[…] 전체 시스템에서 하나의 컴포넌트를 담당하는 개발자는 모든 컴포넌트가 어떻게 조화를 이루는지에 대해서는 잘 알지 못하지만 개발에 있어 반드시 따라야 하는 아키텍처적인 제약사항과 사용해야 하는 규칙에 대해서는 우선 신경을 쓴다.

[…] 콘웨이(Conway)는 시스템 구조는 이를 구축한 조직의 구조를 반영한다는 점을 언급한 바 있다(1968). 하지만 아키텍트는 이러한 콘웨이의 법칙(Conway’s Law)이 반대로 적용될 수도 있다는 것도 알아야 한다.

[…] A는 B의 부분이다. B의 다른 부분들을 바꾸지 않고 A의 비밀을 수정하는 것이 가능해야 한다는 것에 주의하라. 만약 그렇지 않다면 A는 정의에 따라 하위 모듈이 아니다.

[…] 사용 관계에 루프가 하나도 없다면 그 소프트웨어는 레벌 구조가 적용된다. 최하위 레벨인 레벌 0에는 다른 프로그램을 사용하지 않는 모든 프로그램이 있다. 레벨 n은 레벨 n-1 또는 그 하위 레벨들에 있는 프로그램을 사용하는 프로그램들로 이루어져 있다.

프로세스는 런타임 때 일어나는 프로그램에 의해 제어되는 이벤트의 연속이다(다익스트라Dijkstra 1968). 프로그램은 하나 또는 여러 개의 프로세스로 실행된다.

[…] 이 아키텍처(A-7E 기내 비행 프로세서OFP, Onboard Flight Processor)는 현실적인 시스템에서의 정보 은폐 모듈과 사용 구조의 런타임 프로세스 구조로부터 분리를 해냄으로써 소프트웨어 아키텍처 실무에 엄청난 영향을 미쳤다. […] 마지막 사례로 유닉스Unix 시스템이 있다. 이는 개념적 통합성을 갖추고, 널리 쓰이며, 지대한 영향력을 갖는다. 파이프와 필터 디자인은 새로운 애플리케이션의 신속한 구축을 가능케 하는 멋진 추상화 개념이 되었다.

소프트웨어 고고학은 무계획 도시 시스템이 왜 그토록 산만해지게 되었는지 중요한 이유 하나를 강조했다. 바로 프로젝트 초창기에 개발 팀이 그들이 무엇을 만들고 있는지를 몰랐다는 것이다.

콘웨이의 법칙은 제품 내에 이해되지 않는 임의의 설계가 어떻게 포함되었는지를 설명할 때 사용하는 법칙 중 하나이다. 이는 팀의 구분이 있는 조직이라면 그 조직 사이의 의사소통 구조가 그대로 설계에 반영되어 소프트웨어 제품상에서 발견할 수 있다는 것을 의미한다. 콘웨이 법칙에 따르면 의사소통 구조가 뛰어날 때 그만큼 훌륭한 제품이 나올 수 있는 것이다.