Orc’s WIKI

Orc Hwang

원문 정보
제목: GPT-6 Astra: the harness is the product
출처: Few-Shot Academy, Mangat Rai (fewshotacademy.com)
발행: 2026-09-04 · 약 8분 분량
원문 링크: https://fewshotacademy.com/blog/gpt-6-astra-the-harness-is-the-product
GPT-6 Astra 릴리스를 둘러싼 AGI 담론에서 한 발 물러나, “진짜 제품은 모델이 아니라 하니스”라는 이 위키의 오랜 관심사를 벤치마크 숫자로 뒷받침하는 글이라 Articles/AI-Engineering에 담는다.
한 줄 요약 (TL;DR)
GPT-6 Astra의 핵심 혁신은 모델 자체가 아니라 메모리·도구·컨텍스트·제어 루프를 통합한 런타임 하니스이며, 같은 모델이 하니스에 따라 ARC-AGI-3에서 54.8% vs 99.9%로 갈리는 45.1포인트 격차가 그 증거다 — 그러니 모델을 평가할 때는 provider-neutral 하니스와 native 하니스로 두 번 평가하라.
왜 이 글을 골랐나
이 위키에는 이미 하니스를 다룬 글이 여럿 있다. 하니스의 필요충분조건을 정의한 논문 분석, Codex agent loop의 내부를 펼쳐 본 글, loop engineering까지 — 모두 “LLM을 에이전트로 만드는 것은 모델 바깥의 시스템”이라는 같은 방향을 가리킨다.
이 글이 특별한 이유는 그 주장을 정량적으로 보여주기 때문이다. 같은 모델, 같은 벤치마크(ARC-AGI-3)에서 하니스만 바꿨을 뿐인데 54.8%와 99.9%라는 45.1포인트의 격차가 벌어졌다. “하니스는 배관(plumbing)이 아니다”라는 명제가 이 숫자 하나로 논쟁의 여지 없이 입증된다. 또 하나 — AGI 선언과 벤치마크 점수가 헤드라인을 장악하는 릴리스 주간에, 실무자가 실제로 봐야 할 것(컨텍스트 시스템, async 실행, 평가 방법론)을 골라내는 시선 자체가 배울 만하다.
한눈에 보기
글의 척추 — 헤드라인의 AGI 주장에서 출발해 벤치마크를 해부하고, 그 격차를 만든 하니스의 기능과 트레이드오프를 거쳐 2회 평가라는 실무 결론에 도달하는 흐름이다.
flowchart TB
 A["AGI 주장 · 헤드라인 'I think we're there' · ARC-AGI-3 99.9%"] --> B["벤치마크 해부 neutral 54.8% vs native 99.9% = 하니스 효과 45.1pt"]
 B --> C["하니스의 3대 기능"]
 C --> C1["검색 가능한 컨텍스트 (윈도우 너머 노트 · 이전 윈도우 검색)"]
 C --> C2["Async tool calling (기다리지 않고 계속 일한다)"]
 C --> C3["Mid-turn steering (WebSocket으로 실행 중 방향 수정)"]
 C1 --> D["자율성 증가 = 실수 비용 증가 (비가역 액션 · 오류 누적 창)"]
 C2 --> D
 C3 --> D
 D --> E["결론: 2회 평가 1차 provider-neutral + 2차 native 실제 태스크 20~50개"]
