컨텍스트 엔지니어링

💡 학습 가이드: 프롬프트 엔지니어링이 "어떻게 명확하게 말할 것인가"를 다룬다면, 컨텍스트 엔지니어링은 "모델이 적절한 순간에 적절한 정보를 보도록 하는 것"을 다룹니다. 이 장에서는 한 가지 질문을 중심으로 이야기합니다. 제한된 컨텍스트 윈도우 안에서, 어떻게 모델이 당신을 이해하게 하면서도 비용을 낭비하지 않을 수 있을까?

시작하기 전에, 먼저 두 가지 "기초 벽돌"을 쌓는 것을 추천합니다:

• 토큰(Token)이란 무엇인가: 대규모 언어 모델 입문의 「토큰화 & 토큰」부분을 먼저 읽어보세요.
• 프롬프트(Prompt)란 무엇인가: System / User / Assistant의 기본 구조에 익숙하지 않다면, 프롬프트 엔지니어링을 먼저 살펴보세요.

---

0. 서론: 왜 대화가 길어질수록 점점 더 많은 것을 잊고, 점점 더 비싸질까?

1Current round

1200Token usage

$0.0024Current cost

✅Memory intact

Context Window Limit (4000)

System Prompt (1000)

New Input

Drag the slider to add conversation rounds:

Round 1Round 20

💡 Everything is normal：The current token count (1200) is still within the window. The model can recall all conversation details.

많은 사람들이 실제로 대규모 언어 모델을 사용할 때 비슷한 상황을 겪습니다:

• 대화 중간에 모델이 갑자기 이전에 말했던 핵심 조건을 "잊어버리는" 경우
• 긴 대화에서 앞뒤 답변이 모순되어 동일한 설정을 유지하기 어려운 경우
• 대화 턴이 늘어날수록 택시 미터기처럼 요금이 계속 올라가는 경우

직관적으로 우리는 이렇게 생각하기 쉽습니다: "이 모델은 기억력이 나쁘구나". 하지만 대부분의 경우, 문제는 모델이 "기억하지 못하는" 것이 아니라, 우리가 모델이 볼 수 있는 컨텍스트를 제대로 설계하지 않았기 때문입니다.

Problem

• Context is hard to keep consistent：As conversations grow, earlier and later meaning can drift apart.
• Key facts are easy to lose：Information given early can be hard to reference accurately later.
• Call cost keeps rising：Every round has to process a large amount of history again.

Likely causes

• The model only sees the current call：It can only rely on the context provided in this round.
• Information is not structured：Important facts and minor details are mixed together, making stable memory hard.
• History is recomputed repeatedly：Large fixed prefixes are processed again and again across turns.

Impact

• Answer quality becomes unstable：Longer conversations make consistency and traceability harder.
• Cost is hard to estimate：Context size fluctuates heavily from turn to turn.
• Production systems become hard to maintain：Without a clear context strategy, systems are hard to operate and extend.

이러한 도전에 직면했을 때, 단순히 "좋은 프롬프트 작성"에만 의존하는 것은 한계가 있습니다. 우리는 제한된 윈도우와 예산 안에서 모델이 항상 가장 중요한 정보를 얻을 수 있도록 하는 더 체계적인 엔지니어링 방법이 필요합니다. 이것이 바로 컨텍스트 엔지니어링이 해결하려는 문제입니다.

---

1. "컨텍스트 엔지니어링"이란 무엇인가? (정의 + 시나리오)

먼저 간단한 작업 정의를 내리고, 몇 가지 전형적인 시나리오를 살펴보겠습니다.

컨텍스트 엔지니어링은 LLM을 위해 "정보 환경"을 구축하고 관리하는 엔지니어링 방법으로, 모델이 "무엇을 보고, 무엇을 무시하며, 언제 볼 것인지"를 결정하여 제한된 컨텍스트 윈도우 내에서 안정적으로 작업을 완수하도록 합니다.

간단히 세 가지로 요약할 수 있습니다: 정보 정리, 윈도우 제어, 비용 관리. 일반적으로 사용되는 시나리오는 다음과 같습니다:

• 대화형 에이전트와 고객 서비스 봇
• 코드/문서 어시스턴트
• 멀티턴 도구 호출과 긴 워크플로우 오케스트레이션

다음으로, 실제 팀의 "피눈물 나는 교훈"에서 출발하여, 그들이 어떻게 "프롬프트만 작성하는" 단계에서 "컨텍스트 엔지니어링을 할 수 있는" 단계로 진화했는지 살펴보겠습니다.

---

