훌륭한 AI 답변이라 할지라도 실제 비즈니스 시스템 내부에서는 여전히 무용지물처럼 느껴질 수 있습니다. 이 문장이 가혹하게 들릴 수도 있겠지만, 대부분의 배포 팀은 이런 상황을 경험해 보았습니다. 모델이 정책을 잘 설명하면서도 최신 계약 부속서(Annexure)를 무시하는 경우가 있습니다. 예를 들어, 챗봇이 질문은 이해하지만 고객의 열려 있는 티켓(open ticket)을 놓치기도 합니다. 영업 어시스턴트가 세련된 답변을 작성하지만, 해당 지역에서 사용할 수 없는 제품을 추천하기도 합니다. 문제는 언어의 품질인 경우가 거의 없습니다. 문제는 모델이 작업에 필요한 비즈니스 현실을 전달받지 못했다는 점입니다.

이것이 바로 컨텍스트 엔지니어링 (Context Engineering)이 오늘날 가장 진지한 AI 분야 중 하나가 된 이유입니다. 이는 주의를 영리한 지시어(instructions)에서 신뢰할 수 있는 정보 설계(information design)로 이동시킵니다. 프롬프트 엔지니어링 (Prompt Engineering)도 여전히 중요하지만, 엔터프라이즈 AI (enterprise AI)에는 잘 작성된 프롬프트 그 이상의 것이 필요합니다. 관련 데이터, 사용자 의도 (user intent), 메모리 (memory), 권한 (permissions), 도구 (tools), 워크플로 상태 (workflow state), 그리고 출력 제어 (output controls)가 필요합니다. 이 모든 것들이 적절한 순간에 모델에 도달해야 합니다.

타이밍이 중요한 이유는 AI 도입이 실험 단계를 넘어섰기 때문입니다. Stanford의 2025 AI Index 보고서에 따르면, 2024년에 AI를 사용한 조직은 78%로 전년도의 55%에서 증가했습니다. McKinsey의 2025 AI 설문조사에서도 응답자의 62%가 최소한 AI 에이전트 (AI agents)를 실험 중인 것으로 나타났으나, 거의 3분의 2는 기업 전반에 걸쳐 AI를 확장하기 시작하지 않았습니다. 이러한 격차가 현재 시장의 긴장 상태를 설명합니다. 기업들은 강력한 모델을 사용할 수 있지만, 많은 기업이 여전히 신뢰할 수 있는 컨텍스트 시스템 (context systems)이 부족한 실정입니다.

컨텍스트 엔지니어링 (Context Engineering)이란 무엇인가?

컨텍스트 엔지니어링 (Context Engineering)은 AI 시스템이 응답하거나 행동하기 전에 전달받는 정보를 설계, 조립, 관리 및 거버넌스(governing)하는 관행을 의미합니다. 여기에는 프롬프트 (prompt)가 포함되지만, 주변 데이터와 실행 환경 (execution environment)도 포함됩니다.

비즈니스 애플리케이션에서 그러한 컨텍스트 (context)에는 사용자 역할 (user role), 계정 이력 (account history), 제품 규칙 (product rules), 정책 문서 (policy documents), ERP 기록 (ERP records), CRM 활동 (CRM activity), 서비스 티켓 (service tickets), 가격 조건 (pricing conditions), 승인 한도 (approval limits), 그리고 현재 워크플로 단계 (workflow stage)가 포함될 수 있습니다. 모델은 이러한 세부 사항을 추측해서는 안 됩니다. 시스템은 이를 구조화되고 (structured), 안전하며 (secure), 비용 효율적인 (cost-aware) 방식으로 제공해야 합니다.

LangChain은 컨텍스트 엔지니어링 (Context Engineering)을 LLM이 작업을 완료할 수 있도록 적절한 형식으로 적절한 정보와 도구를 제공하는 동적 시스템 (dynamic systems)을 구축하는 것으로 정의합니다. Anthropic은 컨텍스트를 AI 에이전트 (AI agents)를 위한 결정적이고 유한한 자원 (critical and finite resource)으로 설명합니다. 이러한 정의들은 동일한 개념을 가리키고 있습니다. 가장 강력한 AI 시스템은 단 하나의 완벽한 프롬프트 (prompt)에 의존하지 않습니다. 그들은 모델 주변의 전체 정보 환경 (information environment)을 관리합니다.

