컨텍스트 엔지니어링: AI 에이전트가 작업 목표를 놓치지 않게 하는 법

컨텍스트 엔지니어링은 에이전트가 데모에서는 잘 작동하다가 실제 업무에서 목표를 놓칠 때 살펴봐야 할 접근법입니다. 지시를 더하기 전에 모델에 어떤 정보가 전달되는지부터 확인합니다. 단계마다 지시, 툴, 검색으로 가져온 사실, 메모리, 이력이라는 5가지 입력을 직접 관리하는 것입니다. 다음 행동을 올바르게 선택할 만큼의 근거를 제공하면서, 관련 없는 정보는 덜 따라오게 하는 것이 목표입니다.

컨텍스트 엔지니어링이란 무엇인가요?

컨텍스트 엔지니어링은 모델이 다음 판단을 내릴 때 무엇을 볼지 설계하는 일입니다. 작성한 지시뿐 아니라 선택할 수 있는 툴, 툴이 반환하는 근거, 불러오는 메모리, 유지하는 대화까지 모두 포함합니다.

모델의 컨텍스트 윈도우는 요청을 처리하는 작업 공간입니다. 토큰은 모델이 처리하는 텍스트나 그 밖의 콘텐츠 단위입니다. 시스템 어딘가에 저장된 문서는 활용할 수 있는 정보일 뿐입니다. 애플리케이션이나 에이전트가 내용을 불러와야 비로소 활성 컨텍스트가 됩니다.

이 차이를 알면 운영 환경에서 흔히 발생하는 실패를 이해할 수 있습니다. 에이전트가 올바른 정책 문서에 접근할 수 있어도, 판단하는 시점에 최신 정책이 모델에 전달되지 않으면 과거 대화를 근거로 답할 수 있습니다. 반대로 모든 정책을 불러오면 관계없는 예외 조항이나 폐기된 버전까지 섞일 수 있습니다.

Anthropic은 2025년 9월 29일 엔지니어링 글에서 이 작업을 **“LLM 추론 중 최적의 토큰 집합, 즉 정보 집합을 선별하고 유지하는 일”**이라고 설명합니다. 지시를 작성하는 일과 실행 중 제공되는 더 넓은 범위의 정보를 관리하는 일을 구분한 것입니다. Anthropic의 컨텍스트 엔지니어링 설명.

LangChain은 2025년 7월 2일 글에서 **“에이전트가 작업을 진행하는 매 단계마다 꼭 맞는 정보로 컨텍스트 윈도우를 채우는 일”**이라고 설명합니다. 이를 기록, 선택, 압축, 격리로 나눕니다. 유용한 상태를 저장하고, 관련 자료를 가져오고, 남길 내용을 줄이고, 독립적인 조사를 분리하는 것입니다. LangChain의 컨텍스트 엔지니어링 설명.

실무에서는 설계의 단위가 달라집니다. 개별 프롬프트는 고정해 둘 수 있습니다. 하지만 에이전트의 다음 요청은 파일을 읽거나, 툴 결과를 받거나, 하위 작업을 마치거나, 앞선 가정이 틀렸음을 알 때마다 달라집니다. 작업 전반에 걸쳐 그 요청을 어떻게 구성할지 정하는 정책이 필요합니다.

문서 확인일: 2026년 10월 13일. 아래 툴 동작은 당시 최신 Anthropic 및 OpenAI 문서와 대조해 확인했습니다. 뒤에 나오는 예제는 설계를 설명하기 위한 가상 사례이며, 운영 환경의 벤치마크가 아닙니다.

컨텍스트 엔지니어링과 프롬프트 엔지니어링은 어떻게 다른가요?

프롬프트 엔지니어링은 지시를 개선하고, 컨텍스트 엔지니어링은 그 지시를 둘러싼 요청 전체를 개선합니다. 둘 다 필요합니다.

코딩 에이전트라면 프롬프트 엔지니어링으로 “회원가입을 고쳐 줘”라는 지시를 “회원가입을 재시도하면 환영 이메일이 중복 발송되는 원인을 찾고, 최소한의 수정안과 회귀 테스트를 제안해 줘”로 바꿀 수 있습니다. 컨텍스트 엔지니어링은 그 수정안을 제안하기 전에 어떤 회원가입 관련 파일, 재시도 로그, 프로젝트 규칙, 이전 조사 결과를 에이전트에게 전달할지 정합니다.

