컨텍스트 손실 없이 GPT-6 Astra로 전환하는 방법 (2026)

먼저 OpenAI의 공식 모델 페이지에 명시된 사양입니다. Astra는 "1,050,000 컨텍스트 창"과 "128,000 최대 출력 토큰", 그리고 "2026년 4월 30일 지식 컷오프"를 제공합니다. OpenAI는 이를 "가장 까다로운 엔드투엔드 작업을 위해 구축된 가장 유능한 모델"로 설명하며 "복잡한 추론, 코딩, 컴퓨터 사용(computer use), 연구 및 문서 작성"에 권장합니다. 추론은 조정 가능하며, reasoning.effort는 "low, medium, high, xhigh, max"를 지원합니다.

출시는 단계적으로 진행되므로, 혼용 기간을 대비해야 합니다. 모델 페이지에 따르면: "GPT‑6 Astra는 오늘 Trusted Access 프로그램의 기업 고객을 대상으로 출시되며, API 및 Plus, Pro, Business, Enterprise 요금제를 통한 액세스는 향후 며칠 내에 제공될 예정입니다." API 요율 제한 표에도 Free 티어는 "지원되지 않음(Not supported)"으로 표시되어 있습니다.

이는 사람들이 과소평가하기 쉬운 실질적인 이유 때문에 중요합니다. 당분간은 일부 환경에서는 Astra를 실행하고 다른 환경에서는 다른 모델을 실행하게 될 것입니다. 한 모델의 대화 기록 내에 존재하는 컨텍스트는 다른 모델에는 존재하지 않습니다.

지침(Instruction) 파일은 모델에 종속되지 않으므로 완전히 이전됩니다. 이는 반가운 소식이며, 그 이유를 명확히 짚고 넘어갈 가치가 있습니다. Codex 문서에 따르면 "Codex는 작업을 수행하기 전에 AGENTS.md 파일을 읽습니다"라고 명시되어 있으며, 글로벌 파일에서 시작하여 루트 폴더 아래의 프로젝트 파일로 이어지는 탐색 체인은 어떤 모델이 답변하는지와는 아무런 관련이 없습니다. Claude Code의 CLAUDE.md, Cursor의 .cursor/rules, Amp 및 Warp의 AGENTS.md도 마찬가지입니다.

따라서 규칙이 파일에 저장되어 있다면 모델을 전환하는 데 비용이 들지 않습니다. 하지만 대화 속에 있다면, 모델을 전환할 때 그 규칙들을 모두 잃게 됩니다.

대화 기록은 어떤 플랫폼에서도 이전되지 않습니다. 새로운 모델은 새로운 대화입니다. API에서는 이것이 명백합니다. 메시지 배열을 직접 빌드하므로, 직접 전달하지 않는 한 아무것도 유지되지 않습니다. 채팅 인터페이스에서는 답변하는 주체가 바뀌었음에도 인터페이스가 연속적으로 보이기 때문에 이를 알아차리기 어려울 수 있습니다.

지식 컷오프는 어떤 컨텍스트 창 크기로도 보완할 수 없는 부분입니다. 2026년 4월 30일. 그 이후에 내린 여러분의 결정들이 4달 치나 쌓여 있습니다. 이는 우리가 계속해서 강조하는 차이점을 가장 명확하게 보여주는 예입니다: why long context isn't memory. 용량(Capacity)은 모델이 한 번에 담을 수 있는 양입니다. 메모리(Memory)는 시작할 때 그 안에 무언가 들어있는지 여부입니다.

