Design Thinking 8단계를 바탕으로 한 프로젝트 강의이며, 중간/기말고사 없이 3회 발표로 평가합니다.
강의: 19:00~22:00 (5404) · 3시간 블록 = 강의 40분 / 실습 80분 / 코칭·공유 60분

15주 지도

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

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

제출 규칙

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

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

워크샵형 강의는 재료가 없으면 성립하지 않습니다. 즉, 사전 제출물이 없으면 모임 시간에 그 재료부터 만들어야 하고, 그만큼 코칭 시간을 잃게 됩니다.

개인 저장소

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

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

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

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

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

AI 사용 정책

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

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

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

금지 사항

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

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

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

서식과 평가 기준

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

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

처음 들어갈 때 참여 코드 6자리를 한 번 넣습니다. 교수자가 알려 줍니다.
한 번 넣으면 다음부터는 바로 들어옵니다.

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

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

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

여러 강의가 함께 쓰는 구조

이 사이트는 강의 하나가 아니라 여러 강의를 담습니다.

교수자가 강의를 만든다  →  참여 코드 6자리가 나온다
수강자가 코드를 넣는다  →  그 강의 안에서 제출한다

• 강의별 분리: 제출물·임시저장·카드보드는 강의별로 완전히 나뉩니다. 다른 반 것은 보이지 않습니다.
• 시작일: 시작일은 강의마다 다르고, 주차와 마감이 그 날짜로 계산됩니다.
  • 다만 15주 구성·서식 15종은 이 강의 틀을 쓰는 강의가 함께 씁니다. 새로 여는 강의는 기본으로 «SW/AI 캡스톤디자인 (서식 간소화)» 틀(13종)을 씁니다.
• 역할: 그 강의 명단에 적힙니다 — 교수자 · 수강자 · 참관.
• 개설 권한: 강의를 만들 수 있는 계정만 따로 정해 둡니다 → firebase/SETUP.md 4장

새 강의를 여는 방법, 자료를 옮기는 방법은 모두 firebase/SETUP.md에 있습니다.

이 자료의 원본과 빌드

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

node site/dist.js      # 문서 빌드 + public/ 준비 (배포용)
node site/build.js     # 학습 자료(docs.html)만 다시 만들기

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

손대기 전에 해 볼 것

npm install     # 처음 한 번만 (확인용 도구. 배포물과는 무관합니다)
npm run try     # 내 컴퓨터에서 연습판 띄우기 — 진짜 데이터를 건드리지 않습니다
npm test        # 보안 규칙 111가지 확인 — «A반이 B반을 못 본다» 포함

보안 규칙을 고쳤다면 게시하기 전에 npm test 를 돌려 보세요.

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

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

다룰 내용

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

핵심

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

이 기준은 15주 내내 동일하게 적용됩니다. 세 번의 발표에서 저장소의 코드를 한 부분 골라 설명을 청하는데, 설명할 수 있으면 그것으로 완성입니다. 즉, 그 코드를 누가 썼는지는 묻지 않습니다. 설명이 되는지만 봅니다.

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

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

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

이 강의의 프로젝트 구조

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

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

주의

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

또한 팀장이므로 모든 영역을 직접 맡습니다. "나는 프론트만"이 불가능한 구조이고, 그게 이 강의가 개인 프로젝트인 이유입니다. 좀 부담스러우시겠지만, 그래야 15주차에 본인이 설명할 수 있는 것이 남습니다.

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

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

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

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

핵심

검수 기준은 지시하기 전에 정해 두시기 바랍니다. 받은 다음에 정하면 이미 그 결과에 설득당한 뒤가 됩니다.

③ 반려 — 이 강의가 실제로 보는 것

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

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

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

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

주의

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

실습 파트 (65분)

① 마크다운 15분 (15분)

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

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

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

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

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

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

가장 중요한 항목은 4. AI 사용 기준 인데, 방금 배운 지시·검수·반려를 본인 기준으로 옮겨 적는 칸입니다.

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

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

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

주의

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

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

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

이 강의는 특정 서비스를 요구하지 않습니다. 계정을 만들 수 없거나 학교 네트워크에서 막히는 경우 1주차에 확인하고 경로 B로 정합니다. 그대로 두면 기여가 15주 내내 남지 않아, 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건 → 서식 제출 페이지 «인터뷰 전사록» (대상자별 한 건씩)
   - **대상자 ID를 사람마다 다르게** (P1 · P2 · P3) 적고 한 건씩 따로 제출합니다
   - 같은 ID로 다시 제출하면 앞의 전사록을 덮어씁니다. 세 번 모두 P1로 내면 한 건만 남습니다
   - 제출 뒤 «제출함»에서 전사록이 3건인지 확인하세요
   - 타임스탬프 포함
   - 녹음 파일 업로드는 선택입니다 (올리면 교수자와 본인만 들을 수 있습니다)
   - 손으로 받아 적지 마세요. AI 전사 도구를 쓰고 결과를 붙여넣습니다
   - 검수는 «인상적인 발언 3개»로 뽑을 구간만 원본 음성과 대조하면 됩니다
   - 방법: AI 활용 가이드북 「부록 — 인터뷰 전사에 AI 쓰기」

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

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

제출 형식

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

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

# 인터뷰 P1

| 항목 | 내용 |
|---|---|
| 대상자 프로필 | 3학년. 지난달 중고로 아이패드를 팔려다 약속을 못 정해 거래가 무산됨 |
| 녹음 동의 | ☑ 구두 동의 확보 |

## 전사
[00:04:28] 진행자: 그래서 어떻게 하셨어요?
[00:04:31] P1: 제가 정해서 말했어야 하는데... 사실 거의 못 했어요.
[00:04:38] 진행자: 왜요?
[00:04:40] P1: 제가 재촉하는 사람처럼 보일까 봐요. "내일 3시에 어디로 오세요"
           이렇게 말하면 좀 그렇잖아요. 물건 파는 사람이 갑질하는 것 같고.

## 관찰 노트
- 04:17에서 3초 망설임 → 장소를 모르는 게 아니라 먼저 말하지 못하는 것
- 05:44의 "(웃음)"이 즐거움이 아니라 체념으로 들림

## 인상적인 발언 3개
1. "제가 재촉하는 사람처럼 보일까 봐요." (04:40)
2. "제가 정한 데가 그쪽한테 멀면 어떡하지." (05:06)
3. "사흘 동안 그러다가 그쪽이 그냥 안 읽더라고요." (05:27)

이번 주에 남길 것 하나 — 인터뷰 데이터에서 근거가 붙은 인사이트를 최소 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분) 인사이트 3개 이상: 각 인사이트에 근거 인용을 반드시 붙이기 — 서식 사이트 «인사이트 찾기»에서 AI 후보를 받아 다듬고 내가 찾은 것을 1개 이상 더해 고르면 공감지도 칸에 근거와 함께 들어갑니다. 원하면 카톡 링크로 외부 공감 투표를 받아 참고합니다

점검 항목

• 추측 여부: 공감지도 칸에 내 추측이 들어가 있지 않은가? 근거 없는 칸은 지웁니다
• 발언 출처: 감정·생각을 적은 칸에 어느 발언에서 나왔는지가 붙어 있는가?

교차 리뷰 (60분)

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

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

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

다음 주 서식

[3주차 모임 전까지]

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

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

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

마감: 모임 전날 자정

제출 형식

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

## 후보 1

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

**근거 인용:** "제가 재촉하는 사람처럼 보일까 봐요." (P1 04:40)
**해결책 단어 점검:** 앱·플랫폼·AI·자동화 포함 여부 ☑ 없음

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

강의 파트 (40분)

참고

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

다룰 내용

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

핵심

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

② POV에 해결책 단어(앱·플랫폼·AI·자동화)가 들어가면 실패입니다. 내 문장에서 그 단어를 찾아 지워 보세요. 지우고 나서도 문장이 성립하면 통과고, 말이 안 되면 문제 대신 답을 먼저 적어 둔 것이니 다시 써야 합니다.

③ HMW 범위 조절

④ PRD의 «비목표»(하지 않는 것)가 비어 있으면 12주차에 무너집니다. 로그인, 결제, 관리자 페이지, 추천 알고리즘. 이 중 정말 필요한 것이 몇 개인지 지금 따집니다.

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

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

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

실습 파트 (80분)

진행 순서

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

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

AI 반박 실습 (필수)

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

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

그리고 수용한 것 1개 / 반려한 것 1개를 고릅니다. 각각 왜 그렇게 정했는지를 옆 사람에게 말로 설명하되, 따로 제출할 것은 없고 반려한 것만 이번 주 AI 사용 로그의 «반려 기록»에 적으면 됩니다.
말이 막히면 그 문제는 아직 내 것이 아닙니다.

