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

6주차 상세 강의안
실전 티켓 ② — 더 독립적으로

5주차에 실전 티켓을 처음 잡아봤다면, 이번 주는 멘토의 손을 조금 놓습니다. 난이도 ★★ 티켓을 스스로 설계하고, 막혀도 먼저 스스로 해결책을 찾아본 뒤 질문하는 습관을 만듭니다. 금요일에는 다음 2주 종합 프로젝트의 주제와 팀을 정하며 한 단계 도약을 준비합니다.

난이도 ★★ 수습생 4명 · 개발 3 · 디자인 1 주 5일 · 미림마이스터고 3학년

6블록 틀(학습목표 · 진행표 · 멘토 스크립트 · 실습 · 이해 확인 · 흔한 실수)은 1주차 강의안과 동일합니다. 각 세션 카드를 그대로 따라 읽으면 됩니다.

MON

티켓 배정 · 설계를 스스로 제안하기

오늘 목표: 손이 조금 더 가는 ★★ 티켓을 받고, 구현 전에 스스로 설계안을 말로/글로 제안한다.
Day 1 · 세션 1 · 오전

아침 기본기 — 코드리뷰 딥다이브 (포인터 세션)

40분 · 매일 아침 루틴
🎯학습목표
  • 리뷰에서 자주 나오는 지적 패턴(네이밍·중복·조건문·에러 처리)을 이름으로 알아본다.
  • 남의 코드를 읽고 "여긴 이렇게 바꾸면 더 좋겠다"를 한 문장으로 말할 수 있다.
✍️실습

CS 기본기 4주 커리큘럼 문서의 해당 일차를 진행합니다. 이번 주 아침은 "실무 심화 · 코드리뷰 딥다이브" 트랙으로, 자주 나오는 리뷰 코멘트를 유형별로 정리합니다.

  • 커리큘럼 문서 6주차 월요일 분량을 함께 읽고, 예시 코드 1개에 리뷰 코멘트를 각자 2개씩 달기
  • 디자이너 수습생은 디자인 QA 체크 관점(간격·정렬·상태 표현)으로 같은 화면을 리뷰
⚠️흔한 실수
실수 아침 세션을 "그냥 읽기"로만 흘려보낸다.
대처 반드시 각자 코멘트 2개를 소리 내어 발표시켜 참여를 끌어냅니다. 짧아도 좋다고 안심시켜 주세요.
Day 1 · 세션 2 · 오전

★★ 티켓 배정 — "내 티켓" 이해하기

70분
🎯학습목표
  • 자기 티켓의 목적(누가·왜 필요한지)을 자기 말로 다시 설명할 수 있다.
  • 티켓을 작은 할 일 3~5개로 스스로 쪼갤 수 있다.
🕘진행표
0:00
티켓 배정 — 개발 3명에게 각 1개, 예: React 목록 화면에 필터·정렬 추가, Spring Boot 조회 API에 페이지네이션 붙이기, 폼 유효성 검사 보강
0:10
각자 읽기 — 티켓 설명을 조용히 정독하고 모르는 단어에 형광펜
0:25
"내 말로 설명" 발표 — 한 명씩 티켓을 자기 문장으로 다시 말하기
0:45
할 일 쪼개기 — 워크시트에 작은 단계 3~5개 적기
1:05
멘토 점검 — 쪼갠 단계가 말이 되는지 한 명씩 빠르게 확인
💬멘토 스크립트
멘토

"이번 티켓은 지난주보다 손이 조금 더 가요. 겁먹을 필요는 전혀 없어요. 큰 덩어리 하나를 작은 조각으로 나누면, 결국 우리가 매일 하던 것들이 이어진 거예요."

"먼저 티켓을 내 말로 설명해 볼게요. '이 화면을 쓰는 사람이 누구고, 왜 이 기능이 필요할까?' 이거부터 시작해요."

(학생이 막히면) "정답을 말하려 하지 말고, 지금 이해한 만큼만 말해줘요. 나머지는 같이 채워요."

