1교시의 도착점
면담에서 “거의 완성했습니다”라고 말하는 대신, 어디까지 통과했고 무엇이 막혀 있으며 어떤 한 항목을 닫을지 설명할 수 있어야 합니다.
- 01
Alpha, Beta, Release Candidate의 질문을 구분합니다.
- 02
막판 제작에서 범위 동결이 왜 품질을 지키는지 설명합니다.
- 03
실행, 경험, 복구, 성능, 권리, 제출의 릴리스 관문을 읽습니다.
- 04
문제를 P0-P3로 구분하고 수정, 삭제, 보류 중 하나를 선택합니다.
60분의 설명 흐름
릴리스 후보의 정의에서 시작해 실제 build, 권리 기록과 제출 폴더까지 한 번에 연결합니다.
“거의 완성”을 통과 가능한 상태로 바꾸기
Lecture / professor-led
- 14, 15, 16주차의 역할 분리
구조와 blocking issue를 다루는 1차 면담, 릴리스 준비를 판정하는 2차 면담, 최종 제출의 차이를 확인합니다.
- Release Candidate 정의
새 기능 후보가 아니라, 통과하면 그대로 제출할 수 있는 버전이라는 점과 버전 고정 방법을 설명합니다.
- 범위 동결
mechanic, content, tool, asset을 동결하고 새 아이디어를 backlog로 보내는 이유를 사례로 비교합니다.
- 여덟 릴리스 관문
독립 실행, 핵심 루프, 상태와 복구, 로그, 화면과 사운드, 면담 수정, 권리 기록, 제출 묶음을 차례로 읽습니다.
- 문제 우선순위와 세 행동
P0-P3를 영향으로 판정하고 수정, 삭제, 보류 중 가장 안전한 한 행동을 고릅니다.
- Development와 Release 분리
진단용 build와 제출용 build를 구분하고 Player log와 target 환경 검사 순서를 설명합니다.
- 면담 입력물 회수
2교시에 반드시 열 수 있어야 할 RC0, project, evidence, AI asset ledger와 제출 지도를 구술합니다.
세 주차는 같은 프로젝트에 서로 다른 질문을 던집니다
면담이 두 번 있다고 해서 같은 대화를 반복하지 않습니다. 14주차는 구조, 15주차는 출시 준비, 16주차는 제출된 결과를 봅니다.
- 질문
- 핵심 mechanic과 Scene, Prefab, Script 구조가 완주를 막고 있는가?
- 증거
- Beta build, blocking issue, 핵심 Script 구술
- 결과
- 범위 잠금과 구조적 blocker 하나의 해결 계획
- 질문
- 이 RC0를 그대로 제출 후보라고 부를 수 있는가?
- 증거
- 실행 build, critical path, 로그, 권리 기록, 제출 묶음
- 결과
- READY, READY IF, HOLD 판정과 한 장의 수정 ticket
- 질문
- 제출된 게임과 제작 기록이 평가 기준을 충족하는가?
- 증거
- 최종 build, project, 영상, 작품설명, AI 제작 로그
- 결과
- 3-5분 개인 게임 플레이와 제작 과정 회고
- 14주차
- 만들 수 있는 구조인지 확인
- 15주차
- 제출할 수 있는 상태인지 확인
- 16주차
- 실제로 제출된 결과를 평가
RC는 “마지막으로 시험해 보는 버전”입니다
RC0에 통과 불가능한 기능을 일부러 남겨 두거나 큰 mechanic을 추가할 예정이라면 아직 Beta입니다. RC는 문제가 없다는 선언이 아니라, 남은 위험을 고정된 검사로 판정할 수 있다는 선언입니다.
다른 환경에서 시작부터 끝까지
Editor가 아니라 지정 target의 독립 폴더에서 실행되고, 설명 없이 3-5분 핵심 루프가 끝나며 성공, 실패, 재시작이 이어집니다.
행동과 구조를 자신의 말로
게임 목표, 핵심 상태 전환, 중요한 Script 한 곳과 AI 도움을 받은 부분을 화면과 코드에 연결해 설명할 수 있습니다.
파일과 권리가 함께 열림
build, Unity project, 영상, 작품설명서, AI 제작 로그가 정해진 이름과 구조로 있고, 사용한 외부, 생성 에셋의 출처와 최종 사용 여부가 기록됩니다.
동결은 포기가 아니라 검증할 대상을 지키는 일입니다
막판 변경이 많아질수록 새 오류뿐 아니라 무엇이 효과를 냈는지 설명하기 어려워집니다. 면담 전 네 범위를 잠급니다.
- 멈춤
- 새 이동, 적, 점수 방식, 새로운 승패 규칙
- 허용
- 기존 규칙이 약속대로 작동하도록 고치는 수정
- 판정
- 핵심 한 문장에 없는 기능은 backlog로 이동
- 멈춤
- 새 Stage, 대량 Sprite 교체, 긴 사운드 추가
- 허용
- 진행 blocker 제거와 의미를 분명히 하는 최소 교체
- 판정
- 한 판 길이와 critical path를 바꾸지 않음
- 멈춤
- 새 package, 새 AI 도구, 새 자동화 환경 도입
- 허용
- 이미 검증된 도구로 제한된 진단과 수정
- 판정
- 설치, 계정, 버전 위험이 결과보다 크면 사용하지 않음
- 멈춤
- 출처를 모르는 에셋과 권리 검토 없는 생성 결과
- 허용
- 기존 사용 에셋의 가독성, 크기, 색상 최소 조정
- 판정
- source, license, AI 여부, 수정, 최종 사용을 기록
“좋아 보인다” 대신 여덟 문을 통과합니다
2차 면담은 작품 취향을 묻는 시간이 아닙니다. 같은 여덟 관문에서 첫 FAIL을 찾고, 그 지점을 3교시 한 문제로 바꿉니다.
독립 실행
새 폴더와 지정 target 환경에서 실행 파일이 열리고 시작 화면 또는 게임이 정상 표시됩니다.
3-5분 핵심 경로
목표를 이해하고 핵심 행동을 거쳐 결과까지 도착합니다. 진행을 막는 dead end가 없습니다.
결과와 복구
진행, 위험, 성공, 실패가 읽히며 재시작 뒤 초기 상태가 다시 만들어집니다.
오류와 로그
critical path 중 crash, Exception, Missing Reference가 없고 Player log를 확인했습니다.
UI, 화면, 사운드
지정 화면 비율에서 잘리지 않고, 음소거 또는 색 하나 없이도 핵심 상태를 구분합니다.
면담 문제 재검사
면담에서 승인한 한 문제가 같은 입력과 기대 결과로 개선되고 기존 루프가 유지됩니다.
출처와 AI 투명성
외부, 생성 에셋의 source, 허용 범위, prompt, 직접 수정과 최종 사용 여부가 연결됩니다.
제출 리허설
build, project, 영상, 작품설명서, AI 로그가 정해진 이름으로 한 폴더에서 열립니다.
심각도를 정한 뒤 수정, 삭제, 보류 중 하나를 고릅니다
수정 가능 시간이 짧을수록 “불편한가?”보다 “제출과 핵심 경험을 막는가?”를 먼저 묻습니다.
- 상태
- 실행 불가, crash, 진행 불가, 최종 파일 없음
- 행동
- 즉시 수정하거나 원인 기능을 안전하게 삭제
- 예시
- 목표 도착 시 Exception으로 결과 화면이 열리지 않음
- 상태
- 완주는 가능하지만 결과, 조작, 복구가 자주 오해됨
- 행동
- 기능 추가 없이 최소 수정 후 같은 조건 재검사
- 예시
- 성공했지만 플레이어가 실패로 이해하고 종료함
- 상태
- 핵심 루프는 유지되나 일관성, 가독성이 낮음
- 행동
- P0, P1이 없고 회귀 시간이 남을 때만 수정
- 예시
- 일부 효과음 음량이 다른 사건보다 조금 큼
- 상태
- 새 아이디어, 추가 Stage, 장식과 취향
- 행동
- 최종 제출 뒤 확장 목록으로 보류
- 예시
- 두 번째 적 종류와 별도 ending 연출 추가
진단용 build와 제출 후보를 구분합니다
Editor Play Mode 통과는 독립 실행 통과와 다릅니다. 원인을 찾을 때는 Development Build를 사용할 수 있지만, RC 판정은 최종 조건과 같은 profile에서 다시 실행합니다.
문제를 찾는 상태
Development Build, Autoconnect Profiler와 log를 선택적으로 사용합니다. 측정 도구의 overhead가 있을 수 있으므로 이 수치를 최종 체감과 동일하다고 가정하지 않습니다.
제출 조건을 재현하는 상태
지정 Build Profile, Scene List, target platform과 같은 폴더 구조를 사용합니다. 새 위치에서 실행하고 3-5분 critical path를 처음부터 끝까지 검사합니다.
- 01
실패를 같은 순서로 재현합니다
버전, target, 입력, 장면과 기대 결과를 고정합니다. “가끔 안 됨”을 재현 단계로 바꿉니다.
증거 동일한 RC0에서 같은 실패가 다시 나타납니다.
- 02
Console과 Player log를 확인합니다
Editor 메시지만 보지 않고 독립 Player의 경고, 오류와 발생 시점을 확인합니다. 추측한 원인과 실제 stack 위치를 구분합니다.
증거 오류가 없으면 “없음”을, 있으면 첫 관련 오류와 재현 시각을 기록합니다.
- 03
필요할 때만 Profiler로 측정합니다
느림이 release risk일 때 CPU, GPU, Memory 중 질문과 연결된 한 module만 봅니다. 무작정 모든 graph를 열지 않습니다.
증거 target build의 특정 구간과 측정값이 문제 문장에 연결됩니다.
- 04
수정 뒤 release 조건으로 다시 build합니다
진단 옵션을 끄고 새 RC 폴더에 build하여 선택 문제와 기존 핵심 경로를 다시 검사합니다.
증거 RC0와 RC1의 folder, 시간, 변경 범위와 판정이 구분됩니다.
AI metadata는 찾는 단서이지 사용 허가의 증명은 아닙니다
Unity AI 생성 결과는 검색 가능한 metadata를 포함할 수 있지만, 최종 사용에 필요한 제3자 권리와 적합성 판단은 제작자가 책임집니다. 외부 에셋도 같은 방식으로 출처와 허용 범위를 확인합니다.
- 기록
- 직접 제작, 수업 제공, Asset Store, 생성 도구
- 확인
- 원본 위치, 제작자 또는 tool, provider, model
- 금지
- 기억에 의존한 “무료였음”
- 기록
- license 또는 수업 내 사용 범위
- 확인
- 재배포, 수정, 참조 업로드 제한
- 금지
- 다운로드 가능과 사용 허가를 동일시
- 기록
- prompt, reference, 후보, 선택, 직접 수정
- 확인
- 사람의 결정과 게임 내 역할
- 금지
- 최종 결과만 남기고 과정 삭제
- 기록
- 최종 사용, placeholder, 폐기
- 확인
- 실제 RC1 build 안의 파일과 ledger 일치
- 금지
- 프로젝트에 남은 미사용 파일까지 최종 사용으로 표기
막판에 자주 생기는 여섯 가지 착각
완성도를 높이려는 행동이 오히려 제출 가능성을 낮추는 순간을 미리 구분합니다.
새 기능이 완성도를 높인다
검사하지 못한 새 기능은 새로운 release risk입니다. 핵심 경험이 유지되면 추가하지 않습니다.
Editor에서 되면 build도 된다
Scene List, 경로, 권한, platform 차이가 있습니다. 독립 build에서 다시 확인합니다.
오류가 안 보이면 로그도 깨끗하다
화면에 드러나지 않는 Exception과 경고가 있을 수 있습니다. Player log를 직접 확인합니다.
모든 문제를 조금씩 고친다
여러 변경은 회귀 범위를 키웁니다. 가장 앞의 FAIL 하나를 닫고 전체 경로를 다시 실행합니다.
생성 도구가 권리를 보장한다
도구 사용 가능성과 최종 콘텐츠의 제3자 권리는 다른 질문입니다. 제작자가 확인하고 기록합니다.
제출 폴더는 마지막에 만들면 된다
파일 누락과 잘못된 build는 작품 품질과 별개로 제출을 막습니다. RC 단계에서 미리 리허설합니다.
면담 전에 다섯 문장으로 회수합니다
학생이 먼저 답하고, 교수자는 답이 아니라 빠진 증거의 종류를 되묻습니다.
RC
Beta와 Release Candidate의 가장 중요한 차이는 무엇인가요?
Freeze
좋은 아이디어라도 15주차에 backlog로 보내야 하는 이유는 무엇인가요?
Gate
“거의 완성”을 대신할 여덟 관문 중 첫 네 개를 말해 보세요.
Triage
불안정한 선택 기능을 고치는 것보다 삭제하는 편이 안전한 때는 언제인가요?
Evidence
Editor Play Mode 외에 면담에서 열어야 할 증거 네 가지는 무엇인가요?
면담 전에 확인할 공식 자료
메뉴와 기능은 Unity 버전에 따라 달라질 수 있으므로 수업에 설치된 Unity 6.6과 같은 버전의 문서를 사용합니다.
- Unity 6.6, Build Profiles reference ↗target profile, Development Build, Profiler와 build 옵션
- Unity 6.6, Log files reference ↗Editor, Player log의 역할과 운영체제별 위치
- Unity 6.6, Collecting performance data ↗target application과 Profiler 연결
- Unity, Testing and QA practices ↗functional, regression, performance testing과 지속적 QA
- Unity AI, Guiding Principles ↗metadata, data control, traceability와 최종 사용자의 권리 책임