개인별 코칭 (50분)

1인당 6~7분씩입니다. 아래 네 질문을 받으니 미리 답을 준비해 오시기 바랍니다.

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

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

다음 주 서식

[4주차 모임 전까지]

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

2. 작업 — 필요 기술 리스트업 (모르는 것 위주로)

3. 개인 작업 — AI 사용 로그

※ 아이디어 발산은 4주차 모임에서 그 자리에 합니다. 미리 만들어 올 것이
  아니라, 위에서 고른 HMW 질문을 가지고 와서 함께 펼칩니다.

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

제출 형식

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

4주차 · Ideate — 발산·수렴과 주제 확정

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

강의 파트 (30분)

다룰 내용

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

핵심

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

첫 번째 아이디어를 그대로 가져가기가 참 쉽습니다. 고른 것이 아니라 그냥 남은 것입니다. 탈락 대안을 설명하지 못하면 그것은 선택이 아니라 관성입니다. (버린 것이 없으면 고른 것도 없습니다.)

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

"이 분야 논문 3편과 링크"를 시키면 링크가 나오는데, 그 링크를 실제로 클릭해 봅니다. (제목도 저자도 그럴듯하게 붙어 있어서 그냥 믿고 싶어집니다.)
몇 개는 아예 안 열립니다. 열리는 것도 전혀 다른 글인 경우가 있지요.
그 순간을 여러분들이 직접 한 번 겪어보시는 것이 이번 주의 요점입니다.

주의

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

실습 파트 (60분)

참고

아이디어는 여기서 만듭니다. 미리 만들어 오지 않으셔도 됩니다.
여러분들이 가지고 오실 것은 3주차에 고른 HMW 질문 하나뿐입니다. 그것이 오늘 발산의 과녁입니다.

진행 순서

1. (15분) 혼자 발산: 3주차에 고른 HMW 질문에 대한 답을 30개씩 만듭니다. (여기에서는 절대 비판도 실현 가능성도 아직 따지지 않습니다.)
2. (10분) 발산 추가: AI에게 그냥 시키면 이미 나온 것과 비슷하니 조건을 걸어야 합니다. (예: "내가 생각 못 했을 접근으로 10개 만들어 줘")
3. (10분) 그룹핑: HMW 질문에 대한 답 40개 안팎을 성격별로 묶습니다.
4. (15분) 수렴: 임팩트와 실현 가능성의 2×2 매트릭스로 만들어 후보 3개를 최종 선택합니다.

서식 사이트 «아이디어 찾기»에서 이 순서를 그대로 따라 하면(혼자 30개 → AI 발산 추가 → 묶기 → 2×2 → 후보 3개 → 방향과 탈락 이유) 결과가 문제 정의서 «아이디어 선정» 칸에 들어갑니다. 문제 정의서를 다시 내면 주제 확정 심사와 1차 발표 «아이디어 선정 과정»에 쓰입니다.

1. (10분) 선정 근거서: 왜 이것을 골랐고, 왜 나머지 2개는 버렸는지 씁니다.

점검 항목

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

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

각자 3분 발표하고 7분간 질의를 받는데, 아래 질문 중 3~4개가 나갑니다. (어느 것이 나올지는 미리 알려드리지 않습니다. 6개를 전부 준비해 오시기 바랍니다.)

발표 필수 항목

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

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

판정

보류는 벌이 아니라 보호입니다. 지금 며칠 늦는 편이 13주차에 갈아엎는 것보다 훨씬 쌉니다.
여기서 그냥 넘어간 문제는 13주차에 큰 비용으로 돌아옵니다. (그때는 고칠 시간 자체가 없습니다.)

교차 검토 (20분)

혼자 하는 프로젝트일수록 외부 시선이 귀합니다. 내 주제는 내가 오래 들여다볼수록 이상한 데가 잘 안 보이더군요. 옆 사람 주제를 반박하는 것이 이번 작업입니다. (칭찬은 하지 않습니다.)

반박은 이렇게 쓰시면 됩니다

핵심

반박을 잘 받는 것도 훈련입니다. 그 자리에서 답하려 하지 마시고 그냥 받아 적으시기 바랍니다.
여기서 막은 반박은 7주차 발표에서 그대로 다시 나옵니다. (지금 적어 두신 것이 그때 쓸 답입니다.)

다음 주 서식

[5주차 모임 전까지]

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

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

3. 개인 작업 — AI 사용 로그

4. (선택) Figma를 쓰고 싶다면 Figma 교육 요금제 학생 인증 신청
   - 인증에 시간이 걸립니다. 5주차 목업은 Google 계정만 있으면 되는 Google Stitch가 기본입니다

마감: 모임 전날 자정

제출 형식

서식 제출 페이지에서 «플로우·화면 목록» 선택 — 핵심 경로·화면·빈 상태를 함께 제출합니다.
글로 적지 않고 화면 지도로 그립니다: 핸드폰 · 웹 중 화면 모양을 고르고, 필요한 화면을 카드로 놓은 뒤 카드 오른쪽 ●를 끌어 다음 화면에 놓아 화살표로 잇습니다 — 한 화면에서 기능마다 갈라지는 길도 모두 그립니다. 기능마다 사용자가 보통 지나는 메인 흐름(카드의 ☆ 차례)과 무언가 잘못됐을 때 가는 예외 흐름(나머지 화살표)을 나누고, 이 서비스의 핵심 기능을 ★로 고릅니다 — 핵심 기능의 메인 흐름이 발표 시연 · 사용성 테스트 순서가 됩니다. 카드마다 목적 · 관련 FR과 «비었을 때 · 실패했을 때» 쪽지를 붙입니다. 서식 안이 좁으면 크게 그리기 ↗로 새 창을 열어 넓은 판에서 그립니다 — 왼쪽 도구함에서 화면 · 쪽지를 끌어다 놓고, 고친 것은 서식에 바로 들어갑니다.

진입 → 거래 열기(링크 공유) → 시간 고르기 → 약속판 확인

5주차 · Prototyping I — UX 프로토타입

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

강의 파트 (30분)

다룰 내용

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

핵심

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

빈 상태를 반드시 그립니다. 데이터가 하나도 없을 때, 로딩 중일 때, 에러일 때. 즉, 아무것도 없거나 잘못된 상황의 화면들입니다. 가장 자주 빠뜨리는 세 화면이라, 지금 정해 두면 13주차 라이브 데모를 준비하기 쉽습니다.

이번 주 AI 함정 — 맥락 유실

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

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

실습 파트 (80분)

진행 순서 — 3사이클 반복

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

2사이클 도구 — AI 목업 생성

기본은 Google Stitch, 막히면 쓰던 AI의 캔버스로. 30분 안에 가입·사용법 익히기에 시간을 쓰면 비평·수정 사이클이 사라지므로, 도구는 하나로 통일합니다.

핵심

목업 요청은 직접 쓰지 않아도 됩니다. 서식 제출 페이지 «AI 구현 요청 → 목업 요청» 탭에, 4주차에 낸 «플로우·화면 목록»(핵심 경로·화면·빈 상태)과 PRD의 한 줄 설명·타깃으로 만든 요청문이 있습니다. Stitch용과 채팅형 AI용(HTML 한 파일 클릭 목업) 중 하나를 복사해 붙여 넣고, 1사이클 손그림 사진을 함께 올리세요. 목록에 없는 화면을 AI가 멋대로 늘리지 않습니다.

📤 다 만든 목업은 링크로 냅니다. 모임이 끝나기 전에 «화면 목업» 서식에서 쓴 도구를 고르고 그 도구의 공유 링크를 아래 점검 · 상호 시연 기록과 함께 냅니다. 캡처해서 올릴 필요가 없습니다.

• Google Stitch — 담당 교수자 계정에 프로젝트를 공유하면(계정은 서식에 나옵니다) 화면 사진까지 교수자 화면에 저절로 모이고, 6시간마다 새로 가져오므로 고친 화면을 다시 낼 필요가 없습니다
• ChatGPT · Gemini · Claude 캔버스, Figma, 그 밖의 도구 — 로그인 없이 열리는 공유 링크를 넣습니다 (Figma는 «링크가 있는 누구나 볼 수 있음»)
• 고를 수 있는 도구는 담당 교수자가 강의마다 정합니다

주의

무료 범위·요금제는 자주 바뀝니다. 위 표는 2026년 9월 기준입니다.

표의 근거 자료

