GPT‑6 Astra 실전 가이드: 코딩 성능, 사용량, 설정과 전환 방법

OpenAI가 2026년 9월 3일 GPT‑6 Astra를 공개했다. 이미 다른 모델을 쓰고 있다면 궁금한 점은 세 가지다. 어떤 일이 더 잘되는지, 어떻게 써야 그 차이를 느낄 수 있는지, 기존 설정에서 무엇을 고쳐야 하는지다. 코딩 성능과 사용 조건을 먼저 살펴보고, 실제 요청 방법과 설정 변경으로 이어가겠다.

기준일은 2026년 9월 6일이다. 공식 발표·개발자 문서·헬프센터와 공개 제작 사례를 교차 확인했다. 직접 수행한 모델 비교 실험은 아니며, 본문의 요청문과 전환 절차는 그 자료를 바탕으로 만든 활용 제안이다. 단계적 배포와 계정별 조건은 모델 선택기와 사용량 화면에서 다시 확인해야 한다.

기존 사용자라면 재현 가능한 버그 수정이나 여러 파일에 걸친 변경 하나를 골라 시작할 만하다. 목표·제약·검증 방법을 주고 Medium에서 수행해본 뒤, 품질과 재시도 비용을 보고 수준을 조정한다. 처음부터 모든 작업을 Max로 바꾸거나 기존 스킬 전체를 함께 뜯어고치면 무엇이 개선됐는지 구분하기 어렵다.

코딩 성능은 얼마나 좋아졌나

아래는 OpenAI 발표의 GPT‑5.6 Sol 대비 결과다. Terminal-Bench는 20.6%포인트 상승했지만 DeepSWE의 차이는 1.4%포인트다. “코딩이 좋아졌다”는 말 안에서도 과제별 개선 폭은 다르다.

발표 표는 추론 수준별 최고 결과를 사용하며 평가 환경과 도구는 실제 제품과 다를 수 있다. 다른 회사 모델과 비교해도 전 항목 1위는 아니다. 같은 발표에서 Terminal-Bench 4.0은 Astra 57.9%, Claude Fable 5.1 55.8%였지만 Artificial Analysis Coding Agent Index v1.4는 Astra 67.0, Claude Opus 5 68.1이었다. OpenAI 발표 및 평가 조건

이 차이는 교체 대상을 고르는 근거가 된다. 터미널에서 환경을 조사하고 여러 작업을 이어가거나 데이터베이스 변경의 의존 관계를 다루는 업무라면 우선 시험해볼 만하다. 기존 모델이 이미 잘 처리하는 단일 수정까지 같은 폭으로 좋아진다고 기대할 근거는 없다. Claude나 Gemini 사용자도 자신의 저장소·도구·검증 기준으로 비교해야 한다.

Chat, Work, Codex에서 선택하는 방법

같은 Astra라도 일반 Chat에서는 GPT‑6 Pro, Work와 Codex에서는 GPT‑6 Astra라는 이름을 쓴다. Chat의 Instant·Medium·High·Extra High와 자동 추론은 Sol을 사용한다. 따라서 일반 Chat에서 Medium을 골랐다는 것과 Codex에서 Astra Medium을 골랐다는 것은 다르다. Chat 모델 안내

Work·Codex에서 Astra를 쓸 수 있는 Plus 계정도 일반 Chat의 GPT‑6 Pro 권한이 생기지는 않는다. 크레딧 구매 역시 배포 순서를 앞당기지 않는다. Work·Codex 안내, 클라우드 작업과 요금

Codex CLI는 최소 0.153.0이 필요하다. 0.153.4에는 Astra가 기본 모델 선택기에 빠지던 문제의 수정과, 명시적 모델 설정이 없을 때의 기본값 변경이 포함됐다. 앱도 업데이트하고 CLI는 0.153.4 이상인지 확인한다. 기존 설정에 모델을 지정했다면 업데이트만으로 바뀌었다고 생각하지 않는다. Codex 변경 이력

codex --version
npm install -g @openai/codex@latest
codex --model gpt-6-astra

