# How to build with LLM

## NDM 기반 프로토타이핑 통합 설명교재

> 이 문서는 **LLM(ChatGPT / Claude / Claude Code 같은 AI 도구)을 써서 아이디어를 어떻게 작게 만들고, 무엇을 먼저 배우고, 어떻게 설계로 연결할지**를 다루는 통합 교재입니다.
>
> 목표는 큰 서비스를 바로 완성하는 것이 아닙니다.
> **NDM 관점에서 상황을 읽고, 프로토타이핑으로 작은 실험을 설계하고, LLM으로 그 과정을 더 빠르게 전개하는 것**이 목표입니다.
>
> 이 문서는 별도의 초기 검증 개념을 끌어오지 않고,
> **프로토타이핑 안에서 설명을 닫습니다.**

---

## Glossary

- **NDM (Naturalistic Decision Making)**: 실제 현장의 복잡한 상황에서 사람들이 어떻게 판단하는지 다루는 연구 관점
- **RPD (Recognition-Primed Decision)**: `상황 인식 -> 첫 행동 후보 생성 -> mental simulation 점검`으로 이어지는 대표 모델
- **Mental simulation**: 머릿속으로 다음 전개를 짧게 돌려보며 행동의 성립 가능성을 점검하는 과정
- **프로토타이핑**: 아이디어를 작은 형태로 드러내 질문에 답해보는 과정
- **프로토타입**: 그 질문에 답하기 위해 만든 구체적인 실험물
- **LLM**: 가설 정리, 실험 초안 작성, 기록 정리를 빠르게 도와주는 언어모델
- **증거**: 클릭, 신청, 재사용, 인터뷰 반응, 관찰 메모처럼 다음 판단에 도움이 되는 신호

이 문서에서 쓰는 `NDM의 프로토타이핑`이라는 표현은
정전 용어를 그대로 옮긴 말이라기보다,
**NDM의 판단 구조를 수업용 프로토타이핑 설명에 연결한 해석적 표현**입니다.

---

## 이 문서를 읽는 방법

이 문서는 사전처럼 한 번에 외우기 위한 문서가 아닙니다.
오히려 한 프로젝트를 진행하면서 **앞에서 읽고, 해보고, 다시 돌아와 읽는 문서**에 가깝습니다.

처음 읽을 때는 아래 다섯 가지만 잡아도 충분합니다.

1. 프로토타이핑은 완성품 제작이 아니라 **학습을 위한 실험**이라는 점
2. NDM은 `최적의 답 찾기`보다 `지금 성립하는 다음 행동 찾기`에 가깝다는 점
3. 큰 목적보다 **다음 상태**를 잡아야 실험이 작동한다는 점
4. LLM은 실험 속도를 높여주지만 **증거를 대신하지는 못한다**는 점
5. 배운 것을 기록해야 다음 설계로 넘어갈 수 있다는 점

읽는 순서도 이렇게 잡으면 좋습니다.

- 처음 읽을 때는 `0. 출발점`부터 `6. 무엇을 증거로 볼까?`까지 읽습니다.
- 실제로 프로젝트를 시작할 때는 `7. 키트의 기본 구성`부터 `9. 사용 예시`를 봅니다.
- 발표나 정리 직전에는 마지막 `11. 강의용 설명 문안`과 `12. 해석 범위와 불확실`을 다시 봅니다.

---

## 이 문서의 기준

- 프로토타이핑은 **예쁘게 만드는 일**보다 **무엇을 배우려는지 정하고 작게 시험하는 일**에 가깝습니다.
- Fake Door, Concierge, Wizard of Oz, Manual-first Report, Paper / Role-play, Tiny Functional Prototype은 모두 **질문에 맞게 고르는 프로토타이핑 방식**으로 다룹니다.
- `NDM의 프로토타이핑`은 NDM 원문 개념 그 자체라기보다, **NDM의 판단 구조와 생각을 바깥으로 드러내는 실험 기능을 연결한 수업용 설명**으로 다룹니다.
- LLM은 가설 정리, 실험 초안, 기록 정리, 설계 연결에 강하지만, **현실 사용자 증거를 대신하지는 못합니다**.
- 프로젝트 폴더는 단순 저장소가 아니라, **LLM과 사람이 함께 읽는 작업 기록**입니다.
- 순서는 늘 같습니다.
  **상황 읽기 -> 다음 상태 -> 첫 행동 -> 프로토타이핑 -> 증거 -> 설계**

즉, 이 문서는 "LLM으로 바로 코드를 만드는 법"보다
**LLM으로 더 잘 배우고, 더 나은 것을 만들기 시작하는 법**에 더 가깝습니다.

