월간 AX 인사이트 Vol.2 — 컨텍스트 엔지니어링: 모델은 상품, 컨텍스트가 해자다

12개월의 갈림길: 두 임원이 목격한 동일 모델의 다른 결과

2024년 4월, 한 대기업 그룹사의 디지털전략팀장 A씨는 생성형 AI 전사 도입을 선언했습니다. 사내 공문에는 "생성형 AI로 업무 효율 30% 향상"이라는 목표가 명시되었고, GPT-4o 엔터프라이즈 라이선스 200석이 배포되었습니다. 임원들은 그 결정을 박수로 맞이했고, IT 팀은 3주 만에 모든 임직원의 노트북에 접속 계정을 세팅했습니다. 시작은 완벽했습니다.

12개월이 지난 2025년 4월, 같은 회의실에서 A씨는 CFO로부터 동일한 질문을 받았습니다. "ROI가 얼마입니까?" 그는 사용률 수치를 꺼냈습니다. 월간 활성 사용자 67%, 일평균 세션 수 1,240건. 그러나 CFO가 원하는 답은 달랐습니다. "AI 덕분에 무슨 의사결정이 달라졌습니까? 어떤 비용이 줄었습니까? 어떤 업무가 사라졌습니까?" A씨는 그 질문에 답하지 못했습니다. 직원들이 AI에게 무엇을 묻고, AI가 어떤 맥락에서 어떤 판단을 내렸으며, 그 판단이 실제 의사결정에 어떻게 반영되었는지를 조직이 단 한 줄도 기록하지 않았기 때문입니다.

같은 시점, B사의 전략기획 임원 B씨는 다른 보고를 했습니다. 그의 팀은 12개월 전 AI 도입에 앞서 먼저 한 가지 질문을 던졌습니다. "AI에게 무엇을 알려주어야 하는가?" 이 질문을 출발점 삼아 B씨의 팀은 8주에 걸쳐 구매승인 규정집·공급망 이력 데이터베이스·품질관리 SOP 문서를 AI가 실시간으로 참조할 수 있는 구조로 재편했습니다. AI가 쿼리를 받을 때마다 해당 문서의 적절한 섹션을 자동으로 검색하고, 직원별 역할과 권한에 따라 다른 정보 범위를 적용했습니다. 12개월 후, 구매팀의 공급업체 심사 초안 작성 시간은 평균 4.2시간에서 38분으로 단축되었고, 이 수치는 CFO 주재 임원회의에서 공식 KPI로 채택되었습니다.

두 사례에서 사용한 기반 모델은 성능 면에서 동등한 대역에 속합니다. 차이는 단 하나입니다. B사의 AI는 매 대화를 시작할 때마다 조직의 집단 지식과 운영 규칙을 등에 업고 있었고, A사의 AI는 매번 빈 서판으로 대화를 시작했습니다. 이것이 이번 호의 핵심 렌즈입니다: 컨텍스트 엔지니어링(Context Engineering). Anthropic이 2025년부터 공식 카테고리로 명명하고, 산업 전반이 "모델은 commodity, context는 moat"라는 합의를 향해 수렴하고 있는 개념입니다. 이 개념을 이해하지 못한 채 AI 예산을 집행하는 의사결정권자는, 12개월 후 A씨와 같은 회의실에 앉게 됩니다.

왜 지금 이 질문인가: 1차 도입 실망 사이클과 한국의 macro 신호

글로벌 리서치가 동시에 가리키는 한 방향

2025년은 엔터프라이즈 AI 도입의 첫 번째 대규모 실망 사이클이 가시화된 해입니다. Gartner의 2025년 4분기 CIO Agenda 서베이에 따르면, 생성형 AI 파일럿을 운영 중인 기업의 61%가 "초기 기대에 비해 현저히 낮은 비즈니스 임팩트"를 보고했습니다. Foundry(IDG)의 동기간 조사에서는 AI 프로젝트에 투자한 IT 예산 중 실질 ROI를 정량 측정 가능한 수준으로 보고한 기업 비율이 29%에 그쳤습니다. BCG의 2025년 "AI at Scale" 리포트는 더 냉혹합니다: "Most enterprises are still in the configuration phase of AI — adopting tools, not redesigning workflows."

McKinsey의 "The State of AI 2025"는 이 격차의 근본 원인을 다음과 같이 진단합니다.

"Most organizations are using AI on top of their existing information architecture rather than redesigning information flows for AI-native operations. The result is AI that is capable but context-starved."

번역하면: 대부분의 기업이 AI를 기존 정보 구조 위에 얹는 방식으로 사용하고 있으며, 컨텍스트가 결핍된 AI를 운영하고 있다는 것입니다. "컨텍스트 결핍"이라는 표현이 McKinsey의 공식 진단 언어로 등장했다는 사실 자체가 업계의 합의가 어느 방향으로 수렴되는지를 보여줍니다.

Anthropic의 Engineering Blog(2025)는 더 직접적입니다: "Context engineering is the practice of designing and curating the information that AI systems receive, to maximize the reliability and quality of their outputs in production environments. It is distinct from prompt engineering in that it operates at the organizational level, not the individual level." Anthropic은 이를 프롬프트 엔지니어링의 후속 개념이 아닌, 조직 역량 카테고리로 분류했습니다. Anthropic이 이 용어를 공식 카테고리로 채택한 시점은 2025년 하반기이며, 그 이후 LangChain·LlamaIndex·Google Vertex AI 등 주요 AI 인프라 벤더들이 동일한 언어를 채택하기 시작했습니다.

한국 시장의 세 가지 macro 신호

한국 시장에서 이 논의가 특히 시급한 이유는 세 가지 macro 신호가 2026년 상반기를 기점으로 수렴하고 있기 때문입니다.