대화 중에는 /model로 모델과 추론 수준을 확인한다. 기본값을 저장하려면 기존 ~/.codex/config.toml의 해당 항목을 수정한다. 이미 같은 키가 있다면 중복 추가하지 않는다.

model = "gpt-6-astra"
model_reasoning_effort = "medium"

설정 키는 공식 설정 레퍼런스에서 확인할 수 있다.

메시지 한도와 토큰 비용을 구분한다

Chat의 GPT‑6 Pro는 보낼 수 있는 메시지 수로 사용량을 제한한다. 아래 조건은 Work·Codex 사용량과 별개다. Chat 한도 안내

Pro $200에서 Astra의 주간 한도를 쓰면 자동 전환된 모델을 확인한다. 남은 Sol Pro를 쓰려면 직접 선택해야 할 수 있다. 공유 한도인 플랜에서는 모델을 바꿔도 한도가 늘지 않는다.

Work와 Codex에서 쓴 양은 같은 할당량에서 차감된다. Pro $100·$200과 Business Premium은 기존 할당량 전체를 Astra에 사용할 수 있고, Plus와 Business Standard는 제한적인 Astra 사용량이 포함된다. 추가 사용에는 크레딧과 계정·워크스페이스 지출 조건이 적용된다. 플랜별 포함 범위

표는 5시간당 로컬 메시지 추정치이며 보장된 횟수가 아니다. 작업 크기, 문맥, 추론 수준과 속도 옵션이 소모량을 바꾼다. Enterprise·Edu의 유연 요금제는 크레딧 기반으로 별도 확인한다. 사용량 추정치

Business·Enterprise/Edu의 크레딧 요금표에서 Astra는 100만 토큰당 입력 250, 캐시 입력 25, 출력 1,250크레딧이다. Sol의 100·10·500 대비 각각 2.5배다. 이는 API 달러 요금이나 구독 메시지 횟수와 다른 단위다. Work·Codex의 Astra Fast는 표준 크레딧 요율의 2.5배이므로 추론 수준을 낮추는 것과 혼동하지 않는다. 공식 크레딧 요금표

남은 양은 사용량 대시보드나 CLI의 /status에서 확인한다. 계정에 제공된 일회성·보관 리셋은 사용할 수 있지만 모든 계정에 보장되는 기능은 아니다. 이런 리셋을 사용하는 것과 지원팀에 수동 초기화를 요청하는 것은 다르다. 지원팀은 한도를 수동 재설정하지 않는다. 리셋과 사용량 안내

Medium부터 시작하고 필요한 경우에 높인다

Astra Light는 Astra의 추론 강도를 낮춘 설정이다. 앱의 Light와 CLI의 Low는 가벼운 추론 수준이고, Medium은 계획이 필요한 작업의 출발점이다. 어려운 여러 단계의 판단에는 High·Extra High, 하나의 특히 어려운 문제에는 Max를 비교해볼 수 있다. Ultra는 서브에이전트를 활용하는 실행 방식까지 포함하므로 Max와 동일한 설정이 아니다. 표시 옵션은 계정과 클라이언트에 따라 다르다. 추론 수준 안내

Medium의 절감 효과는 작업에 따라 달라진다. “지능 1% 차이로 비용 25% 절감”이라는 수치는 원 평가와 계산 조건을 확인하지 못해 권장 근거에서 제외했다. 평가 점수와 실제 업무의 품질, API 비용과 구독 사용량은 각각 비교해야 한다.

범위가 정해진 수정은 Light/Low, 조사와 계획이 필요한 일은 Medium에서 먼저 수행한다. 실패 원인이 정보 부족이나 충돌하는 지침이면 그 문제를 먼저 고친다. 자료가 충분한데도 복잡한 추론·검증에서 실패한다면 높은 수준으로 다시 비교한다. Max를 항상 켜두는 것보다 어느 과제에서 추가 추론이 필요한지 기록하는 편이 선택에 도움이 된다.

가령 같은 버그 다섯 개를 Medium과 Max에 맡겨 수정·재현·회귀 검증까지 비교한다. 처음 호출의 비용뿐 아니라 재시도와 사람이 수정한 시간을 기록한다. 낮은 수준에서 다시 해야 할 일이 늘면 한 번의 실행이 저렴해도 완성까지는 더 비쌀 수 있다. 다섯 개로 시작하되, 자주 맡기는 작업으로 범위를 넓혀 확인한다.

