go_bunzee

2026년 LLM은 당신의 대화를 기억하기 시작했다.(이전엔 안했다?!) | 매거진에 참여하세요

questTypeString.01quest1SubTypeString.00
publish_date : 26.02.24

2026년 LLM은 당신의 대화를 기억하기 시작했다.(이전엔 안했다?!)

#LLM #기억 #컨텍스트 #보존 #툴관리 #플랫폼 #에이전틱구조 #상태관리 #신기술 #2026년

content_guide

GPT‑5 출시일 2025년 8월 샘 올트만 Sam Altman은 직접 아래와 같이 강조했다.

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가 아닌 퇴보에 가깝다고 비난을 했지만,

이제 제미나이 등의 발전을 보고 있다보니 이제는 어느정도 이해할 수 있을 것 같다.

위의 말은 GPT‑5 이후버전부터, LLM의 구조가 완전히 바뀐것을 이야기한것이었다.

즉, 멀티에이전트 구조와 기억구조의 근본적인 변화가 발생했다.

  1. - Stateful Conversation

    • Responses API 덕분에 모델이 이전 대화를 기억하고 이어가는 환경 내장

    • 개발자가 전체 history를 매번 관리할 필요 없음

  2. - Tool Orchestration 내장

    • 웹 검색, 파일 조회, 계산 등 외부 도구 사용을 모델 내부에서 처리 가능

    • 반복 루프와 상태 관리 코드는 API가 자동 처리

  3. - 멀티모달 + 에이전틱 구조

    • 텍스트, 이미지, 코드, 데이터까지 통합 처리

    • 모델이 스스로 목표를 달성하도록 행동

샘 올트만의 발언은 단순 마케팅이 아니라, 구조적 변화를 반영한 선언이었다.
즉, GPT‑5 출시 이후부터는 개발자가 직접 에이전트를 설계하지 않아도, 모델이 “판단하고 행동하는 AI”,

다시 말해 AGI에 한발 더 가까운 형태로 활용될 수 있다는 의미였다.

그럼 이전에는 대화를 기억하지 못했어? 맞다 대화를 기억하지 않았다. 그렇게 보이도록 뒤에 만든것일뿐

2023~2024년까지의 API 구조는 기본적으로 stateless(상태값이 없음)였다.

  • 개발자가 아닌 사람들은 모르겠지만, 실제 개발자는 매 요청마다 messages : []

  • 전체를 다시 보내야 했고 이전 대화를 서버가 기억하지 않았고, tool 호출도 우리가 루프를 짜서 처리해야 했다

이 시기의 대표 API는 모두 상태 값을 보존하지 않았다(기억하지 않음)

  • - OpenAI의 Chat Completions

  • - Anthropic의 Claude Messages API

  • - Google의 초기 Gemini API

모델은 똑똑했지만, 에이전트는 아니었다.

각자의 개발자들이 , 대화를 이어나가는 것처럼 만들기 위해서

  • - 대화 상태 저장

  • - 토큰 관리

  • - tool 호출 후 재요청

  • - 오류 처리

  • - 반복 루프 설계

즉, “에이전틱 AI”를 만들려면 모델 위에 우리가 에이전트를 직접 구현해야 했다.

2025년 하반기부터 모델이 근본적으로 변경되었고, 2026년부터 정말 적용이 되기 시작했다.

🚀 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월이었다.

그래서 이전 vs 이후를 비교해보자

이 두 사건은 단순한 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

이 차이는 구조적으로 크다.

LLM/에이전틱 AI 구조 비교 (앤트로픽, 오픈AI, 제미나이)

항목

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 환경

2026년부터, 우리가 이것을 기반으로 만들 수 있는 것들

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 기반 프로젝트 관리, 멀티툴 통합 서비스 등.

2025년 GPT‑5 이후 구조에서 달라진 점은 단순히 “모델 성능”이 아니라 모델 + API + 도구 + 상태 유지가 하나의 환경으로 통합된 것이다.

덕분에 개발자는 이제:

  • 반복 루프를 설계하지 않고도 상태와 툴 관리를 신경쓰지 않고도 모델을 자율적 판단과 행동이 가능한 에이전트로 활용할 수 있다.

즉, “에이전틱 AI” 시대가 본격적으로 열린 것이고, 실제 서비스와 플랫폼 수준의 AI 개발이 가능해진 것이다.