GPT-6 Astra는 어디까지 만들었나: 3D 게임·Blender·PCB 사용 사례

GPT-6 Astra로 만든 결과물을 처음 보면 3D 생성 모델의 발전부터 떠올리기 쉽다. 자동차 부품이 차체 밖으로 펼쳐지고, 인체의 근육과 뼈를 따로 선택하며, 게임 속 도시의 낮과 밤이 버튼 하나로 바뀐다. 그러나 이 장면들을 모두 “Astra가 3D 모델을 만들었다”라고 묶으면 Astra가 실제로 맡은 작업을 정확히 설명할 수 없다.

어떤 프로젝트는 기존 모델에 검색과 분해 기능을 붙였다. 어떤 프로젝트는 Blender에서 형상과 재질을 만들었다. 또 다른 프로젝트는 게임 엔진을 실행하고 화면과 내부 상태를 함께 검사했다. GPT-6 Astra의 강점은 하나의 생성 기능이 아니라, 필요한 프로그램을 골라 쓰고 결과를 본 다음 오류를 수정하는 작업을 여러 단계에 걸쳐 이어가는 데 있다.

놀라운 장면보다 작업 방식이 달라졌다

브라우저에서 움직이는 3D 도시를 만든다고 가정해보자. 건물 모델만 있다고 끝나지 않는다. 낮을 밤으로 바꾸면 하늘뿐 아니라 주변 조명과 창문 불빛도 함께 바뀌어야 한다. 숲에서는 잎에 닿는 빛과 그림자가 깊이를 만들어야 한다. 버튼을 누르면 장면의 상태가 바뀌고, 다른 장소로 이동해도 카메라와 조작이 계속 작동해야 한다.

영상에 나온 사례에서 Astra는 이런 동작을 Three.js 코드로 작성했다. Apple Park 재구성에는 Blender가 쓰였다. 은하 충돌 장면은 약 2만2,000개 입자를 계산 규칙에 따라 움직였다. 하나의 채팅창에서 이미지를 뽑는 것과 달리, 코드·렌더러·3D 제작 프로그램을 연결해 실제로 조작할 수 있는 결과물을 만들었다.

Astra의 수정 능력은 첫 결과에 오류가 생겼을 때 확인됐다. 건축물의 싱크대 표면이 울퉁불퉁하게 보이자 표면 방향 정보를 수정하고 가장자리를 다듬었다. 코드는 정상 실행됐지만 렌더 결과는 틀렸기 때문이다. 화면에서는 캐릭터의 발이 바닥에 닿아 보여도 내부 좌표상으로는 공중에 떠 있을 수 있어, 화면과 위치 데이터를 함께 반복 검사했다.

같은 3D 결과처럼 보여도 Astra가 맡은 일은 다르다

인체 해부 장면에는 기존 해부학 데이터인 BodyParts3D가 사용됐다. 자동차에도 기존 차량 모델이 들어갔다. Astra가 한 일은 부위 검색, 선택, 주변 요소 숨기기, 조각 펼치기와 원래 위치로 되돌리기 같은 상호작용을 구현하는 것이었다. 화면에 표시된 2,234개는 프로그램이 다루는 형상 조각 수이지 Astra가 새로 만든 근육과 뼈의 수가 아니다.

반면 열차는 반복되는 창문과 차체 형상을 코드 규칙으로 배치했다. V8 엔진은 축의 회전에 맞춰 피스톤이 오르내리도록 구현했다. 같은 3D 화면이어도 기존 자산에 기능을 붙이는 일과 형상·동작을 절차적으로 만드는 일은 난도가 다르다.

포스트 아포칼립스 게임 장면도 기존 자료를 얼마나 활용했는지 구분해서 봐야 한다. 제작자는 Godot와 Blender MCP를 사용해 반나절 만에 직접 조작할 수 있는 장면을 만들었다고 밝혔다. 제작자는 세계관 설명과 텍스처·모델 참고 링크를 함께 제공했다. 아무 정보 없이 세계 전체가 한 번에 생성된 것이 아니라, 참고 자료와 제작 도구를 연결해 여러 자산을 만든 사례다.

AGI Soon은 UI보다 자동 검증부터 만들었다

