Daily Rhythm

## 하루의 리듬

4주차도 리듬은 같아요. 다만 이번 주는 "만드는 것"만큼 "정리하고 말로 설명하는 것"이 중요한 주라는 점을 기억하세요.

09:30–10:30
아침 강의(멘토) — 그날 과제의 배경 개념을 배워요. 과제집과 연결되는 부분을 표시하며 들으세요.
10:40–12:00
일일 과제 전반 — 과제 카드의 진행 순서 1~3단계를 목표로 시작해요.
13:00–16:30
일일 과제 후반 — 산출물을 완성하는 시간. 막히면 30분 룰: 30분 이상 혼자 헤매지 말고, 시도한 것을 정리해서 멘토에게 질문해요.
16:30–17:00
멘토 과제 리뷰 — 그날의 산출물을 제출하고 피드백을 받아요.
17:00–17:30
하루 정리 · 3줄 회고 — 배운 것 1줄 / 막혔던 것 1줄 / 내일 할 것 1줄.

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

MON
월

## 전체 흐름도 완성 — 요청이 지나가는 길을 한 장에

오전 강의 "요청 흐름 전체 정리"에서 배운 그림을, 이번엔 내 손으로 처음부터 끝까지 그려요.

본 과제

### 버튼 클릭에서 화면 갱신까지 — 전체 흐름도 1장

난이도 ★★
🎯목표

1~3주차에 따로따로 배운 조각들(React, REST API, Spring Boot, DB)을 하나의 요청 흐름으로 꿰어, 시스템 전체를 스스로 설명할 수 있게 돼요.

📋진행 순서

1. 도구를 정해요. 손그림(사진 제출), 파워포인트, 그림판, 화이트보드 앱 — 뭐든 좋아요. 예쁘게 그리는 것보다 단계가 빠짐없이 이어지는 것이 중요해요. 10분 안에 정하고 시작하세요.
2. 큰 상자 7개를 먼저 배치해요. ① 사용자의 버튼 클릭 → ② React 컴포넌트(이벤트 핸들러) → ③ HTTP 요청(REST API 호출) → ④ Spring Boot 서버(Controller → Service) → ⑤ DB(조회/저장) → ⑥ 응답(JSON) → ⑦ React가 상태를 바꿔 화면 갱신. 화살표로 왼쪽에서 오른쪽으로 이어요.
3. 각 상자 아래에 "실제로 일어나는 일"을 1~2줄로 적어요. 예: ③번 상자에는 어떤 HTTP 메서드(GET/POST 등)를 쓰는지, 요청에 무엇이 담기는지를 적어요.
4. 배운 개념을 연결해요. 각 단계마다 1~3주차 강의에서 배운 개념을 최소 1개씩 포스트잇(또는 말풍선)으로 붙여요. 예: ②에 "이벤트 핸들러, 상태(state)", ④에 "Controller, 계층 분리", ⑤에 "테이블, SQL". 단계당 개념 1개 이상, 전체 10개 이상이 목표예요.
5. 실패하는 경우도 1갈래 그려요. 서버가 에러(예: 400 또는 500)를 돌려줄 때 흐름이 어디서 갈라지고, 화면에는 무엇이 보여야 하는지를 점선 화살표로 추가해요.
6. 3주차 소과제와 대조해요. 내가 3주차에 만든 기능에서 실제 코드 파일이 이 그림의 어느 상자에 해당하는지, 파일명을 상자 옆에 적어요(최소 3개 파일).
7. 소리 내어 설명하며 점검해요. 그림을 보며 처음부터 끝까지 2분 안에 말로 설명해 보세요. 말이 막히는 상자가 곧 이해가 빈 곳이에요. 그 부분을 보강해요.

✅완성 점검표
제출 전 셀프 체크리스트 — 전부 "예"여야 제출

    [ ] 7단계 상자가 모두 있고 화살표로 이어져 있다
    [ ] 각 단계 아래에 "실제로 일어나는 일"이 1~2줄씩 적혀 있다
    [ ] 1~3주차 개념 연결 표시가 10개 이상 붙어 있다
    [ ] 에러(실패) 흐름이 점선으로 1갈래 이상 그려져 있다
    [ ] 내 3주차 소과제의 실제 파일명이 3개 이상 상자 옆에 적혀 있다
    [ ] 그림만 보고 2분 안에 말로 설명할 수 있다

📤산출물 · 제출

16:30 제출: 전체 흐름도 1장.

- 손그림이면 잘 보이게 찍은 사진, 디지털이면 이미지/PDF로 내보내서 제출해요.
- 파일명: 주4_월_흐름도_이름.png(또는 pdf)
- 리뷰 시간에 멘토 앞에서 2분 설명을 실제로 하게 되니, 설명 연습까지가 과제예요.

