Part 2 — 운영의 기술

"Agile이라는 이름으로 프로젝트가 무너지는 이유"

Scrum · 번다운 · User Story · Planning Poker · WBS · Hybrid · 리스크

박수현 · SW마에스트로 특강 · 2026

🎨 이미지 프롬프트: "A 6-month project timeline rendered as a tightrope; a small dev team walks it with a balance pole labeled with sprint blocks, a safety net of documents below, dark editorial illustration, teal and purple, 16:9, no text"

"Agile이라는 이름으로 프로젝트가 무너지는 이유"

개발은 코드를 짜는 행위가 아니라
불확실성을 관리하는 행위다

이 시간이 끝나면

자각합니다

• ✅ "우리는 Agile이라 계획 없음" 이 왜 위험한지
• ✅ 프로젝트는 개발보다 운영에서 무너진다는 것
• ✅ 정부 장기 프로젝트엔 왜 Hybrid가 맞는지

직접 씁니다

• ✅ Scrum 역할·RACI 를 3인팀에 매핑
• ✅ User Story 1개 작성 + Planning Poker 산정
• ✅ 우리 프로젝트 WBS 1단계 분해

오늘 Part 2의 길

2-1. Agile 오해 박살내기

실제 프로젝트에서 더 크게 터지는 것

코드가 안 짜져서 망하는 팀보다, 이 3개를 관리 못 해서 망하는 팀이 훨씬 많습니다.

"Agile" 이라는 단어의 두 얼굴

Agile 선언문: "계획을 따르기보다 변화에 대응" — 계획을 버리라는 말이 아닙니다.

Agile 선언문 — 4가지 가치

왼쪽을 더 중시한다 — 오른쪽도 가치 있음(버리는 게 아님):

💬 "문서 < 작동SW" ≠ "문서 0" — 생존 문서는 예외 (2-6)

오른쪽도 가치 있다. 왼쪽을 더 중시할 뿐 — "문서 0"이 아니라 "문서를 위한 문서를 안 만든다".

"무계획"이 아니라 — 원래 이런 층이 있다

왼쪽이 장기 방향(안정), 오른쪽으로 갈수록 단기 실행(유연). 학생은 보통 맨 오른쪽 한 칸만 합니다.

2-2. Scrum — 제대로 알기

Scrum = 불확실성을 잘게 나눠 관리하는 경험적 틀

세 기둥 — 하나라도 빠지면 그냥 회의 많은 워터폴:

"회의 많이 하는 방법론"이 아니라 — 짧게 만들고 → 보고 → 고치는 루프입니다.

Scrum의 3가지 역할

PO는 방향, SM은 흐름, Dev는 실행 — 한 사람이 셋을 다 하면 충돌이 안 보입니다.

SW마에스트로 3인팀에 어떻게 매핑하나

풀타임 PO/SM은 사치. 핵심은 "그 책임을 가진 사람이 명시적으로 있다"는 것.

RACI — "그거 누가 하기로 했죠?" 를 없애는 한 글자

각 작업마다 사람을 네 글자로 못 박습니다 (예: "배포 자동화"):

3인팀에서도 작업마다 A는 반드시 1명. A가 둘이면 "서로 하겠지" → 아무도 안 함.

🎨 이미지 프롬프트: "A realistic RACI matrix grid. Columns = 3 team members 팀원A·팀원B·팀원C. Rows = real tasks 인증·API 서버·모델 추론·배포 자동화·발표 데모. Each cell holds a letter R/A/C/I; exactly one bold highlighted A per row (different person per row), other cells lighter. A clean color-coded legend: R 실행 · A 책임(1명) · C 자문 · I 통보. Flat business infographic, crisp grid lines, teal and purple accents, Korean labels clearly readable, full-width 16:9"

RACI — "그거 누가 하기로 했죠?" 를 없애는 한 글자

Scrum 이벤트 — 한 스프린트의 리듬

Review는 제품을 본다, Retrospective는 우리가 일한 방식을 본다 — 학생은 이 둘을 자주 섞습니다.

🎨 이미지 프롬프트: "A circular Sprint rhythm diagram for one 2-week sprint. Big loop, clockwise: Sprint Planning(계획) → into a Sprint box that contains a small repeating Daily Scrum(매일 15분 동기화) inner loop over development → Sprint Review(결과 시연) → Sprint Retrospective(일하는 방식 개선) → arrow back to next Sprint Planning. A small calendar marking 2주(Week1·Week2). Clean flat process infographic, labeled stages with icons, teal and purple, Korean labels clearly readable, full-width 16:9"

Scrum 이벤트 — 한 스프린트의 리듬

2주 스프린트 — 구체적으로 이렇게 굴러간다

6개월 ≈ 스프린트 12회. "언젠가"가 아니라 12번의 마감으로 쪼개집니다.

