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

MON
월

## 첫 소과제 배정 — 착수 전에 "어떻게 할지"부터

목표 · 안전한 소과제를 하나 받고, 코드를 짜기 전에 접근 방법을 멘토와 말로 맞춘다.
Day 1 · 세션 1 · 오전

### 아침 기본기 — 프로그램(언어)의 진화

40분 · 포인터 세션
🎯학습목표

- 기계어→어셈블리→고급언어, 절차형→객체지향→함수형의 큰 흐름을 한 문장으로 말할 수 있다.
- "왜 언어가 계속 바뀌어 왔는지"를 우리 스택(JS·Java) 예로 감 잡는다.

✍️실습 / 진행 안내

CS 기본기 4주 커리큘럼 문서의 W3 해당 일차를 그대로 진행합니다. 이 세션은 포인터(연결)용이니 30~40분 안에 마치고 본 세션으로 넘어갑니다.

- 커리큘럼 문서 W3 "언어의 진화" 파트를 화면 공유로 함께 읽기.
- 마무리 질문: "오늘 우리가 쓰는 JavaScript는 이 흐름의 어디쯤일까?" 한 명씩 짧게 답.

Day 1 · 세션 2 · 오전

### 첫 소과제 배정 — 안전한 것으로

70분
🎯학습목표

- 자기 이름이 붙은 이슈(과제)를 하나 받고, 무엇을 왜 하는지 자기 말로 설명한다.
- 과제 범위가 "아주 작다"는 것을 이해하고, 크게 벌리지 않는다.

🕘진행표
0–10분
오늘의 그림 설명. "이번 주는 첫 코드가 실제로 반영되는 주"라고 큰 그림부터.
10–35분
과제 배정. 개발 3명에게 안전 과제 1건씩 이슈로 부여(아래 예시 풀에서 선택).
35–55분
과제 읽기. 각자 이슈를 소리 내어 다시 설명 → 멘토가 범위 확인.
55–70분
디자이너 트랙 분기. 디자인 개선 과제 별도 배정(세션 3 참고).
💬멘토 스크립트
멘토

"오늘부터 여러분한테 진짜 코드베이스에서 할 일을 하나씩 줄 거예요. 겁먹지 않아도 돼요. 첫 과제는 일부러 아주 작고 안전한 걸로 골랐어요."

"예를 들면 버튼 문구에 오타가 있는 걸 고친다든가, 화면에 안 맞는 문장을 다듬는다든가, 로그 메시지를 조금 더 알아보기 쉽게 바꾸는 거예요. 하루 만에 세상을 바꾸는 게 목표가 아니라, 내가 고친 게 실제로 반영되는 걸 한 번 경험하는 게 목표예요."

Tip. 과제를 줄 때 "이건 망가뜨려도 되는 안전한 부분"이라고 분명히 말해 심리적 부담을 낮춘다.

✍️실습 — 안전 과제 예시 풀

멘토는 아래에서 각자 수준에 맞게 1건씩 고릅니다. 공통 조건: 반나절 안에 끝나고, 실패해도 서비스에 영향이 없는 것.

- 화면 버튼/안내 문구의 오타·어색한 문장 수정 (예: "저장되엇습니다" → "저장되었습니다").
- 비어 있는 화면의 안내 문구 한 줄 추가 (예: 목록이 없을 때 "아직 등록된 항목이 없어요").
- 버튼 간격·색·비활성 상태 같은 간단한 UI 다듬기.
- 서버 로그 메시지 개선 (무슨 일이 일어났는지 사람이 읽기 쉽게).

⚠️흔한 실수
실수 · 첫 과제를 "제대로 된 기능"으로 크게 주고 싶어진다.
대처 · 이번 주의 목적은 실력 검증이 아니라 사이클 경험이다. 일부러 작게 유지한다.
Day 1 · 세션 3 · 오후

### 착수 전 접근 방법 공유 (+ 디자이너 트랙)

80분
🎯학습목표

- 코드를 짜기 전에 "어디를 · 어떻게 고칠지"를 3~4줄로 먼저 말/글로 정리한다.
- 멘토의 짧은 확인을 받고 나서 손을 대는 습관을 만든다.
- (디자이너) 첫 디자인 개선 과제를 받고 범위를 정한다.

💬멘토 스크립트
멘토

