AWESOMEDEV · 수습 상세 강의안 · 2 / 8

2주차 상세 강의안
기초 다지기 — 읽는 눈 만들기

이번 주의 목표는 두 가지예요. 하나, 코드와 화면을 "읽는" 눈을 만드는 것. 우리 React 웹과 Spring Boot 서버가 어떻게 생겼고, 화면이 서버에 어떻게 말을 거는지 눈으로 확인해요. 둘, 지난주에 배운 예절과 질문법을 매일 반복해서 몸에 붙이는 것. 아직 뭔가를 "만들지" 않아도 괜찮아요. 잘 읽는 사람이 결국 잘 만듭니다.

대상 · 미림마이스터고 3학년 수습생 4명 개발 3 · 디자인 1 주 5일 · 아침 기본기 + 실무 트랙

6블록 틀(학습목표 · 진행표 · 멘토 스크립트 · 실습 · 이해 확인 · 흔한 실수)은 1주차 강의안과 동일합니다. 각 세션 카드를 위에서 아래로 그대로 읽어 내려가며 진행하세요.

MON

코드베이스 구조 훑기

목표 · 우리 React 폴더와 Spring Boot 프로젝트가 "어떻게 생겼는지" 큰 지도를 함께 그린다.
Day 1 · 세션 1 · 오전

기본기(B) — 컴퓨터 구조 마무리 → 자료구조 시작

09:30 – 10:30 · 60분 (포인터 세션)
🎯학습목표
  • 지난주 컴퓨터 구조(CPU·메모리·저장장치)를 한 장으로 마무리한다.
  • 자료구조의 문을 연다 — 배열·리스트, 스택·큐가 "무엇을 담는 통"인지 감을 잡는다.
✍️실습 / 진행 안내

「CS 기본기 4주 커리큘럼」 문서의 2주차 1~2일차를 그대로 진행합니다.

  • 이 강의안은 시간 슬롯만 잡아두는 포인터예요. 상세 내용·예제·퀴즈는 CS 커리큘럼 문서를 여세요.
  • 디자이너 수습생도 함께 듣습니다 — 자료구조는 "화면이 데이터를 어떻게 줄 세우는가"의 기초라 UI에도 쓸모가 있어요.
Day 1 · 세션 2 · 오전

지도를 펼치자 — 프로젝트 폴더 구조 함께 열기

10:40 – 12:00 · 80분
🎯학습목표
  • React 웹 프로젝트에서 "폴더가 왜 이렇게 나뉘어 있는지" 역할을 말할 수 있다.
  • Spring Boot 프로젝트의 큰 덩어리(컨트롤러·서비스·설정)가 어디 있는지 손가락으로 짚을 수 있다.
  • "어디에 무엇이 있나"를 스스로 찾는 습관의 첫 발을 뗀다.
🕘진행표
0–10분
워밍업. "지도 없이 처음 간 건물에서 화장실 찾기" 비유로 시작. 코드도 지도가 있으면 안 헤맨다고 연결.
10–40분
React 웹 투어. 멘토가 에디터를 띄우고 폴더를 하나씩 열며 설명. 각자 자기 화면으로 똑같이 따라 연다.
40–65분
Spring Boot 투어. 서버 프로젝트를 열고 컨트롤러 → 서비스 → 설정 순서로 큰 덩어리만 짚는다.
65–80분
실습 안내 + 질문. 오후 구조도 실습을 예고하고 궁금한 폴더를 자유롭게 질문받는다.
💬멘토 스크립트
멘토

"자, 오늘은 코드를 고치지 않아요. 그냥 구경만 할 거예요. 새 학교 첫날 건물 한 바퀴 도는 거랑 똑같아요. 어디가 교실이고 어디가 급식실인지만 알면 돼요."

"React 웹부터 볼게요. src 폴더 안에 components, pages, api 이런 게 보이죠? components는 버튼·카드처럼 화면 조각이고요, pages는 그 조각을 모아 만든 한 화면이에요. 레고 블록(components)이랑 완성품(pages) 관계라고 생각하면 돼요."

"이제 서버 쪽. Spring Boot는 controller가 손님을 맞는 안내데스크예요. service는 실제로 일을 처리하는 주방이고요. 안내데스크가 주문을 받아 주방에 넘기는 거예요. 지금은 이 두 개만 기억해도 충분해요."

수습생이 "이게 다 뭔지 모르겠어요"라고 하면 — "당연해요! 오늘은 이름이랑 위치만 익히는 날이에요. 뜻은 이번 주 내내 천천히 붙일 거예요." 라고 안심시킨다.

