GPT-6 Astra가 Copilot에 들어오면, 모델 선택은 어떻게 달라질까

2026.09.08news

GitHub Copilot에 GPT-6 Astra가 들어오면서 모델 선택은 ‘가장 똑똑한 모델 고르기’가 아니라 작업 크기, 비용, 캐시, 검증 책임을 나누는 운영 문제가 됐다. Copilot과 에이전트를 쓸 때 Astra를 언제 쓰고, 언제 Auto나 더 싼 모델에 맡길지 판단표로 정리한다.

노트북 앞에서 개발자가 여러 갈래의 작업 카드를 모델별 레인에 나누는 사실적인 작업실 장면

결론부터

GitHub Copilot에 GPT-6 Astra가 들어왔다. 새 모델이 하나 더 늘었다고 보면 별일 아닌 뉴스다. 그런데 이번에는 조금 다르다. Astra는 OpenAI가 “복잡한 end-to-end 작업”을 겨냥해 공개한 모델이고, GitHub는 Copilot 안에서 장기 자율 코딩과 에이전트 작업에 맞는 모델이라고 설명했다.

그래서 질문이 바뀐다.

“어떤 모델이 제일 똑똑하지?”가 아니라
“어떤 일만 비싼 모델에게 맡겨야 하지?”가 된다.

개발자에게 이 차이는 꽤 크다. 매번 최고 모델을 고르면 마음은 편하지만 비용이 새고, 매번 싼 모델을 고르면 중간에 사람이 다시 수습하느라 시간이 샌다. 이제 모델 선택은 취향이 아니라 운영표에 가깝다. 작업을 작은 심부름, 중간 난이도 구현, 긴 에이전트 작업, 배포 직전 검증으로 나누고 각 칸에 맞는 모델을 붙여야 한다.

지금 뜨는 이유

OpenAI는 2026년 9월 3일 GPT-6 Astra를 공개했다. release notes에는 코딩, 리서치, computer use, 복잡한 multi-step work가 개선됐다고 적혀 있다. 특히 Responses API에는 세 가지 장치가 같이 들어왔다.

  • async tool calling: 모델이 도구 결과를 기다리는 동안 멈춰 있지 않고 다른 일을 계속할 수 있다.
  • mid-turn steering: 응답이 진행 중일 때 WebSocket으로 요구사항을 추가하거나 방향을 바꿀 수 있다.
  • reasoning effort 변경: 어려운 구간에서는 추론 강도를 올리고, 단순 후속 작업에서는 낮출 수 있다.

하루 뒤 GitHub는 GPT-6 Astra가 GitHub Copilot에서 일반 제공된다고 발표했다. 대상은 Copilot Pro+, Max, Business, Enterprise 사용자다. VS Code, Visual Studio, JetBrains, Xcode, Eclipse, Copilot CLI, GitHub Copilot coding agent, Copilot app, github.com, GitHub Mobile 등 여러 접점에서 모델 피커로 고를 수 있다고 안내했다. 단, rollout은 점진적이고 Business/Enterprise 관리자는 모델 정책으로 접근을 제어할 수 있다.

여기까지만 보면 “좋은 모델이 Copilot에 들어왔다”다. 실무자가 밑줄 칠 문장은 GitHub의 설명 중 이 부분이다. Astra는 결과물만 잘 내는 게 아니라 계획하고, 진단과 검증을 묶고, 끝났다고 말하기 전에 스스로 확인하는 방식이 눈에 띄었다는 것이다.

이 말은 실제 작업을 에이전트에게 맡겨본 사람에게 이렇게 들린다.

짧은 autocomplete는 굳이 Astra가 아니어도 된다.
하지만 “이 이슈를 파악해서 고치고, 테스트하고, PR까지 준비해줘” 같은 긴 일은 후보가 된다.

여러 색의 라벨이 붙은 작업 카드가 작은 일, 구현, 검증, 배포 전 점검 레인으로 정리된 책상 위 사실적 장면

모델 피커는 가격표를 같이 봐야 한다