✍️워크시트
티켓 쪼개기 워크시트 — 빈칸을 채우세요
[티켓 제목] ___________________________

[이 기능을 쓰는 사람] _______________________
[왜 필요한가 한 줄] _________________________

[작은 할 일로 쪼개기]
  1. _______________________________________
  2. _______________________________________
  3. _______________________________________
  4. (있다면) ___________________________________

[제일 먼저 손댈 것 하나] ___________________
[다 됐다고 말하려면 무엇이 보여야 하나] _______
이해 확인

다음을 각자 대답할 수 있으면 통과입니다.

  • 내 티켓을 한 문장으로 설명해 보세요.
  • 가장 먼저 손댈 작은 할 일은 무엇인가요?
  • "다 됐다"고 말하려면 화면/응답에서 무엇이 보여야 하나요?
Day 1 · 세션 3 · 오후

설계 제안 — "이렇게 만들게요"를 먼저 말하기

90분
🎯학습목표
  • 코드를 짜기 전에 "어떤 파일을 어떻게 바꿀지"를 짧게 스스로 제안한다.
  • 멘토가 답을 주기 전에 자기 안(案)을 먼저 내놓는 습관을 만든다.
🕘진행표
0:00
설계 제안이란 — "손대기 전 30초 계획"의 뜻을 예시로 설명
0:15
각자 설계 초안 작성 — 아래 대본 빈칸 채우기 (25분)
0:40
1:1 설계 리뷰 — 멘토가 "왜 그렇게?"만 물으며 스스로 다듬게 함
1:10
착수 — 승인된 설계대로 첫 커밋까지 시작
💬멘토 스크립트
멘토

"오늘부터는 제가 먼저 '이렇게 하세요'라고 말하지 않을 거예요. 대신 여러분이 먼저 '저는 이렇게 만들려고 해요'를 저에게 말해줘요."

"틀려도 괜찮아요. 계획이 틀리면 같이 고치면 되고, 그 과정이 진짜 실력이 되는 거예요. 완벽한 설계가 아니라 내 생각을 말로 꺼내는 것이 오늘의 목표예요."

✍️설계 제안 대본
설계 제안 — 멘토에게 말하기 전에 채워보기
"제 티켓은 ___________ 입니다.

저는 이렇게 만들려고 해요:
  - 건드릴 파일: _______________________
  - 새로 만들 것: _____________________
  - 데이터는 ___________ 에서 가져와요.

이 방법을 고른 이유는 _____________ 예요.

한 가지 걱정되는 부분은 _____________ 예요."
이해 확인

설계 제안이 통과되면 착수합니다.

  • 어떤 파일을 바꿀지 스스로 지목했나요?
  • "왜 그렇게?"에 한 문장이라도 이유를 댔나요?
  • 걱정되는 부분(리스크)을 하나 이상 말했나요?
⚠️흔한 실수
실수 멘토가 답답함을 못 참고 설계를 대신 다 말해준다.
대처 이번 주 핵심은 독립성입니다. 답 대신 질문("그럼 그 다음은?")으로 스스로 도달하게 두세요. 침묵 10초는 괜찮습니다.
TUE

독립 구현 ① · 막힘 해결력

오늘 목표: 멘토가 먼저 나서지 않는다. 막혔을 때 스스로 시도한 뒤 질문하는 순서를 익힌다.
Day 2 · 세션 1 · 오전

아침 기본기 — 코드리뷰 딥다이브 (포인터 세션)

40분 · 매일 아침 루틴
🎯학습목표
  • 어제 배운 리뷰 패턴을 실제 내 코드에 하나 적용해 본다.
✍️실습

CS 기본기 4주 커리큘럼 문서의 해당 일차를 진행합니다. 오늘은 "중복 줄이기 · 함수 나누기" 편으로, 각자 어제 짠 코드에서 중복 한 군데를 찾아 함수로 빼봅니다.

Day 2 · 세션 2 · 오전~오후

독립 구현 — 스스로 막힘 뚫기

