Design Thinking 8단계 기반 캡스톤. 중간/기말고사 없음. 3회 발표로 평가.
수업: 19:00~22:00 (5404) · 3시간 블록 = 강의 40분 / 실습 80분 / 코칭·공유 60분

15주 지도

한 줄에 두 가지가 함께 있습니다. 수업 시간에 다루는 것과, 그 수업이 성립하기 위해 학생이 미리 만들어 와야 하는 것입니다.

원칙: 수업 시간은 데이터를 가지고 판단하는 시간, 데이터 수집은 과제.
인터뷰·사용성 테스트·구현은 교실 밖에서만 가능하고, 코칭·의사결정·워크샵은 교실 안에서만 가능합니다.

운영 노트

위 표의 주차 문서는 수강생이 보는 자료입니다.
수업을 진행하는 데 필요한 것 — 수업 전 확인, 진행 대본, AI 함정 시연 방법, 개입 기준, 위험 신호, 기록해 둘 것 — 은 주차별 운영 노트에 따로 있습니다.

1주 · 2주 · 3주 · 4주 · 5주 · 6주 · 7주 · 8주 · 9주 · 10주 · 11주 · 12주 · 13주 · 14주 · 15주

제출 규칙

제출 경로는 두 가지입니다. 무엇을 어디에 내는지 헷갈리지 않게 아래 표를 기준으로 하세요.

문서는 제출 페이지 하나로 모입니다. 저장소는 코드와 작업 이력을 담습니다.

워크샵형 수업은 재료가 없으면 성립하지 않습니다. 사전 제출물이 없으면 수업 시간에 그 재료부터 만들어야 하며, 그만큼 코칭 시간을 잃습니다.

개인 저장소

이 과목은 특정 서비스를 요구하지 않습니다. GitHub·GitLab·학내 Git 서버 중 무엇이든 되고, 계정을 만들 수 없거나 네트워크가 막힌 경우를 위한 대체 경로도 있습니다. 1주차에 각자 결정하세요.
→ 저장소 운영 방식 선택 가이드
→ GitHub 협업 × AI 사용 가이드 — 9주차부터 매주 쓰는 흐름

경로가 달라도 아래 네 가지는 누구나 남겨야 합니다. 이것이 학습 목표이기 때문입니다.

1. 작업이 시간에 걸쳐 분포한 기록
2. 누가 무엇을 했는지 식별 가능
3. 변경이 다른 사람의 눈을 거친 흔적
4. 동작을 자동으로 확인하는 수단

project-<이름>/
├── README.md          # 프로젝트 소개, 설치/실행 방법
├── docs/              # 문서 산출물 (서식을 복사해 채움)
│   ├── 01-team-charter.md
│   ├── ...
│   ├── adr/           # ADR은 번호별 개별 파일
│   ├── interviews/    # 인터뷰 전사록
│   ├── retro/         # 주간 회고
│   ├── reviews/       # 리뷰 기록 (변경 요청을 쓸 수 없는 경우)
│   └── usability/     # 사용성 테스트 기록
├── logs/              # AI 사용 로그 (개인별 파일)
│   └── ai-log-홍길동.md
└── src/               # 소스 코드

이 저장소(강의 자료)는 weeks/ 학생용 · teaching/ 운영 노트 · templates/ 서식 · rubrics/ 평가 기준 · guides/ 가이드로 나뉩니다.

AI 사용 정책

AI 사용은 전면 허용합니다. 대신 3가지가 원칙입니다.

1. 내가 설명할 수 있게 — 내가 낸 코드와 문장은 스스로 설명할 수 있으면 됩니다. 발표 때 한 부분을 골라 설명을 청합니다. 설명할 수 있으면 그것으로 완성입니다.
2. 출처 검증 — AI가 알려준 사실·논문·서비스 사례는 원 출처를 직접 확인한 뒤에만 인용합니다. 확인되지 않은 인용이 발견되면 해당 산출물은 0점입니다.
3. 과정을 남기기 — 매주 개인 AI 사용 로그를 제출합니다. 무엇을 시켰고, 무엇으로 검수했고, 무엇을 반려했는지 남깁니다. 이 로그가 내가 한 일을 대신 말해 줍니다.

이 과목에서 여러분은 팀장이고 AI는 팀원입니다. 팀장이 하는 일은 코딩이 아니라 지시 · 검수 · 반려입니다.

금지 사항

• 인터뷰 대상자·사용자 피드백을 AI로 생성하는 행위 (실제 사람만 인정)
• 검증하지 않은 AI 생성 코드를 통합본에 반영하는 행위
• 리뷰 짝이 한 작업을 본인 기여로 기재하는 행위

자세한 내용은 AI 활용 가이드북에 있습니다.

저장소 운영 경로에 따라 "기록"의 형태가 달라집니다. 어떤 경로를 쓰든 동등한 근거로 인정하며, 경로 선택 때문에 점수에 유불리가 생기지 않습니다. → 저장소 운영 방식 선택 가이드

서식과 평가 기준

문서 산출물은 마크다운(.md)으로 씁니다. 외울 문법은 6개뿐이고 1주차에 15분 실습으로 다룹니다 → 마크다운 15분

✍️ 과제 제출 페이지 — 문서 산출물 21종 전부를 여기서 채워 바로 제출합니다.
항목마다 작성 방법과 예시가 붙어 있고, 제출 전에 체크리스트가 실시간으로 확인됩니다.
제출한 것은 제출함에서 다시 열어 수정할 수 있습니다(내가 낸 것만).
https://sw-project-839ae.web.app/forms-firebase.html

표는 손으로 그리지 않아도 됩니다. 목록으로 써도 되고, 집계용 표는 스프레드시트로 만들어 저장소에 넣고 링크만 걸어도 됩니다. AI에게 표 정리를 맡기는 것도 허용합니다 — 내용은 여러분이 판단하고 형식은 도구가 정리하는 것, 그 자체가 이 과목이 가르치는 분담입니다.

모든 서식에는 작성 예시가 함께 있습니다. 예시는 두 가지 프로젝트로 채워져 있습니다.

평가 기준은 학기 시작 시점에 공개됩니다.
1차 발표 · 2차 발표 · 최종 발표 · 상호 평가지

이 자료의 원본과 빌드

문서 원본은 마크다운이며, 사이트는 다음 명령으로 다시 만듭니다.

node sw-capstone-2026/site/build.js

문서를 추가할 때는 site/build.js 상단의 GROUPS 배열에 한 줄을 넣으면 됩니다. 외부 라이브러리 의존성은 없습니다.
슬라이드는 Marp 테마를 사용합니다.

이번 주에 남길 것 하나 — 이 과목이 아이디어 대회가 아니라 프로세스 훈련임을 이해하고, 다음 주 인터뷰를 실제로 나갈 수 있는 상태가 되는 것.

강의 ① 과목 구조와 기준 (25분)

다룰 내용

1. 과목 구조 — Design Thinking 8단계, 시험 없음, 발표 3회, 매주 사전 과제
2. 실패하는 캡스톤 4가지 패턴 - 주제가 너무 큼 → 12주차에 아무것도 완성 안 됨 - 사용자 없이 시작 → 만들고 나서 쓸 사람이 없음 - 막판 통합 → 11주차에 모듈이 안 붙음 - 문서를 학기 말에 몰아 씀 → 프로세스를 배우지 못함
3. 평가 방식 — 루브릭 3종을 오늘 배포하고 함께 읽습니다
4. AI 사용 정책 — 전면 허용, 대신 내가 설명할 수 있게·출처는 직접 확인·과정을 남기기

핵심

"AI 사용은 막지 않습니다. 대신 여러분이 설명하지 못하는 것은 없는 것으로 칩니다."

이 기준은 15주 내내 동일하게 적용됩니다. 세 번의 발표에서 저장소의 코드를 한 부분 골라 설명을 청합니다. 설명할 수 있으면 그것으로 완성입니다.

이번 주 AI 함정 시연 — 자신 있게 틀리기

수업 중에 AI에게 존재하지 않는 것을 함께 물어봅니다. 우리 학과 교과목 코드나 가상의 라이브러리 함수 같은 것이면 됩니다. AI가 망설임 없이 그럴듯한 답을 내놓는 장면을 함께 봅니다. 확신의 강도와 정확도는 아무 관계가 없습니다.

강의 ② AI를 팀원으로 다루는 법 (20분)

이 과목의 프로젝트 구조

개인 프로젝트입니다. 그런데 혼자 하는 것은 아닙니다.

팀장이 하는 일은 코딩이 아닙니다. 지시하고, 검수하고, 반려하는 것입니다.
이 과목이 평가하는 것도 코딩량이 아니라 이 세 가지입니다.

주의

세 번째가 없으면 팀장이 아니라 전달자입니다. 받은 것을 그대로 붙여넣는 일은 누구나 합니다.

또한 팀장이므로 모든 영역을 직접 맡습니다. "나는 프론트만"이 불가능한 구조이고, 그게 이 과목이 개인 프로젝트인 이유입니다.

① 지시 — 지시가 부실하면 결과도 부실합니다

사람 팀원은 지시가 부실하면 되묻습니다. AI는 되묻지 않고 그냥 만듭니다.
그래서 결과가 나쁘면 대개 팀원이 아니라 지시가 나빴던 것입니다.

→ AI 활용 가이드북 「패턴 1. 맥락 먼저」 · 「패턴 2. 인수조건 주입」

② 검수 — 무엇으로 확인할지를 먼저 정합니다

핵심

검수 기준은 지시 전에 정하세요. 받은 다음에 정하면 이미 그 결과에 설득당한 뒤입니다.

③ 반려 — 이 과목이 실제로 보는 것

반려는 AI가 틀렸을 때만 하는 것이 아닙니다.

세 번째를 기억하세요. 이 과목의 기준은 15주 내내 같습니다 —
설명하지 못하는 것은 없는 것으로 칩니다. 설명 못 하는 코드는 그 자리에서 반려 대상입니다.

매주 AI 사용 로그에 반려 최소 1건을 적습니다.
반려 기록이 여러분이 판단했다는 거의 유일한 흔적이고, 15주차 개인 평가가 보는 것도 그것입니다.

AI 팀원이 사람 팀원과 다른 세 가지

주의

혼자 + AI의 가장 큰 위험은 「이해하지 않은 채 진도가 나가는 것」입니다.
사람 팀원에게는 설명해야 해서 강제로 이해하게 됩니다. AI는 설명을 요구하지 않습니다.
그래서 이 과목은 발표마다 코드를 무작위로 골라 설명을 청합니다. 그게 안전장치입니다.

실습 파트 (65분)

① 마크다운 15분 (15분)

이 과목의 문서 산출물은 마크다운으로 씁니다. 마크다운 15분을 화면에 띄우고 함께 봅니다.

외울 것은 6개뿐입니다 — 제목 #, 목록 -, 굵게 **, 체크박스 - [ ], 코드 백틱 3개, 링크 []().

왜 배우는가 — AI가 내놓는 답, 저장소 README, 이슈 본문, 코딩 도구 설정 파일이 전부 마크다운입니다. 이 수업에서 안 배워도 매일 마주칩니다.

부담은 갖지 않아도 됩니다. 표는 스프레드시트로 내도 되고, AI에게 정리시켜도 됩니다. 형식과 씨름하는 시간은 이 과목에서 배울 것이 아닙니다.

② 프로젝트 계획서 작성 (30분)

프로젝트 계획서 서식을 채웁니다. 방금 배운 마크다운을 바로 쓰는 첫 문서입니다.

먼저 자신 있는 것 / 배우고 싶은 것을 한 줄씩 적게 합니다. 부풀리지 않는 편이 학기 내내 도움이 됩니다.
가장 중요한 항목은 목표 수준(A/B/C) 과 6. AI 사용 기준 입니다. 방금 배운 지시·검수·반려를 본인 기준으로 옮겨 적는 칸입니다.

「2. 탐색 영역」은 지금 비워둡니다. 오늘 마지막 워크샵에서 정한 뒤 채워서 제출합니다.

목표 수준은 솔직하게 고르게 합니다. 여기서 B를 고르고 주당 3시간만 쓰면, 손해를 보는 사람은 본인뿐입니다.
A를 고르는 것은 부끄러운 일이 아닙니다. 고르고 지키는 것이 이 과목이 보는 것입니다.

주의

「스스로에 대한 기준」을 반드시 채웁니다. 혼자 하면 진도가 밀려도 말려줄 사람이 없습니다. 무엇을 언제 줄일지 오늘 정해두지 않으면 12주차에 끌려갑니다.

③ 제출 경로와 도구 (20분)

제출 경로는 두 가지입니다. 오늘 둘 다 열어 확인합니다.

주의

오늘 제출 페이지 로그인을 확인합니다. 제출하려면 Google 계정 로그인이 필요합니다.
로그인하면 작성자 이름이 계정에서 자동으로 채워지고, 내가 낸 것만 고치거나 지울 수 있습니다.
프로젝트 계획서 제출이 첫 실습이므로, 그 자리에서 전원 로그인이 되는지 확인합니다.

제출함은 같은 수업 구성원이 함께 보는 공간입니다. 남의 제출물은 열어보기만 한다는 것도 오늘 규칙으로 정합니다.

• 저장소 운영 경로 결정 — 저장소 운영 방식 선택 가이드를 함께 읽고 개인별로 A/B/C 중 선택
• 개인 저장소 생성 후, 리뷰 짝이 볼 수 있는지 확인
• docs/ logs/ src/ 폴더 구조 생성
• AI 코딩 도구 설치 — 학기 내내 쓸 것 하나를 정합니다 (도구를 옮겨 다니면 로그가 흩어집니다)
• 첫 제출: 과제 제출 페이지에서 프로젝트 계획서를 제출하는 것까지 오늘 안에 끝내기

이 과목은 특정 서비스를 요구하지 않습니다. 계정을 만들 수 없거나 학교 네트워크에서 막히는 경우 1주차에 확인하고 경로 B로 정합니다. 그대로 두면 기여가 학기 내내 남지 않아, 15주차 개인 평가에 반영하기 어렵습니다.

탐색 영역 확정 + 인터뷰 설계 워크샵 (70분)

주의

이 워크샵을 2주차로 미루면 안 됩니다. 인터뷰 방법을 2주차에 다루면 인터뷰를 해 올 시간이 없고, 2주차 수업이 통째로 비게 됩니다.

탐색 영역 확정 (10분)

인터뷰를 설계하려면 무엇에 대해 물을지가 먼저 정해져야 합니다. 오늘 정하는 것은 만들 것이 아니라 살펴볼 영역입니다.

정하는 순서

1. 후보를 3개 적습니다 - 관심 있는 영역 중에서 고르되, "내가 다음 주에 만날 사람이 한 명은 떠오르는가" 를 통과한 것만 적습니다
2. 후보마다 그 사람을 이름이나 관계로 함께 적습니다 (예: "같은 과 선배 김○○") - 막연히 "대학생"은 안 됩니다. 연락처를 아는 사람이어야 합니다
3. 사람이 안 떠오르는 후보는 지웁니다 — 인터뷰를 못 하면 그 영역은 진행할 수 없습니다
4. 남은 것 중 가장 궁금한 하나를 고릅니다
5. 고른 영역에서 만날 3명이 채워지는지 확인합니다 - 안 채워지면 2순위 후보로 바꿉니다. 다음 주까지 3명을 실제로 만나야 합니다

핵심

옆 사람과 겹쳐도 괜찮습니다. 같은 영역을 봐도 만나는 사람이 다르면 나오는 것이 다릅니다.
오히려 3주차에 서로의 인사이트를 비교할 수 있어 도움이 됩니다.

주의

여기서 해결책을 정하면 인터뷰가 망가집니다. 만들 것을 정해놓고 나가면 질문이 전부 "그거 필요하시죠?"가 되고, 사용자는 예의상 그렇다고 답합니다. 그 데이터로는 3주차 문제 정의를 쓸 수 없습니다.

핵심

영역은 3주차까지 바뀔 수 있습니다. 인터뷰에서 전혀 다른 것이 나오면 그쪽으로 옮기면 됩니다. 오늘 정하는 것은 다음 주에 누구를 만날지입니다.

확정한 영역은 프로젝트 계획서의 2. 탐색 영역에 적어 제출합니다.

강의 ① 질문을 만드는 다섯 가지 방식 (12분)

해결책을 묻지 말고 경험을 물어라.

좋은 질문은 감각으로 나오지 않습니다. 다섯 가지 형태를 조합해 만듭니다.

쓰는 순서가 있습니다.

순차적 경험 →  감정  →  이유
   (무엇을)   (어떻게 느꼈나)  (왜)

「또」와「구체화」는 순서가 없습니다. 답이 얕다 싶은 어디에든 끼워 넣습니다.

핵심

「또」 질문 하나가 답변 항목을 두 배로 늘립니다. 사용자는 첫 대답에서 가장 무난한 것 하나만 말합니다. "또 있으세요?"를 세 번 물으면 세 번째에 진짜가 나옵니다.

• "왜요?"를 최소 5번 — 표면적인 대답 아래에 진짜 이유가 있습니다
• 침묵을 먼저 채우지 않기 — 3초를 기다리면 사용자가 채웁니다

강의 ② 어떻게 진행할 것인가 (8분)

진행 방식은 두 가지가 있습니다.

이 과목은 반구조화입니다. 우리는 아직 무엇을 물어야 하는지 모르기 때문입니다.