Reddit에 공개된 AGI Soon은 GPT-6 Astra와 Blender MCP의 3D 능력을 시험하려다 1.5일 만에 전체 게임으로 커진 프로젝트다. 제작자는 직접 만든 자산이 하나도 없다고 밝혔다. 제작에 사용된 Codex는 생성된 콘셉트 이미지를 바탕으로 Blender에서 로우폴리 모델을 만들고 GLB로 내보냈다. 효과음 일부는 외부 모델로 만들고, 일부는 코드로 합성했다.

이 프로젝트에서 더 눈에 띄는 것은 제작 순서다. 제작에 사용된 Codex는 UI보다 먼저 결과를 똑같이 재현할 수 있는 헤드리스 시뮬레이션을 만들었다. 봇이 수천 번 게임을 실행했고, 문제가 생기면 이전 실행을 재생해 결과 차이를 비교할 수 있었다. 게임을 제작한 Codex 에이전트가 게임 안의 에이전트 순위 1위에 오르기도 했다.

빠른 제작이 가능했던 이유는 Astra가 그림을 잘 그려서만이 아니다. 게임 규칙을 화면 없이 반복 실행할 수 있고, 이전 실행과 수정 후 실행의 결과를 비교할 수 있게 만든 덕분이다. 제작자도 온보딩과 UX에는 사람의 판단이 필요했다고 밝혔다. 자동 검증이 가능한 규칙은 Astra가 빠르게 다듬었지만, 처음 접한 사용자가 막히는 지점은 사람이 직접 관찰해야 했다.

Chess Cubed는 4일 만에 Blender·웹·Unreal을 연결했다

Chess Cubed는 큐브의 여섯 면을 이어 붙인 체스 게임이다. 기물은 기본 체스와 비슷하게 움직이지만 면의 경계를 넘기 때문에 공격 방향과 이동 규칙이 달라진다. 제작자는 오래전부터 실제 모형으로 구상하던 아이디어를 Astra로 디지털 게임으로 만들었다.

Astra는 Blender MCP로 3D 자산을 만들고 Babylon.js로 웹 버전을 구현했다. 이어 Unreal Engine 버전도 만들어 iOS와 Android로 확장했다. CPU 상대와 난이도 조절, 멀티플레이, 채팅, 여러 스킨까지 4일 동안 구현됐다. 음악과 효과음에도 다른 AI 도구가 쓰였다.

이 속도에는 큰 사용량이 따라왔다. 제작자는 200달러 요금제에서 중간 리셋을 포함해 주간 사용량의 110%를 썼다고 밝혔다. 제작 기간은 짧았지만 자산·게임 규칙·네트워크 기능을 함께 다루느라 사용량은 컸다.

7시간 동안 3,000개 부품과 100개 애니메이션을 만들었다

이 글에서 살핀 사례 중 규모가 가장 큰 Blender 작업은 모든 관절이 움직이는 트랙터다. 제작자는 GPT-6 Astra Max가 약 7시간 동안 작업했고 1억 토큰 이상을 사용했다고 밝혔다. 최종 모델은 3,000개가 넘는 개별 부품과 명령으로 실행할 수 있는 100개 이상의 애니메이션으로 구성됐다. 재질과 텍스처 제작에는 Astra가 호출한 이미지 생성 기능도 쓰였다.

제작 과정은 단순한 한 문장 프롬프트가 아니었다. Astra가 온라인에서 참고 이미지를 찾고 Blender 작업 방식을 정한 뒤 모델과 텍스처를 여러 차례 수정했다.

이 사례에서 부품 수보다 중요한 것은 오랜 작업 동안 앞서 만든 구조를 유지했다는 점이다. 수천 개 부품의 이름과 위치, 연결 관계를 유지하고 100개가 넘는 동작을 명령으로 실행할 수 있게 묶으려면 앞서 만든 구조를 유지하면서 다음 수정을 이어가야 한다. 한 장의 멋진 렌더가 아니라 수정 가능한 구조물을 만들었다는 점에서 이전의 3D 이미지 생성과 다르다.

Blender에서 After Effects까지 필요한 연결 도구도 만들었다

또 다른 제작자는 Astra에게 Blender와 Adobe After Effects용 MCP를 직접 만들게 했다. 두 연결 도구를 만드는 데 약 7분이 걸렸고, 이어 참고 이미지의 비행체를 3D 자산으로 만든 뒤 실제 촬영한 탁자 영상에 합성했다. 이 과정은 약 11분이 걸렸다고 밝혔다.

