【클라우드 태크 서베이】모델은 점점 강해지는데, 왜 Context反而越来越值钱越来越重要해지는가 — 클라우드 태크 서베이 02

이번 클라우드 태크 서베이에서 Qoder 현장에서는 대략 다음과 같은 말을 했습니다:

Model power is a commodity. Context is the asset.

이 문구는 Qoder의 공식 슬로건이 아니라 현장 발표에서 전달된 방향성 관점(厂商归纳, 원문은厂商 현장 발표为准, 과도한 확대 해석은 삼가)을 나타냅니다. 하지만 점점 보편화되는 트렌드를 정확히 짚고 있습니다. 모델이 강력해지고, 모델을 확보하는 문턱이 낮아질수록, AI 제품에서 진정으로 희소한 부분은 더 위로 이동하게 됩니다.企业与复杂应用(기업 및 복잡한 애플리케이션)에게 이 층은 갈수록 Context에 가까워지고 있습니다。

이전 「클라우드 태크 서베이」(클라우드 태크 서베이 01) 제3절에서는 이미 이 판단의 방향을 언급했습니다. Qoder는 코드 저장소를 Wiki, Memory와 Knowledge Cards로 구성하고, QwenWork는 Enterprise Context를 강조하며, OpenSearch는 장기 기억과 컨텍스트 압축을 강조합니다. 세 곳의厂商 모두 같은 방향으로 수렴하고 있습니다. 본 기사에서는 Context를 별도로 분리하여, 그것이 일회성 Prompt 첨부 파일에서 AI 시스템의 장기 자산으로 어떻게 발전하는지, 그리고 어떤 새로운 공학, 거버넌스 및 조직 문제를 야기하는지 살펴보겠습니다.

一、模型虽然了解世界，却不懂”我们这里具体怎么运作”

通用模型已经掌握了大量公共知识，能够完成日益复杂的推理任务。但企业在实际应用中希望模型处理的事务，往往高度依赖于局部信息。

Coding Agent需要了解当前代码仓库的架构规范、代码约定、历史Bug、模块间的依赖关系以及发布流程。企业级Agent需要掌握组织架构、权限体系、标准操作流程、项目状态、客户信息、内部文档和业务规则。电商内容Agent需要熟悉品牌指南、SKU信息、商品真实性约束、目标市场、历史广告效果以及平台规则。Research Agent需要了解之前的搜索历史、可信的信息来源、被推翻的判断结论，以及当前研究任务的证据标准。

这些信息不会随着模型升级而自动补全。

因此，大量Agent产品开始将重点放在”如何构建可持续使用的Context”上。Context不再是一次性Prompt的附属物，而是一个需要长期维护的系统。

기업 AI 파일럿 프로젝트를 수행하면서 가장 빈번하게 목격했던 실패 패턴은 바로 이 점을 극명하게 보여준다: 모델은 매번 똑똑하지만, 시스템 전체적으로는 어리석다. 파일을 다시 업로드해야 하고, 브랜드 요구사항을 다시 설명해야 하며, 프로젝트 배경을 다시 기술하고, 과거 의사결정을 다시 반복해야 한다. 이런 마찰을 제거해야 비로소 모델의 역량이 진정으로 발휘되기 시작한다.

2. Qoder의 Context 엔지니어링: Knowledge Engine이 ‘코드베이스’를 재정의하다

전통적인 코드베이스는 주로 파일과 디렉토리의 관점에서 이해되었다. AI Coding 시대에 들어서며, 코드베이스는 기계가 읽을 수 있는 의미론적(semantic) 계층을 추가로 필요로 하게 되었다.

Qoder의 현rieve에서 소개된 몇 가지 구성 요소는 각각 서로 다른 Context 엔지니어링 역할을 담당한다(벤더 측 분류이며, 원문은 벤더 문서를 기준으로 한다): Repo Wiki는 프로젝트 구조와 모듈 설명을 형성하고, Knowledge Graph는 모듈 간의 의존성과 계약(contract)을 표현하며, Memory는 세션 간의 제약 조건, 선호도, 이력을 저장한다. Knowledge Cards는 현재 작업과 관련된 정보를 Agent에 직접 전달할 수 있는 Context 패키지로 구성한다.

迁移すべき真の価値は、これら四つの事象の根底にある判断基準にある。Contextエンジニアリング 이후, 새로운 작업마다 고신호 대 잡음비(High SNR)의 Context 패키지로부터 출발하는 것이다. 이는 반복적으로 읽히는 소스코드 저장소에서 출발하는 것과 근본적으로 다르다.

만약 Agent가 작업을 수신할 때마다 전체 코드를 재스캔하고, 모든 문서를 다시 읽으며, 아키텍처를 재추측해야 한다면, 모델 성능이 아무리 강해도 상당한 연산 자원이 낭비되고 결과의 일관성도 크게 떨어진다. 더욱 합리적인 구조는 다음과 같다.

Raw Data → Structured Knowledge → Task-specific Context → Agent

Task-specific Context는 현재 작업에 실제로 필요한 요소만 추출하며, 출처, 버전, 제약조건을 함께 포함한다.

고드(Gaude) 팀이 수백만 줄의 코드에서 도메인 지식을 검색 가능한 자산으로 변환한 후, 작업 1회 통과율이 37.3%에서 61.5%로 향상되었다. 이는 Context-as-Asset의 엔지니어링적 증거이다(데이터는厂商 사례에서 발췌한 것으로, Qoder 지식 엔진의 해당 고객 실제 측정 결과이며, 업계 벤치마크 참조 시 주의 필요; 동일한 논거는 이전 「云栖观察 01」第六節 조직 레벨 판단에서도 제시된 바 있다).

三、QwenWork, Context를 코드베이스에서 기업 전체로 확장하다

云栖 현장에서 선보인 QwenWork는 Context를 코드베이스 너머로 기업 전체로 확장한다.

Legal Document Fill Out와 Marketing Content Generation는 그다지 특별해 보이지 않는 두 가지 작업이다. 진짜 주목할 가치는 Agent가 기업 고유의 규칙과 리소스를 파악하는 방식에 있다.

법무 문서 Agent가 기업 템플릿, 승인 규칙, 계약 필드, 권한 정보를 알지 못한다면, 그저 그럴듯해 보이는 문서를 생성하는 데 그칠 수밖에 없다. 마케팅 Agent가 브랜드素材, 이력 캠페인, 타겟 시장, 브랜드 어조, 제품 정보를 파악하지 못한다면, 사용자에게 배경 정보를 계속 다시 설명하게 만들 것이다.

이것이 수많은 AI 도구가 현재直面하고 있는 가장 명백한 애로사항이다. 사용자가 매번 Context를 반복해서 제공해야 한다는 점이다(업체의 방향성 관찰 사항으로, 실제 원문은 云栖大会 공식 보도자료를 기준으로 한다).

장기적 가치를 지닌 진정한 AI Workspace라면, 이러한 반복적인 설명들을 점차 지속적 자산으로 전환해야 한다. 파일을 매번 업로드할 필요가 없고, 브랜드 요구사항을 매번 설명할 필요가 없으며, 프로젝트 배경과 역사적 의사결정을 매번 반복할 필요도 없어야 한다. 모델은 교체될 수 있지만, 시스템이 매번 제로에서 출발해서는 안 된다.

사、Context의 가치는 ‘지속적 축적’에 있으며, ‘더 많이 채우는 것’에 있지 않습니다

Context를 이야기할 때 사람들은 흔히 또 다른 함정에 빠집니다. 컨텍스트 창이 클수록 좋다고 믿고, 모든 자료를 마구 채워 넣으려 하는 것이죠.

실제 시스템에서는 Context가 많을수록 반드시 좋은 것은 아닙니다. 관련 없는 대량의 정보는 Token 비용을 증가시킬뿐만 아니라, 어텐션 밀도도 낮춥니다. 여러 버전의 문서가 동시에 존재할 경우, 모델은 어떤 규칙이 여전히 유효한지 판단하지 못할 수 있습니다.

그래서 Context Engineering이 진정으로 해결해야 할 것은 두 가지입니다: 무엇을 보존할 것인가와 무엇을 잊을 것인가.

무엇을 보존할 것인가 — 채팅 기록이 곧 장기 기억은 아닙니다. 보존해야 할 것은 의사결정, 제약조건, 증거, 실패 원인, 안정적인 선호도, 재사용 가능한 방법론입니다. 결제 시스템 수정에 전체 마케팅 지식베이스가 필요한 것은 아니며, SEO 리서치에 모든 서버 로그가 필요한 것도 아닙니다.

무엇을 잊어야 하는가 — Context에는 반드시 버전, 타임스탬프, 출처, 상태가 포함되어야 한다. 이미 폐기된 아키텍처 결정이 계속해서 Agent에 의해 호출된다면, 장기 기억이 오히려 오류를 증폭시킬 수 있다. 장기 작업에서는 지속적으로 컨텍스트를 요약하고 재구성하며, 핵심 상태는 유지하면서 이미 가치를 잃은 세부 정보는 버려야 한다.

이것이 이번 클라우드 컴퓨팅 컨퍼런스 OpenSearch Agentic Search 포럼에서 Task Memory, Long-term Memory, Context Compression을 특별히 강조한 이유다. Alibaba Cloud OpenSearch가 현장에서 제시한 ‘검색—실행—기억—지식’ 자기 순환 프레임워크(벤더 취합 기준, 클라우드 컴퓨팅 컨퍼런스 보도자료 기준)는 본질적으로 동일한 질문에 대한 답을 제시하고 있다: 어떤 Memory는 오래 남겨두고 사용해야 하고, 어떤 것은 작업 종료 시 압축해야 하며, 어떤 것은 이미 만료되어 능동적으로 잊어야 하는가.

점점 배우는 AI, 46가지 관점

5. Memory는 단순히 “사용자가 말한 것을 기억하는 것”이 아니다

많은 AI 제품에서 Memory는 사용자 선호도를 이해하는 것으로 간주된다. 예를 들어 언어, 이름, 자주 사용하는 형식 등을 기억하는 것이다. 이것도 물론 가치 있지만, Agent에게는 전혀 부족하다.

진정으로 복리를 형성할 수 있는 Memory는 Task Memory에 더 가깝다.

복잡한 작업이 끝난 후 시스템은 이 작업을 최종적으로 어떻게 분해했는지, 어떤 검색 경로가 효과적이었는지, 어떤 도구가 실패했는지, 어떤 자료가 신뢰할 수 있는지, 어떤 결과가 사용자에게 수용되었는지, 왜 수용되었는지, 어떤 단계가 Skill로 추상화될 수 있는지, 어떤 오류는 향후 피해야 하는지를 파악해야 한다.

모든 대화 기록을 단순히 Embedding한 후 다음 라운드에서 검색하는 방식으로는 Memory가 방대한 과거 텍스트 저장소로 퇴화하기 쉽다. 검색된 “관련 구절”이 실제로 관련이 없을 수 있으며, 모델이 교란될 확률이 오히려 높아진다.

Memory에게 진정으로 필요한 것은 정제, 평가 및 구조화다. 그렇지 않으면 Context가 축적될수록 오히려 다음 의사결정이 더 불확실해진다.

여섯 번째, Context도 새로운 Lock-in을 형성한다——Anti-lock-in 5가지 질문 선별 체크리스트

Context가 중요해질수록 새로운 플랫폼 종속에 대한 경계심을 갖춰야 한다.

기업의 모든 과거 의사결정, Workflow, Agent Memory, Skill, 사용자 피드백이 하나의 폐쇄형 플랫폼에 축적된다면, 모델 마이그레이션은 비교적 쉬울 수 있지만 Context 마이그레이션은 어렵다. 이는 모델 전환보다 더 은밀한 장기 비용이다.

고객과 기술 선정을 함께 진행할 때, 우리는 특별히 이렇게 묻는다: “3년 후 이 플랫폼을 교체한다면, 보유하신 Context 자산은 이전할 수 있습니까?” 답을 할 수 없는 솔루션은 선택할 때 신중해야 한다.

AI 플랫폼 벤더 종속을 판단하는 다섯 가지 핵심 질문

AI 플랫폼이 기업을 특정 공급업체에 종속시키는지를 평가하려면, 다음 다섯 가지 질문을 중심으로 판단할 수 있다.

첫 번째, 내보내기. Task History, Decision Log, Knowledge Base, Skill Definition, Evaluation Result, Tool Configuration, Permission Mapping과 같은 Context 자산이 범용 포맷으로 내보내기가 가능한가? 이것은 플랫폼 전환 시 기존 자산을 이전할 수 있는지, 아니면 처음부터 다시 구축해야 하는지를 결정한다.

두 번째, 버전 관리. 내보낸 Context에 버전, 타임스탬프, 출처, 상태 정보가 포함되어 있는가? 타임스탬프가 없는 Knowledge Card는 3년이 지난 후에도 그 당시 왜 존재했는지를 파악할 수 없다.

세 번째, 모델 독립성. Context가 서로 다른 모델에서 활용될 수 있는가? 특정 모델에서만 해석 가능한 Context는 본질적으로 특정 공급업체에 종속된다.

네 번째, 데이터 해외 이전 및 컴플라이언스. Context가境外 서비스에 저장되면 데이터 해외 이전 승인 요건, 개인정보 보호법(GDPR/CCPA/PIPL) 관련 의무, 그리고 엄격히 규제되는 산업의 로컬 데이터 센터 요구사항에 해당하는가? 이 항목이 통과되지 않으면 앞의 네 항목은 모두 의미가 없어진다.

거버넌스 책임에 대한 다섯 가지 질문. 누가 Context의 품질에 대한 책임을 지며, 누구에게 수정 권한이 있으며, 누가 만료된 콘텐츠를 폐기할 것인가? 거버넌스 책임이 불분명하면 Context가 점점 누적되어 새로운 조직 부채로 변질된다.

이 다섯 가지 질문의 핵심 원칙은: Model은 대체 가능하고, Runtime도 대체 가능하지만, Context 자산은 반드시 자기手中에 있어야 한다는 것이다. 이는 AI-native 기업 소프트웨어의 새로운 아키텍처 경계가 될 수 있다.

7. 네 가지 산업에서 Context 축적의 형태는 완전히 다르다

앞에서 설명한 것은 범용적인 연결 구조다. 이제 이 판단 기준을 구체적인 시나리오에 적용해 보자.

통신사——요금제 변경, 기업 전용 회선,跨国 과금 같은 요구사항은 매번 BSS/OSS/CRM과 컴플라이언스 감사 등 네다섯 개의 도메인을 통과해야 한다. AI가 애플리케이션 레이어 코드를 작성하는 속도는 두 배 가까이 빨라졌을 수 있지만, 미들웨어 어댑터 조정, 정산 로직, 컴플라이언스 승인 작업은 조금도 줄지 않는다. 이 경우 Context 축적의 핵심은 코드베이스가 아니라, 과금 이상 이력, 컴플라이언스 기준, 정산 규칙에 있다. 이 유형의 Context는 공개 자료에서 거의 샘플을 찾아볼 수 없으며, 기업만의 진정한 헤지이다.

금융은행 — 핵심 시스템, 리스크 관리, AML(반머니세탁), 설명 가능한 감사. 이 사슬의 핵심 특징은 모든 변경 사항이 설명 가능하고, 감사 가능하며, 추적 가능해야 한다는 점이다. AI가 리스크 관리 규칙을 빠르게 작성할 수 있지만, 이를 규칙 엔진에 적용하려면 모델 검증, 설명 가능성 테스트, 규제 기준 교차 확인, 내부 승인 절차를 거쳐야 한다. 여기서 Context 축적은 데이터 국외 이전合规(개인정보 국외 이전 표준 계약, 개인정보보호법 평가)과 현지 데이터 센터 요구사항을 충족해야 하며, 이 두 가지 조건이 충족되지 않으면 앞에서 구축한 모든 Context 자산은 활용할 수 없다.

제조업 — MES, ERP, QMS, 보고 시스템. 이전 섹션에서 언급했듯이, 제조 사슬에서 AI Coding은 “현장에서는 원활하지만, 통합 시 실패하는” 상황이 가장 흔하게 발생한다. Context 관점에서도 같은 판단이 적용된다: 현장 지식, 장비 매개변수, 수집 기준, PLC 인터페이스, 비전 시스템 버전 등 — 이러한 Context 대부분은 숙련 기술자의 머릿속, 낡은 PDF, 오래된 Excel에 흩어져 있다. “도메인 지식 축적 품질”에 대한 책임 소재가 명확하지 않으면, AI가 받는 Context는很快过期或相互矛盾这种现象在制造业场景下尤为突出。这也是上一节提出的五问清单在制造业领域最直接、最具体的应用场景。

한국어 번역

전자상거래 — 프로모션 준비, 재고 일관성 유지, 부정 이용 방지, 크로스 도메인 정산. AI가 이 분야에서 얻는 Context는 브랜드 가이드라인, 역대 소재 자료, 플랫폼 규정, 프로모션 후 분석이다. 이 부분의 Context는时效성이 가장 강하다 — 3개월 전 인기를 끌었던 소재 로직은 두 번째 프로모션 때 완전히 무효가 될 수 있다. 그래서 전자상거래 환경의 Context 거버넌스 핵심은 “축적”이 아니라 “폐기 리듬”에 있다.

네 가지 업종의 Context 형태는 다르지만, 하나의 공통된 판단을 공유한다: Context 자산의 조직적 거버넌스가 도구 선택보다 먼저 고려되어야 한다.

8. 미래의 판단과 실행을 개선할 수 있는 정보만이 진정으로 가치가 있다

“Context는 자산이다”라는 말을 더 엄격한 기준으로 이어가면, 더 많이 저장한다고 해서 자산이 많아지는 것이 아니라는 결론에 도달한다.

다음 작업의 불확실성을 낮추고, 반복적 탐색을 줄이며, 결과의 안정성을 높이고, 의사결정 품질을 개선할 수 있는 정보만이 진정한 자산을 구성한다.

따라서 앞으로 AI 제품을 설계할 때, 고객과 아키텍처 리뷰를 진행하면서 다음과 같은 질문을 추가로 던진다:

이 시스템이 작업을 완료할 때마다 무엇을 남기는가? 결과인가, 재사용 가능한 방법과 실패 기록인가?

다음에 바로 재사용할 수 있는가? 매번 다시 설명해야 한다면, 재사용은 구호 수준에 머물게 된다.

어떤 결론이 검증되었는가? 검증되지 않은 “경험”이 쌓이면, 다음에는 AI가 같은 실수를 반복하게 된다.

어떤 실패가 시스템에 기록되었는가? 실패 기록이 없는 Context는 불완전한 것이다.

모델을 바꾸면 과거에 쌓아온 가치가 남아 있는가? 이는 앞 섹션의 Anti-lock-in 5가지 질문의 연장선이다. 모델을 바꿔도 Context가 손실되지 않는다면, 그것이 진정한 자산이다.

모델은 지속적으로 발전하고, 호출 가격은 지속적으로 하락하며, 오늘날 강하게 느껴지는 능력도 이내 인프라가 될 수 있다. 진정으로 복리 효과를 낼 수 있는 부분은 대개 모델 외부의 그 층에 있다. 기업 고유의 Context, 검증된 Workflow, 그리고 장기적으로 축적된 판단과 피드백이다.

의사결정자에게 주는 시사점: 다음 분기 3가지 실천과제

CFO에게—“AI가 몇 시간의 工수를 절감했는가”를 “검증된 각 태스크에서 실제로 축적된 재사용 가능한 Context는 어느 정도인가”로 바꿔야 한다. 같은 유형의 태스크를 세 가지 다른 플랫폼에서 수행할 때, 축적되는 Context의 재사용률은 3~5배 차이가 날 수 있다. 이 수치가 “호출 횟수”보다 실제 ROI에 더 가깝고, 장기 자산에 대한 직접적인 지표가 된다.

CIO/CDO에게——다음 분기에 AI 플랫폼 선택 지표를 “모델 벤치마크/토큰 가격”에서 **Anti-lock-in 5가지 질문 체크리스트(내보내기/버전/모델 독립성/컴플라이언스/거버넌스 책임)**로 변경하라. 지표를 변경한 후 1-2분기가 지나면 조직은 자연스럽게 Context可控을要求하게 될 것이다. 지표를 바꾸지 않으면 3년 후 가장 큰 비용은 모델 비용이 아니라 Context 마이그레이션에 투입되는 인건비다.

업무 책임자에게——“도메인 지식 축적 품질”에 대한 책임자를 한 명 또는 한 팀으로 지정하라. 앞 섹션의 고드(Gaode) 사례의 핵심은 도구가上线된 것이 아니라 누군가가 “Context 축적 품질”에 대한 책임을 진다는 것이다. 도구를 팀에 던져주기만 하고 Context 품질을 보증하는 사람이 없으면 효과는 절반 이하로 떨어질 가능성이 높다.

자주 묻는 질문

Q1: Context 자산은 아름다워 보이지만, 중소 기업에서는 누구를 붙여서 축적을 전문적으로 할 수 있겠습니까?

전문적으로 하는 것이 아니라 기존 프로세스에 축적을 통합하는 것이다. 이슈 종결, 요구사항 리뷰, 사고 재현 시마다 “왜 이렇게 했는지, 어떤 함정을 밟았는지”를 추가로 두 문장만 적어라. 1년이면 수만 자의 조직 기억이 된다. 핵심은 工时이 아니라 이를 공식 산출물로 인정할 것인지, 아니면 “문서洁癖”로 볼 것인지의 문제다.

Q2: Agent 플랫폼들이 일제히 Memory와 Knowledge Cards를 내세우고 있는데, 과연 신瓶装旧酒에 불과한 걸까?

일부，的确는 신瓶装旧酒다. 그러나 Task Memory는 실행 이력을 검색 가능한 자산으로 변환하고, Knowledge Cards는 도메인 지식을 구조화한다는 점에서, 이는 기존 Prompt Library가 해결하지 못했던 과제다. 구분 방법은 단 하나다: “이 Memory가 마지막으로 누가, 어떤 태스크에서, 왜 수용하거나 거부했는가?”라는 질문에 답할 수 있는가. 답을 못하면 대부분 구式酒다.

Q3: Anti-lock-in 5가지 질문 중’모델 무관(Model-agnostic)’이 너무 이상적이라는 목소리가 있다. 현실에서는 모델 간 성능 차이가 크고, 모델을 바꾸면 반드시 품질이 떨어진다.

맞다. 단기적으로 품질 하락은 피할 수 없다. 그러나 질문의 핵심은 “제로 코스트로 전환할 수 있는가”가 아니라 “전환 비용이 특정 공급업체에 독점적으로 묶여 있는가”다.エクスポート 가능하고, 포맷 변환이 되고, 버저닝이 유지되면 전환 비용은 계산 가능한 엔지니어링 문제가 된다.エクスポート이 불가능하면 전환 비용은 통제 불가능한 비즈니스 리스크가 된다. 이 둘은 완전히 다른 차원의 문제다.

역방향 자체 점검

이 글의美화를 그리지 마라. 세 가지 사항에 대해 정직해야 한다:

첫째, 본 글은 이전「云栖观察 01」과 방향이 상당 부분 겹친다—Qoder Knowledge Engine, QwenWork Enterprise Context, OpenSearch Task Memory, 고덕(高德)팀의 원샷 통과율 37.3%→61.5%, 그리고 Context 자산화 판단이 양편 모두에서 다뤄진다. 본 글에서는 구조를 재편했으며(Anti-lock-in 5문前置를 6절로 이전, 거버넌스 책임 및 컴플라이언스 차원 보강, 4개 산업 렌즈 추가), 다만 두 편을 연속으로 읽으면 이미 익숙한 내용이 많다는 인상을 받게 된다. 다음 「云栖观察 03」 작성 시에는 이러한 중복을 피하도록 하겠다.

둘째, 글에서厂商 사례 비중이 다소 높다. 고덕, QwenWork Legal Document Fill Out, OpenSearch Agentic Search라는 세 가지 핵심 논거가 모두 현장厂商归纳 또는厂商文档에서 비롯된 것으로, 입장이厂商 측에 편향되어 있다. 이미 인용 설명 파트에서 각각 표기했으며, 논증 시 제3자 학술 서베이(“Memory in the Age of AI Agents”, arXiv:2512.13564)와 교차 검증하는 등 최대한 균형을 맞추려고 했다.

세 번째로, Anti-lock-in 5문항은 현재 설계 단계에 있으며 아직 검증된 지표 체계가 아니다. 실제로 활용하기 위해서는 각 문항별 구체적인 측정 방식, 업계 최저 기준, 컴플라이언스 조항의 구체적 지침 등을 추가로 보완해야 한다. 본 글에서 제공하는 것은 판단의 방향성이지 컴플라이언스 체크리스트가 아니다. 다음에 고객과 공동 작업할 때 보완할 예정이다.

인용 설명 (출처별 항목 + 증거 수준 + 입장)

#	文中论断	来源	日期	谁说的	证据层级	立场
1	“Model power is a commodity. Context is the asset.”（大意）	Qoder 현장 발표(업체 자체 정리, 실제 발언은 현장을 참고)	2026-09-24	Qoder 팀	업체 주장	업체 입장
2	Qoder Knowledge Engine은 Repo Wiki / Knowledge Graph / Memory / Knowledge Cards를 포함	Qoder Knowledge Engine 소개 페이지 + 이전「云栖观察 01」제3절 교차 검증	2025-2026	Qoder 팀	업체 주장	업체 입장

| 5 | OpenSearch Agentic Search “검색—실행—기억—지식” 자기 순환 + Task Memory / Long-term Memory / Context Compression | https://xie.infoq.cn/article/163b700cba024c8adb326ec5c（InfoQ 云栖 2026 报道）+ https://docs.opensearch.org/3.6/vector-search/ai-search/agentic-search/agentic-memory + https://opensearch.org/blog/unpacked-at-open-source-summit-na-2026-inside-opensearchs-massive-leap-into-the-agentic-era/ | 2026-09 |阿里云 OpenSearch团队 / OpenSearch 프로젝트 | 확인된 사실（厂商发布 + 第三方报道） |厂商 / 第三方联合 |

| 6 | Memory Forms × Functions × Dynamics 3차원 분류 | https://arxiv.org/abs/2512.13564（《Memory in the Age of AI Agents》 종합) | 2025-12 | Yuyang Hu 외 46인 (칭화, NTU, 푸단 등) | 검증된 사실 (학술 서베이) | 학계 |
| 7 | “Context Engineering” 용어의 확산 | Shopify, LangChain, Anthropic 문서에서 채택 (업계 통용 용어, 저자 정리) | 2024-2026 | 업계 합의 | 업계 관찰 | — |
| 8 | Anti-lock-in 5가지 질문 선별 체크리스트 (내보내기(Export) / 버전(Version) / 모델 무관(Model-agnostic) / 규제 준수(Compliance) / 거버넌스 책임(Governance responsibility)) | 본문의 방법론 종합 (AI 플랫폼 이식성에 대한 업계 논의 + 협력 고객 익명화 사례 참고) | 2026 | 본문 저자 + 종합 | 저자 추론 | — |

현지화 핵심 포인트 (다국어 번역 대조, IAIUSE 다국어 전략 · 2026-08-09 협약)

19개 언어로 번역 시, 아래 내용은 목표 언어 시장에 맞게 현지화하여 대체하되 구조/시각적 요소는 변경하지 않습니다.

중국어 원고 내용	영어판	일어판	독어판	아랍어판
Qoder / 알리바바 클라우드 제품	Qoder / Alibaba Cloud (제품명 유지)	Qoder / アリババクラウド	Qoder / Alibaba Cloud	Qoder / علي بابا كلاود
핀샤 / 딩딩	Slack / Teams	Slack / Teams / Lark	Slack / Teams	Microsoft Teams
차이나텔레콤 / 차이나모바일 / 차이나유니콤	AT&T / Verizon / T-Mobile	NTT / KDDI / 소프트뱅크	Deutsche Telekom / Vodafone	STC / Etisalat

OpenSearch 에이전트 검색 / OpenSearch Agentic Search (유지) / OpenSearch 에이전트 검색 / OpenSearch Agentensuche / OpenSearch بحث وكلاء البحث
BSS/OSS/CRM / BSS / OSS / CRM (유지) / BSS / OSS / CRM / BSS / OSS / CRM / BSS / OSS / CRM
PIPL / 데이터 수출 / GDPR / PIPL / SCC / GDPR / APPI / DSGVO / BDSG / نظام حماية البيانات الشخصية (PDPL)
《Memory in the Age of AI Agents》arXiv:2512.13564 / 同前（学术文献，保留 arXiv 编号）/ 同前 / 同前 / 同前（学术文献，保留 arXiv 编号）

설명: 상기 현지화 항목 외에, 문中出现하는 글로벌 제품/개념(Rev Wiki, Knowledge Graph, Task Memory, Skill, Context Engineering, Anti-lock-in 5 Questions)은 원문 그대로 유지한다. 기타 15개 언어는 IAIUSE 3단계 트레이드에 따라 실행한다: 핵심 5개 언어(중/영/독/일/아)는 상기 표에 따라 현지화; 부수적 9개 언어(서/프/포/한/러/이/네/폴/터)는 Qoder/QwenWork 원명 유지 + 현지 대표 기업으로 대체; 선택적 5개 언어(스웨/타이/베트/우크/인도)는 원명 그대로 플레이스홀더로 유지한다.

企业在 AI 도입을 검토할 때 어디서부터 시작해야 할지, 어떤 Context 자산을 먼저 구축해야 할지, 모델 업데이트로 인해 곧 사라질 일회성 Prompt에는 어떤 것이 있을지 고민이신 분들은 편하게 연락 주세요. 우리는 세 가지 서비스를 제공합니다.

기업 내부 교육 — AI 시대 R&D 및 운영팀 전환을 위한 2~3일 워크숍으로, Context 자산 점검, Anti-lock-in 5가지 질문, 측정 체계 등을 직접 가져갈 수 있습니다.

전문 컨설팅 — Context 자산 점검부터 Workflow 재설계, 측정 체계 구축까지, ‘모델 성능’을 ‘조직 역량’으로 전환하는 것을 도와드립니다.

경영진 브리핑 및 업계 세미나 — 의사결정자 관점의 AI Context 현황과 Anti-lock-in 선정 기준을 공유합니다.

먼저 90분간 방향성을 같이 이야기해 보고 싶으신 분은 가벼운 상담을 예약해 주세요.合作邮箱：[email protected]

추천 읽기: 《AI 전환 7단계 프레임워크》 — 기업 AI 도입의 전체 과정을 체계적으로 설명합니다.

이 시리즈에 대하여

「클라우드 콤퓨타observer」는 IAIUSE가，推出하는 산업 현장 시리즈입니다. 2026 클라우드 콤퓨타 컨퍼런스에서 출발하여 연구자의 시각으로 AI 산업에서 실제로 일어나고 있는 변화를 해체합니다. — 달DEFF热门에追随せず, 어떤 방향에 베팅할지와 증거의strength만을中심으로 합니다.

시리즈 개요

본 시리즈는 모델 상위 시스템 레이어, Agent 실무 적용, Context 자산, 기업 AI 조직 설계, AI 제품 경쟁 단위의 이동 등 주제를 다루며 총 약 10편으로 구성된다.

연구 자료库 소개

본 시리즈의 연구 자료库에는 200편 이상의 공개 연구 및 업계 사례가 축적되어 있다. 본 글에서 인용하는 근거는 세 가지 레벨에서 도출되었다: 현장 공급업체 발표(Qoder / QwenWork / OpenSearch), 서드파티 독립 연구(《Memory in the Age of AI Agents》arXiv:2512.13564 등 학술 검토), 협력 고객 익명화 사례. 공급업체 사례 비중이 비교적 높으므로, 인용 시 출처 명시 부분에 입장 표기를 병기했다.

#筆者 소개

나는 약 8년간 대기업 컨설팅 및 비즈니스 분석 경력을 보유하고 있으며, IBM 재직 시절 통신, 금융, 보험, 제조업 관련 프로젝트에 참여했다. 이후 통신사 제품, 인터넷 제품, AI 애플리케이션 개발 현업에서 요구사항 분석, 제품 설계, 크로스팀 실행을 진행해왔다. 이 채널을 운영하는 것은 사실상 소규모 팀이다—나와 1~2명의 장기 협력 동료가 있으며, 각각 AI 코딩 도구 연구, 조직 거버넌스 사례 정리, 코칭 대화 등의 영역을分担하고 있다.文中에서 “우리가企业与 함께 거쳐간” 대부분의 프로젝트는 우리 몇 명이 공동으로 수행한 것이다.