Daily Rhythm

## 하루의 리듬

3주차 내내 하루의 뼈대는 같아요. 오전 강의에서 배운 것을 오후에 소과제로 바로 이어가는 구조예요.

09:30–10:30
아침 강의(멘토) — 기본기 코너 「프로그램의 변화」 + 그날의 소과제 진행 포인트
10:40–12:00
일일 과제 전반 — 머리가 맑은 시간. 그날 과제의 가장 어려운 부분부터 시작해요
13:00–16:30
일일 과제 후반 — 막히면 30분 룰: 30분 동안 스스로 시도한 흔적(검색어·시도한 코드·에러 메시지)을 정리한 뒤 멘토에게 질문해요
16:30–17:00
멘토 과제 리뷰 — 그날의 산출물을 제출하고 피드백을 받아요
17:00–17:30
하루 정리 · 3줄 회고 — 오늘 한 것 / 배운 것 / 내일 할 것을 각 1줄로

규칙 하나만 기억해요: 과제가 일찍 끝나면 놀지 말고 예비 과제로 — 예비 과제도 평가에 반영돼요.

MON
월

## 착수 계획서 — 시작하기 전에 지도를 그린다

오전 강의에서 첫 소과제를 배정받고 접근 방법을 공유했어요. 오후엔 그 접근 방법을 문서로 굳혀요.

본 과제

### 소과제 착수 계획서 1장 쓰기

난이도 ★★
🎯목표

코드를 치기 전에 "무엇을, 어떻게, 얼마나 걸려서" 할지 스스로 설명하는 힘을 길러요 — 실무에서 가장 먼저 배우는 습관이에요.

📋진행 순서

1. 과제 티켓을 소리 내어 읽어요. 배정받은 소과제의 설명을 3번 읽고, 모르는 단어·기능 이름에 전부 밑줄을 쳐요.
2. 화면에서 확인해요. 실제 서비스(개발 환경)를 열어 과제가 말하는 화면·기능을 직접 눌러 보고, 현재 동작을 스크린샷 1장으로 남겨요.
3. 코드 입구를 찾아요. 화면에 보이는 문구(버튼 이름 등)를 저장소에서 검색해서, 고쳐야 할 파일 후보를 2~3개까지 좁혀요. 확신이 없어도 괜찮아요 — "후보"면 충분해요.
4. 아래 양식을 채워요. 특히 "불확실한 점"을 비워 두지 마세요. 불확실한 점이 하나도 없다면 과제를 아직 덜 이해한 거예요.
5. 작업을 3덩어리로 쪼개요. "화요일 오전 / 화요일 오후 / 수요일 오전"에 각각 무엇을 끝낼지 계획서의 일정 칸에 적어요.
6. 멘토 확인을 받아요. 계획서를 들고 멘토에게 5분만 시간을 요청해서, 방향이 맞는지 확인 도장을 받아요. 16:30 전에 미리 받아도 좋아요.
7. 수정 사항을 반영해요. 멘토 코멘트를 계획서에 빨간 글씨(또는 "멘토 피드백:" 표시)로 추가해서 최종본을 만들어요.

📤산출물 · 제출

16:30까지 제출: 착수 계획서 1장 (아래 양식 그대로, 마크다운 파일 `plan.md` 또는 공유 문서)

- 양식의 6개 항목이 모두 채워져 있을 것
- "불확실한 점"이 최소 2개 이상 적혀 있을 것
- 멘토 확인 코멘트가 반영돼 있을 것

📤워크시트
착수 계획서 양식 — 빈칸을 채워요

    # 소과제 착수 계획서

    작성자: ______   작성일: 2026-__-__   과제명: ______________________

    ## 1. 무엇을 (What)
    - 이 과제가 끝나면 사용자에게 무엇이 달라지나요? (1~2문장)
      → ________________________________________
    - 현재 동작 스크린샷: (붙여넣기)

    ## 2. 어떻게 (How)
    - 고칠 것으로 보이는 파일/영역 후보:
      1) ______________________ — 이유: __________
      2) ______________________ — 이유: __________
    - 대략의 순서: ____________ → ____________ → ____________

    ## 3. 예상 소요
    - 화요일 오전: ______________________
    - 화요일 오후: ______________________
    - 수요일 오전: ______________________ (PR 올리기 포함)

    ## 4. 불확실한 점 (최소 2개)
    - ________________________________________
    - ________________________________________

    ## 5. 완료 기준 (Definition of Done)
    - [ ] ______________________ 가 화면에서 동작한다
    - [ ] 기존 기능 __________ 이 깨지지 않았다
    - [ ] PR이 올라가고 설명이 채워져 있다

    ## 6. 멘토 피드백 (확인 후 기록)
    - ________________________________________

