Day 1 — 프로젝트 시작하기: 애자일, 스프린트, 그리고 명세서
오늘의 목표
- 애자일과 스프린트가 왜 필요한지 이해한다
- 우리 16주 과정이 어떻게 굴러갈지 감을 잡는다
- 내 프로젝트 아이디어를 "명세서" 한 장으로 정리해서 나간다
오늘 끝나면 여러분 손에 본인 프로젝트 1페이지 기획서가 들려 있어야 합니다.
0. 들어가기 전에 — 왜 이런 걸 배우죠?
혼자 사이드 프로젝트 만들다가 흐지부지된 경험, 다들 한 번쯤 있죠.
대부분 이유는 코딩 실력이 아닙니다. "뭘 만들지 끝까지 안 정해서" 혹은 "한 번에 다 만들려다 지쳐서" 입니다.
애자일과 스프린트는 거창한 이론이 아니라, 이 두 가지 실패를 막는 아주 실용적인 작업 습관입니다. 오늘은 그 습관의 기초를 잡습니다.
1. 애자일(Agile)이란?
한 줄 정의
크게 한 방에 만들지 말고, 작게 만들어서 자주 확인하며 고쳐나가자.
옛날 방식 vs 애자일
전통적인 방식(워터폴)은 폭포수처럼 위에서 아래로 한 방향으로만 흐릅니다. 기획을 완벽하게 끝낸 뒤 → 설계를 다 하고 → 개발을 끝까지 한 다음 → 마지막에 테스트합니다. 문제는, 다 만들고 나서야 "어 이거 내가 원하던 게 아닌데?"를 깨닫는다는 점입니다.
애자일은 다릅니다. 작은 단위로 기획-개발-확인을 반복합니다. 2주마다 "지금까지 만든 거 한번 보자" 하고 점검하기 때문에, 방향이 틀어져도 2주치만 손해 봅니다.
| 워터폴 (옛날 방식) | 애자일 | |
|---|---|---|
| 진행 | 한 방향, 한 번에 | 작은 주기로 반복 |
| 결과 확인 | 맨 마지막에 | 2주마다 |
| 방향 수정 | 거의 불가능 | 언제든 가능 |
| 실패 시 손해 | 프로젝트 전체 | 한 주기치만 |
애자일의 4가지 핵심 가치 (외울 필요 X, 느낌만)
- 계획을 따르기보다 → 변화에 대응하기
- 문서를 완벽히 쓰기보다 → 동작하는 결과물 만들기
- 도구·절차보다 → 사람과 대화
- 계약·조건보다 → 함께 만들어가기
💡 우리 수업에서는: "완벽한 기획서를 쓰고 시작"하지 않습니다. 일단 한 장짜리 명세서로 시작하고, 2주마다 고쳐나갑니다.
2. 스프린트(Sprint)란?
한 줄 정의
정해진 짧은 기간(보통 1~2주) 동안 "딱 이만큼만 만들자"고 약속하고, 그 기간에 집중하는 것.
마라톤을 전력 질주(sprint) 구간으로 쪼갠다고 생각하면 됩니다. 42km를 한 번에 보면 막막하지만, "다음 2km만" 이라고 생각하면 뛸 만하죠.
스프린트 한 주기는 이렇게 돌아갑니다
[스프린트 계획] → [개발] → [스프린트 리뷰] → [회고]
이번에 뭘 실제 만든 거 뭐가 좋았고
할지 정함 만들기 확인 뭘 고칠지
- 스프린트 계획: 이번 2주 동안 만들 것을 목록에서 고른다
- 개발: 고른 것에만 집중한다 (새 아이디어 떠올라도 다음 스프린트로!)
- 리뷰: 끝에 실제 동작하는 결과물을 확인한다
- 회고: "뭐가 잘됐고, 뭘 바꿀까?" 짧게 돌아본다
우리 수업의 스프린트
우리 과정은 4주 = 1블록, 그 안에서 2주 = 1스프린트 로 돌립니다.
- 16주 = 8개의 스프린트
- 매 스프린트 끝 = 멘토링 + 점검
- 핵심 규칙: 8주차 이후엔 새 기능 추가 금지 (다듬기만!)
⚠️ 초보자가 프로젝트를 못 끝내는 1순위 이유: 마지막까지 기능을 계속 추가하다가 배포를 못 함. 스프린트는 이걸 막는 장치입니다.
3. 백로그(Backlog) — 할 일 창고
스프린트에서 "고를" 목록이 필요하겠죠? 그게 백로그입니다.
백로그 = 만들고 싶은 모든 기능을 적어둔 우선순위 목록
전체 백로그에서 이번 스프린트에 할 것만 꺼내오는 식입니다.
백로그 작성 예시 (할 일 관리 앱)
| 우선순위 | 기능 | 비고 |
|---|---|---|
| 🔴 필수 | 회원가입 / 로그인 | 없으면 서비스 자체가 안 됨 |
| 🔴 필수 | 할 일 추가 / 조회 / 수정 / 삭제 | 핵심 기능 |
| 🟡 중요 | 할 일 완료 체크 | |
| 🟡 중요 | 마감일 설정 | |
| 🟢 나중에 | 카테고리 분류 | 시간 남으면 |
| 🟢 나중에 | 다크모드 | 여유되면 |
💡 MoSCoW 기법: Must(필수) / Should(중요) / Could(있으면 좋음) / Won't(이번엔 안 함). 우선순위를 정할 때 이 4단계로 나눠보세요.
4. 실습 — 내 프로젝트 명세서 작성하기
이제 직접 해봅니다. 아래 템플릿을 채워서 오늘 나갈 때 1페이지 명세서를 완성하세요.
🛠 실습 템플릿 (복사해서 채우기)
# 프로젝트 명세서 v0.1
## 1. 한 줄 소개
(이 서비스를 한 문장으로 설명하면?)
예) "혼자 사는 사람을 위한 냉장고 재료 관리 + 레시피 추천 웹앱"
## 2. 누가 쓰나요? (타겟 사용자)
(구체적일수록 좋음)
예) "요리 초보 자취생. 재료를 자주 썩혀서 버린다."
## 3. 어떤 문제를 해결하나요?
예) "냉장고에 뭐가 있는지 까먹어서 중복 구매하고, 유통기한을 놓친다."
## 4. 핵심 기능 (Must / 3개 이내)
- [ ]
- [ ]
- [ ]
## 5. 있으면 좋은 기능 (Could / 나중에)
- [ ]
- [ ]
## 6. 화면 목록 (대략)
예) 로그인 / 재료 목록 / 재료 추가 / 레시피 추천
## 7. 기술 스택 (정해지면)
- 백엔드:
- DB:
- 프론트: (바이브코딩으로 해결 예정)
- 배포:
## 8. 이번 주 할 일 (첫 스프린트 미니 목표)
예) "명세서 확정 + GitHub 저장소 만들기"
✍️ 작성 가이드 — 막힐 때 보세요
아이디어가 안 떠올라요 → "내가 최근에 불편했던 것"에서 출발하세요. 거창할 필요 없습니다. 가계부, 운동 기록, 독서 메모, 맛집 저장 — 작고 명확한 게 완성하기 좋습니다.
기능이 너무 많아요 → 좋은 신호입니다(아이디어가 많다는 뜻). 하지만 핵심 기능은 3개 이내로 줄이세요. 나머지는 5번 "있으면 좋은 기능"으로 내립니다.
이거 너무 단순한 거 아닌가요? → 단순한 게 완성됩니다. 화려한데 미완성인 것보다 단순하고 완성된 게 100배 낫습니다.
5. 오늘의 체크리스트
나가기 전에 아래가 다 됐는지 확인하세요.
- 애자일이 "작게 만들어 자주 확인하기"라는 걸 이해했다
- 스프린트가 "정해진 기간에 정해진 만큼만"이라는 걸 이해했다
- 백로그(할 일 창고)와 우선순위 개념을 안다
- 내 프로젝트 명세서 v0.1을 1페이지로 작성했다 ← 가장 중요!
- 핵심 기능을 3개 이내로 추렸다
6. 다음 시간 예고
Day 2 — 데이터 설계의 시작
- 내 명세서를 바탕으로 "어떤 데이터를 저장할지" 정합니다
- DB 모델링 기초 / REST API 설계 원칙
- 준비물: 오늘 만든 명세서 (이걸로 바로 설계 들어갑니다)
📌 숙제: 명세서를 집에서 한 번 더 다듬어 오세요. 특히 핵심 기능 3개가 정말 핵심인지 다시 보세요.
📚 더 알고 싶다면 (선택)
- 애자일 선언문(원문): agilemanifesto.org — 4가지 가치의 출처
- 키워드 검색: "스크럼(Scrum)", "칸반(Kanban)" — 대표적인 애자일 실천 방법들
수고하셨습니다. 오늘 만든 명세서 한 장이 앞으로 16주의 나침반이 됩니다. 🧭