Antigravity Agent
22cd97698e
- 옛 10_Wiki/Topics/Premium/Thinking & Reasoning/ 정리 (82건 삭제) - 새 구조로 재배치: - 10_Wiki/Topics/Thinking & Reasoning/ (290개 신규) - Premium/Thinking & Reasoning/ (236개 신규) - memory/episodes / lessons 자동 기록 추가 - .DS_Store / chronicle 메타 갱신 순수 콘텐츠 작업 — 코드 변경 없음. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
87 lines
7.2 KiB
Markdown
87 lines
7.2 KiB
Markdown
---
|
|
id: scrum
|
|
title: "Scrum"
|
|
category: "10_Wiki/Topics"
|
|
status: "draft"
|
|
verification_status: "conceptual"
|
|
canonical_id: ""
|
|
aliases: ["스크럼"]
|
|
duplicate_of: ""
|
|
source_trust_level: "B"
|
|
confidence_score: 0.85
|
|
created_at: 2026-05-22
|
|
updated_at: 2026-05-22
|
|
review_reason: ""
|
|
merge_history: []
|
|
tags: ["research", "design thinking", "agile"]
|
|
raw_sources: ["NotebookLM Synthesis"]
|
|
applied_in: ["Indian IT services firm", "Large Private Sector Bank in India"]
|
|
github_commit: ""
|
|
---
|
|
|
|
# [[Scrum]]
|
|
|
|
## 🎯 한 줄 통찰 (One-line insight)
|
|
스크럼은 정의된 백로그를 짧은 주기(Sprint) 내에 반복적으로 실행하여 동작하는 제품 증분(Increment)을 인도하고, 피드백을 통해 지속적으로 개선하는 가장 대중적인 [[Agile]] 프레임워크이다 [1, 2].
|
|
|
|
## 🧠 핵심 개념 (Core concepts)
|
|
1. **Sprint (스프린트):** 1주에서 4주 사이의 짧고 고정된 시간 내에 실행되는 딜리버리 사이클이다 [2, 3].
|
|
2. **Backlog (백로그):** 팀이 수행해야 할 작업을 우선순위에 따라 나열한 목록이다 [4, 5].
|
|
3. **Ceremonies (스크럼 의식):** 작업 계획(Sprint Planning), 일일 점검(Daily Standups), 시연 및 피드백(Sprint Review), 팀 회고(Retrospective)로 구성된 구조화된 활동이다 [4, 5].
|
|
4. **Working Product Increment (동작하는 제품 증분):** 각 스프린트가 끝날 때마다 생성되는, 검토 및 테스트가 가능한 실제 결과물이다 [2, 3].
|
|
|
|
## 🧩 추출된 패턴 (Extracted patterns)
|
|
- **Dual-Track Workflow:** [[Design Thinking]]이 발견 트랙으로서 스크럼 인도 트랙보다 1~2 스프린트 앞서 실행되어 연구 기반의 사용자 스토리를 제공하는 구조이다 [6, 7].
|
|
- **Empowered Teams:** 팀이 상위 경영진의 승인 없이 스스로 제품 결정을 내릴 수 있는 권한을 가질 때 스크럼의 가치가 실현된다 (권한 부재 시 'Fast Waterfall'로 변질됨) [8, 9].
|
|
- **Sequential Innovation Lifecycle:** [[Design Thinking]](발견) → [[Lean Startup]](검증) → **Scrum/Agile**(확장 및 인도) 순으로 연계하여 혁신 리스크를 최소화한다 [10, 11].
|
|
|
|
## 📖 세부 내용 (Details)
|
|
스크럼은 2001년 애자일 선언문(Agile Manifesto)의 원칙을 기반으로 소프트웨어 개발 분야에서 성장한 프레임워크이다 [2, 3]. 주로 **무엇을 구축해야 하는지 이미 알고 있거나 정의된 상태**에서 이를 효율적으로 구현하고 변화에 기민하게 대응하기 위해 설계되었다 [4, 5].
|
|
|
|
- **프로세스 운영:** 스프린트 계획 회의를 통해 백로그에서 작업량을 결정하고, 매일 짧은 스탠드업 미팅으로 장애물을 공유하며 모멘텀을 유지한다 [4, 5]. 스프린트 종료 시에는 이해관계자에게 시연(Review)하고 팀의 프로세스를 개선하기 위한 회고(Retrospective)를 진행한다 [4, 5].
|
|
- **인적 요소:** 스크럼의 성공은 프레임워크 자체가 아니라 리더십의 행동과 인센티브 설계, 팀의 권한 부여 수준에 따라 결정된다 [12, 13].
|
|
- **한계와 보완:** 스크럼은 '무엇을 만들 것인가'에 대한 근본적인 질문에 답하기보다는 '어떻게 빠르게 구축할 것인가'에 집중한다 [14, 15]. 따라서 상위 단계의 문제 정의(Problem Framing)가 결여된 스크럼은 잘못된 문제를 해결하는 제품을 효율적으로 만드는 결과를 초래할 수 있다 [10, 16, 17].
|
|
|
|
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
|
- **Agile vs Waterfall:** 많은 조직이 스크럼 의식(Rituals)을 수행하면서도 의사결정은 여전히 순차적이고 하향식(Waterfall)으로 진행하는 오류를 범하고 있다 [18, 19].
|
|
- **AI의 영향:** 2026년 기준, AI 도구의 가속화로 인해 프로토타이핑 속도가 빨라지면서 스크럼의 각 단계 간 경계가 모호해지고 있으며, 더 높은 수준의 전략적 판단이 요구되고 있다 [20, 21].
|
|
|
|
## 🛠️ 적용 사례 (Applied in summary)
|
|
- **인도 중견 IT 서비스 기업 (8,000명 규모):** 하이데라바드, 푸네, 벵갈루루 딜리버리 센터에서 스크럼을 도입했으나, 상위 단계의 문제 정의 부재로 인해 스프린트 중간에 범위가 계속 변경되는 friction이 발생했다 [22, 23]. 이후 [[Design Thinking]] 기반의 문제 정의 단계를 도입하여 범위 변경을 40% 감소시켰다 [16, 17].
|
|
- **대형 민간 은행:** 모바일 대출 신청 중단 문제를 해결하기 위해 3회의 애자일 스프린트를 실행하여 UI를 개선했으나 실패했다 [24, 25]. 이후 발견 단계를 통해 문제가 UX가 아닌 '신용 점수 하락에 대한 불신'임을 파악하고 해결했다 [26, 27].
|
|
|
|
## ✅ 검증 상태 및 신뢰도
|
|
- **상태:** draft
|
|
- **검증 단계:** conceptual (실제 기업 적용 사례 및 방법론적 비교 데이터 기반)
|
|
- **출처 신뢰도:** B (NextAgile, NN/G, Voltage Control 등 전문 컨설팅 및 연구 기관 데이터 기반)
|
|
- **중복 검사 결과:** 신규 생성
|
|
|
|
## 🔗 관련 문서 링크 (Related document links)
|
|
|
|
### 상위/유사 개념
|
|
- [[Agile]]
|
|
- 연결 이유: 스크럼의 기반이 되는 철학이자 모체이다 [2, 3].
|
|
- [[Design Thinking]]
|
|
- 연결 이유: 스크럼이 해결할 '올바른 문제'를 정의하기 위한 상위 단계의 프로세스이다 [28, 29].
|
|
|
|
### 심층 후속 질문 (Deeper Research Questions)
|
|
- 스크럼의 회고(Retrospective) 데이터가 실제 팀의 성과 지표와 어떻게 정량적으로 연결되는가?
|
|
- 분산된(Distributed) 팀 환경에서 스크럼 의식의 질을 유지하기 위한 촉진(Facilitation) 전략은 무엇인가? [30, 31]
|
|
- AI 가속 프로토타이핑 환경에서 스프린트 주기를 단축하는 것이 항상 효율적인가?
|
|
- 스크럼 마스터와 프로젝트 매니저의 역할 충돌을 해결하기 위한 조직 설계 패턴은 무엇인가? [32, 33]
|
|
- 규제가 엄격한 산업(예: BFSI)에서 스크럼의 유연성을 Compliance와 조화시키는 방법은 무엇인가? [34, 35]
|
|
|
|
### 실무 적용 맥락 (Practical Application Contexts)
|
|
- **Implementation:** 백로그 우선순위 지정 시 사용자 연구 데이터를 기반으로 스토리를 작성해야 한다 [6, 7].
|
|
- **System Design:** 지속적인 피드백 루프를 위해 각 스프린트 종료 시 동작하는 제품 증분을 인도할 수 있는 아키텍처가 필요하다 [2].
|
|
- **Operation / Maintenance:** 스프린트 리뷰를 통해 수집된 이해관계자의 요구사항을 다음 백로그에 즉각 반영한다 [4].
|
|
- **Learning Path:** 스크럼 의식만 수행하는 '무늬만 애자일'을 피하기 위해 팀원 전체가 애자일 12원칙에 대한 이해가 필요하다 [2, 18].
|
|
|
|
### 인접 주변 주제
|
|
- [[Lean Startup]]
|
|
- 확장 방향: 스크럼으로 구축하기 전 가설을 검증하는 MVP(최소 기능 제품) 전략을 탐구한다 [36, 37].
|
|
- [[Double Diamond]]
|
|
- 확장 방향: 스크럼의 스프린트 구조를 디자인 프로세스의 확산과 수렴 모델에 어떻게 통합할지 연구한다 [38].
|
|
|
|
## 📝 변경 이력 (Change history)
|
|
- 2026-05-22: Initial draft generated via Datacollector_MAC P-Reinforce engine based on provided source data. |