예비 과제

### 내 과제 주변 코드 탐험 노트

난이도 ★
🎯목표

내일 구현을 시작할 파일들을 미리 읽어 두면, 화요일 아침의 나에게 큰 선물이 돼요.

📋진행 순서

1. 계획서 2번 항목의 파일 후보를 위에서부터 하나씩 열어요.
2. 파일마다 맨 위(import·컴포넌트/클래스 선언)부터 끝까지 훑고, "이 파일의 역할 1줄"을 노트에 적어요.
3. 모르는 함수·문법이 나오면 일단 이름만 노트에 적고 넘어가요 (전부 이해하려고 멈추지 않기).
4. 파일들 사이의 호출 관계를 화살표로 그려요. 예: `화면 컴포넌트 → API 호출 함수 → 서버 컨트롤러`
5. 노트 마지막에 "내일 제일 먼저 열 파일 1개"를 정해서 적어요.

✚제출

제출: 탐험 노트(파일별 역할 1줄 + 화살표 그림 + 모르는 것 목록). 계획서 뒤에 붙여서 함께 내면 돼요. 일찍 끝났을 때만 하는 과제지만, 하면 화요일이 훨씬 편해져요.

디자이너 과제

### 개선 과제 착수 계획 — 대상 화면과 문제 정의

난이도 ★★
🎨개발자 과제와의 차이

구조는 같고 대상만 달라요. 개발자가 "코드 입구"를 찾는 자리에서, 디자이너는 "화면의 문제"를 찾아요. 계획서 양식도 같은 것을 쓰되 2번 항목을 아래처럼 바꿔서 채워요.

📋진행 순서

1. 배정받은 개선 대상 화면을 열고, 현재 상태 스크린샷을 전부(기본·비어 있음·로딩·오류 상태) 캡처해요.
2. 화면을 처음 보는 사람처럼 사용해 보며 불편한 점을 5개 이상 메모해요 (사소해도 전부).
3. 5개 중 이번 주에 고칠 핵심 문제 1~2개를 고르고, "누가 / 언제 / 왜 불편한가"를 각 1문장으로 정의해요.
4. 참고할 만한 다른 서비스의 같은 화면을 2개 찾아 스크린샷과 "여기서 배울 점 1줄"을 적어요.
5. 착수 계획서 양식의 2번을 "문제 정의 + 참고 사례"로 채우고, 3번 일정(화: 시안 1차 / 수: 시안 2차 / 목: 핸드오프)을 적어요.
6. 멘토 확인을 받고 피드백을 6번 칸에 기록해요.

📤산출물 · 제출

16:30까지 제출: 디자인 착수 계획서 1장 (현재 상태 캡처 + 문제 정의 1~2개 + 참고 사례 2개 + 일정)

TUE
화

## 구현 1일차 — 계획대로 가되, 어긋남을 기록한다

오전 강의의 진행 포인트(작게 커밋하기)를 오후 구현에 바로 적용해요. 퇴근 전 중간보고까지가 오늘의 한 세트예요.

본 과제

### 소과제 구현 1일차 + 퇴근 전 중간보고

난이도 ★★★
🎯목표

계획을 실제 코드로 옮기면서, 진행 상황을 남이 이해할 수 있게 보고하는 실무 사이클을 처음부터 끝까지 경험해요.

📋진행 순서

