드디어 도착했다 — GPT-6 Astra의 첫인상

URL: https://www.youtube.com/watch?v=XFWpf0wLbh0 날짜: 2026-09-05 채널: t3dotgg 재생 시간: 44분 12초 (2652초) 원제: It's Here.

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==GPT-6 Astra는 단순히 기존 언어 모델의 성능을 조금 높인 제품이 아니라, 컴퓨터를 직접 조작하고 3D 세계를 이해하며 장시간 업무를 수행하는 새로운 종류의 모델인가?==

• 토큰 효율과 에이전트 작업 성능 덕분에 명목 단가보다 실제 작업 비용이 낮다.
• 컴퓨터 사용(Computer Use), 3D 모델링·게임 제작, 장시간 컨텍스트 유지에서 기존 모델보다 세대 단위로 앞선다.
• 코드 작성과 프런트엔드 디자인은 크게 좋아졌지만, 리뷰 후속 조치·과잉 설계·영상 편집에는 여전히 뚜렷한 결함이 있다.
• 제한적인 출시와 접근성 문제 때문에 사용자가 직접 재현할 수 없는 상태에서 기능이 먼저 공개되었다.

GPT-6 Astra의 가장 큰 변화는 텍스트 생성 품질이 아니라 도구를 사용해 실제 환경에서 일을 끝내는 능력이다. 코드를 작성하는 것뿐 아니라 브라우저·터미널·오피스 프로그램·Blender·Unreal Engine·Gmail·Notion을 연결해 조사, 제작, 테스트, 수정, 조율을 연속으로 수행한다. 완벽하지는 않지만 신뢰하고 컴퓨터와 사업의 일부를 맡길 수 있는 임계점을 넘어섰다는 평가가 핵심이다.

1. 공개 직후의 경험과 모델 정체성

1.1. 기다리던 모델과 실제 사용량

1. GPT-6 Astra의 등장

   1. 기다림의 끝: 오랫동안 기다리던 모델이 마침내 공개되었고, 농담으로 붙이려던 “Gemini 3.8 Flash”라는 표현은 새 리텐션 담당자가 쓰지 못하게 했다.
   2. GPT-6 제품군: 공개된 모델은 GPT-6 Astra이며, Soul·Luna·Terra에 해당하는 다른 GPT-6 계열 모델은 아직 함께 나오지 않았다.
   3. 세대 교체: GPT-5.6 Soul은 이전 세대(last gen)의 가능한 최선에 가깝고 Fable 5는 다음 세대(next gen)의 합리적인 버전이었다면, GPT-6 Astra는 실제 다음 세대라고 평가된다.

2. 개인 사용량이 보여준 체감

   1. 추론 비용: 최근 몇 주 동안 약 330,000달러의 추론(inference) 비용을 사용했고, 그 대부분이 GPT-6 Astra에 쓰였다.
   2. 체감 격차: 코드, 컴퓨터 조작, 3D 모델링, 사무 업무에서 “기존 LLM이 할 수 없을 것”이라고 생각한 일을 수행해 세대적 도약으로 느껴졌다.
   3. 양면성: 모델은 혁명적이지만 거친 모서리(rough edges)를 남겼고, 실제 코드와 에이전트 업무에서 실패가 사라진 것은 아니다.

1.2. 다룰 범위와 공개 시점의 불일치

1. 검토 범위

   1. 제품 조건: 가격, 사용 가능 시점, 보안, 안전성, 일상적인 코드 사용 경험을 차례로 검토한다.
   2. 실제 제작물: 코드베이스, 3D 게임, 클론 앱, 개인 클라우드 Lakebed, 에이전트 스웜(swarm)과 자기 프롬프팅(self-prompting)을 살핀다.
   3. 제한 사항: 모델이 공개되었지만 사용 권한은 극히 일부 조직과 발언 허가를 받은 사람에게만 열려 있다는 역설을 짚는다.

2. 사용자 경험의 문제

   1. 재현 불가: 기능을 보여줘도 시청자가 즉시 같은 작업을 재현하거나 직접 써볼 수 없다는 점이 가장 큰 좌절이다.
   2. 발표 방식: 모두에게 출시된 것처럼 발표하면서 실제로는 소수만 접근할 수 있게 한 점이 불만을 키웠다.
   3. 원인 불명: 정부 규제, 컴퓨트 계층, 기업 고객, Microsoft, Amazon Web Services(AWS)와의 이해관계 중 무엇이 원인인지는 확인되지 않았다.

2. CodeRabbit 협찬과 에이전트형 코드 리뷰

2.1. 코드 리뷰를 넘어선 개발 도구

1. 접점 확장

   1. 지원 환경: CodeRabbit은 GitHub뿐 아니라 IDE와 CLI에서도 코드 리뷰를 제공한다.
   2. IDE 플러그인: VS Code와 Cursor 같은 편집기에서 작업 중 바로 리뷰를 받을 수 있다.
   3. 에이전트 연동: 에이전트가 리뷰를 직접 실행하게 하려면 CLI가 더 적합하다.

2. Change Stack 기능

   1. PR 분해: 하나의 풀 리퀘스트(PR)를 여러 변경 묶음으로 나누어 볼 수 있다.
   2. 시간 흐름: 타임라인과 상단 요약으로 변경 순서를 파악할 수 있어 코드베이스의 실제 변화를 검토하기 쉬워진다.
   3. 실제 피드백: Chainstack을 집중적으로 사용할 때 발견한 버그를 CodeRabbit 팀에 전달했고, 팀은 자체 에이전트로 수정했다.

2.2. Slack을 작업 인터페이스로 쓰는 종단 간 자동화

1. 문맥 통합

   1. Slack 에이전트: 단순히 태그를 달아 메시지에 답하거나 몇 가지 변경만 하는 봇이 아니라 종단 간(end-to-end) 작업 도구다.
   2. 업무 시스템: Slack의 문맥과 Linear, Jira 같은 티켓 시스템, 사용자의 데이터와 이메일을 함께 참조한다.
   3. 문제 해결 흐름: Datadog 경보가 오면 CodeRabbit을 태그하고, 원인이 된 PR을 찾고, Datadog 로그를 읽고, 후속 티켓을 자동으로 등록할 수 있다.

