6블록 틀(학습목표 · 진행표 · 멘토 스크립트 · 실습 · 이해 확인 · 흔한 실수)은 1주차 강의안과 동일합니다. 이번 주는 세션 대부분이 개인 실습이 아니라 팀 워크숍이라는 점만 기억하세요 — 멘토는 강사보다 퍼실리테이터(진행자)에 가깝게 움직입니다.

MON
월

## 주제 확정 · 역할 분담

목표 — 4명이 만들 "작은 기능 하나"를 정하고, PM 포함 역할을 나눈다.
Day 1 · 세션 1 · 오전

### 아침 스탠드업 — 프로젝트 모드로 전환

30분 (포인터 세션)
🎯학습목표

- 이번 주부터 아침이 "기본기 강의"가 아니라 "팀 프로젝트 시간"임을 이해한다.
- 매일 아침 스탠드업으로 진행 상황을 서로에게 공유하는 습관을 만든다.

✍️실습 / 안내

스탠드업 규칙 — 이번 주부터 CS 기본기 4주 커리큘럼은 잠시 멈추고, 아침 시간을 팀 작업으로 씁니다. 매일 아침 각자 30초씩 세 가지만 말해요.

- 어제 한 것
- 오늘 할 것
- 막힌 것 / 도움이 필요한 것

💬멘토 스크립트
멘토

"자, 오늘부터 한 주 동안은 여러분 넷이 한 팀이에요. 지금까지는 각자 배웠지만, 이번 주는 같이 하나를 만들어 봅니다. 회사에서 실제로 일하는 방식이 딱 이래요."

"아침마다 '스탠드업'이라는 걸 할 거예요. 서서 짧게 하는 회의라 이름이 그래요. 어제 뭐 했고, 오늘 뭐 할 거고, 막힌 게 있으면 말하는 거예요. 잘 못했다고 혼나는 자리 절대 아니고요, 서로 어디쯤 있는지 아는 자리예요."

⚠️흔한 실수
실수 — 스탠드업이 30초를 넘겨 5분짜리 잡담이 된다.
대처 — 멘토가 타이머를 잡고, 길어지면 "그건 끝나고 따로 얘기해요"로 끊어 준다.
Day 1 · 세션 2 · 오전

### 주제 브레인스토밍 워크숍

90분
🎯학습목표

- "작지만 실제 제품에 붙일 수 있는 기능"이 어떤 크기인지 감을 잡는다.
- 아이디어를 자유롭게 내고, 팀이 함께 후보를 3개로 좁힌다.
- 좋은 아이디어와 나쁜 아이디어가 아니라, "1주에 끝나는가"로 판단한다.

🕘진행표
0–10분
범위 감 잡기 — 멘토가 "작은 기능" 예시 3~4개를 보여준다.
10–35분
개인 아이디어 — 각자 포스트잇/메모에 아이디어 3개씩 조용히 적는다.
35–60분
공유 — 한 명씩 벽에 붙이며 30초 설명. 질문·평가 없이 듣기만.
60–80분
묶고 좁히기 — 비슷한 것끼리 모으고, 스티커 투표로 상위 3개.
80–90분
정리 — 후보 3개를 화이트보드에 크게 적어 남긴다.
💬멘토 스크립트
멘토

"우리가 만들 건 '앱 전체'가 아니에요. 이미 있는 제품에 쏙 붙는 작은 기능 하나예요. 예를 들면 '할 일에 마감일 추가하기', '게시글에 좋아요 버튼', '내가 쓴 글만 모아보기' 정도요. 이 정도면 한 주에 기획하고 설계하고 조금 만들어 볼 수 있어요."

"지금은 좋은 아이디어를 뽑는 시간이 아니에요. 많이 내는 시간이에요. 이상해 보여도 일단 적어요. 서로 아이디어에 '에이 그건 안 돼' 하는 말은 잠깐 참아 주세요."

