Author: Trix Cyrus

[🔹 Follow] TrixSec GitHub

[🔹 Join] TrixSec Telegram

Context Engineering이란 무엇인가?

만약 당신이 2023년과 2024년에 프롬프트 문구, chain-of-thought 트릭, few-shot 예제에 집착하며 시간을 보냈다면, 당신은 prompt engineering을 하고 있었던 것입니다. 만약 당신이 2026년에 AI agent를 구축하고 있다면, 완벽한 지침을 작성하는 것이 더 이상 병목 현상(bottleneck)이 아니라는 것을 아마 알아차렸을 것입니다. 병목 현상은 그 지침 _주변의 모든 것_입니다: 어떤 문서가 검색되었는지, 얼마나 많은 대화 기록이 남아 있는지, 모델이 볼 수 있는 도구는 무엇인지, 그리고 이 모든 것이 추론 시간(inference time)에 실제로 일관성 있게 모델의 머릿속에 들어맞는지 여부입니다.

이 더 광범위한 학문 분야가 이제 이름이 생겼습니다: context engineering입니다.

간단한 정의

Context engineering은 주어진 inference 호출에서 언어 모델(language model)이 보는 모든 것—시스템 프롬프트, 사용자 입력, 검색된 문서, 대화 기록, 도구 정의, 그리고 장기 메모리(long-term memory)—을 의도적으로 큐레이션하는 실천입니다. 이를 통해 모델이 작업을 잘 수행하는 데 필요한 정확한 정보만을 갖도록 하고, 그 이상은 없게 만듭니다.

Prompt engineering은

에이전트(Agents)가 단발성 채팅(single-shot chat)을 대체했습니다. 초기 LLM 애플리케이션은 대부분 원샷(one-shot) 방식이었습니다. 이것을 분류하거나, 저것을 요약하거나, 이 질문에 답하는 식이었죠. 모든 상호작용이 하나의 프롬프트(prompt) 안에 머물렀습니다. 에이전트는 다릅니다. 에이전트는 루프(loops)를 돌며, 도구(tools)를 호출하고, 결과를 관찰하며, 다음 단계에서 무엇을 할지 결정합니다. 때로는 수십 또는 수백 단계에 걸쳐 이 과정을 수행합니다. 이 모든 단계마다 누적된 컨텍스트(context)가 모델로 다시 전송됩니다. 따라서 실제 엔지니어링 문제는 원래 지시문의 문구(wording)가 아니라, 이 누적되는 덩어리(blob) 안에 _무엇이 들어있는가_를 관리하는 것이 되었습니다.

더 커진 컨텍스트 윈도우(context windows)는 문제를 해결하지 못했고, 오히려 문제를 드러냈습니다. 백만 토큰 규모의 컨텍스트 윈도우가 있다면 모든 것을 그냥 쏟아붓고 모델이 알아서 해결하게 하면 된다고 생각하기 쉽습니다. 하지만 실제로 모델은 연구자들과 실무자들이 이제 "컨텍스트 부패 (context rot)"라고 부르는 현상을 보입니다. 모델이 명시한 한도 내에 있더라도, 미미하게 관련 있는 내용으로 윈도우를 채울수록 성능이 측정 가능한 수준으로 저하됩니다. 어텐션(Attention)은 유한한 자원입니다. 더 큰 윈도우는 더 많은 집중력을 주는 것이 아니라, 더 많은 여지를 줄 뿐입니다.

프로덕션 에이전트(Production agents)에는 실제 단위 경제성(unit economics)이 존재합니다. 장황한 도구 출력(tool outputs), 중복된 검색 결과(retrieval results), 그리고 전체 대화 기록은 빠르게 쌓입니다. 멀티 에이전트 시스템(Multi-agent systems)은 동일한 작업을 수행하는 단순한 챗봇보다 몇 배 더 많은 토큰을 소모할 수 있습니다. 규모가 커질 때, 필요한 것보다 5배 많은 토큰을 사용하는 에이전트는 단순히 느린 것에 그치지 않고, 실행 가능한 제품과 비용 센터(cost center) 사이의 차이를 만듭니다. 팀들이 토큰 청구서를 확인하기 시작하면서, "이 컨텍스트 윈도우 안에 실제로 무엇이 들어있으며 왜 들어있는가"는 더 이상 학술적인 질문이 아니게 되었습니다.

실제로 관리하게 되는 네 가지 요소

대부분의 컨텍스트 엔지니어링 작업은 다음 네 가지 범주 중 하나에 속합니다.

1. 시스템 지시문(System instructions) 및 도구 정의(tool definitions)