1. 작업 브랜치를 만들어요. `git switch -c feature/과제이름-이니셜` 형태로. 브랜치 이름은 멘토가 봐도 무슨 작업인지 알 수 있게 지어요.
2. 계획서의 "화요일 오전" 덩어리부터 시작해요. 어제 정한 "제일 먼저 열 파일"을 열고, 가장 작은 변경 하나(문구 하나, 조건 하나)로 시작해서 화면에 반영되는지 먼저 확인해요.
3. 동작하는 단위마다 커밋해요. 하루 최소 3커밋. 커밋 메시지는 "무엇을 했는지"가 보이게: `feat: 목록 화면에 빈 상태 문구 추가` 처럼요.
4. 막히면 30분 룰. 30분 동안 ①에러 메시지 정독 ②검색 ③작은 실험, 이 3가지를 해 보고 그래도 안 되면 시도 내역을 정리해 멘토에게 질문해요. 질문도 실력이에요.
5. 15:50이 되면 손을 멈추고 계획서를 다시 열어요. 계획 대비 어디까지 왔는지, 예상과 달랐던 점을 체크해요.
6. 아래 틀로 중간보고를 작성해요. 1주차에 배운 보고 틀 그대로예요: 사실 → 판단 → 다음 행동.
7. 16:30 리뷰에서 중간보고를 읽고, 오늘 커밋을 화면과 함께 보여줘요.

📤산출물 · 제출

16:30까지 제출: ① 오늘의 진행 커밋(브랜치에 3커밋 이상, 푸시 완료) ② 중간보고 메시지(아래 틀)

- 커밋 메시지만 읽어도 오늘 한 일이 보일 것
- 중간보고에 "계획과 달랐던 점"이 솔직하게 적혀 있을 것 (없으면 "없음"이라고 쓰되, 정말인지 한 번 더 생각!)

📤워크시트
중간보고 메시지 틀 — 메신저에 이 형식으로 보내요

    [중간보고] 과제명 — 구현 1일차 (화)

    ■ 오늘 한 것 (사실)
    - ________________________________________
    - ________________________________________
    - 커밋: N개 (브랜치: feature/______)

    ■ 진행률 (판단)
    - 계획 대비: 예정대로 / 조금 늦음 / 많이 늦음 중 하나 + 이유 1줄
    - 계획과 달랐던 점: ________________________________________

    ■ 내일 할 것 (다음 행동)
    - 오전: ______________________
    - 오후: ______________________ + PR 올리기

    ■ 도움이 필요한 것
    - ________________ (없으면 "없음")

예비 과제

### JS 함수 연습 10제 — 손을 멈추지 않기

난이도 ★
🎯목표

소과제가 일찍 끝났거나 멘토 답변을 기다리는 동안, 함수 작성 근육을 유지해요.

📋진행 순서

1. 새 파일 `practice-w3-tue.js`를 만들어요.
2. 아래 문제를 1번부터 순서대로 풀어요. 각 문제는 함수 하나로 작성해요.
3. 문제마다 `console.log()`로 예시 입력 2개 이상을 넣어 결과를 확인해요.
4. 막히는 문제는 건너뛰되, 파일에 `// TODO: 왜 막혔는지 1줄`을 남겨요.
5. 다 풀면(또는 시간이 되면) 커밋해서 개인 연습 저장소에 푸시해요.

📤연습문제
JS 함수 연습 10제 (답은 스스로!)

    1. sum(a, b) — 두 수를 받아 합을 반환하는 함수를 작성하세요.

    2. isEven(n) — 정수를 받아 짝수면 true, 홀수면 false를 반환하세요.

    3. maxOfThree(a, b, c) — 세 수 중 가장 큰 값을 반환하세요.
       (Math.max 없이 if문으로 먼저 풀고, 그 다음 Math.max로도 풀어 보세요.)

    4. repeatText(text, n) — 문자열 text를 n번 이어붙인 문자열을 반환하세요.
       예: repeatText("하", 3) → "하하하"

    5. countVowels(str) — 영어 문자열에서 모음(a,e,i,o,u)의 개수를 반환하세요.
       대문자도 세어야 합니다.

    6. reverseWords(sentence) — 문장을 받아 단어 순서를 뒤집어 반환하세요.
       예: reverseWords("나는 오늘 출근했다") → "출근했다 오늘 나는"

    7. sumArray(numbers) — 숫자 배열의 합을 반환하세요.
       for문으로 한 번, reduce로 한 번, 두 가지 방법으로 작성하세요.

    8. filterLongNames(names, minLength) — 이름 배열에서 글자 수가
       minLength 이상인 이름만 담은 새 배열을 반환하세요.
       예: filterLongNames(["김", "이서연", "박준"], 2) → ["이서연", "박준"]

    9. toPriceText(price) — 숫자를 받아 천 단위 콤마를 붙인 문자열에
       "원"을 붙여 반환하세요. 예: toPriceText(1250000) → "1,250,000원"

    10. findFirstIndex(arr, target) — 배열에서 target이 처음 나오는
        인덱스를 반환하고, 없으면 -1을 반환하세요.
        (indexOf 없이 직접 반복문으로 구현하세요.)

