타일 에디터 저장 버그 — 삭제한 타일이 부활하는 미스터리와 AI의 이해력 한계
들어가며
게임 개발에서 "저장"이라는 기능은 너무나 기본적입니다. 에디터에서 뭔가를 삭제하고, 저장 버튼을 누르면, 삭제된 상태가 유지되어야 합니다. 당연한 거죠. 그런데 이 당연한 것이 안 될 때, 그리고 AI가 이 "당연한 문제"를 이해하지 못할 때, 개발자의 혈압은 어디까지 올라갈 수 있을까요?
이 글은 Bad North 스타일의 3D 전술 배틀 로그라이크 게임 myDGC를 Claude Code와 함께 개발하면서 겪은 하루짜리 삽질기입니다. 타일 에디터 저장 버그부터 전투 시스템의 온갖 엣지 케이스까지, AI와 함께한 기나긴 디버깅 여정을 기록합니다.
프로젝트 배경
myDGC는 Babylon.js 7.36 기반의 3D 전술 게임입니다. 맵 에디터, 액션 에디터, 그리고 게임 본체까지 갖춘 꽤 큰 프로젝트죠. 코드량만 약 96,000줄. 이 정도 규모의 프로젝트를 AI와 함께 작업하다 보면, 컨텍스트 관리 자체가 하나의 도전이 됩니다.
서버가 떴습니다. 브라우저에서 확인하세요:
세 개의 에디터와 게임 클라이언트. 각각이 복잡한 상태 관리를 하고 있고, 이 중 맵 에디터에서 문제가 터졌습니다.
문제의 시작: 삭제한 타일이 부활한다
맵 에디터에서 타일을 삭제합니다. 화면에서 사라집니다. 잘 됐습니다. 저장 버튼을 누릅니다. 다시 열어봅니다. 삭제한 타일이 멀쩡하게 살아있습니다.
처음엔 단순한 저장 로직 버그라고 생각했습니다. 그래서 AI에게 문제를 설명했죠. 그런데 AI는 계속 엉뚱한 곳을 파고들었습니다. "에디터에서 삭제가 안 되는 건가요?" "렌더링 문제인가요?"
"야 제거는 에디터에서 되는거야. 되는데, 저장이 제대로 안되는거라고. 이해 못하니?"
이 한마디에 그날의 감정이 다 담겨있습니다. AI가 문제의 본질을 파악하지 못하고 에디터의 삭제 기능 자체를 의심하는 상황. 화면에서 분명히 지워졌는데, AI는 자꾸 "삭제 로직을 확인해보겠습니다"를 반복했습니다.
문제는 에디터의 인메모리 상태와 직렬화(저장) 로직 사이의 괴리였습니다. 에디터는 타일을 삭제할 때 화면에서 메시를 제거하고 내부 배열에서도 빼지만, 저장 시 원본 맵 데이터에서 해당 타일 정보를 제거하지 않고 있었던 겁니다. 즉, 에디터는 "뷰"만 업데이트하고 "모델"은 그대로 둔 채 저장하고 있었던 거죠.
컨텍스트의 한계: 20MB 세션이 잘리다
이 버그를 잡는 과정에서 또 다른 문제가 발생했습니다. 96,000줄짜리 프로젝트를 탐색하면서 Claude Code의 Context Compaction이 발동한 겁니다. 대화 내용이 20MB를 초과하면서 이전 컨텍스트가 잘려나갔고, AI는 앞서 설명한 문제 상황을 잊어버렸습니다. 같은 설명을 반복해야 하는 상황.
이건 AI 페어 프로그래밍의 구조적 한계입니다. 대규모 코드베이스에서 복잡한 버그를 추적할 때, AI의 컨텍스트 윈도우는 우리가 생각하는 것보다 빨리 소진됩니다.
교훈과 핵심 정리
1. AI에게 문제를 설명할 때는 "현상"과 "기대 동작"을 명확히 분리하라
"저장이 안 돼"보다 "에디터에서 삭제는 화면에 반영되지만, 저장 후 다시 열면 삭제 전 상태로 돌아간다"가 훨씬 효과적입니다. AI는 맥락을 추론하는 데 한계가 있으므로, 현상을 정확하게 기술하는 것이 시간을 아껴줍니다.
2. AI의 데이터 분석을 맹신하지 마라
높이 데이터 오판 사례처럼, AI는 데이터의 일부만 보고 전체를 일반화하는 경향이 있습니다. 특히 대용량 데이터에서 패턴을 파악할 때는 AI의 결론을 반드시 검증해야 합니다.
3. Context Compaction을 고려한 작업 단위를 설계하라
96,000줄 코드베이스에서 여러 시스템에 걸친 버그를 한 세션에 잡으려 하면 컨텍스트가 넘칩니다. 버그 하나당 하나의 세션, 명확한 스코프 설정이 중요합니다.
4. AI에게 미봉책 대신 근본 해결을 요구하라
경로 렌더링 문제에서 Y 오프셋 → renderingGroupId → 깊이 버퍼 클리어로 세 단계를 거친 것은 비효율적이었습니다. 처음부터 "3D 렌더링에서 오브젝트가 지형에 묻히는 근본 원인이 뭐야?"라고 물었다면 한 번에 갈 수 있었을 겁니다.
5. AI와의 작업에서도 "작업 전 설계 설명" 원칙은 유효하다
이 세션 중에 사용자가 요청한 것이기도 합니다. AI가 코드를 바로 수정하기 전에, 수정 로직을 먼저 설명하고 합의하는 과정이 결국 재작업을 줄여줍니다.
마치며
하루 동안 타일 에디터 저장 버그 하나에서 시작해 전투 시스템 전체를 손보게 된 이 경험은, AI 페어 프로그래밍의 현실을 잘 보여줍니다. AI는 강력한 도구이지만, 문제를 이해하는 것은 여전히 인간 개발자의 몫입니다. AI가 이해하지 못할 때 답답하고 화가 나지만, 그 과정에서 우리 스스로가 문제를 더 명확하게 정의하게 되는 역설도 있습니다.
결국 프로그래밍은 — AI와 함께하든 혼자 하든 — **"정확하게 문제를 정의하는 능력"**이 핵심입니다. AI가 이해 못 하는 건 AI의 한계가 아니라, 아직 우리가 문제를 충분히 명확하게 전달하지 못했다는 신호일 수도 있으니까요. 물론, 가끔은 진짜로 AI가 못 알아듣는 거긴 합니다.