6블록 틀(학습목표 · 진행표 · 멘토 스크립트 · 실습 · 이해 확인 · 흔한 실수)은 1주차 강의안과 동일합니다. 각 세션 카드를 위에서 아래로 그대로 읽어 내려가며 진행하면 됩니다.

MON월

## 티켓 배정 · 설계 합의

오늘의 목표 · 각자 실제 티켓 1건을 배정받고, 접근 방법과 예상 소요를 멘토와 합의한다.
Day 1 · 세션 1 · 오전

### 실무 심화 포인터 ① — React 상태 관리 한눈에

소요 40분 (오전 기본기 대체)
🎯학습목표

- "상태(state)"가 무엇인지, 왜 컴포넌트마다 따로 관리하는지 한 문장으로 말할 수 있다.
- 우리 웹(React)에서 상태가 화면을 어떻게 다시 그리는지 큰 그림을 그린다.

🕘진행표
0:00
도입 — "지난 4주는 기본기였고, 오늘부터는 실무 근육이에요"라고 분위기 전환
0:05
개념 — 상태 = "화면이 기억해야 하는 값". 카운터 예시로 `useState` 시연
0:20
확장 — props로 값 내려주기 vs 상태 끌어올리기 개념만 그림으로
0:32
연결 — 오늘 배정될 티켓에서 상태를 만질 수도 있다고 예고
💬멘토 스크립트
멘토

"자, 오늘부터 아침 기본기 시간은 끝났어요. 대신 실무에서 매일 쓰는 걸 아주 짧게 짚고 갈 거예요. 부담 갖지 말고 '아 이런 게 있구나' 정도만 담아 가면 돼요."

"상태라는 건 어렵게 생각할 거 없어요. 버튼 누르면 숫자가 올라가는 화면, 그 숫자를 React가 어딘가 기억하고 있어야 하잖아요? 그 기억하는 값이 상태예요."

(카운터를 직접 눌러 숫자가 바뀌는 걸 보여 주며) 지금 이거, 우리가 만든 게 아니라 상태가 바뀌니까 React가 알아서 다시 그린 거예요.

✍️실습 안내

포인터 세션입니다. 깊게 들어가지 말고, 개념 소개 후 곧바로 티켓 배정으로 넘어가세요.

- 더 촘촘한 CS 기초가 필요하면 CS 기본기 4주 커리큘럼 문서의 해당 일차를 진행하되, 5주차는 원칙적으로 티켓 실무에 시간을 몰아 줍니다.

⚠️흔한 실수
실수 · 상태 관리를 여기서 완벽히 가르치려다 오전을 다 씀.
대처 · "티켓 하면서 필요할 때 다시 볼게요"로 끊고 넘어가세요. 오늘 핵심은 티켓 배정입니다.
Day 1 · 세션 2 · 오전

### 티켓 배정 — 나에게 맞는 첫 티켓 고르기

소요 70분
🎯학습목표

- 자기 수준에 맞는 난이도 ★~★★ 티켓 1건을 배정받고 내용을 자기 말로 다시 설명한다.
- 티켓의 "완료 조건(Done)"이 무엇인지 명확히 짚는다.

🕘진행표
0:00
백로그 열기 — 이슈 트래커에서 수습용으로 골라 둔 티켓 5~6개를 함께 훑기
0:15
난이도 설명 — ★=하루 안, ★★=2~3일 예상이라고 눈금 맞추기
0:25
1:1 배정 — 개발 3명 각자 1건, 디자이너 1명은 개선 디자인 1건
0:45
되말하기 — 각자 자기 티켓을 30초로 요약해 보게 함
1:00
완료 조건 합의 — "무엇이 되면 끝인가"를 티켓에 한 줄로 적기
💬멘토 스크립트
멘토

"오늘부터 여러분은 관람객이 아니라 선수예요. 진짜 우리 제품에 들어갈 코드를 짜는 거예요. 겁먹을 필요 없어요. 여러분이 감당할 수 있는 크기로 티켓을 골라 뒀거든요."

"별 하나짜리는 하루 안에 끝낼 수 있는 크기, 별 둘은 2~3일 걸리는 크기예요. 지금은 작게 시작하는 게 훨씬 좋아요. 작은 걸 확실히 끝내는 게 큰 걸 반쯤 하다 마는 것보다 백 배 나아요."

