오래된 SW 엔지니어의 평생 공부

애자일 소프트웨어 개발의 경우, 약점으로 알려져 있는 것이 개발하는 소프트웨어의 규모이다. 이러한 측면에서 다양한 접근 방법이 제시 되고 있다. 이 부분에 대해서 살펴 보자.

규모 확대 전략 (Scale up strategy)의 종류

애자일 소프트웨어 개발을 대규모로 확장하는 접근 방법으로 다음과 같은 것들이 알려져 있다.

1. Scaled Agile Framework(SAFe)[1]

2. Large Scale Scrum(LeSS)[2]

3. Disciplined Agile Delivery(DaD)[3]

4. Nexus framework[4]

5. Scrum@Scale[5](Scrum of Scrums[6], Spotify model[7])

이렇게 여러가지가 있지만, 소프트웨어 아키텍처에 관련해서 이야기 하는 것들은 1~3번이다.

4번과 5번은 Scrum이 반복을 기반으로 한 애자일 프로세스의 규모확장성(Scalability)에 대한 이야기로 볼 수 있다. 즉, 스크럼이 작은 팀(예를 들어 피자 두 판)만 가능하다고 하면 큰 규모의 소프트웨어 개발을 하는 조직을 어떻게 애자일하게 만들것이냐는 측면에 대한 접근인 것이다. 다른 접근 방법과 다르게 4번과 5번은 여전히 스크럼을 기반으로하고 있으므로 더 애자일한 측면이 있고, 다른 접근 방법들은 산출물이나 스크럼에서 이야기 하지 않는 다른 역할들을 정의하는 규율 기반(Disciplined approach)으로 애자일과는 다른 관점의 항목들이 추가된다고 이야기 할 수 있다.

4번 Nexus framework와 5번 Scrum@Scale의 차이점은 조직을 어떻게 구성하느냐 접근 방식이라고 볼 수 있다. Nexus는 정의부터 3개에서 9개의 스트럼팀을 코디네이트하는 것이라고 하고, Scrum@Scale은 조직 전체를 나누어 여러 스크럼의 스크럼을 단계적으로 만들어간다[8].

이후에는, 1~3번의 세가지 접근 방법에서 이야기 하는 소프트웨어 아키텍처에 대해서 살펴 보자. 대부분의 내용은 [9]에서 설명되어 있는 것들의 요약이다.

비슷한점

• 애자일 아키텍처의 중요성: SAFe, DaD, LeSS 모두 애자일 아키텍처를 중시하며, 시스템을 지속 가능하고 확장 가능하게 설계하는 데 중점을 둔다.
• 점진적 개발: 이들 프레임워크는 모두 변화를 수용하고 점진적으로 시스템을 개발하고자 하는 애자일의 원칙을 따른다.
• 분산된 의사결정: 의사결정의 분산을 통해 빠른 반응과 유연성을 높이는 것을 강조한다.

다른점

• 프레임워크의 구조: SAFe는 포트폴리오, 솔루션, 프로그램, 에센셜, 팀의 5단계 구조를 제공하는 반면, DaD는 시작, 구축, 전환의 3단계로 구성되어 있고, LeSS는 기본적인 스크럼 방식을 확장하여 사용한다.
• 철학 및 접근방식: SAFe는 구조적이고 포괄적인 접근을, DaD는 맞춤형 접근을, LeSS는 최소한의 프로세스를 중심으로 한 접근을 제공한다.
• 역할과 책임: LeSS는 다른 프레임워크에 비해 역할 수를 줄이는 방향을 강조하여 복잡성과 오버헤드를 감소시키고자 한다. 반면 SAFe와 DaD는 좀 더 많은 역할과 구조를 제안한다.

마무리하며...

애자일 개발방법의 규모 확장법이 이렇게 많다는 건 정답이 없다는 반증일 것이다. 특히, 아키텍처를 다루는 3가지 접근 법은 비교해보면 특징이 드러난다. SAFe는 관리적인 측면을 강조하고 있고, LeSS는 Scrum의 자연적인 확장을 기대며 팀에 기댄다. 서로 양극단이라고 한다면, DaD는 그 중간 즈음에 위치한다고 볼 수 있겠다.

참고 자료

[1] Scaled Agile Framework, https://www.scaledagileframework.com/

[2] Large Scale Scrum, https://less.works/

[3] Disciplined Agile Delivery, https://www.pmi.org/disciplined-agile/process/introduction-to-dad

[4] Scaling Scrum with Nexus, https://www.scrum.org/resources/scaling-scrum

[5] The Official Scrum@Scale Guilde, https://www.scrumatscale.com/scrum-at-scale-guide/

[6] Scrum of scrums, https://www.atlassian.com/agile/scrum/scrum-of-scrums

[7] Spotify and Scrum@Scale, https://www.scruminc.com/spotify-model-scrum-at-scale/

