Codex가 전체 x86 어셈블리 게임을 자율적으로 구축할 수 있을까?

대부분의 AI 코딩 시연은 코드 스니펫 생성, CRUD 애플리케이션 구축 또는 현대 프로그래밍 언어로 작은 프로젝트를 만드는 데 초점을 맞추고 있습니다.

저는 다른 것을 테스트하고 싶었습니다.

AI가 어셈블리 코드를 생성할 수 있는지 여부를 묻기보다는, 최소한의 인간 개입으로 전체 소프트웨어 프로젝트를 완료할 수 있는지 알고 싶었습니다.

실험을 가능한 한 어렵게 만들기 위해, 저는 가장 관대한 환경 중 하나를 의도적으로 선택했습니다:

• 16비트 x86 어셈블리
• DOS
• VGA Mode 13h
• 게임 엔진 없음
• 외부 그래픽 라이브러리 없음
• 오디오 라이브러리 없음

목표는 클래식 아스테로이드 스타일의 아케이드 게임을 재현하는 것이었습니다.

규칙이 하나 더 있었습니다: 저는 어셈블리 코드를 작성하지 않을 것이며, 사실 구현에 전혀 참여하지 않을 것입니다.

제 역할은 초기 목표를 정의하고, 전달된 모든 버전을 플레이하며, 발견한 모든 게임플레이 문제를 보고하는 것으로 제한되었습니다.

아키텍처 및 구현부터 디버깅, 문서화, 저장소 관리, 프로젝트 빌드 및 실행에 이르기까지 나머지 모든 것은 Codex가 자율적으로 처리했습니다.

이 글은 그 과정에서 일어난 일을 기록합니다.

규칙

실험을 시작하기 전에, 저는 프로젝트가 완료될 때까지 변경되지 않을 일련의 규칙을 설정했습니다.

목표는 단순히 아스테로이드 스타일의 게임을 만드는 것이 아니었습니다. 목표는 소프트웨어 엔지니어링 에이전트 역할을 하는 Codex가 얼마나 자율적일 수 있는지 평가하는 것이었습니다.

실험을 공정하게 유지하기 위해, 저는 의도적으로 저 자신의 개입을 제한했습니다.

저의 책임

• 프로젝트 목표 정의.
• 명확한 설명이 필요할 때 게임플레이에 대한 질문 답변.
• 완료된 모든 마일스톤 플레이 테스트.
• 게임플레이 버그 또는 예상치 못한 동작 보고.

Codex의 책임
나머지 모든 것.

여기에는 다음이 포함되었습니다:

• 프로젝트 기획 (Project planning)
• 소프트웨어 아키텍처 (Software architecture)
• 어셈블리 구현 (Assembly implementation)
• 리팩토링 (Refactoring)
• 디버깅 (Debugging)
• 문서화 (Documentation)
• Git 저장소 관리 (Git repository management)
• 프로젝트 빌드 (Building the project)
• 각 빌드 후 게임 실행 (Running the game after each build)
• 프로젝트 로드맵 유지 관리 (Maintaining the project roadmap)
• 완료된 마일스톤 검증 (Verifying completed milestones)

실험 내내 한 가지 규칙은 변하지 않았습니다:

저는 어셈블리 코드를 단 한 줄도 직접 작성하지 않았습니다.

사실, 개발 과정에서 프로젝트를 수동으로 구축하거나 게임을 실행한 적이 없습니다.

모든 빌드와 모든 실행은 Codex가 자율적으로 수행했습니다.

저의 역할은 마치 다른 엔지니어가 개발한 소프트웨어를 테스트하듯이 전달된 결과를 평가하는 것이었습니다.

현실 점검 (Reality Check)
Codex가 구현을 독립적으로 처리했음에도 불구하고, 이것은 '손대지 않는(hands-off)' 실험이 아니었습니다.

