【윈치(云栖) 콘퍼런스 관전】윈치 콘퍼런스는 답이 아니라, AI 산업이 어디에 베팅하고 있는지를 보여주는 지도다

이번 윈치 콘퍼런스를 한 바퀴 돌며 얻은 가장 큰 수확은, 새 모델이나 새 회사를 몇 개 더 외운 것이 아니라, 전시회를 바라보는 방식 자체가 달라졌다는 점이다.

예전에는 기술 콘퍼런스에 참여하면 자연스럽게 몇 가지 단정을 내리게 마련이었다. 빅테크가 무게를 두어 다루는 방향이라면 대체로 미래를 가리킬 것이고, 무대에서 반복적으로 등장하는 개념이라면 업계의 합의일 가능성이 높으며, 한 제품이 이미 전시대에 올려졌다면 충분히 성숙했다는 신호로 읽혔다. 그런데 여러 번 참석하고 나면 또 다른 극단으로 미끄러지기도 한다. 콘퍼런스는 어차피 마케팅 행사이고, 부스는 광고이며, 프레젠테이션은 포장일 뿐이라는 시니컬한 시각이다.

두 가지 태도 모두 너무 손쉬운 판단이다.

전시회에 마케팅 속성이 있는 건 분명하다. 다만 마케팅 자체도 하나의 정보다. 한 벤더가 예산, PM 조직, 엔지니어링 조직, 영업 조직, 부스 리소스를 어느 한 방향에 쏟아부었다면, 거기에는 최소한 두 가지가 담겨 있다. 시장이 무엇을 믿어주기를 바라는지, 그리고 어떤 문제를 제품화하기 위해 움직이고 있는지다.

그래서 요즘 나는 대형 기술 콘퍼런스를 고밀도의 산업 샘플링장으로 본다. 답을 주지는 않지만, 샘플과 신호와 반례, 그리고 “업계가 어떤 미래에 베팅하고 있는가”를 보여주는 지도를 건네준다.

1. 먼저 전시회의 “화제성”을 서로 다른 증거 등급으로 쪼개기

이번에는 하나의 기술 방향을 의식적으로 다섯 단계로 나눠 보기 시작했다.

서사(Narrative) → 제품(Product) → 프로덕션(Production) → 비즈니스(Business) → 수익(Revenue)

최상위는 **서사층(Narrative)**이다 — 벤더가 시장에 심고 싶은 이야기다. “에이전트(Agent)가 새로운 업무 진입점이 될 것”, “기업은 AI 네이티브(AI-native) 아키텍처를 채택해야 한다”, “컨텍스트(Context)가 핵심 자산이 된다”, “멀티 에이전트가 점점 더 복잡한 작업을 떠맡게 될 것” 같은 주장들이 여기에 속한다. 이런 내러티브는 조직의 관심과 자본이 어느 방향으로 흐르고 있는지 읽게 해준다는 점에서 의미가 있지만, 본질적으로는 판단과 베팅에 불과하다.

한 층 아래는 **제품층(Product)**이다 — 시연하고, 호출하고, 전달할 수 있는 무언가가 이미 만들어진 단계다. 부스에 완성된 인터페이스, API, 워크벤치, 거버넌스 플랫폼이 갖춰져 있다면, 그 방향은 이미 개념 단계를 넘어 제품화 단계에 진입했다는 뜻이다. 다만 “데모에서 돌아간다”와 “장기간 안정적으로 돌아간다” 사이의 간극은 여전히 크다.

그 아래는 **프로덕션(Production)**이다 — 제품이 실제 고객 업무 흐름에 투입되어 지속적으로 운영되며, 권한, 데이터, 감사, 복구, 비용, 조직 협업 같은 현실적 제약과 정면으로 부딪히는 단계다. 여기에 도달해야 비로소 프로덕션 환경이라 부를 수 있다.

한 단계 아래는 비즈니스(Business) 계층이다. 계속해서 묻는다: 출시 이후 무엇이 달라졌는가? 납품 주기를 단축했는가, 전환율을 높였는가, 인건비를 줄였는가, 광고 소재 테스트량을 늘렸는가, 아니면 기존에 불가능했던 업무 프로세스를 실행 가능하게 만들었는가?

맨 아래, 그리고 가장 실질적인 한 계층은 수익(Revenue) 계층이다. 고객이 장기적으로 비용을 지불할 의향이 있는가, 어떤 결과에 대해 지불할 의향이 있는가, 갱신은 어떤 조건에서 이루어지는가.

