소프트웨어 아키텍처란 무엇이고 소프트웨어 아키텍트의 역할과 역할을 수행하는 과정에 도움이 될 만한 내용들을 정리해본다. 본 내용은 도서 "개발자에서 아키텍트로(한빛미디어)" 내용에서 개인적으로 생각하는 주요 내용을 발췌해서 정리한 내용이다.
아키텍처 설계란?
- 문제를 해결하는 동시에 아직 발견하지 못한 문제를 찾아가는 과정
- 불확실함 속에서 의사결정을 내리는 일
- 의사결정 과정에서 절충과 타협이 있고, 좋은 것을 포기하는 대신 나쁜것을 피하거나, 나쁜 것을 받아들이면서 다른 것을 더 좋게하는 결정도 포함 됨
- 시스템 규모가 클 수록 초기 설계에 투자하는 데서 이득이 커짐(1KSLOC = 1000줄의 코드)
- 시스템 규모가 작으면 초기 설계 투자의 이득이 작을 수 있음
- 아키텍처 설계에 투자할 수록 재작업이 줄어듬
소프트웨어(SW) 아키텍트가 하는일
1. 엔지니어링 관점에서 문제 정의
- 기능 요구사항이 아닌 시스템의 품질 속성(비기능 요구사항, 가용성/확장성 등)을 정의 함
- 아키텍처가 정해진 방향으로만 갈 수 있도록 제약 사항을 정의
2. 시스템 분리 및 책임 위임
- 시스템을 여러 단위(모듈/컴포넌트 등)로 분리하고, 각 분리된 단위마다 품질 속성과 요구사항을 달성하도록 전략을 만듬
3. 큰 그림 그리기
- 넓은 의미의 시스템은 사람, 프로세스, 비즈니스 요구사항, 다양한 기술, 비기술적 의미가 뒤섞여 있음
- 아키텍트는 작은 설계 결정 사항이 가져올 미래도 예측하면서 이런 넓은 의미의 시스템 관점도 가져야 함
4. 품질 속성의 트레이드오프 고려하기
- 아키텍처는 하나를 포기하면 그 대신 하나를 얻는 상황이 자주 발생함
- 이런 다양한 트레이드오프를 파악해서 합리적인 결정을 내려야함
5. 기술 부채 관리
- 기술부채: 시스템의 현재 설계와 시스템이 지속적으로 가치를 창출하기 위해 가져야만 하는 바람직한 설계 사이의 간극
- 기술부채를 전략적으로 활용해 빠른 릴리즈를 달성하면서도 정기적으로 부채를 갚아 꾸준히 더 나은 가치를 만들 수 있음
- 아키텍트는 기술부채를 시각화 하고, 이해관계자들에게 이를 어떻게 관리해야 하는지 도와주는 역할을 함
6. 팀의 아키텍처 설계 역량 키우기
- 아키텍처가 아무리 좋아도 아무도 이해를 못한다면 쓸모가 없음
- 팀원들에게 많은 지식을 나눠주어 공유하고, 함께 설계하고, 문서를 만들고, 건설적인 비평을 나눠야 함
7. 이해관계자가 누구인지 알아내고 그들의 요구를 이해하기
- 이해관계자의 요구 및 기대치는 시스템 설계에 직간접적으로 영향을 줌
소프트웨어 아키텍트는 소프트웨어 설계에 대해 제 나름의 방식으로 생각하는 사람이 된다는 걸 의미 함.
자발적으로 설계에 대한 결정사항들을 정리하고, 아키텍처 설계에 대한 더 많은 책임을 맡는 리더 역할을 수행.
만족스러운 설계를 위한 방법
1. 실험으로 해결하기
- 생각해볼 수 있는 모든 해결책을 평가해야하는 실험이라고 생각
- 가설을 빠르고 저렴하게 평가할 수록 만족할만한 설계가 가능
2. 위험요소 줄이기
- 어떤 부분이 잘못되고 있는지 늘 주시하고, 각 상황에 맞는 시나리오를 고려해둬야 함.
- 위험을 잘 활용해서 다음 설계 방향을 결정
3. 문제 단순화하기
- 이해관계자 수 줄이기
- 제약을 추가 or 삭제 하기
- 반복되는 문제는 패턴 사례 or 경험을 기반으로 해결하기
4. 빠르게 반복하고 빠르게 배우기
- 빠른 실패 = 빠른 학습
- 짧고 촘촘한 일정으로 반복해서 경험하는 것이 모호한 목표만 바라보며 오랫동안 숙고하는 것보다 낫다
5. 문제와 해결책을 동시에 생각하기
- 문제를 잘 이해하면서도 동시에 해결책도 생각해야 함
- ex) 설계 초기부터 코딩을 하는 방법
이해관계자
- 누가 소프트웨어에 영향을 미치고 왜 우리가 그들을 중요하게 생각해야 하는지 파악 함
이해관계자 맵
- 시스템에 관여하거나 영향받는 모든 사람을 보여주는 네트워크 다이어그램
- 사람들 간의 관계 및 상호작용을 시각화
- 중요한 사항이 있을 때 누구와 대화를 나눠야 적합한지 판단 가능
이해관계자 별 비즈니스 목표 정의
- 상황 및 맥락 기반의 이해관계자 별 핵심 비즈니스 목표를 정의한다.
아키텍처 핵심 요구사항(ASR)
아키텍처 핵심 요구사항은 아키텍처를 선택하거나 구성할 때 큰 영향을 미치는 요구사항을 의미한다.
| 핵심 요구사항 항목 | 설명 |
| 제약 | - 바꿀 수 없는 설계상의 의사결정 - 아키텍트 스스로 만드는 제약도 있음 - 요구사항을 절대 만족 못시키는 지옥도 있으나, 잘 선택된 제약은 문제를 단순화 할 수 있음 - 비즈니스적 제약: 인력, 프로세스, 비용, 일정 등 - 기술적 제약: 사용 가능한 기술 결정 등 - 대체로 이미 결정된 사항을 받지만, 가끔 선택권은 있음 |
| 품질 속성 | - 시스템을 다른 시스템과 구분 짓는 겉으로 보이는 요소(비기능 요구사항) - 구체적인 상황에서 시스템이 어떤 작업을 수행해야 하는지 정의 - ex) 가용성, 성능, 확장성, 보안, 변경 가능성, 유지보수성, 재사용성, 관리용이성 등 - 제약과 달리 절충이나 맞교환이 가능함 |
| 영향력 있는 기능 요구사항 |
- 아키텍처에서 특별히 주목해야하는 기능적 요구사항 |
| 기타 | - 시간, 지식, 경험, 능력, 내부규정, 개인의 개성 등 설계에 미치는 영향 |
아키텍처에 영향을 주는 요인
아키텍처에 영향을 주는 요인으로는 아키텍트의 역량/기술/지식, 팀의 역량/기술/지식, 비즈니스 목표, 제약사항, 품질 속성, 영향을 미치는 기능 요구사항, 팀 구성, 최신 유행 기술 등이 있다.
아키텍처 선택
- 설계를 위한 탐색은 분기와 융합을 반복하는 과정
- 문제에 대한 여러가지 대안을 만들고, 대안들 중에서 문제와 가장 적합한 대안을 선택
아키텍트가 설계 시 파악해야 하는 것들
1. 아키텍처 구조를 어떻게 조합할지 결정하기 위한 각 구성요소와 그 역할 정의
2. 각 구성요소 간의 상호작용 방식을 위한 관계와 인터페이스
3. 아키텍처가 모델로 삼은 세상을 이해하기 위한 도메인
- 문제를 잘 이해해야 아키텍처 구성요소를 식별하고, 분할하고 요소간의 역할도 정의가 가능
4. 품질 속성을 끌어올리기 위한 기술
5. 릴리즈를 위한 배포 방법
6. 과거의 설계에서 얻은 관점과 의사결정 과정
- 코드, 문서, 개인적인 경험 등
의사결정 매트릭스
아키텍처 설계 시 여러 선택지의 절충안을 분석할 때 사용하는 도구
구성요소에 기능별 역할 할당
각 구성요소를 식별하고 관계를 나타내고, 각각의 역할을 정의
아키텍처 시각화
- 다이어그램 하나에 모든 것을 담는 것은 지양, 다양한 관점의 여러가지 다이어그램을 그리는 것이 좋음
- 모든 다이어그램에는 범례가 있어야 함
요소-역할 뷰
각 구성요소와 각 역할을 표현하는 뷰
구체화 뷰로 확대/축소
하나의 관점을 점점 상세하게 보이도록 구체화 뷰를 작성
품질 속성 뷰로 품질 속성 충족 여부 보여주기
아키텍처 문서화
| 문서화 방법 | 설명 |
| 원시 부족적 서술 방법 | - 진도가 빠른 초기에 아키텍처를 실계할 때 유용 - 쉽게 고칠수 있지만, 그만큼 공유하기에는 부족함 - 스토리텔링, 은유, 비공식적인 스케치 등 |
| 공동체적 서술방법 | - 개개인의 구전동화가 아니라 공동체 안에서 공유 가능한 방법 - 변경하기 쉽지만 공유하기 용이 - 코딩 스타일, 아키텍처 의사결정 기록(ADR) 등 |
| 형식적 서술방법 | - 더 높은 정확도, 정밀도가 요구 될 경우, 공식적인 문서 - 원시부족적 → 공동체적 → 형식적으로 발전하는 것이 좋음 - 전통적인 아키텍처 명세서 등 |
| 시간 소모적 서술방법 | - 하지 말자!! |
'개발 > 기타' 카테고리의 다른 글
| 기술 부채(Technical Debt)란? (0) | 2025.06.08 |
|---|---|
| MyBatis Invalid bound statement (not found) 오류 조치 (0) | 2024.10.18 |
| 브라우저에서 화면 css 스타일 전체 제거 (0) | 2024.09.07 |
| 드라이퍼스 모델 - 초보자에서 전문가에 이르는 여정 (0) | 2024.08.16 |
| 웹 프론트(화면) 성능 지표 알아보기 (0) | 2024.07.04 |
댓글