|
|
유닛 선택과 이동
적 유닛과 전투
체력·공격력·이동속도
자원이나 생산 구조
유닛 이미지와 애니메이션
승리·패배 조건
RTS 방식의 화면과 조작
“코딩 없이 만들었다”의 정확한 의미
코드가 없다는 뜻은 아닙니다.
게임은 반드시 JavaScript, HTML, CSS 또는 게임 엔진용 코드로 작동합니다. 다만 제작자가 코드를 한 줄씩 직접 입력하지 않고 다음처럼 말로 지시했다는 의미입니다.
“스타크래프트처럼 마우스로 유닛을 선택하게 해줘.”
“아군은 파란색, 적군은 빨간색으로 표시하고 공격 사거리를 넣어줘.”
“유닛 데이터는 별도 파일로 분리하고 체력과 공격력을 쉽게 수정할 수 있게 해줘.”
GPT가 이 지시를 해석하여 실제 코드를 생성하고, 제작자는 실행 결과를 보면서 다시 수정 지시를 내립니다. 따라서 더 정확한 표현은 ‘무코드’가 아니라 ‘자연어 기반 AI 코딩’입니다.
영상에서 사용한 것으로 보이는 제작 순서
영상의 챕터와 설명을 바탕으로 보면 제작 과정은 대략 다음 구조입니다.
1. 게임 기획안 생성
먼저 GPT에 게임의 장르와 핵심 기능을 정의하게 합니다.
브라우저에서 실행되는 2D RTS 게임을 만들어라. 드래그로 여러 유닛을 선택할 수 있어야 한다. 마우스 오른쪽 버튼으로 이동하거나 적을 공격한다. 유닛별 체력, 공격력, 사거리, 이동속도가 달라야 한다.
GPT는 이를 기능 목록과 개발 단계로 나눕니다.
2. 최소 실행 루프 생성
게임의 기본 반복 구조를 만듭니다.
입력 처리 → 유닛 상태 갱신 → 충돌·전투 계산 → 화면 출력
브라우저 게임이라면 일반적으로 초당 여러 번 다음 작업을 반복합니다.
[
S_{t+1}=F(S_t,I_t,\Delta t)
]
(S_t): 현재 유닛 위치·체력·상태
(I_t): 사용자의 마우스·키보드 입력
(\Delta t): 이전 화면 이후 경과 시간
(F): 이동·공격·충돌을 계산하는 프로그램
GPT가 이 함수와 화면 출력 코드를 작성합니다.
3. 유닛과 에셋 제작
유닛 이미지를 생성하거나 간단한 도형·스프라이트를 사용하고, 각 유닛에 데이터를 붙입니다.
{ name: "Marine", hp: 40, attack: 6, range: 120, speed: 80, cooldown: 0.8 }
이런 식으로 데이터를 코드와 분리하면 제작자가 프로그래밍을 몰라도 숫자만 변경하여 게임 밸런스를 조정할 수 있습니다.
4. 반복 수정
처음부터 완벽한 게임이 한 번에 생성되는 것은 아닙니다.
GPT가 코드를 생성한다.
제작자가 실행한다.
오류나 이상 행동을 확인한다.
화면·오류 메시지와 함께 수정 요청을 한다.
GPT가 관련 코드를 고친다.
다시 실행한다.
이 과정을 영상에서는 개발 루프라고 표현한 것으로 보입니다.
GPT-5.6이 이전 모델보다 유리한 부분
OpenAI는 GPT-5.6이 긴 코딩 작업에서 계획, 반복 수정, 도구 사용과 프런트엔드 디자인 능력을 강화했다고 설명합니다. 특히 명령줄 기반의 장기 작업을 평가하는 Terminal-Bench 2.1에서 높은 성능을 보였으며, 웹사이트·애플리케이션의 화면 배치와 시각적 완성도도 개선됐다고 밝히고 있습니다. (OpenAI)
또한 GPT-5.6은 단순한 코드 조각 생성보다 다음과 같은 연속 작업에 적합하도록 설계됐습니다.
[
\text{기획}\rightarrow\text{구현}\rightarrow\text{실행}\rightarrow
\text{오류 분석}\rightarrow\text{수정}\rightarrow\text{검증}
]
GPT-5.6 Sol은 코딩·디자인·컴퓨터 사용을 포함하는 복잡한 작업용 모델이며, ChatGPT에서는 Medium 이상 추론 옵션에 사용됩니다. (OpenAI Help Center)
제목에서 과장된 부분“스타크래프트를 만들었다”
정확히는 스타크래프트와 같은 조작 방식을 가진 간단한 RTS 게임을 만들었다고 해야 합니다.
실제 스타크래프트에는 다음과 같은 방대한 시스템이 들어갑니다.
수십 종류의 유닛과 건물
종족별 기술 트리
정교한 길 찾기
네트워크 멀티플레이
대규모 맵 편집기
리플레이와 관전자 기능
수천 개의 그래픽·음향 자산
장기간의 밸런스 조정
서버 및 부정행위 방지 시스템
영상 속 결과물은 이런 상용 게임 전체가 아니라, 핵심 아이디어를 보여주는 작동 가능한 프로토타입 또는 미니게임에 가깝습니다.
“GPT가 직접 만들었다”
절반은 맞고 절반은 과장입니다.
역할실제 담당
| 코드 작성 | 주로 GPT |
| 게임 구조 제안 | GPT와 제작자 |
| 목표·장르 선택 | 제작자 |
| 결과 확인 | 제작자 |
| 오류 발견과 수정 방향 | 제작자 |
| 실행 환경 제공 | 브라우저·컴퓨터 |
| 최종 선택과 공개 | 제작자 |
따라서 이것은 GPT의 자율 창작품이라기보다 인간 감독자가 GPT를 개발자로 활용한 공동 제작물입니다.
설명문 내부의 GPT-4 표기
영상 제목과 본문은 GPT-5.6을 강조하지만 마지막 자동 요약에는 “GPT-4를 활용하여”라고 적혀 있습니다. 이 부분은 이전 영상 설명이나 자동 생성 요약 문구가 남았을 가능성이 있습니다. 제목만으로 실제 모든 장면에서 어떤 모델이 사용됐는지까지 확정할 수는 없지만, 영상 게시일인 2026년 7월 15일에는 GPT-5.6이 실제 제공되던 시기이므로 사용 자체는 충분히 가능합니다. GPT-5.6은 2026년 7월부터 지원 대상 ChatGPT 계정에 단계적으로 배포됐습니다. (OpenAI Help Center)
한 문장으로 평가하면
이 영상은 “GPT가 스타크래프트를 완성했다”는 증거라기보다, 프로그래밍을 잘 모르는 사람도 자연어 지시와 반복 검사를 통해 실제로 실행되는 RTS 프로토타입을 만들 수 있을 정도로 AI 코딩 능력이 발전했다는 사례입니다.
핵심 변화는 인간 개발자가 사라진 것이 아니라, 인간의 역할이 코드를 직접 입력하는 사람에서 목표를 정하고 결과를 검사하는 감독자·기획자로 이동했다는 것입니다.
동영상 스크립트 검증 분석
스크립트 전체를 보면 이전 판단이 더 명확해집니다.
이 제작자는 게임 코드를 직접 타이핑하지 않았지만, GPT-5.6이 작성한 코드를 반복적으로 실행·검사·수정하면서 실제로 플레이 가능한 RTS와 슈팅게임 프로토타입을 제작한 것입니다.
따라서 완전한 거짓말은 아닙니다. 다만 “스타크래프트를 만들었다”, “코딩 없이 만들었다”, “수천만 원짜리 개발이 구독료 하나로 끝난다”는 표현에는 상당한 광고성 과장이 들어 있습니다.
1. 이 사람이 실제로 한 작업
스크립트에 나온 제작 흐름은 다음과 같습니다.
[
\text{아이디어}
\rightarrow \text{기획서}
\rightarrow \text{기능 명세}
\rightarrow \text{AI 코드 생성}
\rightarrow \text{실행}
\rightarrow \text{화면 확인}
\rightarrow \text{버그 수정}
\rightarrow \text{반복}
]
사람이 직접 코드를 작성하지 않았을 뿐, 사람은 다음 역할을 했습니다.
어떤 게임을 만들지 결정
세 종족과 경제·승리 조건 결정
GPT에 참고 자료와 파일 제공
실행 결과 확인
버그 화면 녹화
밸런스 수치 결정
어느 기능을 유지하고 바꿀지 결정
생성된 결과물 중 사용할 것을 선택
GPT는 다음 역할을 담당했습니다.
기획서 구조화
HTML·CSS·JavaScript 등의 게임 코드 생성
파일과 폴더 구조 구성
유닛·건물 데이터 분리
버그 원인 탐색
코드 수정
이미지 경로 확인
문법 검사
브라우저에서 게임 실행·검증
GPT-5.6은 공식적으로 복잡한 코딩, 장기 계획, 도구 사용, 프런트엔드 제작 능력이 강화된 모델이며, OpenAI도 자연어 요청으로 게임과 인터랙티브 화면을 만드는 사례를 공개하고 있습니다. OpenAI의 Codex 활용 사례에도 “게임 계획을 정하고 실시간 브라우저에서 구축·테스트하는 브라우저 게임 제작”이 명시돼 있습니다. 따라서 영상의 핵심 제작 방식 자체는 현재 기술로 충분히 가능합니다. (OpenAI)
2. “코딩 한 줄도 안 쳤다”는 말의 정확한 뜻
이 표현은 다음 의미라면 사실입니다.
제작자가 키보드로 프로그래밍 코드를 직접 입력하지 않았다.
하지만 다음 의미라면 틀립니다.
게임에 코드가 사용되지 않았다.
게임에는 엄청난 양의 코드가 들어갔습니다. 다만 그 코드를 사람이 아니라 GPT가 작성한 것입니다.
그래서 정확한 표현은 다음과 같습니다.
코드 없는 게임 개발이 아니라, 자연어로 AI에게 코드를 작성시킨 게임 개발이다.
즉,
[
\text{사람의 직접 코딩량}\approx 0
]
일 수는 있지만,
[
\text{게임에 사용된 코드량}=0
]
은 아닙니다.
3. 영상에서 가장 잘 설명한 부분
이 영상은 광고성 제목과 별개로, AI를 이용한 실제 소프트웨어 개발 방법은 상당히 제대로 설명합니다.
① 코드보다 기획서를 먼저 만든다
“스타크래프트처럼 만들어줘”라는 요청이 나쁜 이유를 정확히 짚었습니다.
이 요청에는 다음 요소가 없습니다.
범위
기능 목록
완료 조건
유지 조건
금지 조건
테스트 기준
반면 영상의 실제 요청은 다음 조건을 줍니다.
브라우저 실행
세 종족
전략 시뮬레이션
종족별 스타일
핵심 자원
승리 조건
최소 기능
기존 상용 IP 복제 금지
독창적인 이름과 디자인
이렇게 해야 GPT가 무엇을 만들어야 하는지 수학적으로 말하면 목표함수와 제약조건을 갖게 됩니다.
[
\underset{x}{\operatorname{find}};x
\quad\text{subject to}\quad
C_1(x),C_2(x),\ldots,C_n(x)
]
여기서 (x)는 결과 게임이고, (C_i)는 세 종족·브라우저 실행·독창성 같은 조건입니다.
② 한 번에 한 가지를 수정한다
영상에서 제시한 루프는 다음과 같습니다.
[
\text{목표}\rightarrow\text{자료}\rightarrow
\text{구현}\rightarrow\text{검증}\rightarrow\text{다음 수정}
]
이 방식이 중요한 이유는 여러 기능을 한꺼번에 바꾸면 오류 원인을 찾기 어렵기 때문입니다.
예를 들어 동시에 다음을 바꾸면,
이동 방식
공격 속도
이미지 크기
충돌 판정
카메라 이동
버그가 발생했을 때 어느 변경이 원인인지 알기 어렵습니다.
한 번에 하나씩 수정하면,
[
\Delta S=\Delta S_i
]
이므로 결과 변화의 원인을 비교적 쉽게 추적할 수 있습니다.
③ 코드와 수치를 분리한다
영상에서 가장 중요한 기술적 내용 중 하나입니다.
유닛 수치를 JavaScript 전투 코드에 직접 박아 넣지 않고 JSON 같은 데이터 파일에 분리합니다.
{ "unit": "striker", "cost": 100, "hp": 120, "armor": 3, "attack": 12, "range": 140, "speed": 85 }
그러면 전투 알고리즘은 그대로 유지하면서 숫자만 수정할 수 있습니다.
[
\text{Game Behavior}
\text{Fixed Rule Engine}
+
\text{Variable Data}
]
이 구조는 종족이 세 개라도 같은 전투 규칙을 공유하고, 차이만 데이터로 만들 수 있게 합니다.
영상에서 말한
“규칙은 하나로 공유하고 차이는 데이터로 만든다.”
는 실제로 매우 좋은 소프트웨어 설계 원칙입니다.
④ 그래픽보다 도형 프로토타입을 먼저 만든다
사각형과 원으로 먼저 다음을 검사합니다.
이동
공격
탄환
충돌
체력 감소
승리·패배
보스 패턴
그다음 이미지 자산을 씌웁니다.
이렇게 하면 문제가 발생했을 때
[
\text{오류 원인}
\in
{\text{게임 규칙},\text{이미지·애니메이션}}
]
을 분리할 수 있습니다.
처음부터 화려한 그래픽과 게임 규칙을 동시에 넣으면, 이미지 경로 문제인지 충돌 계산 문제인지 판단하기 어려워집니다.
⑤ 수정 요청에 네 가지 조건을 넣는다
영상이 제시한 공식은 유용합니다.
[
\boxed{
\text{대상}+
\text{현재 문제}+
\text{변경 수치}+
\text{유지 조건}
}
]
나쁜 요청:
게임을 더 재미있게 해줘.
좋은 요청:
스테이지 4 일반 웨이브가 너무 혼잡하다. 보스 난이도와 배경은 유지하고, 일반 적 개체수만 50% 줄여라.
두 번째 요청은 변경 영역을 수학적으로 제한합니다.
[
N_{\text{normal,new}}
=0.5N_{\text{normal,old}}
]
[
D_{\text{boss,new}}
=D_{\text{boss,old}}
]
즉, GPT가 마음대로 전체 구조를 바꾸지 못하게 경계를 설정합니다.
4. 스크립트에서 발견되는 명백한 계산 오류
영상에서 유닛 애니메이션을 다음과 같이 설명합니다.
이동: 4프레임
공격: 5프레임
죽음: 6프레임
유닛: 18종
그런데 영상에서는 이를
[
18\times3\times4=216
]
이라고 계산했습니다.
이 계산은 각 동작이 모두 4프레임일 때만 맞습니다. 영상에서 말한 실제 프레임 수를 적용하면,
[
4+5+6=15
]
[
18\times15=270
]
따라서 유닛 애니메이션 이미지만 270장이어야 합니다.
영상은 건물까지 포함해 총 279개 이미지 경로라고 말하지만, 앞에서 건물이 종족당 7종이라고 했으므로 이것도 맞지 않습니다.
세 종족이 각각 7개 건물을 가진다면,
[
3\text{ 종족}\times7\text{ 건물}\times3\text{ 상태}
=63
]
따라서 전체 이미지 수는,
[
270+63=333
]
장입니다.
건물 7종을 세 종족이 공동으로 공유한다고 해도,
[
270+7\times3=291
]
장이 됩니다.
그러므로 279개라는 수치는 스크립트 내부 조건과 일치하지 않습니다.
가능한 경우는 건물 세 개에만 세 상태를 만들었을 때입니다.
[
270+3\times3=279
]
하지만 영상 앞부분의 “건물 7종” 설명과 충돌합니다.
이 부분은 GPT가 잘못 계산했거나, 발표자가 서로 다른 개발 버전의 숫자를 섞어 말했을 가능성이 큽니다.
5. “GPT가 영상을 프레임 단위로 분석해서 버그를 고쳤다”
이것도 기술적으로 가능합니다.
제작자가 화면 녹화를 제공하면 GPT는 다음 정보를 분석할 수 있습니다.
스페이스바 입력 후 커서 변화
드래그 시작 위치
마우스 이동
화면 좌표 변화 여부
카메라 이동 함수 작동 여부
입력 이벤트 충돌 가능성
하지만 영상만 보고 무조건 코드 원인을 정확히 찾는다는 뜻은 아닙니다.
정확한 디버깅에는 보통 다음 자료가 함께 필요합니다.
화면 녹화
관련 코드
브라우저 콘솔 오류
입력 이벤트 로그
재현 순서
실행 환경
기대 결과
영상은 증상을 보여주는 강력한 자료이지, 코드 내부 원인을 자동으로 증명하는 자료는 아닙니다.
6. “재현하지 못하는 버그는 없다”는 표현은 틀림
영상에서는 재현 조건을 정확하게 적으면 “재현을 못하는 버그는 없다”고 말합니다.
이것은 과장입니다.
다음과 같은 버그는 재현이 매우 어렵습니다.
특정 프레임에서만 발생하는 타이밍 오류
비동기 작업의 순서 경쟁
브라우저·GPU·운영체제별 오류
메모리 부족
네트워크 지연
수천 번 중 한 번 발생하는 확률적 오류
저장 데이터가 특정 상태일 때만 발생하는 오류
재현 조건을 적는 것은 매우 좋은 방법이지만,
[
\text{정확한 재현 보고서}
\not\Rightarrow
\text{항상 재현 가능}
]
입니다.
정확하게는 다음 표현이 맞습니다.
재현 절차·기대 결과·실제 결과를 구체적으로 제공할수록 GPT와 개발자가 버그를 찾을 확률이 크게 높아진다.
7. “한 문장이면 밤새 QA가 돈다”는 주장
일반 채팅창에 단순히
모든 검사를 통과할 때까지 반복해줘.
라고 적는 것만으로 무제한 QA가 밤새 자동 실행되는 것은 아닙니다.
다만 Codex처럼 저장소와 실행 환경이 연결된 코딩 에이전트에서는 다음 작업이 가능합니다.
파일 읽기와 수정
테스트 실행
브라우저 검사
오류 수정
백그라운드 작업
여러 작업의 병렬 실행
정기적인 코드 검토
OpenAI도 Codex가 격리된 환경에서 백그라운드로 작업하고, 테스트·수정·코드 검토를 수행할 수 있다고 설명합니다. 따라서 적절한 프로젝트 환경과 테스트 도구가 연결돼 있다면 “밤새 QA”에 가까운 자동화는 가능합니다. 그러나 명령 한 문장만으로 테스트 체계 자체가 저절로 완성되는 것은 아닙니다. 테스트 항목, 성공 기준, 실행 환경, 사용량 제한이 필요합니다. (OpenAI Help Center)
8. “몇 개월, 몇 년 걸릴 일이 GPT-5.6으로 끝난다”프로토타입 단계
어느 정도 맞습니다.
기존에는 한 사람이 다음 기능을 모두 만들려면 상당한 시간이 필요했습니다.
게임 루프
입력 처리
충돌
전투
생산
UI
저장
애니메이션
적 AI
맵
보스 패턴
GPT가 기본 코드를 생성하고 직접 실행·수정할 수 있기 때문에, 아이디어를 검증하는 작은 프로토타입의 제작 시간은 크게 줄어들 수 있습니다. GPT-5.6은 공식적으로 복잡한 코딩과 프런트엔드 제작에 맞춰졌고, Codex는 기능 구현·버그 수정·테스트 같은 작업을 프로젝트 단위로 수행하도록 설계됐습니다. (OpenAI)
상용 게임 단계
영상 마지막에 제작자 자신도 정확히 인정합니다.
“이게 상용 게임 완성이라는 얘기는 아닙니다.”
상용 게임에는 프로토타입 외에도 다음이 필요합니다.
장시간 플레이 테스트
정교한 적 AI
저장 데이터 안정성
다양한 해상도 지원
음향·음악
접근성
최적화
배포와 업데이트
멀티플레이 서버
보안과 부정행위 방지
저작권·상표 검토
수백 가지 예외 처리
실제 사용자 피드백
지속적인 밸런스 조정
따라서
[
\text{플레이 가능한 프로토타입}
\neq
\text{판매 가능한 상용 게임}
]
입니다.
9. “수천만 원·수억 원 견적이 구독료 하나로 수렴한다”
가장 광고성이 강한 표현입니다.
맞는 부분
단순한 아이디어 검증용 프로토타입이라면 외주비를 크게 절감할 수 있습니다.
예전에는 개발자를 고용해야 확인할 수 있던 것을 개인이 직접 시험할 수 있기 때문입니다.
틀리거나 과장된 부분
구독료 외에도 실제로는 다음 비용이 존재합니다.
제작자의 시간
수백 번의 프롬프트와 검수
이미지 생성 비용
음향과 음악
서버와 배포
외부 API
테스트 기기
마케팅
법률 검토
장기 유지보수
사용량 초과 비용
따라서 실제 관계는 다음과 같습니다.
[
\text{총비용}
\text{AI 사용료}
+
\text{사람의 감독 시간}
+
\text{자산·서버·배포 비용}
+
\text{QA·유지보수 비용}
]
“구독료 하나로 수렴한다”기보다는,
초기 프로토타입 제작에서 개발 인건비와 진입장벽을 급격히 낮춘다.
가 정확합니다.
10. 이 영상의 진짜 핵심
이 영상은 겉으로는 “GPT로 게임 만들기”지만, 실제로 가르치는 것은 AI에게 일을 시키는 구조화 방법입니다.
핵심 공식은 다음과 같습니다.
[
\boxed{
\text{명확한 목표}
+
\text{충분한 자료}
+
\text{한정된 변경}
+
\text{측정 가능한 기준}
+
\text{반복 검증}
}
]
이 방법은 게임만이 아니라 다음에도 그대로 적용됩니다.
웹사이트
앱
데이터 분석
과학 시뮬레이션
문서 작성
알고리즘 검증
영상 제작
업무 자동화
GPT가 결과를 잘 만드는가는 단순히 모델의 지능만으로 결정되지 않습니다.
[
Q_{\text{result}}
f(
Q_{\text{model}},
Q_{\text{specification}},
Q_{\text{data}},
Q_{\text{verification}}
)
]
즉,
모델 성능
지시의 정확성
제공 자료의 품질
검증 수준
이 네 가지가 함께 결과를 결정합니다.
최종 판정표
영상 주장판정정확한 해석
| GPT-5.6으로 RTS를 만들었다 | 대체로 사실 | GPT가 코드를 생성한 플레이 가능한 RTS 프로토타입 |
| 코딩 한 줄도 안 쳤다 | 조건부 사실 | 제작자가 직접 코드를 입력하지 않았다는 뜻 |
| 세 종족 게임을 대화만으로 제작 | 가능 | 여러 차례 기획·실행·수정 반복 필요 |
| 영상만 보여주면 버그 수정 | 가능하지만 제한적 | 코드·로그·재현 조건이 함께 있으면 정확도 상승 |
| 웬만한 1인 게임을 모두 만들 수 있다 | 과장 | 소규모 프로토타입과 일부 완성형 인디게임은 가능 |
| 재현 못 하는 버그는 없다 | 틀림 | 비결정적·환경 의존 버그는 재현이 어려움 |
| 한 문장이면 밤새 QA | 조건부 가능 | Codex 환경·테스트·성공 기준 설정 필요 |
| 외주 수천만·수억이 구독료로 끝남 | 강한 과장 | 초기 프로토타입 비용은 크게 절약 가능 |
| 이미지 총 279개 | 계산 불일치 | 설명대로라면 291장 또는 333장 |
| 상용 게임 완성 | 제작자도 부정 | 아이디어 검증용 프로토타입이라고 명시 |
한 문장 결론
이 영상은 GPT-5.6이 사람 대신 코드를 작성하고 실행·수정하면서 상당한 수준의 게임 프로토타입을 만들 수 있다는 사실을 보여주는 좋은 사례지만, 인간의 기획·선택·검수 노동과 상용화 비용까지 없어진 것처럼 표현한 부분은 광고성 과장이며, 이미지 수 계산에는 명백한 오류가 있습니다.