이 부분은 고전적인 프롬프트 엔지니어링 (Prompt Engineering)과 가장 유사해 보이지만, 목표가 "영리한 지시문을 작성하는 것"에서 "최소한의 모호하지 않은 행동 공간 (Action Space)을 정의하는 것"으로 전환됩니다. 흔히 발생하는 실패 사례는 도구 세트가 너무 비대해지거나 기능이 너무 중복되어, 모델이 실제로 어떤 도구를 호출해야 할지 구분하지 못하는 경우입니다. 도구 목록을 읽는 인간 엔지니어가 주어진 상황에서 어떤 도구가 적용되는지 확신을 가지고 말할 수 없다면, 모델 또한 마찬가지입니다. 도구의 표면적 (Tool surface)을 작게 유지하고 도구 간의 경계를 명확하게 만드는 것은 프롬프트 다듬기 (Prompt polish)가 아니라 컨텍스트 엔지니어링 (Context engineering)입니다.

2. 검색 (Retrieval) (무엇이, 언제 가져와지는가)

여기에는 두 가지 광범위한 전략이 있으며, 대부분의 프로덕션 시스템 (Production systems)은 이 두 가지를 혼합하여 사용하게 됩니다.

_사전 가져오기 (Pre-fetch)_는 모델이 추론을 시작하기 전에 관련 데이터를 미리 가져옵니다. 이는 빠르고 예측 가능하지만, 검색 파이프라인 (Retrieval pipeline)이 무엇이 관련이 있는지 사전에 예측하는 능력에 따라 성능이 결정됩니다.

_적시 검색 (Just-in-time retrieval)_은 모델에게 파일 검색, grep, 또는 데이터베이스 쿼리와 같은 기본 요소 (Primitives)를 제공하여, 모델이 정보가 필요하다고 판단할 때 직접 정보를 가져오게 합니다. 이는 오래된 사전 계산된 인덱스 (Pre-computed indexes)를 피할 수 있게 해주며, 에이전트 (Agent)가 사람처럼 환경을 탐색할 수 있게 하지만, 속도가 더 느리고 모델이 언제 어떻게 검색할지에 대한 좋은 휴리스틱 (Heuristics)을 갖추고 있어야 합니다.

Claude Code는 이러한 하이브리드 접근 방식의 유용한 실제 사례입니다. 프로젝트 수준의 지시문 파일은 처음에 자동으로 컨텍스트에 로드되지만, 파일 내용은 사전 인덱싱되어 잠재적으로 오래된 상태로 두는 대신, 에이전트가 실제로 필요로 할 때 검색 기본 요소 (Search primitives)를 통해 적시 검색 (Just-in-time) 방식으로 가져옵니다.

3. 턴(Turns) 및 세션(Sessions) 간의 메모리

단일 대화 내에서 이는 어떤 대화 기록을 실제로 유지해야 하는지, 반대로 무엇을 요약하거나 삭제할 수 있는지 결정하는 것을 의미합니다. 세션(Sessions) 간에는 무엇을 영구 메모리(Durable memory)에 기록할 가치가 있는지 결정하는 것을 의미합니다. 계층적 메모리(Hierarchical memory), 단기 작업 컨텍스트(Short-term working context), 중기 세션 요약(Medium-term session summaries), 그리고 장기 영구 메모리(Long-term persistent memory)는 현재 연구와 툴링(Tooling) 모두에서 활발하게 다뤄지는 분야입니다. 왜냐하면 모든 것을 기억하려는 단순한(Naive) 접근 방식은 확장성(Scale) 측면에서 매우 좋지 않기 때문입니다.

4. 압축(Compaction) 및 가지치기(Pruning)

장기적으로 실행되는 에이전트(Agent) 작업의 경우, 가공되지 않은(Raw) 기록은 결국 압축되어야 합니다. 압축(Compaction) 기술은 작업의 지속에 실제로 중요한 상태(State)를 보존하면서, 가치가 낮은 턴(Turns)을 요약하거나 폐기합니다. 이를 잘못 수행하면 에이전트가 15단계 전에 부여받은 제약 조건(Constraint)을 잊어버리는 원인이 됩니다. 잘 수행된다면 이는 눈에 띄지 않으며, 에이전트는 가공되지 않은 컨텍스트 창(Context window)이 허용하는 범위보다 훨씬 더 오랫동안 일관성 있게 작업을 계속할 수 있습니다.

작고 구체적인 예시

회사의 문서를 사용하여 지원 티켓(Support tickets)을 분류하고 답장을 초안하는 에이전트를 구축한다고 가정해 봅시다.

프롬프트 엔지니어링(Prompt-engineering) 사고방식은 지시문(Instruction)을 최적화합니다: "당신은 유능한 지원 에이전트입니다. 티켓을 읽고 제공된 문서를 사용하여 전문적인 답장을 작성하세요."