"바로 코드부터 치고 싶은 마음 알아요. 그런데 실무에서는 손대기 전에 '어떻게 할 건지'를 한 번 말로 맞추는 것이 훨씬 빨라요. 엉뚱한 파일을 오래 헤매는 걸 막아주거든요."

"3~4줄이면 충분해요. 어느 파일을 볼 것 같은지, 어떻게 바꿀 생각인지, 확인은 어떻게 할 건지. 완벽하지 않아도 되니까 지금 생각나는 대로 적어봐요."

✍️워크시트 — 접근 방법 3줄 정리
접근 방법 공유 (빈칸을 채워 멘토에게 보내기)

    과제:  [예: 저장 버튼 문구 오타 수정]

    1) 어디를 고칠 것 같은가
       → [예: web의 저장 버튼 컴포넌트 파일일 것 같다]

    2) 어떻게 바꿀 생각인가
       → [예: 버튼 텍스트 문자열만 올바른 맞춤법으로 교체]

    3) 다 되면 어떻게 확인할 것인가
       → [예: 로컬에서 그 화면 열어 버튼 글자 직접 확인]

    막히면?  30분 넘게 혼자 헤매지 않고 멘토에게 물어본다. ✅

디자이너 트랙 (같은 시간, 별도 진행)

- 첫 디자인 개선 과제 배정: 빈 상태(empty state) 화면 또는 버튼의 상태(기본·hover·비활성) 정리.
- Figma에서 개선안을 만들고, "개발자가 그대로 만들 수 있게" 핸드오프 메모를 붙이는 것까지가 이번 주 목표라고 안내.
- 오늘은 범위만 확정: 무엇을 · 어느 화면을 개선할지 한 줄로 적어 멘토 확인.

✅이해 확인

퇴근 전 각자에게 확인:

- 내 과제를 한 문장으로 설명할 수 있는가?
- 접근 방법 3줄을 멘토에게 공유했는가?
- "막히면 30분 룰"이 뭔지 말할 수 있는가?

TUE
화

## 구현 시작 — 스스로 해보되, 30분 룰

목표 · 접근 방법대로 직접 손을 대고, 막히면 30분 안에 도움을 청한다. PR 초안까지.
Day 2 · 세션 1 · 오전

### 아침 기본기 (포인터)

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

- 어제 배운 언어의 진화 흐름을 오늘 과제와 한 줄로 연결한다.

✍️실습 / 진행 안내

CS 기본기 4주 커리큘럼 문서의 W3 해당 일차를 진행합니다. 짧게 복습 + 오늘 분량만.

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

### 직접 구현 — 30분 룰 실습

120분
🎯학습목표

- 어제 정리한 접근 방법대로 실제 코드를 수정한다.
- 혼자 30분 이상 막히면 스스로 손을 들어 도움을 청한다.
- 수정한 화면/동작을 로컬에서 직접 확인한다.

🕘진행표
0–15분
환경 확인. 브랜치 새로 파기 · 로컬 실행되는지 먼저 확인.
15–90분
구현. 각자 진행. 멘토는 순회하며 "막힌 지 몇 분 됐어요?" 물어 30분 룰 상기.
90–110분
동작 확인. 고친 부분을 직접 눈으로 확인.
110–120분
오늘 상태 메모. 어디까지 했고 뭐가 남았는지 3줄.
💬멘토 스크립트
멘토

"30분 룰 하나만 기억해요. 혼자 30분 넘게 같은 자리에서 막히면, 그때는 물어보는 게 맞아요. 오래 붙잡는 게 성실한 게 아니에요. 실무에선 막힌 걸 빨리 공유하는 사람이 더 신뢰받아요."

"물어볼 때는 '안 돼요'만 말고, '이걸 하려는데 여기서 이런 메시지가 떠요, 여기까진 해봤어요'까지 같이 말해주면 서로 훨씬 빨라요."

✍️실습 — 브랜치 & 커밋 기본

오늘의 최소 목표: 새 브랜치에서 수정 → 커밋 → 로컬 확인. 아래 순서를 그대로 따라합니다.

1. 최신 `main`을 받고, 내 과제용 브랜치를 새로 판다.
2. 접근 방법 3줄대로 파일을 찾아 수정한다.
3. 고친 화면/로그를 로컬에서 직접 확인한다.
4. 작은 단위로 커밋 메시지를 남긴다 (예: `fix: 저장 버튼 문구 오타 수정`).