이를 프레임화하는 간단한 방법은 다음과 같습니다. 프롬프트 엔지니어링 (Prompt Engineering)은 모델에게 어떻게 행동할지를 알려줍니다. 컨텍스트 엔지니어링 (Context Engineering)은 모델에게 무엇을 알아야 하는지, 무엇을 사용할 수 있는지, 그리고 무엇에 접근해서는 안 되는지를 제공합니다.

프롬프트 엔지니어링만으로는 더 이상 충분하지 않은 이유
프롬프트 엔지니어링은 초기 LLM을 사용 가능하게 만들었기 때문에 대중화되었습니다. 더 나은 지침 (instructions)은 어조 (tone), 구조 (structure), 추론 스타일 (reasoning style), 그리고 출력 형식 (output format)을 개선했습니다. 이는 팀들이 모호한 챗봇 답변에서 반복 가능한 비즈니스 응답으로 나아가는 데 도움을 주었습니다.

그 단계는 필수적이었습니다. 모델이 제약 조건 (constraints), 예시 (examples), 역할 (roles), 그리고 포맷팅 (formatting)에 어떻게 반응하는지를 팀들에게 가르쳐 주었습니다. 하지만 많은 엔터프라이즈 워크플로 (enterprise workflows)는 정적인 글쓰기 작업이 아닙니다. 여기에는 변화하는 데이터, 사용자 권한 (user permissions), 비즈니스 예외 사항 (business exceptions), 그리고 도구 결정 (tool decisions)이 포함됩니다.

프롬프트는 "최신 정책을 사용하여 답변하세요"라고 말할 수 있습니다. 하지만 최신 정책이 실제로 검색되었는지는 보장할 수 없습니다. 프롬프트는 "기밀 데이터를 공개하지 마세요"라고 말할 수 있습니다. 하지만 그것이 접근 제어 (access control)를 대체할 수는 없습니다. 프롬프트는 "견적을 생성하세요"라고 말할 수 있습니다. 하지만 프롬프트 스스로 가격, 재고, 세금, 마진 (margin), 그리고 승인 규칙을 검증할 수는 없습니다.

이 지점에서 AI 컨텍스트 관리 (AI Context Management)가 필수적이 됩니다. 시스템은 어떤 문서를 검색할지, 어떤 기억을 유지할지, 어떤 도구 (tools)를 노출할지, 그리고 어떤 정보를 제거할지를 결정해야 합니다. 또한 모델이 무엇을 보았는지, 왜 그것을 보았는지, 그리고 그 컨텍스트 (context)가 충분했는지 여부도 추적해야 합니다.

엔터프라이즈 AI (Enterprise AI)의 경우, 프롬프트 (prompt)는 더 큰 설계의 한 구성 요소가 됩니다. 진짜 작업은 모델을 중심으로 반복 가능한 컨텍스트 파이프라인 (context pipelines)을 구축하는 것입니다.

컨텍스트 윈도우 (Context Windows) 설명
컨텍스트 윈도우 (Context Window)는 LLM (Large Language Model)이 단일 요청 동안 참조할 수 있는 텍스트의 양을 토큰 (tokens) 단위로 측정한 것입니다. 여기에는 시스템 메시지 (system message), 사용자 프롬프트 (user prompt), 대화 기록 (conversation history), 검색된 문서 (retrieved documents), 도구 출력값 (tool outputs), 그리고 생성된 응답 (generated response)이 포함됩니다. IBM과 Anthropic은 모두 컨텍스트 윈도우를 요청에 대한 모델의 작업 기억 (working memory)으로 설명합니다.

더 긴 윈도우는 AI 애플리케이션이 시도할 수 있는 범위를 변화시켰습니다. Google의 Gemini 문서는 100만 토큰 길이의 롱 컨텍스트 (long context)를 논의하며, Anthropic은 Claude Opus 4.6 beta를 위해 100만 토큰 컨텍스트를 발표했습니다. 이를 통해 더 큰 문서, 코드베이스 (codebases), 전사 기록 (transcripts), 그리고 사례 기록 (case histories)을 하나의 요청 안에 담을 수 있습니다.