---

## 완료 판단 루브릭

이 문서는 끝까지 읽었는지보다, 읽고 나서 무엇을 더 분명하게 볼 수 있는지를 기준으로 닫습니다.

### Must

1. 지금 보는 상황과 다음 상태를 각각 한 문장으로 말할 수 있다.
2. 선택한 프로토타입이 어떤 질문에 답하는지와 무엇을 증거로 볼지 연결할 수 있다.
3. 완료 미달이면 짧게 회고하고, 배운 점을 반영해 다음 실험을 조정할 수 있다.

### Should

1. NDM, mental simulation, 증거 같은 용어를 장면 안에서 설명할 수 있다.
2. 만든 결과물보다 새로 드러난 판단과 다음 행동을 더 선명하게 남길 수 있다.

이 기준을 통과하지 못하면 실패로 닫지 않습니다.
그때는 **Feedback and Adapt**, 즉 진행 경험에서 드러난 것을 보고 다음 실험을 의도적으로 줄이거나 바꿉니다.

### 증거 기록 3줄

루브릭이 아직 흐리면 긴 보고서보다 아래 세 줄을 먼저 남깁니다.
글을 더 쓰는 일이 아니라, 진행하면서 보이지 않던 판단을 드러내는 일입니다.

1. **오늘 본 상황**: 누가 어떤 장면에서 막히거나 반응했는지 적습니다.
2. **시험한 작은 행동**: 어떤 프로토타입 방식으로 무엇을 확인했는지 남깁니다.
3. **다음에 바꿀 점**: 관찰을 바탕으로 줄일 것, 바꿀 것, 다시 물어볼 것을 하나만 정합니다.

---

## 0. 출발점

아이디어가 떠오르면 본능적으로 이렇게 생각하기 쉽습니다.

> "좋은데? 바로 만들어보자."

그런데 실제로는 그 사이에 질문이 더 들어가야 합니다.

1. **사람들이 이걸 정말 원하나?**
2. **이 흐름이 자연스럽게 작동하나?**
3. **정말 만든다면 어떤 방식으로 구현해야 하나?**

그리고 NDM 관점에서는 여기에 한 질문이 더 선명하게 붙습니다.

- **지금 나는 무슨 상황을 보고 있나?**
- **다음으로 어떤 상태가 성립해야 하나?**
- **지금 떠오른 한 걸음이 맞나?**

이 문서의 핵심은 간단합니다.

> **바로 크게 만들기 전에, 지금의 판단을 작은 실험으로 꺼내서 배운다.**

처음 배우는 사람이 자주 만나는 장면은
첫날부터 완성 화면을 상상하고,
둘째 날부터 기능 목록을 적기 시작하는 것입니다.

그러면 얼핏 열심히 일한 것처럼 보입니다.
하지만 정작 아직 답하지 못한 질문은 남아 있습니다.

- 사람들이 이 문제를 실제로 불편해하는가?
- 지금 설명 방식이 이해되는가?
- 사용자는 이 흐름을 따라올 수 있는가?
- 이 기능 중 꼭 필요한 것은 무엇인가?

이 문서는 그 순서를 바로잡기 위해 쓰였습니다.

---

## 1. NDM으로 보면 왜 이 순서가 자연스러운가

NDM은 사람들이 현실 세계에서 어떻게 판단하는지를 봅니다.
그 현실 세계는 보통 이런 특징을 가집니다.

- 시간이 충분하지 않다
- 정보가 완전하지 않다
- 상황이 계속 바뀐다
- 여러 사람이 얽혀 있다
- 결과의 위험이 작지 않다

이런 환경에서는 사람들이
모든 대안을 길게 비교하고,
점수를 매기고,
가장 좋은 답을 계산해서 움직이기 어렵습니다.

NDM 연구는 오히려 많은 전문가가 다음처럼 움직인다고 봅니다.

1. **상황을 먼저 읽는다**
2. **경험에 비춰 그럴듯한 첫 행동 후보를 떠올린다**
3. **그 행동이 먹힐지 mental simulation으로 짧게 점검한다**
4. **버틸 만하면 실행한다**

그래서 NDM의 초점은 `최적의 답 찾기`보다
`지금 이 상황에서 성립하는 다음 행동 찾기`에 가깝습니다.

### 왜 "목적지"보다 "다음 상태"가 중요한가

처음 배우는 사람은 자주 이렇게 묻습니다.

> "내 목적지는 어디지?"

필요한 질문입니다.
하지만 이 질문이 너무 커지면 실제 행동이 멈춥니다.

