GPT-6의 진짜 변화는 '코딩'이 아니라 '엔지니어링 반복'

GPT-6이 주목받는 이유는 단순한 코딩 능력이 아니라 저장소를 읽고 터미널을 열어 코드를 고치고 실행 결과를 확인하는 일을 스스로 처리하는 데 있다. 문제가 나오면 원인을 찾고 테스트까지 도는 반복 과정을 수행한다. 이는 기존 AI 모델들이 할 수 없던 일이다.

단순히 코드를 잘 쓰는 것이 아니라 실패를 이해하고 수정하고 다시 확인하는 엔지니어링 반복 과정에 AI가 더 깊이 들어오기 시작한 것이 핵심이다. 실제 개발에서는 코드를 한 번 쓰는 것으로 일이 끝나지 않는다. 실패를 이해하고 다시 고치고 다시 확인하는 과정이 계속 이어지는데, 이 반복의 단위 자체가 이제 코드 한 줄에서 한 번의 엔지니어링 반복으로 변했다.

OpenAI가 공개한 벤치마크에서 GPT-6 아스트라는 터미널 도구를 쓰는 과제에서 57.9%의 정답률을 기록했고, GPT-4o는 37.3%였다. 20.6%포인트의 큰 격차다. 내부 데이터베이스 마이그레이션 과제에서도 63.9% 대 42.7%로 21.2%포인트 차이가 났다. 둘 다 GPT-6의 압도적 우위를 보여준다.

그런데 실제 소프트웨어 엔지니어링 평가(SWE-Bench)에서는 상황이 다르다. GPT-6 아스트라가 74.1%, GPT-4o가 72.7%로 겨우 1.4%포인트 차이다. 터미널·마이그레이션 과제는 답을 만드는 일로 끝나지 않는다. 현재 환경을 읽고 파일 문제를 찾고 수정 후 실행해야 하며, 실패하면 이유를 보고 다시 수정하고 테스트 통과를 확인해야 한다. 이런 반복적 검증 단계에서는 두 모델의 차이가 줄어든다.

GPT-6의 진정한 변화를 이해하려면 단순 코딩 능력이 아니라 개발 프로세스의 어느 단계에서 가장 큰 개선이 일어나는지 묻는 것이 핵심이다. 질문 자체가 바뀐다. GPT-6가 코드를 쓸 수 있느냐가 아니라 소프트웨어를 만드는 과정 중 어디가 가장 크게 달라지고 있느냐는 질문이 된다.

터미널 과제와 데이터베이스 마이그레이션 과제는 주어진 환경을 읽고 문제를 찾아 수정하고 실행하고 다시 확인하는 과정을 요구한다. 이것은 코드 생성만이 아니라 문제 해결의 반복적 사이클 전체다. 그리고 OpenAI의 벤치마크에서 보는 바와 같이, 이 반복적 사이클에서 GPT-6의 성능이 눈에 띄게 뛰어나다.

실험 횟수도 기록적인 수준이었다. 같은 시간에 더 많은 시도를 병렬로 수행할 수 있도록 연구 방식이 이동 중이라는 뜻이다.

이는 단순히 코드 작성 속도의 문제가 아니다. AI 에이전트가 실험을 설계하고 실행하고 결과를 평가하고 다음 실험에 피드백하는 전체 사이클을 자동으로 도는 것이 가능해졌다는 의미다. 연구팀의 인원 구성이 같아도 더 많은 아이디어를 시도해볼 수 있고, 실패를 더 빨리 발견할 수 있게 된다.

이것은 인간이 개입해 판단하는 과정을 자동화한 것이다.

AlphaProof는 Informatics 학습의 핵심 행렬 곡선을 23% 개선했고 전체 학습 시간은 약 1% 단축했다. 눈에 띄게 큰 개선이 한 지점에서는 나온 반면, 전체 시간 단축은 적은 이유는 다른 병목이 있기 때문이다. 그래도 핵심은 확실하다. 자동 평가와 선택이 가능해지면, 더 많은 변형을 더 빠르게 시도할 수 있다.