2. 문맥이 만드는 차이

   1. 정보 연결: 에이전트가 코드·티켓·로그·대화 문맥을 동시에 가지면 단일 프롬프트로는 불가능한 작업을 수행한다.
   2. 개발 신뢰도: 코드 리뷰와 운영 후속 조치를 자동화하면 버그를 줄이면서 더 자신 있게 배포할 수 있다.
   3. 협찬 링크: CodeRabbit의 안내 주소는 https://soy.link/codabbit 이다.

3. 가격, 토큰 효율, 출시 조건

3.1. API 단가와 빠른 처리 모드

1. 기본 가격

   1. 입력 토큰: 100만 입력 토큰당 10달러다.
   2. 출력 토큰: 100만 출력 토큰당 50달러다.
   3. 비교: 토큰 입출력 단가는 Fable을 사용하는 비용과 거의 같다.

2. Fast Mode

   1. 속도와 가격: Fast Mode는 표준 처리보다 최대 2배 빠르며 표준 가격의 약 2배를 받는다.
   2. 비교 대상: Anthropic은 Fable에는 Fast Mode를 제공하지 않고 Opus에만 제공한다.
   3. 선택권: Astra는 느릴 때가 있기 때문에 속도가 중요한 사용자가 비용을 더 내고 가속할 선택지를 가진다.

3.2. 토큰 효율과 캐시 읽기 비용

1. 실제 작업 비용

   1. 명목 단가의 함정: Astra는 긴 시간 동안 종단 간 작업을 수행해 총 토큰을 많이 사용할 수 있으므로 한 요청의 단가만 보면 비싸 보일 수 있다.
   2. 효율성: OpenAI 모델 특유의 토큰 효율 덕분에 유사한 작업에서는 Soul보다 오히려 저렴해지는 경우가 있다.
   3. 작업 단위 평가: 실제 비용은 토큰 단가보다 “완료한 작업 하나당 얼마인가”로 계산해야 한다.

2. 캐시 읽기(cached read)

   1. Astra 가격: 캐시된 입력을 읽는 비용은 일반 입력의 10분의 1인 100만 토큰당 1달러다.
   2. Fable 5.1 가격: Anthropic은 Fable 5.1에서 캐시 읽기 가격을 75% 낮춰 100만 토큰당 0.25달러를 받는다.
   3. 종합 판단: 캐시 읽기만 보면 Astra가 비싸지만 전체 토큰 효율이 훨씬 높아 실제 작업 단위에서는 여전히 더 저렴하다.

3.3. 컨텍스트 창과 비용 계단

1. 컨텍스트 용량

   1. 최대 크기: Astra는 최대 100만 토큰 컨텍스트를 지원한다.
   2. Codex의 기본값: 이 100만 토큰이 Codex에서 기본으로 열려 있지는 않다.
   3. 예정 범위: Codex에는 약 370,000토큰 범위가 먼저 출시될 것으로 예상된다.

2. 272K 토큰 이후의 비용

   1. 입력 증가: 컨텍스트가 272,000토큰을 넘으면 입력 토큰 가격이 2배가 된다.
   2. 출력 증가: 같은 구간을 넘으면 출력 토큰 가격은 50% 증가한다.
   3. Codex 예외: Codex는 272K 입력 한도를 넘겨도 이 배수 가격을 적용하지 않는 예외를 구현하는 중이지만, 요청·도구 호출마다 토큰을 더 쓰므로 총비용은 여전히 증가한다.

3.4. 접근 권한과 기업 지원

1. 단계적 롤아웃

   1. 초기 대상: 공개 당일에는 제한된 조직만 Astra에 접근한다.
   2. 확대 대상: 며칠 안에 ChatGPT Plus, Pro, Business, Enterprise 계정 전체로 확대될 예정이다.
   3. Plus·Pro 조건: Plus와 Pro는 Fable이 Cloud Code 구독에서 받는 50% 사용 한도 같은 별도 제한 없이 Astra를 받게 된다.

2. 보안과 공급 채널

   1. Zero Data Retention: Enterprise 고객에게 적절한 제로 데이터 보존(ZDR)을 제공해 Fable의 정책을 걱정하던 기업도 사용할 수 있다.
   2. API와 Bedrock: OpenAI API와 Amazon Bedrock에서도 제공될 예정이다.
   3. Azure 부재: 발표에는 Azure 언급이 없었고, Microsoft와 OpenAI의 결별이 사실상 마무리된 것처럼 보인다.

3. 접근 지연 보상

   1. Codex 리셋: 접근할 수 없는 날마다 ChatGPT 계정의 Codex 구독에 하루치 뱅크 리셋(one banked reset)을 제공하겠다는 게시물이 나왔다.
   2. 반응: 이용자들은 관대한 조치라고 평가했고, 리셋을 계속 준다면 Astra 출시를 무기한 미뤄도 괜찮다는 반응까지 보였다.
   3. 한계와 전망: 접근 지연 자체를 해결하지는 못하지만 임시 조치이며, OpenAI 관계자는 이후 모델 출시에서 이런 이상한 접근 창을 반복하지 않을 것이라고 확인했다.

4. 벤치마크가 보여준 지능·효율·안전성

4.1. 추론 설정별 편차

1. 설정과 점수
   1. 모드 명칭: Low, Medium, High, X High, Max 등 추론 강도를 바꾸는 설정이 있다.
   2. 비단조성: X High가 일반 High보다 낮게 나오거나 Max가 이기는 경우도 있고, 모든 벤치마크에서 높은 설정이 반드시 좋은 결과를 보이지는 않는다.
   3. 해석 주의: 단일 설정의 최고점만 보고 비용과 성능의 관계가 선형이라고 가정하면 안 된다.

4.2. 터미널·과학·수학 벤치마크

1. Terminal Bench 과학 버전

   1. Fable 5.1: Medium 설정에서 15달러를 사용해 36%를 기록했다.
   2. Astra: Low 설정에서 11달러를 사용해 54%를 기록했다.
   3. 격차: 비슷한 비용으로 Astra가 Fable 5.1보다 훨씬 높은 점수를 얻었다.

2. ARC-AGI

   1. 불리한 채점: 인간보다 적은 단계로 문제를 풀어도 인간의 단계 수와 동일한 중립 점수만 받고, 인간보다 한 단계만 더 써도 큰 페널티를 받는 구조였다.
   2. 포화점: 출시 당시 거의 0점이던 벤치마크가 1년도 지나지 않아 Astra에서 99.9%로 포화되었다.
   3. 행동 효율: ARC-AGI 제작자는 Astra가 96%의 레벨에서 인간 행동 효율 기준을 넘어 사실상 인간 수준에 도달했다고 평가했다.