NDM 식으로 줄이면 질문은 이렇게 바뀝니다.

- 나는 어디로 가는가?
  -> 이 상황에서 **다음으로 무엇이 성립해야 하는가?**
- 무엇을 만들 것인가?
  -> 그 상태를 만들 **첫 행동은 무엇인가?**
- 이게 맞는가?
  -> 그 한 걸음을 **어떻게 가장 작게 시험할 것인가?**

### 사용자의 질문을 NDM 언어로 바꾸면

- `지금 내가 뭘 하는지?`
  -> situation assessment 또는 sensemaking에 가깝습니다.
- `내가 목적지로 삼는 데는 어디지?`
  -> 최종 목적보다 `다음 workable state`를 정하는 일에 가깝습니다.
- `이게 맞나?`
  -> 현재 떠오른 행동이 먹힐지 mental simulation으로 짧게 점검하는 흐름에 가깝습니다.

즉, NDM에서 프로토타이핑은 단순한 자기점검이 아니라,
**상황 읽기와 행동 가설을 바깥으로 꺼내 검증하는 작업**에 가깝습니다.

### 프로토타입은 여기서 왜 필요한가

머릿속 판단은 빠르지만 흐릿합니다.
프로토타입은 그 흐릿함을 바깥으로 꺼내 보여줍니다.

그래서 프로토타이핑은 보통 세 가지를 해줍니다.

1. 보이지 않던 생각을 드러낸다
2. mental simulation을 더 구체화한다
3. 다른 사람과 함께 검토할 수 있게 만든다

즉, 프로토타입은 mental simulation을 대체하기보다
**그 판단을 더 구체적이고 검증 가능한 형태로 바꾸는 도구**입니다.

---

## 2. 프로토타이핑이란?

이 문서에서 말하는 프로토타이핑은
완성품을 만들기 전,
아이디어를 작게 드러내고 반응을 보며 배우는 모든 실험을 가리킵니다.

중요한 점은 하나입니다.

> **프로토타이핑은 "예쁘게 시제품을 만드는 일"이 아니라 "무엇을 배울지 정하고 작게 시험하는 일"입니다.**

그래서 프로토타이핑은 한 가지 질문만 다루지 않습니다.
상황에 따라 서로 다른 질문에 답할 수 있습니다.

| 보고 싶은 것 | 던지는 질문 | 예시 |
| --- | --- | --- |
| 가치 | 사람들이 이 문제를 실제로 불편해하나? | 신청 버튼, 샘플 결과물 |
| 사용 흐름 | 입력하고 결과를 보는 과정이 자연스러운가? | 종이 화면, 역할극, Wizard of Oz |
| 구현 방향 | 정말 만든다면 어떤 기능과 구조가 필요한가? | 단일 HTML/JS 도구, 작은 앱, CLI 초안 |

즉, 프로토타이핑은 한 번으로 끝나는 단계가 아니라,
**질문이 바뀔 때마다 다른 형태로 계속 이어지는 과정**입니다.

여기서 중요한 차이를 하나 더 분명히 해두면 좋습니다.

| 구분 | 프로토타입 | 최종 서비스 |
| --- | --- | --- |
| 목적 | 배우기 | 안정적으로 제공하기 |
| 범위 | 필요한 만큼만 작게 | 실제 사용을 감당할 만큼 충분히 |
| 완성도 | 질문에 답할 정도면 충분 | 오류 대응, 운영, 유지보수까지 필요 |
| 평가 기준 | 무엇을 배웠는가 | 얼마나 잘 작동하는가 |

그래서 좋은 프로토타입은 "많이 만든 것"이 아니라
**핵심 질문 하나를 분명히 겨냥한 것**입니다.

---

## 3. 큰 흐름

```text
상황 읽기
  ↓
다음 상태 정하기
  ↓
첫 행동 후보 잡기
  ↓
가장 작은 프로토타입 고르기
  ↓
증거 보기
  ↓
설계 또는 다음 실험으로 이동
```

```mermaid
flowchart TD
  a1["상황 읽기"] --> a2["다음 상태"]
  a2 --> a3["첫 행동 후보"]
  a3 --> a4["프로토타이핑"]
  a4 --> a5["증거 보기"]
  a5 --> a6["설계 또는 다음 실험"]
```

이 흐름을 제품 개발 말로 바꾸면 이렇게 볼 수 있습니다.