디자이너 학생에게: "화면이 그려지는 아이디어가 있으면 그쪽으로 더 밀어봐도 좋아요. 이번 주 화면 설계를 ○○님이 이끌 거니까요."

✍️실습 / 워크시트

아이디어를 이 문장 틀에 맞춰 적으면 크기를 가늠하기 쉬워요. 각자 최소 2개는 이 틀로 채워 봅니다.

아이디어 한 줄 정의 워크시트

    누가: (예: 앱을 쓰는 일반 사용자 / 관리자)
    무엇을 하고 싶다: (예: 할 일에 마감일을 정하고 싶다)
    그래서 어떤 화면·버튼이 생긴다: (예: 날짜 선택 버튼과 마감일 뱃지)
    한 주에 끝날까? (O/△/X):
    우리 스택으로 되나? (웹=React, 서버=Spring Boot):

⚠️흔한 실수
실수 — "인스타그램 같은 거요" 처럼 서비스 전체를 만들자고 한다.
대처 — "그중에 딱 하나 화면만 고른다면?"이라고 되물어 범위를 잘라 준다.
실수 — 목소리 큰 한 명 아이디어로 순식간에 결론난다.
대처 — 개인 메모 → 투표 순서를 지켜, 조용한 학생 아이디어도 벽에 올린다.
Day 1 · 세션 3 · 오후

### 주제 확정 · 역할 분담 회의

120분
🎯학습목표

- 후보 3개 중 하나를 팀 합의로 최종 결정한다.
- PM · 디자인(기획·화면) · 프론트 · 백엔드 역할을 서로 납득하게 나눈다.
- 역할이 "칸막이"가 아니라 "책임을 맡는 사람"이라는 걸 이해한다.

🕘진행표
0–30분
후보 비교 — 3개를 "재미·유용·난이도" 3칸으로 같이 평가.
30–45분
주제 확정 — 손들기로 하나 결정. 멘토는 표결만 돕고 강요하지 않는다.
45–90분
역할 분담 — 아래 역할 카드로 누가 무엇을 맡을지 배정.
90–110분
팀 헌장 작성 — 팀 이름·규칙·소통 방법을 한 장으로 정리.
110–120분
마무리 — PM이 내일 할 일을 한 문장으로 선언.
💬멘토 스크립트
멘토

"이제 셋 중 하나를 골라요. 정답은 없어요. 대신 한번 고르면 이번 주는 그걸로 끝까지 가는 거예요. 마음이 흔들려도요."

"역할을 나눌 건데, PM이 제일 궁금하죠? PM은 대장이 아니에요. 팀이 길을 잃지 않게 챙기는 사람이에요. 오늘 뭐 하기로 했는지, 누가 막혔는지 기억하는 사람. 디자인 맡은 ○○님이 이번 주 화면과 기획을 이끌고, 개발 셋은 프론트·백엔드로 나눠서 붙어요. 근데 벽 쌓지 말고, 서로 넘나들어도 돼요."

✍️실습 / 워크시트

역할 카드를 채워 벽에 붙입니다. 이름을 적는 순간 "내 일"이 생겨요.

팀 헌장 · 역할 배정 워크시트

    팀 이름: ____________________
    우리가 만들 기능(한 줄): ____________________

    PM          : ______  (역할: 일정·할 일 챙기기, 스탠드업 진행)
    기획·디자인 : ______  (역할: 기획서·화면 설계 주도, 스펙 전달)
    프론트엔드  : ______  (역할: React 화면 구현)
    백엔드     : ______  (역할: Spring Boot API 구현)

    우리 팀 규칙 3가지:
     1. ____________________
     2. ____________________
     3. ____________________
    소통 방법(예: 채팅방 / 보드): ____________________

✅이해 확인

퇴근 전 각자 한 문장으로 답하게 하세요.

