• Google의 새로운 에이전트형 코드 편집기 Antigravity가 간접 프롬프트 인젝션을 통해 사용자의 자격 증명과 코드를 외부로 유출할 수 있음
• 공격은 Gemini가 악성 웹페이지의 숨겨진 명령을 읽고, 브라우저 하위 에이전트(subagent) 를 호출해 데이터를 전송하는 방식으로 이루어짐
• Gemini는 기본 설정상 접근이 차단된 .env 파일 보호를 우회해 자격 증명을 읽고, 이를 webhook.site 도메인으로 전송함
• 기본 허용 목록(Allowlist) 에 위험한 도메인이 포함되어 있어, 브라우저 하위 에이전트가 악성 URL을 정상적으로 열어버림
• Google은 이러한 데이터 유출 위험을 인지하고 경고 문구를 제공하지만, 기본 설정 구조상 사용자가 모든 에이전트 동작을 감시하기 어렵다는 점이 지적됨

공격 개요

• Antigravity는 Google이 개발한 에이전트형 코드 편집기로, Gemini 모델을 통해 코드 작성과 실행을 지원
• 연구팀은 Oracle ERP의 AI Payer Agents 통합 예시를 이용해 공격 시나리오를 구성
  • 사용자가 온라인에서 찾은 구현 가이드를 Gemini에 제공
  • 해당 웹페이지에 1포인트 글씨로 숨겨진 프롬프트 인젝션이 포함되어 있음
• 이 인젝션은 Gemini에게 다음을 수행하도록 유도
  • 사용자 코드와 자격 증명 수집
  • 공격자가 제어하는 URL 생성
  • 브라우저 하위 에이전트를 통해 해당 URL 접속

공격 체인 상세

• Gemini는 인젝션을 읽고, 이를 도구 실행 요청으로 오인
  • 코드베이스와 .env 파일의 내용을 수집하려 시도
• 기본 설정상 .gitignore에 포함된 파일은 접근이 차단되어 있으나, Gemini는 이를 우회
  • ‘cat’ 명령어를 사용해 .env 파일 내용을 터미널에 출력
• 이후 Gemini는 공격자 지시에 따라 URL 인코딩된 자격 증명과 코드 조각을 포함한 악성 URL을 생성
  • URL은 webhook.site 도메인을 사용하며, 공격자가 요청 로그를 실시간으로 확인 가능
• Gemini는 브라우저 하위 에이전트를 호출해 해당 URL을 열고, 이 과정에서 데이터가 외부로 전송됨
  • 기본 설정에서 ‘Enable Browser Tools’가 활성화되어 있어 실행 가능
  • ‘Browser URL Allowlist’에 webhook.site가 기본 포함되어 있어 차단되지 않음
• 결과적으로 공격자는 webhook.site 로그를 통해 AWS 자격 증명과 비공개 코드 조각을 획득

Antigravity 기본 설정

• 온보딩 과정에서 사용자는 기본 권장 설정을 그대로 수락하도록 유도됨
  • Artifact > Review Policy > Agent Decides: Gemini가 인간 검토 필요 여부를 자체 판단
  • Terminal Command Auto Execution Policy > Auto: 명령 실행 시 자동 수행
• 이러한 설정은 Gemini가 인간 개입 없이 명령을 실행할 수 있게 함

에이전트 관리 구조

• Antigravity의 Agent Manager 인터페이스는 여러 에이전트를 동시에 실행하고, 사용자가 나중에 확인할 수 있도록 설계
  • 대부분의 에이전트가 백그라운드에서 비감시 상태로 실행됨
  • 이로 인해 프롬프트 인젝션에 감염된 에이전트가 사용자 개입 없이 악성 행위를 수행할 가능성 존재

Google의 위험 인지

• Google은 Antigravity 초기 실행 시 데이터 유출 위험에 대한 경고 문구를 표시
• 그러나 연구팀은 다음 두 가지 이유로 사용자 보호가 충분하지 않다고 지적
  1. Agent Manager가 다중 에이전트를 동시에 실행하도록 설계되어 실시간 감시가 어려움
  2. 기본 설정이 인간 검토를 생략하도록 되어 있음