각 마일스톤마다 저는 게임을 플레이하고 예상치 못한 동작을 찾아내며 제대로 작동하지 않는 모든 것을 보고했습니다.

프로젝트 전체 동안 제가 보고한 것은 자동으로 감지되지 않은 두 가지 게임플레이 버그뿐이었습니다.

두 버그 모두 Codex에 의해 분석, 수정 및 검증된 후에 개발이 계속되었습니다.

원래 목표를 정의하고 각 마일스톤을 검증하는 것 외에는 구현 자체에 관여한 바가 없었습니다.

이러한 규칙을 세운 이유?

AI가 생성한 소프트웨어를 평가할 때 가장 큰 어려움 중 하나는 AI가 수행한 작업과 인간이 수행한 작업을 분리하는 것입니다.

많은 시연에서 AI가 애플리케이션을 구축했다고 주장하지만, 실제 개발자는 여전히 아키텍처 결정을 내리고, 생성된 코드를 편집하며, 컴파일 오류를 수정하고 최종 구현을 완료합니다.

저는 그러한 영향력을 가능한 한 많이 제거하고 싶었습니다.

목표는 Codex가 저를 도울 수 있는지 보는 것이 아니라, 제가 코드를 작성하지 않고 Codex가 얼마나 멀리까지 갈 수 있는지를 보는 것이었습니다.

개발 과정

규칙이 설정된 후, 저는 빈 GitHub 저장소를 만들고 프로젝트에 대해 설명했습니다.

그 시점부터 개발은 반복적인 프로세스가 되었습니다.

Codex는 작업을 계획하고, 마일스톤을 구현하며, 프로젝트를 구축하고, 실행하고, 결과를 검증한 다음, 변경 사항을 커밋하고, 저에게 테스트를 위해 프로젝트를 다시 넘겨주었습니다.

제 임무는 단순히 최신 버전을 플레이하고 하나의 질문에 답하는 것이었습니다:

예상대로 작동하는가?

문제가 발견되면, 저는 관찰한 바를 설명했습니다.

저는 수정 방법을 제안하거나 버그의 위치를 지목하지 않았습니다.

Codex는 보고서를 분석하고, 원인을 파악하여, 수정을 구현하고, 테스트를 위해 새로운 버전을 제시했습니다.

이 사이클은 다음 마일스톤까지 반복되었습니다.

시간이 흐르면서 프로젝트는 빈 저장소에서 구조화된 소스 코드, 문서화, 영구적인 최고 점수 기록 및 완전히 플레이 가능한 게임플레이 루프를 갖춘 완전한 DOS 게임으로 성장했습니다.

결과

실험이 끝날 무렵, Codex가 생산해낸 것은 다음과 같습니다:

• 어셈블리 소스 파일 18개
• 어셈블리 코드 약 2,500줄
• 완벽한 프로젝트 문서화
• 구조화된 커밋이 포함된 GitHub 저장소
• 영구적인 최고 점수 시스템
• 플레이 가능한 Asteroids 스타일 게임

개발 과정 동안:

• 인간 작성 어셈블리: 0줄
• 인간 빌드: 0회
• 인간 실행: 0회
• 보고된 게임플레이 버그: 2건
• Codex가 수정한 게임플레이 버그: 2건

저를 가장 놀라게 한 점은 단 하나였습니다.

Codex는 코드 생성기라기보다는 소프트웨어 엔지니어에 훨씬 더 가까운 방식으로 행동했습니다.

즉시 게임플레이 코드를 작성하는 대신, 프로젝트 계획을 세우고, 아키텍처를 문서화하며, 저장소를 정리하고, 다음 단계로 넘어가기 전에 각 완료된 마일스톤을 검증하는 데 시간을 보냈습니다.

요약

#	마일스톤	주요 결과	시작 주체	활동 시간	상태
0	아키텍처	플랫폼, 메모리 모델, 모듈, 로드맵	Codex	약 1분	✅
...