2주차 일일 과제집
코드 읽기 & 자료구조 적용

처음 보는 프로젝트를 받아도 "어디에 무엇이 있는지" 10분 안에 파악하는 눈을 만들어요.

1. 멘토가 안내한 연습용 React 프로젝트를 에디터(VS Code)로 열어요. 왼쪽 파일 탐색기에서 최상위 폴더부터 하나씩 펼쳐 보세요.
2. 주요 폴더 10개를 골라요. 예: src/, src/components/, src/pages/, src/hooks/, src/api/, public/, node_modules/ 등. 각 폴더 안의 파일 2~3개를 실제로 열어 보고 "이 폴더의 역할"을 한 줄로 적어요. 추측이면 문장 끝에 (추측)이라고 표시해요.
3. 아래 구조도 워크시트 양식에 맞춰 종이나 문서에 트리 형태로 그려요. 그림 도구는 자유(손그림 사진도 OK)지만 폴더 이름과 역할 한 줄은 반드시 들어가야 해요.
4. 같은 방법으로 연습용 Spring Boot 프로젝트를 열어요. src/main/java/ 아래 패키지(controller, service, repository, domain/entity, config 등)와 src/main/resources/를 중심으로 폴더 10개를 골라 역할 한 줄을 적어요.
5. 두 구조도를 나란히 놓고 공통점 2개, 차이점 2개를 문장으로 적어요. (예: "둘 다 화면/요청을 받는 층과 데이터 층이 나뉘어 있다")
6. 마지막으로 "내가 열어 봤지만 역할을 모르겠는 파일" 3개를 골라 파일 경로와 함께 질문으로 적어요. 이건 16:30 리뷰 때 멘토에게 그대로 물어봐요.

아래 10문제를 새 파일 day1.js에 번호 주석과 함께 풀어요. 브라우저 콘솔이나 Node로 실행해 console.log 결과를 확인하고, 답은 외우지 말고 직접 실행해서 검증해요.

1. 변수 name에 자기 이름, age에 나이를 담고 "저는 OO이고 18살입니다" 형태로 출력하세요. (템플릿 문자열 ` ` 사용)
2. let과 const의 차이를 코드로 증명하세요. const로 선언한 변수에 재할당을 시도하고, 발생한 에러 메시지를 주석으로 남기세요.
3. 숫자 score가 90 이상이면 "A", 80 이상이면 "B", 그 외에는 "C"를 출력하는 if/else if/else를 작성하세요. score를 95, 82, 60으로 바꿔 3번 실행해 보세요.
4. 숫자 n이 짝수면 "짝수", 홀수면 "홀수"를 출력하세요. (% 연산자 사용)
5. for 반복문으로 1부터 10까지 출력하세요.
6. for 반복문으로 1부터 100까지의 합을 구해 출력하세요. (정답은 5050이 나와야 해요)
7. while 반복문으로 10부터 1까지 거꾸로 출력하세요.
8. 1부터 30까지 중 3의 배수만 출력하세요. (if와 % 조합)
9. 구구단 7단을 "7 x 1 = 7" 형태로 출력하세요.
10. 이중 for문으로 별 찍기: 1줄에 *, 2줄에 **, ... 5줄에 *****가 나오게 출력하세요.

프로젝트의 "명함"인 설정 파일을 읽고 이 프로젝트가 무엇으로 만들어졌는지 설명할 수 있게 돼요.

1. React 프로젝트의 package.json을 열어요.
2. scripts 항목의 명령어 각각이 무슨 일을 하는지 추측해서 한 줄씩 적어요. (예: dev, build, lint)
3. dependencies에서 라이브러리 5개를 골라 이름을 검색해 보고, 각각의 용도를 한 줄로 적어요.
4. Spring Boot 쪽 pom.xml(또는 build.gradle)을 열어 같은 방식으로 의존성 5개의 용도를 적어요.