하지만 더 큰 컨텍스트 윈도우 (Context Window)가 컨텍스트 품질을 해결해주지는 않습니다. 더 많은 텍스트는 지연 시간 (latency), 비용, 그리고 주의력 희석 (attention dilution)을 증가시킬 수 있습니다. Anthropic의 컨텍스트 윈도우 문서는 또한 토큰 수가 증가함에 따라 정확도 (accuracy)와 회상 (recall) 능력이 저하될 수 있기 때문에, 더 많은 컨텍스트가 자동으로 더 나은 것은 아니라고 경고합니다.

이로 인해 LLM 컨텍스트 (LLM Context) 설계는 우선순위 결정 문제 (prioritization problem)가 됩니다. 질문은 얼마나 많은 정보를 담을 수 있느냐가 아닙니다. 더 나은 질문은 이 작업을 위해 어떤 정보가 그곳에 있을 가치가 있느냐 하는 것입니다.

장기 기억 vs 단기 기억

AI 메모리 (AI Memory)는 종종 모든 것을 기억한다는 의미로 논의되곤 합니다. 그러한 접근 방식은 노이즈 (noise), 리스크 (risk), 그리고 비용을 발생시킵니다. 엔터프라이즈 시스템에는 명확한 목적을 가진 여러 개의 메모리 계층 (memory layers)이 필요합니다.

단기 메모리 (Short-term memory)는 현재의 상호작용을 일관되게 유지합니다. 사용자의 마지막 몇 차례의 대화(turns), 활성화된 양식 필드 (form fields), 선택된 레코드 (selected record), 그리고 즉각적인 작업 (immediate task)을 기억합니다. 이 메모리는 연속성을 위해 유용하지만, 빠르게 소멸되어야 합니다.

장기 메모리 (Long-term memory)는 향후의 상호작용을 개선하는 지속적인 사실들을 저장합니다. 엔터프라이즈 시스템에서 이는 고객 선호도, 사용자 역할 패턴 (user role patterns), 반복되는 예외 사항 (recurring exceptions), 제품 매핑 (product mappings), 또는 프로세스 학습 (process learning) 등을 포함할 수 있습니다. 이 데이터는 향후 결정에 영향을 미칠 수 있으므로 거버넌스 (governance)가 필요합니다.

Write on Medium
에피소드 메모리 (Episodic memory)는 중요한 과거 사건들을 저장합니다. 예를 들어, AI 지원 에이전트는 고객이 지난달에 세 번의 에스컬레이션 (escalations) 실패를 겪었다는 사실을 기억할 수 있습니다. 운영 메모리 (Operational memory)는 승인 단계 (approval stage), 대기 중인 문서 (pending documents), 실패한 통합 (failed integrations), 그리고 열려 있는 의존성 (open dependencies)과 같은 프로세스 상태 (process state)를 저장합니다.

최상의 AI 에이전트 컨텍스트 (AI Agent Context) 시스템은 이러한 메모리 유형들을 분리합니다. 모든 과거 상호작용을 모든 요청에 밀어 넣지 않습니다. 대신 작업 (task), 역할 (role), 최신성 (recency), 권한 (permission), 그리고 비즈니스 영향력 (business impact)을 기반으로 메모리를 선택합니다.

컨텍스트로서의 검색 (Retrieval as Context)

검색 (Retrieval)은 정적인 모델 지식과 살아있는 엔터프라이즈 진실 (enterprise truth) 사이의 가교 역할을 합니다. RAG로 알려진 검색 증강 생성 (Retrieval-Augmented Generation)은 언어 모델을 외부 지식 소스와 결합합니다. 오리지널 RAG 논문은 명시적인 비매개변수적 메모리 (non-parametric memory)가 어떻게 모델이 지식 집약적 작업 (knowledge-intensive tasks)에 대해 더 사실적이고 구체적인 결과물을 내놓으며 답변하도록 도울 수 있는지 설명했습니다.

엔터프라이즈의 경우, 컨텍스트 검색 (Context Retrieval)은 대개 문서에서 시작됩니다. 정책 (policies), 계약서 (contracts), 매뉴얼 (manuals), 제안서 (proposals), 티켓 (tickets), 이메일 (emails), 제품 시트 (product sheets), 송장 (invoices), 그리고 표준 운영 절차 (SOPs)가 검색 가능한 지식 소스가 됩니다. 시스템은 관련 청크 (chunks)를 임베딩 (embeds), 인덱싱 (indexes), 필터링 (filters), 랭킹 (ranks)하여 모델에 반환합니다.

