다른 직업들에 비해 소프트웨어 아키텍트(software architect)는 분명한 커리어패스가 없다.

1. 직업 자체에 대한 명확한 정의가 없다.
   1. 정의 내리기 없다.
   2. "아키텍처는 중요한 것들에 관한 것이다. 그것이 무엇이든 말이다." - 랄프존슨(Ralph Johnson)
2. 역할이 방대한 분야를 포괄하며 범위도 계속 넓어지고 있다.
3. 소프트웨어 개발 생태계는 빠르게 발전하고 소프트웨어 아키텍처는 끊임없이 변한다.
   1. 소프트웨어 아키텍처는 그 정의를 포함한 본질 자체가 동적이다.
4. 소프트웨어 아키텍처에 관한 자료는 대부분 역사적인 연관성을 강조한다.
   1. 이것의 역사는 과거 아키텍트들이 시도했으나 해로운 부수 효과(side effect)만 식별하게 된 것들로 난잡하게 얽혀 있다.
   2. 아키텍처란 예술과 마찬가지로 콘텍스트(context)로서만 이해할 수 없다는 것이다.
      1. 아키텍처가 내린 결정은 대부분 그들이 그렇게 결정한 당시 환경에 기인한 것이다.

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

소프웨어 아키텍처를 바라보는 한가지 방법

• 시스템 구조(structure)
  • 시스템이 구현된 아키텍처 스타일(들)의 종류
    • 레이어드 아키텍처, 마이크로 서비스 아키텍처 등...
  • 구조만으로 아키텍처를 전체적으로 설명하는 것은 부족함
    • NOTE: 보통 구조만으로 아키텍처를 설명하며, 전부가 아님
• 아키텍처 특성(architecture charateristic)
  • 시스템의 기능과 직교하는(orthogonal) 시스템의 성공 기준(success criteria)을 결정함
  • 가용성, 신뢰성, 시험성, 확장성, 보안, 민첩성, 내고장성, 탄력성, 복구성, 성능, 배포성, 학습성
• 아키텍처 결정(architecture decision)
  • 시스템 구축에 필요한 규칙들을 정한 것
  • 시스템의 제약조건(constraint)을 형성하고 개발자가 해도 되는 것과 하지말아야 할 것을 알려줌
• 설계 원칙(design principle)
  • 가이드라인(guideline)과 비슷함

1.2 아키텍트에 대한 기대치

소프트웨어 아키텍트에게 바라는 핵심적인 요구사항

• 아키텍처 결정을 내린다.
  • 가이드한다.
    • 기술 선택을 가이드하는 사람이지, 정해주는(specify) 사람이 아님
    • 아키텍트는 확장성, 성능, 가용성 등의 아키텍처 특성을 수호하기 위해 특정한 기술을 결정해야 할 때도 있는데, 이런 경우에는 그 기술을 지정한 행위 자체를 아키텍처 결정이라고 할 수 있다.
• 아키텍처를 지속적으로 분석한다.
  • 끊임없이 아키텍처와 현재 기술 환경을 분석하고 이를 개선하기 위해 해결 방안을 제시함
  • 지난 아키텍처가 현실성에 대한 평가를 하는 것이 아키텍처 역동성(vitality)에 관한 요구사항이다.
  • 아키텍트는 기술 변화와 문제 영역을 종합적으로 분석하여 아키텍처의 건전성을 추구해야 한다.
  • 아키텍트라면 애플리케이션을 계속 적절하게 유지할 수 있는 능력을 가지고 있어야 한다.
• 최신 트렌드를 계속 유지한다.
  • 핵심 트렌드를 이해하고 계속 좇아갈 수 있어야 미래를 대비하고 올바른 결정을 내릴 수 있다.
• 아키텍처 결정과 설계 원칙의 컴플라이언스(comliance)를 보장한다.
  • 컴플라이언스 보장: 아키텍트가 정의하고 문서화하여 전달한 아키텍처 결정과 설계 원칙들을 개발팀이 제대로 준수하고 있는지 지속적으로 확인한다는 뜻
• 다양한 기술과 경험에 노출되어야 한다.
  • 기술 폭을 넓혀야 한다.
    • 기술 결정에 도움이 될 수 있도록
• 비즈니스 도메인 지식을 보유한다.
  • 폭넓은 실무(hands-on) 기술 지식과 더불어 특정 도메인에 깊이 있는 지식을 보유해야 한다.
