다음 글[1]에 있는 내용을 요약한 것이다.
얼마나 아키텍처링을 해야 하는가?
여기서도 애자일에서도 [2]에서와 같이 소프트웨어 아키텍처가 필요하다고 이야기 하고 있다. 애자일 측면에서는 창발(emegence)한다고 이야기 하고, [2]에서는 진화적 설계라는 이름이로 이야기 하고 있다. 특히, 요사이는 DevOps등도 채용되고 있기 때문에 계획된 설계 보다는 진화적 설계가 더 널리 받아들여 지고 있다.
[1]에서 아키텍처링이 얼마나 진행되어야 하는가에 대해서는 [2]에서와 마찬가지로 "적정하게(Just Enough)"라고 이야기 한다. 기본적으로 구출할 프로젝트나 제품에 따라 다르다고 하는 부분은 일치한다. 또한, 어느 시점에 하느냐의 경우도, 스프린트 제로 혹은 일부 스프린트(이터레이션, 반복)에서 진행해야 하는 것도 필요하다고 이야기 한다. 하지만, 어떻게 하느냐의 부분은 달라진다.
진화적 설계의 입장에서 위에서 언급한 것 같이 여러 번의 스프린트에서 재설계(소위 리팩터링)으로 아키텍처가 확정된다면, 초기에 충분한 선행 설계(Upfront Design)가 있는 것이 나을 수도 있었다. 저자는 이러한 것 때문에 이런 결정이 섯부르게 처리한 것이고 지연과 막대한 기술 부채를 발생시킨다고 이야기 하고, 이것이 도리어 애자일 철학에 모순된다고 주장한다.
큰 기업에서의 소프트웨어 아키텍처 및 애자일 접근법
이 세셕이 [1]의 가장 중요한 부분이라고 할 수 있다.
처음에는 작은 스타트업으로 시작했던 기업이 크게 성장하는 경우에도 여전히 애자일 개발 방법론이 적용된다. 이는 자기조직화(Self-organized)되어 있고 작은 팀들이 책임지고 있는 기능들은 애자일하게 개발이 된다. 예측하기 힘든 여러 상황에서 팀은 이를 해결하며 적응적으로 개발을 진행한다. 특히, 이 애자일리스트들은 이러한 과정 속에서 자신들의 소프트웨어 아키텍처가 창발(emgerge)한다고 믿는다.
그렇지만, 앞에서 이야기 한데로 이러한 여러 팀이 있는 경우라면 회사의 전체 시스템을 이해하기 어렵고 기업에 가지는 전체의 맥락을 이해하기 어려우며 팀이 여러 중복 솔루션이나 호환성을 떨어 뜨릴 수도 있다. 이를 위해서 이러한 문제를 다룰 수 있는 전담인력들이 필요할 수 있다. 즉, 애자일과는 반대 방향일 수 있으나 중앙 집중적인 방법으로 관리되어 참조 아키텍처(Reference Architecture)으로 관리되어야 한다.
두 가지 측면이 반대이고 호환되지 않는 것 처럼 보일 수 있다. 하지만, [1]에서는 SAFe의 Agile Architecture를 설명하면서 이 두가지가 호환되며 상호보완적이라고 주장한다. 기존과 가장 다른 점은 자기조직화팀의 새로운 디자인을 선행 디자인으로 만들어지는 전체 아키텍처에 통합하면서 진행하는 것이다. 저자는 이를 리트로-피딩(retro-feeding, retrospective, 회고)이라고 한다.
이러한 접근법에서 두 가지 장점을 강조한다.
- 의도적 아키텍처를 각 팀이 참조하여 필요로 하는 솔루션을 구축할 수 있다.
- 그러면서도, 팀이 어느 정도의 혁신할 수 있는 여력을 가지고, 이를 의도적 아키텍처에 포함하게 개선하고, 다른 팀이 이를 활용할 수 있게 한다.
이렇게 하기 위한 구조로는 Spotify의 챕터를 [1]에서는 이야기 하지만, 일반적으로 시스템 아키텍트와 어플리케이션 아키텍트 처럼 역할을 나누어 수행할 수도 있을 것으로 보인다.
참고 자료
[1] Miguel Arlandy, "Software Architecture and Agile. Are they both really compatible?" , Feb 19, 2019
[2] George Fairbanks, "Just Enough Software Architecture: A Risk-Driven Approach," 2010 https://technical-leader.tistory.com/89
'Software Architecture' 카테고리의 다른 글
| 반 버논 시리즈, "Patterns of API Design (API 디자인 패턴)" 번역을 마무리 하며... (5) | 2024.03.17 |
|---|---|
| 소프트웨어의 설계는 더 이상 필요 없다? (Is Design Dead?) (0) | 2022.03.01 |
| 소프트웨어 아키텍처 101: 2장 아키텍처 사고 (0) | 2022.03.01 |
| 적정 소프트웨어 아키텍처: 리스크 주도 소프트웨어 아키텍처 설계(Risk-driven SW Architecture Design) (0) | 2021.09.21 |
| Clean Architecture: 클린 아키텍처 주요 개념 (4) | 2020.10.25 |