Week 14 / Period 02 / Theory and Demonstration

구조와 판단을
함께 진단합니다

교수자의 공개 면담 한 번을 천천히 해부하며, 말과 실제 프로젝트 증거가 만나는 지점을 익힙니다.

교수자와 시연자 두 사람이 작은 게임 모형, 네 단계 동작 흐름과 확대된 문제 하나를 확인하고 주변 관찰석이 분리된 미니어처 면담 교실
RUN, TRACE, EXPLAIN, DECIDE 교수자는 준비된 사례를 직접 시연합니다. 학생은 실행되는 사실, 구조 설명과 결정 근거가 어디에서 일치하거나 어긋나는지 판정합니다.

2교시의 도착점

학생은 프로젝트를 제작하지 않습니다. 교수자의 설명과 공개 시연을 보며 면담 질문이 확인하려는 사실과 통과 증거를 자신의 말로 구분합니다.

  • 설명

    실행, 구조, 코드, 증거와 우선순위가 왜 이 순서로 이어지는지 이해합니다.

  • 시연

    준비된 Alpha 사례 한 건을 표준 8분 면담으로 처음부터 끝까지 관찰합니다.

  • 판정

    주장과 실제 위치가 일치하는지 보고 blocking issue 하나와 완료 조건을 고릅니다.

  • 인계

    3교시 시작 전에 자신의 자료에서 확인해야 할 증거 위치만 표시합니다.

설명 장면

시연 화면과 관찰 화면을 분리합니다

교수자는 실행 화면, 구조도와 핵심 Script를 한 화면에 준비합니다. 학생은 결론을 받아 적지 않고 각 질문이 어떤 증거를 요구하는지 추적합니다.

DEMONSTRATION DESK

교수자가 준비한 Alpha 사례

독립 build, 구조도, 핵심 Script, 테스트 기록과 의도적으로 남긴 불일치 한 건을 함께 보여 줍니다.

  • 동일한 시작 조건에서 build 실행
  • 실제 Scene, Prefab과 Script 추적
  • 좋은 설명과 추측을 나란히 비교
  • 마지막에 승인 문장 작성
OBSERVATION DESKS

학생의 판정 노트

학생은 자신의 project를 수정하지 않고 교수자 사례에서 관찰한 증거만 짧게 기록합니다.

  • 확인된 사실과 주장 분리
  • 질문이 가리키는 실제 위치 표시
  • P0부터 P3까지 우선순위 판정
  • 완료 조건과 회귀 범위 비교
DEMO RULE교수자가 먼저 답을 공개하지 않습니다. 학생이 증거를 말한 뒤, 실제 화면을 열어 판단을 확인합니다.

면담 길이보다 네 가지 판정 기준이 먼저입니다

좋은 면담은 질문 수가 많은 면담이 아닙니다. 실행 사실에서 구조와 학생의 판단까지 끊기지 않고 이어지는지 확인합니다.

RUN

같은 조건에서 실행

기억이나 Editor 상태가 아니라 제출 가능한 build에서 핵심 한 판을 재현합니다.

TRACE

결과에서 소유자 추적

화면 변화에서 Scene, Prefab, GameObject, Component와 Script까지 실제 이름으로 거슬러 갑니다.

EXPLAIN

사건과 상태를 연결

코드를 번역하지 않고 owner, event, condition, state, feedback과 proof를 설명합니다.

DECIDE

한 가지 다음 행동 승인

가장 큰 문제 하나의 허용 변경, 금지 범위, 기대 결과와 회귀 검사를 문장으로 닫습니다.

판정 지점통과 증거다시 물어볼 신호
실행학생 설명과 build의 관찰 결과가 일치함Editor에서만 작동하거나 재현 조건이 계속 바뀜
구조실제 이름과 참조를 화면에서 가리킬 수 있음“아마”, “보통”처럼 프로젝트 밖 일반론으로 답함
이해상태 전후, 거부 조건과 피드백을 자신의 말로 연결함코드를 줄마다 읽지만 사건과 결과를 설명하지 못함
결정한 문제의 범위와 PASS 조건이 관찰 가능한 문장임새 기능 목록만 늘어나고 완료 판정이 없음

면담 프로토콜

표준 8분은 실행에서 한 가지 결정까지 이어집니다

