서론: 프롬프트 너머의 「컨텍스트 설계」

AI에게 무언가를 시킬 때, 우리는 자칫 「어떻게 지시할 것인가 (프롬프트)」만을 생각하기 쉽습니다. 하지만 실제로 출력의 질을 결정하는 것은 그 앞 단계에 있는 「무엇을 기억하게 하고, 무엇을 잊게 하며, 무엇을 지금 이 순간 보여줄 것인가」 —— 즉, 컨텍스트 (Context) 설계입니다.

이것은 **Context Engineering (컨텍스트 엔지니어링)**이라 불리며, 프롬프트 엔지니어링 (Prompt Engineering)보다 조금 더 넓은 개념입니다. 프롬프트가 「그 한 번의 지시문을 어떻게 작성할 것인가」라면, 컨텍스트 엔지니어링은 「모델에게 어떤 정보를, 어떤 순서로, 어느 정도 전달할 것인가」라는 조금 더 앞 단계의 설계 이야기를 의미합니다.

코딩 에이전트 (Coding Agent)를 일상적으로 사용하는 분이라면 이 중요성을 이미 피부로 느끼고 있을 것입니다. 무엇이든 채워 넣으면 되는 것이 아니라, 무엇을 싣고 무엇을 싣지 않을지가 출력의 질을 좌우한다는 것은 이제 공통된 인식이라고 해도 과언이 아닙니다.

이 기사에서는 그 사고방식을 Claude Code를 소재로 고찰해 보겠습니다. Claude Code의 사용법을 익히는 것이 목적이 아닙니다. CLAUDE.md · 자동 메모리 · 자동 요약과 같은 메커니즘을 「AI의 메모리를 어떻게 설계할 것인가」라는 관점에서 재검토하여, 우리 스스로 RAG나 에이전트를 만들 때도 사용할 수 있는 사고방식을 얻어가는 것이 목적입니다.

참고로 기사 후반부에서는 소스 코드 유출을 통해 추측되는 미공개 기능에 대해서도 다루지만, 이는 공식 발표가 아니라는 점을 미리 말씀드립니다.

1. 왜 「메모리 설계」가 필요한가

넓은 컨텍스트는 「용량이 여유로운 그릇」이 아니다

OpenAI의 창립 멤버인 Andrej Karpathy는 LLM을 「새로운 OS」에 비유하며, 「LLM은 CPU이며, 컨텍스트 윈도우 (Context Window)는 RAM이다」라고 표현했습니다. 또한 다른 기회에는 컨텍스트 엔지니어링을 「다음 단계에 최적인 정보만을 컨텍스트 윈도우에 채워 넣는, 섬세한 기술이자 과학이다」라고 말하기도 했습니다.

「100만 토큰 (1M)이 있다고 해서 전부 채워 넣으면 되는 것은 아니다」 —— 이는 이미 감각적으로 이해되고 있는 부분입니다만, 그렇다면 실제로 어느 정도 영향을 미칠까요? 이를 보여주는 데이터를 다시 한번 확인해 보겠습니다.

스탠퍼드 대학교 등의 연구에서 제시된 「Lost in the middle (중간 정보의 상실)」 —— 관련 정보가 문맥의 앞부분이나 뒷부분에 있으면 성능이 높고, 중간에 있으면 현저히 저하되는 U자형 곡선 —— 이 대표적인 사례입니다 [1]. 나아가 Chroma의 테크니컬 리포트 「Context Rot」에서는 입력 토큰이 늘어날수록 모델의 회상 능력 (Recall capability)이 (비균일하고 태스크 의존적으로) 저하된다는 것이 18개의 모델을 통해 입증되었습니다 [2].

즉, 넓은 컨텍스트 윈도우는 「용량이 여유로운 그릇」이 아니라, 무엇을 싣고 무엇을 싣지 않을지를 의식하며 사용해야 하는 RAM이라는 직관을 데이터가 뒷받침하고 있는 것입니다. 그렇기 때문에 컨텍스트는 「설계」의 대상이 됩니다.

