컨텍스트 관리

=> AI관련들 이동

AI 엔지니어링에서 컨텍스트를 관리하는 방법

LLM의 컨텍스트 윈도우가 계속 커지면서 한때는 가능한 많은 정보를 모델에게 제공하는 것이 좋은 방법처럼 여겨졌다.

하지만 AI Agent가 긴 시간 동안 작업하고 수많은 Tool을 호출하기 시작하면서 단순히 많은 정보를 제공하는 방식에는 한계가 있다는 것이 분명해지고 있다.

많은 Context
=
좋은 Context

는 아니다.

오히려 실제로 중요한 것은

현재 작업에 필요한 정보를
필요한 순간에
정확하게 제공하는 것

이다.

이러한 문제를 다루는 영역을 최근에는 컨텍스트 엔지니어링(Context Engineering)이라고 부른다.

과거의 Prompt Engineering이

"AI에게 어떻게 질문할 것인가?"

에 집중했다면 Context Engineering은 더 넓은 문제를 다룬다.

System Prompt
사용자 요청
대화 기록
관련 코드
문서
RAG 검색 결과
Ontology
Tool 설명
Tool 실행 결과
Agent Memory
작업 진행 상태

이 중에서 현재 모델이 무엇을 봐야 하는가를 설계하는 것이다.

AI Agent가 장시간 동작할수록 컨텍스트는 계속 증가하기 때문에 무엇을 추가할 것인지뿐만 아니라 무엇을 제거하고, 압축하고, 외부에 저장할 것인지도 중요해진다.

---

왜 컨텍스트 관리가 중요할까?

예를 들어 코드 Agent에게 새로운 기능 구현을 요청했다고 해보자.

관련 정보를 전부 넣는다면 다음과 같은 Context가 만들어질 수 있다.

README
전체 Architecture 문서
전체 API 문서
DB Schema 전체
Git History
관련 없는 Source Code
과거 Issue
모든 Test
Tool 실행 기록
이전 Agent 대화

정보가 많기 때문에 좋아 보일 수 있다.

하지만 실제 작업이

VIP 회원의 예약 취소 정책 수정

이라면 대부분의 정보는 필요하지 않을 수도 있다.

오히려 중요한 것은 다음 정도일 수 있다.

예약 Domain
회원 등급 정책
CancellationPolicy
관련 Service
관련 Test
현재 Architecture Rule

즉 문제는

정보 부족

만 있는 것이 아니다.

정보 과잉

도 문제가 된다.

불필요한 정보가 많아지면 모델이 중요한 정보에 집중하기 어려워지고, 오래된 정책이나 관련 없는 코드가 현재 판단에 영향을 줄 수도 있다.

따라서 Context Engineering의 핵심 목표는 단순한 토큰 절약이 아니다.

AI가 현재 판단에 필요한 정보를 최대한 정확하게 구성하는 것이다.

---

1. Context를 하나의 자원으로 생각한다

Context Window가 크다고 해서 무제한으로 사용하는 것이 좋은 것은 아니다.

AI가 사용할 수 있는 Context에는 일종의 Attention Budget이 있다고 생각할 수 있다.

Context

[중요한 요구사항]
[관련 코드]
[관련 테스트]
[관련 정책]

→ 높은 정보 밀도

반대로

Context

[README 전체]
[로그 10,000줄]
[관련 없는 코드]
[오래된 문서]
[중복된 Tool 결과]
[수십 개 예시]
[과거 대화 전체]

→ 낮은 정보 밀도

가 될 수도 있다.

따라서 Context를 구성할 때는

"넣을 수 있는가?"

보다

"지금 필요한가?"

를 먼저 판단해야 한다.

좋은 Context Engineering의 목표는

가장 많은 정보

가 아니라

가장 적은 양의
가장 의미 있는 정보

를 제공하는 것이다.

---

2. 모든 정보를 처음부터 넣지 않는다

Agent에게 필요한 정보를 처음부터 모두 제공하는 방식은 단순하지만 규모가 커지면 비효율적이다.

Task 시작
   ↓
관련 있을 것 같은 정보 전부 조회
   ↓
Context에 입력
   ↓
Agent 실행

대신 최근 Agent 구조에서는 필요한 순간에 정보를 가져오는 방식이 중요해지고 있다.