✚제출

제출: `practice-w3-tue.js` 파일 링크(푸시된 커밋). 몇 번까지 풀었는지, 어디서 막혔는지를 중간보고 메시지 끝에 한 줄로 덧붙여요.

디자이너 과제

### 시안 1차 — 핵심 문제 하나를 화면으로

난이도 ★★
🎨개발자 과제와의 차이

개발자의 "커밋"이 디자이너에겐 "시안 버전"이에요. 하루의 끝에 중간보고를 보내는 것은 동일하고, 커밋 개수 대신 시안 버전 수를 적어요.

📋진행 순서

1. 어제 정의한 핵심 문제 1개를 골라, 디자인 툴에 현재 화면을 그대로 복제한 프레임을 먼저 만들어요 (비교 기준).
2. 같은 화면의 개선안을 서로 다른 방향으로 2개 그려요. 하나는 "최소 수정", 하나는 "과감한 수정".
3. 각 시안 옆에 "무엇을 왜 바꿨는지"를 3줄 이내로 메모해요.
4. 기본 상태만 그리지 말고, 비어 있음·로딩·오류 상태 중 최소 1개를 함께 그려요.
5. 15:50에 손을 멈추고 중간보고 틀(위 개발자용과 동일)로 보고를 작성해요.

📤산출물 · 제출

16:30까지 제출: 시안 1차 링크(현재 화면 + 개선안 2방향 + 메모) + 중간보고 메시지

WED
수

## 구현 2일차 + PR — 내 작업을 남에게 건넨다

오전 강의에서 좋은 PR의 조건을 배웠어요. 오후엔 구현을 마무리하고 그 조건대로 PR을 올려요.

본 과제

### 구현 마무리 + 첫 PR 올리기

난이도 ★★★
🎯목표

"동작하는 코드"를 "리뷰받을 수 있는 PR"로 포장하는 법을 배워요 — PR은 코드가 아니라 커뮤니케이션이에요.

📋진행 순서

1. 오전(10:40–12:00)에 구현을 끝내는 걸 목표로 어제 중간보고의 "내일 할 것"부터 이어가요. 새 기능 욕심은 금지 — 계획서의 완료 기준만 채워요.
2. 완료 기준 체크리스트를 하나씩 검증해요. 화면에서 직접 눌러 보고, 기존 기능이 깨지지 않았는지 주변 기능 3개를 함께 확인해요.
3. 스크린샷/짧은 녹화를 준비해요. 변경 전(월요일 캡처)과 변경 후를 나란히 놓을 수 있게요.
4. 커밋을 정리해요. "wip", "수정" 같은 커밋 메시지가 있으면 의미가 보이게 고민해 보고, 마지막 커밋까지 푸시해요.
5. 아래 틀로 PR을 작성해요. 제목은 50자 이내, "무엇을"이 바로 보이게. 본문은 틀의 모든 항목을 채워요.
6. 스스로 셀프 리뷰를 해요. PR의 Files changed 탭을 처음부터 끝까지 읽고, 스스로 발견한 어색한 부분에 먼저 코멘트를 달아요 (최소 1개).
7. 리뷰어로 멘토를 지정하고, 메신저로 "PR 올렸습니다 + 링크"를 알려요.