아무리 잘 쓴 지시도 엉뚱한 환경의 로그를 불러온 문제를 해결해 주지는 못합니다. 로그에서 필요한 부분을 세심하게 골라내더라도, 진단할지 수정할지 배포할지 지시하지 않았다면 그 빈틈은 남습니다.

핵심 역량은 정보의 경계를 정하는 데 있습니다

각 정보가 언제 컨텍스트에 들어오고 언제 빠져도 되는지 정합니다. 상시 적용하는 프로젝트 규칙, 임시 작업 상태, 원본 근거는 각각 유지해야 할 기간이 다릅니다.

코딩 규칙은 상시 지시에 넣습니다. “재시도 분기는 아직 테스트하지 않았다”는 내용은 현재 작업의 인계 기록에 넣습니다. 외부 서비스 응답 전문은 접근 가능한 근거 파일에 보관하고, 판단에 영향을 주는 필드가 필요해질 때 해당 부분을 불러옵니다.

이 때문에 검색 증강 생성, 즉 RAG도 전체 작업의 일부에 해당합니다. RAG는 모델에 필요한 참고 자료를 검색합니다. 지시, 툴, 남겨 둘 대화 이력, 검색 결과 중 전달할 내용은 여전히 별도로 정해야 합니다.

AI 에이전트의 컨텍스트는 어떻게 관리하나요?

실패한 단계에서 불필요한 컨텍스트를 가장 많이 만들어 낸 원인부터 손봅니다. 모든 기법을 한꺼번에 도입할 필요는 없습니다. 로그가 넘쳐나는 디버깅 에이전트와 프로젝트 제약을 자꾸 잊는 어시스턴트는 먼저 고쳐야 할 부분이 다릅니다.

대화 주제보다 판단과 남은 작업을 중심으로 압축합니다

Anthropic의 코딩 에이전트인 Claude Code는 컨텍스트 사용량을 확인하는 /context와 대화를 줄이는 /compact를 제공합니다. 자동 관리 기능은 오래된 툴 출력을 먼저 지우고, 필요하면 대화를 요약합니다. 문서에는 대화 앞부분의 상세 지시가 사라질 수 있다는 경고가 명시돼 있습니다. Claude Code 컨텍스트 관리.

압축할 때는 무엇을 남길지 지정합니다. 환영 이메일 조사에서는 /compact Preserve the current goal, change boundaries, relevant file paths, observed evidence, failed hypotheses, and the next unresolved question.을 사용할 수 있습니다. 작업에 맞춘 지침을 담은 명령이지, 모든 세부 정보가 보존된다는 보장은 아닙니다.

계속하기 전에 요약에서 관찰한 사실, 추론한 내용, 아직 확인하지 않은 내용이 구분되는지 살펴봅니다. “이메일 재시도 조사함”은 주제를 붙인 표제에 불과합니다. “외부 서비스가 요청을 수락한 것은 확인했으며, 로컬 확인 응답 처리 경로는 더 살펴봐야 함”은 다음 행동으로 이어지는 상태 기록입니다.

압축에는 정보 손실이 따릅니다. 원본 근거에 계속 접근할 수 있게 하고 상시 규칙은 프로젝트 지시에 남겨야, 뒤이은 단계에서 필요한 세부 정보를 복원할 수 있습니다.

다음 판단에 필요한 근거를 그때그때 가져옵니다

다음 질문에 답할 수 있는 자료를 먼저 가져오고, 그것으로 부족할 때만 검색 범위를 넓힙니다. Anthropic의 엔지니어링 글은 이를 가벼운 참조 정보를 유지하다가 필요할 때 툴로 정보를 불러오는 방식으로 설명합니다. 필요한 시점에 불러오는 컨텍스트.