(준비된 질문)      언제 운동을 하시나요?
                        ↓ 답변을 듣고
(준비하지 않은 질문)  왜 식사하기 직전에 하시나요?

충분히 깊은 이야기가 나왔다고 판단되면 다음 항목으로 넘어갑니다. 질문지는 대본이 아니라 지도입니다.

진행할 때 지킬 세 가지

주의

가장 흔한 실패 — 이미 만들고 싶은 것을 정해놓고 인터뷰를 나가는 경우입니다. 그러면 질문이 전부 "그거 필요하시죠?"가 되고, 사용자는 예의상 그렇다고 답합니다. 그렇게 모은 데이터로는 3주차 문제 정의를 쓸 수 없습니다.

강의 ③ 말로 나오지 않는 것 보기 — 맥락 질의법 (10분)

맥락 질의법(Contextual Inquiry) 은 사용자가 실제로 그 일을 하는 현장에서 관찰과 면담을 함께 하는 방법입니다. 공감 단계에서 가장 많이 쓰는 방식입니다.

사람은 자기 행동의 절반을 설명하지 못합니다. 매일 하는 일일수록 더 그렇습니다. 그래서 하는 것을 옆에서 봅니다.

네 가지 원칙

준비물과 기록할 것

준비물   노트와 펜, 녹음기 또는 촬영 장비

기록     · 대상자의 역할, 업무, 주고받는 말, 그 조직의 문화
         · 물리적 공간과 환경
         · 대상자가 쓰는 물건·도구 (주제와 관련된 것만)
         · 핵심 행동, 그 사람 나름의 요령, 의도

도제관계 모델 (Master–apprentice) — 관계를 뒤집는 것이 핵심입니다.

• 대상자가 스승입니다. 자기 일을 하면서 「소리 내어 생각하기」를 합니다
• 우리는 견습생입니다. 중간중간 물어보며 배웁니다. 평가하러 간 것이 아닙니다

핵심

소리 내어 생각하기(Think Aloud) — 작업을 하면서 자신의 생각과 행동을 전부 말로 내뱉게 하는 방법입니다.

맥락 질의법이 맞지 않는 경우도 있습니다.

• 며칠·몇 주·몇 달에 걸친 장기 관찰이 필요할 때
• 보려는 상황이 드물게 일어날 때 (하루에 1분, 일주일에 한 번)
• 대상자가 수십·수백 명일 때

세 경우에 해당하면 인터뷰와 설문으로 대신합니다. 다만 이 과목의 주제 대부분은 맥락 질의법이 가능한 범위입니다.

실습 (25분)

인터뷰 스크립트 서식으로 1인당 질문지 하나를 오늘 완성합니다.

참고

질문지는 하나입니다. 방금 확정한 탐색 영역 하나에 대해 만듭니다.
인터뷰 3건을 모두 같은 질문지로 진행합니다.
사람마다 질문을 바꾸면 2주차에 전사록 3건을 나란히 놓을 수 없고, 공감지도를 만들 재료가 남지 않습니다.

1. 알아내려는 것을 질문 형태로 1~2개 적습니다
2. 심화 질문을 탐색 영역에 맞게 직접 만듭니다 (3개 이상)
3. 만든 질문마다 다섯 유형 중 무엇인지 표시합니다 - 「이유」 유형이 하나도 없으면 그 질문지는 사실 목록만 모으게 됩니다 - 「또」와 「구체화」를 넣을 지점을 최소 2군데 미리 정해 둡니다
4. 현장에서 볼 수 있는 주제라면 어디로 갈지를 정합니다 (맥락 질의법)

핵심

전사는 도구에 맡기세요. 다음 주 과제인 전사록 3건은 AI 전사 도구를 쓰면 됩니다.
손으로 받아 적으면 한 사람당 서너 시간이 걸리는데, 그 시간은 배우는 시간이 아닙니다.
여러분이 할 일은 관찰 노트와 인용 확인입니다. → AI 활용 가이드북

점검 (5분)

완성한 사람은 질문 2개를 소리 내어 읽습니다. 해결책을 묻는 질문이 섞여 있으면 그 자리에서 고칩니다.

다음 주 과제

[2주차 수업 전까지 · 제출]

1. 실제 사용자 3명 이상 인터뷰 (1인당 30~40분)
   - 리뷰 짝, 이 수업 수강생, 가족은 제외
   - 녹음 전 구두 동의를 받고, 그 동의 발언을 녹음에 포함할 것
   - 동의를 받을 때 «녹음 파일은 수업 담당 교수만 듣습니다»를 함께 알릴 것

2. 전사록 3건 → 과제 제출 페이지 «인터뷰 전사록» (대상자별 한 건씩)
   - 타임스탬프 포함
   - 녹음 파일도 함께 올립니다 (제출 페이지에서 바로 업로드)
   - 손으로 받아 적지 마세요. AI 전사 도구를 쓰고 결과를 붙여넣습니다
   - 검수는 «인상적인 발언 3개»로 뽑을 구간만 원본 음성과 대조하면 됩니다
   - 방법: AI 활용 가이드북 「부록 — 인터뷰 전사에 AI 쓰기」

3. 각 인터뷰마다 관찰 노트
   - 표정·망설임·한숨이 나온 지점
   - 말과 행동이 어긋난 지점
   - 인상적인 발언 3개 (그대로 인용)

마감: 수업 전날 자정 · 제출: 과제 제출 페이지
미제출자는 2주차 워크샵에 참여할 수 없습니다.

제출 형식

과제 제출 페이지에서 «인터뷰 전사록» 선택 — 대상자 1명당 한 건씩 제출합니다.

> 주차: 1주차 과제 · 작성일: 2026-XX-XX
> 작성: 김서연

# 인터뷰 P1

| 항목 | 내용 |
|---|---|
| 일시 | 2026-XX-XX 14:00 (35분) |
| 대상자 프로필 | 3학년, 최근 학기에 전공 중고 물건을 파는 사람 |
| 녹음 동의 | ☑ 구두 동의 확보 |

## 전사
[00:12:04] 진행자: 장소를 먼저 제안해 보신 적이 있으세요?
[00:12:09] P1: 음... (3초) 사실 거의 못 물어봤어요.
[00:12:14] 진행자: 왜요?
[00:12:16] P1: 제가 재촉하는 사람처럼 보일까 봐요.

## 관찰 노트
- 12:09에서 3초 망설임 → 정보가 없는 게 아니라 묻지 못하는 것
- "(웃음)"이 즐거움이 아니라 체념으로 들림

## 인상적인 발언 3개
1. "제가 재촉하는 사람처럼 보일까 봐요."
2. "몰랐죠. 마감 이틀 전에 알았어요."
3. "그래서 제가 다 했어요."

이번 주에 남길 것 하나 — 인터뷰 데이터에서 나도 예상 못 했던 것을 최소 3개 발견하는 것.

강의 파트 (30분)

참고

시연 자료가 따로 있습니다. 2주차 시연 — 인사이트 뽑기
전사록 3건 샘플부터 인사이트 10개까지 전 과정이 실제 문장으로 들어 있습니다. 강의 파트에서 이걸로 한 번 보여준 뒤 실습으로 넘어갑니다.

다룰 내용

1. 질적 코딩 — 발언을 잘라 라벨을 붙이고, 라벨을 묶어 주제를 만드는 절차
2. 요약과 인사이트의 차이 ← 이번 주 핵심

핵심 — 요약과 인사이트의 차이

좋은 인사이트에는 긴장(tension)이 있습니다. "A를 원하면서 동시에 B를 한다" 같은 모순. 모순이 없으면 그건 그냥 누구나 아는 말입니다.

이번 주 AI 함정 — 한국어 뉘앙스 오독

전사록 한 대목을 AI에게 감정 분류시켜 봅니다. 반어법·완곡어법·체념이 섞인 대목에서 거의 반드시 틀립니다.

"괜찮아요 뭐, 그냥 제가 하면 되니까" — AI는 이걸 긍정으로 분류합니다.
공감지도의 감정 칸을 AI 결과 그대로 채우면 안 되는 이유입니다. 분류는 시키되 판정은 직접 합니다.

실습 파트 (80분)

진행 순서

각 단계의 결과물이 어떤 모습이어야 하는지는 시연 자료에서 확인하세요.

1. (15분) 발언 카드화 — 전사록에서 인상적인 발언을 포스트잇 한 장에 하나씩. 최소 24장
2. (20분) 그룹핑 — 비슷한 것끼리 묶고 이름 붙이기. AI에게 같은 작업을 요청해 결과를 비교합니다
3. (25분) 공감지도 — 2번에서 내가 만든 분류를 그대로 칸으로 씁니다. 공감지도 서식에서 카드보드의 분류를 가져올 수 있습니다
4. (20분) 인사이트 10개 — 각 인사이트에 근거 인용을 반드시 붙이기

점검 항목

• 공감지도 칸에 내 추측이 들어가 있지 않은가 — 근거 없는 칸은 지웁니다
• 감정·생각을 적은 칸에 어느 발언에서 나왔는지가 붙어 있는가
• "놀라운가?" 체크가 3개 미만인 → 인터뷰를 겉핥기로 읽은 것입니다. 전사록을 다시 읽습니다

교차 리뷰 (60분)

둘씩 짝지어 공감지도를 서로 설명합니다. 듣는 사람은 딱 두 가지만 묻습니다.

1. "그 인사이트의 근거가 어느 발언이에요?"
2. "그건 인터뷰 전에도 예상했던 거 아니에요?"

두 번째 질문에 답하지 못한다면 그 인사이트는 요약입니다. 전사록으로 돌아가 다시 파고듭니다.

다음 주 과제

[3주차 수업 전까지]

1. 개인 과제 — 문제 정의 후보 3개씩 (각자 3개)
   - 인사이트에 근거해야 함. 아이디어가 아니라 '문제'를 쓸 것
   - 형식: "[구체적 사용자]는 [무엇]이 필요하다. 왜냐하면 [인사이트]이기 때문이다."
   - 제출: 개인 저장소 이슈로 각자 등록

2. 과제 — 부족한 인터뷰 2건 보완
   - 2주차에 새로 생긴 질문을 가지고 다시 만날 것

3. 개인 과제 — AI 사용 로그 1주치
   - 「반려 기록」 항목 필수 (최소 1건)

마감: 수업 전날 자정

제출 형식

이슈 트래커(또는 칸반 보드) — 제목 [문제후보] 홍길동 1. 후보를 서로 보고 토론해야 하므로 보드에 올립니다. 서식은 과제 제출 서식.

## 후보 1

**POV**
이번 학기에 처음 중고 물건을 팔아본 3학년 학생은
상대에게 계속 묻지 않고도 만날 장소와 시간이 좁혀지는 방법이 필요하다.
왜냐하면 먼저 장소를 제안하는 행위가 재촉처럼 보일까 봐
묻지 못한 채 혼자 불안해하다가 결국 혼자 다 떠안게 되기 때문이다.

**근거 인용:** "제가 재촉하는 사람처럼 보일까 봐요." (P1)
**이 문제를 겪지 않는 사람:** 이미 서로 아는 사이. 관계 비용이 낮아 그냥 물어봄
**해결책 단어 점검:** 앱·플랫폼·AI·자동화 포함 여부 ☑ 없음

이번 주에 남길 것 하나 — 해결책 단어가 하나도 없는 문제 정의 문장을 갖는 것. 이 과목에서 결과가 갈리는 첫 번째 지점입니다.

강의 파트 (40분)

참고

시연 자료가 따로 있습니다. 3주차 시연 — 문제 정의
POV를 세 번 고쳐 쓰는 과정, AI가 쓴 PRD와 직접 다시 쓴 PRD 비교가 나란히 들어 있습니다.

다룰 내용

1. POV 문장 — [사용자]는 [니즈]가 필요하다. 왜냐하면 [인사이트]이기 때문이다.
2. HMW 질문 — 범위 조절이 전부입니다
3. 문제 → 요구사항 번역 — 기능/비기능, 사용자 스토리와 인수조건
4. 스코프 경계 — "하지 않는 것" 목록

핵심

① 타깃 사용자는 "상황"까지 써야 합니다.

② POV에 해결책 단어(앱·플랫폼·AI·자동화)가 들어가면 실패입니다. 내 문장에서 그 단어를 찾아 지우고, 지운 뒤에도 문장이 성립하는지 확인합니다.

③ HMW 범위 조절

④ "하지 않는 것" 목록이 비어 있으면 12주차에 무너집니다. 로그인·결제·관리자 페이지·추천 알고리즘 — 이 중 정말 필요한 것이 몇 개인지 지금 따집니다.

이번 주 AI 함정 — 일반론으로 도피

인터뷰 데이터 없이 PRD를 시키면, 어느 프로젝트에 갖다 붙여도 되는 문서가 나옵니다.
인용을 넣기 전과 후를 나란히 놓고 봅니다.

지시에 내 인터뷰 인용이 들어가야 내 문서가 나옵니다. → 「패턴 1. 맥락 먼저」

실습 파트 (80분)

진행 순서

각 단계의 결과물이 어떤 모습이어야 하는지는 3주차 시연 자료에서 확인하세요.
2주차 시연의 3조가 그대로 이어집니다 — 인사이트에서 POV·HMW·PRD·스토리까지 실제 문장으로 들어 있습니다.

1. (20분) 후보 3개 → 1개 — 내 후보를 나란히 놓고 근거 강도로 고릅니다. 인용이 몇 명에게서 나왔는지가 기준입니다
2. (20분) POV·HMW 확정 — 문제 정의서 작성
3. (20분) PRD 초안 — AI로 PRD 골격 생성 후, §2 배경과 §4 시나리오는 직접 다시 쓰기
4. (20분) AI 반박 실습 ← 이번 주 필수

AI 반박 실습 (필수)

각자 자기 문제 정의를 AI에게 넣고 이렇게 요청합니다.

이 문제 정의의 약점을 3가지 지적해줘.
특히 '우리가 근거 없이 가정하고 있는 것'을 찾아줘.
좋게 말하지 말고 냉정하게 평가해줘.

그리고 수용한 것 1개 / 반려한 것 1개와 각각의 이유를 문서에 남깁니다.
반려한 이유를 쓰지 못하면 아직 그 문제를 자기 것으로 만들지 못한 것입니다.

개인별 코칭 (50분)

1인당 6~7분씩 아래 네 질문을 받습니다. 미리 답을 준비해 오세요.

1. 이 사용자를 몇 명이나 실제로 만났나요?
2. 이 문제를 겪지 않는 사람은 누구예요? 왜 안 겪죠?
3. 지금 사용자들은 이 문제를 어떻게 버티고 있나요?
4. 15주차에 무엇이 관찰되면 성공한 건가요?

4번에 "많은 사람이 좋아하면요"는 답이 아닙니다. 무엇이 몇 번 관찰되면 성공인지로 씁니다.

다음 주 과제

[4주차 수업 전까지]

1. 개인 과제 — 아이디어 30개
   - 3주차에 고른 HMW 질문에 대한 답
   - 실현 가능성은 아직 따지지 말 것. 발산 단계입니다

2. 과제 — 유사·경쟁 서비스 5건 조사표
   - 무엇이 있고 / 어떻게 쓰이고 / 왜 부족한가
   - AI가 알려준 사례는 반드시 원 출처 URL을 직접 열어 확인할 것
     확인하지 않은 사례를 쓰면 해당 항목은 0점으로 봅니다

3. 과제 — 필요 기술 리스트업 (모르는 것 위주로)

4. 개인 과제 — AI 사용 로그

※ 4주차 수업에서 주제 승인 심사가 있습니다. 통과해야 5주차로 넘어갑니다.

제출 형식

과제 제출 페이지에서 «선행사례 조사표» 선택 — 5건을 한 건으로 제출합니다.

이번 주에 남길 것 하나 — 탈락시킨 대안과 그 이유를 말할 수 있는 상태로 주제를 확정하는 것.
이번 주는 게이트입니다. 여기를 통과하지 못하면 5주차로 넘어가지 않습니다.

강의 파트 (30분)

다룰 내용

1. 발산 규칙 — 비판 금지, 양이 질을 만든다, 남의 아이디어에 올라타기
2. 수렴 기준 — 임팩트 / 실현 가능성 / 우리만의 차별점
3. 출처 검증 3단계 — 출처를 묻는다 → 직접 연다 → 원문을 확인한다

핵심

발산은 AI, 수렴은 사람.
AI는 30개를 5분에 만듭니다. 하지만 "내 프로젝트이 15주 안에 할 수 있는 것"은 AI가 모릅니다.

첫 번째 아이디어를 그대로 가져가기 쉽습니다. 탈락 대안을 설명하지 못하면 그것은 선택이 아니라 관성입니다.

이번 주 AI 함정 — 없는 출처 만들기

"이 분야 논문 3편과 링크"를 시키면 링크가 나옵니다. 그 링크를 실제로 클릭해 봅니다.
열리지 않는 링크가 나오는 순간이 이번 주의 요점입니다.

주의

URL은 직접 엽니다. 열어보지 않은 사례는 조사표에서 그 자리에 지웁니다.

실습 파트 (60분)

진행 순서

1. (15분) 발산 추가 — AI로 대안을 더 뽑되 조건을 겁니다: "내가 생각 못 했을 접근으로 10개"
2. (15분) 그룹핑 — 40~60개를 성격별로 묶기
3. (20분) 수렴 — 임팩트/실현가능성 2×2 매트릭스에 배치 → 후보 3개
4. (10분) 선정 근거서 — 왜 이것이고, 왜 나머지 둘이 아닌가