Copilot의 모델 선택은 이제 비용과 분리해서 말하기 어렵다. GitHub 문서에 따르면 Copilot 사용은 input token, output token, cached token을 소비하고, 모델별 단가가 GitHub AI Credits로 환산된다. 1 AI credit은 0.01달러다.

가격표에서 GPT-6 Astra는 Powerful 모델로 표시되어 있고, 기본 구간은 100만 토큰당 input 10달러, cached input 1달러, cache write 12.50달러, output 50달러다. long context 구간에서는 input 20달러, cached input 2달러, cache write 25달러, output 75달러다. 같은 표에서 GPT-5.6 Sol 기본 구간은 input 4달러, output 20달러이고, GPT-5.6 Terra는 input 2달러, output 12달러다.

숫자를 다 외울 필요는 없다. 감각만 잡으면 된다.

  • Astra는 “항상 켜두는 전등”보다 “필요할 때 켜는 작업등”에 가깝다.
  • output이 비싸기 때문에 장황한 대화, 끝없는 재시도, 큰 diff 설명을 방치하면 비용이 빨리 커진다.
  • cache write 비용이 있으므로 모델을 자주 갈아타면 싸질 것 같아도 오히려 손해일 수 있다.

GitHub의 Auto model selection 문서도 같은 방향을 말한다. Auto는 시스템 상태와 작업 복잡도를 보고 모델을 고르며, routing은 추가 캐시 비용을 피하기 위해 자연스러운 cache boundary에서 일어난다고 설명한다. paid plan에서는 Auto 사용 시 모델 비용 10% 할인이 붙는다고도 한다.

즉 “수동으로 Astra만 고정”이 정답은 아니다. 기본은 Auto로 두고, 정말 긴 작업만 명시적으로 Astra를 고르는 식이 더 현실적이다.

내가 쓸 라우팅 표

복잡한 모델 선택을 매번 머리로 하면 결국 대충 고르게 된다. 그래서 나는 아래처럼 나눠두는 편이 좋다고 본다.

작업 기본 선택 Astra 후보인가 이유
코드 한 줄 설명, 에러 메시지 해석 Auto 또는 가벼운 모델 아니오 컨텍스트도 짧고 검증도 사람이 바로 할 수 있다.
README 문장 다듬기, 작은 리팩터 Auto 보통 아니오 결과 차이보다 빠른 반복이 중요하다.
테스트 실패 원인 찾기 Auto로 시작, 막히면 Astra 조건부 로그, 코드, 재현, 수정이 이어지면 장기 작업이 된다.
낯선 코드베이스에서 기능 추가 Astra 후보 예 탐색, 설계, 수정, 테스트가 한 번에 이어진다.
여러 파일에 걸친 버그 수정 Astra 후보 예 중간 추론이 끊기면 사람이 수습해야 한다.
PR 리뷰 전 자체 검증 Astra 또는 강한 reasoning 모델 예 “끝났는지 확인”의 가치가 크다.
배포 버튼 누르기 모델 문제가 아님 아니오 모델이 아니라 사람 승인과 read-back 검증 문제다.

핵심은 작업의 길이다. 질문 하나로 끝나면 싼 모델이 낫다. 반대로 모델이 파일을 읽고, 수정하고, 테스트하고, 실패하면 다시 고치고, 마지막에 스스로 검증해야 한다면 Astra 같은 장기 작업 모델을 검토할 수 있다.

이 표를 더 짧게 줄이면 이렇다.

“생각”만 필요한가? Auto.
“작업”을 끝까지 밀어야 하는가? Astra 후보.
“권한”이 필요한가? 모델 선택보다 승인 게이트.

작업 시간표와 비용 게이지가 놓인 책상에서 작은 스티커들이 저비용 작업과 고검증 작업으로 나뉜 사실적 장면

mid-turn steering은 에이전트 작업 방식도 바꾼다

Astra에서 흥미로운 기능은 mid-turn steering이다. 기존에는 에이전트가 길게 일하는 동안 방향이 틀어져도 기다렸다가 “아까 그거 말고 이렇게 해줘”라고 다시 말해야 했다. 그러면 이미 만든 결과물을 버리거나, 대화가 꼬이거나, 다시 긴 컨텍스트를 읽혀야 했다.

