소프트웨어 아키텍처 The Hard Parts

얼마 전에 발표자로 참여했던 카카오 테크밋 행사의 패널 토의에서 리팩터링 전과 후의 차이를 수치로 측정할 객관적인 지표에 대한 질문의 답변으로 설명한 내용 중에 발표에서 소개했던 '코드 복잡도'와 이 책에서 읽었던 피트니스 함수에 대해서 간단히 소개했었다.

 

이 책은 예전에 소개했던 '소프트웨어 아키텍처 101'(이하 101)의 후속으로 많은 내용이 101과 이어지며, 101은 저자가 2명이었는데, 이 후속작은 저자가 4명으로 늘었다. 그 영향인지 가상의 팀을 구성하고 대화체로 상황을 설명하는 방식이 추가되었지만, 책의 분위기는 크게 달라지지 않았다. 101에서 계속 강조하던 트레이드오프의 중요성도 계속 강조된다.

소프트웨어 아키텍처에서는 최고의 설계를 고집하지 마세요. 그 대신에 나쁜 것 중에서 제일 나은(least worst) 트레이드오프 조합을 찾으세요.
...
다른 사람들이 여러분에게 뭔가 전도하도록 강요하지 못하게 하세요. 만사가 다 트레이드오프니까요.

 

101에서 책 중반에 소개되었던, '아키텍처 피트니스 함수'를 이 책에서는 초반에 설계와 품질 원칙을 자동화하는 방법으로 다시 소개한다. 클래스 또는 서비스 간의 의존성 그래프, 커플링 정도, 상속의 깊이 등을 피트니스 함수로 뽑아낼 수 있고, 이를 리팩터링 전과 후의 차이를 확인하는 지표로 활용할 수도 있다. 우리가 흔히 알고 있는 정적 분석 툴 소나큐브 등도 피트니스 함수 개념에 포함된다. 하지만, 저자가 짚어주듯이 정적인 것만 있지는 않다. 통합 테스트와 부하 테스트 등에서 응답 시간, 메모리 사용량 등을 모니터링하는 피트니스 함수를 두고 활용할 수도 있다.

2017년 출간된 『Building Evolution Architectures』(O’Reilly, 2017)에서 저자들(닐 포드, 레베카 파슨스, 패트릭 쿠아)은 아키텍처 피트니스 함수라는 개념을 ‘어떤 아키텍처 특성이나 그것들을 조합한 아키텍처 특성의 무결성을 객관적으로 평가하는 임의의 메커니즘’이라고 정의했습니다.
...
피트니스 함수와 단위 테스트를 구분하는 것은 아키텍트 입장에서 바람직한 범위 설정 지침입니다. 피트니스 함수는 아키텍처 특성을 검증하는 것이지, 도메인 설계를 검증하는 게 아닙니다. 단위 테스트는 정확히 그 반대입니다. 그러므로 아키텍트는 ‘이 테스트를 하려면 도메인 지식이 필요한가?’를 자문해서 피트니스 함수가 필요한지, 아니면 단위 테스트가 필요한지 판단할 수 있습니다. 이 질문에 대한 대답이 ‘예’이면 단위, 기능, 유저 인수 테스트를, ‘아니오’이면 피트니스 함수를 선택합니다.
...
피트니스 함수는 객관적인 결과를 얻는 것이 중요하지만 ‘객관적’이라고 해서 꼭 ‘정적’인 것을 의미하지는 않습니다. true/false나 성능 문턱값(임계치) 같은 비콘텍스트 값을 반환하는 피트니스 함수도 있고, 콘텍스트에 따라서는 다른 값을 반환하는 (동적 양상을 보이는) 함수도 있습니다.

 

책의 초반부에 소개한 피트니스 함수를 책 전반적으로 계속 언급하면서 활용처를 소개한다. 완전히 새로운 내용을 이야기한다기보다, 대부분은 101에서 언급되었던 아키텍처 퀀텀, 데이터 분해, 사가 패턴 등에 대한 내용 등을 더 심도 있게 다루면서, 데이터 분산 처리에 대한 비중이 늘었다. 101을 재밌게 봤다면, 이 책도 재밌게 볼 수 있을 것이다.

 

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=303046970

