2nd/10_Wiki/Topics/Topic_Agent/Agile Development.md

---
id: agile-development
title: "Agile Development"
category: "10_Wiki/Topics"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["애자일 개발", "Iterative Development"]
duplicate_of: ""
source_trust_level: "B"
confidence_score: 0.85
created_at: 2026-06-12
updated_at: 2026-06-12
review_reason: ""
merge_history: []
tags: ["research", "Assumption Validation Loop", "Agile"]
raw_sources: ["NotebookLM Synthesis"]
applied_in: ["Jira-linked Strategic Roadmaps", "Rise8 Core Practices", "Ontik Technology Agile Process"]
github_commit: ""
---

# [[Agile Development]]

## 🎯 한 줄 통찰 (One-line insight)
현대적 애자일 개발은 단순히 빠른 기능 출시가 아니라, 배포와 병행되는 **지속적 발견(Continuous Discovery)** 프로세스를 통해 가설을 검증하고 불확실성을 관리하는 학습 기반의 소프트웨어 공학 체계이다 [1-3].

## 🧠 핵심 개념 (Core concepts)
- **지속적 발견 (Continuous Discovery):** 발견(Discovery)을 프로젝트 초기 단계가 아닌, 개발(Delivery)과 나란히 매주 진행되는 상시 프로세스로 취급하는 사고방식이다 [1, 4].
- **이중 트랙 애자일 (Dual-Track Agile):** 가설을 검증하는 '발견 트랙'과 실제 제품을 구축하는 '배포 트랙'을 동시에 운영하여 학습 속도와 실행 속도를 최적화한다 [5, 6].
- **결과 중심 로드맵 (Outcome-driven Roadmaps):** 단순히 기능(Output)을 나열하는 것이 아니라, 사용자 행동 변화나 비즈니스 가치와 같은 측정 가능한 결과(Outcome)를 목표로 작업을 우선순위화한다 [4, 7].
- **가설 기반 스프린트 (Hypothesis-based Sprints):** 모든 기능을 하나의 가설로 취급하고, 스프린트 내에 검증 작업을 포함하여 데이터에 기반한 의사결정을 내린다 [4, 8].

## 🧩 추출된 패턴 (Extracted patterns)
- **2주 단위 발견 케이던스 (Bi-weekly Discovery Cadence):** 다기능 팀이 2주마다 최소 2시간을 할당하여 가설 맵을 작성하고 실험 데이터를 검토하는 정기적 리듬을 구축한다 [9].
- **스프린트 의사결정 통합:** 스프린트 계획 시 검증 과업을 포함하고, 리뷰 시 기능 데모와 함께 검증 결과를 발표하며, 회고 시 잘못된 가설이 무엇이었는지 논의한다 [8].
- **가설의 데이터화:** 가설을 "우리는 [사용자]가 [이유] 때문에 [행동]할 것이라고 믿는다"는 형식의 반증 가능한 문장으로 작성하고, 사전에 성공/실패 기준(Kill criteria)을 설정한다 [9-11].

## 📖 세부 내용 (Details)
애자일 개발은 전통적인 폭포수 모델의 한계를 극복하기 위해 진화해 왔으며, 특히 **[[Assumption Validation Loop]]**와 결합될 때 그 효율성이 극대화된다 [2, 12].

- **배포와 발견의 결합:** 애자일 팀은 사용자 연구와 가설 검증을 제품 개발 수명 주기 전반에 걸쳐 통합한다 [2]. 이는 로드맵이 내부 의견이 아닌 실제 사용자 문제에 기반하도록 유지하는 역할을 한다 [4, 13].
- **반복적 학습 루프 (Build-Measure-Learn):** 에릭 리스의 린 스타트업 방법론을 애자일에 접목하여, 가장 위험한 가설을 테스트할 수 있는 최소한의 것(MVP)을 구축하고 데이터를 통해 다음 행동(피벗 또는 유지)을 결정한다 [14-16].
- **운영상의 베스트 프랙티스:**
    - **스프린트 기반 QA:** 테스트를 별도 단계가 아닌 매 스프린트에 통합하여 결함 유출률을 낮춘다 [17].
    - **기능 계측(Instrumentation):** 새로운 기능을 출시하기 전 로그 및 분석 도구를 미리 배치하여 사용자 행동을 즉시 측정할 수 있게 한다 [17].
    - **자동화된 배포 파이프라인:** 수동 배포의 가변성을 제거하고 실험 속도를 높이기 위해 CI/CD를 조기에 도입한다 [17, 18].
