6블록 틀(학습목표 · 진행표 · 멘토 스크립트 · 실습 · 이해 확인 · 흔한 실수)은 1주차 강의안과 동일합니다. 처음 여시는 멘토는 1주차 안내 카드를 먼저 참고하세요.

MON
월

## 구현 스프린트 · 기능 완성

오늘의 목표: 남은 기능을 끝까지 밀어붙여 "실제로 동작하는" 화면을 만든다.
Day 1 · 세션 1 · 오전

### 아침 스탠드업 + 프로젝트 마무리 착수

약 40분 (스탠드업 15분 + 착수 25분)
🎯학습목표

- 이번 주에 "완성"이 무엇인지, 각자 남은 일이 무엇인지 말로 정리한다.
- 마무리 주간의 스탠드업 리듬(어제·오늘·막힌 곳)을 몸에 익힌다.

🕘진행표
0–5분
멘토 오프닝. "이번 주가 마지막 주"라는 사실을 담담하고 따뜻하게 알림.
5–20분
스탠드업 한 바퀴. 4명이 순서대로 어제 한 일 · 오늘 할 일 · 막힌 곳을 한 문장씩.
20–35분
남은 작업 쪼개기. 각자 오늘 끝낼 기능 1~2개를 화이트보드에 붙임.
35–40분
착수. 자리로 돌아가 바로 코딩 시작.
💬멘토 스크립트
멘토

"자, 드디어 마지막 주예요. 지난 7주 동안 정말 많이 컸어요. 이번 주는 새로 배우는 주가 아니라, 여러분이 만들던 걸 끝까지 완성해서 자랑스럽게 보여주는 주예요."

"스탠드업 규칙 기억하죠? 딱 세 가지만 말해요. 어제 뭐 했는지, 오늘 뭐 할 건지, 막힌 게 있는지. 막힌 걸 말하는 건 부끄러운 게 아니라 제일 잘하는 거예요. 그래야 제가 도와줄 수 있어요."

디자이너에게: "OO은 오늘부터 발표에서 보여줄 화면이랑 기획 흐름을 다듬어 주세요. 개발 팀이 완성하는 화면이랑 계속 맞춰보면서요."

✍️실습 · 스탠드업 워크시트

오늘의 마무리 보드를 각자 채웁니다. 포스트잇 한 장에 아래 대본을 그대로 옮겨 화이트보드에 붙이세요.

오늘의 마무리 보드 (각자 작성)

    이름: ________

    [어제 한 일]  ________________________
    [오늘 끝낼 기능 ①]  ____________________
    [오늘 끝낼 기능 ②]  ____________________
    [지금 막힌 곳]  ______________________
    [도움이 필요한가?]  ☐ 혼자 가능   ☐ 멘토 도움

✅이해 확인

착수 전에 한 명씩 물어봅니다.

- "오늘 끝낼 기능을 딱 한 문장으로 말해볼래요?"
- "그게 끝났는지 어떻게 알 수 있어요? (완료 기준)"

⚠️흔한 실수
실수 마지막 주라고 갑자기 새 기능을 욕심내서 벌린다.
대처 "완성이 목표지 확장이 목표가 아니에요. 지금 있는 걸 동작하게 만드는 게 먼저예요"라고 범위를 좁혀준다.
Day 1 · 세션 2 · 오전~오후

### 기능 완성 스프린트 — 동작하는 상태까지

약 3시간 (중간 체크 포함)
🎯학습목표

- 맡은 기능을 화면에서 실제로 눌러서 동작하는 상태까지 만든다.
- "됐다고 생각한 것"과 "정말 되는 것"의 차이를 직접 확인한다.

🕘진행표
0–70분
집중 코딩 1. 각자 기능 ①에 몰입. 멘토는 조용히 순회하며 어깨너머로 관찰.
70–80분
중간 데모. 한 명씩 지금까지 만든 화면을 30초씩 옆 사람에게 보여줌.
80–150분
집중 코딩 2. 기능 ②로 넘어가거나 ①의 마무리.
150–180분
오늘 만든 것 커밋. 동작하는 지점에서 커밋 메시지 남기고 push.
💬멘토 스크립트
멘토 (순회 중, 막힌 학생에게)

"화면은 나왔는데 버튼이 안 먹는 거죠? 좋아요, 같이 봐요. 우선 버튼 눌렀을 때 함수가 진짜 불리는지부터 확인해요. `console.log` 한 줄 찍어볼까요?"