더 현실적인 변화는 측정하고 자동으로 평가할 수 있는 평가 엔진이 싸고 빨라졌다는 점이다.

AI가 다음 실험을 혼자 설계했다는 뜻은 아니다. 누군가는 여전히 어떤 실험을 해볼 만한지, 어떤 파라미터를 시도할 만한지를 결정해야 한다. 하지만 컴퓨터 비용 증가도 있었지만 방향은 분명하다. AI 가치가 코드 생성에서 끝나지 않고 더 많은 실험을 더 빨리 수행하는 데서 나온다는 것이다.

테슬라 FSD는 도로 장면을 이해하는 신경망이 있고, 판단을 만드는 자율주행 알고리즘이 있으며, 모델이 차 안에서 제시간에 안정적으로 실행되게 하는 저수준 코드도 있다. 과거 주행 기록·시뮬레이션·실제 하드웨어 테스트·회귀 검사가 뒤에 붙는다. 우리는 FSD 진전을 더 큰 신경망 하나를 학습하는 일로 생각하기 쉽지만, 테슬라가 공개한 자료를 보면 FSD는 운전 모델 하나로 끝나는 시스템이 아니다.

모델을 고쳤다고 바로 차에 넣을 수 없다. 과거 장면과 가상 환경에서 다시 확인하고 실제 차량 주행에서도 문제가 없는지 봐야 한다. 이것이 바로 앞서 본 OpenAI와 Google DeepMind의 자동 평가·선택·재실험 루프와 같은 구조다.

테슬라가 강화학습·비전 인코더·컴파일러·런타임 기반 변화를 공식적으로 설명한 시점은 올해 4월 FSD v14.3 출시 때다. 9월에 기록된 v14.3.9는 14.3 계열의 최신 배포판이며 기반 변화가 처음 들어간 버전은 아니다.

테슬라는 강화 학습 단계를 개선하고 저시성 환경을 위한 비전 인코더를 강화했다. 모델 반복을 빠르게 하기 위해 AI 컴파일러를 바꾸고 실행 런타임을 다시 써서 추론 지연을 최대 20% 줄였다고 공개했다.

이것은 여러 차원에서의 동시 최적화를 의미한다. 신경망 자체뿐 아니라 그 신경망을 만드는 학습 방식, 신경망이 보는 세상의 표현, 신경망을 차에서 실행하는 소프트웨어 모두가 개선 대상이 되었다. 앞서 본 OpenAI의 에이전트 작업일 증가와 Google DeepMind의 자동 평가 루프와 같은 논리다.

테슬라가 말한 20%는 차량 전체 반응 시간이 20% 빨라졌다는 뜻이 아니다. 제동이나 안전성이 20% 좋아졌다는 숫자도 아니다. 테슬라가 말한 것은 차 안에서 모델 계산을 실행하는 시간, 즉 추론 지연이다.

이 구분이 중요한 이유는 실제 차량의 반응시간은 센서 입력에서 물리적 제어까지 여러 단계를 거치기 때문이다. 신경망의 추론 지연만 20% 줄어도 의미가 있지만, 그것이 차량 전체 성능의 20% 개선은 아니라는 뜻이다.

FSD 진전이 운전 모델의 크기나 데이터만으로 결정되지 않는다는 점을 테슬라가 스스로 보여주기 때문에 이 구분이 중요하다. 모델을 만드는 컴파일러와 모델을 실행하는 런타임도 제품의 일부가 된 것이다.

이는 AI 시스템의 개선이 이제 신경망만의 개선이 아니라 신경망을 만들고 실행하는 전체 인프라의 개선까지 포함한다는 뜻이다. 그리고 이런 다층적 최적화야말로 AI 에이전트가 가장 효과적으로 작동할 수 있는 환경이다. 각 단계에서 측정 가능한 성능 지표가 있고, 각 단계를 자동으로 개선하고 평가할 수 있기 때문이다.

