스크럼¶

애자일 개발의 광활한 세계에서, 애자일이 변화를 수용하도록 안내하는 "가치"들의 집합이라면, 스크럼은 그 가치들을 실제로 실천하기 위한 가장 인기 있고 널리 사용되는 가벼운 프레임워크입니다. 스크럼은 상세한 프로세스나 방법론이 아니라, 팀이 효율적으로 협업하고 복잡한 제품을 개발하면서 지속적으로 가치를 전달할 수 있도록 돕는 게임을 위한 "룰북"입니다. 스크럼은 간단하고 명확하지만 강력한 반복적 업무 리듬을 제공하며, 일련의 명확한 역할, 이벤트, 아티팩트를 정의합니다.

스크럼이라는 이름은 럭비에서 팀 전체가 하나의 목표를 향해 긴밀하게 협력하는 "스크럼"이라는 동작에서 유래했습니다. 스크럼은 복잡한 문제에 직면할 때 초기 단계에서 모든 답을 알고 있을 수 없다는 점을 인정합니다. 따라서 스크럼의 핵심은 길고 불확실한 문제를 짧고 고정된 시간 간격의 반복(즉, "스프린트")을 통해 일련의 작은 실험으로 나누는 것입니다. 각 스프린트가 끝날 때 팀은 사용 가능한 제품 증분을 제공하고, 성찰과 조정을 통해 변화 속에서도 경험에서 배우고 나아갑니다.

스크럼 프레임워크의 3대 기둥¶

전체적인 스크럼 프레임워크는 다음의 3가지 경험적 기둥 위에 구축됩니다:

투명성: 결과에 영향을 미치는 모든 중요한 측면은 결과에 책임이 있는 모든 사람들(고객 포함)에게 공개되어야 합니다. 즉, 작업 진행 상황, 장애물, 백로그 등이 개방적이고 투명해야 한다는 의미입니다.
검사: 목표 달성을 위한 스크럼 아티팩트와 진행 상황은 부정적인 편차나 문제를 조기에 감지할 수 있도록 정기적이고 철저하게 검사되어야 합니다.
적응: 검사 결과 현재 작업이 허용 가능한 한계를 벗어나고, 결과물이 수용 불가능한 상태가 될 것이라 판단되면, 프로세스나 처리 중인 자료를 즉시 조정해야 합니다.

스크럼의 3-5-3 구조¶

스크럼의 "게임 규칙"은 간결하게 "3-5-3" 구조로 요약할 수 있습니다: 3개의 역할, 5개의 이벤트, 3개의 아티팩트.

graph TD
    subgraph 스크럼 프레임워크 (3-5-3)
        subgraph 3 Roles
            A(<b>제품 오너</b><br/><i>제품 가치 극대화 책임</i>)
            B(<b>스크럼 마스터</b><br/><i>스크럼이 올바르게 실행되도록 보장하는 역할</i>)
            C(<b>개발자</b><br/><i>제품 증분을 전달하는 책임</i>)
        end

        subgraph 5 Events
            D(<b>스프린트</b><br/><i>핵심 이벤트, 1-4주 반복 주기</i>) --> E(<b>스프린트 계획</b>);
            E --> F(<b>데일리 스크럼</b>);
            F --> G(<b>스프린트 검토</b>);
            G --> H(<b>스프린트 회고</b>);
        end

        subgraph 3 Artifacts
            I(<b>제품 백로그</b><br/><i>전체 요구사항 목록</i>)
            J(<b>스프린트 백로그</b><br/><i>현재 스프린트의 작업 목록</i>)
            K(<b>증분</b><br/><i>현재 스프린트에서 완료된 사용 가능한 제품 부분</i>)
        end
    end

3개의 역할¶

제품 오너(Product Owner): 제품의 "가치"에 대해 유일하게 책임을 지는 사람입니다. 주된 업무는 제품 백로그를 관리하고 최적화하여 개발 팀이 항상 고객과 비즈니스에 가장 높은 가치를 창출하는 항목에 집중하도록 보장하는 것입니다. "무엇을 해야 할지" 결정합니다.
스크럼 마스터(Scrum Master): 스크럼 프레임워크의 "봉사 리더"이자 "코치"입니다. 팀을 관리하는 것이 아니라 팀을 지원하며, 장애물을 제거하고 이벤트를 주관하며 팀이 스크럼의 규칙과 가치를 올바르게 이해하고 따르도록 보장하는 책임이 있습니다.
개발자(Developers): 다양한 기능을 수행하고 스스로 조직하는 전문가들로 구성된 팀으로, 각 스프린트에서 백로그의 항목을 고품질의 전달 가능한 제품 증분으로 전환하는 책임을 집니다. "어떻게 할 것인가"는 개발자들이 결정합니다.