신호 1: AI 예산 증가율 둔화와 CFO의 재검토. 2025년 한국 대기업 IT 예산에서 AI 관련 항목의 증가율이 전년 대비 급격히 둔화되었습니다. 한국IDC의 2026년 1분기 보고서에 따르면, 대기업 신규 AI 투자 증가율은 2024년 43%에서 2026년 예상 18%로 하락했습니다. 이는 초기 투자가 기대에 미치지 못했다는 신호로, CFO와 이사회가 AI 예산 집행에 증거를 요구하기 시작했음을 의미합니다. 이 압박 속에서 컨텍스트 엔지니어링을 통한 명확한 ROI 측정이 AI 예산 방어의 핵심 도구가 됩니다.

신호 2: 이사회 차원의 AI 거버넌스 요구 급증. 금융감독원은 2025년 하반기부터 금융권 AI 사용에 대한 감사 로그 의무화 지침을 준비하고 있습니다. 대기업 그룹사 준법팀에서는 AI 출력물의 근거 추적 가능성을 내부 규정에 포함시키기 시작했습니다. 이는 AI가 어떤 정보를 바탕으로 무엇을 출력했는지—즉 컨텍스트의 추적 가능성—를 시스템적으로 관리해야 하는 외부 압력이 생겨났음을 의미합니다. 컨텍스트 엔지니어링 없이는 이 요건을 충족할 수 없습니다.

신호 3: PoC 성공-실운영 실패의 반복. 현장에서 반복 관찰되는 패턴이 있습니다. PoC 단계에서는 벤더가 정제된 샘플 데이터를 준비해 AI가 인상적인 결과를 보여주지만, 실운영 단계에서 직원들이 실제 비정형 업무 데이터로 AI를 사용하면 품질이 현저히 저하됩니다. 이 격차가 1차 도입 실패의 주된 패턴입니다. PoC 컨텍스트와 운영 컨텍스트의 간극—이것이 컨텍스트 엔지니어링이 해결해야 할 핵심 문제입니다.

이 호가 지금 결정적인 이유

Vol.1에서 우리는 "운영 컨텍스트의 외재화"를 AX(AI Transformation)의 선결 과제로 제시했습니다. 그 연장선에서 이번 호는 그 외재화를 어떻게 시스템으로 구축하는가—즉 컨텍스트 엔지니어링의 구체적인 방법론—를 다룹니다. 2026년 하반기는 한국 기업들이 1차 파일럿의 결론을 내리고 2차 투자를 결정하는 분기점입니다. 이 결정의 질은 컨텍스트 엔지니어링을 이해하느냐 모르느냐에 달려 있습니다. 이 호를 읽고 나서 첫 번째 내리는 의사결정은, 다음 AI 예산을 어디에 쓸 것인가가 아니라 어떤 업무 영역의 컨텍스트를 먼저 구축할 것인가이어야 합니다.

컨텍스트 엔지니어링이란 무엇인가: 정의, 구성요소, 그리고 오해

한 문장으로 기억할 정의

컨텍스트 엔지니어링을 한 문장으로 정의하면 이렇습니다: AI가 매 대화·매 작업에서 접근할 수 있는 정보 집합을 조직 차원에서 설계·구조화·유지관리하는 역량. 이는 개인의 프롬프트 작성 기술이 아닌, 조직이 보유한 지식과 규칙을 AI가 활용 가능한 형태로 지속적으로 관리하는 시스템 역량입니다.

프롬프트 엔지니어링과의 차이는 규모와 영속성에 있습니다. 프롬프트 엔지니어링은 특정 쿼리를 더 잘 표현하는 개인 기술입니다. 담당자가 바뀌면 품질이 달라지고, 다음 대화에 이어지지 않으며, 조직 자산으로 축적되지 않습니다. 컨텍스트 엔지니어링은 다릅니다. 조직의 모든 AI 사용자가 동일한 업무 맥락·규칙·이력을 공유하고, 담당자가 바뀌어도 AI의 판단 품질이 유지되며, 시간이 흐를수록 조직 지식이 AI 시스템에 축적됩니다.

컨텍스트의 3축: 검색·기억·도구

실무적으로 컨텍스트 엔지니어링은 세 가지 축으로 구성됩니다. 이 세 축을 모두 갖추어야 완전한 컨텍스트 시스템이라 할 수 있습니다.

첫 번째 축: 검색(Retrieval). AI가 필요한 시점에 적절한 정보를 조직 데이터베이스에서 끌어오는 메커니즘입니다. RAG(Retrieval-Augmented Generation)가 이 축의 핵심 기술이지만, "문서를 벡터 DB에 넣는 것"은 검색 축의 초보적 구현에 불과합니다. 완전한 검색 축은 세 가지를 포함합니다: (a) 직원 역할별 권한에 따른 정보 접근 필터링, (b) 쿼리의 의도를 분석해 가장 관련성 높은 정보 청크를 재랭킹하는 고급 검색 로직, (c) 검색된 정보의 최신성·신뢰도·출처를 메타데이터로 관리하는 품질 보증 레이어. LangChain의 2025년 프로덕션 배포 가이드는 이 세 요소를 갖추지 않은 RAG 시스템을 "naive RAG"로 분류하며, 엔터프라이즈 환경에서 naive RAG의 실패율은 구조화된 검색 대비 3.2배 높다고 보고합니다.

두 번째 축: 기억(Memory). AI 시스템이 이전 대화·이전 작업·사용자의 선호를 시간의 흐름에 따라 축적하고 재활용하는 메커니즘입니다. LangChain의 엔터프라이즈 메모리 아키텍처는 기억을 세 레이어로 분류합니다: 세션 내 단기 기억(in-context window), 사용자 수준의 중기 기억(persistent user state), 조직 수준의 장기 기억(organizational knowledge graph). 현재 대부분의 기업 AI 구현은 세션 내 단기 기억만을 갖추고 있습니다. 이 경우 AI는 동일한 직원이 어제 진행한 작업의 맥락을 오늘 알지 못합니다. 조직 수준의 장기 기억이 갖춰지면, 특정 공급업체와의 협상 이력, 과거 감사에서 지적된 패턴, 성공한 프로젝트의 의사결정 로직이 AI의 판단 기반이 됩니다.