Scrum 산출물 — 3가지

💬 "거의 됨"은 Increment 아님 — 동작해야 한다 (→ 다음: DoD)

각 산출물엔 "다 됐다"의 기준이 필요합니다 → 다음 슬라이드.

🎨 이미지 프롬프트: "A detailed Scrum process diagram. Left: three labeled role figures — Product Owner(우선순위·백로그 책임), Scrum Master(장애물 제거·진행 코치), Developers(개발팀). Center flow: Product Backlog(우선순위 목록) → Sprint Planning(계획) → Sprint Backlog(이번 스프린트) → a 2-week Sprint cycle box containing a Daily Scrum(매일 15분) loop → Sprint Review(시연) and Retrospective(개선) → Increment(동작하는 결과물); a return arrow loops Increment/feedback back to Product Backlog. Clean flat process infographic, labeled boxes and arrows, teal and purple, Korean labels clearly readable, full-width 16:9"

Scrum 산출물 — 3가지

"거의 다 됐어요" 를 없애는 두 기준

DoD가 없으면 "90% 완료"가 영원히 90%. 합의된 체크리스트가 곧 품질 기준입니다.

Burndown Chart — 남은 일이 시간에 따라 줄어드는 그림

발표 1주 전에 보면 늦습니다. 매일 보면, 망하기 전에 보입니다.

🎨 이미지 프롬프트: "A clean burndown chart: x-axis '스프린트 일자', y-axis '남은 작업', a straight dashed ideal line going down to zero and a jagged actual line staying above it then dropping late, teal and purple, flat educational style, Korean labels readable, 16:9"

Burndown Chart — 남은 일이 시간에 따라 줄어드는 그림

Velocity — 우리 팀의 실제 속도

• 스프린트마다 완료한 스토리 포인트 합 = 우리 속도
• 다음 스프린트에 얼마 담을지 예측하는 데 씀
• 팀 내부 예측용 — 팀 간 비교·평가 도구로 쓰면 조작됨

"우리는 스프린트당 20점쯤" 을 알면, 6개월 백로그가 현실적으로 끝나는지 계산됩니다.

회고(Retrospective) — 감정 토로가 아니라 개선 1개

💬 사람 탓 ❌ 시스템 탓 ⭕ · Try엔 담당(A) 1명 + 다음 회고에 점검

규칙: 사람 탓 ❌, 시스템 탓 ⭕ · Try는 실행 가능한 1개(A 담당자 지정). 안 바뀌면 회고가 아님.

왜 Scrum을 도입했는데 망하나 — 좀비 스크럼

의식(ceremony)만 흉내 내고 점검·적응이 없으면 그건 Scrum의 시체입니다.

Scrum vs Kanban — 무엇을 언제

학생은 "Trello 보드 = 애자일"로 착각합니다. SW마에스트로는 평가·발표 리듬이 있어 Scrum 골격 + Kanban 보드 가 현실적.

2-3. 추정과 일정 — 보이게 만들기

"이거 3일이면 돼요" 가 항상 틀리는 이유

• 사람은 절대 시간(며칠) 추정에 약함 — 낙관 편향
• 잘하는 것: 상대 크기 비교 ("A가 B보다 2배쯤 큼")
• 그래서 Story Point — 시간이 아니라 상대 규모·복잡도·불확실성

시간으로 추정하면 매번 2배 틀리고, 상대 크기로 추정하면 팀 평균 속도(Velocity)로 보정됩니다.

User Story — 무엇을 만들지 사용자 언어로

As a 〈누가〉, I want 〈무엇을〉, so that 〈왜〉.

예: "바쁜 조교로서, 회의록을 자동 요약받고 싶다, 결정사항을 5분 안에 공유하려고."

"로그인 기능 구현"은 작업이지 스토리가 아닙니다. 스토리엔 누가·왜가 들어갑니다.

🎨 이미지 프롬프트: "A User Story anatomy illustration. A big story card showing the template 'As a 〈누가〉 / I want 〈무엇을〉 / so that 〈왜〉' with a real filled example '바쁜 조교로서 / 회의록 자동 요약을 원한다 / 결정사항을 5분 안에 공유하려고'. Around the card, six small badges spelling INVEST(독립적·협상가능·가치있음·추정가능·작음·테스트가능), and a small acceptance-criteria checklist sticky note. Clean flat agile infographic, teal and purple, Korean labels clearly readable, full-width 16:9"

User Story — 무엇을 만들지 사용자 언어로

Planning Poker — 재미있게, 그러나 정직하게

숫자를 맞추는 게임이 아니라 — 숨은 가정과 리스크를 드러내는 대화 장치입니다.