[전자책] 소프트웨어 아키텍처 The Hard Parts

데이터는 소중한 것입니다. 데이터는 시스템 자체보다 더 오래갈 테니까요. 팀 버너스-리
...
소프트웨어 프로젝트에서 중요하지만 긴급하지는 않은 원칙들을 실천할 수 있는 체크리스트를 만드는 게 좋습니다. 실제로 프로젝트 현장에서는 이게 나쁘다는 건 아는데, 시간이 없으니 그냥 가고 나중에 고치자.라는 식으로 긴급성에 묻혀 중요한 원칙들이 간과되는 일이 참 많습니다. 이것이 기술 부채를 지게 되는 가장 흔한 원인이기도 합니다. 아키텍트는 코드 품질, 구조, 그리고 계속 실행되는 피트니스 함수에 반해 안전망이 허술해지지 않도록 규칙을 체계화함으로써 개발자가 그냥 지나칠 수 없는 품질 체크리스트를 작성합니다.
...
다른 도메인에 있는 데이터가 필요해도 해당 데이터베이스에 직접 연결하지 말고, 그 데이터 도메인을 소유한 서비스를 통해 액세스하세요.
...
단일 책임 원칙은 원래 그 범위가 클래스 내부에 한정됐지만, 이후에는 컴포넌트, 서비스까지 개념이 확장됐습니다. 마이크로서비스 아키텍처에서 마이크로서비스는 한 가지 일을 아주 잘하는 개별 배포된 전용 소프트웨어 단위로 정의합니다.
...
결국 전반적인 성능 관점에서 보자면, 서비스들이 각자 알아서 서로 통신하는 성능 손실을 감수하더라도 서비스를 반드시 분리해야 하는 게 옳은지 고민이 필요합니다. 우리의 경험 법칙에 따르면, 다수의 서비스가 서로 통신하게 만드는 요청 수와 이러한 서비스 간 통신을 필요로 하는 요청의 중요성을 고려하는 것이 최선입니다.
...
재사용은 가장 남용되는 추상화 중 하나입니다. 많은 회사에서 일반적으로 재사용을 적극 권장하고 있지만, 재사용에 수반된 트레이드오프를 정확히 분석해보지 않은 채로 무턱대고 재사용하면 심각한 아키텍처 문제가 일어날 수 있습니다.
...
분산 아키텍처에서는 네트워크 분할이 필수이므로 CAP 정리에 따라 둘(일관성, 가용성) 중 하나만 선택할 수 있습니다.
...
분산 아키텍처에서 ACID 트랜잭션은 각 서비스의 콘텍스트 내부에 존재할 수 있지만, 사용하는 데이터베이스가 ACID 속성을 지원하는 경우에만 가능한 얘기입니다. 각 서비스는 원자적 비즈니스 트랜잭션의 범위에서 자신이 소유한 테이블에 대해서는 커밋/롤백이 가능하지만, 여러 서비스에 걸쳐 비즈니스 요청을 처리하는 경우에는 비즈니스 요청 자신이 ACID 트랜잭션이 될 수는 없으므로 분산 트랜잭션이 됩니다.
...
오케스트레이션이 오케스트레이터가 중앙에서 조정을 해주는 통신 스타일이라면, 코레오그래피는 의도적으로 중앙 조정을 하지 않는 통신 스타일입니다. 각 서비스는 마치 같은 팀에서 춤추는 댄서들처럼 움직입니다. 그렇다고 아무렇게나 막 추는 댄스 공연은 아니고, 안무가(즉, 아키텍트)가 미리 안무를 짜되 중앙 조정자 없이 실행되는(춤추는) 것입니다.
...
이 책에 실린 트레이드오프 표들은 사실 그 어떤 것도 수치에 근거한 정량적 자료가 아니라 정성적 자료들입니다. 정량적 비교는 아키텍트마다 천차만별이므로 비교 자체가 어렵지만, 대량의 데이터에 통계적 분석 기법을 동원한다면 합리적인 정량적 분석도 가능할 것입니다.

-알라딘 eBook <소프트웨어 아키텍처 The Hard Parts> (닐 포드.마크 리처즈.세막 데그하니 지음, 이일웅 옮김) 중에서