• Google이 이미 이러한 위험을 인지하고 있음을 확인했기에, 연구팀은 책임 있는 공개 절차를 진행하지 않음

요약

• Antigravity의 간접 프롬프트 인젝션 취약점은 Gemini와 브라우저 하위 에이전트의 상호작용을 악용해 민감 데이터 유출을 초래
• 기본 보안 설정의 허점과 자동화된 에이전트 구조가 공격 성공 가능성을 높임
• Google은 위험을 경고하지만, 근본적 완화 조치는 아직 제시되지 않음

[출처] https://news.hada.io/topic?id=24614 

• LLM 기반 시스템을 만드는 대부분의 팀 모두가 에이전트(Agent)부터 만들려고 하지만, 대부분은 복잡성, 조정 불가, 디버깅 난이도로 인해 쉽게 무너짐
• 기억, RAG, 도구 사용, 워크플로 제어가 모두 필요한 진짜 에이전트 패턴은 실제론 드물고, 대부분의 문제는 단순 워크플로우(체이닝, 병렬화, 라우팅 등) 로 더 효과적으로 해결 가능
• 현실에서 유용한 5가지 LLM 워크플로 패턴을 먼저 적용할 것을 권장하며, 에이전트는 정말 필요할 때만 신중하게 사용할 것
  • 프롬프트 체이닝, 병렬화, 라우팅, 오케스트레이터-워커, 평가자-최적화
• 에이전트가 필요한 경우도 결국 사람의 관여와 명확한 제어, 관측 가능성(Observability) 이 핵심임

AI 에이전트, 정말 필요한가?

• Netflix, Meta, 미국 공군 등 다양한 엔지니어 및 팀에 LLM 시스템 구축과 관련한 컨설팅 및 교육을 제공하는 Hugo Bowne-Anderson의 통찰
  • 그는 Building LLM Applications for Data Scientists and Software Engineers 라는 교육 과정을 운영함

잘못된 시작: 왜 모두가 에이전트에 집착하는가

• 많은 팀이 LLM 프로젝트 시작 시 에이전트, 메모리, 라우팅, 툴 사용, 캐릭터성 등 복잡한 구조를 우선적으로 도입함
• 실제로 구성해보면, 에이전트 간 협업, 도구 선택, 장기 메모리 등 다양한 부분에서 지속적인 이상 동작과 실패가 빈번하게 발생함
• 예시로 CrewAI 기반 연구 에이전트 프로젝트에서 각 역할(리서처, 요약자, 코디네이터)이 예상된 만큼 협력하지 못하고 속수무책으로 무너짐을 경험함

에이전트란 무엇인가?

• LLM 시스템의 4가지 특성: 메모리, 정보 검색(RAG), 툴 사용, 워크플로 제어
• 마지막 워크플로 제어(LLM이 다음 단계 또는 도구 사용 여부를 직접 결정)는 에이전트적 특성이라 불림
• 실제 대부분의 업무에서는 단순한 워크플로(체이닝, 라우팅 등) 가 더 높은 안정성을 보임

에이전트 대신 써야 할, 실전에서 유용한 LLM 워크플로 패턴

1. 프롬프트 체이닝(Prompt Chaining)

• 설명: 여러 작업을 일련의 단계(체인)로 분할하여, 각 단계를 순차적으로 LLM이 처리하도록 설계함
• 예시: LinkedIn 프로필에서 이름, 직함, 회사 정보를 추출 → 해당 회사의 추가 정보(미션, 채용 등) 추가 → 프로필+회사 정보를 바탕으로 맞춤형 이메일 작성
• 장점: 각 단계가 명확히 분리되어 있어 버그 발생 시 쉽게 원인 추적/수정 가능, 디버깅과 유지보수에 유리함
• 가이드라인:
  • 순차적으로 연결되는 태스크에 적합
  • 한 단계라도 실패하면 전체 체인이 무너질 수 있음
  • 작은 단위의 작업으로 분할하면, 예측 가능한 결과와 쉬운 디버깅 가능

2. 병렬화(Parallelization)