2. 메모리 설계의 3가지 질문: 기억하기 · 잊기 · 떠올리기

여기서 이 기사를 통해 핵심 축으로 삼고 싶은 사고방식을 정리해 두겠습니다. AI의 메모리를 설계할 때, 결국 하는 일은 세 가지로 나눌 수 있다고 생각합니다.

기억하기 (Remember): 항상 곁에 두어야 할 전제는 무엇인가. 무엇을 영구적인 기억으로 갖게 할 것인가 -
잊기 (Forget): 무엇을 버릴 것인가. 오래된 정보, 노이즈가 되는 정보를 언제, 어떻게 적극적으로 버릴 것인가 -
떠올리기 (Recall): 필요할 때만 어떻게 과거의 기억을 끌어내어 눈앞에 나열할 것인가

메모리라고 하면 「어떻게 기억시킬 것인가」에만 눈길이 가기 쉽지만, 한정된 컨텍스트를 잘 활용하기 위해서는 「잊는 (Forget)」 설계가 그만큼 중요하다고 느낍니다. 계속 기억시키기만 하면 정보가 점점 쌓여 오히려 정밀도가 떨어지기 때문입니다.

이 「기억하기 · 잊기 · 떠올리기」를 염두에 두고, 다음 장에서는 Claude Code가 각각을 어떻게 구현하고 있는지 살펴보겠습니다. Claude Code를 예로 드는 이유는 이 세 가지가 꽤 깔끔하게 별개의 메커니즘으로 나뉘어 있어 분해해서 생각하기 쉽기 때문입니다.

3. Claude Code는 3가지 질문을 어떻게 해결하고 있는가

Claude Code의 메모리 메커니즘을 앞서 말한 세 가지에 대입해 보겠습니다. 그렇게 하면 각각의 기능이 「메모리 설계의 어떤 판단에 해당하는지」가 명확해집니다.

기억하기: CLAUDE.md (영구 메모리)

CLAUDE.md

는, 인간이 직접 작성하는 「항상 기억해 두었으면 하는 전제」입니다. 코딩 규약, 빌드 명령(build command), 프로젝트 구조와 같이 매 세션 반드시 곁에 두고 싶은 정보를 작성합니다. 세션 시작 시 파일 전체가 읽혀집니다.

여기서 중요한 판단이 바로 「너무 많이 기억시키지 않는 것」입니다. 공식 문서에서는 「파일당 200행 이하를 기준으로」 삼을 것을 권장하며, 이를 초과하면 컨텍스트 (context)를 많이 소비하여 지시 준수율 (adherence)이 저하되는 경향이 있다고 주의를 주고 있습니다 [3]. 영구 메모리는 전부 기억시킨다고 좋은 것이 아니라, 압축할수록 효과적이다. 이는 자체 시스템으로 치면 「시스템 프롬프트 (system prompt)에 무엇을 상주 시킬 것인가」의 판단과 완전히 동일한 문제입니다.

기억해내기: Auto Memory (온디맨드 기억)

Auto Memory

는 Claude Code가 작업 중에 축적한 프로젝트 고유의 지견 (빌드 명령, 디버깅 시의 깨달음, 코드 스타일 선호도 등)을 자동으로 메모리 파일에 저장하는 메커니즘입니다. 모델이 장기 기억으로서 「학습」하는 것이 아니라, 어디까지나 로컬 텍스트 파일에 써 내려가서 다음 회차 이후에 읽어 들이는 것이라는 점에 주의하십시오.

핵심은 전부를 항상 읽어 들이는 것이 아니라는 점입니다. ~/.claude/projects/<project>/memory/ 하위에 저장되지만, 세션 시작 시 읽히는 것은 인덱스 (index, MEMORY.md)의 처음 200행 (또는 25KB, 둘 중 빠른 쪽)뿐입니다. debugging.md나 patterns.md와 같은 토픽 파일은 기동 시에는 읽히지 않으며, 필요할 때 표준 파일 도구를 통해 온디맨드 (on-demand)로 읽어 들여집니다 [3:1].

