한 줄 요약

기능을 더하는 대신 범위를 좁히는 법, 다섯 단계로 한 바퀴 도는 절차, 그리고 막혔을 때 되돌아올 자리를 남기는 규율을 배웠다.

1. 오늘 배운 것

지금까지는 조각을 하나씩 배웠다. 화면, 백엔드, 데이터베이스, 에이전트. 오늘은 그 조각을 모아 내 서비스 하나로 만드는 날이었다.

그런데 수업이 먼저 말한 것은 만드는 방법이 아니라 가장 흔한 실패였다. 초보 프로젝트가 실패하는 이유는 기능이 너무 적어서가 아니라 너무 많아서라는 것이다.

오늘의 핵심 한 문장 다 만들려 하지 말고, 범위를 좁히고 → 다섯 단계로 한 걸음씩 → 막히면 되돌리며 굴러가는 첫 조각을 만든다.

순서 무엇에 답하는가
MVP란 무엇인가 작게 만든다는 게 정확히 무엇을 말하는가
자를 용기 무엇을 남기고 무엇을 미루는가
다섯 단계 어떤 순서로 손을 대는가
의도만 준다 AI에게 무엇을 말하고 무엇을 맡기는가
규칙은 어디서 지키나 내 서비스의 규칙이 실제로 지켜지는 자리는 어디인가
막혔을 때 안 될 때 무엇을 하고 무엇을 하지 않는가

1-1. MVP는 축소판이 아니다

MVP를 “완성품의 축소판”이나 “화면만 그럴듯한 시제품”으로 오해하기 쉽다. 수업의 정의는 달랐다. 사용자가 의미 있는 한 가지 일을 처음부터 끝까지 해낼 수 있는, 의도적으로 작은 버전.

비유가 명확했다. 목표가 “이동”이라면 스케이트보드는 훌륭한 MVP다. 느려도 실제로 굴러가고 나를 데려다준다. 반면 자동차 타이어 하나는 MVP가 아니다. 잘 만들어도 그걸로는 아무 데도 못 간다.

여기서 기준이 나온다. 기능 수가 아니라 흐름의 완결성이다. 부분만 완벽하면 아직 아무 일도 끝나지 않는다.

거대한 서비스도 첫 버전은 초라했다는 이야기도 들었다.

  • 에어비앤비 — 거실에 에어매트리스 세 개, 사진 몇 장, 웹페이지 하나. 예약 시스템도 리뷰도 결제도 없이 첫 주말 손님 세 명을 받아 “낯선 사람이 낯선 집에 돈 내고 묵을까”를 검증했다
  • 드롭박스 — 제품을 안 만들고 3분짜리 시연 영상만 올렸다. 만들기 전에 수요를 확인한 것이다
  • 인스타그램 — 원래는 기능이 잔뜩 든 ‘Burbn’이었는데, 사용자가 사진 공유만 많이 쓰는 것을 보고 사진·필터·피드로 좁혔다

슬랙과 트위터는 방향을 튼(피벗) 쪽이었다. 슬랙은 게임 회사가 사내 소통용으로 만든 도구가 진짜였고, 트위터는 팟캐스트 회사가 설 자리를 잃고 나온 사내 아이디어였다. 공통점이 하나였다 — 부수적으로 만든 것이 진짜 제품이었다.

1-2. 자를 용기 — ‘안 만들 것’ 목록이 무기다

기능을 고를 때 쓰는 질문은 하나였다.

“이 기능 없이 출시해도, 사용자가 핵심 문제를 풀 수 있나?”

그렇다면, 또는 애매하면 자른다. 버전 2에 넣으면 된다.

기능을 네 칸으로 나누는 MoSCoW를 썼다. 꼭(Must) / 있으면 좋음(Should) / 나중에(Could) / 지금은 안 함(Won’t). 그리고 MVP에서는 Must만 만든다.

가장 강력한 칸이 “지금은 안 함”이었다. 일부러 최소 다섯 개를 적어 두라고 했다. 적어 두면 “이것만 더 넣으면 안 될까”의 유혹을 막아 준다. 이 유혹에는 이름이 있었다 — 스코프 크립. 무서운 건 이게 진보처럼 느껄진다는 점이다. 하나하나는 다 그럴듯하다. “고객이 원해서”, “경쟁사에 있어서”, “하루면 된다길래”.