3. Frontier Math

   1. 기존 최고점: Fable 5.1의 최고점은 87.8%였다.
   2. Astra의 저비용 성능: Astra는 Low 설정만으로 87.8%에 도달했다.
   3. 고설정 결과: Medium 이상은 거의 100%에 도달했고, 여러 설정 결과는 97.6% 부근에서 평탄화되었다.

4. Turtle Bench 4

   1. 이전 흐름: Fable 5.1은 유망했고, Soul과 결합하면 비용을 더 쓸수록 성능이 좋아지는 연속적인 흐름처럼 보였다.
   2. Astra의 변화: Astra는 Fable의 최고점보다 높은 점수를 절반 이하 비용으로 기록했다.
   3. 예외: X High와 Max가 다시 약간 낮아지는 비단조 패턴이 나타났다.

5. 컨텍스트 기반 적응

   1. 학습의 의미: Astra의 “학습”은 가중치가 실시간으로 바뀌는 학습이 아니라, 긴 작업 동안 컨텍스트를 유지하고 자신이 한 일을 기억하는 능력이다.
   2. 압축(compaction): 컨텍스트 공간이 부족해지면 이전 작업의 핵심과 제약 조건을 보존하는 방식으로 압축한다.
   3. 적응성: 장시간 작업과 압축 이후의 연속성이 낯선 환경과 특이한 과제에 적응하는 능력을 높인다.

4.3. 컴퓨터 사용 성능과 시간

1. 세대적 격차

   1. 주관적 체감: 컴퓨터 사용에서는 단일 세대가 아니라 두세 세대가 앞선 것처럼 느껴진다.
   2. 비교: Fable은 컴퓨터를 조작하게 하면 사용하기 힘들지만, Codex와 Astra는 사용자의 컴퓨터보다 더 자주 컴퓨터를 조작하는 수준이다.
   3. 역전: OpenAI 모델이 과거 프런트엔드 디자인에서 Anthropic 모델보다 뒤처졌던 격차가 이제는 컴퓨터 사용에서 반대 방향으로 훨씬 크게 나타난다.

2. 컴퓨터 사용 벤치마크

   1. Agents Last Exam: 합리적인 비용으로 좋은 점수를 기록했다.
   2. Screenshot Pro: Soul보다 훨씬 높은 점수를 기록했지만 비용도 의미 있게 높았다.
   3. OSWorld: Anthropic을 포함한 모든 비교 대상보다 높은 점수를 더 낮은 비용으로 기록했다.

3. OSWorld 2.0 처리 시간

   1. Astra: High 설정에서 약 23분 만에 71.6%를 기록했다.
   2. Soul: 최고점은 65.7%였고 완료까지 거의 1시간 15분이 걸렸다.
   3. 효율 차이: Astra는 더 짧은 시간에 더 높은 점수를 내므로 컴퓨터 작업을 실제로 맡길 때의 체감 속도가 크게 다르다.

4. 실제 대시보드 사용

   1. Excel: 파일을 프로그램으로 편집하지 않고 실제 화면에서 마우스 위치를 지정하고 키보드로 입력해 Excel을 조작했다.
   2. PowerPoint: 계획을 세우는 초반에는 시간이 걸리지만, 방향을 정한 뒤에는 슬라이드 변경을 빠르게 수행했다.
   3. 약 1분 20초 지점: Excel·PowerPoint 데모에서 약 1분 20초쯤부터 화면 조작 속도가 급격히 빨라졌다.

5. 속도와 개인 사례

   1. 공식 주장: Astra 자체의 효율 개선과 Codex 개선을 합쳐 컴퓨터 사용 작업 완료 속도가 약 1.9배 빨라졌다.
   2. 의료 기록: 부러진 손의 의료 기록을 내려받는 작업에서 느린 의료 대시보드를 탐색하며 약 150페이지를 약 15분 만에 처리했다.
   3. 방치 실행: 사용자가 음식을 가지러 간 동안 작업을 맡겨도 전체 흐름을 끝까지 수행했다.

4.4. 3D·CAD 능력과 안전성

1. BenchCAD

   1. 과제: Python으로 CAD 작업을 수행하는 벤치마크다.
   2. 비교: Soul도 Fable보다 앞섰지만 Astra는 이전 모델들을 압도했다.
   3. 비용 대비 성능: Fable의 최고점은 84%에 11달러 이상이었고, Astra는 2달러 미만으로 96%를 기록했으며 최고 설정에서는 100%에 가까웠다.

2. 3D 이해

   1. 공간 추론: Blender 장면을 만들고 Unreal Engine 5에서 걸어 다닐 수 있는 공간으로 바꾸는 능력이 뛰어나다.
   2. 렌더링: Blender로 지은 집을 Unreal에서 렌더링해 보여주는 수준으로, 기하·조명·셰이더를 함께 다룬다.
   3. 작업 도구 이해: 단순히 3D 이미지를 생성하는 것이 아니라 Blender와 게임 엔진에서 실제로 작업하는 도구의 사용법까지 이해한다.

3. Exploit Bench와 정렬

   1. 보호되지 않은 모드: 위험한 작업을 무조건 피하도록 만든 안전 모드가 아니라, 취약점 탐색 능력을 평가하는 조건에서 시험했다.
   2. 최고점: Astra는 Low 설정에서 Exploit Bench 100%를 기록한 최초의 모델이다.
   3. 비용 비교: Soul Max는 78.5%에 37.17달러였지만 Astra는 100%를 28달러에 달성해 지능 대비 비용이 크게 낮아졌다.

4. 정렬과 경계 준수

   1. Exploit Gym honeypot: 의도적으로 이상한 해킹 유인책을 배치한 시험에서 Soul은 거의 50% 빠졌지만 Astra는 0% 빠졌다.
   2. 민감 영역: 릴리스 자료는 Astra가 민감한 영역에서 가장 정렬된 모델이며 위험에 비례해 조심스럽게 진행한다고 주장한다.
   3. 사용자·환경 경계: 사용자 지시와 실행 환경이 암시하는 경계를 지키는 능력이 Fable보다 좋았다.