- 우리가 이번 주에 만들 기능을 한 줄로 말해 볼까요?
- 내 역할은 무엇이고, 내일 아침 내가 첫 번째로 할 일은?
- PM이 하는 일은 "명령"인가요, "챙김"인가요?

⚠️흔한 실수
실수 — 개발 3명이 다 백엔드를 하겠다고 몰린다.
대처 — "화면 없으면 사용자가 못 써요"로 프론트의 가치를 세워 균형을 맞춘다.
실수 — 디자이너가 "저는 코드 몰라서요" 하고 뒤로 빠진다.
대처 — 이번 주 화면·기획의 주인이 디자이너임을 분명히 하고, 개발자에게 스펙을 넘기는 역할을 강조한다.
TUE
화

## 기획서 · 화면 설계

목표 — "무엇을 왜 만드는지"를 기획서로, "어떻게 보이는지"를 화면 설계로 남긴다.
Day 2 · 세션 1 · 오전

### 아침 스탠드업

15분 (포인터 세션)
🎯학습목표

- 어제 확정한 주제·역할을 다시 확인하고 오늘 목표를 공유한다.

✍️실습 / 안내

스탠드업 (PM 진행) — 각자 어제 한 것 / 오늘 할 것 / 막힌 것을 30초씩. 오늘은 기획서·화면 설계가 목표라는 걸 PM이 선언합니다. (아침 기본기 강의는 이번 주 없음 — 프로젝트 작업으로 대체)

Day 2 · 세션 2 · 오전

### 기획서 함께 쓰기

120분
🎯학습목표

- 기획서가 "왜 · 누가 · 무엇을 · 성공 기준"을 담는 문서임을 안다.
- 디자이너가 초안을 이끌고, 팀 전원이 한 문단씩 채운다.
- "다 안 만들어도 되는 것(이번 주 범위 밖)"을 분명히 적는다.

🕘진행표
0–15분
좋은 기획서 예시 — 멘토가 한 장짜리 예시 하나를 같이 읽는다.
15–40분
배경·목표 — "왜 이걸 만드나"를 팀이 대화하며 채운다(디자이너 주도).
40–75분
사용자 시나리오 — 사용자가 이 기능을 쓰는 흐름을 문장으로.
75–100분
범위 · 비범위 — 이번 주에 할 것 / 안 할 것을 나눈다.
100–120분
성공 기준 — "이렇게 되면 성공"을 2~3개 적는다.
💬멘토 스크립트
멘토

"기획서는 어렵게 쓰는 게 아니에요. 나중에 우리끼리 딴소리 안 하려고 미리 정해 두는 메모예요. '어? 이거 만들기로 했었나?' 이걸 막아줘요."

"제일 중요한 칸은 안 만들 것 칸이에요. 욕심내면 한 주에 절대 못 끝내요. '이번 주엔 여기까지만' 하고 선을 긋는 것도 실력이에요. 우리 회사 슬로건이 '고객과 함께 더 나은 세상을 만들어 나가는 기업'인데, 그 시작이 이렇게 작은 기능 하나를 제대로 끝내는 거예요."

디자이너에게: "○○님이 이 문서 주인이에요. 개발자들이 헷갈리면 ○○님한테 물어보게 될 거예요."

✍️실습 / 워크시트

기획서 한 장을 이 틀로 완성합니다. 문서 도구(노션·구글 문서 등) 하나에 함께 씁니다.

기획서 원페이저 템플릿

    기능 이름: ____________________
    1. 배경 / 왜 만드나
       ____________________
    2. 누가 쓰나 (대상 사용자)
       ____________________
    3. 사용자 시나리오 (쓰는 흐름)
       ① 사용자가 ____ 한다
       ② 그러면 화면에 ____ 이 보인다
       ③ 사용자가 ____ 하면 ____ 된다
    4. 이번 주에 만들 것 (범위)
       - ____________________
    5. 이번 주에 안 만들 것 (비범위)
       - ____________________
    6. 성공 기준
       - ____________________

