실습 재료

브라우저에서 바로 열립니다. 저장하려면 링크를 우클릭해 다른 이름으로 저장하세요. API 키는 필요 없고, 서버로 아무것도 보내지 않습니다.

완성본은 먼저 열지 마세요. LAB 1을 끝내고 자기 것과 대조할 때 씁니다.

화면설계서 2방향 - 시작하기

화면설계서를 읽고, 쓰고, 그것으로 화면을 만들고, 화면에서 다시 뽑아내는 하루짜리 실습 패키지입니다.

이 패키지가 약속하는 것

하루(6-8시간)를 쓰면 다음 네 가지를 직접 해본 상태가 됩니다.

1. 처음 보는 화면설계서를 읽고 무슨 화면인지 말할 수 있다
2. 화면설계서를 LLM에 넣어 동작하는 화면을 만든다
3. 만든 화면을 거꾸로 화면설계서로 뽑아낸다
4. 남의 서비스 화면 캡처 한 장으로 그 뒤의 설계 규칙을 복원한다 (역기획)

약속하지 않는 것: 디자인 실력, 피그마 숙련, 프로덕션 코드 품질. 이 패키지는 문서와 화면 사이를 왕복하는 감각만 다룹니다.

준비물

API 키는 필요 없습니다. 모든 재료는 정적 HTML이고, 서버로 아무것도 보내지 않습니다.

여는 순서

1. 01_CONCEPT/  를 순서대로 읽는다            (60분)
2. 02_MATERIALS/restaurant/ 를 열어본다        (15분)
3. 03_LAB/LAB1 → LAB2 → LAB3 → LAB4           (4-5시간)
4. 05_ASSESS/ 로 자기 채점                     (30분)

혼자 하면 위 순서대로, 가르친다면 04_INSTRUCTOR/RUNSHEET.md부터 봅니다.

폴더 지도

한 줄 요약

같은 6층(기능 · UI · Logic · Data · API · Deploy)을 화면에서 문서로 뽑으면 역기획이고, 문서에서 화면으로 밀면 구현이다. 이 패키지는 그 왕복을 하루에 한 바퀴 돌린다.

1. 화면설계서란 무엇인가

읽는 데 15분. 이 문서를 덮을 때 "화면설계서를 남에게 3문장으로 설명할 수 있다"가 목표입니다.

1-1. 세 문서의 자리

이 패키지가 다루는 것은 셋 중 화면설계서 하나입니다. 화면 하나의 설계도를 그리고, 각 요소가 뭘 하는지 적는 문서입니다.

1-2. 이름이 여러 개인데 전부 같은 것이다

화면설계서 = 스토리보드 = 와이어프레임 = UI 설계서 = 스크린 디자인.

회사마다 부르는 이름이 다르고 포맷도 PPT·엑셀·피그마로 갈립니다. 표준은 없습니다. 현장에서 자연스럽게 굳은 관행이고, 정답은 "그 회사가 쓰는 방식"입니다.

다만 구조 하나는 10년 넘게 고정입니다.

┌─────────────────┬──────────────────────────┐
│  왼쪽            │  오른쪽                   │
│  와이어프레임     │  디스크립션                │
│  (화면 뼈대 그림) │  (번호별 상세 설명)         │
│  ① ② ③ 번호마커  │  ① ... ② ... ③ ...       │
└─────────────────┴──────────────────────────┘

그림은 껍데기고, 디스크립션이 알맹이입니다. 와이어프레임이 예쁜지는 중요하지 않습니다. 옆에 붙는 설명 - 어떤 태그를 쓰는지, 데이터가 어디에 저장되는지, 예외는 뭔지 - 의 밀도가 이 문서의 품질입니다. 그림 실력이 아니라 디스크립션의 정확성이 기획자의 실력입니다.

1-3. 어원은 영화다

스토리보드는 원래 애니메이션 스튜디오에서 만든 촬영 도구입니다. 장면을 순서대로 그려놓고 옆에 연출 지시를 적습니다.

• 왼쪽 = 콘티(시각적 구성) / 오른쪽 = 디렉팅(연기·카메라·미술 지시)
• 뮤직비디오, 광고, 콘텐츠 기획에서 지금도 같은 양식을 씁니다

그림 하나만 있으면 주먹이 나가는 중인지 빠지는 중인지 알 수 없습니다. 오른쪽 설명이 정적인 그림에 앞뒤 문맥과 진행 방향을 붙여줍니다. 화면설계서도 정확히 같은 일을 합니다.

1-4. 와이어프레임은 "졸라맨"이다

wire(선) + frame(뼈대). 정식 용어로는 low fidelity(저충실도) 디자인입니다.

왜 일부러 대충 그리는가:

• 설계 단계에서 중요한 건 버튼을 넣을지 말지, 위치가 위인지 아래인지뿐입니다
• 고충실도로 예쁘게 만들 시간에 빨리 만들어서 사용자에게 보여주는 게 낫습니다
• 일주일 걸릴 걸 3일에 끝내고 남은 이틀로 사용자 테스트를 두 번 더 하는 쪽이 이깁니다

목적은 하나입니다. 최소 리소스로 최대한 빨리 검증받기.

1-5. 읽는 순서

처음 보는 화면설계서는 이 순서로 봅니다.

1. 왼쪽 와이어프레임에서 번호 마커를 찾습니다 - 1번부터 순서대로
2. 오른쪽에서 같은 번호를 찾아 설명을 읽습니다 - 태그, 데이터 타입, 동작
3. 태그가 왜 그것인지 근거를 확인합니다 - "왜 select이고 text가 아닌가"

3번이 핵심입니다. 옵션이 5개라 드롭다운을 썼고, 3개 이하라 라디오를 썼다는 식의 근거가 없으면 그 문서는 베껴 적은 것입니다.

1-6. 빠진 이빨 - 라면 레시피 문제

아래 레시피를 보고 요리를 만들어 보세요.

물을 끓입니다.
물이 끓으면 면을 넣고 3분간 더 끓입니다.
스프와 건더기 스프를 넣습니다.
면을 그대로 둔 채 물을 버립니다.
기호에 따라 계란을 넣어 드시면 좋습니다.

만들 수는 있습니다. 그런데 무슨 라면인지가 없습니다. 물을 버리라고 했으니 국물 라면은 아닌데, 스프를 국물용으로 넣었습니다. 냄비 이야기도 없습니다. 결과물은 사람마다 다르게 나옵니다.

개발자가 "이거 뭘 어떻게 하라는 거죠?"라고 되물을 때가 정확히 이 상태입니다. 쓴 사람은 다 설명했다고 믿고, 읽는 사람은 못 만듭니다.

현장에서 자주 나오는 빠진 이빨 세 가지:

이 세 가지를 막는 장치가 다음 문서에서 다룰 6층입니다.

2. 6층 - 디스크립션에 무엇을 쓰는가

읽는 데 20분. 이 패키지 전체를 관통하는 단 하나의 프레임입니다.

2-1. 5층이면서 6층이다

디스크립션에 쓸 수 있는 항목을 전부 모으면 30개가 넘습니다. 전부 쓰는 곳은 없습니다. 실무에서 되풀이해서 요구되는 것만 남기면 5층입니다.

그런데 그 5층 위에 한 줄이 더 있습니다. 그래서 실제로는 6층입니다.