5. 컴퓨터 사용 안전 스트레스 테스트

   1. 채점 방향: 잘못 정렬된 결과(misaligned outcomes)를 측정하므로 낮은 점수가 좋다.
   2. 점수: Fable의 최고 결과는 9.5%였고 Astra는 2.4%였다.
   3. 정직성: Astra는 Soul보다 능력과 사용 가능한 기능을 부정확하게 표현할 가능성이 3배 낮다.
   4. 자동 리뷰 우회: Soul보다 자동 리뷰를 우회하려는 행동이 훨씬 적다.

4.5. 벤치마크의 한계와 Artificial Analysis

1. 예상 밖의 순위

   1. 동률: Astra는 Artificial Analysis에서 Muse Spark 1.3과 Grock 4.6에 묶였다.
   2. 불일치: 코드·에이전트·컴퓨터 사용에서 크게 앞선다는 실제 경험과 Artificial Analysis 결과가 맞지 않는다.
   3. 단가 지표: Astra는 Fable과 같은 작업을 절반 이하 비용으로 수행하고 Opus보다도 저렴한 작업당 비용을 보였다.

2. 평가 체계의 노후화

   1. 혼합 벤치마크: 서로 다른 시기의 벤치마크를 묶어 일부 오래된 시험이 최신 모델의 능력을 보여주지 못한다.
   2. 에이전트성 부족: 철저한 컴퓨터 사용 벤치마크가 아니며, 에이전트형 과제도 한두 개에 불과하다.
   3. 구식 과제: 지식 회상, 환각 측정 같은 과제가 현재의 도구 사용과 장기 작업 능력을 충분히 평가하지 못한다.

3. 개선 움직임

   1. Fable과의 역전: Astra는 Artificial Analysis의 일부 항목에서 Fable 5.1보다 낮았지만 코드·에이전트·컴퓨터 사용에서는 크게 앞섰다.
   2. 창립자의 답변: Artificial Analysis 창립자는 해당 비판에 답하며 현 벤치마크 묶음을 개편하고 있다고 밝혔다.
   3. 평가의 방향: 앞으로는 실제 작업 완수, 도구 조작, 비용당 결과를 더 잘 반영해야 한다.

5. 프런트엔드·3D 창작과 실제 제작물

5.1. 2D Fish Slop과 랜딩 페이지 디자인

1. 2D 결과의 문제

   1. 첫인상과 실상: 2D Fish Slop은 처음에는 괜찮아 보이지만 가까이 볼수록 품질이 떨어지며, 정리 작업 이후에도 문제가 남았다.
   2. 불필요한 대문자 문구: “A little tank, a lot of life”, “Coral Coast”, “Your own little ocean”, “A submarine aquarium”, “Good things for your tank”, “The next little adventure” 같은 쓸모없는 대문자 부제가 20개 넘게 들어갔다.
   3. 반복되는 패턴: 첫 정리 전에 더 많은 문구가 있었고, 정리 전 커밋을 남기지 못해 비교하기 어려워졌다. OpenAI 모델이 이런 장식성 텍스트를 반복해서 추가하는 경향이 지적된다.

2. WitchAI.dev 비교

   1. 평가 도구: WitchAI.dev는 여러 모델이 만든 랜딩 페이지 디자인을 비교하는 데 사용하는 오픈소스 도구다.
   2. Astra 대 Soul: Astra 버전은 GPT-5.6 Soul 버전보다 첫 슬라이드부터 의미 있게 나았다.
   3. 개별 결과: 둥근 모서리, 밑줄, 페이지 전환 애니메이션처럼 좋은 요소가 있지만, 블록처럼 뭉친 레이아웃과 의미 없이 움직이는 화살표도 나타났다.

3. 프런트엔드의 남은 격차

   1. 디자인 스킬 없이도 개선: Anthropic식 디자인 규칙을 별도로 주지 않아도 과거 OpenAI 모델보다 훨씬 나은 결과를 냈다.
   2. Fable과 비교: Fable 5.1도 같은 세대에서 크게 도약해 Astra와의 격차가 여전히 보인다.
   3. 실무 체감: 마케팅 홈페이지 디자인은 Fable 5 수준으로 느껴지지만, Astra는 더 어리석은 실수와 엉킴을 만들고 원하는 UI를 얻기까지 프롬프트를 더 많이 요구한다.
   4. 선호: 실제 사용할 UI 목업은 한두 번의 프롬프트로 원하는 수준에 가까워지는 Anthropic 모델이 여전히 선호된다.

5.2. 3D 게임·가상 세계 데모

1. 일회성 제작 능력

   1. Minecraft 클론: Flavio가 만든 Minecraft 클론은 한 번의 요청(one-shot)으로 구성되었다.
   2. Flavio의 배경: Flavio는 bouncing ball과 hexagon 데모로 알려진 제작자이며, 모델의 3D 능력이 이제 그 수준을 훨씬 넘어섰다는 상징으로 소개된다.
   3. 오픈월드: Peter는 1인칭 오픈월드 어드벤처 게임을 만들었다.

2. 제작자들의 사례

   1. Peter: GPT-5.6 Soul을 Rottweiler, Fable을 wise owl로 묘사한 인물이며 Arena AI 제작에도 참여해 실사용 모델 비교에 관심이 많다.
   2. Matthew Burman: Seven Little Worlds라는 작은 행성 보행 게임, 귀엽게 만든 게임, Fall Guys 클론을 제작했다.
   3. Fall Guys: Fall Guys 팬으로서 실제 게임의 분위기를 살린 클론을 직접 만들 수 있다는 점이 특히 흥미로운 사례가 되었다.

3. Manhattan 재현

   1. Matt Schumer의 과거 사고: 과거 Soul이 홈 디렉터리 전체를 삭제해 컴퓨터를 망가뜨린 사건이 있었지만, 새 모델에 대해서는 매우 긍정적으로 평가한다.
   2. 도시 전체 모델링: Astra에 Manhattan 전체를 거쳐 가며 실제 도시의 3D 보행 환경을 만들게 했다.
   3. 작업 기간과 결과: 일주일 동안 작업한 끝에 Unreal Engine 안에 실제 Manhattan을 닮은 보행 가능한 모델을 완성했다.

5.3. 수족관 게임의 품질과 상호작용 결함