(배정 후) 이제 이 티켓, 저한테 다시 설명해 볼래요? 여러분 말로 설명이 되면 반은 이해한 거예요.

✍️워크시트 — 티켓 이해 카드

각자 아래 대본의 빈칸을 채워 멘토에게 제출합니다. 채우지 못하는 칸이 있으면 그게 곧 오늘 물어봐야 할 질문이에요.

티켓 이해 카드 (빈칸 채우기)

    티켓 번호: #____   제목: ________________   난이도: ★ / ★★

    이 티켓을 한 문장으로: "____________을(를) ____________하게 만든다."

    손대야 할 화면/파일(추측): ________________

    완료 조건(이게 되면 끝): ________________

    지금 당장 모르는 것 1가지: ________________

✅이해 확인

다음 자리로 넘어가기 전, 각자에게 물어보세요.

- "이 티켓은 무엇이 되면 끝인가요?" — 완료 조건을 자기 말로 답할 수 있는가
- "어느 화면/파일을 먼저 열어 볼 것 같아요?" — 시작점을 짚는가

⚠️흔한 실수
실수 · 욕심내서 별 셋짜리 큰 티켓을 달라고 함.
대처 · "이번 주는 사이클 한 바퀴를 도는 게 목표예요. 크기보다 완주가 중요해요"라고 방향을 잡아 주세요.
Day 1 · 세션 3 · 오후

### 설계 합의 — 어떻게 풀지 먼저 그려 보기

소요 90분
🎯학습목표

- 코드를 짜기 전에 "접근 방법"을 글로 먼저 적고 멘토와 합의한다.
- 예상 소요 시간을 스스로 추정해 본다(맞고 틀림은 나중에 확인).
- 디자이너는 개선 디자인 1건의 방향을 개발 반영까지 염두에 두고 잡는다.

🕘진행표
0:00
코드 탐색 — 관련 화면/컴포넌트를 열어 "지금 어떻게 돌아가나" 읽기
0:25
접근 계획 쓰기 — 아래 대본으로 3~5단계 계획을 글로 작성
0:50
1:1 리뷰 — 멘토가 한 명씩 계획을 같이 읽고 구멍 짚기
1:10
소요 추정 — 각 단계에 예상 시간 적기, 합계 내기
1:20
합의 도장 — "이 방향으로 갑시다" 확정, 내일 착수 준비 완료
💬멘토 스크립트
멘토

"바로 코드부터 치고 싶은 마음 알아요. 근데 실무에서는 '어떻게 풀지' 먼저 적어 보는 게 습관이에요. 5분 적으면 5시간을 아껴요."

"계획이 틀려도 괜찮아요. 틀린 계획이라도 있으면, 제가 어디가 틀렸는지 짚어 줄 수 있거든요. 아무것도 없으면 저도 도와줄 수가 없어요."

(디자이너에게) OO는 이번에 화면 개선 하나를 맡을 거예요. 예쁘게만 끝나는 게 아니라, 개발자가 그걸 실제 화면에 반영하는 데까지 같이 따라가 볼 거예요.

✍️워크시트 — 접근 계획서

개발 3명은 아래 계획서를, 디자이너는 그 아래 디자인 계획서를 채웁니다. 이 문서가 곧 내일 아침의 출발점이에요.

접근 계획서 — 개발 트랙

    티켓 #____ 접근 계획

    1단계: ____________________  (예상 __분)
    2단계: ____________________  (예상 __분)
    3단계: ____________________  (예상 __분)
    (필요 시) 4단계: ________________  (예상 __분)

    총 예상 소요: 약 __시간

    확인이 필요한 것: ________________
    테스트로 확인할 방법: 화면에서 ____를 하면 ____가 보인다

개선 디자인 계획서 — 디자인 트랙

    개선 대상 화면: ________________

    지금의 문제(한 줄): ________________
    개선 방향(한 줄): ________________

    개발 반영 시 바뀌는 것: 색 / 간격 / 배치 / 문구 中 ____
    개발자에게 넘길 것: 시안 파일 / 색상값 / 여백 수치

✅이해 확인