📤산출물 · 제출

16:30까지 제출: 올라간 PR 링크

- PR 본문의 4개 섹션(무엇/왜/스크린샷/확인 방법)이 모두 채워져 있을 것
- 변경 전·후 스크린샷이 붙어 있을 것
- 셀프 리뷰 코멘트가 1개 이상 달려 있을 것

📤워크시트
PR 설명 틀 — 본문에 이 형식 그대로

    제목: [과제] 목록 화면 빈 상태 안내 추가 ← 예시. 내 과제에 맞게

    ## 무엇을 바꿨나요
    - ________________________________________
    - ________________________________________

    ## 왜 바꿨나요
    - 과제 배경 + 이 방법을 고른 이유: __________________
    - 고민했지만 선택하지 않은 방법(있다면): __________

    ## 스크린샷
    | 변경 전 | 변경 후 |
    |---|---|
    | (이미지) | (이미지) |

    ## 확인 방법 (리뷰어가 따라 할 수 있게)
    1. ______ 화면으로 이동
    2. ______ 버튼 클릭
    3. ______ 가 보이면 정상

    ## 스스로 확인한 것
    - [ ] 완료 기준 체크리스트 전부 통과
    - [ ] 주변 기능 3개 정상 동작: __ , __ , __
    - [ ] 콘솔 에러 없음

예비 과제

### "내 코드 설명 문서" 1장

난이도 ★
🎯목표

내가 바꾼 코드를 말로 설명할 수 있어야 진짜 이해한 거예요 — 내일 리뷰 코멘트에 답할 준비도 돼요.

📋진행 순서

1. 내 PR의 변경 파일 중 가장 핵심인 파일 1개를 골라요.
2. "이 코드를 처음 보는 옆자리 동료"를 독자로 상상하고, 변경한 부분이 줄 단위로 무슨 일을 하는지 설명하는 글을 써요.
3. 설명하다가 "왜 이렇게 썼지?" 싶은 줄이 나오면 솔직하게 "이 부분은 검색해서 가져왔는데 정확히는 모름"이라고 적어요 — 그게 내일 공부할 목록이에요.
4. 마지막에 "이 코드가 고장 난다면 어디부터 볼까?" 1문단을 덧붙여요.
5. A4 1장 분량이 되면 멈추고 저장해요.

✚제출

제출: 설명 문서 1장(`explain.md`). PR 링크와 함께 내요. "정확히는 모름" 표시가 있는 문서가 없는 문서보다 좋은 평가를 받아요.

디자이너 과제

### 시안 2차 + 개발자 피드백 받기

난이도 ★★★
🎨개발자 과제와의 차이

개발자의 "PR 올리기"가 디자이너에겐 "시안을 개발자에게 보여주기"예요. 리뷰받을 수 있는 형태로 포장한다는 점은 완전히 같아요.

📋진행 순서

1. 어제 2개 방향 중 멘토와 함께 고른 방향 1개를 다듬어 2차 시안을 만들어요.
2. 기본·비어 있음·로딩·오류 4개 상태를 전부 그려요.
3. 버튼·입력창의 눌림/비활성 상태도 각각 그려요.
4. 개발 수습 동료 1명에게 시안을 보여주고 "이대로 만들 수 있어? 애매한 부분은 어디야?"를 물어 답을 그대로 받아 적어요 (최소 3개).
5. 받은 피드백 중 반영할 것/안 할 것을 나누고 이유를 1줄씩 적어요.

📤산출물 · 제출

16:30까지 제출: 시안 2차 링크(4개 상태 포함) + 개발자 피드백 3개와 반영 여부 메모

THU
목

## 리뷰 반영 — 코멘트는 공격이 아니라 선물

오전 강의에서 리뷰 코멘트를 읽는 법을 배웠어요. 오후엔 실제 코멘트를 하나씩 반영하고 머지까지 가요.

본 과제

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

난이도 ★★★
🎯목표

리뷰 코멘트를 감정이 아니라 정보로 받아들이고, "무엇을 왜 고쳤는지" 설명하며 반영하는 태도를 익혀요.