Claude Code에서는 파일 읽기 툴과 셸 툴로 이런 흐름을 구현할 수 있습니다. 재시도 핸들러를 찾고, 핸들러와 그 호출부를 읽고, 관련 오류가 발생한 순서를 살펴보도록 요청합니다. 전용 Grep 툴이 활성화된 환경에서는 파일 전체 대신 파일 경로, 일치하는 내용, 일치 건수를 반환할 수 있습니다. Claude Code 툴 레퍼런스.

직접 만든 에이전트라면 원본을 다시 여는 데 쓸 참조값, 관련 발췌문, 적용 범위를 판단할 메타데이터를 반환하게 합니다. 환경, 레코드 식별 정보, 버전, 시행일 등이 여기에 해당합니다. 주변 내용은 후속 툴 호출로 열어 볼 수 있습니다.

검색은 관련 근거를 놓칠 수 있으므로 범위를 넓히는 규칙도 둡니다. 좁은 범위에서 아무것도 찾지 못했다면, 그 사실이 존재하지 않는다고 결론 내리기 전에 범위나 질의를 바꿉니다. 발췌문만으로 예외 적용 여부를 판단할 수 없다면 앞뒤 문단까지 불러옵니다.

툴 결과는 대화에 넣기 전에 정리합니다

다음 판단에 필요한 결과를 반환하되, 생략한 세부 내용을 다시 가져올 방법을 함께 제공합니다. Anthropic은 출력이 긴 툴에 필터링, 페이지 나누기, 범위 선택, 잘라내기를 적용하고, 결과를 줄였을 때는 도움이 되는 안내를 제공하라고 권고합니다. Anthropic의 툴 설계 지침.

Claude Code는 성공한 셸 명령의 출력이 클 때 이 방식을 구체적으로 적용합니다. 대화에 직접 넣는 출력의 상한을 넘으면 저장 파일 경로와 미리보기를 제공해, 에이전트가 필요할 때 파일을 검색하거나 읽도록 합니다. 실패한 명령은 문서에 명시된 처리 방식이 다르므로, 잘린 오류 출력에 언제나 원본을 복구할 파일 경로가 있다고 가정하면 안 됩니다. 셸 출력 처리.

회원가입 에이전트에 유용한 로그 결과는 해당 이벤트, 직전 작업, 오류, 원본 위치를 담습니다. 반복되는 정상 요청은 로그 파일에 남겨 둬도 됩니다. 오류 코드와 이벤트 식별 정보는 정확히 보존합니다. “무언가 시간이 초과됐다”처럼 풀어 쓰면 수정 방향을 결정할 단서가 사라질 수 있습니다.

내용을 무작정 잘라내면 결정적인 예외까지 없어질 수 있습니다. 무엇을 생략했는지 알리고 후속 검색 질의나 파일 참조를 제공합니다. 상충하는 근거를 줄이기 전에 반복되는 잡음부터 줄입니다.

독립적인 조사는 대화 이력을 물려받지 않는 서브에이전트에 맡깁니다

Claude Code 서브에이전트는 별도의 컨텍스트 윈도우에서 범위가 정해진 조사를 수행하고 결과를 돌려줄 수 있습니다. 대화를 포크하지 않는 서브에이전트는 자체 정의와 전달받은 작업만으로 새로 시작합니다. 반면 대화 포크는 상위 에이전트의 이력을 물려받습니다. 둘 다 이후의 작업은 분리하지만, 앞선 대화가 없는 컨텍스트에서 시작하는 것은 전자뿐입니다. 서브에이전트와 대화 포크.

예를 들면 이렇게 위임합니다. “이메일 재시도 경로를 살펴봐 줘. 파일은 수정하지 마. 관련 경로, 중복 전달을 뒷받침하는 근거, 가능한 다른 설명, 다음 확인 사항을 반환해 줘.” 작업 에이전트가 상위 대화를 안다고 가정하지 말고, 필요한 제약을 함께 전달합니다.

반환 내용은 바로 활용할 수 있을 만큼 한정합니다. 조사 결과, 근거 참조, 불확실한 점이면 됩니다. 작업 에이전트가 읽은 이력을 통째로 반환하면, 비대해진 컨텍스트를 주 대화로 옮기는 데 그칩니다.

