이번 주는 수습생 4명이 처음으로 한 팀이 되어, 실제 제품에 붙일 수 있는 작지만 끝까지 가는 기능 하나를 함께 기획하고 설계합니다. 개인 강의를 잠시 접고, 주제 브레인스토밍·역할 분담·설계 리뷰로 이어지는 팀 워크숍 형태로 한 주를 굴립니다. 목요일부터는 실제로 손을 대기 시작하고, 금요일에 계획 대비 어디까지 왔는지 함께 점검합니다.
6블록 틀(학습목표 · 진행표 · 멘토 스크립트 · 실습 · 이해 확인 · 흔한 실수)은 1주차 강의안과 동일합니다. 이번 주는 세션 대부분이 개인 실습이 아니라 팀 워크숍이라는 점만 기억하세요 — 멘토는 강사보다 퍼실리테이터(진행자)에 가깝게 움직입니다.
스탠드업 규칙 — 이번 주부터 CS 기본기 4주 커리큘럼은 잠시 멈추고, 아침 시간을 팀 작업으로 씁니다. 매일 아침 각자 30초씩 세 가지만 말해요.
"자, 오늘부터 한 주 동안은 여러분 넷이 한 팀이에요. 지금까지는 각자 배웠지만, 이번 주는 같이 하나를 만들어 봅니다. 회사에서 실제로 일하는 방식이 딱 이래요."
"아침마다 '스탠드업'이라는 걸 할 거예요. 서서 짧게 하는 회의라 이름이 그래요. 어제 뭐 했고, 오늘 뭐 할 거고, 막힌 게 있으면 말하는 거예요. 잘 못했다고 혼나는 자리 절대 아니고요, 서로 어디쯤 있는지 아는 자리예요."
"우리가 만들 건 '앱 전체'가 아니에요. 이미 있는 제품에 쏙 붙는 작은 기능 하나예요. 예를 들면 '할 일에 마감일 추가하기', '게시글에 좋아요 버튼', '내가 쓴 글만 모아보기' 정도요. 이 정도면 한 주에 기획하고 설계하고 조금 만들어 볼 수 있어요."
"지금은 좋은 아이디어를 뽑는 시간이 아니에요. 많이 내는 시간이에요. 이상해 보여도 일단 적어요. 서로 아이디어에 '에이 그건 안 돼' 하는 말은 잠깐 참아 주세요."
디자이너 학생에게: "화면이 그려지는 아이디어가 있으면 그쪽으로 더 밀어봐도 좋아요. 이번 주 화면 설계를 ○○님이 이끌 거니까요."
아이디어를 이 문장 틀에 맞춰 적으면 크기를 가늠하기 쉬워요. 각자 최소 2개는 이 틀로 채워 봅니다.
누가: (예: 앱을 쓰는 일반 사용자 / 관리자) 무엇을 하고 싶다: (예: 할 일에 마감일을 정하고 싶다) 그래서 어떤 화면·버튼이 생긴다: (예: 날짜 선택 버튼과 마감일 뱃지) 한 주에 끝날까? (O/△/X): 우리 스택으로 되나? (웹=React, 서버=Spring Boot):
"이제 셋 중 하나를 골라요. 정답은 없어요. 대신 한번 고르면 이번 주는 그걸로 끝까지 가는 거예요. 마음이 흔들려도요."
"역할을 나눌 건데, PM이 제일 궁금하죠? PM은 대장이 아니에요. 팀이 길을 잃지 않게 챙기는 사람이에요. 오늘 뭐 하기로 했는지, 누가 막혔는지 기억하는 사람. 디자인 맡은 ○○님이 이번 주 화면과 기획을 이끌고, 개발 셋은 프론트·백엔드로 나눠서 붙어요. 근데 벽 쌓지 말고, 서로 넘나들어도 돼요."
역할 카드를 채워 벽에 붙입니다. 이름을 적는 순간 "내 일"이 생겨요.
팀 이름: ____________________ 우리가 만들 기능(한 줄): ____________________ PM : ______ (역할: 일정·할 일 챙기기, 스탠드업 진행) 기획·디자인 : ______ (역할: 기획서·화면 설계 주도, 스펙 전달) 프론트엔드 : ______ (역할: React 화면 구현) 백엔드 : ______ (역할: Spring Boot API 구현) 우리 팀 규칙 3가지: 1. ____________________ 2. ____________________ 3. ____________________ 소통 방법(예: 채팅방 / 보드): ____________________
퇴근 전 각자 한 문장으로 답하게 하세요.
스탠드업 (PM 진행) — 각자 어제 한 것 / 오늘 할 것 / 막힌 것을 30초씩. 오늘은 기획서·화면 설계가 목표라는 걸 PM이 선언합니다. (아침 기본기 강의는 이번 주 없음 — 프로젝트 작업으로 대체)
"기획서는 어렵게 쓰는 게 아니에요. 나중에 우리끼리 딴소리 안 하려고 미리 정해 두는 메모예요. '어? 이거 만들기로 했었나?' 이걸 막아줘요."
"제일 중요한 칸은 안 만들 것 칸이에요. 욕심내면 한 주에 절대 못 끝내요. '이번 주엔 여기까지만' 하고 선을 긋는 것도 실력이에요. 우리 회사 슬로건이 '고객과 함께 더 나은 세상을 만들어 나가는 기업'인데, 그 시작이 이렇게 작은 기능 하나를 제대로 끝내는 거예요."
디자이너에게: "○○님이 이 문서 주인이에요. 개발자들이 헷갈리면 ○○님한테 물어보게 될 거예요."
기획서 한 장을 이 틀로 완성합니다. 문서 도구(노션·구글 문서 등) 하나에 함께 씁니다.
기능 이름: ____________________ 1. 배경 / 왜 만드나 ____________________ 2. 누가 쓰나 (대상 사용자) ____________________ 3. 사용자 시나리오 (쓰는 흐름) ① 사용자가 ____ 한다 ② 그러면 화면에 ____ 이 보인다 ③ 사용자가 ____ 하면 ____ 된다 4. 이번 주에 만들 것 (범위) - ____________________ 5. 이번 주에 안 만들 것 (비범위) - ____________________ 6. 성공 기준 - ____________________
"화면 설계는 처음부터 예쁘게 그릴 필요 없어요. 네모랑 글씨면 충분해요. '여기 목록이 있고, 위에 추가 버튼, 각 줄에 마감일 뱃지' 이렇게요."
"개발자 셋은 그림 보면서 계속 질문해요. '이 버튼 누르면 저장돼요? 어디에 저장돼요?' 이 질문이 내일 API 설계로 바로 이어져요. 디자이너랑 개발자가 지금 대화를 많이 할수록 나중에 덜 헤매요."
화면 카드를 화면 수만큼 만듭니다. 개발자가 붙는 "데이터 메모" 칸이 핵심이에요.
화면 이름: ____________________ (예: 할 일 목록 화면) 이 화면에 보이는 것: - ____________________ (예: 할 일 목록) - ____________________ (예: [+ 추가] 버튼) - ____________________ (예: 각 항목의 마감일 뱃지) 누르면 일어나는 일: - [____] 버튼 → ____________________ 개발자 데이터 메모 (이 화면이 서버에서 받아야 할 것): - ____________________ (예: 할 일 제목, 마감일)
오후 마무리로 팀에게 물어보세요.
스탠드업 (PM 진행) — 30초씩 3가지. 어제 화면 설계에서 남은 질문이 있으면 오늘 API 설계로 넘겨 해결한다고 정리합니다.
"API가 어려운 말 같죠? 쉽게 생각해요. 식당에서 주문서랑 나온 음식이에요. 화면이 '할 일 목록 주세요' 하고 주문서(요청)를 보내면, 서버가 목록(응답)을 내주는 거예요."
"이 표를 지금 같이 정해 두면, 프론트 맡은 사람이랑 백엔드 맡은 사람이 따로 앉아서도 같은 걸 만들 수 있어요. '나는 이 주소로 보낼게' '나는 이 주소로 받을 준비할게' 이렇게 약속이 되니까요."
API 명세 표를 동작마다 한 줄씩 채웁니다. 우리 스택은 웹=React, 서버=Spring Boot(Java)라는 걸 기억하세요.
동작 방식 주소(URL) 보내는 것 받는 것 -------- ---- ---------------- ----------- ----------------- 목록 보기 GET /api/todos (없음) 할 일 배열 할 일 추가 POST /api/todos 제목, 마감일 추가된 할 일 할 일 삭제 DELETE /api/todos/{id} (없음) 성공 여부 응답 예시(JSON) — 목록 보기: [ { "id": 1, "title": "청소하기", "dueDate": "2026-07-20" }, { "id": 2, "title": "숙제하기", "dueDate": "2026-07-18" } ]
표를 다 채운 뒤 확인하세요.
"이제 큰 덩어리를 손에 잡히는 작은 카드로 쪼갤 거예요. '할 일 기능 만들기'는 너무 커요. '목록 화면 뼈대 만들기', '추가 버튼 붙이기', '서버에 저장 API 만들기'처럼 하루 안에 끝날 크기로 잘라요."
설계 리뷰에서 (격려 톤): "지금부터 제가 몇 가지 물어볼 텐데, 틀렸다고 지적하는 게 아니에요. 여러분이 놓친 게 있으면 지금 찾는 게 훨씬 이득이라서 그래요. 잘 만들었어요, 여기서 한 걸음만 더 봐요."
칸반 보드를 벽이나 노션/트렐로 같은 도구에 만들고, 카드를 채웁니다.
[ 할 일 ] [ 하는 중 ] [ 끝 ] ---------- ---------- ---------- 카드 한 장 형식: 제목 : ____________________ (예: 목록 화면 뼈대 만들기) 담당 : ______ 크기 : 반나절 / 하루 메모 : ____________________ (예: 화면 카드 1번 참고)
멘토가 리뷰 때 이 질문들로 설계 구멍을 확인합니다.
스탠드업 (PM 진행) — 오늘부터는 "오늘 할 것"을 보드 카드 이름으로 말합니다. 예: "저는 '목록 화면 뼈대' 카드 잡을게요." 카드를 '하는 중'으로 옮기며 시작해요.
npm run dev, 서버 기동) 먼저 확인."드디어 코드예요! 근데 오늘 목표는 '완성'이 아니라 '시작해서 굴러가게'예요. 화면에 목록이 딱 하나라도 뜨면 대성공이에요."
"막히는 건 당연해요. 규칙 하나만 지켜요 — 15분 넘게 혼자 못 풀면 손 드세요. 오래 붙들고 있는 게 멋진 게 아니라, 빨리 물어보고 앞으로 가는 게 프로예요. 옆 사람이랑 화면 같이 보면서 해도 좋아요."
디자이너에게: "○○님은 화면이 설계대로 나오는지 봐 주고, 개발자가 스펙을 헷갈려 하면 짚어 주세요. 여유가 되면 간단한 스타일도 손대 보고요."
오늘의 최소 목표(각 역할) — 완벽하지 않아도 됩니다. "한 조각이라도 화면/서버에서 돌아간다"가 기준입니다.
GET /api/todos가 200으로 응답한다(내용은 가짜여도 OK).스탠드업 (PM 진행) — 30초씩 3가지에 더해, PM이 보드를 보며 "지금 끝난 카드 / 남은 카드 개수"를 숫자로 알려 줍니다. 오전은 남은 카드를 조금 더 밀고, 오후는 점검·발표라고 안내합니다.
진행률 카드를 채워 오후 발표에 씁니다. "계획 대비 실행"이 이번 주 평가 포인트 중 하나예요.
전체 카드 수 : ______ 개 끝낸 카드 수 : ______ 개 진행률 : ______ % (끝낸 ÷ 전체 × 100) 지금 실제로 되는 것 (데모 가능): - ____________________ 아직 안 되는 것 (다음 주로): - ____________________ 계획과 달라진 점 / 배운 것: - ____________________
"일주일 동안 정말 많은 걸 했어요. 아이디어에서 시작해서 기획서, 화면, API, 보드, 그리고 실제로 돌아가는 코드까지요. 아직 다 안 됐어도 괜찮아요. 진짜 개발은 원래 다음 주로 이어져요."
"회고는 잘잘못 따지는 자리가 아니에요. '이건 좋았으니 계속하자, 이건 아쉬웠으니 바꿔보자'를 찾는 자리예요. 특히 서로한테 고마웠던 점을 꼭 말해 주세요. 같이 일하는 힘이 거기서 나와요."
KPT 회고를 각자 적고 벽에 붙인 뒤, 팀이 함께 읽습니다.
Keep (좋았던 것, 계속할 것) - ____________________ Problem (아쉬웠던 것, 힘들었던 것) - ____________________ Try (다음 주에 새로 해볼 것) - ____________________ 이번 주 나의 한마디: - 내가 팀에 기여한 것: ____________________ - 팀원 ○○ 덕분에 좋았던 것: ____________________
멘토는 회고를 들으며 이번 주 평가 포인트를 관찰·기록합니다.
다음 주 예고 — 8주차 · 프로젝트 완성 & 최종 발표. 이번 주에 만든 기능을 끝까지 다듬어 완성하고, 데모와 함께 최종 발표로 8주 수습 과정을 마무리합니다.