실제 코딩에서는 무엇을 맡겨볼까

OpenAI는 Astra의 소프트웨어 엔지니어링 능력과 긴 작업의 일관성이 개선됐다고 설명한다. 기존 개발자에게 중요한 질문은 자신이 여러 번 개입하던 작업을 더 적은 수정으로 완수하는가다. 함수 하나의 생성 품질과 저장소 전체의 제약을 지키는 변경 능력은 각각 확인해야 한다. 공식 모델 가이드

공개된 게임 개발 사례에서 Astra는 기존 시뮬레이션을 유지하며 렌더러를 WebGL2에서 Three.js WebGPU 구조로 옮겼다. 상태 조회와 Playwright 테스트를 이용해 문제를 조사하고 변경 전후를 비교했다. 지형 데이터 전송량은 같은 삼각형 수에서 약 35MB에서 15MB로 줄었고, 고정된 지연을 사용한 시뮬레이션에서는 폐기된 지형 작업이 6,074개에서 13개로 줄었다. 공식 게임 개발 사례

이 수치는 해당 프로젝트의 변경 전후 결과다. GPT‑5.6 대비 코딩 점수나 실제 GPU 프레임률 향상률이 아니다. 사용자도 방향을 제시하고 결과를 검토했다. 그 범위 안에서 주목할 부분은 모델이 실행 구조를 파악하고, 관측할 방법을 만들고, 병목의 원인을 좁혀 수정했다는 점이다.

이 사례를 자신의 프로젝트로 옮겨보면 다음과 같은 과제를 시험할 수 있다. 아래 표는 검증된 모델별 우열이 아니라 활용 제안이다.

구현 방법과 함께 검증 방법도 맡긴다

가령 리스트 화면이 느리다면 “메모이제이션을 추가해줘”는 이미 해결책을 선택한 요청이다. 설계와 디버깅 능력을 시험하려면 문제와 제약을 전달하고 원인 확인부터 맡겨볼 수 있다. 아래는 직접 만든 요청 예시다.

검색 결과가 많은 경우 리스트 화면의 스크롤이 끊긴다.
첨부한 재현 절차와 테스트 데이터를 사용해 원인을 조사해줘.
렌더링·계산·네트워크 중 병목 후보를 구분하고 근거를 남겨줘.
기존 정렬·필터·접근성 동작을 유지하는 최소 변경을 구현해줘.
같은 환경에서 수정 전후를 측정하고, 회귀 검증 결과도 보고해줘.
측정할 수 없는 부분은 추정으로 분리해줘.

이 요청이 효과를 내려면 에이전트가 코드뿐 아니라 실행 결과도 볼 수 있어야 한다. 테스트 실행 명령, 재현 데이터, 필요한 브라우저·로그 접근을 연결한다. 매번 사람이 화면을 설명해줘야 하는 환경에서는 모델의 디버깅 능력을 충분히 활용하기 어렵다. 자료와 관측 도구를 갖추는 변경은 다른 모델에도 유용하다.

기존 프롬프트가 모든 구현 단계를 고정했다면, 목표와 필수 제약은 남기고 방법 선택의 여지를 줘본다. 대신 정답으로 인정할 테스트, 변경 범위, 호환성 조건은 구체화한다. 동일 과제에서 기존 모델과 Astra의 완료율, 재수정 횟수, 회귀 오류와 총비용을 비교해야 코딩 개선이 자신의 업무에서도 나타나는지 알 수 있다.

이런 설계 판단은 모델의 능력을 평가하는 대상이다. 뒤에서 다룰 비동기 호출은 대기 중 다른 일을 할 수 있게 하는 실행 기능이다. 테스트를 병렬로 돌렸다는 사실만으로 코드의 정확도가 높아졌다고 판단하지 않는다.

긴 작업에서는 컨텍스트 관리도 바뀐다