반대 방향의 실패담도 들었다. 간단해서 잘나가던 뉴스레터 도구가 요청마다 소셜 예약·CRM·고급 분석을 붙이다 뭐 하나 제대로 못 하는 도구가 된 이야기, 경쟁사를 따라 3주 만에 급조한 기능이 버그투성이라 정작 그 기능을 원했던 고객이 경쟁사로 간 이야기.

범위를 좁히는 출발점은 한 문장이었다. 해결책이 아니라 문제에 초점을 두는 틀이다.

[누가] 가 [어떤 상황·언제] 에 [무엇을 못 해서], [어떤 불편] 을 겪는다.

예로 든 문장이 이랬다. “동네 카페 단골손님이 재방문할 때 종이 쿠폰을 자주 잃어버려서, 사장님도 손님도 적립 혜택을 놓친다.” 해결책은 열려 있고 문제만 담겼다. 문장에 “앱으로·자동으로·AI로” 같은 수단이 들어 있으면 빼라고 했다. 사용자도 ‘모두’가 아니라 첫 버전에서 가장 득을 볼 한 사람으로 콕 집는다.

여기에 완성 기준(done)을 한 줄 정해 둔다. “이것까지 되면 오늘 성공”이다. 범위에 마감을 맞추면 끝없이 늘어나므로, 마감에 범위를 맞춘다.

1-3. 다섯 단계 — 어떤 순서로 손을 대는가

단계 이번에 하는 일 통과하면 생기는 것
1. PRD 만들 것을 한 장으로 AI에게 줄 설계도
2. 작업대 하네스 고르고 빈 프로젝트 세우기 내 화면에 프로젝트가 뜬다
3. 화면 목업 값으로 눈에 보이게 진짜처럼 보인다
4. 저장 + 규칙 남게 하고, 내 규칙을 지키게 새로고침해도 남고 규칙이 안 뚫린다
5. 한 바퀴 + 배포 끝까지 돌려 보고 내보내기 누구나 여는 주소가 생긴다

3단계가 앞에 오는 이유가 인상적이었다. 저장이 없어도 목업 값으로 화면부터 채운다. 눈에 보이는 게 있으면 방향이 맞는지 훨씬 빨리 판단할 수 있기 때문이다.

그리고 어디서 멈춰도 그날의 성과라고 했다. 3단계까지만 가도 성공이다. 대신 단계마다 커밋해서 되돌릴 지점을 남긴다.

1-4. 의도만 준다 — 무엇은 내가, 방법은 AI가

명령을 줄 때의 원칙이 하나였다. 무엇을 원하는지(의도)만 말하고, 방법(how)은 지시하지 않는다. “어떤 DB를 써라”, “이 방식으로 막아라”는 AI가 정할 몫이다. 나는 의도와 됐는지 확인에 집중한다.

그래서 PRD에는 기술 선택을 넣지 않는다. 대신 스택은 AI가 후보를 견줘 고르고, 왜 그걸 골랐는지 근거를 설계 문서에 남기게 한다. 아무거나 기본값으로 고르지 않게 하는 장치다.

코드보다 문서를 먼저 세우는 이야기도 나왔다. 바로 “만들어 줘”라고 하면 그럴듯한 코드가 쏟아지지만 정원 초과 금지 같은 내 규칙이 슬쩍 빠진다. 지난 회차의 스펙 주도 방식이 여기서 쓰인다. OpenSpec 같은 도구를 쓰면 PRD를 제안·설계·명세·작업목록으로 나눠 관리할 수 있는데, 필수는 아니라고 했다.

한 번에 안 나와도 정상이다. 바이브 코딩은 지시 → 결과 확인 → 안 되면 다시 지시를 몇 바퀴 도는 일이다.

1-5. 오늘의 산 — 규칙은 화면이 아니라 DB에서 지킨다

정원 10명인 신청 페이지를 예로 4단계를 다뤘다. 여기가 오늘의 진짜 산이었다.

브라우저에서 남은 자리를 세고 나서 신청을 넣는 방식은 여러 명이 동시에 누르면 뚫린다. 세는 것과 넣는 것 사이에 다른 사람도 통과하기 때문이다. 그래서 “현재 신청 수 < 정원”을 조건으로 한 단일 저장을 DB 함수로 만들고, 신청은 무조건 그 함수를 거치게 한다. 마지막 한 자리에 열 명이 눌러도 한 명만 성공한다.

