AI와 함께 묻고,
함께 설계합니다

여기서 문제는 “해줘”라는 어미 자체가 아닙니다. 질문·선택·검토 없이 결과만 받아들이는 관계에 머무르는지가 중요합니다. 공동창작에서도 작업을 요청할 수 있고, AI의 제안을 거절하거나 바꾸거나 채택할 수 있습니다. 모든 구현 방법을 미리 정해 주어야 주도권이 생기는 것도 아닙니다.

핵심 질문

AI와 무엇을 함께 판단할까요?

이전 학습

7주차 게임 · 8주차 기획서

오늘의 연결

Unity CLI · Pipeline · MCP

오늘의 스킬

Grilling · Spec · Ticket

학습 방식

관점 → 시연 → 문서 → 확인

도착점

연결 증거와 첫 작업 하나

1. 1 · 같은 프로젝트 보기

   Unity CLI와 Pipeline을 준비하고 MCP로 현재 Scene과 Console을 읽습니다.

2. 2 · 일하는 방법 공유하기

   Unity Skill과 Matt Pocock 스킬을 설치하고 문서·작업의 저장 위치를 정합니다.

3. 3 · 질문으로 기획 구체화

   AI가 가정과 빈틈을 질문하고 제안하면, 내 의도와 이유를 설명하며 답합니다.

4. 4 · Spec으로 합의 남기기

   누가 무엇을 할 때 어떤 결과가 나와야 하는지, 어디까지 만들지 기록합니다.

5. 5 · Ticket으로 나누기

   실행해 확인할 수 있는 행동으로 나누고, 선행 작업이 없는 첫 Ticket을 고릅니다.

1교시는 공통 설명과 교수자 시연입니다. 시연에서는 익숙한 7주차 게임에 열쇠와 문을 추가하는 상황을 사용합니다. 개인 프로젝트에서는 8주차에 작성한 자신의 기획서를 사용합니다. 설치가 이미 되어 있다면 성공 확인으로 넘어가고, 처음 설치하는 학생은 같은 순서로 따라갑니다.

Unity CLI는 터미널에서 실행하는 Unity 도구입니다. Pipeline은 실행 중인 Unity Editor가 외부 명령을 받아 처리하도록 프로젝트 안에 설치하는 패키지입니다. MCP는 AI 클라이언트가 도구의 기능을 발견하고 호출하는 연결 규약입니다.

Skill은 어떤 상황에서 어떤 절차와 기준으로 작업할지 AI에게 알려 주는 지침입니다. Skill을 설치했다고 Editor와 연결된 것은 아닙니다. 반대로 도구가 연결되어도 자신의 기획과 완료 기준을 설명하지 않으면 AI가 원하는 경험을 저절로 알 수는 없습니다.

이번 시연은 Unity 공식 CLI의 MCP 경로를 사용합니다. 예전 Unity Assistant 패키지 안의 MCP 서버와 구분합니다. 별도의 GitHub MCP 패키지를 이미 사용한다면 그 패키지의 설치법과 공식 CLI 명령을 섞지 말고, 현재 사용하는 연결을 먼저 확인합니다.

Unity에서 사용할 프로젝트를 열고 Play를 끈 뒤 Scene을 저장합니다. 교수자 시연은 7주차에 연결한 게임을 기준으로 하고, 개인 적용은 자신의 프로젝트를 기준으로 합니다. 프로젝트 경로와 활성 Scene 이름을 눈으로 확인합니다.

AI 클라이언트에서도 같은 프로젝트 폴더를 엽니다. 터미널의 작업 폴더는 Assets, Packages, ProjectSettings가 함께 들어 있는 프로젝트 루트입니다. Assets 내부나 Unity 설치 폴더에서 명령을 실행하지 않도록 현재 위치를 확인합니다.

pwd
ls

두 명령은 현재 경로와 항목을 보여 줍니다. Windows PowerShell에서도 사용할 수 있습니다. Unity Editor는 Pipeline을 사용할 수 있는 Unity 6.0 이상을 기준으로 합니다. 프로젝트에 이미 적용한 Editor 버전은 수업 도중 임의로 바꾸지 않습니다.

