진화적 아키텍처

감사하게도 한빛미디어 출판사에서 도서 리뷰 요청을 해주셨다. 책도 보내주셨지만, 이제 종이책은 보기 힘들어서 알라딘 이북으로 직접 구매해서 봤다. 그러므로, 이 글은 직접 구매한 도서를 읽고 간단히 정리하는 것으로 그동안의 도서 후기와 다르지 않다.

 

얼마 전에 봤던 '소프트웨어 아키텍처 The Hard Parts’ 저자의 신간이다. 책의 표지에는 '개정판'이라는 언급이 없는데, 이 책은 2017년에 출간된 'Building Evolutionary Architectures: SUPPORT CONSTANT CHANGE'의 개정판이다.

진화적 소프트웨어 아키텍처는 여러 차원에 걸쳐 유도된 변화와 점진적 변화를 지원한다.

이 책은 위와 같은 정의를 어떻게 실현할 수 있는지에 대한 세부적인 사항을 설명한다. 그중에서 큰 비중을 차지하고 있는 방법론으로 저자가 '소프트웨어 아키텍처' 시리즈에서 강조하는 피트니스 함수가 있고, 그것에 대한 내용을 이 책에서는 더 자세히 다루고 있다. 읽다 보면 조금 과하다는 느낌이 들 때도 있지만, 저자가 항상 강조하듯이 모든 것은 트레이드 오프이므로 잘 검토해서 적용하면 좋을 것 같다. 그리고, 점진적 빌드와 배포 파이프라인에 대한 내용과 저자가 피트니스 함수와 더불어서 강조했던 '아키텍처 퀀텀’에 대한 내용이 함께 큰 비중을 차지하고 있다.

 

마이크로 서비스를 구성하기 위한 다양한 주제를 설명하지만, 모든 것은 아래의 목표를 이루기 위한 것으로 생각한다.

마이크로서비스의 목표는 단순히 작은 서비스를 만드는 것이 아니라 쓸모 있는 경계 콘텍스트를 만드는 것이다.

소프트웨어 생태계가 변하면서 아키텍처도 그것에 맞게 변화해야 하는 것에 대한 설명도 자주 등장한다.

타임머신을 타고 2000년으로 거슬러 올라가보자. 여기 새로운 아이디어를 들고 운영 책임자를 찾아온 한 아키텍트가 있다.
아키텍트: 각각의 기능을 환상적인 수준으로 격리하는 새로운 아키텍처가 있어요. 마이크로서비스라 부르는 개념입니다. 이 원리에 맞게 비즈니스 기능을 중심으로 각 서비스를 설계하고 고도로 분리된 상태를 유지하려고 하는데요.
운영 책임자: 훌륭하군요. 어떻게 도와드리면 될까요?
아키텍트: 글쎄요, 컴퓨터 50대 정도, 거기에 들어갈 운영체제 라이선스 50개, 격리된 데이터베이스를 담당할 컴퓨터 20대, 그리고 그만큼의 라이선스가 필요합니다. 언제쯤 준비가 될까요?
운영 책임자: 됐습니다. 그만 나가 보세요.
마이크로서비스는 당시에도 좋은 아이디어였을지 모르지만 이를 뒷받침할 만한 생태계는 존재하지 않았다.

위험은 반드시 평가해야 하지만 현실적이어야 한다. 실제하는 기술적 위험과 인지된 기술적 위험의 차이를 이해하는 것은 아키텍트가 지속적으로 배워야 할 과정의 일부다. 아키텍트다운 사고란, ‘얼어붙은 원시인’의 사고와 경험을 극복하고, 다양한 솔루션을 접하고, 맥락에 충실한 질문을 던져야만 갖출 수 있다.

위와 같이 기술적인 내용만이 아닌, 중간중간 등장하는 사람에 대한 이야기도 재밌다.

 

그리고, 아래의 내용을 보면서 언젠가, '왜 사내에서 외부 메이븐 리포지토리 직접 접근을 막는가?'라는 질문을 본 기억이 떠올랐었다.

개발자는 불확실성이라는 토대 위에 반복적인 엔지니어링 관행을 수립해서는 안 된다. 서드파티가 핵심 의존성을 변경하도록 허용하는 것은 이러한 원칙에 위배된다.
...
외부 컴포넌트가 업데이트되면 배포 파이프라인은 변경 사항을 통합하고, 관련 애플리케이션을 빌드한다. 빌드 결과는 스모크 테스트로 검증하고 테스트가 성공하면 해당 업데이트를 생태계에 적용한다.

 