긴 디버깅에서 요약이 반복되면 이미 실패한 접근이나 이전 테스트 조건이 빠질 수 있다. Astra의 Codex 실험 기능은 창을 넘어 노트를 유지하고, 같은 작업의 이전 메시지와 도구 결과를 검색하도록 한다. 과거 기록 전체를 매번 넣지 않고 필요한 근거를 다시 찾는 방식이다. 실험적 컨텍스트 관리

출시 시점에는 지원 Codex 클라이언트에서 ChatGPT Plus·Pro로 로그인했을 때 선택할 수 있고, 기본값은 꺼짐이다. Business·Enterprise 및 API 키 로그인은 이 실험의 출시 대상이 아니다. 적용하려면 config.toml의 최상위에 다음 설정을 넣고 새 작업을 시작한다. TOML의 다른 [section] 아래에 무심코 붙이지 말고 기존 구조와 중복 키를 확인한다.

features.context_management.experimental_mode = true

이것을 무한한 컨텍스트나 무오류 기억으로 이해하면 안 된다. 어떤 내용을 노트에 남기고 언제 과거 기록을 검색하는지가 결과를 좌우한다. 기존 작업에서 압축 전의 실패 원인·제약·검증 결과를 후반에도 정확히 되찾는지 확인해볼 만하다. 중요 결정과 재현 절차는 여전히 저장소 문서나 테스트에 남긴다. 기본 활성화 확대는 발표 당시의 계획이며 현재 설정과 구분해야 한다.

브라우저 작업과 문서 작성은 어떻게 맡길까

컴퓨터 사용은 클릭 성공과 업무 완료를 구분해야 한다. 공식 문서가 강조하는 소스·템플릿·제약·확인 방법을 실제 요청에 넣으면 모델이 결과를 검토할 수 있다. 다음은 이 글에서 만든 예시다.

첨부 CSV의 연락처를 테스트 CRM에 등록해줘.
같은 이메일이 이미 있으면 건너뛰고 사유를 기록해줘.
허용 대상은 이 테스트 워크스페이스뿐이다.
완료 후 CSV의 신규 대상 수와 CRM에 실제 등록된 수를 대조하고,
불일치와 등록 실패를 보고해줘. 이메일은 보내지 마.

여기서 바꿀 것은 프롬프트뿐이 아니다. 중복 확인에 쓸 이메일 값, 등록 결과를 다시 읽을 권한, 실패 시 재시도해도 중복되지 않는 확인 절차가 필요하다. 모델이 더 잘 클릭해도 결과를 읽을 수 없으면 사람의 확인 부담은 남는다.

문서 작업도 “예쁜 슬라이드 만들어줘”에서 자료·템플릿·독자·검토 기준을 주는 방식으로 바꿔볼 수 있다. 모델이 생성한 파일은 실제로 열어 표·차트·슬라이드를 확인한다.

첨부한 인터뷰와 설문으로 제품 회의용 8장 슬라이드를 만들어줘.
기존 발표 파일의 서체와 레이아웃을 참고해줘.
고객 문제 세 가지를 고르고 각 주장에 근거와 표본 범위를 붙여줘.
관찰과 제안을 구분하고, 자료가 약한 부분은 명시해줘.
모든 슬라이드를 렌더링해 잘림·겹침과 출처 누락을 확인해줘.
공유하거나 발송하지 말고 검토할 파일을 남겨줘.

OpenAI의 건축 시각화 사례에서도 사용자는 원하는 공간을 설명하고 결과를 보며 방향을 조정했다. Astra는 Blender 작업과 미리보기, Unreal Engine으로 이어지는 제작을 수행했다. 공개 제작 과정이지 누구나 한 번의 요청으로 같은 결과를 얻는다는 비교 실험은 아니다. 자신의 작업에도 미리보기와 상태 조회를 연결해야 유사한 반복 개선을 시도할 수 있다.

AGENTS.md와 Skills에서 고쳐볼 부분

OpenAI는 Astra가 추가 확인을 자주 요청하거나 작은 코드 변경에도 검증 범위를 넓힐 수 있다고 설명한다. 스킬과 AGENTS.md의 지시에 더 민감할 수 있다는 안내도 있다. 프롬프팅 안내

