AI 트렌드 | 7월 31일 : iCloud AI, Gemini Robotics ER 2, Anyscale, SpecFirst

2026년 7월 31일 | AI 최신 트렌드

---

AI 사용량은 클라우드 구독의 새 등급이 되고, 로봇 모델은 답을 내놓는 대신 여러 실행기를 실시간으로 지휘하기 시작했다. GPU를 빌려 주던 인프라 회사는 분산 실행 소프트웨어까지 품으려 하고, 코딩 에이전트 연구는 구현 전에 명세를 따로 뽑는 단계로 돌아갔다. 서로 멀어 보이는 네 소식이지만 좋은 모델 하나보다 사용량·도구·실행 계층·명세를 함께 설계하는 일이 중요해진 흐름은 꽤 선명하다.

Apple은 AI 사용량을 iCloud Plus 업그레이드와 연결하려 한다

Apple은 서버 모델을 쓰는 AI 기능의 사용 한도와 iCloud Plus 구독을 연결하는 업그레이드 가능성을 언급했다. 이미지: The Verge·Getty Images

The Verge 보도에 따르면 Tim Cook은 실적 발표에서 Apple Intelligence와 새 Siri AI를 많이 쓰려는 사람을 위해 iCloud Plus에서 사용량을 늘리는 업그레이드가 생길 수 있다고 말했다. 아직 구체적인 요금제나 제공량이 확정된 발표는 아니다. 다만 Apple이 6월에 서버 모델을 사용하는 이미지 생성 등 일부 AI 기능에는 일일 한도가 있고, 다수 iCloud Plus 요금제에 더 많은 접근량이 제공된다고 설명한 뒤 나온 발언이라 방향은 읽을 수 있다.

구독형 AI에서 사용 한도는 단순한 가격표가 아니다. 로컬 처리와 서버 처리 중 어느 쪽을 택하는지, 요청 한 건이 얼마나 많은 추론 자원을 쓰는지, 화면 이해와 앱 간 동작처럼 긴 작업이 어디서 중단되는지를 사용자 경험으로 번역하는 장치다. 저장 공간은 50GB나 2TB처럼 비교가 쉽지만 AI 사용량은 요청 수, 토큰, 이미지, 작업 시간 가운데 무엇을 기준으로 삼느냐에 따라 체감이 크게 달라진다.

나는 이 대목에서 월간 횟수보다 작업이 시작되기 전에 남은 한도와 예상 비용을 보여 주는 방식이 더 중요하다고 봤다. 앱 여러 개를 오가는 Siri 작업이 중간에 한도를 만나면 단순 채팅 한 번 실패한 것보다 복구 비용이 크다. 유료 등급을 만든다면 기능별 한도, 온디바이스 대체 경로, 중단된 작업의 재개 조건을 함께 설명해야 한다. 그렇지 않으면 높은 요금제가 더 똑똑한 모델을 뜻하는지, 같은 모델을 더 자주 쓰게 해 주는지부터 헷갈린다.

Apple에는 서비스 매출을 늘릴 수 있는 선택지지만, 개발자에게는 앱 안의 AI 기능을 설계하는 조건이 하나 더 생긴다. 사용자의 구독 등급을 모르는 상태에서도 핵심 동작은 실패하지 않아야 하고, 서버 한도에 닿았을 때 기존 앱 기능으로 자연스럽게 내려와야 한다. AI 기능을 별도 버튼으로 붙이는 단계에서 벗어나려면 추론 자원이 부족해도 완료 가능한 최소 경로를 제품 설계에 넣어야 한다.

Gemini Robotics ER 2는 로봇의 동작 모델을 실시간으로 지휘한다

Gemini Robotics ER 2는 연속 영상으로 작업 진행을 읽고, 하위 VLA 모델과 로봇 API에 실행을 위임하는 상위 추론 계층이다. 이미지: Google DeepMind

Google DeepMind가 공개한 Gemini Robotics ER 2는 직접 모든 모터 출력을 생성하기보다 로봇의 상위 두뇌 역할을 맡는다. 비디오·오디오·텍스트를 스트리밍으로 받고, 사람과 대화하며, 여러 단계의 작업을 계획한 뒤 VLA(Vision-Language-Action) 모델이나 내비게이션·조작 API를 도구처럼 호출한다. Gemini API와 Google AI Studio에서 제공되고, 기업용 에이전트 플랫폼 연결은 비공개 미리보기다.