| 단계 | 핵심 질문 | LLM이 거드는 일 |
| --- | --- | --- |
| 상황 읽기 | 지금 무슨 일이 벌어지고 있나? | 막연한 상황 설명을 한 문장으로 줄이기 |
| 다음 상태 | 바로 다음에 무엇이 성립해야 하나? | 상태 가설 정리하기 |
| 첫 행동 | 무엇을 먼저 해볼 것인가? | 실험 후보 몇 가지 제안하기 |
| 프로토타이핑 | 무엇으로 가장 작게 시험할 것인가? | 화면, 폼, 문구, 흐름 초안 만들기 |
| 증거 보기 | 무엇을 보면 배웠다고 말할 수 있나? | 관찰 항목과 기록 포맷 정리하기 |
| 설계/반복 | 이제 무엇을 유지, 수정, 확장할 것인가? | 다음 액션과 설계 메모 정리하기 |

중요한 순서는 이것입니다.

> **먼저 배운다. 그다음 설계한다.**

완료 기준 없이 설계부터 들어가면,
아직 확인되지 않은 아이디어에 필요한 것보다 큰 노력을 쓰게 됩니다.

### 완료 기준이 흐릴 때 생기는 일

첫째, **아직 확인되지 않은 기능에 시간을 너무 많이 씁니다.**

둘째, **문제보다 해결책 설명이 먼저 커집니다.**

셋째, **만든 것은 남지만 배운 점이 흐려집니다.**

수업에서는 특히 이 차이가 큽니다.
만든 화면은 보여주기 쉽지만,
배운 점이 정리되지 않으면 다음 단계의 설계 근거가 약해집니다.

그래서 계속 같은 질문을 붙잡아야 합니다.

> **지금 우리는 무엇을 만들고 있는가가 아니라, 무엇이 새로 드러났는가?**

---

## 4. 어떤 작은 실험을 고를까

도시 문제나 SDGs 아이디어처럼 큰 주제도,
프로토타이핑에서는 **작은 학습 질문**으로 줄여야 합니다.

| 큰 아이디어 | 먼저 볼 질문 |
| --- | --- |
| 주차 공유 앱 | 사람들이 실제로 "빈 주차공간 알림 신청" 버튼을 누를까? |
| 동네 데이터 리포트 | 샘플 리포트를 읽고 다음 리포트를 요청할까? |
| 폐기물 수거 매칭 | 자동화 없이 폼과 단톡방만 있어도 사람들이 이용할까? |
| 에너지 절약 서비스 | 사용자가 생활 습관을 입력하고 미션을 받아보려 할까? |
| 교통약자 이동 안내 | 사용자가 이 안내를 실제로 유용하다고 느낄까? |

방식 이름이 많아 보여도, 출발점은 항상 같습니다.

> **지금 무엇을 배우고 싶은가?**

### 1) Fake Door: 가짜 문

아직 기능이나 서비스가 없지만, 마치 있는 것처럼 버튼이나 신청 페이지를 둡니다.

확인할 수 있는 것:

- 사람들이 관심을 보이는가?
- 어떤 문구에 더 반응하는가?
- 어떤 문제 설명이 더 설득력 있는가?

### 2) Concierge: 사람이 직접 해주는 방식

자동화를 만들기 전에, 사람이 직접 서비스를 제공합니다.

확인할 수 있는 것:

- 결과물 자체가 유용한가?
- 어떤 부분을 가장 좋아하거나 불편해하는가?
- 나중에 자동화할 만한 반복 작업이 있는가?

### 3) Wizard of Oz: 겉은 자동, 뒤는 수동

겉으로는 자동화된 서비스처럼 보이지만, 뒤에서는 사람이 일부를 처리합니다.

확인할 수 있는 것:

- 사용자가 이런 흐름을 편하게 느끼는가?
- 입력과 출력의 구조가 자연스러운가?
- 나중에 자동화해야 할 핵심 단계가 무엇인가?

### 4) Manual-first Report: 손으로 만든 첫 리포트

도시 데이터 서비스에 특히 잘 맞습니다.
처음부터 대시보드를 만들 필요는 없습니다.
엑셀, 공공데이터, 검색 자료, AI 요약을 조합해서 **샘플 리포트 1개**를 먼저 만들 수 있습니다.

확인할 수 있는 것:

- 사람들이 리포트를 읽는가?
- 다음 리포트를 요청하는가?
- 어떤 정보가 실제 의사결정에 도움이 되는가?

### 5) Paper / Role-play: 종이 또는 역할극

서비스 화면을 종이에 그리거나,
팀원들이 사용자와 시스템 역할을 나눠 연기합니다.

확인할 수 있는 것:

- 서비스 흐름이 자연스러운가?
- 사용자가 어디서 막히는가?
- 어떤 입력과 출력이 필요한가?

### 6) Tiny Functional Prototype: 아주 작은 작동형 도구

작게라도 실제로 작동하는 버전을 만듭니다.

예:

- 단일 HTML 페이지
- Streamlit 미니 앱
- 간단한 CLI 도구
- 입력값에 따라 결과가 달라지는 계산기

확인할 수 있는 것:

- 사용자가 스스로 입력하고 결과를 이해하는가?
- 어떤 기능이 꼭 필요하고 어떤 기능은 나중으로 미뤄도 되는가?
- 실제 구현으로 넘어갈 때 기술 구조를 어떻게 잡아야 하는가?

### 어떤 질문이면 어떤 방식을 먼저 쓰나?

| 지금 알고 싶은 것 | 먼저 시도할 방식 |
| --- | --- |
| 사람들이 관심을 보이는가 | Fake Door |
| 결과물 자체가 유용한가 | Concierge, Manual-first Report |
| 사용 흐름이 자연스러운가 | Wizard of Oz, Paper / Role-play |
| 실제 작동형 도구가 필요한가 | Tiny Functional Prototype |

또 하나 기억할 점은,
이 방식들은 서로 경쟁하는 방식이 아니라 **이어지는 방식**이라는 것입니다.

1. Fake Door로 관심을 본다.
2. Concierge로 결과물 가치를 본다.
3. Wizard of Oz로 사용 흐름을 본다.
4. Tiny Functional Prototype으로 구현 방향을 본다.

즉, 프로토타이핑은 "한 번 선택하고 끝"이 아니라
**질문이 달라질 때마다 실험 방식도 바뀌는 연속 과정**입니다.

---

## 5. LLM이 도움이 되는 구간

LLM은 프로토타이핑에서 특히 강합니다.
왜냐하면 보이지 않던 판단을 문장, 화면, 질문으로 드러내는 속도를 높여주기 때문입니다.

도울 수 있는 일:

- 상황 설명을 한 문장으로 줄이기
- 다음 상태 가설을 정리하기
- 프로토타입 방식 몇 가지 제안하기
- 입력 폼, 랜딩페이지, 결과 화면 초안 만들기
- 인터뷰 질문이나 관찰 포인트 만들기
- 실험 후 배운 점을 정리하기
- 다음 설계 문서 초안 만들기

하지만 LLM이 대신할 수 없는 것도 분명합니다.

- 실제 사용자의 반응
- 현장의 맥락 신호
- 어디서 머뭇거리는지 같은 행동의 질감
- 다시 쓰는지, 포기하는지 같은 현실 증거

즉, LLM은 판단을 **드러내는 속도**를 높일 수는 있지만,
판단의 **현실 검증**까지 대신해주지는 못합니다.

### LLM에게 이렇게 요청하면 좋습니다

LLM은 막연한 요청보다,
장면과 질문이 분명한 요청에서 더 잘 작동합니다.

```text
지금 상황은 이렇다:
[상황 한 문장]

다음으로 성립해야 할 상태는 이렇다:
[다음 상태 한 문장]

우리가 지금 확인하고 싶은 것은:
[관심 신호 / 흐름 / 작동 구조 중 하나]

이걸 가장 작게 시험할 수 있는 프로토타입 3가지를 제안해줘.
각 제안마다
1) 무엇을 배울 수 있는지
2) 무엇을 증거로 볼지
3) 너무 크게 만들지 않으려면 어디까지 줄여야 하는지
를 함께 써줘.
```

### LLM 답만으로는 닫기 어려운 질문

반대로 이런 질문은 LLM이 답해도 바로 결정하기에는 근거가 부족합니다.

- "이 아이디어가 성공할까요?"
- "사용자들이 좋아할까요?"
- "이 서비스가 시장성이 있을까요?"

이 질문들은 너무 큽니다.
LLM은 가능한 설명을 줄 수는 있지만,
다음 행동을 결정할 만큼 강한 증거를 주지는 못합니다.

그래서 큰 질문은 더 작은 질문으로 내려야 합니다.

- "이 문구에서 버튼을 누를까?"
- "이 결과 화면을 이해할까?"
- "이 리포트를 다시 받아보고 싶어 할까?"

### 프로젝트 폴더가 중요한 이유

LLM과 오래 작업할수록 기록의 가치가 커집니다.
처음에는 대화창 안에서 다 기억할 수 있을 것처럼 보여도,
실제로는 프로젝트가 조금만 길어져도 맥락이 섞이기 시작합니다.