작업 에이전트는 자체적으로 요청을 보내고 사용량을 소모합니다. 상위 에이전트가 이미 내린 결정을 작업 지시에서 빠뜨리면 같은 일을 반복할 수도 있습니다. 조사를 분리할 수 있고 중간 출력은 버려도 될 때 활용합니다. 긴밀하게 연결된 추론은 한곳에서 이어 갑니다. 설정 방법은 Claude Code 서브에이전트에서 다룹니다.

메모리 파일에는 작고 안정적인 역할을 부여합니다

CLAUDE.md는 프로젝트 지시 파일입니다. 끝난 대화를 모두 붙여 넣는 곳이 아닙니다. Claude Code에는 학습한 내용을 기록하는 자동 메모리도 있습니다. 문서는 이 둘을 강제 적용되는 설정과 구분합니다. 메모리 파일에 금지 사항을 적는다고 그 행동이 기술적으로 불가능해지지는 않습니다. Claude Code 메모리.

소규모 제품 팀이라면 저장소별 규칙, 실제로 쓰는 빌드·테스트 명령, 변경 범위, 상세 문서 참조를 상시 파일에 남깁니다. 임시 조사 상태는 별도 작업 노트에 기록합니다. 파일 구성은 CLAUDE.md로 팀 메모리 관리하기를 참고합니다.

놓치기 쉬운 제약도 있습니다. 긴 문서를 CLAUDE.md에 가져오면 그 내용도 함께 로드됩니다. 내용을 가져오기용 파일로 옮기면 정리는 잘될 수 있지만 활성 컨텍스트가 줄어드는 것은 아닙니다. 저장소 일부에서만 필요한 지시라면 문서에 설명된 경로별 규칙을 검토합니다. 재사용할 워크플로는 Claude Code 스킬로 만들 수 있습니다. 스킬은 일반적으로 설명만 먼저 공개하고, 호출될 때 전체 지시를 불러옵니다. 메모리 가져오기와 범위별 규칙, 스킬 로딩.

계속 남는 파일은 유용한 지식만큼이나 낡은 가정도 잘 보존합니다. 해결된 장애 기록과 더 이상 쓰지 않는 명령은 제거합니다. 바뀔 수 있는 사실에는 출처나 리비전을 기록합니다. 세션, 작업 컨텍스트, 영구 저장소의 차이는 에이전트 메모리 이해하기에서 더 자세히 설명합니다.

Claude Agent SDK와 Codex에서는 어떻게 적용하나요?

이런 기법은 실제 툴에 구현돼 있지만, 근거와 작업 범위를 정하는 주체는 여전히 애플리케이션입니다. 자동 컨텍스트 관리 기능이 워크플로에서 어떤 업무 정보를 빠뜨리고 검색하지 않았는지 대신 판단할 수는 없습니다.

Claude Agent SDK: 애플리케이션 안에 에이전트 루프를 넣습니다

Claude Agent SDK는 Claude Code의 기반인 툴, 에이전트 루프, 컨텍스트 관리 기능을 Python 및 TypeScript 애플리케이션에서 사용할 수 있게 합니다. 직접 운영하는 제품이나 자동화에 에이전트를 내장할 때 사용합니다. Agent SDK 개요.

SDK는 컨텍스트 윈도우의 한도에 가까워지면 오래된 이력을 자동으로 압축하고 compact_boundary 시스템 이벤트를 내보냅니다. 이 이벤트를 작업 결과와 함께 기록하면 요약 이후에 나타나는 실패를 찾아낼 수 있습니다. 대화를 포크하지 않는 SDK 서브에이전트는 중간 작업을 자체 대화에 남기고 최종 메시지를 반환합니다. SDK 에이전트 루프, SDK 서브에이전트.

프로젝트 지시를 어떻게 불러올지 명확히 설정합니다. 현재 query()의 기본 옵션은 사용자 및 프로젝트 설정 소스를 활성화합니다. TypeScript에서 settingSources를, Python에서 setting_sources를 지정한다면 프로젝트의 CLAUDE.md가 필요할 때 project를 포함해야 합니다. 빈 배열을 지정하면 이 파일을 불러오지 않습니다. 이를 제어하는 것은 설정 소스이며, claude_code 시스템 프롬프트 프리셋 선택이 아닙니다. SDK 지시 로딩.

