Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며

2026년 상반기 AI 엔지니어링 커뮤니티에서 가장 자주 등장하는 단어를 하나 꼽으라면 단연 "컨텍스트 엔지니어링(context engineering)"입니다. 최근 GeekNews에서는 LLM 메모리 레이어 오픈소스인 Supermemory가 화제에 올랐고, Hacker News에서도 에이전트 메모리 설계에 관한 글이 연일 프런트페이지에 오르내리고 있습니다. Claude Code나 Codex 같은 코딩 에이전트가 수 시간 단위의 자율 작업을 수행하는 시대가 되면서, "모델에게 무엇을 어떻게 보여줄 것인가"라는 문제가 프롬프트 문구를 다듬는 일보다 훨씬 중요해졌기 때문입니다.

프롬프트 엔지니어링이 "한 번의 요청을 잘 쓰는 기술"이었다면, 컨텍스트 엔지니어링은 "모델이 매 순간 보는 정보의 전체 구성을 설계하는 기술"입니다. 그리고 그 중심에는 메모리, 즉 에이전트에게 기억을 설계해주는 문제가 있습니다. 이 글에서는 패러다임 전환의 배경부터 메모리 계층 설계, 사실 추출 파이프라인, compaction 전략, 평가 방법, 그리고 메모리 오염 같은 함정까지 차례로 살펴보겠습니다.

프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로

무엇이 달라졌나

2023년의 LLM 활용은 대체로 단발성이었습니다. 사용자가 질문을 입력하고, 모델이 답을 내고, 대화가 끝나면 모든 것이 사라졌습니다. 이 시절의 최적화 대상은 "프롬프트 한 장"이었고, few-shot 예제를 넣을지, 역할극을 시킬지, chain-of-thought를 유도할지가 주된 관심사였습니다.

2026년의 에이전트는 다릅니다. 도구를 호출하고, 파일을 읽고, 수십 턴에 걸쳐 작업을 이어가며, 어제의 세션에서 결정한 내용을 오늘의 세션에서 참조해야 합니다. 이때 모델에게 전달되는 입력은 더 이상 "프롬프트 한 장"이 아니라 다음 요소들의 합성물입니다.

- 시스템 프롬프트와 도구 정의

- 과거 대화 이력 또는 그 요약본

- 검색으로 가져온 문서 조각

- 장기 메모리에서 불러온 사용자 프로필과 사실

- 현재 작업의 중간 산출물(파일 내용, 명령 실행 결과)

이 합성물의 품질이 곧 에이전트의 품질입니다. Anthropic의 엔지니어링 블로그가 정리했듯, 컨텍스트 엔지니어링은 "제한된 컨텍스트 윈도우라는 예산 안에서, 매 추론 시점에 가장 유효한 최소한의 토큰 집합을 골라 배치하는 일"로 정의할 수 있습니다.

두 패러다임 비교

| 구분 | 프롬프트 엔지니어링 | 컨텍스트 엔지니어링 |

| --- | --- | --- |

| 최적화 대상 | 단일 요청의 문구 | 입력 전체의 구성과 흐름 |

| 시간 범위 | 1턴 | 멀티턴, 멀티세션 |

| 핵심 기술 | few-shot, 역할 지정, CoT 유도 | 메모리 계층, 검색, 압축, 격리 |

| 실패 양상 | 어색한 답변 | 맥락 망각, 일관성 붕괴, 비용 폭증 |

| 담당 산출물 | 프롬프트 템플릿 | 메모리 스키마, 파이프라인, 평가셋 |

프롬프트 엔지니어링이 사라진 것은 아닙니다. 시스템 프롬프트의 문구는 여전히 중요합니다. 다만 그것은 이제 전체 설계의 한 구성 요소일 뿐이고, 병목은 "무엇을 기억하고 무엇을 잊게 할 것인가"로 이동했습니다.

컨텍스트 윈도우의 경제학

토큰은 공짜가 아니다

frontier 모델의 컨텍스트 윈도우는 20만에서 100만 토큰까지 커졌지만, "넣을 수 있다"와 "넣어야 한다"는 전혀 다른 문제입니다. 비용 측면부터 보겠습니다. 입력 토큰 단가를 100만 토큰당 3달러로 가정하면, 매 턴 15만 토큰짜리 컨텍스트를 끌고 다니는 에이전트는 턴당 약 0.45달러를 입력 비용으로만 소모합니다. 50턴짜리 세션이면 22달러가 넘고, 하루 1천 세션을 처리하는 서비스라면 입력 비용만으로 월 수십만 달러 규모가 됩니다. prompt caching으로 절감할 수 있지만, 캐시 미스가 발생하는 구조라면 효과가 제한적입니다.

