이번 주는 수습생이 처음으로 "진짜 코드베이스"를 건드립니다. 아주 작고 안전한 소과제를 배정하고, 접근 방법 공유 → 구현 → 중간보고 → 코드리뷰 반영 → 머지 → 배포 확인까지 실무의 한 사이클을 온전히 밟게 합니다. 목표는 잘 만든 결과물이 아니라, "내가 짠 코드가 실제로 반영되는" 첫 성공 경험을 심는 것입니다.
6블록 틀(학습목표 · 진행표 · 멘토 스크립트 · 실습 · 이해 확인 · 흔한 실수)은 1주차 강의안과 동일합니다. 처음 여는 멘토는 1주차 안내 카드를 먼저 참고하세요.
CS 기본기 4주 커리큘럼 문서의 W3 해당 일차를 그대로 진행합니다. 이 세션은 포인터(연결)용이니 30~40분 안에 마치고 본 세션으로 넘어갑니다.
"오늘부터 여러분한테 진짜 코드베이스에서 할 일을 하나씩 줄 거예요. 겁먹지 않아도 돼요. 첫 과제는 일부러 아주 작고 안전한 걸로 골랐어요."
"예를 들면 버튼 문구에 오타가 있는 걸 고친다든가, 화면에 안 맞는 문장을 다듬는다든가, 로그 메시지를 조금 더 알아보기 쉽게 바꾸는 거예요. 하루 만에 세상을 바꾸는 게 목표가 아니라, 내가 고친 게 실제로 반영되는 걸 한 번 경험하는 게 목표예요."
Tip. 과제를 줄 때 "이건 망가뜨려도 되는 안전한 부분"이라고 분명히 말해 심리적 부담을 낮춘다.
멘토는 아래에서 각자 수준에 맞게 1건씩 고릅니다. 공통 조건: 반나절 안에 끝나고, 실패해도 서비스에 영향이 없는 것.
"바로 코드부터 치고 싶은 마음 알아요. 그런데 실무에서는 손대기 전에 '어떻게 할 건지'를 한 번 말로 맞추는 것이 훨씬 빨라요. 엉뚱한 파일을 오래 헤매는 걸 막아주거든요."
"3~4줄이면 충분해요. 어느 파일을 볼 것 같은지, 어떻게 바꿀 생각인지, 확인은 어떻게 할 건지. 완벽하지 않아도 되니까 지금 생각나는 대로 적어봐요."
과제: [예: 저장 버튼 문구 오타 수정] 1) 어디를 고칠 것 같은가 → [예: web의 저장 버튼 컴포넌트 파일일 것 같다] 2) 어떻게 바꿀 생각인가 → [예: 버튼 텍스트 문자열만 올바른 맞춤법으로 교체] 3) 다 되면 어떻게 확인할 것인가 → [예: 로컬에서 그 화면 열어 버튼 글자 직접 확인] 막히면? 30분 넘게 혼자 헤매지 않고 멘토에게 물어본다. ✅
디자이너 트랙 (같은 시간, 별도 진행)
퇴근 전 각자에게 확인:
CS 기본기 4주 커리큘럼 문서의 W3 해당 일차를 진행합니다. 짧게 복습 + 오늘 분량만.
"30분 룰 하나만 기억해요. 혼자 30분 넘게 같은 자리에서 막히면, 그때는 물어보는 게 맞아요. 오래 붙잡는 게 성실한 게 아니에요. 실무에선 막힌 걸 빨리 공유하는 사람이 더 신뢰받아요."
"물어볼 때는 '안 돼요'만 말고, '이걸 하려는데 여기서 이런 메시지가 떠요, 여기까진 해봤어요'까지 같이 말해주면 서로 훨씬 빨라요."
오늘의 최소 목표: 새 브랜치에서 수정 → 커밋 → 로컬 확인. 아래 순서를 그대로 따라합니다.
main을 받고, 내 과제용 브랜치를 새로 판다.fix: 저장 버튼 문구 오타 수정).main에서 바로 수정한다.## 무엇을 바꿨나요 - [예: 저장 버튼의 "저장되엇습니다" 오타를 "저장되었습니다"로 수정] ## 왜 바꿨나요 - [예: 사용자에게 보이는 문구라 맞춤법이 틀리면 신뢰가 떨어짐] ## 어떻게 확인했나요 - [예: 로컬에서 저장 후 토스트 문구를 직접 확인] ## 리뷰어에게 - [예: 다른 화면에도 같은 오타가 있는지 봐주시면 좋겠어요]
PR 초안을 올리기 전 스스로 점검:
main이 아닌 내 작업 브랜치인가?CS 기본기 4주 커리큘럼 문서의 W3 해당 일차를 진행합니다.
"실무에서 팀장이 제일 답답한 게 뭔지 알아요? 진행 상황이 안 보이는 거예요. 다 끝낼 때까지 아무 말이 없으면, 잘 되고 있는지 막혀 있는지 알 수가 없거든요."
"그래서 오늘은 '3줄 보고'를 연습할 거예요. 어제 뭘 했고, 오늘 뭘 할 거고, 막힌 건 뭔지. 딱 세 줄이면 돼요. 이걸 하루 한 번씩만 해도 신뢰가 확 올라가요."
[중간보고] [내 이름] · [날짜] ✅ 한 것: [예: 저장 버튼 오타 수정하고 로컬 확인까지] ▶ 할 것: [예: PR 설명 다듬고 리뷰 요청하기] ⚠ 막힌 것: [예: 없음 / 또는: 같은 오타가 다른 화면에도 있는지 확인 중]
진행: 각자 3줄 보고를 작성 → 팀 채널에 올리기 → 멘토가 한 명씩 짧게 피드백. "막힌 것: 없음"도 좋은 보고라고 알려준다.
화면: [예: 목록 비어있을 때(빈 상태) 화면] Figma: [링크] 바뀐 점 - [예: 빈 상태에 안내 문구 + 일러스트 추가] 개발자가 봐야 할 값 - 글자색: [예: 보조 텍스트 컬러] - 여백: [예: 위아래 24, 좌우 16] - 버튼 상태: [기본 / hover / 비활성 각각 첨부] 궁금하면: [디자이너 이름] 에게 물어보세요 🙂
오늘 끝나기 전:
"제가 여러분 PR에 코멘트를 몇 개 달았어요. 미리 말할게요. 이건 잘못했다고 지적하는 게 아니에요. 저도 제 코드에 매일 리뷰를 받아요. 같이 더 좋게 만드는 대화예요."
"코멘트를 읽고 이해가 안 되면 '이게 무슨 뜻이에요?'라고 물어봐도 아주 좋아요. 리뷰는 원래 주고받는 거예요."
각 리뷰 코멘트를 아래 형식으로 한 줄씩 정리한 뒤 반영을 시작합니다.
"자, 머지 버튼은 여러분이 직접 눌러요. 제가 대신 안 눌러요. 방금 여러분이 짠 코드가 우리 진짜 코드에 합쳐지는 순간이에요."
"그리고 배포가 끝나면, 실제 화면을 같이 열어봐요. 아까 고친 그 문구, 그 버튼이 실제 서비스에서 그대로 보일 거예요. 이게 바로 개발자가 일하는 이유 중 하나예요 — 내가 만든 게 세상에 나가는 거요."
머지한 PR: [제목/번호] 배포 후 확인 - 어디서 확인했나: [예: 스테이징 목록 화면] - 내 변경이 보이나: [예: "저장되었습니다" 문구로 정상 표시됨] - 캡처: [스크린샷 첨부] 지금 기분 한 단어: [__________] 🎉
"이번 주 여러분 전부 진짜 코드를 머지했어요. 첫 실무 주에 이만큼 온 거 정말 대단해요. 결과물 크기는 중요하지 않아요. 사이클을 한 바퀴 돌았다는 게 핵심이에요."
"회고는 반성문이 아니에요. 잘한 것도 꼭 적어요. 아쉬운 건 '다음에 이렇게 해볼래'로 바꿔 적으면 그게 성장이에요."
이번 주 내가 머지한 것: [한 줄] 😀 잘한 점: [예: 막혔을 때 30분 룰대로 바로 물어봤다] 🤔 아쉬운 점: [예: PR 설명을 너무 짧게 썼다] 🚀 다음에 해볼 것: [예: 중간보고를 아침마다 먼저 올리기] 첫 실무 소감 한 줄: [____________________]
구두 또는 짧은 쪽지로:
수습생: [이름] 1) 완주력 — 과제를 머지까지 끝냈는가 근거: [관찰한 사실] 2) 피드백 반영 태도 — 리뷰를 방어 없이 받아 반영했는가 근거: [관찰한 사실] 3) 보고 습관 — 먼저 진행 상황을 공유했는가 근거: [관찰한 사실] 다음 주 개인 목표: [한 줄]
다음 주 예고 — 4주차. 첫 사이클을 돌아본 이제, 조금 더 넓게 봅니다. 우리 서비스가 어떤 구조로 돌아가는지(프론트·백엔드·배포의 큰 그림)를 익히고, 두 번째 과제는 "여러 파일에 걸친 조금 더 큰 변경"으로 한 단계 올라갑니다. 고객사(KT엠모바일·KT알파·핀업)의 실제 화면을 예로 함께 살펴봅니다.