점검 항목

• 후보 3개가 서로 다른 접근인가 (같은 것의 변형 3개면 발산 실패)
• 선정 근거가 "이게 제일 재밌어서"가 아닌가
• 15주 안에 만들 수 있는 크기인가

주제 확정 심사 (60분 · 1인당 10분)

각자 3분 발표하고 7분간 질의를 받습니다. 아래 질문 중 3~4개를 받습니다 — 어느 것이 나올지는 모릅니다.

발표 필수 항목

1. 문제 정의 (POV 한 문장)
2. 선정한 해결 방향
3. 탈락시킨 대안 2개와 탈락 이유
4. 15주차 성공 지표

심사 질문 (1인당 3~4개)

판정

보류는 벌이 아니라 보호입니다. 여기서 넘어간 문제는 13주차에 훨씬 큰 비용으로 돌아옵니다.

교차 검토 (20분)

혼자 하는 프로젝트일수록 외부 시선이 귀합니다. 옆 사람 주제를 반박하는 것이 과제입니다.

반박은 이렇게 씁니다

핵심

반박을 잘 받는 것도 훈련입니다. 방어하지 말고 받아 적으세요. 여기서 막은 반박은 7주차 발표에서 그대로 다시 나옵니다.

다음 주 과제

[5주차 수업 전까지]

1. 사용자 플로우 초안
   - 사용자가 진입해서 목표를 이루기까지의 화면 이동 순서

2. 필요 화면 목록
   - 화면 이름 + 그 화면의 목적 한 줄

3. 참고 서비스 UI 분석 3건
   - 실제로 써보고 캡처할 것. 좋았던 점/나빴던 점 각 1개

4. 개인 과제 — AI 사용 로그

마감: 수업 전날 자정

제출 형식

과제 제출 페이지에서 «플로우·화면 목록» 선택 — 핵심 경로·화면·빈 상태를 함께 제출합니다.

진입 → 거래 열기(링크 공유) → 약속판 → 거래 등록 → 약속판 확인

이번 주에 남길 것 하나 — 화면으로 설명할 수 있는 상태가 되는 것. 말로 설명하던 것을 눈에 보이게 만드는 주입니다.

강의 파트 (30분)

다룰 내용

1. 저충실도 → 고충실도 — 왜 손그림부터 시작하는가
2. 사용자 플로우 — 화면이 아니라 이동을 먼저
3. 정보구조 — 한 화면에 하나의 목표
4. 빈 상태·에러 상태 — 가장 자주 빠뜨리는 화면

핵심

싸게 만들고 빨리 버립니다. 공들여 만든 것은 못 버립니다. 그리고 못 버리면 사용자 피드백을 무시하게 됩니다.

빈 상태를 반드시 그립니다. 데이터가 하나도 없을 때, 로딩 중일 때, 에러일 때 — 가장 자주 빠뜨리는 이 세 화면이 13주차 라이브 데모에서 정확히 터집니다.

이번 주 AI 함정 — 맥락 유실

목업을 대화로 5~6턴 고치다 보면, 앞에서 정한 제약(사용자·화면 개수·톤)을 슬며시 잊고 다른 것을 만들어내는 지점이 옵니다.

대화가 길어지면 새 대화를 열고 맥락을 다시 넣습니다. 같은 대화에서 계속 고쳐 달라고 하는 편이 오히려 느립니다.

실습 파트 (80분)

진행 순서 — 3사이클 반복

1사이클을 종이로 하는 이유는, 도구를 먼저 잡으면 화면을 예쁘게 만드느라 흐름을 안 보기 때문입니다.

점검 항목

• 핵심 경로가 3~5화면 안에 끝나는가 (길면 문제 정의가 넓은 것)
• 빈 상태 화면이 있는가
• 목업이 3주차 사용자 시나리오와 일치하는가

상호 시연 (60분)

둘씩 짝지어, 아무 설명 없이 상대에게 목업을 조작합니다.

• 만든 사람은 한 마디도 하지 않습니다
• 조작하는 사람이 막히는 지점을 기록합니다
• 3분 뒤 역할을 바꿉니다

이것이 사용성 테스트의 축소판입니다. 13~14주차에 할 일을 지금 미리 해보는 것입니다.
"설명하고 싶은데 설명할 수 없는" 경험이 이 시간의 핵심입니다. 실제 사용자 앞에서도 똑같습니다.

다음 주 과제

[6주차 수업 전까지]

1. 목업으로 실사용자 3명에게 피드백 받기
   - 설명하지 말고 조작하게 할 것
   - 막힌 지점을 기록할 것 (감상 아님)

2. 기술 리스크 상위 2개 선정
   - "이게 안 되면 프로젝트가 무너진다" 순으로
   - 왜 불확실한지 한 줄씩

3. ★ 개발 환경 세팅 완료 (필수)
   - 리스크 2개와 관련된 API 키 발급, 계정 생성, 라이브러리 설치
   - 'Hello World' 수준이라도 실행되는 상태까지
   - 완료 스크린샷을 이슈에 첨부

4. 개인 과제 — AI 사용 로그

※ 3번을 안 해오면 6주차 수업(집중 코딩)에 참여할 수 없습니다.
   세팅은 수업 시간에 하는 일이 아닙니다.

제출 형식

과제 제출 페이지에서 «리스크 리포트» 선택 — 리스크 2개·환경 세팅·목업 피드백을 함께 제출합니다. 6주차 수업에서 검증한 결과는 같은 서식을 열어 채운 뒤 다시 제출합니다.

이번 주에 남길 것 하나 — "이건 된다"와 "이건 아직 모른다"를 구분할 수 있게 되는 것.
강의는 짧게, 코딩과 코칭에 시간을 쓰는 주입니다.

강의 파트 (25분)

다룰 내용

1. 가장 불확실한 것부터 죽여라 — 쉬운 것부터 하면 어려운 것이 12주차에 남습니다
2. 타임박싱 — 오늘 3시간 안에 답이 안 나오면, 그것 자체가 답(대안으로 전환)
3. AI 디버깅 3단 — 재현 → 최소화 → 가설

핵심

"고쳐줘"라고 하면 AI는 추측으로 코드를 바꿉니다. 그러면 원인을 모른 채 넘어가고, 같은 버그가 형태를 바꿔 다시 옵니다.

바로 코드를 고치지 말고, 먼저 이 에러가 발생할 수 있는 원인을
가능성 높은 순서로 3가지 알려줘. 그리고 각 가설을 확인하는 방법도.

2시간 규칙 — 같은 버그로 2시간 이상 AI와 씨름했다면 멈추고 수업 채널에 공유. 그 시점부터는 AI가 아니라 접근 방식이 틀린 것입니다.

이번 주 AI 함정 — 없는 함수 만들기

여러분이 쓰는 라이브러리의 사용법을 구체적으로 물어보면, 존재하지 않는 메서드나 옵션을 자신 있게 알려주는 경우가 흔합니다.

공식 문서와 나란히 놓고 대조합니다. 처음 쓰는 라이브러리일수록 그렇습니다.

집중 코딩 (100분)

시작 전 (5분)

각자 수업 채널에 한 줄로 선언합니다.

오늘 우리는 [___]가 가능한지 확인한다.
성공 기준: [___]가 화면/로그에 나오면 성공.

이 선언이 없으면 3시간 뒤 "뭔가 했는데 뭘 확인했는지 모르겠다"가 됩니다.

순회 코칭 (1인당 10~12분씩 2회전)

교수가 두 번 돌며 아래를 묻습니다. 미리 답을 준비해 두세요.

1회전 — 방향 점검

• 지금 만드는 게 리스크 검증인가요, 아니면 편한 기능인가요?
• 성공 기준이 관찰 가능한가요?

2회전 — 막힘 해소

• 2시간 규칙을 지키고 있나요?
• AI에게 뭐라고 시켰는지 프롬프트를 그대로 보여주세요 — 막히는 경우는 대개 맥락이 빠져 있습니다

결과 공유 (40분)

각자 3분씩, 성공/실패 상관없이 공유합니다.

"안 된다는 것을 알아낸 것"도 성과입니다. 실패한 스파이크는 실패가 아니라 가장 값싼 학습입니다. 이것을 공개적으로 인정해야 13주차까지 정직한 보고가 이어집니다.

다음 주 과제

[7주차 1차 발표 준비]

1. 발표자료 (10분 분량)
   필수 포함:
   - 우리가 만난 실제 사용자와 인사이트
   - 문제 정의(POV) — 왜 이 문제인가
   - 아이디어 선정 과정과 탈락시킨 대안
   - 프로토타입 시연 (슬라이드 설명 아님)
   - 기술 리스크: 검증된 것 / 아직 불확실한 것

2. 데모 시나리오
   - 무엇을 어떤 순서로 보여줄지 대본

3. 리허설 1회 + 녹화 영상 제출
   - 10분 안에 끝나는지 실제로 재보세요

마감: 수업 전날 자정
※ 발표 후 코드/문서 무작위 선택 설명이 있습니다.

제출 형식

과제 제출 페이지에서 «발표 구성서» 선택 → 「1차 발표」 — 구성·데모 시나리오·리허설 기록을 제출합니다.

이번 주에 남길 것 하나 — 각자 다음 8주를 어디에 쓸지 명확해진 상태로 나가는 것.
발표는 심사가 아니라 방향 교정입니다.

6명 개별 발표 기준입니다. 발표가 곧 개인 단위 확인이므로 별도 라운드를 두지 않습니다.

진행 방법

순서

1. 발표 10분 (8분에 1차 알림, 10분에 종료)
2. 동료 질문 2분 — 수강생이 먼저 묻습니다
3. 교수 질문 3분

발표자를 제외한 5명은 질문 1개씩을 미리 준비해 옵니다.

평가

• 1차 발표 루브릭으로 채점합니다
• 모든 수강생은 상호 평가지 A파트를 발표를 들으며 작성합니다
• 상호 평가는 평가자 이름을 지우고 발표자에게 전달됩니다

미리 알아두는 감점

질의응답

7번은 이 과목의 시그니처 질문입니다. 매 발표마다 최소 한 사람은 받습니다.
여러분은 팀장이고 AI는 팀원입니다. 무엇을 되돌렸는지가 팀장으로서 한 일입니다.

교차 리뷰 (60분)

서면 리뷰에 담을 것은 셋입니다.

여기서 정한 수용·거부가 그대로 발표 피드백 반영 계획의 재료가 됩니다.

정리 (20분)

오늘 발표 전체에서 자주 나온 유형을 이름 없이 짚습니다. 아래 넷이 매 학기 반복됩니다.

다음 8주는 설계 → 구현 → 검증입니다. 특히 8·9주차가 남은 기간의 개발 속도를 결정합니다.

다음 주 과제

[8주차 수업 전까지]

1. 피드백 반영 계획서
   - 오늘 받은 지적 중 무엇을 수용하고 무엇을 거부할지
   - 거부한 것은 이유를 쓸 것 (수용만 있는 계획서는 반려)

2. 아키텍처 대안 3개 조사
   - AI에게 "우리 요구사항에 맞는 접근 3가지와 트레이드오프"를 시키고
   - 각 대안의 장단점 + 내 프로젝트 상황에서의 적합도를 정리
   - ※ 결정은 하지 말 것. 8주차 수업에서 함께 결정합니다

3. 저장할 데이터 항목 전수 목록
   - 화면에 보이는 것부터 역산해서 뽑을 것
   - 개인정보 해당 여부 표시

4. 개인 과제 — AI 사용 로그

마감: 수업 전날 자정

제출 형식

과제 제출 페이지에서 «피드백 반영 계획서» 와 «아키텍처 대안 조사» 를 각각 제출합니다.

발표 진행 규칙

• 타이머를 화면에 띄웁니다. 모두에게 같은 화면 기준으로 적용됩니다
• 발표 순서는 추첨입니다. 순서에 따른 유불리를 없애기 위한 것입니다
• 채점은 발표 직후 마무리됩니다

이번 주에 남길 것 하나 — "왜 그 기술을 선택했나요?"에 답할 수 있는 문서를 갖는 것.
15주차 발표에서 반드시 나오는 질문이고, 여기서 준비되지 않으면 그때는 늦습니다.

강의 파트 (40분)

다룰 내용

1. 아키텍처 = 결정의 묶음 — 그림이 아니라 결정입니다
2. 데이터 모델링 — 화면에서 역산하기, ERD
3. API 설계 — 경계를 먼저 정해야 병렬 작업이 됩니다
4. ADR 쓰는 법 — 대안 / 결정 / 포기한 것 / 언제 틀렸다고 알 수 있는가

핵심

① 결정에는 반드시 대가가 있습니다.

ADR에 "포기하는 것: 없음"이라고 썼다면 결정을 한 게 아니라 유일한 선택지를 받아적은 것입니다.

② 내 역량은 가장 중요한 제약입니다.
"이 언어를 써 본 적이 없다"은 부끄러운 게 아니라 핵심 설계 입력값입니다. ADR 배경에 솔직하게 씁니다.

③ AI는 대안 정리에 탁월합니다. 결정은 못 합니다.

AI에게 시킬 것: 대안 나열, 장단점 정리, 트레이드오프 비교
사람이 할 것: 우리 제약에서 무엇을 포기할지 결정

이번 주 AI 함정 — 동조 편향

이미 정한 스택을 AI에게 "이 선택 어때?"라고 물으면 대개 칭찬합니다. 정반대 선택을 제시하고 똑같이 물어도 칭찬합니다.

주의

AI는 반대하지 않습니다. 반대는 명시적으로 시켜서 받아야 합니다. → 「패턴 3. 반박 요청」

실습 파트 (80분)

진행 순서

1. (20분) 데이터 모델 — 화면 목록에서 역산해 ERD 초안
2. (20분) 아키텍처 결정 — 대안 3개를 놓고 토론. AI에게 반박도 요청하기
3. (25분) ADR 3건 작성 — ADR 서식
4. (15분) API 명세 초안 — 모듈 경계와 시그니처

ADR 필수 3건

점검 항목

• ADR에 대안이 2개 이상 있는가 (1개면 결정이 아님)
• "포기한 것"이 채워져 있는가
• "이 결정이 틀렸다는 것을 언제 알 수 있는가"가 있는가 ← 가장 많이 비워둡니다

설계 리뷰 (50분)

1인당 6분. 화면에 다이어그램을 띄우고 아래 네 질문을 받습니다.

1. 이 화면을 그리려면 어떤 데이터가 어디서 오나요?
2. A 모듈과 B 모듈은 무엇을 주고받죠? 그 형식이 정해졌나요?
3. 이 결정을 내리면서 무엇을 포기했나요?
4. 이 설계에서 가장 먼저 터질 것 같은 곳은?

2번에 답을 못 하면 11주차 통합에서 반드시 터집니다. 답이 막히면 그 자리에서 인터페이스를 종이에 적고 갑니다.

참고

다음 주부터 브랜치·변경 요청으로 작업합니다. GitHub 협업 × AI 사용 가이드를 미리 훑어보세요.

다음 주 과제

[9주차 수업 전까지]

1. 백로그 전체를 이슈로 등록 (15개 내외)
   ※ 이슈 트래커가 없으면 스프레드시트 칸반으로 대체 (저장소 가이드 참조)
   - 사용자 스토리 1개 = 이슈 1개
   - 이슈 제목: [US-03] 상대와 겹치는 시간 확인
   - 본문: As a / I want / So that + 인수조건 체크박스
   - 인수조건에는 반드시 예외·빈 상태 케이스를 1개 이상 포함

2. 저장소 세팅
   - 통합 브랜치 보호 (설정이 불가능하면 "직접 병합 금지"를 규칙으로)
   - 브랜치 전략 확정 (프로젝트 계획서에 적은 대로)
   - 이슈 라벨 생성: must / should / sprint-1,2,3

3. 개인 과제 — AI 사용 로그

※ 9주차 수업에서 CI를 구축합니다. 저장소가 비어 있으면 진행할 수 없습니다.

제출 형식

이슈 트래커(또는 칸반 보드) — 스토리 1개 = 이슈 1개. 서식 전문은 과제 제출 서식.

제목: [US-03] 상대와 겹치는 시간 확인

**As a** 중고 물건을 파는 사람,
**I want** 상대에게 직접 묻지 않고 서로 가능한 시간이 겹치는 구간 보기,
**So that** 재촉하는 것처럼 보이지 않으면서 만날 시간을 정할 수 있다.

## 인수조건
- [ ] Given 양쪽이 가능 시간을 3개씩 골랐고, When 약속판에 진입하면,
      Then 겹치는 시간이 이른 순서로 한 화면에 보인다.
- [ ] Given 겹치는 시간이 하나도 없으면, Then 다시 고르기 안내가 보인다.
- [ ] Given 작업이 0건이면, Then 빈 상태 안내와 추가 버튼이 보인다.

우선순위: Must · 추정: M · 의존성: US-01, US-02

이번 주에 남길 것 하나 — CI가 실제로 돌아가는 저장소를 갖는 것.
이 주가 남은 6주의 개발 속도를 결정합니다.

강의 파트 (40분)

다룰 내용

1. 백로그 분해 — L짜리는 쪼갠다
2. Definition of Done — 내가 정하는 "끝났다"의 기준
3. 브랜치·변경 요청·코드리뷰 — 리뷰가 형식이 되지 않으려면 → 이번 주부터 매주 쓰는 흐름입니다. GitHub 협업 × AI 사용 가이드를 함께 읽습니다
4. CI — 린트와 테스트 자동 실행