컴퓨터 사용(Computer use)은 '컨텍스트'가 의미하는 바 자체를 바꿉니다. Astra는 컴퓨터 사용을 지원하며, 모델 페이지에는 Apply patch, Skills, MCP, Tool search가 지원되는 것으로 나열되어 있습니다. 에이전트가 여러분을 대신하여 애플리케이션을 작동할 때, 관련 컨텍스트는 단순히 코드베이스뿐만이 아닙니다. 에이전트가 접근할 수 있는 시스템은 무엇인지, 해당 시스템의 내부 명칭은 무엇인지, 지난달에 적용한 임시 방편 중 어떤 것이 여전히 필요한지 등이 포함됩니다. 이러한 정보는 리포지토리에서 유추할 수 없으며, 4월까지만 학습된 모델에는 존재하지 않습니다.

스냅샷은 지식이 아니라 동작을 고정합니다. 문서에 따르면 "스냅샷을 사용하면 모델의 특정 버전을 고정하여 성능과 동작을 일관되게 유지할 수 있습니다"라고 나와 있습니다. 재현성에는 유용하지만, 고정된 버전이라고 해서 프로젝트에 대한 정보를 더 많이 갖게 되는 것은 아닙니다.

1단계: 모델이 가지고 있지 않은 4달 동안의 기록 작성하기

이 작업은 전체 전환 과정에서 가장 가치 있는 한 시간이지만, 이를 실천하는 사람은 거의 없습니다.

5월 이후 머지된 풀 리퀘스트, 의사결정 기록, 계속 링크하게 되는 Slack 스레드 등 팀의 최근 이력을 열고 무엇이 변경되었는지 기록해 보세요. 모든 것을 적을 필요는 없습니다. 에이전트가 모르면 잘못 처리할 만한 내용만 적으면 됩니다.

구체적으로 이는 대개 다섯 가지 범주로 나뉩니다. 의존성 및 프레임워크 이동: 무엇으로 마이그레이션했는지, 그리고 결정적으로 무엇에서 벗어났는지 적어야 합니다. 이전 지식으로 학습된 모델은 이전 방식을 자신 있게 제안할 것이기 때문입니다. 지원 중단(Deprecations): 코드베이스에는 여전히 존재하지만 더 이상 확장해서는 안 되는 서비스, 엔드포인트 및 내부 라이브러리. 4월 이후 확정된 규칙: 명명 규칙 결정, 에러 처리 패턴, 리뷰 규칙 등. 소유권 변경: 현재 어떤 팀이 어떤 영역을 소유하고 있는지. 이유가 포함된 제약 조건: "두 개의 모바일 클라이언트가 이전 빌드를 고정하고 있기 때문에 API 버전을 경로에 포함합니다"와 같은 제약 조건은 열 줄의 스타일 가이드보다 가치 있습니다. 이유가 없으면 에이전트가 이를 친절하게 제거해 버릴 수 있기 때문입니다.

그런 다음 이를 영구적인 곳에 보관하세요. 지침이 이미 AGENTS.md나 CLAUDE.md에 있다면 그곳에 추가하면 됩니다. 이 파일들은 모델과 무관하므로 다음 전환 시에도 이 작업이 유지됩니다. 이에 대한 자세한 논의는 turning project docs into AI memory에서 확인할 수 있습니다.

2단계: 혼용 기간 동안의 처리 방식 결정 및 단일 대화 검증

단계적 출시 기간 동안에는 두 모델을 모두 사용하게 됩니다. 다음 두 가지 결정을 내리면 이 기간을 무사히 넘길 수 있습니다.

첫째, 모델별로 지침을 관리하지 말고 지침 레이어를 한 곳에 유지하세요. 이전 환경을 위해 기존 파일을 남겨둔 채 Astra에 맞춰 튜닝된 지침 파일을 따로 작성하고 싶은 유혹이 생길 수 있습니다. 하지만 이는 첫날부터 두 파일이 서로 달라지게 만들며, why agents ignore your instruction files에서 설명한 현상(에이전트가 지침 파일을 읽지 못하는 것이 아니라, 서로 일치하지 않는 여러 복사본 중 하나를 읽는 문제)을 유발하는 원인이 됩니다.

