[Chapter 1] 서론

소프트웨어 아키텍처란?

• 소프트웨어 아키텍처는 아래의 4가지가 결합된 구조이다.
  1. 시스템의 구조 Structrue
  2. 아키텍처 특성 Architecture characteristic
  3. 아키텍처 결정 Architecture decision
  4. 설계 원칙 Design Principle

 

시스템 구조 Structrue

• 시스템에 어떤 종류의 아키텍처 스타일을 적용했는지를 나타낸다
• e.g) 마이크로서비스, 레이어드, 마이크로커널 등

 

아키텍처 특성 Architecture characteristic

• 시스템이 지원해야 하는 `~성`들이다.
• 시스템의 성공 기준을 결정한다.
• e.g) 가용성, 신뢰성, 시험성, 확장성, 보안, 민첩성, 내고장성, 탄력성, 복구성, 성능, 배포성, 학습성

 

아키텍처 결정 Architecture decision

• 시스템 구축에 필요한 규칙을 정한것이다.
• 시스템의 제약조건을 형성하며 개발자가 해도 되는 것과 하지 말아야 할 것을 알려준다.
• e.g) `프레젠테이션 레이어가 데이터베이스를 직접 호출하지 못하게 비즈니스와 서비스 레이어에서믄 데이터베이스에 액세스 할 수 있다`는 결정 그 자체
• 어떤 상황이나 제약 조건 탓에 시스템의 어느 한 부분에서 아키텍처 결정을 따를 구현할 수 없다면 그 결정은 변형이라는 것을 통해 깨드릴 수 있다.

 

설계 원칙 Design Principle

• 시스템 구축에 필요한 가이드라인이다.
• e.g) 마이크로서비스 아키텍처의 성능 향상을 위해 서비스 간 통신은 비동기 메시징을 활용해야 한다고 서술하는 것

 

아키텍트에 대한 기대치

• 소프트웨어 아키텍트에게 바라는 핵심 요구사항 8가지
  1. 아키텍처 결정을 내린다
  2. 아키텍처를 지속적으로 분석한다
  3. 최신 트렌드를 계속 유지한다
  4. 아키텍처 결정의 컴플라이언스compliance를 보장한다
  5. 다양한 기술과 경험에 노출된다
  6. 비즈니스 도메인 지식을 보유한다
  7. 대인 관계 기술이 뛰어나다
  8. 정치를 이해하고 처세를 잘한다

 

아키텍처 결정을 내린다

• 아키텍트는 기술 선택을 가이드 하는 사람이지 정해주는 사람이 아니다.
• 하지만 확장성, 성능, 가용성 등의 아키텍처 특성을 수호하기 위해 특정한 기술을 결정해야 할 때도 있다.

 

아키텍처를 지속적으로 분석한다.

• 아키텍트는 끊임없이 아키텍처와 현재 기술 환경을 분석하고 이를 개선하기 위한 해결 방안을 제시한다.

 

최신 트렌드를 계속 따라간다.

• 아키텍트는 최신 기술과 업계 트렌드를 따라 가야 한다.
• 핵심 트렌드를 이해하고 계속 좇아갈 수 있어야 미래를 대비할하고 올바른 결정을 내릴 수 있다.

 

아키텍처 결정의 컴플라이언스를 보장한다.

• 아키텍트는 아키텍처 결정과 설계 원칙의 컴플라이언스를 보장해야 한다.
• 컴플라이언스 보장이란 아키텍트가 정의하고 문서화하여 전달한 아키텍처 결정과 설계 원칙을 개발팀이 제대로 준수하고 있는지 지속적으로 확인한다는 것이다.

 

다양한 기술과 경험에 노출된다

• 아키텍트는 다양한 기술, 프레임워크, 플랫폼, 환경에 노출되어야 한다.

 

비즈니스 도메인 지식을 보유한다.

• 아키텍트는 어느 수준 이상의 비즈니스 도메인 전문가여야 한다.
• 비즈니스 도메인 지식이 없으면 비즈니스의 문제점, 목표, 요구사항을 이해하기도 어렵고, 따라서 비즈니스 요구사항을 수용할 만한 효율적인 아키텍처를 설계하기도 어렵다.

 

대인 관계 기술이 뛰어난다.

• 아키텍트는 개발팀을 기술적으로 이끌기만 하는 사람이 아니라, 개발팀을 리드해서 아키텍처를 구현하는 사람이므로 아키텍트라는 직책 또는 역할과 상관 없이, 리더십 스킬은 소프트웨어 아키텍트로서 성공하기위한 필수 조건이다.

 

정치를 이해하고 처세를 잘한다.

• 아키텍트는 기업 내부의 정치적 분위기를 이해하고 적절하게 잘 처신할 줄 알아야 한다.
• 회사에서 정치를 잘 하면서 대부분의 결정을 사람읃ㄹ이 수용하도록 기본적인 협상 기술을 발휘해야 한다.

 

엔지니어링 프랙티스

• 소프트웨어 개발 프로세스란 팀을 어떻게 구성하고 관리할지, 회의는 어떻게 하고 워크플로 조직은 어떻게 운영할지 등 사람을 조직하고 상호작용하는 총체적인 기법이다.
• 소프트웨어 엔지니어링 프랙티스는 프로세스와 무관하게 가시적이고 반복 가능한 혜택을 주는 실천론이다. e.g) 지속적 통합
• 아키텍처 스타일과 엔지니어링  프랙티스는 공생 관계망을 형성하도록 해야한다.
• 피트니스 함수는 어떤 알고리즘을 특정한 용도로 설계할 때 결과를 측정하여 최적해에서 어느정도 거리에 있는지를 측정할 수 있는 수단이다. e.g) 외판원 문제를 해결하기 위한 유전 알고리즘을 설계할 때 피트니스 함수는 경로 거리를 구하는 함수
• 아키텍처 피트니스 함수는 어떤 아키텍처 특성의 객관적인 완전성을 평가하는 수단이며, 메트릭, 단위 테스트, 모니터, 카오스 엔지니어링 등 다양한 메커니즘이 이 평가에 포함된다.

 

프로세스

• 소프트웨어 개발 프로세스는 소프트웨어 아키텍처에 별다른 영향을 미치지 않지만, 피드백 루프가 빠른 애자일 방법론 등의 프로세스를 선택한다면 아키텍처의 변경을 더 잘 지원한다.

 

소프트웨어 아키텍처 법칙

1. 소프트웨어 아키텍처의 모든 것은 트레이드 오프다.
2. `어떻게` 보다 `왜`가 중요하다.