핵심

AI가 쓴 코드를 믿는 방법은 자동화된 검증뿐입니다.

이 문장이 9주차의 전부입니다. 이미 AI로 코드는 빠르게 만들어집니다. 문제는 그게 맞는지 확인할 방법이 없다는 것이고, 그 방법이 테스트와 CI입니다.

스토리를 쪼개는 능력 = AI를 잘 쓰는 능력임도 여기서 연결합니다.

• "쇼핑몰 만들어줘" → AI 실패
• 인수조건 3줄짜리 스토리 → AI 성공
• 즉, 9주차에 배우는 분해 능력이 10주차의 구현 속도를 결정합니다

이번 주 AI 함정 — 리뷰의 형식화

관점을 안 주고 코드 리뷰를 시키면 "좋습니다" 수준의 답이 옵니다.
인수조건 충족 / 예외 처리 / 보안 / 가독성 으로 관점을 나눠 시키면 실제 지적이 나옵니다.

리뷰도 지시입니다. 지시가 부실하면 리뷰도 부실합니다.

실습 파트 (80분)

① 스프린트 계획 (30분)

스프린트 계획 서식을 채웁니다.

주의

Sprint 1에서 레이어별 분업을 하면 안 됩니다. 화면을 다 만든 뒤 API를 붙이려 하면 11주차에 안 붙습니다. 얇더라도 관통하는 경로 하나를 먼저 뚫습니다.

② Definition of Done 정하기 (15분)

직접 씁니다. 최소 항목:

• 인수조건 충족 / 테스트 통과 / 자동 검증 통과 / 리뷰 짝 확인 / main 병합
• 내가 코드를 설명할 수 있음 ← 이 항목을 빠뜨리지 마세요

마지막 항목이 이 과목의 평가 기준이자, AI가 준 것을 반려하는 세 번째 이유입니다.

③ 자동 검증 구축 (35분) — 수업 중 동작까지

CI를 쓸 수 있는 경우

• 린트 + 테스트를 변경 요청에서 자동 실행
• 실패하면 병합 불가 설정
• 오늘 안에 초록불 한 번을 보게 하는 것이 목표입니다

CI를 쓸 수 없는 경우 (경로 B)

• scripts/check.sh (또는 check.ps1)에 린트 + 테스트를 묶는 스크립트 작성
• 병합 전 실행을 규칙으로 확정 → 프로젝트 계획서와 DoD에 명시
• 실행 결과를 리뷰 기록지에 붙여넣는 것까지 오늘 연습

CI가 강제하던 것을 규칙이 대신하는 것입니다. 배우는 내용은 같습니다.
다만 사람은 잊습니다. DoD 체크리스트에 반드시 넣으세요.

리뷰 연습 (50분)

리뷰 짝끼리 작은 변경을 하나씩 만들어 서로 리뷰합니다.

1. 한 사람이 사소한 기능을 변경 요청으로 올립니다 (일부러 예외 처리를 빼고) (변경 요청을 쓸 수 없으면 브랜치를 만들고 리뷰 기록지를 작성)
2. 짝이 리뷰합니다 — 먼저 AI에게 관점별 리뷰를 시킨 뒤, 그 결과를 보고 직접 판단해 코멘트
3. 올린 사람이 수정 → 병합
4. 역할을 바꿔 한 번 더

여기서 짚을 것: AI 리뷰는 사람 리뷰를 대체하지 않습니다. 사람 리뷰어가 사소한 것에 시간 쓰지 않게 해주는 1차 필터입니다.

다음 주 과제

[10주차 수업 전까지 · Sprint 1 착수]

1. 변경 1건 이상을 통합본에 반영
   - 핵심 기능의 골격이면 됩니다. 완성 아니어도 됩니다
   - 자동 검증 통과 + 리뷰 승인을 거칠 것
   - 리뷰 없이 통합본을 직접 고치지 말 것
   ※ 경로 A: 변경 요청 → 리뷰 짝 확인 → 병합
     경로 B: 리뷰 기록지 작성 → 확인 → 커밋 묶음 반영

2. 이슈 보드 갱신
   - 진행 중인 이슈에 담당자와 상태 표시
   - 1인당 동시 진행 이슈는 최대 2개

3. 개인 과제 — AI 사용 로그
   - 이번 주부터는 「반려 기록」을 구현 과정에서 찾으세요

마감: 수업 전날 자정

제출 형식

변경 요청 본문 (또는 리뷰 기록지) — 서식 전문은 과제 제출 서식.

## 무엇을
약속판 조회 API 추가
관련 이슈: #14

## 인수조건 충족 여부
- [x] 상대·상태·겹치는 시간이 한 응답에 포함된다
- [x] 지연 여부를 서버에서 판정해 내려준다
- [ ] 빈 상태 → 다음 변경에서 (화면 작업과 함께)

## 검증
- 테스트: 4/4 통과
- 자동 검증: 통과

## 리뷰어가 봐줬으면 하는 곳
- 시간대 비교를 KST 기준으로 했는데, 경계값 처리가 맞는지

이번 주에 남길 것 하나 — 핵심 기능 하나를 끝에서 끝까지 동작시키는 것.
그리고 그 기능에 테스트가 붙어 있는 것.

강의 파트 (30분)

다룰 내용

1. 스펙 → 테스트 → 구현 순서와 그 이유
2. 작업을 AI가 소화 가능한 크기로 쪼개기
3. 테스트가 있는 코드와 없는 코드의 수정 비용 차이

핵심

① 인수조건을 그대로 지시에 넣습니다.

아래 사용자 스토리를 구현해줘.
[스토리 + 인수조건 그대로 붙여넣기]
구현 전에 먼저 이 인수조건을 검증하는 테스트를 작성해줘.

② 한 번의 지시는 변경 요청 하나 분량(반나절 이내). 그보다 크면 어디가 틀렸는지 못 찾고 통째로 버리게 됩니다.

③ 예외 경로는 AI가 절대 알아서 안 만듭니다. 빈 상태·에러·경계값을 인수조건에 명시하지 않으면 정상 경로만 나오고, 그게 13주차 라이브 데모에서 터집니다.

이번 주 AI 함정 — 예외 경로 누락

간단한 목록 조회를 시킨 뒤 데이터가 0건일 때 실행해 봅니다. 빈 화면·에러·깨진 레이아웃 중 하나가 나옵니다.

예외 경로는 AI가 알아서 만들지 않습니다. 인수조건에 빈 상태를 쓰지 않으면 정상 경로만 나오고,
그게 13주차 라이브 데모에서 그대로 터집니다.

실습 파트 (90분)

진행

각자 구현하고, 그 사이 코드 워크스루가 1인당 10분씩 돌아갑니다.

코드 워크스루 (1인당 10분 · 전원)

저장소를 화면에 띄우고, 임의의 한 곳을 골라 아래 네 질문을 받습니다.

1. 이 부분은 무엇을 하나요?
2. 이거 AI에게 어떻게 시켰어요? 한 번에 됐나요?
3. AI가 준 것 중에 고친 부분이 있어요? 왜 고쳤죠?
4. 이 코드가 깨질 수 있는 상황은 뭘까요?

이것이 13주차·15주차 발표에서 할 코드 설명 확인의 예행연습입니다. 10주차에 한 번 겪어두면 남은 5주 동안 설명할 수 있는 코드를 만들게 됩니다.

점검 항목

• 테스트가 실제로 존재하고 실행되는가
• Sprint 1 목표가 관통 경로인가, 아니면 화면만·API만인가
• 워크스루 질문 4개에 지금 답할 수 있는가

스프린트 1 회고 (50분 중 20분)

주간 회고 서식으로 15분 안에 씁니다. 아래 순서를 지킵니다.

3분간 각자 조용히 쓰는 것이 핵심입니다. 바로 말로 시작하면 목소리 큰 사람 의견만 남습니다.

다음 주 과제

[11주차 수업 전까지 · Sprint 2]

1. 모듈 통합을 반드시 '시도'할 것
   - 완성이 아니어도 됩니다. 붙여보는 것이 목적입니다
   - 붙이다가 실패한 로그와 에러 메시지를 그대로 저장해 오세요
     (11주차 디버깅 클리닉에서 그걸로 수업합니다)

2. Sprint 2 이슈 진행
   - 담당자·상태를 보드에 반영

3. 주간 회고 작성

4. 개인 과제 — AI 사용 로그

마감: 수업 전날 자정
※ "아직 붙일 게 없어요"는 사유가 되지 않습니다. 지금 있는 것끼리라도 붙여보세요.

제출 형식

과제 제출 페이지에서 «통합 시도 기록» 선택 — 11주차 디버깅 클리닉에서 이 기록으로 수업합니다.

POST /api/tasks/12/status 400
{"error":"invalid status","received":"in_progress","expected":["INPROGRESS","DONE","TODO"]}

이번 주에 남길 것 하나 — 내 모듈들이 하나의 앱으로 연결된 상태.
강의는 최소로, 학생이 가져온 실제 버그를 공개 해부하는 데 시간을 쓰는 주입니다.

강의 파트 (20분)

다룰 내용

1. 통합은 마지막이 아니라 지금 — 왜 항상 늦어지는가
2. 디버깅 3단 — 재현 → 최소화 → 가설 검증
3. AI가 못 잡는 버그를 사람이 잡는 절차

핵심

"고쳐줘"는 원인을 모른 채 넘어가게 만듭니다. 그러면 같은 버그가 형태를 바꿔 다시 옵니다.

디버깅 프롬프트에 반드시 넣을 것:

• 에러 메시지 전문 (잘라내지 말 것)
• 관련 코드
• 기대한 동작 / 실제 동작
• 이미 시도해본 것

그리고 요청은 "고쳐줘"가 아니라 "원인 가설 3개와 각각의 확인 방법".

이번 주 AI 함정 — 원인 모른 채 넘어가기

버그를 "고쳐줘"로 시키면 코드가 바뀌고 증상이 사라집니다. 그런데 왜 사라졌는지 설명하지 못하는 상태가 됩니다.

주의

그 코드는 반려 대상입니다 — 맞아도 설명하지 못하면 없는 것으로 칩니다.
"원인 가설 3개와 각각의 확인 방법" 으로 다시 시킵니다.

디버깅 클리닉 (60분)

각자 가져온 통합 실패 로그 중 3~4개를 골라 전체 앞에서 함께 해부합니다.

진행 방법

1. (2분) 버그를 가져온 사람이 증상을 설명합니다 — 무엇을 기대했고 무엇이 일어났는지
2. (3분) 나머지 전원이 가설을 냅니다 (이 단계에서는 검증하지 않습니다)
3. (5분) 가설을 확인 가능한 순서로 정렬 → 가장 싼 것부터 확인
4. (5분) 원인 확정 후, 이 버그를 다음에 미리 잡으려면 무엇이 있어야 했는지 정리

4번이 클리닉의 핵심입니다. "테스트가 있었으면" / "인터페이스를 먼저 정했으면" / "타임존을 명시했으면" 같은 답이 나오면, 그것이 남은 4주의 개선 항목이 됩니다.

자주 나오는 통합 실패 유형

통합 데이 (70분)

점검 항목

• 오늘 안에 붙는가. 안 붙으면 무엇을 잘라야 붙는지 결정합니다
• 2시간 규칙을 지키고 있는가 — 같은 화면을 30분 넘게 보고 있으면 이미 넘긴 것입니다

오늘의 판단 기준

12주차는 품질·배포 주입니다. 11주차에 안 붙으면 13주차 데모가 없습니다.
오늘 안 붙을 것 같으면 기능을 잘라서라도 붙입니다. 미완성 기능 3개보다 동작하는 기능 1개가 낫습니다.

다음 주 과제

[12주차 수업 전까지 · Sprint 3]

1. 예외 처리 보강
   - 빈 상태 / 로딩 / 에러 화면을 최소 핵심 경로에 대해 만들 것

2. 배포 준비
   - 배포 대상 결정, 환경변수 분리, 빌드 성공 확인
   - 12주차 수업 시간에 실제 배포를 합니다

3. README 작성
   - 처음 보는 사람이 설치·실행할 수 있게
   - 12주차 교차 QA에서 다른 수강생이 이 README로 여러분 서비스를 실행합니다

4. 주간 회고 + 개인 AI 사용 로그

마감: 수업 전날 자정

제출 형식

개인 저장소 루트 README.md — 서식 전문은 과제 제출 서식.

npm install
cp .env.example .env    # 값 채우기
npm run dev             # http://localhost:3000

이번 주에 남길 것 하나 — 외부인이 접속해서 쓸 수 있는 주소가 생기는 것.
"돌아가는 것"과 "쓸 수 있는 것"의 차이를 배우는 주입니다.

강의 파트 (25분)

다룰 내용

1. 예외 처리 — 빈 상태 / 로딩 / 에러 / 권한 없음
2. 보안 기본 — 키 노출, 입력 검증, 권한 확인
3. 성능 — 무엇을 재고 무엇을 무시할지
4. 배포와 환경 분리

핵심

① 저장소에 키가 올라가 있는지 지금 확인합니다.
저장소에 .env가 커밋되는 일은 드물지 않습니다. 커밋 이력에 한 번이라도 올라갔으면 키를 재발급해야 한다는 것까지 다룹니다.

② 성능은 목표치가 있어야 개선입니다.
"빠르게 만들었어요"는 측정이 아닙니다. PRD 비기능 요구사항에 적은 수치와 대조합니다.

③ AI에게 보안 점검을 요청하되, 결과를 그대로 믿지 않습니다.
AI 점검은 놓치는 것이 많고, 반대로 문제없는 것을 지적하기도 합니다. 지적 하나하나를 직접 판정합니다 — 채택인지 반려인지.

이번 주 AI 함정 — 오래된 방식

배포·보안 설정을 물어보면 몇 년 전 방식을 알려주는 경우가 흔합니다. 그 시점에는 맞았던 답입니다.

프롬프트에 버전을 명시하면 달라집니다. 그래도 마지막에는 공식 문서와 대조합니다.

배포 실습 (65분)

진행

1. (15분) 환경변수 분리, 시크릿 설정
2. (30분) 실제 배포 — 막히면 그 자리에서 코칭을 받습니다
3. (20분) 배포 환경에서 핵심 경로 동작 확인

로컬에서만 되던 것이 배포하면 깨집니다. 그 경험이 이번 주의 학습 목표입니다. 미리 걱정할 필요는 없습니다. 깨진 뒤에 원인을 함께 찾습니다.

점검 항목

• 키가 코드에 하드코딩되어 있지 않은가
• 배포 URL에 외부 기기(휴대폰)로 접속되는가
• 첫 화면이 뜨는 데 얼마나 걸리는가

교차 QA (60분)

둘씩 짝지어, 상대 서비스를 부숩니다.

규칙

1. README만 보고 접속/실행 (질문 금지)
2. 30분간 자유롭게 사용하며 문제를 찾음
3. 발견한 것을 상대 개인 저장소에 이슈로 등록

이슈 양식

[QA] 무엇을 하려다 / 어떻게 막혔나

재현 절차:
1.
2.

기대한 동작:
실제 동작:
심각도: 상 / 중 / 하

부수는 방법 힌트

• 빈 값, 아주 긴 문자열, 특수문자 입력
• 로그인 없이 내부 주소 직접 접근
• 뒤로가기·새로고침 반복
• 데이터가 0건인 상태로 진입
• 느린 네트워크 (개발자 도구에서 조절)

교차 QA는 13주차 발표 전에 자기 서비스의 구멍을 남의 눈으로 보는 마지막 기회입니다. 여기서 나온 이슈가 14주차 개선 백로그의 절반을 채웁니다.

다음 주 과제

[13주차 2차 발표 준비]

1. 발표자료 (10분) — 슬라이드보다 라이브 데모가 중심입니다
   필수 포함:
   - 1차 발표 피드백을 어떻게 반영했는지
   - 아키텍처와 주요 설계 결정 (ADR 1건 이상 설명)
   - 라이브 데모 (배포 환경에서)
   - 간이 사용성 테스트 결과
   - 남은 2주 계획과 리스크

2. 간이 사용성 테스트 2명
   - 실제 타깃 사용자
   - 과업을 주고 관찰만 할 것. 힌트 금지

3. 교차 QA 이슈 처리
   - 심각도 '상'은 발표 전까지 수정
   - 못 고친 것은 발표에서 정직하게 밝힐 것

4. 개인 과제 — AI 사용 로그

※ 발표 중 저장소 코드를 한 부분을 골라 설명을 요청합니다.
   설명하지 못하면 1건당 -5점입니다.

제출 형식

과제 제출 페이지에서 «사용성 테스트» 선택 — 참가자 1명당 한 건씩, 과업 2~3개로 축소해 제출합니다.

이번 주에 남길 것 하나 — 각자 남은 2주에 무엇을 해야 하는지 확정하고 나가는 것.
이번 발표는 슬라이드가 아니라 라이브 데모가 중심입니다.

진행 방법

라이브 데모 원칙

녹화 영상 대체는 -10점입니다. 네트워크 등 불가피한 사유는 사전 허가를 받아야 합니다.

• 배포 환경에서 시연 (로컬 시연은 감점)
• 데모 전에 각자 노트북을 미리 연결해 화면을 확인해 둡니다
• 데모 도중 에러가 나도 감점하지 않습니다. 어떻게 대응하는지를 봅니다