✍️실습 — 구조도 직접 그리기

손으로 그리는 게 핵심입니다. 종이·화이트보드·아이패드 무엇이든 좋아요. 오후에 각자 자기 지도를 완성해 서로에게 30초씩 설명합니다.

  1. React 웹의 최상위 폴더 3~5개를 상자로 그린다.
  2. 각 상자 옆에 "무엇을 담는 곳"인지 한 줄로 적는다.
  3. Spring Boot도 같은 방식으로 controller · service · config를 그린다.
  4. 화면(React)에서 서버(Spring)로 화살표 하나를 긋고 "여기서 요청이 간다"라고 적는다.
워크시트 · 빈칸을 채우세요
[ 나의 코드베이스 지도 ]

■ React 웹
  components/  → (               ) 을(를) 담는 곳
  pages/       → (               ) 을(를) 담는 곳
  (        )/  → API 호출을 모아둔 곳

■ Spring Boot 서버
  controller  → (               ) 역할
  service     → (               ) 역할

■ 화살표: 화면이 서버에게 (         ) 를 보낸다.
이해 확인

다음을 각자 말로 답하면 통과예요.

  • "버튼 하나를 새로 만들면 React의 어느 폴더에 파일이 생길까요?"
  • "서버에서 손님 요청을 가장 먼저 받는 곳 이름은?"
  • 자기 구조도를 보지 않고 폴더 3개의 역할을 설명한다.
⚠️흔한 실수
실수 · 모든 폴더를 완벽히 이해하려다 지쳐버린다.
대처 · "오늘은 상위 폴더 5개면 충분해요. 하위 폴더는 필요할 때 열어보면 돼요"라고 범위를 좁혀준다.
실수 · 파일 이름을 외우려고 한다.
대처 · 외우는 게 아니라 "찾는 습관"이 목표임을 강조. 지도는 언제든 다시 열 수 있다.
TUE

요청 흐름 추적

목표 · 화면이 서버에 "말을 거는" 순간을 개발자도구 Network 탭으로 직접 눈으로 본다.
Day 2 · 세션 1 · 오전

기본기(B) — 자료구조 이어가기 (배열·리스트)

09:30 – 10:30 · 60분 (포인터 세션)
🎯학습목표
  • 배열과 리스트가 데이터를 "줄 세우는" 방식의 차이를 한 문장으로 말한다.
✍️실습 / 진행 안내

「CS 기본기 4주 커리큘럼」 문서의 2주차 3일차를 그대로 진행합니다.

  • 예제 코드는 JavaScript(배열)를 우선 사용하고, 필요하면 Java를 보조로 보여주세요.
Day 2 · 세션 2 · 오후

화면이 서버에 말을 건다 — Network 탭 열기

13:00 – 14:40 · 100분
🎯학습목표
  • 브라우저 개발자도구의 Network 탭을 열고 요청 목록을 볼 수 있다.
  • 요청 하나에서 method(GET/POST) · URL · 응답(Response)을 짚어낼 수 있다.
  • "React 화면 → REST API → Spring Boot 서버"라는 흐름을 자기 말로 설명한다.
🕘진행표
0–15분
도구 열기. 크롬에서 F12 → Network 탭. 다 함께 열고 화면을 새로고침해 요청이 주르륵 뜨는 걸 본다.
15–45분
한 줄 뜯어보기. 멘토가 요청 하나를 클릭해 Headers(method·URL)와 Response를 함께 읽는다.
45–75분
따라하기. 각자 우리 서비스 화면을 조작하며 자기 Network 탭에 뜨는 요청을 관찰한다.
75–100분
워크시트 작성 + 공유. 각자 요청 하나를 골라 표를 채우고 한 명씩 발표한다.
💬멘토 스크립트
멘토

"어제는 코드가 어디 있는지 지도를 그렸죠? 오늘은 그 지도 위에서 편지가 오가는 걸 직접 볼 거예요. 화면이 서버한테 '이 데이터 좀 주세요' 하고 편지를 보내거든요."

"키보드에서 F12 눌러보세요. 창이 하나 뜨죠? 위에 Network라고 적힌 탭을 눌러요. 그리고 화면을 새로고침. 자, 줄이 좍 뜨죠? 이게 전부 방금 오간 편지예요. 하나하나가 화면과 서버의 대화예요."

"아무거나 하나 클릭해볼게요. Request URL — 이게 편지를 보낸 주소예요. Request MethodGET이면 '주세요', POST면 '이거 저장해주세요'라는 뜻이에요. 밑에 Response는 서버가 보낸 답장이고요."

수습생이 요청이 너무 많아 혼란스러워하면 — "필터 칸에 'Fetch/XHR'를 눌러보세요. 진짜 데이터 편지만 남아요. 이미지·폰트 같은 건 잠깐 무시해도 돼요." 라고 안내한다.

✍️실습 — 요청 하나 골라 관찰하기

요청 하나를 골라 아래 표를 채우면 끝입니다. 어려운 요청 말고, 목록 조회처럼 답이 눈에 잘 보이는 GET 요청을 고르라고 안내하세요.

  • 우리 서비스 화면에서 목록/조회 화면을 하나 연다.
  • Network 탭에서 방금 뜬 요청 하나를 클릭한다.
  • method · URL · 응답의 첫 줄을 워크시트에 옮겨 적는다.
워크시트 · 요청 관찰 카드
[ 내가 관찰한 요청 ]

이 요청은 (어떤 화면 / 버튼) 에서 발생했나요?
  → ___________________________

Request Method  : GET / POST  (동그라미)
Request URL     : _______________________
Status(상태코드): ___  (200이면 성공!)

Response(답장)에서 눈에 띄는 값 하나:
  → ___________________________

한 줄 소감: 이 요청은 서버에게 무엇을 부탁한 걸까?
  → ___________________________
이해 확인

발표할 때 다음이 담기면 통과예요.

  • "내가 고른 요청은 GET/POST 중 무엇이고 왜 그렇게 판단했는지"
  • "이 요청의 URL상태코드가 무엇이었는지"
  • "이 편지가 어느 화면 동작 때문에 발생했는지"
⚠️흔한 실수
실수 · 요청 목록이 수십 개라 어디를 봐야 할지 몰라 얼어붙는다.
대처 · 'Fetch/XHR' 필터를 켜서 진짜 데이터 요청만 남기고, 목록을 위에서 하나만 고르게 한다.
실수 · 응답(JSON)을 전부 이해하려 한다.
대처 · "지금은 값 하나만 짚으면 돼요. 전체 해석은 다음 단계예요"라고 범위를 정해준다.
WED

기능 읽기 과제

목표 · 화면/기능 하나를 골라 "어떻게 동작하는지" 분석해 문서로 정리하고 멘토와 리뷰한다.
Day 3 · 세션 1 · 오전

기본기(B) — 자료구조 (스택 · 큐)

09:30 – 10:30 · 60분 (포인터 세션)
🎯학습목표
  • 스택(쌓기)과 큐(줄서기)의 차이를 일상 비유로 설명한다.
✍️실습 / 진행 안내

「CS 기본기 4주 커리큘럼」 문서의 2주차 4일차를 그대로 진행합니다.

Day 3 · 세션 2 · 오전

기능 하나를 통째로 읽기 — 분석 과제 착수

10:40 – 12:00 · 80분
🎯학습목표
  • 화면 기능 하나를 골라 "사용자 동작 → 화면 변화 → 서버 요청"의 순서를 적을 수 있다.
  • 어제 배운 Network 탭 관찰을 분석 근거로 활용한다.
  • 모르는 부분을 "질문 리스트"로 남기는 습관을 익힌다.
🕘진행표
0–15분
과제 소개. "기능 하나를 탐정처럼 관찰해 리포트를 쓴다." 좋은 예시 리포트 1개를 함께 읽는다.
15–30분
기능 고르기. 각자 분석할 기능을 하나 정한다 (예: 로그인, 목록 검색, 좋아요 버튼).
30–75분
관찰·기록. 화면을 눌러보고 Network 탭을 확인하며 워크시트를 채운다. 멘토는 순회하며 막힌 곳을 돕는다.
75–80분
오후 리뷰 예고. "완벽 말고 솔직하게. 모르는 건 물음표로 남기세요"라고 안내.
💬멘토 스크립트
멘토

"오늘은 여러분이 탐정이에요. 기능 하나를 골라서 '얘가 대체 어떻게 움직이는 거지?'를 캐내는 거예요. 코드를 고치는 게 아니라 설명하는 게 목표예요."

"기능은 작은 걸 고르는 게 좋아요. '좋아요 버튼', '검색창', '로그인' 이런 거요. 화려한 화면 말고, 눌렀을 때 뭔가 딱 벌어지는 단순한 걸로요."

"순서는 세 칸이에요. ①내가 무엇을 눌렀나 → ②화면이 어떻게 변했나 → ③그때 Network 탭에 어떤 편지가 갔나. 이 세 칸만 채우면 훌륭한 분석이에요."

"막히면 물음표로 남기세요"를 반복 강조. 모르는 걸 솔직히 적는 게 감점이 아니라 오히려 좋은 리포트라고 알려준다.

✍️실습 — 기능 분석 리포트 (이번 주 산출물 ①)

이 리포트가 이번 주 공식 산출물입니다. 오전에 초안, 오후 리뷰 후 보완해 완성하세요.

  1. 분석할 기능 하나를 정한다.
  2. 동작을 ①동작 → ②화면변화 → ③서버요청 세 칸으로 적는다.
  3. 모르는 부분은 "질문" 항목에 물음표로 남긴다.
템플릿 · 기능 분석 리포트
# 기능 분석 리포트

분석한 기능 : _______________________
작성자       : _______________________

## 1. 내가 한 동작
  - (예: 검색창에 "KT"를 입력하고 엔터를 눌렀다)

## 2. 화면에서 벌어진 일
  - (예: 목록이 KT 관련 항목으로 바뀌었다)

## 3. 그때 오간 요청 (Network 탭)
  - Method / URL : ___________________
  - 서버가 준 답 : ___________________

## 4. 아직 모르는 것 (물음표 환영!)
  - ? ___________________________
이해 확인 — 오후 멘토 리뷰

오후 1:1 리뷰에서 다음을 확인합니다.

  • ①②③ 세 칸이 순서대로 이어지는지 (동작이 화면 변화로, 화면 변화가 요청으로 연결)
  • 물음표(모르는 부분)를 솔직하게 남겼는지 — 남겼으면 칭찬
  • 어제 배운 Network 관찰이 근거로 들어갔는지
⚠️흔한 실수
실수 · 너무 크고 복잡한 기능을 골라 첫 칸부터 막힌다.
대처 · "버튼 하나짜리로 바꿔봐요"라고 스케일을 줄여준다.
실수 · 모르는 걸 감추려고 아는 척 문장을 지어낸다.
대처 · "물음표가 많은 리포트가 정직한 리포트예요"라고 심리적 안전감을 준다.
THU

Git 실전 연습

목표 · 연습용 저장소에서 브랜치 → 수정 → 커밋 → PR까지 한 바퀴를 직접 돌려본다.
Day 4 · 세션 1 · 오전

기본기(B) — 자료구조 복습 · 미니 문제

09:30 – 10:30 · 60분 (포인터 세션)
🎯학습목표
  • 이번 주 배운 배열·리스트·스택·큐를 미니 문제로 스스로 점검한다.
✍️실습 / 진행 안내

「CS 기본기 4주 커리큘럼」 문서의 2주차 5일차(복습·문제)를 그대로 진행합니다.

Day 4 · 세션 2 · 오전

Git 한 바퀴 — 브랜치에서 PR까지

10:40 – 12:00 · 80분
🎯학습목표
  • 연습용 저장소에서 브랜치를 만들고 파일을 수정할 수 있다.
  • 커밋 컨벤션(feat: · fix: · docs:)에 맞춰 커밋 메시지를 쓴다.
  • PR(Pull Request)을 올려 "리뷰해 주세요" 상태까지 만든다.
🕘진행표
0–10분
비유 워밍업. 브랜치 = 원본을 건드리지 않는 "연습용 복사본". 왜 바로 고치지 않는지 설명.
10–35분
함께 한 바퀴. 멘토가 화면 공유로 브랜치 생성 → 파일 수정 → 커밋을 시연. 학생은 눈으로 먼저 본다.
35–65분
각자 한 바퀴. 연습용 저장소에서 각자 같은 순서를 따라 한다. 멘토 순회 지원.
65–80분
PR 올리기 + 컨벤션 복습. PR을 만들고 제목을 커밋 컨벤션에 맞춘다. 서로의 PR을 열어본다.
💬멘토 스크립트
멘토

"Git은 게임의 세이브 파일이랑 비슷해요. 실수해도 이전 세이브로 돌아갈 수 있어요. 그래서 하나도 안 무서워요. 오늘 마음껏 실수해도 돼요 — 연습용 저장소니까요."

"먼저 브랜치를 만들어요. 이건 원본을 안 건드리는 '나만의 연습장'이에요. 여기서 파일을 고치고, 다 됐으면 커밋으로 '여기까지 저장!' 도장을 찍어요."