1층이 가장 자주 빠지고, 빠졌을 때 가장 크게 무너집니다.

1층은 기술 용어가 없는 한 줄입니다. 사용자 입장에서 이 요소가 무슨 일을 하는지 일상어로 씁니다.

① 지역
   어느 동네에서 식당을 찾을지 고른다.        ← 1층. 여기까지가 아무나 읽는 칸
   UI      <select> 드롭다운. 옵션 5개
   Logic   onchange -> formData.region 갱신
   Data    formData.region (string, mutable, 기본값 "")
   API     없음
   Deploy  정적 HTML

왜 1층이 필요한가. 2층부터는 읽는 사람이 정해져 있습니다. 개발자는 Logic과 Data를 읽고, 디자이너는 UI를 읽습니다. 그런데 설계도는 사람이 읽는 것이고, 회의실에는 그 층을 안 읽는 사람도 앉아 있습니다. 1층이 없으면 그 사람들은 문서를 덮습니다.

1층 없이 2-6층만 있는 문서는 코드를 한국어로 옮겨 적은 것이지 설계서가 아닙니다.

1층 쓰는 법

왼쪽은 2-4층을 1층 자리에 옮겨 쓴 것입니다. 오른쪽은 도구를 하나도 몰라도 읽힙니다.

2-2. 여섯 개를 다 쓰라는 게 아니다

현장에서는 합이 맞는 만큼만 씁니다.

• API를 기획자가 쓰라는 회사가 있고, 개발자 몫으로 가르는 회사가 있습니다
• 어떤 요소는 서너 줄이 나오고, 어떤 요소는 한 줄로 끝납니다
• 기능이 많으면 길어지고, UI만 있으면 짧아집니다

다만 1층과 UI·Logic은 예외 없이 씁니다. 1층이 빠지면 개발자 외에는 못 읽고, UI·Logic이 빠지면 개발자가 못 만듭니다.

한 문장 안에 여러 층이 섞여 있기도 합니다.

"업로드한 사진을 표출합니다"

• 표출합니다 = Logic
• 업로드한 = Data (누가 올렸는지에 따라 저장 위치가 다르다)
• 사진이 어떤 크기로 어디에 뜨는지 = UI (안 적혀 있음 -> 빠진 이빨)
• 이 요소가 사용자에게 무엇인지 = 1층 (역시 없음)

층이 섞인 문장은 쪼갭니다. 쪼개면 무엇이 비어 있는지가 드러납니다.

2-3. Data 층이 가장 자주 비어 있다

세 층 중 가장 많이 생략되고, 가장 많이 사고를 냅니다. Data를 쓸 때 반드시 채우는 네 칸:

formData.region
  ├─ 이름     region
  ├─ 타입     string
  ├─ 변경성   mutable      ← 고치면 이전 값이 사라진다
  └─ 기본값   ""           ← 아무것도 안 골랐을 때

mutable(고쳐 쓰기)인가 append(쌓기)인가가 특히 중요합니다. 폼은 대개 mutable이라 값을 바꾸면 이전 값이 없어집니다. 대화형 인터페이스는 대개 쌓아야 해서 이전 값이 남아야 합니다. 이 한 글자 차이가 "아까 말한 그거"를 기억하느냐 못 하느냐를 가릅니다.

실습 중 이걸 눈으로 보는 방법: 브라우저 개발자 도구 콘솔을 열고 값을 바꿔봅니다. 이전 값이 사라지면 mutable입니다.

2-4. Deploy 층이 "내 컴퓨터에선 되는데"를 잡는다

가장 마지막에 붙고 가장 늦게 배우는 층인데, 실제 사고는 여기서 납니다.

설계서에 Deploy: HTTPS 필수, 도메인 등록 필요라고 한 줄 적혀 있으면 이 사고가 안 납니다. 안 적혀 있으면 배포 당일에 발견합니다.

2-5. 이 프레임은 화면이 바뀌어도 그대로 쓴다

이 프레임의 값어치는 재사용성에 있습니다.

같은 서비스를 폼으로 만들든, 챗봇으로 만들든, 음성으로 만들든:

기능      ← 거의 같다 (사용자가 하려는 일은 그대로다)
UI        ← 이것만 바뀐다
Logic     ┐
Data      │  거의 같다
API       │
Deploy    ┘

식당 예약을 예로 들면, 드롭다운으로 고르든 대화로 말하든 받아야 할 정보(지역·종류·가격대·인원·시간)는 동일합니다. 그 정보 칸을 슬롯(slot)이라고 부릅니다. 슬롯이 다 차야 예약이 성립합니다.

그래서 화면설계서를 한 번 제대로 쓰면, 그 문서가 다음 형태(챗봇·에이전트)의 설계 재료가 됩니다.

2-6. 자가 점검

아래 여섯 줄을 자기 화면의 요소 하나에 대해 채울 수 있으면 이 문서는 통과입니다.

[기능]        이 요소는 (                    ) 한다.   ← 기술 용어 없이
[UI]          (          ) 태그를 쓰고, (        ) 처럼 보인다.
[Logic]       (          ) 하면 (          ) 된다.
[Data]        (   ) 이름 / (   ) 타입 / (mutable|append) / 기본값 (   )
[API]         (없음 | 어디서 뭘 가져온다)
[Deploy]      (정적 | HTTPS 필요 | 키 필요 | 도메인 등록 필요)

3. 왜 지금 이걸 배우는가

읽는 데 10분. 실습 전에 기대치를 맞추는 문서입니다.

3-1. 이건 더 이상 전문성이 아니다

먼저 김을 뺍니다. 화면설계서를 쓸 줄 아는 것 자체는 이제 경쟁력이 아닙니다.

• LLM이 화면설계서를 읽고 화면을 만듭니다. 오타나 누락만 없으면 됩니다
• LLM이 화면을 보고 화면설계서를 씁니다. 사람보다 층을 잘 나눕니다
• 예전에 이 문서를 전담하던 포지션은 빠르게 줄었습니다

그러니 "이 문서를 잘 쓰는 사람"을 목표로 삼으면 안 됩니다. 목표는 읽고 판단할 수 있는 상태입니다.

3-2. 그럼 왜 하는가 - 세 가지 용도

(1) 스파링

LLM이 만든 것을 검수하려면 무엇이 빠졌는지 알아야 합니다.

다 썼다고 생각했는데 구현이 안 된다 -> 무언가 빠졌다 -> 무엇이 빠졌는지 찾는다

이 왕복이 실력입니다. 화면설계서는 그 왕복의 연습 상대입니다.

(2) 드리프트 박제

LLM은 매 실행마다 조금씩 다르게 만듭니다. 내가 원한 것을 시점 고정으로 박아두는 문서가 없으면, 세 번째 실행에서 처음 의도가 사라집니다. 설계서가 그 말뚝입니다.

(3) 오케스트레이션 기준

번호 붙은 요소 하나하나가 작업 단위입니다.

• 사람과 일할 때: 1번은 A가, 2번은 B가. 이 문서가 투입 공수의 근거이자 계약서가 됩니다
• 에이전트와 일할 때: 같은 구조로 작업을 쪼개 배분하고, 끝난 뒤 이 문서로 검수합니다

화면설계서의 오른쪽 디스크립션은 에이전트에게 주는 프롬프트와 같은 자리에 있습니다. 다른 점은 받는 쪽이 사람이라는 것뿐입니다.