코드 설명 확인

발표가 끝나면 저장소에서 임의의 파일 한 곳을 열어 설명을 청합니다.

• 발표 직후에는 1인당 1건. 나머지는 코드 설명 라운드(30분) 에서 전원에게 진행합니다
• 설명하지 못하면 1건당 -5점

평가

• 2차 발표 루브릭으로 교수 채점
• 개발 프로세스 항목(20점)은 저장소를 직접 열어 채점합니다. 발표 내용보다 실제 작업 이력이 우선입니다. 택한 저장소 경로에 따라 확인 대상이 달라집니다 (커밋·변경요청·CI 또는 칸반·리뷰 기록지·검증 로그)
• 모든 수강생은 상호 평가지 A파트를 발표를 들으며 작성합니다

미리 알아두는 감점

질의응답

7번에 정직하게 답하면 가점을 줍니다. "다 할 수 있습니다"라고 답하는 사람이 15주차에 가장 크게 무너집니다.

코드 설명 라운드 (30분)

전원이 각자 5분씩 진행합니다.

7주차에 "다음 8주에 하겠다"고 말한 곳을 우선으로 고릅니다.
AI가 쓴 부분이라도 상관없습니다. 설명할 수 있으면 그것으로 완성입니다.

사용성 테스트 리허설 (30분)

다음 주 과제가 실사용자 5명 테스트입니다. 옆 사람을 참가자로 세워 진행을 연습합니다.

진행에서 자주 나오는 실수

핵심

내 프로젝트를 잘 아는 사람과 하면 다 성공합니다. 처음 보는 사람이라야 진짜 막히는 지점이 보입니다.

정리 (20분)

남은 2주의 구조는 이렇습니다.

• 14주차 — 사용자 검증 (5명 테스트 결과를 가지고 오는 주)
• 15주차 — 최종 발표

다음 주 과제

[14주차 수업 전까지]

1. ★ 실사용자 5명 사용성 테스트 (이번 주의 핵심)
   - 실제 타깃 사용자. 수강생·가족 제외
   - 과업 3~5개를 '목표'로 제시할 것. 방법을 알려주면 안 됩니다
     ❌ "우측 상단 + 버튼을 눌러 작업을 추가해 보세요"
     ✅ "상대와 만날 수 있는 시간 3개를 골라 보세요"
   - 진행 중 힌트 금지. 물어보면 "어떻게 하시면 좋을 것 같으세요?"
   - 기록: 과업별 성공/실패, 소요 시간, 막힌 지점, 사용자 발언

2. 사용 로그·오류 데이터 수집
   - 서비스에서 수집 가능한 것이 있으면 함께 정리

3. 개인 과제 — AI 사용 로그

마감: 수업 전날 자정
※ 14주차 수업은 여러분이 가져온 데이터로 진행합니다.
   데이터가 없으면 그 시간에 할 것이 없습니다.

제출 형식

과제 제출 페이지에서 «사용성 테스트» 선택 — 참가자 1명당 한 건씩 5건. 종합 분석은 14주차에 같은 서식의 아래 절에 채워 다시 제출합니다.

> 주차: 13주차 과제 · 작성일: 2026-XX-XX
> 작성: 김서연

# 사용성 테스트 U2
- 일시 / 프로필: 4학년, 이번 학기 중고 물건을 파는 사람 / 진행 방식: 대면

## 과업 결과
| 과업 | 완료 | 소요 시간 | 도움 필요 | 오류 |
|---|---|---|---|---|
| T1 거래 열기·링크 공유 | 성공 | 68초 | ☐ | 0 |
| T2 만날 시간 3개 고르기 | 실패 | — | ☑ | 2 |
| T3 답 없는 거래 확인 | 성공 | 9초 | ☐ | 0 |

## 막힌 지점
| 시점 | 무엇을 하려다 | 어떻게 막혔나 | 발언 |
|---|---|---|---|
| 3:05 | 날짜 선택 | 모바일에서 날짜 선택기가 잘림 | (화면을 계속 확대·축소) |

## 관찰 노트
- 화면을 두 번 새로고침함. 저장이 됐는지 확신하지 못함

발표 진행 규칙

• 배포 URL은 발표 전날 저녁에 확인합니다. 접속되지 않으면 발표 전에 알려드립니다
• 설명을 청할 코드는 발표 중에 무작위로 고릅니다. 미리 정해두지 않습니다
• 채점은 발표 직후 진행하며, 프로세스 항목은 저장소를 그 자리에서 열어 확인합니다
• 데모 도중 에러가 나도 감점하지 않습니다. 어떻게 대응하는지를 봅니다
• 데모 도중 에러가 나도 감점하지 않습니다. 어떻게 대응하는지를 봅니다

이번 주에 남길 것 하나 — 남은 1주에 할 수 있는 것만 골라내는 것.
검증 결과 전부를 고치려 들면 아무것도 못 고칩니다.

강의 파트 (30분)

다룰 내용

1. 정량과 정성을 함께 읽기 — 성공률·시간 + 막힌 지점
2. 심각도 판정 기준 — 상/중/하
3. 남은 1주에 할 수 있는 것 고르기
4. 못 고친 것을 어떻게 발표할 것인가

핵심

① 심각도 기준을 명확히.

② 우선순위는 심각도 × 수정 난이도입니다.
심각도 '상' + 난이도 S/M 인 것이 최우선. 심각도 '상'인데 난이도 L인 것은 고치지 말고 한계로 밝히게 합니다.

③ 못 고친 것을 정직하게 밝히는 것이 감점보다 낫습니다.

최종 발표 루브릭에서 "한계를 정직하게 밝힘"은 가점 요인입니다. 숨겼다가 질의에서 드러나는 쪽이 훨씬 큰 감점입니다.

④ 5명이면 충분합니다. 사용성 문제의 대부분은 5명 안에서 드러납니다. 인원을 못 채웠더라도 분석을 소홀히 하지 않습니다.

이번 주 AI 함정 — 데이터 없이 결론 만들기

빈약한 데이터를 주고 사용성 테스트 요약을 시키면, AI는 데이터에 없는 결론까지 그럴듯하게 만들어냅니다.

"이 결론의 근거가 된 발언을 인용해줘" 라고 되물으세요. 근거가 없다는 것이 그 자리에서 드러납니다.

실습 파트 (80분)

진행 순서

1. (20분) 정량 집계 — 과업별 성공률, 평균 소요 시간, 목표 대비
2. (25분) 문제 목록화 — 5명 기록에서 막힌 지점을 전부 카드로. AI로 유사 항목 묶기 → 사람이 검증
3. (20분) 심각도·난이도 판정 — 2축 매트릭스에 배치
4. (15분) 개선 백로그 확정 — 1주 안에 할 수 있는 것만

사용성 테스트 서식의 종합 분석 부분을 채웁니다.

점검 항목

• AI가 서로 다른 원인의 문제를 하나로 묶지 않았는가 (사람이 반드시 검증)
• 개선 백로그가 5개를 넘지 않는가 (넘으면 1주 안에 불가능)
• "고치지 않기로 한 것"이 기록되고 있는가

최종 개선 백로그 확정 (60분)

1인당 6~7분 코칭. 아래 네 질문으로 확정합니다.

1. 이 중 안 고치면 최종 데모가 실패하는 것은 무엇인가요?
2. 1주 안에 정말 끝낼 수 있나요?
3. 안 고치기로 한 것은 발표에서 어떻게 말할 건가요?
4. 개선하다가 지금 되는 것을 깨뜨릴 위험은 없나요?

주의

4번이 특히 중요합니다. 마지막 주에 리팩터링을 시작했다가 동작하던 데모를 깨뜨리는 일이 매 학기 나옵니다.
발표 48시간 전에 코드를 얼립니다. 그 뒤로는 고치지 않습니다.

다음 주 과제

[15주차 최종 발표 준비]

1. 최종 개선 반영 + 최종 배포
   ★ 발표 48시간 전 코드 동결. 이후에는 수정 금지
   
2. 발표자료 (15분 구성)
   - 문제와 사용자 (2분)
   - 해결 접근과 핵심 설계 결정 (2분)
   - 라이브 데모 (5분)
   - 사용자 검증 결과 5명 — 지표와 발견 (3분)
   - 한계와 향후 계획 (2분)   ← 생략하지 마세요. 배점이 큽니다
   - 회고: 15주간 무엇을 배웠는가 (1분)

3. 최종 보고서 + 시연 영상

4. 개인 제출
   - 기여 명세서 — 「내가 판단한 것 ↔ AI가 만든 것」 포함 (매주 AI 로그와 대조합니다)
   - 개인 회고
   - AI 사용 로그 전체 요약
   - 상호 평가지 (비공개)

마감: 수업 전날 자정
※ 발표 중 코드 무작위 선택 설명이 있습니다.

제출 형식

과제 제출 페이지에서 «최종 보고서» 와 «기여 명세서» 를 각각 제출합니다.

# 기여 명세서 — 김서연

## 내가 담당한 것
| 주차 | 무엇을 | 근거 |
|---|---|---|
| 5 | 목업 3사이클, 사용자 피드백 3명 수집 | 제출함 «리스크 리포트» 5주차 |
| 10 | US-03 조회 API + 테스트 4건 | 이슈 #14, 커밋 a1b2c3d |
| 11 | 상태 값 불일치 버그 원인 추적 | docs/integration-log.md |

## 내가 판단한 것 ↔ AI가 만든 것
| 무엇 | AI가 만든 것 | 내가 판단한 것 |
|---|---|---|
| 약속판 조회 API | 컨트롤러·쿼리·테스트 4건 초안 | 응답 구조를 서버에서 지연 판정까지 해서 내려주기로 결정. join 최적화 제안은 반려 |
| 공감지도 | 인용 분류 초안 | 「눈치」 축을 별도로 뺀 것. AI는 「불편」 하나로 묶었는데 인터뷰에서는 다른 감정이었음 |
| 시간대 버그 | 없음 (AI 제안이 원인) | 원인 추적과 경계값 테스트 설계 |

## 내가 내린 판단 (코딩이 아니라 결정)
1. 약속판 응답 구조를 서버에서 지연 판정까지 해서 내려주기로 결정.
   프론트에서 계산하면 시간대 처리가 두 곳으로 갈라지기 때문.
2. AI가 제안한 join 방식 최적화를 반려. 우리 스키마에서는 데이터 중복이 커짐.

## AI 사용 요약
- 대략 40시간 / 주로 테스트 초안과 보일러플레이트
- 반려 사례 2건: 위 2번, 그리고 UTC 기준 마감 판정(경계값에서 하루 오차)

## 개인 회고
- 가장 크게 성장한 것: 인수조건을 먼저 쓰면 AI 결과를 판정할 수 있다는 것
- 다시 한다면: 통합을 Sprint 1에서 한 번 해봤을 것

이번 주에 남길 것 하나 — "AI가 준 것을 언제 믿고 언제 의심해야 하는가"에 대한 감각을 가지고 나가는 것.
결과물보다 그 감각이 이 과목의 진짜 산출물입니다.

진행 방법

발표 구성 (15분)

마지막 두 항목을 생략하기 쉽습니다. 배점이 가장 큰 구간입니다.

코드 설명 확인

• 발표 직후에는 1인당 1건. 나머지는 팀장 라운드(30분) 에서 6명 전원에게 진행합니다
• 담당자에게 설명 요청 → 실패 시 1건당 -5점
• 15주차에는 AI 로그와 대조해서 묻습니다: "로그에 이 부분을 반려했다고 썼는데, 대신 어떻게 했나요?"

평가

• 최종 발표 루브릭으로 채점합니다
• 학기 내내 남은 기록(작업 이력·AI 로그·회고·리뷰)과 교차 확인합니다

미리 알아두는 감점

질의응답

8번은 「AI를 판단에 썼는가」의 근거로 쓰입니다. "코딩을 많이 했어요"가 아니라 판단을 묻는 질문이라는 점이 중요합니다.

과정 확인

발표 점수에 아래 근거를 교차 확인합니다.

주의

한 가지 근거만으로 감점하지 않습니다. 여러 근거가 일치할 때만 조정합니다.

팀장 라운드 (30분)

6명 각자 5분씩 말하고 질의를 받습니다.
이 과목은 학생을 팀장, AI를 팀원으로 놓았습니다. 마지막 확인은 팀장으로서 무엇을 했는가입니다.

참고

2번은 AI 사용 로그와 대조해 묻습니다. 로그에 적은 반려 사례를 직접 설명합니다.
3번이 이 과목의 학습 성과입니다 — "약속판 만들어줘"에서 "이 인수조건 3개를 만족하는"까지 왔는가.

마무리 (20분)

상호 총평 (10분)

옆 사람에게 한마디씩 합니다. 한 학기 내내 서로를 본 유일한 외부 시선입니다.
점수와 무관합니다 — 옆 사람에게서 배운 것 1가지, 가장 크게 달라진 지점.

학기 마무리 (10분)

정리하는 내용

1. 잘한 사람의 공통점 — 대개 "일찍 통합한 사람"과 "정직하게 보고한 사람"입니다
2. AI 활용의 차이 — 같은 도구를 썼는데 결과가 갈린 이유
3. 한계를 밝힌 사람에 대한 평가 — 정직하게 밝힌 사람이 숨긴 사람보다 높은 점수를 받습니다

마지막 메시지

이 과목이 끝나고 여러분에게 남기를 바라는 것은 프롬프트 모음집이 아닙니다.

"AI가 준 것을 언제 믿고 언제 의심해야 하는가" 에 대한 감각.
그것만 남으면 이 과목은 성공입니다. 도구는 내년에 또 바뀝니다.

학생 자료: 1주차 · 오리엔테이션과 빌딩
진행에 필요한 것만 담습니다. 학생 자료와 겹치는 내용은 넣지 않습니다.

시간 운영

수업 전 준비

진행 대본

강의 ① — 실패 4패턴을 먼저

과목 구조보다 실패 패턴을 먼저 말하는 편이 집중이 붙습니다.
지난 학기 사례가 있으면 익명화해서 한 문장씩 붙입니다.

"이 과목이 평가하는 건 아이디어가 아닙니다"를 여기서 한 번, 15주차에 한 번 더 말합니다.

AI 함정 시연 — 자신 있게 틀리기 (5분)

1. 학과 교과목 코드나 가상의 라이브러리 함수를 하나 정해 둡니다 (실존하지 않는 것으로)
2. 프로젝터에서 AI에게 물어봅니다
3. 망설임 없이 그럴듯한 답이 나오는 장면을 함께 봅니다

여기서 꼭 말할 것: "확신의 강도와 정확도는 아무 관계가 없습니다."
이 문장이 15주 내내 반복되는 기준선입니다.

강의 ② — 3칸으로 진행

칠판을 세 칸으로 나누고, 학생 대답을 받아 채웁니다.

학생들은 ①②는 쉽게 받아들이고 ③에서 멈칫합니다. 거기가 이 강의의 목적입니다.

탐색 영역 확정 — 개입 기준

주의

이 워크샵을 2주차로 미루면 안 됩니다. 인터뷰를 해 올 시간이 없어져 2주차가 통째로 빕니다.

실습 중에 볼 것

• 프로젝트 계획서 「만날 수 있는 사람」 — 여기만 보면 다음 주 진행 여부를 알 수 있습니다
• 「AI 사용 기준」의 반려 칸 — 세 번째(설명 못 함)를 안 적은 학생에게 그 자리에서 묻습니다
• 저장소 경로 A/B 선택 — 계정을 못 만드는 학생은 오늘 B로 확정합니다

이번 주 위험 신호

기록해 둘 것

학생 자료: 2주차 · Empathize — 사용자 관찰
진행에 필요한 것만 담습니다. 학생 자료와 겹치는 내용은 넣지 않습니다.

시간 운영

수업 전 확인

진행 대본

강의 — 칠판에 두 문장

요약     : 사용자는 앱이 복잡해서 불편해한다
인사이트 : 복잡해서가 아니라 실수를 되돌릴 방법이 없어서 신중해지고, 결국 포기한다

두 문장을 나란히 적어두고 차이를 학생에게 먼저 말하게 합니다.
"구체적이다" 정도가 나오면, 긴장(tension) 이라는 단어를 주고 다시 묻습니다.

시연 자료의 인사이트 10개 중 3~4개만 골라 보여줍니다. 전부 읽으면 30분을 넘깁니다.

AI 함정 시연 — 한국어 뉘앙스 오독 (5분)

1. 제출된 전사록에서 반어법·완곡어법·체념이 섞인 대목을 미리 하나 골라 둡니다
2. AI에게 그 대목의 감정 분류를 시킵니다
3. "괜찮아요 뭐, 그냥 제가 하면 되니까" 류가 긍정으로 분류되는 장면을 보여줍니다

이어서 말할 것: 분류는 시켜도 되지만 감정 칸의 판정은 직접 해야 한다는 것.
이 시연이 공감지도 실습으로 바로 이어집니다.

실습 중에 볼 것

카드보드는 제출 페이지 «공감지도» 화면에서 열립니다.
「내 제출물에서 카드 붙이기」를 쓰면 전사 작업을 다시 하지 않아도 됩니다 — 첫 5분에 안내하세요.

교차 리뷰 — 두 질문만

듣는 사람이 딴 얘기를 시작하면 바로 되돌립니다. 두 질문 외에는 하지 않습니다.