• Google Stitch: Complete Guide (2026)
• Stitch Review 2026 — AITrendTool
• Google Stitch 2.0 Review — Murat Esmer
• Google Stitch Clickable Prototypes
• Google Stitch 2.0 Review — ComputerTech
• Figma for Education 2026 — AIToolPick
• Figma Education Plan for College Students
• AI wireframe generators compared — LogRocket
• 6 Uizard Alternatives Tested (2026) — Banani
• Visily Review 2026 — Toolworthy

점검 항목

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

상호 시연 (60분)

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

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

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

다음 주 서식

[6주차 모임 전까지]

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

2. ★ 개발 환경 세팅 완료 (필수)
   - 리스크 2개와 관련된 API 키 발급, 계정 생성, 라이브러리 설치
   - 'Hello World' 수준이라도 실행되는 상태까지
   - 제출 서식은 없습니다. 6주차 모임 시작 때 실행 화면으로 확인합니다

3. 개인 작업 — AI 사용 로그

※ 2번을 안 해오면 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분 안에 끝나는지 실제로 재보세요

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

제출 형식

따로 제출하는 서식이 없습니다 (2026-10부터 «발표 구성서» 폐지). 서식 제출 페이지의 «자동으로 만들기 → 발표 자료» 에서 「1차 발표」를 고르면 슬라이드 순서가 자동으로 잡힙니다. 직접 적는 것은 두 가지 — 시연(보여줄 것·조작 순서) 과 시연이 실패하면 — 뿐이고, 적으면 자동으로 저장되어 PPT에 들어갑니다. 리허설 영상은 발표 모임에 가지고 옵니다.

이번 주에 남길 것 하나 — 각자 다음 8주를 어디에 쓸지 명확해진 상태로 나가는 것.

참고

발표 자료 — 서식 제출 페이지 «발표 자료»에 1차 발표 슬라이드 재료가 루브릭 필수 항목 순서로 모여 있습니다. «개요 복사»를 누르고 파워포인트 [보기 → 개요]에 붙여 넣으면 끝입니다. 슬라이드가 한 번에 만들어집니다.
발표는 심사가 아니라 방향 교정입니다. 오늘 받은 지적 가운데 무엇을 받아들이고 무엇을 흘려보낼지가 남은 8주를 어디에 쓸지 그대로 정해 줍니다.

6명이 각자 발표하는 기준으로 짠 시간표인데, 발표 자체가 곧 개인 단위 확인이라 따로 라운드를 두지 않습니다.

진행 방법

순서

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

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

평가

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

미리 알아두는 감점

질의응답

7번은 이 강의의 시그니처 질문입니다. 매 발표마다 최소 한 사람은 받습니다.
여러분이 팀장이고 AI가 팀원인 이상, 무엇을 만들게 했는지보다 무엇을 되돌렸는지가 팀장으로서 한 일이기 때문입니다.

교차 리뷰 (60분)

서면 리뷰에 담을 것은 셋입니다. 예를 들어 이런 식이면 됩니다.

여기서 정한 수용·거부가 그대로 9주차 스프린트 계획 «1차 발표 피드백 반영» 표의 재료가 되니, 왜 그렇게 정했는지까지 함께 적어 두면 다음 주에 같은 고민을 두 번 하지 않습니다.

정리 (20분)

오늘 발표 전체에서 자주 나온 유형을 이름 없이 짚습니다. 대개 아래 넷입니다.

다음 8주는 설계 → 구현 → 검증입니다. 속도는 8·9주차에 갈립니다. 여기서 정한 아키텍처와 백로그를 들고 남은 기간을 전부 달리게 되니까요.

다음 주 서식

[8주차 모임 전까지]

1. 피드백 정리 (따로 제출하지 않습니다)
   - 오늘 받은 지적 중 무엇을 수용하고 무엇을 거부할지
   - 거부한 것은 이유를 쓸 것 (수용만 있으면 반려)
   - ※ 9주차 스프린트 계획 «1차 발표 피드백 반영» 표에 담아 냅니다

2. 아키텍처 대안 3개 조사
   - AI에게 "우리 요구사항에 맞는 접근 3가지와 트레이드오프"를 시키고
   - 각 대안의 장단점 + 내 프로젝트 상황에서의 적합도를 정리
   - ※ 결정은 하지 말 것. 8주차 모임에서 함께 결정합니다
   - ※ 따로 제출하지 않습니다. 8주차에 ADR-0001 «검토한 대안»·«내 제약»으로 옮깁니다

3. 저장할 데이터 항목 전수 목록
   - 화면에 보이는 것부터 역산해서 뽑을 것
   - 개인정보 해당 여부 표시
   - ※ 8주차에 ADR-0001 «저장할 데이터 항목» 표로 옮깁니다

4. 개인 작업 — AI 사용 로그
   - 이번 주부터 세 칸: 무엇을 시켰나 · 무엇으로 검수했나 · 무엇을 왜 반려했나(5분)

마감: 모임 전날 자정

제출 형식

이번 주는 따로 내는 서식이 AI 사용 로그뿐입니다. 피드백 정리는 9주차 스프린트 계획의 «1차 발표 피드백 반영» 표로 냅니다(2026-10부터 «피드백 반영 계획서» 폐지 · 이미 낸 것은 스프린트 계획에 자동으로 옮겨집니다). 아키텍처 대안·데이터 항목은 조사만 해 오고 따로 내지 않습니다 — 8주차에 첫 ADR(ADR-0001)에 담아 냅니다.

발표 진행 규칙

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

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

강의 파트 (40분)

다룰 내용

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

핵심

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

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

② 내 역량은 가장 중요한 제약입니다.
"이 언어를 써 본 적이 없다"는 부끄러운 게 아니라 핵심 설계 입력값입니다. 즉, 숨길 것이 아니라 적어야 할 것입니다. 첫 ADR(ADR-0001)의 «내 제약»에 솔직하게 쓰고, 결정의 근거로 쓰시면 됩니다.

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

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

이번 주 AI 함정 — 동조 편향

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

주의

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

실습 파트 (80분)

진행 순서

1. (20분) 데이터 모델: 화면 목록에서 역산해 ERD 초안
2. (20분) 아키텍처 결정: 대안 3개를 놓고 토론. AI에게 반박도 요청하기
3. (25분) ADR-0001 작성: ADR 서식 — 7주차에 조사해 온 대안·데이터 항목은 ADR-0001에 옮겨 담습니다
4. (15분) API 명세 초안: 모듈 경계와 시그니처

ADR 필수 1건 (더 쓰는 것은 선택)

7주차 «아키텍처 대안 조사»는 따로 내지 않습니다. 조사한 대안은 ADR-0001의 «검토한 대안» 표로 옮깁니다.
«저장할 데이터 항목»은 PRD 기능·플로우에서 뽑은 후보가 «확인 필요» 표시로 미리 채워져 있습니다. 확인하고 고쳐서 냅니다.

점검 항목

• 대안 수: 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 빈 상태 안내와 추가 버튼이 보인다.

이번 주에 남길 것 하나 — CI가 실제로 돌아가는 저장소를 갖는 것.

🤖 AI 구현 요청 — 서식 제출 페이지 «AI 구현 요청»에서 먼저 사용하는 AI(저장소에서 코드를 고치는 도구 / 채팅형 AI)를 고르세요. 어떤 AI든 쓸 수 있습니다. 코딩 도구라면 프로젝트 맥락 파일(AGENTS.md 등)을 저장소에 두고, 채팅형 AI라면 대화 시작 메시지를 먼저 보낸 뒤, 스토리 하나씩 구현 요청을 복사해 붙여 넣으면 됩니다. PRD·스토리·화면·ADR에 쓴 것이 그대로 들어갑니다. 막히면 같은 화면의 «디버깅 요청»을 쓰세요.
이 주가 남은 6주의 개발 속도를 결정합니다.

강의 파트 (40분)

다룰 내용

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

핵심

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

이 문장이 9주차의 전부입니다. 이미 AI로 코드는 빠르게 만들어집니다. 문제는 그게 맞는지 확인할 방법이 없다는 것이고, 그 방법이 테스트와 CI입니다. 즉, 코드를 만드는 속도가 아니라 확인하는 속도가 남은 6주를 결정합니다.

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

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

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

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

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

실습 파트 (80분)

① 스프린트 계획 (30분)

스프린트 계획 서식을 채웁니다. 한 건만 냅니다 — Sprint 1을 자세히 쓰고, Sprint 2·3 목표는 «Sprint 2·3 목표»에 한 줄씩 적습니다. 스프린트가 바뀌면 같은 문서를 고쳐 다시 제출합니다.