Task 시작
   ↓
최소 Context 제공
   ↓
Agent 판단
   ↓
추가 정보 필요
   ↓
검색 / Tool 호출
   ↓
관련 정보 추가

이를 Just-in-Time Context 방식으로 볼 수 있다.

예를 들어 Coding Agent에게 Repository 전체 코드를 넣지 않는다.

대신 처음에는

프로젝트 구조
현재 Task
Architecture Rule

정도만 제공한다.

Agent가

ReservationService가 필요하다.

고 판단하면 그때 해당 파일을 읽는다.

Task
 ↓
Repository 구조 탐색
 ↓
Reservation 관련 파일 발견
 ↓
관련 코드 조회
 ↓
관련 Test 조회
 ↓
수정

이 방식은 Agent가 필요한 정보를 단계적으로 발견하도록 만든다.

---

3. Progressive Disclosure를 활용한다

Just-in-Time Context와 연결되는 개념이 점진적 공개(Progressive Disclosure)다.

처음부터 모든 상세 정보를 보여주는 것이 아니라 필요한 단계에서 점점 더 자세한 정보를 제공한다.

예를 들어 다음과 같은 Repository가 있다고 하자.

src/

customer/
reservation/
payment/
notification/
admin/
analytics/

사용자의 요청이

VIP 예약 취소 정책 변경

이라면 처음에는

customer/
reservation/

만 탐색하면 된다.

이후 Agent가

취소 시 환불 정책도 영향을 받는다.

는 사실을 발견했을 때

payment/

를 추가로 탐색한다.

Task

 ↓

Customer
Reservation

 ↓

관련 코드 분석

 ↓

Payment 관계 발견

 ↓

Payment Context 추가

즉 Context를 한 번에 구성하는 것이 아니라 Agent의 작업 진행에 따라 점진적으로 확장한다.

---

4. RAG를 이용해 관련 정보를 검색한다

모든 문서나 지식을 Context에 넣을 수 없기 때문에 필요한 정보를 검색해서 가져오는 방법이 필요하다.

대표적인 방법이 RAG(Retrieval-Augmented Generation)다.

사용자 질문
    ↓
검색
    ↓
관련 문서
    ↓
Context
    ↓
LLM

예를 들어 사내 규정이 수천 개 존재한다면 전체 규정을 모델에게 전달할 필요는 없다.

"VIP 고객의 환불 정책"

이라는 질문에 대해 관련 문서만 검색한다.

회원 등급 정책
환불 정책
예약 취소 정책

그리고 해당 내용만 Context에 넣는다.

하지만 RAG를 사용하는 것만으로 Context 문제가 해결되는 것은 아니다.

검색 결과가 잘못되면

잘못된 검색
    ↓
잘못된 Context
    ↓
논리적인 추론
    ↓
잘못된 결과

가 만들어질 수 있다.

따라서 RAG 시스템에서는 다음도 함께 관리해야 한다.

검색 정확도
문서 최신성
문서 중복
검색 결과 개수
Ranking
Metadata
출처

---

5. Vector 검색만으로 해결하려 하지 않는다

Vector RAG는 의미적으로 비슷한 문서를 찾는 데 강점이 있다.

하지만 업무 관계가 복잡해지면 단순한 의미 유사도만으로 필요한 정보를 찾기 어려울 수 있다.

예를 들어

VIP 고객의 예약 취소 정책

이라는 요청이 있다고 하자.

Vector 검색은 비슷한 문장을 가진 문서를 찾는다.

하지만 업무 구조를 알고 있다면 다음 관계를 따라갈 수도 있다.

VIP
 ↓
Customer
 ↓
Reservation
 ↓
CancellationPolicy
 ↓
RefundPolicy

이때 온톨로지나 Knowledge Graph를 활용할 수 있다.

사용자 Intent
      ↓
관련 Entity
      ↓
Relation 탐색
      ↓
관련 Rule / Data
      ↓
Context 구성

즉

Vector Search

와

Ontology / Graph Search

는 경쟁 관계라기보다 함께 사용할 수 있다.

Vector Search
→ 의미적으로 관련된 정보 탐색

Ontology
→ 업무적으로 연결된 정보 탐색

