에이전틱 LLM의 컨텍스트 파이프라인
에이전틱 LLM 시스템에서 컨텍스트 엔지니어링은 프롬프트 문자열이 아니라 LLM 호출에 들어가는 전체 정보 생명주기를 설계하는 일이다. 선택, 정렬, 압축, 출처 분리, 메모리, 평가를 함께 운영해야 비용과 지연, prompt injection, 근거 오염, 회귀 원인 불명을 줄일 수 있다.
Script Companion
오디오와 함께 스크립트 보기
- 01
에이전틱 LLM 시스템에서 컨텍스트 엔지니어링은 프롬프트를 잘 쓰는 문제보다 넓다. agent 입력에는 prompt뿐 아니라 RAG 문서, tool observation, memory, UI state, policy가 함께 들어간다. long context가 가능해도 관련 없는 정보가 많으면 attention이 흐려지고 비용과 지연이 늘어난다. 그래서 토큰 예산은 단순한 길이 제한이 아니라 품질 예산에 가깝다.
- 02
핵심은 많이 넣기가 아니라 lifecycle 운영이다. 후보 context를 어디서 모을지 정하는 Collect, 이번 step에 필요한 것을 고르는 Select, 무엇을 먼저 읽게 할지 정하는 Rank가 먼저 온다. 이어서 무엇을 보존하고 버릴지 정하는 Compress, 어떤 슬롯과 신뢰 경계에 넣을지 정하는 Assemble, 실제 호출 입력을 확인하는 Execute가 이어진다. 마지막으로 context가 충분했는지 평가하고, 무엇을 memory로 남길지 결정한다.
- 03
Context Bundle은 LLM 호출마다 들어간 정보를 하나의 묶음으로 보는 관점이다. 운영에서는 bundle 전체를 trace에 남기되, 개인정보와 secret은 redaction해야 한다. trusted instruction과 untrusted evidence를 분리해 남겨야 나중에 왜 이 답이 나왔는지 재구성할 수 있다. 재현성을 확보하려면 당시 context bundle을 버전과 함께 다시 만들 수 있어야 한다.
- 04
Context Budget은 모든 정보를 넣지 않기 위한 기준이다. 예시는 지시문 5~15%, 작업 상태 10~20%, 근거 문서 40~60%, 도구 결과 10~30%, 메모리 5~15%처럼 역할별로 나뉜다. 초과할 때는 중복 문서, 낮은 score 문서, 오래된 observation, 요약 가능한 history 순으로 줄인다. 고객지원 answer step처럼 기준이 있는 경우 sufficiency >= 0.85, grounding >= 0.9, irrelevant_token_ratio <= 0.25 같은 통과선을 둔다.
- 05
Budget은 prompt caching과도 연결된다. system policy, tool schema, citation rule처럼 자주 바뀌지 않는 앞부분은 cacheable_prefix로 고정할 수 있다. 반대로 사용자 질문, 검색 결과, 최근 tool observation은 prefix 밖의 변동 슬롯에 둔다. 캐시 적중률을 높이려고 오래된 evidence를 prefix에 묶으면 context budget과 grounding 품질이 동시에 망가질 수 있다.
- 06
Selection과 Ranking은 top-k 몇 개를 고르는 문제로 끝나지 않는다. 최근 tool observation이나 chat turn에는 Recency가 유용하지만 최신 정보가 항상 가장 중요한 것은 아니다. RAG chunk와 memory 후보에는 Relevance score가 쓰이지만, 비슷하지만 틀린 문서가 상위에 올 수 있다. 정책 문서, API spec, runbook은 Authority를 보되 버전을 확인해야 하고, Diversity는 중복 chunk를 줄이면서 핵심 근거를 잃지 않는 균형이 필요하다.
- 07
Source Tagging과 Trust Boundary는 LLM 보안과 직접 연결된다. LLM은 token만 보기 때문에 system rule과 웹페이지가 주장한 instruction을 혼동할 수 있다. trusted instruction, untrusted retrieved text, user data, tool output을 한 문자열로 섞으면 prompt injection과 근거 오염이 생긴다. 그래서 context에는 출처와 신뢰도를 명시해야 하며, 이 구분은 L12-80 LLM 보안의 prompt injection 방어와 이어진다.
- 08
Context Compression은 짧게 요약하는 일이 아니라 의사결정에 필요한 정보를 보존하는 일이다. RAG 근거는 원문 문장을 고르는 Extractive compression이 citation 안정성 면에서 안전하고, agent state는 decision, evidence, open_questions 같은 구조로 줄이는 Schema compression이 적합하다. 압축 결과는 원문과 분리해 versioning해야 한다. summary_version, source_span_ids, created_at을 남겨야 모델 변경과 압축 정책 변경을 나눠 볼 수 있다.
- 09
Memory는 대화 전체 저장소가 아니다. Working memory는 현재 task state를 담고 run 종료 시 폐기하며, Episodic memory는 과거 작업 결과 중 재사용 가치가 있을 때만 남긴다. Semantic memory는 사용자나 도메인 사실을 출처와 갱신일과 함께 보유하고, Preference memory는 사용자가 명시한 형식이나 제약을 담는다. 잘못된 memory는 retrieval보다 위험하다. 모델이 그것을 이미 아는 사실처럼 받아들이기 때문이다.
- 10
Memory에는 lifecycle 규칙이 필요하다. Write gate는 사용자가 명시했거나 여러 source로 검증된 정보만 저장하게 한다. Update rule은 새 정보가 기존 memory와 충돌할 때 바로 덮어쓰기보다 conflict 상태로 두게 한다. 프로젝트 상태, 가격, 권한처럼 변하는 정보에는 Expiry를 둔다. Provenance로 어느 대화, 문서, tool 결과에서 왔는지 추적하고, Read policy로 현재 task와 관련 있는 memory만 retrieve한다.
- 11
Context Evaluation은 답변만 보는 평가의 한계를 줄인다. Sufficiency는 이 context만으로 정답을 만들 수 있는지, Relevance는 들어간 chunk 중 answer에 실제 사용된 비율을 본다. Grounding은 답변 claim이 context span에 연결되는지 확인하고, Contamination은 untrusted text가 instruction처럼 작동했는지 본다. Economy는 같은 품질을 더 적은 token으로 만들 수 있는지 묻는다. 이 지표는 L12-90 관측성·평가의 trace와 함께 봐야 한다.
- 12
평가 단위는 Candidate set, Selected context, Generated answer로 나누면 원인 분석이 쉬워진다. 정답 근거가 후보 검색 결과 안에 있었는데 실제 주입된 context에서 빠졌다면 selection이나 budget 문제다. selected context 안에 근거가 있었는데 답이 틀렸다면 prompt, model, output contract, judge 문제일 가능성이 높다. 이렇게 나누면 모델이 틀렸다는 말 대신 입력 단계의 병목을 찾을 수 있다.
같은 레이어
L12에서 이어 듣기
- LLM API 기초와 운영 감각 길이 미정
- 운영 자산으로 보는 프롬프트 엔지니어링 길이 미정
- 임베딩과 벡터 운영의 핵심 경로 길이 미정
- RAG 기초: 검색, 주입, 생성의 운영 기준 길이 미정
- LLM 도구 호출의 설계와 운영 길이 미정
- 에이전트 오케스트레이션 운영 기준 길이 미정
- LLM 비용과 지연을 운영 지표로 읽는 법 길이 미정
- LLM 보안과 운영 방어 계층 길이 미정
- LLM 운영을 위한 관측성과 평가 길이 미정
- 상태 머신으로 LLM 워크플로를 다루기 길이 미정
- AI 워크플로를 위한 Temporal Durable Execution 길이 미정
- Human-in-the-loop AI 워크플로 설계 길이 미정
- AI 앱의 온톨로지와 역량 모델링 길이 미정
- 심리측정으로 설계하는 SJT와 LLM 평가 길이 미정