에이전트 루프가 아무리 뛰어나도 업무에 맞는 검색 정책은 필요합니다. 지원 에이전트에는 현재 고객이 누구인지, 어떤 정책이 적용되는지, 행동하기 전에 어떤 근거가 있어야 하는지를 여전히 직접 정의해야 합니다.

Codex: 저장소 지시와 진행 중인 대화를 분리합니다

OpenAI의 Codex는 작업 전에 AGENTS.md 지시를 읽습니다. 전역 지침과 함께 저장소 루트에서 작업 디렉터리까지의 프로젝트 파일을 결합합니다. 나중에 읽는 지침이 우선하며, 각 디렉터리에서는 AGENTS.override.md가 우선합니다. Codex 프로젝트 지시.

이 계층 구조를 활용해 공통 빌드 규칙은 루트에, 특정 작업에만 필요한 규칙은 해당 작업 위치 가까이에 둡니다. Codex CLI는 현재 보이는 대화를 요약하는 /compact와 지시 파일의 뼈대를 만드는 /init도 제공합니다. 생성된 초안을 기준 문서로 삼기 전에 실제 저장소와 대조해 검토합니다. Codex 명령.

저장소 지시 파일이 진행 중인 작업까지 자동으로 기록하지는 않습니다. 현재 목표, 확인한 사실, 남은 작업, 근거 위치는 따로 저장합니다. 재시작하거나 대화를 압축한 뒤에는 전체 조사 과정을 재생하지 않아도 다음 요청에서 그 작업 상태를 활용할 수 있어야 합니다.

컨텍스트 엔지니어링 예제: 비대해진 에이전트 입력 줄이기

판단에 꼭 필요한 정보는 지키면서 그 주변을 덜어냅니다. 회원가입 재시도 후 환영 이메일이 중복 발송되는 문제를 조사하는 가상의 코딩 에이전트를 생각해 봅니다. 아래 파일명과 근거는 설계 방식을 설명하기 위한 예시이며, 배포된 시스템에서 얻은 결과가 아닙니다.

처음에는 엔지니어링 핸드북 전체, 저장소에서 광범위하게 추출한 내용, 관련 없는 서비스 로그, 이전 디버깅 대화 전부, 무관한 관리 업무용 툴까지 한꺼번에 제공했다고 가정합니다. 실제 할 일은 훨씬 좁습니다. 중복 발송 경로를 찾고, 최소한의 변경안을 제안하고, 회귀 테스트를 정하는 것입니다. 스키마 변경은 범위 밖입니다.

1. 1

   현재 작업과 상시 제약을 남깁니다

   대화 이력에 섞인 서로 다른 요청을 현재 목표와 완료 기준으로 정리합니다. 스키마 변경 금지 제약은 계속 보이게 합니다. 이 작업에 필요한 저장소 툴을 제공하고, 관련 없는 관리 툴의 정의는 이번 실행에서 제외합니다. 안정적으로 유지할 저장소 규칙은 적절한 프로젝트 지시 파일로 옮기고, 임시 관찰 결과는 작업 노트에 남깁니다. 자동으로 불러오는 파일에 핸드북 전체를 넣지 않습니다.

2. 2

   파일 묶음 대신 근거의 위치를 정리합니다

   signup-handler.ts, welcome-job.ts, 재시도 테스트, 관련 로그 파일을 가리키는 참조를 남깁니다. 이 이름들은 예시입니다. 다음 질문에 답하는 데 필요할 때 핸들러와 워커를 읽고, 필요에 따라 의존 코드도 살펴봅니다. 근거의 위치를 정리하면 자료에 접근할 수 있지만, 실제로 읽는 과정을 대신할 수는 없습니다.