이 구조에서 중요한 변화는 추론과 동작을 번갈아 멈춰 가며 처리하지 않는다는 점이다. ER 2는 로봇이 현재 동작을 수행하는 동안 다음 단계를 판단하고, 연속 영상을 보며 작업 진행률과 완료 순간을 추적한다. 전구 조이기나 커피 따르기처럼 끝났는지 판별하기 어려운 작업에서 실패를 감지하면 전체 절차를 처음부터 반복하지 않고 해당 단계의 수정 경로를 고를 수 있다.

Google은 진행률 구간 분류에서 57.4% 정확도, 중요한 순간을 찾는 평가에서 91.3% 정확도와 평균 0.96초 오차를 보고했다. 모두 공급사의 자체 평가이므로 숫자를 일반적인 로봇 성공률로 읽으면 안 된다. 그래도 로봇 벤치마크가 최종 물체 위치 하나에서 진행 중인 상태와 전환 시점으로 넓어졌다는 점은 실무적으로 의미가 있다. 물리 작업은 정답 행동을 골라도 멈추는 타이밍이 틀리면 실패하기 때문이다.

Boston Dynamics Spot 데모에서는 이동과 매니퓰레이터 API를 조합해 자연어 요청으로 물건을 가져왔고, 여러 로봇이 같은 공간에서 역할을 나누는 협업도 소개됐다. 여기서는 모델 성능만큼 도구 계약이 중요하다. 로봇별 좌표계, 실행 시간, 실패 코드, 취소 가능 여부가 다르면 상위 모델의 계획이 맞아도 실제 동작은 어긋난다. 나는 로봇 에이전트를 볼 때 데모 성공 횟수와 함께 도구 호출을 중단하고 사람이 개입할 수 있는 경계를 먼저 확인하게 된다.

검색 같은 외부 도구까지 연결할 수 있다는 점도 양면적이다. 최신 정보를 찾아 계획을 보완할 수 있지만, 웹에서 읽은 지시와 안전 규칙을 같은 신뢰 수준으로 다루면 물리 동작까지 오염될 수 있다. 로봇이 읽는 데이터, 세운 계획, 호출한 저수준 API, 실제 센서 결과를 분리해 기록하고, 위험 동작은 별도 승인 계층을 거치는 편이 맞다.

Nscale의 Anyscale 인수는 GPU와 Ray 운영 계층을 한 묶음으로 만든다

AI 네오클라우드 Nscale은 데이터센터 자원 위에 Ray 기반 워크로드 관리와 관측 계층을 함께 제공하려 한다. 이미지: TechCrunch·Getty Images

TechCrunch는 영국 AI 네오클라우드 Nscale이 Anyscale을 인수한다고 보도했다. Anyscale은 오픈소스 분산 컴퓨팅 프레임워크 Ray를 만든 팀이 세운 회사로, 대규모 학습·서빙·데이터 처리·강화학습 워크로드를 여러 서버에 배치하는 개발 도구와 관측 기능을 제공한다. 보도된 인수 금액 16억5천만 달러는 익명 소스를 인용한 Bloomberg 수치이므로 확정 공시 금액과는 구분할 필요가 있다.

Nscale은 전력, 데이터센터, 컴퓨팅 자원에 이어 소프트웨어 오케스트레이션까지 수직으로 묶는 쪽으로 움직이고 있다. GPU를 임대하는 사업만으로는 고객 워크로드가 어느 단계에서 느려지는지, 빈 자원이 왜 생기는지, 추론 서버가 실제로 얼마나 활용되는지까지 통제하기 어렵다. Ray 기반 실행 계층을 품으면 하드웨어 배치와 애플리케이션 스케줄링을 같은 회사 안에서 최적화할 여지가 생긴다.

고객 입장에서도 한 공급자가 클러스터와 런타임을 같이 책임지면 장애 원인을 나누어 찾는 시간이 줄 수 있다. 반대로 편의성이 높을수록 애플리케이션 코드, 스케줄러 설정, 관측 데이터가 특정 인프라에 묶일 수 있다. Anyscale은 기존 브랜드와 고객 서비스를 유지한다고 밝혔지만, 장기적으로 오픈소스 Ray와 상용 플랫폼, Nscale 전용 최적화 사이의 경계가 어떻게 유지되는지가 더 중요하다.

