3주차 일일 과제집
첫 소과제 실전

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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