지시를 충실히 따른다는 특성은 잘못 연결된 지시의 영향도 키울 수 있다. 예를 들어 사용자가 로컬 문서 수정을 맡겼는데 스킬에 “변경 전 항상 승인받는다”가 있으면, 모델은 작은 수정에서도 멈출 수 있다. 추론 수준을 높여도 규칙의 충돌은 해결되지 않는다. 실제로 읽힌 파일과 멈춘 이유부터 확인해야 한다.

다음은 기존 구성을 점검하기 위한 수정 예시다. 새 모델이라는 이유로 필요한 승인과 검증을 없애는 지침은 아니다.

중요한 것은 스킬의 개수보다 적용 조건과 내용이다. 글쓰기 스킬에 구현 작업의 배포 승인 절차가 섞여 있거나, 오래된 테스트 명령을 강제하면 새 모델도 그 지시를 따라 비용을 쓸 수 있다. 변경 기록에는 어떤 스킬이 적용됐는지, 불필요한 질문과 검증이 어디서 발생했는지 남기면 된다.

예를 들어 팀 규칙을 다음처럼 구체화할 수 있다. 아래는 이 글에서 만든 지시문 예시다.

문서의 단순 오탈자 수정은 수정된 문단과 문서 빌드를 확인한다.
프로그램 동작을 바꾸면 영향받는 기능을 검증한다.
요구사항의 빈칸이 결과를 크게 바꾸면 질문하고,
그 답이 필요하지 않은 조사와 준비는 계속한다.

모델을 바꾼 뒤에도 자꾸 멈춘다면 추론 강도부터 높이기보다 읽힌 지침을 확인하자. 오래된 승인 규칙이나 맞지 않는 테스트 명령이 원인일 수 있다. 지침이 모델 성능보다 언제나 중요하다는 뜻은 아니다. 새 모델이 기존 지시를 더 충실히 따르면서 생길 수 있는 문제다.

멈춤·과도한 검증·위임을 구체적으로 조정한다

“알아서 끝까지”만 추가하기보다 허용한 일을 명시하는 편이 낫다. 아래는 예시이며 조직 정책이나 실제 권한을 대체하지 않는다.

맡긴 로컬 수정은 조사·구현·관련 검사·결과 보고까지 진행한다.
별도 답이 필요한 결정은 질문하고, 독립적인 준비는 계속한다.
승인이 필요한 외부 게시 전에는 검토 가능한 결과물을 먼저 만든다.
스킬 때문에 멈춘다면 정확한 파일 경로와 해당 지시를 밝히고,
명시된 요구인지 너의 해석인지 구분해서 설명한다.

작은 변경 뒤 전체 검사를 반복한다면 변경에 맞는 필수 검사와 확대 조건을 정한다. 병렬 검토가 필요하다면 독립적인 검토 항목을 나눠 서브에이전트에 맡기라고 요청한다. 모든 작업을 분할하면 맥락 전달과 종합 비용도 늘어난다. 글쓰기에는 독자·문체·분량을 지정하고 목록과 표는 비교가 필요한 부분에만 사용하게 한다. 모델별 행동과 권장 지침

작업이 멈췄을 때 원인을 구분한다

지시 파일의 승인 요구, 실행 환경의 권한 제한, 안전 모니터링은 서로 다른 중단 원인이다. Astra는 OpenAI 준비성 프레임워크의 사이버보안 Critical 수준에 도달한 첫 모델로 분류됐고, 배포에는 강화된 모니터링이 포함된다. 이것은 사용자가 모든 평가상의 보안 능력을 제한 없이 사용할 수 있다는 뜻이 아니다. 안전 개요

Work·Codex 모니터링은 비동기로 수행돼 원인이 된 행동보다 늦게 알림이 올 수 있다. 중단되면 마지막 메시지만 보고 원인을 추측하지 말고 제공된 알림과 판단 근거를 확인한다. 작업 중단 안내

개별 행동의 자동 승인 검토를 통과했어도 작업 전체 모니터링이 나중에 멈출 수 있다. 종료된 작업을 이어가야 한다면 먼저 실제 파일 변경·외부 실행 여부를 확인하고 남은 일만 정리한다. 이미 수행한 등록·전송을 무조건 반복하지 않도록 하기 위한 절차다.