⚠️흔한 실수
실수 — 기획서를 화면 얘기(버튼 색·위치)로 가득 채운다.
대처 — "그건 다음 화면 설계 시간에요. 여기선 왜·무엇만"이라고 나눠 준다.
실수 — 성공 기준이 "잘 되면 성공"처럼 뭉뚱그려진다.
대처 — "무엇을 보면 알 수 있죠?"로 구체적 문장(예: 마감일이 화면에 뜬다)으로 바꾼다.
Day 2 · 세션 3 · 오후

### 화면 설계 (와이어프레임) — 디자이너 주도

150분
🎯학습목표

- 기획서의 시나리오를 실제 화면 그림(와이어프레임)으로 옮긴다.
- 화면에 어떤 요소·버튼이 있고, 무엇을 누르면 어디로 가는지 정한다.
- 디자이너가 화면을 이끌고, 개발자가 "이건 어떻게 동작해요?"를 질문한다.

🕘진행표
0–20분
화면 목록 뽑기 — 이 기능에 필요한 화면이 몇 개인지 센다(보통 1~3개).
20–90분
손그림 와이어프레임 — 종이/피그마로 화면마다 요소 배치.
90–120분
흐름 연결 — 화살표로 "이 버튼 → 이 화면" 연결.
120–150분
개발자 질문 타임 — 각 요소가 데이터로 뭘 필요로 하는지 메모.
💬멘토 스크립트
멘토

"화면 설계는 처음부터 예쁘게 그릴 필요 없어요. 네모랑 글씨면 충분해요. '여기 목록이 있고, 위에 추가 버튼, 각 줄에 마감일 뱃지' 이렇게요."

"개발자 셋은 그림 보면서 계속 질문해요. '이 버튼 누르면 저장돼요? 어디에 저장돼요?' 이 질문이 내일 API 설계로 바로 이어져요. 디자이너랑 개발자가 지금 대화를 많이 할수록 나중에 덜 헤매요."

✍️실습 / 워크시트

화면 카드를 화면 수만큼 만듭니다. 개발자가 붙는 "데이터 메모" 칸이 핵심이에요.

화면 설계 카드 (화면 1개당 1장)

    화면 이름: ____________________  (예: 할 일 목록 화면)
    이 화면에 보이는 것:
       - ____________________  (예: 할 일 목록)
       - ____________________  (예: [+ 추가] 버튼)
       - ____________________  (예: 각 항목의 마감일 뱃지)
    누르면 일어나는 일:
       - [____] 버튼 → ____________________
    개발자 데이터 메모 (이 화면이 서버에서 받아야 할 것):
       - ____________________  (예: 할 일 제목, 마감일)

✅이해 확인

오후 마무리로 팀에게 물어보세요.

- 우리 기능은 화면이 몇 개예요? 각 화면에서 사용자가 뭘 하죠?
- 가장 중요한 버튼 하나를 누르면 무슨 일이 나요?
- 이 화면들을 그리면서 새로 생긴 질문이 있나요?

⚠️흔한 실수
실수 — 색·폰트·간격을 다듬느라 시간을 다 쓴다.
대처 — "지금은 '무엇이 어디 있나'만. 예쁘게는 나중에"라고 방향을 잡아 준다.
실수 — 개발자들이 그림만 구경하고 질문을 안 한다.
대처 — 멘토가 "이 버튼 누르면 데이터 어디서 와요?"를 먼저 시범 질문한다.
WED
수

## API 설계 · 태스크 보드

목표 — 화면과 서버가 주고받을 데이터를 API로 정하고, 할 일을 보드에 쪼갠다.
Day 3 · 세션 1 · 오전

### 아침 스탠드업

15분 (포인터 세션)
🎯학습목표

- 화면 설계까지 온 상태를 확인하고, 오늘 API·보드 목표를 공유한다.

✍️실습 / 안내