아래 설치와 AI 입력 예시는 Codex 기준입니다. 다른 클라이언트를 사용하면 MCP와 Unity Skill의 지원 목록에서 자신의 이름을 선택합니다. 셸 명령은 터미널에, $grill-with-docs처럼 시작하는 스킬 요청은 AI 대화창에 입력합니다.

unity --version

버전이 출력되면 CLI를 실행할 수 있습니다. command not found 또는 명령을 인식할 수 없다는 메시지가 나오면 아래에서 자신의 운영체제를 펼칩니다. Unity Hub를 통해 이미 설치된 경우도 있으므로 먼저 확인하는 순서를 지킵니다.

curl -fsSL https://unity.com/install.sh | bash

irm https://unity.com/install.ps1 | iex

설치 방법은 Unity CLI 공식 설치 안내와 Unity 공식 Skill에서 확인할 수 있습니다. 아래 연결 명령이 지원되지 않으면 unity --version과 해당 명령의 --help를 확인합니다. CLI 버전은 Editor 버전과 별개입니다.

프로젝트 루트의 터미널에서 로그인한 뒤 Pipeline을 설치합니다. 로그인은 브라우저에서 자신의 Unity 계정으로 진행합니다. CLI 설치, Unity 계정 로그인, 프로젝트 패키지 설치는 각각 다른 상태이므로 순서대로 확인합니다.

unity auth login
unity pipeline install --project-path .

.은 현재 프로젝트 폴더입니다. 설치 후 Unity Editor로 돌아와 패키지 해석과 컴파일이 끝날 때까지 기다립니다. 그다음 터미널에서 아래 상태를 읽습니다. 컴파일 중인 상태를 곧바로 연결 실패라고 판단하지 않습니다.

unity pipeline list
unity status --project-path .
unity command --project-path .

마지막 unity command는 뒤에 작업 이름을 쓰지 않았으므로 사용 가능한 명령을 조회합니다. 이 단계에서는 Scene에 오브젝트를 추가하지 않습니다. 여러 Editor가 열려 있다면 경로를 함께 확인합니다. 설치와 확인의 기준은 Unity Pipeline 공식 안내입니다.

unity mcp configure --list
unity mcp configure codex --project-path .

첫 줄에서 지원 클라이언트 목록을 확인하고, 둘째 줄은 Codex의 MCP 설정에 현재 프로젝트를 지정합니다. 기존 Unity 항목을 갱신하는 안내가 나오면 대상 경로를 확인한 뒤 진행합니다. 등록이 끝나면 사용하는 AI 클라이언트가 연결 설정을 다시 읽도록 새로고침하거나 재시작합니다.

도구 목록에 Unity가 보이면 아래 요청으로 실제 읽기를 확인합니다. 단순히 코드 파일만 읽은 답과 MCP 도구가 실행 중인 Editor에서 읽은 답을 구분합니다. 연결이 안 된 부분을 그럴듯한 Scene 이름으로 채우지 않도록 요청에 포함합니다.

Unity MCP 도구를 사용해 현재 프로젝트 경로와 활성 Scene을 읽어줘.
Hierarchy의 플레이어, 수집 상태, 목표 판정, UI 담당 오브젝트를 찾아 관계를 설명해줘.
Console 오류도 확인하고 실제 도구에서 확인한 사실만 적어줘.
읽지 못한 정보는 확인하지 못했다고 표시해줘. 지금은 파일이나 Scene을 변경하지 마.

Unity의 unity-cli Skill은 상태 조회, 프로젝트 지정, 명령 발견, 실행 결과 확인 등의 작업 방법을 안내합니다. 이 수업에서는 현재 프로젝트에 설치하는 방법으로 통일합니다. 이미 공식 Unity 플러그인으로 같은 Skill을 사용하고 있다면 중복 설치 없이 목록과 내용을 확인합니다.

unity skill install --list
unity skill install codex --local