성능도 공짜가 아니다 — lost in the middle

비용보다 더 심각한 것은 성능 저하입니다. Liu 등의 "Lost in the Middle" 연구(2023)는 긴 컨텍스트의 중간에 위치한 정보의 활용률이 앞과 뒤에 비해 현저히 떨어진다는 사실을 보여주었고, 이 경향은 2026년의 최신 모델에서도 정도만 줄었을 뿐 여전히 관찰됩니다. 흔히 "context rot"라고 부르는 현상도 있습니다. 관련성 낮은 정보가 누적될수록 모델이 지시를 놓치고, 오래된 정보와 새 정보를 혼동하며, 환각률이 올라갑니다.

검색 정확도 (개념적 곡선)

100% |■■■

|■■■■■

80% |■■■■■■■ ■■■■

|■■■■■■■■ ■■■■■■

60% |■■■■■■■■■ ■■■■■■■■

|■■■■■■■■■■■■■■■■■■■■■■

+--------------------------

문서 위치: 앞 중간 뒤

핵심 정보가 컨텍스트 "중간"에 있을 때

회수율이 가장 낮다 (lost in the middle)

결론: 컨텍스트는 희소 자원이다

정리하면 컨텍스트 윈도우는 세 가지 의미에서 희소 자원입니다.

1. 금전 비용 — 토큰 단가와 캐시 효율

2. 지연 시간 — 입력이 길수록 첫 토큰까지의 시간이 늘어남

3. 주의력 예산 — 토큰이 많을수록 개별 정보에 대한 모델의 주의가 희석됨

컨텍스트 엔지니어링의 출발점은 이 세 가지 제약을 인정하고, "전부 넣기" 대신 "골라 넣기"를 설계하는 것입니다. 그리고 골라 넣으려면, 어딘가에 골라둘 저장소가 필요합니다. 그것이 메모리입니다.

메모리 계층 설계

인지과학의 기억 분류를 차용하면 에이전트 메모리는 세 계층으로 나누는 것이 표준 패턴으로 자리잡았습니다.

+--------------------------------------------------+

| 에이전트 메모리 계층 |

+--------------------------------------------------+

| 작업 메모리 (working memory) |

| - 현재 컨텍스트 윈도우 그 자체 |

| - 수명: 현재 세션, 용량: 토큰 예산 |

+--------------------------------------------------+

| 에피소드 메모리 (episodic memory) |

| - "언제 무슨 일이 있었나" 사건 단위 기록 |

| - 세션 요약, 작업 로그, 결정 이력 |

+--------------------------------------------------+

| 시맨틱 메모리 (semantic memory) |

| - "무엇이 사실인가" 시간 독립적 지식 |

| - 사용자 프로필, 선호, 도메인 사실 |

+--------------------------------------------------+

작업 메모리 — 컨텍스트 윈도우 그 자체

작업 메모리는 별도 저장소가 아니라 지금 모델이 보고 있는 컨텍스트입니다. 설계 포인트는 배치와 우선순위입니다. 시스템 프롬프트와 핵심 지시는 맨 앞에, 최신 대화와 당면 과제는 맨 뒤에 두고, 중간에는 회수율이 낮아도 되는 보조 자료를 둡니다. 도구 실행 결과처럼 부피가 큰 항목은 수명 정책을 정해 일정 턴이 지나면 잘라냅니다.

에피소드 메모리 — 사건의 기록

에피소드 메모리는 "지난 화요일 세션에서 결제 모듈 리팩터링을 했고, 트랜잭션 격리 수준 문제로 두 번 실패했다" 같은 사건 단위 기록입니다. 구현은 보통 세션 종료 시점(또는 compaction 시점)에 LLM으로 요약을 생성해 타임스탬프와 함께 저장하는 방식입니다. 다음 세션이 시작될 때 최근 에피소드 몇 건을 컨텍스트에 주입하면 "어제 하던 일 이어서"가 가능해집니다.

시맨틱 메모리 — 사실의 저장소

