GPT-6 Astra 발표: 화면 조작·코딩·사이버 능력을 업무에 나누어 읽기

AI가 코드를 작성하는 것과, 그 코드를 실행하고 화면에서 결과를 확인하는 것은 다른 일입니다. 개발자는 수정안을 받아도 브라우저를 열어 동작을 확인하고, 실패한 테스트를 해석하고, 빠진 요구사항을 다시 알려줘야 했습니다. GPT-6 Astra 발표에서 눈여겨볼 변화는 이런 여러 단계를 하나의 작업으로 이어서 수행하는 능력입니다.

OpenAI는 2026년 9월 초 Astra를 공개하며 컴퓨터 사용, 소프트웨어 개발, 전문 업무와 과학 분야의 성능 향상을 강조했습니다. 이 글에서는 화면 조작과 코딩이 어떻게 연결되는지, 벤치마크 숫자는 무엇을 뜻하는지, 실제 사용 비용에는 어떤 조건이 붙는지 살펴봅니다. 공식 발표

Astra의 기본 사양, 긴 문맥과 최신 정보는 다르다

API 모델 이름은 gpt-6-astra입니다. 공식 문서의 주요 사양은 아래와 같습니다. 이 값은 API 모델 기준이며, 개별 앱이 제공하는 기능과 사용 한도는 별도로 봐야 합니다.

항목	공식 문서 기준
컨텍스트 창	1,050,000토큰
최대 출력	128,000토큰
지식 마감	2026년 4월 30일
입출력	텍스트 입출력, 이미지 입력
추론 강도	low · medium · high · xhigh · max

컨텍스트가 크다는 것은 한 요청에서 다룰 수 있는 자료의 범위가 넓다는 뜻입니다. 저장소의 여러 파일과 설계 문서를 함께 비교할 때 도움이 될 수 있습니다. 하지만 자료를 많이 넣는 것만으로 필요한 사실을 빠짐없이 활용하거나 최신 사건을 저절로 알게 되는 것은 아닙니다. 최신 정보는 검색이나 제공한 자료로 보완해야 합니다. 모델 사양

예를 들어 장애 원인을 찾을 때 전체 로그를 무작정 넣는 대신 발생 시각, 정상 요청과 실패 요청의 차이, 관련 변경 이력을 묶어 주면 검토 대상을 더 분명하게 만들 수 있습니다. 긴 문맥의 실용적인 가치는 자료의 양을 늘리는 데서보다, 서로 떨어진 근거를 연결하는 데 있습니다.

화면을 이해하는 능력이 업무 완료와 연결되는 방식

공식 발표는 온라인 폼 입력, 고객 정보 갱신, 일정 정리, 조사와 프론트엔드 QA를 활용 사례로 제시합니다. OSWorld 2.0 지연 시뮬레이션에서는 Astra가 약 40분에 72.6%, GPT-5.6 Sol이 약 75분에 65.7%를 기록했다고 밝혔습니다. 이는 해당 평가 조건의 결과이며, 모든 업무가 40분에 끝난다는 뜻은 아닙니다. 컴퓨터 사용 평가

가령 관리 화면에 검색 필터를 추가하는 작업을 생각해 보겠습니다. 코드가 컴파일돼도 검색 결과가 잘못 정렬될 수 있고, 빈 결과 안내가 빠질 수 있으며, 작은 화면에서 버튼이 가려질 수도 있습니다. 화면을 직접 다루는 도구와 연결된 모델이라면 입력·클릭·결과 확인을 이어서 수행하는 흐름을 설계할 수 있습니다.

여기서 완료 기준은 ‘버튼을 눌렀다’가 아니라 ‘기대한 결과가 나타났다’여야 합니다. 예를 들어 검색어를 지웠을 때 전체 목록으로 돌아오는지, 존재하지 않는 값을 입력하면 빈 상태가 보이는지, 페이지를 바꿔도 필터가 유지되는지까지 정하면 검증 결과를 사람이 판단하기 쉬워집니다. 아래는 도입 시험에 사용할 수 있는 예시입니다.

맡길 작업	함께 받을 결과
웹 화면 수정	변경 화면, 정상·빈 결과·오류 상태의 확인 내용
반복 입력 자동화	처리 건수, 실패한 항목, 중복 여부
자료 조사	주장별 출처, 자료 날짜, 확인되지 않은 부분
문서·표 작성	원본 수치와 결과의 대조, 누락 항목 확인

코딩 에이전트의 평가 기준이 ‘수정 코드’에서 ‘검증 결과’로 넓어진다

Cognition의 Devin 사례는 이 흐름을 잘 보여줍니다. OpenAI가 소개한 협업 사례는 Astra의 컴퓨터 사용과 코드 이해 능력을 테스트 과정에 연결하는 데 초점을 맞춥니다. 여기서 중요한 변화는 패치를 만들었다는 보고에 그치지 않고, 실제 동작을 확인한 자료까지 함께 전달한다는 점입니다. Cognition·Devin 사례