5개의 이벤트¶

스프린트: 스크럼의 핵심이며, 고정된 기간(일반적으로 1~4주)의 시간 박스입니다. 스프린트 동안 팀은 "스프린트 목표(Sprint Goal)"를 달성하는 데 집중합니다.
스프린트 계획: 각 스프린트 시작 시 진행됩니다. 제품 오너는 제품 백로그에서 가장 우선순위가 높은 항목들을 개발 팀에게 설명합니다. 팀은 스스로 해당 스프린트에서 완료할 수 있는 작업을 선택하고 약속하며, 초기 실행 계획을 세워 스프린트 백로그를 형성합니다.
데일리 스크럼: 15분을 넘지 않는 일일 동기화 회의입니다. 개발 팀의 각 구성원은 차례로 다음 세 가지 질문에 답합니다: "어제 무엇을 했는가?", "오늘 무엇을 할 것인가?", "어떤 장애물을 만났는가?" 이 회의의 목적은 신속하게 진행 상황을 동기화하고 장애물을 식별하는 것이지, 관리자에게 보고하는 것이 아닙니다.
스프린트 검토: 스프린트 종료 시 진행됩니다. 개발 팀은 제품 오너, 고객, 기타 이해관계자들에게 완료된 동작 가능한 증분을 시연하고 피드백을 수집합니다. 이 회의는 "제품"에 대한 비공식적인 논의의 장입니다.
스프린트 회고: 스프린트 검토 이후 다음 스프린트 시작 전에 진행됩니다. 스크럼 팀(PO, SM, 개발자)은 방금 끝난 스프린트에서 사람, 관계, 프로세스, 도구 측면에서 잘된 점과 개선할 점을 성찰하고, 다음 스프린트를 위한 구체적인 개선 계획을 수립합니다.

3개의 아티팩트¶

제품 백로그: 알려진 모든 제품 요구사항, 기능, 수정, 개선사항을 포함하는 동적이고 우선순위가 매겨진 포괄적인 목록입니다. 제품 오너만이 관리합니다.
스프린트 백로그: 개발 팀이 현재 스프린트에서 완료하기로 약속한 작업 목록과 "스프린트 목표" 달성을 위한 계획입니다. 개발 팀이 독점적으로 소유하고 관리합니다.
증분: 각 스프린트 종료 시점에서 완료된 제품 백로그 항목들의 총합입니다. 이 증분은 사용 가능해야 하며 "완료의 정의(Definition of Done)"에 부합해야 합니다. 이는 팀의 작업 결과를 직접적으로 보여주는 것입니다.

적용 사례¶

사례 1: 온라인 음식 주문 앱 개발

제품 백로그: "사용자 등록", "메뉴 보기", "온라인 결제", "주문 추적" 등 수백 개의 사용자 스토리 포함.
스프린트 1 (2주):
- 스프린트 목표: "사용자가 성공적으로 등록하고 로그인할 수 있게 한다."
- 스프린트 백로그: 팀은 등록 및 로그인 관련 5개의 사용자 스토리를 선택함.
- 데일리 스크럼: 팀은 매일 진행 상황을 동기화하며 "불안정한 SMS 인증 코드 인터페이스"라는 장애물을 발견함. 스크럼 마스터가 즉시 조치하여 문제를 해결함.
- 스프린트 검토: 팀은 작동 가능한 등록 및 로그인 프로세스를 시연함.
- 스프린트 회고: 팀은 작업 예측이 지나치게 낙관적이었다는 점을 반성하고, 다음 스프린트부터는 보수적인 예측 방법을 채택하기로 함.

사례 2: 마케팅 팀이 제품 출시 이벤트를 기획하는 경우