그래서 폴더 안에 최소한 아래는 남겨둬야 합니다.

- 어떤 문제를 다루는지
- 누구를 위한 아이디어인지
- 무엇을 먼저 배우려는지
- 어떤 프로토타입을 만들었는지
- 어떤 반응 데이터를 보려는지
- 무엇을 배웠는지
- 다음 설계로 넘어간다면 무엇을 만들지

쉽게 말하면:

> **프로젝트 폴더는 LLM과 사람이 같이 읽는 작업 기록입니다.**

---

## 6. 무엇을 증거로 볼까

프로토타이핑은 "만들기"보다 "배우기"에 가깝기 때문에,
무엇을 증거로 볼지도 미리 정하는 편이 좋습니다.

| 프로토타입 | 보고 싶은 증거 |
| --- | --- |
| Fake Door 페이지 | 클릭 수, 신청 전환율, 어떤 문구가 먹히는지 |
| 샘플 리포트 | 끝까지 읽었는지, 다음 리포트를 요청했는지 |
| Wizard of Oz | 입력 과정에서 어디서 막히는지, 결과를 신뢰하는지 |
| Tiny Functional Prototype | 사용자가 스스로 끝까지 써보는지, 어떤 기능이 필요 없는지 |

증거를 미리 정해두면,
프로토타입이 예뻤는지보다 **무엇을 배웠는지**로 대화를 할 수 있습니다.

### 약한 증거와 강한 증거를 구분하기

| 상대적으로 약한 증거 | 상대적으로 강한 증거 |
| --- | --- |
| 재미있어 보인다는 말 | 실제 클릭 |
| 해보면 좋겠다는 말 | 이메일 남기기 |
| 아이디어가 좋아 보인다는 말 | 폼 제출 |
| 발표 자리에서의 호의적 반응 | 다시 사용해보기 |
| 팀 내부 추정 | 실제 사용자 인터뷰에서 나온 구체적 불편 |

약한 증거가 쓸모없다는 뜻은 아닙니다.
약한 증거는 **다음 실험을 설계하는 단서**가 될 수 있습니다.
다만 그것만으로 "검증됐다"고 말하면 안 됩니다.

### 짧은 회고를 남기는 법

실험이 끝나면 길게 보고서를 쓰기 전에
아래 세 줄만 먼저 적어도 좋습니다.

```text
우리가 보고 싶었던 것:
실제로 본 것:
그래서 다음에 바꿀 것:
```

이 짧은 기록이 쌓이면
나중에 발표 자료, 설계 문서, 구현 계획이 훨씬 쉬워집니다.

---

## 7. 키트의 기본 구성

키트를 풀면 대략 이런 구조를 보게 됩니다.

```text
my-urban-project/
├── GEMINI.md
├── project/
│   ├── 01-idea.md
│   ├── 02-service-loop.md
│   ├── 03-sdg-map.md
│   ├── 04-stakeholders.md
│   ├── 05-prototype-spec.md
│   ├── 06-build-plan.md
│   ├── 07-demo-scenario.md
│   ├── 08-reflection.md
│   └── pitch.md
├── evidence/
│   ├── assumptions.md
│   ├── sources.md
│   └── data-notes.md
├── prototype/
│   └── README.md
└── .gemini/
    ├── commands/urban/
    ├── agents/
    └── skills/
```

처음 보면 파일이 많아 보일 수 있습니다.
하지만 학생이 직접 전부 외울 필요는 없습니다.

핵심은 세 폴더입니다.

| 폴더 | 의미 |
| --- | --- |
| `project/` | 아이디어, 서비스 흐름, 설계 메모 |
| `evidence/` | 가정, 근거, 반응 데이터, 배운 점 |
| `prototype/` | 실제로 만들어본 작은 실험 도구 |

여기서 자주 놓치는 점은,
`prototype/`만 채우고 `evidence/`를 비워두는 것입니다.

그러면 만든 것은 남지만 배운 것은 남지 않습니다.

> **실험 도구 하나보다, 실험에서 배운 점 한 줄이 더 중요할 수 있습니다.**

---

## 8. 가장 추천하는 사용 순서

처음부터 모든 명령을 쓸 필요는 없습니다.
아래 순서만 따라가도 충분합니다.

```text
/urban:scope
→ /urban:service-loop
→ /urban:prototype
→ /urban:demo-review
→ /urban:pitch
```

```mermaid
flowchart LR
  c1["scope"] --> c2["service-loop"]
  c2 --> c3["prototype"]
  c3 --> c4["demo-review"]
  c4 --> c5["pitch"]
  c3 -.배운 점 반영.- c2
  c4 -.수정.- c3
```