📋진행 순서

1. 코멘트를 전부 먼저 읽어요. 하나씩 고치기 전에 끝까지 읽고, 아래 반영 기록표에 코멘트를 번호 붙여 옮겨 적어요.
2. 이해 안 되는 코멘트엔 바로 되물어요. "이 코멘트는 ~라는 뜻이 맞을까요?"라고 PR에서 질문하는 것도 훌륭한 반영이에요.
3. 하나 고칠 때마다 커밋 하나. 코멘트 여러 개를 한 커밋에 뭉치지 않아요. 커밋 메시지에 어떤 코멘트에 대한 수정인지 남겨요.
4. 반영 기록표를 채워요. 코멘트마다 "무엇을 / 왜 그렇게" 고쳤는지 1~2줄. 반영하지 않기로 한 코멘트가 있다면 이유를 적고 리뷰어와 합의해요.
5. 고친 뒤 PR에 답글을 달아요. 각 코멘트에 "반영했습니다 + 커밋 링크" 또는 자기 생각을 답해요. 말없이 고치기만 하면 리뷰어가 다시 다 찾아봐야 해요.
6. 승인(Approve)을 받으면 머지해요. 머지 방식(멘토가 안내한 방식)을 확인하고 실행해요.
7. 배포를 확인해요. 머지 후 개발 서버 화면에서 내 변경이 실제로 보이는지 직접 눌러 확인하고, 확인 스크린샷을 남겨요. "머지 = 끝"이 아니라 "화면에서 보임 = 끝"이에요.

📤산출물 · 제출

16:30까지 제출: ① 머지된 PR 링크 ② 반영 기록표 ③ 배포 확인 스크린샷

- 모든 코멘트에 답글이 달려 있을 것 (반영/미반영 모두)
- 반영 기록표의 "왜" 칸이 비어 있지 않을 것

📤워크시트
리뷰 반영 기록표

    # 리뷰 반영 기록 — 과제명

    | # | 코멘트 요약 | 무엇을 고쳤나 | 왜 그렇게 고쳤나 | 커밋 |
    |---|---|---|---|---|
    | 1 | ______________ | ______________ | ______________ | ____ |
    | 2 | ______________ | ______________ | ______________ | ____ |
    | 3 | ______________ | ______________ | ______________ | ____ |

    ## 반영하지 않은 코멘트 (있다면)
    - 코멘트: __________ / 이유: __________ / 리뷰어 합의: 예·아니오

    ## 배포 확인
    - 머지 시각: __:__ / 화면 확인 시각: __:__
    - 확인한 화면·동작: ________________________ (스크린샷 첨부)

    ## 오늘 리뷰에서 배운 것 1가지
    - ________________________________________

예비 과제

### 동료 PR 읽기 — 배운 점 3개

난이도 ★
🎯목표

남의 PR을 읽는 것은 공짜 과외예요 — 같은 주에 같은 코드베이스에서 일어난 일이라 흡수가 빨라요.

📋진행 순서

1. 다른 수습 동료의 PR 1개를 골라요 (머지됐거나 리뷰 중인 것).
2. 본문을 먼저 읽고, "이 PR이 뭘 하는지" 내 말로 1문장 요약해요.
3. 변경 파일을 처음부터 끝까지 읽어요. 이해 안 되는 줄은 건너뛰되 개수를 세요.
4. 리뷰 코멘트와 답글의 대화를 읽고, 배운 점 3개를 메모해요 (코드 기법 / PR 쓰는 법 / 대화하는 법 무엇이든).
5. 가능하다면 그 PR에 칭찬 코멘트 하나를 남겨요. "이 부분 설명이 이해하기 쉬웠어요" 같은 것도 좋아요.

✚제출

제출: 메모 1장(PR 링크 + 1문장 요약 + 배운 점 3개 + 이해 못 한 줄 개수). 반영 기록표 뒤에 붙여 함께 내요.

디자이너 과제

### 핸드오프 문서 — 시안을 만들 수 있는 명세로

난이도 ★★★
🎨개발자 과제와의 차이

