17.27 애자일(Agile) 개발 환경에서의 다기능 팀 스프린트 운영

1. 애자일 방법론의 이론적 기반과 다기능 팀의 연결

1.1 애자일 선언과 핵심 원칙

애자일 소프트웨어 개발 선언(Agile Manifesto, 2001)은 네 가지 핵심 가치를 제시한다: 프로세스와 도구보다 개인과 상호작용(individuals and interactions over processes and tools), 포괄적 문서보다 작동하는 소프트웨어(working software over comprehensive documentation), 계약 협상보다 고객과의 협력(customer collaboration over contract negotiation), 계획 수행보다 변화에 대한 대응(responding to change over following a plan). 이 가치들은 전통적 폭포수(waterfall) 방법론의 계획 주도적(plan-driven) 접근에 대한 대안으로 제시되었다.

Boehm과 Turner(2003)는 애자일 방법론과 계획 주도적 방법론이 상호 배타적이 아니라, 프로젝트의 특성에 따라 적절히 배합되어야 한다고 주장하였다. 과업의 불확실성이 높고, 요구사항의 변동이 빈번하며, 팀의 자율성과 역량이 높은 상황에서 애자일 접근이 더 효과적이다.

다기능 조직(Cross-functional Team)과 애자일 방법론 사이에는 구조적 친화성이 존재한다. 스크럼 가이드(Scrum Guide)가 정의하는 스크럼 팀은 “제품 목표를 달성하는 데 필요한 모든 기술을 갖춘 다기능적(cross-functional)” 구성을 핵심 특성으로 규정한다. 애자일 프레임워크는 다기능 팀을 전제 조건으로 설정하며, 다기능 팀의 효과적 운영 없이는 애자일의 약속이 실현되지 못한다.

1.2 반복적-점증적 개발의 이론적 근거

애자일 방법론의 반복적-점증적(iterative-incremental) 개발 접근은 경험적 프로세스 제어(empirical process control) 이론에 기반한다. Schwaber와 Sutherland(2020)는 스크럼의 세 가지 기둥으로 투명성(transparency), 검사(inspection), 적응(adaptation)을 제시하였다. 이 세 기둥은 복잡하고 불확실한 환경에서 미리 완벽한 계획을 수립하는 것이 불가능하므로, 짧은 주기로 산출물을 생산하고 이를 검사하여 방향을 조정하는 경험적 접근이 필수적이라는 인식에 기반한다.

Takeuchi와 Nonaka(1986)의 “The New New Product Development Game” 논문은 럭비의 스크럼(scrum)에서 영감을 받아, 제품 개발에서 순차적 릴레이(sequential relay) 방식보다 팀 전체가 동시에 움직이는 전체론적(holistic) 접근이 더 효과적임을 주장하였다. 이 연구는 스크럼 프레임워크의 직접적 기원으로 인정되며, 다기능 팀의 자율적이고 동시적인 작업 방식의 학술적 근거를 제공하였다.

2. 스프린트의 구조와 다기능 팀의 역할

2.1 스프린트의 정의와 구성 요소

스프린트(sprint)는 스크럼 프레임워크에서 정의하는 고정된 시간 단위(time-box)의 개발 주기이다. Schwaber와 Sutherland(2020)에 따르면, 스프린트는 최대 1개월 이내의 기간으로 설정되며, 각 스프린트에서 팀은 “완료(done)“의 정의를 충족하는 잠재적으로 출시 가능한 제품 증분(potentially releasable product increment)을 산출한다.

스프린트는 다음의 구성 요소로 이루어진다: 스프린트 계획(sprint planning), 일일 스크럼(daily scrum), 개발 작업(development work), 스프린트 리뷰(sprint review), 스프린트 회고(sprint retrospective).

다기능 팀에서 각 스프린트 의식(ceremony)은 기능 간 조정과 통합의 구조화된 기회를 제공한다. 이는 기능 간 의사소통이 비구조화된 방식에만 의존할 때 발생하는 조정 실패를 방지하는 제도적 장치로 기능한다.

2.2 스프린트 계획에서의 다기능적 추정과 우선순위 설정

스프린트 계획(sprint planning)에서 다기능 팀은 제품 백로그(product backlog)에서 해당 스프린트에 수행할 항목을 선택하고, 이를 달성하기 위한 계획을 수립한다. 다기능 팀의 맥락에서 스프린트 계획의 핵심적 과제는 기능별 작업량의 균형 배분과 기능 간 의존성의 관리이다.

작업량 추정에서 다기능 팀은 스토리 포인트(story point)나 이상적 일수(ideal days)를 활용하여 각 백로그 항목의 복잡성을 평가한다. Cohn(2005)이 제시한 플래닝 포커(planning poker) 기법은 팀 구성원 각자가 독립적으로 추정치를 제시한 후, 차이가 큰 항목에 대해 토론을 통해 합의에 도달하는 구조화된 추정 방법이다. 다기능 팀에서 이 기법은 서로 다른 기능적 관점에서의 복잡성 인식 차이를 노출시키고, 숨겨진 기능 간 의존성을 사전에 식별하는 데 효과적이다.