1. "그 인사이트의 근거가 어느 발언이에요?"
2. "그건 인터뷰 전에도 예상했던 거 아니에요?"

2번에서 막히는 학생이 절반 이상이면, 다음 주 강의 앞부분에 인사이트를 5분 더 붙입니다.

이번 주 위험 신호

학생 자료: 3주차 · Define — 문제 정의와 요구사항
진행에 필요한 것만 담습니다. 학생 자료와 겹치는 내용은 넣지 않습니다.

시간 운영

수업 전 확인

진행 대본

강의 — POV를 세 번 고쳐 씁니다

시연 자료의 POV 1차 → 2차 → 3차를 한 화면에 나란히 띄워두고 진행합니다.
무엇이 달라졌는지 학생에게 먼저 말하게 하는 편이 빠릅니다.

해결책 단어(앱·플랫폼·AI·자동화)를 지우는 시범을 실제 학생 후보 하나로 해봅니다.
지우고 나서 문장이 성립하지 않으면, 그건 문제가 아니라 아이디어였다는 뜻입니다.

AI 함정 시연 — 일반론으로 도피 (5분)

1. 인터뷰 데이터 없이 PRD를 시킵니다 → 어느 프로젝트에 붙여도 되는 문서가 나옵니다
2. 같은 지시에 학생 인터뷰 인용 3개를 붙여 다시 시킵니다
3. 두 결과를 나란히 놓습니다

여기서 「패턴 1. 맥락 먼저」로 연결합니다. 지시가 결과를 결정한다는 1주차 강의의 재확인입니다.

실습 중에 볼 것

반박 실습에서 반려한 것 1개를 못 적는 학생이 많으면, 다음 주에 「패턴 3. 반박 요청」을 5분 다시 다룹니다.

개인별 코칭 — 네 질문

학생 자료에 공개돼 있으므로 준비해 옵니다. 답의 질을 봅니다.

마지막 답이 막연하면 그 자리에서 관찰 가능한 형태로 다시 쓰게 합니다.
여기를 넘기면 14주차 사용자 검증에서 잴 것이 없습니다.

이번 주 위험 신호

학생 자료: 4주차 · Ideate — 발산·수렴과 주제 확정
이번 주는 게이트입니다. 통과하지 못하면 5주차로 넘기지 않습니다.

시간 운영

수업 전 확인

참고

조사표 URL을 공개적으로 여는 것이 이번 주의 숨은 목적입니다.
열리지 않는 링크가 나오는 일은 드물지 않고, 한 번 겪으면 남은 학기 인용 사고가 크게 줄어듭니다.

진행 대본

AI 함정 시연 — 없는 출처 만들기 (5분)

1. AI에게 "이 분야 관련 논문 3편과 링크"를 요청합니다
2. 나온 링크를 강의 화면에서 실제로 클릭합니다
3. 열리지 않는 링크가 나오는 순간을 함께 봅니다

학생 조사표에서 실제로 안 열린 링크가 나왔다면 그걸 쓰는 편이 훨씬 낫습니다.
남의 사례가 아니라 자기 제출물이기 때문입니다.

발산·수렴 — 흔한 실패

"발산은 AI, 수렴은 사람." 이 문장을 칠판에 남겨둡니다.

첫 아이디어를 그대로 가져가는 학생이 매 학기 나옵니다.
탈락 대안을 설명하지 못하면 선택이 아니라 관성이라는 말을 여기서 한 번 합니다.

주제 확정 심사 — 판정 기준

보류는 벌이 아니라 보호입니다. 여기서 넘긴 문제는 13주차에 훨씬 큰 비용으로 돌아옵니다.
판정을 미루지 마세요. 그 자리에서 말해야 이번 주 안에 고칩니다.

질문 고르는 요령

학생 자료에 6개가 공개돼 있습니다. 1인당 3~4개를 고릅니다.

이번 주 위험 신호

기록해 둘 것

학생 자료: 5주차 · Prototyping I — UX 프로토타입
진행에 필요한 것만 담습니다. 학생 자료와 겹치는 내용은 넣지 않습니다.

시간 운영

수업 전 확인

진행 대본

강의 — 빈 상태를 걸고 넘어갑니다

"가장 자주 빠뜨리는 세 화면이 13주차 라이브 데모에서 정확히 터집니다."

이 문장을 5주차에 한 번, 10주차에 한 번, 12주차에 한 번 반복합니다.
매 학기 여기서 안 그린 학생이 13주차에 그 화면에서 막힙니다.

AI 함정 시연 — 맥락 유실 (5분)

1. 목업을 AI와 5~6턴 이어서 고칩니다
2. 앞에서 정한 제약(사용자·화면 개수·톤)을 슬며시 잊고 다른 것을 만들어내는 지점이 옵니다
3. 새 대화를 열고 맥락을 다시 넣으면 회복되는 것을 보여줍니다

학생들은 "대화를 이어가는 게 이득"이라고 생각합니다. 그 반대라는 것이 이 시연의 요점입니다.

실습 중에 볼 것

상호 시연 — 진행 규칙

이 시간의 학습은 "설명하고 싶은데 설명할 수 없는" 경험입니다. 그래서 규칙이 전부입니다.

• 만든 사람이 한 마디라도 하면 즉시 끊습니다
• 조작하는 사람이 막히면 도와주지 않습니다. 기록만 하게 합니다
• 3분 뒤 역할 교대

13~14주차 사용성 테스트의 축소판입니다. 여기서 규칙을 느슨하게 하면 14주차 데이터도 느슨해집니다.

이번 주 위험 신호

다음 주를 위해

주의

6주차 사전 과제의 「개발 환경 세팅」이 이번 주의 진짜 숙제입니다.
세팅을 안 해오면 6주차 집중 코딩 100분이 통째로 날아갑니다.
수업 마지막에 한 번 더 구두로 공지하고, 완료 스크린샷 제출을 확인하세요.

학생 자료: 6주차 · Prototyping II — 기술 검증(PoC)
강의는 짧게, 순회 코칭에 시간을 쓰는 주입니다.

시간 운영

수업 전 확인

진행 대본

목표 선언 (5분)

각자 수업 채널에 한 줄씩 올리게 하고, 화면에 띄워둔 채로 수업을 진행합니다.

오늘 나는 [___]가 가능한지 확인한다.
성공 기준: [___]가 화면/로그에 나오면 성공.

선언이 모호한 학생은 그 자리에서 고치게 합니다.
"API 연동해본다"는 선언이 아닙니다. 무엇이 화면에 나오면 성공인지가 있어야 합니다.

AI 함정 시연 — 없는 함수 만들기 (5분)

1. 학생들이 실제로 쓰는 라이브러리를 하나 고릅니다
2. AI에게 구체적인 사용법(메서드명·옵션)을 묻습니다
3. 공식 문서를 나란히 띄워 대조합니다

존재하지 않는 메서드를 자신 있게 알려주는 경우가 흔합니다. 처음 쓰는 라이브러리일수록 그렇습니다.

순회 코칭 — 2회전

1회전 (방향 점검) · 1인당 10분

2회전 (막힘 해소) · 1인당 12분

프롬프트를 보여달라는 요청이 이 시간의 핵심 도구입니다.
코드를 보면 결과만 보이지만, 프롬프트를 보면 지시의 질이 보입니다.

결과 공유 — 실패를 먼저

"안 된다는 것을 알아낸 것"도 성과입니다.

이것을 교수가 먼저 말해야 학생이 실패를 보고합니다.
여기서 실패 보고가 나오면 13주차까지 정직한 보고가 이어지고, 여기서 안 나오면 끝까지 안 나옵니다.

가능하면 실패한 스파이크를 먼저 발표시키세요. 순서가 분위기를 만듭니다.

이번 주 위험 신호

다음 주를 위해

7주차는 1차 발표입니다. 리허설 영상 제출을 강조하세요 —
영상을 안 낸 학생은 거의 예외 없이 시간을 초과합니다.

학생 자료: 7주차 · 1차 발표
발표는 심사가 아니라 방향 교정입니다. 이 톤을 유지하세요.

시간 운영

6명 개별 발표이므로 별도 개인 라운드를 두지 않습니다. 발표 자체가 개인 단위 확인입니다.

수업 전 확인

진행 규칙

질의 순서를 지킵니다

주의

동료 질문을 먼저. 교수가 먼저 물으면 그 뒤로는 아무도 손을 들지 않습니다.

1. 발표 10분 (8분에 1차 알림)
2. 동료 질문 2분
3. 교수 질문 3분

발표자를 제외한 5명은 질문 1개씩을 준비해 옵니다. 준비를 안 해온 학생이 있으면 그 자리에서 지목합니다.

채점

• 1차 발표 루브릭으로 채점 — 발표 직후 마무리합니다. 몰아서 하면 뒤 순서가 유리해집니다
• 상호 평가지는 평가자 이름을 지우고 발표자에게 전달
• "수고하셨습니다"만 적힌 평가지는 미제출 처리

질문 고르는 요령

학생 자료에 7개가 공개돼 있습니다. 1인당 2~3개.

7번(AI가 준 것 중 반려한 것)은 매 발표마다 최소 한 사람에게 묻습니다.
이 과목의 시그니처 질문이고, 답을 못 하는 학생이 많으면 다음 주에 「패턴 3. 반박 요청」을 5분 다시 다룹니다.

총평 — 이름 없이 유형으로

매 학기 반복되는 넷입니다. 해당 학생을 지목하지 않고 전체를 향해 말합니다.

기록해 둘 것

학생 자료: 8주차 · 아키텍처 설계
진행에 필요한 것만 담습니다. 학생 자료와 겹치는 내용은 넣지 않습니다.

시간 운영

수업 전 확인

진행 대본

AI 함정 시연 — 동조 편향 (7분)

이번 주에서 가장 효과가 큰 시연입니다. 반드시 라이브로 하세요.

1. 어떤 학생이 이미 정한 스택을 골라 AI에게 "이 선택 어때?"라고 묻습니다 → 칭찬합니다
2. 같은 화면에서 정반대 선택을 제시하고 똑같이 묻습니다 → 그것도 칭찬합니다
3. 마지막으로 "이 선택의 가장 큰 약점 3가지"를 시킵니다 → 이제야 쓸모 있는 답이 나옵니다

1주차 강의 ②의 「AI는 반대하지 않는다」가 여기서 증명됩니다.
반대는 명시적으로 시켜서 받아야 한다 — 「패턴 3. 반박 요청」으로 연결합니다.

강의 — 결정에는 대가가 있습니다

ADR에 "포기하는 것: 없음"이라고 썼다면, 결정을 한 게 아니라 유일한 선택지를 받아적은 것입니다.

내 역량이 제약이라는 점도 여기서 짚습니다.
"이 언어를 써 본 적이 없다"를 ADR 배경에 쓰는 것은 부끄러운 일이 아니라 설계 입력값입니다.

실습 중에 볼 것

개인별 설계 리뷰 — 2번이 관건

질문 4개는 학생 자료에 공개돼 있습니다. 그중 2번만 특별히 다룹니다.

"A 모듈과 B 모듈은 무엇을 주고받죠? 그 형식이 정해졌나요?"

여기서 막히면 11주차 통합에서 반드시 터집니다.
답이 막히는 학생은 그 자리에서 인터페이스를 종이에 적게 하고 넘어갑니다. 5분이면 됩니다.

이번 주 위험 신호

다음 주를 위해

9주차에 CI를 구축합니다. 저장소가 비어 있으면 진행할 수 없습니다.
백로그 이슈 등록(15개 내외)과 브랜치 보호 설정을 수업 마지막에 다시 공지하세요.

경로 B 학생에게는 저장소 운영 방식 가이드의 리뷰 기록지를 미리 안내합니다.

학생 자료: 9주차 · 개발 계획과 협업 체계
이 주가 남은 6주의 개발 속도를 결정합니다. 자동 검증을 오늘 안에 돌리는 것이 유일한 목표입니다.

시간 운영

수업 전 확인

진행 대본

강의 — 한 문장이 전부입니다

"AI가 쓴 코드를 믿는 방법은 자동화된 검증뿐입니다."

이 문장을 칠판에 적고 시작합니다. 나머지는 이 문장의 각주입니다.

이어서 1주차 프레임과 연결합니다 —
지시(스토리 분해) → 검수(테스트·CI) → 반려(리뷰) 가 이번 주에 도구로 구현되는 것입니다.

즉 9주차에 배우는 분해 능력이 10주차의 구현 속도를 결정합니다.

AI 함정 시연 — 리뷰의 형식화 (5분)

1. 같은 코드에 대해 관점 없이 리뷰를 시킵니다 → "좋습니다" 수준
2. 인수조건 충족 / 예외 처리 / 보안 / 가독성 으로 나눠 시킵니다 → 실제 지적이 나옵니다

요점: 리뷰도 지시다. 지시가 부실하면 리뷰도 부실합니다.

자동 검증 구축 — 오늘의 목표

주의

오늘 안에 초록불 한 번을 보게 하는 것이 목표입니다.
여기서 못 세우면 남은 6주 동안 아무도 안 씁니다.

경로 B는 CI가 강제하던 것을 규칙이 대신하는 것입니다. 배우는 내용은 같습니다.
다만 사람은 잊으므로 DoD 체크리스트에 반드시 들어가야 합니다.

Sprint 1 분업 함정

주의

화면을 다 만든 뒤 API를 붙이려는 계획이 나오면 즉시 교정합니다.
얇더라도 관통하는 경로 하나를 먼저 뚫어야 합니다. 이것이 통합 실패의 1순위 원인입니다.

리뷰 연습 — 진행

리뷰 짝끼리 양방향으로 한 번씩. 일부러 예외 처리를 빼고 올리게 하는 것이 핵심입니다.

여기서 반드시 짚을 것:

AI 리뷰는 사람 리뷰를 대체하지 않습니다.
사람 리뷰어가 사소한 것에 시간 쓰지 않게 해주는 1차 필터입니다.
같은 모델이 쓴 코드를 같은 모델이 리뷰하면 같은 오해가 두 번 통과합니다.

이번 주 위험 신호

기록해 둘 것

학생 자료: 10주차 · Implementation I — 스펙에서 테스트로
이번 주의 핵심 도구는 코드 워크스루입니다. 13·15주차 코드 설명 확인의 예행연습입니다.

시간 운영

수업 전 확인

진행 대본

AI 함정 시연 — 예외 경로 누락 (5분)

1. 간단한 목록 조회 기능을 AI에게 만들게 합니다
2. 데이터가 0건일 때 실행합니다 → 빈 화면·에러·깨진 레이아웃 중 하나가 나옵니다
3. 인수조건에 빈 상태를 넣고 다시 시켜 차이를 보여줍니다

5주차에 했던 말을 여기서 반복합니다 — 13주차 라이브 데모에서 정확히 이 지점이 터집니다.

코드 워크스루 — 이번 주의 핵심

1인당 10분씩, 6명이면 90분 안에 전원을 한 번 봅니다.
저장소를 화면에 띄우고 임의의 한 곳을 골라 묻습니다. 질문 4개는 학생 자료에 공개돼 있습니다.

10주차에 한 번 겪어두면 남은 5주 동안 설명할 수 있는 코드를 만들게 됩니다.
반대로 여기서 넘어가면 13주차에 -5점이 쌓입니다.

실습 중에 볼 것

• 테스트가 실제로 실행되는가 (파일만 있고 안 돌아가는 경우가 흔합니다)
• Sprint 1 목표가 관통 경로인가, 화면만·API만인가
• 한 번의 지시가 너무 큰가 — 반나절 넘는 분량이면 쪼개게 합니다

스프린트 1 회고 — 순서를 지킵니다

3분간 각자 쓰는 것이 핵심입니다. 바로 말로 시작하면 목소리 큰 사람 의견만 남습니다.
개인 프로젝트지만 회고는 전체가 함께 합니다 — 남의 Problem이 내 다음 주 문제인 경우가 많습니다.

이번 주 위험 신호

다음 주를 위해

11주차는 학생이 가져온 실패 로그로 수업합니다.
"아직 붙일 게 없어요"는 사유가 되지 않는다는 점을 반드시 공지하세요 —
로그가 없으면 디버깅 클리닉 60분이 통째로 빕니다.

학생 자료: 11주차 · Implementation II — 통합과 디버깅 클리닉
강의는 최소로, 학생이 가져온 실제 버그를 공개 해부하는 데 시간을 씁니다.

시간 운영

수업 전 확인

참고

클리닉에 쓸 로그 3~4개를 수업 전에 미리 골라둡니다.
즉석에서 고르면 20분이 날아갑니다. 서로 다른 유형으로 고르는 것이 좋습니다.

진행 대본

AI 함정 시연 — 원인 모른 채 넘어가기 (7분)

이번 주에서 가장 중요한 시연입니다. 학생 버그로 라이브로 하세요.

1. 버그 하나를 골라 "고쳐줘"로 시킵니다
2. 코드가 바뀌고 증상이 사라집니다
3. "왜 사라졌죠?" 라고 묻습니다 → 아무도 설명하지 못합니다
4. 같은 버그를 「원인 가설 3개와 각각의 확인 방법」으로 다시 접근합니다

여기서 1주차 프레임을 다시 꺼냅니다 —
맞는 코드라도 설명하지 못하면 반려 대상입니다. 이번 주가 그 규칙이 가장 잘 보이는 주입니다.

디버깅 클리닉 — 진행