3D 카메라를 설정할 때 Blender나 After Effects의 기본 기능에만 의존하지 않았다는 점도 눈에 띈다. Astra는 Python으로 카메라의 위치와 각도를 계산하고, 참고 이미지에 맞춰 조명·색·그림자·반사를 구성했다. 필요한 연결 도구가 없자 이를 먼저 만든 뒤 본 작업으로 넘어갔다.

그 대가는 사용량이었다. 제작자는 Astra High의 잔여량이 98%에서 28%로 내려갔다고 썼다. 20분 안에 결과가 나왔지만 작업량까지 적었던 것은 아니다.

과거 해커톤과 영상 프로젝트를 3D 세계로 만든 loaflet.com은 기존 콘텐츠를 3D 공간으로 재구성한 또 다른 사례다. 프로젝트 목록을 카드로 나열하는 대신 건물과 랜드마크 사이를 직접 걸어 다니게 만들었다. 작업 시간과 자산 제작 비율은 공개되지 않았지만, 이미 존재하는 콘텐츠를 새로운 탐색 방식으로 재구성한 사례다.

KiCad·Onshape·게임 최적화까지 작업 범위가 넓어졌다

영상에서 Astra의 작업 범위는 3D 콘텐츠를 넘어 전문 설계 프로그램으로 이어졌다. KiCad 사례에서는 드론 제어용 6층 기판을 설계하고, 설계 규칙 검사가 지적한 배선 간격과 연결 문제를 고친 뒤 제조용 파일까지 출력했다. 회로도에서 선 하나로 보이는 연결도 실제 기판에서는 배선이 지나갈 공간과 층별 배치가 필요하다. Astra는 검사 결과를 읽고 해당 부분을 다시 수정했다.

다만 이 기판은 아직 제작되거나 실물 시험을 거치지 않았다. 전원을 넣었을 때 센서 잡음이 생기는지는 실제 보드에서 측정해야 한다. 제조 파일이 생성됐다는 것과 제품 검증이 끝났다는 것은 다른 단계다.

Onshape에서는 설계용 AI 에이전트 Adam이 Astra를 연결해 터보팬 형상을 만들었다. 복잡한 치수와 조립 구조를 전문 CAD 프로그램에서 다룬 결과지만 실제 추진 성능을 검증한 것은 아니다. 이 사례 역시 Astra가 전문 프로그램에서 복잡한 형상을 만들 수 있다는 증거이지, 항공 엔진 개발이 완료됐다는 뜻은 아니다.

Mac 게임 최적화 사례에서는 3D 제작과 다른 문제 해결 능력이 나타났다. 제작자는 약 8FPS로 실행되던 게임이 수정 뒤 70~150FPS로 올라갔다고 보고했다. Astra는 그래픽 옵션부터 낮추지 않고, Windows 게임을 Mac에서 구동하는 Wine 호환 계층의 실행 과정을 추적했다. Wine의 예외 처리 부분을 고치고 처리 결과를 재사용하는 캐시를 추가했다. 수치는 제작자 보고이며 독립 벤치마크는 아니지만, 게임 내부의 실행 경로를 조사해 병목을 찾았다는 점이 핵심이다.

잘된 프로젝트에는 네 가지 조건이 반복됐다

1. “멋있게” 대신 비교할 기준을 줬다

게임 제작자는 목표 이미지를 함께 제공하고 색감과 구도를 맞추게 했다. 포스트 아포칼립스 장면에는 세계 설명과 자산 참고 링크가 들어갔다. 트랙터 작업에도 여러 참고 이미지가 쓰였다. 결과를 평가할 기준이 있어야 Astra도 렌더를 보고 무엇을 고칠지 결정할 수 있다.

2. 한 모델에 모든 기능을 우겨 넣지 않았다

Blender는 형상과 재질을 만들고, Three.js와 Babylon.js는 브라우저에서 장면을 움직였다. Godot와 Unreal Engine은 게임 규칙과 실행 환경을 맡았다. 이미지 생성 모델은 버튼·아이콘·텍스처를 보조했다. Astra의 역할은 모든 도구를 대체하는 것이 아니라 작업 순서를 정하고 각 도구에서 나온 결과를 이어 붙이는 데 가까웠다.