스탠드업 (PM 진행) — 30초씩 3가지. 어제 화면 설계에서 남은 질문이 있으면 오늘 API 설계로 넘겨 해결한다고 정리합니다.

Day 3 · 세션 2 · 오전

### API 설계 워크숍 — 화면과 서버 잇기

150분
🎯학습목표

- API가 "화면(React)과 서버(Spring Boot)가 데이터를 주고받는 약속"임을 이해한다.
- 화면 카드의 "데이터 메모"를 실제 요청·응답 모양으로 옮긴다.
- 어떤 주소(URL)로, 어떤 방식(GET/POST)으로 주고받을지 팀이 합의한다.

🕘진행표
0–20분
API 개념 — 멘토가 "식당 주문서" 비유로 요청/응답을 설명.
20–50분
필요한 동작 나열 — 화면에서 필요한 동작(목록 보기·추가·삭제)을 적는다.
50–110분
API 표 채우기 — 동작마다 주소·방식·주고받는 데이터를 정한다.
110–140분
응답 예시(JSON) — 서버가 돌려줄 데이터 모양을 손으로 적어 본다.
140–150분
합의 — 프론트·백엔드가 이 표대로 만들기로 악수.
💬멘토 스크립트
멘토

"API가 어려운 말 같죠? 쉽게 생각해요. 식당에서 주문서랑 나온 음식이에요. 화면이 '할 일 목록 주세요' 하고 주문서(요청)를 보내면, 서버가 목록(응답)을 내주는 거예요."

"이 표를 지금 같이 정해 두면, 프론트 맡은 사람이랑 백엔드 맡은 사람이 따로 앉아서도 같은 걸 만들 수 있어요. '나는 이 주소로 보낼게' '나는 이 주소로 받을 준비할게' 이렇게 약속이 되니까요."

✍️실습 / 워크시트

API 명세 표를 동작마다 한 줄씩 채웁니다. 우리 스택은 웹=React, 서버=Spring Boot(Java)라는 걸 기억하세요.

API 명세 워크시트

    동작        방식     주소(URL)             보내는 것        받는 것
    --------    ----     ----------------      -----------     -----------------
    목록 보기   GET      /api/todos           (없음)          할 일 배열
    할 일 추가  POST     /api/todos           제목, 마감일     추가된 할 일
    할 일 삭제  DELETE   /api/todos/{id}      (없음)          성공 여부

    응답 예시(JSON) — 목록 보기:
    [
      { "id": 1, "title": "청소하기", "dueDate": "2026-07-20" },
      { "id": 2, "title": "숙제하기", "dueDate": "2026-07-18" }
    ]

✅이해 확인

표를 다 채운 뒤 확인하세요.

- "목록 보기"는 왜 GET이고 "추가"는 왜 POST일까요?
- 프론트 담당자: 이 주소로 무엇을 보내고 무엇을 받죠?
- 백엔드 담당자: 이 응답 JSON을 만들려면 서버가 뭘 저장해야 하죠?

⚠️흔한 실수
실수 — 프론트와 백엔드가 서로 다른 주소·데이터 이름을 상상한 채 넘어간다.
대처 — 표를 한 장에 같이 적어 "이 이름 그대로 쓴다"를 못 박는다.
실수 — API를 실제 제품 수준으로 완벽히 설계하려 든다.
대처 — "이번 기능에 필요한 동작만"으로 3~4줄이면 충분하다고 안심시킨다.
Day 3 · 세션 3 · 오후

### 태스크 보드 만들기 + 멘토 설계 리뷰

120분
🎯학습목표

- 기획·화면·API를 "작은 할 일 카드"로 쪼개 보드에 올린다.
- 각 카드에 담당자와 순서를 붙여, 목요일에 바로 손댈 수 있게 한다.
- 멘토 리뷰를 통해 설계에 큰 구멍이 없는지 점검받는다.