--local은 현재 프로젝트 범위에 설치한다는 뜻입니다. 확인한 CLI의 Codex 경로는 .agents/skills/unity-cli/입니다. 실제 출력에 안내된 위치와 AI의 스킬 목록을 함께 봅니다. unity skill은 단수형이며, 설치 명령이 없으면 현재 버전의 도움말을 확인합니다.

$unity-cli
이 프로젝트에서 사용할 Unity CLI의 역할과 연결 확인 순서를 설명해줘.
프로젝트를 지정하는 방법과 현재 Editor가 제공하는 명령을 찾는 방법을 알려줘.
현재 설치된 Skill을 읽고 설명하되 Scene은 변경하지 마.

새로 설치한 Skill이 목록에 보이지 않으면 같은 프로젝트에서 새 AI 세션을 열고 다시 확인합니다. 파일이 생겼는지와 AI가 해당 Skill을 인식하는지를 나누어 점검합니다. Unity 공식 스킬 저장소에는 여러 Unity 작업의 지침과 플러그인 설치 경로도 안내되어 있습니다.

Matt Pocock의 스킬 묶음에는 기획을 검토하는 질문 방식과 Spec·Ticket을 만드는 지침이 있습니다. 이 수업에서는 파일을 프로젝트에 복사하는 설치 방법을 사용합니다. 이미 같은 스킬을 플러그인으로 설치했다면 기존 설치를 확인하고 중복해서 추가하지 않습니다.

먼저 node --version과 npm --version으로 Node.js와 npm이 준비되어 있는지 확인합니다. 명령을 찾지 못하면 Node.js 공식 다운로드에서 LTS를 설치하고 터미널을 새로 엽니다. 이 도구는 Unity 패키지가 아니라 스킬 설치 명령을 실행하는 데 사용합니다.

npx skills@latest add mattpocock/skills --skill "*" --agent codex --copy --yes

모든 스킬을 오늘 한꺼번에 사용한다는 뜻은 아닙니다. grill-with-docs가 내부의 질문·도메인 지침을 사용하는 것처럼 연결된 스킬이 있어서 묶음을 설치하고 필요한 흐름만 사용합니다. 이번 교시에서는 설정, grilling, spec, ticket에 집중합니다.

npx skills@latest list --agent codex

목록에서 setup-matt-pocock-skills, grill-with-docs, grilling, to-spec, to-tickets를 찾습니다. AI에서도 스킬을 선택할 수 있는지 확인합니다. 설치한 이름은 원본 저장소와 실제 목록을 기준으로 합니다.

to-spec과 to-tickets는 결과를 어디에 남길지 알아야 합니다. 수업에서는 외부 이슈 서비스를 준비하지 않아도 진행할 수 있도록 프로젝트 안의 로컬 Markdown을 사용합니다. 설정 스킬이 현재 파일을 확인하고 초안을 보여 주면 저장 위치와 기존 문서의 보존 여부를 읽고 확인합니다.

$setup-matt-pocock-skills
이 Unity 프로젝트에서는 이슈 저장소로 로컬 Markdown을 사용할게.
Spec과 Ticket은 .scratch/<기능이름>/ 아래에 남기자.
용어집은 GLOSSARY.md, 결정 기록은 docs/adr/를 사용할게.
기본 작업 상태 이름을 사용하되, 선행 Ticket이 남은 작업은 blocked로 구분하고 싶어.
기존 AGENTS.md 또는 CLAUDE.md가 있으면 그 내용을 보존해 반영안을 보여줘.
둘 다 없다면 Codex용 AGENTS.md를 사용하는 것으로 진행하자.
설정 초안을 함께 확인한 뒤 기록하자.

<기능이름>은 기능별 폴더를 만들겠다는 설명입니다. 뒤의 시연에서는 key-door를 사용합니다. 이 문구는 AI에게 보낼 요청이며 셸 명령이 아닙니다. 설정 스킬이 되묻는 항목에는 수업의 저장 방식을 확인해 답합니다.

Grilling은 계획에 남은 가정과 결정을 질문으로 드러내는 방식입니다. “문을 만들어 달라”는 말에는 언제 열리는지, 어떻게 알려 주는지, 다시 접근하면 어떻게 되는지, 재시작 때 무엇을 되돌리는지가 생략되어 있습니다. AI가 이 질문을 제시하고 추천안을 설명하면, 학생은 자신의 경험 의도에 맞춰 답합니다.