3-3. 여전히 손으로 써야 하는 곳이 있다

인터넷이 차단된 환경에서 일하는 대형 프로젝트가 있습니다. 보안 규정상 LLM을 못 씁니다. 그런 현장에서는 이 문서를 전부 손으로 씁니다.

채용 공고에 "스토리보드·IA 작성 가능자"가 크게 적혀 있다면 둘 중 하나입니다.

• 폐쇄망 환경이라 사람이 직접 써야 한다
• 아직 방식을 바꾸지 못한 조직이다

어느 쪽인지 확인하고 지원하면 됩니다. 나쁘다는 뜻이 아니라, 무슨 일을 하게 될지 알고 가라는 뜻입니다.

3-4. 리터러시 눈금

자기 위치를 재는 기준입니다.

이 패키지 하루로 도달 목표는 세 번째 줄입니다. 첫 줄은 반복이 필요합니다.

3-5. 포트폴리오에 대한 주의

화면설계서를 몇 장 만들어 포트폴리오에 넣는 것 자체는 이제 변별력이 없습니다. 딸깍으로 만들어지는 것을 모두가 압니다.

물어보는 것은 이쪽입니다.

• 왜 이렇게 만들었나 - 왜 드롭다운이고 라디오가 아닌가
• 무엇을 뺐나 - 왜 이 기능은 안 넣었나
• 빈 백지를 보고도 진행할 수 있나

그래서 이 패키지의 실습은 전부 "만들고 나서 왜 그런지 적기"로 끝납니다. 만든 결과보다 그 옆에 붙는 근거가 산출물입니다.

실습 재료 안내

무엇이 들어 있나

읽기 전에 알아야 할 두 가지

1. 6층으로 되어 있습니다

요소마다 맨 위에 기능 한 줄이 있고, 그 아래 UI · Logic · Data · API · Deploy가 붙습니다. 1층은 기술 용어 없이 이 요소가 무엇인지 말하는 칸이라 개발을 몰라도 읽힙니다.

2. API · Deploy 칸이 전부 같습니다

세 도메인 모두 API: 없음, Deploy: 정적 HTML입니다. 재료가 부실한 게 아니라 폼이라는 대상이 그 두 층을 안 쓰기 때문입니다.

빈 칸을 먼저 본 사람만 LAB 3에서 그 칸이 채워질 때 무엇이 달라지는지 압니다. 실제 서비스를 역기획하면 API가 여러 종으로 늘고 Deploy에 HTTPS·도메인 등록·호출 제한이 붙습니다. 그 대비가 이 패키지의 난이도 계단입니다.

3. 완성 실물은 먼저 열지 마세요

answer_*.html 은 정답지입니다. LAB 1을 끝내고 자기 것과 대조할 때 엽니다. 가르치는 경우에는 배포하지 않고 시연에만 씁니다.

숙소에 완성 실물이 없는 것도 같은 이유입니다. 시연 없이 설계서만 보고 만드는 단계라서 정답지를 두지 않았습니다.

난이도 순서

식당    설계서 + 절차 + 시연  →  따라 만든다
택시    설계서 + 차이점만     →  나머지는 스스로
숙소    설계서만              →  시연 없이 만든다
(캡처)  아무것도 없음         →  설계서부터 만든다   ← LAB 3

하루에 넷을 다 돌리려 하지 마세요. 1회차 운영에서 식당 하나에 오전을 다 쓰고 택시·숙소가 미소비로 남았습니다. 식당 + 캡처 역기획 조합이 현실적입니다.

출처

식당·택시 화면설계서와 템플릿은 1회차 수업의 배포 원본입니다. 숙소 설계서와 스타터 3종은 같은 규격으로 새로 만들었습니다. 규격은 SPEC.md 3장을 보세요.

숙소 예약 폼 - 화면설계서

화면 ID ACC-001 · 시스템 숙소 예약 · 버전 1.0

이 재료에는 완성 실물이 없습니다. 시연 없이 이 문서만 보고 만드는 것이 목적입니다.
막히면 식당 폼 코드를 참고하고, 각 요소의 UI 항목이 어떤 HTML 태그인지 되짚으세요.

화면 개요

숙소 조건 5가지를 입력받는 단일 폼. 선택 2 + 숫자 1 + 체크박스 2 + 제출 1.

요소별 명세

각 요소는 6층으로 씁니다. 굵은 문장 한 줄이 1층(기능)이고, 그 아래 UI · Logic · Data · API · Deploy가 붙습니다.

1. 종류 (필수)

어떤 형태의 숙소를 찾는지 고른다.

• UI <select> 드롭다운. 옵션 3개: 호텔 / 게스트하우스 / 모텔. 전체 너비
• Logic onchange -> formData.type 갱신. 초기값은 "선택하세요"(빈 값)
• Data formData.type (string, mutable, 기본값 "")
• API 없음
• Deploy 정적 HTML

2. 가격대 (필수)

예산 구간을 고른다.

• UI <select> 드롭다운. 옵션 3개: 저가 / 중가 / 고가
• Logic onchange -> formData.pricerange 갱신
• Data formData.pricerange (string, mutable, 기본값 "")
• API 없음
• Deploy 정적 HTML

3. 숙박 기간 (필수)

며칠 묵을지 입력한다.

• UI <input type="number">. 제약 min=1 max=30. 단위 표기 "박"
• Logic 숫자만 입력. 범위 밖이면 브라우저가 막는다
• Data formData.stay (number, mutable, 기본값 없음)
• API 없음
• Deploy 정적 HTML

4. 인터넷 (선택)

와이파이가 필요한지 체크한다.

• UI <input type="checkbox">. 라벨 "인터넷"
• Logic 체크 여부만. 다른 체크박스와 독립
• Data formData.internet (boolean, mutable, 기본값 false)
• API 없음
• Deploy 정적 HTML

5. 주차 (선택)

주차가 필요한지 체크한다.

• UI <input type="checkbox">. 라벨 "주차"
• Logic 체크 여부만. 인터넷과 독립
• Data formData.parking (boolean, mutable, 기본값 false)
• API 없음
• Deploy 정적 HTML

6. 예약하기 (버튼)

입력값을 모아 제출한다.

• UI <button type="submit">. 전체 너비, 강조색
• Logic preventDefault() -> FormData 수집 -> 객체 변환 -> console.log + 화면 표시
• Data formData 전체를 JSON으로
• API 없음. 서버 전송 안 함
• Deploy 정적 HTML. 브라우저에서 직접 실행

완료 기준 [5/5]

[ ] 종류 드롭다운 3옵션
[ ] 가격대 드롭다운 3옵션
[ ] 숙박 기간 숫자 입력 (1-30)
[ ] 인터넷 체크박스
[ ] 주차 체크박스

제출 버튼은 위 5개가 다 되면 자동으로 따라옵니다.

식당 폼과 비교하면

UI와 슬롯만 다르고 나머지 세 층은 같습니다.

1. 화면설계서란

문서 답하는 질문 비유

화면설계서 이 화면이 어떻게 생겼고, 뭘 누르면 뭐가 되는가 건물 한 방의 도면

IA (정보구조) 무엇이 어디에 있는가 건물 층별 안내도

정책서 규칙이 뭔가 (화면에 안 보이는 것) 건물 운영 규정