🕘진행표
0–15분
보드 소개 — 할 일 / 하는 중 / 끝 3칸 칸반을 만든다.
15–55분
카드 쪼개기 — 기능을 하루 안에 끝날 크기의 카드로 나눈다.
55–75분
담당·순서 — 카드마다 이름 붙이고, 먼저 할 것을 위로.
75–115분
멘토 설계 리뷰 — 팀이 기획~보드를 5분 발표, 멘토가 질문·보완.
115–120분
정리 — PM이 "목요일 아침 첫 카드"를 지목.
💬멘토 스크립트
멘토

"이제 큰 덩어리를 손에 잡히는 작은 카드로 쪼갤 거예요. '할 일 기능 만들기'는 너무 커요. '목록 화면 뼈대 만들기', '추가 버튼 붙이기', '서버에 저장 API 만들기'처럼 하루 안에 끝날 크기로 잘라요."

설계 리뷰에서 (격려 톤): "지금부터 제가 몇 가지 물어볼 텐데, 틀렸다고 지적하는 게 아니에요. 여러분이 놓친 게 있으면 지금 찾는 게 훨씬 이득이라서 그래요. 잘 만들었어요, 여기서 한 걸음만 더 봐요."

✍️실습 / 워크시트

칸반 보드를 벽이나 노션/트렐로 같은 도구에 만들고, 카드를 채웁니다.

태스크 보드 · 카드 템플릿

    [ 할 일 ]        [ 하는 중 ]      [ 끝 ]
    ----------       ----------       ----------

    카드 한 장 형식:
      제목  : ____________________ (예: 목록 화면 뼈대 만들기)
      담당  : ______
      크기  : 반나절 / 하루
      메모  : ____________________ (예: 화면 카드 1번 참고)

✅이해 확인 · 멘토 리뷰 체크

멘토가 리뷰 때 이 질문들로 설계 구멍을 확인합니다.

- 기획서의 "성공 기준"을 보드 카드들이 다 커버하나요?
- 화면에 있는 버튼마다, 그걸 처리할 API 카드가 있나요?
- 목요일 아침에 누가 어떤 카드부터 잡을지 정해졌나요?
- 혹시 한 사람에게만 카드가 몰려 있지 않나요?

⚠️흔한 실수
실수 — 카드가 "기능 완성"처럼 너무 커서 며칠이 걸린다.
대처 — "이걸 반나절짜리 두세 개로 자르면?"으로 함께 쪼갠다.
실수 — 리뷰에서 지적받자 학생이 위축된다.
대처 — "설계 단계에서 찾은 문제는 100% 이득"이라고 프레임을 바꿔 준다.
THU
목

## 개발 착수

목표 — 보드의 첫 카드들을 실제 코드로 옮기기 시작한다(React · Spring Boot).
Day 4 · 세션 1 · 오전

### 아침 스탠드업 — 개발 첫날

15분 (포인터 세션)
🎯학습목표

- 각자 오늘 잡을 첫 카드를 말로 선언하고 시작한다.

✍️실습 / 안내

스탠드업 (PM 진행) — 오늘부터는 "오늘 할 것"을 보드 카드 이름으로 말합니다. 예: "저는 '목록 화면 뼈대' 카드 잡을게요." 카드를 '하는 중'으로 옮기며 시작해요.

Day 4 · 세션 2 · 오전~오후

### 구현 착수 — 페어로 손대기

240분 (중간 휴식 포함)
🎯학습목표

- 설계 문서(기획·화면·API)를 보며 첫 코드를 작성한다.
- 프론트는 React로 화면 뼈대, 백엔드는 Spring Boot로 API 뼈대를 만든다.
- 막히면 혼자 오래 붙들지 않고 팀·멘토에게 빨리 묻는다.