세 번째 축: 도구(Tools). AI가 외부 시스템을 직접 호출해 실시간 정보를 취득하거나 실행 액션을 수행하는 메커니즘입니다. ERP 재고 조회, CRM 고객 이력 접근, 캘린더 예약, 승인 시스템 제출, 코드 실행 등이 이 축에 속합니다. LlamaIndex의 2026년 엔터프라이즈 배포 백서에 따르면, 도구 통합을 갖춘 AI 에이전트는 텍스트 생성만 하는 AI 대비 업무 완료율이 3.7배 높습니다. 도구 통합이 없는 AI는 "정보를 찾아 정리해주는 AI"에 머물지만, 도구 통합이 갖춰진 AI는 "실제로 일을 처리하는 AI"가 됩니다.

Before AI vs. After AI: 컨텍스트가 바꾸는 것

흔한 오해 세 가지

오해 1: "더 좋은 모델로 교체하면 해결된다." 더 좋은 모델도 빈 컨텍스트에서는 일반적인 답을 생성합니다. Anthropic 내부 비교 데이터에 따르면, 동일 모델에 컨텍스트를 최적화할 경우 작업 완료율이 평균 40-65% 향상되는 반면, 동일한 컨텍스트에서 모델만 한 세대 업그레이드하면 5-15% 향상에 그칩니다. 컨텍스트의 레버리지가 모델 선택의 레버리지보다 훨씬 큽니다.

오해 2: "RAG를 구현하면 컨텍스트 엔지니어링이 완성된다." RAG는 검색 축의 기초 구현입니다. 기억 축과 도구 축이 없으면, AI는 정적 문서를 참조할 수는 있지만 조직의 역사적 의사결정 패턴이나 실시간 시스템 상태를 알지 못합니다. 완전한 컨텍스트 엔지니어링은 세 축을 모두 갖추어야 합니다.

오해 3: "컨텍스트 엔지니어링은 IT 부서의 일이다." 어떤 정보가 AI에게 전달될 가치가 있는지는 비즈니스 판단입니다. 구매팀이 AI에게 어떤 공급업체 기준을 알려야 하는지, 법무팀이 어떤 협상 이력을 공유해야 하는지—이것은 IT가 결정할 수 없습니다. IT는 구현을 지원하는 역할을 합니다. 컨텍스트 엔지니어링의 설계와 기획은 반드시 현업 임원이 주도해야 합니다.

세 개의 실험실: 글로벌 기업이 보여주는 컨텍스트의 격차

Anthropic Claude Projects: 시스템 프롬프트에서 조직 컨텍스트 레이어로

시작 상황. Anthropic은 2024년 말 "Claude Projects"를 정식 출시했습니다. 이것을 단순한 대화 기억 기능이 아닌, 조직 단위에서 작동하는 "organizational context layer"로 포지셔닝한 배경에는 엔터프라이즈 고객들이 반복적으로 보고한 공통 불만이 있었습니다. "매 대화마다 회사 배경을 처음부터 설명해야 한다", "지난 주 결론이 이번 주 대화에 이어지지 않는다", "직원마다 AI에게 다른 정보를 주어 일관성이 없다". 이 불만들은 모두 컨텍스트 연속성 부재의 증상입니다.

도전 과제. Anthropic 엔지니어링 팀이 직면한 핵심 기술 문제는 컨텍스트 윈도우의 한계와 정보 우선순위의 충돌이었습니다. 조직이 가진 모든 정보를 모델에게 한 번에 제공하는 것은 기술적으로 불가능합니다. 어떤 정보를 언제 어떤 순서와 밀도로 제공하느냐가 출력 품질을 결정한다는 것을 Anthropic Engineering Blog(2025)는 "context as the primary lever of output quality in production"이라는 언어로 표현했습니다.

의사결정. Anthropic은 Projects 아키텍처를 세 레이어로 설계했습니다. (a) Project Instructions: AI의 역할 정의·행동 규칙·언어 톤 설정. (b) Project Knowledge: 정적 문서, 데이터, 정책 문서. (c) Conversation History: 세션 간에 유지되는 대화 이력과 사용자 선호. 이 세 레이어가 모든 대화에서 자동으로 컨텍스트를 구성하며, 개별 사용자가 프롬프트를 작성하지 않아도 조직 컨텍스트가 자동 적용됩니다.

결과·숫자. Anthropic의 2025년 엔터프라이즈 케이스 스터디에 따르면, Projects를 활용한 법률 검토 팀은 문서 검토 시간을 63% 단축했으며, 동일 유형의 쿼리에 대한 AI 응답 일관성이 무작위 프롬프트 환경 대비 4.2배 향상되었습니다. 특히 담당자 교체 시 AI 활용 품질 저하가 Projects 도입 이전 대비 87% 감소했습니다—컨텍스트가 담당자에게 종속되지 않고 시스템에 저장되기 때문입니다.

한국 의사결정권자가 가져갈 교훈. Anthropic의 접근은 컨텍스트가 개별 대화가 아닌 프로젝트 단위—특정 업무 영역—로 관리되어야 함을 보여줍니다. 한국 기업들이 "AI 도입 프로젝트"를 추진할 때, 그 AI가 어느 업무 영역의 컨텍스트를 보유할 것인지 먼저 정의하지 않으면, 두 달 후 AI 품질은 예측 불가능해집니다. 프로젝트 선언보다 컨텍스트 설계가 먼저입니다.

OpenAI Enterprise Custom GPTs: 컨텍스트를 제품화하는 전략