"커밋 메시지에는 규칙이 있어요. 새 기능이면 feat:, 고친 거면 fix:, 문서면 docs:를 앞에 붙여요. 지난주에 봤던 그 규칙이에요. 예: docs: 내 소개 파일 추가."

"마지막은 PR. '제가 이렇게 고쳤어요, 봐주세요'라고 손드는 거예요. PR을 올리면 리뷰어가 확인하고 합쳐줘요. 오늘은 올리는 것까지가 목표예요."

✍️실습 — 연습 PR 올리기 (이번 주 산출물 ②)

이 PR이 이번 주 공식 산출물입니다. 아래 순서를 그대로 따라오게 하세요. 명령어는 멘토가 화면에 크게 띄워둡니다.

  1. 연습용 저장소를 받아 브랜치를 만든다.
  2. 자기 소개를 담은 파일 하나를 추가/수정한다.
  3. 커밋 컨벤션에 맞춰 커밋한다.
  4. PR을 올리고 제목을 컨벤션대로 쓴다.
따라 치는 명령 · 빈칸을 채우세요
# 1) 내 연습용 브랜치 만들기
git checkout -b practice/이름-week2

# 2) 파일 수정 후, 바뀐 걸 담기
git add 파일이름

# 3) 도장 찍기 (컨벤션 지키기!)
git commit -m "docs: __________ 추가"

# 4) 내 브랜치를 원격으로 밀어올리기
git push -u origin practice/이름-week2

# 5) 브라우저에서 "Pull Request" 버튼을 눌러 PR 생성
#    PR 제목도 컨벤션으로!  예)  docs: 수습 자기소개 추가
이해 확인

PR 링크를 멘토에게 공유하며 다음을 확인합니다.

  • 브랜치 이름이 main이 아닌 연습용 브랜치인지
  • 커밋 메시지가 컨벤션 접두어로 시작하는지
  • PR이 실제로 열려 "리뷰 대기" 상태인지
⚠️흔한 실수
실수 · 브랜치를 안 만들고 main에서 바로 작업한다.
대처 · 첫 단계 git checkout -b를 다 함께 소리 내어 확인하고 시작한다.
실수 · 커밋 메시지를 "수정함", "ㅇㅇ"처럼 대충 쓴다.
대처 · "미래의 내가 읽는 편지예요"라고 상기시키고 컨벤션 예시를 다시 보여준다.
주중 병행 · 디자이너 트랙 · 오후

디자이너 — UI 인벤토리 작성 + 개선점 5개 리포트

주중 오후 시간 분산 · 총 4~5시간
🎯학습목표
  • 우리 서비스 화면의 색·타이포·컴포넌트를 목록으로 정리(UI 인벤토리)할 수 있다.
  • 일관성이 깨진 곳·개선 여지를 5개 찾아 근거와 함께 리포트한다.
  • 예절과 질문법은 개발자 트랙과 동일하게 상시 관찰 대상이다.
💬멘토 스크립트
멘토

"개발자 친구들이 코드를 '읽는' 동안, 디자이너는 화면을 '읽어요'. 우리 서비스에 쓰인 색이 몇 개인지, 글자 크기가 몇 종류인지, 버튼 모양이 제각각인지 하나하나 세어보는 거예요."

"세다 보면 '어? 이 버튼만 색이 다르네?' 같은 게 보여요. 그게 바로 개선점이에요. 5개만 찾아서 '어디가, 왜 아쉽고, 어떻게 바꾸면 좋을지'를 적어주면 훌륭한 리포트예요."

✍️실습 — UI 인벤토리 & 개선 리포트

화면을 눈으로 훑으며 빈칸을 채웁니다. 스크린샷을 붙여두면 근거가 더 명확해져요.

  • 색: 실제 쓰인 색을 모아 목록으로.
  • 타이포: 글자 크기·굵기 종류를 정리.
  • 컴포넌트: 버튼·카드·입력창 등 반복되는 조각 정리.
템플릿 · UI 인벤토리 + 개선점
# UI 인벤토리

## 색 (Colors)
  - 주 색 : #______  / 보조 : #______

## 타이포 (Typography)
  - 제목 __px / 본문 __px / 캡션 __px

## 컴포넌트 (Components)
  - 버튼 종류 __개, 카드 __종류 ...

# 개선점 5가지
  1. 어디가?  → ______
     왜 아쉽나? → ______
     어떻게? → ______
  (2~5 동일 형식)