개인적으로 이 책을 저자의 '소프트웨어 아키텍처' 시리즈보다 먼저 보는 것을 추천한다. 분량도 가장 적고, 설계에 대한 이야기만이 아니라, 구현과 실무에서 자주 접하는 거버넌스에 대한 설명도 있기에 개발자가 보기에 조금 더 이해가 쉽다고 생각한다.

 

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

[전자책] 진화적 아키텍처

아키텍처 피트니스 함수를 통해 조직의 요구와 비즈니스 기능의 맥락을 함께 고려해 의사 결정을 내릴 수 있으며, 결정의 근거를 명시적이고 테스트 가능한 방식으로 마련할 수 있다.
...
애자일 아키텍처의 목표는 아키텍처의 부재 자체가 아니라 소프트웨어 개발 과정에 존재하는 무가치한 관료적 행태를 배제하는 것이다.
...
단위 테스트와 마찬가지로 피트니스 함수는 팀 코드베이스의 일부가 된다. 따라서 아키텍처 요구 사항이 변경되고 발전함에 따라 피트니스 함수도 적절히 변경되어야 한다.
...
아키텍처 위반 사항을 자동으로 검사하면 개발자는 구조적인 문제보다 도메인의 문제에 더 집중할 수 있다. 더 나아가 아키텍트는 자신이 수립한 규칙을 실행 가능한 아티팩트로 통합할 수 있다.
...
카오스 엔지니어링의 기본 원칙은 많은 이의 공감을 얻는다. 시스템은 반드시 장애를 일으킨다. 문제는 그것이 언제인가다. 예측할 수 있는 최종 상황을 설계하고 관리함으로써 아키텍트와 운영자는 한층 견고한 시스템을 발판 삼아 협업할 수 있다.
...
실행되지 않는 원칙은 일정의 압박과 여러 제약 조건 속에서 유명무실해진다. 아키텍처 설계 원칙과 거버넌스 규칙을 피트니스 함수로 변환하면 설령 외부의 힘이 작용한다 해도 생략되거나 건너뛰지 않도록 절차를 보장할 수 있다.
...
테스트는 좋은 문서와 같다. 문서를 읽는 독자는 자신의 정직함을 의심할 필요가 없다. 그들은 항상 테스트를 실행하고 결과를 확인할 수 있다. 신뢰하되 검증하라!
...
진화적 아키텍처는 커플링의 적정 수준에 주목한다. 커플링을 맺을 아키텍처를 식별하고 최소한의 오버헤드와 비용을 들여 최대한의 이득을 볼 수 있어야 한다.
...
아키텍처 퀀텀이란 높은 기능 응집도를 갖추었으며 독립적으로 배포 가능한 컴포넌트를 가리킨다. 시스템이 제대로 작동하기 위해 필요한 모든 구조적 요소가 아키텍처 퀀텀에 속한다. 
...
‘알아야 할 것’만 아는 수준으로 계약을 유지한다면 의미론적 커플링과 필수 정보 사이에서 균형을 유지할 수 있을 뿐만 아니라 통합 아키텍처 취약점을 노출할 위험까지 방지할 수 있다.
...
모니터링과 로깅은 아키텍처의 최우선 관심사가 되어야 한다. 운영팀이 모니터링하지 못하는 서비스가 있다면 그 서비스는 사실상 존재하지 않는 것이나 마찬가지다. 
...
데이터베이스 트랜잭션은 강한 핵력처럼 아키텍처 퀀텀을 묶는다.
...
계약에 포함된 정보가 많을수록 계약은 불필요하게 강화 된다. 
...
테스트하기 용이한 아키텍처의 대표적인 특성은 단일 책임 원칙 준수다. 우수한 시스템은 각 부분이 저마다 하나의 책임을 진다.
...
열악한 설계는 걸핏하면 병적인 커플링을 생산하며 각종 안티패턴과 결합해 코드 재구축을 방해한다. 개발자가 아키텍처를 재구축하는 첫 단계는 기술 부채로 굳어진 과거의 설계 타협점을 제거하는 것이어야 한다.

-알라딘 eBook <진화적 아키텍처> (닐 포드 외 지음, 정병열 옮김) 중에서