> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apiyi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# API에 ChatGPT 같은 메모리가 있나요?

> API 자체에는 메모리가 없습니다. 에이전트 도구에서 메모리라고 부르는 것은 실제로 사용자의 컴퓨터에 저장된 파일이며, 새 대화를 시작할 때마다 다시 읽혀 입력으로 과금됩니다. 이 페이지에서는 작동 방식, 다른 컴퓨터로 옮기는 방법, 비용을 낮추는 방법을 설명합니다.

## 짧은 답변

<Info>
  **아니요. API는 상태 비저장이며 이전 요청의 어떤 내용도 기억하지 않습니다.**

  ChatGPT 웹 앱, Claude Code 또는 Codex에서 경험하는 메모리는 해당 제품이 API 위에 구축한 기능입니다. 이들은 메모리를 파일에 기록하고 이후 대화에서 그 파일을 모델에 다시 제공합니다. 파일은 사용자에게 유지되며, APIYI는 대화 내용을 저장하지 않습니다.
</Info>

## 웹 앱의 메모리란 무엇인가

ChatGPT 웹 앱에는 두 가지 종류의 메모리가 있습니다:

* **저장된 메모리**: 직업이나 글쓰기 스타일처럼 기억해 달라고 요청한 사실과 선호 사항
* **채팅 기록 참조**: 과거 대화에서 파악한 정보

둘 다 OpenAI 계정에 저장되며 웹 제품에 속합니다. **이 정보는 API를 통해 노출되지 않습니다.** API를 통해 동일한 모델을 호출하면 웹 앱 대화에 대해서는 아무것도 알지 못합니다.

웹 앱과 API의 차이점에 대한 자세한 내용은 [공식 웹 앱과 API가 서로 다른 결과를 제공하는 이유는 무엇인가요?](/ko/faq/webapp-vs-api-difference)를 참조하십시오.

## 에이전트 도구의 메모리는 단지 파일입니다

코딩 에이전트 도구에서 메모리는 항상 **클라이언트가 로컬 파일을 읽고 쓰는 것**을 의미합니다:

<CardGroup cols={3}>
  <Card title="Claude Code" icon="terminal">
    프로젝트 규칙은 `CLAUDE.md`에 저장하고, 개인 설정과 학습한 내용은 로컬 메모리 디렉터리에 저장합니다. 세션이 시작되면 둘 다 읽습니다.
  </Card>

  <Card title="Codex" icon="code">
    프로젝트 규칙은 `AGENTS.md`에 저장합니다. 2026년 4월부터 Codex에는 과거 세션에서 내용을 추출하여 `~/.codex/memories/`에 로컬로 저장하는 내장 메모리도 있습니다.
  </Card>

  <Card title="Claude API 메모리 도구" icon="folder-open">
    모델이 메모리 파일에 대한 읽기 및 쓰기 요청을 발행하고, 애플리케이션이 이를 실행합니다. 파일을 저장할 위치는 직접 결정합니다: 로컬 디스크, 데이터베이스 또는 클라우드 스토리지입니다.
  </Card>
</CardGroup>

이 도구들의 공통점은 다음과 같습니다:

1. **메모리는 파일**이며, 일반적으로 직접 열고 편집할 수 있는 Markdown입니다.
2. **모델은 모든 파일을 한 번에 읽지 않습니다.** 클라이언트는 현재 작업과 관련된 내용만 가져옵니다.
3. **새 대화마다 다시 읽습니다.** 모델 자체는 아무것도 기억하지 않으며, 클라이언트가 읽은 내용은 질문과 함께 API로 전송됩니다.

## 다른 컴퓨터로 메모리 옮기기

<Steps>
  <Step title="프로젝트 수준 메모리는 리포지터리와 함께 이동합니다">
    `CLAUDE.md` 및 `AGENTS.md` 같은 파일은 프로젝트 디렉터리에 있습니다. 이를 git에 커밋하면 다른 컴퓨터에서 코드를 pull하는 즉시 사용할 수 있습니다. 이 방식으로 팀이 동일한 프로젝트 규칙을 공유할 수 있습니다.
  </Step>

  <Step title="사용자 수준 메모리는 복사하거나 동기화해야 합니다">
    사용자 디렉터리에 저장된 메모리(예: Codex의 `~/.codex/memories/` 또는 Claude Code의 로컬 메모리 디렉터리)는 리포지터리에 포함되지 않습니다. 새 컴퓨터의 동일한 위치에 복사하거나 클라우드 스토리지 또는 동기화 도구를 통해 동기화 상태로 유지하십시오.
  </Step>

  <Step title="새 컴퓨터에서 작동 여부를 확인합니다">
    동일한 프로젝트를 열고 프로젝트의 테스트 명령처럼 메모리만 답할 수 있는 내용을 질문하십시오. 올바른 답변이 나오면 메모리가 함께 옮겨진 것입니다.
  </Step>
</Steps>

<Tip>
  API 키, 비밀번호 또는 기타 비밀 정보를 메모리 파일에 넣지 마십시오. 해당 내용은 모델로 전송되며, 클라우드 스토리지에 동기화하거나 리포지터리에 커밋할 때 유출될 수 있습니다.
</Tip>

## 메모리와 비용

메모리는 무료가 아닙니다.