⚠️흔한 실수
실수 · "그냥 예쁘다/별로다"처럼 취향으로만 평가한다.
대처 · "일관성·가독성처럼 근거를 붙여요"라고 방향을 잡아준다.
실수 · 개선점을 20개씩 나열해 초점이 흐려진다.
대처 · "가장 눈에 띄는 5개만. 깊게 쓰는 게 나아요"라고 범위를 좁힌다.
FRI

주간 회고 · 1:1 · 미니 퀴즈

목표 · 한 주를 스스로 돌아보고(잘한 것 1 / 개선 1), 기본기를 퀴즈로 점검한다.
Day 5 · 세션 1 · 오전

기본기(B) 미니 퀴즈

09:30 – 10:30 · 60분 (포인터 세션)
🎯학습목표
  • 이번 주 자료구조 개념을 짧은 퀴즈로 스스로 확인하고, 약한 부분을 안다.
✍️실습 / 진행 안내

「CS 기본기 4주 커리큘럼」 문서의 2주차 미니 퀴즈를 진행합니다.

  • 점수용이 아니라 "어디가 약한지 확인용"임을 분명히 알려주세요. 틀린 문항은 함께 다시 봅니다.
Day 5 · 세션 2 · 오후

주간 회고 & 1:1 — 잘한 것 1 · 개선 1

13:00 – 15:00 · 120분 (회고 40분 + 1:1 순차)
🎯학습목표
  • 한 주를 돌아보며 "잘한 것 1개 / 개선할 것 1개"를 구체적으로 적는다.
  • 1:1에서 멘토와 다음 주 목표 한 가지를 합의한다.
  • 이번 주 산출물(기능 분석 문서 · 연습 PR)을 함께 점검한다.
🕘진행표
0–20분
개인 회고 작성. 각자 조용히 회고 시트를 채운다. 멘토는 방해하지 않는다.
20–40분
돌아가며 공유. 한 명씩 "잘한 것 1 / 개선 1"을 말한다. 서로 박수·격려.
40–110분
1:1 (1인당 약 15분). 산출물 점검 + 다음 주 목표 합의. 나머지는 회고 보완·자율 정리.
110–120분
마무리. 다음 주 예고와 격려로 한 주를 닫는다.
💬멘토 스크립트
멘토

"한 주 정말 고생했어요. 오늘은 '내가 뭘 했지?'를 정리하는 날이에요. 딱 두 가지만 적어요 — 잘한 것 하나, 다음에 더 잘하고 싶은 것 하나. 많이 안 적어도 돼요."

"'잘한 것'은 아주 작아도 좋아요. '처음으로 Network 탭을 열어봤다'도 훌륭한 성취예요. 개선점도 자책이 아니라 '다음 주엔 이걸 해보자' 같은 방향이면 돼요."

1:1에서는 이번 주 산출물 두 개(기능 분석 문서, 연습 PR)를 함께 열어보고, 이해력·질문의 질(30분 룰·질문 3요소)·예절 정착도를 부드럽게 피드백한다. 지적보다 성장을 먼저 짚는다.

✍️실습 — 주간 회고 시트

두 칸이면 충분합니다. 다음 주 1:1에서 이 시트를 이어서 봅니다.

템플릿 · 2주차 주간 회고
# 2주차 회고 — 이름: ______

■ 이번 주 잘한 것 1가지
  → ___________________________

■ 다음 주 더 해보고 싶은 것 1가지
  → ___________________________

■ 멘토와 합의한 다음 주 목표
  → ___________________________

[ 산출물 체크 ]
  □ 기능 분석 문서 1개
  □ 연습 PR 1개
이해 확인 — 이번 주 평가 체크포인트

멘토는 1:1에서 세 가지 축으로 관찰 기록을 남깁니다.

  • 이해력 · 구조·요청 흐름·기능 분석을 자기 말로 설명하는가
  • 질문의 질 · 30분 룰을 지키고, 질문 3요소(무엇을·무엇을 시도·무엇이 막힘)를 담는가
  • 예절 정착도 · 인사·경청·피드백 수용이 일상으로 자리잡았는가
⚠️흔한 실수
실수 · 회고에 "그냥 열심히 했다"처럼 뭉뚱그려 적는다.
대처 · "어떤 순간에, 무엇을 했는지 하나만 콕 집어요"라고 구체화를 돕는다.
실수 · 개선점을 자기 비난으로 적어 위축된다.
대처 · 개선은 "다음 행동"으로 바꿔 쓰게 한다. 우리는 함께 더 나은 세상을 만드는 팀이라는 톤을 유지한다.