오늘을 닫기 전 각자에게:

- "내일 아침 가장 먼저 열 파일/화면은 뭐예요?"
- "이 계획에서 제일 자신 없는 단계는 몇 번이에요?" — 불안한 곳을 미리 드러내게

⚠️흔한 실수
실수 · 계획을 "코드를 짠다" 한 줄로 뭉뚱그림.
대처 · "어디를, 무엇으로, 어떻게 바꾸는지"로 쪼개 달라고 되물어 주세요. 쪼개지는 순간 스스로 길이 보입니다.
TUE화

## 구현 사이클 시작 · 중간보고

오늘의 목표 · 계획대로 코드를 짜기 시작하고, 하루 끝에 중간보고로 진행 상황을 공유한다.
Day 2 · 세션 1 · 오전

### 실무 심화 포인터 ② — Spring Boot 계층 구조

소요 35분 (오전 기본기 대체 · 포인터)
🎯학습목표

- Controller → Service → Repository의 3층이 각각 무슨 일을 하는지 한 줄로 구분한다.

🕘진행표
0:00
비유 — 식당 비유: 홀(Controller)·주방(Service)·창고(Repository)
0:12
코드 투어 — 우리 백엔드에서 실제 3개 파일을 열어 층을 짚기
0:28
연결 — "네 티켓이 어느 층을 건드리는지" 각자 답하기
💬멘토 스크립트
멘토

"백엔드는 식당이라고 생각하면 쉬워요. 손님 주문 받는 홀이 Controller, 요리하는 주방이 Service, 재료 꺼내 오는 창고가 Repository예요. 각자 자기 일만 해요."

"왜 이렇게 나눌까요? 요리사가 창고 정리까지 하면 정신없잖아요. 나눠 놓으면 고칠 데를 딱 찾기 쉬워요. 여러분 티켓도 '어느 층 문제인지'만 알면 절반은 찾은 거예요."

✍️실습 안내

포인터 세션입니다. Java는 보조 언어이니 문법을 깊게 다루지 말고 "층 구분" 감만 주고 마무리하세요.

- 더 다지고 싶으면 CS 기본기 4주 커리큘럼 문서의 해당 일차를 진행합니다.

⚠️흔한 실수
실수 · 프론트 티켓을 받은 학생이 "나랑 상관없네" 하고 흘려들음.
대처 · "API를 부르는 쪽도 서버가 어떻게 나뉘는지 알면 소통이 빨라져요"라고 연결해 주세요.
Day 2 · 세션 2 · 오전~오후

### 1단계 구현 — 작은 성공을 먼저 만들기

소요 180분 (중간 휴식 포함)
🎯학습목표

- 어제 계획서의 1단계를 실제로 코드로 옮겨 "화면에서 눈에 보이는 변화" 하나를 만든다.
- 막혔을 때 15분 규칙(15분 혼자 → 그래도 안 되면 질문)을 지킨다.

🕘진행표
0:00
브랜치 생성 — 티켓 번호로 작업 브랜치 만들기(멘토가 옆에서 확인)
0:15
몰입 구현 — 각자 1단계 작업. 멘토는 순회하며 화면 너머로 관찰
1:20
중간 점검 — "지금 뭐가 됐고 뭐가 안 되나" 30초씩 돌아가며
1:35
이어서 구현 — 걸린 사람은 멘토가 붙어 같이 디버깅
2:50
커밋 — 오늘까지 된 만큼 의미 있는 단위로 커밋 남기기
💬멘토 스크립트
멘토

"오늘 목표는 티켓을 다 끝내는 게 아니에요. '화면에서 뭔가 하나 바뀌는 걸' 만드는 거예요. 버튼 하나라도 원하는 대로 움직이면 오늘은 대성공이에요."

"막히면요, 15분만 혼자 붙잡아 봐요. 그래도 안 풀리면 바로 손 들어요. 15분 넘게 혼자 끙끙대는 건 용기가 아니라 시간 낭비예요. 질문하는 게 실력이에요."

(에러가 났을 때) 에러 났다고 겁먹지 말고, 빨간 글씨를 소리 내서 같이 읽어 봐요. 대부분 답이 거기 적혀 있어요.

✍️실습 — 오늘의 커밋