2. "피눈물 나는 교훈"에서 시작하기: Manus 팀이 밟은 함정들

이 장의 사례는 Manus(범용 AI 에이전트)에서 가져왔습니다. 일반 대화와 달리, Manus는 자율적으로 계획을 세우고 도구를 호출하여 긴 작업(수십에서 수백 턴의 상호작용 포함)을 완료해야 합니다.

이로 인해 핵심 모순이 발생합니다:

• 기록하지 않으면: 핵심 정보가 손실되어 작업이 중단됩니다.
• 전부 기록하면: 비용과 지연 시간이 폭발적으로 증가하고, 컨텍스트 윈도우 제한을 초과할 수도 있습니다.

Manus 팀은 여러 번의 아키텍처 재구성을 거친 후에야 한 가지 진리를 깨달았습니다: 컨텍스트는 단순히 "작성"하는 것이 아니라, "설계"해야 한다는 것입니다.

2.1 네 번의 재구성이 우리에게 가르쳐 준 것

Manus의 공동 창업자 季逸超는 그들의 "실패의 역사"를 공유했습니다:

단계	직면한 문제	당시의 생각	결과
첫 번째	AI가 대화하다 보면 점점 잊어버림	"프롬프트를 더 많이 작성하면 되겠지"	점점 더 길어지고, 점점 더 비싸짐
두 번째	중요한 정보가 항상 밀려남	"중요한 건 여러 번 복사하면 되겠지"	텍스트가 더 길어지고, 비용은 더 높아짐
세 번째	청구서가 엄청나게 높음	"이전 계산을 재사용할 수 있을까?"	중복 계산 비용을 줄이는 방법을 찾음
네 번째	긴 문서를 처리할 수 없음	"필요할 때만 조회하면 안 될까?"	"도서관 + 필요 시 검색" 방안 구축

핵심 깨달음: 많이 기억할수록 좋은 것이 아니라, 교묘하게 기억할수록 좋다는 것입니다.

2.2 AI의 "기억력"은 도대체 무엇과 비슷할까?

전통적인 컴퓨터 메모리 = 하드 디스크:

• 용량이 큼: 대량의 데이터를 장기간 보관 가능
• 가격이 저렴함: 1년 보관 비용이 비교적 낮음
• 읽기/쓰기 속도가 상대적으로 느리고, 정보를 찾는 데 일정 시간이 소요됨

AI의 컨텍스트 = 작은 칠판:

• 읽기/쓰기가 빠름: 모델이 한 번의 호출로 전체 컨텍스트를 직접 볼 수 있음
• 용량이 제한적: 가득 차면 오래된 내용을 지울 수밖에 없음
• 모든 토큰을 쓸 때마다 추가 계산과 비용이 발생

Manus의 경험: 작은 칠판은 아껴 쓰고, 교묘하게 써야 하며, 백과사전을 저장하는 용도로 쓰면 안 됩니다.

---

3. 첫 번째 단계: 비용 인식 - 당신의 모든 돈은 어디에 쓰이는가?

3.1 왜 먼저 비용을 살펴봐야 할까?

전형적인 AI 대화에서 당신의 돈이 어떻게 소비되는지 살펴보겠습니다:

💰 비용 구성 (1회 대화):
├─ 70% 이전 내용을 반복해서 읽음 ("방금 우리 무슨 얘기했지?")
├─ 20% 새로운 내용 처리 ("지금 무슨 말을 하고 있지?")
└─ 10% 답변 생성 ("어떻게 대답하지?")

놀라운 발견: 70%의 비용이 AI가 당신이 이전에 말한 내용을 다시 읽게 하는 데 사용됩니다!

3.2 KV Cache란 무엇인가? (프리픽스 재사용)

가격을 논의하기 전에, 먼저 핵심 기술 개념 하나를 이해해야 합니다: KV Cache(키-값 캐시). 이 기술 용어에 겁먹지 마세요. 이는 사실 AI의 "단기 기억 속성 조회표"에 불과합니다.

• KV Cache가 없을 때: AI는 매번 이 글을 처음 보는 것처럼, 첫 글자부터 다시 읽고, 이해하고, 계산합니다.
• KV Cache가 있을 때: AI는 이미 읽은 부분(Pre-fill)의 계산 결과를 저장해 둡니다. 다음에 시작 부분이 변경되지 않았다면, 직접 기억을 불러와 다시 계산할 필요가 없습니다.

이는 마치 다음과 같습니다:

당신이 시험장에 갔다고 생각해 보세요. 상황 A: 매번 교과서 전체를 처음부터 끝까지 읽은 후 문제를 풀기 시작합니다. (느리고, 힘들고, 비쌈) 상황 B: 교과서 내용을 이미 완벽하게 외우고 있어서(Cache), 자리에 앉자마자 바로 답을 씁니다. (빠르고, 편하고, 저렴함)

클라우드 사업자의 과금표에서 "이미 외운 내용" (Cache Hit)은 보통 "새로 읽는 내용" (Cache Miss)보다 90% 이상 저렴합니다.

3.3 "교과서 외우기" vs "필요할 때 찾아보기"의 가격 차이

Claude를 예로 들면:

• 필요할 때 찾아보기 (캐시 없음): 백만 자당 $3.00
• 외워서 사용하기 (캐시 있음): 백만 자당 $0.30
• 10배 차이!

Manus의 실천: AI에게 "교과서를 외우게" 함으로써, 비용을 $0.15에서 $0.02로 낮추어, 87%를 절약했습니다!

13Tokens written so far

/

100Maximum tokens on the board

13.0%

🧠The small board the model can see (context window)

ContextEngineeringmeansoptimizingtheinformationprovidedtoalargelanguagemodel.

Input content

Context Engineering means optimizing the information provided to a large language model.

💡Note: The context window is like a small board for the model. The board has limited space, so old content must be erased before new content can fit. Once it overflows, the earliest content disappears from the model view.

3.4 함정 피하기: 타임스탬프가 당신의 "캐시"를 망치지 않게 하라

많은 개발자들은 "현재 시간"을 System Prompt의 첫 줄에 쓰는 습관이 있습니다. 엄밀하다고 생각하기 때문이죠. 하지만 이것이야말로 컨텍스트 엔지니어링에서 가장 큰 안티 패턴 중 하나입니다.

상상해 보세요: 당신이 역사책 한 권(System Prompt)을 통째로 외웠는데, 그 책의 첫 줄에 "현재 초"가 적혀 있습니다. 만약 이 줄이 매초 바뀐다면, 당신이 이전 1초 동안 외운 모든 내용은 다음 1초에 전부 무효가 됩니다——처음부터 다시 외워야 합니다.

이것이 바로 프리픽스 재사용(KV Cache)의 치명적인 약점입니다: 시작 부분만 바뀌어도, 그 뒤의 모든 내용을 다시 계산해야 합니다.

잘못된 예시: 동적 정보를 앞에 배치

System: 지금은 2024-01-01 12:00:01 입니다. 당신은 어시스턴트입니다...
(1분 후)
System: 지금은 2024-01-01 12:01:01 입니다. 당신은 어시스턴트입니다...

결과: 단 몇 글자만 변경되었지만, 시작 부분에 있기 때문에 뒤따르는 99%의 고정 콘텐츠가 캐시를 재사용할 수 없게 되어, 매 요청이 처음과 똑같이 느리고 비싸집니다.

올바른 방법: 동적/정적 분리

System: 당신은 어시스턴트입니다... (여기에 수천 자의 고정 규칙, 지식 베이스 배치)
User: (여기에서 도구 호출이나 사용자 메시지를 통해 현재 시간 전달)

장점: 앞부분의 수천 자 규칙은 절대 변하지 않으므로, AI는 한 번만 "외우면" 됩니다. 이후 요청은 직접 기억을 불러와 속도가 매우 빨라집니다.

👇 클릭해서 확인해 보세요: 아래 토글을 클릭하여 "교과서 외우기 가속"을 켠 후, "새 요청 보내기"를 여러 번 클릭해 보세요. 첫 번째 콘텐츠 블록이 "이미 외운 상태"가 될 때, 첫 토큰 응답 시간(TTFT)이 어떻게 변화하는지 관찰해 보세요.

Enable prefix reuse / KV Cache

⚙️Fixed opening prompt (System Prompt)

You are a helpful AI assistant... (about 500 tokens)

💬Recent chat history

User: hello... (about 200 tokens)

❓New question for this turn

Write a Python snippet for me (about 50 tokens)

0ms

Time to first token (TTFT)

0

Tokens processed this time

0

Approximate compute cost

⏱️Without cache:Every request recomputes attention from the beginning, like rereading a textbook from page one every time.

---

4. 두 번째 단계: 슬라이딩 윈도우 - "기억"이 "비용"으로 바뀔 때

대화가 길어짐에 따라 가장 먼저 부딪히는 문제는: 윈도우가 가득 차면 어떻게 할 것인가?

4.1 왜 "선입선출"이 문제가 될까?

가장 간단한 기억 관리는 슬라이딩 윈도우(Sliding Window): 새로운 것이 들어오면, 오래된 것이 나갑니다. 이는 매우 공평하게 들리지만, 실제 작업에서는 재앙이 될 수 있습니다.

시나리오 재현:

대화 기록:
[1] 사용자: 저는 장삼이고, 결제 시스템을 담당합니다
[2] 사용자: 프로젝트는 Go 언어로 개발합니다
[3] 사용자: 데이터베이스는 PostgreSQL입니다
...
[20] 사용자: 인터페이스 하나 작성해 주세요

결과: 20번째 대화에 도달했을 때, 1번째 "저는 장삼입니다"는 이미 윈도우 밖으로 밀려났습니다. AI는 당신이 누구인지, 어떤 시스템을 담당하는지 완전히 잊어버립니다.

문제의 본질: 이 전략은 중요한 정보(신원, 기술 스택)와 잡담("네", "알겠습니다")을 동등하게 취급하여 함께 제거해 버립니다.

4.2 "중간 기억 상실증" - 왜 AI는 항상 핵심 정보를 놓칠까?

"빨리 잊어버리는" 것 외에도, AI에는 또 다른 특이한 점이 있습니다: "놓쳐 보는" 현상입니다. 연구에 따르면: AI는 시작과 끝 부분에 가장 민감하고, 중간 부분을 가장 쉽게 무시합니다. 이것이 바로 유명한 Lost in the Middle(중간에서 길을 잃다) 현상입니다.

U자형 기억 곡선:

위치: 시작 → 중간 → 끝
기억:  높  →  낮  →  높

👇 클릭해서 확인해 보세요:

1. 먼저 "슬라이딩 윈도우"를 시도해 보세요: 아래 채팅창에 여러 메시지를 보내, 오래된 대화가 어떻게 무정하게 "밀려나는지" 관찰해 보세요.
2. 그다음 "중간에서 길을 잃다"를 살펴보세요: 핵심 정보가 전체 텍스트의 중간 부분에 숨겨져 있을 때, 검색 성공률이 가장 낮아지는지 관찰해 보세요.

Maximum remembered messagesUp to 4

🗑️ Forgotten content

Nothing has been pushed out yet

⬆ Outside the window, invisible to the model

⬇ Inside the window, still visible to the model

🖼️ Conversation still in memory

Start chatting here and watch old messages get pushed out

💡Note: A sliding window is the simplest memory strategy: new content enters and old content leaves. It never overfills the context, but once content slides out, the model forgets it completely.

Where is the key fact in the full context: 50%

Start (System)

End (Query)

📍

Key fact

Recall probability

Position in context

40.0%

Retrieval success

Middle area, highest risk

Position description

🔍Observation:When a key fact is hidden in the middle of a long context, the model is most likely to miss it.
The reliable approach is to place important instructions at the very front in the System Prompt or at the end in the latest user query.

해결책: 핵심 정보를 시작 부분(시스템 프롬프트) 또는 끝 부분(사용자 질문)에 배치하세요.

---

5. 세 번째 단계: 선택적 보존 - 핵심 정보를 어떻게 "고정"할 것인가?

"선입선출"이 믿을 수 없다면, 어떻게 해야 할까요? Manus의 답은: "정보 등급 제도"를 구축하는 것입니다.

5.1 왜 정보에 등급을 매겨야 할까?

더 이상 모든 정보를 동등하게 취급하지 않고, 중요도에 따라 남기거나 제거합니다:

등급	정보 유형	대우	비용 영향
VIP	시스템 설정, 사용자 신원	영구 보존	+15% 비용
중요	현재 작업 목표	작업 기간 동안 보존	+10% 비용
일반	일반 대화 이력	최근 5턴 보존	기준 비용
폐기 가능	검색 가능한 지식	필요할 때만 조회	-60% 비용

핵심 사상: 25%의 비용 증가로, 90%의 핵심 정보 보존을 달성합니다.

5.2 "못 박기" 전략

컨텍스트 윈도우를 하나의 칠판으로 상상해 보세요:

• VIP 정보: 칠판 가장 위에 못으로 단단히 고정합니다 (System Prompt).
• 중요 정보: 자석으로 칠판 중간에 붙여 둡니다 (Context Injection).
• 일반 대화: 칠판 하단에 적고, 가득 차면 오래된 것을 지웁니다 (Sliding Window).

👇 클릭해서 확인해 보세요: 아래 데모에서 중요한 대화를 "고정"해 보세요. 계속 대화할 때, 고정된 정보는 계속 남아 있지만 고정되지 않은 정보는 밀려나는지 관찰해 보세요.

3Messages remembered now

/

6Maximum messages on the board

📌Pinned area for important information1 now

System

You are a helpful AI assistant focused on coding.

📜Regular FIFO conversation2 now

User

Hi, I want to learn Vue.

AI

Sure! Vue is a progressive framework.

💡Note: Selective retention means pinning important information to the board while ordinary messages slide away. System prompts are usually pinned permanently, and key user facts such as names, accounts, or preferences can be pinned through memory modules or RAG.

---

6. 네 번째 단계: RAG - "기억"에 "도서관"이 필요할 때

때로는 처리해야 할 정보가 너무 많아(예: 수백 페이지의 기술 문서), 칠판에 도저히 다 쓸 수 없을 때가 있습니다. 이럴 때 필요한 것이 외장 두뇌——RAG(검색 증강 생성)입니다.

6.1 왜 "작은 칠판"으로는 부족할까?

Manus가 백만 자 규모의 기술 문서를 다룰 때, 두 가지 방법을 비교했습니다:

1. 전체 입력: 모든 내용을 한 번에 컨텍스트에 집어넣기.
   • 결과: 칠판이 순식간에 가득 차고, 처리가 극도로 느려지며, "중간에서 길을 잃다" 이론에 따르면 AI가 중간 내용을 전혀 기억하지 못합니다.
   • 비용: 약 $50/회, 15초 대기.
2. 필요 시 검색(RAG): 먼저 도서관(데이터베이스)에서 조회하고, 관련된 몇 단락만 칠판에 옮겨 적기.
   • 결과: 칠판이 매우 깨끗하고, AI가 핵심 정보에 집중합니다.
   • 비용: 약 $0.5/회, 2초 대기.

99%의 비용과 87%의 시간을 절약했습니다!

6.2 "자료 찾기"의 모범 사례

Manus의 경험 요약:

• 책 한 권을 얼마나 큰 조각으로 나눌까? 500-1000자가 가장 효과적입니다.
• 한 번에 몇 권을 조회할까? 3-5권, 너무 많으면 오히려 방해됩니다.
• 얼마나 관련성이 있어야 조회할까? 유사도 > 0.7, 관련 없는 내용을 억지로 끼워 맞추지 마세요.

👇 클릭해서 확인해 보세요: 검색창에 질문을 입력하고(예: "비밀번호를 재설정하는 방법"), 시스템이 많은 문서 중에서 가장 관련성 높은 몇 가지만 어떻게 찾아내는지 살펴보세요.

1User Query

🔍

2Library retrieval

📄Password reset guide

Users can reset their password by clicking the "Forgot password" link on the settings page. The system sends a verification email.

📄Pricing policy

Basic is $10 per month, Pro is $29 per month. Enterprise customers should contact sales for a quote.

📄API documentation

All API requests must include a Bearer Token in the Header for authentication.

📄Account security

For account security, enable two-factor authentication and change passwords regularly.

✂️ Copy into context

3Final Prompt

SYSTEM You are a professional AI assistant. Answer the user question using the retrieved materials below.

USER Waiting for a question...

---

7. 다섯 번째 단계: 압축 - "작은 칠판"을 어떻게 더 빽빽하게 쓸 것인가?

정보가 모두 중요해서 도저히 삭제할 수 없고, 검색하기도 싫다면 어떻게 할까요? 그렇다면 글씨를 더 작게 쓰는 수밖에 없습니다——이것이 바로 컨텍스트 압축입니다.

7.1 언제 "축약"이 필요할까?

• 검색해 온 자료가 너무 방대할 때 (>2000자).
• 대화 이력이 너무 장황할 때 (칠판 공간의 80% 이상 차지).
• 빠르게 답변해야 하고, AI가 장문을 읽게 하고 싶지 않을 때.

7.2 "축약"의 세 가지 경지

압축 방식	압축률	보존되는 것	적용 시나리오	비용 절감 효과
요약식	70%	주요 의미	빠른 이해	30% 절약
핵심식	50%	핵심 포인트	구조화된 출력	50% 절약
표 형식	30%	핵심 데이터	프로그램 처리	70% 절약

👇 클릭해서 확인해 보세요: 다양한 압축 전략을 선택하여, 장문이 어떻게 짧고 정제되는지 살펴보세요.

1. Choose compression strategy

Original text420 tokens

Context Engineering means optimizing the prompt and information provided to a large language model so it has what it needs to generate accurate and relevant responses. One major challenge is the limited context window, which restricts how much text a model can process at once. Developers use techniques such as summarization to condense long documents while preserving key information. Retrieval-augmented generation fetches only the most relevant snippets for a user query. Converting unstructured text into structured data such as JSON can also reduce redundancy and increase information density.

⬇️

Compressed

Click a button above to start compression

---

8. 시스템 통합: AI의 "기억의 궁전" 만들기

앞서 우리는 블록 쌓기처럼 다양한 독립적인 전략을 배웠습니다:

• KV Cache: 비용 절감에 도움 (제3장)
• 슬라이딩 윈도우: 공간 확보에 도움 (제4장)
• 등급별 보존: 핵심 내용 유지에 도움 (제5장)
• RAG: 외장 두뇌 확장에 도움 (제6장)

이제 이 블록들을 하나의 완전한 성으로 조립할 시간입니다——우리는 이를 Manus의 "기억의 궁전"이라고 부릅니다.

8.1 집을 짓듯 컨텍스트 조립하기

컨텍스트를 뒤죽박죽된 텍스트 더미로 보지 말고, 계층화된 건축물로 바라보세요. 각 계층마다 고유한 기능과 "거주 규칙"이 있습니다.

👇 클릭해서 확인해 보세요: "건설 시작"을 클릭하여, 우리가 어떻게 이 궁전을 한 층씩 쌓아 올리는지 살펴보세요.

🔍

Layer 4: Library (RAG)

Knowledge retrieved on demand

💬

Layer 3: Living Room (Chat)

Most recent 5-10 conversation turns

📌

Layer 2: Pillar (Task)

Current task goal and user profile

🏛️

Layer 1: Foundation (System)

System identity, role, and principles

🚧 Empty lot: click the button below to build the memory palace

Progress: 0/4

8.2 이렇게 설계하는 것이 가장 강력한 이유는?

이 궁전의 설계 철학은 사실 세 가지 모순을 해결하기 위한 것입니다:

1. 기초(System Prompt) —— "비싸다"는 문제 해결

   • 모순: 시스템 설정(당신이 누구인지, 규칙은 무엇인지)이 가장 길지만, 매번 보내야 합니다.
   • 해결책: 가장 아래층에 배치하고, KV Cache 기술을 활용하여 변경되지 않는 한 AI가 "전체를 암송"할 수 있게 합니다. 이후 수백 턴의 대화에서 이 부분의 계산 비용은 거의 0입니다.

2. 기둥(Task Context) —— "잊어버린다"는 문제 해결

   • 모순: 대화가 길어지면 AI가 처음의 작업 목표를 쉽게 잊어버립니다(예: "스네이크 게임을 작성하라").
   • 해결책: 등급별 보존 전략을 활용하여, 작업 목표를 두 번째 층에 "고정"합니다. 얼마나 많은 턴이 진행되든, 이 층은 절대 삭제되지 않아 AI가 초심을 잃지 않도록 합니다.

3. 최상층(Chat & RAG) —— "혼란스럽다"는 문제 해결

   • 모순: 새로운 대화도 있고, 검색한 자료도 있어서 섞이면 혼란스러워집니다.
   • 해결책:
     • 거실(대화): 슬라이딩 윈도우로 관리하며, 최근 5-10문장만 남깁니다.
     • 도서관(RAG): 자료는 사용 후 바로 제거되어 공간을 차지하지 않습니다.

8.3 실전 효과

Manus 팀이 이 아키텍처를 배포한 후, 효과는 즉각적이었습니다:

• 비용 절감: 기초가 "암기"되었기 때문에, 턴당 대화 비용이 84% 폭락했습니다.
• 속도 향상: AI가 매번 수천 자를 처음부터 읽지 않아도 되어, 평균 응답 시간이 8초에서 2초로 단축되었습니다.
• 정확도 향상: 핵심 정보가 "고정"되어, 대화하다 보면 자신의 역할을 잊어버리는 일이 다시는 없어졌습니다.

---

9. 실전 템플릿: 바로 베껴 쓰기

이 메커니즘이 어떻게 작동하는지 더 직관적으로 이해할 수 있도록, 전체 과정 시뮬레이션을 준비했습니다.

시나리오를 선택하고 "다음"을 클릭하여, 사용자 질문에서 AI 응답까지의 몇 초 동안 기억의 궁전이 어떻게 컨텍스트를 동적으로 불러오고, 조립하고, 정리하는지 살펴보세요.

📱 User view (Chat)

Help me write a Python snake game...

Step 1 / 5

🧠 AI view (Context Construction)

🏛️Layer 1: Foundation (System)KV Cached

System: You are a senior Python engineer...

📌Layer 2: Pillar (Task)Pinned

Task: Build a snake game with Pygame...

💬Layer 3: Living Room (Chat)Sliding

(No chat history yet)

📚Layer 4: Library (RAG)Temp

(No retrieval needed now)

💡 What happened in this step: Initialize: load the foundation (System) and task. Layers 1 and 2 are established.

📝 바로 가져다 쓸 수 있는 실전 설계

Manus와 유사한 시스템을 설계한다면, 프롬프트를 어떻게 작성할지만 고민하지 말고 시스템 아키텍처가 컨텍스트를 어떻게 스케줄링하는지에 더 주목하세요.

다음은 두 가지 클래식 시나리오의 시스템 설계 청사진으로, 프롬프트 설계와 코드 로직(의사 코드)을 포함합니다.

시나리오 1: 풀스택 엔지니어 Agent (장기 기억형)

핵심 과제: 작업 주기가 길어 원래의 요구사항과 프로젝트 배경을 쉽게 잊어버립니다. 해결 전략: System 층(신원) + Task 층(목표 고정) + Chat 층(슬라이딩 윈도우).

1. 시스템 프롬프트 (Layer 1 & 2)

# Layer 1: 신원 설정 (System Prompt) - 절대 변경되지 않음, KV Cache 활용
당신은 시니어 풀스택 엔지니어로서 Python과 Vue3에 능숙합니다.
코드 스타일:
- 변수 명명은 PEP8을 엄격히 준수
- 주요 로직에는 반드시 주석 포함
- 프로젝트 기존의 유틸리티 함수를 우선적으로 사용

# Layer 2: 작업 고정 (Task Context) - 작업 기간 동안 삭제 금지
현재 작업: 결제 모듈(payment_module) 리팩토링
핵심 제약 사항:
1. 기존 API 인터페이스 v1.0과 호환되어야 함
2. 데이터베이스 마이그레이션 스크립트는 멱등성을 보장해야 함
3. 마감: 이번 주 금요일

2. 컨텍스트 조립 로직 (의사 코드)

def build_engineer_context(user_input, chat_history, task_info):
    context = []

    # 1. 기초층: 신원 설정 (KV Cache 캐싱 활용)
    # 이 부분은 수백 턴의 대화에서 변하지 않으므로, 계산 비용이 거의 0
    context.append(SYSTEM_PROMPT)

    # 2. 기둥층: 작업 고정 (Pinned)
    # 대화가 아무리 길어져도, 이 부분은 항상 System 뒤에 삽입됨
    context.append(f"현재 작업: {task_info}")

    # 3. 검색층: 코드 조각 (RAG)
    # 사용자 질문에 따라 코드 저장소에서 관련 코드 검색
    relevant_code = search_codebase(user_input)
    if relevant_code:
        context.append(f"참고 코드:\n{relevant_code}")

    # 4. 상호작용층: 대화 이력 (Sliding Window)
    # 최근 10턴만 가져와서 컨텍스트 초과 방지
    recent_chat = chat_history[-10:]
    context.extend(recent_chat)

    # 5. 최신 입력
    context.append(user_input)

    return context

시나리오 2: 스마트 고객 서비스 Agent (정밀 응답형)

핵심 과제: 비용에 민감하며, 절대 잘못된 정보를 제공해서는 안 됩니다. 해결 전략: System 층(강력한 제약) + RAG 층(동적 주입).

1. 시스템 프롬프트 (Layer 1)

# Layer 1: 신원 설정 (System Prompt)
당신은 전문 전자상거래 고객 서비스 담당자입니다.
응답 원칙:
1. 부드럽고, 전문적이며, 간결한 어조
2. **절대 금지** 사실을 날조하지 말고, [참고자료]에 기반하여 답변
3. 자료에 답이 없다면, "죄송합니다만, 이 질문은 상담원 연결이 필요합니다"라고 직접 답변

2. 컨텍스트 조립 로직 (의사 코드)

def build_support_context(user_input):
    context = []

    # 1. 기초층: 신원 설정
    context.append(SYSTEM_PROMPT)

    # 2. 도서관층: 동적 검색 (RAG)
    # 고객 서비스 시나리오에서만 RAG가 중심 역할을 하며, 중간 위치에 배치
    docs = vector_db.search(user_input, top_k=3)

    context.append("【참고자료 시작】")
    for doc in docs:
        context.append(doc.content)
    context.append("【참고자료 끝】")

    # 3. 상호작용층: 아주 짧은 이력
    # 고객 서비스는 보통 오래된 기억이 필요하지 않으며, 최근 3턴만 유지
    context.extend(get_recent_chat(limit=3))

    context.append(user_input)

    return context