기본적인 검색 (Basic retrieval)만으로는 더 이상 진지한 사용 사례 (use cases)를 충족하기에 충분하지 않습니다. 이제 팀에는 메타데이터 필터 (metadata filters), 하이브리드 검색 (hybrid search), 재순위화 (reranking), 문서 권한 (document permissions), 인용 추적 (citation tracking), 최신성 확인 (freshness checks), 그리고 쿼리 재작성 (query rewriting) 기능이 필요합니다. 법률 관련 답변에는 조항 수준의 참조 (clause-level references)가 필요할 수 있습니다. 서비스 관련 답변에는 최신 티켓 상태 (latest ticket status)가 필요할 수 있습니다. ERP 관련 답변에는 실시간 재고 및 고객 신용 데이터가 필요할 수 있습니다.

훌륭한 검색은 컨텍스트 인식 AI (Context-Aware AI)가 근거가 확실하다고 느끼게 만듭니다. 반면, 형편없는 검색은 강력한 모델조차 잘못된 증거를 바탕으로 자신 있게 말하게 만듭니다.

AI 관측성 (AI Observability)

컨텍스트 엔지니어링 (Context Engineering)이 성숙해짐에 따라, 조직은 컨텍스트가 실제로 AI 성능을 개선하고 있는지 측정할 수 있는 더 나은 방법도 필요하게 되었습니다. 이는 기업용 AI 분야에서 가장 빠르게 성장하는 영역 중 하나인 AI 관측성 (AI Observability)의 등장으로 이어졌습니다.

전통적인 애플리케이션 모니터링 (application monitoring)은 인프라, 가동 시간 (uptime), 그리고 시스템 상태 (system health)에 집중합니다. AI 시스템은 다른 계층의 가시성 (visibility)을 요구합니다. 팀은 올바른 컨텍스트가 모델에 도달했는지, 검색 (retrieval)이 관련성 있는 증거를 생성했는지, 응답이 사실 관계를 유지했는지, 그리고 시스템이 얼마나 효율적으로 작업을 완료했는지를 이해해야 합니다.

여러 지표가 프로덕션 AI의 표준이 되고 있습니다. 컨텍스트 품질 (Context quality)은 모델에 제공된 정보가 관련성이 있고 충분했는지를 측정합니다. 환각률 (Hallucination rate)은 모델이 근거가 없거나 부정확한 정보를 얼마나 자주 생성하는지 추적합니다. 검색 성공률 (Retrieval success)은 검색 계층이 정확한 응답에 필요한 증거를 반환했는지 평가합니다. 평가 프레임워크 (Evaluation frameworks)는 출력값을 예상 결과와 비교하여 일관성과 작업 완료도를 측정합니다. 지연 시간 (Latency)은 전체 컨텍스트 파이프라인이 정보를 검색하고, 도구를 호출하며, 응답을 생성하는 속도를 모니터링합니다.

도구 호출 및 액션 컨텍스트 (Tool Calling and Action Context)
[IMG:1]

Enterprise AI는 시스템 내부에서 동작할 수 있을 때 더욱 유용해집니다. 도구 호출 (Tool calling)은 LLM이 정의된 스키마 (schemas)를 통해 외부 함수, API, 데이터베이스 또는 워크플로 (workflows)를 호출할 수 있게 합니다. OpenAI의 함수 호출 (function calling) 문서는 이를 모델이 애플리케이션에서 제공하는 데이터와 액션 (actions)에 접근하는 방법으로 설명합니다.

도구 호출은 컨텍스트 엔지니어링 (Context Engineering)에 새로운 계층을 추가합니다. 모델은 어떤 도구가 존재하는지, 언제 사용해야 하는지, 어떤 입력값이 필요한지, 그리고 어떤 리스크를 수반하는지를 반드시 알고 있어야 합니다. 읽기 전용 고객 조회 (read-only customer lookup)는 주문을 확인하는 것과는 다릅니다. 견적 미리보기 (quote preview)는 인보이스 (invoice)를 발행하는 것과는 다릅니다.

이것이 바로 프로덕션 AI 에이전트 (AI agents)에게 단순한 도구 접근 권한이 아닌, 도구 컨텍스트 (tool context)가 필요한 이유입니다. 도구 설명은 구체적이어야 합니다. 입력값은 검증되어야 합니다. 민감한 액션은 확인 절차를 필요로 해야 합니다. 백엔드 시스템은 모델이 올바른 도구를 선택하더라도 권한 (permissions)을 강제해야 합니다.

