[소프트웨어 아키텍처 101] 1. 서론

서문

이 책은 지난 10년 동안 일어난 모든 혁신과 더불어 오늘날의 새로운 구조와 관점에 부합하는 새로운 지표를 바탕으로 소프트웨어 아키텍처를 현대적인 관점에서 살펴본다.
이 책의 부제는 '엔지니어링 접근 방식'이다.
기존 소프트웨어 아키텍처에서 당연시됐던 많은 공리들을 최근 생태계와 설계 아키텍처의 관점에서, 그리고 요즘 전반적인 추세와 비교하여 다시 한번 돌아보겠다.

---

인상깊은 부분

아키텍처를 공부하기 어려웠던 이유

아래와 같은 이유로 아키텍처에 대한 공부를 하기 어려웠군.

1. 소프트웨어 아키텍처의 역사는 과거 아키텍트들의 시도가 난잡하게 얽혀있음
   • 소프트웨어 아키텍처에 관한 자료는 대부분 역사적인 연관성을 강조함
   • 위키피디아 페이지를 읽다보면 종잡을 수 없는 약어들로 광활한 지식의 세계로 상호 참조하는 링크들을 어렵잖게 발견할 수 있음
   • 이런 약어들은 대부분 진부하거나 이미 실패한 시도들임
2. 문맥, 문락(context)으로서만 이해할 수 있음
   • 아키텍트가 내린 결정은 대부분 그들이 그렇게 결정한 당시 환경에 기인함
   • 예를 들어, 20세기 아키텍처의 주요 목표 중 하나는 최대한 효율적으로 리소스를 공유하여 사용하는 것이었는데, 그 시절에는 모든 인프라가 가격이 비쌌기 때문임

아키텍트에 대한 기대치

1.2 아키텍트에 대한 기대치를, 상위 기술 리더십에게 바라는 기대치로 받아들여도 좋겠다.
내가 원하는 모습이 되려면 이런 기대치 달성을 목표로 삼아야할 것 같다.

아키텍처 결정을 내린다
아키텍처를 지속적으로 분석한다
최신 트렌드를 계속 유지한다
아키텍처 결정의 컴플라이언스(compliance)를 보장한다
다양한 기술과 경험에 노출된다
비즈니스 도메인 지식을 보유한다
대인 관계 기술이 뛰어나다
정치를 이해하고 처세를 잘한다

기술 폭

내가 만나본 멋있는 기술 리더십을 가진 사람들은 깊이도 있고 폭도 넓어서 어느 시점부터 폭을 파야하는지 모르겠다.

한 가지 캐시 제품에 정통한 전문가가 되려고 하기 보다는 10가지 캐시 제품을 어느 정도 다룰 줄 알고 각각의 장단점을 아는 게 더 중요

피트니스 함수

목표 기준에 도달하기 위해 측정을 자동화하는 방법을 고려해야할 필요가 있겠다.

개발자는 반드시 결과를 측정하여 최적해에 가까워졌는지, 멀어졌는지 확인해야 합니다. 그 측정 수단이 바로 피트니스 함수입니다.
...
피트니스 함수의 실행 빈도와 피트니스 함수가 제공하는 피드백 사이의 관계를 눈 여겨 보세요.

---

요약

1.1 소프트웨어 아키텍처란?

• 시스템의 구조
  • 시스템에 적용한 아키텍처 스타일의 종류 (ex: 마이크로서비스, 레이어드, 마이크로커널 등)
• 아키텍처 특성
  • 소프트웨어 아키텍처를 다른 관점에서 바라본 것으로, 일반적으로 시스템의 기능과 직교하는 시스템의 성공 기준을 결정함
  • 시스템이 지원해야 하는 '~성' (ex: 가용성, 확장성, 내고장성, 성능, 신뢰성, 보안, 탄력성, 배포성, 시험성, 민첩성, 복구성, 학습성)
• 아키텍처 결정
  • 시스템 구축에 필요한 규칙들을 정한 것 (시스템을 구축하는 규칙)
  • 시스템의 제약조건(constraint)을 형성하며, 개발자가 해도 되는 것과 하지 말아야 할 것을 알려줌
  • 반드시 지켜야할 규칙
• 설계 원칙
  • 시스템 구축에 필요한 가이드라인

1.2 아키텍트에 대한 기대치

• 아키텍처 결정을 내린다
  • 아키텍처와 설계 원칙을 결정하고 팀, 부서뿐만 아니라 회사 전체의 기술 결정을 가이드
  • 기술 선택을 가이드, 정해주는 것은 X
  • 아키텍처 결정과 설계 원칙을 통해 기술 선택을 가이드
  • 개발팀 스스로 옳은 기술 결정을 하도록 가이드하는 데에 도움이 되는 지, 개발팀을 위해 기술을 대신 선택해주는 게 더 나을지 자문한 뒤 아키텍처 결정