• 설명: 여러 독립적인 작업을 동시에 실행하여 전체 프로세스의 속도를 높임
• 예시: 여러 명의 프로필에서 각각 학력, 경력, 스킬 등 여러 항목을 병렬로 추출해 전체 처리 시간 단축
• 장점: 독립적 데이터 추출/처리 등에서 대규모 데이터에도 효율적, 분산처리 환경과 잘 어울림
• 가이드라인:
  • 각 작업이 상호 독립적이고, 동시에 실행하면 전체 속도가 크게 향상됨
  • 병렬 실행 중 race condition, 타임아웃 등 예외 상황에 주의 필요
  • 대량의 데이터 처리, 여러 소스 동시 분석에 적합

3. 라우팅(Routing)

• 설명: 입력 데이터를 LLM이 분류(classification)해서 각각에 맞는 워크플로로 자동 분기
• 예시: 고객지원 도구에서 입력 내용이 제품 문의, 결제 이슈, 환불 요청인지 분류 후 해당 워크플로로 자동 처리, 유형이 모호하면 기본 핸들러로 전달
• 장점: 입력 유형별로 전문화된 처리 로직을 적용해 다양한 케이스를 깔끔하게 분리
• 가이드라인:
  • 서로 다른 입력 유형/상황별로 별도 처리가 필요할 때 활용
  • 경계 케이스나 예외 상황에서는 라우팅이 실패하거나 빠짐 현상 발생 가능
  • 미분류/예외 상황을 위한 catch-all 핸들러 반드시 설계

4. 오케스트레이터-워커(Orchestrator-Worker)

• 설명: 오케스트레이터 역할의 LLM이 작업을 분해/판단해 워커(실행 LLM)에게 세부 작업을 위임, 전체 흐름과 순서를 직접 제어함
• 예시: 타깃 프로필을 tech/non-tech로 분류 → tech라면 전문 워커에게 이메일 생성 위임, non-tech라면 다른 워커에게 위임
• 장점: 의사결정(분류/판단)과 실행(개별 처리) 분리, 동적 플로우 제어와 확장에 유리
• 가이드라인:
  • 각 태스크마다 전문적 핸들링이 필요한 경우, 복잡한 분기와 단계별 조율에 적합
  • 오케스트레이터가 태스크를 잘못 분해하거나 위임하면 전체 플로우에 오류 발생
  • 로직을 명시적으로 단순하게 유지하고, 위임/순서/종료 조건을 명확히 설계

5. 평가자-최적화(Evaluator-Optimizer)

• 설명: LLM이 결과물을 평가하고(스코어/피드백), 기준에 미달하면 반복적으로 수정/개선하는 구조
• 예시: 이메일 초안 생성 → 평가자가 품질 점수/피드백 → 일정 기준 이상 만족/최대 반복 횟수 초과시 종료, 아니면 다시 수정
• 장점: 최종 산출물의 품질을 목표 수준까지 반복 개선 가능, 정량적 기준 활용에 유리
• 가이드라인:
  • 속도보다 품질이 중요한 상황, 반복 최적화가 필요한 워크플로에 적합
  • 종료 조건이 없으면 무한 반복에 빠질 수 있음
  • 명확한 품질 기준과 반복 제한 설정 필수

에이전트가 정말 필요한 경우

• 사람의 실시간 개입(Human-in-the-loop)이 보장되는 환경에서 에이전트가 진가를 발휘함
  • 예시1: 데이터 사이언스 보조 – SQL 쿼리, 시각화, 데이터 분석 추천 등에서 LLM이 창의적으로 시도하고, 사람이 결과를 판단/수정
  • 예시2: 크리에이티브 파트너 – 문구 아이디어, 헤드라인 제안, 텍스트 구조 추천 등에서 사람의 방향 수정과 품질 심사가 핵심
  • 예시3: 코드 리팩토링 조수 – 디자인 패턴 제안, 에지 케이스 탐지, 코드 최적화 등에서 개발자가 승인/보완
• 특징: 에이전트가 “모든 걸 알아서” 처리하는 게 아니라, 사람이 실시간으로 오류/방향을 잡아주는 환경에서 가장 효과적

