RUDA DIRECTOR · AI Agent — 30 DAYS / 90 ARTICLES · Day 02 · Learn 03
30초 답변: AI Agent의 Context는 저장된 모든 기록이 아니라, Model이 이번 Turn의 다음 Decision을 내릴 때 실제로 볼 수 있도록 조립한 정보의 working set이다. 좋은 Context 설계는 더 많이 넣는 일이 아니라, 다음 결정을 바꿀 정보만 남기고 원본 State·Memory·Session은 별도 계층에서 관리하는 일이다.
Context는 전체 기록이 아니라 이번 Decision의 입력이다
Anthropic은 Context를 LLM이 추론할 때 포함되는 Token 집합으로 설명하고, Context Engineering을 그 Token 집합을 선별·유지하는 작업으로 정의한다. OpenAI도 Context Window를 한 번의 요청에서 사용할 수 있는 최대 Token 범위로 설명하며, 입력·출력과 일부 Model의 reasoning token이 같은 한도 안에 들어간다고 명시한다.
여기서 중요한 경계가 있다. Context Window는 용량이고, Context는 그 용량 안에 실제로 넣은 내용이다. 창이 크다고 모든 기록을 넣어야 하는 것은 아니다. Agent Loop가 길어질수록 사용자 메시지, Tool Definition, Tool Result, 중간 상태, 검색 문서가 계속 쌓인다. 다음 Decision과 무관한 정보까지 전달하면 Token Cost와 Latency가 늘고, 중요한 신호가 다른 정보와 경쟁한다.
설계 원칙: “나중에 쓸지도 모른다”가 아니라 “이 정보가 지금의 다음 Action을 바꿀 수 있는가?”를 Context 포함 기준으로 삼아라.
Context, Session, Memory, State는 같은 것이 아니다
| 개념 | 무엇을 뜻하는가 | Model이 항상 보는가 | 대표적인 설계 질문 |
|---|---|---|---|
| Context | 이번 Model Call에 조립된 메시지·지시·Tool 정보·선별된 근거 | LLM-visible Context라면 그렇다 | 다음 Decision에 무엇이 필요한가? |
| Context Window | 한 요청이 사용할 수 있는 Token 용량 | 내용이 아니라 한도다 | 입력과 출력 여유를 얼마나 남길까? |
| Session | 여러 Turn을 하나의 대화 단위로 묶고 이력을 이어 가는 컨테이너 | 구현에 따라 이력이 다시 주입된다 | 어떤 대화를 같은 범위로 볼까? |
| Memory | 정보를 지속 저장하고 필요할 때 검색·갱신하는 메커니즘 | 검색되어 Context에 들어올 때만 본다 | 무엇을 언제 저장하고 다시 불러올까? |
| State | 업무와 외부 세계의 현재 사실·진행 상태 | 필요한 일부만 보여 주는 편이 안전하다 | 진실의 원본은 어디에 둘까? |
OpenAI Agents SDK는 “Context”라는 말이 두 의미로 쓰인다고 구분한다. Local Context는 Tool이나 callback이 쓰는 ID, dependency, approval state 같은 application-side 데이터이고 Model에 자동으로 전달되지 않는다. 반면 Agent/LLM Context는 Model이 응답을 생성할 때 실제로 보는 정보다. Secret, credential, 권한 객체를 Model에게 보일 이유가 없다면 Local Context에 두고 Tool 내부에서 강제해야 한다.
Session도 Memory와 동일하지 않다. OpenAI Agents SDK의 Session은 특정 Session의 대화 이력을 저장하고 다음 Run 전에 불러오는 client-side memory 기능이다. 그러나 “이력을 저장했다”와 “다음 Decision에 필요한 사실을 정확히 검색했다”는 다른 문제다. 긴 Session 전체를 그대로 주입하는 방식은 Memory의 write·retrieve·expiry 정책을 대신하지 못한다.
Mechanism: Context는 매 Turn 다시 조립된다
RAW SOURCES
User input · Instructions · State · Session · Memory · Tool Result
↓
SELECT / RETRIEVE
현재 Goal과 Decision에 필요한 정보만 선택
↓
CONTEXT ASSEMBLY
제약 · 진행 상태 · 근거 · 사용 가능한 Tool · Stop Condition
↓
MODEL DECISION
Answer · Tool Call · Clarification · Stop
↓
RUNTIME
검증 · 권한 판단 · 실행 · State 갱신
↓
PERSIST
구조화 State · Source pointer · 필요한 Memory · Compact summary
↺ 다음 Turn
이 flow에서 Context Builder는 단순한 문자열 연결기가 아니다. 현재 Goal, 변하지 않는 제약, 최신 State, 관련 근거, 직전 Tool Result, 남은 불확실성을 우선순위에 따라 조립한다. 반대로 원본 로그 전체, 중복된 Tool 설명, 오래된 요약, 현재 결정과 무관한 사용자 정보는 제외한다. 무엇을 넣었는지뿐 아니라 어떤 Source의 어느 version을 근거로 넣었는지도 Trace에 남겨야 갱신과 디버깅이 가능하다.
Worked Example: 중복 결제 조사의 Context를 조립하는 법
아래는 구조를 설명하기 위한 가상 Trace다. 실제 운영 기록, 고객 사례, 성능 실험이 아니다.
User가 “같은 주문이 두 번 결제된 것 같아. 환불 가능한지 확인해 줘”라고 요청했다고 하자. System에는 200개의 상담 댓글, 4만 줄의 결제 로그, 세 건의 거래, 환불 정책 문서, 계정 권한 상태가 있다. 이 전부를 Model에 넣는 것이 아니라, 다음 Decision인 “실제 중복 거래인가?”를 판정하는 데 필요한 working set을 만든다.
| Step | 들어오는 State / Evidence | Context에 남기는 것 | 다음 Decision |
|---|---|---|---|
| 1 | 주문 ID와 계정 ID | 현재 Goal, tenant 범위, 조회 전용 권한 | 어떤 거래를 조회할까? |
| 2 | 거래 3건과 4만 줄 로그 | 거래 ID·금액·시각·상태, 관련 로그 구간의 Source pointer | 중복 후보는 어느 두 건인가? |
| 3 | 환불 정책 v7 | 적용 조건, 예외, 문서 version과 확인 시각 | 정책상 환불 가능한가? |
| 4 | 중복 후보 2건 확정 | 판정 근거, 미해결 항목, refund는 아직 미실행 | 추가 확인 또는 Approval이 필요한가? |
| 5 | 사용자 Approval 상태 | 승인 여부와 허용된 Action만 | 환불 요청을 실행할까, 중단할까? |
상담 댓글 200개는 필요할 때 검색할 수 있는 Session/Memory 쪽에 남기고, 원본 로그는 Observability 저장소에 둔다. Model에는 결론을 바꿀 수 있는 거래 필드와 근거 위치만 전달한다. Turn이 끝나면 case_id, 후보 거래 ID, 확인한 정책 version, Tool Call 상태, Approval 상태를 구조화 State로 저장한다. 자연어 요약은 보조물이고, 금액·권한·실행 상태의 Source of Truth가 되어서는 안 된다.
Context 설계가 실패하는 5가지 방식
1. 전체 Transcript를 매번 붙인다
초기에는 구현이 쉽지만 Turn이 늘수록 입력 Token, Latency, Cost가 함께 증가한다. Anthropic은 Context를 유한한 자원으로 보고, Token이 늘어날수록 중요한 정보 회수와 장거리 추론의 정밀도가 저하될 수 있다고 설명한다. 긴 기록은 저장하되, 이번 Decision에 필요한 부분만 검색하거나 압축해야 한다.
2. 요약문을 원본 State처럼 믿는다
요약은 조건, 예외, 숫자, 미해결 항목을 떨어뜨릴 수 있다. Source pointer와 version 없이 요약만 다음 Turn에 넘기면 왜 그런 결론이 났는지 확인하기 어렵다. 구조화 State와 원본 근거를 유지하고, 요약은 재구성 가능한 index로 취급해야 한다.
3. Tool Result 원문을 그대로 쏟아 넣는다
API 응답의 모든 field와 raw log는 대부분 다음 Decision에 필요하지 않다. 불필요한 Token을 쓰고, 외부 문서에 포함된 지시문이나 민감 정보까지 LLM-visible Context로 유입될 수 있다. Tool adapter에서 allowlist field, 길이 제한, provenance, 신뢰 수준을 구조화해 반환하는 편이 낫다.
4. Local Context와 LLM Context를 섞는다
Database handle, credential, 내부 permission object는 Tool 실행에 필요할 수 있지만 Model의 판단 입력일 필요는 없다. 둘을 섞으면 비밀 노출과 과도한 권한 추론의 surface가 넓어진다. Model에는 허용된 Capability와 필요한 결과만 보여 주고, 실제 Authorization은 Runtime에서 검증한다.
5. Compaction 뒤 제약과 미완료 작업을 잃는다
OpenAI의 Compaction은 긴 Context Window를 더 적은 Token의 다음 Context로 바꾸는 메커니즘을 제공한다. 하지만 자체 요약을 만들든 공식 기능을 쓰든, 현재 Goal·금지 조건·완료된 Action·미완료 항목·Source pointer가 보존되는지 검증해야 한다. “짧아졌다”는 사실만으로 안전한 Context가 되지는 않는다.
세 가지 Context 전략의 Trade-off
| 전략 | Quality / Reliability | Latency / Cost | Observability | Complexity / Failure Surface |
|---|---|---|---|---|
| 전체 이력 주입 | 원본 보존은 높지만 신호 경쟁이 커진다 | 가장 빠르게 증가 | 원문은 있으나 실제 근거 식별이 어렵다 | 초기 구현은 단순, 규모가 커지면 취약 |
| 요약만 주입 | 핵심 누락·왜곡 위험 | 낮음 | Source pointer가 없으면 낮음 | 요약 갱신·검증 규칙 필요 |
| 구조화 State + 선택 근거 | 결정에 필요한 신호와 원본 추적을 함께 유지 | 선별 비용은 있지만 예측 가능 | 포함 근거와 version을 기록하기 쉬움 | Context Builder와 retrieval 정책 필요 |
기본값은 세 번째 전략이다. 먼저 결정론적 State store와 단순한 선택 규칙으로 시작하고, 자료 규모와 검색 요구가 실제로 커질 때 retrieval이나 장기 Memory를 추가한다. Vector Database, Multi-Agent, 복잡한 Memory graph는 Context 문제의 출발점이 아니다. 구성 요소가 늘어날수록 coordination cost, Context 전달 비용, Latency, permission surface, 부분 실패 지점도 늘어난다.
언제 Memory나 복잡한 Context Engineering을 쓰지 말아야 하는가
- 한 번의 요청으로 끝나고 이후 Turn에서 재사용할 정보가 없는 작업
- 최신 값을 Database나 API에서 즉시 다시 읽을 수 있는 구조화 State
- 일반 Code가 필요한 field를 확정적으로 선택할 수 있는 단순 Workflow
- 민감 정보를 안전하게 분리·만료·삭제할 저장 정책이 없는 환경
- 검색 오류 비용이 구현 복잡성보다 큰 고위험 Action
특히 숫자, 권한, 실행 완료 여부처럼 정확해야 하는 값은 “Model이 기억하게” 만들지 말고 원본 System에서 매번 확인하는 편이 낫다. Memory는 진실의 원본을 대체하는 장치가 아니라, 필요한 원본을 다시 찾게 돕는 장치에 가깝다.
실무 적용 원칙
Context 설계의 핵심은 저장된 기록 전체를 복제하지 않고, 다음 Decision을 바꾸는 Goal·Constraint·Evidence·Current State·Open Question만 전달하는 것이다. 서로 다른 검토 결과를 한 문장으로 압축하면 어떤 기준이 충족되었고 무엇이 남았는지 추적하기 어려워지므로, 필요한 근거와 미해결 항목은 구분된 상태로 유지하는 편이 낫다.
실무 Context 설계 Checklist
- 다음 Model Call이 내려야 할 Decision을 한 문장으로 쓸 수 있는가?
- 그 Decision을 실제로 바꿀 정보만 Context에 들어가는가?
- 원본 State, Session, Memory, LLM-visible Context의 저장 위치가 분리되어 있는가?
- Local Context의 secret과 permission object가 Model에 노출되지 않는가?
- Tool Result는 allowlist field와 Source pointer로 축약되는가?
- 근거마다 version·확인 시각·적용 범위가 있는가?
- Context Builder가 무엇을 포함·제외했는지 Trace할 수 있는가?
- Compaction 뒤에도 Goal·Constraint·미완료 항목·실행 상태가 보존되는가?
- Session과 Memory가 사용자·tenant·task 경계를 넘지 않는가?
- Memory 없이 구조화 State 조회만으로 해결할 수 있는가?
Design Rule: 저장은 넓게 하더라도, Model에게 보여 주는 Context는 다음 Decision을 바꿀 최소한의 근거로 좁혀라.
이전 / 다음 / 관련 글
- Previous: Tool Calling이란 무엇인가: Model은 Tool을 직접 실행하지 않는다
- Next: AI Agent Memory와 Session의 차이: 무엇을 기억하고 무엇을 잊어야 하는가
- Related: Agent Loop란 무엇인가: AI Agent가 한 번의 답변으로 끝나지 않는 이유
- Foundation: AI Agent란 무엇인가: 챗봇과 무엇이 다른가
공식 참고 자료
- OpenAI — Conversation state와 Context Window 관리
- OpenAI Agents SDK — Context management
- OpenAI Agents SDK — Sessions
- OpenAI — Compaction
- Anthropic Engineering — Effective context engineering for AI agents
문서 확인일: 2026-09-28. API와 SDK의 세부 동작은 바뀔 수 있으므로 구현 시 최신 공식 문서를 다시 확인해야 합니다.