실습 결과물: 티켓 브랜치에 최소 1개의 의미 있는 커밋. 커밋 메시지는 아래 형식으로 적게 하세요.

커밋 메시지 · 빈칸 채우기

    유형 선택: feat / fix / style
    한 줄 요약: ____를 ____하게 바꿈

    예) feat: 로그인 버튼 색을 브랜드 색으로 교체
    예) fix: 목록이 빈 화면일 때 안내 문구 표시

✅이해 확인

커밋 전 각자에게:

- "이 변화를 화면 어디서 확인할 수 있어요?" — 눈으로 검증 가능한가
- "방금 커밋, 제목만 봐도 뭘 했는지 알 수 있어요?"

⚠️흔한 실수
실수 · 하루 종일 짠 걸 한 번에 거대 커밋으로 몰아 넣음.
대처 · "화면에서 확인 가능한 변화 하나 = 커밋 하나"로 잘라 달라고 안내하세요.
Day 2 · 세션 3 · 오후

### 첫 중간보고 — 30초로 오늘을 말하기

소요 30분
🎯학습목표

- "한 것 / 막힌 것 / 내일 할 것"을 30초 안에 말하는 중간보고 형식을 익힌다.

🕘진행표
0:00
형식 소개 — 중간보고 3줄 틀 안내
0:05
돌아가며 보고 — 4명이 각자 30초~1분 발표
0:20
멘토 피드백 — 막힌 지점에 대해 내일 방향 한 줄씩
💬멘토 스크립트
멘토

"실무에서는 매일 이렇게 짧게 보고해요. 잘한 걸 자랑하는 자리가 아니라, 막힌 걸 나누는 자리예요. 막혔다고 말하는 게 제일 프로다운 거예요."

(발표가 위축될 때) 오늘 못 끝냈어도 괜찮아요. 어디까지 왔는지만 정확히 말해 주면 저는 그걸로 충분해요.

✍️워크시트 — 중간보고 3줄

발표 전 각자 아래 3줄을 채워 놓고 보고합니다. 매일 같은 형식을 씁니다.

중간보고 카드 (매일 사용)

    오늘 한 것:  ________________
    막힌 것:     ________________ (없으면 "없음")
    내일 할 것:  ________________

✅이해 확인

보고 후 확인:

- 모두 3줄 형식으로 말했는가 (장황하게 늘어놓지 않았는가)
- 막힌 사람이 솔직하게 "막혔다"고 말했는가

⚠️흔한 실수
실수 · "그냥 다 잘 됐어요"로 뭉개고 막힌 걸 숨김.
대처 · "잘 안 된 것 딱 하나만 말해 볼까요?"로 구체 질문을 던져 안전하게 꺼내게 하세요.
WED수

## 코드리뷰 받고 반영하기

오늘의 목표 · 처음으로 코드리뷰를 받고, 지적을 감정이 아닌 개선으로 받아들여 반영한다.
Day 3 · 세션 1 · 오전

### PR 올리기 — 리뷰받을 수 있는 모양 만들기

소요 90분
🎯학습목표

- 지금까지 작업을 Pull Request로 올리고, 설명을 남에게 읽히는 글로 적는다.
- "무엇을 왜 바꿨는지"를 리뷰어가 이해할 수 있게 정리한다.

🕘진행표
0:00
PR 개념 — "내 코드를 봐 주세요"라고 정식으로 요청하는 것
0:10
본문 작성 — 아래 PR 템플릿으로 각자 설명글 작성
0:40
셀프 점검 — 올리기 전 스스로 코드 한 번 다시 읽기
1:00
PR 생성 — 멘토를 리뷰어로 지정해 올리기
1:15
디자이너 병행 — 시안을 개발자에게 정식 전달, 반영 항목 합의
💬멘토 스크립트
멘토

"PR은 '제 코드 좀 봐 주세요' 하고 정식으로 부탁하는 거예요. 그래서 설명을 잘 적어야 해요. 리뷰어는 여러분 머릿속을 못 보니까, 무엇을 왜 바꿨는지 글로 알려 줘야 해요."

"올리기 전에 딱 한 번, 내 코드를 남의 코드라 생각하고 읽어 봐요. 오타나 지우다 만 흔적, 거기서 절반은 스스로 잡혀요."