이것은 테슬라가 이미 GPT-6이나 Codex를 FSD 개발에 쓴다는 이야기가 아니다. 그런 공개 근거는 없다. 오늘의 질문은 특정 모델을 누가 쓰고 있느냐가 아니라 테슬라가 공개한 개발 고리 중 어떤 부분이 더 에이전트 친화적으로 바뀔 수 있느냐는 것이다.

FSD 개발은 소프트웨어 개발이면서 동시에 현실 세계를 상대하는 개발이다. 실제 도로에서 드문 문제가 발견되면, 그 장면을 찾고 어떤 상황이 중요한지 고르고 가설과 코드를 만든다. 대규모 학습을 돌린 뒤 기록된 장면으로 평가하고 시뮬레이션과 실제 하드웨어에서 다시 확인한다. 차량에 배포한 뒤 현실에서 어떤 일이 벌어지는지 다시 보고, 그 결과가 다음 데이터가 된다.

이것은 앞서 본 OpenAI의 에이전트 작업일과 Google DeepMind의 자동 평가 루프와 닮아 있으면서도 다르다. AI 에이전트가 문제를 찾고 해결하는 과정이 있지만, 현실의 데이터와 차량 검증이 거기에 추가되어 있다. 이 추가 단계들이 바로 AI 에이전트가 자동화할 수 없는 부분이다.

AI 에이전트가 FSD를 크게 가속할 수 있다는 말은 반은 맞지만 FSD 전체가 같은 비율로 빨라진다는 뜻은 아니다. 소프트웨어 병목은 줄어줄 수 있어도 현실의 데이터와 검증은 마지막 제약으로 남는다.

테슬라의 FSD 개발 구조를 보면 실제 도로에서 문제가 발견되는 것이 가장 처음 단계다. 그 이후 코드 작성·학습·테스트·배포는 AI 에이전트가 도울 수 있다. 하지만 실제 도로의 데이터는 여전히 인간이 차량에서 수집해야 한다. 시뮬레이션도 현실과 완벽히 같을 수 없다. 따라서 AI 에이전트는 발견된 문제를 더 빨리 처리하게 할 수는 있지만, 새로운 문제를 발견하는 속도 자체는 높이지 못한다.

AI가 초안을 빨리 만들더라도 검토와 검증, 다시 고치는 비용, 코드 베이스의 맥락을 이해하는 시간이 더 큰 병목이 될 수 있다는 점은 남는다.

이것은 오류 비용이 큰 시스템에서 더 심하다. FSD처럼 사람의 목숨이 걸린 시스템이라면, AI가 만든 코드의 검증 비용은 더 클 수밖에 없다. 따라서 AI 에이전트가 FSD 개발을 가속하려면 단순히 코드 작성만 빨라서는 안 된다. 검증·디버깅·통합 같은 전체 과정이 더 효율적으로 흘러야 한다.

하지만 AI가 FSD를 만드는 공장이 일부러 더 빠르게 만들 수 있다. 무엇이 잘못되는지 이해하고 고치고 테스트하고 이전 결과와 비교하고 버리거나 남기고 다시 반복하는 과정이다. 이 과정의 비용이 낮아지면 같은 팀도 더 많은 실험을 알고 실패를 더 빨리 발견할 수 있다.

실제 데이터와 대규모 학습, 차량 검증은 사라지지 않는다. 다만 현실에서 문제가 발견된다면 그 문제를 개발 시스템 안에서 다시 다루는 속도는 더 빨라질 수 있다. 이것이 OpenAI의 연구팀에서 보인 3.1배의 에이전트 작업일이 현실적으로 의미하는 바다. 같은 인력으로 더 많은 반복을 더 빠르게 도는 것이다.