개발자의 "머지"가 디자이너에겐 "핸드오프"예요. 어제 받은 개발자 피드백(애매하다던 부분)이 오늘 명세로 답해야 할 목록이에요.

📋진행 순서

1. 최종 시안 프레임을 정리하고, 사용한 색·글자 크기를 이름 붙은 스타일로 정돈해요.
2. 화면 요소 사이의 간격을 숫자로 표기해요 (여백·요소 간 거리, 최소 8곳 이상).
3. 버튼·입력창의 상태별 명세를 표로 써요: 기본 / 눌림 / 비활성 / 오류 — 각각 색·문구가 어떻게 달라지는지.
4. 인터랙션 명세를 문장으로 써요: "이 버튼을 누르면 → 무엇이 → 어떻게 되는가"를 최소 3개.
5. 어제 개발자가 "애매하다"고 한 부분마다 명세에 답이 있는지 체크해요.
6. 같은 개발자에게 문서를 보여주고 "이제 만들 수 있겠어?"라는 답을 받아요.

📤산출물 · 제출

16:30까지 제출: 핸드오프 문서 링크(간격 표기 + 상태 명세표 + 인터랙션 3개 + 개발자 확인 코멘트)

FRI
금

## 첫 실무 회고 — 계획과 실제의 간격을 잰다

오전엔 한 주 마무리 강의와 1:1 면담이 있어요. 오후엔 이번 주 전체를 숫자와 문장으로 되돌아봐요.

본 과제

### "계획 대비 실제" 회고 1장

난이도 ★★
🎯목표

예측과 실제의 차이를 직접 재 보면, 다음 과제의 예상 소요가 훨씬 정확해져요 — 이게 경력의 핵심 근육이에요.

📋진행 순서

1. 월요일의 착수 계획서와 화·수 중간보고를 나란히 펴 놓아요.
2. 아래 비교표의 "예상" 칸을 계획서에서 그대로 옮겨 적어요 (지금 기억으로 다시 쓰지 않기 — 그대로 옮기는 게 핵심).
3. "실제" 칸을 채워요. 커밋 시각·중간보고·PR 타임라인을 근거로 최대한 정확하게.
4. 예상 못 한 문제를 전부 나열하고, 각각 "미리 알 수 있었나? (예/아니오)"를 표시해요.
5. "다음에 다르게 할 것 3가지"를 써요. "열심히 한다" 같은 다짐 금지 — 행동으로 검증 가능한 문장만: 예) "계획서에 파일 후보를 적기 전에 실제로 파일을 열어 확인한다".
6. 이번 주 가장 뿌듯했던 순간 1개, 가장 힘들었던 순간 1개를 솔직하게 적어요.
7. 오후 1:1 면담(멘토가 시간을 잡아요)에서 회고를 함께 읽으며 이야기해요.

📤산출물 · 제출

16:30까지 제출: 회고 1장 (아래 양식, `retro-w3.md`)

- "예상" 칸이 계획서 원문 그대로일 것
- "다음에 다르게 할 것"이 검증 가능한 행동 문장 3개일 것

📤워크시트
첫 실무 회고 양식

    # 3주차 회고 — 첫 소과제

    ## 1. 계획 대비 실제
    | 항목 | 예상 (월요일 계획서 원문) | 실제 | 차이·이유 |
    |---|---|---|---|
    | 구현 완료 시점 | ________ | ________ | ________ |
    | 고친 파일 | ________ | ________ | ________ |
    | PR 올린 시점 | ________ | ________ | ________ |
    | 리뷰 코멘트 개수 | ____개 예상 | ____개 | ________ |

    ## 2. 예상 못 한 문제 (전부)
    | 문제 | 얼마나 잡아먹었나 | 미리 알 수 있었나 |
    |---|---|---|
    | ____________ | 약 __시간 | 예 / 아니오 |
    | ____________ | 약 __시간 | 예 / 아니오 |

    ## 3. 다음에 다르게 할 것 3가지 (검증 가능한 행동으로)
    1. ________________________________________
    2. ________________________________________
    3. ________________________________________

    ## 4. 이번 주의 순간들
    - 가장 뿌듯했던 순간: ________________________
    - 가장 힘들었던 순간: ________________________

    ## 5. 멘토에게 묻고 싶은 것 1가지
    - ________________________________________