예비 과제

### 가장 자신 없는 단계 1개, 파고들기

난이도 ★
🎯목표

흐름도에서 설명이 가장 얇았던 단계 하나를 골라, 그 단계만큼은 자신 있게 만들어요.

📋진행 순서

1. 흐름도 7단계 중 2분 설명에서 말이 가장 막혔던 단계를 하나 고르세요.
2. 그 단계에 대해 스스로 질문 3개를 적어요. 예: "서버는 JSON을 어떻게 자바 객체로 바꾸지?", "브라우저는 응답을 받은 뒤 무엇을 하지?"
3. 공식 문서·강의 자료·1~3주차 필기에서 답을 찾아 각 질문에 3~5줄로 답을 적어요.
4. 알게 된 내용을 흐름도의 해당 상자에 반영해서 그림을 업데이트해요.

➕제출

질문 3개 + 답 문서(반 쪽 분량)와 업데이트된 흐름도를 본 과제 제출물에 덧붙여요. 예비 과제까지 한 사람의 흐름도는 리뷰에서 티가 나요.

디자이너 과제

### 같은 흐름을 "사용자 여정"으로 그리기

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

같은 7단계를 그리되, 관점을 "기계"가 아니라 "사람"에 둬요. 개발자 흐름도가 "요청이 어디를 지나가는가"라면, 디자이너 버전은 "그동안 사용자는 무엇을 보고, 무엇을 느끼고, 무엇을 기다리는가"예요.

📋진행 순서

1. 본 과제와 같은 시나리오(버튼 클릭 → 화면 갱신)를 고르고, 가로축을 시간으로 하는 여정 지도를 준비해요.
2. 각 시점마다 3줄을 채워요: 화면에 보이는 것 / 사용자의 생각·감정 / 뒤에서 일어나는 일(한 줄 요약).
3. 특히 기다리는 순간(요청이 서버에 가 있는 동안)을 놓치지 마세요. 로딩 중에 화면이 무엇을 보여줘야 사용자가 불안하지 않을지 스피너·스켈레톤 등 대안을 2가지 스케치해요.
4. 실패했을 때의 화면도 1장 그려요. 에러 메시지는 사용자가 다음에 무엇을 해야 하는지 알려줘야 해요(문구까지 직접 써 보기).
5. 개발 동료 1명에게 여정 지도를 보여주고, "뒤에서 일어나는 일" 요약이 기술적으로 맞는지 확인받아 수정해요.

📤산출물 · 제출

16:30 제출: 사용자 여정 지도 1장 + 로딩·에러 화면 스케치.

- 파일명: 주4_월_여정지도_이름.png(또는 pdf)
- 리뷰 때 "사용자가 가장 불안해할 순간이 어디인지" 질문을 받게 돼요.

TUE
화

## 두 번째 소과제 1일차 — 계획서와 착수

오전 강의에서 두 번째 소과제(난이도 상승)를 받았어요. 오늘은 계획을 스스로 완성하고 구현을 시작하는 날이에요.

본 과제

### 착수 계획서 작성 + 구현 시작 + 중간보고

난이도 ★★★
🎯목표

3주차에는 멘토가 계획을 다듬어 줬지만, 이번엔 멘토 확인 전에 스스로 계획의 완성도를 끌어올리는 힘을 길러요.

📋진행 순서

1. (10:40–11:20) 계획서 초안을 써요. 아래 양식(3주차와 같은 양식)을 그대로 채우세요. "구현 단계 쪼개기"는 한 단계가 90분을 넘지 않게 쪼개는 것이 기준이에요.
2. (11:20–12:00) 스스로 계획을 공격해요. 초안을 다 쓰고 나서, 아래 3가지 질문으로 자기 계획의 구멍을 찾아 계획서를 고쳐요: ① 이 중 내가 한 번도 안 해 본 것은? ② 가장 늦어질 것 같은 단계는? ③ 수요일 오후까지 안 끝나면 무엇을 뺄 것인가(축소 계획)?
3. (13:00) 브랜치를 만들고 첫 커밋을 해요. 브랜치 이름은 3주차 규칙 그대로(예: `feature/기능이름-이름`). 첫 커밋은 빈 뼈대(파일·폴더 구조)만이라도 좋아요.
4. (13:00–15:30) 계획서의 1~2단계를 구현해요. 커밋은 단계 하나 끝날 때마다 남겨요. 커밋 메시지에 계획서의 단계 번호를 적으면 리뷰가 쉬워져요(예: "1단계: 목록 조회 API 뼈대").
5. (15:30–16:00) 30분 룰 점검. 오늘 30분 이상 막혔던 지점이 있었다면, 무엇을 시도했고 어디서 막혔는지 3줄로 기록해 두세요. 없었다면 "없음"이라고 적어요.
6. (16:00–16:30) 중간보고를 써요. 계획서 아래에 "1일차 중간보고" 칸을 채워요: 완료한 단계 / 예상과 달랐던 점 / 내일 첫 90분에 할 일.