이것은 그야말로 「기억해내기」의 설계입니다. 전부를 항상 컨텍스트에 올려두는 것이 아니라, 색인(index)만 가지고 있다가 필요할 때 꺼내 쓰는 방식입니다. RAG의 「인덱스는 보유하되, 검색에서 히트(hit)된 것만 프롬프트에 올린다」는 구조와 발상이 같습니다.

참고로, 이 온디맨드 읽기의 내부 메커니즘은 공식적으로 공개되지 않았으나, 관찰 결과 키워드 검색에 가까운 동작을 보일 때가 있습니다. 따라서 「표현 방식이 바뀌면 과거의 기억을 끌어내기 어렵다」는 약점이 지적되기도 합니다 (이는 어디까지나 실운용상의 관찰에 기반한 지적이며, 공식 사양은 아닙니다). 「기억해내기」의 정밀도를 어떻게 높일 것인가는 후술할 시맨틱 검색 (semantic search) 이야기로 이어집니다.

잊기: 컴팩션 (Compaction, 자동 요약)

그리고 「잊기」를 담당하는 것이 컴팩션 (compaction)입니다. 공식 문서에 따르면, 컨텍스트가 상한에 가까워지면 Claude Code는 먼저 오래된 도구 출력 (tool output)을 폐기하고, 필요에 따라 대화를 요약합니다. 구체적인 임계값(threshold)에 대해서는 커뮤니티의 분석에 따르면 「사용률이 약 83.5%에 도달한 시점에서, 처리용 버퍼 (약 33K 토큰)를 남기고 컴팩션이 실행된다」고 보고되고 있습니다 (공식적으로 명시된 수치가 아니라, 리버스 엔지니어링이나 관측에 기반한 값이라는 점에 유의하십시오).

여기서 포인트는 「잊는 것」이 부작용이 아니라, 제대로 된 기능으로 준비되어 있다는 점입니다. 그대로 두면 컨텍스트는 언젠가 넘치기 때문에, 시스템이 스스로 버리러 가는 것입니다. 다만, 이 자동 망각에만 전적으로 맡기면 디버그 로그나 특정 변수명 같은 중요한 문맥까지 함께 사라질 수도 있습니다. 따라서 「무엇을 잊게 하고, 무엇을 잊지 않게 할 것인가」는 우리가 의식적으로 설계하고 싶은 부분입니다.

4. 우리의 설계로 가져오기: 실전 팁

3가지 질문과 Claude Code의 해답을 살펴보았습니다. 이제부터는 이를 바탕으로 실제로 어떻게 운용할 것인가 / 자신의 시스템에 어떻게 활용할 것인가를 정리된 프레임워크에 따라 생각해보겠습니다.

컨텍스트 관리를 Write / Select / Compress / Isolate의 4가지로 나누어 생각하는 정리 방식이 있습니다 (LangChain의 공식 블로그 「Context Engineering for Agents」에서 소개된 것입니다 [4]). 이 분류 방식이 머릿속을 정리하는 데 유용했기에, 4가지 각각에 대해 Claude Code에서의 사용법과 자신의 시스템에 대입했을 때 어떻게 되는지를 세트로 작성하겠습니다.

Select (필요한 것만 기억해내기)

「기억해내기」를 효율화하는 이야기입니다. Claude Code는 기본적으로 도구 스키마 (tool schema)를 지연 (deferred)시키며, 태스크에서 필요해진 것만 온디맨드로 읽어 들입니다 (환경 변수 ENABLE_TOOL_SEARCH

제어합니다). 또한, .claude/rules/ 하위의 규칙은 YAML 프론트매터(YAML frontmatter)의 paths 필드에서 스코프(scope)를 지정할 수 있으며, 해당 패턴의 파일을 다룰 때만 적용됩니다.