⚠️흔한 실수
실수 · 막힌 걸 부끄러워 3시간을 혼자 헤맨다.
대처 · 30분 룰을 규칙으로 못박는다. 물어본 학생을 칭찬해 분위기를 만든다.
실수 · `main`에서 바로 수정한다.
대처 · "무조건 새 브랜치에서"를 첫날부터 몸에 배게 한다.
Day 2 · 세션 3 · 오후

### PR 초안 작성

60분
🎯학습목표

- PR(Pull Request)이 "리뷰해 달라고 내미는 요청서"임을 이해한다.
- 무엇을·왜 바꿨는지, 어떻게 확인했는지가 담긴 PR 설명을 쓴다.

✍️워크시트 — PR 설명 템플릿
PR 설명 (빈칸 채워 초안 올리기)

    ## 무엇을 바꿨나요
    - [예: 저장 버튼의 "저장되엇습니다" 오타를 "저장되었습니다"로 수정]

    ## 왜 바꿨나요
    - [예: 사용자에게 보이는 문구라 맞춤법이 틀리면 신뢰가 떨어짐]

    ## 어떻게 확인했나요
    - [예: 로컬에서 저장 후 토스트 문구를 직접 확인]

    ## 리뷰어에게
    - [예: 다른 화면에도 같은 오타가 있는지 봐주시면 좋겠어요]

✅이해 확인

PR 초안을 올리기 전 스스로 점검:

- 제목만 봐도 무엇을 한 PR인지 알 수 있는가?
- "어떻게 확인했는지"가 구체적으로 적혀 있는가?
- 이 브랜치가 `main`이 아닌 내 작업 브랜치인가?

WED
수

## 중간보고 — 진행 상황을 먼저 말하는 습관

목표 · 시키지 않아도 진행 상황을 짧게 보고하고, PR을 리뷰 받을 수 있게 완성한다.
Day 3 · 세션 1 · 오전

### 아침 기본기 (포인터)

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

- W3 커리큘럼의 남은 분량을 마무리하고 한 줄로 요약한다.

✍️실습 / 진행 안내

CS 기본기 4주 커리큘럼 문서의 W3 해당 일차를 진행합니다.

Day 3 · 세션 2 · 오전

### 중간보고 실습 — "3줄 보고"

70분
🎯학습목표

- 물어보기 전에 먼저 "지금 어디까지 됐는지" 보고하는 습관을 만든다.
- 보고를 짧고 구조적으로(한 것·할 것·막힌 것) 말한다.

💬멘토 스크립트
멘토

"실무에서 팀장이 제일 답답한 게 뭔지 알아요? 진행 상황이 안 보이는 거예요. 다 끝낼 때까지 아무 말이 없으면, 잘 되고 있는지 막혀 있는지 알 수가 없거든요."

"그래서 오늘은 '3줄 보고'를 연습할 거예요. 어제 뭘 했고, 오늘 뭘 할 거고, 막힌 건 뭔지. 딱 세 줄이면 돼요. 이걸 하루 한 번씩만 해도 신뢰가 확 올라가요."

✍️워크시트 — 3줄 중간보고 대본
중간보고 (팀 채널에 붙여넣기)

    [중간보고] [내 이름] · [날짜]

    ✅ 한 것:   [예: 저장 버튼 오타 수정하고 로컬 확인까지]
    ▶ 할 것:   [예: PR 설명 다듬고 리뷰 요청하기]
    ⚠ 막힌 것: [예: 없음 / 또는: 같은 오타가 다른 화면에도 있는지 확인 중]

진행: 각자 3줄 보고를 작성 → 팀 채널에 올리기 → 멘토가 한 명씩 짧게 피드백. "막힌 것: 없음"도 좋은 보고라고 알려준다.

⚠️흔한 실수
실수 · 보고가 "하고 있어요"처럼 뭉뚱그려진다.
대처 · 한 것·할 것·막힌 것 세 칸을 반드시 채우게 한다.
Day 3 · 세션 3 · 오후

### PR 완성 & 리뷰 요청 (+ 디자이너 핸드오프)

90분
🎯학습목표

- 리뷰 받을 수 있는 상태로 PR을 다듬고, 정식으로 리뷰를 요청한다.
- (디자이너) 개선안을 개발자가 바로 쓸 수 있게 핸드오프한다.