이 프레임워크의 가치는 서로 다른 종류의 증거를 뒤섞지 않는 데 있다. 전시 부스는 한 방향이 다뤄볼 만하다는 점을 입증할 수 있고, 포럼은 벤더가 특정 인식을 강화하려 한다는 점을 보여준다. 실제 고객 사례는 생산 계층과 비즈니스 계층의 신뢰도를 높여주며, 지속적인 수익만이 수익 계층을 검증한다.

따라서 어떤 방향이 컨퍼런스에서 화제라는 사실만으로 “지금 투자해야 한다”로 곧바로 결론을 내릴 수는 없다.

둘, 이번에 가장 뚜렷한 변화: 모델 위에 점점 더 많은 계층이 자라나고 있다

지난 몇 년간 AI를 이야기할 때, 관심사는 거의 전적으로 모델에 쏠려 있었다: 파라미터 규모, 벤치마크(Benchmark), 추론 능력, 가격, 컨텍스트 윈도우, 이미지 품질, 코딩 능력.

이번 현장에서는 그 초점이 이동하고 있음을 분명히 느낄 수 있었다.

모델은 여전히 중요하지만, 모델을 둘러싼 시스템 레이어가 눈에 띄게 두꺼워지고 있다. 데이터 레이어, 모델 연동, Token 거버넌스, 에이전트 런타임(Agent Runtime), 샌드박스(Sandbox), 컨텍스트(Context), 메모리(Memory), 스킬(Skill), 브라우저 조작(Browser Use), 컴퓨터 조작(Computer Use), 검증(Verification), 옵저버빌리티(Observability), 권한 관리, 감사, 비용 제어까지 — 점점 더 많은 기능이 독립적인 제품으로 분리되고 있다.

이유는 단순하다. 모델이 질문에 답할 수 있다는 것과, 모델이 프로덕션 흐름에 투입되어 안정적으로 업무를 완수한다는 것 사이에는 그야말로 풀스택 엔지니어링 시스템 한 세트가 놓여 있다.

전시회장을 하루 종일 돌아다녀 보면, 완전히 다른 이름의 제품이 한 다섯여섯 개는 눈에 들어옵니다. 그런데 자세히 들여다보면 이 제품들이 사실상 같은 구조로 수렴하고 있다는 점이 흥미롭습니다.

QwenWork(Alibaba의 엔터프라이즈 에이전트 워크스페이스)는 격리된 환경에서 에이전트가 다양한 도구를 호출해 작업을 완수하는 방식을 보여줍니다. Qoder(Alibaba의 AI 코딩 IDE)는 Context, Spec, Harness, Verification, Memory, 멀티 모델 라우팅을 핵심 요소로 내세웁니다. 참관한 독립 벤더 TinyFish는 에이전트가 실제 웹 환경에 들어가 직접 작업을 수행하도록 만듭니다. WonderClip은 영상 제작을 Script, 스토리보드, 소재, 생성, 검수, 버전, 批量(일괄) 생산으로 분해합니다. 阿里云 OpenSearch의 Agentic Search는 검색을 다시 한번 Planning, Reasoning, Memory, Action, Evaluation의 흐름으로 확장해 나갑니다.

겉보기에는 완전히 다른 영역에 속해 있는 듯하지만, 이면의 구조는 같은 방향을 가리킵니다.

컨텍스트 → 계획 → 스킬 → 실행 → 검증 → 메모리 → 비즈니스 결과
(Context → Planning → Skill → Execution → Verification → Memory → Business Outcome)

모델은 점차 그중 하나의 중요한 구성 요소로 자리 잡아가고 있으며, 제품의 가치는 상위 시스템에 더 많이 실리게 됩니다.

3. 컨텍스트(Context), ‘입력 재료’에서 장기적 자산으로

Qoder(Alibaba의 코딩 어시스턴트)의 현장 프레젠테이션 한 슬라이드가 이를 매우 직관적으로 보여줍니다.

Model power is a commodity. Context is the asset.

물론 이 말에는 벤더의 입장이 분명히 깔려 있지만, 그러나 실제로 중요한 문제를 짚어줍니다. 모델 능력이 강해지고 도입 비용이 낮아질수록, 에이전트(Agent)가 장기적으로 제대로 작동할 수 있느냐를 좌우하는 요소는 결국 ‘그것이 실제로 무엇을 알고 있느냐’로 모아집니다.