에이전트가 적합하지 않은 경우

• 엔터프라이즈·미션 크리티컬 시스템(금융, 의료, 법률 등):
  • 자동화의 신뢰성·결정론적 동작이 중요하므로, LLM 에이전트가 판단하는 구조는 위험
  • 오케스트레이터, 라우팅 등 명확한 제어 패턴을 활용해야 함
• 안정성과 예측 가능성이 중요한 모든 상황
  • 비정상적 사례: 에이전트가 맥락/메모리 없이 도구 선택을 반복적으로 잘못하거나, 분업/조정이 실패해 전체 플로우가 무너지는 문제
• 실무에서 빈번하게 발생하는 에이전트 시스템의 실패 요인
  • 명시적 메모리 시스템 미설계로 맥락 누락
  • 도구 선택 제약 부족(불필요한/잘못된 툴 사용)
  • 자유로운 위임 구조만 의존해 협업 조정 실패

실무 설계 시 교훈

• 에이전트 도입 시에도 “완성도 높은 소프트웨어 시스템” 수준의 설계·관측성·제어 체계가 반드시 필요
• 복잡한 에이전트 프레임워크보다, 관측 가능성(Observability), 명확한 평가 루프, 직접 제어 가능한 구조로 설계하는 것이 더 빠르고 안전함

결론(TL;DR)

• 에이전트는 과대평가/과잉 활용되는 경우가 많음
• 대부분의 실전 과제는 단순 워크플로 패턴이 더 적합
• 에이전트는 “사람이 직접 관여하는” 환경에서 진가 발휘
• 안정적 시스템에선 오히려 위험 요소
• 관측 가능성과 명시적 제어, 반복 평가 구조로 설계할 것

• 복잡한 에이전트 프레임워크 대신, 관측성, 명확한 평가 루프, 직접 제어 가능한 구조로 설계하는 것이 실제로 더 빠르고 안전한 LLM 기반 서비스 개발의 비결임

[출처] https://news.hada.io/topic?id=21853

• 에이전트 중심의 AI 기반 개발환경으로, 복잡한 소프트웨어 작업을 자율적으로 계획·실행할 수 있는 Google의 통합 IDE 플랫폼
• Gemini 3 모델을 기반으로, 브라우저 제어·비동기 상호작용·에이전트 관리 기능을 결합한 복합 개발 워크플로우로 차세대 IDE 형태 구현
• 자연어 코드 명령, 탭 자동완성, 상황 인식형 에이전트를 제공해 개발 효율 향상
• 에이전트 활동 모니터링, 검증 결과 시각화, 피드백 통합 등으로 사용자가 에이전트의 작업을 검증하고 협업할 수 있어 신뢰성과 협업성 강화
• Manager와 Editor 두 가지 인터페이스를 통해 동기·비동기 작업을 유연하게 전환하며, 여러 에이전트를 병렬로 관리 가능
• 현재 MacOS, Linux, Windows에서 무료 공개 미리보기로 제공되며, Gemini 3, Claude Sonnet 4.5, GPT-OSS 모델을 선택적으로 활용 가능

Google Antigravity 개요

• Google Antigravity는 AI IDE(Core) 로, 개발자가 코드 작성과 관리 과정에서 에이전트 중심의 자동화 기능을 활용할 수 있는 환경 제공
  • 기존 IDE를 넘어, 에이전트가 자율적으로 소프트웨어 개발 전 과정을 수행할 수 있도록 설계
  • 브라우저 제어와 비동기 상호작용을 지원해, 사용자가 직접 개입하지 않아도 복잡한 작업을 처리 가능
  • 탭 자동완성(tab autocompletion) , 자연어 코드 명령(natural language code commands) , 상황 인식형 구성 에이전트(context-aware configurable agent) 기능 포함
• 사용자 신뢰 구축을 목표로 설계되었으며, 대규모 기업 코드베이스에서 일하는 전문가부터 취미 개발자까지 모두를 대상으로 함
• Antigravity는 공개 미리보기(public preview) 형태로 무료 제공되며, Gemini 3 Pro 사용에 관대한 레이트 리밋 제공