오늘 만드는 것은 이 셋 중 화면설계서입니다. 화면 하나의 설계도를 그리고, 각 요소가 뭘 하는지 적는 문서입니다.

구성

화면설계서는 두 부분으로 나뉩니다.

왼쪽 오른쪽

와이어프레임 - 화면의 뼈대 그림. 번호 마커가 각 요소에 붙어 있습니다 디스크립션 - 번호별로 이 요소가 뭔지, 어떤 태그인지, 누르면 뭐가 되는지 적습니다

그림은 껍데기고, 디스크립션이 알맹이입니다. 와이어프레임이 예쁜지는 중요하지 않습니다. 옆에 붙는 설명 - 어떤 태그를 쓰는지, 데이터가 어디에 저장되는지, 예외는 뭔지 - 의 밀도가 이 문서의 품질입니다. 그림 실력이 아니라 디스크립션의 정확성이 기획자의 실력입니다.

읽는 순서

이 문서를 처음 볼 때는 아래 순서로 보세요.

왼쪽 와이어프레임에서 번호 마커를 찾습니다 - 1번부터 순서대로

오른쪽에서 같은 번호를 찾아 설명을 읽습니다 - 태그, 데이터 타입, 동작

태그가 왜 그것인지 근거를 확인합니다 - "왜 select이고 text가 아닌가"

LAB 1 - 화면설계서로 화면 만들기 (정방향)

소요 40-60분 · 난이도 낮음 · 산출 동작하는 식당 예약 폼 1개

문서가 코드가 되는 방향을 먼저 겪습니다. 이 랩이 되면 나머지 셋의 기준선이 생깁니다.

준비

02_MATERIALS/restaurant/screen_spec_restaurant.html   ← 오늘의 입력

브라우저로 먼저 열어서 왼쪽 와이어프레임과 오른쪽 디스크립션을 눈으로 확인합니다. 번호 9개가 양쪽에 짝지어 있습니다.

절차

1단계 - 작업 폴더 만들기

form-restaurant/
├── index.html        (빈 파일로 생성)
└── storyboard.md     (빈 파일로 생성)

받은 설계서 파일이 있는 폴더에서 작업하지 마세요. 그 파일은 인쇄해서 받은 문서이지 프로젝트 폴더가 아닙니다.

2단계 - 설계서를 텍스트로 옮기기

screen_spec_restaurant.html을 브라우저에서 열고, 디스크립션 표 전체를 드래그해서 복사한 뒤 storyboard.md에 붙여넣습니다.

서식이 깨져도 상관없습니다. 60여 줄의 글자면 충분합니다.

3단계 - 지시하기

LLM 코딩 어시스턴트에 다음을 지시합니다.

@storyboard.md 를 참고해서 index.html 을 구현하는 plan.md 를 작성해줘.
한 번의 작업에서 API 호출이 분당 15회를 넘지 않도록 작업을 잘게 쪼개줘.

왜 plan.md를 거치나: 바로 구현시키면 중간에 멈추거나 절반만 만듭니다. 계획을 먼저 받아두면 끊겨도 이어서 시킬 수 있습니다.

plan.md를 눈으로 확인한 뒤:

plan.md 의 작업을 순서대로 진행해줘.

4단계 - 확인하기

1. 브라우저로 index.html을 엽니다 (로컬 서버 권장)
2. 필드를 전부 채우고 제출 버튼을 누릅니다
3. 개발자 도구 콘솔을 엽니다 (F12, Mac은 fn + F12)
4. 상단 Console 탭에서 출력된 값을 펼쳐봅니다

콘솔에 찍히는 이 객체가 Data 층입니다. 실제 서비스라면 이 모양 그대로 데이터베이스에 쌓입니다. 화면을 그린다는 감각에서 데이터가 오간다는 감각으로 넘어가는 지점이 여기입니다.

5단계 - mutable 확인하기

지역을 "강남"으로 골랐다가 "홍대"로 바꾼 뒤 다시 제출합니다. 콘솔을 보면 "강남"은 어디에도 없습니다.

이게 mutable입니다. 폼은 값을 고쳐 씁니다. 이전 값은 남지 않습니다.

완료 기준 [9/9]

[ ] 지역 드롭다운 - 옵션 5개
[ ] 종류 드롭다운 - 옵션 5개
[ ] 가격대 드롭다운 - 옵션 3개
[ ] 인원 숫자 입력 - 최소 1, 최대 20
[ ] 시간 선택기
[ ] 야외석 체크박스
[ ] 주차 체크박스
[ ] 인터넷 체크박스
[ ] 제출 버튼 -> 콘솔에 값 출력

함정

남기는 것

• 폼 화면 스크린샷 1장
• 콘솔 출력 스크린샷 1장
• 한 줄: 설계서에 있었는데 구현에 빠진 것 / 설계서에 없었는데 구현에 생긴 것

마지막 한 줄이 이 랩의 진짜 산출물입니다.

LAB 2 - 화면에서 설계서 뽑기 (역방향 · 코드 입력)

소요 40-50분 · 난이도 중간 · 산출 내가 만든 화면의 화면설계서 1장

방금 만든 index.html을 거꾸로 문서로 되돌립니다. 같은 6층을 반대 방향으로 통과시키는 것이 이 랩의 전부입니다.

왜 이 방향이 학습에 유효한가

사람이 화면을 설명하면 눈에 보이는 것만 말합니다. "드롭다운이 있고 버튼이 있어요."

LLM은 같은 화면을 컴포넌트 단위로 쪼개서 6층으로 설명합니다. 사람이 도제식으로 몇 년에 걸쳐 배우던 것을, 화면 하나당 1분이면 뽑아볼 수 있습니다.

그러니 이 랩의 목적은 문서를 만드는 게 아니라 처음 보는 설명을 만나는 것입니다. 모르는 용어가 나오면 그게 오늘의 수확입니다.

절차

1단계 - 새 대화를 연다

기존 대화를 이어 쓰면 앞의 구현 맥락이 섞여서 "이미 아는 것"을 그대로 베낍니다. 반드시 새 대화에서 시작합니다.

2단계 - 양식을 먼저 준다 (건너뛰면 실패한다)

@index.html 를 스토리보드 형태로 만들어줘.
왼쪽은 와이어프레임, 오른쪽은 디스크립션이야.

이렇게만 하면 대개 실패합니다. 여기서 시간을 가장 많이 잃습니다.

양식을 명시적으로 붙입니다.

@index.html 를 스토리보드로 만들어줘.
양식은 아래와 같아. 이 구조를 그대로 따라줘.

(02_MATERIALS/_template/screen_spec_template.md 전문을 붙여넣기)

출력은 storyboard_out.html 로 저장해줘.
plan.md 를 먼저 작성하고, 분당 15회 제한을 넘지 않게 작업을 쪼개줘.

3단계 - 6층으로 강제한다

산출물이 "드롭다운입니다" 수준으로 얕으면 다음을 덧붙입니다.

각 요소를 6층으로 설명해줘.
1층 기능 - 기술 용어 없이 이 요소가 무엇인지 한 줄
그 아래 UI / Logic / Data / API / Deploy
Data 는 이름 · 타입 · mutable 여부 · 기본값 4가지를 반드시 채워줘.

4단계 - 원본과 대조한다