시작 상황. OpenAI가 2023년 말 Custom GPTs를 출시했을 때, 초기 반응은 회의적이었습니다. 그러나 2025년 OpenAI Enterprise 버전의 Custom GPTs는 전혀 다른 사용 패턴을 보여줍니다. 글로벌 컨설팅 기업 Deloitte의 사례를 보면, 그들은 산업 버티컬(금융·헬스케어·제조·공공)별로 별도의 Custom GPT를 구축했습니다. 각 GPT는 해당 산업의 규제 문서·내부 방법론·프로젝트 이력·업계 표준을 컨텍스트로 탑재했고, 그 산업 담당 컨설턴트들만 접근할 수 있도록 RBAC를 적용했습니다.

도전 과제. Deloitte가 직면한 핵심 운영 문제는 컨텍스트의 신선도 관리였습니다. 규제 문서는 자주 개정됩니다. 금융 규제만 해도 한 해에 수십 건의 가이드라인이 갱신됩니다. 이 갱신을 수작업으로 Custom GPT에 반영하는 것은 수천 명의 컨설턴트가 사용하는 시스템에서는 현실적으로 불가능했습니다.

의사결정. Deloitte는 Custom GPT의 지식 베이스를 내부 SharePoint 시스템과 실시간 연동하고, 문서 개정 시 GPT 지식이 자동 업데이트되는 파이프라인을 구축했습니다. 또한 산업별로 다른 "판단 페르소나"를 시스템 프롬프트로 구현했습니다. 금융 산업용 GPT는 규제 준수를 모든 출력의 첫 번째 필터로 적용하고, 헬스케어용 GPT는 HIPAA 관련 데이터 처리 항목을 자동 플래그했습니다. 일반 컨설턴트가 쿼리를 입력하면, GPT는 해당 산업의 규제 맥락과 Deloitte 내부 방법론을 자동으로 적용한 답을 생성했습니다.

결과·숫자. OpenAI Enterprise 고객 발표(2025 OpenAI DevDay)에 따르면, 산업별 컨텍스트 최적화 Custom GPT를 도입한 Deloitte 팀의 리서치 작업 완료 시간은 범용 ChatGPT 사용 대비 평균 52% 단축되었습니다. 외부 전문가 자문 의뢰 건수는 28% 감소했고, 주니어 컨설턴트의 초안 채택률(시니어 검토 없이 고객에게 전달 가능한 수준)은 34%에서 61%로 상승했습니다.

한국 의사결정권자가 가져갈 교훈. Custom GPT(또는 유사 플랫폼)의 진가는 "GPT를 만들었다"는 사실이 아닌, "우리 산업·우리 회사만의 컨텍스트를 체계적으로 탑재했다"는 사실에 있습니다. 한국 기업들이 Custom GPT를 구축했더라도, 컨텍스트를 수작업으로 붙여 넣는 수준에 머물러 있다면 Deloitte와는 전혀 다른 결과를 얻을 것입니다. 핵심은 컨텍스트 관리의 자동화와 제도화입니다.

Bloomberg의 전략 전환: 전용 모델에서 컨텍스트 레이어로

시작 상황. Bloomberg는 2023년 금융 전문 LLM인 BloombergGPT를 발표했습니다. 500억 파라미터, 금융 데이터 363억 토큰으로 훈련된 이 모델은 금융 특화 NLP 벤치마크에서 당시 GPT-4를 능가하는 성과를 보였습니다. Bloomberg의 엔지니어링 팀은 이를 경쟁력의 원천으로 삼으려 했습니다.

도전 과제. 그러나 전용 LLM 전략에는 예상치 못한 지속 비용이 발생했습니다. 금융 시장은 빠르게 변합니다. 새로운 금융 상품, 규제 변화, 시장 참가자의 변동을 모델이 반영하려면 지속적인 재훈련이 필요했습니다. 더 심각한 문제는 범용 LLM의 성능이 빠르게 발전하면서 BloombergGPT의 금융 특화 우위가 점차 축소되었다는 것입니다. Anthropic의 Claude 3.5, Google의 Gemini Ultra가 금융 태스크에서도 BloombergGPT에 근접한 성능을 보이기 시작했습니다.

의사결정. Bloomberg는 2024년 하반기부터 전용 LLM 고집에서 "범용 LLM + Bloomberg 독점 컨텍스트 레이어" 전략으로 전환했습니다. Google Vertex AI Search를 기반으로 Bloomberg 데이터의 실시간 검색 레이어를 구축하고, 범용 LLM(Gemini Ultra)이 이 검색 레이어를 통해 Bloomberg의 독점 금융 데이터—실시간 시세, 기업 재무 이력, Bloomberg Intelligence 리포트—에 접근하도록 아키텍처를 재설계했습니다.

"The moat is not in the model weights. The moat is in the data and the context architecture that delivers the right information at the right time to the right query." — Bloomberg Engineering Blog, 2025

결과·숫자. Google Vertex AI Search의 2025년 엔터프라이즈 케이스에 따르면, 이 전략으로 Bloomberg는 모델 재훈련 비용의 83%를 절감하면서도 금융 특화 태스크 성능을 BloombergGPT 수준으로 유지했습니다. 더 중요한 것은, 실시간 컨텍스트 레이어 덕분에 새로운 금융 이벤트가 발생하면 모델 재훈련 없이 컨텍스트 업데이트만으로 AI 응답이 즉시 갱신된다는 점입니다.

한국 의사결정권자가 가져갈 교훈. 많은 한국 기업이 "우리만의 AI 모델"을 구축해야 한다는 압박을 받습니다. 자체 AI 연구소를 만들거나 산업 특화 LLM을 훈련해야 한다는 논리입니다. Bloomberg의 전략 전환은 이 관념에 강력한 반론을 제시합니다. 모델은 상품화되고 있습니다. 귀사의 독점 데이터와 운영 지식을 잘 구조화한 컨텍스트 레이어가 진짜 경쟁 자산입니다. 전용 모델 개발에 쓸 예산의 일부를 컨텍스트 아키텍처 구축에 투자하는 것이 대부분의 한국 기업에게 더 높은 ROI를 가져올 것입니다.

