개발자에서 아키텍트로

→

1장. 소프트웨어 아키텍트가 되다.

• SW 아키텍트가 하는 일
  • SW가 언제 어떻게 전달되는지 결정하는 사람
  • 비즈니스 목표에 부합하도록 만드는 사함
  • 코딩을 하지만 알고리즘이나 코드를 짜기보다는 더 크고 많은 것을 설계함
  • 엔지니어링 관점에서 문제 정의하기
    • Product Manager: 기능(feature)를 정의함
    • SW 아키텍트:
      • Product Manager, Project Manager, 모든 stackholder와 협업하면서 비즈니스 목표와 요구사항을 만듬
      • 품질 속성을 또 하나의 요구사항으로 만듬
      • SW 아키텍처가 정해진 방향으로 갈 수 있도록 제약과 기능을 꾸준히 확인해야 함
      • SW 시스템을 여러 조각으로 나누고 조각마다 품질 속성과 요구사항을 달성하도록 전략을 만듬
  • 큰 그림 그리기 & Trade-off
    • 아키텍트는 작은 설계 결정 사항이 가져올 미래도 예측하면서 넓은 의미의 시스템 관점도 가져야 함
    • 소프트웨어 설계는 이상과 현실 사이에 규현을 찾아가는 꾸준한 싸움임 → trade-off를 생각해야 함
      • e.g.비용과 고가용성 사이에 trade-off
    • trade-off에 따라 타협해야 하기도 하고 기술 부채가 쌓이기도 함
  • 기술 부채
    • SW 아키텍트는 비즈니스 요구사항과 기술 선택을 잇는 일임
    • 기술 부채(technical debt)란 SW 시스템의 현재 설계와 SW가 지속적으로 가치를 창출하기 위해 가져야만 하는 바람직한 설계 사이의 간극
    • 노련한 팀은 기술 부채를 전략적으로 활용해 빠른 릴리스를 달성하면서도 정기적으로 부채를 갚아서 꾸준히 더 나은 가치를 만들어감
    • 아키텍트는 기술 부채를 시각화 하고 이해관계자 모두에게 이를 어떻게 관리해야 하는지 도와주는 일을 함
  • 팀의 아키텍처 설계 역량 키우기
    • 아키텍트는 설계 기술과 구조에 대한 개념을 적시에 가르칠 수 있어야 함
    • 팀원들과 함계 설계하고, 이를 가르치기 위한 문서를 만들고, 건설적인 비평을 나눠야 함
    • 팀원들의 설계 역량을 끌어올리는 일이 아키텍트로서 할 수 있는 가장 중요한 활동임
• SW 아키텍처란 무엇인가?
  • 한 SW를 어떻게 구성해야 하는지 그리고 필요한 품질 속성을 어떻게 증진해야 하는지에 대한 중요한 결정들과 다른 SW와는 구별되는 특징을 모아놓은 집합임
  • 잘 구성된 아키텍처일수록 이해관계자들이 원하는 품질 속성은 더 높이고 이해관계자들이 원하지 않은 품질 속성은 줄이거나 없애도록 만들어짐
  • 필수 구조 정의하기
    • SW에는 구조가 있음. 구조는 우리 시스템의 전체적인 모양을 결정함
      • 어떤 품질 속성이 필요한지 결정할 수 있음
      • 사용자가 경험할 여러가지 속성을 파악할 수 있음
    • 구조를 만드는 일은 요소들끼리 관계를 만드는 일임
    • 종이와 펜으로만 구조를 설계하면 현실을 반영하지 못할 가능성이 높음
    • 이를 피하기 위해 요소와 관계를 3가지 타입의 구조 중 선택해 설계할 수 있음
      • 모듈: 설계할 때 만들기 시작해서 주로 코딩할 때 다루게 됨
        • 설계시점에 의미 있는 요소
        • 클래스, 패키지, 레이어, 저장 프로시저, 모듈, 설정 파일, DB 테이블
      • 컴포넌트와 커넥터(C&C): SW가 실행하기 시작하면 컴포트 간에 커넥션을 만들고 프로세스를 생성하거나 오브젝트를 초기화함. 모듈과 다른 점은 시스템이 동작하지 않으면 사라진다는 점임 
        • 런타임 시점에 의미 있는 요소임
        • 오브젝트, 커넥션, 스레드, 프로세스, 계층, 필터
      • 자원할당: 모듈과 C&C가 서로 어떤 관계에 있는지 물리적인 요소로 보여주고자 할 때 만듬. 자원할당 타입을 매핑구조라고도 부르는데 여러 요소가 서로 어떻게 매핑되는지 나타낼 수 있음
        • 서버, 센서, 랩톱, 로드 밸런서, 팀, 사람, 도커 컨테이너
    • 품질 속성
      • SW를 평가하는데 도드라지는 특성: 확장성, 가용성, 유지 모수성, 테스트 가능성
      • SW 구조를 만들 때 시스템에서 어떤 것을 품질 속성으로 설정해서 가치를 높여나가야 할지 정해야 함
      • 품질 속성은 SW를 독창적으로 만들어 줌
  • 팀에서 아키텍트가 되려면
    • 개발자에서 SW 아키텍트로
      • 아키텍트로서의 책임감이 커질수록 프로그래밍할 시간이 줄어듬 → 코딩을 떼면 안되지만 한편 자연스러운 현상임
      • 개발자에서 아키텍트로 성장하고자 한다면 프로젝트 포트폴리오를 만들어보자
        • 이해 관계자들은 누구였고 주요 비즈니스 목표는 무엇이었는가?
        • 최종적으로 어떤 결과가 나왔는가?
        • 어떤 기술을 사용했는가?
        • 가장 큰 리스크는 무엇이었고, 어떻게 극복하였는가?
        • 다시 시작할 수 있다면 어떤 점을 다르게 하겠는가?
      • SW 아키텍처를 만들 기회가 올 때 즉시 잡을 수 있도록 준비하라.
      • SW 아키텍처에 영향을 미치는 어떤 의사결정을 한다면 누구든지 임시 아키텍트가 될 수 있음
• 훌륭한 SW 만들기
  • SW를 옳은 방향으로 만들기 위한 여러가지 요소가 있음
    • SW 아키텍처는 큰 문제를 작게 나누고 관리하기 쉽게 만듬
    • SW 아키텍처는 사람들이 협업하는 방법을 보여줌
    • SW 아키텍처는 복잡한 아이디어를 설명할 때 사용하는 사전임
    • SW 아키텍처는 기능과 스펙 너머로 시야를 넓혀줌
    • SW 아키텍처는 값비싼 실수를 줄여줌
    • SW 아키텍처는 애자일을 가능하게 함