사용하지 않는 정보까지 맨 앞에서 전부 읽어 들이는 것은 컨텍스트(context)의 낭비입니다. CLAUDE.md를 비대하게 만들지 않고, 조건부로 로드하게 합니다. 자체 시스템을 구축한다면 "모든 문서를 매번 프롬프트에 넣는" 것이 아니라, 쿼리(query)에 따라 필요한 부분만 추출한다——이는 RAG(Retrieval-Augmented Generation) 그 자체의 발상입니다.

Write (기억해야 할 상태를 외부에 퇴피시키기)

"잊는 것"에 대비하는 이야기입니다. 컨텍스트가 상한선에 가까워지면 Claude Code는 자동으로 컴팩션(compaction)을 수행하기 때문에, 대화 이력의 세세한 문맥은 소실될 수 있습니다. 이를 방지하려면 사라져 버리는 대화 이력에 의존하는 대신, 물리 파일에 수시로 써 내려가게 하는 것이 유효합니다. 구체적으로는 코딩 규약이나 아키텍처 제약과 같은 영구적인 전제는 CLAU.md에, 현재 태스크 진행 상황과 같이 변하는 상태는 PROGRESS.md와 같은 별도의 파일에 나누어 작성한다는 이미지입니다. 둘 다 항상 로드되므로, 컴팩션으로 대화 이력이 깎여 나가더라도 문맥을 유지할 수 있습니다.

휘발되는 기억(대화 이력)과 영속하는 기억(파일)을 의식적으로 구분하여 사용합니다. 자체 에이전트를 만들 때도 "대화 로그에 남길 것"과 "DB에 영속화할 것"을 구분하는 동일한 설계 판단이 필요하게 됩니다.

Compress (적극적으로 잊기)

"잊는 것"을 스스로 수행하는 이야기입니다. 시스템의 자동 컴팩션에만 전적으로 맡기면 중요한 문맥이 상실되기 쉽습니다. 제 경험상, 컨텍스트가 50% 정도에 도달했을 때, 차라리 스스로 /clear를 통해 세션을 끊고, PROGRESS.md 등의 구조화된 파일로부터 문맥을 다시 읽어 들인 편이 결과적으로 품질을 유지하기 쉽다고 느낍니다 (명확한 수치적 근거가 있는 것은 아니며, 어디까지나 운용상의 경험칙입니다).

"잊게 만드는 타이밍을 설계자가 쥐고 있다"는 발상입니다. 수동적으로 잊히는 것이 아니라, 능동적으로 리셋하여 정말로 필요한 정보만을 다시 읽어 들이게 합니다.

Isolate (회상하는 정밀도 높이기)

"회상하는" 정밀도를 높이는 이야기입니다. 표준 Auto Memory는 기동 시 읽어 들이는 인덱스가 200행(25KB)까지이며, 토픽 파일은 온디맨드(on-demand)로 읽어 들이는 구조였습니다. 프로젝트가 장기화되면 이 구조만으로는 과거의 기억을 끌어내기가 어려워집니다.

본격적으로 운용하려면 memsearch나 claude-session-memory와 같은 오픈 소스 메모리 확장 도구의 도입도 선택지입니다. 대화 이력을 벡터 DB(Vector DB)화하면, 키워드가 다르더라도 "의미(시맨틱 검색, Semantic Search)"를 통해 과거의 기억을 끌어낼 수 있습니다. 이것은 바로 자체적으로 RAG를 구축할 때 하는 일 그 자체입니다. Claude Code의 "회상" 약점을 보완하는 방법이 자체 시스템의 설계와 그대로 겹칩니다.

5. 미래 이야기: "잊기"를 자동화하는 Auto Dream

여기까지는 현재 실제로 사용할 수 있는 메커니즘과 운용에 관한 이야기였습니다. 마지막으로, "잊기" 설계의 연장선상에 있는 미래 이야기 하나를 소개합니다.