• 이슈는 미리 채워져 있습니다. 사용자 스토리에서 가져온 이슈를 확인하고 고치면 됩니다
• «1차 발표 피드백 반영» 표도 이 서식 안에 있습니다 — 7주차에 정리한 받은 지적 · 출처 · 수용/거부 · 이유 · 반영 시점을 옮깁니다. 거부가 하나도 없으면 반려합니다 (옛 «피드백 반영 계획서»를 이미 냈다면 자동으로 옮겨져 있습니다)

주의

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가 절대 알아서 안 만듭니다. 빈 상태·에러·경계값을 인수조건에 명시하지 않으면 정상 경로만 나옵니다.

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

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

예외 경로는 AI가 알아서 만들지 않습니다. 인수조건에 빈 상태를 쓰지 않으면 정상 경로만 나옵니다.
빈 상태 · 에러는 인수조건에 직접 적습니다.

실습 파트 (90분)

진행

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

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

저장소를 화면에 띄우고, 임의의 한 곳을 골라 아래 네 질문을 받습니다. 어디를 고를지는 미리 알려드리지 않습니다.

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

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

점검 항목

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

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

15분 안에 함께 이야기합니다. 따로 제출하지 않습니다 — 막힌 것은 이 자리에서 Problem으로 꺼내고, 통합·디버깅 문제라면 AI 사용 로그의 «막혔을 때만 — 통합·디버깅» 칸에 남깁니다. 아래 순서를 지킵니다.

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

다음 주 서식

[11주차 모임 전까지 · Sprint 2]

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

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

3. 개인 작업 — AI 사용 로그
   - 세 칸(시킨 것 · 검수한 것 · 반려한 것)을 씁니다. «시킨 것»은 «AI 구현 요청»에서 복사한 요청으로 미리 채워집니다
   - 통합하다 막혔다면 «막혔을 때만 — 통합·디버깅» 칸에 실패 로그를 적을 것 (주간 회고는 따로 내지 않습니다)

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

제출 형식

따로 내는 서식이 없습니다 (2026-10부터 «통합 시도 기록» 폐지). 막힌 주에는 AI 사용 로그의 «막혔을 때만 — 통합·디버깅» 칸 세 개를 채웁니다. 이 내용이 «AI 구현 요청 → 막혔을 때» 디버깅 요청에 그대로 들어가고, 11주차 디버깅 클리닉에서 이 기록으로 함께 짚습니다.

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

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

강의 파트 (20분)

다룰 내용

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

핵심

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

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

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

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

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

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

주의

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

디버깅 클리닉 (60분)

각자 가져온 통합 실패 로그(AI 사용 로그 «막혔을 때» 칸) 중 3~4개를 골라 전체 앞에서 함께 해부합니다.

진행 방법

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

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

자주 나오는 통합 실패 유형

통합 데이 (70분)

점검 항목

• 오늘 안에 붙는가? 안 붙으면 무엇을 잘라야 붙는지 결정합니다
• 2시간 규칙: 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주 계획과 리스크
   ※ «발표 구성서»는 내지 않습니다. «자동으로 만들기 → 발표 자료»에서 순서가 자동으로 잡히고,
     시연(보여줄 것·조작 순서)·시연이 실패하면 두 칸만 적으면 PPT에 들어갑니다

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

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

4. 개인 작업 — AI 사용 로그

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

제출 형식

서식 제출 페이지에서 «사용성 테스트» 선택 — 한 건만 냅니다. 과업 3개는 플로우의 핵심 경로에서 미리 채워져 있으니 확인하고 고친 뒤, 참가자를 만날 때마다 참가자 표에 «간이»로 한 줄씩 더해 다시 제출합니다. 13~14주차 본 테스트 5명도 같은 문서에 이어 적습니다.

이번 주에 남길 것 하나 — 각자 남은 2주에 무엇을 해야 하는지 확정하고 나가는 것.

참고

발표 자료 — 서식 제출 페이지 «발표 자료»의 «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명 사용성 테스트 (이번 주의 핵심)
   - 실제 타깃 사용자. 수강자·가족 제외
   - 12주차와 같은 과업 3개를 '목표'로 제시할 것. 방법을 알려주면 안 됩니다
     ❌ "우측 상단 + 버튼을 눌러 시간을 추가해 보세요"
     ✅ "상대와 만날 수 있는 시간 3개를 골라 보세요"
   - 진행 중 힌트 금지. 물어보면 "어떻게 하시면 좋을 것 같으세요?"
   - 기록: 참가자 표에 한 줄씩 — 과업별 성공/실패/포기, 막힌 곳, 사용자 발언

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

3. 개인 작업 — AI 사용 로그

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

제출 형식

서식 제출 페이지에서 «사용성 테스트» 선택 — 12주차에 낸 같은 문서를 열어, 본 테스트 참가자를 만날 때마다 «본»으로 한 줄씩 더해 다시 제출합니다(5명). 종합 분석은 14주차에 저장소 문서(docs/usability/summary.md)로 쓰고 최종 보고서 4장에 요약합니다.

발표 진행 규칙

• URL 확인: 배포 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주 안에 할 수 있는 것만

사용성 테스트 템플릿 5절(종합 분석)을 저장소의 docs/usability/summary.md로 쓰고,
최종 보고서 4장 1절(사용자 테스트 결과)·4장 2절(향후 개발 방향)에 요약합니다. (서식 제출 페이지의 «사용성 테스트» 서식은 과업·참가자 표·관찰 노트만 받습니다)

점검 항목

• 묶음 검증: 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분)
   ※ «발표 구성서»는 내지 않습니다. «자동으로 만들기 → 발표 자료»의 「최종 발표」에서 순서가 자동으로 잡히고,
     시연(보여줄 것·조작 순서)·시연이 실패하면 두 칸만 적으면 PPT에 들어갑니다

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

4. 개인 제출
   - 기여 명세서 — «내가 담당한 것»·반려 사례 2건은 매주 AI 로그에서 자동으로 채워짐. 근거를 확인하고 «내가 내린 판단» 2건 이상을 쓸 것 (ADR 결정·거부한 피드백에서 후보가 미리 채워짐 — 확인·수정)
   - 상호 평가지 (비공개)

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

제출 형식

• 최종 보고서는 교수자가 나눠 주는 한글·워드 템플릿으로 작성합니다. 서식 제출 페이지의 «최종 보고서 자료» 에 15주 동안 낸 서식이 보고서 목차대로 정리되어 있으니, 절마다 «복사»를 눌러 템플릿에 붙여 넣고 내 말로 다듬으세요. 회색 [직접 작성] 부분(배포 URL, 못 한 것과 이유 등)은 직접 채웁니다.
• 기여 명세서는 서식 제출 페이지에서 «기여 명세서» 서식으로 제출합니다. 처음 열면 «내가 담당한 것»과 «AI 제안을 반려한 사례»가 매주 낸 AI 사용 로그에서 채워져 있으니, 근거를 확인·수정합니다. «내가 내린 판단»도 ADR 결정과 거부한 피드백에서 후보가 미리 채워지니, 내 말로 고치고 빠진 판단을 더해 냅니다.

# 기여 명세서 — 김서연

## 내가 담당한 것
| 주차 | 무엇을 | 근거 |
|---|---|---|
| 5 | 목업 3사이클, 기술 리스크 2개 선정 | 제출함 «리스크 리포트» 5주차 |
| 10 | US-03 조회 API + 테스트 4건 | 이슈 #14, 커밋 a1b2c3d |
| 11 | 상태 값 불일치 버그 원인 추적 | AI 사용 로그 11주차 «막혔을 때» |

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

## AI 제안을 반려한 사례 2건
- 위 2번 — join 방식 최적화 (우리 스키마에서 데이터 중복)
- UTC 기준 마감 판정 (경계값에서 하루 오차)

이번 주에 남길 것 하나 — "AI가 준 것을 언제 믿고 언제 의심해야 하는가?"에 대한 감각을 가지고 나가는 것.

참고

발표 자료 — 서식 제출 페이지 «발표 자료»의 «최종 발표»에 권장 시간(2·2·5·3·2·1분)과 함께 슬라이드 재료가 모여 있습니다. 최종 보고서는 «최종 보고서 자료»를 쓰세요.
결과물보다 그 감각이 이 강의의 진짜 산출물입니다.

진행 방법

발표 구성 (15분)

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

코드 설명 확인

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

평가

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

미리 알아두는 감점

질의응답

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

과정 확인

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

주의

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

팀장 라운드 (30분)

6명 각자 5분씩 말하고 질의를 받습니다.
이 강의는 수강자를 팀장, AI를 팀원으로 놓았습니다. 즉, 마지막 확인은 무엇을 만들었는가가 아니라 팀장으로서 무엇을 했는가입니다.

참고

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

마무리 (20분)

상호 총평 (10분)

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

과정 마무리 (10분)

정리하는 내용

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

마지막 메시지

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

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