📝양식
착수 계획서 (3주차 양식 재사용 · 빈칸을 채우세요)

    ■ 소과제 이름: ______________________  ■ 작성자: ________  ■ 날짜: 2026-__-__

    1. 한 줄 요약 (이 기능은 사용자가 ______ 할 수 있게 한다)
       → ________________________________________________

    2. 완료 조건 (이게 되면 끝) — 3개
       ① ______________________________________________
       ② ______________________________________________
       ③ ______________________________________________

    3. 화면 스케치 / API 설계 (택1 이상)
       - 화면: 어떤 요소가 어디에? (간단 스케치 첨부)
       - API: 메서드 ____ / 경로 /api/____________ / 요청 본문 ______ / 응답 ______

    4. 구현 단계 쪼개기 (한 단계 = 90분 이내, 순서대로)
       1단계: ____________________ (예상 __분)
       2단계: ____________________ (예상 __분)
       3단계: ____________________ (예상 __분)
       4단계: ____________________ (예상 __분)
       5단계: ____________________ (예상 __분)

    5. 예상 위험 & 대비
       - 가장 자신 없는 부분: ______________ → 막히면: ______________
       - 수요일 오후까지 안 끝나면 뺄 것(축소 계획): ______________

    --- 1일차 중간보고 (16:00 작성) ---
       완료한 단계: ______  /  예상과 달랐던 점: ____________________
       내일 첫 90분에 할 일: ____________________

📤산출물 · 제출

16:30 제출: 완성된 착수 계획서(중간보고 포함) + 오늘의 진행 커밋.

- 계획서 파일명: 주4_화_계획서_이름.md(또는 문서)
- 커밋: 브랜치에 2개 이상, 각 커밋이 계획서 단계와 연결되어야 해요.
- 멘토는 "계획서만 보고 내일 뭘 할지 알 수 있는가"를 봐요.

예비 과제

### JavaScript 근육 유지 — 배열·객체 연습 10제

난이도 ★
🎯목표

소과제에서 매일 쓰게 될 배열·객체 다루기를 손에 완전히 붙여요.

📋진행 순서

1. 새 파일 `week4-practice.js`를 만들고, 아래 10문제를 위에서부터 순서대로 풀어요.
2. 각 문제의 답 함수 아래에 `console.log`로 직접 실행해서 결과를 눈으로 확인해요.
3. 검색은 자유지만, 답 코드를 통째로 복사하지 말고 보고 닫은 뒤 직접 타이핑하세요.
4. 다 풀면 가장 어려웠던 문제 번호와 이유를 파일 맨 아래 주석으로 남겨요.

🧩연습문제
배열·객체 연습 10제 (답은 적혀 있지 않아요 — 직접!)

    1. 숫자 배열 [3, 7, 1, 9, 4]에서 가장 큰 값을 반환하는 함수 max(arr)를 작성하세요.
       (Math.max 없이 반복문으로 한 번, Math.max로 한 번 — 두 가지 방법 모두)

    2. 문자열 배열 ["react", "spring", "cloud"]를 모두 대문자로 바꾼
       새 배열을 map으로 만들어 반환하는 함수를 작성하세요.

    3. 숫자 배열에서 짝수만 골라내는 함수 evens(arr)를 filter로 작성하세요.
       예: evens([1,2,3,4,5,6]) → [2,4,6]

    4. 상품 배열 [{name:"키보드", price:35000}, {name:"마우스", price:18000},
       {name:"모니터", price:210000}]에서 전체 가격 합계를 reduce로 구하세요.

    5. 4번의 상품 배열에서 가격이 30000원 이상인 상품의 이름만 담은 배열을
       만드세요. (filter와 map을 이어서 사용)

    6. 객체 {id: 7, title: "회의", done: false}를 받아 done만 true로 바뀐
       "새 객체"를 반환하는 함수를 작성하세요. (원본을 수정하면 안 됨,
       스프레드 문법 사용)

    7. 할 일 배열에서 id가 일치하는 항목의 done을 반전(토글)한 새 배열을
       반환하는 함수 toggle(todos, id)를 작성하세요. 나머지 항목은 그대로.

    8. 문자열 "2026-07-14"를 받아 {year: 2026, month: 7, day: 14} 객체로
       바꾸는 함수를 작성하세요. (split과 Number 사용)

    9. 사용자 배열 [{name:"지수", team:"dev"}, {name:"민호", team:"design"},
       {name:"서연", team:"dev"}]를 받아 {dev: 2, design: 1}처럼 팀별 인원을
       세는 함수를 작성하세요.

    10. fetch로 GET /api/todos를 호출해 응답 JSON을 콘솔에 출력하는
        async 함수 loadTodos()를 작성하세요. 실패했을 때(네트워크 에러)
        "불러오기 실패"를 출력하는 try/catch도 포함하세요.
        (서버가 없어도 좋아요 — catch가 실제로 동작하는지 확인해 보세요)

