핵심

아키텍처의 정의 및 목표, 실전 적용 사례에 대해 다룬 장이었다.

생각해볼 것들

#1 아키텍처의 목표

소프트웨어 아키텍트라면 코드에서 탈피하여 고수준의 문제에 집중해야 한다는 거짓말에 속아 넘어가서는 안된다. 소프트웨어 아키텍트는 다른 프로그래머 만큼 코드를 많이 작성하지 않을 수도 있지만 , 프로그래밍 작업에는 지속적으로 참여한다. 프로그래밍 작업을 계속하는 이유는, 발생하는 문제를 경험해보지 않는다면 다른 프로그래머를 지원하는 작업을 제대로 수행할 수 없기 때문이다.

→ 실제 개발레벨에서 겪는 문제를 해결할 수 없는 아키텍처는 의미가 없다. 아키텍처를 위한 아키텍처 사용을 지양해야하지 않을까? MVP, MVVM 등의 단어에 매몰되어 해당 구조의 트레이드 오프를 인지하지 못하고 사용하는 것은 아닐까?

#2 아키텍처가 가져다주는 이점

시스템 아키텍처는 시스템의 동작 여부와는 거의 관련이 없다. 형편없는 아키텍처를 갖춘 시스템도 수없이 많지만, 그런대로 잘 동작한다. 아키텍처의 주된 목적은 시스템의 생명주기를 지원하는 것이다. 좋은 아키텍처는 시스템을 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지보수하고, 또 쉽게 배포하게 해준다. 아키텍처의 궁극적인 목표는 시스템의 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성은 최대화하는 데 있다.

→ 변경하기 쉬워야한다. 동작만 하는 프로그램은 어떠한 형태로든 구현은 할 수 있으나 점점 유지보수 비용이 눈덩이처럼 불어난다.

다른 요소를 고려하지 않는다면 이 시스템의 아키텍처는 다섯 개의 컴포넌트로 (각 팀마다 하나씩) 발전될 가능성이 높다. 유지보수의 가장 큰 비용은 탐사(spelunking)와 이로 인한 위험부담에 있다. 탐사란 기존 소프트웨어에 새로운 기능을 추가하거나 결함을 수정할 때, 소프트웨어를 파헤쳐서 어디를 고치는 게 최선인지, 그리고 어떤 전략을 쓰는게 최적일지를 결정할 때 드는 비용이다. 이러한 변경사항을 반영할 때 의도치 않은 결함이 발생할 가능성은 항상 존재하며, 이로 인한 위험부담 비용이 추가된다. 주의를 기울여 신중하게 아키텍처를 만들면 이 비용을 크게 줄일 수 있다.

→ 팀이 아니라 개인별로 다른 컴포넌트로 발전될 수도 있다. 비슷한 종류의 비즈니스 로직을 처리하는데 구현 방식이 다르다면 필연적으로 커뮤니케이션을 동반한 유지보수 비용이 추가된다. 균일하고 품질 관리를 위해 코드 리뷰가 꼭 필요한 이유가 아닐까. 코드 리뷰가 어렵다면 어느정도 프레임워크화 시켜서 일관된 구현 방식을 가이드 해볼수도 있겠다.

#3 정책과 세부사항의 분리

모든 소프트웨어 시스템은 주요한 두 가지 구성요소로 분해할 수 있다. 바로 정책과 세부사항이다. 정책 요소는 모든 업무 규칙과 업무 절차를 구체화한다. 세부사항은 사람, 외부 시스템, 프로그래머가 정책과 소통할 때 필요한 요소지만, 정책이 가진 행위에는 조금도 영향을 미치지 않는다.

→ 정책은 핵심 비즈니스 로직, 세부사항은 이를 구현하기 위한 요소들이다. 세부사항으로는 I/O 장치, DB, 서버, 프레임워크 등이 있을 수 있다.

세부 사항에 몰두하지 않은 채 고수준의 정책을 만들 수 있다면, 이러한 세부사항에 대한 결정을 오랫동안 미루거나 연기할 수 있다. 선택사항을 더 오랫동안 열어둘 수 있다면 더 많은 실험을 해볼 수 있고 더 많은 것을 시도할 수 있다. 오늘날의 운영체제는 입출력 장치를 소프트웨어 함수로 추상화했고 (…) 동일한 프로그램을 아무런 변경 없이도 카드에서 읽고 쓰거나 테이프에서 읽고 쓸 수 있게 되었다.

→ 정책은 매우 드문 경우를 제외하고는 변경되지 않는다. 세부 사항은 언제든 변경될 수 있다. 즉, 정책은 세부사항에 대해 의존성이 적을수록 좋다. 세부 사항을 언제든지 바꿀 수 있고, 이러한 세부 사항의 변경에 대해 영향을 받지 않기 때문이다. (OCP 원칙)