Mini-Loot: GPT 5.5 덕분에 살아나다

여기에서 Mini-Loot을 플레이할 수 있습니다.

걱정 마세요, 저는 Mini-Loot이 Antigravity의 실패라는 수렁 속에서 방치되도록 두지 않을 것입니다.

Antigravity에서 시도했던 여러 모델들에게 주었던 것과 정확히 동일한 프롬프트 (Prompt)를 사용하여, Codex의 GPT 5.5에게 Mini-Loot을 구축하라는 과제를 부여했습니다. 첫 번째 반복 (Iteration) 버전은 채 5분도 되지 않아 실행되었으며, 상당히 완성도가 높았습니다. 비록 GPT 5.5가 매 전투가 아닌 '한 번 건너매 전투마다' 상점이 나타나게 하는 대신, 모든 전투 후에 상점이 나타나도록 결정하긴 했지만 말입니다. 분명 제가 프롬프트에서 해당 부분을 표현한 방식이 매우 불분명했던 모양입니다.

Mini-Loot 프롬프트 (Prompt)

우리는 브라우저 기반의 턴제 (Turn-based) 오토배틀러 (Auto-battler) 게임을 만들 것입니다
...

심지어 그것은 ... 로고? 스플래시 화면 (Splash screen)? 캡슐 아트 (Capsule art)? ... 어쨌든 타이틀 화면 옆에 자리 잡고 있는 무언가를 만들어냈습니다:

그리고 전투 화면에는 플레이어의 캐릭터와 싸우고 있는 몬스터 (Monster)의 표현이 아마도 있어야 할 것이라고 직관적으로 파악했습니다. 톤 (Tone)을 정확하게 맞췄는지는 확신할 수 없지만, 5분이라는 시간과 단 하나의 프롬프트만으로 이 정도면 나쁘지 않습니다:

왜 우리가 여기서 모두 웃고 있는지 모르겠고, "B"가 "Cave Skitter" 몬스터와 어떻게 관련이 있는지도 모르겠지만, 적어도 이것들이 얼굴이라는 점은 분명하며 시각적인 흥미를 더하려는 시도 자체는 정말 높게 평가합니다.

자, 그렇다면: 왜 Codex의 GPT는 Antigravity에서 여러 모델이 그토록 고전했던 것과 달리, 이렇게 빠르고 쉽게 이 모든 것을 해낼 수 있었을까요?

제 생각에 가장 기본적이고 단순한 답변은, 두 IDE(통합 개발 환경) 사이에서 모델을 근본적으로 다른 방향으로 안내하는 시스템 프롬프트 (system prompts) 및 툴링 (tooling)의 차이 때문인 것 같습니다. 하지만 두 접근 방식의 차이점에는 주목할 만한 특별한 세부 사항이 있다고 생각합니다. 이는 AI 기반 프로젝트에 대한 접근 방식에 정보를 제공할 수 있고, 완전히 사람이 작성하는 프로젝트에 대해서도 좋은 상기 사항이 되기 때문입니다.

Codex에서 취한 접근 방식은 간단했습니다. 게임을 호스팅할 HTML 파일 하나, 게임을 실행할 단순한 JavaScript 파일 하나, 그리고 스타일을 제공할 클래식한 CSS 파일 하나, 이렇게 3개의 파일을 생성했습니다. 라이브러리를 사용하지 않았고, 컴파일 단계 (compilation steps)를 추가하지 않았으며, 사전에 특정한 구조를 강요하지도 않았습니다. 기술적으로는 HTTP 서버조차 필요하지 않았지만, 서버를 사용하기로 했을 때는 단순히 Python의 http.server를 실행했습니다.

반면 Antigravity는 작동하는 프로젝트가 생기기도 전에 수많은 도구를 모으고 방대한 구조를 구축했습니다. 콘텐츠 번들링 및 서빙을 위한 Vite, TypeScript와 TypeScript 컴파일러, DOM 관리를 위한 React, 그리고 린팅 (linting)을 위한 eslint 등이 포함되었습니다. Antigravity의 Gemini와 Claude는 약 12개의 소스 파일을 생성했으며, 선택한 도구들의 오버헤드 (overhead)로 인해 개발 워크스페이스 (development workspace)에는 약 5,700개의 파일이 존재하게 되었습니다 (물론 그중 상당수가 node_modules에 들어있지만, 어쨌든 그 안에 포함되어 있습니다).

