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

소프트웨어 아키텍트의 커리어패스는 분명하지 않다. WHY?

• 소프트웨어 아키텍트라는 직업 자체에 대한 명확한 정의가 아직 없다.
• 소프트웨어 아키텍트의 역할은 실로 방대한 분야를 포괄하여 업무 범위도 계속 넓어지고 있다.
• 소프트웨어 개발 생태계는 워낙 빠르게 발전하는 분야이고 소프트웨어 아키텍처는 끊임없이 변한다.
• 소프트웨어 아키텍처에 관한 자료는 대부분 역사적인 연관성을 강조한다.

 

p. 27
소프트웨어 아키텍트는 이렇게 끊임없이 변하는 생태계 안에서 뭔가 결정을 내리는 사람들입니다.
......
즉, 아키텍트가 내린 결정은 대부분 그들이 그렇게 결정한 당시 환경에 기인한 것입니다.

 

p. 28
모든 아키텍처는 그 콘텍스트의 결과물이라는 사실을 기억하세요.

 

 

소프트웨어 아키텍처의 구성

1. 아키텍처 특성 : 시스템의 기능과 직교하는 시스템의 성공 기준을 결정
2. 아키텍처 결정 : 시스템의 제약조건 형성 (반드시 지켜야 할 규칙)
3. 설계 원칙 : 가이드라인 (우선 권장)
4. 구조 : 시스템이 구현된 아키텍처 스타일(들)의 종류

 

아키텍트에 대한 기대치

• 아키텍처 결정을 내린다.
  • keyword : 가이드
  • 아키텍트는 기술 선택을 가이드하는 사람이지, 정해주는 사람이 아니다.
• 아키텍처를 지속적으로 분석한다.
  • 아키텍처 역동성에 관한 요구사항
  • 아키텍트는 테스팅과 릴리스 환경을 망각하기 쉽다.
• 최신 트렌드를 계속 유지한다.
• 아키텍처 결정의 컴플라이언스를 보장한다.
  • 컴플라이언스 보장 : 아키텍트가 정의하고 문서화하여 전달한 아키텍처 결정과 설계원칙들을 개발팀이 제대로 준수하고 있는지 지속적으로 확인하는 것
• 다양한 기술과 경험에 노출된다.
  • 기술폭 : 아주 자세히는 몰라도 본인이 잘 알고 있는 것과 연관지어 알고 있는 것들
  • 아키텍트는 한 가지 캐시 제품에 정통한 전문가가 되려고 하기보다는 10가지 캐시 제품을 어느 정도 다룰 줄 알고 각각의 장단점을 아는 게 더 중요하다.
• 비즈니스 도메인 지식을 보유한다.
• 대인 관계 기술이 뛰어나다.
• 정치를 이해하고 처세를 잘한다.
  • 아키텍트가 내린 거의 모든 결정은 사람들의 반발에 부딪히기 마련이다.

 

p. 40 
이 회사에 절실히 필요했던 건 탄력적 확장이었습니다. 리소스 인스턴스를 필요한 만큼 더 많이 가동시키는 능력 말입니다.

 

 

프로세스 vs 엔지니어링 프랙티스

프로세스

• 팀을 어떻게 구성하고 관리할지, 회의는 어떻게 하고 워크플로 조직은 어떻게 운영할지 등
• 사람을 조직하고 상호작용하는 총체적인 기법

엔지니어링 프랙티스

• 프로세스와 무관하게 가시적이고 반복 가능한 혜택을 주는 실천론
• ex) 지속적 통합

 

엔지니어링 프랙티스의 중요성

• 소프트웨어 개발 분야는 보다 성숙한 다른 엔지니어링 체계에 있는 많은 특성들이 빠져있다.
• 소프트웨어 개발의 아킬레스건 중 하나는 추정이다.

 

p. 42
알려지지 않은 미지의 것들은 소프트웨어 시스템에서 필연입니다.
......
모든 아키텍처는 알려지지 않은 미지의 것들 때문에 자꾸 되풀이되는데, 애자일은 단지 이것을 인지해서 더 빨리 수행하는 것이다.

 

p. 46
소프트웨어를 구축하는 방법(프로세스)은 사실 소프트웨어 아키텍처(구조)에 별다른 영향을 끼치지 않습니다.

 

p. 47
소프트웨어 아키텍처의 모든 것은 다 트레이드오프다.
- 소프트웨어 아키텍처 제 1법칙

 

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