1. Software 아키텍처 - 소프트웨어 아키텍트가 되다.

소프트웨어 아키텍트가 하는 일

소프트웨어 아키텍트는 팀에서 독특한 위치에 있다. 소프트웨어 아키텟트는 프로그램 매니저가 아니다 . 아키텍트는 소프웨어가 어떻게 전달되는지를 결정하는 사람이다. 또한 소프트웨어가 비즈니스 목표에 부합하도록 만드는 사람이다. 코딩은 하지만 알고리즘이나 코드를 짜기보다는 크고 많은것을 설계 하는 사람이다. 소프트 웨어 아키텍스는 여러가지 역할에 대한 책임을 지며 모든 소프트웨어 개발 업무의 중심에 있는 것처럼 보이기도 한다.

1. 엔지니어링 관점에서 문제 정의

소프트웨어 아키텍처는 프로덕트 매니저, 프로젝트 매니저, 그리고 모든 이해 관계자와 협업하면서 비지니스 목표와 요구사항을 만들어 갑니다.

2. 시스템은 분리하고 책임은 위임하기

아키텍트는 소프트웨어 시스템을 여러 조각으로 나누고 조각마다 품질 속성과 요구사항을 달성하도록 전략을 만듭니다. 예를 들어 기능단위 역할을 만들어 사용자 등록 기능만 하는 컴포넌트와 고양이 그림을 식별하는 컴포넌트를 나눕니다. 

3. 큰 그림 그리기

시스템은 기술만 의미하지 않습니다. 사람, 프로세스, 비즈니스 요구사항 그리고 다양한 기술 비기술적인 의미가 소프트웨서 시스템에 뒤섞여 있습니다. 아주 간단한 설계라도 결과에 따라 광범위한 영향을 줄 수 있습니다. 아키텍트는 작은 설계 결정 사항이 가져올 미래도 예측하면서 넓은 의미의 시스템 관점도 가져야 합니다. 소프트웨어 설계는 이상과 현실 사이의 균형을 찾아가는 싸움 입니다. 트레이드 오프를 생각해야 합니다.

4.품질/속성의 트레이드 오프 고려하기 

어떤 소프트웨어 에서 고각용성이 중요한 품질 속성이라고 가정하면 해당 소프트웨어는 99.9% 응답을 해야 합니다. 가용성을 끌어올리는 방법 중 하나는 일부 요소를 중복배치 하는 것 입니다. 이 방법은 단순하지만 놓치기 쉬운 문제가 있습니다. 하드웨어를 2배로 구매해야 하므로 비용이 두배가 됩니다. 이때는 비용과 고가용성 사이에 트레이드 오프가 발생한다고 볼 수 있습니다. 소프트웨어 시스템은 결과 완벽하게 나누어 떨어지지 않습니다. 타협해야만 합니다. 이 과정에서 실수도 있을수 있습니다. 시스템을 만들도 보면 아케텍쳐 곳곳에 기술 부채도 쌓이기 시작 합니다.

5. 기술 부채 관리하기

소프트웨어 아키텍트를 시스템이 어떻게 나누어 있느지 자세하게 알고 있어야 합니다. 동시에 큰 그림을 보면 모든 조각들이 함꼐 하나로 움직일 수 있는지도 알아야 합니다. 비즈니스 요구사항과 기술 선택을 잇는 일도 합니다. 모든 지식을 아키텍처에 담으면서 기술 부채가 관리 가능한 수준으로 잡아 가도록 해야 합니다.

 

기술 부채는 소프트웨어 시스템의 현재 설계와 소프트웨어가 지속적으로 가치를 창출하기 위해 가져야만 하는 설계 사이의 간극 입니다. 이 간극을 줄이는 데 얼마만큼의 노력이 필요할지 예측하는 것으로 기술 부채를 측정할 수 있습니다.  노련한 소프트웨어 개발팀은 기 술 부채를 전략적으로 활용해서 빠른 릴리즈를 당성하면서도 정기적으로 부채를 갚아서 꾸준히 나은 가치를 만들어 냅니다. 

 

아키텍트는 기술 부채를 시각화하고 이해관계자 모두에게 이를 어떻게 관리해야 하는지 도와주는 일을 합니다.  

6. 팀의 아키텍처 설계 역량 키우기

아키텍트는 설계 기술과 구조에 대한 개념을 적시에 가르칠 수 있어야 합니다. 지식을 전달할때 팀원과 함께 설계하고, 이를 가르치기 위한 문서를 만들고, 건설적인 비평을 나눠야 합니다. 팀원들을 설계 과정에 참여시켜서 팀의 설계 역량을 끌어올리는 일이 아키텍트로서 할 수 있는 가장 중요한 활동이라고 볼 수 있습니다.