오해는 마십시오. 이들은 모두 좋은 도구들이며, 장기적으로 이 프로젝트를 위한 잘못된 선택이었다고 생각하지도 않습니다. 하지만 이들은 엄청난 양의 초기 복잡성을 추가했습니다. Antigravity는 대문자 P로 시작하는 Project(프로젝트)를 계획하여 대문자 P로 시작하는 Production(프로덕션) 단계까지 갈 계획이었음이 분명해 보이지만, 수집한 모든 실타래를 하나의 기능적인 무언가로 엮어내는 데 결국 실패했습니다. 수많은 부품은 가지고 있었지만, 그것들을 이용해 제가 원하는 것을 어떻게 만들어야 하는지는 모르는 것처럼 보였습니다.

Codex는 이 과제를 훨씬 더 잘 이해했습니다. 즉, 제가 설명한 이 물건의 단순하고 작동 가능한 버전을 만드는 것이었습니다. 그리고 Codex는 반복 작업(iteration)을 수행하기에 아주 좋은 상태로 프로젝트를 남겨두었습니다. 그것이 작성한 단 하나의 JavaScript 파일은 길지만, 상당히 잘 조직되어 있어 프로젝트가 계속 성장하더라도 분해하기가 매우 수월할 것입니다 (전달해 주어야 할 state 객체가 있긴 하지만, 게임의 현재 상태를 객체로 조직화하는 영리함을 보여주었기에 이를 극복하는 데 큰 장벽은 없습니다).

이 경험을 통해 AI가 아닌(제 생각에는 "유기적인") 프로젝트에 적용할 수 있는 유용한 교훈은, 너무 많은 도구를 너무 빠르게 도입하려다 보면 일종의 "인지적 과부하 구석 (cognitive overload corner)"에 스스로를 몰아넣을 수 있다는 점입니다.

"인지적 과부하 구석"은 이상한 표현인데, 조금 설명해 보겠습니다.

그러한 도구들을 선택하는 데에는 시간과 생각, 그리고 에너지가 필요합니다. 그리고 그것들을 설치하고 설정하는 데에도 시간이 필요하죠. 또한 디렉토리 구조를 고안하고 컴포넌트(components), 훅(hooks), 스타일 규칙(style rules)을 위한 이름을 잘 붙인 파일들을 만들어내는 데에는 더 많은 시간과 생각, 그리고 에너지가 소모됩니다.

이 작업의 교활한 점은 이것이 엄연한 '작업'이라는 것입니다. 즉, 당신을 지치게 만들고, 무언가 생산적인 일을 했다는 느낌(정말로 무언가를 해냈다는 느낌)을 주지만, 그것이 정작 유용한 '무언가'는 아니라는 점입니다. 이제 당신에게는 존재하기는 하지만 서로 연결되어 아무것도 하지 못하는 수많은 조각들이 남게 됩니다. 이 조각들은 아직 측정 가능하고 실질적이며 상호작용이 가능한 무언가를 만들어내지 못하므로, 서로를 고정해 줄 장치도 없고 앞으로 어떻게 조직되어야 하는지를 명확히 해줄 도움도 없습니다. 무언가를 만들고 그에 맞춰 도구를 사용하는 대신, 당신은 '무언가'를 도구에 맞추어야 하는 우울한 상황에 빠지게 됩니다.

오해는 하지 마세요. 이것은 도구를 사용하지 말라는 호소가 아닙니다. 그저 (다른 누구보다 저 자신에게 하는 말이지만) 도구와 프레임워크를 천천히, 그리고 그것들이 실제 문제를 해결할 때 추가하는 것이 완벽하게 괜찮으며, 어쩌면 더 나은 방법일 수 있다는 점을 상기시키는 것입니다.

음, 이야기가 왠지 너무 철학적이고 설교조로 흘러간 것 같네요.

하지만 어쨌든, GPT 5.5 버전의 Mini-Loot GitHub 저장소는 여기 있습니다.

평소와 마찬가지로, 이 포스트 상단의 로고는 Leonardo.ai의 GPT Image 2를 사용하여 제작되었습니다.