• 아키텍처를 지속적으로 분석한다
  • 끊임없이 아키텍처와 현재 기술 환경을 분석하고 이를 개선하기 위한 해결 방안을 제시
• 최신 트렌드를 계속 유지한다
  • 항상 최신 기술과 업계 트렌드를 따라가야함
  • 아키텍트가 결정한 것들은 대개 오래 지속되고 바꾸기 어려움
  • 핵심 트렌드를 이해하고 계속 좇아갈 수 있어야 미래를 대비하고 올바른 결정을 내릴 수 있음
• 아키텍처 결정의 컴플라이언스(compliance)를 보장한다
  • 아키텍처 결정과 설계 원칙의 컴플라이언스를 보장해야함
  • 컴플라이언스 보장이란, 아키텍트가 정의하고 문서화하여 전달한 아키텍처 결정과 설계 원칙들을 개발팀이 제대로 준수하고 있는지 지속적으로 확인한다는 뜻
• 다양한 기술과 경험에 노출된다
  • 다양한 기술, 프레임워크, 플랫폼, 환경에 노출되어야함
  • 가장 익숙한 영역(comfort zone)을 점점 넓혀가는 것이 가장 좋음
  • 한가지 기술이나 플랫폼에만 올인하는 것은 안일한 태도
  • 여러가지 언어, 플랫폼, 기술을 경험할 기회를 적극적으로 모색
  • 기술의 깊이 보다는 '폭'에 초점. 기술 폭이란, 아주 자세히는 몰라도 본인이 잘 알고 있는 것과 연관 지어 알고 있는 것들을 말함. 예를 들어, 한 가지 캐시 제품에 정통한 전문가가 되려고 하기 보다는 10가지 캐시 제품을 어느 정도 다룰 줄 알고 각각의 장단점을 아는 게 더 중요
• 비즈니스 도메인 지식을 보유한다
  • 어느 수준 이상의 비즈니스 도메인 전문가여야 함
  • 비즈니스 도메인 지식이 없으면 비즈니스 문제점, 목표, 요구사항을 이해하기 어렵고, 따라서 비즈니스 요구사항을 수용할 만한 효율적인 아키텍처를 설계하기도 어려움
  • 성공한 아키텍트는 폭넓은 실무(hands-on) 기술 지식과 더불어 특정 도메인에 깊이 있는 지식을 보유한 사람들이었음. 그들은 C-level 과 업무 담당자 등의 이해관계자들이 이해하는 도메인 지식과 언어를 사용해 효과적으로 소통할 수 있음 (강한 신뢰감)
• 대인 관계 기술이 뛰어나다
  • 팀워크, 조정(facilitation), 리더십을 포함한 대인 관계 기술이 뛰어나야함
  • 제럴드 와인버그 "그들이 당신에게 뭐라고 말하든 항상 사람이 문제입니다."
  • 리더십 스킬은 소프트웨어 아키텍트로서 성공하기 위해 필수 요구사항의 최소한 절반 이상은 차지함
• 정치를 이해하고 처세를 잘한다
  • 기업 내부의 정치적 분위기를 이해하고 적절하게 잘 처신할 줄 알아야함
  • 아키텍트가 내린 거의 모든 결정은 사람들의 반ㄴ발에 부딪히게 마련임. 아키텍처 결정을 실천하려면 시간과 비용이 들게 되므로 제품 오너, 프로젝트 관리자, 비즈니스 이해 담당자들의 뭇매를 맞게 됨
  • 아키텍트는 회사에서 정치를 잘하면서 대부분의 결정을 사람들이 수용하도록 기본적인 협상 기술을 발휘해야 함 (협상 기술을 리더십만큼이나 중요하고 필요함)

1.3 아키텍처의 교차점 그리고...

