이번 강의에서 배우는 제작 방법
기능의 상태·참조·실행 흐름을 설명하고, 오류의 재현 정보로 AI와 원인을 확인한 뒤 기존 동작까지 검증할 수 있습니다.
- 01구조 읽기
상태와 참조의 담당 위치 확인
- 02작업 나누기
한 번에 관찰할 수 있는 변경 선택
- 03원인 확인
재현과 오류 정보로 범위 좁히기
- 04재검사
변경한 기능과 기존 동작 확인
기존 기능의 관계부터 읽습니다
9주차에는 작은 기능을 처음 요청하고 실행하는 흐름을 배웠습니다. 이번에는 여러 기능이 연결된 프로젝트에서 확장 방법을 판단합니다. 시연에서는 기존 수집 기능에 열쇠와 문이 연결되어 있다고 가정하고, 다른 게임에서는 자기 기능의 관계로 바꾸어 적용합니다.
| 질문 | 확인할 근거 |
|---|---|
| 상태는 어디에 있는가? | 열쇠 보유 여부를 저장하는 필드와 이를 바꾸는 메서드 |
| 누가 그 상태를 읽는가? | 문 통과 조건, 안내 UI, 재시작 처리에서 참조하는 대상 |
| 언제 실행되는가? | 충돌 이벤트, 입력 처리, 버튼 클릭 등 기능을 시작하는 지점 |
열쇠 획득부터 문 통과, 재시작까지의 실행 흐름을 찾아줘. 관련 Scene 오브젝트, Component와 Script의 실제 이름을 근거로 설명해줘. 상태를 저장하는 곳, 읽는 곳, 초기화하는 곳을 구분해줘. 코드에서 확인한 사실과 실행으로 확인해야 할 부분을 나눠서 알려줘.
상태를 여러 곳에 복사해 저장하면 한쪽만 바뀌는 문제가 생길 수 있습니다. 현재 프로젝트가 어떤 값을 기준으로 동작하는지 확인하고, 새 기능이 그 기준을 어떻게 읽을지 정합니다.
요청을 확인 가능한 단계로 나눕니다
“열쇠 시스템을 개선해줘”를 바로 구현하기보다 바뀔 행동을 구체적으로 적습니다. 예를 들어 문이 요구하는 열쇠 수를 조절하려면 상태의 자료형, 획득 처리, 문 조건, UI와 초기화까지 영향을 확인합니다.
- 원하는 변화 정의. 문이 필요한 수량을 Inspector에서 정할 수 있도록 바꾼다는 목표를 적습니다.
- 영향 범위 확인. 기존 보유 상태와 수집 메서드가 수량을 표현할 수 있는지 확인합니다.
- 작업 순서 제안. 수량 데이터 → 획득 → 문 조건 → 표시 → 초기화 순서처럼 각 단계의 확인 방법을 함께 정합니다.
- 하나씩 적용. 각 변경 후 컴파일과 해당 행동을 확인합니다. 의도와 다른 결과가 있으면 그 단계에서 수정합니다.
문마다 필요한 열쇠 수를 Inspector에서 지정하도록 확장하고 싶어. 현재 상태와 참조 구조를 바탕으로 필요한 변경을 설명해줘. 기존 열쇠 획득과 재시작 동작을 유지하고, UI는 같은 수량을 읽어야 해. 작업을 단계로 나누고 각 단계에서 직접 확인할 동작을 제안해줘.
오류를 다시 볼 수 있게 설명합니다
오류 메시지가 있으면 메시지 전문과 호출 경로를 확인합니다. 오류 메시지가 없어도 예상과 실제 동작이 다르면 문제를 재현할 수 있는 순서를 적습니다. AI에게 실행 상태를 전달할 때는 실제 관찰과 추측을 구분합니다.
| 항목 | 예시 |
|---|---|
| 실행 환경 | 현재 Scene, Play Mode 또는 빌드, 관련 오브젝트 |
| 재현 순서 | 새 게임 시작 → 열쇠 획득 → 재시작 → 같은 열쇠 획득 |
| 예상 결과 | 재시작 직후 수량은 0, 재획득하면 1 |
| 실제 결과 | 재시작 직후 수량이 이전 값으로 표시됨 |
| 근거 | Console 메시지, 호출 경로, Inspector 참조, 화면 기록 |
재시작 후 열쇠 UI가 이전 수량을 보여줘. 예상: 재시작 직후 0. 실제: 이전 수량이 그대로 표시됨. Console 오류는 없고, 새로 열쇠를 얻으면 그때 표시가 바뀜. 초기화하는 값과 UI 갱신 시점을 확인해줘. 먼저 원인 후보와 확인 방법을 설명하고, 확인된 원인에 맞춰 수정해줘.
증상에 맞는 근거로 원인을 좁힙니다
| 증상 | 확인할 곳 | 다음 행동 |
|---|---|---|
| 컴파일 오류 | Console의 파일·줄 번호와 첫 관련 오류 | 메서드 이름·타입·참조를 확인하고 다시 컴파일 |
| NullReferenceException | 호출 경로와 해당 줄에서 사용하는 참조 | Inspector의 연결과 실행 시점 확인 |
| 한 번의 행동이 중복 처리됨 | 이벤트 등록, Collider, 같은 Component의 중복 | 어디에서 몇 번 호출되는지 기록 |
| 값은 바뀌지만 화면이 그대로임 | UI가 읽는 대상과 갱신 시점 | 상태 변경부터 화면 표시까지 흐름 추적 |
오류를 숨기기 위한 조건문을 먼저 추가하기보다 참조가 왜 비어 있는지, 호출이 왜 반복되는지 확인합니다. 로그를 잠시 추가해 원인을 확인했다면 필요한 기록만 남기고 임시 출력을 정리합니다.
수정한 행동과 연결된 행동을 다시 확인합니다
- 같은 조건으로 재검사. 문제가 발생했던 순서를 그대로 실행하여 결과가 달라졌는지 확인합니다.
- 경계 조건 확인. 필요 수량보다 적을 때·같을 때, 아무것도 얻지 않았을 때처럼 관련 조건을 확인합니다.
- 기존 동작 확인. 문 통과, 원래 수집 기능과 재시작 등 이번 변경에 영향을 받을 동작을 다시 실행합니다.
- 변경 설명. 원인, 바꾼 부분, 확인한 결과와 아직 확인하지 못한 항목을 짧게 정리합니다.
학습 내용 점검
먼저 자신의 말로 설명한 뒤 답을 펼쳐 확인합니다.
기능을 추가하기 전에 어떤 관계를 읽을까요?
상태를 저장·변경·조회·초기화하는 위치와 이를 연결하는 참조, 실행 시점을 확인합니다.
오류 설명에서 예상과 실제를 나누는 이유는 무엇일까요?
원하는 행동과 관찰한 증상을 구분해야 확인할 원인과 수정 목표를 좁힐 수 있습니다.
수정한 기능만 확인하면 충분할까요?
같은 상태나 참조를 사용하는 기존 기능도 다시 확인해야 변경의 영향을 알 수 있습니다.
자신의 프로젝트에 적용하기
2·3교시는 개인 프로젝트 제작 시간입니다. 구현 항목과 일정은 각자의 기획서를 기준으로 정하며, 이번 강의의 예시와 주제가 공통 구현 과제를 뜻하지 않습니다.
기획서에서 지금 필요한 작업을 고르고, 오늘 배운 방법 가운데 도움이 되는 것을 사용합니다. 원하는 결과와 실제 실행 결과를 비교하면서 제작을 이어가고, 막힌 부분은 현재 상태와 함께 설명합니다.
공식 자료
설치와 연결 화면은 사용 중인 버전의 공식 안내를 함께 확인합니다.
- Unity Console 창 ↗
오류 메시지와 호출 경로 확인
- Unity CLI 공식 문서 ↗
Editor 상태 조회와 도구 연결 참고