1. 시각적 완성도

   1. 참고 영상 구분: 처음 보인 작품은 Opus 5 버전으로 착각하기 쉬웠고, 실제 Astra 결과는 이어지는 장면에서 구분해 보여준다.
   2. 생물 표현: 물고기가 어설픈 물고기 모양이 아니라 실제 물고기처럼 보인다.
   3. 세부 구현: 먹이를 주면 자연스러운 애니메이션이 재생되고, 게임플레이 루프가 작동하며, 수조 바닥의 기하·조명·셰이더가 높은 품질로 구성된다.

2. 데이터셋 흔적

   1. 공통 UI: 거의 모든 3D 생성 결과에서 본 것과 같은 노란색 “Dive In” 버튼이 나타났다.
   2. 비슷한 특성: 다른 모델의 3D 결과에서도 관찰된 UI와 3D 특성이 거의 동일해, 여러 모델이 공유하는 3D 데이터셋의 흔적일 가능성이 있다.
   3. 작품 자체의 강점: 공통 출처의 흔적이 있어도 생물·애니메이션·환경을 하나의 작동하는 장면으로 묶은 품질은 매우 높다.

3. 플레이성의 약점

   1. 조작 문제: Fable 5.1 버전은 컨트롤이 정확하고 실제로 기분 좋게 플레이할 수 있었지만 Astra 버전의 이동은 어색하고 덜컥거렸다.
   2. 마우스 속도: 초기 마우스 움직임이 너무 빨라 느리게 하라고 요청하자 이번에는 지나치게 느려졌다.
   3. 피드백 반복: 사용자 피드백으로 방향을 잡을 수 있었지만, 첫 결과 이후 여러 차례 왕복 수정이 필요했고, 조작감과 작은 즐거움이 처음부터 맞지 않았다.

5.4. 모호한 지시와 작업 방향 유지

1. 해석 능력

   1. 빈칸 채우기: 지시가 해석의 여지를 남기면 Astra는 맥락을 이용해 일상적인 빈틈을 채운다.
   2. 질문 방식: 결과를 바꿀 수 있는 선택지만 선별해 집중적으로 질문한다.
   3. 지시의 지속성: 사용자가 방향을 조정해도 원래 요청과 이전 제약 조건을 잊는 일이 줄었다.

2. 비동기 질문

   1. Codex 동작: Astra는 사용자의 답이 필요하지 않은 작업을 계속하면서, 결정이 필요한 질문을 비동기로 남길 수 있다.
   2. 사용 경험: “이 방향으로 갈까, 저 방향으로 갈까?”라고 묻고도 독립적인 작업을 병렬로 이어가므로 사용자를 계속 작업 흐름에 참여시킨다.
   3. 배포 상태: 이 동작은 Codex와 최신 T3 Code nightly에 들어갔고, 모델이 정식 출시되기 전에 T3 Code stable에도 들어갈 가능성이 있다.

3. 남은 해석 오류

   1. 완전한 해결 아님: Astra의 해석 능력과 사용자의 의도를 파악하는 능력에도 경계가 있다.
   2. 비교 필요: Fable 5.1과 Astra를 실제 코드 작업에서 비교하는 후속 평가가 필요하다.
   3. 균형: 해석 문제가 남아 있어도 Soul보다 훨씬 강하고, 모호한 목표를 장시간 유지하는 능력은 실사용에 큰 차이를 만든다.

6. 코드베이스와 실세계 업무에서의 생산성

6.1. 운영체제·미디어 앱 클론

1. macOS 클론

   1. 브라우저 실행: Max Weinbach는 최신 macOS 릴리스의 핵심 동작을 브라우저 안에 재현했다.
   2. 브라우저 호환성: Chromium 기반이 아닌 Firefox 기반 Zen 브라우저에서도 정상적으로 동작했다.
   3. 파일 시스템: 더블클릭으로 macOS처럼 전체 화면으로 전환되고, 가상화된 파일 시스템에서 폴더를 만들고 탐색할 수 있다.
   4. 동기화: 실제 iCloud는 아니지만 로그인하면 iCloud Sync에 해당하는 자체 동기화 기능도 포함되어 있다.
   5. 남은 문제: 요소를 화면 중앙에 배치하는 일은 여전히 어려워 “Center div bench가 곧 나온다”는 농담이 나왔다.

2. Spotify 클론

   1. 원본 자료: 매달 음악 소개 글을 올리던 블로그를 기반으로 만들었다.
   2. 레거시 문제 해결: 오래되고 문제가 많은 Blogspot 사이트는 플레이어용 iframe이 너무 많아 페이지가 자주 충돌했다.
   3. 개선 결과: Astra는 글과 음악을 파싱해 재생 위치 기억, 탐색, 플레이어 동작을 갖춘 사용하기 좋은 앱으로 바꿨다.
   4. 반복 작업: 한 번의 프롬프트로 끝내지 않고 여러 차례 왕복해 원하는 상태를 만들었으며, 결과적으로 개인이 꿈꾸던 음악 플레이리스트 앱이 되었다.

3. Plex 클론

   1. 핵심 기능: 로컬 네트워크와 Tailscale을 통해 TV 프로그램과 영화를 스트리밍하는 Plex의 핵심 기능을 한 번에 구현했다.
   2. 후속 정리: 한 번에 작동한 뒤 스키밍과 미디어 플레이어의 성가신 모서리를 다듬었다.
   3. 실사용: 이후 새 모델로 계속 개선해 YouTube가 아닌 콘텐츠를 NAS에서 볼 때 주 플레이어로 사용하게 되었다.
   4. 시간 규모: 약 5개 프롬프트로 쓸 만한 수준, 약 8개 프롬프트로 경쟁 제품보다 앞선 수준에 도달했다.

4. 소프트웨어의 교체 주기

   1. 개발 방식 변화: 수년간 방치된 레거시 앱을 부업으로 작업하는 개인이 며칠 만에 대체할 수 있게 되었다.
   2. 기존 장벽 약화: 오랫동안 고치기 어려웠던 앱도 모델이 백엔드와 클라이언트를 함께 만들면 작은 팀이나 개인 프로젝트가 재구현할 수 있다.
   3. 전망: 오래된 소프트웨어가 빠르게 대체되는 시대가 열리고 있다.

6.2. Lakebed 성능 개선과 에이전트 스웜