---

10. 용어 대조표

영문 용어	한국어 대조	설명
Context Window	컨텍스트 윈도우	모델이 한 번에 처리할 수 있는 텍스트의 최대 길이(입력 및 출력 포함). 제한을 초과하는 내용은 잘리거나 잊혀집니다.
Token	토큰	LLM이 텍스트를 처리하는 최소 단위. 일반적으로 1토큰은 약 0.75개의 영단어 또는 0.5개의 한자에 해당합니다. 과금과 윈도우 제한 모두 이 단위를 기준으로 합니다.
KV Cache	KV 캐시	이미 계산된 어텐션 키-값 쌍을 캐싱하여, 반복되는 프리픽스에 대한 중복 계산을 방지하는 추론 가속 기술입니다. 지연 시간과 비용을 크게 줄입니다.
RAG	검색 증강 생성	질문에 답하기 전에, 먼저 외부 지식 베이스에서 관련 정보를 검색하여 컨텍스트로 모델에 제공하여, 환각을 줄이고 지식의 경계를 확장합니다.
Sliding Window	슬라이딩 윈도우	가장 기본적인 컨텍스트 관리 전략. 윈도우 내 토큰 수를 일정하게 유지하며, 새 내용이 들어오면 가장 오래된 내용을 자동으로 제거합니다.
Lost in Middle	중간에서 길을 잃다	대규모 모델의 한계 중 하나. 연구에 따르면, 모델은 긴 컨텍스트의 시작과 끝 정보를 가장 잘 기억하고, 중간 부분의 정보를 쉽게 무시합니다.
System Prompt	시스템 프롬프트	대화의 가장 앞에 위치한 명령으로, 모델의 신원, 행동 규범, 응답 스타일 및 핵심 작업을 설정합니다.
Few-shot	퓨샷 학습	프롬프트에 몇 가지 "질문-답변" 예시를 제공하여, 모델이 작업 패턴과 출력 형식을 빠르게 이해하도록 돕습니다.
Chain of Thought	사고 연쇄	모델이 최종 답변을 제시하기 전에 먼저 추론 단계를 출력하도록 유도합니다. 이 방법은 복잡한 논리와 수학 문제를 해결하는 모델의 능력을 크게 향상시킵니다.
Hallucination	환각	모델이 그럴듯해 보이지만 실제로는 잘못되었거나 존재하지 않는 정보를 자신 있게 생성하는 현상입니다.
Embedding	임베딩	텍스트를 고차원 수치 벡터로 변환하는 기술. 의미적으로 유사한 텍스트는 벡터 공간에서 더 가까운 거리에 위치하며, 시맨틱 검색의 기초입니다.
Vector DB	벡터 데이터베이스	벡터 데이터를 저장하고 검색하는 데 특화된 데이터베이스. 유사도 검색을 통해 쿼리와 가장 일치하는 문서 조각을 빠르게 찾을 수 있습니다.
Temperature	온도	모델 출력의 무작위성을 제어하는 하이퍼파라미터. 값이 높을수록(예: 0.8) 출력이 더 다양하고 창의적이며, 낮을수록(예: 0.2) 더 확정적이고 엄격합니다.
TTFT	첫 토큰 지연 시간	Time to First Token, 즉 사용자가 요청을 보낸 후 모델이 첫 번째 토큰을 출력하기까지 소요되는 시간으로, 상호작용 경험을 측정하는 핵심 지표입니다.

---

요약: 컨텍스트 엔지니어링의 본질

Manus의 네 번의 재구성이 우리에게 알려줍니다:

실천적 관점에서: 많이 기억할수록 좋은 것이 아니라, 더 구조화되고 선택적으로 기억할수록 좋습니다.

비용 관점에서 보면:

• 대부분의 낭비는 고정된 프리픽스에 대한 중복 계산에서 발생하며, 프리픽스 안정화와 캐시 메커니즘을 통해 해결해야 합니다;
• 중요한 정보가 실수로 삭제되는 것은, 종종 "차별 없는" 슬라이딩 윈도우에서 비롯되며, 정보 등급화와 고정 전략을 통해 해결해야 합니다;
• 매우 긴 문서와 지식 베이스를 다룰 때, 단순히 컨텍스트 윈도우를 늘리는 것만으로는 비현실적이며, 반드시 검색과 압축 메커니즘을 결합해야 합니다.

목표는: 주어진 모델과 컨텍스트 상한선 안에서, 모든 토큰의 투입이 명확한 용도를 갖도록 하는 것입니다.