티스토리 뷰
GPT-6 Astra에서 주목할 부분은 단순한 모델 성능 향상만이 아니다.
ARC-AGI-3 평가에서 Astra는 일반적인 실행 환경에서도 높은 성능을 보였지만, OpenAI가 제공하는 상태 유지형 실행 구조를 활용했을 때 성능이 훨씬 더 크게 향상됐다.
이 결과가 보여주는 중요한 변화는 하나다.
앞으로 Agent의 성능은 Model 자체뿐 아니라 Model을 어떤 Runtime과 Harness에서 실행하느냐에 크게 좌우될 수 있다.
그리고 이 변화는 Agent Architecture의 역할에도 영향을 주기 시작했다.
1. Agent Framework가 직접 하던 일이 Provider 기능으로 이동하고 있다
초기 LLM Application은 비교적 단순했다.
Application
↓
Prompt
↓
LLM
↓
Response
Agent가 등장하면서 구조는 빠르게 복잡해졌다.
Application
↓
Agent Framework
├ Planning
├ Memory
├ Context 관리
├ Tool Loop
├ Reflection
└ Retry
↓
LLM
모델만으로는 장기 작업이나 복잡한 Tool 실행을 안정적으로 처리하기 어려웠기 때문에 Application과 Framework가 많은 기능을 직접 구현해야 했다.
하지만 최근에는 상황이 달라지고 있다.
GPT-5.6부터 Persisted Reasoning과 Context Compaction이 제공되기 시작했고, GPT-6 Astra에서는 Async Tool Calling과 Mid-turn Steering 같은 기능까지 추가됐다.
즉 기존에 Framework가 직접 구현했던 일부 기능이 점차 Provider Runtime의 기본 기능으로 이동하고 있다.
Application / Agent Platform
↓
Provider Runtime
├ Reasoning State
├ Context Management
├ Tool Execution Loop
├ Async Tool
└ Steering
↓
Model
이제 Model 하나만 보는 것이 아니라 Model + Runtime을 하나의 실행 능력으로 볼 필요가 있다.
2. Stateful Agent가 기본적인 실행 방식이 되고 있다
기존 LLM 호출은 대체로 Stateless했다.
매 호출마다 이전 대화와 필요한 Context를 다시 전달했다.
Request
+ Previous Messages
+ Context
↓
LLM
장기 작업에서는 이전 계획이나 진행 상황을 다시 구성해 전달해야 했다.
Stateful Runtime에서는 구조가 달라진다.
Run #1
↓
Provider State
↓
Run #2
↓
Provider State
↓
Run #3
이전 실행의 상태를 이어받아 작업을 지속할 수 있다.
이 방식의 장점은 단순히 API 호출이 편해지는 것이 아니다.
모델이 이전에 형성한 계획과 작업 맥락을 반복해서 재구성하지 않아도 되기 때문에 장기 추론의 연속성과 효율이 좋아질 수 있다.
Astra의 ARC-AGI-3 결과는 이 효과를 매우 극적으로 보여준 사례다.
3. Context 관리 방식도 달라질 가능성이 크다
과거 Agent에서는 긴 대화가 발생하면 Application이 직접 다음과 같은 작업을 수행하는 경우가 많았다.
Conversation History
↓
Summary 생성
↓
중요 정보 추출
↓
Prompt 재구성
하지만 Provider가 Context Compaction과 Working State를 관리하기 시작하면 이런 로직의 일부는 불필요해질 수 있다.
앞으로 Application에서 더 중요해질 Context는 오히려 모델이 스스로 만들어낸 과거 추론 내용보다 외부 세계의 신뢰할 수 있는 현재 정보다.
예를 들면 다음과 같다.
User Context
Current Service State
Device / Environment State
Business Data
Domain Knowledge
즉 Context Architecture의 중심도
“어떻게 이전 대화를 잘 요약해서 넣을 것인가”
에서
“모델이 필요할 때 신뢰할 수 있는 최신 정보를 어떻게 제공할 것인가”
로 이동할 가능성이 크다.
4. Planning과 Reflection을 얼마나 직접 구현해야 할까?
Agent Framework에는 전통적으로 이런 구조가 많이 사용됐다.
Planner
↓
Executor
↓
Evaluator
↓
Reflection
↓
Replan
복잡한 문제를 여러 번의 LLM 호출로 나누어 해결하기 위한 방법이었다.
하지만 모델이 하나의 지속적인 Reasoning State 안에서
관찰
→ 계획
→ Tool 실행
→ 결과 분석
→ 계획 수정
을 수행할 수 있게 되면 별도의 Planner나 Reflection 단계를 항상 구현할 필요는 줄어들 수 있다.
물론 Explicit Workflow나 검증 단계가 필요한 경우는 여전히 존재한다.
다만 앞으로는
모델의 부족한 추론 능력을 보완하기 위해 만든 구조인지, 실제 서비스가 요구하는 명시적인 실행 구조인지
를 구분할 필요가 있다.
전자의 경우 Model과 Provider Runtime 발전에 따라 빠르게 불필요해질 수 있기 때문이다.
5. Async Tool Calling은 Agent 실행 방식을 바꾼다
기존 Tool Calling은 보통 이런 방식이다.
Agent
↓
Tool A 호출
↓
Tool A 완료 대기
↓
다음 추론
느린 Tool 하나가 전체 Agent 실행을 멈출 수 있다.
Async Tool Calling에서는 달라진다.
Tool A ───────────────┐
│
Agent → 분석 → Tool B │
↓ │
다른 작업 │
│
Tool A 완료
즉 Agent가 Tool의 완료를 기다리는 동안 독립적인 작업을 계속 진행할 수 있다.
이는 장기 작업이나 여러 외부 시스템을 사용하는 Agent에서 상당히 중요한 변화다.
하지만 한 가지 오해해서는 안 된다.
모델이 Async Tool을 호출할 수 있다는 것과 실제 Tool 실행 상태를 안전하게 관리하는 것은 다른 문제다.
외부 시스템에서는 여전히 다음과 같은 기능이 필요하다.
- Timeout
- Retry
- 중복 실행 방지
- 권한 확인
- 실행 결과 확인
- 오류 복구
모델의 자율성이 높아질수록 오히려 실제 실행 경계는 더 명확하게 관리해야 한다.
6. Mid-turn Steering은 Agent를 ‘대화 가능한 실행 프로세스’로 만든다
장기 Agent 작업에서는 사용자의 상황이나 요구사항이 실행 중 바뀔 수 있다.
기존 방식에서는 현재 작업을 중단하거나 완료한 후 새로운 요청을 처리해야 하는 경우가 많았다.
Mid-turn Steering이 가능해지면 사용자가 실행 중간에 새로운 조건을 줄 수 있다.
Agent 작업 시작
↓
검색 / 분석
↓
User:
"그 조건은 제외해줘"
↓
현재 작업 방향 수정
↓
계속 실행
Agent가 단순히 요청 하나를 처리하는 시스템에서 진행 중인 작업을 사용자와 함께 조정하는 시스템으로 바뀌는 것이다.
장기 Research, Coding, Planning, Automation Agent에서는 특히 중요한 변화다.
다만 이미 실행된 외부 행동까지 자동으로 되돌려주는 것은 아니다.
따라서 실제 Side Effect가 존재하는 시스템에서는 승인, 취소, 보상과 같은 별도의 실행 정책이 계속 필요하다.
7. Stateful Agent가 강해질수록 Recovery는 더 중요해진다
Stateful Runtime에는 큰 장점이 있지만 새로운 문제도 생긴다.
Provider 내부에 Working State가 쌓여 있는 상태에서 장애가 발생하면 어떻게 할 것인가?
Stateless 환경에서는 단순히 다른 모델에 같은 Prompt를 전달하는 방식이 가능했다.
Stateful Agent에서는 그렇게 단순하지 않다.
Provider 내부의 Reasoning State를 다른 모델이나 다른 Provider가 그대로 이해할 수 있다고 기대하기 어렵기 때문이다.
따라서 중요한 원칙은 다음과 같다.
Provider의 Working State와 실제 서비스의 Durable State를 구분해야 한다.
Provider가 관리해도 좋은 것은 다음과 같다.
현재 추론
임시 계획
중간 작업 맥락
Context Compaction 결과
반대로 Application이 독립적으로 관리해야 하는 것은 다음과 같다.
실제 업무 진행 상태
완료된 외부 작업
사용자 승인
중요한 데이터 변경
장기적으로 유지할 정보
장애가 발생하면 Provider 내부 사고 상태를 복원하는 것보다, 이런 Durable State를 기반으로 새로운 Agent가 작업을 이어갈 수 있도록 만드는 것이 더 현실적이다.
8. Workflow는 여전히 별개의 문제다
모델이 Long-horizon task를 잘 수행한다고 해서 Workflow Engine이 불필요해지는 것은 아니다.
두 가지는 목적이 다르다.
Agent Reasoning은
“다음에 무엇을 해야 하는가?”
를 결정한다.
Workflow는
“실제 작업이 어디까지 실행되었는가?”
를 관리한다.
예를 들어 다음과 같은 상태는 모델의 기억에 맡길 수 없다.
WAITING_FOR_APPROVAL
PAYMENT_COMPLETED
STEP_3_FAILED
RETRY_COUNT = 2
COMPENSATION_REQUIRED
특히 장기 실행, Approval, Retry, Compensation이 필요한 업무에서는 Durable Workflow가 계속 중요한 역할을 한다.
Provider Runtime이 Cognitive Execution을 흡수하더라도 Business Execution까지 모두 대체하는 것은 아니다.
9. 무엇은 줄어들고 무엇은 더 중요해질까?
Astra와 최근 Agent Runtime의 발전 방향을 보면 앞으로 자체 구현 필요성이 줄어들 가능성이 높은 영역이 있다.
직접 구현 비중이 줄어들 가능성이 높은 영역
- Basic Agent Loop
- 중간 추론 상태 관리
- Conversation Summary
- 단순 Context Compaction
- 범용 Planning
- 범용 Reflection
- 단순 Agent Handoff
반대로 중요성이 더 커질 영역도 있다.
더 중요해질 가능성이 높은 영역
- Durable Workflow
- Tool Execution Control
- Authorization / Policy
- 신뢰 가능한 외부 Context
- Long-Term Source of Truth
- Recovery / Fallback
- Verification
- Observability / Audit
전체 방향을 단순화하면 다음과 같다.
점점 Provider가 담당
────────────────────
Think
Plan
Remember Working State
Select Tool
Compact
Reflect
그리고 Application Platform에는 다음이 남는다.
계속 Application이 담당
──────────────────────
Can it be done?
Should it be done?
Has it been done?
Was it successful?
How do we recover?
10. Agent Platform의 역할 자체가 변하고 있다
과거 Agent Framework의 중요한 역할 중 하나는 모델의 부족한 능력을 보완하는 것이었다.
Model
+
Planner
Memory
Reflection
Tool Loop
Context Summary
하지만 Model과 Provider Runtime이 계속 발전한다면, 이러한 보완 기능에 대한 자체 구현 가치는 점차 낮아질 수 있다.
그 대신 Agent Platform의 역할은 다음과 같이 이동한다.
강력한 Model Runtime
↓
Agent Platform
↓
실제 서비스
Agent Platform은 모델에게 생각하는 방법을 가르치는 계층보다는,
계속 발전하는 Model Runtime을 실제 서비스의 데이터, 도구, 정책 및 Workflow에 안전하게 연결하는 계층
이 되어갈 가능성이 높다.
GPT-6 Astra는 이 변화를 처음 만든 모델이라기보다, 이미 진행되고 있던 흐름을 매우 선명하게 보여준 사례에 가깝다.
결국 앞으로 중요한 질문은
“Agent 기능을 얼마나 많이 직접 구현할 것인가?”
보다
“어떤 책임을 Provider에게 넘기고, 어떤 책임은 끝까지 Application이 가져가야 하는가?”
가 될 가능성이 크다.
그리고 그 경계를 잘 설계하는 것이 앞으로 Agent Architecture에서 가장 중요한 과제 중 하나가 될 것이다.