사용 주차: 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

백로그

참고

우선순위는 PRD 기능 요구사항(FR)에서 정합니다. 스토리는 관련 FR의 우선순위를 따라갑니다.
스토리 크기: S (반나절) / M (1~2일) / L (3일 이상 → 더 쪼개세요). 추정은 스프린트 계획에 적습니다.
L짜리 스토리는 AI에게도 사람에게도 실패합니다. 반드시 분할하세요.

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

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

Should

Could / Won't

스토리 상세

위 표의 각 항목을 아래 형식으로 상세 기술합니다. (Must 스토리는 전부 필수)

US-01 · (제목)

As a ,
I want ,
So that .

인수조건

• Given , When , Then .
• Given , When , Then .
• (예외/빈 상태/에러 상태 최소 1개)

관련 FR:

US-02 · (제목)

As a ,
I want ,
So that .

인수조건

• Given , When , Then .

관련 FR:

INVEST 자가 점검

각 스토리가 아래를 만족하는지 확인하세요.

9주차: 이슈로 전환

• 단위: 스토리 1개 = 이슈 1개
• 이슈 제목: [US-03] 리뷰 짝 진행 상황 확인
• 이슈 본문: 스토리 + 인수조건을 체크박스로
• 라벨/분류: must / should / sprint-1 / 담당 영역
• 연결: 변경 요청 본문에 이슈 번호를 적어 이슈와 코드를 연결

이슈 트래커를 제공하는 호스팅을 쓸 수 없으면 스프레드시트 칸반(할 일 / 진행 / 리뷰 / 완료)으로 대체합니다. 열 구성과 기록 항목은 동일하게 유지하세요.
자세한 내용은 저장소 운영 방식 선택 가이드를 참고하시기 바랍니다.

제출 체크리스트

• 모든 Must 스토리에 인수조건이 3개 이상 있는가?
• 각 스토리에 예외/빈 상태/에러 인수조건이 최소 1개 있는가?
• L 크기(3일 이상) 스토리가 남아 있지 않은가?
• 인수조건이 "잘 동작한다" 같은 판정 불가 문장이 아닌가?
• 스토리와 PRD의 FR이 서로 연결되는가?

사용 주차: 8주차 ADR-0001 한 건 필수 → 더 쓰는 것은 선택 (중요한 결정마다 추가)
ADR-0001(아키텍처·데이터 결정) 에는 7주차에 조사해 온 대안·제약·데이터 항목을 담습니다. «아키텍처 대안 조사»는 2026-10부터 따로 내지 않습니다.
미리 채워짐: «저장할 데이터 항목» 후보는 PRD 기능·플로우에서 뽑아 «확인 필요» 표시로 들어가 있습니다. 확인하고 고쳐서 냅니다.
제출: 서식 제출 페이지에서 «ADR» 선택 → 결정 1건마다 따로 제출 (번호를 다르게)

왜 ADR을 쓰는가?

15주차 발표에서 반드시 이 질문을 받습니다.

"왜 그 기술을 선택했나요?"

이때 "인터넷에서 많이 쓴다고 해서요" 또는 "AI가 추천해서요"라고 답한다면, 그 사람은 설계를 했다고 보기 어렵습니다.
ADR은 결정의 순간에 그 이유를 남기는 문서인데, 나중에 쓰면 그 이유가 미화되고 왜곡되기 쉽습니다.

주의

이 강의에서 ADR이 특히 중요한 이유:
AI는 대안을 나열하고 장단점을 정리하는 데 매우 뛰어나니, 그건 AI에게 시키세요.
하지만 "내 프로젝트의 상황에서 무엇을 포기할 것인가" 는 AI가 대신 결정할 수 없습니다.
ADR은 "AI가 정리하고 사람이 결정한다"는 이 강의의 원칙이 문서로 드러나는 자리입니다.

파일명 규칙

docs/adr/0001-architecture-data.md
docs/adr/0002-auth-oauth-vs-session.md

템플릿 (이 아래를 복사해서 사용)

# ADR-0001: (결정 내용을 한 줄로)

- **날짜:** 2026-XX-XX

## 배경 (Context)

무엇을 결정해야 하는가? 왜 지금 결정해야 하는가?

## 검토한 대안 (Options)

### 대안 A: (이름)
- 장점:
- 단점:
- 내 프로젝트 기준 적합도:

### 대안 B: (이름)
- 장점:
- 단점:
- 내 프로젝트 기준 적합도:

### 대안 C: (이름)
- 장점:
- 단점:
- 내 프로젝트 기준 적합도:

## 결정 (Decision)

우리는 **(대안 X)** 를 선택한다.

**결정적인 이유 (한 가지):**


**이 결정으로 우리가 포기하는 것:**


> 포기하는 것이 없다면, 그건 결정이 아니라 그냥 유일한 선택지였던 것입니다.
> 진짜 결정에는 반드시 대가가 따릅니다.

<!-- 아래 두 절은 ADR-0001(아키텍처·데이터 결정)에만 씁니다 -->

## 내 제약

- 역량: (예: 백엔드는 실습에서만 해 봄)
- 기간: (예: 남은 개발 기간 6주)
- 예산·환경: (예: 무료 범위, GPU 없음)

## 저장할 데이터 항목

| 항목 | 설명 | 개인정보(O) | 어느 화면에서 |
|---|---|---|---|
| | | | |

«내 제약» 은 위 «검토한 대안»의 적합도를 판단하는 기준입니다. 일반적인 좋고 나쁨이 아니라 이 제약에 비추어 적합도를 적습니다.
«저장할 데이터 항목» 은 화면 목록에서 거꾸로 따져 3개 이상 빠짐없이 적습니다. 개인정보(O)가 있으면 그 처리도 결정에 넣습니다.

작성 예시

8주차 필수 ADR 1건 (2026-10부터 · 2건 → 1건)

1번(ADR-0001)만 필수입니다. 2번은 더 쓰고 싶을 때 고르는 선택 영역입니다.

2번을 쓴다면 사람마다 다르니, 6주차 리스크 리포트에서 "미해결"로 남은 항목을 고르시면 됩니다.

작성 시 흔한 실수

제출 체크리스트

• 결정 1건 = 파일 1개로 분리되어 있는가?
• 각 ADR에 대안이 2개 이상 검토되었는가?
• 결정적인 이유 한 가지가 적혀 있는가?
• 포기한 것이 명시되어 있는가?
• ADR-0001에 내 제약과 저장할 데이터 항목(3개 이상)이 있는가? («확인 필요» 표시를 모두 확인했는가?)

사용 주차: 9주차 3개 스프린트 계획 수립 → 10·11·12주차 실행
제출: 서식 제출 페이지에서 «스프린트 계획» — 한 건만 냅니다. 지금 스프린트를 자세히 쓰고 «Sprint 2·3 목표»를 한 줄씩 적어 두며, 스프린트가 바뀌면 같은 문서를 고쳐 다시 제출합니다 (작업 목록은 이슈 보드가 정본)
미리 채워짐: 이슈는 사용자 스토리에서, DoD는 프로젝트 계획서의 검수 기준에서 가져와 채워져 있습니다. 확인하고 고쳐서 냅니다.
1차 발표 피드백 반영도 이 문서 안에 씁니다 — «피드백 반영 계획서»는 2026-10부터 따로 내지 않습니다(이미 냈다면 자동으로 옮겨집니다).
이슈 트래커를 쓸 수 없으면 저장소 운영 방식 선택 가이드의 대체 수단을 사용하세요.

이 강의의 스프린트 구조

주의

Sprint 1에서 "화면만" 또는 "API만" 만들면 실패입니다.
얇더라도 끝에서 끝까지(end-to-end) 관통하는 경로 하나를 먼저 뚫어 두어야 11주차 통합이 수월합니다.

Definition of Done (DoD)

전체가 합의한 "끝났다"의 기준으로, 이 기준을 통과하지 못한 것은 진행 중입니다.
프로젝트 계획서의 검수 기준으로 미리 채워져 있으니, 9주차 모임에서 본인이 직접 확인하고 고치시기 바랍니다.

• 인수조건이 전부 충족됨
• 테스트 코드 작성 및 통과
• 자동 검증 통과 (CI 또는 로컬 검증 스크립트 — 린트 + 테스트)
• 리뷰 짝 1명 이상의 리뷰 승인 (변경 요청 승인 또는 리뷰 기록지)
• 통합본에 반영됨 (A는 변경 요청 병합, B는 커밋 묶음 반영)
• 작성자가 코드 동작을 설명할 수 있음 (AI 생성분 포함)
• (추가 규칙: )