성숙한 소프트웨어 프로젝트에는 아키텍처 제약, 과거의 의사결정, 모듈 간 의존 관계, 코딩 컨벤션, 이미 밟았던 함정, 배포 이력이 있습니다. 한 기업에는 조직 관계, 권한, SOP, 문서, 업무 채팅, 비즈니스 규칙, 고객 현황이 있습니다. 한 브랜드에는 상품 정보, 비주얼 가이드라인, 과거 제작물, 캠페인 데이터, 채널별 제약이 있습니다.

이런 정보는 더 강력한 모델로 교체한다고 해서 자동으로 생겨나지 않습니다.

따라서 Qoder는 코드 저장소 Wiki(Repo Wiki), 메모리(Memory), 지식 카드(Knowledge Cards)를, QwenWork은 엔터프라이즈 컨텍스트(Enterprise Context)를, OpenSearch는 장기 기억, 작업 기억, 컨텍스트 압축을 각각 강조합니다. 이 모두가 같은 문제를 풀려고 합니다. 매번 에이전트가 처음부터 세상을 이해하도록 강요하지 않는 것.

이는 동시에 과거에 많은 팀이 쌓아 두길 좋아했던 프롬프트 라이브러리(Prompt Library)의 장기적 가치가 생각보다 크지 않을 수 있다는 뜻이기도 합니다. 프롬프트(Prompt)는 특정 작업을 호출하는 방식에 불과하고, 실제로 복리로 쌓이는 것은 업무 컨텍스트, 의사결정 이력, 검증 결과, 실패 원인, 재사용 가능한 스킬입니다.

4. AI 제품의 경쟁 단위가 “단일 기능”에서 “완전한 워크플로”로 이동하기 시작했다

WonderClip이 저에게 준 인상은 특히 분명했습니다.

기능 목록만 보면, 새로울 것이 없습니다. 이미지 생성, 영상 생성, 번역, 더빙, 소재 교체, 일괄 생산. 하나하나 따로 보면, 이런 기능들은 모델 벤더, 영상 편집 툴, 기타 SaaS에서도 충분히 따라잡거나 흡수할 수 있습니다.

하지만 라이브 데모에서 보여 준 제품 구조는 이미 한층 완전한 프로덕션 시스템 쪽으로 움직이고 있습니다.

Upload the script → Review the breakdown → Prepare the assets → Generate in bulk

이어서 Storyboard, Canvas, 커스텀 스킬, 자산 공유, 팀 협업, 버전 관리 같은 기능이 뒤따릅니다. 제품은 ‘생성’ 단계를 다시 워크플로의 한가운데로 끌어올렸습니다.

이는 AI 애플리케이션을 만드는 데 직접적인 시사점을 줍니다.

제품의 핵심이 여전히 ‘무언가를 업로드하면 AI가 처리해주고 결과를 받는’ 구조라면, 다음 모델 업그레이드에서 그 가치가 크게 깎일 수 있습니다. 더 나은 방향은, 사용자가 본래 완수해야 했던 작업 전체를 제품이 점유하는 것입니다.

예를 들어 이커머스 콘텐츠 영역에서 상품 교체, 배경 교체, 번역, 더빙 같은 기능을 단독으로 제공하는 것은 얕은 레벨에 불과합니다. 한 단계 더 올라가면, 제품이 다루는 대상은 점차 브랜드(Brand), 단일 상품(SKU), 캠페인(Campaign), 시장(Market), 크리에이티브 전략(Creative Strategy), 소재 변형(Variants), 배포 채널(Distribution), 광고 성과(Performance)로 확장되어야 합니다. 생성은 그저 실행기일 뿐이고, 진짜 가치는 크리에이티브 운영 워크플로(Creative Operations Workflow) 전체에서 나옵니다.

5. 에이전트(Agent): ‘질문에 답하기’에서 ‘작업을 완수하기’로

오늘 Alibaba Cloud OpenSearch의 에이전트 검색 세션에서 진화 로드맵을 보여주는 한 장의 다이어그램이 인상적이었다.

초기 검색은 Query(질의어)에서 Results(결과 목록)로의 연결을 해결하는 것이었다. 생성형 AI는 이를 Question(질문)에서 Answer(답변)로 한 단계 끌어올렸다. 에이전트 검색은 한 걸음 더 나아가, 과제를 Goal(목표)에서 Action(실행)으로 재설정한다.

이는 곧 검색 자체가 그 정체성을 다시 정의하고 있음을 뜻한다.