보안 업무에서는 Daybreak 승인과 Astra 접근도 구분한다. 출시 시점에 대부분의 Daybreak 고객은 Astra의 거부 완화를 사용할 수 없다. 표준 보호 조치의 Astra를 사용하거나 Blue를 지원하는 Sol로 전환해야 한다. ChatGPT 로그인 Codex의 Daybreak 토글은 지원 모델에 적용되며 API 키 로그인에서 같은 토글을 쓰는 방식은 아니다. Daybreak 공식 안내

API 비용은 완성한 작업 하나를 기준으로 계산한다

먼저 사양에서 확인되는 차이를 정리하면 다음과 같다. 가격은 표준 API의 텍스트 토큰 100만 개 기준이다.

출처: Sol 모델 문서, Astra 모델 문서. Sol의 현재 가격은 최소 2026년 11월 21일까지 제공되는 프로모션 가격으로 안내돼 있다.

Astra는 입력이 272K 토큰을 넘으면 요청 전체에 입력·캐시 요율 2배, 출력 요율 1.5배가 적용된다. 캐시 쓰기 요율은 100만 토큰당 $12.50이다. 긴 세션의 비용을 계산할 때 기본 표만 사용하면 안 된다. Astra 요금 조건

숫자 6으로 넘어갔다고 입력 공간이 커진 것은 아니다. 같은 문서를 더 넣는 용도보다는, 이미 넣을 수 있었던 자료로 얼마나 어려운 일을 해결하는지 평가하는 편이 맞다.

요금표만으로 작업 비용을 단정할 수도 없다. OpenAI는 일부 평가에서 Astra가 출력 토큰을 줄여 더 낮은 추정 작업 비용을 보였다고 설명한다. 이는 공급자의 평가 결과이며, 모든 업무에서 더 저렴하다는 보장은 아니다. 공식 모델 가이드

비교 기준을 단순화해 보자. 캐시와 도구 요금을 제외하고, 입력 10만 토큰과 과금 대상 출력 1만 토큰을 쓰면 Sol은 $0.60, Astra는 $1.50이다. 여기서 두 모델의 입력·출력 사용량이 같은 비율로 줄어든다고 가정하면, Astra가 Sol 사용량의 40%를 써야 비용이 같아진다. 60% 절감은 손익분기 계산에 필요한 가정이지, 확인된 성능 수치가 아니다.

실제 에이전트에서는 재시도, 캐시, 추론 토큰, 도구 호출이 섞인다. 따라서 비교할 값은 한 번의 답변 길이보다 검토를 통과한 작업 하나에 들어간 총비용이다.

자체 하네스와 API를 쓰는 경우

Codex의 설정과 API 요청은 나눠 적용한다. Astra의 도구 호출은 Responses API를 사용해야 한다. 기존 none·minimal 추론 설정은 low로 바꾸고, 지원하지 않는 temperature·top_p·top_logprobs와 로그 확률 요청도 점검한다. 모델 이름만 바꾸기 전에 실제 요청 형식을 확인한다. API 전환 안내

도구가 끝나기를 기다리는 동안에도 일한다

비동기 도구 호출은 함수 또는 커스텀 도구에 async: true를 지정해, 결과가 돌아오기 전에 모델이 다른 작업을 이어가도록 한다. 도구 실행과 대기 중인 작업 관리는 애플리케이션이 맡고, 결과는 원래 호출의 call_id에 연결해 돌려준다.

예를 들어 코딩 에이전트가 테스트를 시작했다고 하자. 테스트 결과와 무관하게 할 수 있는 변경 내역 정리나 문서 검토가 있다면 대기 시간에 진행할 수 있다. 반대로 실패 원인을 고치거나 테스트 통과를 보고하는 일은 실제 결과를 기다려야 한다.

테스트 실행 요청 ───────────────→ 결과 수신
                변경 내역 정리 → 결과를 반영한 최종 보고