둘을 조합하면 Context 구성의 정확도를 높일 수 있다.

---

6. 전체 Tool 결과를 계속 Context에 남기지 않는다

Agent는 작업하면서 수많은 Tool을 호출한다.

파일 읽기
검색
Git Diff
Test
Build
Database 조회
Web 검색
API 호출

문제는 Tool 결과를 계속 Context에 남기면 빠르게 Context가 커진다는 것이다.

예를 들어 테스트를 실행했다.

mvn test

3,284 lines output

Agent에게 정말 3,284줄 전체가 계속 필요할까?

대부분의 경우 필요한 정보는 다음 정도다.

Test Result

FAILED: 2

ReservationServiceTest
- VIP cancellation expected true but false

PaymentTest
- refund status mismatch

따라서

Raw Tool Output
      ↓
필요 정보 추출
      ↓
Context 유지

하는 방식이 좋다.

이미 작업이 끝난 오래된 Tool 결과는 Context에서 제거할 수도 있다.

Tool 호출
 ↓
결과 사용
 ↓
핵심 정보만 유지
 ↓
Raw 결과 제거

이는 장시간 동작하는 Agent에서 특히 중요하다.

---

7. Context Compaction을 사용한다

Agent가 장시간 작업하면 대화와 작업 기록이 계속 쌓인다.

Task
 ↓
파일 조회
 ↓
코드 수정
 ↓
Test
 ↓
오류
 ↓
수정
 ↓
추가 분석
 ↓
Test
 ↓
...

어느 순간 전체 기록을 계속 유지하는 것이 비효율적이 된다.

이때 사용할 수 있는 방법이 Context Compaction이다.

기존 Context를 요약해 필요한 정보만 남기는 것이다.

기존 Context

30,000 tokens

      ↓

Compaction

      ↓

현재 목표
중요 결정
수정된 파일
발견된 문제
남은 작업

      ↓

4,000 tokens

예를 들면 다음과 같이 남길 수 있다.

현재 목표
- VIP 예약 취소 정책 구현

결정 사항
- 일반회원 24시간
- VIP 2시간

수정 파일
- ReservationService.java
- CancellationPolicy.java

현재 문제
- PaymentTest 1건 실패

남은 작업
- 환불 정책 확인
- Regression Test 실행

이렇게 하면 Agent가 전체 대화를 기억하지 않아도 작업을 계속할 수 있다.

---

8. 중요한 정보는 Memory로 분리한다

모든 정보를 Context Window 안에 계속 유지할 필요는 없다.

장기간 유지해야 하는 정보는 외부 Memory로 분리할 수 있다.

Context
=
현재 작업에 필요한 Working Memory

Memory
=
나중에도 필요한 Persistent Information

예를 들어 Agent가 다음 사실을 발견했다고 하자.

Reservation 모듈에서는
Instant를 기준 시간 타입으로 사용한다.

현재 Context에만 존재하면 Context가 초기화되었을 때 사라진다.

따라서 다음과 같은 곳에 저장할 수 있다.

MEMORY.md
Project Notes
Vector DB
Database
Knowledge Graph

그리고 필요할 때 다시 조회한다.

Agent
 ↓
Memory 검색
 ↓
관련 정보만 Context에 복원

즉 Memory의 목적은 Context Window를 무한히 늘리는 것이 아니라 Context 밖에 정보를 저장하고 필요할 때 다시 가져오는 것이다.

---

9. 작업 상태와 지식을 구분한다

Context에는 서로 성격이 다른 정보가 섞여 들어온다.

예를 들어

예약 정책
현재 수정 파일
테스트 실패 결과
사용자 요구사항
Architecture Rule
다음 작업

이 모두를 하나의 대화 기록으로 관리하면 복잡해진다.

따라서 정보를 종류별로 나눌 수 있다.

Task State

현재 목표
현재 진행 단계
남은 작업

Domain Knowledge

예약 정책
회원 정책
환불 정책

Engineering Rule

Architecture
Coding Convention
Security Policy

Execution Result

Test 결과
Tool 결과
Error

이렇게 구분하면 Agent가 어떤 정보를 오래 유지해야 하는지 결정하기 쉬워진다.

---

10. Agent별 Context를 분리한다