시맨틱 메모리는 시간과 무관하게 참인 명제의 모음입니다. "사용자는 TypeScript를 선호한다", "이 프로젝트의 DB는 PostgreSQL 16이다" 같은 것들입니다. 핵심 설계 과제는 추출(대화에서 사실을 어떻게 뽑아낼 것인가), 갱신(모순되는 새 사실이 오면 어떻게 덮어쓸 것인가), 회수(현재 질의에 관련된 사실만 어떻게 골라낼 것인가)의 세 가지입니다.

계층별 특성 비교

| --- | --- | --- | --- | --- |

대화에서 사실 추출하기 — 사용자 프로필 구축 패턴

GeekNews에서 화제가 된 Supermemory를 비롯해 mem0, Letta(구 MemGPT) 같은 메모리 레이어 오픈소스들이 공통적으로 제공하는 핵심 기능이 바로 이 부분입니다. 대화가 흘러가는 동안 백그라운드에서 "기억할 가치가 있는 사실"을 추출하고, 기존 메모리와 대조해 추가/갱신/폐기를 결정하는 파이프라인입니다.

추출 파이프라인의 구조

대화 턴 --> [추출기 LLM] --> 후보 사실 목록

기존 메모리 검색 (유사도 top-k)

[판정기 LLM] --> ADD / UPDATE / DELETE / NOOP

메모리 스토어 반영

구현 예제

다음은 추출과 판정을 분리한 최소 구현입니다. 실제 서비스에서는 추출기를 작은 모델로, 판정기를 중간 모델로 두어 비용을 낮추는 것이 일반적입니다.

from anthropic import Anthropic

client = Anthropic()

EXTRACT_PROMPT = """다음 대화에서 장기적으로 기억할 가치가 있는

사용자에 관한 사실만 추출하라. 일시적 상태(지금 배고프다 등)는 제외.

JSON 배열로만 답하라. 각 원소는 fact, category, confidence 필드를 가진다.

category는 preference, identity, project, constraint 중 하나."""

def extract_facts(conversation_text: str) -> list[dict]:

resp = client.messages.create(

model="claude-haiku-4-5",

max_tokens=1024,

system=EXTRACT_PROMPT,

messages=[{"role": "user", "content": conversation_text}],

)

return json.loads(resp.content[0].text)

RECONCILE_PROMPT = """새 사실과 기존 메모리 목록을 비교해

각 새 사실에 대해 ADD, UPDATE(대상 id 포함), NOOP 중 하나를 판정하라.

모순되는 기존 메모리가 있으면 UPDATE를 선택하라. JSON 배열로만 답하라."""

def reconcile(new_facts: list[dict], existing: list[dict]) -> list[dict]:

payload = json.dumps(

{"new_facts": new_facts, "existing": existing},

ensure_ascii=False,

)

resp = client.messages.create(

model="claude-sonnet-4-5",

max_tokens=2048,

system=RECONCILE_PROMPT,

messages=[{"role": "user", "content": payload}],

)

return json.loads(resp.content[0].text)

추출 시 판단 기준

무엇이든 다 저장하면 메모리가 곧 쓰레기장이 됩니다. 실무에서 검증된 필터 기준은 다음과 같습니다.

- 반복 가능성: 미래 대화에서 다시 쓰일 확률이 있는가

- 안정성: 다음 주에도 참일 가능성이 높은가 (일시적 감정, 오늘의 날씨 제외)

- 출처 명확성: 사용자가 직접 말했는가, 모델이 추측했는가 (추측은 confidence를 낮게)

- 민감도: 건강, 정치 성향 등 민감 정보는 명시적 동의 없이 저장하지 않음

RAG vs 메모리 — 무엇이 다른가

둘 다 "외부 저장소에서 텍스트를 가져와 컨텍스트에 넣는다"는 점에서 기계적으로는 비슷하지만, 설계 목적이 다릅니다. 혼동하면 잘못된 도구를 선택하게 됩니다.

| 구분 | RAG | 메모리 |

| --- | --- | --- |

| 데이터 출처 | 외부 문서 코퍼스 | 에이전트 자신의 상호작용 |

| 데이터 성격 | 정적, 대량, 공유됨 | 동적, 소량, 사용자별 |

| 갱신 주체 | 배치 인덱싱 파이프라인 | 에이전트 런타임 |

| 쓰기 연산 | 거의 없음 (read-heavy) | 빈번함 (read-write) |

| 충돌 처리 | 불필요 | 핵심 과제 (사실 갱신) |

| 대표 질문 | 이 문서에 뭐라고 쓰여 있나 | 이 사용자는 누구인가 |