Matt Pocock 묶음에서 grilling은 질문의 기본 지침입니다. grill-me는 일반적인 계획 검토의 진입점이고, 이번처럼 프로젝트의 용어와 결정도 기록하려면 grill-with-docs를 사용합니다. 세 개를 차례로 실행해야 하는 것이 아닙니다. 이번에는 grill-with-docs 하나로 질문과 기록을 시작합니다.

$grill-with-docs
내 2D 게임에 “필요한 물건을 찾아 잠긴 길로 돌아오는 경험”을 만들고 싶어.
지금은 열쇠와 문을 생각하고 있지만, 더 적합한 방식이 있다면 제안해줘.
현재 프로젝트와 8주차 기획서를 먼저 읽고 확인한 사실을 설명해줘.
플레이어가 느낄 경험, 행동의 조건, 반복 접근, 재시작에서 빠진 결정을 질문해줘.
현재 답할 수 있는 질문을 한 묶음으로 번호를 붙여 제시하고,
각 질문에는 추천안과 이유를 함께 적어줘.
내가 답하지 않은 결정을 확정하지 말고, 합의한 용어와 이유를 기록하자.
지금은 기능을 구현하지 않고 기획을 함께 구체화할게.

처음부터 “열쇠를 소모하지 말고 자동으로 열어”까지 전부 정해 주기보다, 왜 잠긴 길이 필요한지 설명하고 대안을 듣습니다. 반대로 AI가 추천했다고 그대로 채택하지도 않습니다. 이번 게임에서 탐색에 집중할지, 문 앞의 선택과 조작에 집중할지 생각하며 답합니다.

AI가 파일을 읽으면 알 수 있는 사실은 프로젝트에서 확인하게 합니다. 학생은 의도·선호·범위처럼 선택이 필요한 항목에 답합니다. 답하지 않은 결정을 AI가 사실처럼 채우면 미정으로 돌려놓습니다. 앞선 답에 따라 달라지는 질문은 다음 라운드에서 다룹니다.

처음에는 상호작용 키를 누르게 하려다가, AI의 질문을 듣고 이번 단계에서는 자동 열림이 목적에 더 맞는다고 판단할 수 있습니다. 이것은 주도권을 잃은 일이 아닙니다. 제안의 이유를 검토하고 자신의 기준으로 선택한 과정입니다. 이 이유를 남겨야 다음 작업에서도 같은 판단을 이어 갈 수 있습니다.

합의가 끝나면 확정한 것, 아직 확인할 것, 이번에 하지 않을 것을 나누어 읽습니다. 현재 프로젝트에 어떤 관리자가 있는지는 조사할 사실이고, 열쇠를 소모할지는 설계 결정입니다. 두 가지를 섞으면 존재하지 않는 구조를 전제로 Spec을 작성할 수 있습니다.

이번 기능은 열쇠 하나와 문 하나로 한정할게.
별도 키 입력 없이 접근하면 열리고, 열쇠는 소모하지 않는 방식으로 하자.
탐색한 뒤 돌아오는 경험에 집중하려는 선택이야.
한 번 열린 문은 같은 판 동안 유지하고 재시작하면 초기 상태로 돌아가야 해.
현재 프로젝트에서 상태와 재시작을 어디에 연결할지는 실제 코드를 읽어 확인해줘.
합의한 내용, 확인이 필요한 사실, 이번 범위 밖의 내용을 구분해서 보여줘.

Spec은 합의한 기능의 행동·범위·확인 기준을 정리한 기능 설계서입니다. 대화 중에 정한 의도와 선택이 다음 AI 세션이나 다음 작업으로 넘어갈 때 흐려지지 않도록 합니다. “문 기능 완성”처럼 해석이 넓은 말 대신 “열쇠가 없는 상태에서 접근하면 안내가 보이고 통과가 막힌다”처럼 관찰할 수 있는 결과로 씁니다.