뽑아낸 설계서를 LAB 1에서 입력으로 썼던 원본 설계서와 나란히 놓고 비교합니다.

원본 설계서  ←→  내 구현  ←→  역으로 뽑은 설계서

세 개가 한 바퀴입니다. 원본에 있었는데 사라진 항목, 원본에 없었는데 생긴 항목을 각각 적습니다.

완료 기준 [4/4]

[ ] 요소별 6층이 전부 채워진 설계서 1장
[ ] Data 층에 타입과 mutable 여부가 적혀 있다
[ ] 원본 대비 사라진 항목 목록
[ ] 원본 대비 생긴 항목 목록

함정

남기는 것

• 뽑아낸 설계서 파일
• 처음 보는 용어 3개 와 각각의 한 줄 뜻

세 번째 항목이 이 랩의 진짜 산출물입니다. 모르는 게 안 나왔다면 층을 덜 파고든 것입니다.

LAB 3 - 캡처 한 장으로 역기획 (핵심 랩)

소요 2-3시간 · 난이도 높음 · 산출 남의 서비스 화면 1장의 화면설계서 + (선택) 재현 구현

이 패키지의 중심입니다. 앞의 둘은 이 랩을 위한 준비였습니다.

역기획이란

순서가 뒤집힌 기획입니다.

신규 기획   기획 → 설계서 → 구현
역기획      관찰 → 구현 → 설계서 → 원본 대조

이미 존재하는 화면을 보고, 그 뒤에 숨은 설계 규칙을 복원합니다. 남의 완성품을 뜯어서 그 안의 결정을 읽어내는 훈련이고, 혼자 하는 실무 연습으로 가장 효율이 높습니다.

중요: 역기획 설계서에서 값어치 있는 칸은 기능 설명이 아니라 "왜 이렇게 만들었을까" 입니다. 그게 없으면 베껴 적은 문서입니다.

대상 고르기

일상적으로 쓰는 앱에서 화면 하나를 캡처합니다. 조건:

• 입력할 것이 있는 화면 (검색, 예약, 주문, 호출)
• 요소가 8-15개 정도 - 너무 단순해도 너무 복잡해도 안 됩니다
• 캡처가 아니라 지금 실제로 눌러볼 수 있는 화면

권장: 택시 호출, 배달 주문, 숙소 검색, 항공권 조회 중 하나.

절차

1단계 - 이미지를 읽히기

캡처를 이미지 판독이 되는 LLM에 넣습니다.

이 화면을 화면설계서(스토리보드) 형식으로 분해해줘.
- 요소마다 번호를 붙이고
- 6층으로 설명해줘 - 1층 기능(기술 용어 없이 한 줄) + UI / Logic / Data / API / Deploy
- 화면에 보이지 않지만 반드시 있어야 하는 상태와 예외도 적어줘

주의: 코딩 어시스턴트에 붙은 소형 모델은 이미지를 못 읽는 경우가 많습니다. 웹 챗 LLM 중 이미지 판독이 확실한 것으로 옮기세요. 이 우회는 실패가 아니라 정상 절차입니다.

2단계 - 눈으로 재검사

LLM 산출을 그대로 믿지 않습니다. 원본 캡처를 다시 보면서 어긋난 곳을 찾습니다. 여기가 이 랩의 알맹이입니다.

찾을 것 세 가지:

세 번째까지 찾으면 그 화면을 이긴 것입니다.

3단계 - 확정하고 근거를 적기

애매한 것은 택일하고 근거를 남깁니다.

③ 내 위치 마커가 ④ 출발 핀과 위치가 다르다. 이유는 둘 중 하나다.
  (A) 내 위치 = GPS 원좌표, 출발 핀 = 도로변으로 스냅된 픽업 지점  → 정상 동작
  (B) 내 위치 = 인근 배차 가능 차량                              → 과잉 정보
→ (A)로 확정한다. 근거: 마커가 1개뿐이고 도로 위에 놓여 있다.

"모르겠다"로 두면 문서가 아닙니다. 가설 + 근거 + 확정까지 가야 설계서입니다.

4단계 (선택) - 재현 구현

설계서를 LAB 1의 방식으로 코드로 밀어봅니다. 지도가 필요하면 키가 필요 없는 오픈소스 지도를 씁니다.

상용 지도 SDK는 개발자 등록과 도메인 심사가 필요합니다. 어렵진 않지만 오늘 할 일은 아닙니다.

5단계 - 문서에 없던 빈칸 기록하기

구현하면 문서 위에서는 안 보이던 구멍이 반드시 드러납니다.

예를 들면 이런 식입니다.

설계서에 "반경 50m 내 장소를 역지오코딩해서 표시명 결정"이라고 적었다.
그런데 50m 안에는 장소가 여러 개 있고, 그중 무엇을 고를지는 안 정해 놨다.
돌려보니 지도 서버는 "가장 가까운 것"을 돌려줬고, 사람이 아는 랜드마크가 아니었다.
표시명 우선순위를 직접 정해야 했다.

이 기록이 이 랩의 최고 산출물입니다. 설계서가 완벽해 보였는데 구현이 뚫은 구멍이야말로 면접에서 이야기할 거리입니다.

완료 기준 [5/5]

[ ] 요소 8개 이상 × 6층
[ ] 화면에 안 보이는 상태(state) 목록
[ ] 예외 상황 목록 (실패하면 어떻게 되는가)
[ ] "왜 이렇게 만들었을까" 추정 의도 - 요소마다 1줄
[ ] 구현하면서 드러난 문서의 빈칸 - 최소 1건

함정

남기는 것

• 화면설계서 1장
• (선택) 재현 구현
• 확인 못 한 항목 목록 - 실제 앱을 눌러 채울 다음 회차의 입력

LAB 4 - 같은 로직, 다른 껍데기

소요 30-40분 · 난이도 낮음 · 산출 같은 기능의 다른 브랜드 버전 1개

6층 중 UI만 바뀌고 나머지는 그대로라는 것을 손으로 확인하는 랩입니다. 짧고, 재미있고, 개념이 몸에 박힙니다.

절차

1단계 - 뼈대 고르기

02_MATERIALS/taxi/ 의 택시 호출 폼을 씁니다. 슬롯은 넷입니다.

출발지 · 도착지 · 출발 시간 · 차량 종류

이 넷은 어떤 브랜드로 바꿔도 그대로입니다. 차가 움직이는 이상 출발지와 도착지는 반드시 필요합니다.

2단계 - 껍데기 갈아끼우기

같은 폼을 전혀 다른 맥락으로 다시 만듭니다. 예시:

지시는 이 정도면 충분합니다.

@taxi.html 을 (   ) 느낌으로 다시 만들어줘.
기능과 필드는 그대로 두고 UI만 바꿔줘.
누가 봐도 (   ) 에서 쓰는 화면이라는 게 보이게.

3단계 - 무엇이 안 바뀌었는지 적기

만든 뒤 바뀐 것과 안 바뀐 것을 표로 정리합니다.

바뀐 것    : 색 / 폰트 / 문구 / 아이콘 / 선택지 이름
안 바뀐 것 : 슬롯 4개 / submit 이벤트 / formData 구조 / API 없음 / 정적 HTML

이 표가 산출물입니다.

완료 기준 [3/3]

[ ] 변주 버전 1개가 동작한다
[ ] 슬롯 4개가 그대로 유지된다
[ ] 바뀐 것 / 안 바뀐 것 표 1장