* **읽히는 메모리는 입력 tokens로 과금됩니다.** 클라이언트가 새 대화에서 읽는 모든 메모리 파일은 해당 요청의 입력에 포함됩니다.
* **대화는 길어질수록 비용이 증가합니다.** API는 상태 비저장이므로 각 턴마다 지금까지의 전체 대화를 다시 전송하며, 입력 tokens가 계속 누적됩니다.
* **캐시 과금은 반복되는 부분의 비용을 줄입니다.** 각 요청의 시작 부분(시스템 prompt, 메모리 파일, 이전 턴)이 동일하게 유지되면 캐시에 적중할 수 있으며, 일반 입력 가격보다 훨씬 낮게 과금됩니다.

APIYI에서 Claude, OpenAI, DeepSeek, Qwen, Grok 등 주요 채널의 캐시 적중은 안정적입니다. **Gemini의 암시적 캐시는 적중률이 보통 수준이므로**, Gemini 비용은 캐시 미적용 가격을 기준으로 예산을 산정하십시오. 각 채널의 규칙은 [APIYI는 캐시 과금을 지원하나요?](/ko/faq/cache-billing)를 참조하십시오.

<Tip>
  캐시 적중을 늘리려면 변경되지 않는 콘텐츠(시스템 prompt, 메모리 파일)를 요청의 시작 부분에 배치하고, 변경되는 콘텐츠는 그 뒤에 배치하십시오. 타임스탬프처럼 매번 변경되는 값은 시작 부분에 넣지 마십시오.
</Tip>

## 서버 측 대화 상태는 메모리가 아닙니다

<Info>
  일부 제공업체 API는 OpenAI Responses API의 `previous_response_id`처럼 서버 측 대화 상태를 제공합니다. 제공업체가 대화를 저장하며(기본값은 30일), 다음 턴에서는 이전 응답 ID만 필요합니다.

  이는 다음 두 가지 측면에서 메모리와 다릅니다:

  * **하나의 대화 체인만 이어집니다.** 세션 간에 사용자의 선호도를 기억하지 않습니다.
  * **비용을 절감하지 않습니다.** 체인의 모든 이전 콘텐츠는 매 턴마다 여전히 입력 tokens으로 과금됩니다.

  APIYI에서는 클라이언트 측에서 대화 기록을 유지하는 방식을 권장합니다. 이는 가장 신뢰할 수 있는 접근 방식이며 모델 전반에서 동일하게 작동합니다. 자세한 내용은 [멀티턴 대화 가이드](/ko/api-capabilities/multi-turn-conversation)를 참조하십시오.
</Info>

## 자주 묻는 질문

<AccordionGroup>
  <Accordion title="APIYI는 내 대화를 저장합니까?">
    아니요. 릴레이 플랫폼인 APIYI는 요청만 전달하며 요청 또는 응답 내용을 저장하지 않습니다. [APIYI는 데이터 보안을 어떻게 보장합니까?](/ko/faq/data-security)를 참조하십시오.

    위의 `previous_response_id`와 같은 제공업체의 서버 측 대화 기능을 사용하면, 제공업체가 자체 규정에 따라 해당 대화를 저장합니다.
  </Accordion>

  <Accordion title="API가 내 선호도를 기억하도록 할 수 있습니까?">
    예, 하지만 직접 구축해야 합니다. 가장 간단한 방법은 선호도를 시스템 prompt에 넣고 모든 요청과 함께 전송하는 것입니다. 선호도가 많다면 파일이나 데이터베이스에 저장하고, 관련 내용을 검색하여 요청에 추가하십시오. Claude API 메모리 도구는 이 접근 방식을 공식적으로 패키징한 것입니다.
  </Accordion>

  <Accordion title="메모리가 많을수록 항상 더 좋습니까?">
    아니요. 메모리가 많을수록 모든 요청의 입력이 길어지고 비용이 증가하며, 모델을 방해할 수 있는 관련 없는 콘텐츠도 많아집니다. 메모리 파일을 정기적으로 검토하고 오래된 항목을 제거하며, 실제로 사용하는 규칙과 사실만 유지하십시오.
  </Accordion>

  <Accordion title="폴더를 복사하는 것 외에 메모리를 동기화할 다른 방법은 무엇입니까?">
    몇 가지 옵션이 있습니다:

    * 프로젝트 수준 메모리를 git에 커밋하여 코드와 함께 이동하도록 합니다.
    * 사용자 수준 메모리는 클라우드 스토리지 또는 동기화 도구로 동기화 상태를 유지합니다.
    * 자체 메모리 서비스를 실행합니다. 일부 에이전트 도구는 MCP를 통해 외부 메모리 서비스에 연결할 수 있으며, 여러 컴퓨터가 동일한 서비스를 공유할 수 있습니다.

    어느 방식을 사용하든 메모리는 API 측이 아니라 사용자가 제어하는 위치에 남아 있습니다.
  </Accordion>
</AccordionGroup>

## 관련 문서

<CardGroup cols={2}>
  <Card title="공식 웹 앱과 API의 결과가 서로 다른 이유는 무엇인가요?" icon="layers" href="/ko/faq/webapp-vs-api-difference">
    웹 앱이 API에 추가하는 기능
  </Card>

  <Card title="여러 차례 대화 가이드" icon="messages-square" href="/ko/api-capabilities/multi-turn-conversation">
    각 API 형식에서 대화 기록을 유지하는 방법
  </Card>

  <Card title="APIYI는 캐시 과금을 지원하나요?" icon="database" href="/ko/faq/cache-billing">
    채널별 캐시 과금 규칙 및 적중 팁
  </Card>

  <Card title="APIYI는 데이터 보안을 어떻게 보장하나요?" icon="shield" href="/ko/faq/data-security">
    암호화된 전송 및 요청 콘텐츠 미저장
  </Card>
</CardGroup>