3. 3

   실패와 관련된 부분만 툴 결과로 가져옵니다

   문제가 발생한 회원가입 이벤트와 재시도 순서를 요청합니다. 가상의 기록에 외부 서비스의 요청 수락, 로컬 확인 응답 누락, 큐에 추가된 재시도가 차례로 나타났다고 가정합니다. 그 순서와 이벤트 식별 정보, 원본 위치를 남깁니다. 관련 없는 정상 요청은 원본 로그에 둡니다. 두 번째 시도가 실제 전달로 이어졌는지는 아직 불확실하다는 점도 보존합니다.

4. 4

   범위가 정해진 탐색을 분리합니다

   대화 이력을 물려받지 않는 작업 에이전트에 중복 발송 방지가 어디에 구현돼 있는지 찾도록 맡깁니다. 작업 범위와 관련 경로를 함께 전달합니다. 코드 위치와 근거를 요청하고, 검색을 끝내지 못했다면 그 사실도 명시하게 합니다. 조사 결과는 주 에이전트에 돌려주되, 작업 에이전트가 탐색하며 읽은 내용은 주 대화 밖에 둡니다.

5. 5

   조사 내용을 다음 작업에 쓸 인계 기록으로 압축합니다

   현재 목표, 확인된 근거, 배제한 설명, 미해결 질문, 다음 행동을 남깁니다. 큐에 들어간 재시도와 실제로 확인된 중복 전달을 구분합니다. 원본 대화를 보관해 에이전트가 추측하는 대신 필요한 세부 정보를 다시 확인할 수 있게 합니다.

6. 6

   남긴 정보로 다음 요청을 구성합니다

   작업, 상시 규칙, 관련 핸들러 발췌문, 추린 이벤트 순서, 작업 에이전트의 조사 결과를 불러옵니다. 다음 할 일은 확인 응답과 중복 방지 경로를 살펴보고 회귀 테스트를 제안하는 것입니다. 그 행동에 더 많은 근거가 필요하면 추가로 불러옵니다. 습관적으로 보관 자료 전체를 다시 첨부하지 않습니다.

작업 노트는 다음과 같이 작성할 수 있습니다.

목표: 회원가입 재시도 후 환영 이메일이 중복 발송되는 이유를 설명하고, 회귀 테스트를 포함한 최소 수정안을 제안합니다.
제약: 스키마 변경은 범위에서 제외합니다.
근거: 선택한 로그 구간에는 외부 서비스의 요청 수락, 로컬 확인 응답 누락, 큐에 추가된 재시도가 나타납니다. 이벤트 참조와 원본 로그 위치를 보존합니다.
미확인 사항: 큐에 들어간 재시도가 실제 전달로 이어졌는지, 중복 발송 방지가 어디에 적용되는지 확인해야 합니다.
다음 확인: 참조한 핸들러와 워커에서 확인 응답 및 중복 방지 경로를 살펴봅니다.

이 가상의 노트는 불확실성을 그대로 드러냅니다. 모델은 진단을 내릴 때 이 노트와 함께 뒷받침하는 발췌문을 받습니다.

결과적으로 포함할 콘텐츠의 목록은 줄어들지만, 이것이 토큰 감소량을 입증하는 것은 아닙니다. 정확한 토큰 수는 실제 요청과 토크나이저에 따라 달라집니다. 비용 절감과 완료율 개선은 측정해야 합니다. 이 예제는 무엇을 빼고 무엇을 남길지 보여 줍니다.

작업 인계에 쓸 컨텍스트 엔지니어링 템플릿

다음 항목을 갖춘 작업 노트를 만들고, 실제 실행에서 확인한 근거로 채웁니다.

• 목표와 완료 조건: 현재 요청과 완료로 인정할 기준을 적습니다.
• 제약: 다음 단계에서도 지켜야 할 경계를 적습니다.
• 확인한 사실: 각 조사 결과에 출처 위치와 관련 리비전 또는 적용 범위를 함께 기록합니다.
• 불확실성: 아직 추론에 머무는 내용, 상충하는 내용, 살펴보지 않은 내용을 적습니다.
• 다음 행동: 다음에 확인할 사항과 그 근거를 가져올 위치를 적습니다.

조사 결과가 바뀌면 노트도 갱신합니다. 이전 내용을 고치지 않은 채 새 생각을 계속 덧붙이면, 더 작은 파일에서 같은 문제가 되풀이됩니다.