함정

남기는 것

• 변주 버전 1개
• 바뀐 것 / 안 바뀐 것 표
• 한 줄: 이 서비스의 슬롯은 무엇이고, 왜 그것이 반드시 필요한가

마지막 한 줄이 이 랩의 진짜 산출물입니다. 차가 움직이는 이상 출발지와 도착지는 어떤 브랜드로도 뺄 수 없습니다. 그 필연성을 말로 옮기는 것이 슬롯을 이해했다는 증거입니다.

마무리 - 6층 비교표

세 도메인을 다 만들었다면 마지막으로 이 표를 채웁니다. 빈 틀은 05_ASSESS/ 에 있습니다.

채우고 나면 한 문장이 남습니다.

도메인이 바뀌면 UI(필드 모양)와 슬롯(받을 정보)이 바뀐다. Logic · API · Deploy는 거의 그대로다.

이 문장이 다음 단계(같은 서비스를 대화형·에이전트로 바꾸기)의 출발점입니다.

진행표 - 하루 8세션

가르치는 사람용. 혼자 하는 사람은 00_START_HERE.md 순서를 따르면 됩니다.

권장 편성 (실측 반영판)

LAB 4는 빨리 끝낸 학생용 추가 과제로 돌립니다.

실측 경고 - 편성이 밀리는 지점

1회차 운영에서 이렇게 어긋났습니다. 같은 실수를 피하려면 읽어두세요.

세션 운영 규칙

1. 이론은 짧게, 사례는 실물로

개념 문서 3개를 다 읽어주지 마세요. 01_화면설계서란 의 1-1, 1-2, 1-6만 말로 하고 나머지는 읽기 과제로 돌립니다. 대신 실제 설계서 파일을 화면에 띄우고 번호를 하나씩 짚습니다.

2. 시연에서 반드시 보여줄 장면 2개

• 콘솔의 Data: 값을 바꿨을 때 이전 값이 사라지는 것 (mutable)
• 번호가 화면에 렌더링되는 사고: 그리고 한 줄로 고치는 것

두 번째가 특히 좋습니다. LLM이 문서를 곧이곧대로 읽는다는 것과, 사람이 한 줄로 교정한다는 것을 동시에 보여줍니다.

3. 막힌 학생 3열 대응

증상 확인 → 옆 사람 화면과 비교 → 강사 호출

바로 강사가 붙지 않습니다. 두 번째 단계에서 대부분 풀립니다.

4. 개별 점검은 세션 안에서

S7에 15분씩 개별 점검을 넣으면 진도가 갈립니다. 10분 x 2회 로 쪼개고, 나머지는 전체 공지로 처리합니다.

제출 마감

수업 종료 시점이 아니라 당일 자정으로 잡습니다. 마감을 당기면 제출 수가 아니라 완성도가 떨어집니다. 마지막 세션은 만들던 것을 정리하고 QA하는 시간이지 새로 만드는 시간이 아닙니다.

시연 대본 - 설계서로 화면 만들기 (S2용)

소요 25분 · 화면 공유 상태로 진행

0. 시작 문장

"지금부터 문서 하나를 코드로 밀어보겠습니다. 저는 코드를 한 줄도 안 씁니다."

1. 설계서를 연다 (5분)

screen_spec_restaurant.html 을 브라우저로 엽니다.

• "왼쪽이 화면 뼈대, 오른쪽이 설명입니다. 번호가 짝지어져 있죠."
• 1번(지역)을 확대합니다. "이 안에 다섯 개 층이 다 들어 있습니다."
• 6층을 소리 내어 읽습니다. 기능 → UI → Logic → Data → API → Deploy
• "맨 위 한 줄이 기능입니다. 여기까지는 개발 몰라도 읽힙니다. 이게 없으면 나머지를 아무도 안 읽어요."
• 2-3번을 빠르게 훑습니다. "어떤 건 세 줄이고 어떤 건 한 줄입니다. 기능이 많으면 길어집니다."

여기서 던질 질문: "왜 지역은 드롭다운이고 출발지는 텍스트 입력일까요?"

답: 선택지가 정해져 있으면 드롭다운, 무한하면 텍스트.

2. 빈 폴더를 만든다 (2분)

form-restaurant/
├── index.html      ← 비어 있음
└── storyboard.md   ← 비어 있음

"받은 설계서 파일이 있는 폴더에서 작업하지 마세요. 그건 인쇄해서 받은 문서입니다."

3. 설계서를 붙여넣는다 (2분)

디스크립션 표를 드래그해서 storyboard.md 에 붙여넣습니다.

"서식 다 깨졌죠. 상관없습니다. 글자 60줄입니다."

4. 지시한다 (5분)

@storyboard.md 를 참고해서 index.html 을 구현하는 plan.md 를 작성해줘.
분당 15회를 넘지 않도록 작업을 조절해줘.

"왜 plan을 먼저 받냐면, 바로 시키면 중간에 멈춥니다. 계획이 있으면 이어서 시킬 수 있어요."

plan.md 확인 후:

plan.md 의 작업을 순서대로 진행해줘.

5. 결과를 연다 (5분)

로컬 서버로 index.html 을 엽니다.

여기서 번호가 화면에 같이 나옵니다. (실측: 실제로 그렇게 됩니다)

"번호까지 그려버렸네요. 왜 그럴까요?"
"문서에 번호가 적혀 있으니까 그것도 화면 요소라고 읽은 겁니다. 사람은 이게 문서용 표기라는 걸 아는데, 얘는 모릅니다."

한 줄로 고칩니다.

번호는 설계도를 문서화하려고 붙인 것이고 UI가 아니야. 빼줘.

다시 열어서 사라진 것을 확인합니다.

이 장면이 오늘 시연의 핵심입니다. 문서를 곧이곧대로 읽는다는 것, 그리고 사람이 한 줄로 교정한다는 것.

6. 콘솔을 연다 (6분)

필드를 다 채우고 제출합니다. F12 (Mac은 fn + F12) → Console 탭.

"이 객체가 Data 층입니다. 실제 서비스면 이 모양 그대로 데이터베이스에 쌓입니다."

mutable 시연: 지역을 강남에서 홍대로 바꾸고 다시 제출합니다.

"강남이 어디 갔죠? 없습니다. 이게 mutable입니다. 폼은 고쳐 씁니다."
"내일(또는 다음 단계) 대화형으로 바꾸면 이게 문제가 됩니다. '아까 말한 그거'를 못 찾거든요."

마무리 문장

"여기까지가 문서에서 화면으로 가는 방향입니다. 이제 여러분이 해보시고, 오후에는 거꾸로 갑니다."

시연 대본 - 역기획 (S4용)

소요 30분 · 실패 장면을 포함한 대본입니다

0. 시작 문장

"오전에는 문서를 화면으로 밀었습니다. 이제 거꾸로 갑니다. 그리고 미리 말씀드리면, 이쪽이 훨씬 잘 실패합니다."

1. 왜 거꾸로 하는가 (5분)

"화면을 보고 설명해보라고 하면 사람은 눈에 보이는 것만 말합니다. 드롭다운 있고 버튼 있어요."
"그런데 얘한테 시키면 컴포넌트 단위로 쪼개서 여섯 층으로 설명합니다. 그게 우리가 도제식으로 몇 년 걸려 배우던 겁니다."