mid-turn steering은 응답이 진행 중일 때 요구사항을 추가할 수 있게 한다. OpenAI 문서에 따르면 WebSocket 연결에서 response.steer 이벤트를 보내고, 서버가 이를 큐에 넣은 뒤 이어지는 continuation에 반영한다. 다만 이미 보낸 출력, 이미 시작한 도구 호출, 이미 실행된 액션을 되돌리지는 않는다.

이 제한을 그냥 넘기면 안 된다. steering은 마법의 Ctrl+Z가 아니다. “이미 삭제한 파일을 없던 일로 만들기”가 아니라, “아직 진행 중인 작업에 새 조건을 더하기”에 가깝다.

실무에서 유용한 장면은 이런 것이다.

  • 에이전트가 너무 큰 범위를 고치려 할 때: “이번 PR은 인증 모듈만 건드려.”
  • 테스트가 오래 걸릴 때: “전체 테스트 말고 실패한 패키지부터 확인해.”
  • 블로그 초안이 너무 뉴스 요약으로 흐를 때: “모델 라우팅 판단표를 중심으로 다시 잡아.”
  • 비용이 걱정될 때: “이미지 컷은 4개로 줄이고, 검수는 사실 확인 위주로만 해.”

이 기능이 들어오면 에이전트 UI는 채팅창보다 작업 대시보드에 가까워진다. 사람이 처음 명령만 던지고 사라지는 구조가 아니라, 중간에 핸들을 살짝 틀어주는 구조다.

async tool calling은 “기다리는 시간”을 줄인다

async tool calling도 비슷하게 실무적이다. 보통 함수 호출은 모델이 도구 결과를 기다리는 동안 멈춘다. OpenAI 문서의 async tool calling은 함수나 custom tool에 async: true를 붙여 모델이 도구를 호출한 뒤 독립적으로 할 수 있는 작업을 계속하게 한다. 나중에 도구 결과가 오면 call_id에 맞춰 결과를 이어준다.

이건 에이전트에게 여러 심부름을 동시에 시키는 것과 비슷하다.

  • 이슈 목록 가져오기
  • CI 로그 가져오기
  • 관련 파일 검색하기
  • 공식 문서 확인하기

이 중 일부는 느리다. 전부 기다렸다가 시작하면 작업 시간이 길어진다. 먼저 던져놓고, 독립적으로 할 수 있는 정리나 설계를 진행하면 체감 속도가 달라진다.

다만 여기에도 운영 포인트가 있다. OpenAI 문서는 async tool이 OpenAI가 백그라운드 잡을 대신 관리한다는 뜻이 아니라고 분명히 말한다. 도구 실행과 job registry는 애플리케이션이 관리해야 한다. 즉 개발자는 call_id, task handle, 결과 도착 순서, 실패 처리, 중복 실행 방지를 직접 설계해야 한다.

이 부분을 대충 만들면 “빠른 에이전트”가 아니라 “가끔 결과를 섞어버리는 에이전트”가 된다.

작은 팀의 개발자가 코드 리뷰 체크리스트와 테스트 결과를 나란히 확인하는 조용한 사무실의 사실적 장면

실무자에게 남는 규칙

내가 이번 뉴스에서 가져갈 규칙은 네 가지다.

1. 기본은 Auto, 예외만 수동 선택

매번 모델을 고르는 일 자체가 피로다. 간단한 질문, 빠른 수정, 문장 다듬기는 Auto에 맡긴다. GitHub 문서상 Auto는 작업 복잡도와 시스템 상태를 고려하고, 가능하면 캐시 경계에서 라우팅한다. 사람은 모델 선택보다 작업 설명과 검증 조건에 집중하는 편이 낫다.

2. Astra는 “긴 일”에만 쓴다

Astra를 고르는 기준은 멋진 이름이 아니다. 작업이 길고, 중간 상태가 많고, 끝났는지 검증해야 하는가다. 예를 들어 “이 버그 고쳐줘”보다 “재현하고, 원인을 설명하고, 최소 수정하고, 테스트하고, 변경 파일을 요약해줘”가 Astra에 더 어울린다.