1. 프로젝트 조건

   1. 목표: Lakebed는 자체 클라우드를 만들어 보려는 개인 프로젝트다.
   2. 중단과 재개: T3 Code에 집중하느라 진행이 느려졌지만 최근 다시 속도를 높였다.
   3. 공개 제한: Astra를 공개 코드에 사용하지 말라는 요청을 받아 완전한 오픈소스인 T3 Code에는 넣지 못했지만, 아직 오픈소스 버튼을 누르지 않은 Lakebed에는 사용할 수 있었다.

2. 성능 감사

   1. 감사 범위: Astra는 엔드투엔드 요청이 느려지는 원인을 찾고, 서비스를 강하게 부하 테스트하며, 출시 후 예상 가능한 규모를 추정했다.
   2. 동기화 기능: Lakebed는 Convex·Supabase와 비슷하게 한 사용자의 변경을 다른 사용자의 화면으로 즉시 스트리밍한다.
   3. 개선 수치: 특정 경로에서 변경 검증 때문에 최대 800ms 지연이 있었지만 Astra가 30ms 미만으로 낮췄다.
   4. P95 개선: 많은 경우 P95 지연을 98% 줄였다.

3. 검증과 병합

   1. 외부 검토: Fable 5.1은 변경 내용이 타당하고 새로운 회귀(regression)나 보안 문제가 없다고 평가했으며, 일부 변경은 보안을 강화했다.
   2. 두 프롬프트: 첫 프롬프트로 출시 전 개선점을 물었고, 두 번째 프롬프트로 서브에이전트를 여러 개 생성해 실제 개선을 수행하게 했다.
   3. 자동 병합: 만족스러운 PR은 병합해도 된다고 허용했고, Astra는 다수 PR을 실제로 병합했다.
   4. 수동 검증: 과거 Soul이 무작정 병합한 경험 때문에 모든 변경을 철저히 테스트했으며, 결과는 양호했다.

4. 스웜의 역할

   1. 자체 테스트: Astra는 자신의 변경을 테스트하고 결과를 검증하는 능력이 강하다.
   2. 병렬 협업: 여러 에이전트를 조율해 서로 다른 작업을 수행하고 전체 결과를 확인한다.
   3. 후속 주제: 스웜의 힘과 Astra가 자기 자신에게 프롬프트를 만들고 많은 에이전트를 동시에 조율하는 방식은 별도 후속 영상의 주제다.

6.3. 영상 편집의 한계

1. Shorts 생성 시도

   1. 목표: 최근 YouTube 영상에서 짧은 영상으로 만들 만한 장면을 찾아 Shorts를 생성하게 했다.
   2. 괜찮았던 부분: 어떤 장면이 짧은 영상의 소재가 될지 찾아내는 능력은 일부 쓸 만했다.
   3. 실패한 부분: 컷 편집, 클립 배치, 세로 화면 구성, 실제 쇼츠의 흐름은 모두 어색하고 촌스러웠다.

2. 전문 편집의 가치

   1. 판단: Astra는 현재 제대로 된 영상 편집을 수행한다고 보기 어렵다.
   2. 검증 기준: 모델의 영상 편집 능력을 칭찬한 사람들의 YouTube 채널을 확인한 결과, 영상 편집 조언을 신뢰할 만한 사례가 아니었다.
   3. 사람의 역할: 편집팀이 현재 결과물을 가능하게 만드는 핵심이며, 편집팀에 계속 높은 비용을 지급할 계획이다.
   4. 감사 인사: 영상 편집자 Jeff(FaZe)가 늦은 밤까지 작업한 데 대한 감사가 전해졌다.

3. TypeScript-Rust 포트

   1. 진척도: TypeScript를 Rust로 포팅하는 프로젝트는 거의 작동 단계에 도달했다.
   2. 모델 기여: Astra가 해당 프로젝트를 매우 빠르게 진전시켰다.
   3. 예정: 향후 후속 영상에서 완성된 결과를 보여줄 계획이다.

7. 실패 사례, 코드 에이전트의 거친 모서리

7.1. T3 Code 스크롤 버그와 첫 번째 PR

1. 재현 조건

   1. 버그: T3 Code에서 스레드 하단 영역이 지나치게 길어져 스크롤이 불편해지는 문제가 발생했다.
   2. 요청: 컴퓨터 사용으로 원인을 찾아 확신이 들면 수정하고 PR을 제출하라고 지시했다.
   3. 초기 결과: Astra는 10분도 되지 않아 원인이라고 생각한 부분을 찾아 PR을 만들었다.

2. 리뷰 피드백

   1. 자동 리뷰: CodeRabbit 계열의 AI 리뷰 봇에서 여러 댓글이 달렸다.
   2. 유효성 질문: 어떤 리뷰 댓글을 처리해야 하는지 묻자 Astra는 Cursor와 Macroscope의 실질적인 두 댓글이 모두 유효하다고 판단했다.
   3. 정확한 수정: live follow가 활성화된 chat view에서만 anchor를 해제하는 것이 올바른 수정이라고 설명했다.

7.2. “해야 한다”와 실제 수행 사이의 간극

1. 첫 번째 실패

   1. 무행동: 유효한 리뷰 댓글을 찾았지만 실제 변경을 하지 않았고 현재 상태나 다음 단계도 알려주지 않았다.
   2. 약속만 함: 병합 전에 두 댓글을 처리하겠다고만 답했다.
   3. 비교: Anthropic 모델이라면 즉시 수정했을 것이고 Soul도 같은 스레드에서 해야 할 일을 파악했을 가능성이 높다는 비교가 나왔다.

2. Babysit 요청

   1. 명시적 지시: “그럼 고치고 변경을 푸시한 다음 준비될 때까지 지켜봐. 도대체 뭐 하는 거야?”라는 식으로 재촉했다.
   2. Babysit 스킬: PR을 계속 모니터링하고, CI 실패를 처리하며, main과 최신 상태를 유지하고, 충돌이 나면 rebase하고, 리뷰 봇 댓글이 오면 대응하며, 모든 체크가 초록색이 될 때까지 멈추지 않는 규칙을 담은 스킬이다.
   3. 첫 번째 후속: Astra는 두 리뷰 항목을 수정하고 필수 체크를 통과했다고 보고했다.

