Context Engineering 알아보기

 

1. Context Engineering 정의

 

Context Engineering은 에이전트가 매 단계마다 필요한 정보만을 적절히 선택, 압축, 저장, 격리해서 LLM의 컨텍스트 윈도우에 넣는 전략적 시스템 설계 작업입니다 marktechpost.com+13blog.langchain.com+13medium.com+13.

 

LangChain에서 제안하는 네 가지 핵심 전략:

• Write: 정보를 외부 스크래치패드나 메모리에 기록
• Select: 필요한 정보를 필요할 때 컨텍스트로 불러오기
• Compress: 긴 기록은 요약 등으로 축소
• Isolate: 서로 다른 주제는 분리 저장 등 llmmultiagents.comblog.langchain.com

 

2. 필요성 및 기존 문제

• LLM의 컨텍스트 윈도우 한계로 긴 멀티턴 대화 시 정보 손실
• Costs/Latency 증가, hallucination, context poisoning/distraction/confusion/clash 등의 문제 blog.langchain.com
• LangChain 등에서는 “context engineering이 에이전트 설계에서 가장 중요한 업무(#1 job)”이라고 강조 youtube.com+15blog.langchain.com+15blog.langchain.com+15

 

3. Prompt Engineering vs Context Engineering 비교

 

 

항목	Prompt Engineering	Context Engineering
범위	단일 입력·출력	전체 시스템 흐름, 메모리, 도구 통합
지속성	일회성	멀티턴, 세션 또는 장기 메모리
목표	명확한 지시	정황 환경 구성/상태 유지
기술	문장 조정, 예시, few-shot	RAG, 스크래치패드, 동적 데이터, 툴 체인 (medium.com, blog.langchain.com)
스케일	소규모 테스트	실전 시스템, 다양한 유저 및 플로우

 

핵심 관계: Prompt Engineering은 Context Engineering의 하위 범주이며, 문장 디자인은 컨텍스트 기반에서 이루어져야 효과적

 

 

 

4. 구체 사례 및 실습 전략

LangChain에서 제안하는 에이전트 내 컨텍스트 관리 전략:

1. Write: 스크래치패드, 메모리에 중요한 결정, 플랜 저장
2. Select: 상태 업데이트 시 필요한 메모리 불러오기
3. Compress: history 요약해서 컨텍스트 절약
4. Isolate: 주제별 정보 분리

 

🔧 1. Write – 컨텍스트를 '어디에' 남길 것인가?

✅ 정의

사용자가 말한 중요한 내용을 에이전트가 직접 기억할 수 없기 때문에, 이를 외부 메모리(예: Dict, DB, Vector Store 등)에 명시적으로 기록하는 전략입니다.
→ 꼭 필요한 사실을 ‘수첩에 적는다’는 개념입니다.

🧠 왜 중요한가?

"에이전트가 말을 잘해도 금방 까먹으면, 결국 다시 설명해야 합니다."

• LLM은 이전 대화의 맥락을 계속 기억하지 않습니다.
• 사용자가 말한 기준, 선호, 제약조건을 적어두지 않으면,
  다음 대화에서 에이전트가 엉뚱한 답을 주거나, 중복 질문을 하게 됩니다.
• 특히 멀티턴 대화나 도구 호출, 복잡한 계획이 필요한 에이전트에서는 초기에 들은 내용을 반드시 기록해야 합니다.

 

💡 예시 (여행 추천 에이전트 기준)

사용자의 말

"저는 시끄러운 관광지는 싫고, 한적한 동네에서 산책하는 걸 좋아해요."

잘못된 경우 (Write 없이 진행)

• 몇 분 뒤 추천:
  "명동 쇼핑 거리, 경복궁, 남산 타워 코스 추천해드릴게요!"
  → 🤦 사용자의 ‘조용한 장소 선호’ 조건이 무시됨

올바른 흐름 (Write 적용)

1. 사용자가 말한 '조용한 동네 선호'를 메모리에 기록
2. 이후 추천에서 "서촌 골목, 북촌 한옥길, 안국동 산책로"처럼 기억을 반영한 맞춤 추천

 

💥 핵심 요점 요약

질문	답변
언제 쓰나?	사용자가 ‘중요한 기준, 조건, 선호’를 말했을 때 바로
어디에 기록하나?	LangChain에서는 Memory, Dict, Scratchpad, Vector Store 등
안 쓰면 어떻게 되나?	에이전트가 금방 잊어버리고 ‘헛소리’를 하기 시작함
어떤 정보가 대상인가?	선호도, 제약조건, 선택된 옵션, 완료된 작업 결과 등

 

---

🔍 2. Select –  기억을 다 보여줄 필요는 없다. 필요한 것만 꺼내라

✅ 정의

에이전트가 이전에 기록해 둔 많은 정보들 중에서, 지금 대화에 꼭 필요한 정보만 선별해서 LLM에게 전달하는 전략입니다.
→ 모든 걸 주면 산만해지고, 핵심만 보여줘야 정확한 답이 나옵니다.

🧠 왜 중요한가?

"기억은 많을수록 좋지만, 한 번에 다 꺼내면 오히려 말이 꼬입니다."

• GPT는 긴 대화, 많은 기록을 모두 집어넣으면:
  • 비용(Token) 증가
  • 답변 정확도 하락 (혼란, 헷갈림)
  • irrelevant info로 인해 핵심을 놓침
• 마치 회의할 때, 지난 3달치 회의록을 다 읽어주는 사람처럼 됩니다.

💡 예시 (여행 일정 추천 시나리오)

상황: 이미 여러 정보를 저장한 상태

• “혼잡한 장소 싫어해요”
• “하루 예산은 15만 원이 한계예요”
• “한식 좋아하고 일식은 별로예요”
• “도보 이동이 편해요, 많이 걷는 건 힘들어요”

사용자의 새 요청

"맛집 중심의 여행지를 추천해줘."

❌ 잘못된 경우 (Select 없이 모든 메모를 통째로 입력)

• GPT 입력 예: 위 4개의 조건 + 지난 10턴 대화 전체
• 출력 예시:
  "이동 편한 관광지 위주로 추천드리겠습니다. 경복궁, 북촌, 인사동 등"
  → 🤦 문제: 맛집 조건은 약하게 반영되고, 걷기 관련 정보가 과도하게 영향

✅ 올바른 경우 (Select 적용)

• GPT 입력 예:
  "사용자는 한식 선호, 일식 비선호 → 한식 위주 맛집 추천 필요"
• 출력 예시:
  "서울 종로구의 전통 한정식 코스 맛집 3곳을 추천드립니다."

💥 핵심 요점 요약

질문	답변
언제 쓰나?	사용자가 새로운 요청을 했을 때, 관련된 이전 정보만 꺼내서 줄 때
왜 필요한가?	GPT에게 불필요한 정보까지 다 주면 정확도가 떨어지고 비용도 늘어남
어떤 정보만 꺼내야 하나?	현재 질문과 관련된 요구사항, 제약조건, 선호도 등
무엇을 쓰나?	조건 필터링, 태그 기반 메모리 조회, Vector Similarity 등 다양한 방법 사용 가능

---

🪶 3. Compress – 너무 많으면 요약하자, 핵심만 남겨라

✅ 정의

에이전트가 기억하고 있는 긴 기록(history)이나 복잡한 출력 결과를, 핵심 정보만 남겨 요약하거나 정제해서 LLM에게 전달하는 전략입니다.
→ 말하자면, "10분 회의 내용을 30초 요약으로 전달하는 기술"입니다.

 

🧠 왜 중요한가?

• 긴 기록을 그대로 LLM에 넣으면:
  • Token 초과 → 답변 거부 또는 비싼 비용
  • GPT가 핵심을 못 잡고 어중간한 답을 내놓음
• 특히 멀티턴 대화, 툴 호출 결과, 계획 리스트 같은 것은 압축이 필수

💡 예시 (여행 일정 추천 시나리오)

상황

사용자가 10턴에 걸쳐 다음과 같은 요구를 말함:

• "저는 서울에서 이틀 여행하고 싶어요."
• "사람이 적은 곳을 좋아해요."
• "한옥마을은 좋았는데 너무 걸어서 피곤했어요."
• "한식보다는 중식을 좋아해요."
• "예산은 하루 15만 원까지요."

이걸 그대로 GPT에 넣으면:

• 총 1000 tokens 이상
• GPT가 혼란스럽고, 중복 또는 비일관된 추천을 함

✅ Compress 적용한 경우

요약 예시:

"서울 2일 여행 계획: 조용한 장소 선호, 중식 선호, 걷기 제약, 예산 15만 원"

→ GPT는 요약된 핵심 조건만 보고 명확한 추천 가능

 

💥 핵심 요점 요약

질문	답변
언제 쓰나?	대화가 길어지거나, 툴 호출 결과가 너무 많을 때
왜 중요한가?	LLM이 핵심만 보고 판단해야 실수도 줄고 비용도 절감됨
무엇을 줄이나?	대화 기록, 툴 결과, 리스트, 의사결정 과정
어떻게 줄이나?	GPT를 써서 요약하거나, rule-based 방식으로 요약 또는 추출

---

🧱 4. Isolate – '서로 다른 주제'는 분리해야 한다

✅ 정의

하나의 사용자와 여러 주제를 동시에 다룰 때, 정보가 섞이지 않도록 각 주제별로 따로 나누어 저장하고, 사용할 때도 명확히 구분해서 불러오는 전략입니다.
→ ‘여행 이야기’와 ‘보험 이야기’를 같은 노트에 섞어 쓰지 않는 것과 같습니다.

 

🧠 왜 중요한가?

"기억을 잘해도, 잘못된 걸 같이 기억하면 더 큰 문제가 생깁니다."

• LLM 기반 에이전트는 모든 걸 연결하려는 경향이 있습니다
• 서로 관련 없는 주제 정보가 하나의 컨텍스트에 섞이면:
  • GPT가 불필요하게 연관을 만들어냄
  • 사용자에게 혼란스러운 답변을 하게 됨
• 특히 멀티 도메인 에이전트에서 필수 전략

💡 예시

사용자 메시지:

"서울 여행 추천 좀 해줘.
그리고 내 보험 만기일도 확인해줘."

❌ 잘못된 경우 (하나의 메모리에 저장, 구분 없음)

• GPT 입력:→ 🤦 여행 추천에 보험 얘기가 섞임 = 의도치 않은 연관 오류
• 사용자: 서울 여행 → 조용한 장소 원함 사용자: 보험 → 3개월 후 만기 예정 GPT: 서울 여행 시 만기 보험 보장 여부도 고려해볼까요?

✅ 올바른 경우 (Isolate 전략 적용)

• 여행 정보는 → travel_context
• 보험 정보는 → insurance_context
• GPT에 입력할 때도 각각 따로 구성
• 결과:
  • 여행 추천은: “북촌 한옥마을, 안국동 산책 코스 등”
  • 보험 알림은: “OO 생명보험이 3개월 뒤 만기됩니다”

💥 핵심 요점 요약

질문	답변
언제 쓰나?	사용자가 서로 다른 주제를 동시에 요청할 때
왜 중요한가?	정보가 섞이면 GPT가 연관성 없는 내용을 엮어서 이상한 답변을 만듦
어떻게 분리하나?	메모리 구조를 주제별로 나누거나, 아예 에이전트를 다르게 설계
구현 방법 예시	context_type="travel" vs context_type="insurance" 또는 LangGraph에서 다른 상태 블록 사용

 

---

🔁 요약: 왜 이 4가지가 핵심인가?

 

전략	핵심 질문	기능
Write	기억해야 할 건 뭐지?	중요한 정보 기록
Select	지금 쓸 건 뭐지?	필요한 정보만 추출
Compress	너무 길면 어떻게 하지?	요약해서 핵심만 전달
Isolate	주제 섞이면 안 되지 않을까?	서로 다른 주제 분리 저장

 

 

이 네 가지 전략은 단순한 메모리 관리가 아니라, “LLM의 뇌와 환경 사이를 설계하는 시스템 공학”입니다. Prompt engineering이 “무엇을 말할까”에 집중한다면, context engineering은 “말하는 배경, 기억, 주제, 시간 흐름 전체”를 책임지는 환경 설계자의 역할이라고 볼 수 있습니다.

 

 

 

 

5. 회의적 질문

• “프롬프트 문장만 잘 짜면 되지, 왜 이런 복잡한 컨텍스트 관리를 해야 하는가?”
  → 복잡 멀티턴 시, 단순 prompt는 context window 초과, memory drift 등으로 신뢰성 깨짐
• “Prompt engineering이 여전히 중요하지 않나?”
  → 물론 중요하지만, 컨텍스트 환경이 견고하지 않으면 prompt 설계가 묻혀버림 arxiv.org+14medium.com+14blog.langchain.com+14

 

6. 요약 및 가이드

• Context Engineering = LLM 에이전트가 장기적으로 정확하고 일관된 행동을 하도록 환경을 설계하는 시스템 공학
• Prompt Engineering은 그 환경 안에서 순간적인 지시를 효과적으로 표현하는 작업
• 둘은 상호 보완 관계: 컨텍스트가 확보되어야 prompt가 더 명확하게 작동
• 실전 블로그 구성 예시:
  1. 개념 정의
  2. 필요성 문제
  3. 관계 비교
  4. 사례 실습
  5. 회의적 쟁점
  6. 결론 + 다음 단계

 

 

 

출처

No	명	URL
1	Context Engineering Guide	https://nlp.elvissaravia.com/p/context-engineering-guide
2	context-engineering-for-agents	https://blog.langchain.com/context-engineering-for-agents/
3	EP 58. 컨텍스트 엔지니어링은 '목발'이다? Noam Brown 팟캐스트 읽어보기	https://www.youtube.com/watch?v=9yAkW-WgiWk&ab_channel=%EB%85%B8%EC%A0%95%EC%84%9D
4	[프롬프트 강의] 프롬프트 엔지니어링과 컨텍스트 엔지니어링	https://www.youtube.com/watch?v=CeZPsKo1nXw&ab_channel=%ED%94%84%EB%A1%AC%EC%88%98%EC%A7%84