➕제출

week4-practice.js 파일을 본 과제 제출물에 덧붙여요. 10문제 중 7문제 이상 실행 확인이 목표예요.

디자이너 과제

### "내가 다시 디자인한다면" 개선안 — 1일차: 문제 정의와 러프 시안

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

개발 팀이 두 번째 소과제를 만드는 이틀 동안, 디자이너는 같은 화면을 "다시 디자인"해요. 오늘은 문제 정의와 러프 시안, 내일은 다듬기와 비교 문서예요. 개발 계획서처럼 디자이너도 오늘 "개선 계획서"를 먼저 써요.

📋진행 순서

1. (10:40–11:30) 대상 화면을 고르고 문제를 3개 찾아요. 1~3주차에 팀이 만든 화면 중 하나를 골라 스크린샷을 찍고, "사용자 입장에서 불편한 점"을 3개 적어요. 각 문제에 근거를 붙여요(예: "버튼이 어디 있는지 3초 이상 찾게 됨").
2. (11:30–12:00) 개선 계획서를 써요. 문제 3개 / 각각의 개선 방향 1줄 / 이틀 일정(오늘: 러프, 내일: 완성) / "안 바꿀 것"(범위 밖) 목록.
3. (13:00–15:00) 러프 시안을 그려요. 종이 또는 디자인 도구로 개선안 레이아웃을 잡아요. 색·아이콘은 아직 대충, 배치와 흐름에 집중하세요. 대안을 2가지 이상 그려서 비교해요.
4. (15:00–16:00) 개발 동료 1명에게 5분 인터뷰. 두 대안을 보여주고 어느 쪽이 이해하기 쉬운지, 구현 난이도는 어떤지 듣고 기록해요.
5. (16:00–16:30) 내일 할 일을 3줄로 정리해요. 어느 대안으로 갈지, 무엇을 다듬을지.

📤산출물 · 제출

16:30 제출: 개선 계획서 + 러프 시안 2안 + 인터뷰 기록.

- 파일명: 주4_화_개선계획_이름 폴더에 모아서 제출해요.
- 멘토는 "문제 정의에 근거가 있는가"를 가장 먼저 봐요.

WED
수

## 두 번째 소과제 2일차 — 마무리, PR, 셀프 리뷰

오전 강의에서 코드 리뷰 관점(읽는 사람 입장)을 배웠어요. 오늘은 그 눈으로 "내 코드"를 스스로 리뷰해요.

본 과제

### 구현 마무리 + PR 올리기 + 셀프 리뷰 코멘트 3개

난이도 ★★★
🎯목표

기능을 끝까지 완성해 PR로 정리하고, 남이 지적하기 전에 자기 코드의 약점을 스스로 찾아내는 눈을 길러요.

📋진행 순서

1. (10:40) 어제 중간보고의 "첫 90분 할 일"부터 시작해요. 계획서를 열어 놓고, 끝낸 단계에 체크하며 진행해요.
2. (13:00) 축소 판단 시점. 남은 단계를 보고 16:00까지 다 못 끝낼 것 같으면, 계획서의 "축소 계획"을 지금 실행해요. 늦게 결정할수록 손해예요. 축소했다면 PR 설명에 그 사실과 이유를 적어요.
3. (–15:00) 구현을 마무리하고 완료 조건 3개를 직접 확인해요. 브라우저에서 실제로 눌러 보고, 안 되는 것이 있으면 완료 조건 옆에 솔직하게 "미완"이라고 표시해요.
4. (15:00–15:30) PR을 올려요. 제목은 "기능 요약 (이름)", 본문에는 ① 무엇을 만들었나 ② 어떻게 테스트했나 ③ 아쉬운 점/미완 을 적어요. 스크린샷 1장 이상 첨부.
5. (15:30–16:20) 셀프 리뷰: 내 PR에 코멘트 3개를 직접 달아요. 아래 양식의 세 관점에서 하나씩, 코드 줄을 정확히 지정해서 달아요. "여기 좋음" 같은 칭찬 말고, 리뷰어가 지적할 법한 것을 스스로 먼저 지적하는 거예요.
6. (16:20) 계획서에 2일차 결과를 기록해요. 계획 대비 실제(단계별 예상 시간 vs 실제 시간)를 한 줄씩 적어요. 목요일 발표 자료의 "배운 점" 재료가 돼요.

