At the GPT‑5 launch, Sam Altman described the model as a significant step toward AGI moving the field closer to general intelligence capabilities
그러나 실제 사용한 사람들은 5버전이 AGI가 아닌 퇴보에 가깝다고 비난을 했지만,
이제 제미나이 등의 발전을 보고 있다보니 이제는 어느정도 이해할 수 있을 것 같다.

- Stateful Conversation
Responses API 덕분에 모델이 이전 대화를 기억하고 이어가는 환경 내장
개발자가 전체 history를 매번 관리할 필요 없음
- Tool Orchestration 내장
웹 검색, 파일 조회, 계산 등 외부 도구 사용을 모델 내부에서 처리 가능
반복 루프와 상태 관리 코드는 API가 자동 처리
- 멀티모달 + 에이전틱 구조
텍스트, 이미지, 코드, 데이터까지 통합 처리
모델이 스스로 목표를 달성하도록 행동
샘 올트만의 발언은 단순 마케팅이 아니라, 구조적 변화를 반영한 선언이었다.
즉, GPT‑5 출시 이후부터는 개발자가 직접 에이전트를 설계하지 않아도, 모델이 “판단하고 행동하는 AI”,
다시 말해 AGI에 한발 더 가까운 형태로 활용될 수 있다는 의미였다.
2023~2024년까지의 API 구조는 기본적으로 stateless(상태값이 없음)였다.
개발자가 아닌 사람들은 모르겠지만, 실제 개발자는 매 요청마다 messages : []
전체를 다시 보내야 했고 이전 대화를 서버가 기억하지 않았고, tool 호출도 우리가 루프를 짜서 처리해야 했다
이 시기의 대표 API는 모두 상태 값을 보존하지 않았다(기억하지 않음)
- OpenAI의 Chat Completions
- Anthropic의 Claude Messages API
- Google의 초기 Gemini API
모델은 똑똑했지만, 에이전트는 아니었다.
각자의 개발자들이 , 대화를 이어나가는 것처럼 만들기 위해서
- 대화 상태 저장
- 토큰 관리
- tool 호출 후 재요청
- 오류 처리
- 반복 루프 설계
즉, “에이전틱 AI”를 만들려면 모델 위에 우리가 에이전트를 직접 구현해야 했다.

