새 모델을 고를 때 컨텍스트 창 크기는 눈에 잘 들어온다. GPT-6 Astra의 문서에는 105만 토큰 컨텍스트 창과 12만 8천 토큰 최대 출력이 적혀 있다. 복잡한 코드베이스, 긴 조사 기록, 여러 문서를 한 번에 다루는 작업이라면 분명 흥미로운 수치다.
다만 실제 도입에서는 창의 크기만 보고 판단하기 어렵다. 같은 문서에는 입력이 27만 2천 토큰을 넘으면 해당 요청 전체에 입력·캐시 요금은 2배, 출력 요금은 1.5배가 적용된다고 적혀 있다. 긴 문맥을 넣을 수 있다는 사실과, 매번 그렇게 넣는 것이 합리적인지는 다른 질문이다.
이번 변화에서 눈여겨볼 점은 장기 작업을 지원하는 모델이 개발 도구 안으로 빠르게 들어오고 있다는 것이다. GitHub는 9월 4일 GPT-6 Astra를 Copilot에 제공하기 시작했고, 단계적 롤아웃 중이라고 밝혔다. TechCrunch 보도에 따르면 OpenAI는 이 모델을 컴퓨터·브라우저 사용과 사이버 보안 능력이 커진 모델로 소개하면서 접근 범위를 순차적으로 넓히고 있다. 따라서 팀에서 체감하는 변화는 모델 자체의 점수보다도 선택 가능한 플랜, 관리자 정책, 실제 요청 크기에 따라 달라질 수 있다.
긴 컨텍스트는 무료 메모리가 아니다
컨텍스트 창은 모델이 한 요청에서 참고할 수 있는 입력과 대화 이력의 상한이다. 창이 크다고 해서 모든 로그와 파일을 계속 넣는 편이 좋은 것은 아니다. 오래된 지시가 현재 목표와 충돌하거나, 관련 없는 자료가 판단을 흐리게 할 수 있다. 비용도 함께 늘어난다.
GPT-6 Astra의 표준 API 가격은 입력 100만 토큰당 10달러, 캐시 입력은 1달러, 출력은 50달러다. 이 수치는 모델 선택의 출발점일 뿐이다. 27만 2천 토큰을 넘는 요청은 별도 가격 구간에 들어가므로, 한 번의 대형 요청과 여러 번의 작은 요청을 단순히 토큰 총량만으로 비교하면 실제 비용을 놓칠 수 있다.
특히 에이전트는 한 번 답하고 끝나지 않는다. 파일을 읽고, 도구를 호출하고, 결과를 검토한 뒤 다시 실행한다. 처음에 긴 문맥을 넣은 선택이 재시도와 후속 요청에서도 반복되면 비용과 대기 시간이 함께 커진다. 반대로 필요한 맥락만 남기는 압축이 너무 공격적이면 이전 결정의 근거를 잃을 수 있다. 어느 쪽이 나은지는 작업의 성격으로 확인해야 한다.
‘한 번에 많이 넣기’와 ‘필요할 때 찾기’를 분리해 보기
긴 작업을 설계할 때는 자료를 세 층으로 나누어 보는 편이 낫다. 첫째, 현재 작업의 목표·제약·승인 조건처럼 매 요청에 반드시 필요한 정보다. 둘째, 최근 변경 내역과 열린 이슈처럼 자주 참조하지만 매번 전문이 필요하지 않은 정보다. 셋째, 과거 로그·원본 문서처럼 검색이나 파일 도구로 필요할 때만 꺼내도 되는 정보다.
첫째 층은 짧고 명확하게 유지한다. 둘째 층은 요약과 원문 위치를 함께 남긴다. 셋째 층은 파일 검색이나 지식 저장소에 두고, 에이전트가 인용할 때만 읽게 한다. 이렇게 하면 컨텍스트 창을 작게 쓰자는 주장이 아니라, 큰 창을 비상 저장소처럼 쓰지 않게 된다.
OpenAI 문서상 이 모델은 Responses API에서 웹 검색, 파일 검색, 호스팅 셸, 컴퓨터 사용, MCP 등을 지원한다. 도구가 많다는 것은 작업 범위가 넓어진다는 뜻이기도 하다. 그렇지만 모든 도구를 한 흐름에 연결할 필요는 없다. 예를 들어 코드 수정 작업에서는 저장소 검색과 테스트 결과를 우선 사용하고, 외부 웹 검색은 근거가 필요한 지점으로 제한하는 식이 더 검토하기 쉽다.
벤치마크의 긴 실행과 업무의 긴 실행은 다르다
ARC Prize는 GPT-6 Astra를 두 가지 하네스로 평가했다. 표준 하네스에서는 모델이 남기고 싶은 메모를 이어 가게 했고, Provider Adapter 하네스에서는 제공사가 설계한 불투명한 추론 상태 보존과 압축을 활용했다. 같은 모델이라도 평가 환경에 따라 결과가 크게 달라질 수 있다는 점은 중요하다.
이 결과를 곧바로 업무 성과로 옮기면 안 된다. ARC-AGI-3는 새롭고 제한된 게임 환경에서 탐색·모델링·목표 설정·계획 실행을 보는 벤치마크다. 실제 업무에는 권한, 데이터 최신성, 사람 승인, 실패했을 때의 복구 절차가 추가된다. 다만 모델만 비교하지 말고 메모리 보존 방식, 도구 구성, 재시도 규칙까지 묶어 시험해야 한다는 교훈은 가져올 수 있다.
도입 전에 해볼 작은 측정
- 요청 크기 분포를 기록한다. 최근 자동화 작업 10건에서 입력 토큰, 출력 토큰, 도구 호출 횟수, 재시도 횟수를 남긴다. 평균만 보지 말고 27만 2천 토큰 가격 경계를 넘는 작업이 있는지 따로 확인한다.
- 두 가지 문맥 전략을 비교한다. 원문을 넓게 넣는 방식과 요약·검색으로 필요한 자료만 불러오는 방식을 같은 과제에 적용한다. 완료 시간, 비용, 사람이 수정한 횟수, 근거 누락을 함께 비교한다.
- 모델 정책을 먼저 확인한다. Copilot을 쓴다면 관리자 모델 정책과 실제 사용자 화면의 모델 선택 가능 여부를 확인한다. GitHub도 롤아웃이 단계적이라고 안내하므로, 공지의 출시일만으로 팀 전체에 준비됐다고 판단하면 안 된다.
모델 사양은 시작점이고, 운영 단위는 요청이다
긴 컨텍스트와 도구 지원은 AI가 더 큰 일을 맡을 수 있게 하는 기반이다. 하지만 업무에서 비용과 품질을 결정하는 최소 단위는 모델 이름이 아니라 실제 요청이다. 어떤 자료를 넣었는지, 무엇을 캐시했는지, 어느 지점에서 사람이 검토했는지에 따라 결과가 달라진다.
GPT-6 Astra의 공개는 장기 작업용 모델을 평가할 때 더 구체적인 질문을 남긴다. 우리 작업은 정말 긴 문맥이 필요한가. 필요한 정보는 어디에 보관하고 언제 읽을 것인가. 가격 경계를 넘는 요청이 정확도 향상으로 이어지는가. 이 세 가지를 작은 과제로 확인한 뒤 기본값을 바꾸는 편이 안전하다.