"거봐요, 로그가 안 찍히죠? 그럼 문제는 함수 안이 아니라 연결이에요. `onClick`이 제대로 걸렸는지 봐요. 이렇게 하나씩 좁혀가는 거예요. 한 번에 다 보려고 하면 오히려 안 보여요."

✍️실습 · 완료 확인 체크

기능 하나를 "끝났다"고 말하기 전에, 아래 3가지를 실제로 클릭해서 확인합니다.

"진짜 되는가" 셀프 체크 (기능마다)

    기능 이름: __________

    ☐ 정상 경우: 제대로 입력하면 기대한 화면이 나온다
    ☐ 빈 경우: 아무것도 입력 안 하고 눌러도 앱이 안 터진다
    ☐ 이상한 경우: 이상한 값을 넣어도 에러 화면 대신
       안내 메시지가 나온다

    세 개 다 ☑ 되면 → git commit -m "___기능 완성___"

✅이해 확인

중간 데모 때 각자에게:

- "방금 보여준 게 정상 경우죠? 빈 값 넣으면 어떻게 돼요?" (즉석에서 눌러보게 한다)
- "이 커밋 메시지만 보고 나중에 무슨 작업인지 알 수 있어요?"

⚠️흔한 실수
실수 화면에 보이기만 하면 "됐다"고 넘어가고, 예외 경우를 한 번도 안 눌러본다.
대처 멘토가 직접 그 자리에서 빈 값·이상한 값을 넣어 앱을 한 번 "터뜨려" 보이고, "이게 발표날 나면 진땀 나요"라고 웃으며 예방의 필요를 느끼게 한다.
TUE
화

## 통합 · 연결하기

오늘의 목표: 따로 만든 조각들을 하나의 앱으로 연결해 처음부터 끝까지 흘러가게 한다.
Day 2 · 세션 1 · 오전

### 아침 스탠드업 (포인터 세션)

약 15분
🎯학습목표

- 어제 완성분을 공유하고, 오늘 "연결"의 목표를 한 문장으로 세운다.

✍️진행 안내

아침 스탠드업은 어제와 같은 마무리 보드 형식으로 짧게 진행합니다. 오늘은 "내 기능이 옆 사람 기능과 어디서 만나는가"를 한 마디씩 덧붙이게 하세요. (CS 기본기가 필요한 팀원이 있으면 CS 기본기 4주 커리큘럼 문서의 해당 일차를 진행하되, 마지막 주인 만큼 프로젝트 완성이 우선입니다.)

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

### 통합 작업 — 프론트와 데이터를 잇다

약 3시간 30분
🎯학습목표

- React 화면(프론트)과 데이터(백엔드/API)를 연결해 실제 데이터가 화면에 뜨게 한다.
- 처음 화면부터 마지막 화면까지 "한 흐름(사용자 시나리오)"으로 이어본다.

🕘진행표
0–15분
연결 지도 그리기. 화면 → 어떤 데이터를 부르는지 화살표로 칠판에 그림.
15–90분
연결 1. 각자 자기 화면에서 실제 데이터를 `fetch`해 뿌리기.
90–100분
합류 점검. 두 명씩 짝지어 서로 화면을 이어 눌러봄.
100–190분
전체 시나리오 연결. 로그인 → 목록 → 상세처럼 처음부터 끝까지 이어봄.
190–210분
통합본 커밋 & 공유. 하나로 합친 버전을 push하고 화면 녹화(30초).
💬멘토 스크립트
멘토

"어제까지는 각자 자기 방을 꾸민 거예요. 오늘은 그 방들을 복도로 연결해서 한 집으로 만드는 날이에요. 손님(사용자)이 현관에서 들어와서 방까지 쭉 걸어갈 수 있어야 해요."

"연결할 때 제일 자주 나는 문제가 뭔지 알아요? 데이터가 안 오는 게 아니라 모양이 다른 거예요. 백엔드는 `userName`으로 줬는데 화면은 `name`을 찾고 있으면 빈칸이 떠요. 그럴 땐 브라우저 개발자도구 Network 탭에서 진짜 온 데이터를 눈으로 확인해요."

✍️실습 · 연결 지도

코딩 전에 연결 지도를 먼저 채웁니다. 내 화면이 어떤 데이터를 필요로 하는지 말로 정리하면 코드가 쉬워집니다.