나는 이런 수직 통합을 볼 때 평균 GPU 사용률 하나보다 이식 가능한 실행 명세와 관측 데이터를 확인한다. 같은 Ray job을 다른 클라우드에서 재현할 수 있는지, autoscaling 결정과 비용을 외부로 내보낼 수 있는지, 하드웨어 장애 때 스케줄러가 어떤 선택을 했는지 남아야 한다. AI 인프라 경쟁이 칩 수량에서 워크로드 운영 경험으로 옮겨 갈수록, 개방성은 소스 공개 여부만이 아니라 실제 이동 비용으로 측정해야 한다.

SpecFirst는 코딩 전에 실행 가능한 명세부터 뽑는다

SpecFirst는 문서와 실행 전용 바이너리를 탐색해 구조화된 동작 명세를 만든 뒤, 별도 에이전트가 그 명세를 기준으로 구현한다. 이미지: arXiv:2607.27167 Figure 1

SpecFirst 논문은 기존 코드가 없는 프로그램 합성에서 요구사항 추출을 독립된 첫 단계로 둔다. ProgramBench는 자연어 문서와 실행만 가능한 기준 바이너리를 주고 같은 동작을 구현하게 하는데, 논문은 강한 최신 모델도 전체 사례의 1% 미만만 완전히 해결했다고 설명한다. 문서를 읽고 바이너리를 시험하고 코드를 쓰는 일을 한 루프에 섞으면 에이전트가 충분히 탐색하기 전에 구현을 시작하고, 긴 실행 동안 원래 동작에 대한 기억도 흐려진다는 진단이다.

SpecFirst의 첫 번째 에이전트는 바이너리에 다양한 입력을 넣어 정상 출력뿐 아니라 오류 경로와 옵션 조합을 확인하고, 관찰 결과를 문서와 합쳐 구조화된 명세로 만든다. 두 번째 에이전트는 이 명세를 고정된 참조점으로 삼아 코드를 작성한다. 구현과 탐색을 병렬로 조금씩 진행하는 대신 무엇을 만들어야 하는지 합의한 뒤 어떻게 만들지를 시작하는 구성이다.

저자들은 ProgramBench 200개 전체 사례와 두 계열의 모델 네 개를 평가해 단일 루프 기준선보다 테스트 통과율이 6.9%에서 21.3%, 바이너리 탐색 커버리지가 9.4%에서 18.5% 개선됐다고 보고했다. 이 역시 논문이 정한 실행 전용 바이너리 재구현 과제 안의 결과다. 일반 저장소 기능 개발에 같은 폭의 향상이 난다고 단정할 수는 없다. 다만 모델 규모가 달라도 명세 단계를 분리한 효과가 일관됐다는 점은 눈에 들어온다.

내가 코딩 에이전트와 일할 때도 초반 실패는 코드 문법보다 동작 해석에서 자주 시작됐다. 빈 입력이 오류인지 빈 결과인지, 정렬 순서가 안정적인지, 잘못된 옵션 조합에서 어떤 메시지를 내는지 확정하지 않은 채 구현하면 테스트가 늘어날수록 임시 규칙이 쌓인다. 먼저 관찰 표를 만들고 각 주장을 재현 입력과 묶으면 컨텍스트가 압축돼도 기준이 덜 흔들린다.

다만 명세를 먼저 쓴다는 말이 긴 문서를 한 번 더 만들자는 뜻은 아니다. 어떤 입력을 시험했고 무엇을 관찰했는지, 아직 모르는 경계가 무엇인지가 코드와 연결돼야 한다. SpecFirst에서 가져올 실무 포인트는 탐색 결과를 구현 프롬프트 속 기억이 아니라 검증 가능한 산출물로 승격하는 것이다. 에이전트가 구현을 시작하기 전에 명세의 빈칸을 드러내게 하면, 빠르게 틀린 코드를 만드는 비용을 줄일 수 있다.

출처

• The Verge — Tim Cook hints at iCloud Plus tier for AI power users
• Google DeepMind — Gemini Robotics ER 2
• TechCrunch — Nscale buys Anyscale
• arXiv:2607.27167 — SpecFirst