둘째, 추론 노력을 플랫폼 기본값에 맡겨두지 말고 의도적으로 조정하세요. reasoning.effort는 low부터 max까지 설정할 수 있으며, 모델에 컨텍스트가 부족한 작업에 대해 더 높은 노력을 들이도록 설정한다고 해서 더 나은 답변이 나오지는 않습니다. 오히려 더 철저하게 추론된 잘못된 답변을 만들어낼 뿐입니다. 먼저 컨텍스트를 제공하세요.

그런 다음 딱 한 번 검증해 보세요. 새로운 Astra 대화를 시작하고, 4월 이후의 결정에만 의존하는 올바른 답변(즉, 컷오프 이전의 답변은 확실히 틀린 질문)을 질문해 보세요. 돌아오는 답변을 읽어보십시오. 만약 이전 답변을 준다면 지침 레이어가 모델에 도달하지 못하고 있는 것이며, 이를 풀 리퀘스트 단계가 아니라 단 2분 만에 알아낸 것입니다.

이 작업을 수행하는 동안, 실제로 100만 토큰을 사용하는 데 드는 비용이 얼마인지 확인해 보세요. 컨텍스트 창이 매우 크면 모든 것을 복사해서 붙여넣고 싶어지지만, 전체 리포지토리로 가득 찬 대화는 중요한 10가지 사실만 담고 있는 대화와 다릅니다. 로드하는 내용과 반환받는 결과 사이의 관계는 keeping less in agent memory의 주제입니다.

위의 모든 작업은 실제 공수가 들어가는 일이며, 불편한 점은 여러분이 GPT-5.6 때도 이 작업을 수행했고 12월에 출시될 새로운 모델에 대해서도 똑같이 반복하게 될 것이라는 점입니다. 모든 모델 전환이 컨텍스트 마이그레이션으로 변하는 이유는 컨텍스트가 잘못된 위치(대화 내부 또는 도구별로 유지 관리하는 파일 내부)에 저장되어 있기 때문입니다.

대안은 영구적으로 유지되어야 하는 정보를 두 곳 모두의 외부에서 관리하는 것입니다. 모델이 바뀐다고 해서 프로젝트에 대한 사실이 바뀌지는 않습니다. 에이전트가 읽는 레이어에 이 정보가 존재한다면, 모델 전환은 원래 그래야 하듯이 단순히 '모델 전환'일 뿐입니다. 동일한 지식을 다른 모델에 연결하기만 하면 모델이 정보를 파악한 상태로 시작할 수 있습니다.

또한 이는 지식 컷오프 문제를 일회성이 아니라 영구적으로 해결해 줍니다. 2026년 4월 30일은 더 이상 긴 복사 붙여넣기로 때워야 하는 절벽이 아닙니다. 그 이후의 4달 동안의 정보가 모델이 접근할 수 있는 곳에 기록되어 있기 때문입니다. MemoryLake는 단 세 단계로 설정할 수 있습니다.

1단계: API 키 생성

로그인한 후 대시보드에서 API 키를 생성합니다. 이 키는 모델, 스냅샷 또는 요금제 티어에 종속되지 않으므로, 새로운 모델에 대한 액세스가 여러 플랫폼에 걸쳐 단계적으로 제공되는 동안 매우 유용하게 작용합니다.

2단계: 첫 번째 메모리 업로드

위의 1단계 목록부터 시작해 보세요: 무엇으로 이동했고 무엇에서 벗어났는지, 지원 중단된 항목은 무엇인지, 4월 이후 확정된 규칙, 소유권, 그리고 이유가 첨부된 제약 조건들입니다.

컴퓨터 사용 에이전트가 필요로 하지만 스스로 유추할 수 없는 정보들을 추가하세요. 에이전트가 다루어야 할 내부 시스템, 팀에서 부르는 명칭, 벤더가 아직 해결하지 않아 여전히 존재하는 수동 단계 등이 이에 해당합니다.

3단계: AI 및 에이전트 연결