내 화면 연결 지도

    내 화면 이름: ____________

    이 화면이 열릴 때 불러야 할 데이터:
      주소(API): /api/________
      받는 것:   ____________________

    화면에 보여줄 항목:
      ① ________  ← 데이터의 ______ 필드
      ② ________  ← 데이터의 ______ 필드

    데이터가 안 왔을 때 화면: ☐ 로딩중 표시  ☐ 빈 목록 안내

✅이해 확인

합류 점검 때 짝끼리 서로 물어보게 합니다.

- "이 화면은 데이터 오기 전에 뭐가 보여? 빈 화면이면 안 돼."
- "Network 탭에서 진짜 온 데이터랑 화면에 뜬 게 같아?"

⚠️흔한 실수
실수 각자 자기 브랜치에서만 동작하고, 합쳤더니 충돌(conflict)로 앱이 안 켜진다.
대처 오전 중 한 번은 반드시 `main`으로 합쳐보게 하고, 충돌 해결을 멘토가 옆에서 한 번 같이 해준다. "합치는 건 자주 할수록 안 아파요"를 반복.
WED
수

## 버그 정리 · 안정화

오늘의 목표: 남은 버그를 잡고, 발표 때 실제로 보여줄 흐름이 끊김 없이 돌게 만든다.
Day 3 · 세션 1 · 오전

### 아침 스탠드업 + 버그 목록 만들기

약 30분
🎯학습목표

- 지금 남은 문제들을 한 곳에 모아 "고칠 순서"를 정한다.
- 모든 버그가 똑같이 급하지 않다는 것(우선순위)을 이해한다.

🕘진행표
0–10분
스탠드업. 어제 통합에서 깨진 곳을 각자 한 가지씩 말함.
10–25분
버그 보드 채우기. 발견된 문제를 포스트잇으로 다 붙이고 급함/안급함으로 나눔.
25–30분
분배. 급한 것부터 각자 이름표를 붙임.
💬멘토 스크립트
멘토

"버그가 많아 보여도 걱정 마요. 프로 개발자도 발표 전엔 다 이래요. 중요한 건 다 고치는 게 아니라 발표에 보여줄 길을 매끄럽게 만드는 것이에요."

"그래서 오늘은 버그를 두 줄로 나눠요. 왼쪽은 '발표 흐름에서 사용자가 만나는 것', 오른쪽은 '깊이 들어가야 보이는 것'. 왼쪽부터 잡아요. 오른쪽은 회고에 '다음에 개선'으로 적으면 그것도 훌륭한 결과예요."

✍️실습 · 버그 보드

팀 공용 버그 보드를 채웁니다. 각 버그를 아래 형식으로 적어야 나중에 다시 재현할 수 있습니다.

버그 카드 (한 장에 하나)

    [무엇을 했더니]  ______________________
    [무엇이 나왔나]  ______________________
    [원래 나와야 할 것]  __________________

    발표 흐름에 포함?  ☐ 예(급함)  ☐ 아니오(나중)
    담당: ______

✅이해 확인

분배 직전에:

- "이 버그, 발표 시연에서 심사위원이 볼까요 안 볼까요?"
- "제일 먼저 잡아야 할 버그 하나를 고른다면?"

⚠️흔한 실수
실수 눈에 잘 안 띄지만 재밌어 보이는 버그부터 붙잡고 반나절을 쓴다.
대처 "그건 오른쪽 줄이에요. 발표 길부터 뚫고, 시간 남으면 돌아와요"라고 우선순위로 되돌린다.
Day 3 · 세션 2 · 오후

### 안정화 스프린트 — 발표 흐름 끝까지 돌리기

약 3시간
🎯학습목표

- 발표에서 보여줄 시나리오를 처음부터 끝까지 한 번도 안 끊고 돌린다.
- 버그를 고친 뒤 "다시 눌러 확인"하는 습관을 익힌다.

🕘진행표
0–90분
급한 버그 잡기. 각자 왼쪽 줄(발표 흐름) 버그부터 처리.
90–120분
전체 통과 시험 1회. 팀 전원이 모여 시작→끝 시나리오를 한 번 쭉 실행.
120–170분
남은 흐름 버그 처리. 통과 시험에서 끊긴 지점 고침.
170–180분
오늘 결과 커밋 + 회고 메모. 못 고친 건 "다음에 개선"으로 기록.
💬멘토 스크립트
멘토 (버그 하나 고친 학생에게)

"고쳤어요? 좋아요! 그런데 여기서 제일 중요한 한 가지. 고쳤다고 바로 다음으로 넘어가지 말고, 방금 그 버그가 났던 그 동작을 다시 한 번 그대로 눌러봐요. 진짜 사라졌는지 눈으로 확인해야 해요."

"그리고 하나 더. 고치다가 옆 기능이 같이 깨지는 경우가 많아요. 그래서 고친 뒤에는 짧게라도 전체를 한 번 훑는 거예요. 이걸 잘하면 발표날 사고가 확 줄어요."

✍️실습 · 발표 흐름 통과표

팀이 함께 발표 흐름 통과표를 만들고, 오후에 한 번은 전 구간 ☑를 목표로 합니다.

발표 시나리오 통과표 (팀 공용)

    1단계  첫 화면 진입 ................ ☐ 통과
    2단계  ___________________ .......... ☐ 통과
    3단계  ___________________ .......... ☐ 통과
    4단계  ___________________ .......... ☐ 통과
    5단계  마무리 화면 ................ ☐ 통과

    전 구간 한 번에 통과한 시각: __:__

✅이해 확인

전체 통과 시험 후:

- "방금 어디서 끊겼죠? 그게 급한 버그로 보드에 있나요?"
- "버그 고친 뒤에 다시 눌러 확인했어요?"

⚠️흔한 실수
실수 데모 데이터가 없어서 발표 때 화면이 텅 비어 보인다.
대처 오늘 안에 "보기 좋은 예시 데이터"를 미리 넣어두게 한다. 빈 화면보다 채워진 화면이 훨씬 잘 전달된다는 걸 실제로 비교해 보인다.
THU
목

## 리허설 · 마무리

오늘의 목표: 데모 시나리오를 확정하고, 실제처럼 발표 리허설을 하며, 남은 버그를 정리한다.
Day 4 · 세션 1 · 오전

### 아침 스탠드업 + 데모 시나리오 확정

약 50분
🎯학습목표

- 내일 발표에서 "누가, 어느 화면을, 어떤 순서로" 보여줄지 확정한다.
- 15분 발표의 뼈대(문제 → 우리가 만든 것 → 시연 → 배운 점)를 잡는다.

🕘진행표
0–10분
스탠드업. 어제 남은 버그와 오늘 리허설 목표 공유.
10–30분
발표 뼈대 짜기. 4개 파트(문제/솔루션/시연/회고)에 담당자 배정.
30–45분
시연 대본 초안. 시연 담당이 클릭 순서를 한 줄씩 적음.
45–50분
디자이너 파트 확인. 화면·기획 발표 흐름을 발표 뼈대에 끼워 맞춤.
💬멘토 스크립트
멘토

"발표는 코딩이랑 달라요. 잘 만든 걸 잘 전하는 것까지가 실력이에요. 15분이면 생각보다 짧아요. 그래서 순서를 정해둬야 안 헤매요."

"순서는 간단해요. ①우리가 풀려던 문제가 뭐였는지, ②그래서 뭘 만들었는지, ③실제로 이렇게 됩니다(시연), ④8주 동안 뭘 배웠는지. 이 네 칸만 채우면 발표가 돼요."

디자이너에게: "OO은 ②와 함께 화면을 어떻게 설계했는지, 왜 이렇게 배치했는지 기획 이야기를 맡아주세요. 개발자들이 만든 걸 '왜'로 이어주는 다리예요."

✍️실습 · 발표 대본 뼈대

팀이 함께 발표 대본 뼈대를 채웁니다. 담당자와 대략의 시간까지 적어야 리허설이 가능합니다.

15분 발표 대본 뼈대 (팀 공용)

    ① 문제 (약 2분)   담당 ____
       "우리는 ________ 문제를 풀고 싶었습니다."
    ② 솔루션 (약 3분) 담당 ____ + 디자이너 ____
       "그래서 ________ 을 만들었습니다."
    ③ 시연 (약 7분)   담당 ____
       클릭 순서: _______________________
    ④ 배운 점 (약 3분) 담당 ____
       "8주 동안 가장 크게 배운 것: ________"

✅이해 확인

뼈대를 다 채운 뒤:

- "시연에서 첫 클릭이 뭐예요? 마지막 클릭은요?"
- "내 파트를 한 문장으로 시작한다면 무슨 말로 열래요?"

⚠️흔한 실수
실수 기능을 전부 다 보여주려다 15분을 훌쩍 넘기고 핵심이 묻힌다.
대처 "제일 자랑스러운 흐름 하나에 집중해요. 다 보여주는 것보다 하나를 확실히 보여주는 게 강해요"라고 덜어내게 돕는다.
Day 4 · 세션 2 · 오후

### 발표 리허설 — 실전처럼 두 번

약 2시간 30분
🎯학습목표

- 실제 장비·실제 화면으로 처음부터 끝까지 리허설을 완주한다.
- 발표 중 사고(끊김·질문)에 대응하는 법을 미리 연습한다.

🕘진행표
0–30분
개별 파트 연습. 각자 자기 파트를 소리 내어 2~3번.
30–75분
리허설 1회차. 실제 화면 띄우고 처음부터 끝까지. 멘토는 시간만 잰다.
75–95분
피드백. 좋았던 점 먼저, 고칠 점은 구체적으로 하나씩.
95–135분
리허설 2회차 + 예상 질문 연습. 멘토가 심사위원 역할로 질문.
135–150분
남은 버그 최종 정리. 리허설에서 걸린 곳만 마지막으로 손봄.
💬멘토 스크립트
멘토 (리허설 후 피드백)

"방금 정말 좋았어요. 특히 시연에서 화면 넘어가는 게 매끄러웠어요. 딱 하나만 다듬어요. 시작할 때 조금 빨랐어요. 첫 문장은 심호흡하고 천천히. '안녕하세요, 저희 팀이 만든 건…' 이렇게 여유 있게 열면 나머지가 편해져요."

"그리고 만약 발표 중에 화면이 안 뜨면요? 당황하지 말고 이렇게 말하면 돼요. '잠시 화면을 다시 불러오겠습니다.' 이 한마디면 프로처럼 보여요. 사고는 누구나 나요. 대응이 실력이에요."

✍️실습 · 리허설 피드백 카드

리허설 1회차 뒤, 서로에게 피드백 카드를 한 장씩 써 줍니다. 좋은 점을 반드시 먼저 적는 규칙입니다.

동료 피드백 카드

    받는 사람: ______

    [좋았던 점 — 꼭 하나 이상]
      ________________________________

    [더 좋아질 한 가지 — 구체적으로]
      ________________________________

    [내일 이거 하나만 기억하면 돼요]
      ________________________________

✅이해 확인

2회차 후 각자에게:

- "발표 도중 화면이 멈추면 첫 마디를 뭐라고 할래요?"
- "예상 질문 하나를 미리 준비했어요? 뭐예요?"

⚠️흔한 실수
실수 리허설 직전까지 코드를 고치다가 잘 되던 발표 버전을 깨뜨린다.
대처 목요일 오후 이후로는 발표용 버전을 별도 브랜치/태그로 얼려두기. "여기서부터는 발표본을 지킵니다"를 팀 규칙으로 선언한다.
FRI
금

## 데모 발표 · 최종 면담

오늘의 목표: 경영진·팀 앞에서 데모를 발표하고, 자기평가서를 제출하고, 최종 평가와 전환 면담으로 8주를 마무리한다.
Day 5 · 세션 1 · 오전

### 발표 준비 + 자기평가서 제출

약 60분
🎯학습목표

- 발표 직전 장비·화면·데이터를 최종 점검한다.
- 8주를 돌아보는 자기평가서를 스스로 작성해 제출한다.

🕘진행표
0–15분
장비 리허설. 발표장 화면 연결, 데모 앱 켜서 첫 화면 확인.
15–45분
자기평가서 작성. 조용히 각자 8주 회고 + 자기평가.
45–55분
제출 & 발표 순서 최종 확인. 누가 언제 나설지 한 번 더 맞춤.
55–60분
파이팅. 짧게 서로 응원하고 발표장으로 이동.
💬멘토 스크립트
멘토

"자기평가서는 잘 보이려고 쓰는 게 아니에요. 8주 전의 나랑 지금의 나를 비교하는 거예요. 못한 걸 솔직히 적어도 괜찮아요. 오히려 '이건 아직 부족하고, 다음엔 이렇게 하고 싶다'가 있으면 저는 그게 제일 좋아요."

"발표 전 긴장되는 거 알아요. 긴장은 잘하고 싶은 마음이에요. 나쁜 게 아니에요. 리허설한 대로만 하면 돼요. 우리 이미 어제 두 번 다 해봤잖아요."

✍️실습 · 자기평가서

각자 자기평가서를 아래 항목대로 작성해 제출합니다. (평가 루브릭과 함께 사용)

수습 자기평가서 (8주 회고)

    이름: ______   트랙: ☐ 개발  ☐ 디자인

    1. 8주 중 가장 크게 성장했다고 느낀 것
       ________________________________
    2. 이번 프로젝트에서 내가 맡아 끝낸 것
       ________________________________
    3. 아직 부족하다고 느끼는 것 (솔직하게)
       ________________________________
    4. 앞으로 3개월 안에 더 잘하고 싶은 것
       ________________________________
    5. 스스로에게 주는 한마디
       ________________________________

✅이해 확인

발표장 이동 전 최종 확인:

- "데모 앱, 지금 첫 화면 떠 있죠? 인터넷·로그인 다 됐죠?"
- "자기평가서 5칸 다 채웠어요? 빈칸 없죠?"

⚠️흔한 실수
실수 발표 직전에 코드를 또 만지거나 브랜치를 바꿔 발표본이 안 켜진다.
대처 "오늘은 코드 그만. 우리는 어제 얼려둔 발표본으로만 갑니다"를 다시 못 박는다. 노트북은 발표본 상태 그대로 유지.
Day 5 · 세션 2 · 오후

### 데모 발표 — 경영진·팀 대상 15분

약 90분 (발표 + 질의응답 + 강평)
🎯학습목표

- 준비한 15분 발표를 경영진과 팀 앞에서 완주한다.
- 질문에 당황하지 않고 자기 언어로 답하는 경험을 한다.

🕘진행표
0–5분
오프닝. 멘토가 8주 과정과 발표 순서를 소개하며 분위기를 데운다.
5–20분
팀 발표 15분. 문제 → 솔루션 → 시연 → 배운 점 순.
20–35분
질의응답. 경영진·팀의 질문. 멘토가 필요하면 다리를 놓아줌.
35–50분
강평. 참석자들이 좋았던 점 위주로 격려 코멘트.
50–90분
기념 촬영 & 정리. 발표 마무리, 발표자료·회고 취합.
💬멘토 스크립트
멘토 (발표 오프닝, 경영진·팀 앞에서)

"안녕하세요. 지난 8주 동안 미림마이스터고에서 온 수습생 네 명과 함께 달려왔습니다. 오늘은 그 결과를 직접 보여드리는 자리예요. 첫 주에 `console.log` 하나에 감탄하던 친구들이 이제 동작하는 앱을 만들어 왔습니다. 따뜻하게 봐주세요."

멘토 (질문이 어려워 학생이 멈칫할 때)

"좋은 질문이에요. 잠깐 제가 거들면요, 지금 질문은 '이 기능을 어떻게 더 빠르게 만들 수 있냐'는 거예요. OO이 시도해본 방향으로 답해볼래요?"

✍️실습 · 발표 진행 대본

발표 진행자(멘토 또는 팀장 역할 수습생)가 아래 진행 대본을 손에 들고 흐름을 이끕니다.

데모 발표 진행 대본

    [열기]  "지금부터 ___팀명___ 의 데모를 시작하겠습니다."
    [전환] 파트 넘길 때: "다음은 __이름__ 이(가)
            __파트__ 를 이어가겠습니다."
    [시연 안내] "실제 화면으로 보여드리겠습니다. 화면 봐주세요."
    [질문 받기] "질문 있으실까요? 편하게 말씀해 주세요."
    [닫기]  "저희 발표를 들어주셔서 감사합니다.
            8주간 정말 즐거웠습니다."

✅이해 확인

발표 직전 진행자에게:

- "파트가 넘어갈 때 이름을 불러서 넘겨줄 거죠?"
- "질문이 아무도 없으면 어떻게 자연스럽게 닫을래요?"

⚠️흔한 실수
실수 시연 중 앱이 멈추자 학생이 굳어서 말을 잃는다.
대처 멘토가 즉시 개입해 "이런 경우엔 준비한 녹화 영상으로 보여드릴게요"라며 백업 화면 녹화로 전환. (그래서 화·수에 30초 녹화를 남겨둔 것.) 학생을 탓하지 않는다.
Day 5 · 세션 3 · 오후

### 최종 평가 · 전환 면담 (1:1)

약 90분 (1인당 약 20분 + 마무리)
🎯학습목표

- 멘토 평가 + 데모 + 자기평가를 루브릭으로 종합해 전환 결과를 전달한다.
- 결과가 무엇이든 성장을 인정하고, 다음 3개월 성장목표를 함께 세운다.

🕘진행표 (1인 기준)
0–3분
따뜻하게 열기. 8주 고생을 먼저 인정하며 긴장을 풀어줌.
3–8분
함께 돌아보기. 자기평가서를 같이 보며 성장한 지점을 짚음.
8–13분
결과 전달. 루브릭 종합 결과(전환/조건부/미전환)를 분명하고 다정하게.
13–18분
다음 3개월 목표. 결과와 무관하게 구체적 성장목표 2~3개를 함께 적음.
18–20분
닫기. 감사와 응원. 언제든 물어보라는 말로 문을 열어둠.
💬멘토 스크립트
멘토 — 전환 결정 시

"결론부터 말할게요. OO, 정식으로 함께하게 됐어요. 축하해요! 데모에서 보여준 완성도랑, 막혔을 때 끝까지 파고드는 태도가 특히 좋았어요. 다음 3개월은 이 세 가지를 같이 키워봐요."

멘토 — 조건부 전환 시

"OO은 '조건부 전환'이에요. 무슨 뜻이냐면, 가능성은 충분히 봤고 딱 한두 가지만 더 채우면 된다는 거예요. 부족하다는 게 아니라 '거의 다 왔다'는 신호예요. 앞으로 3개월 동안 이 부분을 이렇게 채워가면 돼요. 제가 계속 봐줄게요."

멘토 — 미전환 시

"OO, 이번엔 정식 전환까지는 이르지 못했어요. 그런데 이건 OO이 못했다는 뜻이 절대 아니에요. 8주 전과 지금을 비교하면 정말 많이 자랐어요. 지금 이 성장 방향을 이렇게 이어가면 분명히 좋은 개발자가 돼요. 오늘 결과보다 앞으로가 훨씬 길어요."

✍️실습 · 최종 면담 기록지

멘토는 면담마다 기록지를 채우고, 다음 3개월 목표는 수습생과 함께 소리 내어 적습니다.

최종 평가 · 전환 면담 기록지 (멘토 작성)

    수습생: ______   트랙: ☐ 개발  ☐ 디자인

    [루브릭 종합]
      멘토 평가 __ / 데모 __ / 자기평가 __
    [전환 결정]  ☐ 전환   ☐ 조건부 전환   ☐ 미전환
    [결정의 근거 — 잘한 점 먼저]
      ________________________________

    [다음 3개월 성장목표 — 함께 작성]
      ① ____________________________
      ② ____________________________
      ③ ____________________________

    멘토 서명 ______   면담일 2026-__-__

진행 팁: 결과가 무엇이든 "잘한 점 → 결과 → 앞으로"의 순서를 지키세요. 결과를 먼저 던지면 뒤 이야기가 들리지 않습니다.

✅이해 확인 (멘토 셀프)

각 면담을 닫기 전에 멘토 스스로 점검합니다.

- 결과를 분명한 단어로 전달했는가? (에둘러 말해 오해를 남기지 않았는가)
- 미전환·조건부라도 다음 3개월 목표를 함께 손에 쥐여 보냈는가?
- 이 학생이 방을 나설 때 주눅이 아니라 방향을 안고 나가는가?

⚠️흔한 실수
실수 미전환을 전하기 미안해 말을 흐려서, 학생이 결과를 정확히 이해하지 못한 채 나간다.
대처 다정함과 명확함은 반대말이 아니다. "결과는 미전환이에요"를 분명히 말한 뒤, 곧바로 성장과 다음 목표로 시간을 충분히 쓴다.
실수 전환된 학생에게 칭찬만 하고 다음 목표를 안 준다.
대처 전환도 끝이 아니라 시작이다. 잘한 학생일수록 다음 3개월 성장목표를 더 구체적으로 함께 세운다.

8주 과정 완주를 축하합니다. 첫 주 `console.log("Hello")`에서 시작해, 오늘 동작하는 데모를 경영진 앞에서 발표하기까지 — 네 명 모두 놀랍게 성장했습니다. 여기가 끝이 아니라 진짜 시작입니다. 각자 손에 쥔 다음 3개월 성장목표와 함께, "고객과 함께 더 나은 세상을 만들어 나가는" AWESOMEDEV의 동료로 계속 나아가요.