지난 18개월 동안 여러분이 2024년에 배웠던 LLM API는 더 저렴해졌고, 더 길어졌으며, 훨씬 더 신뢰할 수 있게 되었습니다. 개발자 대상의 다섯 가지 기능이 제가 실제로 빌드하는 방식을 바꾸어 놓았습니다: 프롬프트 캐싱 (Prompt caching), 백만 토큰 컨텍스트 (Million-token context), 엄격한 구조화된 출력 (Strict structured outputs), 모델 컨텍스트 프로토콜 (Model Context Protocol), 그리고 추론 노력 제어 (Reasoning-effort controls)입니다. 하지만 제가 매일 마주치는 두 가지 문제에는 여전히 깔끔한 해답이 없습니다: 휴대 가능한 메모리 (Portable memory)와 진정한 결정론 (Real determinism)입니다.

저는 생업으로 에이전트 시스템 (Agent systems)을 구축하고 있기 때문에, 이러한 API들을 끊임없이 다룹니다. 2024년에 제가 "알고 있었던" 것들의 절반은 이제 느리고 비용이 많이 드는 방식이 되었습니다. 만약 여러분이 몇 년 전에 OpenAI나 Anthropic API를 배웠고 그 이후로 살펴보지 않았다면, 이것이 바로 따라잡기 위한 내용입니다.

1. 프롬프트 캐싱 (Prompt caching)은 반복되는 접두사 비용을 약 90% 절감합니다

프롬프트 캐싱 (Prompt caching)은 프롬프트의 안정적인 앞부분을 저장하여, 매 호출마다 이를 다시 전송하는 데 전체 비용을 지불하지 않도록 합니다. 만약 거대한 시스템 프롬프트 (System prompt)나 요청 전반에 걸쳐 반복되는 긴 문서가 있다면, 이것이 여러분이 가질 수 있는 가장 큰 비용 조절 레버입니다.

현재 3대 주요 제공업체 모두 서로 다른 사용 편의성(Ergonomics)을 가지고 이를 출시했습니다. OpenAI와 Gemini는 접두사가 반복되면 자동으로 캐싱합니다. Anthropic은 사용자가 직접 중단점(Breakpoint)을 설정하게 만드는데, 이는 더 나쁘게 들릴 수 있지만 정확한 제어권을 제공합니다:

import anthropic
client = anthropic.Anthropic()

...

캐시 읽기 (Cache reads) 비용은 Anthropic과 Gemini에서 일반 입력 토큰보다 약 90% 저렴하게 실행됩니다 (OpenAI의 자동 할인은 약 50%입니다). 쓰기 비용은 Anthropic에서 약간 더 비싼데, 5분 캐시는 약 1.25배, 1시간 옵션은 2배입니다. 접두사가 단 두 번만 재사용되어도 즉시 이득을 봅니다. 무거운 시스템 프롬프트가 포함된 채팅 백엔드에서는 이것만으로도 입력 비용을 한 자릿수(An order of magnitude)만큼 낮출 수 있습니다.

2. 백만 토큰 컨텍스트 (Million-token context)는 이제 프리미엄 등급이 아닌 표준입니다

1M-토큰 컨텍스트 윈도우 (context window)는 과거 Gemini의 눈길을 끄는 기술 (party trick)에 불과했습니다. 2026년 현재, 이는 프런티어 (frontier) 모델의 기본 사양이며 추가 비용도 사라졌습니다.

Claude Opus와 Sonnet은 표준 요금으로 1M 컨텍스트를 실행합니다 (Anthropic은 2026년 3월에 롱 컨텍스트 (long-context) 추가 요금을 폐지했습니다). GPT-5.5는 1M 윈도우를 탑재하여 출시되었습니다. Google의 최신 Gemini Pro 역시 1M을 지원하며, 상위 등급에서는 2M까지 도달합니다. 저 또한 1M 컨텍스트 모델을 사용하고 있기에 솔직한 주의 사항을 말씀드리자면, 회상률 (recall)이 완벽하게 일정하지는 않습니다. Google이 발표한 건더기 찾기 (needle-in-a-haystack) 수치에 따르면, 컨텍스트가 1M에 가까워지면 회상률이 약 99.7%로 떨어지는 반면, 그 절반 수준에서는 사실상 100%에 달합니다. "이 전체 코드베이스를 머릿속에 담아두기"에는 훌륭하지만, 정밀한 조회를 위해서는 여전히 검색 레이어 (retrieval layer)를 사용하는 것이 가치가 있습니다. 전체 윈도우를 무료 RAM처럼 취급하지 마세요.

3. 구조화된 출력 (Structured outputs)은 JSON 형태의 희망이 아닌, 스키마에 유효한 JSON을 제공합니다

구조화된 출력은 모델이 사용자의 스키마 (schema)와 일치하는 JSON을 출력하도록 디코딩 (decoding) 과정에서 제약합니다. 따라서 깨진 대괄호를 수정하기 위해 정규 표현식 (regex)을 작성하는 일을 멈출 수 있습니다. 이 기능은 제 코드에서 한 종류의 파싱 (parsing) 버그를 조용히 제거해 주었습니다.

과거의 "JSON 모드 (JSON mode)"는 구문적으로 유효한 JSON만을 보장했을 뿐, 사용자의 필드와 일치한다는 보장은 없었습니다. 2026년 버전은 스키마를 엄격히 준수합니다:

from openai import OpenAI
client = OpenAI()

...

이것은 Chat Completions 형태이며, 여전히 작동합니다. OpenAI의 최신 Responses API에서는 동일한 스키마가 text.format 아래에 존재합니다. Anthropic도 이 부분에서 따라잡았습니다. 이제 단순히 과거의 도구 사용 (tool-use) 트릭이 아니라, output_config를 통한 네이티브 구조화된 출력을 지원하며, 엄격한 도구 스키마 (tool schemas)도 제공합니다. Gemini는 responseMimeType과 함께 responseSchema를 사용합니다. 만약 당신이 여전히 프롬프트 위협을 통해 모델로부터 JSON을 구걸하고 있다면, 이제 그만두세요. API가 당신을 위해 형태를 보장해 줄 것입니다.

4. MCP가 표준 전쟁에서 승리했습니다

모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)은 이제 모델을 당신의 도구 및 데이터와 연결하는 벤더 중립적인 (vendor-neutral) 표준이 되었으며, 이것이 바로 2026년의 진정한 헤드라인입니다. 이는 더 이상 "Anthropic의 전유물"이 아닙니다.

Anthropic은 MCP를 Linux Foundation에 기부했으며, 이후 Block 및 OpenAI와 함께 새로운 Agentic AI Foundation을 공동 설립했습니다. 여기에 Google, Microsoft, AWS가 멤버 스폰서로 참여했습니다. OpenAI는 2025년에 자사의 Agents SDK 전반에 MCP를 채택했습니다. Google은 Gemini SDK 전반에 지원을 추가했습니다. 따라서 이제 여러분의 데이터베이스나 이슈 트래커 (issue tracker)를 노출하는 동일한 서버가 모든 주요 클라이언트에서 작동합니다. 서버를 한 번만 정의하면, 어떤 MCP 클라이언트든 해당 서버와 통신할 수 있습니다:

// 어떤 MCP 클라이언트도 이해할 수 있는 단일 서버 정의
{
  "mcpServers": {
...

저는 이 기술을 적극적으로 활용하고 있습니다. 저의 개인 스택은 MCP 서버를 통해 브라우저, 결제 대시보드, 분석 백엔드 (analytics backend)와 통신하며, 이 중 어느 것을 위해서도 맞춤형 통합 (bespoke integration) 코드를 작성하지 않았습니다. MCP를 한 번만 배우면 모든 것에 연결할 수 있습니다.

5. 원시 토큰 예산 (raw token budget)을 대체한 추론 노력 (Reasoning effort)

추론 제어 (Reasoning controls) 기능을 사용하면 모델이 답변하기 전에 얼마나 깊게 생각할지를 조절할 수 있으며, 2026년에 이르러 이 조절 장치는 토큰 수 대신 단순한 노력 수준 (effort level)으로 바뀌었습니다. 이는 마법 같은 숫자를 추측할 필요 없이, 호출당 지연 시간 (latency)과 깊이 (depth)를 맞바꿀 수 있기 때문에 중요합니다.

OpenAI는 none부터 xhigh까지의 레벨을 가진 reasoning_effort를 제공합니다:

resp = client.chat.completions.create(
    model="gpt-5.5",
    reasoning_effort="high",   # none | low | medium | high | xhigh
...

이러한 수렴 과정을 주목하십시오. 이는 업계가 어디로 향하고 있는지를 보여주기 때문입니다. Anthropic은 최신 모델에서 적응형 사고 (adaptive thinking)와 노력 설정 (effort setting)을 위해 기존의 고정된 budget_tokens를 폐지했습니다. Gemini는 thinkingBudget에서 질적인 thinkingLevel로 이동하고 있습니다. 세 개의 벤더가 하나의 형태를 띠고 있습니다. 토큰 수가 아니라, 조절 노브 (knob) 형태입니다. 데이터 추출 (extraction)에는 낮게 설정하고, 논리적 방어가 필요한 작업에는 높게 설정하십시오.

여전히 기다리고 있는 것 #1: 어디서나 즉시 작동하는 메모리 프리미티브 (memory primitive)

저는 일반적인 API 프리미티브 (primitive)로서 세션 간에 지속되는 메모리 (persistent, cross-session memory)를 원하지만, 2026년 중반인 지금까지도 이것이 일관되게 제공되지는 않고 있습니다. Anthropic이 Memory 도구와 실제로 직접 호스팅해 주는 베타 버전의 Managed Agents Memory Store를 통해 가장 근접한 기능을 선보였습니다. OpenAI의 Responses API는 previous_response_id를 통해 30일간의 보관 기간을 가지며 턴 (turn)을 체이닝 (chaining) 해줍니다. 하지만 그것은 대화 기록 (conversation history)일 뿐, 사용자가 소유할 수 있는 휴대 가능한 메모리 (portable memory)는 아니며, Gemini의 API는 그런 의미에서 상태를 유지하지 않는 스테이트리스 (stateless) 상태를 유지합니다. 진정한 장기 메모리 (long-term memory)를 위해서는 여전히 직접 벡터 스토어 (vector store)를 구축하거나 제3자 레이어 (third-party layer)를 덧붙여야 합니다.

그래서 저는 이를 흉내 냅니다. 제 에이전트 (agent) 전체는 파일 위에서 작동합니다. 각 세션은 중요한 내용을 디스크에 기록하고, 다음 세션은 부팅 시 마지막 청크 (chunk)를 다시 읽습니다. 작동은 하지만, 제가 직접 관리해야 하며 다른 제공업체로 옮겨갈 수도 없습니다. "세션 전반에 걸쳐 이 사용자를 기억하라"는 기능은 어떤 API에서든 하나의 플래그 (flag)로 존재해야 합니다. 하지만 아직은 그렇지 않습니다. 여러분은 현재 장기 메모리를 어떻게 처리하고 계신가요?

여전히 기다리고 있는 것 #2: 진정한 결정론 (real determinism)

저는 동일한 입력이 신뢰할 수 있는 동일한 출력을 생성하기를 원하지만, 어떤 제공업체도 이를 보장하지 않습니다. OpenAI와 Gemini는 seed 파라미터를 노출하지만, 둘 다 최선(best-effort)을 다할 뿐이라고 문서화되어 있습니다. Anthropic은 시드 (seed)를 전혀 노출하지 않습니다.

resp = client.chat.completions.create(
    model="gpt-5.5",
    seed=42,          # 최선을 다할 뿐, 약속이 아님
...

그 이유는 API 레이어에서 해결할 수 없는 실제적인 문제입니다. 부동 소수점 연산 (floating-point math)은 서로 다른 GPU 배치 (batch)와 하드웨어 간에 결합 법칙 (associative)이 성립하지 않기 때문에, temperature=0 설정조차 결과를 고정하지 못합니다. 저는 화요일에는 통과했던 테스트가 동일한 입력값임에도 금요일에는 실패하는 것을 목격한 적이 있는데, 이는 디버깅하기에 매우 고통스러운 일입니다. 재현 가능한 파이프라인 (pipelines)과 평가 (evals)를 위해, 제가 가장 닫히기를 원하는 간극이 바로 이것입니다. 여러분은 모델 출력을 어떻게 고정하고 계신가요? 진심으로 여쭤봅니다.

요점 (The takeaway)

만약 여러분이 2024년에 이러한 API들을 배웠다면, 세 가지 오래된 습관이 이제는 여러분의 비용과 신뢰성을 갉아먹고 있습니다. 캐싱(Caching)되지 않은 동일한 접두사(Prefix)를 반복해서 다시 보내고, JSON을 수동으로 파싱하며, 모든 도구마다 커스텀 통합(Custom integration)을 구축하고 있습니다. 이제는 접두사를 캐싱하고, 엄격한 스키마(Strict schema)를 요청하며, MCP(Model Context Protocol)를 사용하십시오. 그리고 작업에 실제로 필요할 때만 큰 컨텍스트 윈도우(Context window)와 노력 조절(Effort dial)을 활용하십시오.

이동 가능한 메모리(Portable memory)와 결정론(Determinism)이라는 두 가지 간극은 주목할 가치가 있습니다. 이 기능들을 세 곳의 제공업체 모두에서 깔끔하게 출시하는 곳이 나온다면, 우리 나머지 사람들이 앱을 구축하는 방식을 다시 한번 변화시킬 것입니다.

이 글은 제가 앱과 도구를 구축하는 astraedus.dev에서의 실제 업무를 바탕으로 작성되었습니다. 무언가를 구축하고 계시거나, 이와 같은 문제로 막혀 계신가요? astraedus.dev 또는 theagentthatcould@gmail.com으로 연락해 주세요.