to-spec은 확인한 대화와 프로젝트의 사실을 문서로 정리합니다. 새로운 기능을 마음대로 보충하는 단계로 사용하지 않습니다. 검사할 접점이나 실행 기준을 함께 검토할 수는 있지만, 핵심 기획이 아직 흐릿하다면 질문 단계에서 먼저 합의합니다.

$to-spec
방금 합의한 열쇠와 문 기능을 Spec으로 정리하자.
로컬 Markdown 저장 방식을 사용하고 .scratch/key-door/spec.md에 저장해줘.
플레이어의 문제, 만들 경험, 사용자 행동, 합의한 처리,
Unity에서 확인할 기준, 이번 범위 밖의 내용을 포함해줘.
프로젝트에서 확인한 사실과 아직 확인하지 못한 가정을 구분해줘.
확인 기준의 접점이 필요하면 기존 Play 동작과 재시작 흐름을 기준으로 검토하자.
새 기능이나 미합의 결정을 추가하지 말고, 아직 구현은 시작하지 마.

# 열쇠와 문 · 기능 설계서 (Spec)

> 9주차 시연용 완성 형태 예시. 구현 완료 보고가 아니다.
> 이 예시의 구조를 참고하되 개인 프로젝트의 합의와 조사 결과로 작성한다.

## Problem Statement · 플레이어가 겪는 문제

플레이어가 통과할 수 없는 문을 만났을 때 이유와 다음 행동을 알기 어렵다.
필요한 물건을 발견하고 돌아왔을 때 탐색의 결과가 문 통과로 이어져야 한다.

## Solution · 만들 경험

열쇠가 없는 동안 문은 통과를 막고 접근하면 필요한 조건을 안내한다.
열쇠를 얻은 뒤 접근하면 문이 자동으로 열리며 통과할 수 있다.
같은 판에서는 열린 상태가 유지되고 재시작하면 초기 상태로 돌아간다.

## User Stories · 플레이어의 행동과 이유

1. 플레이어로서 잠긴 문 앞에서 필요한 조건을 알아 다음 탐색 행동을 정하고 싶다.
2. 플레이어로서 열쇠 획득 여부를 화면에서 확인해 문으로 돌아갈 시점을 알고 싶다.
3. 플레이어로서 열쇠를 얻고 돌아왔을 때 문을 통과해 탐색의 결과를 경험하고 싶다.
4. 플레이어로서 열린 문에 다시 접근해도 계속 통과할 수 있어 진행을 이어가고 싶다.
5. 플레이어로서 재시작하면 처음 조건에서 같은 규칙으로 다시 플레이하고 싶다.

## Implementation Decisions · 합의한 처리

- 열쇠 하나와 문 하나를 다룬다. 열쇠는 문을 열 때 소모하지 않는다.
- 열쇠 보유 여부와 문 열림 여부를 구분한다.
- 문은 접근할 때 보유 상태를 확인한다. 별도 상호작용 키는 추가하지 않는다.
- 열쇠가 없을 때는 문 통과를 막고 근처에 안내를 표시한다. 멀어지면 안내를 숨긴다.
- 열쇠 획득은 월드의 열쇠 표시와 보유 표시를 함께 갱신한다.
- 열린 문은 충돌 통과와 시각적 상태가 일치해야 한다.
- 재시작은 기존 게임의 재시작 흐름에 연결한다. 별도의 중복 게임 관리자를 만들지 않는다.
- 기존 수집·목표 판정·이동을 유지한다.
- 적용할 컴포넌트와 상태 소유자는 현재 프로젝트 조사 결과로 결정한다.

## Testing Decisions · 화면에서 확인할 기준

- 열쇠 없이 접근: 안내가 보이고 통과할 수 없다. 멀어지면 안내가 사라진다.
- 열쇠 획득: 월드 열쇠가 사라지고 보유 표시가 바뀐다.
- 획득 후 접근: 문이 열리고 실제로 반대편까지 이동할 수 있다.
- 열린 문 재접근: 다시 잠기거나 획득 횟수가 증가하지 않는다.
- 재시작: 열쇠가 돌아오고 보유 상태와 문이 초기화되며 이전 안내가 남지 않는다.
- 기존 수집·목표 판정·재시작을 다시 실행하고 Console 오류를 확인한다.