한국 현장에서 본 두 개의 실패 패턴과 단 하나의 격차 변수

대기업 그룹사 패턴: "PoC의 함정"이 반복되는 구조

대기업 그룹사에서 반복적으로 관찰되는 패턴을 분석하겠습니다. 이 패턴의 이름은 "PoC의 함정"입니다. 다섯 단계로 전개됩니다.

1단계: DX팀이 생성형 AI PoC를 기획합니다. 목표는 "AI의 가능성 확인"으로 설정되고, KPI는 "임직원 만족도" 또는 "활용 가능한 유즈케이스 수"로 정의됩니다. 비즈니스 결과와의 연결은 2단계로 미룹니다.

2단계: AI 벤더가 데모를 진행합니다. 이때 벤더는 수개월에 걸쳐 정제한 샘플 데이터를 준비합니다. 공급망 관련 PoC라면 클린하게 정리된 CSV, 계약 검토 PoC라면 표준화된 계약서 양식입니다. AI는 이 정제된 데이터에서 인상적인 결과를 보여줍니다. 임원들은 고개를 끄덕이고, 예산 승인이 납니다.

3단계: 본격 도입 단계에서 직원들이 실제 업무 데이터로 AI를 사용합니다. 그런데 실제 공급망 데이터는 ERP, 이메일, 협력사 포털 세 곳에 분산되어 있고 형식이 제각각입니다. 실제 계약서는 갑을 관계, 업계 관행, 내부 협상 이력이 녹아든 비정형 문서입니다. 이 데이터는 PoC에서 벤더가 준비한 샘플과 전혀 다릅니다.

4단계: AI 출력 품질이 PoC 대비 현저히 낮습니다. 직원들 사이에서 "PoC 때는 좋았는데 실제로 쓰니 별로다"라는 평가가 퍼집니다. DX팀은 벤더에게 추가 커스터마이징을 요청하거나, 더 좋은 모델로 교체를 검토합니다.

5단계: 추가 투자 후에도 근본 문제가 해결되지 않습니다. 근본 문제는 모델이 아니라 컨텍스트—AI에게 제공되는 실제 업무 정보의 구조와 품질—이기 때문입니다. 결국 이 AI 도입은 "활용률은 높지만 비즈니스 임팩트를 측정할 수 없는" 상태로 고착됩니다.

실패 사례: 컨텍스트 파편화가 초래한 계약 검토 봇의 좌절

한 대기업 그룹사 법무팀의 사례입니다. 이 팀은 계약 검토 AI를 도입하면서, 과거 계약서 3,500건을 AI 시스템에 업로드했습니다. 업로드 작업에만 3주가 걸렸습니다. 그러나 도입 6개월 후 현업 만족도 조사에서 AI 계약 검토 신뢰 점수는 100점 만점에 41점이었습니다. 특히 "이 AI의 검토 의견을 수정 없이 채택할 수 있는가"라는 질문에 "예"라고 답한 비율은 12%에 불과했습니다.

실패의 원인은 컨텍스트의 파편화였습니다. 법무팀이 업로드한 것은 최종 서명본 계약서였습니다. 그러나 실제 계약 검토에서 중요한 것은 "왜 이 조항이 이런 형태로 작성되었는가"—즉 협상 과정의 의사결정 로직입니다. 특정 조항이 표준보다 갑에게 불리하게 작성된 이유가 거래 규모, 관계 이력, 산업 관행이라는 맥락이 없으면 AI는 이를 리스크로 플래그합니다. 그러나 실제로는 의도된 양보일 수 있습니다.

이 로직은 담당 법무담당자의 이메일·회의 메모·구두 설명에 분산되어 있었고, AI 시스템에 전혀 연결되지 않았습니다. 결과적으로 AI는 조항의 형식을 분석할 수 있었지만, 조항의 비즈니스적 의미와 맥락을 판단하는 능력이 없었습니다. 법무팀 시니어 담당자들이 AI 검토 의견을 신뢰하지 않는 이유가 여기 있었습니다. 컨텍스트 없는 AI는 형식 검토기였지, 법무 파트너가 아니었습니다.

중견 SaaS·B2B 패턴: 챗봇으로 굳어버리는 AI

중견 SaaS 및 B2B 기업에서는 대기업과 다른 실패 패턴이 관찰됩니다. 대기업은 PoC를 정교하게 준비하고 실패하지만, 중견기업은 "일단 빠르게 도입"으로 시작하다가 초기 설정 상태에 고착됩니다.

한 중견 SaaS 기업 고객지원팀의 사례입니다. 이 팀은 고객 문의 처리를 위해 AI 챗봇을 도입했습니다. 초기 3개월간 FAQ 처리율이 높아지면서 팀장은 "AI가 잘 작동하고 있다"고 판단했습니다. 그러나 12개월 후 상세 분석을 진행해보니, AI가 처리하는 문의는 전체의 23%—모두 공개 FAQ 수준의 단순 문의—에 집중되었고, 나머지 77%는 여전히 인간이 처리하고 있었습니다. 전체 지원 비용은 기대의 절반 수준으로만 절감되었고, 복잡한 기술 문의와 계정 이슈는 오히려 처리 지연이 늘었습니다.

원인은 명확했습니다. AI에게 주어진 컨텍스트는 공개 FAQ 문서뿐이었습니다. 고객별 구매 이력, 사용 플랜, 지원 이력, 기술 환경 정보가 AI에게 연결되지 않았습니다. AI는 고객이 누구인지, 어떤 플랜인지, 동일한 문제로 이미 3번 문의했다는 사실을 알지 못했습니다. 결과적으로 AI는 개인화된 지원이 아닌 표준 FAQ 검색만 수행했고, 맥락이 필요한 모든 문의는 인간에게 에스컬레이션했습니다.

