8주의 마지막, 각자 기능 하나를 처음부터 끝까지 만들어 대표님 앞에서 시연합니다.
+ 밤샘 경쟁 해커톤이 아니라, 두 달간 배운 걸 종합하는 미니 스프린트 + 발표예요. 자기가 매일 쓰는 이 플랫폼을 더 좋게 만듭니다.
+
+ 7~8주차 · 종합
+ 1인 1기능 (디자이너는 페어)
+ 데모데이: 8주차 금요일
+
+
+
+
+
What
+
무엇을 만드나
+
거창한 새 서비스가 아니에요. "이 플랫폼에 있으면 좋겠다" 싶은 기능 하나를, 혼자 힘으로 끝까지.
+
+
대상은 여러분이 매일 쓰는 이 학습 플랫폼(mirim-app)입니다. 8주간 티켓으로 이 코드를 만져 왔으니
+ 구조를 이미 알아요. 그 위에 "화면 → API → DB"를 관통하는 기능 하나를 스스로 설계하고 구현합니다.
+ 범위는 4~5일에 끝낼 수 있는 크기 — 멘토와 함께 첫날 범위를 확정해요.
+
+
+
개발
학습 뱃지·연속 출석
코스를 N개 완료하면 뱃지, 며칠 연속 학습했는지 표시. 진도 데이터를 활용.
+
개발
코딩 문제 즐겨찾기
어려웠던 문제를 별표해 두고 나중에 다시 풀기. 새 테이블 + 화면.
+
개발
멘토용 주간 리포트
이번 주 학생별 제출·진도 요약을 한 화면에. 집계 쿼리 연습.
+
디자인+개발
대시보드 리디자인
첫 화면을 더 동기부여되게. 디자이너가 설계, 개발자와 페어로 반영.
+
+
아이디어는 자유예요. 위는 예시일 뿐 — 자기가 "있으면 진짜 쓸 것 같은" 걸 고르는 게 제일 좋아요. 단, 첫날 멘토와 범위를 못 박아 "5일 안에 끝나는 크기"로 자릅니다.
+
+
+
+
Schedule
+
일정 — 7주차 기획, 8주차 스프린트
+
이미 7주차(기획·설계) → 8주차(구현·발표) 커리큘럼과 이어져요. 그 뼈대에 데모데이를 얹습니다.
+
+
7주차기획 주간
주제 정하기 · 설계 발표
무엇을·왜 만들지 정하고, 화면 스케치 + 데이터 구조(어떤 테이블·API)를 한 장으로. 주 끝에 멘토·동료 앞에서 3분 설계 발표 → 피드백으로 범위 조정.
+
8주차 월~목스프린트
구현 + 매일 스탠드업
매일 아침 5분 "어제 한 것·오늘 할 것·막힌 것" 공유. 중간에 PR을 열어 동료·멘토 리뷰(코드리뷰 가이드 그대로). 막히면 30분 룰로 질문.
+
8주차 금데모데이 🎉
시연 + 발표 + 회고
각자 5분 시연 + 3분 Q&A. 대표님·멘토·동료가 관객. "무엇을·왜·어떻게·무엇을 배웠나"를 담아요. 끝나고 두 달 전체 회고.
+
+
+
+
+
Demo Day
+
발표는 이렇게
+
코드가 멋진 것보다 "무엇을 배웠는지 전할 수 있는가"가 더 중요해요. 5분이면 충분합니다.
+
+
+
1
왜 만들었나 (30초) — 어떤 불편을 풀고 싶었는지.
+
2
실제로 보여주기 (2분) — 슬라이드 말고 돌아가는 화면으로 시연. 미리 시나리오를 연습해 두기.
+
3
어떻게 만들었나 (1분) — 화면·API·DB가 어떻게 이어지는지 한 장으로.
+
4
무엇을 배웠나 · 못한 것 (1분) — 막혔던 지점과 배움. 못 끝낸 부분을 솔직히 말하는 게 오히려 점수예요.
+
5
Q&A (3분) — 관객 질문. 모르면 "그건 아직 몰라요, 찾아볼게요"가 정답.
+
+
+
완성이 목표가 아니에요. 미완이어도 괜찮습니다 — 어디까지 했고 왜 거기서 멈췄는지 설명할 수 있으면 돼요. 밤새우지 마세요. 지속가능한 속도가 실무의 기본입니다.
+
+
+
+
Evaluation
+
무엇을 보나
+
캡스톤은 별도 점수가 아니라, 8주 평가 루브릭의 여러 축을 한 번에 종합해 확인하는 자리예요.
+
+
보는 것
연결되는 평가 축
무게
+
+
혼자 힘으로 화면~DB를 관통했나
② 기본기 · 직무 역량
높음
+
스탠드업·리뷰·질문으로 잘 협업했나
③ 협업 · 소통
높음
+
막힘을 스스로 헤쳐 나갔나
① 성장 속도 · 학습력
중간
+
발표로 자기 일을 설명했나
③ 협업 · 소통 / ④ 태도
중간
+
끝까지 책임지고 마무리했나
④ 태도 · 책임감 / ⑤ 성장 가능성
중간
+
+
+
즉, 캡스톤은 8주의 축소판이에요. 평소에 티켓·리뷰·질문을 성실히 한 사람이 자연스럽게 잘합니다 — 벼락치기가 안 되는 구조예요. 자세한 채점은 「어썸데브 수습 평가 루브릭」 참고.
코드리뷰는 "누가 잘못했나"를 찾는 자리가 아니라, 팀의 코드를 함께 좋게 만드는 자리예요.
+ 5~8주차 티켓 작업 내내, 여러분은 서로의 PR을 리뷰합니다. 리뷰를 잘 주는 법과 잘 받는 법을 여기서 익혀요.
+
+ 5~8주차 · 상시
+ 도구: Gitea Pull Request
+ 평가 ③ 협업·소통과 연결
+
+
+
+
+
Why
+
왜 신입 때부터 리뷰를 배우나
+
실무 개발자는 코드를 짜는 시간만큼 남의 코드를 읽습니다. 리뷰는 선택이 아니라 일하는 방식이에요.
+
+
1
버그는 혼자 못 잡는다. 내 코드의 빈틈은 내 눈에 잘 안 보여요. 다른 눈 하나가 사고를 막습니다 — 우리 감사에서 나온 버그들도 대부분 "한 번 더 읽었으면" 잡혔을 것들이에요.
+
2
남의 코드를 읽으며 는다. 동료가 문제를 어떻게 풀었는지 보는 게 가장 빠른 학습이에요. 리뷰는 공짜 과외입니다.
+
3
코드에 대한 대화가 팀을 만든다. "왜 이렇게 했어?"를 감정 없이 주고받는 연습 — 이게 되는 사람이 함께 일하기 좋은 사람이에요.
+
4
기록이 남는다. PR의 리뷰 코멘트는 여러분이 어떻게 성장했는지 보여주는 증거예요. 평가 ③ 협업·소통의 핵심 근거가 됩니다.
+
+
+
+
+
Flow
+
우리 팀 리뷰 흐름
+
티켓 하나를 끝낼 때마다 이 순서를 돕니다. 4명이라 서로를 다 볼 수 있어요.
+
+
브랜치에서 작업하고 PR을 연다
티켓별 브랜치(예: feat/empty-state)에서 작업 → Gitea에서 Pull Request 생성. 제목·설명에 "무엇을 왜 했는지" + 스크린샷(화면 변경 시)을 적어요.
+
리뷰어를 지정한다 — 동료 1명 + 멘토
동료 수습생 한 명과 멘토를 리뷰어로. 동료끼리 먼저 보는 게 핵심이에요 — 같은 눈높이의 질문이 가장 배움이 큽니다.
+
리뷰어는 24시간 안에 코멘트를 남긴다
아래 체크리스트로 읽고, 줄 단위로 코멘트. 좋은 점도 꼭 하나 남겨요("여기 이렇게 나눈 거 좋네요").
+
작성자는 코멘트에 답하고 반영한다
고치면 "반영했어요", 다르게 생각하면 "이래서 이렇게 했는데 어때요?"로 답. 침묵하고 그냥 merge하지 않기.
+
승인(Approve) 후 merge
리뷰어가 Approve하면 작성자가 merge. 배포는 멘토와 함께(운영은 학생 사용 시간을 피해서).
+
+
+
+
+
Reviewer
+
리뷰할 때 — 무엇을 볼까 (체크리스트)
+
위에서 아래로. 위쪽이 더 중요해요. 스타일 지적보다 "돌아가는가·안전한가"가 먼저입니다.
+
+
+
정말 동작하나 — 직접 받아서 실행해 봤나? 엣지 케이스(0건, 빈 값, 아주 긴 입력)는?
+
안전한가 — 사용자 입력을 그대로 믿지 않나? 남의 데이터에 접근되지 않나? (우리가 배운 것들)
+
읽히나 — 3개월 뒤의 내가, 처음 보는 동료가 이 코드를 이해할까? 이름이 하는 일을 말해주나?
+
테스트가 있나 — 규칙이 있는 로직이면 테스트로 못 박았나?
+
범위가 맞나 — 티켓과 상관없는 "김에 수정"이 섞여 있지 않나? PR은 작아야 리뷰가 됩니다.
+
우리 패턴을 따르나 — 옆 코드와 같은 방식인가? (프론트 Field 부품, 백엔드 서비스 계층 등)
+
+
+
리뷰의 황금률: 사람이 아니라 코드를 짚는다. "너 왜 이렇게 했어?"(X) → "이 부분은 이러이러해서 이렇게 하면 어떨까요?"(O). 질문형으로, 근거와 함께.
+
+
+
+
Examples
+
같은 지적, 다르게 쓰기
+
내용이 맞아도 말투가 팀을 만들거나 무너뜨려요. 왼쪽처럼 말고 오른쪽처럼.
+
+
+
🚫 이렇게 말고
+
+ "이거 버그임"
+ "왜 여기서 컴포넌트를 또 만들었어요?"
+ "그냥 다 지우고 다시 하세요"
+ (코멘트 없이 Approve만 누름)
+
+
+
+
✅ 이렇게
+
+ "0건일 때 .map()이 빈 배열이라 화면이 비어요. 빈 상태 안내를 넣으면 어떨까요?"
+ "컴포넌트를 함수 안에 정의하면 렌더마다 새로 만들어져 포커스가 풀려요(가입 폼에서 났던 그 버그!). 밖으로 빼면 어떨까요?"
+ "방향은 좋아요! 이 함수만 두 가지 일을 해서, 조회와 저장을 나누면 더 읽기 쉬울 것 같아요."
+ "여기 이름 나눈 거 깔끔하네요 👍 한 가지만: …"
+
+
+
+
+
+
+
Author
+
리뷰받을 때 — 잘 받는 것도 실력
+
리뷰는 내 코드에 대한 것이지 나에 대한 게 아니에요. 방어하지 말고 배우면 됩니다.
+
+
+
고맙다고 시작한다. 리뷰어는 내 시간을 아껴 준 거예요.
+
이해가 안 되면 되묻는다. "이 부분 왜 그런지 조금만 더 알려줄 수 있어요?" — 몰라서 묻는 건 부끄러운 게 아니에요.
+
동의하지 않으면 근거로 답한다. 감정이 아니라 "이래서 이렇게 했는데, 어떻게 생각해요?"로.
+
고쳤으면 알린다. 코멘트마다 "반영했어요" / "이건 이래서 그대로 뒀어요"로 마무리.
+
+
+
하지 말 것: 리뷰를 무시하고 조용히 merge / "그냥 되게만 하면 되잖아요" / 지적을 인신공격으로 받기. 리뷰를 잘 받는 사람이 가장 빨리 큽니다.
중간보고·질문(30분 룰·3요소)을 하고, 받은 리뷰를 이해하고 반영한다. 동료 PR에 한 건이라도 성실히 리뷰한다.
15–17점
+
Lv4 우수
먼저 공유하고, 동료 PR에 근거 있는 리뷰로 도움을 준다. 리뷰를 감정이 아닌 코드로 주고받는다.
18–20점
점수/ 20
+
💡 코드리뷰는 이 축의 핵심 근거예요 — Gitea PR의 리뷰 코멘트(주고받은 것 모두)가 5~8주차 내내 남습니다. 리뷰를 잘 받는 것(방어하지 않고 배우기)과 리뷰를 잘 주는 것(사람이 아닌 코드를 짚기)을 함께 봅니다. 자세한 방법은 학습 문서 「코드리뷰 실습 가이드」 참고.