- **조직 문화의 역할:** 실패를 처벌하지 않고 가설 검증의 과정으로 보는 심리적 안전감이 확보된 애자일 문화는 실험 속도(Experiment Velocity)를 높이고 비즈니스 모델의 적응력을 강화한다 [19-21].

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- **MVP에 대한 오해:** 많은 팀이 MVP를 최종 제품의 '거친 초안'이나 '기능을 줄인 버전'으로 오해하여 가설 검증과 무관한 기능을 포함시키는 오류를 범한다 [22, 23]. 최신 지견은 MVP를 제품이 아닌 **'학습 도구(Learning tool)'**로 정의할 것을 권고한다 [24-26].
- **속도 vs 구조:** 단순히 빨리 만드는 것이 애자일이 아니다. 구조화된 지표와 증거 없이 빠르게만 움직이는 것은 "비싼 혼돈(Expensive chaos)"일 뿐이며, 검증된 학습이 속도보다 우선되어야 한다 [27-29].

## 🛠️ 적용 사례 (Applied in summary)
- **Jira 통합 로드맵:** Tempo의 전략적 로드맵 도구는 Jira와 직접 통합되어 로드맵이 정적인 문서가 아닌 실제 작업 진행 상황과 연결된 살아있는 상태를 유지하도록 한다 [30].
- **Rise8의 핵심 관행:** 'Balanced Teams'와 'Dual-Track Development'를 통해 보안 및 규정 준수 리스크를 일상적인 개발 습관으로 전환하여 cATO(지속적 운영 승인)를 달성한다 [6, 31].
- **Ontik Technology:** 애자일 프로세스 내에서 저충실도 및 고충실도 MVP 접근 방식을 모두 지원하여 팀이 검증 단계에 맞는 적절한 피델리티를 선택할 수 있도록 가이드한다 [32, 33].

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
- **중복 검사 결과:** 신규 생성 (New discovery)


## 🔗 관련 문서 링크 (Related document links)

### 상위/유사 개념

#### [전략적 프레임워크]
- [[Assumption Validation Loop]]
  - 연결 이유: 애자일 개발의 의사결정을 지원하는 과학적 방법론적 기반임 [34, 35].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 애자일 스프린트가 무엇을 위해(학습) 돌아가야 하는지에 대한 목적성.

#### [실행 모델]
- [[Minimum Viable Product]]
  - 연결 이유: 애자일 반복 주기 내에서 가설을 검증하기 위해 사용하는 핵심 학습 매개체임 [36, 37].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: '최소한'의 구축으로 '최대한'의 학습을 얻는 방법.

#### [의사결정 체계]
- [[Pivot or Persevere]]
  - 연결 이유: 스프린트 또는 실험 주기가 끝날 때 데이터에 기반하여 내리는 전략적 선택지임 [38-40].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 실패를 자산화하고 방향을 전환하는 타이밍 포착.

### 심층 후속 질문 (Deeper Research Questions)
- 애자일 스프린트 내에서 '발견' 과업과 '배포' 과업의 리소스 배분 최적 비율은 무엇인가? [5, 41]
- 대규모 조직(Enterprise)에서 이중 트랙 애자일을 운영할 때 발생하는 거버넌스 충돌을 어떻게 해결할 것인가? [5, 42]
- AI 도구(LLM 등)를 활용하여 애자일 반복 주기의 'Build' 단계를 얼마나 압축할 수 있으며, 이것이 검증의 질에 미치는 영향은 무엇인가? [43, 44]
- '결과 중심 지표'가 팀의 동기부여와 성과 측정에 기능 위주 지표보다 긍정적인 영향을 미치는 심리적 기제는 무엇인가? [27, 45]
- 애자일 회고(Retrospective)에서 가설의 오류를 인정하는 문화적 토대를 구축하기 위한 리더십의 구체적인 행동 양식은? [46, 47]

### 실무 적용 맥락 (Practical Application Contexts)
- **Implementation:** 백로그 관리 시 모든 티켓을 사용자 스토리(User Story)뿐만 아니라 가설 문장으로 재정의하여 관리한다 [8, 48].
- **System Design:** 기능 플래그(Feature Flags)를 설계에 포함하여 점진적 배포와 실시간 A/B 테스트가 가능한 아키텍처를 구축한다 [4, 49, 50].
- **Operation / Maintenance:** 가용성이나 보안 같은 비기능적 요구사항(NFR)도 애자일 검증 루프에 포함하여 운영 리스크를 상시 관리한다 [31, 51].
- **Learning Path:** 주니어나 신규 팀원은 기능을 구현하는 기술뿐만 아니라 'Mom Test'와 같은 인터뷰 기술과 가설 맵 작성법을 먼저 익혀야 한다 [9, 52].

### 인접 주변 주제
- [[Design Thinking]]
  - 확장 방향: 사용자 공감과 문제 정의 단계에서 애자일의 '발견' 트랙에 깊은 통찰을 제공함 [53-56].
- [[Innovation Accounting]]
  - 확장 방향: 매출이 발생하기 전 단계에서 애자일 팀의 진척도를 '검증된 학습량'으로 측정하는 체계 제공 [57, 58].


## 📝 변경 이력 (Change history)
- 2026-06-12: Initial draft generated via Datacollector_MAC P-Reinforce engine.