6회차에서 트랜잭션을 개념으로 배웠는데, 오늘은 그것을 어디에 두는가의 문제였다. 관리자 권한도 같은 원리였다. 화면에서 버튼을 숨기는 것은 보안이 아니다. 누구든 요청을 직접 보낼 수 있으니, 관리 함수가 실행될 때마다 스스로 “관리자냐”를 다시 확인해야 한다. 화면은 패널을 보여 줄 뿐이고 진짜 문지기는 DB다.

확인 방법도 배웠다. AI에게 동시 신청 테스트를 만들어 돌리게 하고 로그를 직접 읽는다. AI가 “됐습니다”라고 한 말은 확인이 아니다.

1-6. 막혔을 때 — 네 가지 규율

AI에게 “앱 전체를 완성해 줘”라고 보내면 파일 스무 개가 바뀌고 실행은 안 되는 상태가 된다. 이때 더 긴 프롬프트로 밀어붙이면 문제의 위치만 더 깊이 묻힌다.

  1. 한 번에 하나만 — 프롬프트 하나에 다섯 가지를 요구하면 몇 개는 맞고 몇 개는 틀린다. 고칠 때도 “필요한 것만 바꿔 줘”
  2. 작동하면 저장 — 바뀔 때마다가 아니라 작동할 때마다 커밋한다
  3. 막히면 되돌리고 리셋 — 랜덤하게 이것저것 바꾸라고 시키는 것이 코드를 이해 불가능하게 만드는 지름길이다. 대신 “지금까지 뭐가 됐고, 뭐가 남았고, 지금 문제는 뭐다”로 초점을 다시 맞춘다
  4. 이해 못 한 코드는 배포하지 않는다 — 시제품 단계의 “다 수락”은 괜찮지만, 남에게 내보낼 거라면 그 코드가 무엇을 하는지 알아야 한다

3번이 필요한 이유에 이름이 있었다 — 둠 루프. “거의 다 됐는데” 버그 하나가 안 잡히고, AI는 고쳤다는데 실제론 안 고쳐지고, 프롬프트를 더 넣을수록 멀쩡하던 기능까지 깨진다. 이건 운이 아니라 구조적이라고 했다. 대화가 길어지며 맥락이 오염되고, AI에게는 무엇이 무엇에 의존하는지의 지도가 없어 원인이 아니라 증상만 계속 땜질하기 때문이다. 막힘이 30분을 넘기면 더 파기 전에 멈추고 되돌리는 것이 대개 더 빠르다.

막힘을 푸는 오래된 비법도 배웠다. 러버덕 디버깅 — 고무 오리 인형에게 문제를 소리 내어 설명하는 것이다. 원리는 자기 설명 효과다. 머릿속에서는 슬쩍 넘어가던 전제가 말로 옮기는 순간 빈틈을 드러낸다. 바이브 코딩에서 내 고무 오리는 AI다.

Git 이야기도 한 겹 더 들어갔다. Git은 저장 버튼이 아니라 변화의 이유와 순서를 되짚게 하는 기록 장치라는 것이다. 책상 비유로 세 장소를 구분했다.

장소 무엇인가
working tree(작업 트리) 지금 손으로 펼쳐 놓은 원고
staging area(스테이징) 다음 기록 상자에 넣기로 골라 둔 원고 묶음
repository(저장소) 확정된 사진첩

git add가 “모든 변경을 자동 백업”이 아니라 “이 파일의 이 상태를 다음 기록에 포함하겠다”는 선택이라는 설명이 특히 유용했다. AI가 의도한 파일 말고 버튼 색까지 고쳐 놓았을 때, 의도한 것만 add하고 나머지는 작업 트리에 두면 검증한 변화와 아직 실험 중인 변화가 나뉜다.

되돌리기 명령은 이름이 비슷해도 위험이 다르다.

명령 무엇을 바꾸나
git restore <파일> 아직 커밋하지 않은 변경을 버리고 마지막 커밋 상태로 되돌린다
git reset --hard <커밋> 커밋·스테이징·작업 트리를 함께 맞춘다. 커밋하지 않은 작업을 실제로 지운다
git revert <커밋> 과거를 지우지 않고 효과를 반대로 적용하는 새 커밋을 만든다

reset은 내 로컬 실험의 책상 정리, revert는 공유된 역사에 남기는 취소 메모로 기억하라고 했다. “안 되면 하드 리셋”은 진단법이 아니다.

