이 과제집은 오전 강의가 끝난 뒤, 오후 자기주도 시간(10:40–12:00, 13:00–16:30)에 여러분이 혼자 힘으로 수행하는 과제를 담고 있어요. 매일 16:30 멘토 리뷰 시간에 제출할 산출물이 정해져 있으니, 하루를 시작할 때 그날의 산출물부터 확인하고 거꾸로 시간을 계획해 보세요. 4주차는 지금까지 배운 것을 하나로 묶고, 금요일 미니 발표회로 마무리하는 주예요.
4주차도 리듬은 같아요. 다만 이번 주는 "만드는 것"만큼 "정리하고 말로 설명하는 것"이 중요한 주라는 점을 기억하세요.
규칙: 과제가 일찍 끝나면 놀지 말고 예비 과제로 — 예비 과제도 평가에 반영돼요.
오전 강의 "요청 흐름 전체 정리"에서 배운 그림을, 이번엔 내 손으로 처음부터 끝까지 그려요.
1~3주차에 따로따로 배운 조각들(React, REST API, Spring Boot, DB)을 하나의 요청 흐름으로 꿰어, 시스템 전체를 스스로 설명할 수 있게 돼요.
[ ] 7단계 상자가 모두 있고 화살표로 이어져 있다 [ ] 각 단계 아래에 "실제로 일어나는 일"이 1~2줄씩 적혀 있다 [ ] 1~3주차 개념 연결 표시가 10개 이상 붙어 있다 [ ] 에러(실패) 흐름이 점선으로 1갈래 이상 그려져 있다 [ ] 내 3주차 소과제의 실제 파일명이 3개 이상 상자 옆에 적혀 있다 [ ] 그림만 보고 2분 안에 말로 설명할 수 있다
16:30 제출: 전체 흐름도 1장.
흐름도에서 설명이 가장 얇았던 단계 하나를 골라, 그 단계만큼은 자신 있게 만들어요.
질문 3개 + 답 문서(반 쪽 분량)와 업데이트된 흐름도를 본 과제 제출물에 덧붙여요. 예비 과제까지 한 사람의 흐름도는 리뷰에서 티가 나요.
같은 7단계를 그리되, 관점을 "기계"가 아니라 "사람"에 둬요. 개발자 흐름도가 "요청이 어디를 지나가는가"라면, 디자이너 버전은 "그동안 사용자는 무엇을 보고, 무엇을 느끼고, 무엇을 기다리는가"예요.
16:30 제출: 사용자 여정 지도 1장 + 로딩·에러 화면 스케치.
오전 강의에서 두 번째 소과제(난이도 상승)를 받았어요. 오늘은 계획을 스스로 완성하고 구현을 시작하는 날이에요.
3주차에는 멘토가 계획을 다듬어 줬지만, 이번엔 멘토 확인 전에 스스로 계획의 완성도를 끌어올리는 힘을 길러요.
feature/기능이름-이름). 첫 커밋은 빈 뼈대(파일·폴더 구조)만이라도 좋아요.■ 소과제 이름: ______________________ ■ 작성자: ________ ■ 날짜: 2026-__-__ 1. 한 줄 요약 (이 기능은 사용자가 ______ 할 수 있게 한다) → ________________________________________________ 2. 완료 조건 (이게 되면 끝) — 3개 ① ______________________________________________ ② ______________________________________________ ③ ______________________________________________ 3. 화면 스케치 / API 설계 (택1 이상) - 화면: 어떤 요소가 어디에? (간단 스케치 첨부) - API: 메서드 ____ / 경로 /api/____________ / 요청 본문 ______ / 응답 ______ 4. 구현 단계 쪼개기 (한 단계 = 90분 이내, 순서대로) 1단계: ____________________ (예상 __분) 2단계: ____________________ (예상 __분) 3단계: ____________________ (예상 __분) 4단계: ____________________ (예상 __분) 5단계: ____________________ (예상 __분) 5. 예상 위험 & 대비 - 가장 자신 없는 부분: ______________ → 막히면: ______________ - 수요일 오후까지 안 끝나면 뺄 것(축소 계획): ______________ --- 1일차 중간보고 (16:00 작성) --- 완료한 단계: ______ / 예상과 달랐던 점: ____________________ 내일 첫 90분에 할 일: ____________________
16:30 제출: 완성된 착수 계획서(중간보고 포함) + 오늘의 진행 커밋.
소과제에서 매일 쓰게 될 배열·객체 다루기를 손에 완전히 붙여요.
week4-practice.js를 만들고, 아래 10문제를 위에서부터 순서대로 풀어요.console.log로 직접 실행해서 결과를 눈으로 확인해요.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문제 이상 실행 확인이 목표예요.
개발 팀이 두 번째 소과제를 만드는 이틀 동안, 디자이너는 같은 화면을 "다시 디자인"해요. 오늘은 문제 정의와 러프 시안, 내일은 다듬기와 비교 문서예요. 개발 계획서처럼 디자이너도 오늘 "개선 계획서"를 먼저 써요.
16:30 제출: 개선 계획서 + 러프 시안 2안 + 인터뷰 기록.
오전 강의에서 코드 리뷰 관점(읽는 사람 입장)을 배웠어요. 오늘은 그 눈으로 "내 코드"를 스스로 리뷰해요.
기능을 끝까지 완성해 PR로 정리하고, 남이 지적하기 전에 자기 코드의 약점을 스스로 찾아내는 눈을 길러요.
코멘트 ① [읽기 쉬움] — 이름·구조가 헷갈리는 곳 위치: 파일 ________ / 줄 ____ 내용: "이 변수(함수) 이름은 ______라서 오해할 수 있다. ______로 바꾸면 더 명확하다." 처럼 대안까지 적기 코멘트 ② [깨질 수 있음] — 값이 없거나 이상할 때 위치: 파일 ________ / 줄 ____ 내용: "______가 비어 있으면(또는 서버가 에러를 주면) 여기서 ______가 일어난다. ______ 처리가 필요하다." 코멘트 ③ [중복·정리] — 반복되거나 자리가 어색한 코드 위치: 파일 ________ / 줄 ____ 내용: "이 코드는 ______와 거의 같다. 함수로 빼면(또는 ______로 옮기면) 한 곳만 고치면 된다."
16:30 제출: PR 링크 + 셀프 리뷰 코멘트 3개.
셀프 리뷰에서 기른 눈을 판단 문제로 한 번 더 훈련해요 — 정답보다 "이유"가 중요해요.
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문제 전부, 이유 없이 선택만 적은 답은 인정되지 않아요.
개발 팀의 "PR + 셀프 리뷰"에 해당하는 것이 디자이너의 "완성 시안 + 전·후 비교 문서"예요. 남에게 보여줄 수 있는 형태로 정리하고, 자기 시안의 약점도 스스로 3개 적어요.
16:30 제출: 완성 시안 + 전·후 비교 문서 + 셀프 리뷰 3개.
오전에 발표 구성법 강의와 1:1 코칭 순서를 배정받았어요. 오후는 온전히 발표 자료를 만드는 시간이에요.
4주간 배운 것을 "남이 이해할 수 있는 이야기"로 재구성해요 — 설명할 수 있어야 진짜 아는 거예요.
발표 제목: 내가 이해한 ______________________ (10분) [도입 1장] 4주 전의 나는 ______를 몰랐다. 지금의 나는 ______를 설명할 수 있다. (호기심을 끄는 한 문장) [개념 3장] 내가 고른 핵심 개념 3개 — 각 장에서 할 말 한 줄 개념 ①: ____________ — "____________________________" 개념 ②: ____________ — "____________________________" 개념 ③: ____________ — "____________________________" (예: 클라이언트와 서버 / API / 상태와 화면 / DB / 배포와 클라우드 중에서 자신 있는 3개. 디자이너는 사용자 여정 / 화면 설계 / 피드백 반영 등으로 바꿔도 좋아요) [우리 시스템 연결 2장] 개념이 우리가 만든 것 어디에 있는지 연결 ①: 개념 __는 내가 만든 ______에서 이렇게 쓰였다 (스크린샷/흐름도) 연결 ②: 개념 __는 ______에서 이렇게 쓰였다 (스크린샷/시안) [배운 점 1장] 기술 말고 "일하는 방식"에서 배운 것 1가지 → ________________________________________________ (예: 계획을 쪼개는 법, 막혔을 때 질문하는 법, 리뷰 받는 법)
16:30 제출: 발표 자료 초안(7장 내외) + 리허설 기록.
발표 뒤 질의응답에서 당황하지 않도록, 질문을 스스로 예측하고 답을 미리 말해 봐요.
예상 질문·답 문서(5문항)를 본 과제 제출물에 덧붙여요. 금요일 발표회에서 멘토가 이 중 하나를 실제로 물어볼 수 있어요.
진행 순서와 7장 구성, 리허설, 제출물은 본 과제와 완전히 같아요. 다른 것은 재료뿐: 개념 3장은 "사용자 여정·화면 설계·피드백 반영" 같은 디자인 개념으로, 우리 시스템 연결 2장은 월요일 여정 지도와 화·수 개선안 전·후 비교로 채워요. 단, 최소 1장은 "개발 팀과 협업하며 알게 된 기술 이야기"(예: 왜 로딩 화면이 필요한가)를 넣어요 — 그게 이번 4주의 차별점이에요.
16:30 제출: 발표 자료 초안(7장 내외) + 리허설 기록 + 코칭 질문 2개. (본 과제와 동일)
오후에 미니 발표회와 중간평가 면담이 있어요. 오전 자기주도 시간은 최종 점검, 발표 후에는 자기평가서를 써요.
준비한 것을 실전에서 전달해 보고, 4주간의 나를 스스로 공정하게 평가하는 경험을 해요.
이름: ________ 작성일: 2026-__-__
1. 항목별 자기평가 — 각 항목에 1~4점과 근거(이번 주 산출물·사례)를 함께
(1: 아직 어려움 / 2: 도움 받으면 가능 / 3: 혼자 가능 / 4: 남에게 설명 가능)
① 시스템 이해 (요청 흐름을 설명할 수 있다) 점수: __
근거: ____________________________________________
② 구현 능력 (계획한 기능을 완성했다) 점수: __
근거: ____________________________________________
③ 일하는 방식 (계획·커밋·30분 룰·리뷰 반영) 점수: __
근거: ____________________________________________
④ 소통 (질문·발표·리뷰 코멘트) 점수: __
근거: ____________________________________________
2. 4주 전의 나와 지금의 나 — 가장 크게 달라진 것 1가지 (3~5문장)
→ ________________________________________________
3. 가장 어려웠던 순간과 그때 내가 한 행동 (3~5문장)
→ ________________________________________________
4. 남은 기간에 집중하고 싶은 것 2가지 (구체적으로)
① ______________________________________________
② ______________________________________________
5. 멘토에게 하고 싶은 말 / 요청 (자유)
→ ________________________________________________
16:30 제출: 최종 발표자료 + 자기평가서.
4주간 만든 것을 한 폴더에 정리해, 나중에 포트폴리오로 키울 수 있는 상태로 만들어요.
어썸데브_4주_이름), 주차별 하위 폴더 4개를 만들어요.README 문서를 만들어 "무엇을 만들었고, 뭘 배웠는지"를 주차별 2줄씩, 총 8줄로 적어요.아카이브 폴더(README 포함)를 제출해요. 이 폴더는 중간평가 면담 자료로도 쓰여요.
오늘은 개발·디자인 구분 없이 본 과제와 완전히 동일하게 진행해요. 자기평가서의 ② "구현 능력" 항목만 "시안 완성도(문제 정의 → 시안 → 전·후 비교를 끝까지 완성했다)"로 바꿔 읽고 평가하세요. 근거는 화·수의 개선안 산출물에서 가져와요. 예비 과제(아카이브)도 동일하게 해당돼요.
16:30 제출: 최종 발표자료 + 자기평가서(② 항목만 치환). 파일명 규칙은 본 과제와 같아요.
요일별로 무엇을 확인하고 어떤 질문을 던질지 정리했어요. 학생도 이 가이드를 볼 수 있으니, "무엇을 준비해야 하는지"의 기준으로 삼으세요.