앞으로 Research Agent(연구형 에이전트)는 스스로 질문을 분해해 쿼리 플랜을 세우고, 여러 검색 소스를 호출하며, 보완적인 재검색을 수행하고, 교차 검증을 거쳐 중간 결론을 도출한 뒤, 다시 다른 도구를 호출해 실행을 이어갈 것이다. 검색 API는 점점 더 에이전트가 외부 컨텍스트를 확보하기 위한 인프라에 가까워질 것이다.

이는 또한 SEO와 GEO(Generative Engine Optimization, 생성형 엔진 최적화)를 관찰하는 방식 자체를 바꾸게 한다. 과거에는 Impression(노출), Click(클릭), Ranking(순위)에 집중했다. 앞으로는 AI Visibility(AI 가시성), Citation(인용), Mention(언급), AI Referral(AI 유입)을 함께 봐야 하며, 궁극적으로 그 트래픽이 Signup(가입), Paid(유료 전환), Retention(리텐션)으로 이어지는지를 추적해야 한다.

검색이 사라진 게 아니다. 더 큰 태스크 루프(task loop) 안으로 흡수되기 시작한 것이다.

6. 기업 AI의 진짜 난관, 조직 차원으로 진입하다

학회에서 기업 AI의 기술 이슈는 충분히 다뤄졌다. 데이터, 권한, 보안, 거버넌스, 모델 연동, 클라우드 아키텍처, Agent 플랫폼.

모두 중요하다. 그런데 몇몇 기업 사례를 접한 뒤, 내가 더 주목하게 된 질문은 따로 있다.

진심으로 AI를 쓰려는 동기는 과연 누구에게 있는가?

한 직원이 AI를 써서 기존 8시간짜리 업무를 5시간으로 줄였다고 하자. 남은 3시간은 어떻게 될까? 답이 “그 사람에게 일을 더 주는 것”뿐이라면, 직원이 AI 도입을 자발적으로 밀어붙일 인센티브는 사실상 없다.

다른 예를 보자. AI 팀의 KPI가 Agent 배포 수와 호출 횟수라면, 그 팀은 끊임없이 기능을 추가할 동기를 갖는다. 반면 비즈니스 팀은 업무 프로세스 개편 비용을 떠안고, IT·보안 팀은 장애 리스크를 짊어진다. 정작 그 결과로 발생하는 매출 증가는 누구 덕분인지 명확히 귀속되지 않는다. 이런 조직 구조에서는 기술이 아무리 갖춰져 있어도 현장 확산은 느릴 수밖에 없다.

기업 AI는 아키텍처(Architecture)만으로 판단할 문제가 아니다. 인센티브 설계(Incentive Design)가야말로 진짜 천장이다.

기술 문제는 돈으로 해결할 수 있지만, 조직 문제는 돈으로 해결되지 않을 수도 있습니다. 하나의 프로젝트를 시작하기 전에는 최소한 다음 여섯 가지를 분명히 정리해야 합니다. 역할(Role), 핵심성과지표(KPI), 수익(Benefit), 비용(Cost), 위험(Risk), 의사결정권(Decision Right). 수익을 가져가는 쪽이 위험을 지고, 의사결정권을 가진 쪽이 결과에 대한 책임을 져야 합니다.

흔히들 ‘AI 도입 문제’라 부르는 것들 중 상당수는, 알고 보면 조직 설계의 문제입니다.

7. 가장 오해하기 쉬운 지표는, 가장 직관적으로 보이는 지표이다

Qoder(AI 코딩 어시스턴트)의 한 장짜리 PPT가 깊은 인상을 남겼습니다.

Generation rate is a vanity metric.

현장 발표에서는 서로 다른 단계의 AI 코드 생성 비중을 비교해 보였고, 동시에 소프트웨어 전달 주기(Delivery Cycle)가 같은 비율로 단축되지 않는다는 점을 강조했습니다. 여기서 인용된 구체적인 수치는 벤더의 현장 사례에서 나온 것이므로, 산업 벤치마크(Benchmark)로 직접 받아들이기에는 무리가 있습니다. 다만 그 이면에 깔린 논리 자체는 성립합니다.

AI가 코딩(Coding) 비용을 끌어내리면, 병목은 요구사항(Requirement), 컨텍스트(Context), 아키텍처(Architecture), 리뷰(Review), 테스트(Test), 통합(Integration), 배포(Deployment), 검증(Validation)으로 옮겨간다.