### 수업 시간 기준 추천 운영 흐름

1. `scope`로 문제와 대상을 한 문장으로 줄입니다.
2. `service-loop`로 사용자가 무엇을 입력하고 무엇을 받는지 정리합니다.
3. `prototype`으로 가장 작은 실험물을 만듭니다.
4. `demo-review`로 무엇을 배웠는지 정리합니다.
5. `pitch`로 발표나 정리 문서에 연결합니다.

### 혼자 할 때의 최소 루프

혼자 작업할 때는 더 줄여도 됩니다.

```text
상황 한 문장
→ 다음 상태 한 문장
→ 가장 작은 프로토타입
→ 짧은 회고 3줄
```

여기서 가장 중요한 것은 속도보다 **닫힌 루프**입니다.
작게 만들고, 보고, 적고, 다음 행동으로 연결해야 합니다.

---

## 9. 사용 예시: 분리배출 도우미

가설:

```text
자취생은 분리배출 방법을 헷갈리는 상황 때문에,
품목을 입력하면 버리는 방법을 알려주는 간단한 도구를 필요로 할 것이다.
```

이 가설에서 바로 완성 앱으로 가는 대신,
질문을 순서대로 쪼갭니다.

### 1단계: 관심 신호 보기

Fake Door 페이지를 만듭니다.

- 제목: "분리배출 도우미 써보기"
- 버튼: "혼합쓰레기인지 바로 확인하기"
- 확인할 것: 버튼을 누르는가, 어떤 제목이 더 먹히는가

### 2단계: 결과물 가치 보기

Concierge 또는 Manual-first Report 방식으로
몇 명에게 직접 답변을 보내봅니다.

- 확인할 것: 답변이 실제로 도움이 되는가
- 추가 질문: 한 번 쓰고 끝나는가, 다시 물어보는가

### 3단계: 사용 흐름 보기

Wizard of Oz나 종이 화면으로
입력 -> 결과 확인 흐름을 봅니다.

- 품목을 어떻게 표현하는가
- 사용자가 어디서 막히는가
- 결과 문장을 이해하는가

### 4단계: 작동형 도구로 줄이기

Tiny Functional Prototype을 만듭니다.

- 단일 HTML 페이지
- 품목 입력창
- 분류 결과와 주의사항 출력

### 이 사례에서 배워야 하는 것

이 사례의 핵심은 서비스 전체를 만드는 일이 아니라,
**한 걸음씩 무엇을 배우는가를 분리하는 것**입니다.

관심 신호, 결과 가치, 사용 흐름, 작동 구조는
각각 다른 실험으로 보는 편이 더 정확합니다.

---

## 10. 바로 쓰는 기본 루프

NDM 프로토타이핑을 처음 설명할 때는 아래 다섯 줄이면 충분합니다.

```text
1. 지금 무슨 상황인가?
2. 다음으로 어떤 상태가 성립해야 하나?
3. 그 상태를 만들 첫 행동은 무엇인가?
4. 그 행동을 가장 작게 시험할 프로토타입은 무엇인가?
5. 성립 여부를 무엇으로 판단할 것인가?
```

이 다섯 줄을 표로 바꾸면 더 쓰기 쉽습니다.

| 단계 | 질문 | 예시 답 |
| --- | --- | --- |
| 상황 | 지금 무슨 상황인가? | 사용자가 자신의 문제를 말하기 어려워한다 |
| 다음 상태 | 바로 다음에 무엇이 성립해야 하나? | 사용자가 문제 유형 하나를 고를 수 있어야 한다 |
| 첫 행동 | 무엇을 해볼 것인가? | 선택형 첫 화면을 보여준다 |
| 프로토타입 | 무엇으로 시험할 것인가? | 단일 HTML 페이지 또는 종이 화면 |
| 증거 | 무엇을 볼 것인가? | 중간에 포기하는지, 끝까지 고르는지 |

### 한 페이지 워크시트

지금 나는 이런 상황을 보고 있다:

`__________________________________________________`

바로 다음에 이런 상태가 성립해야 한다:

`__________________________________________________`

그래서 나는 먼저 이것을 해본다:

`__________________________________________________`

이걸 가장 작게 시험하는 방법은 이것이다:

`__________________________________________________`

성립 여부를 볼 신호는 이것이다:

`__________________________________________________`

---

## 11. 강의용 설명 문안

### 짧은 버전