3시간 (점심 제외) · 집중 구현
🎯학습목표
  • 막혔을 때 바로 손 들지 않고 "스스로 3가지 시도"를 먼저 해본다.
  • 질문할 때 "무엇을 시도했고 무엇이 안 됐는지"를 함께 말한다.
🕘진행표
0:00
오늘의 규칙 공지 — "막히면 먼저 3가지, 그다음 질문" 규칙 안내 (5분)
0:05
집중 구현 — 각자 자기 티켓 진행, 멘토는 자리 순회만
1:30
중간 체크인 — "지금 어디까지 됐는지" 한 줄씩 공유 (10분)
1:40
집중 구현 계속
2:50
막힘 로그 정리 — 오늘 막혔던 지점과 해결법 1개 기록
💬멘토 스크립트
멘토

"오늘은 제가 옆에서 먼저 '이거 이렇게 해요' 하지 않을게요. 여러분이 막히는 건 아주 자연스러운 일이에요. 개발자는 하루 종일 막히고 뚫는 사람이에요."

"막히면 이 순서를 지켜봐요. ① 에러 메시지를 끝까지 읽기 ② 검색이나 문서에서 비슷한 예 찾기 ③ 작은 코드로 따로 테스트해 보기. 이 세 가지를 하고도 안 되면, 그때 저를 불러줘요."

(질문받을 때) "좋아요. 지금까지 뭘 시도해봤어요? 그걸 먼저 들려줘요."

✍️워크시트
막힘 로그 — 질문 전에 스스로 채우기
[막힌 지점] _________________________________

[시도 1] ___________________ → 결과: _______
[시도 2] ___________________ → 결과: _______
[시도 3] ___________________ → 결과: _______

[에러 메시지에서 핵심 한 줄] _______________

[멘토에게 물어볼 딱 한 가지 질문]
  _______________________________________
이해 확인

하루 끝에 각자 답해 봅니다.

  • 오늘 스스로 뚫은 막힘이 하나라도 있나요?
  • 질문할 때 "시도한 것"을 함께 말했나요?
  • 내일 이어서 할 첫 할 일은 무엇인가요?
⚠️흔한 실수
실수 "그냥 안 돼요"라고만 말하며 손을 든다.
대처 막힘 로그를 먼저 채우게 한 뒤 질문받으세요. 다만 30분 넘게 같은 곳에서 헤매면 개입해 좌절을 막습니다 — 독립성과 방치는 다릅니다.
Day 2 · 세션 3 · 오후

디자이너 트랙 — 프로젝트 화면 방향 구상 시작

80분 · 디자인 수습생 중심
🎯학습목표
  • 다음 2주 프로젝트에서 자신이 맡을 기획·화면 방향을 스스로 그려보기 시작한다.
  • 개발 수습생이 만드는 화면과 어떻게 맞물릴지 한 장으로 정리한다.
✍️워크시트
화면 방향 스케치 — 디자이너 워크시트
[이 프로젝트는 누구를 위한 것] _______________
[핵심 화면 3개]
  1. _______________  (무엇을 보여주나)
  2. _______________
  3. _______________
[가장 중요한 버튼/행동 하나] _____________
[개발 파트와 맞춰야 할 것] _______________

진행 방식 종이 스케치나 간단한 와이어프레임으로 충분합니다. 완성도보다 "방향"이 목표예요.

  • 거친 손그림 → 멘토와 5분 대화 → 한 번 다시 그리기
  • 우리 고객사(KT엠모바일 · KT알파 · 핀업) 서비스 화면을 참고 예시로 살펴보기
이해 확인

세션 끝에 확인합니다.

  • 핵심 화면 3개를 말로 설명할 수 있나요?
  • 개발 파트와 맞춰야 할 지점을 하나 짚었나요?
WED

독립 구현 ② · 코드리뷰로 다듬기

오늘 목표: 절반쯤 온 코드를 스스로 리뷰하고, 멘토 리뷰를 받아 고쳐 커밋한다.
Day 3 · 세션 1 · 오전