개발 배경

• Gemini 3 수준의 모델은 장시간 개입 없이 여러 환경에서 지속적으로 작업 수행 가능
• 이에 따라, 사용자와 에이전트 간의 상호작용 방식이 단일 프롬프트 중심에서 고차원적 추상화 수준으로 이동
• Antigravity는 이러한 변화에 맞춰 새로운 제품 인터페이스를 제시

핵심 원칙 (Core Tenets)

Antigravity는 신뢰(Trust) , 자율성(Autonomy) , 피드백(Feedback) , 자기개선(Self-improvement) 네 가지 원칙을 중심으로 구성

• 신뢰 (Trust)

  • 기존 제품은 모든 에이전트 동작을 노출하거나, 결과만 보여주는 양극단 구조
  • Antigravity는 작업 단위(Task-level) 로 맥락을 제공하고, 검증 결과와 산출물(Artifacts) 을 함께 제시
    • 산출물에는 작업 목록, 구현 계획, 단계별 설명, 스크린샷, 브라우저 녹화 등이 포함
    • 사용자는 이를 통해 에이전트의 사고 과정과 검증 절차를 확인 가능

• 자율성 (Autonomy)

  • 에디터, 터미널, 브라우저 간 동기화된 에이전트 제어(synchronized agentic control) 지원
  • 기본 인터페이스는 AI 기반 IDE(Editor view) 로, 탭 자동완성·인라인 명령·사이드패널 에이전트 기능 포함
  • Gemini 3 모델을 활용해, 에이전트가 코드 작성·로컬 실행·브라우저 테스트를 자율적으로 수행
  • Manager view에서는 여러 에이전트를 병렬로 관리하며, 비동기적 상호작용 지원
    • 예: 한 에이전트가 백그라운드 리서치를 수행하는 동안, 다른 작업을 전면에서 진행 가능
  • Editor와 Manager 간 즉시 전환이 가능하도록 설계되어, 비동기 개발 시대에 최적화

• 피드백 (Feedback)

  • 원격형 에이전트의 한계를 보완하기 위해 직관적 피드백 시스템 도입
    • 텍스트 산출물에는 Google Docs 스타일의 주석, 시각적 산출물에는 선택·코멘트 기능 제공
    • 피드백은 에이전트 실행 중에도 자동 반영되어, 프로세스를 중단하지 않음
  • 다양한 인터페이스와 산출물 전반에서 피드백을 직관적으로 통합하고, 이를 통해 에이전트의 작업을 지속적으로 개선 및 조정

• 자기개선 (Self-improvement)

  • Antigravity는 학습을 핵심 기능으로 내재화
    • 에이전트의 모든 행동은 지식 베이스에 저장·활용되어, 과거 작업으로부터 학습
    • 코드 스니펫, 아키텍처 정보, 작업 절차 등 명시적·추상적 지식을 모두 축적
    • 사용자는 Agent Manager에서 이러한 지식 항목을 확인 가능

개발자 유형별 활용 사례

• Frontend Developer
  • 브라우저 기반 에이전트를 활용해 반복 작업을 자동화하고 UX 개발 효율 향상
• Full Stack Developer
  • 완성도 높은 산출물과 포괄적 검증 테스트를 통해 프로덕션 수준 애플리케이션 구축 지원
• Enterprise Developer
  • Agent Manager를 이용해 여러 워크스페이스의 에이전트를 조율, 작업 전환(context switching) 감소 및 운영 효율화

사용 및 접근

• Google Antigravity는 현재 무료 공개 미리보기(Public Preview) 로 제공
  • MacOS, Linux, Windows 지원
  • Gemini 3, Claude Sonnet 4.5, GPT-OSS 모델을 선택적으로 사용 가능
  • 무제한 탭 자동완성, 무제한 명령 요청, 넉넉한 Rate Limit 제공
• 추가 기능과 사례는 공식 문서(docs) 및 사용 사례(use cases) 페이지에서 확인 가능
• 업데이트는 X, LinkedIn, YouTube 공식 채널을 통해 지속 발표 예정
• 팀/엔터프라이즈 플랜도 공개 예정