✍️워크시트 — PR 설명 템플릿

아래 빈칸을 채워 PR 본문으로 붙여 넣습니다. 리뷰어가 이 글만 읽고도 맥락을 알 수 있어야 합니다.

Pull Request 본문 · 빈칸 채우기

    ## 무엇을 (What)
    ____________________

    ## 왜 (Why) — 어떤 티켓/문제 때문에
    티켓 #__ · ____________________

    ## 어떻게 확인하나 (How to test)
    1. ____화면에 들어간다
    2. ____를 누른다
    3. ____가 보이면 정상

    ## 아직 자신 없는 부분 (리뷰어가 봐 줬으면)
    ____________________

✅이해 확인

PR 올린 뒤:

- "이 PR 제목만 봐도 뭘 했는지 알 수 있어요?"
- "리뷰어가 어떻게 테스트하면 되는지 적혀 있어요?"

⚠️흔한 실수
실수 · 설명 없이 코드만 덜렁 올림("보면 알겠죠").
대처 · "리뷰어는 여러분이 뭘 고민했는지 몰라요. 3줄이라도 적어 주면 리뷰가 훨씬 빨라져요"라고 이유를 붙여 안내하세요.
Day 3 · 세션 2 · 오후

### 리뷰 반영 — 지적을 성장으로 바꾸기

소요 150분
🎯학습목표

- 멘토의 리뷰 코멘트를 하나씩 이해하고, 고칠 것과 물어볼 것을 분류한다.
- 리뷰를 인신공격이 아니라 코드에 대한 이야기로 받아들인다.
- 반영 후 "무엇을 왜 바꿨는지"를 코멘트로 답한다.

🕘진행표
0:00
리뷰 함께 읽기 — 멘토가 남긴 코멘트를 학생과 한 줄씩 소리 내 읽기
0:25
분류 — 코멘트를 "바로 고침 / 물어보고 고침 / 이번엔 보류" 3칸으로
0:45
반영 구현 — 각자 코멘트 반영. 멘토는 순회하며 도움
2:00
답글 달기 — 각 코멘트에 "이렇게 고쳤어요" 답 코멘트
2:20
재푸시 — 반영 커밋을 PR에 올려 리뷰어에게 재확인 요청
💬멘토 스크립트
멘토

"리뷰 코멘트 보고 마음 상하는 거, 아주 자연스러운 거예요. 근데 하나만 기억해요. 저는 여러분을 지적한 게 아니라, 코드를 같이 더 좋게 만들려는 거예요. 코드랑 여러분은 다른 사람이에요."

"모든 코멘트를 다 고칠 필요도 없어요. 이해가 안 되면 '이건 왜 그런가요?' 하고 물어봐요. 물어보는 거, 반박이 아니라 배움이에요. 오히려 멋진 거예요."

(반영 후) 고쳤으면 '이렇게 바꿨어요' 하고 답글 달아 줘요. 그래야 저도 다시 볼 때 빨라요.

✍️워크시트 — 리뷰 분류표

코멘트를 감정 없이 처리하기 위한 표입니다. 코멘트 개수만큼 줄을 늘려 채우세요.

리뷰 코멘트 분류 · 빈칸 채우기

    코멘트 1: "____________"
     → 처리: 바로 고침 / 물어보고 / 보류
     → 내가 한 일: ____________

    코멘트 2: "____________"
     → 처리: 바로 고침 / 물어보고 / 보류
     → 내가 한 일: ____________

✅이해 확인

반영 후:

- "고친 것 중에 왜 고쳤는지 모르는 것은 없어요?" — 이해 없이 시키는 대로만 고치지 않았는가
- "이해 안 되는 코멘트에 대해 질문을 남겼어요?"

⚠️흔한 실수
실수 · 코멘트를 자기 부정으로 받아들여 표정이 굳음.
대처 · "이건 OO가 못한 게 아니라, 원래 다들 처음엔 이렇게 짜요"라고 보편화해 주세요. 리뷰 톤은 항상 코드에 한정합니다.
THU목

## 마무리 구현 · 배포 준비

오늘의 목표 · 남은 구현을 끝내 완료 조건을 채우고, 배포 직전 최종 점검까지 마친다.
Day 4 · 세션 1 · 오전