커밋 메시지도 ‘오후 작업’처럼 시간으로 쓰지 않고 “신청이 저장된다”처럼 행동과 관찰 가능한 결과로 쓴다. 그래야 나중에 깨졌을 때 어느 지점이 정상이었는지 바로 찾는다.

1-7. 왜 필요한가

오늘 배운 것은 도구가 아니라 판단의 순서였다.

AI는 요청한 것을 다 만들어 준다. 그래서 무엇을 요청하지 않을지가 내 몫으로 남는다. 범위를 좁히는 것, 규칙이 지켜지는 자리를 아는 것, 되돌아올 지점을 남기는 것 — 셋 다 AI가 대신 해 주지 않는 일이다.

수업이 인용한 문장 하나가 오래 남았다. “첫 버전이 부끄럽지 않다면 너무 늦게 낸 것이다.” 머릿속의 완벽한 설계보다 손에 잡히는 어설픈 실물 하나가 더 많은 걸 가르쳐 준다.

2. 실습 / 코드 — 내 도메인으로 MVP 착수

오전은 이론, 오후는 각자 만들고 싶은 것의 MVP를 직접 만드는 시간이었다. 이 모듈의 최종 제출(메인 퀘스트)의 착수분이기도 하다.

2-1. 무엇을 만들지부터 정하지 못했다

만들 것이 정해져 있지 않아 LLM과 브레인스토밍부터 했다. 그 결과 정한 한 문장은 이렇다.

나이 든 반려동물의 하루를 가족이 함께 기록하고, 약을 놓치지 않고, 병원에서 잘 설명할 수 있게 하는 케어 매니저

만성질환을 가진 반려동물과 사는 보호자가 겪는 하루에서 출발했다. 어제 저녁 약을 내가 먹였는지 배우자가 먹였는지 기억나지 않는다. 2주 전보다 밥을 덜 먹는지는 알 수 없다. 병원에서는 “요즘 좀 안 좋아요”밖에 말하지 못한다. 1-2에서 배운 한 문장 틀이 이 지점에서 쓰였다.

2-2. 절차 — 문서 4종을 먼저, 그다음 단위로 쪼개기

수업의 다섯 단계를 그대로 쓰지 않고, 세션을 나눠 오래 진행할 수 있게 앞에 문서 단계를 더 두었다.

문서 무엇을 담는가
컨텍스트 기획 결정의 원본. 판단이 충돌할 때 최상위 기준
PRD 무엇을·왜. 기술 선택은 넣지 않음
기술명세서 어떻게. 스키마·함수 시그니처·배포까지
단위 작업 명세서 작업을 단위로 쪼갠 목록과 세션 운영 방법

문서 위계를 먼저 못 박은 것이 이번 설계의 핵심이었다. 컨텍스트 > PRD > 기술명세서 > 구현 순으로 우선하고, 기술명세서에서 PRD를 바꾸고 싶으면 PRD를 먼저 고친다.

그리고 단위를 쪼갤 때 네 조건을 걸었다.

  1. 1세션에 끝난다
  2. 끝나면 테스트할 수 있다 — 다음 단위를 기다리지 않는다
  3. 경계가 닫혀 있다 — “하지 않을 것”이 명시돼 범위가 새지 않는다
  4. 되돌릴 수 있다 — 한 단위 = 한 커밋. 실패하면 그 단위만 버린다

2번이 1-6의 “작동하면 저장”과 같은 규칙이다. 검증 방법도 유형별로 정해 뒀다. npm test로 끝나는 단위, 개발용 라우트에서 눈으로 보는 단위, 실기기로 확인해야 하는 단위가 다르다.

순수 계산 함수를 UI보다 먼저 만들기로 한 것도 여기서 나왔다. 날짜 계산이나 약 스케줄 같은 로직은 화면 없이 npm test만으로 검증되니, 계산 버그와 화면 버그를 섞지 않는다.

2-3. 세션 운영 — 상태 파일 하나가 다음 세션의 진입점

한 세션이 끝나면 다음 세션은 아무것도 기억하지 못한다. 그래서 이렇게 정했다.

  • 명세 문서 4종은 저장소 밖에 두고, 저장소에는 앱 코드만 올린다
  • 진행 상황은 누적 상태 파일 하나로 유지한다(200줄 이하)
  • 단위마다 종료 기록 파일을 따로 남긴다 — 무엇을 만들었나, 명세와 달라진 점과 이유, 막혔던 것, 다음 단위에 넘기는 주의사항
  • 새 세션 프롬프트에 “먼저 이것만 읽어. 다른 문서는 읽지 마”를 명시하고, 읽을 절을 지정한다