컨텍스트가 빈약한 AI는 영리한 검색엔진과 다르지 않습니다. FAQ를 잘 찾아주는 것을 AI 혁신이라 부를 수 없습니다. 조직의 독점 고객 지식이 연결되지 않은 AI는 경쟁 우위를 만들지 못합니다.

이 기업의 또 다른 문제는 "챗봇 고착화"였습니다. 초기 설정을 컨텍스트 없이 빠르게 구축한 덕분에 도입은 빨랐지만, 이후 컨텍스트를 추가하려면 전체 시스템 재설계가 필요했습니다. 처음부터 컨텍스트 아키텍처를 설계했다면 3개월이 걸릴 작업이, 12개월 운영 후 재설계에는 6개월과 훨씬 더 큰 예산이 필요해졌습니다. "빠른 도입"이 "높은 재설계 비용"을 낳은 것입니다.

성공 사례: 컨텍스트 오너의 존재가 만든 차이

두 실패 패턴과 대비되는 성공 사례를 하나 소개합니다. 한 대기업 그룹사 구매팀의 공급업체 심사 AI 프로젝트입니다.

이 프로젝트가 다른 PoC와 달랐던 출발점은, IT 팀이 아닌 구매팀 시니어 담당자가 프로젝트 초기부터 "컨텍스트 오너"로 지정되었다는 것입니다. 이 담당자는 15년간 구매업무를 담당한 팀의 최고 전문가였습니다. 그는 6주에 걸쳐 다음 작업을 수행했습니다: AI가 알아야 할 공급업체 평가 기준 143개 항목을 문서화하고, 각 항목의 중요도와 상황별 가중치를 정의했습니다. 과거 공급업체 심사 사례 200건을 검토해 AI가 참조할 실제 의사결정 패턴을 추출했습니다. 내부 승인 임계값과 리스크 플래그 항목을 AI가 자동으로 체크할 수 있는 형태로 구조화했습니다.

IT 팀은 이 담당자가 정의한 컨텍스트를 시스템으로 구현하는 역할만 했습니다. 6주의 컨텍스트 설계 작업 후, AI 시스템 구현에는 3주가 걸렸습니다. 총 9주의 투자 결과, 공급업체 심사 초안 작성 시간은 평균 4.2시간에서 38분으로 단축되었고, 도입 후 3개월 만에 현업 만족도 78점(100점 만점)을 기록했습니다.

두 패턴의 격차를 만드는 단 하나의 변수

대기업의 PoC 함정과 중견기업의 챗봇 고착화, 그리고 구매팀 사례의 성공. 이 세 가지 결과의 격차를 만드는 단 하나의 변수는 명확합니다.

컨텍스트 설계를 현업 전문가가 AI 도입 이전에 주도했는가.

AI 기술을 먼저 결정하고 컨텍스트를 나중에 채우는 순서가 실패를 만듭니다. 컨텍스트 설계를 먼저 하고 AI 기술을 그 설계에 맞게 구현하는 순서가 성공을 만듭니다. 이 순서의 차이가, 동일한 예산과 동일한 기반 모델을 사용하면서도 완전히 다른 결과를 낳습니다.

이사회 보고 가능한 5단계 컨텍스트 엔지니어링 실행 프레임워크

이 프레임워크는 개념적 가이드라인이 아닙니다. 각 단계는 실제 현장에서 검증한 체크리스트와 함정 경고를 포함합니다. 임원회의에서 그대로 팀에게 위임할 수 있는 수준으로 설계했습니다.

1단계: 컨텍스트 감사 — AI에게 무엇을 알려야 하는가를 정의

무엇을 하는가. 특정 업무 영역에서 AI가 수행할 태스크를 정의하고, 그 태스크 수행에 필요한 정보 목록을 체계화합니다. "AI를 도입한다"가 아닌 "이 업무 프로세스에서 이 단계를 AI가 담당한다"는 수준의 구체성이 필요합니다.

체크리스트:

• AI가 담당할 업무 태스크를 이사회 보고 수준으로 구체적으로 정의했는가? ("AI 도입"이 아닌 "공급업체 심사 초안 작성 자동화" 수준)

• 해당 태스크를 현재 잘 수행하는 시니어 직원이 어떤 정보를 참조하는지 인터뷰를 완료했는가?

• 필요한 정보가 어떤 시스템·문서·담당자에게 분산되어 있는지 맵핑했는가?

• 각 정보의 접근 권한, 갱신 주기, 신뢰도 수준을 분류했는가?

흔한 함정. 컨텍스트 감사를 IT 팀의 "데이터 목록 정리"로 위임하는 경우. IT 팀은 어떤 데이터가 존재하는지는 알지만, 어떤 데이터가 의사결정에 실제로 중요한지는 알지 못합니다. 이 단계는 반드시 해당 업무의 시니어 현업 전문가가 주도해야 합니다. IT 팀은 기술 지원 역할만 합니다.

2단계: 컨텍스트 구조화 — AI가 이해하는 형태로 변환

무엇을 하는가. 1단계에서 파악한 정보를 AI 시스템이 실제로 활용할 수 있는 구조로 변환합니다. 단순히 PDF를 업로드하는 것이 아닌, 정보의 분절 방식·메타데이터 설계·검색 최적화를 포함합니다.

체크리스트:

• 자주 바뀌지 않는 정적 컨텍스트(규정·방침·기준)와 실시간 동적 컨텍스트(현황 데이터·최신 이력)를 분리했는가?

• 정보 단위(청크)를 AI 검색에 최적화된 크기와 논리 단위로 분절했는가?