Multi-Agent 시스템에서 모든 Agent에게 동일한 Context를 제공할 필요는 없다.

예를 들어

Planner Agent
Worker Agent
Reviewer Agent
Security Agent

가 있다고 하자.

Planner가 필요한 Context는

Task
Architecture
전체 진행 상황

정도일 수 있다.

반면 Worker는

현재 Sub Task
관련 Source
관련 Test

가 중요하다.

Reviewer는

Requirement
Diff
Test Result
Architecture Rule

정도면 충분할 수 있다.

따라서

모든 Agent

→ 전체 Context 공유

보다

Planner
→ 계획에 필요한 Context

Worker
→ 구현에 필요한 Context

Reviewer
→ 검증에 필요한 Context

로 분리하는 것이 효율적이다.

이를 통해 각 Agent가 자신의 역할에 필요한 정보에 집중할 수 있다.

---

11. Sub-Agent를 Context 격리 수단으로 사용할 수 있다

Sub-Agent는 단순히 작업을 병렬화하기 위한 도구만은 아니다.

Context를 분리하는 역할도 할 수 있다.

예를 들어 Main Agent가 다음 문제를 해결해야 한다.

대규모 시스템 구조 분석

하나의 Agent가 모든 코드를 읽으면 Context가 빠르게 커질 수 있다.

대신

Main Agent
   │
   ├─ Customer 분석 Agent
   ├─ Reservation 분석 Agent
   ├─ Payment 분석 Agent
   └─ Security 분석 Agent

로 분리할 수 있다.

각 Agent는 자신의 영역을 깊게 탐색한다.

Reservation Agent

40,000 tokens 탐색

        ↓

Main Agent에게

1,500 tokens 요약 전달

Main Agent는 모든 상세 Context를 직접 가지고 있을 필요가 없다.

상세 Context
→ Sub-Agent 내부

핵심 결과
→ Main Agent

이 방식은 복잡한 작업에서 Context 오염을 줄이는 데 도움이 된다.

---

12. Tool 자체도 Context 관점에서 설계한다

Tool은 단순히 기능만 수행하는 것이 아니다.

Tool의 설명과 반환값 역시 Context를 차지한다.

예를 들어 다음과 같은 Tool이 있다고 하자.

getRepositoryData()

호출하면

Repository 전체 정보
수천 개 파일 목록
Git Log
Branch
Commit
Issue
PR

를 모두 반환한다면 매우 비효율적이다.

대신 Tool을 목적별로 나눌 수 있다.

searchFiles(query)

readFile(path)

getGitDiff()

getRecentCommits()

그리고 반환 데이터 역시 필요한 정보만 제공한다.

Tool은
많은 데이터를 반환하는 것이 아니라
Agent의 다음 판단에 필요한 데이터를 반환한다.

Tool 설계 자체가 Context Engineering의 일부인 이유다.

---

13. Prompt에 모든 규칙을 넣지 않는다

Agent가 따라야 하는 규칙이 많아지면 모든 내용을 System Prompt에 넣고 싶어질 수 있다.

System Prompt

Architecture Rule 100개
Security Rule 100개
Coding Convention 50개
Domain Rule 100개
예외사항 80개

하지만 이 방식은 유지보수도 어렵고 Context도 크게 소비한다.

따라서 정보를 계층화하는 것이 좋다.

System Prompt

핵심 행동 원칙
      ↓
필요한 규칙 탐색 방법

그리고 상세한 규칙은 외부에서 관리한다.

ARCHITECTURE.md
SECURITY.md
DOMAIN.md
AGENTS.md
Ontology

Agent가 필요할 때 해당 규칙을 조회하도록 한다.

즉

모든 지식을 Prompt에 넣는다.

가 아니라

지식을 어디에서 찾을 수 있는지를 알려준다.

는 방향이다.

---

14. 현재 Context와 기준 문서를 구분한다

Context에는 임시 정보와 장기적인 기준이 동시에 들어간다.

예를 들어

현재 Test 실패

는 잠깐 필요한 정보다.

반면

Controller는 Repository를 직접 호출하지 않는다.

는 프로젝트 전체에서 유지되어야 하는 규칙이다.

두 정보를 동일하게 관리하면 중요한 기준이 오래된 Tool 결과 속에 묻힐 수 있다.

