*잠깐, 위시켓은 2022년 시밀러웹 방문자 수 기준, 국내 1위 IT아웃소싱 플랫폼입니다. 현재 10만 이상의 개발업체, 개발 프리랜서들이 활동 중이며 무료로 프로젝트 등록이 가능합니다. 프로젝트 등록 한 번으로 여러 개발업체의 견적, 예상기간, 포트폴리오 등을 한 번에 비교해 보세요📝
어떤 문제를 겪고 있는 한 팀이 있습니다. 이 팀은 프로젝트 초기에 프로덕트적인 목표를 달성하기 위해 복합 기능적으로(cross-functional) 구성되었습니다. 또, 효과적으로 제품의 성능을 향상하기 위해 애자일 하게 움직였죠. 그런데 제품에 대한 사용자의 수요가 증가함에 따라 개발 요건이 증가하게 되고, 백로그도 많아지게 됩니다. 이제 제품의 관계자들은 팀의 규모를 확장(scale) 할 필요가 있다고 판단하게 됩니다. 혹시 여러분의 팀도 비슷한 상황을 겪고 있나요?
만약 팀이 적절한 시간 내에 처리할 수 있는 것보다 더 많은 양의 업무를 해야 한다면 스케일링을 고려해야 합니다. 올바른 확장형 프레임워크를 적용하면 여러 팀이 ‘애자일’한 상태를 유지하며 협업할 수 있습니다. 그러나 잘못된 프레임워크를 적용하면 생산성 저하와 함께 상당한 재정적 손실을 초래할 수 있기 때문에 신중해야 합니다.
팀에 가장 적합한 ‘애자일 프레임워크’는 사용 가능한 자금의 규모, 조직의 상황과 제품의 복잡성과 같은 여러 요소에 따라 달라집니다.
애자일 프레임워크 확장은 이럴 때 해야 합니다.
확장을 고려하기에 앞서서 충족해야 할 몇 가지 기준이 있습니다.
1. 개발을 한 팀 만으로 관리할 수 있나요?
확장형 애자일 프레임워크(Scaled Agile frameworks, SAFe)를 적용하는 것은 복잡하고 상당한 시간이 걸릴 수 있기 때문에 팀 워크로드가 과부하 되어 반드시 확장해야 하는 상황이 아니라면 하지 않는 것이 좋습니다.
2. 팀이 애자일 한가요?
팀의 애자일 방법론 숙련도는 가장 중요한 기준입니다. 여러분의 팀이 충분히 애자일 경험을 쌓지 못한 채로 확장하게 되면 더 많은 문제가 발생하게 됩니다.
3. 팀의 개발 관행을 개선해야 하나요?
팀의 엔지니어링 관행(practices)이 효율적이지 않다면 목표한 스케일링 효과를 얻지 못할 수 있습니다. DevOps1나 CI/CD2 파이프라인 같은 관행은 팀 간의 일관성을 유지하기 위해 반드시 필요합니다. 또한, QA가 표준화되어 있지 않다면 새로운 기능을 테스트하기 어려울 수 있습니다.
4. 팀이 통합 증분3을 산출하고 있나요?
스케일링에는 여러 팀이 동일한 제품을 위해 협업해서 기능을 개발하는 통합 작업이 수반됩니다. 아래 표에는 네 가지 가능한 팀과 제품 구성의 시나리오가 자세히 나와 있습니다. 이 중 맨 아래 시나리오에서만 확장하면 됩니다.
| 팀 수 | 제품 수 | 시나리오 |
|---|---|---|
| 1팀 | 1개 | 한 팀이 한 개 제품의 개발을 관리합니다. 스케일링은 필요치 않습니다. |
| 1팀 | 2개 이상 | 한 팀이 여러 제품을 개발합니다. 프로젝트 매니저는 제품들의 개발 순서를 정해서 하나씩 개발하거나 여러 팀이 개별 제품을 병렬적으로 개발하도록 관리할 수 있습니다. 스케일링은 필요치 않습니다. |
| 2개 이상 | 2개 이상 | 제품 수와 팀의 수가 같습니다. 스케일링은 필요치 않습니다. |
| 2개 이상 | 1개 | 여러 팀이 협력해서 한 개의 대규모 제품 솔루션을 관리합니다. 이 경우에는 프로젝트 매니저가 확장형 스케일 프레임워크를 적용해야 합니다. |
스케일링 프레임워크 정하기
많은 애자일 스케일링 프레임워크가 있지만 가장 널리 사용되는 솔루션인 SAFe(Scaled Agile Framework), Nexus, LeSS(Large-Scale Scrum), Scrum@Scale, Disciplined Agile(DA) 총 5가지를 소개하겠습니다. 저는 이 솔루션들이 가장 효과적이면서 다양한 시나리오와 조직에 적용될 수 있다고 생각합니다. 그럼 바로 이어서 여러분의 상황에 딱 맞는 ‘애자일 프레임워크’를 선택하는데 필요한 정보를 소개하겠습니다.
1. 확장형 애자일 프레임워크 Scaled Agile Framework(SAFe)
SAFe는 가이드와 절차가 잘 정리되었고, 가치 흐름(value stream)4에 초점을 갖춘 여러 구성을 갖추고 있어서 가장 일반적으로 사용되는 프레임워크입니다. 2021년에 실시한 설문조사에 따르면 조사에 참여한 애자일 실무자 중 37%가 SAFe를 사용하는 것으로 나타났습니다.
SAFe는 50명 이상 규모의 대형 조직이 솔루션을 개발할 때 사용되기 때문에 애자일 릴리스 트레인(Agile Release Trains(ARTs)) 단위로 팀을 편성합니다. ART에서 팀을 동기화하기 위해서 스크럼 스프린트와 유사한 증분 이터레이션 프로그램을 적용합니다. 각 이터레이션은 보통 8주에서 12주간 진행됩니다. 이 방식을 통해 프로덕트 매니저들은 과도한 변경 없이 전체 팀의 목표에 집중하고, 복잡한 제품 로드맵을 효율적으로 관리할 수 있습니다.
SAFe는 스크럼 프레임워크를 기반으로 하지만 몇 가지 중요한 차이점이 있습니다. SAFe는 팀 레벨이 아닌 엔터프라이즈 레벨에서 적용됩니다. 또, 스크럼에서는 프로덕트 오너(PO)가 우선순위 조정에 대한 전권을 가지지만 SAFe는 보다 민주적인 접근 방식을 권장합니다.
SAFe에는 4개의 레벨이 있습니다.
- Essential SAFe
Essential SAFe는 SAFe의 기초이기 때문에 이후 소개될 레벨로 넘어가기 전에 반드시 마스터해야 합니다. Essential SAFe에서 스크럼 마스터, 프로덕트 매니저, 프로덕트 오너는 보통의 스크럼에서 부여받는 역할에 대해서 릴리즈 트레인 엔지니어의 역할을 수행해야 합니다. 이 팀원은 서번트 리더이자 ART 코치로서 전체 팀들의 목표를 조정하는 가이드 역할을 수행합니다. ART안에는 각각이 완전한 솔루션을 산출해낼 능력이 있는 5개에서 12개의 팀이 있을 수 있습니다.
- Large Solution
Large Solution은 Essential SAFe보다 상위 레벨이며, ‘솔루션 틀레인’이라는 개념이 새롭게 도입됩니다. 이 구성은 여러 개의 ART(수백에서 수천 명 규모)가 하나의 가치 흐름 내에서 협업하는, 이름 그대로 복잡한 대규모 솔루션을 만들 때 사용됩니다. 마이크로소프트를 예시로 하면 엑셀, 워드, 파워포인트를 담당하는 3개의 팀은 모두 마이크로소프트 오피스라는 하나의 가치 흐름 안에서 작업하고 있다고 보면 됩니다.
- Portfolio
Portfolio는 Large Solution과 다르게 다양한 가치 흐름을 위해 작업하는 여러 개의 ART로 구성됩니다. 다시 마이크로소프트로 예를 들자면 마이크로 소프트 오피스, 스카이프, Xbox 등 다른 부서에서 근무하는 팀 들입니다.
- Full SAFe
Full SAFe는 위에서 소개한 모든 레벨을 포함하는 가장 포괄적인 구성으로서 전사적인 팀 관리를 조정합니다.
| 조직에 SAFe가 적합한지 판단하는 기준 |
|---|
| – 규모가 크고 안정적인 기업이다. – 조직이 스크럼에 능숙하다. – 추가 인원을 채용할 재정적 여력이 있다. – 향후 다수의 팀이 필요할 수 있는 복잡한 솔루션을 구축한다. – 핵심 프레임워크의 관행을 엄격하게 따를 수 있다. – 직급과 무관하게 의사 결정이 가능한 애자일 리더십을 적용하고 있다. |
2. 넥서스 프레임워크 Nexus Framework
넥서스 프레임워크도 스크럼을 기반으로 하지만 보통 3~9개의 팀이 협업을 하기 때문에 SAFe보다는 가볍습니다. 또한, 넥서스는 SAFe와 달리 릴리즈 트레인 엔지니어 같은 새로운 역할이 필요하지 않습니다. 이 프레임워크에서는 각 팀에서 대표자 한 명을 뽑아서 구성된 통합팀(integration team)을 만들고, 하나의 목표를 달성하기 위해서 팀들의 업무를 조정 관리합니다. 그리고 스크럼과 마찬가지로 모든 팀이 함께 스프린트 계획 세션에 참여하고, 결과는 프로덕트 백로그가 됩니다. 또, 각 팀은 진행 상황 확인을 위해 스탠드업과 유사한 회의를 매일 합니다. 통합팀도 매일 회의를 하며 진행 상황을 공유합니다.
넥서스 프레임워크는 여러 팀들의 협동을 요하기 때문에 백로그 관리의 복잡성이 높습니다. 그렇기 때문에 스프린트 도중에 백로그의 우선순위를 정하고 업무 사이즈를 예측하는 개선(refinement) 세션을 가집니다. 또, 스프린트 이후에는 팀들이 모여서 리뷰와 회고를 해야 합니다.
| 조직에 넥서스 프레임워크가 적합한지 판단하는 기준 |
|---|
| – 가벼운 프레임워크가 필요한 스타트업이다. – 조직이 스크럼에 능숙하다. – 보유한 재정 자원이 제한적이다. – 간단한 솔루션을 만든다. |
3. 대형 스크럼 Large-Scale Scrum(LeSS)
LeSS는 넥서스와 거의 동일한데, 네이밍 규칙과 팀별 스프린트 계획 세션이 있는 등의 사소한 차이가 있습니다. 또한 8개 이상 팀의 협업을 지원하는 두 번째 구성인 LeSS Huge으로 확장할 수도 있습니다.
LeSS Huge는 고객 중심적인 접근 방식으로 개발 구성을 조직화합니다. 업무를 효과적으로 관리하기 위해서, 프로덕트 오너는 하이 레벨 프로덕트의 백로그를 보다 세부화된 항목의 ‘영역 백로그(area backlog)’들로 분할한 후에, 영역 백로그들을 요구 사항 영역(requirement area) 별로 분류합니다.
이러한 요구 사항 영역들은 영역 프로덕트 오너(area product owner(APO))가 관리합니다. APO는 담당하는 영역을 전문으로 하며, 여러 팀과 함께 해당 영역에 대한 솔루션을 구축합니다. 각 요구사항 영역은 단 한 명의 APO가 관리하고, 백로그에 기록된 요구사항들은 해당 영역에만 속합니다.
| 조직에 LeSS와 LeSS Huge 프레임워크가 적합한지 판단하는 기준 |
|---|
| – 가벼운 프레임워크가 필요한 스타트업이다. – 조직이 스크럼에 능숙하다. – 보유한 재정 자원이 제한적이다. – 향후 다수의 팀이 필요할 수 있는 복잡한 솔루션을 구축한다. |
4. 스크럼 스케일 Scrum@Scale(S@S)
Scrum@Scale은 한 팀이 진행하는 스크럼 방식을 여러 팀을 하나의 팀처럼 운용하며 스크럼 하는 프레임워크입니다. 또, 널리 알려져 있는 스크럼 개발 프로세스의 확장 개념이기 때문에 가장 쉽게 배우고 이해할 수 있습니다.
이 프레임워크의 핵심 구성 요소는 각 팀에서 선출된 대표자 한 명씩이 모여서 매일 미팅을 진행하는 Scrum of Scrums (SoS)입니다. SoS는 프레임워크에 속한 팀들 간의 조정 및 의사소통을 돕는 것과 종속성이나 업무 중복 등의 관리를 목표로 진행됩니다.
Scrum@Scale에는 SoS 마스터와 치프 프로덕트 오너(chief product owner)라는 프레임 고유의 포지션이 있습니다. SoS 마스터는 스크럼 마스터의 확장 개념의 역할을 수행하고, 치프 프로덕트 오너는 각 팀의 프로덕트 오너들과 함께 SoS의 백로그를 관리합니다.
Scrum@Scale은 다른 프레임워크에 비해 규정된 게 적기 때문에 조직의 페이스에 맞게 자유롭게 확장할 수 있습니다. 만약 팀의 수가 계속 증가하고 SoS 미팅이 너무 많아지면 조직은 Scrum of Scrum of Scrums (SoSoS)로 한 단계 더 확장하면 됩니다.
| 조직에 Scrum@Scale이 적합한지 판단하는 기준 |
|---|
| – 규모가 큰 기업이다. – 유연한 스케일링 접근법이 필요하다. – 조직이 스크럼에 능숙하다. – 향후 다수의 팀이 필요할 수 있는 복잡한 솔루션을 구축한다. |
5. 학습 애자일 Disciplined Agile(DA)
DA는 스크럼(Scrum)과 칸반(Kanban) 등 다양한 프레임워크의 하이브리드 형태입니다. 또, 문맥 중심의 프레임워크이기 때문에 규칙을 엄격히 준수해야 하는 여타 프레임워크들과 달리 상황에 따라 가장 적절한 확장 전략을 선택할 수 있는, 마치 도구 상자와 같은 역할을 합니다. DA의 바탕이 되는 사상은 팀원부터 팀과 조직까지의 모든 단위에서 각자는 모두 다 다른 규모, 배포 및 도메인을 가지고 있다는 다름을 포용하는 것입니다.
DA 프레임워크는 소프트웨어 개발 팀부터 엔터프라이즈 레벨까지 모든 규모의 팀 단위에 적용할 수 있습니다. 엔터프라이즈 레벨에 적용하는 경우 DA는 재무, IT 운영 및 공급업체 관리와 같은 다양한 비즈니스 기능이 해결해야 하는 문제에 대한 다양한 옵션을 제공합니다.
DA는 프로젝트를 크게 ‘도입(inception), 구축(construction), 전환(transition)’ 세 단계로 구분합니다. 또한, 5개의 필수 포지션이 있고 확장할 때 임시로 역할을 수행하는 5개의 확장 지원 포지션으로 구성됩니다. 필수 포지션은 이해관계자(stakeholder), 팀 멤버, 팀 리드, 프로덕트 오너, 아키텍처 오너가 있으며, 지원 포지션은 스페셜리스트, 도메인 전문가, 기술 전문가, 독립 테스터(independent tester)와 통합자(integrator)가 있습니다.
또한 DA는 다른 ‘애자일 프레임워크’와 함께 사용되어서 스케일링 효과를 크게 가져갈 수도 있습니다.
| 조직에 DA가 적합한지 판단하는 기준 |
|---|
| – 규모가 크고 안정적인 기업이다. – 애자일 하지만 반드시 스크럼 프로세스를 따르지 않아도 된다. – 유연한 스케일링 접근법이 필요하다. – 추가 인원을 채용할 재정적 여력이 있다. |
‘애자일 프레임워크’는 신중하게 정하고 천천히 도입해야 합니다.
조직에 가장 적절한 ‘애자일 프레임워크’를 적용한다면 보다 매끄럽게 애자일 팀들의 업무를 통합하면서 스케일링할 수 있습니다. 만약 ‘애자일 프레임워크’를 선정하는 게 어렵다면 아래의 흐름도를 참고해 보세요.
이 글에 소개된 확장형 ‘애자일 프레임워크’들 중에 여러분의 조직에 꼭 맞는 것을 찾을 수 있을 거라고 확신합니다. 그리고 어떤 프레임워크를 선택하는지 보다 중요한 것은, 조직의 혼란을 최소화하기 위해서 프레임워크를 도입하기 한참 전부터 계획해야 하며 스케일링을 점진적으로 해야 하는 것임을 꼭 명심하셔야 합니다.
1 개발(Development)과 운영(Operations)을 합친 말로서, 소프트웨어 개발자와 운영자 간의 긴밀한 의사소통 및 협업을 강조하는 개발 환경 및 문화
2 지속적인 통합 및 지속적인 배포
3 스프린트를 통해 완료되어 기존 프로덕트에 새로 더해지는 새로운 부분
4 고객에게 지속적인 가치의 흐름을 제공하는 솔루션을 구축하는 조직이 사용하는 일련의 단계
국내 1위 IT아웃소싱 플랫폼 위시켓에 프로젝트를 등록해 보세요.
6만여 건의 데이터를 바탕으로 프로젝트 견적을 상담해 드립니다.