이 기능을 붙일 때의 설계 문제는 어떤 작업이 독립적인지 구분하는 것이다. 아직 끝나지 않은 테스트와, 테스트 성공에 의존하는 배포를 같은 방식으로 취급하면 안 된다. 비동기 호출은 기다림을 줄일 기회를 주지만 의존 관계를 없애지는 않는다.

작업 도중 바뀐 요구사항을 받아들인다

Mid-turn steering은 WebSocket 연결에서 작업 중인 응답에 추가 사용자 지시를 보내는 기능이다. 완료된 작업을 보존하면서 수정 내용을 후속 실행에 반영한다. 지시를 접수한 이벤트와 실제 반영에 필요한 도구 결과·승인 상태를 구분해 처리해야 한다.

이를테면 사용자가 보고서 작성을 맡긴 뒤 “올해 전체 말고 2분기만 비교해줘”라고 범위를 바꿀 수 있다. 이미 읽은 자료를 활용하되, 그다음 분석과 결과물은 새 범위를 따라야 한다. 긴 작업을 하는 동안 사용자가 모든 결정을 처음부터 확정할 필요가 줄어든다.

여기에는 UI 설계도 따라온다. 사용자는 자신의 수정이 접수됐는지, 어느 작업부터 반영되는지 알아야 한다. 이미 전송한 메일이나 실행한 외부 작업까지 되돌린다고 해석해서는 안 된다. 요구사항 변경을 지원하는 것과 실행 취소를 구현하는 것은 각각 다뤄야 할 문제다.

비동기 호출과 작업 중 지시 변경을 지원하면, 사용자는 실행을 기다리는 중에도 진행 상황을 보고 방향을 조정할 수 있다. 얼마나 빨라지는지는 서로 독립적으로 진행할 일이 얼마나 있는지에 달려 있다.

기존 구성에서 바꿀 순서

1. 기준선 기록: 기존 모델·버전·추론 수준·스킬·도구와 대표 과제의 완료 기준을 기록한다. Claude나 Gemini를 사용했다면 해당 설정을 기준선으로 남긴다.
2. 모델 교체와 호환성 확인: 접근 권한과 요청·도구 형식을 확인하고, 필수 수정만 적용해 실행한다. 이 단계에서 프롬프트까지 전부 바꾸지 않는다.
3. 지침 정리: 멈춤과 과도한 검증을 유발한 규칙부터 고치고 같은 과제를 다시 실행한다.
4. 추론 수준 비교: 품질을 유지하는 낮은 수준을 찾아보고, 실패·재시도를 포함한 사용량을 비교한다.
5. 호스트 기능 적용: 비동기 실행이 필요한 작업에 대기 상태·결과 연결을 추가한다. Steering은 지원 앱 또는 WebSocket 연동에서 별도로 적용한다.

모델 자체의 개선, 지침 수정의 효과, 실행기의 개선을 나눠 측정해야 무엇을 유지할지 판단할 수 있다. 완료율과 금지 행동 통제를 유지하면서 사람의 수정량·시간·총비용이 나아진 변경만 채택한다. 검토 부담이나 비용이 늘어난 작업은 기존 모델·구성을 유지할 수 있다. 평가 구성은 AI Eval 가이드에서 이어서 볼 수 있다.

먼저 맡겨볼 작업

Astra의 첫 적용 대상으로는 여러 파일과 자료를 조사하고, 실행 결과를 확인하며, 중간에 요구사항이 바뀌는 작업이 적합하다는 것이 내 판단이다. 반면 기존 모델로 충분히 처리하는 짧은 분류나 정형 변환은 별도 비용 평가가 필요하다.

도입 실험에서는 완수 여부와 함께 사람의 개입 횟수, 경과 시간, 총비용을 기록하면 좋다. 비동기 실행으로 시간이 줄어도 검토 부담이 늘었다면 그 차이까지 결과에 포함해야 한다.

처음에는 익숙한 과제 하나면 충분하다. 모델만 바꿔 실행해보고, 불필요하게 멈춘 규칙을 고친 뒤 다시 비교한다. 그 결과를 보고 추론 수준과 도구 구성을 조정하면 무엇을 바꿔야 효과가 나는지 알 수 있다.