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 Method가 `GET`이면 '주세요', `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요소(무엇을·무엇을 시도·무엇이 막힘)를 담는가
- 예절 정착도 · 인사·경청·피드백 수용이 일상으로 자리잡았는가

⚠️흔한 실수
실수 · 회고에 "그냥 열심히 했다"처럼 뭉뚱그려 적는다.
대처 · "어떤 순간에, 무엇을 했는지 하나만 콕 집어요"라고 구체화를 돕는다.
실수 · 개선점을 자기 비난으로 적어 위축된다.
대처 · 개선은 "다음 행동"으로 바꿔 쓰게 한다. 우리는 함께 더 나은 세상을 만드는 팀이라는 톤을 유지한다.

다음 주 예고 · 3주차 — 읽는 눈에서 손으로 바꾸는 힘으로. 아주 작은 이슈 하나를 골라 직접 코드를 고치고 진짜 PR을 올리는 "첫 기여" 주간이 시작됩니다. (KT엠모바일·KT알파·핀업과 함께 만드는 실제 화면을 소재로.)