🕘진행표
0–40분
PR 마무리. 설명 채우기 · 불필요한 변경 없나 스스로 diff 훑기.
40–60분
리뷰 요청. 멘토를 리뷰어로 지정하고 팀 채널에 한 줄 공지.
60–90분
디자이너 핸드오프. Figma 링크 + 핸드오프 메모를 담당 개발자에게 전달.
✍️워크시트 — 디자이너 핸드오프 메모
디자인 핸드오프 (개발자에게 전달)

    화면:   [예: 목록 비어있을 때(빈 상태) 화면]
    Figma:  [링크]

    바뀐 점
    - [예: 빈 상태에 안내 문구 + 일러스트 추가]

    개발자가 봐야 할 값
    - 글자색: [예: 보조 텍스트 컬러]
    - 여백:   [예: 위아래 24, 좌우 16]
    - 버튼 상태: [기본 / hover / 비활성 각각 첨부]

    궁금하면: [디자이너 이름] 에게 물어보세요 🙂

✅이해 확인

오늘 끝나기 전:

- 개발 3명 모두 리뷰 요청된 PR이 있는가?
- PR에 내 변경만 들어 있는가(엉뚱한 파일 X)?
- 디자이너는 핸드오프 메모를 전달했는가?

THU
목

## 리뷰 반영 → 머지 → 배포 확인

목표 · 리뷰 피드백을 반영해 머지하고, 배포된 화면에서 내 변경이 실제로 보이는 걸 확인한다.
Day 4 · 세션 1 · 오전

### 코드리뷰 함께 읽기

70분
🎯학습목표

- 리뷰 코멘트가 "혼내는 게 아니라 같이 좋게 만드는 것"임을 안다.
- 코멘트를 하나씩 읽고, 무엇을 요청하는지 자기 말로 옮긴다.

💬멘토 스크립트
멘토

"제가 여러분 PR에 코멘트를 몇 개 달았어요. 미리 말할게요. 이건 잘못했다고 지적하는 게 아니에요. 저도 제 코드에 매일 리뷰를 받아요. 같이 더 좋게 만드는 대화예요."

"코멘트를 읽고 이해가 안 되면 '이게 무슨 뜻이에요?'라고 물어봐도 아주 좋아요. 리뷰는 원래 주고받는 거예요."

✍️실습 — 코멘트 옮겨 적기

각 리뷰 코멘트를 아래 형식으로 한 줄씩 정리한 뒤 반영을 시작합니다.

- 코멘트 요약: "무엇을 바꿔달라는가"
- 내 판단: "바로 반영 / 질문 필요"
- 반영 방법: "어디를 어떻게 고칠지 한 줄"

⚠️흔한 실수
실수 · 리뷰 코멘트를 지적으로 받아들여 위축된다.
대처 · 멘토가 먼저 "이건 잘했다"는 코멘트도 섞어 달아 균형을 준다.
Day 4 · 세션 2 · 오후

### 반영 → 머지 → 배포 확인 (하이라이트)

120분
🎯학습목표

- 리뷰 코멘트를 반영해 커밋을 추가하고 다시 리뷰를 받는다.
- 승인 후 머지하고, 배포된 화면에서 내 변경을 직접 확인한다.
- "내 코드가 실제로 반영된다"는 성공 경험을 명확히 인지한다.

🕘진행표
0–50분
반영. 코멘트대로 수정 → 커밋 추가 → "반영했어요" 코멘트로 알림.
50–70분
재확인 & 승인. 멘토가 재리뷰 → 승인(Approve).
70–90분
머지. 학생이 직접 머지 버튼을 누른다(멘토 옆에서).
90–120분
배포 확인. 배포 후 실제 화면/동작에서 내 변경이 보이는지 눈으로 확인.
💬멘토 스크립트
멘토

"자, 머지 버튼은 여러분이 직접 눌러요. 제가 대신 안 눌러요. 방금 여러분이 짠 코드가 우리 진짜 코드에 합쳐지는 순간이에요."

"그리고 배포가 끝나면, 실제 화면을 같이 열어봐요. 아까 고친 그 문구, 그 버튼이 실제 서비스에서 그대로 보일 거예요. 이게 바로 개발자가 일하는 이유 중 하나예요 — 내가 만든 게 세상에 나가는 거요."

✍️실습 — 배포 확인 체크
배포 확인 (머지 후 채워서 인증)

    머지한 PR: [제목/번호]

    배포 후 확인
    - 어디서 확인했나: [예: 스테이징 목록 화면]
    - 내 변경이 보이나: [예: "저장되었습니다" 문구로 정상 표시됨]
    - 캡처: [스크린샷 첨부]

    지금 기분 한 단어: [__________] 🎉