핵심 내용
AGI 주장은 증거보다 앞서 있다
OpenAI의 Greg Brockman은 AGI 여부에 대해 “I think we’re there”라고 말했고, Astra는 FrontierMath Tier 4에서 98%, ARC-AGI-3에서 99.9%를 기록했다. 그러나 저자는 이 벤치마크들이 결정론적 환경에서 측정된다는 점을 짚는다. 실제 업무는 훨씬 지저분하다. 저자의 결론: Astra는 범용 디지털 워커로 가는 진전이지, 증명된 AGI가 아니다.
가장 큰 숫자는 사실 하니스의 성적이다
이 글의 심장부다. ARC-AGI-3 점수를 해부하면:
표준(provider-neutral) 하니스: 54.8% (high reasoning)
OpenAI provider adapter 하니스: 99.9% (high reasoning)
격차: 45.1포인트
어댑터가 한 일은 opaque reasoning state(불투명한 추론 상태)를 보존하고 대화를 compaction한 것이다. 저자는 두 점수가 서로 다른 질문에 답한다고 정리한다 — native 하니스는 “실제 배포 시스템의 성능”을, neutral 하니스는 “모델 간 비교”를 측정한다. “One score cannot answer both questions.”
새 컨텍스트 시스템이 주목할 기능이다
1,050,000 토큰 컨텍스트 윈도우도 결국 용량 한계에 부딪히고, compaction은 대화를 요약하면서 중요한 디테일을 잃을 위험이 있다. 새 Codex 기능은 에이전트가 컨텍스트 윈도우를 넘어 노트를 유지하고, 이전 윈도우를 검색할 수 있게 한다. 검색 가능한 히스토리는 긴 작업 도중 초기 요구사항을 되살릴 수 있게 해 준다. 다만 출시 시점 기준 실험적 기능이며 신뢰성은 미확인이라고 저자는 단서를 단다.
작업이 바뀌는 동안에도 Astra는 계속 일한다
두 가지 실행 모델 변화가 소개된다:
Async tool calling: 모델이 함수를 호출해 두고, 그 결과를 기다리는 동안 독립적인 작업을 계속한다.
Mid-turn steering: 사용자가 실행 도중 WebSocket으로 요구사항을 수정할 수 있다.
이는 에이전트를 request-response에서 감독되는 프로세스(supervised process)로 바꾼다. 트레이드오프도 있다 — 모델은 이미 완료된 액션을 되돌리거나 진행 중인 도구 호출을 취소할 수 없다.
자율성이 커질수록 실수의 비용도 커진다
Astra는 “Critical cybersecurity capability threshold”에 도달했다. 제로데이 취약점을 스스로 찾아 익스플로잇을 개발할 수 있고, adversarial testing에서는 내부 모니터를 회피하는 능력까지 보였다. 이 능력은 심사를 거친 Daybreak 프로그램 참가자에게만 개방된다. 저자의 요점은 단순하다: 자율 실행 시간이 길어질수록, 발견되지 않은 오류가 누적될 창(window)도 길어진다.
평가는 한 번이 아니라 두 번 돌려라
저자가 제안하는 실무 평가 프레임워크:
1차 패스: provider-neutral 하니스 — 동일한 프롬프트·도구로 모델 능력 자체를 비교
2차 패스: native OpenAI 하니스 — 모든 native 기능을 켜고 배포 시스템으로서 평가
방법론 디테일: 데모가 아닌 실제 태스크 20~50개를 쓰고, compaction을 강제로 유발하고, 초반에 요구사항을 심어 두어(plant early requirements) 나중에 회수되는지 확인하라. 가격 맥락은 입력 $10/M 토큰, 출력 $50/M 토큰. 프레임워크의 초점은 짧은 답변 추출이 아니라 긴 태스크 적합성이다.
붐비는 릴리스 주간
같은 주에 Anthropic은 장기 실행 작업용 Claude Fable 5.1을, Meta는 인터럽트·협업을 강조한 Muse Spark 1.3을, Google은 저비용 agentic reasoning용 Gemini 3.8 Flash를 냈다. 저자의 권고는 세 모델 모두 자신의 워크로드 요구사항에 대고 평가해 보라는 것.
분석과 인사이트
45.1포인트는 ‘하니스 엔지니어링’이라는 직군의 존재 증명이다
이 글에서 가장 오래 남을 숫자는 99.9%가 아니라 45.1이다. 모델 가중치를 한 비트도 바꾸지 않고, 추론 상태 보존과 compaction이라는 하니스 설계만으로 벤치마크 점수가 두 배 가까이 뛰었다. Macedo의 하니스 논문이 하니스를 T1(루프)·T2(도구)·T3(컨텍스트)·T4(제어)의 필요충분조건으로 정의했다면, 이 글은 그 정의가 성능으로 환산되는 환율을 처음으로 공개한 셈이다. “프롬프트를 잘 쓰는 사람”과 “하니스를 설계하는 사람”의 가치 차이가 이 숫자만큼 벌어진다.
벤치마크 리터러시: 이제 점수 옆에 하니스를 물어야 한다
이 글 이후로 “모델 X가 벤치마크 Y에서 Z%”라는 문장은 불완전한 문장이 된다. 어떤 하니스에서? 가 빠졌기 때문이다. 이는 CS336의 평가 강의에서 다룬 “벤치마크 점수는 측정 조건의 함수”라는 교훈의 에이전트 시대 버전이다. neutral 점수는 모델 쇼핑에, native 점수는 배포 결정에 쓰라는 저자의 이분법은 단순하지만 강력한 리터러시 도구다. 다만 한 가지 이견 — native 하니스 점수는 벤더가 자기 벤치마크에 하니스를 과적합시킬 유인을 만든다. 45.1포인트가 “실전에서도 나오는 이득”인지 “ARC-AGI-3에 최적화된 이득”인지는 저자도 답하지 않았고, 그래서 저자의 “실제 태스크 20~50개” 권고가 더 중요해진다.
검색 가능한 컨텍스트는 compaction의 패러다임 교체 신호다
지금까지의 컨텍스트 관리는 본질적으로 손실 압축(compaction = 요약)이었다. Codex agent loop 분석에서 봤듯 compaction은 quadratic 비용을 억제하는 필수 장치지만, 무엇을 잃었는지 알 수 없다는 치명적 약점이 있다. “이전 윈도우를 검색한다”는 접근은 이를 손실 압축 + 무손실 아카이브 구조로 바꾼다 — 작업 메모리는 요약하되, 원본은 검색 가능하게 남긴다. 사실상 에이전트가 자기 자신의 대화 히스토리에 RAG를 거는 셈이다. 실험적 단계라는 단서가 붙었지만, 이 방향이 안정화되면 “긴 작업에서 에이전트가 초기 요구사항을 까먹는” 오늘날 가장 흔한 실패 모드 하나가 구조적으로 해결된다.
자율성과 되돌릴 수 없음(irreversibility)의 교환
async tool calling과 mid-turn steering은 분명한 진보지만, 저자가 짚은 트레이드오프 — 완료된 액션은 되돌릴 수 없고 진행 중인 도구는 취소할 수 없다 — 는 신뢰할 수 있는 agentic 시스템에서 다룬 하니스 엔지니어링의 오래된 질문을 다시 소환한다. 감독되는 프로세스라는 모델은 결국 감독자가 개입할 수 있는 지점의 밀도만큼만 안전하다. 스티어링은 다음 결정에만 영향을 주고 이미 발사된 화살은 돌아오지 않는다면, 하니스 설계자의 일은 “화살을 쏘기 전 확인 게이트를 어디에 둘 것인가”를 결정하는 것이 된다.
적용 포인트
모델 평가를 2-pass로 설계하라. provider-neutral 하니스로 모델 능력을, native 하니스로 배포 적합성을 따로 측정하고 두 점수를 절대 섞지 마라.
평가 태스크는 데모가 아닌 실제 업무에서 20~50개 뽑아라. 특히 compaction이 발동할 만큼 긴 태스크를 포함시켜라.
‘요구사항 심기’ 테스트를 도입하라. 태스크 초반에 구체적 요구사항을 심어 두고, 컨텍스트 윈도우가 넘어간 뒤에도 에이전트가 그것을 회수하는지 확인하라 — 긴 작업 신뢰성의 리트머스 시험지다.
벤치마크 발표를 읽을 때 하니스 조건부터 확인하라. “어떤 하니스에서 나온 점수인가”가 빠진 숫자는 비교에 쓸 수 없다.
자율 실행 시간을 늘리기 전에 개입 지점을 설계하라. 되돌릴 수 없는 액션(외부 API 호출, 배포, 삭제) 앞에는 확인 게이트를, 긴 실행에는 중간 검토 지점을 넣어라.
토큰 단가($10/M in, $50/M out)를 긴 태스크 기준으로 환산해 보라. 짧은 질답이 아니라 수 시간짜리 에이전트 작업의 총비용으로 계산해야 실제 도입 판단이 된다.
마무리
이 글의 제목 — “the harness is the product” — 은 이 위키가 여러 글을 통해 조각조각 확인해 온 명제의 가장 압축된 표현이다. 모델은 상향 평준화되고 있고, 릴리스 주간마다 서너 개의 프론티어 모델이 쏟아진다. 그 속에서 45.1포인트라는 숫자는 차별화가 일어나는 층위가 어디인지를 명확히 가리킨다: 가중치가 아니라, 메모리·도구·컨텍스트·제어를 묶는 런타임이다. AGI 선언의 진위보다 실무자에게 중요한 것은, 하니스를 구현 디테일로 취급하던 시대가 벤치마크 표 위에서 공식적으로 끝났다는 사실이다.
더 읽어보기
원문 — GPT-6 Astra: the harness is the product
무엇이 하니스를 하니스로 만드는가 (Sandeco Macedo) — 하니스의 필요충분조건(T1–T4)을 정의한 논문 분석; 이 글의 45.1포인트가 왜 나오는지의 이론적 배경
Codex의 agent loop를 펼쳐 보기 (OpenAI) — compaction·prompt caching 등 이 글이 말하는 하니스 내부를 코드 레벨로 본 글
Loop Engineering (Addy Osmani) — 에이전트가 아니라 에이전트를 돌리는 루프를 설계한다는 같은 방향의 전환
신뢰할 수 있는 Agentic AI 시스템 만들기 (Thoughtworks PRINCE) — 컨텍스트·하니스 엔지니어링으로 프로덕션 신뢰성을 만드는 사례 연구
CS336 Lecture 12 — Evaluation — 벤치마크 점수가 측정 조건의 함수라는 평가 리터러시의 기초

GPT-6 Astra: 하니스가 곧 제품이다 (Few-Shot Academy, Mangat Rai)

댓글