### 완료 조건 채우기 — "끝"의 기준에 도달하기

소요 160분
🎯학습목표

- 월요일에 적은 완료 조건을 하나씩 대조하며 남은 작업을 끝낸다.
- "되겠지"가 아니라 화면에서 직접 눌러 보며 확인한다.

🕘진행표
0:00
완료 조건 소환 — 티켓 이해 카드의 완료 조건을 다시 꺼내 읽기
0:10
남은 구현 — 아직 안 채워진 조건을 목표로 작업
1:20
직접 검증 — 각 조건을 화면에서 눌러 보며 O/X 표시
2:00
디자이너 반영 확인 — 개발자 화면에서 개선 디자인이 실제로 보이는지 함께 확인
2:20
커밋 · 재푸시 — 완료분 커밋하고 PR 갱신
💬멘토 스크립트
멘토

"오늘은 '끝'에 도달하는 날이에요. 근데 '끝'이 뭐였죠? 월요일에 우리가 적었잖아요. 그 문장을 지금 다시 꺼내서, 한 줄 한 줄 진짜 됐는지 눌러 봐요."

"'아마 될 거예요'는 안 돼요. 직접 눌러 보고 '됐어요'가 돼야 해요. 개발자는 눈으로 확인한 것만 믿어요."

(디자이너에게) OO 시안이 실제 화면에 들어갔는지 개발자 옆에서 같이 봐요. 여백 하나, 색 하나 다르면 지금 말해 줘야 해요.

✍️워크시트 — 완료 조건 체크

완료 조건을 그대로 옮겨 적고, 하나씩 직접 확인해 O/X를 매깁니다. 전부 O가 되어야 티켓 완료입니다.

완료 조건 체크 · 직접 눌러 확인

    완료 조건 1: ____________  → 확인: O / X
    완료 조건 2: ____________  → 확인: O / X
    완료 조건 3: ____________  → 확인: O / X

    전부 O 인가? 예 / 아니오
    아니오라면, 남은 것: ____________

✅이해 확인

세션 끝에:

- "완료 조건 모두 O인가요? 하나라도 X면 뭐가 남았어요?"
- "방금 그거, 말로만이 아니라 화면에서 직접 눌러 봤어요?"

⚠️흔한 실수
실수 · 코드가 컴파일되니 "됐다"고 판단하고 실제 동작은 안 눌러 봄.
대처 · "컴파일은 문법이 맞다는 거지, 원하는 대로 됐다는 게 아니에요. 화면에서 눌러 봐요"라고 반드시 재현시키세요.
Day 4 · 세션 2 · 오후

### 배포 준비 — 세상에 나가기 직전 점검

소요 100분
🎯학습목표

- 내 변경이 배포되면 실제 사용자(고객사 서비스)에게 나간다는 무게를 이해한다.
- 배포 전 최종 체크리스트를 스스로 통과시킨다.

🕘진행표
0:00
무게 인식 — "이 코드가 KT엠모바일·KT알파·핀업 화면에 나갈 수도 있다"
0:10
최종 리뷰 승인 — 멘토가 PR을 마지막으로 확인하고 승인
0:35
체크리스트 — 아래 배포 전 점검표를 각자 통과
1:05
머지 준비 — 충돌 없는지 확인, 내일 배포할 상태로 정리
💬멘토 스크립트
멘토

"이거 배포하면 진짜로 나가요. 우리 회사 슬로건이 '고객과 함께 더 나은 세상을 만들어 나가는 기업'이잖아요. 여러분 코드가 그 '더 나은 세상'의 아주 작은 조각이 되는 거예요. 뿌듯하죠?"

"그래서 나가기 전에 딱 한 번 더 봐요. 겁주려는 게 아니라, 프로는 항상 배포 전에 심호흡 한 번 하고 체크리스트를 봐요."

✍️워크시트 — 배포 전 체크리스트

모든 칸에 체크가 들어가야 내일 배포로 넘어갑니다. 하나라도 비면 오늘 채웁니다.