스크럼은 소프트웨어 개발에만 적용되는 것이 아닙니다.
제품 오너: 마케팅 디렉터.
제품 백로그: "출시 이벤트 테마 결정", "메인 비주얼 디자인", "미디어 및 KOL 초청", "보도자료 작성", "장소 예약" 등 모든 작업 항목 포함.
스프린트 1 (1주):
- 스프린트 목표: "출시 이벤트의 핵심 테마와 초기 메인 비주얼 디자인 확정."
- 팀은 1주일 간의 스프린트를 통해 결과물을 신속히 제작하고 검토 회의에서 고위 경영진에게 시연하여 즉각적인 피드백을 받았으며, 잘못된 방향으로 디자인 자원을 과도하게 투자하는 것을 방지함.

사례 3: 학생 그룹이 학기 프로젝트를 수행하는 경우

제품 오너: 한 명의 학생이 PO 역할을 하며 교수와 소통하고 프로젝트 요구사항을 명확히 함.
제품 백로그: "문헌 고찰", "데이터 수집", "데이터 분석", "보고서 작성", "PPT 제작" 등 전체 프로젝트를 분할한 항목들.
스프린트: 학기의 남은 8주를 4개의 2주 스프린트로 나눔. 각 스프린트는 명확한 목표를 가지며, 예를 들어 첫 번째 스프린트의 목표는 "문헌 고찰 및 연구 설계 완료"였습니다. 이 접근법은 학기 말에 몰아서 작업하는 것을 효과적으로 방지했습니다.

스크럼의 장점과 도전 과제¶

핵심 장점

생산성과 속도 향상: 짧은 사이클의 반복과 집중을 통해 팀은 더 빠르게 가치를 전달할 수 있습니다.
유연성과 적응력 향상: 변화하는 요구사항에 침착하게 대응하며 피드백을 기반으로 방향을 적시에 조정할 수 있습니다.
투명성과 커뮤니케이션 향상: 명확한 역할, 이벤트, 아티팩트는 팀 내외부의 커뮤니케이션과 정보 동기화를 크게 향상시킵니다.
팀 역량 강화, 사기 진작: 스스로 조직하는 개발 팀은 더 높은 자율성과 주인의식을 가집니다.

잠재적 도전 과제

"이해는 쉬워도 숙련은 어렵다": 스크럼의 규칙은 간단하지만, 애자일의 본질적인 정신을 진정으로 이해하고 특정 조직 문화 속에서 성공적으로 실천하는 것은 매우 어렵습니다.
제품 오너에 대한 높은 요구: 제품 오너는 비즈니스, 시장, 고객에 대해 깊이 이해해야 하며, 뛰어난 커뮤니케이션 능력과 의사결정 능력을 가져야 합니다.
"범위 확장(Scope Creep)" 가능성: 제품 오너가 백로그와 이해관계자들의 기대를 잘 관리하지 못하면 스프린트 목표가 자주 변경될 수 있습니다.
팀 성숙도 요구: 스스로 조직하는 팀은 높은 책임감, 협업 정신, 다기능 역량을 갖춘 구성원들을 필요로 합니다.

확장 및 연계¶

애자일 개발: 스크럼은 애자일의 가치와 원칙을 실현하기 위한 구체적이고 주류인 프레임워크입니다.
칸반: 또 다른 인기 있는 애자일 방법입니다. 스크럼이 "시간 박스(스프린트)" 기반의 리듬을 갖는 반면, 칸반은 "지속적인 흐름"에 초점을 둡니다. 실제로 많은 팀들이 두 방법을 결합합니다. 예를 들어, 스크럼 스프린트 내에서 칸반을 사용하여 작업 흐름을 시각화하고 관리하는 방식은 "스크럼반(Scrumban)"이라고 불립니다.
익스트림 프로그래밍(XP): 스크럼은 "관리 프레임워크"를 제공하고, XP는 훌륭한 "엔지니어링 실천 방법"을 제공합니다. XP의 실천 방법(예: 테스트 주도 개발, 페어 프로그래밍 등)을 스크럼 프레임워크에 통합하면 제품 증분의 기술적 품질을 크게 향상시킬 수 있습니다.

참고: 스크럼 프레임워크는 1990년대 초반 제프 서더랜드(Jeff Sutherland)와 켄 슈웨이버(Ken Schwaber)가 공동으로 제안했습니다. 이들의 공동 저작물인 "스크럼 가이드(The Scrum Guide)"는 스크럼 프레임워크에 대한 유일한 공식 정의이며, 실무의 발전을 반영하여 정기적으로 업데이트됩니다.