이 관점은 일반 개발팀에도 적용할 수 있습니다. 로그인 오류를 고쳤다면 수정한 함수 목록만 받을 것이 아니라, 어떤 입력에서 문제가 재현됐는지와 수정 뒤 같은 조건에서 무엇이 달라졌는지를 받아야 합니다. 테스트 실행이 불가능했다면 환경 제약과 확인하지 못한 경로를 남겨야 합니다. 실패 기록도 다음 판단에 필요한 결과물입니다.

작업을 지시할 때는 ‘관련 코드를 수정하고 완료해줘’보다 ‘재현 → 수정 → 관련 테스트 → 화면 확인 순서로 진행하고, 실패와 미검증 항목을 포함해 결과를 정리해줘’처럼 완료 조건을 구체화해 볼 수 있습니다. 이는 특정 모델의 성공을 보장하는 주문이 아니라, 결과를 검토할 수 있게 만드는 작업 설계입니다.

벤치마크를 비교할 때 먼저 확인할 세 가지

Astra 발표의 높은 점수는 유력한 비교 근거입니다. 다만 평가 이름이 같아도 도구, 시간 제한, 시행 횟수와 채점 방식이 다를 수 있습니다. 특히 컴퓨터 사용에서는 일부 단계의 성공에 점수를 주는 평가와 전체 과제의 완수를 요구하는 평가를 구분해야 합니다.

첫째, 무엇을 성공으로 세었는지 봅니다. 코드 생성인지, 테스트 통과인지, 실제 화면 동작까지인지에 따라 의미가 달라집니다. 둘째, 어느 정도 자원을 썼는지 봅니다. 추론 강도와 재시도를 늘린 결과를 빠른 기본 설정과 그대로 비교하면 판단이 흔들립니다. 셋째, 우리 업무와 닮았는지 봅니다. 짧은 수정 요청과 며칠치 자료를 읽는 장애 분석은 필요한 능력이 다릅니다.

모델 비교를 시작한다면 같은 작업 묶음에 같은 자료와 제한 시간을 주고, 완료율·사람의 수정 시간·총비용을 함께 기록해 보세요. 첫 응답이 빨라도 사람이 다시 고치는 시간이 길면 업무 전체는 빨라지지 않습니다. 반대로 응답이 조금 늦어도 한 번에 검증 가능한 결과를 받으면 전체 소요 시간은 줄 수 있습니다.

API 요금: 긴 입력에는 별도 단가가 적용된다

표준 처리의 기본 요금은 100만 토큰당 새 입력 10달러, 캐시 입력 1달러, 캐시 쓰기 12.50달러, 출력 50달러입니다. 입력이 272,000토큰을 넘으면 요청 전체에 입력·캐시 요금 2배, 출력 요금 1.5배가 적용됩니다. 큰 컨텍스트를 지원한다는 사실과 같은 단가로 끝까지 사용할 수 있다는 것은 다릅니다. 공식 가격표

가정 계산: 캐시 없는 입력 10만 토큰과 과금 대상 출력 1만 토큰을 사용하는 표준 요청은 1달러 + 0.50달러 = 1.50달러입니다. 입력이 30만 토큰이고 출력이 같다면 긴 입력 요율로 6달러 + 0.75달러 = 6.75달러가 됩니다. 도구 요금·추가 호출·세금 등은 제외한 계산이며, 실제 비용은 청구되는 사용량으로 확인해야 합니다.

따라서 매 단계마다 전체 저장소를 다시 보내기보다, 필요한 파일과 직전 실행 결과를 정확히 전달하는 설계가 중요해집니다. 비용을 낮추기 위해 핵심 요구사항까지 없애면 재작업이 늘 수 있으므로, 정보의 양과 충분성을 함께 봐야 합니다.

강한 사이버 능력과 일반 사용자에게 열린 기능의 경계

OpenAI는 Astra가 자사의 Preparedness Framework에서 사이버보안 Critical 기준에 도달했다고 밝혔습니다. 이는 능력과 위험을 평가하는 분류이며 일반 사용자가 모든 고급 사이버 기능에 접근할 수 있다는 뜻은 아닙니다. 출시 버전은 안전한 코드 검토와 패치 작업을 지원하는 한편, 취약점 공격 실증 코드 생성 같은 고급 작업에는 제한을 둡니다. 안전 개요

업무에 붙일 때는 모델의 능력과 도구의 권한을 구분해야 합니다. 읽기와 분석을 잘 수행한다는 이유만으로 운영 시스템의 변경 권한까지 넓힐 필요는 없습니다. 팀이 소유한 코드와 테스트 환경에서 결함을 확인하고, 수정안을 검토할 수 있는 흐름부터 평가하는 것이 도입 목적에 맞습니다.

Astra를 살펴볼 때 가장 실용적인 질문은 ‘몇 점 더 높은가’에 더해 ‘우리의 어떤 작업을 검증 가능한 상태까지 끝낼 수 있는가’입니다. 코드·화면·문서가 이어지는 업무를 하나 골라, 사람이 다시 손대는 시간과 완료한 작업 한 건의 비용을 재면 발표의 의미를 훨씬 구체적으로 판단할 수 있습니다.

자료 확인: 2026년 9월 18일. 성능 수치는 개발사 발표이며 독립 실측이 아닙니다. 업무 사례와 비용 계산은 설명용 가정입니다.