컨텍스트 크기와 비용은 따로 확인해야 합니다

요청 하나의 길이보다 완료 기준을 충족한 결과를 얻는 비용을 최적화합니다. 주 대화가 작아져도 작업 에이전트 호출, 검색 요청, 실패한 시도는 늘어날 수 있습니다.

문서에 나오는 지시 분량 기준을 비교하면 단위가 왜 중요한지 알 수 있습니다. Codex의 기본 프로젝트 문서 합산 상한은 32 KiB, 즉 32 × 1,024 = 32,768 bytes입니다. 토큰 예산이 아니라 바이트 한도입니다. Claude Code는 각 CLAUDE.md를 200줄 미만으로 유지하라고 권고합니다. 이는 작성 지침이며, 컨텍스트 윈도우의 강제 한도가 아닙니다. 어느 수치도 비용 절감량을 예측해 주지 않습니다. Codex 지시 한도, Claude Code 작성 지침.

운영 워크플로에서는 주 에이전트, 작업 에이전트, 압축, 검색, 재시도의 비용을 기록합니다. 그런 다음 아래와 같이 계산합니다.

완료 기준을 충족한 작업당 비용 = 모든 시도의 워크플로 총비용 ÷ 완료 기준을 충족한 작업 수.

월 예산을 계산할 때는 모델 사용료에 툴, 검색, 저장소, 호스팅 요금을 더합니다. 컨텍스트 엔지니어링에 정해진 단일 월 요금은 없습니다. 실제 워크로드와 적용되는 제공업체 요금 없이는 달러 기준 절감액을 타당하게 제시할 수 없습니다.

캐시까지 고려하면 비교가 더 복잡해집니다. OpenAI의 프롬프트 캐시는 최종 구성된 프롬프트의 앞부분이 일치할 때 이를 재사용합니다. 압축으로 요청이 짧아져도 그 앞부분이 달라지면 캐시 재사용은 줄어들 수 있습니다. 재사용할 지시는 가능한 한 안정적으로 유지하고, 변경 전후의 총비용을 비교합니다. 캐시 적중률이 낮아졌다는 사실만으로 최적화 실패를 단정할 수는 없습니다. OpenAI 프롬프트 캐싱.

GPT-6 프롬프트 캐싱 진단을 활용하면 프롬프트 앞부분의 변화로 생긴 문제와 불필요한 내용 때문에 생긴 문제를 구분할 수 있습니다. 캐시는 반복 입력을 더 저렴하게 처리하게 해 줍니다. 그 입력이 작업에 필요한지까지 판단해 주지는 않습니다.

컨텍스트 엔지니어링 실무에서는 무엇부터 바꿔야 하나요?

트레이스에서 컨텍스트 문제가 확인됐을 때, 그 원인을 해결할 가장 작은 변경을 적용합니다. 트레이스는 요청, 툴 호출, 결과의 순서를 기록한 것으로, 각 판단 전에 모델이 무엇을 봤는지도 포함합니다.

개발자는 잘못된 행동 직전의 단계를 살펴봅니다. 근거가 빠졌다면 검색을 고칩니다. 반복 출력에 근거가 묻혔다면 툴 결과를 필터링합니다. 이전 논의가 현재 작업보다 앞서 적용된다면 작업 상태와 인계 기록을 바로잡습니다. 분리할 수 있는 조사가 주 대화를 가득 채운다면 별도로 떼어냅니다.

운영자는 성공으로 인정할 결과를 정의하고, 대표적인 실패 사례를 평가용으로 보존합니다. 같은 작업을 대상으로 완료 품질, 근거 없는 주장, 재시도, 지연 시간, 총비용을 비교합니다. 결과를 해석할 수 있도록 한 번에 컨텍스트 정책 하나만 바꿉니다. 기존 트레이스를 활용해 오프라인 평가 사례를 설계합니다.

도입을 검토하는 담당자는 제품이 답변의 바탕이 된 컨텍스트와 툴 결과를 공개하는지, 요약 후에도 출처 참조를 보존하는지, 상시 지시를 직접 제어할 수 있는지 확인합니다. 무엇을 불러오는지 볼 수 없는 “메모리” 기능은 문제를 진단하기 어렵습니다.