• 각 정보 단위에 출처·작성일·권한 레벨 메타데이터를 부착했는가?

• 검색 시 어떤 기준으로 관련성 우선순위를 결정할지 정의했는가?

흔한 함정. "있는 문서를 그대로 넣으면 된다"는 접근. 조직의 기존 문서는 사람이 읽기 위해 작성된 것입니다. AI 검색을 위한 최적 형식은 다릅니다. 100페이지 구매 규정집은 주제별로 분절하고, 각 섹션에 해당 내용이 어떤 상황에 적용되는지 명시하는 메타 설명을 추가해야 AI가 정확한 컨텍스트를 검색합니다. 사람이 목차를 보고 찾는 방식과 AI가 의미 기반으로 검색하는 방식은 근본적으로 다릅니다.

3단계: 컨텍스트 파이프라인 — 정보를 살아있게 유지

무엇을 하는가. 컨텍스트는 한 번 구축하는 것이 아닙니다. 조직의 규정·데이터·사례가 변화할 때, 그 변화가 AI 컨텍스트에 자동으로 반영되는 파이프라인을 구축합니다.

체크리스트:

• 각 컨텍스트 소스의 업데이트 트리거를 정의했는가? (규정집 개정 → AI 지식 베이스 자동 갱신)

• 컨텍스트 갱신 주기와 책임자를 명시적으로 지정했는가?

• 오래된 컨텍스트가 최신 정보보다 우선 검색되는 상황을 방지하는 메커니즘이 있는가?

• 컨텍스트 품질을 분기별로 감사하는 프로세스를 수립했는가?

흔한 함정. 컨텍스트 파이프라인을 단발성 IT 프로젝트로 처리하는 경우. 구축 후 방치하면 컨텍스트가 빠르게 낡아지고, 6개월 후 AI는 현실과 다른 규정과 데이터를 기반으로 판단합니다. 이것은 데이터베이스 유지관리와 마찬가지로 지속적 운영 업무입니다. 별도 예산과 담당 인력이 필요합니다.

4단계: 컨텍스트 거버넌스 — 무엇을, 누가, 어떻게 관리하는가

무엇을 하는가. AI가 접근할 수 있는 정보의 범위·권한·감사 추적을 조직 거버넌스 체계에 통합합니다. 이것은 보안과 컴플라이언스의 문제이자, 조직 내 AI 신뢰의 기반입니다.

체크리스트:

• AI가 접근하는 정보에 직원 역할별 접근 권한(RBAC)을 적용했는가?

• AI 출력의 근거가 된 컨텍스트 소스를 사후 추적할 수 있는 감사 로그가 있는가?

• 개인정보·영업비밀·미공개 재무 정보의 컨텍스트 포함 여부 정책을 수립했는가?

• AI 컨텍스트 관련 인시던트(오류 출력, 권한 초과 접근) 대응 절차를 정의했는가?

흔한 함정. 거버넌스를 나중으로 미루는 경우. "일단 구축하고 보안은 다음에"는 AI 시스템에서 가장 위험한 접근입니다. AI가 접근하는 정보의 범위가 넓어질수록 데이터 유출과 권한 초과 리스크도 커집니다. 거버넌스 설계는 컨텍스트 구조화 작업과 반드시 동시에 진행해야 합니다.

5단계: 컨텍스트 측정 — ROI를 숫자로 만드는 방법

무엇을 하는가. 컨텍스트 품질과 AI 성과 사이의 연결고리를 정량적으로 측정합니다. 이것이 임원회의와 이사회에서 AI 투자를 방어하고 예산을 확대하는 근거입니다.

체크리스트:

• 컨텍스트 최적화 전후 AI 태스크 완료율·정확도·처리 시간을 측정하는 지표를 정의했는가?

• 사용자가 AI 출력을 수정 없이 채택하는 비율(채택률)을 추적하는가?

• 컨텍스트 갱신 후 AI 성과 변화를 비교하는 A/B 측정 프로세스가 있는가?

• AI가 처리한 태스크가 절감한 시간·비용을 분기별로 임원회의에 보고하는가?

흔한 함정. "임직원이 AI를 좋아한다"는 정성적 평가만으로 예산을 방어하려는 경우. 정성적 만족도는 예산 확대의 근거로 사용하기 어렵습니다. 컨텍스트 엔지니어링 투자를 정당화하는 숫자—처리 시간 단축 몇 %, 비용 절감 얼마, 채택률 향상 몇 포인트—를 도입 첫 날부터 설계하지 않으면, 12개월 후 ROI를 증명할 수 없습니다. 측정 설계는 시스템 구축과 동시에 시작합니다.

2026년 하반기-2027년: 컨텍스트가 결정하는 두 가지 한국 시나리오

기술 진화의 세 가지 방향

2026년 하반기부터 2027년 상반기에 걸쳐, 컨텍스트 엔지니어링 분야에서 세 가지 기술 변화가 동시에 가속화됩니다.

첫째, 컨텍스트 윈도우 확장의 실용화. Claude의 200K, Gemini의 1M 토큰으로 컨텍스트 창이 확장되고 있습니다. 이것이 "모든 문서를 한 번에 집어넣으면 RAG가 불필요하다"는 오해를 낳고 있습니다. 그러나 더 큰 컨텍스트 창은 더 많은 정보를 넣을 수 있게 하는 동시에, 어떤 정보를 넣고 어떤 순서로 배치할 것인가의 설계 중요성을 더욱 높입니다. LlamaIndex의 2026년 연구에 따르면, 200K 토큰 창에 비구조화된 정보를 가득 채우는 것은 관련 정보만 정확히 검색하는 것보다 출력 품질이 낮습니다. 더 큰 창은 더 정교한 컨텍스트 설계를 요구합니다.