🕘진행표
0–20분
환경 확인 — 각자 프로젝트가 실행되는지(React `npm run dev`, 서버 기동) 먼저 확인.
20–120분
첫 카드 구현 — 프론트=화면 뼈대, 백엔드=API 뼈대(빈 응답이라도).
120–130분
중간 싱크 — 5분 서서 "어디까지 됐나" 짧게 공유.
130–220분
이어서 구현 — 프론트-백엔드가 API 주소로 실제 연결 시도.
220–240분
카드 정리 — 끝난 카드는 '끝'으로, 못 끝낸 건 메모 남기기.
💬멘토 스크립트
멘토

"드디어 코드예요! 근데 오늘 목표는 '완성'이 아니라 '시작해서 굴러가게'예요. 화면에 목록이 딱 하나라도 뜨면 대성공이에요."

"막히는 건 당연해요. 규칙 하나만 지켜요 — 15분 넘게 혼자 못 풀면 손 드세요. 오래 붙들고 있는 게 멋진 게 아니라, 빨리 물어보고 앞으로 가는 게 프로예요. 옆 사람이랑 화면 같이 보면서 해도 좋아요."

디자이너에게: "○○님은 화면이 설계대로 나오는지 봐 주고, 개발자가 스펙을 헷갈려 하면 짚어 주세요. 여유가 되면 간단한 스타일도 손대 보고요."

✍️실습 / 안내

오늘의 최소 목표(각 역할) — 완벽하지 않아도 됩니다. "한 조각이라도 화면/서버에서 돌아간다"가 기준입니다.

- 프론트: React로 첫 화면이 열리고, 목록 자리(빈 목록이라도)가 보인다.
- 백엔드: Spring Boot에서 `GET /api/todos`가 200으로 응답한다(내용은 가짜여도 OK).
- 디자이너: 화면 설계와 실제 화면을 나란히 비교해 다른 점 3개를 메모한다.
- PM: 오늘 끝난 카드와 남은 카드를 세어 내일 아침에 공유할 준비.

⚠️흔한 실수
실수 — 처음부터 예쁜 UI·완벽한 코드에 매달려 아무것도 안 굴러간다.
대처 — "일단 못생겨도 돌아가게, 다듬기는 나중에"를 반복해 준다.
실수 — 프론트·백엔드가 서로 안 맞춰서 연결이 안 된다.
대처 — 수요일 API 표를 다시 펴서 주소·데이터 이름이 같은지 대조하게 한다.
FRI
금

## 중간 점검 · 진행률 리뷰

목표 — 계획 대비 어디까지 왔는지 함께 확인하고, 다음 주 할 일을 정한다.
Day 5 · 세션 1 · 오전

### 아침 스탠드업 + 오늘 마무리 계획

20분 (포인터 세션)
🎯학습목표

- 어제까지 진행을 확인하고, 오늘 "점검·발표"가 목표임을 공유한다.

✍️실습 / 안내

스탠드업 (PM 진행) — 30초씩 3가지에 더해, PM이 보드를 보며 "지금 끝난 카드 / 남은 카드 개수"를 숫자로 알려 줍니다. 오전은 남은 카드를 조금 더 밀고, 오후는 점검·발표라고 안내합니다.

Day 5 · 세션 2 · 오전

### 마무리 스프린트 + 진행률 집계

120분
🎯학습목표

- 오늘 오전에 끝낼 수 있는 카드를 골라 마무리한다.
- 계획(월~수 보드) 대비 실제 진행률을 숫자로 정리한다.
- 못 끝낸 것을 "실패"가 아니라 "다음 주 할 일"로 옮긴다.

🕘진행표
0–70분
마무리 구현 — 거의 다 된 카드를 우선 끝낸다(새 카드 시작 금지).
70–95분
진행률 집계 — 전체 카드 중 몇 개 끝났는지 세어 % 계산.
95–120분
데모 준비 — 오후 발표용으로 "지금 되는 것"을 정리.
✍️실습 / 워크시트