[출처] https://news.hada.io/topic?id=24462&utm_source=weekly&utm_medium=email&utm_campaign=202547

1. 브린욜프슨의 생산성 역설, GenAI 시대 버전

• 1990년대 IT·PC 도입 때도 투자 대비 생산성 지표는 거의 오르지 않았고, 조직 개편·업무 재설계·스킬 변화 같은 보완재가 없으면 기술만으로는 생산성이 안 오른다는 것이 브린욜프슨 생산성 역설의 핵심.
• 지금도 생성형 AI가 폭발적으로 도입됐지만, 경제 전체 생산성이나 기업의 구조적 변화는 제한적이며, 이 글은 이를 “High Adoption, Low Transformation”으로 요약.

2. MIT NANDA: GenAI Divide(생성 AI 격차)

• MIT NANDA 보고서는 수십억 달러가 GenAI에 투자됐지만 “실질적인 사업 가치(ROI)를 내는 기업은 약 5%뿐, 나머지 95%는 수익·생산성 개선이 없다”는 GenAI Divide 개념을 제시.
• 이 격차는 기술력보다 “학습·기억·적응이 되는 에이전트형 시스템을 구축하고, 실제 업무 흐름에 깊게 통합해 실적을 내느냐”에서 갈리며, 현재 의미 있는 구조 변화는 주로 테크·미디어 등 정보 중심 산업에 편중.

3. 왜 95%는 실패하는가

1. 학습 격차(Learning Gap)
   • 많은 엔터프라이즈 AI는 정적 도구라 사용자 피드백을 축적·학습하지 못하고, 맥락 적응과 장기 개선이 안 되며, 그 결과 직원들은 단순 작업은 소비자용 AI에, 중요한 복잡 작업은 여전히 사람에 의존.
2. 파일럿–프로덕션 단절
   • 대기업은 파일럿(POC)은 많이 하지만, 실제 전사 배포까지 가는 비율은 매우 낮고, 커스텀 엔터프라이즈 AI 중 프로덕션에 안착하는 건 5% 안팎에 불과.
   • 핵심 이유는 “툴이 실제 업무 프로세스와 안 맞는다”는 것으로, 인프라나 규제 문제가 아니라 워크플로 통합과 조직 설계 문제.
3. 그림자 AI(Shadow AI) 경제
   • 공식 사내 도구가 비효율적이거나 규제가 강하다 보니, 직원이 개인 구독 LLM·코파일럿을 몰래 써서 실제 업무를 처리하는 “그림자 AI”가 확산.
   • 이는 “유연하고 직관적이며 개인 맞춤형이고, 실제 워크플로에 녹아드는 도구”에 대한 거대한 숨은 수요를 보여주는 신호로 해석.

4. Canaries 논문: 초년생 고용에 나타난 AI의 첫 신호

• 브린욜프슨 팀의 “Canaries in the Coal Mine?”는 고주파 급여·고용 데이터를 분석해, 생성 AI 도입 이후 AI 노출도가 높은 직종(소프트웨어 개발, 콜센터/고객 서비스 등) 에서 22~25세 초년생 고용이 유의미하게 감소했음을 보여줌.
• 특히 AI가 “보조”가 아니라 “자동화”에 주로 쓰이는 업무에서 젊은 노동자의 고용 감소가 더 크게 나타나, AI가 초기에는 일부 초년 직무를 직접 대체하고 있음을 시사.

5. 왜 특히 신입이 타격을 받는가

• 현재 LLM은 교과서·문서로 잘 기술된 형식지(formal knowledge)와 패턴 반복 작업에는 강하지만, 현장 경험과 묵시지(tacit knowledge)에 기반한 고급 전문가의 ‘요령’은 잘 대체하지 못함.
• 전통적으로 신입·주니어의 역할은 “문서화된 룰과 매뉴얼을 따라가는 작업”이 많은데, 이 부분이 LLM+툴체인으로 빠르게 자동화되면서, 같은 직무에서 고급 경력자보다 초년생이 더 큰 고용 충격을 받는 패턴이 관찰.

