디버깅과 테스트를 AI와 함께 수행하기

생성보다 중요한 것은 검증이다

AI를 제작 파이프라인에 넣으면 코드와 에셋, UI 초안을 빠르게 만들 수 있다. 하지만 속도가 빨라질수록 다른 문제가 생긴다. 작은 오류도 더 빨리, 더 많이 만들어질 수 있다. 그래서 AI 개발의 품질은 생성 속도가 아니라 오류를 얼마나 빨리 발견하고, 재현하고, 검증하는가에서 결정된다.

디버깅에서 AI의 역할은 세 가지다.

첫째, 로그와 증거를 읽고 원인 후보를 정리한다. 둘째, 사람이 놓친 재현 조건과 테스트 항목을 질문한다. 셋째, 수정 후 회귀 테스트, 즉 예전에 되던 기능이 다시 망가지지 않았는지 확인할 목록을 만든다.

반대로 AI에게 맡기면 안 되는 일도 있다. "어떻게든 고쳐 줘"처럼 넓은 권한을 주고 프로젝트 전체를 수정하게 하는 일이다. 버그는 원인을 좁힌 뒤 작은 변경으로 고쳐야 한다. AI가 제안한 수정도 코드 리뷰, 실행 테스트, Git 변경 내역 확인을 거쳐야 한다.

AI 생성 이미지

AI에게 줄 디버깅 정보는 증거 묶음이어야 한다

AI에게 오류를 설명할 때 가장 흔한 실수는 에러 메시지 한 줄만 보내는 것이다. 예를 들어 NullReferenceException만 전달하면 AI는 일반적인 설명은 할 수 있지만, 프로젝트 안에서 어떤 오브젝트가 비어 있는지는 알 수 없다.

좋은 디버깅 요청은 다음 정보를 함께 담는다.

• 무엇을 하려고 했는가

• 실제로 어떤 문제가 발생했는가

• 언제부터 발생했는가

• 어떤 로그와 스택 트레이스가 나왔는가

• 관련 씬, 프리팹, 블루프린트, 위젯의 현재 설정은 무엇인가

• 최근 변경된 파일은 무엇인가

• AI가 수정해도 되는 범위와 수정하면 안 되는 범위는 어디인가

• 수정 후 어떤 방식으로 검증할 것인가

핵심은 AI가 추측할 공간을 줄이는 것이다. 로그, 화면 상태, 입력 순서, 에디터 설정을 묶어 주면 AI는 "가능한 원인 목록"이 아니라 "확인해야 할 순서"를 제안할 수 있다.

디버깅 요청의 기본 형식은 다음처럼 잡을 수 있다.

목표:
- 플레이어가 아이템을 클릭하면 인벤토리에 추가되고 UI 슬롯이 갱신되어야 한다.

문제:
- 아이템 클릭 후 콘솔에 NullReferenceException이 발생한다.
- 인벤토리 데이터에는 추가된 것처럼 보이지만 UI 슬롯은 갱신되지 않는다.

재현 절차:
1. TestInventoryScene을 연다.
2. Play Mode를 실행한다.
3. 화면 왼쪽의 Potion_Item을 클릭한다.
4. 인벤토리 패널을 연다.
5. 콘솔 오류를 확인한다.

증거:
- 콘솔 로그와 스택 트레이스:
  ...
- 관련 오브젝트 Inspector 값:
  InventoryPanel: 연결됨
  SlotContainer: None
  ItemSlotPrefab: 연결됨
- 최근 변경 파일:
  InventoryUI.cs
  ItemPickup.cs

요청:
- 바로 수정하지 말고 원인 후보를 우선순위대로 정리해 줘.
- 추가로 확인해야 할 Inspector 값과 로그 위치를 알려 줘.
- 수정이 필요하다면 InventoryUI.cs 안에서만 최소 변경안을 제안해 줘.

검증 기준:
- 같은 절차에서 콘솔 오류가 없어야 한다.
- Potion 아이템이 첫 번째 빈 슬롯에 표시되어야 한다.
- 슬롯이 20개를 넘지 않아야 한다.