📝양식
셀프 리뷰 코멘트 3개 — 관점별로 1개씩

    코멘트 ① [읽기 쉬움] — 이름·구조가 헷갈리는 곳
       위치: 파일 ________ / 줄 ____
       내용: "이 변수(함수) 이름은 ______라서 오해할 수 있다.
              ______로 바꾸면 더 명확하다." 처럼 대안까지 적기

    코멘트 ② [깨질 수 있음] — 값이 없거나 이상할 때
       위치: 파일 ________ / 줄 ____
       내용: "______가 비어 있으면(또는 서버가 에러를 주면) 여기서
              ______가 일어난다. ______ 처리가 필요하다."

    코멘트 ③ [중복·정리] — 반복되거나 자리가 어색한 코드
       위치: 파일 ________ / 줄 ____
       내용: "이 코드는 ______와 거의 같다. 함수로 빼면(또는 ______로
              옮기면) 한 곳만 고치면 된다."

📤산출물 · 제출

16:30 제출: PR 링크 + 셀프 리뷰 코멘트 3개.

- PR 본문 3요소(무엇을/어떻게 테스트/아쉬운 점) + 스크린샷 필수.
- 셀프 리뷰 3개는 각각 다른 관점(읽기 쉬움 / 깨질 수 있음 / 중복·정리)이어야 해요.
- 미완이 있어도 감점보다 솔직한 기록이 더 높게 평가돼요.

예비 과제

### 코드 판단 문제 8제 — 어느 쪽이 나을까?

난이도 ★
🎯목표

셀프 리뷰에서 기른 눈을 판단 문제로 한 번 더 훈련해요 — 정답보다 "이유"가 중요해요.

📋진행 순서

1. 아래 8문제를 읽고, 각 문제에 선택 + 이유 2줄을 문서로 적어요.
2. "상황에 따라 다르다"고 답해도 좋아요. 단, 어떤 상황이면 어느 쪽인지 적어야 해요.
3. 다 쓰면 내 어제·오늘 코드에서 같은 상황이 있었는지 1개 찾아 표시해요.

🧩판단 문제
코드 판단 문제 8제 — 선택과 이유를 적으세요

    1. 변수 이름: data1, data2, data3  vs  todos, doneTodos, activeTodos
       — 어느 쪽? 왜?

    2. 한 함수가 120줄  vs  30줄짜리 함수 4개로 분리
       — 어느 쪽? 분리하면 무엇이 좋아지고 무엇이 번거로워질까?

    3. React에서 서버 응답을 기다리는 동안: 아무것도 안 보여줌  vs
       "불러오는 중..." 표시 — 어느 쪽? 사용자는 각각 어떻게 느낄까?

    4. 같은 계산 코드가 3군데 복사되어 있음: 그대로 둠  vs  함수로 추출
       — 언제 추출하는 게 이득이고, 언제 그냥 둬도 될까?

    5. API 응답이 실패했을 때: console.log만 찍음  vs  화면에 에러 메시지
       표시 — 개발 중일 때와 실제 사용자가 쓸 때, 각각 어느 쪽?

    6. Spring Boot에서 요청 값 검증: 프론트에서 했으니 서버는 생략  vs
       서버에서도 다시 검증 — 어느 쪽? 프론트 검증만 있으면 무슨 일이
       생길 수 있을까?

    7. 커밋: 하루 작업을 저녁에 커밋 1개로  vs  단계마다 작은 커밋 여러 개
       — 어느 쪽? 나중에 버그를 찾을 때 무엇이 달라질까?

    8. 주석: 코드 한 줄마다 설명 주석  vs  "왜 이렇게 했는지"만 주석
       — 어느 쪽? 주석이 코드와 달라져 버리면 어떤 문제가 생길까?

➕제출

선택+이유 문서를 본 과제 제출물에 덧붙여요. 8문제 전부, 이유 없이 선택만 적은 답은 인정되지 않아요.

디자이너 과제

### "내가 다시 디자인한다면" 개선안 — 2일차: 완성과 전·후 비교

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

개발 팀의 "PR + 셀프 리뷰"에 해당하는 것이 디자이너의 "완성 시안 + 전·후 비교 문서"예요. 남에게 보여줄 수 있는 형태로 정리하고, 자기 시안의 약점도 스스로 3개 적어요.

📋진행 순서

