03. 인터랙션 버그

여러 파일에 걸쳐 있는 복잡한 버그를 Kiro와 함께 단순한 핫픽스가 아니라, 의미 있는 리팩터링으로 해결하는 방법을 배웁니다.

이번 모듈에서 다루는 문제

플레이어가 상자나 아이템 같은 상호작용 가능한 오브젝트 옆에 서 있어도, 근처에 벽이 함께 있으면 E 키 안내 프롬프트가 사라지는 현상이 보고되었습니다. 즉 "가장 가까운 오브젝트"를 고르는 로직이 벽까지 후보로 잡고 있는 것이 원인입니다.

플레이어가 벽 근처에서 상자에 다가가도 E 프롬프트가 표시되지 않는 모습
벽이 가까이 있을 때 상호작용 프롬프트가 사라지는 버그 재현 모습.

1단계 — Kiro에게 증상 설명하기

먼저 게임을 직접 플레이해 보며 어떤 상황에서 문제가 재현되는지 한국어 또는 영어로 자연스럽게 정리합니다. 그런 다음 Kiro 채팅에 다음과 같은 프롬프트를 입력합니다.

Sometimes when the player is closer to the wall than to an interactive object like an item or the chest, then the interact prompt does not appear over the interactive object.

코드베이스를 직접 뒤지지 않아도 됩니다. Kiro가 관련 파일을 스스로 탐색해 원인 후보를 추려 줍니다.

2단계 — 첫 번째 제안을 비판적으로 검토

Kiro는 "가장 가까운 오브젝트"를 계산하는 함수가 벽을 걸러내지 않는다는 것을 찾아내고, game-object-system.ts 한 파일만 손봐서 mass 가 Infinity 인 오브젝트를 후보에서 제외하자고 제안할 수 있습니다.

Kiro가 단일 파일에서 mass=Infinity로 벽을 필터링하자고 제안하는 화면
Kiro의 첫 제안: 한 파일 안에서 mass가 Infinity인 오브젝트를 제외합니다.
주의. 동작은 하지만 좋은 해법은 아닙니다. mass는 본래 물리 시뮬레이션을 위한 값이지 "상호작용 가능한지" 를 나타내기 위한 값이 아닙니다. 나중에 mass가 유한한 장식용 오브젝트가 추가되거나, 반대로 무한 질량인데 상호작용 가능한 오브젝트가 생기는 순간 로직이 깨집니다.
팁. AI가 내놓은 첫 제안을 그대로 받아들이지 마세요. "이 코드의 API가 의미적으로 맞는가?", "한두 단계 뒤의 변화에도 견디는가?" 를 항상 머릿속에 두고 다시 질문하는 습관이 중요합니다.

3단계 — 더 넓은 범위로 리팩터링하기

본질적인 해결은 "이 오브젝트가 상호작용 가능한가" 를 코드가 직접 표현하도록 하는 것입니다. GameObject 타입에 새 속성 interactive 를 추가하고, 근접 판정 함수가 이 속성을 기준으로 필터링하도록 바꾸면 됩니다.

Kiro 입력창에서 # 키를 누르면 컨텍스트 피커가 열립니다. 타입, 클래스, 함수, 파일 등 코드 요소를 직접 지정할 수 있어서 LLM이 잘못된 곳을 건드릴 위험이 줄어듭니다. 다음 프롬프트를 활용하세요.

In #GameObject add a new required property `interactive`.
In #updatePlayerProximity filter out non interactive objects.
All calls to #addObject throughout the code need to set interactive to true or false.
  1. #GameObject 에 필수 속성 interactive: boolean 을 추가합니다.
  2. #updatePlayerProximity 가 interactive === true 인 오브젝트만 후보로 고려하도록 수정합니다.
  3. 코드 전반의 #addObject 호출부에서 각 오브젝트가 상호작용 가능한지 명시적으로 지정합니다.
  4. 변경 결과를 검토하고 게임을 실행해 벽 옆에서도 상자/아이템 위에 E 프롬프트가 정상적으로 뜨는지 확인합니다.
Kiro가 여러 파일에 걸쳐 22건의 변경을 제안한 화면
여러 파일에 걸친 22건의 변경. API에 의미가 부여되어 이후 기능 추가가 쉬워집니다.

이 모듈에서 얻어 갈 세 가지

  1. 한 단계 더 보기. LLM은 눈앞의 증상에만 답하는 경향이 있습니다. 제안된 코드를 머지하기 전에 "이 변경이 다음 기능 두세 개에도 안전한가" 를 스스로 점검하세요.
  2. 컨텍스트를 좁혀라. # 컨텍스트 피커로 함수, 타입, 파일을 직접 짚어 주면 결과 정확도가 크게 올라갑니다.
  3. 이름과 API에 의미를 담아라. mass 같은 무관한 속성에 의도를 끼워 넣지 말고, 새로운 의도가 생기면 새로운 속성을 만드는 편이 장기적으로 훨씬 깔끔합니다.