이 형식은 Unity와 Unreal 모두에 적용할 수 있다. 엔진마다 증거의 이름이 다를 뿐이다.

Unity: 콘솔 로그, 스택 트레이스, 씬 구성을 함께 전달하기

Unity에서 AI 디버깅을 할 때는 Console 창의 로그만 복사하지 말고, 스택 트레이스와 씬 상태를 함께 전달해야 한다. 스택 트레이스는 오류가 어떤 함수 호출 흐름에서 발생했는지 보여 주는 기록이다. 초보자는 길어서 부담스럽게 느낄 수 있지만, AI와 사람이 원인을 좁히는 데 가장 중요한 단서다.

Unity 디버깅 요청에는 다음 항목을 넣는다.

• Unity 버전과 대상 플랫폼

• 현재 씬 이름

• Play Mode에서 한 입력 순서

• Console 오류 전체와 스택 트레이스

• 관련 GameObject의 Hierarchy 위치

• Inspector에 연결된 참조 값

• 최근 수정한 C# 스크립트

• 프리팹 인스턴스인지 씬 오브젝트인지 여부

특히 NullReferenceException, MissingReferenceException, IndexOutOfRangeException은 Inspector 값과 연결되는 경우가 많다. AI에게 코드만 보여 주면 "null 체크를 추가하라"고 답할 가능성이 높다. 하지만 실제 원인은 프리팹의 필드가 비어 있거나, 씬 안의 오브젝트 이름이 바뀌었거나, 비활성화된 오브젝트를 찾지 못한 것일 수 있다.

AI에게는 이렇게 요청하는 편이 좋다.

Unity 디버깅 요청

환경:
- Unity 6
- 씬: UI_Inventory_Test
- 입력: 마우스 클릭 + 키보드 I

오류:
- Console 로그 전체:
  ...
- 스택 트레이스:
  ...

현재 씬 구성:
- Canvas
  - InventoryPanel
    - SlotContainer
- Player
  - InventoryController
- EventSystem 있음

Inspector 상태:
- InventoryUI.slotContainer = None
- InventoryUI.slotPrefab = ItemSlot.prefab
- InventoryController.inventoryUI = InventoryPanel의 InventoryUI

요청:
1. 오류 원인을 코드 문제, Inspector 연결 문제, 실행 순서 문제로 나누어 분석해 줘.
2. 가장 먼저 확인할 항목 3개를 알려 줘.
3. 수정안은 최소 변경으로 제안하고, 새 public 필드를 추가하지 않는 방향을 우선해 줘.
4. Play Mode에서 확인할 테스트 절차를 같이 작성해 줘.

Unity에서 AI가 자주 제안하는 수정은 FindObjectOfType, GameObject.Find, 넓은 try-catch, 무조건적인 null 체크다. 이런 코드는 당장 오류를 숨길 수는 있지만 구조를 더 불안정하게 만들 수 있다. 따라서 AI 답변을 받을 때는 "오류를 숨기는 수정인지, 원인을 제거하는 수정인지"를 구분해야 한다.

좋은 수정은 보통 다음 중 하나다.

• 필요한 참조를 Inspector에서 명확히 연결한다.

• 초기화 순서를 Awake, Start, 이벤트 구독 시점에 맞게 정리한다.

• UI 갱신 함수가 데이터 변경 후 한 번만 호출되도록 한다.

• 리스트 범위, 빈 슬롯, 비활성 오브젝트 같은 조건을 명시적으로 처리한다.

수정 후에는 같은 재현 절차를 다시 실행하고, Console에 새 경고가 생기지 않았는지 확인한다. AI에게 "수정 코드"만 받지 말고 "검증 로그에 무엇이 보여야 하는지"까지 요청해야 한다.

Unreal: Output Log, Blueprint 오류, PIE 결과를 최소 재현으로 묶기

Unreal에서는 오류의 증거가 여러 곳에 흩어져 있다. Output Log, Blueprint 컴파일 오류, Message Log, PIE 실행 결과, 크래시 리포트가 각각 다른 단서를 준다. AI에게 분석을 요청할 때는 이 정보를 한 번에 정리해야 한다.

Unreal 디버깅 요청에는 다음 항목이 필요하다.

• Unreal Engine 버전

• 오류가 발생한 Level 이름

• PIE에서 한 입력 순서

• Output Log의 관련 구간

• Blueprint Compile Error 원문

• 문제가 발생한 Blueprint, Widget Blueprint, Actor 이름

• 관련 변수의 기본값과 런타임 값

• 최근 수정한 노드, 함수, 이벤트

• 크래시가 있다면 발생 직전 행동과 콜스택 요약

Blueprint 오류는 노드 이름만 보고 고치기 어렵다. AI에게는 그래프의 의도를 설명해야 한다. 예를 들어 "Interact 이벤트에서 Door Actor를 Cast한 뒤 Open 함수를 호출한다"처럼 흐름을 말해야 한다. 노드 스크린샷을 사용할 수 있다면 변수명과 연결 방향이 보이게 캡처한다.

Unreal용 요청 형식은 다음처럼 쓸 수 있다.

Unreal 디버깅 요청

환경:
- Unreal Engine 5.x
- Level: L_Interaction_Test
- 실행 방식: PIE

문제:
- E 키로 문을 열려고 하면 아무 반응이 없다.
- Blueprint compile은 성공하지만 PIE 중 Warning이 출력된다.

재현 절차:
1. L_Interaction_Test를 연다.
2. PIE 실행.
3. 플레이어를 BP_Door_01 앞까지 이동.
4. E 키 입력.
5. 문 애니메이션이 실행되지 않고 Output Log에 Warning 발생.

증거:
- Output Log 관련 구간:
  ...
- 관련 Blueprint:
  BP_PlayerCharacter
  BPI_Interactable
  BP_Door
- 변수 상태:
  CurrentInteractTarget = None
  InteractionTraceDistance = 250
- 최근 변경:
  LineTrace 채널을 Visibility에서 Camera로 변경함.

요청:
1. 입력 문제, Trace 문제, Interface 호출 문제, Door Blueprint 문제로 나누어 원인을 분석해 줘.
2. Blueprint 그래프에서 확인할 노드와 변수 목록을 알려 줘.
3. 수정안을 제안하되, 기존 BPI_Interactable 구조는 유지해 줘.
4. PIE에서 확인할 테스트 케이스를 작성해 줘.

크래시가 발생한 경우에는 "에디터가 꺼졌다"가 아니라 발생 직전 행동을 남겨야 한다. 어떤 레벨을 열었는지, 어떤 에셋을 클릭했는지, PIE 시작 직후인지 종료 시점인지, 특정 Blueprint를 컴파일한 직후인지가 중요하다. 크래시는 한 줄 설명보다 재현 순서가 더 가치 있다.

AI에게 테스트 체크리스트를 만들게 하기

AI는 사람이 놓친 테스트 항목을 넓게 뽑아내는 데 유용하다. 특히 UI, 입력, 저장, 해상도처럼 반복 확인이 필요한 영역에서 효과적이다. 단, AI가 만든 체크리스트도 프로젝트에 맞게 줄여야 한다. 모든 테스트를 매번 수행하면 제작 속도가 떨어진다. 중요한 기능과 최근 변경된 영역을 우선한다.

UI 테스트

UI 테스트는 "보이는가"에서 끝나면 안 된다. 실제 데이터와 입력이 들어왔을 때 무너지지 않는지 봐야 한다.

• 버튼 기본, hover, pressed, disabled 상태가 구분되는가

• 팝업이 열릴 때 배경 입력이 차단되는가

• 닫기 버튼, Esc, 게임패드 B 버튼이 같은 동작을 하는가

• 긴 텍스트와 다국어 문자열에서 레이아웃이 깨지지 않는가

• 빈 목록, 최대 목록, 오류 상태가 표시되는가

• HUD가 게임 진행 중 필요한 정보를 가리지 않는가

• 색상만으로 상태를 구분하지 않는가

AI에게는 이렇게 요청할 수 있다.

이 인벤토리 UI에 대해 누락된 테스트 항목을 찾아 줘.
조건:
- 마우스, 키보드, 게임패드 입력을 지원한다.
- 아이템 슬롯은 0개부터 80개까지 변할 수 있다.
- 한국어와 영어 문자열을 사용한다.
- Unity Canvas로 구현되어 있다.
출력:
- 필수 테스트 10개
- 나중에 해도 되는 테스트 5개
- 버그가 발생했을 때 남길 증거 목록

입력 테스트

입력 테스트는 플랫폼과 장치에 따라 달라진다. PC에서는 키보드와 마우스가 잘 되더라도 게임패드 포커스가 끊길 수 있다. 모바일에서는 터치 영역이 작거나, 화면 회전 후 좌표가 어긋날 수 있다.

• 같은 동작이 키보드, 마우스, 게임패드에서 일관되게 작동하는가

• UI가 열렸을 때 캐릭터 이동 입력이 차단되는가

• 버튼을 빠르게 연타해도 상태가 꼬이지 않는가

• 입력 장치를 바꾸었을 때 안내 아이콘이 갱신되는가

• 포커스가 없는 상태에서 게임패드 입력이 막히지 않는가

저장·불러오기 테스트

저장 기능은 AI가 만든 코드에서 특히 조심해야 한다. 실행 중에는 정상처럼 보여도 다시 시작하면 데이터가 사라지거나, 버전이 바뀐 뒤 불러오기에 실패할 수 있다.

• 새 게임에서 기본값이 올바른가

• 저장 후 재시작해도 같은 상태가 복원되는가

• 저장 파일이 없을 때 오류 없이 시작되는가

• 일부 데이터가 누락된 오래된 저장 파일을 처리하는가

• 저장 중 게임을 종료해도 파일이 완전히 깨지지 않는가

• 인벤토리, 퀘스트, 위치, 옵션 값이 서로 맞는가

해상도와 플랫폼 테스트

Figma에서 정리한 화면이 엔진에 들어오면 해상도와 안전 영역 문제가 드러난다. AI에게 해상도 테스트 표를 만들게 하면 반복 확인이 쉬워진다.

• 16:9, 16:10, 21:9, 4:3 비율에서 주요 UI가 잘리는가

• 모바일 노치나 콘솔 안전 영역을 침범하지 않는가

• 작은 해상도에서 글자와 버튼이 너무 작아지지 않는가

• 큰 해상도에서 요소 간격이 과하게 벌어지지 않는가

• 전체 화면, 창 모드, 해상도 변경 후 레이아웃이 갱신되는가

AI 수정안은 회귀 테스트와 함께 검토한다

버그를 하나 고쳤는데 다른 기능이 망가지는 일이 있다. 이것이 회귀다. AI가 제안한 수정은 빠르기 때문에 회귀 위험도 함께 커진다. 수정 전후를 비교하는 절차를 정해 두어야 한다.

가장 간단한 검토 순서는 다음과 같다.

1. 버그 재현 절차를 문서화한다.

2. 수정 전 Git 상태를 확인하고 브랜치를 나눈다.

3. AI에게 원인 분석과 최소 수정안을 요청한다.

4. 변경 파일을 제한한다.

5. 수정 후 같은 재현 절차를 다시 실행한다.

6. 관련 기능의 회귀 테스트를 실행한다.

7. Git diff를 확인해 의도하지 않은 변경이 없는지 본다.

8. 테스트 결과와 남은 위험을 커밋 메시지나 작업 기록에 남긴다.

AI에게 Git diff를 보여 줄 때는 전체 파일을 무작정 붙이기보다 변경 의도를 함께 설명한다.

다음 Git diff를 리뷰해 줘.
목표:
- 인벤토리 슬롯 갱신 시 NullReferenceException을 해결한다.

검토 기준:
- 오류를 숨기기만 하는 null 체크가 아닌지 확인해 줘.
- 기존 저장 데이터 구조를 바꾸지 않았는지 확인해 줘.
- UI 갱신 호출 횟수가 불필요하게 늘어나지 않았는지 확인해 줘.
- 추가로 필요한 테스트를 제안해 줘.

변경 파일:
- InventoryUI.cs
- InventoryController.cs

Diff:
...

이때 AI의 리뷰는 최종 승인이 아니다. 사람이 실제 실행 결과를 확인해야 한다. 특히 입력, 물리, 애니메이션, 네트워크, 저장 기능은 코드만 보고 판단하기 어렵다. Play Mode, PIE, 실제 기기 테스트가 필요하다.

단위 테스트와 플레이 테스트를 함께 사용하기

테스트는 크게 두 종류로 나눌 수 있다. 하나는 작은 함수나 규칙을 확인하는 단위 테스트다. 다른 하나는 실제 플레이 흐름을 확인하는 플레이 테스트다.

단위 테스트는 계산, 데이터 변환, 저장 포맷, 인벤토리 규칙처럼 입력과 출력이 분명한 기능에 적합하다. 예를 들어 "아이템이 20개를 넘으면 추가되지 않는다", "같은 아이템은 스택 수량이 증가한다" 같은 규칙은 자동 테스트로 만들기 좋다.

플레이 테스트는 조작감, UI 흐름, 카메라, 전투 감각, 튜토리얼 이해도처럼 사람이 경험해야 하는 부분에 필요하다. AI는 플레이 테스트 기록을 정리하고 패턴을 찾는 데 도움을 줄 수 있다.

플레이 테스트 기록은 다음처럼 남긴다.

플레이 테스트 기록

빌드/브랜치:
- inventory-fix-07

테스트한 기능:
- 아이템 획득
- 인벤토리 열기/닫기
- 슬롯 선택
- 저장 후 불러오기

발견한 문제:
1. 게임패드로 두 번째 줄 슬롯에 이동할 수 없음.
2. 아이템 이름이 길면 수량 텍스트와 겹침.
3. 저장 후 불러오면 선택 슬롯 표시가 사라짐.

AI에게 요청:
- 위 문제를 입력, 레이아웃, 저장 상태 문제로 분류해 줘.
- 각 문제의 최소 재현 절차를 작성해 줘.
- 다음 수정 브랜치에서 우선 처리할 순서를 제안해 줘.

이 방식은 버그 보고를 개인 기억에 의존하지 않게 만든다. 팀원은 같은 절차로 문제를 재현하고, AI는 정리된 기록을 바탕으로 누락된 테스트를 찾아낼 수 있다.

디버깅 루프를 팀의 표준 절차로 만들기

AI와 함께하는 디버깅은 즉흥 대화가 아니라 반복 가능한 루프가 되어야 한다.

• 재현한다.

• 증거를 모은다.

• AI에게 원인 후보와 확인 순서를 묻는다.

• 최소 범위로 수정한다.

• 같은 절차로 다시 검증한다.

• 관련 기능의 회귀 테스트를 실행한다.

• 변경 내역과 테스트 결과를 기록한다.

이 루프가 정착되면 AI는 단순한 코드 생성기가 아니라 품질 관리 보조 도구가 된다. 중요한 것은 AI가 더 많은 코드를 쓰게 하는 것이 아니다. 팀이 더 빨리 실패를 발견하고, 더 작은 범위에서 고치고, 같은 문제가 반복되지 않도록 기록을 남기는 것이다.

다음 단계에서는 이러한 디버깅과 테스트 기록을 개인 작업 방식에 머물게 하지 않고, 팀 협업 규칙과 AI 거버넌스로 확장해야 한다. 누가 AI에게 어떤 권한을 줄 수 있는지, 생성물과 수정 내역을 어떻게 승인할지, 프로젝트의 품질 기준을 어디에 기록할지가 실제 제작 속도와 안정성을 좌우한다.