예비 과제

### 「프로그램의 변화」 그림 한 장 정리

난이도 ★
🎯목표

이번 주 아침 기본기 코너에서 배운 "프로그램의 변화(상태가 어떻게 바뀌어 가는가)"를 그림 한 장으로 남기면 오래 기억돼요.

📋진행 순서

1. 이번 주 아침 강의 노트를 훑고, "프로그램의 변화"에서 배운 개념을 키워드로 다 뽑아요 (변수의 값 변화, 상태 전이, 이벤트→상태→화면 등).
2. 종이든 디지털이든 한 장에, 내 소과제 기능을 예로 들어 "사용자 행동 → 상태 변화 → 화면 변화"의 흐름을 그림으로 그려요.
3. 화살표마다 "무엇이 바뀌는지"를 라벨로 붙여요.
4. 그림 아래에 "이번 주 가장 새로웠던 개념 1개"를 2~3문장으로 설명해요.

✚제출

제출: 그림 1장(사진 또는 파일). 회고와 함께 내요. 잘 그린 그림은 다음 기수 교육 자료로 쓸 수도 있어요.

디자이너 과제

### 디자인 회고 — 시안의 계획 대비 실제

난이도 ★★
🎨개발자 과제와의 차이

회고 양식은 개발자용을 그대로 쓰되, 1번 표의 항목을 "시안 1차 완료 / 개발자 피드백 개수 / 핸드오프 완료 시점"으로 바꿔 채워요. 특히 "개발자가 애매하다고 한 것들을 처음부터 명세에 넣었다면?"을 2번 표에서 꼭 다뤄요.

📋진행 순서

1. 월요일 디자인 착수 계획서와 화·수 시안 버전들을 나란히 펴요.
2. 회고 양식 1번 표를 디자인 버전 항목으로 바꿔 채워요.
3. 개발자 피드백에서 나온 "애매한 부분"들을 2번 표(예상 못 한 문제)에 넣고, 미리 알 수 있었는지 표시해요.
4. 다음 시안 때 다르게 할 것 3가지를 행동 문장으로 써요. 예) "시안을 넘기기 전에 4개 상태를 그렸는지 셀프 체크한다".
5. 1:1 면담에서 회고를 함께 읽어요.

📤산출물 · 제출

16:30까지 제출: 디자인 회고 1장 (비교표 + 다르게 할 것 3가지)

For Mentors

## 멘토 리뷰 가이드 (16:30–17:00)

매일 리뷰에서 확인할 것과 던질 질문이에요. 산출물의 완성도보다 "스스로 설명할 수 있는가"를 봐 주세요.

월 · 계획서
확인: 불확실한 점이 솔직하게 적혔는가, 일정 3덩어리가 현실적인가. 질문: "이 과제에서 제일 자신 없는 부분이 어디예요? 그게 계획서에 적혀 있나요?"
화 · 구현 1일차
확인: 커밋이 의미 단위로 쪼개졌는가, 중간보고에 사실·판단·다음 행동이 구분됐는가. 질문: "오늘 계획과 달랐던 점을 언제 알아챘어요? 더 일찍 알 수 있었을까요?"
수 · PR
확인: PR 본문만 읽고 리뷰가 가능한가, 셀프 리뷰 코멘트가 있는가. 질문: "이 PR에서 리뷰어가 제일 걱정할 부분이 어디라고 생각해요?"
목 · 리뷰 반영
확인: 모든 코멘트에 답글이 달렸는가, 반영 기록의 "왜"가 채워졌는가, 배포 확인까지 했는가. 질문: "가장 아팠던 코멘트는 뭐였고, 지금은 어떻게 생각해요?"
금 · 회고
확인: "예상" 칸이 계획서 원문 그대로인가, 다르게 할 3가지가 행동 문장인가. 질문: "다음 소과제의 예상 소요를 지금 다시 잡는다면 뭘 근거로 잡을 거예요?" — 1:1에서 다음 주 방향까지 합의.