컨텍스트 엔지니어링(Context-engineering) 사고방식은 더 긴 질문 목록을 던집니다: 이 티켓을 위해 실제로 어떤 문서가 검색(Retrieve)되는가? 그리고 전체 지식 베이스(Knowledge base)를 단순히 키워드 매칭하는 대신 어떻게 검색의 정확도(Precision)를 유지할 것인가? 에이전트는 전체 티켓 스레드(Thread)를 보는가, 아니면 내용이 길어지면 요약된 버전을 보는가? 에이전트가 "문서 검색", "과거 티켓 검색", "상담원 연결" 도구(Tool)에 접근할 수 있다면, 모델이 잘못된 도구를 호출하지 않도록 그 경계가 충분히 명확한가? 만약 이 에이전트가 20번의 메시지가 오가는 며칠간의 티켓 작업을 수행한다면, 20번째 메시지 시점에도 컨텍스트에 남아 있는 것은 무엇이고 무엇이 가지치기(Pruned) 되었는가?

이 질문들 중 단 하나도 단어 선택에 관한 것이 아닙니다. 이 모든 질문이 에이전트의 신뢰성(Reliable)을 결정합니다.

실무적 시사점(Practical takeaways)

팀들이 이 문제에 접근하는 방식에서 몇 가지 원칙이 일관되게 나타납니다:

• 컨텍스트(Context)를 단순한 쓰레기통이 아닌, 희소하고 비용이 많이 드는 자원으로 취급하십시오. 포함하는 모든 토큰(Token)은 비용(dollars) 측면과 모델의 어텐션 예산(Attention budget) 측면 모두에서 비용을 발생시킵니다.
• 크고 중복되는 도구 세트보다는 작고 경계가 명확한 도구 세트가 더 낫습니다. 도구 A와 도구 B를 언제 사용할지에 대한 명확한 규칙을 설명할 수 없다면, 모델 또한 이를 수행할 수 없습니다.
• 검색량(Retrieval volume)보다는 검색 정밀도(Retrieval precision)를 우선시하십시오. 거대한 컨텍스트 윈도우(Context window)를 사용할 수 있더라도, 느슨하게 관련된 100개의 청크(Chunk)를 가져오는 것보다 매우 관련성이 높은 10개의 청크를 가져오는 것이 더 효과적입니다.
• 실제 운영 환경에서 컨텍스트 제한에 도달한 후에 요약 단계를 덧붙이기보다는, 실행 시간이 길어질 수 있는 모든 작업에 대해 처음부터 압축(Compaction)을 계획하십시오.
• 잘 설계된 컨텍스트를 가진 약한 모델이, 지저분한 컨텍스트를 가진 강력한 모델보다 종종 더 나은 성능을 보입니다. 아무리 원시적인 능력(Raw capability)이 뛰어나더라도, 눈앞의 작업에 실제로 무엇이 관련되어 있는지 구분하지 못하는 에이전트를 완전히 보완할 수는 없습니다.

향후 전망 (Where this is headed)

이 분야는 여전히 빠르게 움직이고 있습니다. 연구자들은 무엇이 컨텍스트에 포함되어야 하는지를 결정하기 위해 더 공식적이고 거의 정보 이론적(Information-theoretic)인 방식들을 탐구하고 있습니다(각 후보 청크가 작업에 대해 측정 가능한 양의 정보를 담고 있다고 간주하고, 최소한의 충분한 집합을 선택하는 방식). 에이전트 프레임워크(Agent frameworks)는 수동으로 구축된 파이프라인(Pipeline)에 전적으로 의존하기보다, 에이전트가 스스로 컨텍스트를 능동적으로 관리하고 심지어 재작성할 수 있도록 하는 방향으로 발전하고 있습니다. 또한 메모리 아키텍처(Memory architectures)는 단일한 평면적 대화 로그(Flat conversation log)보다는 운영체제의 메모리 계층 구조(Memory hierarchy)와 더 유사한 계층형 시스템을 지향하는 추세입니다.

하지만 도구가 어떻게 진화하든 핵심 아이디어는 유지될 가능성이 높습니다. 모델의 출력은 당신이 제공하는 정보의 풍경(Information landscape)만큼만 훌륭할 수 있습니다. 다회차 작업(Multi-turn task)의 모든 단계에서 의도적으로 그 풍경을 올바르게 구성하는 것이 이제는 중요한 과업입니다.

추가 읽을거리 (Further reading)

• Anthropic, "AI 에이전트를 위한 효과적인 컨텍스트 엔지니어링 (Effective context engineering for AI agents)"
• Simon Willison, "컨텍스트 엔지니어링 (Context engineering)"
• Mei et al., "대규모 언어 모델 (LLMs)을 위한 컨텍스트 엔지니어링 서베이 (A Survey of Context Engineering for Large Language Models)"

~Trixsec