• 대인 관계 기술이 뛰어나다.
  • 팀워크, 조정(facilitation), 리더십을 포함한 대인 관계 기술이 뛰어나야 한다.
  • 개발팀을 리드해서 아키텍처를 구현하는 사람이므로 아키텍트라는 직책 또는 역할과 상관없이, 리더십 스킬은 소프트웨어 아키텍트로서 성공하기 위해 필수 요구사항의 최소한 절반 이상을 차지
• 정치를 이해하고 처세를 잘한다.
  • 기업 내부의 정치적 분위기를 이해하고 적절하게 잘 처신할 줄 알아야 한다.
  • 최종적으로 폭넓고 중요한 결정을 내리는 아키텍트 수준에 이르면 거의 모든 결정을 정당화하고 반대 세력에 맞서 싸울 준비를 갖추어야 한다.

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

• 엔지니어링 프랙티스(engineer practice)
  • 프로세스와 무관하게 가시적
  • 반복가능한 혜택을 주는 실천론
  • 예를 들어 지속적 통합(continuous integration)은 특정 프로세스에 의존하지 않는 검증된 엔지니어링 프랙티스
• 소프트웨어 개발 프로세스
  • 사람을 조직하고 상호작용하는 총체적인 기법
    • 팀을 어떻게 구성, 관리할지
    • 회의는 어떻게
    • 워크플로 조직은 어떻게 운영할지
    • 등...

엔지니어링 프랙티스에 집중하는 것은 중요하다.

1. 소프트웨어 개발 분야는 보다 성숙한 다른 엔지니어링 체계에 있는 많은 특성들이 빠져 있다.
2. 소프트웨어 개발의 아킬레스 건 중 하나는 추정(estimation)이다.
   1. 알려지지 않은 미지의 것들(unknown unknowns) 때문에 더 어렵다.

알려지지 않은 미지의 것들은 소프트웨어 시스템에서 필연적이다. 아키텍트는 알려지지 않은 미지의 것들을 설계할 수 없기 때문에 빅 디자인 업 프런트(Big Design Up Front; 일단 설계부터 확실하게!)방식으로 진행하기 어렵다.

"모든 아키텍처는 알려지지 않은 미지의 것들 때문에 자꾸 되풀이되는데, 애자일은 단지 이것을 인지해서 더 빨리 수행하는 것이다."

반복적인 프로세스를 통해 이를 해결해야 한다. 아키텍트는 아키텍처 스타일과 엔지니어링 프랙티스가 공생 관계망(symbiotic mesh)을 형성하도록 해야 한다. 소프트웨어 개발은 동적이며 아키텍트는 어떤 기준에 맞게 시스템을 설계할 수 있지만, 그 설계는 구현과 소프트웨어 개발 생태계의 어쩔 수 없는 변화를 모두 거치면서 살아남아야 한다. 그래서 우리가 필요한 것은 진화하는 아키텍처(evolutionary architecture)이다.

• 피트니스 함수(fitness function)

  • 알고리즘을 특정한 용도로 설계할 때 개발자는 반드시 결과를 측정하여 최적해(optimal solution)에 가까워졌는지, 멀어졌는지 확인해야 한다.
  • 어떤 아키텍처 특성의 객관적인 완전성을 평가하는 수단

• 프로세스

  • 소프트웨어를 개발하는 개발팀의 프로세스는 소프트웨어 아키텍처 여러 파트에 영향을 미친다
  • 모든 아키텍처는 단지 시간 문제일 뿐 반복적이다.
  • 재구성(restructuring)은 애자일 방법론의 진면목을 볼 수 있는 중요한 아키텍처 분야 중 하나다.

• 데이터

  • 코드와 데이터는 공생 관계여서 상대방이 없으면 무용지물이다.

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

소프트웨어 아키텍처 제1법칙 "소프트웨어 아키텍처의 모든 것은 다 트레이드오프다. 아키텍트가 트레이드오프가 아닌 뭔가를 발견했다고 생각했다면 그것은 그가 아직 트레이드오프를 발견하지 못했다는 증거일 가능성이 높다."

소프트웨어 아키텍처 제2법칙 "'어떻게'보다 '왜'가 더 중요하다."

시스템을 들여다보면 아키텍처의 구조적인 작동원리는 알아낼 수 있지만, 왜 다른 것 대신 그런 선택을 하게 됐는지 설명하기는 어렵다.

이 책에서는 아키텍트가 트레이드오프를 감안하여 왜 그런 결정을 하는지, 그리고 중요한 결정을 포착하는 멋진 기법을 중점적으로 살펴본다.