소프트웨어 아키텍트란?
소프트웨어 아키텍트는 프로그래밍 외에도 여러 책임을 집니다.
아키텍트는 엔지니어링 관점에서 문제를 정의합니다. 소프트웨어 시스템을 구현 가능한 작은 조각으로 나누는 동시에
전체 시스템이 일관성 있게 동작하도록 큰 그림을 그립니다.
아키텍트는 품질에 영향을 주는 다양한 품질 속성사이에서 균형을 잡아야 하며 어쩔 수 없이 늘어나는 기술 부채도 관리합니다.
무엇보다도 아키텍트는 팀원들의 설계 역량을 개발합니다.
소프트웨어 아키텍트가 하는 일
소프트웨어 아키텍트는 프로그램 매니저가 아닙니다.
아키텍트는 소프트웨어가 언제 어떻게 전달되는지 결정하는 사람입니다.
또한 소프트웨어가 비지니스 목표에 부합하도록 만드는 사람입니다.
코딩은 하지만 알고리즘이나 코드를 짜기보다는 더 크고 많은 것을 설계합니다.
소프트웨어 아키텍트는 여러 가지 역할에 대한 책임을 지면서, 동시에 모든 소프트웨어 개발 업무의 중심에 있는 것처럼 보이기도 합니다.
엔지니어링 관점에서 문제 정의하기
소프트웨어 아키텍처를 설계하는 일은 인간중심의 설계 철학과 맥을 같이합니다.
소프트웨어와 관련된 모든 사람이 자신이 소프트웨어를 어떻게 대하고 무엇을 기대하는지 당신에게 알려줄 수 있습니다.
소프트웨어 아키텍트는 프로덕트 매니저, 프로젝트 매니저, 그리고 모든 이해관계자와 협업하면서 비지니스 목표와 요구사항을 만들어갑니다.
통상적으로 프로덕트 매니저는 기능을 정의합니다.
소프트웨어 아키텍트는 이에 상응하는 품질 속성을 또 하나의 요구사항으로 만드는 일을 합니다.
아키텍트는 시스템의 품질 속성을 정의할 뿐만 아니라 소프트웨어 아키텍처가 정해진 방향으로만 갈 수 있도록 제약과 기능을 꾸준히 확인해야 합니다.
시스템은 분리하고 책임은 위임하기
소프트웨어 개발은 축구 경기와 비슷합니다.
릴리스 한 번 하면 거대한 소프트웨어가 덩어리로 굴러 나아갑니다.
소프트웨어를 분명한 책임을 가진 단위로 나누고 각각의 포지션을 지키면서 게임하면 운영이 더 순조로워집니다.
아키텍트는 소프트웨어 시스템을 여러 조각으로 나누고 조각마다 품질 속성과 요구사항을 달성하도록 전략을 만듭니다.
예를 들어, 기능 단위로 역할을 만들어, 사용자 등록 기능만 하는 컴포넌트와 고양이 그림을 식별하는 컴포넌트로 나눕니다.
여러 팀이 서로 다른 모듈을 개발하도록 할 수도 있습니다.
또 다른 방법으로, 데이터를 읽는 작업과 쓰는 작업을 분리해서 더 신뢰성 있고 가용성 높은 소프트웨어 시스템을 구축할 수도 있습니다.
큰 그림 그리기
소프트웨어 시스템은 소프트웨어 보다 더 큰 세상 안에서 살아갑니다.
그 세상에는 사용자, 개발팀, 하드웨어 등이 있고, 무엇보다도 그 소프트웨어를 개발해야 하는 목적도 있습니다.
이상적으로 아키텍처란 이 넓은 맥락 안에서 조화롭게 존재해야 합니다.
넓은 의미로 보면 시스템은 기술만 의미하지 않습니다.
사람, 프로세스, 비즈니스 요구사항, 그리고 다양한 기술, 비기술적인 의미가 소프트웨어 시스템에 뒤섞여 있습니다.
아주 간단한 설계라도 결과에 광범위한 영향을 줄 수 있습니다.
아키텍트는 작은 설계 결정사항이 가져올 미래도 예측하면서 넓은 의미의 시스템 관점도 가져야 합니다.
소프트웨어 설계는 이상과 현실 사이에 균형을 찾아가는 꾸준한 싸움입니다.
다시 말해, 트레이드오프를 생각해야만 합니다.
품질/속성의 트레이드오프를 고려하기
어떤 소프트웨어에서 고가용성이 중요한 품질 속성이라고 가정해봅시다.
이 소프트웨어는 요청에 대해 99.9% 응답을 해야 합니다.
가용성을 끌어올리는 방법 중 하나는 일부 요소를 중복 배치 하는 것입니다.
이 방법은 단순하지만 놓치기 쉬운 문제점이 있습니다. 하드웨어를 두 배로 구매해야하므로 비용이 두 배가 됩니다.
이떄는 비용과 고가용성 사이에 트레이드오프가 생긴다고 할 수 있습니다.
소프트웨어 개발에서는 이처럼 하나를 포기하면 그 대신 하나를 얻는 상황이 자주 발생합니다.
아키텍트는 다양한 트레이드오프를 파악해 어떤 결정이 더 합리적인지 결정할 수 있어야 합니다.
기술 부채 관리하기
소프트웨어 아키텍트는 시스템이 어떻게 나뉘어 있는지 자세하게 알고 있어야 합니다.
동시에 큰 그림을 보면서 모든 조각들이 함께 하나로 움직일 수 있는지도 알아야 합니다.
비즈니스 요구 사항과 기술 선택을 잇는 일도 합니다. 이 모든 지식을 아키텍처에 담으면서 기술 부채가 관리 가능한 수준으로 최적의 위치를 잡아가도록 해야 합니다.
기술 부채는 소프트웨어 시스템의 현재 설계와 소프트웨어가 지속적으로 가치를 창출하기 위해 가져야만 하는 바람직한 설계 사이의 간극입니다.
이 간극을 줄이는 데 얼마만큼의 노력이 필요할지 예측하는 것으로 기술 부채를 측정할 수 있습니다.
기술 부채란( Technical debt )?
기술적인 빚을 말한다.
기술적으로 해결되어야 할 문제들은 뒤로 미루고, 비지니스 문제를 해결하는 시점을 당기는 것이다.
- 이 코드의 시간 복잡도가 영 좋지 않지만 우선은 개발 일정이 빡쌔니 나중에 리팩터링 하자.
- 기능을 추가 했는데, 뭔가 전체적인 시스템 아키텍쳐와는 컨셉이 맞지 않는 것 같아. 근데 파악할 시간도 없고 아 몰랑. 나중에 보자
- 내가 뭔가를 짰는데, 급하게 짤게 또 있네.. 일단 급한 거부터 하고 나중에 문서화를 하자
- 거의 다 만들고 나니 코딩 컨벤션이 똥망이네. 에이 이번만 이렇게 하고 다음에 시간 날 때 컨벤션 맞춰야지.
- 아.. 거의 다 만들었는데 갑자기 기획이 바뀌다니. 일단 급한 데로 기능만 돌아가게 해두고 나중에 리팩터링 하자. 등등
놀랍게도 친숙한 상황들일 것이다. 생각해보면 저렇게 닥친 상황을 쳐낸 다음 수복한 일이 있던가?
유명한 법칙이 있다.
나중은 결코 오지 않는다 - 르블랑의 법칙
소프트웨어 아키텍처란?
한 소프트 웨어를 어떻게 구성해야 하는지 그리고 필요한 품질 속성을 어떻게 증진해야 하는지에 대한
중요한 결정들과 다른 소프트웨어와는 구별되는 특징들을 모아놓은 집합입니다.
중요한 결정으로 손꼽기 위해서는 몇 가지 이유가 필요합니다.
품질 속성, 일정, 비용에 영향을 주거나 한번 결정하고 나면 돌이킬 수 없는 어떤 사항일 수 있습니다.
여러 사람에게 영향을 줄 수 있고, 다른 소프트웨어를 바꾸도록 강요하곤 합니다.
때론 나중에 잘못되었음을 알고 바꾸고자 할 때 많은 비용이 필요한 경우가 중요한 결정에 포함되기도 합니다.
품질 속성을 증진한다는 것은 품질을 중요한 결정사항으로 만들어서 소프트웨어 시스템에 드러내는 일을 의미합니다.
잘 구성된 아키텍처일수록 이해관계자들이 원하는 품질 속성은 더 높이고 이해관계자들이 원하지 않는 품질 속성을 줄이거나
없애도록 만들어집니다.
필수 구조 정의하기
소프트웨어에는 구조가 있습니다.
구조는 소프트웨어가 정렬되어 있는 형태입니다.
구조를 만드는 일은 곧 요소들끼리 관계를 만드는 일입니다.
요소는 소프트웨어를 만드는 기본 조각입니다. 관계는 연관된 요소들이 함께 동작해서 특정 작업을 완수하는 단위입니다.
요소 | 관계 | |
모듈 | 클래스, 패키지, 레이어, 저장 프로시저, 모듈, 설정 파일, 데이터베이스 테이블 | 사용한다, 사용을 허락한다, 의존한다 |
컴포넌트와 커넥터 | 오브젝트, 커넥션, 스레드, 프로세스, 계층, 필터 | 호출한다, 구독한다, 연결한다, 송출한다, 응답한다 |
자원 할당 | 서버, 센서, 랩톱, 로드 밸런서, 팀, 사람, 도커 컨테이너 | 구동한다, 책임이 있다, 개발한다, 저장한다, 지불한다 |
모듈
설계할 때 만들기 시작해서 주로 코딩할 때 다루게 됩니다.
모듈은 파일 시스템 상의 어떤 형태로 표현할 수 있으며 소프트웨어가 동자갛지 않아도 상관없습니다.
컴포넌트와 커넥터(C&C)
소프트웨어가 실제 동작할 때부터 의미 있습니다.
소프트웨어가 실행하기 시작하면 컴포넌트 간에 커넥션을 만들고 프로세스를 생성하거나 오브젝트를 초기화합니다.
모듈 타입과 다른 점이라면, C&C는 시스템이 동작하지 않으면 사라진다는 점입니다.
자원 할당
모듈과 C&C가 서로 어떤 관계에 있는지 물리적인 요소로 보여주고자 할 때 만듭니다.
자원 할당 타입은 매핑 구조라고도 부르는데, 여러 요소가 서로 어떻게 매핑되는지 나타낼 수 있기 때문입니다.
모듈과 컴포넌트의 차이
소프트웨어 개발에서 모듈과 컴포넌트가 유사한 의미로 혼용되곤 합니다.
기술적으로 말하자면 모듈과 컴포넌트는 다릅니다.
모듈은 설계 시점에 의미있는 요소이며
컴포넌트는 런타임 시점에 의미 있는 요소입니다.
개발자에서 소프트웨어 아키텍처로
개발자에서 아키텍트로 성장하고 있는지 측정해보고 싶다면 프로젝트 포트폴리오를 만들어보세요
소프트웨어 시스템을 만들 때마다 어떤 역할을 했든지 간에, 참여했던 소프트웨어 시스템에 대해 간략히 정리하고
개발하면서 배운 점을 정리하세요.
프로젝트 포트폴리오를 정리할 때 의미 있는 질문은 아래와 같습니다.
- 이해관계자들은 누구였고 주요 비지니스 목표는 무엇이었는가?
- 최종적으로 어떤 결과가 나왔는가?
- 어떤 기술을 사용했는가?
- 가장 큰 리스크는 무엇이었고, 어떻게 극복했는가?
- 다시 시작할 수 있다면 어떤 점을 다르게 하겠는가?
'비전공의 CS 지식' 카테고리의 다른 글
모듈과 컴포넌트 (0) | 2021.11.15 |
---|---|
구글 검색 너란 녀석... (0) | 2021.09.22 |
CI/CD란? (2) | 2021.09.01 |
캐시가 뭐에요? 먹는건가요? (0) | 2021.08.29 |