루프와
운영
이 수업의 기본 단위는 루프입니다. 가설을 세우고, 만들고, 배포하고, 측정하고, 배우는 한 바퀴를 말합니다. 마일스톤과 평가는 모두 이 루프를 중심으로 설계되어 있습니다. 학기 일정을 직접 계산해 보는 스프린트 플래너가 포함되어 있습니다.
두 팀의 차이는 피드백 횟수에서 나왔습니다
AI 도구가 빌드 시간을 줄인 지금, 병목은 만드는 속도가 아니라 배우는 속도입니다.
두 팀의 한 학기
같은 학기에 캡스톤을 수강한, 실력이 비슷한 두 팀이 있었습니다. A팀은 매주 보고 때마다 "완성되면 보여드리겠다"고 답했습니다. 코드는 늘었고 화면도 다듬어졌지만, 그것을 본 사람은 팀원 네 명뿐이었습니다. 첫 배포는 최종보고서를 제출하던 12주차였습니다.
B팀은 4주차에 완성도가 낮은 첫 버전을 배포했습니다. 기능은 하나뿐이었고, 처음 사용해 본 열 명 중 일곱 명이 30초 안에 이탈했으며 남긴 반응도 대부분 부정적이었습니다. 팀은 그 주에 핵심 화면을 고쳤고, 다음 배포에서 다시 부정적인 피드백을 받았고, 다시 고쳤습니다.
기말 발표에서 두 팀의 차이는 분명했습니다. B팀의 서비스는 실제 사용자의 행동 데이터로 설명되었고, A팀의 서비스는 팀의 의도로 설명되었습니다. 차이를 만든 것은 재능이나 투입 시간이 아니라 피드백을 받은 횟수였습니다. A팀은 학기 동안 외부 검증을 한 번 받았고, B팀은 예닐곱 번 받았습니다. AI 도구가 만드는 데 걸리는 시간을 몇 주에서 며칠로 줄인 지금, 성과를 가르는 변수는 만드는 속도가 아니라 배우는 속도입니다. 이 장은 그 배우는 속도를 학기 운영에 반영하는 방법을 다룹니다.
두 팀의 이야기는 특정 팀의 실화가 아니라 매 학기 반복되는 패턴을 요약한 것입니다. 이 패턴은 학생 프로젝트에만 나타나는 것도 아닙니다. 스타트업 실패 원인 조사에서 상위에 꾸준히 오르는 항목은 기술 부족이 아니라 "시장이 원하지 않는 것을 만들었다"입니다. 원하지 않는다는 사실을 일찍 알수록 방향을 바꿀 시간이 남고, 늦게 알수록 매몰비용이 커집니다. 배포가 늦어질수록 손해가 커지는 이유는 품질이 아니라 정보가 도착하는 시점 때문입니다.
"완성도 낮은 버전을 내놓으면 첫인상을 망친다"는 걱정은 자연스럽지만, 초기 사용자 열 명은 시장 전체가 아닙니다. 초기 사용자에게 잃을 수 있는 평판의 크기와 그들에게서 얻는 정보의 가치를 비교하면, 학기 단위 프로젝트에서는 후자가 훨씬 큽니다. 링크드인 창업자 리드 호프먼의 "첫 버전이 부끄럽지 않다면 너무 늦게 출시한 것이다"라는 말이 자주 인용되는 것도 같은 이유입니다.
루프의 구성
한 바퀴는 다섯 칸으로 이루어지고, 두 가지 규칙이 적용됩니다 — 루프 하나에 핵심 가설은 하나, 길이는 1~2주입니다.
한 바퀴의 다섯 칸
루프는 "만들기"가 아니라 "검증하기"의 단위입니다. 다섯 칸 중 빌드는 한 칸에 불과하고, 나머지 네 칸은 모두 가설과 정보에 관한 것입니다.
| 칸 | 하는 일 | 산출물 | 소요 |
|---|---|---|---|
| ① 가설 | 이번 바퀴에서 검증할 믿음을 한 문장으로 적습니다 — "누가, 어떤 상황에서, 이것을 쓸 것이다" | 가설 문장 1개 + 판정 기준(무엇이 관측되면 참인지) | 반나절 |
| ② 빌드 | 그 가설 하나를 검증하는 데 필요한 최소한만 AI 도구로 만듭니다 | 동작하는 버전(기능 1~2개) | 2~4일 |
| ③ 배포 | 팀 바깥의 실제 사용자가 접근할 수 있는 곳에 올립니다 | 접속 가능한 URL | 반나절 |
| ④ 측정 | 사용자의 행동과 반응을 기록합니다 — 방문, 이탈, 재방문, 직접 관찰과 인터뷰 | 수치 몇 개 + 관찰 메모 | 2~4일 |
| ⑤ 학습 | 가설의 판정을 내리고, 사업 모델 캔버스를 수정하고, 다음 가설을 정합니다 | 판정(참/거짓/불명) + 캔버스 수정 + 다음 가설 | 반나절 |
이 다섯 칸은 에릭 리스가 The Lean Startup(2011)에서 정식화한 Build–Measure–Learn 사이클을 확장한 것입니다. 리스의 세 칸 앞뒤에 "무엇을 검증하는가"(가설)와 "누구 앞에 내놓는가"(배포)를 별도의 칸으로 명시했는데, 학생 프로젝트에서 가장 자주 생략되는 것이 바로 이 두 칸이기 때문입니다. 가설 없는 빌드는 검증할 것이 없고, 배포 없는 측정은 잴 것이 없습니다.
왜 "완성한 뒤 공개"가 아니라 루프인가를 생각해 볼 필요가 있습니다. 계획의 정확도는 가진 정보량에 비례하는데, 이 프로젝트에서 가장 중요한 정보 — 사용자가 실제로 무엇을 하는가 — 는 사용자와의 접촉에서만 나옵니다. 루프를 돌지 않는 팀은 학기 내내 정보량이 0인 상태에서 계획을 세우는 셈이고, 그 계획이 정교할수록 틀린 방향으로 정교해질 위험이 있습니다. 루프는 계획을 버리는 것이 아니라, 계획을 갱신할 정보가 정기적으로 도착하도록 일정을 설계하는 것입니다.
소요 시간의 배분도 눈여겨볼 만합니다. 다섯 칸을 합치면 1~2주인데, 그중 빌드는 절반 이하입니다. AI 도구가 보급되기 전에는 빌드가 바퀴 전체를 차지했기 때문에 학기 안에 한 바퀴 돌기도 어려웠습니다. 빌드가 며칠로 줄어든 지금은 나머지 칸 — 가설을 명확히 적는 것, 사용자를 실제로 데려오는 것, 관찰한 것을 정직하게 판정하는 것 — 이 실력의 차이를 만듭니다. 도구가 상향 평준화한 것은 빌드이지 학습이 아닙니다.
출처 Ries, The Lean Startup, Crown Business, 2011, theleanstartup.com
가설은 하나, 길이는 1~2주
루프가 제대로 돌아가려면 두 가지 제약이 필요합니다. 이 제약을 지키지 않으면 루프는 다시 "한 학기짜리 프로젝트"로 돌아갑니다.
두 규칙의 공통 목적은 실패의 비용을 낮추는 것입니다. 가설 하나짜리 1~2주 루프가 틀리면 1~2주를 잃지만, 가설 열 개짜리 한 학기 프로젝트가 틀리면 학기를 잃습니다.
규칙 1은 실험 설계의 언어로 말하면 변수 통제입니다. 여러 변경을 한 배포에 섞으면 어떤 관측이 나와도 해석이 어려워집니다. 다만 "핵심 가설 1개"가 "변경 1건"을 뜻하지는 않습니다. 판정하려는 믿음이 하나라면, 그 믿음을 검증하는 데 필요한 여러 변경을 한 바퀴에 실어도 됩니다.
규칙 2는 심리적 장치이기도 합니다. 마감이 2주 뒤로 고정되면 "이것까지만 더 다듬고"가 구조적으로 어려워집니다. 제프 서덜랜드가 Scrum(2014)에서 스프린트를 고정 길이로 정의한 이유도 같습니다 — 기한이 범위를 결정하게 만들면, 범위가 기한을 늘리는 문제가 차단됩니다.
출처 Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time, Crown Business, 2014 · Maurya, Running Lean (2nd ed.), O'Reilly, 2012.
마일스톤 × 루프
보고서를 쓰기 위해 루프를 멈추는 것이 아니라, 돌고 있는 루프의 기록을 정리해 내는 것이 보고서입니다.
무엇을 언제 내는가
제출 일정은 고정이고, 루프는 그 사이에서 진행됩니다. 각 제출물은 직전 루프가 남긴 기록을 담습니다. 정확한 날짜와 대면·비대면 방식은 각 주차 eclass 공지가 기준입니다.
| 주차 | 제출물 | 해당 루프 | 이 제출물이 담아야 할 것 |
|---|---|---|---|
| 매주 | 진행사항 보고 + Q&A 제출 | 진행 중인 루프 | 이번 주 루프가 어디까지 진행되었는지 — 검증 중인 가설, 한 일, 배운 것, 막힌 것. 질문은 Q&A로 함께 제출합니다 |
| 2주차 | 온라인 주제 발표 | 루프 0 (발견) | 어떤 문제를 누구의 문제로 보았고 첫 가설이 무엇인지 — "무엇을 만들 것인가"가 아니라 "무엇을 검증할 것인가" |
| 4주차 | 1차 보고서 | 루프 1 기록 | 시장·고객 분석, 사업 모델 캔버스 v1, 첫 프로토타입 계획과 진행 |
| 8주차 | 2차 보고서 (중간) | 루프 2 기록 | 배포된 MVP와 첫 피드백 결과, 캔버스 갱신. 1차 보고서 평가의견에 대한 답변을 반드시 첨부합니다 |
| 9주차 | 목업 발표 (데모 시연) | 루프 2~3 | 동작하는 서비스의 시연 — 이 수업에서는 실제 배포된 서비스의 데모를 권장합니다 |
| 12주차 | 최종보고서 | 루프 3~4 기록 | 진행한 루프 전체의 기록과 사업성 분석. 팀원 역할 분담표 제출이 의무입니다 |
| 기말 | 최종 발표 | 루프 4 마무리 | 발표자와 Q&A 대응자가 랜덤으로 선정됩니다 — 전원이 전체를 설명할 수 있어야 합니다 |
보고서는 루프의 기록입니다. 보고서 주간이 되면 루프를 멈추고 문서 작업으로 전환하는 팀이 있는데, 순서가 뒤집힌 것입니다. 매주 루프를 돌며 가설·판정·캔버스 수정을 기록해 온 팀에게 보고서는 그 기록을 편집하는 하루 정도의 일이고, 기록 없이 지내 온 팀에게만 보고서가 일주일짜리 작문이 됩니다.
일정표에서 주의 깊게 볼 것은 제출물 사이의 간격입니다. 4주차 1차 보고서와 8주차 2차 보고서 사이는 4주 — 루프 2 하나가 통째로 들어가는 길이입니다. 그런데 2차 보고서는 "배포된 MVP와 첫 피드백"을 요구합니다. 즉 8주차까지 배포가 없으면 2차 보고서에 쓸 내용 자체가 없습니다. 마일스톤이 루프를 전제로 설계되어 있는 것입니다.
2차 보고서에 1차 평가의견 답변을 첨부하는 규정도 같은 설계의 일부입니다. 평가의견은 채점 결과가 아니라 다음 루프의 입력이며, 답변 첨부 의무는 그 입력이 실제로 사용되었는지 확인하는 장치입니다. 지적받은 항목을 어떻게 반영했고, 반영하지 않았다면 어떤 판단에서 그렇게 했는지를 쓰면 됩니다. 반영하지 않은 것 자체는 감점 사유가 아니지만, 검토하지 않은 것은 §3의 첫 번째 평가 차원에서 드러나게 됩니다.
목업 발표: 그림보다 배포 URL을 권장합니다
수업 규정상의 명칭은 "목업 발표(데모 시연)"입니다. 다만 AI 도구로 배포 비용이 크게 낮아진 지금, 이 수업에서는 그림 목업 대신 실제 배포된 서비스의 URL 데모를 권장합니다.
둘의 차이는 완성도가 아니라 증거의 유무입니다. 그림 목업은 팀의 의도를 보여 주고, 배포된 서비스는 사용자의 행동을 보여 줍니다. 9주차는 학기의 3분의 2 지점입니다. 이 시점에 보여 줄 사용자 행동이 없다면, 남은 기간에 만들 시간은 있어도 검증할 시간이 부족해집니다.
목업이라는 관행 자체는 배포 비용이 높던 시기의 합리적인 타협이었습니다. 실제로 만들어 보이는 데 몇 달이 걸린다면, 그림으로 먼저 합의를 만드는 것이 맞습니다. 지금은 전제가 달라졌습니다. 프론트엔드 프로토타입을 만들어 무료 호스팅에 올리는 시간이 그림 목업을 정성 들여 그리는 시간과 비슷하거나 더 짧습니다. 같은 노력으로 "의도의 그림"과 "행동의 데이터" 중 하나를 고를 수 있다면 후자를 고르는 것이 합리적입니다.
발표의 성격도 달라집니다. 실배포 데모의 발표는 "저희 서비스를 소개합니다"가 아니라 "저희 가설이 어디까지 판정되었는지 보고합니다"가 됩니다. 듣는 입장에서 전자는 광고에 가깝고 후자는 근거가 있는 보고입니다. 심사자가 던질 수 있는 "그건 써 본 사람이 그렇다고 하던가요?"라는 질문에 답할 수 있는 팀과 없는 팀이 여기서 갈립니다.
평가의 구조
절대 완성도를 재는 축은 없습니다. 평가는 직전 대비 개선과 스스로 세운 목표 대비 달성을 잽니다 — 그래서 목표를 부풀리면 오히려 손해입니다.
무엇이 점수가 되는가
평가는 네 개의 차원으로 이루어집니다. 배점 확정본은 학기 초 eclass 공지가 기준이며, 여기서는 각 차원이 무엇을 재는지를 봅니다.
| 차원 | 재는 것 | 루프 관점의 의미 |
|---|---|---|
| ① 평가의견 반영·개선도 | 직전 보고서에서 받은 평가의견을 다음 산출물에 얼마나 반영·개선했는지 | 피드백이 루프의 입력으로 사용되었는지 — 학습 칸이 실제로 돌았는지 |
| ② 계획 대비 성과 달성도 | 스스로 제출한 계획에 견주어 실제로 어디까지 왔는지 | 루프가 예고한 대로 진행되었는지 — 계획의 신뢰성 |
| ③ 목표 달성율 대비 실달성 수준 | 세운 목표를 분모로, 실제 달성을 분자로 놓은 비율 | 가설을 감당 가능한 크기로 세웠는지 — 목표 설정 능력 자체가 평가됩니다 |
| ④ 팀원 간 협력 + 팀 상호 발표 평가 | 팀 내부의 협력, 그리고 발표에 대한 팀 간 투표 — 자기 팀에는 투표할 수 없고 총 3표를 행사합니다 | 루프가 한두 명이 아니라 팀 전체의 작업이었는지 |
하나. 목표 부풀리기는 손해입니다. ③의 분모는 팀이 스스로 적어 낸 목표입니다. 발표를 크게 보이게 하려고 목표를 부풀리면 분모가 커져서, 같은 실달성으로도 달성률이 낮아집니다. 이 구조에서 유리한 선택은 감당 가능한 목표를 정직하게 적고 그것을 달성하는 것입니다.
둘. 배포 없는 완성은 검증 0회와 같습니다. ①은 피드백의 반영을 재는데, 배포하지 않은 팀에게는 반영할 사용자 피드백 자체가 없습니다. 루프 중심 수업에서 "완성도 높은 미공개 작업물"은 평가 구조상 "아직 아무것도 검증하지 않은 작업물"과 같은 위치에 놓입니다.
③이 목표 설정 능력 자체를 평가한다는 점은 실무의 OKR 운영과 닿아 있습니다. 목표를 낮게 잡아 100%를 채우는 팀과 무리하게 잡아 30%에 그치는 팀 모두 목표 설정에 실패한 것이며, 잘 세운 목표는 "노력하면 닿는 지점보다 약간 위"입니다. 학기 초에는 자기 팀의 속도를 모르므로 첫 목표는 틀리는 것이 정상이고, 루프를 한두 바퀴 돌고 나면 팀의 실제 속도를 알게 되어 목표의 정확도가 올라갑니다. 이것 역시 일찍 루프를 돌린 팀이 유리해지는 지점입니다.
④의 상호 투표는 발표를 듣는 태도를 바꾸는 장치이기도 합니다. 자기 팀에 투표할 수 없고 3표를 행사해야 하므로, 다른 팀의 발표를 비교하며 듣게 됩니다. 다른 팀의 루프에서 자기 팀이 가져올 것을 발견하는 것이 이 시간의 실질적인 이득입니다.
"마지막에 몰아서 잘 만들면 된다"는 전략의 문제
"중간에는 적당히 넘기고, 마지막 몇 주에 몰아서 완성도를 끌어올리면 된다. 결국 최종 결과물이 좋으면 되는 것 아닌가." — 이 전략은 이 수업의 평가 구조에서 세 가지 방향으로 동시에 불리해집니다.
첫째, 개선도를 잴 수 없습니다. ①은 직전 산출물 대비 개선을 재는데, 중간 산출물이 부실하면 개선의 과정 자체가 기록에 없습니다. 마지막 결과물이 좋아도 그것이 개선인지 우연인지 보여 줄 이전 지점이 없습니다.
둘째, 답변할 내용이 없습니다. 2차 보고서에는 1차 평가의견 답변 첨부가 의무입니다. 1차가 부실하면 받는 의견도 "전반적으로 미흡"에 그치고, 답변에 쓸 구체적인 반영 내역이 생기지 않습니다.
셋째, 몰아서 만든 완성물은 검증되지 않은 완성물입니다. 마지막 몇 주에는 배포–측정–학습을 돌릴 시간이 없으므로, 그 완성도는 사용자 접촉 0회의 완성도입니다. 방향이 틀렸다면 가장 공들인 버전이 가장 틀린 버전이 될 위험이 있습니다.
요약하면, 이 평가 구조에서 몰아치기는 태도의 문제가 아니라 기대값의 문제입니다. 같은 총노력을 학기 후반에 몰아넣는 방식과 매주 루프에 나누어 넣는 방식 중, 네 개의 평가 차원 모두에서 후자의 기대 점수가 높습니다.
팀 운영
AI 도구 시대의 역할 분담은 개발자·비개발자의 분업이 아니라, 루프의 칸을 바퀴마다 돌아가며 맡는 순환입니다.
직군이 아니라 칸을 맡습니다
"개발할 줄 아는 사람이 만들고, 나머지가 발표와 문서를 맡는" 분업은 AI 도구 이전의 방식입니다. 빌드의 진입 장벽이 낮아진 지금은 전원이 모든 칸을 경험할 수 있고, 평가 구조(전원 랜덤 발표, 역할 분담표 의무)도 그것을 전제로 합니다.
핵심은 이 담당을 바퀴마다 순환시키는 것입니다. 루프 2에서 빌드를 맡았던 사람이 루프 3에서는 피드백을 맡습니다. 순환의 비용은 인수인계이고, 이득은 전원이 전체 루프를 설명할 수 있게 되는 것입니다 — 그리고 그것이 기말 발표의 랜덤 선정이 확인하려는 능력입니다.
- 전원 발표 준비. 기말 발표는 발표자와 Q&A 대응자가 랜덤으로 선정됩니다. 리허설에서 매번 발표자를 바꾸고 질문 대응도 돌아가며 맡아 두면, 이 규칙이 부담이 되지 않습니다.
- 회의 기록이 곧 보고 재료. 주간 회의에서 가설·진행·판정·다음 계획을 같은 틀로 적어 두면, 매주 진행사항 보고는 그 기록을 옮기는 일이 되고 보고서는 그 기록을 편집하는 일이 됩니다. 기록을 따로 만드는 팀은 같은 일을 두 번 하게 됩니다.
- 갈등은 조기에 상담. 무임승차나 기여 불균형은 시간이 해결해 주지 않고, 최종보고서의 역할 분담표에서 결국 드러납니다. 팀 안에서 두 번 이야기해도 달라지지 않으면, 학기 말이 아니라 그 시점에 담당 교수와 상담하는 것이 좋습니다.
순환제에 대한 흔한 반론은 효율입니다 — "제일 잘하는 사람이 계속 맡는 것이 빠르지 않은가". 한 바퀴만 보면 맞는 말입니다. 그러나 학기 전체로 보면 고정 분담은 단일 실패점을 만듭니다. 빌드 담당 한 명이 시험 기간이나 개인 사정으로 빠지는 순간 루프 전체가 멈춥니다. 순환은 속도를 조금 내주고 회복력을 얻는 거래이며, 넉 달짜리 프로젝트에서는 대부분 남는 거래입니다.
회의 기록의 틀은 간단해도 됩니다. "이번 주 가설 / 한 일 / 관찰한 것 / 판정 / 다음 주"의 다섯 줄이면 충분하고, 중요한 것은 매주 같은 틀로 쌓이는 것입니다. 학기 말에 이 기록이 12주치 쌓여 있으면, 최종보고서의 루프 기록 부분은 초고가 이미 나와 있는 셈입니다.
스프린트 플래너
학기를 날짜로 펼쳐 보면 루프 하나가 생각보다 짧습니다. 첫 배포를 미룰 여유가 없다는 것이 숫자로 확인됩니다.
남은 시간을 숫자로 확인합니다
한 줄 목표: 마일스톤까지의 D-day와 각 루프의 실작업일을 계산해, "아직 시간이 많다"는 감각과 실제 숫자의 차이를 확인합니다.
스프린트 플래너
개강일이 속한 주가 1주차입니다. 주차별 월요일 날짜, 루프 구간, 마일스톤과 오늘 기준 D-day를 계산합니다. 기말 최종 발표는 15주차로 가정해 표시하며, 확정 일정은 학사일정과 eclass 공지가 기준입니다.
조작 안내 — ① 개강일을 실제 학사일정의 개강일로 맞춰 보세요. ② 개강일을 요일이 다른 날짜(수요일, 금요일)로 바꿔도 1주차 월요일이 올바르게 계산되는지 확인해 보세요. ③ 표에서 자기 팀이 지금 어느 루프 구간에 있는지 찾아보세요.
관찰 포인트 — 루프 2(5~8주)는 "MVP를 배포하고 첫 피드백까지 받는" 구간인데, 실작업일이 4주 = 28일(주중 20일)뿐이라는 점입니다. 그 안에 빌드·배포·측정·학습이 모두 들어가야 하므로, 첫 배포를 한 주 미루면 측정할 시간이 그만큼 줄어듭니다. "루프 하나가 생각보다 짧다"가 숫자로 확인되면 이 실습은 성공입니다.
달력을 계산기로 만든 이유는, 학기 초의 시간 감각이 체계적으로 낙관적이기 때문입니다. "15주"는 길게 들리지만, 시험 기간과 공휴일과 다른 과목의 마감을 빼고 나면 한 루프에 온전히 쓸 수 있는 날은 표의 숫자보다도 적습니다. 계획 오류(planning fallacy)라 불리는 이 낙관 편향에 대한 가장 실용적인 대응은 의지가 아니라 달력을 미리 펼쳐 놓는 것입니다.
표의 D-day는 팀 회의에서 그대로 쓸 수 있습니다. 매주 회의 첫 줄에 "다음 마일스톤까지 D-며칠"을 적는 팀과 적지 않는 팀은 4주차쯤부터 진도가 달라집니다. 마감까지 남은 날을 매주 확인하는 것만으로도 루프 길이 규칙(1~2주)이 지켜질 확률이 올라갑니다.
퀴즈와 핵심 정리
먼저 스스로 답한 뒤 펼쳐서 확인해 보세요.
퀴즈
발표를 크게 보이게 하려고 학기 목표를 실제보다 부풀려 적으면, 이 수업의 평가 구조에서 왜 손해가 될까요?
"중간 제출은 적당히 넘기고 마지막에 완성도를 끌어올린다"는 전략이 이 평가 구조에서 실패하는 이유를 두 가지 이상 들어 보세요.
이번 주에 눈에 띄는 진행이 없었습니다. 매주 제출하는 진행사항 보고에 무엇을 쓰는 것이 좋을까요?
하나. 루프 한 바퀴는 가설–빌드–배포–측정–학습의 다섯 칸이고, 한 바퀴에 핵심 가설은 하나, 길이는 1~2주입니다. AI 도구가 줄여 준 것은 빌드이지 학습이 아니므로, 성과는 루프를 돌린 횟수에 비례합니다.
둘. 마일스톤은 루프의 기록이고 평가는 과정을 잽니다 — 직전 대비 개선(①), 계획 대비 달성(②), 스스로 세운 목표 대비 실달성(③), 팀의 협력(④). 이 구조에서 목표 부풀리기와 몰아치기는 모두 기대값이 낮은 선택입니다.
셋. 역할은 직군이 아니라 루프의 칸으로 나누고 바퀴마다 순환합니다. 매주의 회의 기록이 보고가 되고, 보고가 보고서가 됩니다. 일정·배점·방식의 확정본은 언제나 eclass 공지가 기준입니다.
참고문헌
루프 방법론의 기본 문헌 세 권입니다. 링크는 공식 페이지가 확실한 것만 달았습니다.
루프 방법론
- Ries, E. (2011). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business. theleanstartup.com — Build–Measure–Learn 루프와 검증된 학습(validated learning)의 원전입니다.
- Maurya, A. (2012). Running Lean: Iterate from Plan A to a Plan That Works (2nd ed.). O'Reilly Media. — 린 캔버스와 가설 우선순위를 다룹니다. 2장의 사업 모델 도구가 이 책의 틀을 따릅니다.
- Sutherland, J. (2014). Scrum: The Art of Doing Twice the Work in Half the Time. Crown Business. — 고정 길이 스프린트와 팀 운영을 다룹니다. §1의 루프 길이 규칙과 §4의 순환제가 이 책과 닿아 있습니다.
운영 기준 이 장의 마일스톤·평가 차원은 수업 운영 방침을 서술한 것이며, 날짜·배점·진행 방식의 확정본은 학기 중 eclass 공지가 기준입니다. 공지와 이 문서가 다르면 공지가 우선합니다.
이 자료는 단일 HTML 파일로 배포되며, 실습은 순수 JavaScript로 구현되어 오프라인에서도 동작합니다.