[8] Scrum@Scale An Introduction, https://medium.com/serious-scrum/scrum-scale-an-introduction-432bb0402488

[9] 라제시 RV 저자(글) · 김모세 번역, "애자일 소프트웨어 아키텍트의 길, 소프트웨어의 지속적인 설계를 통한 진화", 에이콘출판 · 2022년 10월 28일

다음 글[1]에 있는 내용을 요약한 것이다.

얼마나 아키텍처링을 해야 하는가?

여기서도 애자일에서도 [2]에서와 같이 소프트웨어 아키텍처가 필요하다고 이야기 하고 있다. 애자일 측면에서는 창발(emegence)한다고 이야기 하고, [2]에서는 진화적 설계라는 이름이로 이야기 하고 있다. 특히, 요사이는 DevOps등도 채용되고 있기 때문에 계획된 설계 보다는 진화적 설계가 더 널리 받아들여 지고 있다.

[1]에서 아키텍처링이 얼마나 진행되어야 하는가에 대해서는 [2]에서와 마찬가지로 "적정하게(Just Enough)"라고 이야기 한다. 기본적으로 구출할 프로젝트나 제품에 따라 다르다고 하는 부분은 일치한다. 또한, 어느 시점에 하느냐의 경우도, 스프린트 제로 혹은 일부 스프린트(이터레이션, 반복)에서 진행해야 하는 것도 필요하다고 이야기 한다. 하지만, 어떻게 하느냐의 부분은 달라진다.

진화적 설계의 입장에서 위에서 언급한 것 같이 여러 번의 스프린트에서 재설계(소위 리팩터링)으로 아키텍처가 확정된다면, 초기에 충분한 선행 설계(Upfront Design)가 있는 것이 나을 수도 있었다. 저자는 이러한 것 때문에 이런 결정이 섯부르게 처리한 것이고 지연과 막대한 기술 부채를 발생시킨다고 이야기 하고, 이것이 도리어 애자일 철학에 모순된다고 주장한다. 

큰 기업에서의 소프트웨어 아키텍처 및 애자일 접근법

이 세셕이 [1]의 가장 중요한 부분이라고 할 수 있다.

처음에는 작은 스타트업으로 시작했던 기업이 크게 성장하는 경우에도 여전히 애자일 개발 방법론이 적용된다. 이는 자기조직화(Self-organized)되어 있고 작은 팀들이 책임지고 있는 기능들은 애자일하게 개발이 된다. 예측하기 힘든 여러 상황에서 팀은 이를 해결하며 적응적으로 개발을 진행한다. 특히, 이 애자일리스트들은 이러한 과정 속에서 자신들의 소프트웨어 아키텍처가 창발(emgerge)한다고 믿는다.

그렇지만, 앞에서 이야기 한데로 이러한 여러 팀이 있는 경우라면 회사의 전체 시스템을 이해하기 어렵고 기업에 가지는 전체의 맥락을 이해하기 어려우며 팀이 여러 중복 솔루션이나 호환성을 떨어 뜨릴 수도 있다. 이를 위해서 이러한 문제를 다룰 수 있는 전담인력들이 필요할 수 있다. 즉, 애자일과는 반대 방향일 수 있으나 중앙 집중적인 방법으로 관리되어 참조 아키텍처(Reference Architecture)으로 관리되어야 한다.

두 가지 측면이 반대이고 호환되지 않는 것 처럼 보일 수 있다. 하지만, [1]에서는 SAFe의 Agile Architecture를 설명하면서 이 두가지가 호환되며 상호보완적이라고 주장한다. 기존과 가장 다른 점은 자기조직화팀의 새로운 디자인을 선행 디자인으로 만들어지는 전체 아키텍처에 통합하면서 진행하는 것이다. 저자는 이를 리트로-피딩(retro-feeding, retrospective, 회고)이라고 한다.

이러한 접근법에서 두 가지 장점을 강조한다.

1. 의도적 아키텍처를 각 팀이 참조하여 필요로 하는 솔루션을 구축할 수 있다.
2. 그러면서도, 팀이 어느 정도의 혁신할 수 있는 여력을 가지고, 이를 의도적 아키텍처에 포함하게 개선하고, 다른 팀이 이를 활용할 수 있게 한다.

이렇게 하기 위한 구조로는 Spotify의 챕터를 [1]에서는 이야기 하지만, 일반적으로 시스템 아키텍트와 어플리케이션 아키텍트 처럼 역할을 나누어 수행할 수도 있을 것으로 보인다.

참고 자료

[1] Miguel Arlandy, "Software Architecture and Agile. Are they both really compatible?" , Feb 19, 2019

https://medium.com/quick-code/software-architecture-and-agile-are-they-both-really-compatible-c1eef0afcbb1

[2] George Fairbanks, "Just Enough Software Architecture: A Risk-Driven Approach," 2010 https://technical-leader.tistory.com/89