4단계가 전부입니다. "테스트가 있었으면" / "인터페이스를 먼저 정했으면" / "타임존을 명시했으면" —
여기서 나온 답이 남은 4주의 개선 항목이 됩니다. 칠판에 남겨두고 통합 데이로 넘어갑니다.

자주 나오는 유형

통합 데이 — 오늘의 판단 기준

주의

11주차에 안 붙으면 13주차 데모가 없습니다.

오늘 안 붙을 것 같으면 기능을 잘라서라도 붙이게 합니다.
미완성 기능 3개보다 동작하는 기능 1개가 낫습니다. 이 판단을 학생에게 맡기면 대개 미룹니다.

이번 주 위험 신호

다음 주를 위해

12주차는 실제 배포와 교차 QA입니다.
README가 없으면 교차 QA를 받을 수 없다는 점을 공지하세요 — 남의 README로 실행하는 것이 이번 QA의 규칙입니다.

학생 자료: 12주차 · Implementation III — 품질과 배포
목표는 하나입니다 — 외부인이 접속해서 쓸 수 있는 주소가 오늘 안에 생기는 것.

시간 운영

수업 전 확인

진행 대본

강의 — 키 노출을 그 자리에서 확인

"지금 각자 저장소 커밋 이력에서 .env를 검색해 보세요."

30초면 됩니다. 매 학기 한두 명은 나옵니다.
나오면 키 재발급이 필요하다는 것까지 그 자리에서 다룹니다 — 파일을 지우는 것만으로는 안 됩니다.

AI 함정 시연 — 오래된 방식 (5분)

1. AI에게 배포·보안 설정을 물어봅니다 → 몇 년 전 방식이 나오는 경우가 흔합니다
2. 공식 문서와 나란히 놓고 차이를 봅니다
3. 프롬프트에 버전을 명시하고 다시 시켜 달라지는 것을 보여줍니다

요점: AI의 답은 그 시점에는 맞았던 답입니다. 틀린 게 아니라 오래된 것입니다.
그래서 버전을 지시에 넣는 것이 검수의 일부가 됩니다.

배포 실습 — 미리 안심시킵니다

"로컬에서만 되던 것이 배포하면 깨집니다. 그 경험이 오늘의 학습 목표입니다."

이 말을 실습 시작 전에 해두면 학생들이 덜 당황하고 원인을 찾습니다.
말 안 해두면 깨진 순간에 얼어붙습니다.

교차 QA — 규칙이 전부

질문하려는 학생이 나오면 바로 끊으세요. 여기서 한 번 풀어주면 QA 전체가 무의미해집니다.

부수는 방법 힌트는 학생 자료에 있습니다. 시작 5분 뒤에도 이슈가 0건인 짝이 있으면 힌트를 소리 내어 읽어줍니다.

여기서 나온 이슈가 14주차 개선 백로그의 절반을 채웁니다.

이번 주 위험 신호

다음 주를 위해

13주차는 2차 발표입니다.

주의

배포 URL을 전날 저녁에 직접 확인합니다. 접속되지 않으면 발표 전에 알려줍니다.
발표 중에 확인하면 그 학생의 시간이 다 날아갑니다.

간이 사용성 테스트 2명도 미리 공지하세요 — 안 해오면 사용자 검증 항목에서 감점입니다.

학생 자료: 13주차 · 2차 발표
이번 발표는 슬라이드가 아니라 라이브 데모가 중심입니다.

시간 운영

수업 전 확인

진행 규칙

라이브 데모

• 배포 환경에서 시연 (로컬 시연은 감점)
• 녹화 영상 대체는 -10점. 네트워크 등 불가피한 사유는 사전 허가
• 데모 전에 노트북을 미리 연결해 화면을 확인해 둡니다
• 데모 도중 에러가 나도 감점하지 않습니다. 어떻게 대응하는지를 봅니다

마지막 항목을 발표 전에 소리 내어 말해주세요. 말 안 하면 에러가 난 학생이 남은 발표를 망칩니다.

채점

• 2차 발표 루브릭으로 채점, 발표 직후 마무리
• 개발 프로세스 항목(20점)은 저장소를 그 자리에서 열어 채점합니다. 발표 내용보다 실제 작업 이력이 우선입니다
• 경로에 따라 확인 대상이 다릅니다 — A: 커밋·변경요청·CI / B: 칸반·리뷰 기록지·검증 로그

코드 설명 확인 — 고르는 요령

발표 직후 1건, 라운드에서 1인당 1건. 설명 실패는 1건당 -5점입니다.

미리 정해두지 않고 무작위로 고른다는 점을 발표 전에 말해둡니다.
AI가 쓴 부분이어도 상관없다는 것도 함께 — 설명할 수 있으면 완성입니다.

질문 고르는 요령

학생 자료에 7개가 공개돼 있습니다. 1인당 2~3개.

7번에 정직하게 답하면 가점을 줍니다. 그리고 그 자리에서 그렇게 말해주세요.
"다 할 수 있습니다"라고 답한 학생이 15주차에 가장 크게 무너집니다.

사용성 테스트 리허설 — 짝을 섞습니다

핵심

서로 프로젝트를 잘 아는 사이끼리 붙이면 다 성공합니다.
리뷰 짝이 아닌 사람, 그 프로젝트를 처음 보는 사람끼리 붙이세요.

진행에서 자주 나오는 실수 4개는 학생 자료에 있습니다. 순회하며 그중 무엇을 하고 있는지만 짚어줍니다.

총평 — 이름 없이 유형으로

기록해 둘 것

학생 자료: 14주차 · 사용자 검증
이 수업은 학생이 가져온 데이터로 진행합니다. 데이터가 없으면 할 것이 없습니다.

시간 운영

수업 전 확인

진행 대본

강의 — 정직성이 가점이라는 것을 먼저

"못 고친 것을 정직하게 밝히는 것이 감점보다 낫습니다."

이 말을 강의 앞부분에 배치합니다. 뒤에 두면 이미 숨길 계획을 세운 뒤입니다.
최종 발표 루브릭에서 「한계를 정직하게 밝힘」이 가점 요인이라는 것을 루브릭 화면으로 보여주세요.

AI 함정 시연 — 데이터 없이 결론 만들기 (5분)

1. AI에게 사용성 테스트 요약을 시키되 일부러 빈약한 데이터를 줍니다
2. 데이터에 없는 결론까지 그럴듯하게 나옵니다
3. "이 결론의 근거가 된 발언을 인용해줘" 라고 되묻습니다 → 근거가 없다는 것이 드러납니다

이 되묻기 한 문장이 이번 주 실습의 검수 도구입니다. 칠판에 적어두세요.

실습 중에 볼 것

최종 개선 백로그 — 네 질문

질문은 학생 자료에 공개돼 있습니다. 4번이 특히 중요합니다.

주의

마지막 주에 리팩터링을 시작했다가 동작하던 데모를 깨뜨리는 일이 매 학기 나옵니다.

코드 동결 공지

주의

발표 48시간 전에 코드를 얼립니다.

이것을 수업 마지막에 구두로 한 번 더 공지하세요.
문서에만 있으면 절반은 안 봅니다.

이번 주 위험 신호

다음 주를 위해

15주차 사전 제출물은 셋입니다 — 최종 보고서 · 시연 영상 · 기여 명세서.
미제출은 -15점입니다.

기여 명세서의 「내가 판단한 것 ↔ AI가 만든 것」 표를 특히 안내하세요.
이 표가 15주차 팀장 라운드의 자료가 되고, 개인 평가의 거의 유일한 근거입니다.

학생 자료: 15주차 · 최종 발표
이 과목의 산출물은 결과물이 아니라 "AI가 준 것을 언제 믿고 언제 의심해야 하는가"에 대한 감각입니다.

시간 운영

수업 전 확인

채점 순서

학기 내내 남은 기록과 교차 확인합니다. 발표 점수만으로 판단하지 않습니다.

과정 확인 조정

주의

한 가지 근거만으로 감점하지 않습니다. 여러 근거가 일치할 때만 조정합니다.
13주차 코드 설명 실패 기록이 있는 학생을 먼저 확인하세요.

질문 고르는 요령

학생 자료에 8개가 공개돼 있습니다.

6번은 AI 로그와 대조해서 묻습니다. "로그에 이 부분을 반려했다고 썼는데, 어떻게 다르게 했나요?"
로그와 말이 다른 경우가 드물지 않고, 그게 가장 확실한 판별점입니다.

팀장 라운드 (30분)

이 과목은 학생을 팀장, AI를 팀원으로 놓았습니다. 마지막 확인은 팀장으로서 무엇을 했는가입니다.

말할 것 3가지는 학생 자료에 있습니다. 그중 3번이 이 과목의 학습 성과 측정입니다.

"학기 초와 지금, 내 지시가 어떻게 달라졌는가"

마무리 (20분)

상호 총평 (10분)

옆 사람에게 한마디씩. 점수와 무관하다는 것을 먼저 말해줍니다.
한 학기 내내 서로를 본 유일한 외부 시선입니다.

학기 마무리 (10분)

1. 잘한 사람의 공통점 — 대개 "일찍 통합한 사람"과 "정직하게 보고한 사람"입니다
2. AI 활용의 차이 — 같은 도구를 썼는데 결과가 갈린 이유
3. 한계를 밝힌 사람에 대한 평가 — 정직하게 밝힌 쪽이 숨긴 쪽보다 높은 점수를 받았다는 것을 실제로 말해줍니다

마지막 메시지

이 과목이 끝나고 여러분에게 남기를 바라는 것은 프롬프트 모음집이 아닙니다.

"AI가 준 것을 언제 믿고 언제 의심해야 하는가" 에 대한 감각.
그것만 남으면 이 과목은 성공입니다. 도구는 내년에 또 바뀝니다.

학기 종료 후 정리

사용 주차: 1주차 (수업 중 작성)
제출: 과제 제출 페이지에서 «프로젝트 계획서» 선택 → 채우고 제출
혼자 하는 프로젝트가 무너지는 이유는 실력이 아니라 스스로 정하지 않은 기준 때문입니다.
지금 30분 쓰면 12주차에 3시간을 아낍니다.

1. 기본 정보

저장소 주소는 4. 저장소 운영 경로에 적습니다.

혼자 한다고 혼자 판단하지는 않습니다. 이 과목은 «변경이 다른 사람의 눈을 거친 흔적»을 요구합니다.
9주차부터 수강생끼리 리뷰 짝을 이뤄 서로의 변경 요청을 봐 줍니다. 짝은 격주로 바꿉니다.

2. 탐색 영역

1주차 마지막 워크샵에서 정합니다. 여기에 적는 것은 만들 것이 아니라 살펴볼 영역입니다.
무엇을 만들지는 4주차에 정합니다.

주의

「만날 수 있는 사람」을 못 적으면 그 영역은 진행할 수 없습니다. 다음 주까지 3명을 실제로 만나야 합니다.
막연히 "대학생"이 아니라, 연락할 수 있는 사람이어야 합니다.

핵심

영역은 3주차까지 바뀔 수 있습니다. 인터뷰에서 전혀 다른 것이 나오면 그쪽으로 옮기면 됩니다.

3. 내 프로젝트의 목표 수준

하나만 고르세요. 솔직하게 적어야 나중에 스스로를 속이지 않습니다.

• A. 학점만 무난하게 (주당 5시간 이내 투입)
• B. 제대로 된 포트폴리오 하나 만들기 (주당 8~12시간)
• C. 공모전 출품 / 창업 / 논문까지 (주당 15시간 이상)

그렇게 고른 이유:

(예: 전원 B에 합의. 단, ○○는 취업 준비로 10~12주차에 시간이 적음.
     해당 기간에는 문서·테스트 위주로 분담하고, 5~9주차에 더 투입하기로 함.)

4. 저장소 운영 경로

이것을 먼저 정합니다. 아래 작업 규칙의 형태가 여기서 결정됩니다.
저장소 운영 방식 선택 가이드를 읽고 본인 상황에 맞는 경로를 고르세요.

계정을 만들 수 없어도 평가에서 불이익이 없습니다. 경로 B로 진행하면 됩니다.

5. 작업 규칙

혼자 하더라도 규칙이 없으면 12주차에 무너집니다. 미래의 나를 위한 약속입니다.

참고

1주차에 다 못 정해도 됩니다. 이 절은 선택 항목입니다.
다만 9주차 개발 계획 전까지는 채워야 합니다 — 그때부터 이 규칙대로 작업하게 됩니다.

주의

"열심히 하자" 같은 문장은 규칙이 아닙니다. 언제·무엇을 하는지가 적혀야 합니다.

주의

main에 직접 커밋하지 않는다 — 혼자일수록 지키기 어렵고, 지키면 가장 크게 남습니다.
브랜치와 변경 요청이 없으면 리뷰 짝이 볼 것도, 학기 말에 보여줄 이력도 남지 않습니다.

6. AI 사용 기준

이 프로젝트에서 여러분은 팀장이고, AI가 팀원입니다.
팀장이 하는 일은 코딩이 아니라 지시 · 검수 · 반려입니다. 그 기준을 여기에 미리 정합니다.

주의

③ 「내가 설명 못 한다」를 반드시 넣으세요. 이 과목의 기준은 15주 내내 같습니다 —
맞는 코드라도 설명하지 못하면 없는 것으로 칩니다. → AI 활용 가이드북

매주 AI 사용 로그에 반려 최소 1건을 적습니다. 그 기록이 여러분이 판단했다는 흔적입니다.

7. 스스로에 대한 기준

혼자 하면 미루는 것을 말려줄 사람이 없습니다. 미리 정해 두세요.

진도가 밀렸다고 판단하는 기준:

(예: 2주 연속 스프린트 목표를 못 채우면, 그 주 안에 Must 기능을 하나 줄이고
     프로젝트 계획서를 고쳐 다시 제출한다.)

막혔을 때 도움을 청하는 기준:

(예: 같은 오류로 2시간을 넘기면 리뷰 짝에게 먼저 묻고,
     그래도 안 되면 다음 수업 코칭 시간에 가지고 온다.)

핵심

2시간 규칙은 이 과목이 매주 확인하는 것입니다. 혼자 붙들고 있는 시간은 배우는 시간이 아닙니다.

8. 서명

나는 위 기준을 따르며, 바꿔야 할 일이 생기면 이 문서를 고쳐 다시 제출한다.

작성 예시

취업 포트폴리오로 쓸 것 하나가 필요하다. 다만 10~12주차에 인턴 지원이 겹친다.
→ 그 기간에는 새 기능을 늘리지 않고 테스트와 문서만 채운다.
→ 대신 5~9주차에 더 투입한다. 이걸 지금 적어두지 않으면 12주차에 Must를 못 줄인다.

2주 연속 스프린트 목표를 못 채우면, 그 주 안에 Must 기능을 하나 줄이고
이 계획서를 고쳐 다시 제출한다. 미루지 않기 위해 리뷰 짝에게 먼저 말한다.

제출 체크리스트

• 자신 있는 것 / 배우고 싶은 것을 솔직하게 채웠는가
• 목표 수준(A/B/C)을 고르고, 왜 그렇게 골랐는지 적었는가
• 탐색 영역에 만날 수 있는 사람 3명이 이름이나 관계로 적혔는가
• 저장소 운영 경로를 정하고 저장소 주소를 적었는가
• 리뷰 짝이 그 저장소를 볼 수 있는가
• AI 사용 기준에 지시 · 검수 · 반려가 각각 적혔는가
• 「스스로에 대한 기준」이 구체적인가 ("열심히 하자" 같은 문장 금지)

사용 주차: 1주차 작성 → 1~2주차 사이 실시 → 2주차 전사록 제출
제출: 과제 제출 페이지에서 «인터뷰 스크립트» 와 «인터뷰 전사록»(대상자별)

인터뷰의 제1원칙

해결책을 묻지 마세요. 경험을 물으세요.

사용자는 자기가 무엇을 원하는지 모릅니다. 하지만 자기가 어제 무엇을 했는지는 정확히 압니다.
"이런 앱 있으면 쓰시겠어요?"라는 질문에서는 아무것도 나오지 않습니다.

1. 인터뷰 설계

참고

탐색 영역이 먼저입니다. 프로젝트 계획서의 「2. 탐색 영역」을 정한 뒤에 이 표를 채웁니다.
영역 없이 "알아내려는 것"을 쓰면 질문이 막연해집니다.

📌 질문지는 한 사람에 하나입니다. 리뷰 짝이 각자 다른 사람을 만나더라도 같은 질문지를 씁니다.
질문이 서로 다르면 2주차에 답을 비교할 수 없습니다.

📌 아래 예시는 «중고거래»를 탐색 영역으로 고른 내 것입니다.
여러분이 1주차에 정한 영역으로 바꿔 쓰세요. 형식만 참고하면 됩니다.

2. 질문지

도입 (5분) — 긴장 풀기

1. 간단히 자기소개 부탁드립니다. 요즘 어떤 하루를 보내시나요?
2. (주제 영역)과 관련해서 평소 어떤 일을 하시나요?

경험 캐기 (20분) — 핵심

1. 가장 최근에 (주제 상황)을 겪었던 게 언제인가요?
2. 그때 있었던 일을 처음부터 순서대로 말씀해 주시겠어요?
3. 그 중 가장 짜증났던/힘들었던 순간은 언제였나요? 왜요?
4. 그때 어떻게 해결하셨나요? (해결 못 했다면) 왜 못 하셨나요?
5. 그 문제 때문에 시간이나 돈을 따로 쓴 적이 있나요?
6. 주변 사람들은 이 상황을 어떻게 하던가요?