• 엔지니어링 프랙티스
  • 프로세스와 무관하게 가시적이고 반복 가능한 혜택을 주는 실천론
  • 예를 들어, 지속적 통합(continuous integration)은 특정한 프로세스에 의존하지 않는 검증된 엔지니어링 프랙티스임
    • 켄트 벡과 여러 소프트웨어 개발자들은 과거 성공적인 프로젝트를 분석한 결과, 테스트를 더 많이 하는 것과 소프트웨어 품질이 상호 연관 관계가 있음을 밝힘
  • 불확실성과 추정
    • 프로젝트는 알려지지 않은 미지의 것들, 즉 아무도 몰랐던 것들이 갑자기 불쑥 튀어나와 미궁에 빠지기 쉬움
    • 모든 아키텍처는 알려지지 않은 미지의 것들 때문에 자꾸 되풀이되는데, 애자일은 단지 이것을 인지해서 더 빨리 수행하는 것
    • 프로세스와 아키텍처는 거의 분리되어 있지만, 소프트웨어 아키텍처의 속성상(추정, 불확실성을 의미) 반복적인 프로세스(ex: 애자일)이 잘 맞음. 폭포수 모델처럼 낡은 프로세스를 이용하여 마이크로서비스 시스템을 구축하려는 팀은, 소프트웨어가 서로 맞물려 돌아가는 현실을 무시한 구식 프로세스 때문에 사사건건 마찰을 빚게 될 것임
  • 아키텍처 스타일과 엔지니어링 프랙티스
    • 아키텍트는 아키텍처 스타일과 엔지니어링 프랙티스가 공생 관계망을 형성하도록 해야함
    • 마이크로서비스 아키텍처 스타일은 머신 프로비저닝과 자동화 테스팅/배포 등 많은 것들을 전제로 함
    • 문제 영역마다 적합한 아키텍처 스타일이 있듰이 엔지니어링 프랙티스도 동일한 종류의 공생 관계를 맺음
  • 피트니스 함수
    • 결과를 측정하여 최적해에 가까워졌는지, 멀어졌는지 확인하는 수단
    • 아키텍처 피트니스 함수 : 어떤 아키텍처 특성의 객관적인 완전성을 평가하는 수단. 매트릭(지표), 단위 테스트, 모니터, 카오스 엔지니어링 등 다양한 메커니즘이 이 평가에 포함됨
    • 예를 들어, 아키텍트는 페이지 로드 시간을 중요한 아키텍처 특성으로 꼽을 수 있는데, 성능 저하 없이 시스템을 변경하려면 각 페이지마다 로드 시간을 측정하는 테스트로 피트니스 함수를 구축한 다음, 프로젝트를 위한 지속적 통합의 일환으로 이 테스트를 실행함
• 운영/데브옵스
  • 공간 기반 아키텍처
    • 과거 많은 기업들이 개발과 운영은 별개로 생각하여 비용 절감 차원에서 외주를 맡기는 경우가 많았음
    • 1990년, 2000년대에 설계된 아키텍처는 대부분 아키텍트가 운영을 마음대로 할 수 없다는 전제하에 그러한 제약 위주로, 방어적으로 구축되었음 (15장, 공간 기반 아키텍처가 좋은 예임)
    • 운영을 외주화하여 비용을 줄이는 과정에서 비롯된 제약 때문에 방어적인 설계를 하게 되고, 확장, 성능, 탄력성, 그 밖의 여러 가지 기능을 내부적으로 처리할 수 있는 아키텍처를 구축함. 그 대가로 아키텍처가 매우 복잡해지는 부작용이 생김
  • 마이크로서비스 아키텍처
    • 운영 관심사는 운영으로 처리해야 더 매끄럽다는 것을 깨닫고, 아키텍처와 운영 간에 연결고리를 맺어 설계를 단순화하고 운영자가 가장 잘 처리할 수 있는 부분은 운영에 맡기게 됨
    • 그 과정에서 아키텍트와 운영자는 리소스를 남용하면 뜻밖의 난관에 빠지게 된다는 사실을 깨닫고 마이크로서비스를 만들었음 (17장에서 자세히 다룸)
• 소프트웨어 개발 프로세스
  • 팀을 어떻게 구성하고 관리할지, 회의는 어떻게 하고 워크플로 조직은 어떻게 운영할지 등 사람을 조직하고 상호작용하는 총체적인 기법
  • 소프트웨어를 개발하는 개발팀의 프로세스는 소프트웨어 아키텍처 여러 파트에 영향을 미침

1.4 소프트웨어 아키텍처 법칙

• 두 가지 법칙
  • 소프트웨어 아키텍처의 모든 것은 다 트레이드오프다.
  • '어떻게'보다 '왜'가 더 중요하다.
• 제1 정리
  • 아키텍트가 트레이드오프가 아닌 뭔가를 발견했다고 생각한다면 그것은 그가 아직 트레이드오프를 발견하지 못했다는 증거일 가능성이 높다
• 이 책에서 아키텍트가 트레이드오프를 감안하여 왜 그런 결정을 하는지, 그리고 중요한 결정을 포착하는 멋진 기법을 중점적으로 살펴볼 것임 (19.3절)