🎨 이미지 프롬프트: "A detailed Planning Poker scene. A team of 4 around a table each revealing a Fibonacci card simultaneously (1, 3, 5, 8, 13), the spread highlighted — one person shows 3, another shows 8 — with speech bubbles '왜 8?'/'왜 3?' prompting discussion, then a re-vote arrow toward consensus. A fanned deck 1·2·3·5·8·13·21 in the corner. Clean flat agile infographic, friendly, teal and purple, Korean labels clearly readable, full-width 16:9"

Planning Poker — 재미있게, 그러나 정직하게

WBS — 큰 덩어리를 쪼개는 기술

"AI 웹서비스 만들기"는 한 덩어리가 아닙니다:

학생은 D(모델)만 봅니다. 실제 일은 A·B·C·F·G·H가 훨씬 많습니다.

빙산 — 모델은 물 위, 운영은 물 아래

발표에서 무너지는 지점은 거의 항상 물 아래입니다.

Gantt 차트 — "언제 무엇을, 무엇 다음에"

핵심은 막대가 아니라 의존성·병렬·병목·Critical Path(가장 긴 사슬)입니다.

현실 사례 — "백엔드 API가 안 나와서…"

프론트 2명이 2주를 대기했다. 코드가 어려워서가 아니라, 선행 작업(API) 이 안 끝나서.

2-4. 왜 SW마에스트로는 Hybrid인가

상위는 Waterfall, 하위 실행은 Agile

기업도 이렇게 합니다. 정부 사업은 더더욱 — 평가·산출물·일정이 계약이기 때문.

정부 장기 프로젝트라서 — 반드시 있어야 하는 것

이게 없으면 멘토 피드백을 반영할 구조도, 실패 원인을 분석할 기록도 없습니다.

멘토·심사위원은 리스크가 아니라 자원이다

이해관계자 관리 = "기대를 맞추는" 일. 멘토가 무엇으로 우리를 평가하는지 모르면 6개월을 헛짚습니다.

2-5. 리스크 · 기술 부채 · PMP 관점

프로젝트 관리가 보는 6가지

개발자가 가장 많이 놓치는 건 마지막 줄 — 리스크·커뮤니케이션·이해관계자입니다.

리스크는 닥쳐서가 아니라 미리 — 한 장이면 충분

각 리스크를 한 줄로: 무엇이 / 발생 가능성 / 영향 / 그러면 우리는

• 핵심 팀원 이탈 — 가능성 中 · 영향 大 → 지식 공유·문서·페어
• 모델 정확도 미달 — 가능성 中 · 영향 大 → 베이스라인 먼저, 대체안 B
• 발표 데모 장애 — 가능성 高 · 영향 大 → 녹화 백업·로컬 폴백
• API 일정 지연 — 가능성 高 · 영향 中 → Mock 인터페이스 선합의

가능성 × 영향이 큰 것부터. "발표 데모 장애"는 거의 모든 팀의 1순위 리스크입니다.

기술 부채 — 빌리는 건 자유, 이자는 복리

💬 부채가 악이 아니라 — 갚을 계획 없이 쌓는 게 악. 백로그에 부채도 올려라

부채 자체가 악이 아닙니다. 갚을 계획 없이 쌓는 게 악. 백로그에 부채 항목도 올리세요.

2-6. 문서화 = 귀찮은 게 아니라 생존 기술

문서 없이 가다가 — 3개월 후의 대화

3인팀은 한 명만 이탈해도 머릿속 지식이 통째로 증발합니다. 문서 = 팀의 백업.

많이 말고 — 이것만은

도구는 Notion · GitHub Project · Jira/Trello 무엇이든. 핵심은 형식이 아니라 결정이 남는가.

2-7. 현실적인 3인팀 운영

3인팀에서 진짜 터지는 것 — 그리고 대응

"완성도 > 기능 수" — 안 되는 기능 5개보다 끝까지 되는 1개가 발표에서 이깁니다.

팀은 기술이 아니라 사람에서 깨진다

대응: 초반 팀 합의서(역할·기여량·소통 규칙) · 작업마다 RACI의 A 1명 · 갈등은 작을 때 회고에서 · 안 풀리면 멘토를 중재자로.

Part 2 정리 — 불확실성을 관리하는 기술

• ✅ Agile ≠ 무계획 — 변화 대응 시스템 (Vision→Roadmap→Sprint)
• ✅ Scrum 제대로 — 역할·RACI·이벤트·번다운·DoD·회고, 좀비 스크럼 경계
• ✅ 추정은 상대로(User Story·Planning Poker) · WBS·Gantt로 일정을 보이게
• ✅ 정부 장기 프로젝트 = Hybrid (상위 WF + 하위 Agile)
• ✅ 리스크·기술부채·문서·역할 = 3인팀 생존 도구

다음 — Part 3: 잘 만들고 잘 굴려도 — 아무도 안 쓰면 그건 기술이 아니라 취미입니다.