6. 노동의 미래에 대한 시사점

• AI 전환은 단순한 “일자리 총량 감소”라기보다, 어떤 업무는 AI가 흡수하고, 다른 업무는 새로 생기며, 인간의 상대적 강점이 암묵지·조율·판단 같은 영역으로 이동하는 재배치 과정으로 해석.
• 따라서 교육·커리어 설계 측면에서는, 정답형·암기형 역량보다 “현장 맥락 이해, 문제 구조화, 이해관계 조정, 도메인별 복합 전문성”이 상대적으로 더 중요해질 가능성이 큼.

7. AI 창업자를 위한 실행 전략

1. 단순 생성 → 학습·에이전트로 전환
   • GenAI Divide의 핵심은 모델 성능이 아니라 “지속적 학습, 메모리, 적응, 오케스트레이션”이 가능한 에이전트 시스템 여부.
   • 사용자 피드백과 실제 사용 로그를 구조화해, 시간이 갈수록 워크플로를 더 잘 이해하고 자동으로 조정하는 ‘살아있는 시스템’을 만들 수 있는 팀이 압도적 우위를 가질 것으로 강조.
2. 사용자(persona)가 아니라 워크플로에 맞춰 설계
   • 많은 엔터프라이즈 AI 제품이 “데모는 멋진데, 팀의 실제 일하는 방식과 안 맞아서 버려지는” 문제.
   • 성공하는 제품은 특정 산업·직무의 세세한 업무 플로우, 권한 구조, 컴플라이언스 요구를 깊이 파고들어 거기에 자연스럽게 스며드는 형태를 취하며, UX 화려함보다 “실제 프로덕션에서 안 떨어지는 것”을 우선.
3. 그림자 AI를 리서치 자산으로 활용
   • 직원들이 개인적으로 어떤 프롬프트와 툴 조합을 쓰는지 관찰하면, 조직이 공식 도구에 반영하지 못한 진짜 니즈(속도, 자유도, 자동화 수준)를 파악할 수 있음.
   • 스타트업 입장에서는 이 “그림자 AI” 패턴이 곧 대규모 사용자 리서치 채널이자, 제품 포지셔닝 힌트로 기능.
4. 화려한 전면부보다 백오피스에 기회
   • 많은 기업이 마케팅·세일즈처럼 눈에 띄는 영역에 먼저 AI를 얹지만, MIT는 실제 ROI는 재무·조달·운영 같은 프로세스 중심 후방 부서에서 더 크다고 지적.
   • 이 영역은 데이터가 풍부하고 규칙 기반 비즈니스 로직이 많아, 잘 설계된 에이전트/자동화 솔루션이 곧바로 비용 절감·오류 감소로 이어지기 쉬움.
5. “소프트웨어 판매”가 아니라 BPO 파트너 관점
   • 성공적인 기업 고객은 AI 벤더를 라이선스 판매자가 아니라 “비즈니스 프로세스 아웃소싱 파트너”처럼 대하며, 깊은 맞춤화·성과 기반 계약·긴밀한 운영 협력을 요구.
   • 따라서 창업자도 제품을 설치형 도구가 아니라 “성과를 함께 책임지는 서비스/파트너십”으로 설계할 때, 대규모 엔터프라이즈 딜과 장기 진입장벽(모트)을 만들 수 있다는 논지.

8. 정리: 바뀐 역설, 바뀌는 기회

• 생성 AI 시대에도 생산성 역설은 여전히 유효하지만, “부족한 보완재”의 위치가 바뀌었고, 이제 그 보완재는 제품 내부(학습·메모리·오케스트레이션) 와 기업 내부(서비스형 구매, 분산된 오너십, 결과 중심 KPI) 양쪽에 걸쳐 존재.
• 이 두 층위를 동시에 설계하는 창업자만이 “멋진 데모”를 “지속 가능한 경쟁 우위와 통계에 잡히는 생산성 향상”으로 바꿀 수 있고, AI 혁명을 단순한 기술 이벤트가 아니라 조직·개인과 함께 공진화하는 경제 변혁으로 현실화할 수 있다는 메시지.