교수자는 준비된 사례의 시연자 역할도 맡습니다. 질문, 사례 답변, 실제 화면 확인과 판정 해설을 구분해 보여 줍니다.

  1. RUN교수자가 Alpha build를 실행합니다

    준비된 사례의 시작, 핵심 행동, 성공 또는 실패와 재시작 중 필요한 경로를 교수자가 보여 줍니다.

  2. STATE핵심 mechanic을 한 문장으로 말합니다

    행동, 조건, 상태 변화와 목표가 화면 결과와 일치하는지 확인합니다.

  3. MAPScene에서 Script까지 추적합니다

    구조도의 실제 이름을 Hierarchy, Project와 Inspector에서 찾아 참조를 연결합니다.

  4. EXPLAIN핵심 Script 한 건을 설명합니다

    owner, event, condition, state, feedback과 proof를 코드와 실행 결과로 연결합니다.

  5. EVIDENCE플레이테스트와 AI 기록을 확인합니다

    준비된 사례의 실제 관찰, 선택된 수정, 사용 또는 미사용 내역과 검증 증거를 구분합니다.

  6. DECIDE가장 큰 문제 하나를 승인합니다

    문제 문장, 변경 범위, 완료 조건, 재검사와 15주차 전 마감을 기록합니다.

좋은 답은 말과 화면이 같은 사실을 가리킵니다

유창함을 평가하지 않습니다. 학생이 짧게 말하더라도 실제 build, Inspector, 코드와 테스트가 설명을 지지하면 충분합니다.

CLAIM

학생의 주장

“세 번째 수집 뒤 출구가 열립니다”처럼 관찰 가능한 문장으로 말합니다.

LOCATION

실제 소유 위치

상태 필드, 변경 메서드, Prefab 참조와 Scene Instance를 가리킵니다.

RUN

실행 결과

정상 조건과 거부 조건을 Play Mode 또는 build에서 재현합니다.

RECORD

남은 증거

테스트 행, 화면, Console과 변경 기록이 같은 결론을 남깁니다.

확인이 더 필요한 답

“AI가 이렇게 하라고 했습니다”

선택 이유, 실제 변경 위치와 테스트가 없으므로 학생의 판단을 확인할 수 없습니다.

통과 가능한 답

“이 조건을 추가하고 두 경계값을 다시 검사했습니다”

학생의 선택, 변경과 증거가 연결되므로 도구 사용 여부와 관계없이 이해를 확인할 수 있습니다.

질문은 확인하려는 사실에 맞춰 고릅니다

모든 질문을 묻지 않습니다. build와 학생 설명이 어긋나는 지점에서 가장 가까운 질문을 사용합니다.

핵심 mechanic이 실제로 완결되는가
  • 한 판의 시작과 끝을 어떤 상태가 구분하나요?
  • 핵심 행동이 목표에 영향을 주지 않는 경우는 언제인가요?
  • 실패 뒤 같은 초기 상태를 어떻게 복구하나요?
Scene과 Prefab의 역할을 구분하는가
  • 이 오브젝트는 Scene에만 있나요, Prefab Instance인가요?
  • Prefab Asset을 바꾸면 어떤 Instance에 영향을 주나요?
  • 이 Inspector 참조가 비어 있으면 어디에서 실패하나요?
핵심 Script를 이해하는가
  • 이 메서드를 호출하는 최초 사건은 무엇인가요?
  • 중복 실행을 막는 조건은 어디에 있나요?
  • 상태를 바꾼 직후 어떤 피드백이 갱신되나요?
테스트와 AI 기록이 진실한가
  • 이 수정 전후에 같은 조건을 사용했나요?
  • 도구 제안 중 거부한 항목은 무엇이며 왜 거부했나요?
  • 현재 build가 이 기록 이후 만들어졌다는 근거는 무엇인가요?

한 가지 결정

면담은 문제 목록이 아니라 승인된 다음 행동으로 끝냅니다

문제를 세 개 이상 말해도 이번에 승인하는 것은 하나입니다. 경험 영향, 반복 여부와 수정 위험을 함께 보고 가장 작은 완료 단위로 바꿉니다.

P0 / CANNOT SHIP

실행과 제출이 불가능함

build 실패, crash, Scene 누락과 외부 파일 의존처럼 다른 검사를 시작할 수 없는 문제입니다.

P1 / CORE BLOCKER

핵심 한 판이 끝나지 않음

입력, 진행, 성공·실패 또는 재시작이 끊겨 목표를 완료할 수 없는 문제입니다.

P2 / CLARITY

완료되지만 의미가 흐림