CI를 쓸 수 없으면 3번을 "병합 전 scripts/check 실행 + 결과를 리뷰 기록지에 첨부" 로 바꿔 적습니다.
이 실행은 사람이 잊기 쉬우니 DoD에 명시해 두는 것이 특히 중요합니다. → 저장소 운영 방식 선택 가이드

참고

아래 스프린트별 이슈 표는 이슈 보드나 스프레드시트로 대체해도 됩니다.
다만 스프린트 목표 한 문장과 DoD는 마크다운으로 씁니다.

Sprint 1 — 핵심 기능 관통

Sprint 2·3 목표 (한 줄씩):

• Sprint 2 —
• Sprint 3 —

회고: 10주차 모임 중에 함께 이야기하며, 따로 제출하지는 않습니다.

Sprint 2 — 통합

Sprint 2가 시작되면 위 문서를 고쳐(어느 스프린트 · 목표 · 이슈) 다시 제출합니다. 새 건을 만들지 않습니다.

통합 계획 — 11주차 이전에 반드시

통합은 마지막에 하는 일이 아닙니다. 좀 억지스럽더라도 이번 스프린트 중반에 한 번 붙여 보시기 바랍니다.
일단 붙여 봐야 무엇이 안 맞는지 알 수 있고, 그걸 알아야 남은 기간에 고칠 수 있습니다.

Sprint 3 — 품질·배포

작업 분배 원칙

진행 관리

1차 발표 피드백 반영

7주차 발표·교차 리뷰에서 받은 지적을 무엇은 받아들이고 무엇은 거부할지 정합니다. 거부 항목이 하나도 없으면 반려합니다.

AI 활용 계획 (스프린트별)

작성 예시

제출 체크리스트

• 지금 스프린트 목표가 한 문장이고, «Sprint 2·3 목표»가 한 줄씩 있는가?
• Sprint 1이 end-to-end 관통을 목표로 하는가? (레이어별 분업 X)
• 모든 이슈에 담당자와 추정이 있는가?
• DoD에 본인이 실제로 합의했는가? (미리 채워진 것을 그대로 두지 않았는가?)
• «1차 발표 피드백 반영»에 거부 항목과 이유가 있는가?
• 백로그가 이슈(또는 본인이 정한 대체 보드)로 전부 등록되었는가?

사용 주차: 1주차부터 매주
제출: 서식 제출 페이지에서 «AI 사용 로그» 선택 → 주차를 바꿔 매주 따로 제출
제출로 대체할 수 없습니다. 이 로그가 개인 기여도 평가의 근거입니다.

왜 쓰는가?

이 강의에서 여러분은 팀장이고 AI는 팀원입니다. 그래서 이 로그는 감시 기록이 아니라 팀장의 작업 지시·검수 기록입니다.

이 강의는 AI 사용을 전면 허용하는 대신 "무엇을 시켰고, 받은 것을 어떻게 판정했는가?" 를 기록하게 합니다. 즉, 이 기록이 여러분이 실제로 한 일이며 배운 것입니다.

물론 코드는 AI가 쓸 수 있습니다. 하지만 "받은 것을 왜 채택했고 왜 반려했는가?"는 오직 여러분만 쓸 수 있습니다. 그것이 바로 이 강의가 평가하는 것입니다.

작성 시간: 주당 5분. 세 칸만 씁니다. 길게 쓸 필요는 없고, 대신 거짓 없이 써야 합니다.
«무엇을 시켰나»는 지난 마감 뒤 «AI 구현 요청»에서 복사한 요청으로 미리 채워지므로, 확인하고 검수·반려만 쓰면 됩니다.

주간 기록 형식 (아래를 매주 아래에 이어 붙이기)

2026-10(7주차)부터 세 칸으로 줄였습니다. 1~6주차에 이미 낸 로그는 옛 모양 그대로 인정합니다.

## Week XX (2026-XX-XX) — 이름

### 무엇을 시켰나
- (한 줄에 하나 — 예: US-03 구현 요청, 로그인 오류 원인 가설 3개 요청)

### 무엇으로 검수했나
- (한 줄에 하나 — 예: 인수조건 3개를 직접 실행, 빠진 테스트를 추가해 통과 확인)

### 🔴 무엇을 왜 반려했나 (필수)
- (AI가 준 것 중 되돌린 것 — 그리고 왜)

### 막혔을 때만 — 통합·디버깅 (선택)
- 기대한 동작 / 실제 동작:
- 에러 메시지 전문:
- 무엇을 해 봤고 어떻게 됐나:

«막혔을 때만» 칸은 막힌 주에만 채웁니다. 이 내용이 «AI 구현 요청 → 막혔을 때» 디버깅 요청에 그대로 들어가고, 11주차 디버깅 클리닉의 재료가 됩니다. «통합 시도 기록»은 2026-10부터 따로 내지 않고 이 칸으로 옮겼습니다.

검수 방법 예시: 테스트 실행 / 직접 실행해 확인 / 경계값 넣어보기 /
공식 문서 대조 / 원 출처 URL 직접 열기 / 리뷰 짝 리뷰 / 다른 방식으로 재계산

반려는 AI가 틀렸을 때만 하는 것이 아닙니다. 세 가지 경우가 있습니다.

경우	예
틀렸다	시간대를 UTC로 처리해 자정 근처에서 하루 오차가 남
맞지만 우리 것이 아니다	join 최적화 — 우리 스키마에서는 데이터 중복이 커짐
맞지만 내가 설명하지 못한다	동작은 하는데 왜 되는지 모르는 코드

반려 칸이 «없음»인 주는 그 주 로그를 인정하지 않습니다. 검수하지 않고 받아 쓴 것이기 때문입니다.
매주 최소 1건을 찾으세요. 반려할 것이 한 건도 없는 주는 없습니다.

작성 예시

## Week 10 (2026-XX-XX) — 김서연

### 무엇을 시켰나
- US-03 인수조건을 그대로 주고 테스트 코드 먼저 작성 요청
- 그 테스트를 통과하는 조회 API 구현 요청
- N+1 쿼리 최적화 제안 요청

### 무엇으로 검수했나
- 테스트 4개 중 빈 상태 케이스가 빠져 있어 1개 직접 추가 후 실행 — 3/4 통과, 실패 원인 직접 추적
- 밤 11시에 테스트 데이터를 넣어 경계값 확인

### 🔴 무엇을 왜 반려했나
- 겹치는 시간 판정 로직 — 시간대를 UTC로 처리해 자정~09시에 등록한 약속이 하루 일찍 '지난 약속'으로 표시됨 (틀렸다)
- join 방식 최적화 — 우리 스키마에서는 데이터 중복이 커짐. 별도 조회 후 메모리 병합으로 변경 (맞지만 우리 것이 아니다)

평가에 쓰이는 방식

하면 안 되는 것

서식 제출 서식

사용 시점: 매주 · 제출: 각 서식에 적힌 경로
주차별 서식을 어떤 형식으로 내는지 모아 둔 문서로, 해당 주차 서식을 복사해 채우면 됩니다.

공통 규칙

문서 산출물은 전부 서식 제출 페이지에서 제출합니다.
아래 서식들은 그 페이지에 그대로 들어 있고, 이 문서는 무엇을 어떻게 채우는지를 설명하는 참고 자료입니다.

저장소에 직접 쓰는 것은 이 넷뿐입니다: 이슈 본문, 변경 요청 본문, README, 소스 코드.

모든 제출물 머리말

> 주차: 3주차 서식 · 작성일: 2026-XX-XX
> 작성: 김서연
> 관련 서식: 04-problem-definition

머리말의 작성일이 작업 시점 확인에 쓰이므로 실제로 쓴 날짜를 적습니다.

서식 제출 페이지

https://capstone.mayai.kr/forms-firebase.html

• 작성 안내: 표를 직접 정렬할 필요가 없고, 항목마다 작성 방법과 예시가 붙어 있습니다.
• 실시간 점검: 제출 전에 체크리스트가 실시간으로 표시됩니다 (예: "Must 기능이 3개를 넘었습니다").
• 로그인: Google 계정으로 로그인합니다. 내가 낸 것만 고치거나 지울 수 있습니다.
• 제출함: 제출한 것은 제출함에서 다시 열어 수정하거나 숨길 수 있습니다 (본인 것만).

표를 손으로 그리지 마세요

마크다운 표를 직접 정렬해 쓰는 것은 이 강의에서 배울 것이 아니니, 아래 세 가지 방법 중 편한 것을 쓰시면 됩니다.

오른쪽이 마크다운인 이유는 판단과 근거가 담긴 글이기 때문이고, 평가에서 보는 것도 이 글입니다.
문법이 헷갈리면 마크다운 15분을 참고하시기 바랍니다.

1주차 → 인터뷰 전사록

