AI에게 일을 맡길 때 가장 답답한 순간은 답변을 조금 늦게 받을 때만이 아닙니다. 검색 하나를 기다리느라 다른 작업도 멈추고, 중간에 조건을 바꾸면 처음부터 설명해야 하며, 끝났다는 보고를 받은 뒤 빠진 내용을 사람이 다시 채울 때도 답답합니다. 모델이 어려운 문제를 푸는 능력과 우리가 일을 맡기기 편한 정도 사이에는 이런 간격이 있습니다.
GPT-6 Astra에서 주목할 변화는 그 간격을 줄이려는 방향입니다. 도구의 결과를 기다리는 동안 별도의 일을 진행하고, 진행 중인 작업에 새 지시를 반영하며, 같은 대화 안에서 생각하는 강도를 조절할 수 있게 됐습니다. 복잡한 과제를 맡기는 사용자라면 단순한 대화 성능보다 이 변화가 더 크게 다가올 수 있습니다.
비교 상대인 Claude Fable 5.1도 장시간 코딩과 지식 업무를 겨냥한 모델입니다. 그래서 “Astra가 모든 면에서 이겼다”는 결론은 적절하지 않습니다. 이 글은 2026년 9월 7일 확인한 양사의 공식 문서를 바탕으로 개선 방향을 비교한 분석이며, 두 모델을 같은 환경에서 직접 실행한 성능 실험은 아닙니다. 아래 업무 사례와 비용 계산은 차이를 설명하기 위해 구성한 가상 예시입니다.
먼저 구분할 것: 이전 GPT보다 좋아진 점과 Fable보다 나은 점
OpenAI는 Astra의 개선 분야로 소프트웨어 개발, 브라우징, 컴퓨터 사용과 전문 업무를 제시합니다. 일부 평가에서 이전 모델보다 적은 출력 토큰으로 더 좋은 결과를 얻었다고도 설명합니다. 그러나 이것은 OpenAI의 공식 평가 설명이며, 모든 업무에서 Fable 5.1보다 빠르고 저렴하다는 의미가 아닙니다.
특히 컴퓨터 사용, 구조화된 출력, 프롬프트 캐시와 긴 대화의 압축은 Astra에서 처음 생긴 기능이 아닙니다. GPT-5.6에도 있던 기능을 신제품의 독점적인 장점처럼 나열하면 비교가 흐려집니다. Astra의 새 기능과 이어받은 기능은 OpenAI 모델 가이드에서 구분할 수 있습니다.
이 글의 판단 기준은 세 가지입니다. 새 기능이 사람의 개입을 줄이는가, 같은 결과를 얻는 데 드는 전체 비용이 줄어드는가, 변경된 요구를 반영하면서도 결과물을 신뢰할 수 있는가입니다. 첫 번째와 세 번째는 단가표만으로 알 수 없고, 두 번째는 모델 이름만으로 결정되지 않습니다.
첫 번째 개선: 기다리는 동안에도 일을 이어 갈 수 있다
Astra의 비동기 도구 호출은 외부 도구가 실행되는 동안 모델이 다른 추론이나 독립적인 도구 호출을 이어 갈 수 있게 합니다. API에서 도구에 비동기 실행을 설정하고, 나중에 원래 호출 식별자에 맞춰 결과를 돌려주는 방식입니다. 도구 실행과 대기 작업 관리는 여전히 애플리케이션이 맡습니다. 모델을 바꿨다고 기존 프로그램의 모든 작업이 자동으로 병렬화되는 것은 아닙니다. 공식 비동기 도구 호출 문서가 이 책임 구분을 설명합니다.
가령 기업 분석 보고서를 만드는 상황을 생각해 봅시다. 공시 파일을 내려받는 데 시간이 걸리더라도 이미 확보한 자료로 목차를 정리하거나 비교할 기업 목록을 확정하는 일은 먼저 할 수 있습니다. 반면 매출액을 읽기도 전에 성장률을 계산하는 일은 하면 안 됩니다. 동시에 할 수 있는 부분과 선행 결과가 필요한 부분을 나누는 것이 핵심입니다.
쉽게 말하면 주방에서 물이 끓는 동안 채소를 손질하는 방식입니다. 물이 끓기만 기다리던 시간은 줄일 수 있지만, 아직 익지 않은 재료를 완성된 음식으로 내놓을 수는 없습니다. AI 업무에서도 시간을 아끼는 만큼 결과가 도착한 뒤 앞선 판단과 충돌하지 않는지 확인하는 과정이 필요합니다.
Fable 5.1 역시 장시간·비동기 업무를 목표로 합니다. 따라서 “Fable은 하나씩만 일한다”는 비교는 맞지 않습니다. Astra에서 눈에 띄는 부분은 이 동작을 Responses API의 명시적인 기능으로 사용할 수 있다는 점입니다. 실제 속도 차이는 연결한 도구, 서버 자원, 작업 의존관계와 구현 방식에 따라 달라집니다.
두 번째 개선: 작업 중간에 방향을 고치기 쉬워졌다
Astra의 mid-turn steering은 모델이 작업하는 동안 추가 지시를 전달하는 기능입니다. 공식 API 문서는 WebSocket 연결에서 완료된 작업을 유지하며 새 지시를 후속 진행에 포함하는 흐름을 설명합니다. 실제 앱에서 어떤 입력 화면으로 제공되는지는 앱의 구현과 지원 범위에 달려 있습니다. 작업 중 지시 변경 문서에서 동작을 확인할 수 있습니다.
예를 들어 “임원 보고용으로 작성해 달라”고 맡긴 뒤, 중간에 독자가 신규 입사자로 바뀌었다고 합시다. 이미 확인한 매출이나 제품 정보는 유지하면서 설명의 깊이와 용어를 바꾸면 됩니다. 조사 전체를 다시 시작할 필요가 줄고, 마지막 결과를 받은 뒤 대대적으로 재작성하는 낭비도 줄일 여지가 있습니다.
다만 새 지시는 이미 발생한 외부 작업을 저절로 취소하는 마법이 아닙니다. 이메일이 이미 발송됐거나 데이터가 저장된 뒤라면 별도의 복구 절차가 필요합니다. 그래서 이 기능의 가치는 특히 아직 작성 중인 코드, 문서 구조, 분석 대상과 표현 방식을 바꾸는 과정에서 큽니다.
Fable과 비교할 때도 수정 지시를 이해할 수 있느냐만 보면 부족합니다. 사용 중인 도구가 실행 도중 지시를 받을 수 있는지, 기존 작업 결과가 얼마나 유지되는지, 바뀐 조건이 이후 모든 단계에 적용되는지를 함께 봐야 합니다. 모델의 지능과 모델을 감싼 프로그램의 기능이 합쳐져 협업 경험을 만듭니다.
세 번째 개선: 같은 대화 안에서 추론 강도를 바꾼다
Astra는 대화 도중 추론 강도를 변경하면서 기존 프롬프트 접두부와 캐시를 유지하는 기능을 안내합니다. 앞부분의 지시를 다시 작성하지 않고 설정 변경 항목을 전달하는 방식입니다. 지원하는 추론 강도에는 low부터 max까지가 있으며, 생각을 완전히 끄는 none은 지원하지 않습니다. 이는 앞서 연결한 OpenAI 모델 가이드에 명시된 기능입니다.
실무에서는 모든 순간에 최대한 오래 생각할 필요가 없습니다. 처음에 폴더를 확인하고 자료를 모으는 단계는 비교적 단순합니다. 서로 모순되는 계약 조건을 해석하거나 간헐적인 장애 원인을 찾는 단계는 더 깊은 검토가 필요합니다. 문제가 해결된 뒤 결과를 정리하는 단계에서는 다시 부담을 낮출 수 있습니다.
이때 중요한 것은 설정 이름보다 결과입니다. 높은 강도를 지정해도 출처가 틀리거나 필요한 테스트가 빠지면 좋은 결과가 아닙니다. 반대로 낮은 강도로 요구를 정확히 만족했다면 굳이 더 많은 연산을 쓰지 않아도 됩니다. 어려운 판단에만 자원을 집중할 수 있다는 점이 운영상의 장점입니다.
Fable 5.1은 공식 모델 표에서 적응형 사고를 항상 사용하는 모델로 표시됩니다. 양사의 추론 방식과 설정 이름은 같지 않으므로 두 모델에 high를 지정했다는 사실만으로 동일한 연산량을 썼다고 볼 수 없습니다. 비교 실험에서는 이름을 맞추기보다 시간·비용 한도와 결과물의 합격 기준을 맞춰야 합니다. Claude 모델 사양이 비교의 출발점입니다.
긴 문서를 읽는 능력은 용량만으로 결정되지 않는다
공식 사양상 Astra의 컨텍스트 창은 105만 토큰이고 최대 출력은 12만8,000토큰입니다. Fable 5.1은 컨텍스트 100만 토큰과 최대 출력 12만8,000토큰을 안내합니다. 텍스트와 이미지를 입력받는 것도 두 모델의 공통점입니다. Astra 모델 사양과 Claude 모델 표 기준입니다.
두 모델 모두 대량의 자료를 다룰 수 있는 범주에 들어갑니다. 그러나 컨텍스트가 약 5% 더 크다는 사실을 독해 정확도가 5% 더 높다는 뜻으로 바꾸면 안 됩니다. 각 회사의 토큰 계산 방식도 다르고, 자료가 길어질수록 중요한 근거를 정확히 찾아 연결하는 능력이 더 중요해집니다.
수백 쪽짜리 문서를 읽힐 때는 마지막에 그럴듯한 요약을 내놓았는지보다 작은 예외 조항을 놓치지 않았는지 봐야 합니다. 본문과 부록의 날짜가 다를 때 차이를 지적하는지, 표 안의 단위를 잘못 읽지 않는지, 질문과 직접 관련 없는 문장을 근거로 가져오지 않는지가 실제 품질을 가릅니다.
또한 더 많이 넣는 방식이 항상 좋은 것은 아닙니다. 먼저 자료의 종류와 질문을 좁히고 필요한 부분을 찾게 하면 비용과 검토 부담을 함께 줄일 수 있습니다. 큰 컨텍스트는 필요한 순간에 쓸 수 있는 여유이지, 매 요청을 가득 채우라는 권장량은 아닙니다.
Fable 5.1의 강점도 분명하게 봐야 한다
Anthropic은 Fable 5.1을 장시간 코딩, 여러 앱을 거치는 업무, 문서와 시각 자료 해석에 적합한 모델로 소개합니다. 작업을 계획하고 실패에서 복구하며 진행 상황을 전달하는 능력을 강조합니다. 따라서 Astra의 긴 작업 수행 능력을 소개하면서 Fable을 단순 채팅 모델처럼 취급할 이유는 없습니다. Fable 공식 소개에서 확인할 수 있는 방향입니다.
비교할 때 특히 구체적인 Fable의 장점은 캐시 읽기 가격입니다. 같은 긴 문서를 반복해서 참조하는 대화에서는 처음 자료를 입력한 비용보다 이후 수십 차례 되읽는 비용이 더 크게 쌓일 수 있습니다. 이 구간의 가격 차이는 구현과 사용량이 같다는 조건에서 계산할 수 있습니다.
이미 Claude 기반 도구와 문서 흐름이 잘 갖춰진 조직이라면, 새 모델이 나왔다는 이유만으로 전체 환경을 옮길 필요는 없습니다. 기존 업무의 성공률이 충분한지, 자주 실패하는 과제가 무엇인지부터 살펴야 합니다. 모델 교체에는 프롬프트 조정, 도구 연결, 평가와 사용자 교육에 드는 운영 부담도 있습니다.
반대로 여러 외부 도구를 연결한 자체 에이전트를 개발한다면 Astra의 작업 중 지시 변경과 비동기 호출이 설계를 단순하게 만들 여지가 있습니다. 이는 특정 벤치마크 우승보다 시스템을 개발하고 관리하는 사람에게 중요한 장점일 수 있습니다.
기본 단가는 같지만 계산서는 달라진다
다음 표는 확인일 기준 표준 API 텍스트 토큰 요금입니다. 월 구독료와는 다른 가격이며, 표의 단위는 100만 토큰당 미국 달러입니다.
| 항목 | GPT-6 Astra | Claude Fable 5.1 |
|---|---|---|
| 일반 입력 | 10달러 | 10달러 |
| 출력 | 50달러 | 50달러 |
| 캐시 읽기 | 1달러 | 0.25달러 |
가격 근거는 Astra 요금표와 Claude 공식 요금표입니다. 캐시를 처음 만드는 비용, 유지 시간, 장문 할증, 지역·처리 방식과 도구 비용은 별도로 봐야 합니다.
Astra는 입력이 27만2,000토큰을 넘는 요청에 대해 요청 전체의 입력·캐시 요율을 2배, 출력 요율을 1.5배 적용한다고 안내합니다. 최대 컨텍스트와 일반 단가 적용 범위를 혼동하지 않아야 합니다. Fable의 캐시도 초기 저장이 무료가 아니며 5분·1시간 저장 조건에 따른 요율이 다릅니다.
가상 계산을 해 보겠습니다. 이미 캐시가 만들어진 뒤의 한 요청에서 새로운 입력 2만 토큰, 캐시 읽기 18만 토큰, 청구 대상 출력 1만 토큰을 사용했다고 가정합니다. 최초 캐시 저장, 외부 도구와 별도 서비스 비용은 제외하며 기본 요율을 적용합니다.
| 계산 항목 | Astra | Fable 5.1 |
|---|---|---|
| 새 입력 2만 토큰 | 0.20달러 | 0.20달러 |
| 캐시 읽기 18만 토큰 | 0.18달러 | 0.045달러 |
| 출력 1만 토큰 | 0.50달러 | 0.50달러 |
| 해당 요청 합계 | 0.88달러 | 0.745달러 |
이 조건에서는 Fable이 약 15.3% 저렴합니다. 캐시 읽기 단가가 75% 낮다고 해서 전체 요청도 75% 저렴해지는 것은 아닙니다. 전체 비용에서 캐시가 차지하는 비중이 다르기 때문입니다.
반대로 Astra가 같은 품질을 청구 대상 출력 7,300토큰으로 완성한다면 해당 계산은 0.745달러가 되어 같아집니다. 출력이 2,700토큰, 즉 27% 줄어드는 손익분기점입니다. 이는 Astra가 실제로 그만큼 절약한다는 실험 결과가 아니라, 어느 정도 절약해야 가격 차이를 상쇄하는지 보여 주는 산술입니다. 실제 토큰 수와 재시도는 업무 기록에서 확인해야 합니다.
코딩에서는 수정한 줄보다 재작업을 보자
두 모델을 비교할 과제로 로그인 후 간헐적으로 세션이 끊기는 오류를 가정해 봅시다. 좋은 결과는 오류 메시지를 숨기는 코드 몇 줄이 아닙니다. 어떤 조건에서 문제가 발생하는지 재현하고, 원인을 설명하며, 수정 후 기존 로그인 기능까지 정상인지 확인하는 결과입니다.
Astra에서는 테스트가 실행되는 동안 관련 문서를 읽거나 별도 파일의 영향을 확인하도록 작업을 설계할 수 있습니다. 중간에 “모바일 로그인도 포함해 달라”는 지시가 들어오면 이후 확인 범위를 조정할 수 있습니다. 이 기능들은 코드 생성 그 자체보다 조사와 검증 사이의 연결에 도움을 줄 가능성이 있습니다.
Fable 5.1도 원인 분석과 장시간 코드 작업을 강조하므로 동일한 과제를 맡길 이유가 충분합니다. 어느 모델이 먼저 패치를 냈는지보다 수정이 실제로 문제를 해결했는지, 재현용 테스트가 의미 있는지, 관련 없는 파일까지 손대지 않았는지를 비교해야 합니다.
예를 들어 한 모델이 8분에 패치를 제출했지만 사람이 30분을 고쳐야 했고, 다른 모델이 15분에 검증된 패치를 제출했다면 사용자 입장에서는 후자가 더 빠를 수 있습니다. 이 숫자 역시 설명용 가정입니다. 실제 선택에는 모델의 실행 시간에 사람의 검토와 수정 시간을 더한 기록이 필요합니다.
조사와 문서 업무에서는 중간 변경의 가치가 커진다
제안서 작성에서 처음 받은 요구가 끝까지 그대로인 경우는 드뭅니다. 독자가 바뀌거나 예산이 줄고, 넣기로 했던 사례를 빼야 할 수도 있습니다. 이때 중요한 것은 이미 쓴 문장을 조금 고치는 능력보다 변경 조건이 표, 요약, 결론에 일관되게 반영되는지입니다.
이 관점에서 Astra의 방향은 흥미롭습니다. 기존 작업을 유지한 채 새 조건을 반영하는 기능은 긴 업무를 사람과 함께 조정하는 데 도움이 될 수 있습니다. 다만 모델에게 추가 메시지를 전달하는 것만으로 최종 문서의 모든 모순이 사라진다고 보장할 수는 없습니다. 완성된 결과를 서로 대조하는 검토는 여전히 필요합니다.
가령 예산을 1억 원에서 7,000만 원으로 바꿨다면 총액만 고치면 끝이 아닙니다. 인력 투입, 일정, 제공 범위와 기대 효과도 함께 맞춰야 합니다. 잘하는 모델은 어떤 약속을 줄여야 하는지까지 설명하고, 근거가 없는 수치를 조용히 만들어 넣지 않습니다.
Fable의 문서·시각 자료 이해를 평가할 때도 같은 관점이 유효합니다. 표를 읽는 능력과 표의 의미를 문서 전체에 맞게 반영하는 능력은 다릅니다. 겉보기 완성도보다 근거와 조건의 일관성이 구매 판단에 더 중요합니다.
벤치마크 숫자를 곧바로 승패로 읽기 어려운 이유
벤치마크에는 모델뿐 아니라 도구, 작업 시간, 추론 설정, 재시도 횟수와 채점 방식이 들어갑니다. 같은 이름의 시험도 문제 묶음이 달라지면 점수를 직접 비교하기 어렵습니다. 서로 다른 조건의 표에서 높은 숫자만 가져오면 정확한 비교처럼 보여도 실제로는 다른 시험을 나란히 놓은 셈입니다.
Anthropic의 Fable 5.1 발표에는 OSWorld 2.0의 2026년 8월 과제를 사용했으며 이전 공개 결과와 직접 비교할 수 없다는 주석이 있습니다. 이런 설명 때문에 경쟁 모델 점수를 표시하지 않은 항목도 있습니다. 공식 발표의 평가 조건을 점수와 함께 읽어야 하는 이유입니다.
이 글에서는 확인하지 못한 Astra 대 Fable의 우승률이나 속도 배수를 만들지 않았습니다. 공식 문서로 비교할 수 있는 기능과 요금에는 분명한 차이가 있지만, 어느 모델이 우리 업무를 더 잘 끝내는가는 별도의 질문입니다.
실무 평가를 한다면 매일 반복되는 쉬운 과제만 모으기보다 현재 자주 실패하는 사례를 포함하는 편이 좋습니다. 긴 문서의 예외 조항 찾기, 중간 조건 변경, 실패한 도구 재시도처럼 업무가 어긋나는 지점에서 차이가 잘 드러날 수 있습니다. 이전 글인 AI 모델의 비용 대비 효율 비교에서도 단가와 실제 업무 비용을 함께 살펴보는 관점을 이어갈 수 있습니다.
어떤 업무에서 Astra의 변화가 반가울까
짧은 번역이나 간단한 문장 수정만 한다면 이번 변화의 효과는 작을 수 있습니다. 반면 검색, 코드 실행, 파일 편집과 문서 작성을 여러 단계로 묶는 사람이라면 기다림과 재설명의 시간을 줄이는 기능이 유용할 가능성이 큽니다.
자체 자동화 도구를 운영하는 팀은 비동기 실행이 쉬워지는지 살펴볼 만합니다. 진행 중에 사람이 조건을 자주 바꾸는 팀은 새 지시가 작업에 어떻게 반영되는지 보는 것이 좋습니다. 동일한 긴 자료를 계속 되읽는 팀은 Fable의 캐시 비용 이점부터 계산해 볼 수 있습니다.
어느 경우에도 두 모델에 처음부터 동일한 역할을 모두 맡길 필요는 없습니다. 익숙한 도구는 유지하면서 실패가 많은 특정 작업부터 새 모델에 배정하면 변화의 효과를 구분하기 쉽습니다. 업무에 맞춰 모델을 선택하는 LLM 라우터의 관점도 이런 운영 방식과 연결됩니다.
새 모델 도입의 성과는 계정을 바꿨다는 사실이 아니라 실제로 줄어든 대기, 재작업과 오류로 나타나야 합니다. PoC를 실서비스 증거로 바꾸는 방법에서 다룬 것처럼, 작은 시연의 성공을 반복 업무의 성과로 확대 해석하지 않는 태도가 필요합니다.
좋아진 점의 중심은 함께 일하는 방식이다
GPT-6 Astra의 개선을 가장 흥미롭게 읽을 수 있는 부분은 작업을 조정하는 방식입니다. 외부 결과를 기다리는 시간, 새 요구를 전달하는 순간, 어려운 문제에 더 깊이 생각하게 하는 과정이 API 기능으로 구체화됐습니다. 복잡한 일을 AI와 함께 끝내려는 사람에게 의미 있는 변화입니다.
Fable 5.1과 비교하면 Astra의 작업 제어 기능과 Fable의 캐시 읽기 비용이 각기 눈에 띕니다. 두 모델 모두 긴 작업을 겨냥하기 때문에 제목 하나로 전체 승자를 정하기보다는 자기 업무가 어디에서 시간을 잃고 비용을 쓰는지 살펴야 합니다.
필자가 Astra에서 기대하는 변화도 그 지점입니다. 한 번의 답변이 인상적인가를 넘어, 사람이 방향을 고쳤을 때 맥락을 이어 가고 필요한 결과를 완성하는 과정이 더 자연스러워지는 것입니다. 그 기대가 우리 업무에서 실제 개선이 되었는지는 결과물의 정확성과 줄어든 재작업으로 판단할 수 있습니다.