짧고 범위가 명확한 워크플로가 이미 안정적으로 작동한다면 추가 장치 도입은 미룹니다. 메모리 서비스나 작업 에이전트 네트워크 없이, 지시를 더 명확히 하거나 툴의 오류 메시지를 개선하는 것만 필요할 수 있습니다. 잘못된 권한, 애플리케이션 로직의 결함, 원본 데이터의 부재가 실패 원인이라면 그 원인을 직접 해결합니다. 컨텍스트 선별만으로는 고칠 수 없습니다.

컨텍스트 엔지니어링에서 과장된 기대는 무엇인가요?

더 큰 컨텍스트 윈도우, 더 많은 메모리, 더 많은 에이전트는 처리 역량을 늘릴 뿐, 판단이 나아졌다는 근거가 되지는 않습니다. 따져야 할 것은 해당 워크플로에서 올바른 정보를 다음 단계로 전달하는 데 도움이 되는지입니다.

“프롬프트에 전부 넣자”는 선택을 피하는 방법이지만, 서로 경쟁하는 자료를 끌어들입니다. “전부 요약하자”는 중요한 예외까지 지운다면 지나치게 과감한 선별입니다. “서브에이전트에 맡기자”는 필수적인 결정 사항을 잃지 않고 작업을 넘길 수 있을 때만 도움이 됩니다.

가장 값비싼 실수는 요청을 짧게 만든 것을 시스템 검증과 혼동하는 것입니다. 잘못된 정책으로 저렴하게 답하는 에이전트도 여전히 틀립니다. 좋은 컨텍스트 정책은 답을 더 쉽게 검증할 수 있게 해야 합니다. 적용할 규칙이 보이고, 뒷받침하는 근거에 출처가 있으며, 아직 해소하지 못한 불확실성이 명시돼 있어야 합니다.

에이전트가 작업 목표를 놓칠 때 자주 묻는 질문

데모에서는 잘되던 에이전트가 운영 환경에서 실패하는 문제도 해결할 수 있나요?

근거 누락, 낡은 지시, 과도한 툴 출력, 작업 상태 유실은 컨텍스트 엔지니어링으로 개선할 수 있습니다. 먼저 실패한 요청을 살펴봅니다. 고장 난 툴, 잘못된 애플리케이션 로직, 모델 역량을 벗어난 작업은 각각 별도의 해결이 필요합니다. 대표 작업에서 완료 기준을 충족한 결과로 변경의 효과를 판단합니다.

시작하려면 벡터 데이터베이스나 멀티 에이전트 프레임워크가 필요한가요?

필요하지 않습니다. 명확한 프로젝트 지시, 필요한 부분에 집중한 파일·문서 검색, 범위가 제한된 툴 결과, 작업 인계 기록부터 시작합니다. 관련 자료를 찾는 데 필요해지면 의미 기반 검색을 추가하고, 독립적인 조사를 별도 컨텍스트에서 수행하는 편이 유리하면 서브에이전트를 도입합니다.

컨텍스트를 너무 많이 줄였는지는 어떻게 알 수 있나요?

다음 판단에 필요한 규칙, 뒷받침하는 근거, 적용 범위, 중요한 예외가 여전히 있는지 확인합니다. 삭제한 사실을 에이전트가 추측해야 한다면 너무 많이 줄인 것입니다. 다시 가져올 수 있는 출처를 남겨 두고, 발췌문만으로 답을 정할 수 없다면 읽는 범위를 넓힙니다.

이번 주에 바로 해볼 일: 이미 확보한 실패 기록에서 첫 번째 오작동 직전의 요청을 살펴봅니다. 그 안의 내용을 상시 지시, 현재 작업 상태, 지금 필요한 근거, 저장소에 남겨 둬도 되는 자료로 구분합니다. 그에 맞는 최소한의 변경을 적용한 뒤, 같은 평가 사례에서 결과와 워크플로 총비용을 비교합니다.

유용한 에이전트를 만들고 운영하는 실무 가이드를 받아보려면 뉴스레터를 구독하세요.