우선순위 설정에서 제품 소유자(product owner)가 비즈니스 가치에 기반한 우선순위를 제시하면, 다기능 팀은 기술적 실현 가능성, 기능 간 의존성, 학습 목표 등을 고려하여 스프린트 내 작업 순서를 결정한다. 이 과정에서 서로 다른 기능적 관점이 우선순위 판단에 반영되며, 특정 기능의 관점에만 편향된 우선순위 결정을 방지한다.

2.3 일일 스크럼에서의 기능 간 조정

일일 스크럼(daily scrum)은 15분 이내의 짧은 동기화(synchronization) 회의로, 팀 구성원이 전일 수행 내용, 금일 수행 계획, 장애물(impediment)을 공유한다. 다기능 팀에서 일일 스크럼은 기능 간 작업 진행 상황의 실시간 투명성을 보장하는 핵심 메커니즘이다.

Stray 등(2016)의 연구는 일일 스크럼이 팀의 공유 상황 인식(shared situational awareness)을 향상시키고, 기능 간 장애물의 조기 식별을 가능하게 한다고 보고하였다. 다기능 팀에서 특정 기능 영역의 진행 지연이나 기술적 장애가 타 기능의 작업에 미치는 영향을 일일 스크럼에서 신속하게 파악함으로써, 스프린트 목표의 달성을 위한 적시적 조정이 이루어진다.

그러나 일일 스크럼이 단순한 상태 보고(status reporting)로 퇴행하는 위험이 존재한다. Stray 등(2016)은 효과적인 일일 스크럼이 정보 공유를 넘어서 협력적 문제 해결의 기회로 활용되어야 함을 강조하였다. 다기능 팀에서 기능 간 장애물은 종종 다기능적 해결을 요구하므로, 일일 스크럼에서 식별된 장애물에 대한 후속 논의를 즉시 안배하는 관행이 필요하다.

2.4 스프린트 리뷰와 스프린트 회고

**스프린트 리뷰(sprint review)**에서 다기능 팀은 스프린트 산출물을 이해관계자에게 시연하고, 피드백을 수집하며, 제품 백로그를 갱신한다. 다기능 팀의 맥락에서 스프린트 리뷰는 팀의 통합적 산출물이 이해관계자의 기대를 충족하는지를 검증하는 동시에, 기능 간 통합의 품질을 외부적으로 평가받는 기회이다.

**스프린트 회고(sprint retrospective)**에서 팀은 스프린트의 프로세스를 돌아보고 개선점을 도출한다. Derby와 Larsen(2006)은 효과적인 회고를 위한 구조화된 기법들을 제시하였으며, “무엇이 잘 되었는가(what went well)”, “무엇이 잘 되지 않았는가(what didn’t go well)”, “무엇을 개선할 수 있는가(what can we improve)“의 기본 프레임워크가 널리 활용된다.

다기능 팀에서 스프린트 회고는 기능 간 협업 프로세스의 효과성을 주기적으로 점검하는 핵심 메커니즘이다. 기능 간 의사소통의 적절성, 의존성 관리의 효과, 통합 작업의 효율성 등이 회고의 주요 검토 대상이 된다. Senge(1990)의 팀 학습 개념이 스프린트 회고를 통해 구조화된 실천으로 구현된다.

3. 다기능 팀의 스프린트 운영에서의 특수한 도전

3.1 기능 간 작업 흐름의 불균형

다기능 팀의 스프린트 운영에서 빈번히 발생하는 문제는 기능별 작업량의 불균형이다. 특정 스프린트에서 디자인 작업이 집중되는 반면 개발 작업은 적거나, 반대로 개발 작업이 집중되는 반면 테스트 작업이 부족한 상황이 발생할 수 있다. 이러한 불균형은 특정 기능의 유휴(idle) 시간과 다른 기능의 과부하를 동시에 초래한다.

이 문제의 해결을 위해 Leffingwell(2011)은 다기능 팀 구성원의 T자형 역량(T-shaped skills) 개발을 권고하였다. T자형 역량이란 자신의 주 전문 영역에서의 깊은 전문성(T의 수직선)과 함께 인접 기능 영역에서의 기초적 역량(T의 수평선)을 보유하는 것을 의미한다. T자형 역량을 갖춘 구성원은 자신의 주 영역의 작업이 부족할 때 다른 기능 영역의 작업을 보조할 수 있어, 스프린트 내 작업 흐름의 원활화에 기여한다.

3.2 완료 정의의 다기능적 합의

“완료의 정의(Definition of Done, DoD)“는 백로그 항목이 완료된 것으로 간주되기 위해 충족해야 하는 기준의 목록이다. 다기능 팀에서 완료의 정의는 모든 기능 영역의 기준을 통합적으로 반영해야 한다. 기능 테스트의 통과, 성능 기준의 충족, 사용자 경험(UX) 기준의 부합, 보안 검토의 완료, 문서화의 수행 등이 완료의 정의에 포함될 수 있다.

