드디어 마지막 주입니다. 이번 주는 만들던 것을 실제로 동작하는 상태까지 완성하고, 경영진과 팀 앞에서 데모로 발표하며, 8주간의 성장을 함께 돌아보고 마무리합니다. 금요일에는 최종 평가와 전환 면담으로 다음 여정을 이야기합니다.
6블록 틀(학습목표 · 진행표 · 멘토 스크립트 · 실습 · 이해 확인 · 흔한 실수)은 1주차 강의안과 동일합니다. 처음 여시는 멘토는 1주차 안내 카드를 먼저 참고하세요.
"자, 드디어 마지막 주예요. 지난 7주 동안 정말 많이 컸어요. 이번 주는 새로 배우는 주가 아니라, 여러분이 만들던 걸 끝까지 완성해서 자랑스럽게 보여주는 주예요."
"스탠드업 규칙 기억하죠? 딱 세 가지만 말해요. 어제 뭐 했는지, 오늘 뭐 할 건지, 막힌 게 있는지. 막힌 걸 말하는 건 부끄러운 게 아니라 제일 잘하는 거예요. 그래야 제가 도와줄 수 있어요."
디자이너에게: "OO은 오늘부터 발표에서 보여줄 화면이랑 기획 흐름을 다듬어 주세요. 개발 팀이 완성하는 화면이랑 계속 맞춰보면서요."
오늘의 마무리 보드를 각자 채웁니다. 포스트잇 한 장에 아래 대본을 그대로 옮겨 화이트보드에 붙이세요.
이름: ________ [어제 한 일] ________________________ [오늘 끝낼 기능 ①] ____________________ [오늘 끝낼 기능 ②] ____________________ [지금 막힌 곳] ______________________ [도움이 필요한가?] ☐ 혼자 가능 ☐ 멘토 도움
착수 전에 한 명씩 물어봅니다.
"화면은 나왔는데 버튼이 안 먹는 거죠? 좋아요, 같이 봐요. 우선 버튼 눌렀을 때 함수가 진짜 불리는지부터 확인해요. console.log 한 줄 찍어볼까요?"
"거봐요, 로그가 안 찍히죠? 그럼 문제는 함수 안이 아니라 연결이에요. onClick이 제대로 걸렸는지 봐요. 이렇게 하나씩 좁혀가는 거예요. 한 번에 다 보려고 하면 오히려 안 보여요."
기능 하나를 "끝났다"고 말하기 전에, 아래 3가지를 실제로 클릭해서 확인합니다.
기능 이름: __________ ☐ 정상 경우: 제대로 입력하면 기대한 화면이 나온다 ☐ 빈 경우: 아무것도 입력 안 하고 눌러도 앱이 안 터진다 ☐ 이상한 경우: 이상한 값을 넣어도 에러 화면 대신 안내 메시지가 나온다 세 개 다 ☑ 되면 → git commit -m "___기능 완성___"
중간 데모 때 각자에게:
아침 스탠드업은 어제와 같은 마무리 보드 형식으로 짧게 진행합니다. 오늘은 "내 기능이 옆 사람 기능과 어디서 만나는가"를 한 마디씩 덧붙이게 하세요. (CS 기본기가 필요한 팀원이 있으면 CS 기본기 4주 커리큘럼 문서의 해당 일차를 진행하되, 마지막 주인 만큼 프로젝트 완성이 우선입니다.)
fetch해 뿌리기."어제까지는 각자 자기 방을 꾸민 거예요. 오늘은 그 방들을 복도로 연결해서 한 집으로 만드는 날이에요. 손님(사용자)이 현관에서 들어와서 방까지 쭉 걸어갈 수 있어야 해요."
"연결할 때 제일 자주 나는 문제가 뭔지 알아요? 데이터가 안 오는 게 아니라 모양이 다른 거예요. 백엔드는 userName으로 줬는데 화면은 name을 찾고 있으면 빈칸이 떠요. 그럴 땐 브라우저 개발자도구 Network 탭에서 진짜 온 데이터를 눈으로 확인해요."
코딩 전에 연결 지도를 먼저 채웁니다. 내 화면이 어떤 데이터를 필요로 하는지 말로 정리하면 코드가 쉬워집니다.
내 화면 이름: ____________ 이 화면이 열릴 때 불러야 할 데이터: 주소(API): /api/________ 받는 것: ____________________ 화면에 보여줄 항목: ① ________ ← 데이터의 ______ 필드 ② ________ ← 데이터의 ______ 필드 데이터가 안 왔을 때 화면: ☐ 로딩중 표시 ☐ 빈 목록 안내
합류 점검 때 짝끼리 서로 물어보게 합니다.
main으로 합쳐보게 하고, 충돌 해결을 멘토가 옆에서 한 번 같이 해준다. "합치는 건 자주 할수록 안 아파요"를 반복."버그가 많아 보여도 걱정 마요. 프로 개발자도 발표 전엔 다 이래요. 중요한 건 다 고치는 게 아니라 발표에 보여줄 길을 매끄럽게 만드는 것이에요."
"그래서 오늘은 버그를 두 줄로 나눠요. 왼쪽은 '발표 흐름에서 사용자가 만나는 것', 오른쪽은 '깊이 들어가야 보이는 것'. 왼쪽부터 잡아요. 오른쪽은 회고에 '다음에 개선'으로 적으면 그것도 훌륭한 결과예요."
팀 공용 버그 보드를 채웁니다. 각 버그를 아래 형식으로 적어야 나중에 다시 재현할 수 있습니다.
[무엇을 했더니] ______________________ [무엇이 나왔나] ______________________ [원래 나와야 할 것] __________________ 발표 흐름에 포함? ☐ 예(급함) ☐ 아니오(나중) 담당: ______
분배 직전에:
"고쳤어요? 좋아요! 그런데 여기서 제일 중요한 한 가지. 고쳤다고 바로 다음으로 넘어가지 말고, 방금 그 버그가 났던 그 동작을 다시 한 번 그대로 눌러봐요. 진짜 사라졌는지 눈으로 확인해야 해요."
"그리고 하나 더. 고치다가 옆 기능이 같이 깨지는 경우가 많아요. 그래서 고친 뒤에는 짧게라도 전체를 한 번 훑는 거예요. 이걸 잘하면 발표날 사고가 확 줄어요."
팀이 함께 발표 흐름 통과표를 만들고, 오후에 한 번은 전 구간 ☑를 목표로 합니다.
1단계 첫 화면 진입 ................ ☐ 통과 2단계 ___________________ .......... ☐ 통과 3단계 ___________________ .......... ☐ 통과 4단계 ___________________ .......... ☐ 통과 5단계 마무리 화면 ................ ☐ 통과 전 구간 한 번에 통과한 시각: __:__
전체 통과 시험 후:
"발표는 코딩이랑 달라요. 잘 만든 걸 잘 전하는 것까지가 실력이에요. 15분이면 생각보다 짧아요. 그래서 순서를 정해둬야 안 헤매요."
"순서는 간단해요. ①우리가 풀려던 문제가 뭐였는지, ②그래서 뭘 만들었는지, ③실제로 이렇게 됩니다(시연), ④8주 동안 뭘 배웠는지. 이 네 칸만 채우면 발표가 돼요."
디자이너에게: "OO은 ②와 함께 화면을 어떻게 설계했는지, 왜 이렇게 배치했는지 기획 이야기를 맡아주세요. 개발자들이 만든 걸 '왜'로 이어주는 다리예요."
팀이 함께 발표 대본 뼈대를 채웁니다. 담당자와 대략의 시간까지 적어야 리허설이 가능합니다.
① 문제 (약 2분) 담당 ____ "우리는 ________ 문제를 풀고 싶었습니다." ② 솔루션 (약 3분) 담당 ____ + 디자이너 ____ "그래서 ________ 을 만들었습니다." ③ 시연 (약 7분) 담당 ____ 클릭 순서: _______________________ ④ 배운 점 (약 3분) 담당 ____ "8주 동안 가장 크게 배운 것: ________"
뼈대를 다 채운 뒤:
"방금 정말 좋았어요. 특히 시연에서 화면 넘어가는 게 매끄러웠어요. 딱 하나만 다듬어요. 시작할 때 조금 빨랐어요. 첫 문장은 심호흡하고 천천히. '안녕하세요, 저희 팀이 만든 건…' 이렇게 여유 있게 열면 나머지가 편해져요."
"그리고 만약 발표 중에 화면이 안 뜨면요? 당황하지 말고 이렇게 말하면 돼요. '잠시 화면을 다시 불러오겠습니다.' 이 한마디면 프로처럼 보여요. 사고는 누구나 나요. 대응이 실력이에요."
리허설 1회차 뒤, 서로에게 피드백 카드를 한 장씩 써 줍니다. 좋은 점을 반드시 먼저 적는 규칙입니다.
받는 사람: ______ [좋았던 점 — 꼭 하나 이상] ________________________________ [더 좋아질 한 가지 — 구체적으로] ________________________________ [내일 이거 하나만 기억하면 돼요] ________________________________
2회차 후 각자에게:
"자기평가서는 잘 보이려고 쓰는 게 아니에요. 8주 전의 나랑 지금의 나를 비교하는 거예요. 못한 걸 솔직히 적어도 괜찮아요. 오히려 '이건 아직 부족하고, 다음엔 이렇게 하고 싶다'가 있으면 저는 그게 제일 좋아요."
"발표 전 긴장되는 거 알아요. 긴장은 잘하고 싶은 마음이에요. 나쁜 게 아니에요. 리허설한 대로만 하면 돼요. 우리 이미 어제 두 번 다 해봤잖아요."
각자 자기평가서를 아래 항목대로 작성해 제출합니다. (평가 루브릭과 함께 사용)
이름: ______ 트랙: ☐ 개발 ☐ 디자인 1. 8주 중 가장 크게 성장했다고 느낀 것 ________________________________ 2. 이번 프로젝트에서 내가 맡아 끝낸 것 ________________________________ 3. 아직 부족하다고 느끼는 것 (솔직하게) ________________________________ 4. 앞으로 3개월 안에 더 잘하고 싶은 것 ________________________________ 5. 스스로에게 주는 한마디 ________________________________
발표장 이동 전 최종 확인:
"안녕하세요. 지난 8주 동안 미림마이스터고에서 온 수습생 네 명과 함께 달려왔습니다. 오늘은 그 결과를 직접 보여드리는 자리예요. 첫 주에 console.log 하나에 감탄하던 친구들이 이제 동작하는 앱을 만들어 왔습니다. 따뜻하게 봐주세요."
"좋은 질문이에요. 잠깐 제가 거들면요, 지금 질문은 '이 기능을 어떻게 더 빠르게 만들 수 있냐'는 거예요. OO이 시도해본 방향으로 답해볼래요?"
발표 진행자(멘토 또는 팀장 역할 수습생)가 아래 진행 대본을 손에 들고 흐름을 이끕니다.
[열기] "지금부터 ___팀명___ 의 데모를 시작하겠습니다." [전환] 파트 넘길 때: "다음은 __이름__ 이(가) __파트__ 를 이어가겠습니다." [시연 안내] "실제 화면으로 보여드리겠습니다. 화면 봐주세요." [질문 받기] "질문 있으실까요? 편하게 말씀해 주세요." [닫기] "저희 발표를 들어주셔서 감사합니다. 8주간 정말 즐거웠습니다."
발표 직전 진행자에게:
"결론부터 말할게요. OO, 정식으로 함께하게 됐어요. 축하해요! 데모에서 보여준 완성도랑, 막혔을 때 끝까지 파고드는 태도가 특히 좋았어요. 다음 3개월은 이 세 가지를 같이 키워봐요."
"OO은 '조건부 전환'이에요. 무슨 뜻이냐면, 가능성은 충분히 봤고 딱 한두 가지만 더 채우면 된다는 거예요. 부족하다는 게 아니라 '거의 다 왔다'는 신호예요. 앞으로 3개월 동안 이 부분을 이렇게 채워가면 돼요. 제가 계속 봐줄게요."
"OO, 이번엔 정식 전환까지는 이르지 못했어요. 그런데 이건 OO이 못했다는 뜻이 절대 아니에요. 8주 전과 지금을 비교하면 정말 많이 자랐어요. 지금 이 성장 방향을 이렇게 이어가면 분명히 좋은 개발자가 돼요. 오늘 결과보다 앞으로가 훨씬 길어요."
멘토는 면담마다 기록지를 채우고, 다음 3개월 목표는 수습생과 함께 소리 내어 적습니다.
수습생: ______ 트랙: ☐ 개발 ☐ 디자인 [루브릭 종합] 멘토 평가 __ / 데모 __ / 자기평가 __ [전환 결정] ☐ 전환 ☐ 조건부 전환 ☐ 미전환 [결정의 근거 — 잘한 점 먼저] ________________________________ [다음 3개월 성장목표 — 함께 작성] ① ____________________________ ② ____________________________ ③ ____________________________ 멘토 서명 ______ 면담일 2026-__-__
진행 팁: 결과가 무엇이든 "잘한 점 → 결과 → 앞으로"의 순서를 지키세요. 결과를 먼저 던지면 뒤 이야기가 들리지 않습니다.
각 면담을 닫기 전에 멘토 스스로 점검합니다.
8주 과정 완주를 축하합니다. 첫 주 console.log("Hello")에서 시작해, 오늘 동작하는 데모를 경영진 앞에서 발표하기까지 — 네 명 모두 놀랍게 성장했습니다. 여기가 끝이 아니라 진짜 시작입니다. 각자 손에 쥔 다음 3개월 성장목표와 함께, "고객과 함께 더 나은 세상을 만들어 나가는" AWESOMEDEV의 동료로 계속 나아가요.