마지막 항목은 7회차에서 배운 점진 공개를 그대로 적용한 것이다. 기술명세서가 1,300줄이 넘으니 통째로 읽히면 안 된다.

2-4. 어디까지 갔나 — 11 / 33

쪼개고 보니 단위가 33개가 나왔다. 수업이 끝난 뒤 밤새 진행해서 11단위까지 완료했다. 홈 화면과 미완료 표시가 뜨는 지점이다.

스택은 PRD에 넣지 않고 AI가 고르게 한 뒤 근거를 기술명세서에 남겼다.

레이어 선택
언어·빌드 TypeScript(strict) + Vite
UI React + React Router, CSS Modules + 토큰
로컬 저장 Dexie(IndexedDB) — 로컬이 기본, 서버는 부가 레이어
테스트 Vitest
배포 Vercel — GitHub 연동 자동 배포

아직 서버가 없다. 1-5에서 배운 DB 함수나 RLS는 이 프로젝트에서는 아직 쓰지 않았다. 계정과 동기화는 뒤쪽 단위로 미뤄 뒀고, 지금은 기록이 브라우저 안에만 있다. 그래서 미접속이 길어지면 기록이 사라질 수 있다는 제약을 기술명세서에 적어 두고, 자동 백업과 설치 유도를 필수 구현으로 잡았다.

2-5. 그리고 막혔다 — 토큰이 먼저 떨어졌다

단위가 33개가 되면서 문제가 생겼다. 매 세션 문서를 다시 읽고 작업하니 시간이 늘고, 단계를 거듭할수록 토큰 소모가 빨라졌다. 그래서 지금은 라이트 버전으로 처음부터 다시 시작해야 하나 고민 중이다.

이 고민을 4번에 정리했다. 결론부터 적어 두면 — 33은 완성까지의 전체 목록이고, 매일 쓸 수 있게 되는 지점은 그 끝이 아니었다.

2-6. 이 절에 덧붙일 것

  • 첫 마일스톤(U17)까지 도달했는지, 그때 실제로 쓸 만했는지
  • 라이트 버전 재시작 여부와 그 판단 근거
  • 완성 화면, 그리고 앱을 껐다 켜도 기록이 남는 장면
  • 서버를 붙인 뒤 RLS가 실제로 남의 기록을 막는지 확인한 로그

3. 그림 / 스크린샷

스케이트보드에서 자전거, 자동차로 가는 경로는 매 단계 탈 수 있고 타이어에서 차체, 자동차로 가는 경로는 완성 전까지 탈 수 없다
그림 1. MVP의 기준은 기능 수가 아니라 '끝까지 되는가'
PRD, 작업대, 화면, 저장과 규칙, 한 바퀴와 배포 다섯 단계와 각 단계의 통과 기준, 그리고 단계마다 남기는 커밋 체크포인트
그림 2. 다섯 단계 — 그리고 단계마다 남기는 되돌릴 지점
화면에서 남은 자리를 센 뒤 저장하면 정원이 뚫리고, DB 함수 안에서 조건부로 한 번에 저장하면 한 건만 성공한다
그림 3. 규칙은 화면이 아니라 DB에서 강제한다
범위가 넓어 단위가 33개가 되고 세션마다 문서를 다시 읽어 토큰 소모가 가속되는 흐름, 그리고 33단위 위에 표시된 현재 위치와 첫 마일스톤
그림 4. 단위를 잘게 쪼갠 대가, 그리고 첫 마일스톤의 위치

4. 막혔던 점과 해결

막힌 지점 궁금했던 이유 정리한 답
잘게 쪼갰는데 왜 더 무거워졌나? 쪼개기는 수업에서 배운 규율인데 오히려 역효과가 났다 쪼개기가 아니라 쪼개는 대상이 컸다. 범위가 넓으면 잘게 나눠도 단위 수만 늘어난다. 33이라는 숫자는 분해 방식의 문제가 아니라 범위를 아직 안 잘랐다는 신호로 읽는 게 맞다. Must 3개·Won’t 5개를 못 박는 일이 모듈 분해보다 앞이어야 했다
컨텍스트 요약 파일이 왜 토큰을 태우나? 세션을 끊기 위해 만든 장치인데 반대로 소모를 키웠다 요약을 매 세션 앞에서 통째로 읽히면 단계마다 누적된다. 그래서 “지정된 절만 읽어”와 상태 파일 200줄 상한을 걸어 뒀는데, 그래도 찬 이유는 한 단위에 구현·테스트·검사·기록 갱신이 다 붙어 있기 때문이다. 명세에 이미 답이 적혀 있었다 — 한 단위가 한 세션에 안 끝나면 그 자리에서 둘로 쪼갠다
33단계면 라이트 버전으로 다시 시작해야 하나? 끝이 안 보여서 처음부터 다시 하는 게 빠를 것 같았다 내가 쓴 명세에 이미 답이 있었다. 첫 마일스톤(U17)이 “자기 사용 시작” 지점으로 정의돼 있고, 33은 외부 사용자까지 받는 완성 시점의 목록이다. 지금 11에서 여섯 단위 남았다. 그러니 재시작 판단은 U17 도달 여부로 미룰 수 있다. 다만 그때도 안 굴러가면 그건 범위 문제이므로 자르는 게 맞다
단위마다 테스트 가능해야 한다는 조건이 부담을 키운 건 아닌가? 이 조건 때문에 단위가 더 잘게 쪼개졌다 이건 유지하는 게 맞다. 1-6의 “작동하면 저장”과 같은 규칙이고, 되돌릴 지점이 없으면 둠 루프에서 빠져나올 방법이 없다. 오히려 “단위가 끝났는데 테스트할 방법이 없다면 분해가 틀린 것”이 기준이 된다

5. 스스로 확인하기

  • MVP가 “축소판”이나 “시제품”과 어떻게 다른지 한 문장으로 말할 수 있는가?
  • 스케이트보드와 타이어 비유로 내 프로젝트의 첫 조각을 설명할 수 있는가?
  • 기능을 자를 때 쓰는 질문 한 문장을 기억하는가?
  • 내 서비스의 ‘지금은 안 함’ 다섯 개를 지금 적을 수 있는가?
  • 다섯 단계의 순서와 각 단계의 통과 기준을 댈 수 있는가?
  • PRD에 기술 선택을 넣지 않는 이유를 설명할 수 있는가?
  • 화면에서 세고 저장하는 방식이 왜 뚫리는지 예로 설명할 수 있는가?
  • 관리자 기능에서 “버튼 숨기기”가 왜 보안이 아닌지 말할 수 있는가?
  • reset과 revert를 언제 각각 쓰는지 구분할 수 있는가?
  • git add가 무엇을 하는 명령인지 자기 말로 설명할 수 있는가?
  • 둠 루프에 빠졌다는 신호와 그때 할 일 세 가지를 말할 수 있는가?
  • 내 프로젝트에서 “이것까지 되면 성공”인 완성 기준을 한 줄로 쓸 수 있는가?

6. 더 알아볼 것

  • 첫 마일스톤(U17)까지 밀어 보기 — 라이트 버전 재시작 판단은 그 지점에서 다시 한다
  • Must 3개 · Won’t 5개를 뒤늦게라도 못 박기 — 33단위 중 무엇이 Must가 아닌지 다시 훑기
  • 단위 종료 기록을 짧게 유지하는 방법 찾기 — 상태 파일이 길어지면 그 자체가 토큰이 된다
  • 6회차 글의 2번 채우기 — Todo 앱 커스텀 기능, DB 구조도, 완성 화면
  • 7회차 과제 이어가기 — 만든 스킬 며칠 써 보고 description 다듬기, 스킬 출력을 용어 사전 글로 옮기기, Todo 앱에 CLI 붙이기
  • 밀린 숙제: PowerShell 기초, 비동기를 코드로 확인하기(setTimeout으로 실행 순서 찍어 보기)
  • 러버덕을 실제로 해 보기 — 막혔을 때 상황을 글로 먼저 풀어놓고, 그 사이 스스로 찾은 게 있었는지 기록하기

참고 자료

아래는 수업 자료에 적힌 출처를 옮긴 것이다. 직접 검색해 확인하지 않았으므로 경로가 바뀌었을 수 있다. 특히 문서 사이트는 주소가 자주 바뀐다.