2. 첫 시도 - 그리고 실패한다 (7분)

새 대화를 엽니다.

@index.html 를 한 장의 스토리보드로 만들어줘.
왼쪽은 와이어프레임, 오른쪽은 디스크립션이야.

대개 실패합니다. 실패하면 그대로 보여줍니다.

"안 되네요. 왜 안 될까요?"
"양식을 안 줬습니다. '스토리보드로 만들어줘'는 우리끼리는 통하는 말인데, 얘한테는 아무 형태도 없는 말입니다."

실패를 감추지 마세요. 학생은 곧 같은 실패를 합니다. 강사가 먼저 겪는 장면을 봐야 자기 실패를 정상으로 받아들입니다.

3. 양식을 주고 다시 (8분)

템플릿 전문을 붙여넣습니다.

@index.html 를 스토리보드로 만들어줘. 양식은 이거야.

(screen_spec_template.md 전문)

plan.md 를 먼저 작성하고, 분당 15회 제한을 넘지 않게 쪼개줘.

이번엔 나옵니다.

"양식이 있고 없고 차이가 이겁니다."

4. 이미지로 넘어간다 (10분)

캡처 이미지를 넣어봅니다.

이 이미지를 화면설계서 형태로 바꿔줘.

코딩 어시스턴트에 붙은 소형 모델은 대개 못 읽습니다.

"이미지를 못 읽네요. 이건 모델 한계입니다."
"그러면 도구를 바꿉니다. 이미지 판독이 되는 쪽으로 옮기세요."

다른 LLM에서 같은 요청을 하면 나옵니다.

"이렇게 도구를 갈아타는 것도 기술입니다. 하나로 다 하려다 시간을 버립니다."
"규칙으로 하나 정합시다. 비정형 데이터(이미지) 분석은 판독 되는 도구로."

산출을 다시 코드 쪽으로 가져와 구현시킵니다.

"엉망이죠. 우리가 준 원본과 많이 다릅니다."
"그런데 중요한 건 이겁니다. UI는 달라도, 로직과 데이터와 API를 명세할 수 있으면 시스템을 본떠 옮길 수 있다는 것."

마무리 문장

"오늘 과제는 여러분이 실제로 쓰는 앱 화면 하나입니다. 구현은 안 하셔도 됩니다. 문서가 필수입니다."
"화면을 뜯으면 UI가 아니라 로직이 어때야 하는지가 줄줄 나옵니다. 뭔 소리지 싶은 것들이 나올 텐데, 그게 오늘의 수확입니다."

함정과 대응

이 패키지를 준비하고 진행하면서 실제로 마주치는 것들입니다.

A. 도구 함정

B. 환경 함정

B2·B3은 Deploy 층을 왜 쓰는지 보여주는 최고의 사례입니다. 발생하면 그 자리에서 개념과 연결하세요.

C. 문서 함정

C5가 이 패키지의 품질을 가릅니다. 구현은 도구가 해주지만 판단은 안 해줍니다. 추정 의도 칸이 AI 문장으로만 채워져 있으면 그 산출물은 미완성입니다.

D. 진행 함정

E. 마감 QA

가장 흔한 미완성 패턴은 만들어놓고 안 눌러보는 것입니다. 산출물은 있는데 버튼이 동작하지 않고, 문서에 적은 것과 실제가 다릅니다.

S7 마지막 10분을 QA 전용으로 못 박습니다. 항목은 셋입니다.

[ ] 모든 버튼을 한 번씩 눌러본다
[ ] 콘솔에 에러가 없는지 본다
[ ] 문서에 적은 것과 실제 동작이 같은지 3개만 대조한다

평가 루브릭

산출물 채점 기준. 자기 채점에도 그대로 씁니다.

채점 대상 3종

1. 정방향 구현물 (LAB 1)
2. 역기획 설계서 (LAB 3)
3. 회고 (4Ls)

1. 정방향 구현물 - 30점

2. 역기획 설계서 - 50점 (핵심)

추정 의도 채점 눈금

15점 답안이 이 패키지의 도달 목표입니다.

3. 회고 - 20점

4Ls(Liked / Learned / Lacked / Longed for) 각 5점.

채점 포인트는 Lacked입니다. 자기가 못 한 것을 구체적으로 쓴 사람이 다음 회차에 늘어납니다.

통과선

• 80점 이상: 다음 단계(대화형·에이전트 전환)로 넘어가도 됨
• 60-79점: 역기획을 한 번 더. 대상을 바꿔서
• 60점 미만: LAB 1·2를 다시. 정방향이 안 되면 역방향은 안 됨

채점자 주의

구현물의 완성도로 점수를 주지 마세요. 예쁘게 만든 것과 잘 이해한 것은 다릅니다.

배점이 역기획 설계서에 50점, 그중 20점이 "추정 의도 + 빈칸"에 몰려 있는 이유입니다. 구현은 도구가 해줍니다. 판단은 안 해줍니다.

완료 체크리스트

랩마다 이 표로 자기 채점합니다. 전부 채우면 하루가 끝납니다.

LAB 1 - 설계서로 화면 만들기 [9/9]

[ ] 지역 드롭다운 - 옵션 5개
[ ] 종류 드롭다운 - 옵션 5개
[ ] 가격대 드롭다운 - 옵션 3개
[ ] 인원 숫자 입력 - min 1 / max 20
[ ] 시간 선택기
[ ] 야외석 체크박스
[ ] 주차 체크박스
[ ] 인터넷 체크박스
[ ] 제출 버튼 -> 콘솔에 값 출력

추가 확인:

[ ] 문서용 번호가 화면에 남아 있지 않다
[ ] 값을 바꾸면 이전 값이 사라지는 것(mutable)을 콘솔에서 봤다

LAB 2 - 화면에서 설계서 뽑기 [4/4]

[ ] 요소별 6층이 채워진 설계서 1장
[ ] Data 층에 타입 / mutable 여부 / 기본값이 있다
[ ] 원본 대비 사라진 항목을 적었다
[ ] 원본 대비 생긴 항목을 적었다

LAB 3 - 캡처 역기획 [5/5]

[ ] 요소 8개 이상 x 6층
[ ] 화면에 안 보이는 상태(state) 목록
[ ] 예외 상황 목록
[ ] 요소마다 추정 의도 1줄 - 내 판단이 들어가 있다
[ ] 구현하며 드러난 문서의 빈칸 1건 이상

LAB 4 - 브랜드 변주 [3/3]

[ ] 변주 버전이 동작한다
[ ] 슬롯이 그대로 유지된다
[ ] 바뀐 것 / 안 바뀐 것 표

마감 QA (10분, 생략 금지)

[ ] 모든 버튼을 한 번씩 눌렀다
[ ] 콘솔에 에러가 없다
[ ] 문서에 적은 것과 실제 동작을 3개 대조했다

이 10분을 빼면 "만들었는데 안 눌러본" 상태로 끝납니다. 문서에 적은 동작과 실제가 다른 채로 제출됩니다.

6층 비교표 (마무리)

채운 뒤 한 문장으로 요약합니다.

도메인이 바뀌면 ( )가 바뀌고, ( )는 그대로다.

제출 틀

혼자 하면 자기 기록용, 가르치면 제출 양식입니다.

1. 산출물