따라서

Stable Context

Architecture
Security Rule
Domain Model
Ontology

와

Dynamic Context

현재 Task
Tool Result
Error
진행 상태

를 구분할 수 있다.

그리고 Dynamic Context는 작업 진행에 따라 계속 교체한다.

---

15. 정보의 최신성을 관리한다

관련성이 높은 정보라도 오래된 정보라면 오히려 문제를 만들 수 있다.

예를 들어

CancellationPolicy.md

작성일: 2025

와

CancellationPolicy-v2.md

작성일: 2026

가 동시에 존재한다고 해보자.

Agent가 이전 문서를 사용하면 잘못된 기능을 구현할 수 있다.

따라서 Context를 가져올 때

관련성
+
최신성
+
신뢰도

를 함께 고려해야 한다.

Metadata를 활용할 수도 있다.

document

version = 3
updated_at = 2026-08-20
status = ACTIVE
owner = ReservationTeam

그리고 오래된 문서는

status = DEPRECATED

처럼 명확하게 표시한다.

Context Engineering에서는 무엇을 가져오는가뿐만 아니라 어떤 버전의 정보를 가져오는가도 중요하다.

---

16. 중복 정보를 제거한다

동일한 내용이 여러 형태로 Context에 들어오는 경우가 많다.

README
Architecture 문서
Wiki
PR 설명
System Prompt
Agent Memory

모두 다음 내용을 포함하고 있을 수 있다.

Controller에서 Repository 직접 호출 금지

정보 자체는 중요하지만 동일한 내용이 반복되면 Context를 낭비한다.

더 심각한 문제는 서로 조금씩 다른 버전이 존재하는 경우다.

문서 A
VIP 취소 제한 = 2시간

문서 B
VIP 취소 제한 = 3시간

이 경우 단순한 정보량 문제가 아니라 Context 충돌이 발생한다.

따라서

Single Source of Truth

를 정하고 중복된 정보를 최소화하는 것이 좋다.

---

17. Context Priority를 정한다

모든 정보가 동일한 중요도를 가지는 것은 아니다.

예를 들어 다음 Context가 있다고 하자.

사용자 요구사항
Architecture Rule
관련 Source
관련 Test
과거 Git Commit
일반 README

우선순위를 정하면 다음과 같이 볼 수 있다.

1. 현재 사용자 요구사항
2. 보안 / 정책 / Architecture Rule
3. 관련 Source / Test
4. Domain Knowledge
5. 과거 기록
6. 참고 자료

Agent가 Context를 압축하거나 일부를 제거해야 할 때 이 우선순위를 사용할 수 있다.

Context 부족
      ↓
낮은 Priority 정보 제거
      ↓
핵심 정보 유지

이런 기준이 없으면 중요한 요구사항이 오래된 Tool 결과와 함께 사라질 수 있다.

---

18. Context Budget을 작업별로 관리한다

모든 작업에 동일한 양의 Context가 필요한 것은 아니다.

오타 수정

에 Repository 전체 Context는 필요하지 않다.

반면

Authentication 구조 변경

같은 작업은 더 많은 Context가 필요할 수 있다.

따라서 작업의 복잡도에 따라 Context Budget을 다르게 설정할 수 있다.

간단한 Task

Task
관련 파일
관련 Test

→ 작은 Context

복잡한 Task

Task
Architecture
Domain
관련 Source
관련 Test
관련 Dependency
Security Rule

→ 큰 Context

즉 Context도 CPU나 Memory처럼 작업에 따라 할당하는 Resource라고 볼 수 있다.

---

19. 실패한 작업에서 Context 문제를 찾아야 한다

Agent가 잘못된 결과를 만들었을 때 모델 성능만 문제라고 판단해서는 안 된다.

실패 원인이 Context일 수도 있다.

Agent 실패
   ↓
왜 실패했는가?

Model 추론 오류?

Context 누락?

잘못된 문서?

오래된 문서?

검색 실패?

너무 많은 불필요한 정보?

서로 충돌하는 규칙?

따라서 Eval이나 Observability를 이용해 Agent가 실제로 어떤 Context를 사용했는지 확인할 수 있어야 한다.

예를 들어

Expected

VIP 취소 = 2시간

