게임 클라이언트용 SDK 만드느라 SDK 테스트에 사용할 견본 게임을 만드는데, Codex(gpt-5.3 high)든 Claude Code(opus 4.6)든 일 잘 못하긴 마찬가지구나.

특히 이미 2D 애셋이 있어서 애셋에 맞춰 구현하는 경우에, "눈"과 "미감"이 없다는 점이 치명적으로 약점으로 작용한다. 드로우콜을 줄이려는 최적화 기법, 가령 스프라이트 아틀라스는 AI 코딩 에이전트에게 악몽이다. 어느 정도로 악몽이냐면,

Claude Code는 포기했는지 집요하게 애셋을 쓰라고 지시하는데도 계속 회피하고 거짓말로 외면하며 애셋을 안 쓰고 지 멋대로 벡터 이미지를 그린다. 기존 애셋을 분석해서 네가 작업하기 좋게 재구성하라고 했더니 눈가리고 아웅식으로 구성하는 척하고선 실제로는 사용을 안 했다. 거짓말하는 솜씨가 가히 Gemini급이다.

Codex는 쬐.끔. 나은데, 기존 아틀라스를 분석하여 꽤 유의미하게 애셋을 구성했다. 그 와중에 많은 애니메이션이 유실되거나 정체를 파악 못한 애셋은 무시하거나 사용하지도 않으면서 복사하긴 했지만.

캐릭터 관절로 스프라이프가 구성된 경우, 부위별 애니메이션은 포기하는 게 낫다. 이 작업에서 Codex는 재밌는 모습을 보였는데, 각 부위 위치를 잡고 충돌 처리를 파악하기 위해 부위에 박스를 그렸다는 점이다. 다시말해 숫자와 공식으로 처리하는 게 아니라 사람이 눈으로 보며 캐릭터 부위를 파악해 위치를 조정하는 것처럼 작업했다는 것이다. 비유가 아니라 실제로 그렇게 출력하고 화면 캡쳐하며 아틀라스에 있는 메타데이터의 숫자 의미를 파악하려고 했다. 흥미로웠다. 흥미롭긴 했는데 결과물은 역시 별로였다.

애셋이 대부분 상대 크기에 가깝다보니 실제 화면에 그려지는 오브젝트 크기를 AI 코딩 에이전트는 감을 잡지 못하는데, 사람이 편의상 스프라이트에 여백을 준 경우 이미지가 계속 엉뚱한 위치에 그려졌고, AI 코딩 에이전트는 원인도 모른 채 계속 크기와 위치를 산술 계산으로 잡으려 애썼다. 그러니까 오른쪽으로 조금 옮겨봐, 라고 하면 50px을 더하는 게 아니라 오른쪽으로 옮길 오브젝트의 실제 크기와 비율 조정한 크기 계산을 하고, 현재 화면의 크기와 대상 오브젝트 간 거리를 계산해서 위치를 조정하는 건데, 스프라이트 자체에 여백이 들어가있어서 AI 에이전트의 계산은 애초에 맞을 수가 없는 것이다.

Claude Code는 진작 포기해서 거짓말로 일관했고, Codex는 오브젝트 위치 조정하는 데 20분씩 써가며 고군분투하더라.

시차 스크롤링 (Parallax scrolling)도 AI 코딩 에이전트가 애셋만으로는 감조차 잡지 못해서 몹시 헤맸는데, 통으로 된 배경 스프라이트 몇 장이면 간단히 구현한다. 문제는 풍성한 미감을 주면서도 최적화를 위해 배경 오브젝트 요소가 다양하게 구성된 경우인데, 무엇이 산이고, 무엇이 바위이며, 무엇이 화면 맨 앞에(카메라쪽) 배치되는 나무인지 모르니 엉망진창으로 배치한다. 결국 Claude Code에겐 시차 스크롤링을 최소화하게 지시해서 캐릭터가 배경에 파묻히는 문제를 해결했고, Codex는 2시간 걸리고 애셋을 과도하게 늘리거나 해서 지저분해지긴 했지만 결국 애셋 의도에 거의 비슷하게 시차 스크롤링을 구성했다.

그나마 HTML 5 기반 웹 2D 게임인 경우 Playwright로 캡쳐하며 이것 저것 시도하는데, 유니티로 구현하니 카메라 위치 잡는 데에도 한참 걸렸다.

출근하면 회사 내 게임 클라이언트 개발자 옆에 앉아서 AI 코딩 에이전트를 어떻게 활용하는지 관찰 좀 해봐야겠다.