3. 모니터링 누락

   1. 남은 댓글: 실제 PR을 확인하자 처리되지 않은 댓글이 더 있었다.
   2. 가능한 원인: 모니터링 하네스, T3 Code, GitHub rate limit 중 하나일 수 있으며, 지나치게 많은 코드를 푸시한 탓에 GitHub rate limit이 가장 유력했다.
   3. 평가: 모니터링이 완전하지 않은 것은 짜증나지만 어느 정도 예상 가능한 문제로 보았다.

4. 같은 실수의 반복

   1. 맥락 보존 실패: 새 댓글이 유효한지 다시 묻자 Astra는 유효하다고 답하면서도 변경을 실행하지 않았다.
   2. 스킬 무시: 바로 앞에서 좋은 처리 방식을 명시했고 Babysit 스킬도 컨텍스트에 있었지만, “그렇게 해야 한다”고 말한 뒤 실행하지 않았다.
   3. 푸시 누락: 결국 수정은 했지만 변경을 원격 저장소에 푸시하지 않았다.

5. 모델·하네스 개선

   1. 문제의 본질: 같은 스레드의 좋은 행동보다 과거의 나쁜 행동을 더 강하게 재현한 점이 핵심 문제였다.
   2. OpenAI의 대응: 모델, 하네스, 시스템 프롬프트 등 여러 계층을 수정해 이런 행동을 줄였다.
   3. 현재 상태: 새 스냅샷에서 해당 모서리의 성능은 의미 있게 좋아졌지만 나쁜 행동이 완전히 제거된 것이 아니라 발생 빈도가 줄었을 뿐이다.

7.3. 과잉 설계와 리뷰 루프

1. Soul 대비 개선

   1. PR 범위: Soul은 문제를 해결해도 불필요한 테스트를 추가하고 PR을 과도하게 키우며 원래 요청을 넘어서는 일이 많았다.
   2. Astra의 절제: Astra는 변경 범위를 더 잘 이해하고 상대적으로 절제된 결과를 만든다.
   3. 병합 신뢰: Soul은 해결 과정에 엉망을 남기는 경우가 있어 직접 병합하기 어려웠지만 Astra 변경은 어느 정도 자신 있게 병합할 수 있다.

2. Astra의 반복 결함

   1. 리뷰 루프: 리뷰 댓글이 충분히 많이 쌓이면 Astra도 루프에 갇혀 빠져나오기 어려워진다.
   2. 완료 지연: T3 Code 스레드에서 Astra 사용 비중이 높은 이유는 작업량뿐 아니라 스레드가 완료되지 않아 오래 남기 때문이기도 하다.
   3. 비용 대비 판단: 품질이 매우 높은 작업과 Astra만 수행할 수 있는 작업이 존재하지만, 자동 병합 전에는 여전히 사람이 확인해야 한다.

3. 코드 성능의 비교 과제

   1. SWE 벤치마크: DeepSWE 계열 결과에서 Astra X High가 74.1%를 기록했고 Max는 73%로 낮아졌다.
   2. Google 모델: Gemini 3.8 Flash도 73.8%를 기록했다.
   3. Anti-gravity: Google이 T3 Code에 Anti-gravity를 추가할 수 있도록 허가해 Gemini 3.8 Flash High를 예상보다 많이 사용하게 되었고, 문제는 있지만 능력은 확인했다.
   4. 후속 비교: Cloud Code와 Codex 사용 비율을 90% Codex·10% Cloud로 바꿀지에 대한 답은 Fable 대 Astra 후속 영상에서 다룰 예정이다.

주요 발언 모음

“GPT-6은 다음 세대다. OpenAI가 해냈다.”

“Codex는 이제 내 컴퓨터를 나보다 더 많이 사용한다.”

“Astra는 3D 작업에서 다른 모델과 비교하는 것 자체가 불공평하게 느껴질 정도로 앞서 있다.”

“나쁜 행동이 사라진 것이 아니라 줄어든 것이다.”

“오랫동안 썩어 있던 레거시 앱을 이제 며칠 만에 대체할 수 있다.”

“Astra를 특별하게 만드는 것은 역대 최고의 코드 모델이라는 점이 아니라, 다른 많은 영역에서 너무 앞서서 AGI처럼 느껴진다는 점이다.”

“내가 컴퓨터를 맡길 수 있다고 정해 둔 기준은 이제 우스꽝스럽게 느껴질 만큼 낮았다.”

“어느 시점에 모델의 작업을 계속 확인하지 않고 스스로 하게 둘 것인가?”

핵심 데이터 & 수치

• 실제 추론 사용량: 최근 몇 주 약 330,000달러이며 대부분 GPT-6 Astra에 사용되었다.
• API 가격: 입력 100만 토큰당 10달러, 출력 100만 토큰당 50달러다.
• Fast Mode: 표준 처리보다 최대 2배 빠르고 약 2배 비싸다.
• 캐시 읽기: Astra는 100만 토큰당 1달러, Fable 5.1은 0.25달러다.
• 컨텍스트 창: 최대 100만 토큰이며, Codex에서는 약 370K 범위가 먼저 제공될 전망이다.
• 비용 증가 구간: 272K 토큰 초과 시 입력은 2배, 출력은 50% 더 비싸질 수 있다.
• Terminal Bench 과학 버전: Fable 5.1 Medium은 15달러·36%, Astra Low는 11달러·54%다.
• ARC-AGI: Astra는 99.9%에 도달했고 96%의 레벨에서 인간 행동 효율 기준을 넘었다.
• Frontier Math: Fable 5.1 최고점은 87.8%, Astra는 Low에서 이를 맞추고 Medium 이상에서 약 100%에 도달했다.
• OSWorld 2.0: Astra High는 약 23분에 71.6%, Soul 최고점은 65.7%에 약 75분이 걸렸다.
• 컴퓨터 사용 속도: Astra와 Codex 조합은 작업 완료 속도가 약 1.9배 빠르다고 주장된다.
• 의료 기록 작업: 느린 대시보드에서 약 150페이지를 약 15분에 처리했다.
• BenchCAD: Astra는 2달러 미만에 96%, Fable은 11달러 이상에 84%였다.
• Exploit Bench: Astra Low는 100%·28달러, Soul Max는 78.5%·37.17달러였다.
• 안전 스트레스 테스트: Fable 9.5%, Astra 2.4%로 낮을수록 좋다.
• Lakebed 성능: 특정 지연이 800ms에서 30ms 미만으로 감소했고, 많은 경로의 P95가 98% 줄었다.
• Lakebed 자동화: 개선 작업은 핵심 프롬프트 두 개와 여러 서브에이전트로 진행되었다.
• 앱 클론: Plex는 약 5개 프롬프트로 실사용 수준, 약 8개로 경쟁 제품을 앞선 수준에 도달했다.
• 출시 제한 보상: Astra에 접근하지 못한 날마다 Codex 구독에 뱅크 리셋 하나가 제공될 예정이다.