목표, 상태와 다음 행동을 이해하기 어렵거나 피드백이 잘못된 의미를 전달합니다.

P3 / POLISH

완료와 이해에 영향이 적음

작은 정렬, 추가 연출과 선택적 장식입니다. 14주차 승인 항목으로 선택하지 않습니다.

DECISION SENTENCE

[관찰 조건]에서 [현재 결과]가 나타납니다. [Scene, Prefab 또는 Script]의 [작은 범위]만 바꾸고, [같은 조건의 기대 결과]와 [회귀 범위]로 완료를 판정합니다.

준비된 사례 하나를 15분 동안 판정합니다

교수자가 같은 사례를 두 번째로 보여 주되 이번에는 중간 해설을 멈춥니다. 학생은 근거를 먼저 고른 뒤 마지막에 판정 이유를 설명합니다.

  1. 3 minOBSERVE

    실행 화면에서 확인된 사실과 시연자의 주장을 두 칸으로 나누어 적습니다.

  2. 4 minTRACE

    화면 결과를 소유하는 Scene, Prefab과 Script 위치를 구조도에서 찾습니다.

  3. 4 minJUDGE

    문제를 P0부터 P3까지 분류하고 승인할 한 문제와 완료 조건을 고릅니다.

  4. 4 minEXPLAIN

    선택한 증거와 다른 선택을 버린 이유를 짝에게 60초 안에 설명합니다.

이 연습에서는 실제 project를 열거나 수정하지 않습니다.

답이 다르면 다수결로 정하지 않습니다. 어느 화면, 이름, 상태 또는 테스트가 각 판단을 지지하는지 다시 확인합니다.

모든 학생에게 같은 기준과 다른 깊이의 질문을 제공합니다

게임 장르와 구현 방식은 달라도 통과 기준은 같습니다. 말하기 속도, 유료 도구와 생성 횟수는 평가하지 않습니다.

공통으로 확인

실행 가능한 핵심 loop, 실제 구조, Script 한 건의 이해, 플레이테스트 증거와 다음 수정의 완료 조건입니다.

학생마다 조절

선택한 mechanic과 코드 난도에 따라 질문 깊이와 확인할 Script 수를 줄이거나 늘립니다.

AI 미사용 경로

직접 구현과 공식 문서 사용 기록만으로 같은 설명, 변경과 검증 기준을 충족할 수 있습니다.

설명 지원

말로 설명하기 어렵다면 구조도와 코드를 가리키거나 짧은 문장 순서표를 사용할 수 있습니다.

면담이 막힐 때는 더 작은 사실로 돌아갑니다

학생의 답을 대신 만들지 않고 현재 확인할 수 있는 가장 가까운 증거를 찾습니다.

build가 시작되지 않습니다

면담 시간을 설치와 복구에 모두 쓰지 않습니다. 최근 실행 화면과 Console을 확인하고 P0로 기록한 뒤, 작동하는 project copy와 Build Profile을 복구하는 첫 행동을 승인합니다.

학생이 Script를 전혀 설명하지 못합니다

코드를 외우게 하지 않습니다. 바뀌는 필드, 그 필드를 쓰는 메서드, 메서드를 부르는 사건을 차례로 찾게 합니다. 그래도 연결되지 않으면 해당 생성 코드를 핵심 범위에서 제거하거나 직접 이해 가능한 구현으로 축소합니다.

문제가 너무 많아 하나를 고르지 못합니다

실행 불가, 핵심 진행 불가, 의미 불명확, 장식의 순서로 나눕니다. 앞 단계가 해결되지 않았다면 뒤 단계는 Later로 이동합니다.

교수자가 바로 고칠 수 있는 문제입니다

대신 수정하지 않습니다. 확인할 위치와 테스트 질문까지만 제공하고 학생이 자신의 자리에서 변경과 검증을 수행하게 합니다.

면담 시간이 끝났지만 결론이 없습니다

확인된 사실, 아직 모르는 사실과 다음 진단 행동 한 가지를 기록합니다. 완성 해결책이 없어도 검증 가능한 다음 행동이 있으면 면담 기록은 유효합니다.

면담 중 새 기능 아이디어가 나왔습니다

Later에 한 문장으로 보존하고 이번 승인 항목에 넣지 않습니다. 현재 한 판의 완료를 막는 문제부터 닫습니다.

2교시 확인 자료

면담에서는 일반적인 기억보다 해당 프로젝트의 실제 연결과 Unity 6.6 공식 문서를 우선합니다.