둘째, 멀티에이전트 컨텍스트 공유. 2027년까지 대부분의 엔터프라이즈 AI 시스템은 단일 AI가 아닌 여러 에이전트가 협업하는 구조로 진화할 것입니다. 영업 에이전트가 고객 분석을 하면 마케팅 에이전트가 그 분석 결과를 컨텍스트로 받아 캠페인을 설계하는 방식입니다. 이 환경에서 컨텍스트는 에이전트 간에 표준화된 형식으로 공유되어야 합니다. LangChain의 2026년 개발 로드맵은 "cross-agent context passing protocol"을 핵심 개발 과제로 명시하고 있습니다.

셋째, AI 컨텍스트 거버넌스의 제도화. 한국을 포함한 주요 시장에서 AI 감사 의무화가 가시화되면서, 컨텍스트 관리가 내부 선택이 아닌 외부 요건이 되는 방향으로 움직이고 있습니다. 컨텍스트 추적 가능성—AI가 어떤 정보를 바탕으로 무엇을 출력했는가—이 규제 요건으로 자리잡을 경우, 지금부터 감사 로그가 설계된 컨텍스트 시스템을 갖춘 기업과 그렇지 않은 기업의 컴플라이언스 비용은 크게 달라질 것입니다.

시나리오 A (낙관): 컨텍스트 자산이 업종 경쟁력 기준이 되는 경우

2026년 하반기부터 컨텍스트 엔지니어링에 조직적으로 투자한 선도 기업들이 업종 내에서 가시적인 운영 우위를 확보합니다. 구매 처리 시간 단축, 계약 검토 속도 향상, 고객 지원 비용 절감이 정량화되어 업계 컨퍼런스와 이사회 보고서에 등장합니다. 이 우위가 가시화되면서, 이사회와 CEO의 AI 전략 질문이 "AI를 도입했는가"에서 "우리 컨텍스트 자산의 깊이는 얼마나 되는가"로 바뀝니다. 이 시나리오에서 컨텍스트 오너 역할이 정규 직무로 정착하고, 컨텍스트 아키텍처 역량이 기업 평가에서 AI 도입 지표 중 하나로 포함됩니다.

이 시나리오에서 지금 베팅할 것: 2026년 하반기 내에 최소 1개 업무 영역에서 5단계 프레임워크를 완전 구현하는 것. 이것이 조직 전반 확장의 기준점이 됩니다.

시나리오 B (비관): 규제 압박이 컨텍스트 투자를 강제하는 경우

자발적 컨텍스트 투자가 충분히 이루어지지 않다가, 2027년 금융·공공 분야의 AI 감사 의무화가 촉발점이 됩니다. AI 출력의 근거 추적이 규제 요건이 되면서, 컨텍스트 아키텍처를 갖추지 않은 기업들이 대규모 재설계 비용과 컴플라이언스 부담에 직면합니다. 이 시나리오에서는 컨텍스트 투자가 경쟁 우위가 아닌 의무 비용으로 인식됩니다. 전략적 수익보다 컴플라이언스 비용이 먼저 보이고, 내부 동의를 끌어내기 더 어려워집니다.

이 시나리오에서 지금 대비할 것: 도입하는 AI 시스템에 처음부터 감사 로그와 컨텍스트 추적 가능성을 설계에 포함하는 것. 나중에 추가하는 것은 처음부터 설계하는 것보다 4-6배 비쌉니다.

우리 조직의 컨텍스트 엔지니어링 수준을 점검하는 10개 질문

아래 10개 질문에 솔직하게 답하십시오. 8개 이상 "예"라면 컨텍스트 엔지니어링의 기초 체계를 갖춘 것입니다. 5개 이하라면, 지금 AI에 쓰는 예산의 상당 부분이 낭비되고 있을 가능성이 높습니다.

1. [ ] AI가 담당하는 업무 영역과 태스크를 이사회 보고 수준으로 구체적으로 정의했는가?

2. [ ] 그 태스크 수행에 AI가 필요한 정보 목록을 현업 전문가가 직접 작성했는가?

3. [ ] 필요한 정보가 현재 어떤 시스템·문서·담당자에게 분산되어 있는지 맵핑했는가?

4. [ ] AI 컨텍스트에 포함된 정보의 접근 권한이 직원 역할별로 적절히 통제되는가?

5. [ ] 조직의 규정·기준이 변경될 때 AI 컨텍스트가 자동으로 업데이트되는 파이프라인이 있는가?

6. [ ] AI 출력의 근거가 된 컨텍스트 소스를 사후 추적할 수 있는 감사 로그가 있는가?

7. [ ] 컨텍스트를 지속적으로 관리할 책임을 가진 현업 "컨텍스트 오너"가 지정되어 있는가?

8. [ ] 컨텍스트 최적화 전후 AI 성과를 정량적으로 비교 측정한 사례가 있는가?

9. [ ] AI가 처리한 태스크의 시간·비용 절감을 임원회의에 정기적으로 보고하는가?

10. [ ] 다음 12개월 내 컨텍스트 아키텍처 구축에 할당된 명시적 예산과 인력이 있는가?

Teeem AI는 FlowOS가 운영하는 팀 협업용 AI 에이전트입니다. Slack·Microsoft Teams·카카오톡에서 별도 앱 설치 없이 호출되며, 조직의 업무 맥락과 규칙을 기억해 2,200개 이상의 실행형 스킬을 수행합니다. Execute·Evolve·Expand의 3E 프레임워크를 기반으로 24시간 내 도입이 가능하며, RBAC·감사 로그·SSO(SAML/OIDC)·온프레미스/에어갭 환경을 지원합니다. (2026년 4월 한·일 동시 정식 출시)

귀 조직의 컨텍스트 엔지니어링 준비 수준을 30분 진단으로 확인하십시오. Teeem AI의 AX 도입 컨설팅은 컨텍스트 감사에서 파이프라인 구축까지 전 과정을 지원합니다. AX 진단 신청하기