아침 기본기 — 코드리뷰 딥다이브 (포인터 세션)

40분 · 매일 아침 루틴
🎯학습목표
  • "에러 처리와 예외 상황" 패턴을 알고 내 코드에서 빈틈을 한 곳 찾는다.
✍️실습

CS 기본기 4주 커리큘럼 문서의 해당 일차를 진행합니다. 오늘은 "빈 값·에러 상황 다루기" 편입니다. 각자 자기 코드에서 "값이 없으면?" "실패하면?" 두 질문을 던져 봅니다.

Day 3 · 세션 2 · 오전~오후

독립 구현 계속 + 셀프 코드리뷰

3시간 · 구현 + 자기점검
🎯학습목표
  • 커밋 전에 스스로 자기 코드를 리뷰하는 셀프체크 습관을 만든다.
  • 멘토 리뷰 코멘트를 받아 스스로 고쳐서 다시 올린다.
🕘진행표
0:00
집중 구현 — 어제 이어서, 절반 지점 통과가 목표
1:20
셀프 코드리뷰 — 커밋 전 체크리스트로 자기 코드 점검 (20분)
1:40
멘토 리뷰 — 1인당 10분, 코멘트는 2~3개로 짧게
2:20
고쳐서 재커밋 — 받은 코멘트를 스스로 반영
💬멘토 스크립트
멘토

"코드를 다 짰다고 바로 올리지 말고, 올리기 전에 스스로 한 번 읽어봐요. '내가 이 코드를 처음 보는 사람이라면 이해될까?' 이 질문 하나면 충분해요."

"제 리뷰 코멘트는 여러분을 혼내는 게 아니에요. 더 좋게 만드는 힌트예요. 반영은 여러분이 직접 해봐요 — 제가 대신 고치지 않을게요."

✍️워크시트
커밋 전 셀프 코드리뷰 체크리스트
[ ] 변수·함수 이름만 봐도 뜻이 통하나?
[ ] 같은 코드가 두 번 반복되지 않나?
[ ] 값이 없거나 실패할 때도 안 터지나?
[ ] 안 쓰는 코드·주석·console.log 를 지웠나?
[ ] 커밋 메시지가 무엇을 바꿨는지 설명하나?

[스스로 발견해 고친 것 한 가지]
  _______________________________________
이해 확인

재커밋 전에 확인합니다.

  • 셀프리뷰에서 스스로 고친 게 하나라도 있나요?
  • 멘토 코멘트를 내 손으로 반영했나요?
⚠️흔한 실수
실수 리뷰 코멘트를 "지적당했다"고 받아들여 위축된다.
대처 잘한 점을 먼저 한 가지 꼭 짚어준 뒤 개선점을 말하세요. 코멘트는 코드에 대한 것이지 사람에 대한 게 아니라고 분명히 해줍니다.
THU

독립 구현 ③ · 마무리와 품질

오늘 목표: 티켓을 "완료" 상태까지 끌고 간다. 테스트·확인으로 스스로 품질을 보증한다.
Day 4 · 세션 1 · 오전

아침 기본기 — 코드리뷰 딥다이브 (포인터 세션)

40분 · 매일 아침 루틴
🎯학습목표
  • "직접 확인(테스트)" 패턴을 알고, 완료 전 손으로 확인하는 절차를 세운다.
✍️실습

CS 기본기 4주 커리큘럼 문서의 해당 일차를 진행합니다. 오늘은 "내가 만든 걸 내가 확인하기" 편으로, 화면/응답을 직접 눌러보며 확인하는 절차를 만듭니다.

Day 4 · 세션 2 · 오전~오후

티켓 마무리 — "완료"의 기준 맞추기

3시간 · 마감 집중
🎯학습목표
  • 월요일에 정한 "완료 기준"에 맞춰 스스로 확인하고 마감한다.
  • 정상 경우뿐 아니라 빈 값·틀린 입력도 직접 눌러 확인한다.