제출: docs/interviews/P1.md, P2.md, P3.md (대상자 1명당 1파일)

> 주차: 1주차 서식 · 작성일: 2026-XX-XX
> 작성:

# 인터뷰 P1

| 항목 | 내용 |
|---|---|
| 대상자 프로필 | (익명. 학년·상황만. 실명 금지) |
| 녹음 동의 | ☑ 구두 동의 확보 |

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

## 관찰 노트 (말이 아닌 것)
- 망설임·한숨이 나온 지점:
- 말과 행동이 어긋난 지점:
- 인터뷰 후 떠오른 생각:

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

2주차 → 문제 정의 후보 (개인)

제출: 개인 저장소 이슈로 각자 등록 · 제목 [문제후보] 홍길동 1

## 후보 1

**POV**
[구체적 사용자]는 [무엇]이 필요하다.
왜냐하면 [인사이트]이기 때문이다.

**근거 인용:** "..." (P?)
**해결책 단어 점검:** 앱·플랫폼·AI·자동화 포함 여부 ☐ 없음

후보 3개를 각각 위 형식으로. 아이디어가 아니라 문제를 씁니다.

3주차 → 선행사례 조사표

제출: docs/04-benchmark.md

> 주차: 3주차 서식 · 작성일: · 작성:

# 선행·경쟁 사례 조사

## 사례 1 — (이름)
- 무엇을 하는가:
- 어떻게 쓰이나:
- 왜 부족한가: (우리 인터뷰 근거와 함께)
- 출처 URL:
- 직접 확인: ☐

## 사례 2 ~ 3 — (같은 형식, 최소 3건)

## 직접 써 본 것 (최소 1건)
- 서비스명 / 사용 시간 / 좋았던 점 / 불편했던 점

## 우리가 다르게 할 지점

주의

직접 확인 칸이 비어 있는 항목은 무효입니다. AI가 알려준 사례는 URL을 직접 열어 확인합니다.

이 조사표는 스프레드시트로 만들어 파일을 저장소에 넣고 링크만 걸어도 됩니다.
다만 "왜 부족한가"에는 일반적인 단점이 아니라 우리 인터뷰 근거가 들어가야 합니다.

4주차 → 사용자 플로우와 화면 목록

제출: docs/05-flow.md

# 사용자 플로우

## 핵심 경로 (1개만)
진입 → □□ → □□ → 목표 달성

## 화면 목록

| # | 화면 이름 | 이 화면의 목적 (한 줄) | 관련 FR |
|---|---|---|---|
| 1 | | | |

## 빈 상태·에러 화면
| 상황 | 무엇을 보여줄 것인가 |
|---|---|
| 데이터 0건 | |
| 로딩 중 | |
| 에러 | |

5주차 모임 중 → 화면 목업과 상호 시연

제출: docs/mockup.md — 서식 제출 페이지 «화면 목업»에서 냅니다 (2026-10 추가)

먼저 목업을 만든 도구를 고르고(Google Stitch · ChatGPT·Gemini·Claude 캔버스 · Figma · 그 밖의 도구 — 담당 교수자가 연 것만 보입니다) 그 도구의 공유 링크를 넣습니다.
Stitch는 담당 교수자 계정에 공유하면 화면 사진까지 교수자 화면에 저절로 모이고 6시간마다 새로 가져옵니다. 다른 도구는 로그인 없이 열리는 링크만 모입니다.

# 화면 목업과 상호 시연

## 목업 링크
| 도구 | 링크 |
|---|---|
| Google Stitch (또는 고른 도구) | https://… |

## 점검
| 항목 | 내용 |
|---|---|
| 핵심 경로 | 4화면 — □□ → □□ → □□ → □□ (3~5화면) |
| 빈 상태 · 에러 화면 | |
| 시나리오와 달라진 곳 | 없음 / 무엇을 고칠지 |

## 상호 시연 — 막힌 곳
| 화면 · 지점 | 무엇에서 막혔나 | 고칠 것 |
|---|---|---|
| | | |

5주차 → 리스크 리포트

제출: docs/06-risk.md

# 기술 리스크 리포트

## 상위 리스크 2개

### 리스크 1: (한 줄로)
- 이게 안 되면: (프로젝트에 미치는 영향)
- 확인 방법: (무엇이 되면 해결된 것인가)
- 검증 상태: ☐ 미검증 ☐ 검증됨 ☐ 불가 판정 → 대안:

### 리스크 2: (동일 형식)

개발 환경 세팅은 이 서식에 적지 않습니다. 6주차 모임 시작 때 실행 화면으로 확인합니다.

6·12·14주차 → 발표 구성서 (2026-10 폐지 — 따로 내지 않음)

슬라이드 순서는 서식 제출 페이지 «자동으로 만들기 → 발표 자료» 가 발표 차수별로 자동으로 잡습니다. 직접 적는 것은 두 칸뿐이고, 적으면 자동으로 저장되어 PPT에 들어갑니다.

7주차 → 피드백 반영 계획서 (2026-10 폐지 — 따로 내지 않음)

받은 지적의 수용·거부는 정리만 해 와서 9주차 스프린트 계획의 «1차 발표 피드백 반영» 표(받은 지적 · 출처 · 수용/거부 · 이유 · 반영 시점)에 담습니다. 옛 서식으로 이미 낸 것은 스프린트 계획에 자동으로 옮겨집니다.

거부한 항목이 하나도 없으면 반려합니다. 전부 수용했다는 것은 판단하지 않았다는 뜻입니다.

7주차 → 아키텍처 대안 조사 (2026-10 폐지 — 따로 내지 않음)

대안 3개와 저장할 데이터 항목은 조사만 해 와서 8주차에 첫 ADR(ADR-0001 — 아키텍처·데이터 결정)에 담습니다.

8주차 → 이슈 등록

제출: 이슈 트래커 (또는 칸반 보드)

제목: [US-03] 리뷰 짝 진행 상황 확인

**As a** 중고 물건을 파는 사람,
**I want** ...,
**So that** ...

## 인수조건
- [ ] Given , When , Then .
- [ ] Given , When , Then .
- [ ] (예외·빈 상태·에러 중 최소 1개)

우선순위는 PRD 기능 요구사항(FR)에서 정하고, 추정은 스프린트 계획에 적습니다. 이슈에는 라벨(must / should / sprint-1)만 붙입니다.

9주차 → 변경 요청 본문

제출: 변경 요청 (또는 리뷰 기록지)

## 무엇을
관련 이슈: #12

## 인수조건 충족 여부
- [x] 조건 1
- [x] 조건 2
- [ ] 조건 3 → 다음 변경에서

## 검증
- 테스트: 4/4 통과
- 자동 검증: 통과 (또는 `scripts/check` 실행 결과 첨부)

## 리뷰어가 봐줬으면 하는 곳

10주차 → 통합 시도 기록 (2026-10 폐지 — 따로 내지 않음)

막힌 주에만 AI 사용 로그의 «막혔을 때만 — 통합·디버깅» 칸에 적습니다. 이 내용이 «AI 구현 요청 → 막혔을 때» 디버깅 요청에 들어가고, 11주차 디버깅 클리닉의 재료가 됩니다.

성공한 통합보다 실패 로그가 더 중요한 기록입니다. 11주차 모임은 이 로그로 진행합니다.

11주차 → README

제출: 개인 저장소 루트 README.md

# (프로젝트명)

한 줄 설명

## 무엇을 해결하나
## 스크린샷 또는 데모 URL

## 설치
​```bash
​```

## 실행
​```bash
​```

## 환경변수
| 이름 | 설명 | 예시 |

## 프로젝트

12주차 교차 QA에서 다른 수강자가 이 README만 보고 여러분 서비스를 실행합니다. 질문은 받지 않습니다.

12주차 → 간이 사용성 테스트 (2명)

제출: 서식 제출 페이지 «사용성 테스트» 한 건 — 과업 3개(참가자 모두 같은 과업)를 정하고, 참가자 표에 «간이»로 한 줄씩 더해 다시 제출 (사용성 테스트 템플릿 4절)

13주차 → 사용성 테스트 5명

제출: 12주차에 낸 «사용성 테스트» 같은 문서에 참가자를 만날 때마다 «본»으로 한 줄씩 더해 다시 제출(5명) · 종합 분석은 저장소 docs/usability/summary.md → 최종 보고서 4장 1절 «사용자 테스트 결과»에 요약 (사용성 테스트 템플릿 5절)

14주차 → 최종 제출물

제출: 교수자가 나눠 주는 한글·워드 템플릿으로 작성 — 서식 제출 페이지 «최종 보고서 자료»에서 아래 목차대로 정리된 내용을 복사해 옮겨 씁니다