AI 에이전트 컨텍스트 (AI Agent Context)에는 액션 메모리 (action memory)도 필요합니다. 에이전트는 무엇을 이미 확인했는지, 무엇이 실패했는지, 무엇이 오래된 데이터 (stale data)를 반환했는지, 그리고 무엇이 여전히 승인을 기다리고 있는지를 알고 있어야 합니다. 이것이 없다면 다단계 워크플로 (multi-step workflows)는 반복적이고 취약해집니다.

Model Context Protocol, MCP
Model Context Protocol, 또는 MCP는 이 분야에서 가장 중요한 발전 중 하나입니다. 공식 MCP 문서는 이를 데이터 소스, 도구 및 워크플로를 포함한 외부 시스템에 AI 애플리케이션을 연결하기 위한 개방형 표준 (open standard)으로 설명합니다. Anthropic은 2024년에 AI 도구와 데이터 소스 간의 안전한 양방향 연결을 위한 표준으로 MCP를 도입했습니다.

MCP가 중요한 이유는 AI 애플리케이션이 컨텍스트를 발견하고 사용하는 일관된 방식이 필요하기 때문입니다. 표준이 없다면 모든 통합 (integration)은 맞춤형 브리지 (custom bridge)가 되어야 합니다. 이는 개발 속도를 늦추고 보안 격차를 증가시킵니다.

기업 팀의 경우, MCP는 에이전트(agents)를 파일 시스템, CRM, ERP, 티켓팅 시스템, 코드 저장소(code repositories), 분석 플랫폼 및 내부 도구와 연결하는 데 도움을 줄 수 있습니다. 하지만 MCP 그 자체만으로는 완전한 거버넌스 (governance) 전략이 될 수 없습니다. 신원 (Identity), 권한 부여 (authorization), 감사 로그 (audit logging), 도구 위험 수준 (tool risk levels) 및 승인 흐름 (approval flows)은 여전히 이를 중심으로 설계되어야 합니다.

훌륭한 MCP 구현은 모델이 동작하기 전에 네 가지 질문에 답할 수 있어야 합니다. 사용자는 누구인가? 요청은 무엇인가? 어떤 컨텍스트 (context)가 허용되는가? 어떤 작업에 인간의 승인이 필요한가?

컨텍스트 압축 기술 (Context Compression Techniques)
에이전트가 더 긴 작업을 수행함에 따라 컨텍스트는 빠르게 증가합니다. 대화 기록이 확장됩니다. 도구 출력값 (tool outputs)이 쌓입니다. 검색된 문서들이 유사한 사실을 반복합니다. 압축이 없다면 모델은 너무 많은 짐을 지게 됩니다.

컨텍스트 압축 (Context compression)은 작업에 중요한 의미를 보존하면서 토큰 부하 (token load)를 줄여줍니다. 이는 오래된 대화 턴을 요약하거나, 무관한 도구 출력을 제거하거나, 중복된 사실을 병합하거나, 구조화된 엔티티 (structured entities)를 추출하거나, 결정에 관련된 상태 (state)만 유지할 수 있습니다.

압축에는 위험이 따릅니다. 부실한 요약은 나중에 중요해질 제약 조건을 누락할 수 있습니다. 고객 지원 에이전트가 고객이 임시 방편을 거부했다는 사실을 잊을 수 있습니다. 금융 어시스턴트가 승인과 관련된 예외 사항을 놓칠 수 있습니다. 이것이 압축이 작업 유형 및 평가 (evaluation)와 연계되어야 하는 이유입니다.

LangChain은 에이전트 컨텍스트 전략을 쓰기 (write), 선택 (select), 압축 (compress), 격리 (isolate)로 그룹화합니다. 이러한 프레임워크는 기업 아키텍처 (enterprise architecture)에 유용합니다. 쓰기 (Write)는 유용한 정보를 저장합니다. 선택 (Select)은 컨텍스트 창 (window)에 들어올 내용을 결정합니다. 압축 (Compress)은 부하를 줄입니다. 격리 (Isolate)는 관련 없는 컨텍스트를 분리하여 에이전트들이 서로를 오염시키지 않도록 합니다.

전체 블로그 읽기 — Context Engineering: The Next Evolution After Prompt Engineering