NDM에서 프로토타이핑은 크게 완성품을 향해 가는 작업이 아니라,
`지금 상황을 어떻게 읽고 있는지`, `다음에 어떤 상태를 만들어야 하는지`,
`그 한 걸음이 맞는지`를 작은 실험으로 확인하는 과정이라고 볼 수 있다.

### 조금 더 정확한 버전

NDM 연구는 전문가가 여러 대안을 길게 비교하기보다,
먼저 상황을 인식하고, 그 상황에 맞는 첫 행동 후보를 떠올린 다음,
mental simulation으로 그 행동이 성립할지 빠르게 점검한다고 본다.
이때 프로토타입은 그 머릿속 판단을 바깥으로 드러내어
더 빠르게 확인하게 해주는 도구다.

### 한 문단 버전

NDM에서 프로토타이핑은 멋진 시제품을 만드는 일이 아니라,
지금 상황을 어떻게 읽고 있는지와 다음 한 걸음이 무엇인지를 바깥으로 꺼내 검증하는 일이다.
전문가 판단은 대개 여러 대안을 길게 비교하는 방식보다,
상황을 인식하고, 첫 행동 후보를 떠올리고,
mental simulation으로 그 행동이 먹힐지 짧게 점검하는 방식으로 작동한다.
프로토타입은 이 머릿속 판단을 화면, 흐름, 질문지, 실험물로 바깥에 드러내 더 선명하게 보이게 만든다.
그래서 좋은 프로토타이핑은 "무엇을 만들까?"보다 "지금 이 한 걸음이 맞는가?"를 확인하는 데 초점을 둔다.

---

## 12. 해석 범위와 불확실

- `NDM의 프로토타이핑` 자체는 대표적인 NDM 정전 용어라고 보기는 어렵습니다.
- 이 문서의 설명은 `NDM의 판단 구조`와 `디자인 프로토타이핑이 생각을 바깥으로 드러내는 기능`을 연결한 해석입니다.
- 따라서 강의에서는 `NDM 자체의 원문 개념`과 `우리가 수업에서 쓰는 해석적 확장`을 구분해 말하는 편이 안전합니다.
- 프로토타이핑은 mental simulation을 대체한다기보다, **그 판단을 바깥에서 보강하고 점검하는 장치**로 보는 편이 더 정확합니다.
- 프로토타이핑은 한 번 하고 끝나는 일이 아니라, **만들고 보고 고치고 다시 시험하는 반복 과정**입니다. LLM은 그 반복을 빠르게 도와줄 수는 있어도, **현실의 행동 증거는 결국 실제 사용자 반응과 관찰로 확인해야 합니다**.

---

## 13. 통합 원천과 참고 자료

### 연구 참고 문헌

[1] [Designing for decision making](https://consensus.app/papers/details/8d77a2f824015c2eaff549f500ca6ee7/?utm_source=unknown) (D. Jonassen, 2012, Educational Technology Research and Development, 160 citations)

[2] [The role of mental simulation in problem solving and decision making](https://consensus.app/papers/details/764a9210f1135c4daf1f01973e8eaa11/?utm_source=unknown) (G. J. Klein et al., 2018, Unknown Journal, 66 citations)

[3] [The role and impact of mental simulation in design](https://consensus.app/papers/details/d42307de922b5ced8d67413875f661eb/?utm_source=unknown) (Bo T. Christensen et al., 2009, Applied Cognitive Psychology, 116 citations)

[5] [Taking stock of naturalistic decision making](https://consensus.app/papers/details/15ec5d3db13a5f458b26833e27a11da2/?utm_source=unknown) (R. Lipshitz et al., 2001, Journal of Behavioral Decision Making, 781 citations)

[8] [Naturalistic Decision Making](https://consensus.app/papers/details/fdc9ca36cf89557bac7043d44d334e06/?utm_source=unknown) (G. Klein, 2008, Human Factors: The Journal of Human Factors and Ergonomic Society, 2119 citations)

[16] [Naturalistic Decision-Making in Emergency Medical Services](https://consensus.app/papers/details/cb5e1aa3b36a5784915bbb319f1dec8a/?utm_source=unknown) (Michael A. Rosen et al., 2017, Unknown Journal, 1 citation)

[17] [On the realization of the recognition-primed decision model for artificial agents](https://consensus.app/papers/details/a10c54de799959898d9d7edbc5935dc2/?utm_source=unknown) (S. Danial et al., 2019, Human-centric Computing and Information Sciences, 9 citations)

[18] [Naturalistic decision making](https://consensus.app/papers/details/919df823ac4f5696b18bfb713fc9b3f3/?utm_source=unknown) (GoreJulie et al., 2018, Cognition, Technology & Work, 42 citations)