배포 전 최종 점검 · 빈칸 채우기

    [ _ ] 완료 조건이 전부 O 다
    [ _ ] 리뷰 코멘트에 다 답했고, 멘토가 승인했다
    [ _ ] 화면에서 직접 눌러 확인했다
    [ _ ] 다른 기능을 망가뜨리지 않았다(주변 화면도 눌러 봄)
    [ _ ] (디자인 티켓) 시안과 실제 화면이 같다

    한 줄 소감: ____________

✅이해 확인

퇴근 전:

- "체크리스트 전부 체크됐어요?"
- "혹시 주변 화면도 눌러 봤어요? 내 것만 보다 옆을 깨뜨리는 일이 많아요"

⚠️흔한 실수
실수 · 내 티켓 화면만 확인하고, 그 변경이 옆 기능을 깬 걸 못 봄.
대처 · "고친 화면의 이웃 화면 하나만 더 눌러 봐요"라고 습관을 심어 주세요.
FRI금

## 배포 확인 · 회고 · 1:1

오늘의 목표 · 티켓을 실제 배포로 마무리하고, 한 주를 돌아보며 1:1로 개인 피드백을 받는다.
Day 5 · 세션 1 · 오전

### 배포 & 확인 — 내 첫 티켓이 살아 움직인다

소요 90분
🎯학습목표

- 승인된 PR을 머지하고, 배포된 화면에서 내 변경이 실제로 반영됐는지 확인한다.
- 배포 후 확인(사후 점검)까지가 한 사이클임을 체득한다.

🕘진행표
0:00
머지 — 멘토 입회하에 PR 머지(배포 트리거)
0:15
배포 대기 — 빌드/배포가 도는 동안 무엇이 일어나는지 설명
0:35
사후 확인 — 배포된 환경에서 완료 조건을 다시 O/X로 재검증
1:05
티켓 종료 — 이슈 트래커에서 티켓을 Done으로 옮기고 코멘트
💬멘토 스크립트
멘토

"자, 머지 버튼 눌러 볼까요? 이 순간이에요. 여러분이 짠 코드가 진짜 우리 제품 안으로 들어가는 순간. 축하해요, 이거 아무나 하는 거 아니에요."

"근데 배포했다고 끝이 아니에요. 배포된 화면 가서 진짜 됐는지 다시 눌러 봐야 해요. '올렸으니 됐겠지'가 사고의 시작이거든요."

(확인되면) 봤죠? 이게 여러분 거예요. 이번 주에 여러분은 관람객에서 선수가 됐어요.

✍️실습 — 배포 후 사후 점검

실습 결과물: 배포된 환경에서 완료 조건 재검증 완료 + 티켓 Done 처리. 아래 종료 코멘트를 티켓에 남깁니다.

티켓 종료 코멘트 · 빈칸 채우기

    배포 완료했습니다. ✅

    바뀐 것: ____________
    배포 환경에서 확인함: ____화면에서 ____ 정상
    배운 점 한 줄: ____________

✅이해 확인

티켓 닫기 전:

- "배포된 환경에서 확인했어요? (내 PC 말고)"
- "티켓을 Done으로 옮기고 종료 코멘트를 남겼어요?"

⚠️흔한 실수
실수 · 머지만 하고 배포 환경 확인 없이 티켓을 닫음.
대처 · "머지 ≠ 배포 확인. 배포된 화면에서 한 번 더 눌러야 진짜 끝이에요"라고 마지막 절차를 지키게 하세요.
Day 5 · 세션 2 · 오후

### 주간 회고 — 사이클 한 바퀴를 돌아보기

소요 70분
🎯학습목표

- "착수→구현→리뷰→배포" 한 사이클에서 배운 것과 어려웠던 것을 스스로 정리한다.
- 다음 티켓에서 다르게 해 볼 것 1가지를 뽑는다.

🕘진행표
0:00
개인 회고 작성 — 아래 회고 카드 각자 채우기
0:20
돌아가며 공유 — 4명이 배운 점·어려웠던 점 나누기
0:45
공통 주제 정리 — 멘토가 공통으로 나온 어려움을 칠판에 묶기
1:00
다음 다짐 — 각자 "다음엔 이걸 다르게" 1줄 발표
💬멘토 스크립트
멘토

