추론(inference) API의 원래 약속은 단순했다. 입력을 보내면 출력이 돌아오고, 그 둘을 모아두면 대화 전체를 손에 쥘 수 있었다. 트랜스크립트에는 지시문, 메시지, 도구 호출, 도구 결과가 담기고, 사용자는 그것을 열어보거나 보관하거나 다시 재생할 수 있었다. 다른 모델이 똑같은 다음 토큰을 내놓지는 않더라도, 무슨 일이 있었는지 이해하고 작업을 이어받을 수는 있었다. Earendil Engineering은 이 성질, 즉 '세션 이식성(session portability)'이 최근 주요 API들에서 조용히 사라지고 있다고 지적한다.
여기서 말하는 이식성은 모델을 바꿔도 결과가 동일해야 한다는 뜻이 아니다. 모델마다 능력, 성격, 컨텍스트 크기, 도구 사용 방식이 다르고 샘플링 자체가 비결정적이기 때문에 그건 애초에 불가능하다. 이식성은 훨씬 소박한 요구다. 보관된 기록만으로 다른 모델이 작업을 이어갈 수 있을 만큼 내용이 해석 가능해야 하며, 옛 공급자가 ID를 조회하거나 암호문을 복호화하거나 검색 결과를 기억해 줘야만 재구성되는 상태여서는 안 된다는 것이다. 응답 ID는 트랜스크립트가 아니고, 사용자가 열 수 없는 암호문은 사용자가 통제하는 상태가 아니며, 인용 목록은 모델이 실제로 본 근거가 아니다.
암호화된 추론과 서버 저장이라는 미끼
문제의 핵심은 마케팅 용어의 오해다. 'encrypted_content'는 사용자를 위한 프라이버시 기능처럼 들리지만, 실제로는 클라이언트가 읽을 수 없고 공급자만 열 수 있는 캡슐인 경우가 대부분이다. 키를 정하고, 자사 모델을 위해 복호화하고, 어디서 재생 가능한지 정하는 주체가 모두 공급자다. 이 암호화는 데이터를 추론 공급자로부터 감추는 것이 아니라 사용자로부터 감춘다. OpenAI가 store: false와 함께 암호화된 추론을 돌려주고 다음 요청 때 메모리에서 복호화하는 방식은 Zero Data Retention 고객에게는 실제 이점이 있지만, 애초에 암호화가 필요할 이유 자체가 없는 데이터라는 점은 여전히 남는다.
서버 저장은 공급자에게 매력적이다. 애플리케이션이 보내는 데이터가 줄고, 숨겨진 추론과 도구 상태를 보존할 수 있으며, 캐시 라우팅도 쉬워진다. OpenAI의 Responses API는 기본적으로 응답을 저장하고 최소 30일 보관하며, 새로 나온 Gemini Interactions API도 store: true가 기본값으로 유료 티어 55일, 무료 티어 1일을 보관한다. 문제는 로컬 애플리케이션이 사용자 메시지와 최종 텍스트만 기록해두면, 그 응답 ID가 사용자가 통제하지 못하는 데이터베이스를 가리키는 외래 키가 된다는 점이다. 원문은 폐쇄형 가중치 모델 전반에서 raw 사고 과정이 노출되지 않으며, Anthropic이 signature 필드에 암호화된 사고를 담고 읽을 수 있는 부분은 다른 모델이 만든 요약이라는 점도 짚는다. Anthropic 문서 스스로 사고 블록은 이를 생성한 모델에 묶여 있어 모델을 바꿀 때는 제거해야 한다고 명시한다.
호스팅 검색과 서버 압축의 구멍
서버 측 웹 검색은 트랜스크립트에 뚫린 구멍을 가장 선명하게 보여준다. 클라이언트 측 검색 도구라면 사용자가 순위와 문단을 살펴보고, 페이지를 다시 가져오고, 같은 근거를 다른 모델에 넘길 수 있다. 하지만 호스팅 검색에서는 공급자가 비공개 도구 루프를 돌린다. OpenAI, 구글, Anthropic은 검색 동작과 인용, 때로는 출처 URL을 노출하지만 답을 만드는 데 쓰인 전체 텍스트 맥락은 주지 않는다. URL은 안정적인 재생이 아니다. 그 내용은 바뀔 수 있고, 모델이 보기 전에 짧은 스니펫으로 축약됐을 수도 있다. 다음 턴에서 '세 번째 출처와 첫 번째를 비교하고 논란이 된 수치를 다시 확인하라'고 다른 모델에 시키면, 그 모델은 결과 순위도, 추출된 문단도, 걸러진 자료도 받지 못한다. 원문은 호스팅 검색이 질의, 결과 메타데이터, 검색된 문단, 타임스탬프, 보존된 내용을 담는 완전 충실도(full-fidelity) 내보내기 모드를 제공해야 한다고 주장한다.
긴 에이전트 세션은 결국 압축(compaction)이 필요하다. 클라이언트가 통제하는 요약은 손실이 있어도 검사하고 편집하고 다른 모델에 넘길 수 있다. 반면 OpenAI의 서버 측 압축은 문서상 '불투명하며 사람이 해석하도록 의도되지 않은' 암호화 항목을 내놓고, 별도의 /responses/compact 엔드포인트는 클라이언트가 그대로 전달하라고 지시받는 '정규 다음 컨텍스트 윈도우'를 반환한다. 이것은 기술적 필연이 아니다. Anthropic의 서버 측 압축은 읽을 수 있는 content 필드를 담은 압축 블록을 돌려주고 커스텀 요약 지시도 허용한다. 봉인된 산출물이 원래 모델에서 더 나은 성능을 낼 수는 있으나, 그것이 읽을 수 있는 인수인계 요약을 대체하는 것이 아니라 함께 제공되는 선택적 최적화여야 한다는 것이다.
멀티에이전트가 상황을 악화시킨다
멀티에이전트 시스템은 트랜스크립트가 하나가 아니라 세션의 트리와 그 사이를 오가는 메시지 스트림이 되기 때문에 문제를 증폭시킨다. OpenAI의 호스팅 Responses 멀티에이전트 베타는 multi_agent_call, multi_agent_call_output, agent_message라는 새 항목 유형을 도입했는데, 에이전트 생성 예시의 메시지 인자와 에이전트 간 메시지는 encrypted_content만 담는다. 멀티에이전트를 켜면 클라이언트가 요청하지 않아도 모든 에이전트에 서버 측 자동 압축이 암묵적으로 활성화되고, 개발자가 편집할 수 없는 루트·서브에이전트 지시문이 주입된다. 실제로 2026년 6월 오픈소스 Codex 클라이언트에 'Encrypt multi-agent v2 message payloads'라는 커밋이 들어왔고, 부모가 낸 도구 인자를 Responses API가 암호화해 자식에게 전달하며 Codex 자신의 InterAgentCommunication.content는 비어 있게 됐다. 어떤 에이전트가 무슨 지시를 받았는지를 사용자가 확인할 수 없다는 뜻이다.
한국의 실무자 관점에서 이 흐름의 무게는 분명하다. 대부분은 매주 공급자를 바꾸지 않지만, 모델이 은퇴하거나 서비스가 멈추거나 가격·정책이 바뀌거나 특정 단계를 로컬에서 돌려야 하거나 감사자가 무슨 일이 있었는지 재구성해야 할 때 세션을 옮겨야 할 수 있다. 에이전트가 세션을 며칠, 나아가 몇 년치로 늘리는 지금은 더욱 그렇다. 떠날 수 있는 선택지 자체가 공급자에게 규율을 부여한다는 점도 중요하다. 사용자가 다른 곳에서 이어갈 수 있음을 공급자가 알면 모델 품질과 가격, 신뢰로 경쟁해야 하지만, 축적된 맥락을 한 공급자만 해석할 수 있다면 유인 구조는 어긋난다. Earendil이 요구하는 것은 봉인된 최적화를 금지하라는 것이 아니라, 그 옆에 읽을 수 있는 인수인계 기록과 감사용 사본을 남기라는 최소한의 규칙이다. 시스템을 설계할 때 트랜스크립트를 온전히 자기 손에 두는 클라이언트 측 검색·압축 옵션을 확보해 두는 것은, 종속의 대가를 나중에 치르지 않기 위한 실무적 방어선이다.
"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"
실제 수강생 후기- 비전공자도 6개월이면 첫 수익
- 20년 경력 개발자 직강
- 자동화 프로그램 + 소스코드 제공