인데 Agent가

VIP 취소 = 3시간

으로 구현했다.

Trace를 확인해보니

CancellationPolicy-OLD.md

를 검색했다면 문제는 모델이 아니라 Context Retrieval에 있다.

이렇게 실패 원인을 구분해야 시스템을 제대로 개선할 수 있다.

---

20. Context Engineering도 Eval 대상이 되어야 한다

Context 구성을 변경했다고 해서 반드시 Agent 성능이 좋아지는 것은 아니다.

예를 들어

검색 문서 10개
→ 5개로 감소

시켰다고 하자.

토큰은 줄었지만 중요한 문서를 놓칠 수도 있다.

따라서 Context 전략을 변경할 때도 평가해야 한다.

Context 전략 A

Accuracy 92%
Cost $0.40
Latency 8s

Context 전략 B

Accuracy 95%
Cost $0.28
Latency 6s

이런 식으로 비교할 수 있다.

측정할 수 있는 지표는 다음과 같다.

Task 성공률
Retrieval 정확도
Context Token 수
불필요한 Context 비율
누락된 정보 비율
Latency
Model 호출 비용
재시도 횟수

즉 Context Engineering은 단순한 최적화 기법이 아니라 성능에 직접 영향을 주는 시스템 구성 요소이므로 Eval과 함께 관리해야 한다.

---

Context 관리의 전체 구조

AI Agent에서 Context를 관리하는 흐름을 정리하면 다음과 같다.

                  사용자 요청
                       ↓

                 최소 기본 Context

          Task / 핵심 규칙 / 현재 상태

                       ↓

                    Agent

                       ↓

               추가 정보 필요

                       ↓

     ┌────────────────────────────┐
     │                            │
   Vector RAG                Ontology
     │                            │
   문서 검색                  관계 탐색
     │                            │
     └────────────┬───────────────┘
                  ↓

              관련 정보 추가

                  ↓

               Tool 실행

                  ↓

           Tool 결과 정제 / 요약

                  ↓

              Agent 판단

                  ↓

       ┌──────────┴──────────┐
       │                     │
     작업 계속             작업 완료
       │
       ↓
 Context 증가

       ↓

Compaction / Memory / Pruning

       ↓

필요한 정보만 유지

실제로 활용할 수 있는 방법을 정리하면 다음과 같다.

• 최소 Context 구성
• Just-in-Time Retrieval
• Progressive Disclosure
• Vector RAG
• Graph RAG
• Ontology
• Metadata Filtering
• Tool Result Pruning
• Context Compaction
• Summary
• Agent Memory
• Structured Note
• Task State 관리
• Multi-Agent Context 분리
• Sub-Agent
• Tool 반환값 최적화
• Single Source of Truth
• Context Priority
• Context Budget
• Version 관리
• Context Eval

결국 AI 엔지니어링에서 Context Engineering의 핵심은 더 많은 정보를 모델에게 제공하는 것이 아니다.

AI가 현재 작업을 수행하는 데 필요한 정보를

필요한 순간에
필요한 만큼
신뢰할 수 있는 형태로

제공하는 것이다.

모델의 Context Window가 아무리 커지더라도 프로젝트의 모든 코드, 문서, 로그, Tool 결과를 항상 넣는 것은 좋은 방법이 될 수 없다.

오히려 Agent가 필요한 정보를 스스로 찾고, 중요하지 않은 정보는 버리고, 장기적으로 필요한 정보는 Memory에 저장하고, 현재 작업에 필요한 정보만 Working Context에 유지하도록 만드는 것이 중요하다.

결국 Context Engineering은

"AI에게 무엇을 알려줄 것인가"

뿐만 아니라

"언제 알려줄 것인가, 무엇을 기억하게 할 것인가, 무엇을 버리게 할 것인가"

까지 설계하는 영역이라고 볼 수 있다.

이 방향은 현재 에이전트 설계 흐름과도 잘 맞습니다. Anthropic은 **Just-in-Time 검색, 점진적 정보 탐색, 컨텍스트 압축, 외부 메모리, 서브에이전트를 통한 컨텍스트 격리**를 주요 방법으로 정리하고 있고, Tool 자체도 반환 토큰을 최소화하도록 설계할 것을 강조합니다.