"회고는 반성문이 아니에요. '뭘 배웠나, 다음엔 뭘 다르게 할까'를 챙기는 시간이에요. 잘한 것도 꼭 적어요. 자기가 뭘 잘했는지 알아야 그걸 또 하거든요."

(공유가 서로 비슷할 때) 봐요, 다들 비슷한 데서 막혔죠? 그건 여러분이 못해서가 아니라 원래 거기가 어려운 지점이라는 거예요.

✍️워크시트 — 주간 회고 카드

각자 채워서 제출합니다. 멘토는 이 카드를 개인 성장 기록으로 보관합니다.

주간 회고 · 빈칸 채우기

    이번 주 내가 배포한 티켓: #__

    가장 뿌듯했던 것: ____________
    가장 어려웠던 것: ____________
    리뷰에서 얻은 것: ____________

    다음 티켓에서 다르게 해 볼 것 1가지:
    ____________

✅이해 확인

회고 마무리에:

- 모두 배운 것 + 다르게 할 것을 각각 1개 이상 적었는가
- 회고가 자책이 아니라 다음 행동으로 끝났는가

⚠️흔한 실수
실수 · 회고가 "그냥 힘들었어요"로 끝나 배움이 안 남음.
대처 · "구체적으로 어느 단계에서, 왜 힘들었어요?"로 파고들어 다음 행동으로 연결하세요.
Day 5 · 세션 3 · 오후

### 1:1 개인 피드백 — 한 명씩 마주 앉기

소요 60분 (1인당 12~15분)
🎯학습목표

- 수습생 개개인이 자기주도성·코드 품질 성장·반복 지적 여부에 대한 개인 피드백을 받는다.
- 멘토는 평가 체크포인트에 근거해 다음 주 개인 목표를 함께 정한다.

🕘진행표
0:00
순번 안내 — 나머지는 다음 주 티켓 후보를 훑어보게 하고 1명씩 호출
0:02
먼저 듣기 — "이번 주 스스로 어땠어요?" 학생 말을 먼저
0:06
구체 피드백 — 잘한 점 → 성장 지점 → 반복하지 말 것 순서로
0:11
다음 목표 합의 — 개인 목표 1개를 함께 적기
💬멘토 스크립트
멘토

"오늘은 OO 얘기만 들을게요. 이번 주 스스로 어땠어요? 먼저 들어 보고 싶어요."

"제가 본 건요, OO는 막혔을 때 15분 규칙 잘 지켰어요. 그게 자기주도성이에요. 대신 같은 리뷰 지적이 두 번 나온 게 하나 있었어요. 다음 주엔 리뷰 받은 걸 메모해 두고 다음 티켓에서 먼저 챙겨 보면 좋겠어요."

(마무리) 이번 주 정말 잘했어요. 진짜 티켓 하나를 세상에 내보냈잖아요. 다음 주엔 이 목표 하나만 같이 챙겨 봐요.

✍️실습 — 평가 체크포인트 기록

멘토가 학생별로 아래를 채워 평가 루브릭에 반영합니다. 학생과 화면을 같이 보며 합의한 목표를 남깁니다.

개인 피드백 기록 · 멘토 작성

    이름: ____   배포 티켓: #__

    자기주도성 (막힘 대처·질문 타이밍): 상 / 중 / 하 — 근거 한 줄
    코드 품질 성장 (첫날 대비): 상 / 중 / 하 — 근거 한 줄
    같은 지적 반복 여부: 없음 / 1회 / 반복 — 항목

    다음 주 개인 목표(합의): ____________

✅이해 확인

1:1 종료 시:

- 학생이 다음 주 개인 목표 1개를 자기 말로 확인했는가
- 피드백이 잘한 점으로 시작해 다음 행동으로 끝났는가

⚠️흔한 실수
실수 · 개선점만 잔뜩 말해 학생이 위축된 채로 주말을 맞음.
대처 · 잘한 점 → 성장 지점 → 다음 목표 순서를 지키고, 마지막 말은 반드시 격려로 닫으세요.

다음 주(6주차) 예고 · 실전 티켓 ② — 난이도를 한 칸 올린 티켓(★★~★★★)에 도전하고, 이번 주 개인 목표를 실제로 적용해 봅니다. 사이클을 더 빠르고 안정적으로 두 바퀴 돌리는 것이 목표예요.