1. 멘토가 안내한 우리 서비스 화면(웹) 5개 이상을 돌아다니며 스크린샷을 찍어요.
2. 스포이드 도구(Figma·브라우저 개발자도구 등)로 화면에 실제 쓰인 색을 전부 추출해요. HEX 값으로 기록해요.
3. Figma에 색상 칩을 나열하고 주색·보조색·회색 계열·경고/성공색으로 그룹핑해요.
4. "거의 같은데 미묘하게 다른 색" 쌍을 찾아 표시해요. (예: #333333 vs #343434) — 목요일 불일치 찾기의 재료가 돼요.
5. 색이 몇 개인지 세어 보고, "이 서비스의 색은 관리되고 있는가?"에 대한 내 생각을 3문장으로 적어요.

화면 뒤에서 오가는 요청과 응답을 스스로 관찰하고 "이 요청이 무슨 일을 하는지" 추론하는 힘을 길러요.

1. 브라우저에서 우리 서비스를 열고 F12 → Network 탭을 켜요. 필터를 Fetch/XHR로 바꾸면 API 요청만 보여요.
2. 서비스를 자유롭게 사용하면서(로그인, 목록 보기, 검색, 저장 등) Network 탭에 잡히는 요청 중 서로 다른 동작 5개를 골라요. GET만 5개 고르지 말고 POST·PUT·DELETE 중 최소 1개를 포함해요.
3. 각 요청을 클릭해 Headers·Payload·Response를 확인하고 아래 추적표 양식에 기록해요. 응답 JSON이 길면 핵심 필드 5개만 적어도 돼요.
4. 각 요청마다 "이 요청은 ~를 하는 것 같다"라는 추측 문장을 적어요. 근거(URL 단어, 응답 내용 등)도 한 줄 함께요.
5. 5개 중 하나를 골라 상태 코드가 무엇인지 확인하고, 일부러 실패시켜 보세요(예: 로그아웃 상태로 호출, 잘못된 검색어). 성공/실패 시 상태 코드와 응답이 어떻게 다른지 2문장으로 기록해요.
6. 다 적었으면 표를 다시 읽으며 내가 자신 없는 칸에 형광 표시를 해요. 리뷰 때 그 부분부터 질문해요.

아침 자료구조 강의(배열·리스트)와 연결되는 문제예요. day2.js에 15문제를 모두 풀고 실행해서 확인해요.

공통 준비: const fruits = ["사과", "바나나", "포도"]; const nums = [3, 1, 4, 1, 5, 9, 2, 6];

1. fruits 배열 끝에 "딸기"를 추가하고(push) 배열 전체를 출력하세요.
2. fruits 배열의 마지막 요소를 제거하고(pop) 제거된 값과 남은 배열을 각각 출력하세요.
3. fruits 배열 맨 앞에 "귤"을 추가하세요(unshift). 맨 앞 요소를 제거하는 것(shift)도 해 보세요.
4. nums 배열의 길이(length)와 3번째 요소(인덱스 주의!)를 출력하세요.
5. nums에서 5가 몇 번째 인덱스에 있는지 indexOf로 찾아 출력하세요. 없는 값 100을 찾으면 무엇이 나오는지도 확인하세요.
6. nums 배열에 9가 포함되어 있는지 includes로 확인해 true/false를 출력하세요.
7. for문으로 nums의 모든 요소를 한 줄씩 출력하세요. 그다음 같은 일을 forEach로 다시 작성하세요.
8. nums의 모든 요소를 2배로 만든 새 배열을 map으로 만들어 출력하세요. (원본 nums는 그대로여야 해요 — 확인 출력 포함)
9. nums에서 4 이상인 요소만 남긴 새 배열을 filter로 만들어 출력하세요.
10. nums의 합계를 구하세요. 먼저 for문으로, 그다음 reduce로 두 번 구현하세요.
11. nums에서 가장 큰 값을 찾으세요. (반복문으로 직접 — Math.max 금지)
12. fruits 배열을 join으로 "사과, 바나나, 포도" 형태의 문자열로 만들어 출력하세요.
13. nums를 오름차순 정렬하세요. sort()만 쓰면 [1,1,2,3,4,5,6,9]가 안 나올 수 있어요 — 왜 그런지 주석으로 설명하고 올바르게 고치세요.
14. 학생 배열 const students = [{name:"김", score:85}, {name:"이", score:92}, {name:"박", score:78}] 에서 score가 80 이상인 학생의 name만 담긴 배열을 만드세요. (filter + map 조합)
15. nums에서 중복을 제거한 새 배열을 만드세요. 방법은 자유(반복문, includes, Set 등) — 어떤 방법을 왜 골랐는지 주석 한 줄을 남기세요.

자주 만나는 HTTP 상태 코드를 내 언어로 정리해 두면 앞으로 에러를 볼 때 당황하지 않아요.

1. 다음 8개 코드에 대해 조사해요: 200, 201, 301, 400, 401, 403, 404, 500.
2. 각 코드마다 "공식 의미 한 줄 + 내 언어로 다시 쓴 한 줄 + 언제 만날 것 같은지 예시 한 줄"을 적어요.
3. 오늘 Network 탭에서 실제로 본 코드에는 ✔ 표시를 해요.

1. 어제 본 화면 5개에서 제목·부제목·본문·버튼 라벨·캡션에 해당하는 텍스트를 찾아요.
2. 개발자도구로 각 텍스트를 클릭 검사해 font-family / font-size / font-weight / line-height / 색상을 기록해요.
3. Figma에 "타입 스케일 표"를 만들어요: 역할(제목1, 제목2, 본문…) × 속성 값.
4. 같은 역할인데 값이 다른 경우(예: 본문이 어떤 화면은 14px, 어떤 화면은 15px)를 찾아 표시해요.
5. 글자 크기 종류가 총 몇 개인지 세고, "적절한 개수인가?"에 대한 생각을 3문장으로 적어요.

"버튼 클릭부터 응답까지" 한 기능의 전체 여정을 코드와 화면을 오가며 설명할 수 있게 돼요 — 이게 되면 코드 읽기의 절반은 끝난 거예요.

1. 해부할 기능을 하나 골라요. 추천: 로그인 또는 목록 조회. 너무 복잡한 기능(결제 등)은 피해요. 고민되면 10:40에 멘토에게 30초만 물어보고 시작해요.
2. 화면에서 관찰: 그 기능을 직접 사용하면서 "무엇을 누르면 → 화면이 어떻게 변하고 → Network 탭에 어떤 요청이 뜨고 → 어떤 응답이 오는지"를 순서대로 메모해요. (어제 배운 추적표 방식 재활용)
3. 프론트 코드에서 찾기: React 프로젝트에서 그 버튼/화면을 담당하는 컴포넌트 파일을 찾아요. 에디터 전체 검색(Ctrl+Shift+F)에 버튼에 적힌 문구나 URL 일부를 넣으면 빨라요. 찾으면 파일 경로와 줄 번호를 기록해요.
4. 그 컴포넌트에서 API를 호출하는 코드(fetch, axios 등)를 찾아 파일·줄을 기록하고, 화면에서 본 요청 URL과 일치하는지 확인해요.
5. 백엔드 코드에서 찾기: Spring Boot 프로젝트에서 그 URL을 받는 컨트롤러를 찾아요(@GetMapping·@PostMapping의 경로 검색). 컨트롤러 → 서비스 → 리포지토리로 이어지는 호출을 따라가며 각 단계의 파일·줄·역할 한 줄을 기록해요. 모든 줄을 이해할 필요는 없어요 — 흐름의 연결만 잡으면 성공이에요.
6. 아래 보고서 양식대로 정리해요. 이해 안 되는 코드는 "❓ 여기서 ~하는 것 같은데 확실하지 않음"으로 솔직하게 적어요. ❓가 있는 보고서가 없는 보고서보다 좋은 보고서예요.
7. 시간이 남으면 흐름을 그림 1장(손그림 OK)으로 그려 보고서에 붙여요.

아침 자료구조 강의(해시)와 연결돼요. 객체와 Map은 "이름표로 값을 찾는 구조"예요. day3.js에 10문제를 풀어요.

1. 자신을 표현하는 객체 me를 만드세요. name, age, school, hobby 4개 속성을 넣고 전체를 출력하세요.
2. me.hobby를 점 표기법으로, me["school"]을 대괄호 표기법으로 각각 출력하세요. 두 방식의 차이를 주석 한 줄로 적으세요.
3. me에 새 속성 goal(올해 목표)을 추가하고, age 속성을 delete로 삭제한 뒤 결과를 출력하세요.
4. Object.keys(me)와 Object.values(me)를 출력하고, 각각 무엇이 나오는지 주석으로 설명하세요.
5. for...in 반복문으로 me의 모든 "속성이름: 값"을 한 줄씩 출력하세요.
6. 메뉴판 객체 const menu = { 아메리카노: 4500, 라떼: 5000, 주스: 6000 } 에서 사용자가 고른 메뉴 이름(변수 pick)의 가격을 출력하세요. menu에 없는 메뉴면 "없는 메뉴입니다"를 출력하세요.
7. 문자열 "hello world"에서 각 글자가 몇 번 나오는지 세는 객체를 만드세요. (예: {h:1, e:1, l:3, ...}) 공백은 제외하세요.
8. new Map()으로 학번→이름 Map을 만들고 set으로 3명을 넣은 뒤, get으로 1명을 꺼내고 has로 존재 여부를 확인하세요. size도 출력하세요.
9. 7번을 객체 대신 Map으로 다시 구현하세요. 객체 버전과 Map 버전 중 어느 쪽이 편했는지 주석 한 줄로 적으세요.
10. 학생 배열 [{name:"김", team:"A"}, {name:"이", team:"B"}, {name:"박", team:"A"}] 를 팀별로 묶은 객체 {A:["김","박"], B:["이"]} 로 변환하세요.

한 번 해 본 해부를 다른 기능에 반복하면 속도가 2배로 붙는 걸 스스로 느낄 수 있어요.

1. 본 과제에서 안 고른 기능 하나를 골라요.
2. 보고서 양식 중 ①(화면 관찰)과 ④(전체 흐름 한 문장)만 채워요. 코드 추적은 여유 있을 때만.
3. 본 과제 때보다 얼마나 빨라졌는지 소요 시간을 기록해요.

1. 서비스 전체에서 버튼을 보이는 대로 전부 스크린샷으로 수집해요. (주 버튼, 보조 버튼, 텍스트 버튼, 비활성 버튼, 아이콘 버튼…)
2. 같은 방법으로 입력 필드(기본, 포커스, 에러, 비활성)와 카드(목록 카드, 상세 카드 등)를 수집해요.
3. Figma에 세 그룹(버튼/입력/카드)으로 나눠 나열하고, 각 변형에 이름을 붙여요. (예: "버튼-주-대", "입력-에러")
4. 변형별로 크기·모서리 반경·색을 메모해요. 정확하지 않아도 눈대중 + 개발자도구 확인이면 충분해요.
5. "이 둘은 사실 하나여야 하지 않나?" 싶은 변형 쌍에 표시를 남겨요 — 내일 불일치 찾기의 핵심 재료예요.

실무 협업의 기본 사이클(브랜치→커밋→PR→리뷰)을 혼자서 처음부터 끝까지 3번 돌릴 수 있게 돼요.

1. 멘토가 만든 연습 저장소를 clone 해요. 오전에 받은 저장소 주소를 사용하고, git clone 주소 → cd 폴더명 순서예요.
2. 1회전 — README 오타 수정: git switch -c fix/readme-오타-본인이름 으로 브랜치를 만들고, README에 심어 둔 오타를 찾아 고쳐요. git add → git commit -m "docs: README 오타 수정" → git push -u origin 브랜치명 → 저장소 웹 화면에서 PR 생성. PR 설명은 아래 양식대로 써요.
3. 2회전 — 주석 추가: main으로 돌아가(git switch main → git pull) 새 브랜치 docs/주석-본인이름을 만들어요. 저장소의 utils.js에서 주석 없는 함수 2개를 골라 "무엇을 받아 무엇을 돌려주는지" 주석을 달고, 같은 사이클로 PR까지 만들어요.
4. 3회전 — 간단 함수 작성: 브랜치 feat/함수-본인이름에서 utils.js에 아래 세 함수 중 2개를 골라 구현해요: ⓐ sum(arr) 배열의 합 반환 ⓑ maxNum(arr) 배열의 최댓값 반환 ⓒ countChar(str, ch) 문자열에서 특정 글자 개수 반환. console.log로 각각 2가지 입력을 실행해 결과 확인 후 PR까지 만들어요.
5. 동료 리뷰: 옆 사람의 PR 목록에서 아무거나 1개를 열어 코드를 읽고, 리뷰 코멘트 1개 이상을 남겨요. "좋아요"만 쓰지 말고 ⓐ 좋은 점 1가지 + ⓑ 질문 또는 제안 1가지를 꼭 포함해요. (예: "변수 이름이 알아보기 쉬워요. 그런데 빈 배열이 들어오면 어떻게 되나요?")
6. 내 PR에 달린 코멘트가 있으면 답글을 달아요. 수정이 필요하면 같은 브랜치에서 고치고 다시 push하면 PR에 자동 반영되는 것도 확인해요.
7. 3회전 중 헷갈렸던 명령어를 나만의 Git 치트시트로 정리해요(명령어 + 내 언어 설명, 최소 8줄).

좋은 커밋 메시지와 나쁜 커밋 메시지를 구별하는 눈을 만들어요.

1. 아래 나쁜 커밋 메시지 6개를 각각 좋은 메시지로 고쳐 쓰세요. 상황은 자유롭게 상상하되, "무엇을 왜 했는지"가 드러나야 해요.
2. 고친 메시지마다 "원래 메시지의 문제점"을 한 줄씩 적어요.

1. 월~수에 모은 인벤토리를 펼쳐 놓고 불일치 지점 10개를 골라요. (색 2~3개, 타이포 2~3개, 컴포넌트 4~5개 권장)
2. 각 불일치마다 비교 스크린샷 2장(A화면 vs B화면)을 나란히 붙여요.
3. 각 항목에 "무엇이 다른가 / 사용자에게 어떤 혼란을 주는가 / 어느 쪽으로 통일하면 좋을까(내 의견)"를 각 한 줄씩 적어요.
4. 10개에 심각도(상·중·하)를 매기고, 상인 이유를 한 줄로 적어요.

자료구조를 "외운 것"에서 "만들어 본 것"으로 바꾸고, 그것이 실제 서비스 어디에 살아 있는지 연결해요.

1. 새 파일 stack.js에 Stack 클래스를 만들어요. 내부 저장은 배열을 쓰되, 밖에서는 다음 4개 메서드만 쓰게 해요: push(값) 넣기 / pop() 맨 위 꺼내기(비었으면 undefined) / peek() 맨 위 확인만 / isEmpty() 비었는지 true·false.
2. 동작 확인 코드를 작성해요: 1, 2, 3을 push한 뒤 pop을 두 번 하면 3, 2가 나오고 peek이 1인지 console.log로 검증해요. 빈 스택에서 pop하는 경우도 꼭 확인해요.
3. queue.js에 Queue 클래스를 만들어요: enqueue(값) 뒤로 넣기 / dequeue() 앞에서 꺼내기 / front() 맨 앞 확인 / isEmpty(). "가", "나", "다"를 넣고 꺼내면 넣은 순서 그대로 나오는지 검증해요.
4. 아래 판단문제 5개를 풀어요. 각 상황이 스택·큐 중 무엇에 어울리는지 고르고 이유를 한 줄씩 적어요.
5. 서비스 탐험: 우리 서비스에서 "목록(배열)이 화면에 그려지는 화면" 3개를 찾아 스크린샷을 찍어요. 각 화면마다 ⓐ 무엇의 목록인지 ⓑ Network 탭 응답에서 배열([ ... ])이 실제로 보이는지 ⓒ 프론트 코드에서 그 목록을 그리는 map 호출을 찾을 수 있으면 파일·줄까지 기록해요. (ⓒ는 3개 중 1개만 성공해도 충분해요)
6. 모든 내용을 주간 챌린지 리포트 1개 문서로 묶어요: 구현 코드 캡처(또는 링크) + 검증 결과 + 판단문제 답 + 화면 3건 기록.
7. 마지막으로 이번 주 3줄 회고의 확장판, 주간 회고 5줄을 리포트 끝에 적어요: 가장 배운 것 / 가장 어려웠던 것 / 30분 룰을 쓴 순간 / 다음 주에 시도할 것 / 멘토에게 바라는 것.

내가 만든 자료구조를 "문제 풀이 도구"로 써 보는 첫 경험이에요.

1. 본 과제의 Stack 클래스를 재사용해 함수 isBalanced(str)를 만들어요. 문자열의 소괄호 ( )가 짝이 맞으면 true, 아니면 false를 반환해요.
2. 힌트: (를 만나면 push, )를 만나면 pop. pop할 게 없거나, 끝났는데 스택에 남아 있으면 false예요.
3. 다음 5개 입력으로 검증해요: "(())" → true / "(()" → false / "())(" → false / "안녕(하세요)" → true / "" → true.

1. 어제 찾은 불일치 10개 중 심각도가 높고 고치기 쉬운 것 위주로 개선점 5개를 골라요.
2. 각 개선점을 현재(As-Is) 스크린샷 → 개선안(To-Be) 시안 구성으로 만들어요. To-Be는 Figma로 간단히 그리면 돼요 — 완성도보다 "무엇이 달라지는지"가 보이면 충분해요.
3. 각 개선점에 3줄을 붙여요: 문제 / 개선안 / 기대 효과(사용자 입장에서).
4. 표지(제목·이름·날짜)와 마지막 장(이번 주 인벤토리 요약: 색 몇 개, 글자 크기 몇 종, 버튼 변형 몇 개)을 붙여 리포트를 완성해요.
5. 16:30 리뷰 때 5분 발표로 공유할 수 있게 말할 순서를 머릿속으로 한 번 연습해요.