따라서 코드 생성률, Token 수, 에이전트 수, 호출 횟수, 이미지 생성량 같은 지표는 부분적인 효율 지표가 될 수 있다. 진짜 중요한 것은 엔드 투 엔드(end-to-end) 결과다. 리드 타임(Lead Time)은 줄었는지, 휴먼 미닛(Human Minutes)은 줄었는지, 퍼스트패스 수락률(First-pass Acceptance Rate)은 올랐는지, 수락 작업당 비용(Cost per Accepted Task)은 내려갔는지, 최종 비즈니스 지표가 달라졌는지가 핵심이다.

이번 컨퍼런스에서 하나 일깨워준 게 있다. “AI가 얼마나 했는가”에 현혹되지 말고, “그 결과 시스템 전체가 무엇이 달라졌는가”를 보라는 점이다.

8. 컨퍼런스는 베팅 거리를 제공하지만, 판단권은 여전히 자기 손에

컨퍼런스에參加하면 가장 흔히 벌어지는 일은, 외부 세계가 자기 대신 우선순위를 정해주기 시작하는 것이다.

무대에서 한 방향을 많이 다루면 자신도 연구해야 할 것 같고, 대기업이 많이 투자했으니 자신도 따라가야 할 것 같고, 어떤 제품이 진보해 보여 자신도 한 세트 갖춰야 할 것 같다.

이번에는 이런 정보들을 한 가지 더 단순한 질문으로 모아두고 싶다.

이 정보가 내 어떤 결정을 바꾸는가?

“흥미롭다”는 인상 정도만 남는다면, 그것은 그냥 입력(input)일 뿐이다.

그 정보로 인해 자가 구축(Build)과 구매(Buy), 무시(Ignore) 사이의 판단이 달라지고, 제품 경계가 재조정되며, 가치가 낮은 프로젝트가 중단되고, 업무 흐름이 다시 설계되며, 실험 지표 자체가 재정의된다면—그제서야 비로소 결정(decision)에 들어온 것이다.

윈치(云栖) 컨퍼런스[Alibaba가 매년 주최하는 클라우드/AI 기술大会]는 답이 아니다.

그것은 오히려 산업 전체의 베팅 지도를 펼쳐놓은 것에 가깝다. 그 지도는 다른 이들이 어디로 향하고 있는지, 어느 길이 이미 붐비기 시작했는지, 어떤 인프라가 형태를 갖춰 가고 있는지, 어떤 문제가 대규모 제품화 단계에 진입했는지를 알려준다.

결국 어느 길로 갈지는—자기 자신의 목표와 제약, 자원, 그리고 증거로 돌아가 판단해야 한다.

이것이 내가 요즘 기술 컨퍼런스에 참석할 때 가장 지키고 싶은 태도이기도 하다. 더 많은 베팅(map)을 살피되, 판단의 주체는 내 손에 남겨두는 것.

기업용 AI를 어디서부터切入할지, 어떤 방향에 투자할 가치가 있는지, 어디가 서사(narrative)에 불려 부풀려진 거품인지—이런 평가를 진행하고 있다면 언제든 이야기 나누길 권한다. 우리는 기업 AI 전환 컨설팅을 전담하고 있으며, 기술 선정에서 조직 설계,度量 체계까지—컨퍼런스의热闹을 “나만의 판단”으로 착지시키는 작업을 함께한다. 협업 이메일: [email protected].

확장阅读: 《AI 전환 7단계 프레임워크》에서 기업 현장에 AI를落地하는 전체 경로를 체계적으로 다루고 있다.

본 시리즈에 대하여

「云栖观察(Yunqi Observatory)」는 IAIUSE의 산업 현장 시리즈다. 2026 云栖大会(Yunqi Conference)에서 출발해, 연구자의 시각으로 AI 산업에서 실제로 일어나고 있는 변화를 해부한다. 화제성을 좇지 않으며, 베팅이 향하는 방향과 증거의 강도만을 살핀다.

시리즈는 모델 위의 시스템 계층, Agent 도입, Context 자산, 기업 AI 조직 설계, AI 제품 경쟁 단위의 이동 등 약 10개 주제를 다룬다.

필자는 대기업 컨설팅과 비즈니스 분석 분야에서 약 8년의 경력을 보유하고 있으며, IBM에 재직하며 통신·금융·보험·제조 업종 프로젝트에 참여했다. 이후 통신 사업자 제품, 인터넷 제품, AI 애플리케이션 개발 현장에서 요구사항 분석, 제품 설계, 크로스팀 도입을 담당해 왔다. 본 시리즈의 판단은 필자의 현장 관찰과 업계 교차 검증에 기반하며, 명확한 필자의 시각이 반영되어 있지만 어떠한 벤더의 입장도 대표하지 않는다.