축적된 기억을 방치하면 금방 진부해지고, 모순된 정보(오래된 라이브러리 기술 등)가 쌓입니다. 유출된 소스 코드에 따르면, 이를 해결하기 위해 준비되어 있는 것으로 보이는 것이 바로 **"Auto Dream"**입니다. 주목해야 할 점은, 그 4단계 중 마지막이 Prune(가지치기) = 불필요한 정보를 삭제하고 인덱스를 정리하는 것, 즉 "잊는" 공정으로서 명시적으로 설계되어 있다는 점입니다.

인간의 수면 중 기억 정리(기억의 고착화)에 비유한 이 발상은, "AI에게 무엇을 잊게 할 것인가"를 자동화의 대상으로 삼고 있습니다. 설령 이러한 메커니즘이 정식으로 도입된다 하더라도, 설계자가 고민해야 할 것——"무엇을 남기고 무엇을 버릴 것인가"——이 사라지는 것은 아닙니다. 오히려 망각의 기준을 결정하는 것은 여전히 인간의 설계 판단입니다.

6. 마치며: 기억하기·잊기·회상하기를 자신의 손으로 설계하기

Claude Code를 분해해 보면, 결국 처음에 언급했던 세 가지로 귀결됩니다.

• 기억하기 = CLAUDE.md (항상 곁에 두는 영구 메모리. 단, 범위를 좁힐수록 효과적임)
• 회상하기 = Auto Memory (인덱스만 보유하고, 필요할 때 온디맨드로 끌어냄)
• 잊기 = 컴팩션(Compaction) · /clear · Auto Dream (적극적으로 버려서 컨텍스트를 깔끔하게 유지함)

그리고 이 3개 계층은 Claude Code만의 이야기가 아닙니다. RAG(Retrieval-Augmented Generation)의 "무엇을 검색 가능하게 하고, 무엇을 프롬프트(Prompt)에 포함할 것인가"도, 자체 에이전트의 "대화 이력을 어디까지 유지하고, 언제 요약할 것인가"도 완전히 동일한 설계 문제입니다. 컨텍스트(Context)를 다루는 일은 기업의 중요한 자산인 지식(Knowledge)을 어떻게 축적하고, 어느 타이밍에 호출할 것인가라는 핸들링(Handling) 그 자체와도 직결됩니다. LLM(Large Language Model)에게 언제, 어떻게, 무엇을 전달하고, 무엇을 전달하지 않으며, 어떤 지시(Instruction) 하에 사용하게 할 것인가. 이 설계가 AI를 활용한 기능의 최종적인 아웃풋(Output) 품질과 가치를 결정합니다.

프롬프트의 좋고 나쁨만 고민할 것이 아니라, 그 전 단계인 컨텍스트 그 자체를 설계하는 것. 그리고 기억하게 하는 것만큼이나 "무엇을 잊게 할 것인가"도 의식해야 합니다. Claude Code는 그러한 사고방식을 정리하기에 아주 적절한 소재였다고 생각합니다.

Lost in the Middle: How Language Models Use Long Contexts (Liu et al., TACL 2024 / arXiv:2307.03172) — 관련 정보가 문맥의 중간에 있으면 성능이 저하되는 "U자형 곡선" ↩︎

Context Rot: How Increasing Input Tokens Impacts LLM Performance (Chroma Research, 2025) — 입력 토큰 증가에 따른 성능 저하를 18개 모델에서 검증 ↩︎

How Claude remembers your project (Claude Code Docs) — CLAUDE.md · Auto Memory의 사양 (200행/25KB의 읽기 상한, adherence에 미치는 영향 등) ↩︎ ↩︎

Context Engineering for Agents (LangChain Blog, 2025-07-02) — 컨텍스트 관리를 Write / Select / Compress / Isolate로 정리 ↩︎

Discussion