1. (10:40–14:30) 어제 고른 대안을 완성 시안으로 다듬어요. 색·간격·글자 크기를 정리하고, 실제 문구(버튼 라벨, 에러 메시지)를 진짜처럼 채워요. "여기에 텍스트" 같은 자리표시 문구는 금지.
2. (14:30–15:30) 전·후 비교 문서를 만들어요. 왼쪽에 기존 화면, 오른쪽에 개선안을 나란히 놓고, 화살표로 바뀐 지점 3곳을 짚으며 각각 "무엇이 문제였고 → 어떻게 바꿨고 → 사용자에게 뭐가 좋아지는지"를 한 줄씩 적어요.
3. (15:30–16:00) 셀프 리뷰 3개. 개발 팀과 똑같이, 내 시안의 약점을 스스로 3개 적어요(예: "이 색 대비는 밝은 화면에서 잘 안 보일 수 있다").
4. (16:00–16:30) 개발 동료 1명에게 구현 난이도 확인. 개선안 중 "만들기 어려운 부분"이 있는지 물어보고, 답을 비교 문서에 메모해요.

📤산출물 · 제출

16:30 제출: 완성 시안 + 전·후 비교 문서 + 셀프 리뷰 3개.

- 파일명: 주4_수_개선안_이름 폴더로 제출해요.
- 이 결과물이 목요일 발표 자료의 핵심 재료가 돼요.

THU
목

## 발표 자료 만들기 — "내가 이해한 컴퓨터 / 우리 시스템"

오전에 발표 구성법 강의와 1:1 코칭 순서를 배정받았어요. 오후는 온전히 발표 자료를 만드는 시간이에요.

본 과제

### 10분 발표 슬라이드 초안 + 소리 내어 리허설 1회

난이도 ★★
🎯목표

4주간 배운 것을 "남이 이해할 수 있는 이야기"로 재구성해요 — 설명할 수 있어야 진짜 아는 거예요.

📋진행 순서

1. (10:40–11:10) 슬라이드를 만들기 전에, 아래 구성 가이드의 빈칸부터 채워요. 각 장에서 할 말이 한 줄로 정해져야 슬라이드가 산으로 안 가요.
2. (11:10–12:00) 도입 1장 + 개념 3장의 초안을 만들어요. 슬라이드 1장에 핵심 문장 1개 + 그림 1개가 기본이에요. 글자를 문단으로 채우지 마세요 — 읽는 자료가 아니라 말하는 자료예요.
3. (13:00–14:30) 우리 시스템 연결 2장 + 배운 점 1장을 만들어요. 연결 2장에는 월요일 흐름도와 화·수 소과제(디자이너는 개선안) 결과물을 꼭 넣어요. 새로 그리지 말고 이번 주 산출물을 재사용하세요.
4. (14:30–15:00) 그림을 점검해요. 슬라이드 7장 중 그림·스크린샷·도식이 있는 장이 5장 이상인지 세어 보세요. 부족하면 글을 그림으로 바꿔요.
5. (15:00–15:40) 소리 내어 리허설 1회. 타이머를 켜고 실제로 서서, 실제 목소리 크기로 처음부터 끝까지 말해요. 속으로 읽는 건 리허설이 아니에요. 걸린 시간을 기록해요(목표 9~11분).
6. (15:40–16:20) 리허설에서 발견한 문제를 고쳐요. 말이 꼬인 장, 시간을 너무 잡아먹은 장을 표시하고 슬라이드나 대본을 수정해요. 1:1 코칭에서 물어볼 질문 2개를 적어 두세요.

📝양식
발표 구성 가이드 — 슬라이드를 만들기 전에 빈칸을 채우세요

    발표 제목: 내가 이해한 ______________________ (10분)

    [도입 1장] 4주 전의 나는 ______를 몰랐다.
       지금의 나는 ______를 설명할 수 있다. (호기심을 끄는 한 문장)

    [개념 3장] 내가 고른 핵심 개념 3개 — 각 장에서 할 말 한 줄
       개념 ①: ____________ — "____________________________"
       개념 ②: ____________ — "____________________________"
       개념 ③: ____________ — "____________________________"
       (예: 클라이언트와 서버 / API / 상태와 화면 / DB / 배포와 클라우드
        중에서 자신 있는 3개. 디자이너는 사용자 여정 / 화면 설계 /
        피드백 반영 등으로 바꿔도 좋아요)

    [우리 시스템 연결 2장] 개념이 우리가 만든 것 어디에 있는지
       연결 ①: 개념 __는 내가 만든 ______에서 이렇게 쓰였다 (스크린샷/흐름도)
       연결 ②: 개념 __는 ______에서 이렇게 쓰였다 (스크린샷/시안)

    [배운 점 1장] 기술 말고 "일하는 방식"에서 배운 것 1가지
       → ________________________________________________
       (예: 계획을 쪼개는 법, 막혔을 때 질문하는 법, 리뷰 받는 법)

📤산출물 · 제출