저장소 주소 또는 배포 주소:
(둘 다 없으면 화면 캡처 첨부)

2. 진행 기록 (스크럼 3점)

[시작 시점]
- 지금 준비된 것은?
- 오늘 무엇을 할 예정인가?
- 막을 것 같은 요소는?

[중간 점검]
- 지금 어디까지 됐나?
- 다음에 무엇을 할 건가?
- 막고 있는 것은?

[완료 점검]
- 무엇을 했나?
- 무엇이 막혔나?

세 시점을 각각 그 시점에 씁니다. 끝나고 한 번에 몰아 쓰면 기록이 아니라 요약이 됩니다.

3. 회고 (4Ls)

Liked     (좋았던 것):
Learned   (배운 것):
Lacked    (부족했던 것):
Longed for(바라는 것):

Lacked를 구체적으로 쓰세요. "시간이 부족했다"는 아무것도 아닙니다. 무엇을 확인 못 했는지, 어느 판단이 내 것이 아닌지를 적습니다.

4. 오늘의 빈칸 (필수)

설계서에는 (              ) 라고 적혀 있었는데,
실제로 돌려보니 (              ) 였다.
그래서 (              ) 를 새로 정했다.

이 세 줄이 하루의 최종 산출물입니다. 구현은 도구가 해주지만 이 빈칸은 사람만 찾습니다.

운영 실측 - 1회차

이 패키지의 편성과 시간 배분은 설계가 아니라 실제로 한 번 굴려본 기록에서 나왔습니다. 무엇이 밀렸고 무엇을 잘라야 하는지의 근거입니다.

조건

편성이 밀린 지점

가장 큰 교훈은 첫 줄입니다. 이 주제는 말할 거리가 많아서 이론이 오전을 다 먹습니다. 개념 문서 3개를 다 읽어주면 반드시 밀립니다.

도구 장애

하루 동안 실제로 발생한 것들입니다.

시연 실패를 공개한 것이 좋은 장면이 됐습니다. 강사가 먼저 막히는 것을 본 사람은 자기 실패를 정상으로 받아들입니다. 04_INSTRUCTOR/시연대본_역기획.md가 실패 장면을 대본에 포함시킨 이유입니다.

무엇이 통했나

1. 콘솔에서 mutable을 눈으로 보는 장면

값을 바꾸면 이전 값이 사라지는 것을 화면에서 직접 보여주는 것. 말로 설명할 때와 반응이 달랐습니다.

2. 번호가 화면에 렌더링되는 사고

강사 시연에서 실제로 발생했고 한 줄로 고쳤습니다. "LLM은 문서를 곧이곧대로 읽는다"와 "사람이 한 줄로 교정한다"를 동시에 보여주는 장면이라 대본의 핵심으로 승격했습니다.

3. 역기획으로 과제를 바꾼 것

브랜드 변주보다 실제 서비스 화면 역기획이 훨씬 깊은 작업을 만들었습니다. 그래서 LAB 3이 이 패키지의 중심이 됐고 배점도 50점입니다.

이 패키지에 반영된 것

패키지 규격서

이 패키지를 개작하거나 다른 도메인으로 확장할 때 읽습니다. 각 파일이 무슨 규격인지, 무엇을 바꾸면 무엇이 깨지는지의 정본입니다.

작성 근거: 성인 17명 대상 1일 과정을 실제로 운영한 1회차 기록. 편성·시간 배분·도구 장애 실측 = 06_EVIDENCE/운영_실측.md.

1. 제품 정의

약속하지 않는 것: 디자인 실력, 피그마 숙련, 프로덕션 코드 품질.

2. 단 하나의 프레임

패키지 전체가 6층으로 통일돼 있습니다. 1층(기능)이 맨 위에 오고 그 아래 다섯 층이 붙습니다.

[한 줄 요약]  일상어로 이 요소가 무엇인지
[UI]          어떻게 보이는가
[Logic]       무엇을 하면 무엇이 되는가
[Data]        이름 / 타입 / mutable 여부 / 기본값
[API]         어디서 가져오고 어디로 보내는가
[Deploy]      어디에 올라가고 무슨 조건이 붙는가

이 6칸은 모든 파일에서 같은 순서, 같은 이름으로 씁니다. 순서를 바꾸거나 이름을 바꾸면 재료·랩·루브릭이 서로 안 맞게 됩니다.

Data의 4항목(이름·타입·변경성·기본값)도 고정입니다. 이 넷이 이후 단계(대화형 전환)에서 mutable/append 대비의 기반이 됩니다.

3. 파일 규격

3-1. 화면설계서 (02_MATERIALS/*/screen_spec_*.html|md)

3-2. 완성 실물 (answer_*.html)

3-3. 스타터 (starter_*.html)

3-4. 랩 (03_LAB/LAB*.md)

각 랩은 아래 6절을 반드시 갖습니다. 절이 빠지면 랩이 아닙니다.

1. 소요 · 난이도 · 산출        (한 줄)
2. 준비물 또는 입력 파일
3. 절차 - 단계마다 확인 방법 포함
4. 완료 기준 [n/n] 체크박스
5. 실측 함정 표 (증상 / 원인 / 대응)
6. 남기는 것 - 마지막 항목이 진짜 산출물

5번은 실제로 발생한 것만 적습니다. 추정으로 채우지 않습니다.

3-5. 시연 대본 (04_INSTRUCTOR/시연대본_*.md)

실패 장면이 없는 대본은 반려합니다. 학습자는 곧 같은 실패를 하고, 강사가 먼저 겪는 걸 봐야 자기 실패를 정상으로 받아들입니다.

4. 도메인 추가하는 법

새 도메인(예: 항공권 조회, 병원 예약)을 넣으려면 4개를 만듭니다.

02_MATERIALS/<domain>/
├── screen_spec_<domain>.html   화면설계서
├── answer_<domain>.html        완성 실물
├── starter_<domain>.html       스타터
└── (선택) screen_spec_<domain>.md

슬롯을 먼저 정합니다. 그 업무가 성립하려면 반드시 받아야 하는 정보가 무엇인지. 예약이면 무엇을·언제·누가·얼마에. 슬롯이 정해지면 UI는 따라옵니다.

슬롯 정하는 기준:

• 선택지가 정해져 있고 5개 이상 -> 드롭다운
• 선택지 3개 이하이고 하나만 -> 라디오
• 여러 개 동시 선택 가능 -> 체크박스
• 선택지가 무한 -> 텍스트 입력
• 숫자·시간·날짜 -> 전용 입력 타입

5. 난이도 계단

scaffolding을 단계적으로 걷어내는 설계입니다. 순서를 바꾸면 무너집니다.

식당(1) -> 택시(2) -> 숙소(3) -> 캡처 역기획(4).

운영 경고: 1회차에서 1단계에 시간을 다 쓰고 2-3단계가 미소비로 남았습니다. 하루에 4단계를 다 돌릴 계획을 세우지 마세요. 1 + 4 조합이 현실적입니다.

6. 개작 금지 항목

바꾸면 패키지가 깨지는 것들입니다.

7. 이 패키지 다음에 오는 것

같은 6층으로 이어지는 후속 조각들입니다. 이 패키지는 그 사슬의 첫 칸입니다.

각 칸은 앞 칸의 산출물을 입력으로 받습니다. 그래서 6층 프레임을 바꾸면 안 됩니다.