## Out of Scope · 이번 기능에 포함하지 않는 것

여러 열쇠와 문 매칭, 인벤토리 창, 세이브·로드, 신규 목표 판정, 고급 문 애니메이션.

## Further Notes · 다음 대화에 남길 것

실제 프로젝트에 적용할 때는 Scene·참조·기존 재시작 방식부터 확인한다.
합의되지 않은 조건이 있으면 Spec에 사실처럼 추가하지 않고 질문으로 되돌린다.

문서를 받은 뒤 자신이 말하지 않은 조건이 들어갔는지 읽습니다. 예를 들어 “문을 열면 열쇠가 사라진다”가 들어갔다면 앞의 합의와 다릅니다. 구현이 시작되기 전에 Spec을 수정해야 뒤의 Ticket과 코드가 같은 기준을 갖습니다.

Ticket은 실제로 수행할 작업 하나입니다. “스크립트 작성”, “UI 제작”, “테스트”처럼 작업 종류만 분리하면 각각 끝났어도 플레이어 행동은 아직 동작하지 않을 수 있습니다. 이번에는 한 행동이 입력부터 화면의 결과까지 이어지는 크기로 나눕니다.

예를 들어 첫 Ticket은 “열쇠 없이 문에 접근하면 안내가 보이고 통과가 막힌다”입니다. 코드, 충돌 설정, 안내 UI가 함께 필요할 수 있습니다. 파일이 여러 개 바뀌더라도 하나의 행동을 직접 시연할 수 있으면 작업의 완료 기준이 분명합니다.

$to-tickets
.scratch/key-door/spec.md를 기준으로 작업을 나누자.
각 Ticket은 Unity에서 한 가지 행동을 끝까지 시연할 수 있는 크기로 잡아줘.
제목, 만들 행동, 완료 기준, Blocked by를 보여줘.
작업 크기와 선행 관계를 먼저 함께 검토하자.
합의한 뒤 .scratch/key-door/issues/에 Ticket 하나당 Markdown 파일 하나로 저장해줘.
앞선 Ticket이 끝나야 하는 작업은 blocked로 구분하고,
지금 시작할 수 있는 첫 Ticket 하나를 알려줘. 아직 구현하지 마.

Blocked by는 이 작업을 시작하기 전에 완료되어야 하는 작업입니다. 번호가 작아서 먼저 하는 것과 실제로 의존하는 것은 구분합니다. AI가 제안한 목록에서 작업이 너무 크거나 작은지, 선행 관계가 맞는지 검토한 뒤 저장합니다. to-tickets는 이 검토를 대화에 포함합니다.

# 01: 열쇠 없이 접근하면 안내하고 통과를 막는다

**What to build:** 플레이어가 잠긴 문에 접근하면 필요한 조건을 읽고, 문을 통과할 수 없음을 경험한다. 멀어지면 안내가 사라진다.

**Blocked by:** None (선행 작업 없음)

**Status:** ready-for-agent

- [ ] 열쇠가 없는 시작 상태에서 문 앞까지 이동할 수 있다.
- [ ] 가까이 가면 “열쇠가 필요합니다”가 보이고 문은 통과할 수 없다.
- [ ] 문에서 멀어지면 안내가 사라진다.
- [ ] 기존 이동·수집·목표 판정에 영향이 없는지 실행해 확인한다.

**시연 순서:** 새로 시작 → 문 접근 → 통과 시도 → 멀어지기.

열쇠를 획득해 문을 여는 경로는 Ticket 02에서 연결한다.

아래는 수업용으로 작성한 대화와 문서의 발췌입니다. 실제 AI가 응답하는 화면은 아닙니다. 각 단계를 눌러 “탐색에 집중한다”는 의도가 어떻게 구체적인 행동과 완료 기준이 되는지 비교합니다.