실전에서는 둘을 조합합니다. 도메인 지식은 RAG로, 사용자와 작업의 이력은 메모리로 가져오되, 컨텍스트에 주입할 때는 출처를 명시한 별도 섹션으로 구분해주는 것이 모델의 혼동을 줄입니다.

Compaction과 Summarization 전략

긴 세션에서 컨텍스트가 한도에 접근하면 무언가를 버려야 합니다. Claude Code의 auto-compact가 대표적인 구현인데, 일반화하면 전략은 세 가지입니다.

전략 1 — 슬라이딩 윈도우 + 요약

오래된 턴을 통째로 버리는 대신 요약으로 치환합니다. 요약 시 반드시 보존해야 할 항목을 명시하는 것이 품질을 좌우합니다.

COMPACT_PROMPT = """다음 대화 이력을 요약하라. 반드시 보존할 것:

1. 사용자의 원래 목표와 제약 조건

2. 내려진 결정과 그 이유

3. 시도했다가 실패한 접근 (재시도 방지용)

4. 현재 진행 중인 작업의 정확한 상태

5. 파일 경로, 함수명, 설정값 등 구체적 식별자

잡담과 중간 추론 과정은 버려도 된다."""

def compact(history: list[dict], keep_recent: int = 10) -> list[dict]:

old, recent = history[:-keep_recent], history[-keep_recent:]

summary = summarize_with_llm(COMPACT_PROMPT, old)

return [{"role": "user", "content": f"[이전 대화 요약]\n{summary}"}] + recent

전략 2 — 구조화 노트 (note-taking)

요약 대신, 에이전트가 작업 중에 스스로 구조화된 노트 파일을 유지하게 하는 방식입니다. 장시간 자율 작업 모델 세대에서 특히 효과적입니다. 컨텍스트가 리셋되어도 노트 파일만 다시 읽으면 상태가 복원됩니다.

전략 3 — 서브에이전트 격리

부피가 큰 탐색 작업(코드베이스 검색, 문서 조사)을 서브에이전트에게 위임하고, 본 에이전트는 압축된 결과만 받는 방식입니다. 컨텍스트 오염을 원천 차단하는 효과가 있습니다.

| 전략 | 장점 | 단점 | 적합한 경우 |

| --- | --- | --- | --- |

메모리 스키마 예제

메모리를 자유 텍스트로 쌓으면 갱신과 충돌 처리가 불가능해집니다. 스키마를 정의해야 합니다. 다음은 실무에서 출발점으로 쓸 만한 JSON 스키마 예제입니다.

