2026년 5월 26일 | AI 최신 트렌드
5월 26일 오전 기준으로 눈에 들어온 축은 AI가 검색창, 개발 조직, 업무 조직, 과학 연구, 평가 벤치마크 안으로 들어갈 때 생기는 운영 비용이었다. 겉으로는 모두 “더 똑똑한 에이전트” 이야기처럼 보이지만, 자세히 보면 클릭이 줄어든 웹, 사람이 줄어든 팀, 통제가 필요한 코딩 에이전트, 과장되기 쉬운 과학 서사, 오염을 숨기는 평가 방식이 한꺼번에 올라오고 있었다.
1. Google AI 검색, 편하지만 웹의 클릭 구조를 다시 흔드는 중
WIRED의 Google AI Search 분석은 “사용자가 싫어해도 결국 쓰게 될 것”이라는 쪽에 가깝다. 핵심은 AI Overviews와 AI Mode가 너무 편하다는 점이다. 검색 결과 링크를 몇 개 열어 비교하던 과정을 Google이 한 덩어리 답변으로 압축해 주면, 사용자는 출처 사이트로 넘어가기 전에 이미 필요한 정보를 얻는다. 검색이 링크 목록에서 답변 엔진으로 바뀌는 셈이다.
나는 이 흐름이 단순 UI 업데이트가 아니라 웹의 수익 구조를 건드리는 문제라고 본다. 블로그, 뉴스, 문서 사이트는 검색 결과에서 클릭을 받아 광고·구독·브랜드 신뢰를 쌓아 왔다. 그런데 AI 답변이 앞에서 요약을 끝내면, 원문을 만든 쪽은 학습 재료와 인용 재료가 되지만 트래픽은 덜 받는다. Google은 편의를 주고, 사용자는 시간을 아끼지만, 콘텐츠 생산자의 보상 루프는 약해진다.
재미있는 건 이 문제가 품질 이슈와도 붙어 있다는 점이다. The Verge가 보도한 AI Overviews의 “disregard/ignore/skip” 오작동처럼, 검색창이 챗봇처럼 반응하면 짧은 단어 검색조차 이상해질 수 있다. 결국 AI 검색의 경쟁력은 답변을 길게 잘 쓰는 것만이 아니다. 기본 검색이 깨지지 않으면서 출처와 클릭 경로를 어떻게 남길지가 더 중요해지고 있다.
2. OpenAI Codex, 코딩 에이전트가 기업용 운영층으로 올라가는 장면
OpenAI는 Codex가 Gartner의 Enterprise AI Coding Agents Magic Quadrant에서 Leader로 평가됐다고 밝혔다. 보도자료 성격의 글이라 그대로 받아들이기보다, 어떤 기준을 전면에 세우는지를 보는 편이 낫다. OpenAI가 강조한 건 Codex 앱, IDE 확장, CLI, SDK, 클라우드 오케스트레이션 같은 넓은 표면과 approval gate, RBAC, 정책 설정, OS-level sandboxing, 감사 가능한 workspace governance다.
이 대목에서 나는 “코딩 에이전트 경쟁이 모델 성능표에서 운영 통제표로 넘어가는구나” 하고 봤다. 개인 개발자가 쓰는 에이전트는 빠르게 diff를 만들고 테스트를 돌리면 꽤 충분하다. 하지만 기업에서는 누가 어떤 repo에 어떤 권한으로 들어갔는지, 어떤 명령을 실행했는지, 실패하면 어디에서 멈추는지, 감사 로그가 남는지가 바로 도입 조건이 된다. 에이전트가 코드를 잘 짜는지만큼 권한과 증거를 어떻게 남기는지가 제품 가치가 되는 것이다.
OpenAI는 Codex가 매주 400만 명 이상에게 쓰이고, Cisco·Datadog·Dell Technologies·NVIDIA 같은 기업 사례가 있다고 설명했다. 숫자 자체보다 더 중요한 건 기업용 코딩 에이전트가 “IDE 플러그인 하나”에서 끝나지 않는다는 점이다. sandbox, review, policy, deployment option까지 같이 묶이면, 코딩 에이전트는 개발자 도구라기보다 소프트웨어 생산 공정의 한 계층이 된다. 이건 Anthropic, Google, GitHub 쪽 도구들도 피하기 어려운 방향으로 보인다.
3. ClickUp 감원, AI 에이전트 도입이 조직 설계 언어가 되는 순간
TechCrunch는 ClickUp이 인력 22%를 감원하면서 이를 비용 절감이 아니라 AI 중심 조직 전환으로 설명한 상황을 정리했다. ClickUp CEO Zeb Evans는 AI를 잘 활용해 큰 임팩트를 만드는 직원에게 기존 밴드를 넘어서는 보상을 하겠다는 메시지도 냈다. 기사에 따르면 ClickUp은 내부에서 약 3,000개의 AI 에이전트를 업무에 쓰고 있고, 직원은 직접 일을 모두 처리하기보다 에이전트를 지시하고 결과를 검토하는 역할로 이동하고 있다.
이 이야기는 듣기 좋은 생산성 서사와 불편한 고용 현실이 같이 들어 있다. 회사 입장에서는 AI 에이전트가 반복 작업을 줄이고, 남은 사람이 더 큰 범위를 다루게 만든다고 설명할 수 있다. 하지만 노동자 입장에서는 “AI를 잘 쓰는 사람은 더 보상받고, 그렇지 못한 사람은 줄어든다”는 신호로 읽힌다. 나는 이런 뉴스가 나올 때마다 AI 도입률보다 성과 측정 기준이 무엇으로 바뀌는지를 먼저 보게 된다.
ClickUp은 token consumption 자체보다 value created와 time saved를 측정하려 한다고 설명했다. 이 방향은 tokenmaxxing보다 낫지만, 여전히 어려운 문제가 남는다. 에이전트가 만든 초안의 품질 검토, 잘못된 자동화가 만든 부채, 사람 간 조율 비용은 단순히 절약 시간으로 잘 안 잡힌다. 그래서 AI 조직 전환을 평가하려면 “몇 명을 줄였는가”나 “몇 개 에이전트를 띄웠는가”가 아니라, 자동화 이후 품질·속도·재작업률·책임 소재가 실제로 어떻게 변했는지를 같이 봐야 한다.
4. Constraint Decay, 백엔드 코딩 에이전트가 구조 제약에서 무너지는 지점
GeekNews에 올라온 Constraint Decay 정리는 코딩 에이전트를 쓰는 입장에서 꽤 현실적으로 보였다. 요지는 간단하다. LLM 에이전트는 느슨한 기능 요구사항만 있을 때는 코드를 그럴듯하게 만든다. 그런데 framework, architecture pattern, database backend, ORM integration 같은 구조 제약이 쌓이면 성능이 급격히 떨어진다. 소개된 연구는 같은 OpenAPI 기능 요구사항을 고정하고 8개 웹 프레임워크와 여러 구조 제약을 바꿔 보면서 이 현상을 분리해 봤다.
눈에 띄는 숫자는 fully specified 조건에서 assertion pass rate가 평균 30포인트 가까이 떨어졌다는 부분이다. 또 agent logic failure의 45%가 data layer defect와 연결됐다고 한다. 이건 내가 실제 코딩 에이전트를 쓸 때 느끼는 감각과도 닿아 있다. CRUD 예시는 빨리 만들지만, transaction boundary, ORM runtime behavior, migration, repository layer 같은 제약이 겹치면 모델이 “보이는 패턴”을 따라가다가 실제 실행에서 깨지는 일이 많다.
이 문제의 교훈은 “에이전트에게 더 자세히 말하자”에서 끝나지 않는다. 오히려 구조 제약을 긴 Markdown으로 늘어놓으면 중요한 제약이 context 안에서 희석될 수 있다. 작은 예제 파일, 타입 검사, 정적 검증, 짧은 모듈, 단계별 테스트가 같이 있어야 한다. 나는 Constraint Decay를 코딩 에이전트의 능력 부족이라기보다 하네스 설계 문제로 보는 편이 맞다고 느꼈다. 에이전트가 구조를 지키게 하려면, 구조가 자연어 설명이 아니라 실행 가능한 검증으로 내려와야 한다.
5. Google I/O의 AI 과학, 전문 도구와 과학 에이전트 사이의 긴장
MIT Technology Review는 Google I/O에서 드러난 AI-driven science의 방향 변화를 짚었다. 핵심은 AlphaFold, WeatherNext, AlphaGenome, AlphaEarth Foundations처럼 특정 과학 문제에 맞춘 전문 도구의 성과와, LLM 기반 agentic system이 과학 자체를 수행할 수 있다는 더 큰 서사가 동시에 존재한다는 점이다. Google DeepMind의 Demis Hassabis가 과학 AI를 이야기하며 “singularity” 쪽 언어를 꺼낸 것도 이 긴장을 키운다.
나는 이 대목에서 과학 AI를 두 층으로 나눠 보는 게 필요하다고 생각했다. 첫 번째 층은 특정 문제를 아주 잘 푸는 전문 모델이다. AlphaFold가 단백질 구조 예측에서 실제 연구자들에게 쓰이고, WeatherNext가 예측 정확도와 조기 경보에 기여하는 식이다. 두 번째 층은 연구 가설 생성, 실험 설계, 문헌 탐색, 코드 작성, 도구 호출을 묶는 과학 에이전트다. 둘은 연결될 수 있지만, 같은 성숙도라고 보면 안 된다.
AI가 과학을 “돕는” 단계와 “하는” 단계 사이에는 검증 비용이 크게 남아 있다. 실험은 논리적으로 그럴듯한 답변보다 재현성, 측정, 실패 분석, 도메인 제약이 중요하다. 그래서 나는 Google의 AI 과학 서사를 볼 때도 실제 검증 가능한 전문 도구와 장기적 에이전트 비전을 분리해서 읽으려 한다. 과학 에이전트가 매력적인 방향인 건 맞지만, 지금 당장 성과를 내는 건 여전히 좁고 강한 도구들이 많다.
6. Zero-CoT Probe, reasoning 평가에서 오염이 숨어드는 방식
Hugging Face Daily Papers에서 잡힌 arXiv 2605.21856, “The Illusion of Reasoning”도 그냥 평가 논문으로 넘기기 아까웠다. 이 논문은 reasoning benchmark에서 data contamination이 더 교묘하게 숨어들 수 있다고 본다. 표면 문장이 그대로 들어간 오염은 n-gram overlap 같은 방식으로 어느 정도 찾을 수 있지만, benchmark 문제가 paraphrase되거나 synthetic data 안에 변형되어 들어가면 표면 검출이 어려워진다.
저자들이 제안한 Zero-CoT Probe의 아이디어는 흥미롭다. 모델에게 reasoning step을 길게 쓰게 하지 않고, 바로 최종 답만 내도록 만든다. 그런 다음 원래 문제와 논리 구조는 같지만 숫자와 맥락을 바꾼 reference question을 비교한다. 만약 모델이 원래 문제는 reasoning 없이 잘 맞히는데, 같은 구조의 새 문제에서는 무너지면, 실제 추론보다 memorized shortcut에 의존했을 가능성이 커진다.
이 논문이 중요한 이유는 “Chain-of-Thought를 보면 모델이 생각하는지 알 수 있다”는 기대를 흔든다는 데 있다. CoT가 길고 그럴듯하면 오히려 memorization 신호를 덮을 수 있다. 평가자로서는 불편한 결론이다. 앞으로 모델 성능표를 볼 때는 benchmark score뿐 아니라 데이터 출처, 오염 검출 방법, perturbation 방식, logits 접근 여부까지 같이 봐야 한다. 추론 능력을 평가하려면 추론 텍스트 자체를 의심하는 장치도 필요해졌다.
짧게 정리하면
이번 묶음에서 공통으로 보인 건 AI가 한 단계 더 제품 안쪽으로 들어갈수록 “능력”보다 “운영 조건”이 커진다는 점이다. Google AI 검색은 웹의 보상 구조를, Codex는 기업용 통제와 감사 로그를, ClickUp은 조직 설계와 성과 측정을, Constraint Decay는 에이전트 검증 하네스를, Google의 AI 과학은 전문 도구와 과학 에이전트의 경계를, Zero-CoT Probe는 평가 오염 문제를 드러냈다. AI가 더 많이 쓰일수록 질문은 점점 단순해진다. 이걸 어디까지 믿고, 누가 검증하고, 실패 비용은 어디에 남는가.
출처 목록
- WIRED, Even if you hate AI, you will use Google AI Search
- The Verge, Google’s AI search is so broken it can “disregard” what you’re looking for
- OpenAI, OpenAI named a Leader in enterprise coding agents by Gartner
- TechCrunch, What ClickUp’s mass layoff tells us about the future of work
- GeekNews, Constraint Decay: Vulnerability of LLM Agents in Backend Code Generation
- MIT Technology Review, Google I/O showed how the path for AI-driven science is shifting
- arXiv, The Illusion of Reasoning: Exposing Evasive Data Contamination in LLMs via Zero-CoT Truncation