완료의 정의에 대한 다기능적 합의의 부재는 “미완료 작업(undone work)“의 누적을 초래한다. 특정 기능의 기준만 충족한 채 다른 기능의 기준을 미충족한 상태로 항목이 “완료“로 표시되면, 이후 스프린트에서 미완료 작업의 보완에 추가적 비용이 발생하며, 이는 기술 부채(technical debt)의 축적으로 이어진다.

3.3 스프린트 주기와 기능별 작업 주기의 정렬

서로 다른 기능 영역의 작업 주기(work cycle)가 상이할 때 스프린트 주기와의 정렬이 어려울 수 있다. 예컨대 사용자 조사(user research)는 스프린트 주기보다 긴 기간을 요구하며, 하드웨어 프로토타이핑은 소프트웨어 개발보다 현저히 긴 리드타임(lead time)을 수반한다.

이러한 불일치의 관리를 위해 선행 스프린트(look-ahead sprint) 또는 이중 트랙(dual-track) 접근이 활용된다. Gothelf와 Seiden(2013)이 제시한 린 UX(Lean UX) 접근에서 발견(discovery) 트랙과 전달(delivery) 트랙을 병행 운영하여, 사용자 조사와 개발이 동시에 진행되되 적절한 시차(time lag)를 두고 정보가 전달되는 구조를 설계하였다.

4. 대규모 애자일에서의 다기능 팀 조정

4.1 다수 팀 간 조정 프레임워크

조직의 규모가 확대되어 다수의 다기능 팀이 동일 제품에 기여하는 경우, 팀 간 조정의 문제가 발생한다. 이를 해결하기 위한 대규모 애자일(scaled agile) 프레임워크들이 제시되었다.

**SAFe(Scaled Agile Framework)**는 Leffingwell(2011)이 개발한 대규모 애자일 프레임워크로, 팀 수준(team level), 프로그램 수준(program level), 대규모 솔루션 수준(large solution level), 포트폴리오 수준(portfolio level)의 네 가지 계층을 정의한다. 프로그램 수준에서 복수의 다기능 팀은 애자일 릴리스 열차(Agile Release Train, ART)라는 단위로 조직되며, 프로그램 증분(Program Increment, PI) 계획을 통해 팀 간 의존성을 관리한다.

**LeSS(Large-Scale Scrum)**는 Larman과 Vodde(2016)가 제시한 프레임워크로, 스크럼의 원칙을 최소한의 추가 구조로 확장하는 접근을 취한다. LeSS에서는 다수의 다기능 팀이 동일한 제품 백로그를 공유하며, 팀 간 조정은 비공식적 의사소통, 공동 회고, 교차 팀 정교화(cross-team refinement) 등의 경량 메커니즘을 통해 수행된다.

4.2 스크럼 오브 스크럼

스크럼 오브 스크럼(Scrum of Scrums)은 다수의 스크럼 팀 간 조정을 위해 각 팀의 대표가 참여하는 상위 수준의 동기화 회의이다. 이 회의에서는 팀 간 의존성, 장애물, 통합 이슈를 논의한다. 다기능 팀의 맥락에서 스크럼 오브 스크럼은 팀 간 기능적 인터페이스의 관리와 통합 작업의 조정에 초점을 맞춘다.

5. 애자일 원칙의 비소프트웨어 영역 확장과 한계

5.1 비소프트웨어 기능의 스프린트 참여

다기능 팀에 마케팅, 영업, 법무, 규제 등 비소프트웨어 기능이 포함된 경우, 스프린트 운영에 특수한 적응이 필요하다. 이러한 기능의 작업은 소프트웨어 개발과 상이한 특성을 가지므로, 스프린트 내에서의 통합이 직관적이지 않다.

Rigby 등(2016)은 하버드 비즈니스 리뷰(Harvard Business Review)에서 애자일 원칙의 비소프트웨어 영역 확장 가능성을 논의하며, 혁신이 요구되고, 환경이 불확실하며, 모듈화된 산출물이 가능한 영역에서 애자일 접근이 효과적이라고 결론지었다.

5.2 하이브리드 접근의 필요성

모든 기능 영역이 동일한 스프린트 주기와 애자일 의식에 동등하게 참여하는 것이 현실적이지 않은 경우, 하이브리드 접근(hybrid approach)이 채택된다. 핵심 개발 기능은 스크럼의 엄격한 프레임워크를 따르되, 보조 기능은 칸반(Kanban) 방식이나 전통적 프로젝트 관리 방식으로 운영하면서 정기적 동기화 지점에서 통합되는 방식이다.

Vinekar 등(2006)은 애자일과 전통적 방법론의 공존을 “양손잡이 접근(ambidextrous approach)“으로 개념화하며, 조직이 상이한 과업 특성에 적합한 방법론을 동시에 운영할 수 있는 역량을 갖추어야 한다고 주장하였다. 다기능 팀에서 이러한 양손잡이 접근은 기능별 업무 특성의 차이를 존중하면서도 전체 팀의 통합적 성과를 달성하기 위한 실용적 전략이다.