{

"memory_id": "mem_01HXYZ",

"subject": "user:fjvbn2003",

"category": "preference",

"fact": "코드 리뷰 코멘트는 한국어로, 코드 주석은 영어로 작성하길 원함",

"confidence": 0.92,

"source": {

"type": "explicit_statement",

"session_id": "sess_20260610_a",

"turn": 14

"created_at": "2026-06-10T09:32:00Z",

"updated_at": "2026-06-10T09:32:00Z",

"expires_at": null,

"supersedes": null,

"embedding_ref": "vec_8f3a",

"access_count": 7,

"last_accessed_at": "2026-06-12T01:10:00Z"

}

설계 포인트를 짚어보면 다음과 같습니다.

- source 필드: 명시 발언인지 추론인지 구분합니다. 메모리 오염 사고 조사 시 필수입니다.

- supersedes 필드: 갱신 시 이전 메모리 id를 가리켜 이력을 보존합니다. 삭제는 soft delete로.

- access_count와 last_accessed_at: 회수 랭킹과 망각(decay) 정책의 입력이 됩니다.

- expires_at: "다음 달 이사 예정" 같은 시한부 사실에 사용합니다.

세션 간 상태 유지 — 구현 패턴

마지막 퍼즐은 이 모든 것을 묶어 세션 경계를 넘는 에이전트를 만드는 것입니다. 핵심은 세션 시작 시 메모리에서 컨텍스트를 조립하고, 세션 종료 시 새 기억을 적재하는 두 개의 훅입니다.

class MemoryAwareAgent:

def __init__(self, store, user_id: str):

self.store = store

self.user_id = user_id

def start_session(self, first_message: str) -> str:

profile = self.store.get_semantic(self.user_id, limit=20)

episodes = self.store.get_recent_episodes(self.user_id, limit=3)

relevant = self.store.search(self.user_id, first_message, k=5)

memory_block = render_memory_block(profile, episodes, relevant)

return (

"다음은 이 사용자에 대해 기억하고 있는 내용이다.\n"

"오래되었거나 현재 대화와 모순되면 대화 내용을 우선하라.\n\n"

+ memory_block

)

def end_session(self, history: list[dict]) -> None:

episode = summarize_episode(history)

self.store.add_episode(self.user_id, episode)

facts = extract_facts(render_history(history))

existing = self.store.get_semantic(self.user_id, limit=100)

for op in reconcile(facts, existing):

self.store.apply(self.user_id, op)

여기서 놓치기 쉬운 디테일 두 가지를 강조하고 싶습니다.

첫째, 메모리 블록 주입 시 "모순되면 현재 대화를 우선하라"는 지시를 함께 넣어야 합니다. 이 한 줄이 없으면 모델이 낡은 메모리를 현재 사용자 발언보다 신뢰하는 사고가 발생합니다.

둘째, end_session 훅은 비동기로 처리해야 합니다. 사실 추출과 판정에 LLM 호출이 두 번 들어가므로, 동기로 처리하면 사용자가 세션 종료 시 수 초를 기다리게 됩니다.

메모리 시스템 평가 방법

"붙여보니 좋아진 것 같다"는 평가가 아닙니다. 메모리 시스템은 다음 네 축으로 측정합니다.

1. 추출 품질

수동 라벨링한 대화 셋에서 추출기의 정밀도와 재현율을 측정합니다. "기억했어야 하는데 놓친 사실"(재현율)과 "기억하지 말았어야 하는데 저장한 잡음"(정밀도)을 모두 봐야 합니다.

2. 회수 품질

질의별로 관련 메모리가 top-k 안에 들어오는지 측정합니다. 일반 검색 평가와 같은 방법론(recall at k, MRR)을 쓰되, 시간 감쇠와 갱신 이력이 반영되는지를 별도 케이스로 검증합니다.

실무에서는 유사도 단독이 아니라 최근성과 사용 빈도를 합산한 점수로 랭킹하는 것이 일반적입니다. 가중치 자체가 평가 대상이 됩니다.

def memory_score(m, query_sim: float, now) -> float:

days = (now - m.last_accessed_at).days

recency = math.exp(-days / 30) # 30일 반감 가정

frequency = math.log(1 + m.access_count)

return 0.6 * query_sim + 0.25 * recency + 0.15 * frequency

3. 엔드투엔드 과제 성공률

가장 중요한 지표입니다. "3세션 전에 알려준 선호를 새 세션에서 묻지 않고 반영하는가" 같은 시나리오를 스크립트로 만들어 통과율을 측정합니다. LongMemEval 같은 공개 벤치마크는 시간 추론, 다중 세션 추론, 갱신된 사실의 우선 적용 등을 체계적으로 다루므로 자체 평가셋의 설계 참고로 좋습니다.

4. 비용과 지연

메모리 파이프라인 자체의 LLM 호출 비용, 그리고 메모리 주입으로 늘어난 입력 토큰이 절약시킨 토큰(재설명 불필요)보다 큰지 작은지를 측정합니다. 메모리가 비용 절감 장치인지 비용 추가 장치인지는 측정 전에는 알 수 없습니다.

평가 시나리오 예시 (multi-session probe)

세션 1: 사용자가 "우리 팀은 pnpm만 쓴다"고 언급

세션 2: (무관한 대화)

세션 3: "의존성 추가해줘" 요청

통과: pnpm add 를 사용

실패: npm install 을 사용하거나 어느 것을 쓰는지 되물음

함정과 비판적 시각

메모리 오염 (memory poisoning)

가장 위험한 실패 모드입니다. 잘못된 사실이 한 번 저장되면 이후 모든 세션에 주입되어 오류를 재생산합니다. 더 심각한 것은 악의적 오염입니다. 사용자가 아닌 제3자의 콘텐츠(웹페이지, 이메일, 문서)를 에이전트가 읽다가 그 안의 지시문을 "기억"해버리면, 지속성을 가진 프롬프트 인젝션이 됩니다. 방어책은 다음과 같습니다.

- 신뢰 경계 구분: 사용자 직접 발언과 외부 콘텐츠 유래 정보를 다른 신뢰 등급으로 저장

- 쓰기 검증: 메모리 쓰기 전에 인젝션 패턴 검사

- 정기 감사: 메모리 스토어를 주기적으로 LLM 감사 (모순, 이상 지시문 탐지)

- 사용자 가시성: 저장된 메모리를 사용자가 열람하고 삭제할 수 있는 UI

프라이버시와 규제

메모리는 본질적으로 사용자 프로파일링입니다. GDPR의 삭제권(right to erasure)에 대응하려면 메모리 스토어 설계 단계부터 사용자 단위 완전 삭제가 가능해야 하고, 임베딩과 백업까지 삭제 범위에 포함해야 합니다. 민감 범주(건강, 신념, 성적 지향)는 추출 단계에서 기본 차단하고, 명시적 옵트인이 있을 때만 저장하는 것이 안전합니다.

과잉 기억의 역설

메모리를 많이 주입할수록 좋다는 가정은 틀렸습니다. 관련성 낮은 메모리 주입은 앞서 본 context rot를 그대로 재현하며, 사용자 입장에서도 "예전에 한 말을 맥락 없이 끌고 오는" 섬뜩한 경험이 됩니다. 회수 단계의 관련성 임계값을 보수적으로 잡고, 주입량의 상한을 두는 것이 실무 권장값입니다.

"그냥 컨텍스트를 키우면 되지 않나"라는 반론

100만 토큰 컨텍스트 시대에 메모리 시스템이 필요하냐는 반론이 있습니다. 일리가 있지만 세 가지 이유로 메모리는 여전히 필요합니다. 첫째, 멀티세션 누적 이력은 100만 토큰도 금방 넘습니다. 둘째, 비용과 지연은 컨텍스트 길이에 비례합니다. 셋째, lost in the middle은 윈도우가 커져도 사라지지 않았습니다. 긴 컨텍스트와 메모리는 대체재가 아니라 보완재입니다.

실무 도입 가이드

처음부터 3계층 메모리를 다 만들 필요는 없습니다. 단계적 로드맵을 권합니다.

1. 1단계 — compaction부터: 세션 내 요약 치환만 구현해도 긴 세션 품질이 눈에 띄게 개선됩니다.

2. 2단계 — 에피소드 메모리: 세션 종료 시 요약 저장, 시작 시 최근 3건 주입. 구현 난도 대비 효과가 가장 큽니다.

3. 3단계 — 시맨틱 메모리: 사실 추출과 갱신 파이프라인. Supermemory, mem0 같은 기존 오픈소스를 먼저 검토하고, 요구사항이 특수할 때만 자체 구축합니다.

4. 4단계 — 평가와 거버넌스: multi-session probe 평가셋, 메모리 열람/삭제 UI, 감사 파이프라인.

각 단계에서 "메모리가 없을 때 대비 과제 성공률이 얼마나 올랐는가"를 측정하고 다음 단계 진행 여부를 결정하면, 과잉 엔지니어링을 피할 수 있습니다.

마치며

프롬프트 엔지니어링이 "말을 잘 거는 법"이었다면, 컨텍스트 엔지니어링은 "기억과 주의를 설계하는 법"입니다. 그리고 이것은 일회성 트릭이 아니라 스키마 설계, 파이프라인, 평가, 거버넌스를 갖춘 소프트웨어 엔지니어링의 영역입니다. Supermemory 같은 오픈소스가 화제가 되는 이유도, 이 문제가 모든 에이전트 빌더의 공통 숙제가 되었기 때문일 것입니다.

에이전트의 지능은 모델 가중치에서 나오지만, 에이전트의 유용함은 상당 부분 기억 설계에서 나옵니다. 다음 에이전트를 만들 때, 모델 선택보다 메모리 스키마를 먼저 그려보시길 권합니다.

참고 자료

- Supermemory — 메모리 레이어 오픈소스: https://github.com/supermemoryai/supermemory

- GeekNews — Supermemory 소개 토픽: https://news.hada.io/topic?id=30378

- Anthropic — Effective context engineering for AI agents: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

- Lost in the Middle: How Language Models Use Long Contexts (Liu et al.): https://arxiv.org/abs/2307.03172

- MemGPT: Towards LLMs as Operating Systems (Packer et al.): https://arxiv.org/abs/2310.08560

- Letta (구 MemGPT) 프로젝트: https://github.com/letta-ai/letta

- mem0 — 메모리 레이어 오픈소스: https://github.com/mem0ai/mem0

- LongMemEval — 장기 메모리 벤치마크: https://arxiv.org/abs/2410.10813

- LangGraph Memory 개념 문서: https://langchain-ai.github.io/langgraph/concepts/memory/

- Anthropic — Prompt caching 문서: https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching