이번 주부터 수습생은 실제 백로그 티켓 하나를 맡아 "착수 → 구현 → 리뷰 → 배포"의 한 사이클을 스스로 돌립니다. 4주간 쌓은 기본기를 진짜 코드베이스 위에서 처음으로 꺼내 쓰는 주간이에요. 멘토는 정답을 대신 짜 주는 사람이 아니라, 막힐 때 방향을 같이 찾아 주는 페이스메이커로 붙습니다.
6블록 틀(학습목표 · 진행표 · 멘토 스크립트 · 실습 · 이해 확인 · 흔한 실수)은 1주차 강의안과 동일합니다. 각 세션 카드를 위에서 아래로 그대로 읽어 내려가며 진행하면 됩니다.
useState 시연"자, 오늘부터 아침 기본기 시간은 끝났어요. 대신 실무에서 매일 쓰는 걸 아주 짧게 짚고 갈 거예요. 부담 갖지 말고 '아 이런 게 있구나' 정도만 담아 가면 돼요."
"상태라는 건 어렵게 생각할 거 없어요. 버튼 누르면 숫자가 올라가는 화면, 그 숫자를 React가 어딘가 기억하고 있어야 하잖아요? 그 기억하는 값이 상태예요."
(카운터를 직접 눌러 숫자가 바뀌는 걸 보여 주며) 지금 이거, 우리가 만든 게 아니라 상태가 바뀌니까 React가 알아서 다시 그린 거예요.
포인터 세션입니다. 깊게 들어가지 말고, 개념 소개 후 곧바로 티켓 배정으로 넘어가세요.
"오늘부터 여러분은 관람객이 아니라 선수예요. 진짜 우리 제품에 들어갈 코드를 짜는 거예요. 겁먹을 필요 없어요. 여러분이 감당할 수 있는 크기로 티켓을 골라 뒀거든요."
"별 하나짜리는 하루 안에 끝낼 수 있는 크기, 별 둘은 2~3일 걸리는 크기예요. 지금은 작게 시작하는 게 훨씬 좋아요. 작은 걸 확실히 끝내는 게 큰 걸 반쯤 하다 마는 것보다 백 배 나아요."
(배정 후) 이제 이 티켓, 저한테 다시 설명해 볼래요? 여러분 말로 설명이 되면 반은 이해한 거예요.
각자 아래 대본의 빈칸을 채워 멘토에게 제출합니다. 채우지 못하는 칸이 있으면 그게 곧 오늘 물어봐야 할 질문이에요.
티켓 번호: #____ 제목: ________________ 난이도: ★ / ★★ 이 티켓을 한 문장으로: "____________을(를) ____________하게 만든다." 손대야 할 화면/파일(추측): ________________ 완료 조건(이게 되면 끝): ________________ 지금 당장 모르는 것 1가지: ________________
다음 자리로 넘어가기 전, 각자에게 물어보세요.
"바로 코드부터 치고 싶은 마음 알아요. 근데 실무에서는 '어떻게 풀지' 먼저 적어 보는 게 습관이에요. 5분 적으면 5시간을 아껴요."
"계획이 틀려도 괜찮아요. 틀린 계획이라도 있으면, 제가 어디가 틀렸는지 짚어 줄 수 있거든요. 아무것도 없으면 저도 도와줄 수가 없어요."
(디자이너에게) OO는 이번에 화면 개선 하나를 맡을 거예요. 예쁘게만 끝나는 게 아니라, 개발자가 그걸 실제 화면에 반영하는 데까지 같이 따라가 볼 거예요.
개발 3명은 아래 계획서를, 디자이너는 그 아래 디자인 계획서를 채웁니다. 이 문서가 곧 내일 아침의 출발점이에요.
티켓 #____ 접근 계획 1단계: ____________________ (예상 __분) 2단계: ____________________ (예상 __분) 3단계: ____________________ (예상 __분) (필요 시) 4단계: ________________ (예상 __분) 총 예상 소요: 약 __시간 확인이 필요한 것: ________________ 테스트로 확인할 방법: 화면에서 ____를 하면 ____가 보인다
개선 대상 화면: ________________ 지금의 문제(한 줄): ________________ 개선 방향(한 줄): ________________ 개발 반영 시 바뀌는 것: 색 / 간격 / 배치 / 문구 中 ____ 개발자에게 넘길 것: 시안 파일 / 색상값 / 여백 수치
오늘을 닫기 전 각자에게:
"백엔드는 식당이라고 생각하면 쉬워요. 손님 주문 받는 홀이 Controller, 요리하는 주방이 Service, 재료 꺼내 오는 창고가 Repository예요. 각자 자기 일만 해요."
"왜 이렇게 나눌까요? 요리사가 창고 정리까지 하면 정신없잖아요. 나눠 놓으면 고칠 데를 딱 찾기 쉬워요. 여러분 티켓도 '어느 층 문제인지'만 알면 절반은 찾은 거예요."
포인터 세션입니다. Java는 보조 언어이니 문법을 깊게 다루지 말고 "층 구분" 감만 주고 마무리하세요.
"오늘 목표는 티켓을 다 끝내는 게 아니에요. '화면에서 뭔가 하나 바뀌는 걸' 만드는 거예요. 버튼 하나라도 원하는 대로 움직이면 오늘은 대성공이에요."
"막히면요, 15분만 혼자 붙잡아 봐요. 그래도 안 풀리면 바로 손 들어요. 15분 넘게 혼자 끙끙대는 건 용기가 아니라 시간 낭비예요. 질문하는 게 실력이에요."
(에러가 났을 때) 에러 났다고 겁먹지 말고, 빨간 글씨를 소리 내서 같이 읽어 봐요. 대부분 답이 거기 적혀 있어요.
실습 결과물: 티켓 브랜치에 최소 1개의 의미 있는 커밋. 커밋 메시지는 아래 형식으로 적게 하세요.
유형 선택: feat / fix / style 한 줄 요약: ____를 ____하게 바꿈 예) feat: 로그인 버튼 색을 브랜드 색으로 교체 예) fix: 목록이 빈 화면일 때 안내 문구 표시
커밋 전 각자에게:
"실무에서는 매일 이렇게 짧게 보고해요. 잘한 걸 자랑하는 자리가 아니라, 막힌 걸 나누는 자리예요. 막혔다고 말하는 게 제일 프로다운 거예요."
(발표가 위축될 때) 오늘 못 끝냈어도 괜찮아요. 어디까지 왔는지만 정확히 말해 주면 저는 그걸로 충분해요.
발표 전 각자 아래 3줄을 채워 놓고 보고합니다. 매일 같은 형식을 씁니다.
오늘 한 것: ________________ 막힌 것: ________________ (없으면 "없음") 내일 할 것: ________________
보고 후 확인:
"PR은 '제 코드 좀 봐 주세요' 하고 정식으로 부탁하는 거예요. 그래서 설명을 잘 적어야 해요. 리뷰어는 여러분 머릿속을 못 보니까, 무엇을 왜 바꿨는지 글로 알려 줘야 해요."
"올리기 전에 딱 한 번, 내 코드를 남의 코드라 생각하고 읽어 봐요. 오타나 지우다 만 흔적, 거기서 절반은 스스로 잡혀요."
아래 빈칸을 채워 PR 본문으로 붙여 넣습니다. 리뷰어가 이 글만 읽고도 맥락을 알 수 있어야 합니다.
## 무엇을 (What) ____________________ ## 왜 (Why) — 어떤 티켓/문제 때문에 티켓 #__ · ____________________ ## 어떻게 확인하나 (How to test) 1. ____화면에 들어간다 2. ____를 누른다 3. ____가 보이면 정상 ## 아직 자신 없는 부분 (리뷰어가 봐 줬으면) ____________________
PR 올린 뒤:
"리뷰 코멘트 보고 마음 상하는 거, 아주 자연스러운 거예요. 근데 하나만 기억해요. 저는 여러분을 지적한 게 아니라, 코드를 같이 더 좋게 만들려는 거예요. 코드랑 여러분은 다른 사람이에요."
"모든 코멘트를 다 고칠 필요도 없어요. 이해가 안 되면 '이건 왜 그런가요?' 하고 물어봐요. 물어보는 거, 반박이 아니라 배움이에요. 오히려 멋진 거예요."
(반영 후) 고쳤으면 '이렇게 바꿨어요' 하고 답글 달아 줘요. 그래야 저도 다시 볼 때 빨라요.
코멘트를 감정 없이 처리하기 위한 표입니다. 코멘트 개수만큼 줄을 늘려 채우세요.
코멘트 1: "____________" → 처리: 바로 고침 / 물어보고 / 보류 → 내가 한 일: ____________ 코멘트 2: "____________" → 처리: 바로 고침 / 물어보고 / 보류 → 내가 한 일: ____________
반영 후:
"오늘은 '끝'에 도달하는 날이에요. 근데 '끝'이 뭐였죠? 월요일에 우리가 적었잖아요. 그 문장을 지금 다시 꺼내서, 한 줄 한 줄 진짜 됐는지 눌러 봐요."
"'아마 될 거예요'는 안 돼요. 직접 눌러 보고 '됐어요'가 돼야 해요. 개발자는 눈으로 확인한 것만 믿어요."
(디자이너에게) OO 시안이 실제 화면에 들어갔는지 개발자 옆에서 같이 봐요. 여백 하나, 색 하나 다르면 지금 말해 줘야 해요.
완료 조건을 그대로 옮겨 적고, 하나씩 직접 확인해 O/X를 매깁니다. 전부 O가 되어야 티켓 완료입니다.
완료 조건 1: ____________ → 확인: O / X 완료 조건 2: ____________ → 확인: O / X 완료 조건 3: ____________ → 확인: O / X 전부 O 인가? 예 / 아니오 아니오라면, 남은 것: ____________
세션 끝에:
"이거 배포하면 진짜로 나가요. 우리 회사 슬로건이 '고객과 함께 더 나은 세상을 만들어 나가는 기업'이잖아요. 여러분 코드가 그 '더 나은 세상'의 아주 작은 조각이 되는 거예요. 뿌듯하죠?"
"그래서 나가기 전에 딱 한 번 더 봐요. 겁주려는 게 아니라, 프로는 항상 배포 전에 심호흡 한 번 하고 체크리스트를 봐요."
모든 칸에 체크가 들어가야 내일 배포로 넘어갑니다. 하나라도 비면 오늘 채웁니다.
[ _ ] 완료 조건이 전부 O 다 [ _ ] 리뷰 코멘트에 다 답했고, 멘토가 승인했다 [ _ ] 화면에서 직접 눌러 확인했다 [ _ ] 다른 기능을 망가뜨리지 않았다(주변 화면도 눌러 봄) [ _ ] (디자인 티켓) 시안과 실제 화면이 같다 한 줄 소감: ____________
퇴근 전:
"자, 머지 버튼 눌러 볼까요? 이 순간이에요. 여러분이 짠 코드가 진짜 우리 제품 안으로 들어가는 순간. 축하해요, 이거 아무나 하는 거 아니에요."
"근데 배포했다고 끝이 아니에요. 배포된 화면 가서 진짜 됐는지 다시 눌러 봐야 해요. '올렸으니 됐겠지'가 사고의 시작이거든요."
(확인되면) 봤죠? 이게 여러분 거예요. 이번 주에 여러분은 관람객에서 선수가 됐어요.
실습 결과물: 배포된 환경에서 완료 조건 재검증 완료 + 티켓 Done 처리. 아래 종료 코멘트를 티켓에 남깁니다.
배포 완료했습니다. ✅ 바뀐 것: ____________ 배포 환경에서 확인함: ____화면에서 ____ 정상 배운 점 한 줄: ____________
티켓 닫기 전:
"회고는 반성문이 아니에요. '뭘 배웠나, 다음엔 뭘 다르게 할까'를 챙기는 시간이에요. 잘한 것도 꼭 적어요. 자기가 뭘 잘했는지 알아야 그걸 또 하거든요."
(공유가 서로 비슷할 때) 봐요, 다들 비슷한 데서 막혔죠? 그건 여러분이 못해서가 아니라 원래 거기가 어려운 지점이라는 거예요.
각자 채워서 제출합니다. 멘토는 이 카드를 개인 성장 기록으로 보관합니다.
이번 주 내가 배포한 티켓: #__ 가장 뿌듯했던 것: ____________ 가장 어려웠던 것: ____________ 리뷰에서 얻은 것: ____________ 다음 티켓에서 다르게 해 볼 것 1가지: ____________
회고 마무리에:
"오늘은 OO 얘기만 들을게요. 이번 주 스스로 어땠어요? 먼저 들어 보고 싶어요."
"제가 본 건요, OO는 막혔을 때 15분 규칙 잘 지켰어요. 그게 자기주도성이에요. 대신 같은 리뷰 지적이 두 번 나온 게 하나 있었어요. 다음 주엔 리뷰 받은 걸 메모해 두고 다음 티켓에서 먼저 챙겨 보면 좋겠어요."
(마무리) 이번 주 정말 잘했어요. 진짜 티켓 하나를 세상에 내보냈잖아요. 다음 주엔 이 목표 하나만 같이 챙겨 봐요.
멘토가 학생별로 아래를 채워 평가 루브릭에 반영합니다. 학생과 화면을 같이 보며 합의한 목표를 남깁니다.
이름: ____ 배포 티켓: #__ 자기주도성 (막힘 대처·질문 타이밍): 상 / 중 / 하 — 근거 한 줄 코드 품질 성장 (첫날 대비): 상 / 중 / 하 — 근거 한 줄 같은 지적 반복 여부: 없음 / 1회 / 반복 — 항목 다음 주 개인 목표(합의): ____________
1:1 종료 시:
다음 주(6주차) 예고 · 실전 티켓 ② — 난이도를 한 칸 올린 티켓(★★~★★★)에 도전하고, 이번 주 개인 목표를 실제로 적용해 봅니다. 사이클을 더 빠르고 안정적으로 두 바퀴 돌리는 것이 목표예요.