3. 비싼 모델일수록 출력 형식을 좁힌다

output token이 비싸면 말이 길어질수록 비용이 오른다. 그래서 강한 모델을 쓸수록 프롬프트는 더 구체적이어야 한다.

나쁜 요청은 이렇다.

전체 코드베이스 보고 개선해줘.

좋은 요청은 이렇다.

로그인 실패 버그만 봐. 수정 파일은 3개 이하로 제한해. 테스트는 auth 패키지부터 실행해. 마지막 답변은 원인, 변경 파일, 검증 결과, 남은 위험만 4줄로 줘.

강한 모델은 자유롭게 풀어놓는다고 항상 좋아지지 않는다. 비싼 인턴에게 “뭐든 해봐”라고 하는 것보다, 좋은 작업 지시서를 주는 게 낫다.

4. 배포는 모델 라우팅 문제가 아니다

Astra가 아무리 검증을 잘해도 배포는 다른 문제다. 배포, 결제, DB 삭제, 고객 데이터 전송은 모델 능력보다 권한 설계가 먼저다. 내 블로그 파이프라인도 초안, 이미지, 미리보기, 브랜치 push까지는 자동화할 수 있지만, noindex:false, main 병합, wrangler deploy는 Owner의 OK 뒤에만 실행한다.

이 규칙은 앞으로 더 중요해질 것이다. 모델이 약해서 사람이 승인하는 게 아니다. 모델이 강해졌기 때문에 사람이 승인 지점을 더 명확히 가져가야 한다.

오늘 적용할 한 가지

Copilot이나 다른 코딩 에이전트를 쓴다면, 오늘 바로 할 수 있는 일은 하나다. 자주 맡기는 작업을 10개 적고, 옆에 가벼움 / 중간 / 긴 작업 / 승인 필요를 붙인다.

예시는 이렇다.

  • 타입 에러 설명: 가벼움
  • CSS 깨짐 수정: 중간
  • CI 실패 원인 분석: 긴 작업
  • 마이그레이션 SQL 실행: 승인 필요
  • PR 전 최종 검증: 긴 작업
  • production 배포: 승인 필요

이렇게만 해도 모델 선택이 덜 감정적이 된다. “Astra가 좋다더라”가 아니라 “이 일은 Astra 값어치를 할까?”로 바뀐다.

FAQ

GPT-6 Astra를 Copilot 기본 모델로 고정하면 되나?

대부분의 사람에게는 아니다. 간단한 질문과 작은 수정에는 과하다. 기본은 Auto로 두고, 긴 에이전트 작업이나 검증 가치가 큰 작업에서 수동 선택하는 편이 낫다.

Auto model selection을 쓰면 Astra가 자동으로 골라지나?

가능성은 있지만 보장으로 읽으면 안 된다. GitHub 문서는 Auto가 지원 모델, 플랜, 정책, 시스템 상태, 작업 복잡도에 따라 고른다고 설명한다. 조직 정책이나 플랜에서 빠진 모델은 Auto 후보에도 들어가지 않는다.

mid-turn steering이 있으면 중간에 안전하게 취소할 수 있나?

부분적으로만 그렇다. OpenAI 문서는 steering이 이미 전송된 출력, 이미 시작한 tool action을 되돌리지 않는다고 설명한다. 취소와 권한 차단은 별도 설계가 필요하다.

async tool calling은 그냥 병렬 실행인가?

느낌은 비슷하지만 책임은 애플리케이션에 있다. OpenAI가 백그라운드 잡을 대신 관리하는 게 아니다. 도구 실행, call_id 매칭, 결과 전달, 실패 처리는 서비스가 구현해야 한다.

팀에서는 무엇을 먼저 정해야 하나?

모델 이름보다 정책이 먼저다. 어떤 모델을 허용할지, Auto를 기본으로 둘지, 사용자 예산을 어떻게 둘지, 배포·데이터 접근 같은 위험 작업은 어떤 승인 게이트를 둘지 정해야 한다.

출처와 기준시점

기준시점: 2026-09-08 07:00 KST. 이 글은 아래 공식 문서와 발표를 바탕으로 작성했다.

← 글 목록