한 줄로 말하면
컨텍스트 엔지니어링은 모델이 지금 일을 제대로 판단하도록, 그 순간 필요한 지시·자료·도구 결과·기억을 골라 한 작업대에 올려놓는 설계야.
비유로 이해하기
긴 현장 작업을 하는 사람에게 창고 전체를 책상 위에 쏟아 주면 오히려 일을 못 해. 오늘 할 일, 안전 수칙, 직전 작업 결과, 꼭 필요한 도면만 꺼내 줘야 해.
언어모델도 비슷해. 한 번의 호출에서 보는 텍스트와 도구 결과에는 한계가 있고, 중요한 사실이 너무 많은 주변 정보에 묻히면 다음 행동이 흔들릴 수 있어. Anthropic은 retrieval, tools, memory를 붙인 augmented LLM을 에이전트 시스템의 기본 블록으로 보고, 모델이 검색 질의·도구 선택·남길 정보를 스스로 정할 수 있다고 설명해.1 그래서 필요한 것을 제때 꺼내고, 끝난 일은 짧게 정리하며, 나중에 다시 찾아올 수 있게 보관하는 설계가 필요해.
이 비유는 여기까지야. 실제 시스템은 종이 더미를 정리하는 것보다 복잡해. 어떤 정보가 사실인지, 누가 볼 수 있는지, 어느 시점의 정보인지, 도구가 낸 결과를 믿어도 되는지까지 함께 다뤄야 해.
정확한 정의
컨텍스트는 모델에 지금 전달되는 작업 환경이야. 시스템 지시, 사용자의 요청, 대화 일부, 검색한 문서, 파일 내용, 도구의 반환값, 이전 작업의 요약이 여기에 들어갈 수 있어.
컨텍스트 엔지니어링은 이 재료를 무작정 많이 넣는 일이 아니야. 지금 목표에 필요한 정보를 고르고, 우선순위를 정하고, 오래된 기록은 요약하거나 밖에 보관했다가 필요할 때 다시 가져오는 일이야. agent loop가 결과를 보고 다음 행동을 고르는 구조라면, 컨텍스트 엔지니어링은 그 다음 판단에 무엇을 보여 줄지 정하는 구조라고 볼 수 있어.
OpenAI Agents SDK는 이 경계를 런타임 기능으로 쪼개 보여줘. 내장 agent loop는 도구 호출을 처리하고 결과를 다시 LLM에 넘긴 뒤 과제가 끝날 때까지 반복하고, handoff는 다른 agent에게 일을 넘기며, session은 agent loop 안에서 작업 맥락을 유지하는 지속 기억층으로 설명돼.2 같은 모델 호출이라도 무엇을 session에 남기고, 무엇을 handoff로 넘기고, 무엇을 tracing으로 관찰할지가 달라지면 다음 호출의 판단 재료도 달라져.
flowchart TD A["현재 목표"] --> B["필요한 지시와 자료 선택"] B --> C["모델의 판단과 도구 실행"] C --> D["결과 확인"] D --> E["중요한 기록 저장·요약"] E --> B F["권한·최신성·출처 확인"] -.-> B F -.-> D
이 그림에서 핵심은 선택이야. 같은 문서라도 지금 과제에 직접 필요한 부분은 원문으로 남기고, 이미 끝난 과정은 짧은 기록으로 바꾸며, 나중에만 필요할 사실은 검색 가능한 곳에 둘 수 있어. 어느 쪽이 맞는지는 과제의 위험, 최신성, 비용, 다시 확인할 필요에 따라 달라져.
왜 중요한가
agentic workflow가 길어질수록 모델은 더 많은 도구 결과와 이전 결정을 마주해. Anthropic은 agent가 실행 중 도구 결과나 코드 실행 결과 같은 환경의 ground truth를 단계마다 받아 진행 상황을 평가해야 한다고 설명해.1 처음 목표를 잃으면 같은 일을 반복하거나, 이미 확인한 사실을 놓치거나, 권한 밖의 행동을 제안할 수 있어.
반대로 모든 기록을 계속 붙이는 것도 답은 아니야. 관련 없는 대화와 오래된 결과가 늘어나면 중요한 조건이 묻히고, 처리 비용과 지연도 커져. 컨텍스트 엔지니어링은 모델을 더 똑똑하게 만드는 주문이 아니라, 제한된 작업 공간을 현재 과제에 맞게 쓰는 방법이야.
특히 사람의 정보, 사내 문서, 외부 도구가 섞인 작업에서는 무엇을 보여 주지 않을지도 중요해. Anthropic이 프레임워크의 과한 추상화가 underlying prompts and responses를 가려 디버깅을 어렵게 할 수 있다고 경고하는 이유도 여기와 이어져.1 필요한 정보만 보이게 하는 일은 성능을 위한 정리이면서 권한과 보안을 지키는 경계이기도 해.
실제 예시
고객 문의를 처리하는 에이전트를 생각해 보자. 다음 답을 만들 때 제품 정책 전체, 고객의 모든 대화, 회사의 모든 문서를 한꺼번에 넣을 필요는 없어. 현재 문의, 고객의 최근 주문 상태, 적용되는 정책 조항, 직전에 한 약속, 필요한 조회 도구 결과가 우선이야.
대화가 길어지면 이전 발언을 그대로 모두 들고 가기보다, 합의한 사실과 아직 풀리지 않은 질문을 요약해 다음 단계에 넘길 수 있어. 다만 환불 금액이나 배송 상태처럼 다시 확인해야 할 사실은 요약문만 믿지 않고 원래 시스템에서 다시 조회해야 해.
코드 작업도 마찬가지야. 수정할 파일, 테스트 실패 메시지, 프로젝트 규칙은 다음 행동에 가까이 둬야 해. OpenAI Agents SDK가 Responses API를 직접 쓰는 경우와 SDK를 쓰는 경우를 나눌 때, SDK 쪽에는 turns, tool execution, guardrails, handoffs, sessions 관리를 맡기고 싶을 때를 둬.2 반면 이미 해결한 오류의 자세한 로그는 짧은 기록으로 남기거나 필요할 때 찾아보게 하는 편이 나을 수 있어.
헷갈리지 말아야 할 점
- 컨텍스트 엔지니어링은 프롬프트 작성과 같은 말이 아니야. 프롬프트는 중요한 한 부분이지만, 실제 작업에서는 도구 결과, 문서, 대화 기록, 권한 조건도 함께 판단 재료가 돼.
- 장기 기억과도 같지 않아. 기억은 여러 작업 사이에 남겨 둘 사실을 뜻하고, 컨텍스트는 지금 호출에서 모델이 실제로 보는 범위야. 남긴 기억도 현재 일에 필요할 때 골라 와야 해.
- 검색만 잘 붙이면 끝나는 일도 아니야. 검색은 외부 기록에서 필요한 자료를 가져오는 한 방법일 뿐이야. 가져온 자료의 최신성, 출처, 우선순위, 서로의 충돌도 따로 다뤄야 해.
- 긴 컨텍스트가 항상 좋은 것은 아니야. 더 많은 정보를 담을 수 있어도, 지금 판단에 필요한 정보가 무엇인지 정리하지 않으면 중요한 조건이 묻힐 수 있어.
- 요약은 원문을 대체하지 않아. 요약은 다음 행동을 빠르게 돕지만, 사실 확인이 중요한 순간에는 원래 문서나 시스템 기록으로 돌아가야 해.
- handoff는 단순 전달이 아니야. 다른 에이전트에게 넘길 때는 목표, 지금까지 확인한 사실, 넘기지 말아야 할 권한 조건이 함께 정리돼야 해. 이름만 바꿔 넘기면 다음 모델 호출은 맥락을 잃어.
관련 문서
- 도구 실행과 검증을 묶는 큰 작업 흐름: agentic workflow
- 결과를 읽고 다음 행동을 고르는 반복 구조: agent loop
- 모델이 외부 도구와 자료에 연결되는 규약: Model Context Protocol(MCP)
남은 질문들
- 긴 작업에서 원문, 요약, 검색 결과를 각각 언제 남기고 언제 버려야 할까?
- 모델이 이전 기록을 잘못 요약했을 때, 어떤 정보는 원문으로 다시 확인하게 해야 할까?
- 컨텍스트 창이 커져도 정보 선택과 순서가 계속 중요한 이유를 어떤 벤치마크로 확인할 수 있을까?
- 여러 에이전트가 같은 일을 나눠 할 때, 각자가 무엇을 공유하고 무엇을 분리해야 충돌을 줄일 수 있을까?
댓글