🕘진행표
0:00
마감 스프린트 — 남은 할 일을 마무리, 필요한 질문만 짧게
1:30
직접 확인(수동 테스트) — 정상/빈값/오류 3경우를 손으로 눌러보기
2:00
최종 셀프리뷰 + 커밋 — 완료 기준 대조표 체크
2:30
완료 발표 — "무엇을 만들었고 어떻게 확인했는지" 3분 데모
💬멘토 스크립트
멘토

"오늘 '완료'는 코드를 짰다는 뜻이 아니라, 직접 눌러 확인했다는 뜻이에요. 잘 되는 경우만 보지 말고, 빈칸으로 두거나 이상한 값을 넣으면 어떻게 되는지도 눌러봐요."

"마지막 데모는 자랑하는 시간이에요. 한 주 동안 스스로 여기까지 온 거예요. 짧아도 좋으니 당당하게 보여줘요."

✍️워크시트
완료 기준 대조표 — 마감 전 채우기
[월요일에 정한 완료 기준] ___________________

직접 확인한 경우
  [ ] 정상 입력   → 결과: _______________
  [ ] 빈 값 / 없음 → 결과: _______________
  [ ] 틀린 입력   → 결과: _______________

[남은 아쉬운 점(다음에 고칠 것)] ___________
[3분 데모에서 보여줄 핵심 화면] ___________
이해 확인

완료 처리 전에 확인합니다.

  • 세 가지 경우(정상·빈값·오류)를 직접 눌러봤나요?
  • 완료 기준과 실제 결과가 맞나요?
  • 데모에서 무엇을 보여줄지 정했나요?
⚠️흔한 실수
실수 "잘 되는 경우"만 한 번 눌러보고 완료라고 선언한다.
대처 빈 값·틀린 입력을 반드시 함께 확인시키세요. 실무에서 버그는 대부분 "예상 못한 입력"에서 나온다고 짚어줍니다.
FRI

종합 프로젝트 예고 · 팀 구성 · 회고

오늘 목표: 다음 2주 프로젝트의 주제 후보를 보고, 팀·역할·PM을 정하고, 한 주를 돌아본다.
Day 5 · 세션 1 · 오전

종합 프로젝트 예고 — 주제 후보 함께 보기

80분
🎯학습목표
  • 다음 2주 종합 프로젝트가 어떤 것인지 큰 그림을 이해한다.
  • 주제 후보들을 비교하고 "왜 이게 끌리는지"를 말할 수 있다.
🕘진행표
0:00
프로젝트 개요 — 2주간 팀으로 하나를 만든다는 흐름 설명
0:15
주제 후보 공유 — 예: 사내 미니 도구, 고객 서비스 참고형 화면, 학습 기록 앱 등 3~4개
0:40
각자 선호 투표 + 이유 — 끌리는 주제와 이유 한 줄
1:00
토론 — 우리 4명이 2주에 만들 수 있는 크기인지 함께 가늠
💬멘토 스크립트
멘토

"다음 2주는 지금까지 배운 걸 다 모아서, 팀으로 하나의 결과물을 만드는 시간이에요. 혼자가 아니라 넷이 함께요. 우리 회사가 '고객과 함께 더 나은 세상을 만들어 나가는' 것처럼, 여러분도 함께 만들어 볼 거예요."

"주제는 제가 정해주는 게 아니라 같이 골라요. 거창하지 않아도 좋아요. '2주에 우리가 진짜 끝낼 수 있는 크기'가 제일 중요해요."

✍️워크시트
프로젝트 주제 고르기 — 각자 채우기
[가장 끌리는 후보] ___________________
[끌리는 이유 한 줄] _________________
[내가 잘 맡을 수 있을 부분] ___________
[걱정되는 점 하나] ___________________
이해 확인

세션 끝에 확인합니다.

  • 프로젝트가 2주짜리 팀 작업이라는 걸 이해했나요?
  • 선호 주제와 그 이유를 말했나요?
Day 5 · 세션 2 · 오후

팀 구성 · 역할과 PM 롤 정하기