🚀 Responses API 공개 (2025년 3월) → 그러나 실제 제대로 사용가능한것은 GPT 5부터(2025년 8월)
OpenAI는 2025년 3월, Responses API를 공개했다.
이 API는 단순한 리네이밍이 아니었다.
previous_response_id 기반 상태 유지
서버 측 대화 관리
내장 tool 호출 통합
웹 검색 / 파일 검색 / 컴퓨터 사용 내장이제 개발자는 이전 응답 이어서 계속해
라고 요청할 수 있게 됐다.
이건 엄청난 변화였다.
🚀 GPT‑4o의 구조적 한계
한계 | 이유 |
|---|---|
상태 유지 어려움 | 모델 자체가 stateless, 모든 context를 개발자가 전달해야 함 |
tool orchestration 제한 | 외부 tool 호출과 반복 루프를 직접 구현해야 함 |
멀티턴 안정성 부족 | context window와 session 관리 기능 한계 |
에이전틱 AI 구현 난이도 | 모델 + 개발자가 만들어야 할 agent 로직이 많음 |
즉, GPT‑4o는 강력했지만 “에이전틱 AI 구현 환경”으로 쓰기에는 구조적 제약이 있었다.
반대로 GPT‑5 이후 구조는:
- stateful session 내장
- tool orchestration 통합
- multi-turn, multi-tool 안정성 확보
덕분에 개발자가 복잡한 agent를 구현하지 않아도, 모델이 스스로 판단하고 행동하는 환경을 만들 수 있게 된 것이다.
🔁 Gemini Interactions API (2025년 12월 베타)
Gemini API 위에 Interactions API를 베타로 공개했다.
여기서도 핵심은 같다:
- 멀티턴 상태 유지
- tool orchestration
- 세션 기반 흐름 관리
Google은 원래 Gemini에서 멀티턴은 지원했지만, 이걸 명확하게 agent형 API로 추상화한 건 2025년 12월이었다.
이 두 사건은 단순한 API 업데이트가 아니었다.
이건 “AI를 어떻게 호출하느냐”의 패러다임 전환이었다.
구분 | 2024년 이전 | 2025년 이후 |
|---|---|---|
상태 관리 | 개발자가 직접 | API가 일부 관리 |
tool 루프 | 직접 구현 | 내장 지원 |
에이전트 구현 | 복잡 | 간단 |
구조 | LLM 호출 | Agent 실행 |
이 시점부터 모델은 단순 “텍스트 생성기”가 아니라 상태를 유지하는 실행 엔진에 가까워졌다.
1. Stateless → Stateful 추상화
이전:
모델은 기억하지 않는다.
이후:
세션과 응답 ID 기반으로 흐름을 이어간다.
2. Tool이 “외부 기능”이 아니라 “내장 기능”이 됨
웹 검색, 파일 검색, 시스템 제어가 이제 모델 외부 확장이 아니라 API 구조 안으로 들어왔다.
이건 모델이 아니라 플랫폼이 에이전트화된 것이다.
3. LLM → Agent Runtime
2024년:
LLM + 우리가 만든 로직
2025년:
Agent Runtime + LLM
이 차이는 구조적으로 크다.
항목 | Anthropic Claude | OpenAI GPT‑5 + Responses API | Google Gemini + Interactions API |
|---|---|---|---|
상태 유지 | ❌ Stateless – 매 요청 전체 메시지 전달 필요 | ✅ Stateful – previous_response_id로 세션 유지 | ✅ Stateful – multi-turn, session 기반 |
tool orchestration | ❌ 직접 구현 필요, 호출 후 결과 전달 | ✅ 내장 – 웹/파일/계산 자동 | ✅ 내장 – API 내 도구 호출 통합 |
멀티턴 지원 | 가능하지만 개발자 직접 관리 | 내장 multi-turn, 안정적 | 내장 multi-turn, 안정적 |
토큰/비용 효율 | ❌ 대화 길수록 선형 증가, 컴팩팅 필요 | ✅ 이전 응답 ID만 전달 → 효율적 | ✅ 서버 관리 → 효율적 |
멀티에이전트 구현 | ❌ 개발자 책임, 반복 루프 직접 설계 | ✅ API 내장으로 간단 | ✅ API 내장으로 간단 |
compacting/최적화 | ✅ SDK/클라이언트 수준, 메시지 요약 | ✅ 필요 없음, API 상태 관리 | ✅ 필요 없음, API 상태 관리 |
개발자 부담 | 높음 – 상태, tool, multi-turn, 비용 최적화 모두 직접 | 낮음 – 목표/전략 설계만 | 낮음 – 목표/전략 설계만 |
에이전틱 AI 적합도 | 제한적 | 높음 – 내장 agent 환경 | 높음 – 내장 agent 환경 |
GPT‑5 이후 구조와 OpenAI Responses API, Google Gemini Interactions API 덕분에,
개발자는 단순 텍스트 생성기를 넘어 ‘실행 가능한 에이전트’를 설계할 수 있는 환경을 갖게 되었다.
이제 가능해진 것들을 정리하면 다음과 같다.
1. 멀티에이전트 에코시스템
여러 AI 에이전트를 동시에 배치하고 협업하게 할 수 있다.
예: 하나의 에이전트는 데이터 수집, 다른 에이전트는 분석, 또 다른 에이전트는 보고서 작성.
이전에는 각 에이전트별 반복 루프와 상태 관리 코드를 개발자가 구현해야 했지만, 지금은 모델과 API가 이를 자동으로 관리.
2. 자동화된 연구/분석 도구
모델이 웹 검색, 데이터베이스 조회, 코드 실행까지 수행하며 연속적인 분석 흐름을 생성 가능.
예: 시장 보고서 작성 → 경쟁사 동향 조사 → 시각화 자료 생성 → 보고서 초안 작성까지 모델 단독 실행 가능.
개발자는 단지 “목표와 전략”만 설계하면 됨.
3. 멀티모달 에이전틱 AI
텍스트, 이미지, 코드, 데이터 등 다양한 형식의 정보를 통합해 처리할 수 있다.
예: 디자인 콘셉트 생성 → 이미지 프로토타입 제작 → 피드백 반영 → 최종 산출물 생성까지 모델이 단일 세션 안에서 수행.
이전에는 각 미디어마다 별도 루프와 상태 관리 필요.
4. 개인화·컨텍스트 기반 에이전트
모델이 대화와 행동을 사용자별 컨텍스트에 맞게 유지.
예: 개인 비서, 고객 대응 AI, 학습 도우미 등.
이전에는 개발자가 매번 사용자의 모든 history를 관리해야 했지만, 지금은 세션과 previous_response_id로 자연스럽게 유지 가능.
5. 에이전틱 AI 플랫폼화
단일 모델이 아니라 모델 + API + tool orchestration = Agent Runtime 구조.
즉, AI 자체가 플랫폼이 되어 다양한 서비스를 구축 가능.
예: 기업 내 자동화된 업무 처리, AI 기반 프로젝트 관리, 멀티툴 통합 서비스 등.
덕분에 개발자는 이제:
반복 루프를 설계하지 않고도 상태와 툴 관리를 신경쓰지 않고도 모델을 자율적 판단과 행동이 가능한 에이전트로 활용할 수 있다.
즉, “에이전틱 AI” 시대가 본격적으로 열린 것이고, 실제 서비스와 플랫폼 수준의 AI 개발이 가능해진 것이다.