표지 — SW 종합설계 프로젝트 <최종 보고서> · 주제명 · <서비스명> · 이름 · 교수자 · 소속

요약문 (■ 개조식, 한 쪽)
1. 제목
2. 개발 목적 및 필요성
3. 제안 시스템 요약 — 1) 제안 시스템  2) 기능 설명
4. 향후 개발 방향 및 기대효과 — 1) 개발 결과  2) 기대효과 및 향후 계획

1장. 서론
  1절. 연구개발의 배경 — 분야 상황 → 사용자가 겪는 문제(인터뷰 근거) → 기존 방식의 한계
  2절. 연구개발의 목적 — 최종 목적 + 첫째·둘째·셋째 개발 목표

2장. 기존 시스템 분석
  1절. 핵심 기술 분석 — 쓰는 기술(라이브러리·API·DB)과 역할
  2절. 기존 서비스 및 기술 분석 — 가·나·다 + [표 1] 비교표

3장. 제안 시스템
  1절. 제안 시스템 — 목표 · 사용 흐름 · [그림] 기능 구성도
  2절. 주요 기능 — 가. ○○ 기능(이하 기능 1) …
  3절. 시스템 설계 — [그림] 시스템 아키텍처 · 구성요소와 선택 이유(ADR)

4장. 연구개발 결과
  1절. 최종 연구개발 결과 — 화면별 [그림] · 주요 알고리즘 [코드] · 사용자 테스트 결과(5명)
  2절. 향후 개발 방향 및 기대효과 — 1) 향후 추가 개발 방향(못 한 것과 이유)  2) 적용 분야 및 기대 효과

참고문헌

개인 제출: logs/contribution-홍길동.md

# 기여 명세서 — 홍길동

## 내가 담당한 것
| 주차 | 무엇을 | 근거 (이슈·작업 이력·문서) |
|---|---|---|
| 10 | US-03 조회 API + 테스트 | #14, 커밋 a1b2c3d |

## 내가 내린 판단 (코딩이 아니라 결정)
1.
2.

## AI 제안을 반려한 사례 2건
1.
2.

«내가 담당한 것»과 «AI 제안을 반려한 사례»는 서식을 처음 열면 매주 낸 AI 사용 로그에서 자동으로 채워집니다. 맞는지 확인하고 근거(이슈·커밋·문서)를 고쳐 적으면 됩니다.
«내가 내린 판단»(2건 이상)은 ADR 결정과 거부한 피드백에서 후보가 미리 채워집니다. 확인하고 내 말로 고쳐 냅니다 — 이 칸이 이 문서의 핵심입니다. 이 강의는 여러분을 팀장으로, AI를 팀원으로 놓습니다.
팀장의 성과는 팀원이 만든 결과물이 아니라 무엇을 어떤 조건으로 시켰고 무엇을 되돌렸는가입니다. 이 칸이 비어 있는 것이 감점 사유입니다.

기여 명세서는 매주 쓴 AI 사용 로그와 대조합니다. 로그에 없는 기여는 근거가 없습니다.

시점: 7주차 · 형식: 개인 발표 10분 + 질의응답 5분
배점: 100점 만점 (강의계획서 평가항목 배점으로 환산)

참고

1주차에 공개합니다. 평가 기준을 모른 채 준비하는 일이 없도록 합니다.

발표에 반드시 포함할 것

1. 우리가 만난 실제 사용자와 거기서 나온 인사이트
2. 문제 정의 (POV) — 왜 이 문제인가?
3. 아이디어 선정 과정과 탈락시킨 대안
4. 프로토타입 시연 (슬라이드 설명 아님)
5. 기술 리스크 — 무엇이 검증됐고 무엇이 아직 불확실한가?

평가 항목

1. 사용자 근거 (25점)

2. 문제 정의 (25점)

3. 아이디어 수렴 과정 (20점)

4. 프로토타입 (20점)

5. 발표 및 질의응답 (10점)

미리 알아두는 감점

참고

모두 미리 공개하므로 발표 당일에 처음 듣는 감점은 없습니다.
즉, 아래 항목만 피하면 감점은 발생하지 않습니다.

질의응답

준비된 발표만으로는 실제 이해도가 드러나지 않습니다. 아래에서 골라 묻습니다.

1. 인터뷰 대상자 중 여러분의 예상을 가장 많이 깬 사람은 누구였고, 무엇 때문이었나요?
2. 이 문제를 겪지 않는 사람은 누구인가요? 왜 안 겪나요?
3. 탈락시킨 아이디어 중 가장 아까웠던 것은? 왜 탈락시켰나요?
4. 지금 이 문제를 사용자들은 어떻게 버티고 있나요? 그 방법의 무엇이 부족한가요?
5. 여러분 프로토타입에서 가장 확신이 없는 부분은 어디인가요?
6. 15주차에 무엇이 관찰되면 성공한 건가요?
7. (AI 활용) AI가 준 것 중 반려한 것이 있나요? 왜 반려했나요?

시점: 13주차 · 형식: 개인 발표 10분 + 질의응답 5분
배점: 100점 만점

주의

이번 발표는 슬라이드가 아니라 라이브 데모가 중심입니다.
녹화 영상 대체는 감점입니다(네트워크 등 불가피한 사유는 사전 허가 필요).

발표에 반드시 포함할 것

1. 1차 발표 피드백을 어떻게 반영했는지
2. 아키텍처와 주요 설계 결정 (ADR 중 1건 이상 설명)
3. 라이브 데모 — 실제로 동작하는 것
4. 간이 사용성 테스트(2명) 결과
5. 남은 2주 계획과 리스크

평가 항목

1. 구현 완성도 (30점)

2. 설계와 근거 (20점)

3. 개발 프로세스 (20점)

참고

이 항목은 제출함과 저장소를 직접 확인해 채점합니다. 즉, 발표 내용보다 실제 작업 이력이 우선합니다.
문서 제출물은 서식 제출 페이지의 제출 시각으로, 코드 작업은 저장소 이력으로 확인합니다.
확인 대상은 택한 저장소 운영 경로에 따라 달라지며,
이슈·변경요청·CI 이력이 없으면 칸반 보드 + 리뷰 기록지 + 검증 스크립트 로그를 동등하게 인정합니다.

4. AI 활용의 질 (15점)

핵심

발표 중 코드 설명 확인을 합니다.
교수자가 저장소에서 한 부분을 고르면, 해당 담당자가 동작을 설명해야 합니다.

5. 사용자 검증 및 발표 (15점)

미리 알아두는 감점

참고

모두 미리 공개하므로 발표 당일에 처음 듣는 감점은 없습니다.
즉, 아래 항목만 피하면 감점은 발생하지 않습니다.

질의응답

1. 저장소의 이 부분(무작위 선택)은 무엇을 하는 코드인가요? 왜 이렇게 짰나요?
2. 이 기능을 AI에게 어떻게 시켰나요? 한 번에 됐나요, 몇 번 만에 됐나요?
3. AI가 준 코드 중 버린 것이 있나요? 왜 버렸나요?
4. 지금 이 시스템에서 가장 먼저 문제가 생길 것 같은 곳은 어디인가요?
5. 테스트가 없는 부분은 어디이고, 왜 없나요?
6. 통합할 때 가장 오래 걸린 문제는 무엇이었나요?
7. 남은 2주에 못 할 것 같은 것은 무엇인가요? (정직하게 답하면 가점)

시점: 15주차 · 형식: 개인 발표 15분 + 질의응답 5분
배점: 100점 만점 (개인 점수)

발표 구성 (권장 15분)

마지막 2개 항목은 생략하기 쉽지만, 가장 점수가 높은 구간입니다.

평가 항목

1. 문제-해결 정합성 (20점)

2. 구현 완성도 (25점)

3. 사용자 검증 (20점)

4. 공학적 프로세스 (20점)

참고

작업 시점을 확인합니다. 15주차에 몰아서 만든 문서는 이 항목에서 인정하지 않습니다.
확인 방법은 택한 저장소 운영 경로를 따릅니다 —
커밋 날짜, 또는 주차별 스냅샷과 변경기록의 날짜.

5. AI 활용 역량 (10점)

참고

이 강의는 수강자를 팀장, AI를 팀원으로 놓습니다.
AI가 만든 분량은 감점 요소가 아닙니다. 되돌린 기록이 없는 것이 감점 요소입니다.

6. 발표 및 질의응답 (5점)

미리 알아두는 감점

참고

모두 미리 공개하므로 발표 당일에 처음 듣는 감점은 없습니다.
즉, 아래 항목만 피하면 감점은 발생하지 않습니다.

과정 확인 (감점·가점의 근거)

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