2026년 7월 13일 | AI 최신 트렌드
Apple의 폐기된 자율주행차 프로젝트가 온디바이스 AI 칩의 씨앗으로 남았다는 보도부터, 여러 대의 GPU를 한 모델처럼 묶는 오픈소스, 실제 조사 데이터를 바탕으로 만든 합성 소비자, 코딩 에이전트의 숨은 토큰 비용, 여러 객체를 실시간으로 분할하는 연구까지 한 흐름으로 이어졌다. 모델 크기만 키우는 경쟁보다 연산을 어디에 두고, 어떤 비용을 감추지 않으며, 실제 작업 단위로 어떻게 검증할지가 더 선명해진 하루였다.
폐기된 Apple Car가 Neural Engine과 M7 Ultra의 밑거름이 됐다는 보도
The Verge는 Apple의 자율주행차 프로그램이 제품으로 나오지는 못했지만, 초기 자동차용 프로세서 연구가 Neural Engine 개발에 영향을 줬다고 전했다. Neural Engine은 A11 Bionic과 iPhone X에서 Face ID, Animoji, 증강현실 같은 컴퓨터 비전 기능을 맡기 시작했고, 이후 M 시리즈를 통해 데스크톱의 온디바이스 AI 처리 기반으로 확장됐다. 자동차라는 큰 목표가 사라진 뒤에도 연산 구조와 인력, 설계 경험은 다른 제품군에 남은 셈이다.
보도에 따르면 Apple은 M6의 Pro·Max·Ultra 파생형보다 M7 개발을 앞당기고 있으며, M7 Ultra를 최대 1.5TB 메모리를 지원하는 서버 제품의 기반으로 검토하고 있다. 아직 공식 제품 사양으로 확정된 내용은 아니지만 방향은 흥미롭다. Apple의 AI 전략을 소프트웨어 발표만으로 평가하면 뒤처진 부분이 보이지만, 기기 안에서 처리하는 추론과 자체 서버용 칩을 한 설계 계보로 묶는다면 이야기가 달라진다. 개인정보를 클라우드로 덜 보내는 장점도 결국 충분한 로컬 연산 성능이 있어야 성립한다.
나는 이 사례에서 중단된 연구개발을 보는 기준을 다시 생각하게 됐다. 프로젝트의 최종 제품이 실패했는지와, 그 과정에서 만든 공통 기술 자산이 실패했는지는 별개의 문제다. AI 인프라는 모델 하나보다 훨씬 긴 주기로 움직이기 때문에, 폐기된 제품의 칩 설계가 몇 세대 뒤 다른 시장에서 살아나는 일이 앞으로 더 잦아질 수 있다.
Mesh LLM, 여러 머신의 GPU와 메모리를 OpenAI 호환 API 뒤에 묶다
Mesh LLM은 사무실과 홈랩에 흩어진 GPU와 메모리를 하나의 추론 자원처럼 쓰게 하는 오픈소스 프로젝트다. 클라이언트는 localhost:9337/v1의 OpenAI 호환 API만 호출하고, 내부에서는 현재 머신의 GPU로 실행할지, 모델을 이미 적재한 피어로 요청을 보낼지, 한 장비에 들어가지 않는 모델을 여러 노드에 나눌지를 결정한다. 작은 모델부터 235B 규모의 MoE 모델까지 카탈로그로 제공한다는 점도 눈에 들어왔다.
네트워크 계층에는 iroh를 사용한다. 각 노드의 공개키가 ID이자 네트워크 표면이 되고, NAT 통과와 홀 펀칭, 직접 연결이 어려울 때의 릴레이 경로를 QUIC 위에서 처리한다. 대형 모델 분할 모드인 Skippy는 모델 계층 범위를 여러 머신에 배치하고, 각 단계의 활성값을 다음 노드로 전달한다. 가중치를 매 토큰마다 느린 저장장치에서 읽는 대신 각 장비의 VRAM에 나눠 상주시킬 수 있다는 발상이다.
다만 분산 추론의 성패는 “여러 GPU를 묶었다”는 문장보다 노드 간 지연, 장애 복구, 모델 적재 시간, 실제 토큰 처리량에서 갈린다. 로컬 네트워크에서는 쓸 만해도 지리적으로 멀어진 인터넷 피어에서는 토큰마다 누적되는 왕복 지연이 크게 느껴질 수 있다. 그래도 API 계약을 바꾸지 않은 채 단일 노드에서 사설 메시로 확장할 수 있다는 구조는 좋다. 클라우드 API와 단일 워크스테이션 사이에 팀이 직접 통제할 수 있는 중간 선택지가 생기기 때문이다.
오픈서베이의 합성 소비자, LLM 페르소나보다 조사 데이터에 무게
오픈서베이는 데이터스페이스에 ‘합성 소비자와 대화’ 기능을 넣었다. 범용 LLM에 “30대 직장인처럼 답해 달라”고 요청하는 방식과 달리, 실제 패널이 과거 조사에 남긴 응답을 머신러닝 예측 모델로 학습해 취향 정보를 만들고 LLM이 그 정보를 바탕으로 평가 응답과 대화를 생성한다. 사용자는 자체 설문이나 트렌드 리포트 데이터로 세그먼트를 만든 뒤, 그 집단을 대표하는 페르소나와 인터뷰할 수 있다.
제품 설명에서 가장 중요한 부분은 답변 근거를 구분한다는 점이다. 내부 데이터가 있으면 그 데이터를 사용하고, 없으면 페르소나 프로필을 바탕으로 추론했다는 사실을 나눠 보여 준다. 신뢰도도 충실도, 정확도, 개인정보 보호라는 세 축으로 본다. 실제 분포를 얼마나 잘 따르는지, 합성 패널 결과가 실제 패널 결과와 얼마나 비슷한지, 특정 개인의 정보를 그대로 복제하지 않는지를 따로 점검하는 방식이다.
합성 소비자는 빠른 가설 탐색과 제품 콘셉트 스크리닝에는 유용하지만 실제 고객 조사를 대체하는 만능 도구는 아니다. 신체 감각이나 직접 사용 경험이 필요한 질문, 갑자기 확산한 유행처럼 학습 데이터에 아직 잡히지 않은 현상은 실제 인터뷰가 필요하다. 나는 이 기능을 ‘가상 고객의 정답’보다 비싼 본조사 전에 질문의 허점을 찾는 시뮬레이터로 보는 편이 안전하다고 생각한다. 생성된 응답의 설득력과 대표성은 같은 것이 아니다.
Claude Code와 OpenCode 비교가 드러낸 코딩 에이전트의 시작 비용
Systima가 같은 모델과 머신, 과제에서 Claude Code와 OpenCode의 API 요청을 프록시로 기록한 소규모 비교를 공개했다. 한 줄 응답을 요구한 첫 실험에서 Claude Code는 사용자 프롬프트를 처리하기 전에 시스템 프롬프트, 도구 스키마, 주입된 스캐폴딩으로 약 3만3000토큰을 보냈고 OpenCode는 약 7000토큰을 보냈다. 다만 다른 모델로 다시 측정하자 격차가 줄었기 때문에, 숫자를 모든 버전과 설정에 그대로 적용하면 안 된다.
실무 설정을 더했을 때 비용이 어떻게 부풀어 오르는지도 유용했다. 72KB짜리 저장소 지침 파일은 요청마다 평균 약 2만 토큰을 더했고, MCP 서버 다섯 개는 도구 스키마로 5000~7000토큰을 추가했다. 작은 작업을 두 하위 에이전트로 나눴을 때 총 사용량이 12만1000토큰에서 51만3000토큰으로 늘어난 사례도 있었다. 각 하위 에이전트가 시작 비용을 다시 부담하고, 부모가 그 결과 기록을 다시 읽기 때문이다.
반전도 있다. 여러 단계 작업 전체에서는 Claude Code가 도구 호출을 더 적은 요청에 묶어 총 토큰이 오히려 낮게 나온 구간이 있었다. 그래서 결론은 특정 도구가 무조건 비싸다는 것이 아니라, 고정 시작 비용과 턴당 반복 비용을 분리해서 측정해야 한다는 쪽에 가깝다. 긴 지침 파일을 무작정 붙이거나 사용하지 않는 MCP 도구를 모두 노출하는 습관, 작은 일까지 하위 에이전트로 퍼뜨리는 운영은 모델 성능과 무관하게 비용과 컨텍스트를 갉아먹는다.
SAM-MT, 대상이 늘어도 실시간 속도를 지키는 비디오 분할
비디오 객체 분할은 사용자가 지정한 대상을 프레임이 바뀌어도 계속 추적하고 픽셀 단위로 나누는 작업이다. SAM2 계열의 강한 단일 대상 모델을 여러 객체에 적용하는 가장 단순한 방법은 대상 수만큼 디코딩과 메모리 처리를 반복하는 것이다. 문제는 사람이 많거나 차량이 빽빽한 장면에서 대상 수가 늘수록 지연도 함께 커진다는 점이다. 객체를 하나로 합치면 속도는 줄일 수 있지만 개별 ID를 잃어 실제 추적에는 쓰기 어렵다.
SAM-MT는 전역 문맥을 공유 표현으로 처리하고, 개별 대상은 명시적인 경량 쿼리로 표현한다. 대상끼리 섞여 ID가 흐려지는 문제를 줄이기 위해 분리된 마스크 어텐션을 쓰고, 시간 흐름을 안정적으로 유지하기 위한 희소 메모리와 가림·겹침 처리 전략을 더했다. 연구진은 10개 대상을 처리할 때도 초당 36프레임을 넘겨 단일 대상 기준선에 가까운 실시간 속도를 유지했다고 보고했다.
이 구조의 핵심은 더 큰 백본이 아니라 반복되는 계산의 단위를 바꾼 데 있다. 영상 전체에서 한 번 계산해도 되는 문맥과 대상마다 달라야 하는 상태를 분리하면, 객체 수가 늘어도 비용 증가를 완만하게 만들 수 있다. 로봇과 자율주행처럼 대상 수를 미리 정하기 어려운 시스템에서는 평균 정확도 못지않게 대상이 늘었을 때 지연이 어떻게 변하는지가 중요한 배포 지표다.
다섯 소식을 한 줄로 묶으면, AI의 병목은 모델 밖으로 이동 중
다섯 소식은 서로 다른 분야처럼 보이지만 공통 질문이 있다. Apple은 연산 위치를 기기와 자체 서버로 가져오려 하고, Mesh LLM은 흩어진 하드웨어를 하나의 API 뒤에 묶는다. 합성 소비자는 생성 능력보다 데이터 근거와 대표성 검증을 앞세우고, 코딩 에이전트 비교는 모델 호출 전에 쌓이는 숨은 컨텍스트 비용을 보여 준다. SAM-MT는 대상 수가 늘 때 반복되는 계산 자체를 다시 설계한다.
모델 벤치마크 점수만 보면 놓치기 쉬운 부분들이다. 실제 시스템에서는 메모리 대역폭, 네트워크 지연, 프롬프트 스캐폴딩, 데이터 대표성, 객체 수에 따른 지연 곡선이 체감 품질과 비용을 결정한다. 같은 모델을 써도 이 주변 설계가 다르면 처리량과 단가, 실패 양상이 완전히 달라진다. 그래서 공개 수치 하나보다 측정 조건과 비용이 늘어나는 축을 함께 보는 편이 낫다. 나는 새 도구를 볼 때 “무엇을 더 잘하나”와 함께 “어떤 비용을 어디로 옮겼나”를 같이 적어 두려 한다. 그 질문이 있어야 멋진 데모와 오래 굴러가는 시스템을 구분할 수 있다.