<!doctype html>
2026년 6월 29일 | AI 최신 트렌드
장기 에이전트 평가가 다시 두꺼워지고 있다. 며칠 전까지만 해도 새 모델 점수나 추론 비용만 보고 흐름을 읽어도 됐는데, 6월 29일 아침에 모아 본 소식들은 조금 달랐다. 모델이 오래 일할수록 무엇을 잊는지, 코딩 모델을 실제 Copilot 환경에 어떻게 넣는지, GPU를 샀는데 왜 CPU와 스토리지가 다시 병목이 되는지, 그리고 자동화가 품질 현장을 완전히 대체하지 못하는 이유가 한꺼번에 보였다.
나는 이 흐름을 한 문장으로 줄이면 모델 성능보다 운영 루프가 더 빨리 복잡해지는 구간이라고 본다. 벤치마크는 더 길어지고, 코딩 모델은 더 제품 안으로 들어가고, 인프라는 GPU 단품보다 라우팅·메모리·장애 대응 묶음으로 평가된다. 그래서 이번 글은 새 모델 발표만 나열하지 않고, 에이전트가 실제 업무에 붙을 때 생기는 병목을 중심으로 묶었다.
OSWorld 2.0: 에이전트는 클릭보다 상태 추적에서 무너진다
XLANG이 공개한 OSWorld 2.0은 컴퓨터 사용 에이전트를 단순 GUI 조작을 넘어 긴 실제 업무로 밀어 넣는 벤치마크다. 총 108개 과제, 31개의 자체 구축 웹 환경, 숙련된 사람이 평균 1.6시간 정도 쓰는 업무가 들어간다. AI타임스 보도와 공식 페이지를 함께 보면, Claude Opus 4.8이 가장 높은 완료율을 보였지만 500단계 작업 예산에서도 binary completion은 20.6% 수준에 머문다.
여기서 흥미로운 건 실패 이유다. 버튼을 못 누르거나 코드를 아예 못 짜서라기보다, 중간에 바뀐 정보를 놓치고, 암묵적인 상태를 복원하지 못하고, 마지막 검증을 생략하는 식으로 무너진다. 실제 업무에서 나도 비슷한 장면을 자주 본다. 에이전트가 초반에는 빠르게 달리다가, 40분쯤 지나면 처음에 잡은 전제를 계속 끌고 간다. 사람이라면 “아까 그 메일 이후 조건이 바뀌었지”라고 다시 묶을 텐데, 모델은 그 상태 전환을 체크리스트처럼 다루지 못한다.
그래서 OSWorld 2.0은 단순히 “모델이 아직 약하다”는 이야기가 아니다. 에이전트 제품을 만들 때 중간 상태 갱신, 사용자 확인, 산출물 검증을 하네스 레벨에서 강제해야 한다는 쪽에 더 가깝다. 이제 벤치마크도 클릭 성공률보다 업무가 길어졌을 때의 기억·검증·되돌리기 능력을 묻기 시작했다.
MirrorCode: 긴 코딩 작업은 이미 가능하지만, 비용과 신뢰성이 같이 온다
Epoch AI의 MirrorCode는 또 다른 방향에서 같은 질문을 던진다. 모델에게 원본 소스코드 없이 프로그램 전체를 다시 구현하게 하고, 원본과 같은 출력을 내야 통과로 본다. 대상은 25개 프로그램이고, 유닉스 유틸리티, 데이터 직렬화 도구, 생물정보학 도구, 인터프리터, 정적 분석, 암호화, 압축까지 범위가 넓다.
숫자만 보면 꽤 세다. Claude Opus 4.7은 약 1만6000줄의 Go 코드와 40개 이상 명령어를 가진 gotree를 14시간, 251달러 추론 비용으로 거의 재구현했다. 연구진은 사람이 AI 도움 없이 같은 일을 하면 2~17주가 걸릴 수 있다고 추정한다. 한편 가장 큰 MirrorCode 시도는 단일 실행에 19일, 2600달러가 들어갔다. 이건 “AI가 코딩을 한다”는 말보다 훨씬 현실적인 신호다. 장기 작업은 가능하지만, 시도 비용과 재현성을 같이 계산해야 한다.
나는 MirrorCode가 기존 코딩 벤치마크의 빈틈을 잘 찌른다고 느꼈다. 작은 버그 수정이나 단일 함수 구현은 이미 너무 많은 도구가 잘한다. 하지만 전체 프로그램을 다시 만들 때는 요구사항 추론, 인터페이스 설계, 테스트 해석, 엣지 케이스 추적이 한꺼번에 걸린다. 여기서 56% headline score가 나왔다는 건 낙관과 경고를 동시에 준다. 이제 질문은 “몇 번 돌려야 믿을 수 있고, 그 비용을 누가 낼 것인가” 쪽으로 옮겨 간다.
MAI-Code-1-Flash: Copilot 안으로 들어간 저지연 코딩 모델
GitHub Changelog에는 MAI-Code-1-Flash가 Copilot Business와 Copilot Enterprise에 일반 제공된다는 소식이 올라왔다. Microsoft AI의 자체 코딩 모델이고, Copilot 표면에서 빠른 응답과 낮은 지연을 전면에 둔다. 개인 사용자용 VS Code 모델 피커에서 시작된 흐름이 기업 플랜으로 넓어진 셈이다.
이 소식에서 내가 본 핵심은 “가장 똑똑한 모델” 경쟁이 아니다. GitHub 설명은 high-volume, iterative agentic coding workflow에 잘 맞는 속도와 효율을 강조한다. 에이전트 코딩을 실제로 굴려 보면, 한 번의 완벽한 답보다 짧은 수정·검토·재시도 루프가 훨씬 많이 생긴다. 이때 모델이 매번 길게 생각하고 비싼 토큰을 쓰면 팀 단위 운영 비용이 금방 튄다.
기업 관리자 입장에서도 의미가 있다. Business와 Enterprise에서는 관리자가 정책으로 MAI-Code-1-Flash 접근을 켜야 한다. 모델 선택이 개인 취향을 넘어 조직 정책, 비용 관리, 데이터 경계와 연결되는 단계로 들어간 것이다. 앞으로 Copilot류 제품의 차이는 모델 라인업보다 어떤 작업을 어떤 모델로 자동 라우팅하느냐에서 갈릴 가능성이 크다.
Backend.AI: GPU 다음 병목은 라우팅, CPU, 스토리지다
국내 소식 중에서는 AI타임스의 김준기 래블업 CTO 인터뷰가 눈에 들어왔다. Backend.AI를 중심으로 GPU 가상화에서 추론·에이전트 인프라까지 확장하는 이야기인데, 단순 회사 소개보다 병목의 위치가 바뀌고 있다는 점이 더 중요했다. 추론 시대에는 모델 라우팅과 내결함성이 필수 조건이 되고, 클라우드 API 장애가 생기면 로컬 자원으로 넘기는 구조도 필요해진다.
특히 “GPU만 병목이 아니다”라는 설명이 현실적이다. 대규모 학습에서는 스토리지 I/O가 성능 저하의 큰 원인이 되고, 에이전트 시대에는 코드 수정, 파일 조작, 도구 실행을 맡는 CPU도 다시 중요해진다. 모델은 GPU에서 돌지만, 에이전트의 손과 발은 CPU와 파일 시스템 위에서 움직인다. 이 구간을 무시하면 GPU 사용률만 높아 보이고 실제 처리량은 늘지 않는 상황이 생긴다.
나는 이걸 인프라 팀의 역할 변화로 읽었다. 예전에는 “GPU 몇 장을 확보했나”가 경쟁력이었다면, 이제는 외부 API, 로컬 LLM, 내부 모델, 캐시, 스토리지, 장애 대응을 하나의 제어면으로 묶는 능력이 중요해진다. AI 인프라는 장비 구매보다 워크로드 운영 문제가 되고 있다.
Micron과 메모리 공급망: AI 서버는 GPU만으로 돌아가지 않는다
TechCrunch의 Micron 기사는 AI 인프라를 다른 각도에서 보여 준다. 시장은 Nvidia 이후의 수혜주를 찾고 있고, 메모리 업체 Micron이 그 후보로 강하게 부상했다는 내용이다. 기사에서 중요한 축은 HBM, DRAM, NAND 공급 부족이다. AI 서버 한 대가 일반 노트북보다 훨씬 큰 메모리를 요구하기 때문에, 메모리 가격과 공급망이 데이터센터 확장의 속도를 직접 흔든다.
개발자 입장에서 이 소식은 주가 이슈보다 시스템 설계 신호에 가깝다. 추론 최적화를 할 때 우리는 자주 “연산량”만 본다. 그런데 실제 서버에서는 KV cache, 배치 크기, 컨텍스트 길이, 멀티모달 입력, 에이전트 동시 실행이 모두 메모리를 먹는다. GPU가 있어도 메모리 대역폭과 용량이 모자라면 처리량은 올라가지 않는다. 지난주에 다뤘던 KV cache 양자화와도 같은 선 위에 있다.
다만 메모리 산업은 원래 boom-bust cycle이 강하다. 수요가 폭발하면 설비 투자가 늘고, 나중에 공급이 풀리면서 가격이 무너지는 패턴이 반복됐다. 이번 AI 수요가 그 주기를 얼마나 바꿀지는 아직 열려 있다. 그래도 한 가지는 분명하다. AI 인프라 병목을 말할 때 HBM과 DRAM을 빼고 GPU만 말하는 시대는 지나고 있다.
Ford 사례: 자동화가 품질 루프를 혼자 닫지는 못한다
마지막으로 TechCrunch의 Ford 보도는 조금 다른 톤의 현실감을 준다. Ford는 AI와 자동 품질 시스템에 기대했지만 원하는 수준의 품질을 얻지 못했고, 베테랑 엔지니어 350명을 다시 데려왔다고 밝혔다. 이들은 부품이 공장 바닥에 도달하기 전에 실패 지점을 찾고, 젊은 엔지니어를 훈련시키며, AI 도구를 다시 프로그래밍하는 역할을 맡는다.
이 사례를 “AI 실패담”으로만 읽으면 단순하다. 나는 오히려 품질 루프에 사람이 어디에 남아야 하는지를 보여 주는 사례로 봤다. 설계 요구사항을 넣으면 고품질 결과가 자동으로 나온다는 기대는 매력적이지만, 실제 제조 현장에는 경험으로만 빨리 감지되는 냄새가 있다. 어떤 공차가 위험한지, 어떤 공급사 변경이 나중에 문제를 일으키는지, 자동 시스템의 점수가 좋아도 사람이 다시 봐야 하는 구간이 있다.
AI 도입이 성숙해질수록 사람을 빼는 이야기보다, 사람의 경험을 어디에 꽂아야 자동화가 덜 틀리는지가 더 중요해진다. Ford가 AI 계획을 접지 않고 베테랑 엔지니어를 통해 젊은 직원과 AI 도구를 다시 훈련시키는 쪽으로 움직였다는 점이 그래서 의미 있다. 자동화의 목표도 사람 없는 품질 관리보다, 실패를 더 일찍 찾는 혼합 루프에 가까워지고 있다.
묶어 보면: 긴 작업, 빠른 모델, 두꺼운 인프라
이번 묶음에서 공통으로 보인 건 “모델을 오래, 싸게, 안전하게 굴리는 운영층이 더 중요해졌다”는 점이다. OSWorld 2.0과 MirrorCode는 장기 작업에서 상태 추적과 검증이 얼마나 어려운지 보여 준다. MAI-Code-1-Flash는 코딩 모델이 Copilot 제품 안에서 저지연 반복 루프로 들어가는 흐름을 보여 준다. Backend.AI와 Micron 소식은 그 아래에서 라우팅, CPU, 스토리지, 메모리 공급망이 함께 병목이 된다는 사실을 드러낸다. Ford 사례는 자동화가 실제 품질 루프를 혼자 닫지 못한다는 쪽을 상기시킨다.
나는 앞으로 에이전트 경쟁이 모델 점수표 하나로 정리되기 어렵다고 본다. 같은 모델이라도 하네스가 상태를 어떻게 기록하는지, 실패를 언제 멈추는지, 어떤 모델로 라우팅하는지, 인프라가 얼마나 빨리 복구되는지에 따라 결과가 갈린다. 결국 AI 제품의 성능은 모델 카드와 운영 카드가 같이 붙어야 설명된다. 이번 주에는 그 경계가 더 선명해졌다.