70분
🎯학습목표
  • 팀 안에서 각자의 역할(개발 파트·디자인 파트)을 정한다.
  • PM(진행 담당) 역할이 무엇인지 알고 한 명을 정한다.
🕘진행표
0:00
역할 소개 — 개발 3 · 디자인 1 구성에서 누가 무엇을 맡을지 예시
0:15
PM 롤이란 — 일정·할 일 정리·소통 담당(대장이 아님)임을 설명
0:30
역할·PM 정하기 — 서로 상의해 자율 결정, 멘토는 중재만
0:55
킥오프 준비물 정리 — 다음 주 첫날 무엇부터 시작할지 메모
💬멘토 스크립트
멘토

"PM은 '대장'이 아니에요. 팀이 길을 잃지 않게 할 일을 정리하고, 서로 소통을 돕는 사람이에요. 돌아가면서 경험해 보면 좋은 역할이에요."

"디자인을 맡은 친구는 화면 방향을, 개발 친구들은 각자 맡을 화면·기능을 나눠요. 정답은 없어요. 서로 하고 싶은 것과 잘하는 것을 얘기하면서 정해봐요."

✍️워크시트
팀 구성표 — 함께 채우기
[프로젝트 이름(가칭)] _______________
[PM(진행 담당)] _______________

역할 나누기
  - 디자인 파트: _____ → 맡을 것 _______
  - 개발 A: _____ → 맡을 것 _______
  - 개발 B: _____ → 맡을 것 _______
  - 개발 C: _____ → 맡을 것 _______

[다음 주 첫날 가장 먼저 할 일] _________
이해 확인

세션 끝에 확인합니다.

  • 각자 맡을 역할이 정해졌나요?
  • PM이 무슨 일을 하는지 말할 수 있나요?
  • 다음 주 첫날 시작점을 정했나요?
⚠️흔한 실수
실수 목소리 큰 한 명이 역할을 다 정해버리고 나머지는 따라간다.
대처 4명 모두 "하고 싶은 것"을 한 번씩 말하게 한 뒤 정하도록 멘토가 진행 순서를 잡아줍니다.
Day 5 · 세션 3 · 오후

주간 회고 · 1:1 면담

60분
🎯학습목표
  • 한 주 동안 "더 독립적으로" 해본 경험을 스스로 돌아본다.
  • 1:1에서 잘한 점·다음 목표를 멘토와 확인한다.
🕘진행표
0:00
그룹 회고 — 이번 주 KPT(좋았던 것·아쉬운 것·다음에 시도) 한 바퀴
0:25
1:1 면담 — 1인당 7~8분, 나머지는 워크시트 정리
0:55
다음 주 예고 — 프로젝트 킥오프 안내로 마무리
💬멘토 스크립트
멘토

"이번 주 여러분, 제가 옆에서 덜 도와줬는데도 티켓을 끝까지 해냈어요. 그게 얼마나 큰 성장인지 알아줬으면 해요. 막히고 스스로 뚫은 순간들이 진짜 실력이에요."

(1:1에서) "이번 주 스스로 제일 잘했다고 느낀 순간은 언제였어요? 다음 주 프로젝트에서 꼭 해보고 싶은 건요?"

✍️워크시트
6주차 회고 — KPT
[Keep] 이번 주 좋았던 것 _______________
[Problem] 아쉬웠던 것 _________________
[Try] 다음 주 시도할 것 _______________

[스스로 뚫은 막힘 중 가장 뿌듯한 것]
  _______________________________________
[프로젝트에서 맡고 싶은 역할] ___________
이해 확인 (멘토용 평가 체크포인트)

이번 주 관찰 항목을 수습생별로 기록합니다.

  • 독립성 — 멘토 개입 없이 스스로 판단·진행한 정도
  • 문제해결력 — 막혔을 때 스스로 시도한 뒤 질문했는가
  • 협업 태도 — 팀 구성·역할 논의에서 서로를 존중했는가
  • 산출물: 완료 티켓 · 프로젝트 킥오프 준비(팀·역할·주제)