Astra가 이 저장소를 바라보게 하고, 다른 곳에서 여전히 실행 중인 다른 모델들도 동일한 저장소를 바라보게 하세요. 단계적 출시 기간 동안 이는 단일 진실 공급원(Single Source of Truth)을 갖는 것과 서로 어긋나는 두 개의 정보원을 갖는 것의 차이를 만듭니다. 이에 대한 자세한 내용은 switching between AI models without losing context에서 다루고 있습니다.

첫 번째 변화는 컷오프 날짜가 더 이상 중요하지 않게 된다는 점입니다. 모든 모델에는 컷오프가 있고 모두 과거의 시점입니다. 다음 릴리스가 이 선을 충분히 뒤로 미뤄주기를 바라는 대신, 최근의 이력을 직접 기록함으로써 그 공백을 메울 수 있습니다.

두 번째는 큰 컨텍스트 창이 의무가 아니라 기능(Capability)이 된다는 점입니다. 100만 토큰을 담을 수 있다고 해서, 자신이 누구인지(프로젝트의 맥락이 무엇인지)를 다시 설명하는 데 그 토큰을 낭비할 필요는 없습니다. 오리엔테이션이 아니라 실제 작업 내용을 로드하세요.

세 번째는 다음 전환 비용이 매우 저렴해진다는 점입니다. 올해 들어 프론티어 모델의 출시로 팀들이 이전을 고민하게 만든 것이 벌써 네다섯 번째입니다. 매번 온전한 비용을 치르는 팀들은 컨텍스트가 대화 속에 머물러 있는 팀들입니다.

• 두 숫자를 모두 확인하세요. 1,050,000 토큰의 용량과 2026년 4월 30일 지식 컷오프. 여러분의 작업을 바꾸는 것은 두 번째 숫자입니다.
• 컷오프 이후의 기간을 기록하세요. 프레임워크 이동, 지원 중단, 규칙, 소유권, 이유가 포함된 제약 조건 등.
• 모델별이 아닌 단 하나의 지침 레이어를 유지하세요. 지침 파일은 원래 모델에 종속되지 않습니다. 굳이 그렇게 만들지 마세요.
• 혼용 기간을 예상하세요. 출시는 Trusted Access, API, 유료 요금제를 통해 단계적으로 진행되며, API Free 티어는 지원되지 않는 것으로 표시되어 있습니다.
• reasoning.effort를 의도적으로 설정하세요. low부터 max까지는 실질적인 범위이며, 노력이 컨텍스트를 대체할 수는 없습니다.
• 4월 이후의 질문으로 검증하세요. 컷오프 이전의 답변이 틀린 프롬프트 하나만으로도 컨텍스트가 모델에 도달하고 있는지 알 수 있습니다.
• 지식이 아니라 재현성을 위해 스냅샷을 고정하세요. 고정된 버전은 일관되게 동작할 뿐, 더 많은 것을 알지는 못합니다.
• 컴퓨터 사용에 고유한 컨텍스트를 제공하세요. 어떤 시스템인지, 내부적으로 어떻게 불리는지, 어떤 임시 방편이 여전히 적용되는지 등.

Astra에서 흥미로운 점은 100만 토큰을 담을 수 있다는 사실이 아닙니다. 이토록 유능한 모델조차도 매 대화를 시작할 때 여러분의 팀이 5월에 무엇을 결정했는지 모른 채 시작한다는 점입니다.

성공적으로 전환한다는 것은 이 두 가지 문제를 분리하는 것을 의미합니다. 기능(Capability)은 모델에서 나오며, 이는 진정으로 더 뛰어납니다. 지식(Knowledge)은 여러분에게서 나오며, 매번 전환할 때마다 지식 비용을 치르지 않는 유일한 방법은 대화가 일어났던 임의의 장소가 아니라 모델이 읽을 수 있는 곳에 지식을 보관하는 것입니다.