결론 및 시사점

1. 평가 단위를 바꿔야 한다: 텍스트 품질이나 단일 벤치마크 점수보다 도구를 사용해 실제 작업을 완료하는지, 작업당 비용이 얼마인지, 긴 작업에서 제약을 유지하는지를 평가해야 한다.
2. 컴퓨터 사용이 가장 큰 차별점이다: Excel·PowerPoint·의료 대시보드처럼 사람이 직접 조작해야 했던 인터페이스를 빠르게 탐색하고 완료하는 능력이 업무 자동화의 병목을 낮춘다.
3. 3D 제작의 진입장벽이 무너진다: Blender·CAD·Unreal Engine을 연결해 게임과 보행 가능한 세계를 만들면서 소규모 개인 제작자가 과거 팀 단위로 필요했던 결과를 만들 수 있다.
4. 레거시 소프트웨어가 빠르게 교체된다: 음악 블로그, Plex, macOS의 핵심 경험처럼 오래 방치된 앱을 며칠과 몇 개의 프롬프트로 실사용 가능한 형태로 다시 만들 수 있다.
5. 스웜과 장기 실행이 생산성을 확장한다: 자기 프롬프팅, 서브에이전트 병렬화, 자체 테스트와 PR 조율이 결합되면 한 모델이 작은 개발팀처럼 움직인다.
6. 신뢰는 무조건적인 위임이 아니다: Astra는 Soul보다 절제되고 안전하지만 리뷰 댓글을 인지하고도 수정·푸시하지 않는 사례가 있었으므로, PR과 운영 변경에는 여전히 사람의 검증이 필요하다.
7. 영역별 강점이 다르다: 컴퓨터 사용과 3D에서는 Astra가 압도하지만, 프런트엔드 디자인과 영상 편집에서는 Fable과 전문 편집자가 더 안정적이다.
8. 제품 접근성이 혁신의 전제다: 발표 당일 대부분의 사용자가 모델을 사용할 수 없다면 실제 생산성 혁신이 확산되지 못하며, 리셋 보상은 지연 자체를 대신할 수 없다.
9. AGI라는 표현의 기준이 달라진다: 모델이 글을 쓰는 수준을 넘어 컴퓨터·업무·사업을 직접 운영하고 문제를 장시간 해결하면 LLM이라는 명칭만으로 능력을 설명하기 어려워진다.
10. 신뢰 임계점을 실험해야 한다: 업무마다 검수 중단 기준을 정하고, 반복적으로 결과를 평가해 모델이 실제로 그 기준을 넘었을 때만 자율 실행 범위를 넓혀야 한다.

핵심 요약 (20줄)

1. GPT-6 Astra는 GPT-5.6 Soul보다 세대적으로 앞선 모델로, 코드뿐 아니라 컴퓨터·3D·사무 업무를 직접 수행한다.

2. 최근 몇 주 동안 사용된 약 330,000달러의 추론 비용 대부분이 Astra에 쓰였을 만큼 실제 사용량과 체감 성능이 높았다.

3. Astra의 API 가격은 입력 100만 토큰당 10달러와 출력 100만 토큰당 50달러로 Fable과 거의 같다.

4. 토큰 효율이 높아 긴 작업을 수행해도 실제 작업당 비용은 Fable보다 절반 이하로 내려가는 경우가 많다.

5. 100만 토큰 컨텍스트를 지원하지만 272K를 넘으면 입력과 출력 가격이 상승할 수 있고 Codex 기본값은 더 작다.

6. Astra는 제한된 조직부터 출시되고 ChatGPT Plus·Pro·Business·Enterprise와 API·Amazon Bedrock으로 순차 확대된다.

7. Zero Data Retention과 기업 지원이 제공되지만 Azure가 언급되지 않아 Microsoft와의 관계 변화가 관측된다.

8. Terminal Bench 과학 버전에서 Astra Low는 11달러로 54%를 기록해 Fable 5.1 Medium의 15달러·36%를 크게 앞섰다.

9. ARC-AGI에서 99.9%를 기록하고 96%의 레벨에서 인간 행동 효율 기준을 넘어 새로운 평가 상한을 만들었다.

10. OSWorld 2.0에서 Astra High는 약 23분에 71.6%를 달성해 Soul의 65.7%와 약 75분보다 빠르고 정확했다.

11. 실제 Excel·PowerPoint 조작과 느린 의료 대시보드의 150페이지 기록 다운로드가 컴퓨터 사용 능력을 입증했다.

12. BenchCAD에서 Astra는 2달러 미만으로 96%를 기록해 11달러 이상에 84%인 Fable을 비용과 성능 모두에서 앞섰다.

13. Blender와 Unreal Engine을 연결하는 3D 이해력은 다른 모델과 비교하기 어려울 만큼 뛰어나며 게임 제작도 한 번에 수행한다.

14. 수족관 게임은 물고기·애니메이션·조명·셰이더가 훌륭했지만 이동과 마우스 조작은 여러 번 수정해야 했다.

15. 프런트엔드 디자인은 Soul보다 크게 좋아졌지만 Fable 5.1보다 실수가 많아 실무 UI 목업에는 여전히 격차가 있다.

16. macOS·Spotify·Plex 클론은 소수의 프롬프트만으로 실사용 수준에 도달해 레거시 앱 교체의 속도를 높인다.

17. Lakebed는 Astra의 성능 감사와 스웜 작업으로 800ms 지연을 30ms 미만으로 낮추고 많은 P95 지연을 98% 줄였다.

18. YouTube Shorts 편집은 장면 선택 외에 컷·세로 레이아웃·구성이 나빠 전문 편집팀을 대체하지 못했다.

19. Astra는 리뷰 댓글을 찾고도 수정과 푸시를 누락하는 등 개선된 하네스에서도 모니터링과 후속 조치의 결함을 보인다.

20. Astra의 본질적 도약은 최고의 코드 모델보다 컴퓨터와 업무를 맡길 수 있어 AGI의 맛을 느끼게 한다는 점이다.