진행률 카드를 채워 오후 발표에 씁니다. "계획 대비 실행"이 이번 주 평가 포인트 중 하나예요.

주간 진행률 워크시트

    전체 카드 수      : ______ 개
    끝낸 카드 수      : ______ 개
    진행률           : ______ %  (끝낸 ÷ 전체 × 100)

    지금 실제로 되는 것 (데모 가능):
      - ____________________
    아직 안 되는 것 (다음 주로):
      - ____________________
    계획과 달라진 점 / 배운 것:
      - ____________________

⚠️흔한 실수
실수 — 발표 직전에 새 기능을 욕심내다 되던 것까지 망가뜨린다.
대처 — "지금부터 새 카드 금지, 되는 걸 지키자"로 잠금한다.
Day 5 · 세션 3 · 오후

### 진행률 리뷰 · 팀 회고

120분
🎯학습목표

- 팀이 만든 것을 서로에게 데모하고, 한 주를 회고한다.
- 협업·소통·주도성·계획 대비 실행을 스스로/서로 돌아본다.
- 다음 주에 이어서 할 일을 보드에 명확히 남긴다.

🕘진행표
0–25분
데모 — "지금 되는 것"을 화면으로 시연(작아도 OK).
25–70분
회고 (KPT) — 좋았던 것 / 아쉬운 것 / 다음에 해볼 것.
70–95분
서로 칭찬 — 팀원별로 "이 사람 덕분에 좋았던 점" 한마디씩.
95–120분
다음 주 준비 — 남은 카드 정리, 멘토 마무리 코멘트.
💬멘토 스크립트
멘토

"일주일 동안 정말 많은 걸 했어요. 아이디어에서 시작해서 기획서, 화면, API, 보드, 그리고 실제로 돌아가는 코드까지요. 아직 다 안 됐어도 괜찮아요. 진짜 개발은 원래 다음 주로 이어져요."

"회고는 잘잘못 따지는 자리가 아니에요. '이건 좋았으니 계속하자, 이건 아쉬웠으니 바꿔보자'를 찾는 자리예요. 특히 서로한테 고마웠던 점을 꼭 말해 주세요. 같이 일하는 힘이 거기서 나와요."

✍️실습 / 워크시트

KPT 회고를 각자 적고 벽에 붙인 뒤, 팀이 함께 읽습니다.

KPT 회고 워크시트

    Keep (좋았던 것, 계속할 것)
      - ____________________
    Problem (아쉬웠던 것, 힘들었던 것)
      - ____________________
    Try (다음 주에 새로 해볼 것)
      - ____________________

    이번 주 나의 한마디:
      - 내가 팀에 기여한 것: ____________________
      - 팀원 ○○ 덕분에 좋았던 것: ____________________

✅이해 확인 · 평가 체크포인트

멘토는 회고를 들으며 이번 주 평가 포인트를 관찰·기록합니다.

- 협업·소통 — 스탠드업·리뷰에서 서로 묻고 도왔는가?
- 주도성 — 시키기 전에 카드를 잡고 스스로 움직였는가?
- 계획 대비 실행 — 보드 계획과 실제 결과의 차이를 스스로 설명하는가?
- 디자이너는 화면·기획을 주도하고 개발자에게 스펙을 넘겼는가?

⚠️흔한 실수
실수 — 회고가 "누구 때문에 안 됐다"는 탓하기로 흐른다.
대처 — "사람이 아니라 방법을 말해요"로 방향을 돌리고, 칭찬 라운드로 마무리한다.
실수 — 다 못 끝냈다고 팀 전체가 풀이 죽는다.
대처 — "한 주에 여기까지 온 게 대단한 것"이라고 성취를 구체적으로 짚어 준다.

다음 주 예고 — 8주차 · 프로젝트 완성 & 최종 발표. 이번 주에 만든 기능을 끝까지 다듬어 완성하고, 데모와 함께 최종 발표로 8주 수습 과정을 마무리합니다.