Spec과 Ticket이 정리되면 첫 작업의 행동과 확인 기준을 AI에게 함께 전달합니다. AI가 바꿀 대상과 현재 구조를 설명하면 그 계획이 합의한 경험에 맞는지 검토합니다. 이후 구현은 코드를 만드는 데서 끝나지 않고, 필요한 Component·Inspector 참조·Scene 연결까지 확인합니다.

합의한 Spec과 .scratch/key-door/issues/01-locked-door.md를 읽고 첫 작업을 진행하자.
현재 프로젝트에서 문 충돌과 안내 UI를 연결할 대상을 먼저 확인해줘.
이 Ticket의 행동이 끝까지 동작하도록 구현하고, 변경한 대상과 실행 확인 방법을 알려줘.
내가 문 접근 → 통과 시도 → 멀어지기를 직접 플레이하며 결과를 함께 확인할게.
다음 Ticket은 이 결과를 확인한 뒤 진행하자.

완료 기준에는 컴파일뿐 아니라 플레이어가 실제로 보는 행동이 들어갑니다. 문이 열리는 그림만 바뀌고 Collider가 남아 있으면 “통과”가 완료되지 않았습니다. 첫 Ticket이 목표한 안내와 차단을 실제로 확인한 뒤 다음 작업을 진행합니다.

첫 Ticket을 실행했어.
재현: 새로 시작 → 문으로 이동 → 문에서 멀어짐.
예상: 가까이 있을 때만 안내가 보임.
실제: 가까이 가면 안내는 보이지만 멀어져도 남아 있어. Console 오류는 없어.
현재 구현에서 거리 또는 접촉 종료를 어디서 판단하는지 읽고 원인 후보를 설명해줘.
확인한 원인부터 수정한 뒤 같은 순서와 기존 이동·수집 동작을 다시 확인하자.

2·3교시는 개인 프로젝트 제작 시간입니다. 구현 항목과 일정은 각자의 기획서를 기준으로 정하며, 이번 강의의 예시와 주제가 공통 구현 과제를 뜻하지 않습니다.

자신의 기획서에서 지금 판단이 필요한 기능 하나를 고릅니다. 그 기능의 경험 의도를 말하고 질문을 받은 뒤, 합의한 내용을 Spec과 Ticket에 남깁니다. 이미 합의와 작업이 명확한 경우에는 같은 내용을 다시 문서화하기보다 현재 기록을 확인하고 필요한 부분을 보완합니다.

첫 Ticket은 자신의 프로젝트에서 실행해 확인할 수 있는 크기로 고릅니다. 대화 선택, 퍼즐 판정, 적의 행동, 화면 전환 등 무엇이든 같은 원리를 적용할 수 있습니다. 열쇠와 문은 질문·결정·작업의 연결을 설명하기 위한 시연 사례입니다.

합의 기록·Spec·Ticket 예시 문서 내려받기 · 구성과 사용 안내

설치 명령과 옵션은 Unity CLI 1.0.0-beta.13의 도움말 및 dry-run, 공식 문서로 대조했습니다. 교안의 대화·Spec·Ticket은 교수 시연을 위한 작성 예시이며 실제 게임을 실행한 로그가 아닙니다.

• Unity CLI 설치 ↗운영체제별 설치와 명령 사용
• Unity Pipeline ↗Editor 버전, 프로젝트 패키지 설치와 연결 확인
• Unity CLI의 MCP ↗공식 MCP 경로와 이전 Assistant 서버의 구분
• Unity 공식 스킬 ↗Unity 작업 지침과 플러그인 안내
• Unity CLI Skill ↗명령 확인·프로젝트 지정·실행 결과 검증
• Matt Pocock 스킬 ↗설치, 설정과 각 스킬의 역할
• Grilling ↗질문 라운드와 추천, 합의 확인
• Grill with docs ↗질문과 프로젝트 용어·결정 기록의 연결
• To Spec ↗합의한 대화에서 기능 설계서 만들기
• To Tickets ↗행동 단위 작업, 완료 기준, 선행 관계
• 프로젝트별 스킬 설정 ↗로컬 Markdown·작업 상태·문서 위치 설정
• Skills CLI ↗add·list·agent·copy 옵션