심화 (10분) — 주제에 맞게 직접 작성

9.
10.
11.

마무리 (5분)

1. 오늘 이야기 중에 제가 놓친, 꼭 하고 싶은 말씀이 있으신가요?
2. 비슷한 경험이 있는 분을 한 분 소개해 주실 수 있나요?

"왜요?"를 최소 5번 쓰세요. 표면적인 대답 아래에 진짜 이유가 있습니다.
침묵이 흘러도 먼저 말을 채우지 마세요. 3초를 기다리면 사용자가 채웁니다.

3. 인터뷰 실시 기록

대상자 실명은 기록하지 않습니다. P1, P2 같은 익명 ID를 쓰세요.
녹음 전 반드시 구두 동의를 받고, 그 동의 발언 자체를 녹음에 포함하세요.

4. 전사록 작성 규칙

전사(transcription)는 AI를 써도 됩니다. 단, 반드시 원본 음성과 대조하며 검수하세요.
전사는 AI 도구로 합니다. 손으로 받아 적지 마세요.
다만 AI 전사는 고유명사·숫자·말끝을 자주 틀립니다.

전사록 파일 형식 (docs/interviews/P1.md):

# 인터뷰 P1
- 일시 / 소요시간 / 진행자 / 대상자 프로필(익명)

## 전사
[00:02:14] 진행자: ...
[00:02:31] P1: ...

## 관찰 노트 (말이 아닌 것)
- 표정/망설임/한숨이 나온 지점
- 말과 행동이 어긋난 지점  ← 여기에 인사이트가 있습니다
- 인터뷰 후 떠오른 생각

## 인상적인 발언 3개 (그대로 인용)
1. "..."
2. "..."
3. "..."

작성 예시

[00:12:04] 진행자: 장소를 먼저 제안해 보신 적이 있으세요?
[00:12:09] P1: 음... (3초) 사실 거의 못 물어봤어요.
[00:12:14] 진행자: 왜요?
[00:12:16] P1: 제가 재촉하는 사람처럼 보일까 봐요. 아직 기한도 안 됐는데
           확인하면 좀 그렇잖아요. 못 믿는 것처럼.
[00:12:28] 진행자: 그러면 약속 상황은 어떻게 아셨어요?
[00:12:31] P1: 몰랐죠. (웃음) 마감 이틀 전에 알았어요. 그래서 제가 다 했어요.

제출 체크리스트

• 실제 사람 3명 이상 (리뷰 짝·수강생·가족 제외)
• 해결책이 아니라 과거 경험을 물었는가
• 전사록에 타임스탬프가 있고 원본과 대조 검수했는가
• 관찰 노트(말이 아닌 것)가 각 인터뷰마다 있는가
• 인용 가능한 실제 발언이 인터뷰당 3개 이상 확보되었는가

사용 주차: 2주차 (수업 중 워크샵)
제출: 과제 제출 페이지에서 «공감지도» 선택
인터뷰 데이터를 해석하는 단계입니다. 요약이 아닙니다.

참고

채우는 과정 전체를 보고 싶다면 2주차 시연 — 인사이트 뽑기를 보세요.
전사록에서 카드를 자르고 묶어 이 표를 채우기까지가 실제 문장으로 나와 있습니다.

1. 페르소나 (인터뷰에서 도출)

AI로 만들어낸 가상 인물이 아니라, 실제 인터뷰 대상자를 합성한 것이어야 합니다.
모든 항목 옆에 근거가 된 대상자 ID(P1, P2…)를 적으세요.

2. 공감지도

각 칸에 인용문 또는 관찰 사실을 넣으세요. 내 추측을 넣으면 안 됩니다.

👂 SAYS — 실제로 한 말 (그대로 인용)

"..." (P1)
"..." (P2)

🤔 THINKS — 말하지 않았지만 생각하는 것 (근거 필수)

- (내용) ← 근거: P1이 ○○ 질문에서 3초 망설임

🏃 DOES — 실제로 하는 행동

-

❤️ FEELS — 감정

- (감정) ← 근거: P2 "..." 발언 시 한숨

3. PAINS & GAINS

4. 인사이트 10개

인사이트 ≠ 요약.
요약: "사용자는 앱이 복잡해서 불편해한다." → 누구나 아는 말. 쓸모없음.
인사이트: "사용자는 앱이 복잡해서가 아니라, 실수했을 때 되돌릴 방법이 없어서 신중해지고 결국 포기한다."

좋은 인사이트에는 긴장(tension) 이 있습니다. "A를 원하면서 동시에 B를 한다" 같은 모순.

10개를 아래 형식으로 씁니다. 표로 써도 되지만, 목록이 쓰기 편합니다.

**1.** (인사이트 한 문장)
- 근거: "..." (P1)
- 놀라운가: ☐

1.

• 인사이트:
• 근거:
• 놀라운가: ☐

2. ~ 10. (같은 형식)

놀라운가? = 인터뷰 전에 우리가 예상하지 못했던 내용인가.
체크된 것이 3개 미만이면, 인터뷰를 제대로 안 했거나 데이터를 겉핥기로 읽은 것입니다.

5. AI 활용 기록 (이 주차)

AI가 놓친 것을 반드시 1개 이상 적으세요. AI는 문장은 잘 묶지만 침묵·망설임·모순처럼 전사록에 안 적힌 것을 못 봅니다. 거기에 인사이트가 있습니다.

작성 예시

"제가 재촉하는 사람처럼 보일까 봐 못 물어보겠더라고요." (P1)
"그냥 제가 하는 게 마음이 편해요. 싸우는 것보단 낫잖아요." (P3)

- 먼저 제안하면 상대가 나를 재촉하는 사람으로 볼 것이다
  ← 근거: P1이 "재촉" 질문에서 3초 망설인 뒤 웃으며 넘어감
- 사실 아무도 안 하고 있을까 봐 확인하기가 무섭다
  ← 근거: P3 "확인 안 하는 게 아니라 못 하는 거예요"

- 카톡방에 안부처럼 돌려 물어봄 ("다들 잘 되어가?")
- 답이 없으면 재차 묻지 않고 그냥 기다림 (P1, P3)
- 마감 2일 전에 혼자 밤을 새움 (P3)

- 불안 ← P1이 "마감 전 일주일은 잠을 잘 못 자요"
- 미안함 ← P3 "제가 자꾸 물어보면 상대가 귀찮아할 것 같아서요"

제출 체크리스트

• 공감지도의 모든 칸에 근거(인용/관찰) 가 붙어 있는가
• 페르소나가 실제 인터뷰 기반인가 (상상 금지)
• 인사이트 10개 중 "놀라운 것"이 3개 이상인가
• AI가 놓친 것을 1개 이상 찾아 기록했는가

사용 주차: 3주차 (개인 후보 3개 사전 제출 → 수업 중 확정)
제출: 과제 제출 페이지에서 «문제 정의서» 선택 → 채우고 제출

왜 이 문서가 가장 중요한가

캡스톤이 실패하는 1순위 원인은 기술력 부족이 아니라 문제를 잘못 정의한 것입니다.
문제가 틀리면, 그 위에 쌓은 15주치 코드는 전부 낭비입니다.

좋은 문제의 3가지 조건

1. 구체적인 사람이 있다 — "대학생"은 사람이 아닙니다. "이번 학기에 처음 중고 물건을 팔아본 3학년"이 사람입니다.
2. 이미 대가를 치르고 있다 — 그 사람이 지금 시간·돈·감정을 쓰고 있다는 근거가 있다.
3. 아직 안 풀렸다 — 이미 좋은 해결책이 있다면, 그건 문제가 아니라 시장입니다.

1. POV (Point of View) 문장

[ 사용자 ] 는 [ 니즈 ] 가 필요하다.

왜냐하면 [ 인사이트 ] 이기 때문이다.

작성 예시:
[이번 학기에 처음 중고 물건을 팔아본 3학년 학생]은
[리뷰 짝이 실제로 일을 하고 있는지 눈치 보지 않고 확인할 방법]이 필요하다.
왜냐하면 [진행 상황을 물어보는 행위 자체가 리뷰 짝을 불신하는 것처럼 보일까 봐,
판매자는 먼저 제안하지 못한 채 눈치만 보다가 결국 거래가 흐지부지되기] 때문이다.

내 프로젝트의 POV:

2. HMW (How Might We) 질문

POV를 3~5개의 실행 가능한 질문으로 쪼갭니다.

너무 넓으면: "어떻게 하면 중고거래를 잘 되게 할까?" → 아무것도 못 함
너무 좁으면: "어떻게 하면 진행률 바를 넣을까?" → 이미 해결책임
적당하면: "어떻게 하면 서로 묻지 않아도 만날 장소와 시간이 자연스럽게 좁혀질까?"

4주차 Ideate에서 집중할 HMW 1~2개:

3. 문제 정의 요약

4. 문제의 근거 (Evidence)

주장이 아니라 데이터를 적으세요.

5. 성공의 정의

15주 뒤, 무엇이 관찰되면 우리는 성공했다고 말할 수 있는가?

"많은 사람이 좋아한다" 같은 건 지표가 아닙니다. 14주차에 실제로 측정할 수 있는 것만 적으세요.

6. 스코프 경계 (매우 중요)

"하지 않는 것" 목록이 비어 있으면 12주차에 무너집니다.
로그인·결제·관리자 페이지·추천 알고리즘·모바일 앱 — 이 중 정말 필요한 것이 몇 개입니까?

7. AI 활용 기록 (이 주차)

3주차 필수 실습: AI에게 우리 문제 정의를 반박시키기.
반박 내용 중 수용한 것 1개와 반려한 것 1개를 반드시 기록하세요.

작성 예시

[이번 학기에 처음 중고 물건을 팔아본 3학년 학생]은
[상대에게 계속 묻지 않고도 만날 장소와 시간이 좁혀지는 방법]이 필요하다.
왜냐하면 [먼저 장소를 제안하는 행위가 상대를 재촉하는 것처럼 보일까 봐
서로 미루다가 대화가 끊기고 거래가 흐지부지되기] 때문이다.

[전공 강의에서 실시간 자막 없이 수업을 듣는 청각장애 학생]은
[교수의 발화를 놓쳤을 때 강의 흐름을 잃지 않고 따라잡을 방법]이 필요하다.
왜냐하면 [속기 지원은 신청 절차가 길고 모든 수업에 배정되지 않으며,
녹음을 나중에 듣는 방식은 그 수업 시간 안에서 질문할 기회를 이미 놓치기] 때문이다.

제출 체크리스트

• POV 문장에 해결책 단어가 없는가
• 타깃 사용자가 "상황"까지 구체적인가
• 모든 주장에 인터뷰 근거가 붙어 있는가
• 성공 지표가 14주차에 실제 측정 가능한가
• "하지 않는 것" 목록이 3개 이상인가
• AI 반박 중 반려한 것과 그 이유가 적혀 있는가

사용 주차: 3주차 v0.1 작성 → 이후 계속 갱신 (버전 기록 필수)
제출: 과제 제출 페이지에서 «PRD» 선택 → 채우고 제출 (갱신할 때마다 다시 제출)

0. 이 문서를 쓰는 법

PRD는 "무엇을 왜 만드는가" 를 적는 문서입니다. "어떻게 만드는가"는 여기 쓰지 않습니다(그건 8주차 아키텍처 문서).

주의

AI로 PRD 초안을 만드는 것은 허용됩니다. 그대로 제출하는 것은 금지입니다.
AI는 그럴듯하지만 일반적인 PRD를 씁니다. 여러분의 인터뷰 데이터가 안 들어간 PRD는 어느 것이든 상관없는 문서이며, 0점입니다. 초안 생성 후 반드시 §2·§4를 직접 다시 쓰세요.

1. 개요

2. 배경 및 근거

여기가 여러분의 PRD를 여러분 것으로 만드는 부분입니다. 인터뷰 데이터를 직접 인용하세요.

문제 상황:

사용자 근거:

기존 대안과 그 한계:

3. 목표와 비목표

목표 (Goals)

1.
2.
3.

비목표 (Non-Goals) — 이번 학기에 하지 않는 것

1.
2.
3.

비목표를 적어두면 12주차에 "이것도 넣을까?" 하는 유혹을 이길 수 있습니다.

4. 사용자 시나리오

기능 목록보다 시나리오가 먼저입니다. 사용자가 어떤 상황에서 이걸 꺼내드는지 서술하세요.

시나리오 1 (핵심):

(누가) ○○는 (언제/어디서) △△한 상황에서
(무엇을 하려고) □□하려 한다.
(현재) 지금은 ~~하게 하고 있어서 ~~한 문제가 있다.
(우리 제품으로) 우리 제품에서는 ~~ → ~~ → ~~ 순서로 진행하고,
(결과) 결과적으로 ~~를 얻는다.

시나리오 2:

5. 기능 요구사항

MoSCoW 기준

• Must — 이게 없으면 제품이 아님. 혼자 하는 프로젝트는 2~3개를 넘기지 마세요.
• Should — 있으면 확실히 좋음. 시간 남으면.
• Could — 여유가 있을 때만.
• Won't — 이번 학기엔 안 함 (비목표와 연결).

주의

Must가 4개 이상이면 반드시 미완성으로 끝납니다. 지금 줄이세요. (혼자 6주 기준)

6. 비기능 요구사항

비기능 요구사항을 빈칸으로 두면 12주차에 "돌아가긴 하는데 쓸 수 없는 것"이 나옵니다.

7. 화면 및 흐름 (요약)

사용자 플로우:

(예: 진입 → 로그인 → 거래 열기 → 가능 시간 선택 → 약속판 → 확정 알림)

8. 데이터 (개요)

개인정보가 하나라도 있으면 8주차 설계에서 별도로 다룹니다. 지금은 목록만.

9. 오픈 이슈

10. AI 활용 기록

작성 예시

판매자는 만날 장소를 모르는 게 아니다. 제안할 방법이 없어서가 아니라,
먼저 제안하는 행위가 재촉으로 읽힐까 봐 제안하지 못한다. 결과적으로 대화가 끊긴 뒤에야
알게 되고, 그때는 거래를 접는 것 말고 선택지가 없다.

제출 체크리스트

• §2 배경에 내 프로젝트 인터뷰 인용이 들어 있는가 (AI 문장 그대로 X)
• Must 기능이 6개 이하인가
• 모든 기능이 시나리오나 인터뷰 근거로 연결되는가
• 비기능 요구사항에 측정 방법이 적혀 있는가
• 비목표(Non-Goals)가 3개 이상인가
• 인용한 외부 사례의 URL을 직접 열어서 확인했는가

사용 주차: 3주차 작성 → 9주차에 이슈로 전환 → 10~12주차 구현
제출: 과제 제출 페이지에서 «사용자 스토리» — 스토리 1개당 한 건씩 제출 (9주차부터는 이슈 보드가 정본)

왜 사용자 스토리인가

"로그인 기능 구현"은 할 일입니다. 왜 하는지, 언제 끝난 건지 알 수 없습니다.
사용자 스토리는 누구를 위해, 왜, 무엇이 되면 끝인지를 한 줄에 담습니다.

그리고 이 과목에서 더 중요한 이유가 있습니다.

인수조건이 명확한 스토리는 AI에게 시킬 수 있는 단위입니다.
"쇼핑몰 만들어줘"는 AI가 실패합니다. 인수조건 3줄짜리 스토리는 성공합니다.
즉, 스토리를 잘 쪼개는 능력이 곧 AI를 잘 쓰는 능력입니다.

스토리 작성 형식

As a [사용자 유형],
I want [무엇을 하기],
So that [어떤 가치를 얻기 위해]

인수조건 (Acceptance Criteria) — Given/When/Then

Given [사전 상태]
When [사용자 행동]
Then [관찰 가능한 결과]

작성 예시

### US-03 · 상대와 겹치는 시간 확인
**As a** 중고 물건을 파는 사람,
**I want** 상대에게 직접 묻지 않고 서로 가능한 시간이 겹치는 구간 보기,
**So that** 재촉하는 것처럼 보이지 않으면서 만날 시간을 정할 수 있다.

**인수조건**
- [ ] Given 양쪽이 가능 시간을 3개씩 골랐고, When 판매자가 약속판에 진입하면,
      Then 겹치는 시간이 이른 순서로 한 화면에 보인다.
- [ ] Given 겹치는 시간이 하나도 없고, When 약속판에 진입하면,
      Then 해당 작업이 시각적으로 구분되어 표시된다.
- [ ] Given 작업이 하나도 없고, When 약속판에 진입하면,
      Then 빈 상태 안내와 작업 추가 버튼이 보인다.

**관련 FR:** FR-02 · **우선순위:** Must · **추정:** M
**의존성:** US-01(로그인), US-02(거래 열기)

백로그

추정 단위: S (반나절) / M (1~2일) / L (3일 이상 → 더 쪼개세요)
L짜리 스토리는 AI에게도 사람에게도 실패합니다. 반드시 분할하십시오.

📌 아래 백로그 표는 스프레드시트로 대체해도 됩니다 (파일을 저장소에 넣고 링크).
다만 그 아래 스토리 상세와 인수조건은 반드시 마크다운으로 씁니다. 이슈 본문과 AI 프롬프트에 그대로 쓰이기 때문입니다.

Must (핵심 — 없으면 제품이 아님)