⚠️흔한 실수
실수 · 머지만 하고 배포 결과를 확인하지 않는다.
대처 · "머지 = 끝"이 아니라 배포 확인까지가 한 사이클임을 못박는다.
실수 · 배포가 늦어 세션 안에 반영이 안 보인다.
대처 · 안전 과제는 미리 배포 파이프라인을 확인해 두고, 안 되면 스테이징에서 확인.
FRI
금

## 회고 · 1:1 · 퀴즈

목표 · 첫 실무 사이클을 돌아보고, 잘한 점·아쉬운 점을 기록하며 다음을 준비한다.
Day 5 · 세션 1 · 오전

### 첫 실무 회고

70분
🎯학습목표

- 이번 주 사이클(접근 공유→구현→보고→리뷰→머지→배포)을 자기 말로 되짚는다.
- 잘한 점 1개, 아쉬운 점 1개, 다음에 시도할 것 1개를 적는다.

💬멘토 스크립트
멘토

"이번 주 여러분 전부 진짜 코드를 머지했어요. 첫 실무 주에 이만큼 온 거 정말 대단해요. 결과물 크기는 중요하지 않아요. 사이클을 한 바퀴 돌았다는 게 핵심이에요."

"회고는 반성문이 아니에요. 잘한 것도 꼭 적어요. 아쉬운 건 '다음에 이렇게 해볼래'로 바꿔 적으면 그게 성장이에요."

✍️워크시트 — 첫 실무 회고
3주차 회고 (각자 작성 후 공유)

    이번 주 내가 머지한 것: [한 줄]

    😀 잘한 점:        [예: 막혔을 때 30분 룰대로 바로 물어봤다]
    🤔 아쉬운 점:      [예: PR 설명을 너무 짧게 썼다]
    🚀 다음에 해볼 것:  [예: 중간보고를 아침마다 먼저 올리기]

    첫 실무 소감 한 줄: [____________________]

✅이해 확인 — 이번 주 퀴즈

구두 또는 짧은 쪽지로:

- "30분 룰"이 무엇이고 왜 있는가?
- PR 설명에 꼭 들어가야 할 것 2가지는?
- 머지 다음에 반드시 해야 하는 것은?
- (디자이너) 좋은 핸드오프 메모에 들어갈 정보 2가지는?

Day 5 · 세션 2 · 오후

### 1:1 면담 & 평가 체크포인트

인당 15분 · 순차
🎯학습목표

- 수습생 각자와 짧게 마주 앉아 이번 주 소감과 다음 주 각오를 나눈다.
- 멘토는 평가 루브릭 3항목을 관찰 근거와 함께 기록한다.

🕘진행표
인당 0–5분
소감 듣기. "이번 주 가장 기억에 남는 순간?"으로 시작.
인당 5–11분
피드백. 잘한 것 먼저, 개선점은 구체적 행동으로.
인당 11–15분
다음 주 한 가지 목표 함께 정하기.
✍️멘토 기록 — 평가 체크포인트
평가 루브릭 (멘토용 · 각 수습생별)

    수습생: [이름]

    1) 완주력       — 과제를 머지까지 끝냈는가
       근거: [관찰한 사실]

    2) 피드백 반영 태도 — 리뷰를 방어 없이 받아 반영했는가
       근거: [관찰한 사실]

    3) 보고 습관     — 먼저 진행 상황을 공유했는가
       근거: [관찰한 사실]

    다음 주 개인 목표: [한 줄]

⚠️흔한 실수
실수 · 1:1이 일방적 평가 통보가 된다.
대처 · 학생이 말하는 시간을 더 준다. 멘토는 듣고 근거만 기록.
실수 · 결과물 완성도로만 평가한다.
대처 · 이번 주 평가축은 완주력·반영 태도·보고 습관임을 기억한다.

다음 주 예고 — 4주차. 첫 사이클을 돌아본 이제, 조금 더 넓게 봅니다. 우리 서비스가 어떤 구조로 돌아가는지(프론트·백엔드·배포의 큰 그림)를 익히고, 두 번째 과제는 "여러 파일에 걸친 조금 더 큰 변경"으로 한 단계 올라갑니다. 고객사(KT엠모바일·KT알파·핀업)의 실제 화면을 예로 함께 살펴봅니다.