16:30 제출: 발표 자료 초안(7장 내외) + 리허설 기록.

- 리허설 기록: 걸린 시간 / 막힌 장 / 내일 고칠 것 — 3줄이면 충분해요.
- 1:1 코칭 질문 2개도 함께 제출해요.
- 완성도보다 구조(7장 구성이 서 있는가)를 봐요. 꾸미기는 내일 아침에.

예비 과제

### 예상 질문 5개 만들고 답 준비하기

난이도 ★
🎯목표

발표 뒤 질의응답에서 당황하지 않도록, 질문을 스스로 예측하고 답을 미리 말해 봐요.

📋진행 순서

1. 내 발표를 처음 듣는 사람이 되었다고 상상하고, 나올 법한 질문 5개를 적어요. 최소 1개는 "가장 받기 싫은 질문"이어야 해요.
2. 각 질문에 3~4문장 답을 적어요. 모르는 부분이 섞여 있으면 "여기까지는 알고, 여기부터는 아직 공부 중"이라고 답하는 연습도 해요.
3. 답 5개를 소리 내어 한 번씩 말해 봐요.
4. 질문·답 문서를 발표 자료와 같은 폴더에 저장해요.

➕제출

예상 질문·답 문서(5문항)를 본 과제 제출물에 덧붙여요. 금요일 발표회에서 멘토가 이 중 하나를 실제로 물어볼 수 있어요.

디자이너 과제

### 디자이너의 10분 발표 — 같은 구성, 다른 재료

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

진행 순서와 7장 구성, 리허설, 제출물은 본 과제와 완전히 같아요. 다른 것은 재료뿐: 개념 3장은 "사용자 여정·화면 설계·피드백 반영" 같은 디자인 개념으로, 우리 시스템 연결 2장은 월요일 여정 지도와 화·수 개선안 전·후 비교로 채워요. 단, 최소 1장은 "개발 팀과 협업하며 알게 된 기술 이야기"(예: 왜 로딩 화면이 필요한가)를 넣어요 — 그게 이번 4주의 차별점이에요.

📤산출물 · 제출

16:30 제출: 발표 자료 초안(7장 내외) + 리허설 기록 + 코칭 질문 2개. (본 과제와 동일)

FRI
금

## 미니 발표회 — 최종 점검과 자기평가

오후에 미니 발표회와 중간평가 면담이 있어요. 오전 자기주도 시간은 최종 점검, 발표 후에는 자기평가서를 써요.

본 과제

### 발표 최종 점검 + 발표 + 자기평가서 작성

난이도 ★★
🎯목표

준비한 것을 실전에서 전달해 보고, 4주간의 나를 스스로 공정하게 평가하는 경험을 해요.

📋진행 순서

1. (10:40–11:10) 어제 코칭 피드백을 반영해요. 1:1 코칭에서 받은 지적을 슬라이드에 반영하되, 새 장을 추가하지 마세요. 발표 직전의 큰 수술은 사고의 지름길이에요. 고치는 건 문구·그림·순서까지만.
2. (11:10–11:40) 최종 리허설 1회. 어제처럼 타이머를 켜고 서서, 소리 내어 처음부터 끝까지. 9~11분 안에 들어오는지 확인하고, 넘치면 개념 장에서 말을 줄여요(장을 빼는 게 아니라 말을 줄이는 거예요).
3. (11:40–12:00) 발표 환경을 점검해요. 발표용 PC에서 자료가 열리는지, 글자가 뒤에서도 보이는지, 시연 화면이 있다면 미리 띄워지는지 확인해요. 자료는 2곳 이상에 저장(로컬 + 클라우드).
4. (13:00–) 미니 발표회. 내 차례가 아닐 때는 청중 역할이 과제예요: 발표자마다 좋았던 점 1개 + 질문 1개를 메모하고, 질의응답 때 최소 1번은 손을 들어 질문해요.
5. (발표회 종료 후–16:20) 자기평가서를 작성해요. 평가 루브릭 문서의 자기평가 양식(아래에 동일 양식 수록)을 채워요. 근거 없는 점수는 인정되지 않아요 — 모든 항목에 이번 주 산출물을 근거로 대세요.
6. (16:20–16:30) 최종 발표자료와 자기평가서를 제출해요. 중간평가 면담은 이 자기평가서를 바탕으로 진행돼요.