3. 실패를 자동으로 재현할 수 있게 만들었다

AGI Soon은 헤드리스 시뮬레이션과 봇으로 게임을 수천 번 실행했다. 문제가 생기면 이전 실행을 재생하고 차이를 비교했다. 영상의 게임 제작 사례도 같은 장면을 반복하며 화면과 내부 위치 데이터를 함께 확인했다. 성공한 프로젝트에는 화면 확인 외에도 같은 조건으로 반복할 수 있는 검증 절차가 있었다.

4. 긴 작업을 단계로 나누고 중간 결과를 유지했다

영상 속 한 제작 사례에서는 두 번째 작업 단계에만 약 9시간이 걸렸으며, 영상은 이 전 과정이 무인 실행이었다고 설명하지 않았다. 이 영상 사례에서는 처음 요구한 조건, 앞에서 만든 파일, 오류와 수정 결과를 유지하며 다음 단계로 넘어갔다. 트랙터는 약 7시간, Chess Cubed는 4일이 걸렸지만 두 Reddit 게시물에는 작업 중 사람이 얼마나 개입했는지 공개되지 않았다.

긴 작업에는 큰 사용량이 들었고 실물 검증은 남았다

복수의 장시간·다중 도구 사례에서 큰 사용량이 보고됐다. Chess Cubed는 주간 사용량 110%, 트랙터는 1억 토큰 이상, Blender와 After Effects 합성에서는 사용 가능량이 70%포인트 줄었다는 제작자 보고가 나왔다.

간단해 보이는 수정도 항상 싸지 않았다. 한 Reddit 사용자는 100달러 요금제에서 맵에 산을 추가하고 레벨 스크립트와 주문을 바꾼 뒤 테스트·Git 푸시까지 한 작업에 요금제 사용 가능량의 18%를 썼다고 밝혔다. 공개 사례마다 작업 범위, 추론 강도, 도구 호출과 반복 검사 조건이 달라 작업 시간만으로 사용량을 비교하기 어렵다.

같은 7시간이나 같은 한 번의 수정이라도 어떤 작업에 사용량이 얼마나 배분됐는지는 공개되지 않았다. 확인할 수 있는 것은 여러 도구를 연결하고 렌더링과 검사를 반복한 사례에서 큰 사용량이 함께 보고됐다는 점뿐이다.

검증 범위도 구분해야 한다. 브라우저에서 움직이는 V8 엔진은 구조를 설명하는 시각화이지 내구성 시험을 마친 엔진이 아니다. KiCad 제조 파일은 공장에 넘길 수 있는 형식이지만 통전과 노이즈 시험을 대신하지 않는다. Onshape 터보팬은 CAD 형상이지 추진 성능이 확인된 엔진이 아니다. Astra는 설계안을 제조·실행 가능한 파일로 만드는 시간을 크게 줄였지만, 실물 시험과 사용자의 미적 판단까지 대신하지는 못했다.

GPT-6 Astra는 첫 결과물보다 수정과 검증에서 달라졌다

GPT-6 Astra가 만든 결과물만 모아보면 3D 생성 능력이 가장 먼저 보인다. 그러나 제작 과정을 보면 공통점은 3D 생성이 아니라 반복 수정에 있다. 참고 자료를 읽고, 필요한 도구를 연결하고, 코드를 실행하고, 화면과 검사 결과를 보고, 틀린 부분을 다시 고친다. 이 과정을 몇 분이 아니라 몇 시간과 며칠 동안 이어간다.

기존 AI도 코드 조각과 3D 예제를 만들 수 있었다. Astra가 보여준 변화는 그 조각들을 Blender·게임 엔진·CAD·기판 설계 도구 안에서 실제 결과물로 묶는 데 있다. 1.5일 만에 완성한 게임과 3,000개 부품의 트랙터가 가능한 이유는 한 번에 정답을 냈기 때문이 아니라, 틀린 결과를 보고 다시 작업할 수 있었기 때문이다.

GPT-6 Astra의 강점은 첫 시도에 완성품을 내놓는 데 있지 않다. 여러 도구를 직접 다루고 실행 결과를 확인하며 오류를 반복 수정하는 데 있다.

자주 묻는 질문