프롬프트 엔지니어링은 기본입니다. 컨텍스트 엔지니어링이 다음 개척지입니다.

Salesforce가 지난주에 발표한 내용 중 제가 계속 생각하고 있는 것이 있습니다. 그들은 프롬프트 엔지니어링 (Prompt Engineering, 질문을 최적화하는 것)과 컨텍스트 엔지니어링 (Context Engineering, 질문에 답하는 조건들을 최적화하는 것)을 구분하고 있습니다.

만약 당신이 AI 에이전트 (AI agents)를 활용해 구축 작업을 해온 지 몇 달이 넘었다면, 이 구분은 아마 공감이 갈 것입니다. 제 경험상 말씀드리자면, 대부분의 에이전트 실패 원인은 나쁜 프롬프트 때문이 아닙니다. 컨텍스트 (Context)가 누락되었거나, 잘못된 컨텍스트이거나, 혹은 에이전트가 필요할 때 접근할 수 없는 컨텍스트 때문입니다.

컨텍스트 엔지니어링이 실제로 다루는 범위

컨텍스트 엔지니어링은 에이전트를 중심으로 정보 아키텍처 (Information Architecture)를 설계하는 관행입니다. 구체적으로는 다음과 같습니다:

• 에이전트가 어떤 데이터 소스 (Data sources)를 볼 수 있는지 — 그리고 언제 볼 수 있는지
• 어떤 지식 베이스 (Knowledge bases)가 최신인지 — 그리고 그것들을 어떻게 갱신할 것인지
• 단일 턴 (Single turn)에 얼마나 많은 컨텍스트가 들어가는지 — 그리고 그렇지 못할 때 어떤 일이 발생하는지
• 쿼리 시점 (Query time)에 무엇이 검색되는지 — 그리고 검색 품질을 어떻게 검증할 것인지

마지막 항목이 실무적인 부분입니다. 대부분의 RAG (Retrieval-Augmented Generation, 검색 증강 생성) 설정은 재현율 (Recall)을 최적화합니다. 즉, 관련이 있을 법한 모든 것을 가져오는 것이죠. 하지만 에이전트에게는 정밀도 (Precision)가 더 중요합니다. 만약 50개의 문서를 검색하고 에이전트가 이를 합성해야 한다면, 당신은 지연 시간 (Latency)과 노이즈 (Noise)를 추가한 셈입니다. 만약 질문에 직접적으로 답하는 정확히 3개의 문서만 검색한다면, 에이전트는 더 빠르고 정확해집니다.

OpenClaw 특유의 컨텍스트 문제

OpenClaw의 메모리 시스템은 세션 상태 (Session state)와 파일 기반 컨텍스트를 처리합니다. 하지만 에이전트 워크플로 (Agentic workflows)를 구축할 때는 여러 계층에 걸친 컨텍스트를 고민해야 합니다:

1. 세션 컨텍스트 (Session context) — 현재 대화에 포함된 내용 (OpenClaw가 이를 처리합니다)
2. 에이전트 메모리 (Agent memory) — 이전 세션으로부터 에이전트가 이 사용자/프로젝트에 대해 알고 있는 내용
3. 도구 컨텍스트 (Tool context) — 도구를 호출하기 전 에이전트가 외부 시스템에 대해 알아야 하는 상태
4. 도메인 컨텍스트 (Domain context) — 에이전트가 사용할 수 있어야 하는 도메인 특화 지식

제가 목격한 대부분의 에이전트 실패는 세 번째 계층의 공백에서 발생합니다. 에이전트는 기술적으로 CRM API를 호출할 수 있지만, 올바르게 호출하기 위해 필요한 CRM의 상태에 대해 충분히 알지 못합니다. 도구는 정상 작동하지만, 에이전트에게 그것을 잘 사용할 컨텍스트가 없는 것입니다.

구체적인 사례

저는 서버 인프라를 관리하는 에이전트를 구축했습니다. 이 에이전트는 모니터링 도구, 배포 도구, 로그 뷰어에 접근할 수 있습니다. 간단해 보입니다.

실패 모드: 에이전트가 현재 배포 상태를 모르는 채로 배포 도구를 호출하는 일이 발생했습니다. 배포가 이미 진행 중인데도 배포를 시도하거나, 이미 재시작 중인 서비스를 다시 재시작하려 했습니다. 도구는 작동했습니다. 컨텍스트가 누락되었을 뿐입니다.

해결책은 워크플로 시작 부분에 상태 확인 단계를 추가하는 것이었습니다: "운영 도구를 호출하기 전에, 대상 시스템의 현재 상태를 확인하십시오."

이것은 프롬프트 변경이 아닙니다. 에이전트가 작업을 시도하기 전에 필요한 정보를 확보하도록 보장하는 컨텍스트 엔지니어링 (Context engineering)의 변화입니다.

제가 사용하는 실무 프레임워크

새로운 에이전트 워크플로 (Agentic workflow)를 설계할 때, 저는 이제 다음과 같은 질문을 던집니다:

1. 에이전트가 첫 번째 행동을 취하기 전에 알아야 할 것은 무엇인가? (초기 컨텍스트)
2. 에이전트가 각 주요 도구 호출을 하기 전에 알아야 할 것은 무엇인가? (도구 호출 전 컨텍스트)
3. 컨텍스트가 누락되었거나 오래된(stale) 경우 어떤 일이 발생하는가? (컨텍스트 실패 처리)
4. 에이전트는 컨텍스트의 품질을 어떻게 검증하는가? (컨텍스트 검증)

마지막 질문은 대부분의 사람들이 건너뛰는 부분입니다. 만약 에이전트(Agent)가 지식 베이스(Knowledge base)로부터 컨텍스트(Context)를 검색한다면, 그 검색이 올바른지 어떻게 알 수 있을까요? 이 지점에서 MCP 도구 계약(MCP tool contract)이 도움이 됩니다. MCP 서버가 컨텍스트를 제공하며, 만약 MCP 서버에 스키마(Schema)가 있다면 에이전트는 최소한 반환된 데이터가 예상된 구조와 일치하는지 검증(Validate)할 수 있습니다.

컨텍스트 엔지니어링(Context engineering)은 각 워크플로(Workflow)마다 구체적이고 다르기 때문에 프롬프트 엔지니어링(Prompt engineering)보다 어렵습니다. 하지만 그만큼 더 가치 있습니다. 컨텍스트의 격차(Context gap)를 해결하는 것은 모델이나 프롬프트를 전혀 변경하지 않고도 신뢰할 수 없던 에이전트를 신뢰할 수 있게 만들 수 있기 때문입니다.