📝양식
자기평가서 (평가 루브릭 문서의 자기평가 양식과 동일)

    이름: ________  작성일: 2026-__-__

    1. 항목별 자기평가 — 각 항목에 1~4점과 근거(이번 주 산출물·사례)를 함께
       (1: 아직 어려움 / 2: 도움 받으면 가능 / 3: 혼자 가능 / 4: 남에게 설명 가능)

       ① 시스템 이해 (요청 흐름을 설명할 수 있다)        점수: __
          근거: ____________________________________________
       ② 구현 능력 (계획한 기능을 완성했다)              점수: __
          근거: ____________________________________________
       ③ 일하는 방식 (계획·커밋·30분 룰·리뷰 반영)       점수: __
          근거: ____________________________________________
       ④ 소통 (질문·발표·리뷰 코멘트)                    점수: __
          근거: ____________________________________________

    2. 4주 전의 나와 지금의 나 — 가장 크게 달라진 것 1가지 (3~5문장)
       → ________________________________________________

    3. 가장 어려웠던 순간과 그때 내가 한 행동 (3~5문장)
       → ________________________________________________

    4. 남은 기간에 집중하고 싶은 것 2가지 (구체적으로)
       ① ______________________________________________
       ② ______________________________________________

    5. 멘토에게 하고 싶은 말 / 요청 (자유)
       → ________________________________________________

📤산출물 · 제출

16:30 제출: 최종 발표자료 + 자기평가서.

- 발표자료 파일명: 주4_금_발표_이름.pdf(발표에 쓴 최종본 그대로)
- 자기평가서: 4개 항목 전부 점수+근거, 서술 문항 전부 작성.
- 청중 메모(좋았던 점+질문)도 함께 제출하면 소통 항목 평가에 반영돼요.

예비 과제

### 4주 산출물 아카이브 — 내 포트폴리오의 씨앗

난이도 ★
🎯목표

4주간 만든 것을 한 폴더에 정리해, 나중에 포트폴리오로 키울 수 있는 상태로 만들어요.

📋진행 순서

1. 폴더를 하나 만들고(`어썸데브_4주_이름`), 주차별 하위 폴더 4개를 만들어요.
2. 각 주의 대표 산출물을 모아 넣어요: 계획서, 흐름도, PR 링크 목록, 발표자료, 시안 등.
3. 맨 위에 `README` 문서를 만들어 "무엇을 만들었고, 뭘 배웠는지"를 주차별 2줄씩, 총 8줄로 적어요.
4. 지금은 부끄러운 결과물도 빼지 마세요 — 성장의 증거는 "전"이 있어야 보여요.

➕제출

아카이브 폴더(README 포함)를 제출해요. 이 폴더는 중간평가 면담 자료로도 쓰여요.

디자이너 과제

### 발표 + 자기평가서 — 개발 팀과 동일 진행

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

오늘은 개발·디자인 구분 없이 본 과제와 완전히 동일하게 진행해요. 자기평가서의 ② "구현 능력" 항목만 "시안 완성도(문제 정의 → 시안 → 전·후 비교를 끝까지 완성했다)"로 바꿔 읽고 평가하세요. 근거는 화·수의 개선안 산출물에서 가져와요. 예비 과제(아카이브)도 동일하게 해당돼요.

📤산출물 · 제출

16:30 제출: 최종 발표자료 + 자기평가서(② 항목만 치환). 파일명 규칙은 본 과제와 같아요.

For Mentors

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

요일별로 무엇을 확인하고 어떤 질문을 던질지 정리했어요. 학생도 이 가이드를 볼 수 있으니, "무엇을 준비해야 하는지"의 기준으로 삼으세요.

월
흐름도의 연결이 진짜인지 확인. 그림 없이 말로만 2분 설명을 시켜 보고, "④에서 ⑤로 갈 때 정확히 무엇이 전달되나요?"처럼 상자 사이의 화살표를 파고드는 질문을 해요.
화
계획서가 스스로 서는지 확인. "이 계획서만 보고 내일 아침에 뭘 할지 알겠어요?"를 기준으로 보고, "가장 늦어질 것 같은 단계와 그때의 축소 계획"을 학생 입으로 말하게 해요.
수
셀프 리뷰의 깊이 확인. 코멘트 3개 중 하나를 골라 "그럼 어떻게 고칠 건가요?"를 물어요. 미완이 있다면 축소 판단을 13:00에 했는지(늦지 않았는지)를 확인해요.
목
구조와 시간 확인. 7장 구성이 서 있는지, 리허설 시간이 9~11분에 들어오는지 보고, "이 발표에서 딱 한 장만 남긴다면 어느 장인가요?"로 핵심을 묻어요. 꾸미기 지적은 최소로.
금
자기평가의 근거 확인. 점수보다 근거를 봐요. 점수가 근거보다 높으면 "그 점수의 근거가 되는 산출물이 뭐예요?"를, 낮으면 "이 산출물이 있는데 왜 낮게 줬어요?"를 물어 스스로 조정하게 해요. 면담은 4번 항목(남은 기간 집중할 것)에서 출발해요.