--- title: "AI 세션, 이제 진짜 내 데이터가 아닐 수도 있다" published: 2026-07-31T03:47:59.000Z canonical: https://jeff.news/article/5272 --- # AI 세션, 이제 진짜 내 데이터가 아닐 수도 있다 추론 API가 단순한 입력-출력 기록에서 벗어나, 제공자 서버에 묶인 상태값과 암호화된 블롭에 의존하는 방향으로 가고 있다는 비판이다. reasoning token, 호스팅 검색, 서버 측 압축, 멀티 에이전트 메시지, 응답 아이디 같은 기능이 편리함을 주는 대신 세션 이식성과 감사 가능성을 깎아먹는다는 게 핵심이다. 글은 로컬 이벤트 로그를 표준으로 삼고, 검색·압축·에이전트 통신을 사람이 읽고 내보낼 수 있어야 한다고 주장한다. - 원래 추론 API의 약속은 되게 단순했음. 입력을 보내고, 출력을 받고, 그 둘을 저장하면 대화 기록이 내 손에 남는 구조였음 - 프롬프트 캐시가 제공자 GPU에 있고, 모델마다 토크나이저가 다르고, 샘플링이 재현 불가능하다는 한계는 원래 있었음 - 그래도 instructions, messages, tool calls, tool results가 들어간 transcript만 있으면 다른 충분히 똑똑한 모델이 “무슨 일이 있었는지” 이해하고 이어받을 수 있었음 - 그런데 최근 추론 API는 점점 “텍스트 기록”이 아니라 “제공자 서버에 묶인 상태값”을 섞어 반환하는 쪽으로 가고 있다는 게 글의 문제의식임 - 사용자가 돈을 내고 생성한 reasoning token이 암호화된 블롭으로만 돌아오거나, 검색 결과의 실제 본문은 모델만 보고 사용자는 못 보는 식임 - 서버 측 compaction 결과, 하위 에이전트 메시지, 파일·벡터스토어·컨테이너·캐시 참조, response id 같은 것들도 다른 제공자에서는 해석할 수 없는 상태가 되기 쉬움 - 결과적으로 내 컴퓨터에 있는 transcript는 “세션 전체”가 아니라, 제공자 서버에 있는 진짜 세션을 일부만 비춘 그림자에 가까워짐 > [!IMPORTANT] > 글에서 제안하는 세션 소유권 테스트는 간단함. 기존 제공자의 자격 증명을 폐기한 뒤에도 export한 transcript만으로 새 제공자 모델이 의미 있게 이어받을 수 있어야 한다는 것임. - 저자가 말하는 portable session은 “다른 모델이 같은 다음 토큰을 내야 한다”는 뜻이 아님 - 모델마다 성격, 능력, 컨텍스트 창, 도구 사용 방식이 다르니 완전한 재현은 애초에 불가능함 - 대신 다른 구현체가 세션의 의미론적 맥락을 재구성할 수 있어야 함 - 이를 위해 inspection, export, replay, audit, deletion이라는 5가지 테스트를 제시함 - 특히 “암호화”라는 말이 꽤 교묘하다고 지적함 - encrypted_content라는 이름은 사용자 프라이버시 기능처럼 들리지만, 실제로는 사용자가 못 읽고 제공자만 열 수 있는 캡슐인 경우가 많음 - OpenAI처럼 store: false 상태에서 암호화된 reasoning을 클라이언트에 돌려주고 다음 요청 때 메모리에서 복호화하는 방식은 서버 저장보다 나은 면이 있음 - 하지만 이 암호화는 제공자로부터 데이터를 숨기는 게 아니라 사용자로부터 숨기는 구조라는 게 핵심 비판임 - 서버에 저장되는 대화는 transcript를 포인터로 바꿔버림 - OpenAI Responses API는 기본적으로 response object를 저장하고, 문서상 기본 보존 기간이 최소 30일이라고 설명함 - Gemini Interactions API도 기본값이 store: true이고, 유료 티어는 55일, 무료 티어는 1일 보존으로 소개됨 - previousResponseId로 이어붙이는 구조는 앱이 보내는 데이터량을 줄이고 캐시 라우팅도 쉬워지지만, 로컬 앱이 저장한 first.id는 결국 남의 데이터베이스 외래키가 됨 - reasoning token은 더 노골적인 잠금 지점임 - 주요 폐쇄형 모델 연구소들은 raw chain of thought를 노출하지 않는 이유가 있다고 주장하고, API에서는 보통 이 토큰을 볼 수 없음 - OpenAI는 저장된 응답에서는 previous_response_id로 이전 reasoning을 다시 활용할 수 있고, store: false에서는 encrypted_content를 보존했다가 되돌려줘야 함 - Anthropic은 전체 thinking을 signature 필드에 암호화해 넣고, 읽을 수 있는 thinking text는 raw chain of thought가 아니라 다른 모델이 만든 요약이라고 설명됨 - 게다가 Anthropic 문서상 thinking block은 만든 모델에 묶여 있고, 모델을 바꿀 때 제거하라고 되어 있어 같은 생태계 안에서도 이식성을 목표로 한 흔적이 약함 - 서버 측 웹 검색은 transcript에 생기는 구멍을 가장 잘 보여주는 사례임 - 클라이언트 측 검색 도구라면 query, 검색 시각, URL, 제목, passage, ranking을 전부 기록할 수 있음 - 반대로 호스팅 검색에서는 OpenAI, Google, Anthropic이 검색 action, citation, URL 목록 정도는 노출해도 모델이 실제로 본 전체 텍스트 맥락은 주지 않는 경우가 많음 - URL은 안정적인 replay가 아님. 페이지 내용이 바뀔 수도 있고, 모델이 본 것은 이미 짧게 잘린 snippet일 수도 있음 ```mermaid sequenceDiagram participant 사용자앱 as 사용자 앱 participant 제공자검색 as 제공자 검색 participant 모델 as 모델 participant 새모델 as 새 모델 사용자앱->>제공자검색: 검색 요청 위임 제공자검색->>모델: 선별된 본문과 passage 전달 모델->>사용자앱: 답변과 일부 출처 URL 반환 사용자앱->>새모델: 답변과 URL만 전달 새모델->>사용자앱: 원래 근거를 재현할 수 없음 ``` - compaction도 마찬가지로, 성능 최적화가 이식성을 잡아먹을 수 있음 - 긴 에이전트 세션에서는 20만 토큰짜리 히스토리를 계속 들고 갈 수 없으니 압축이 필요함 - 사람이 읽을 수 있는 요약은 손실이 있어도 검토·수정·이전이 가능함 - 그런데 OpenAI의 서버 측 compaction은 “사람이 해석하려는 용도가 아닌” 암호화된 compaction item을 만들고, 클라이언트는 canonical next context window를 그대로 넘기도록 안내받음 - 저자는 이런 제공자 전용 압축이 선택적 최적화일 수는 있지만, 읽을 수 있는 handoff summary를 대체하면 안 된다고 봄 - 멀티 에이전트로 가면 문제는 더 커짐. 이제 transcript가 하나가 아니라 세션 트리와 에이전트 간 메시지 흐름이 되기 때문임 - OpenAI Responses Multi-agent beta에는 multi_agent_call, multi_agent_call_output, agent_message 같은 항목이 있고, 예시에서 spawn_agent의 message argument가 암호화되어 있음 - 에이전트 간 메시지는 encrypted_content만 담고, 멀티 에이전트가 켜지면 각 에이전트에 자동 서버 측 compaction도 암묵적으로 활성화된다고 설명됨 - reasoning summary도 지원하지 않고, root 및 subagent instruction이 API에서 주입되며 개발자가 수정하거나 제거할 수 없다는 지점도 비판함 > [!WARNING] > 하위 에이전트가 잘못된 파일을 수정하거나 잘못된 가정을 따라갔을 때, “그 에이전트가 정확히 뭘 지시받았나?”를 사용자가 답할 수 없다면 감사 가능한 에이전트 시스템이라고 보기 어렵다는 지적임. - 저자는 “사람들이 세션 중간에 모델을 잘 안 바꾸잖아”라는 반론도 별로 중요하지 않다고 봄 - 운영체제나 통신사를 매주 바꾸지 않아도 바꿀 자유가 중요한 것과 같은 논리임 - 모델 폐기, 서비스 장애, 가격 변경, 정책 차단, 기밀 작업의 로컬 실행, 감사 요구 같은 이유로 세션 이동이 필요할 수 있음 - 특히 에이전트 작업은 며칠치 결정과 근거를 쌓을 수 있고, 개인 비서는 몇 년치 transcript를 축적할 수도 있음 - 글이 요구하는 portable inference API의 원칙은 꽤 구체적임 - 로컬 이벤트 로그가 canonical이어야 하고, 서버 저장은 미러나 가속용이어야 함 - store: false는 쉽고 문서화되어야 하며, 가능하면 기본값이어야 함 - 암호화된 reasoning, compaction, tool signature가 같은 제공자 품질 개선용으로 들어갈 수는 있어도, 의미의 유일한 carrier가 되면 안 됨 - 호스팅 도구는 입력, 출력, 근거, 필터링, provenance, timestamp, content hash까지 남기는 full-fidelity log를 제공해야 함 - 하위 에이전트의 task, message, result, lineage, model, tool permission도 읽을 수 있게 보존돼야 함 - 마지막에는 distillation까지 얘기가 이어짐. 폐쇄형 연구소들이 바깥쪽 distillation에는 적대적이면서 자기들 내부 distillation은 합법적이고 유용한 방법이라고 말하는 비대칭을 꼬집음 - Anthropic은 2026년 2월 DeepSeek, Moonshot, MiniMax 관련 의혹을 “distillation attack”이라고 불렀고, 상업 약관에서 경쟁 모델 학습에 출력을 쓰는 걸 금지함 - 동시에 frontier lab 내부에서는 distillation이 널리 쓰이는 정당한 학습 방법이라고 인정함 - OpenAI도 더 강한 OpenAI 모델 출력을 써서 작은 OpenAI 모델을 fine-tune하는 1st-party distillation workflow를 제공한 적이 있음 - 저자는 distillation이 비싼 frontier capability를 더 작고 싸고 빠른 로컬 모델로 옮겨 경쟁과 사용자 통제권을 늘릴 수 있다고 봄 - 결론은 단순함. 사용자는 계정을 닫아도 세션을 가져갈 수 있어야 함 - 새 모델이 더 못하거나, 질문을 다시 하거나, 다른 판단을 내리는 건 괜찮음 - 하지만 예전 모델이 사용자의 히스토리, 근거, 계획, 위임 작업을 봤던 자리에 새 모델이 암호문만 보고 멍하니 있어야 한다면 그건 자유가 아님 - 저자는 상태 저장 API 자체에 반대하는 게 아니라, 더 좋은 성능이 더 적은 사용자 통제와 묶이는 설계에 반대하는 것임 --- ## 기술 맥락 - 여기서 핵심 선택은 “세션의 원본을 로컬 transcript로 둘 것인가, 제공자 서버의 상태값으로 둘 것인가”예요. 로컬 transcript가 원본이면 느리고 비싸질 수 있지만, 디버깅과 감사와 이전이 가능해져요. - 제공자 입장에서는 server-side compaction, previousResponseId, hosted search가 꽤 매력적이에요. 매번 긴 컨텍스트를 다시 보내지 않아도 되고, 모델별 reasoning이나 캐시 상태를 보존할 수 있어서 품질과 비용을 동시에 잡기 좋거든요. - 문제는 이 최적화가 유일한 의미 저장소가 될 때 생겨요. 사용자가 읽을 수 없는 encrypted_content만 남으면, 다른 모델은 그동안 어떤 검색 결과를 봤는지, 어떤 reasoning을 이어받아야 하는지, 하위 에이전트가 무슨 지시를 받았는지 알 방법이 없어요. - 실무에서는 그래서 이벤트 로그 설계가 중요해요. tool call의 입력과 출력, 검색 passage, 파일 산출물, 에이전트 lineage, compaction에 쓰인 요약 지시까지 남겨야 나중에 장애 분석이나 보안 감사가 가능해져요. - 제공자 전용 상태를 완전히 쓰지 말자는 얘기는 아니에요. 같은 모델에서 품질을 높이는 캐시나 암호화 블록은 쓸 수 있지만, 사람이 읽을 수 있는 handoff representation이 같이 있어야 팀이 특정 API에 갇히지 않아요. ## 핵심 포인트 - 추론 API의 세션 기록이 점점 제공자 전용 상태값에 의존하고 있다 - 암호화된 추론, 서버 측 압축, 호스팅 검색은 사용자에게 편하지만 이식성과 감사 가능성을 떨어뜨린다 - 응답 아이디나 암호문은 다른 모델이 이어받을 수 있는 완전한 transcript가 아니다 - 멀티 에이전트 시스템에서는 하위 에이전트에게 전달된 실제 지시까지 숨겨질 수 있다 - 저자는 상태 저장 API 자체가 아니라 사용자 통제권을 잃는 설계를 문제 삼는다 ## 인사이트 AI 앱을 만드는 팀이면 이 글은 꽤 불편하게 읽힐 만하다. 기능을 빨리 붙이다 보면 서버 측 상태 저장과 제공자 전용 최적화가 당장은 편한데, 나중에는 디버깅·감사·마이그레이션을 죄다 막는 잠금장치가 될 수 있다는 얘기라서다.