2026년 7월 11일 | AI 최신 트렌드
AI 경쟁의 무게중심이 모델 점수 하나에서 하드웨어 설계, 메모리 비용, 배포 통제권, 장기 에이전트의 상태 유지로 빠르게 퍼지고 있다. 나는 이번 흐름에서 거대한 모델을 더 크게 만드는 이야기보다 이미 가진 자원을 어떻게 다시 쓰고, 누가 실행 환경을 통제하며, 에이전트가 언제 기억을 꺼내야 하는가가 더 눈에 들어왔다.
Apple과 OpenAI, AI 하드웨어 경쟁이 법정으로 갔다
TechCrunch 보도에 따르면 Apple은 OpenAI와 일부 전직 Apple 직원을 상대로 영업비밀 유용과 계약 위반을 주장하는 소송을 제기했다. 소장에는 미공개 제품 정보, 기술 문서, 부품과 공급업체 선정 과정 등이 언급됐다. 이는 어디까지나 Apple이 제기한 주장이고 법원의 판단은 아직 나오지 않았다는 선을 분명히 그어야 한다.
그래도 이 사건이 던지는 신호는 크다. OpenAI가 모델 API 회사에 머무르지 않고 소비자용 하드웨어를 준비하면서, 경쟁의 병목이 칩이나 모델만이 아니라 제품 설계 경험과 공급망 지식으로 옮겨갔기 때문이다. AI 기기가 앱 중심 스마트폰과 다른 인터페이스를 내세우더라도 실제 양산에서는 소재, 열, 배터리, 센서, 협력사 관리 같은 오래된 하드웨어 역량을 건너뛸 수 없다.
개발 조직 입장에서도 가볍게 볼 문제는 아니다. 에이전트가 저장소와 문서를 폭넓게 읽는 환경에서는 퇴사자 계정 회수, 문서 등급, 로컬 다운로드 기록, 인터뷰 과제의 자료 반입 경계가 예전보다 더 중요해진다. 모델 보안만 강화하고 사람과 파일의 이동 경로를 그대로 두면, 가장 민감한 지식은 여전히 평범한 업무 흐름을 타고 빠져나갈 수 있다.
Meta의 CXL 브리지, 구형 DDR4를 추론 자원으로 되돌렸다
GeekNews가 정리한 Meta의 Vistara 사례는 화려한 새 GPU 대신 버려질 뻔한 메모리를 다시 쓴 이야기다. Meta는 자체 CXL 브리지 ASIC을 이용해 구형 DDR4 DIMM을 DDR5 서버에 연결하고, 운영체제에는 CPU가 없는 별도 NUMA 노드처럼 노출했다. 빠른 로컬 메모리와 상대적으로 느린 확장 메모리를 계층으로 나눈 셈이다.
정리된 수치에 따르면 이 구성은 일부 분리형 추론 워크로드에서 필요한 서버 수를 최대 25% 줄였고, 작업 재시작과 리소스 단편화 관련 오버헤드도 33% 낮췄다. 모든 워크로드에 같은 효과가 난다는 뜻은 아니다. 지연에 민감하고 메모리 접근 지역성이 나쁜 작업이라면 CXL 계층이 오히려 병목이 될 수 있다. 그래서 이 사례의 핵심은 단순 증설보다 어떤 데이터가 느린 메모리로 내려가도 되는지를 워크로드 단위로 골랐다는 데 있다.
나는 이 접근이 AI 인프라의 다음 최적화 축을 잘 보여 준다고 본다. 모델 양자화가 파라미터 한 개의 비용을 줄이는 일이라면, CXL 메모리 계층화는 서버 플릿 전체에서 놀고 있는 용량을 다시 배치하는 일이다. 새 장비 구매만으로 해결하던 시기가 지나고, 이제는 메모리 수명과 서버 수명의 차이까지 운영 모델에 넣는 쪽으로 가고 있다.
Hugging Face가 말한 ‘AI 임대’의 끝은 비용과 통제권 문제다
Hugging Face CEO Clem Delangue의 인터뷰에서는 기업이 처음에는 프런티어 모델 API로 빠르게 출발하지만, 사용량이 커지면 비용 때문에 오픈 모델로 옮기는 패턴이 반복된다는 설명이 나왔다. 오픈소스가 무조건 싸다는 단순한 주장은 아니다. GPU 확보, 서빙 최적화, 관측성, 보안 업데이트를 직접 떠안으면 고정비가 커진다.
반대로 트래픽이 충분히 크고 입력 분포가 안정적이라면 직접 운영의 장점이 살아난다. 모델 버전이 갑자기 바뀌지 않고, 데이터가 외부 API로 나가지 않으며, 특정 업무에 맞춘 양자화와 캐시 전략을 오래 유지할 수 있다. 결국 선택 기준은 모델의 공개 여부보다 변동비를 계속 낼지, 운영 역량을 고정비로 가져갈지에 가깝다.
실무에서는 한쪽으로 완전히 몰기보다 라우팅을 나누는 편이 현실적이다. 어려운 요청과 변동이 큰 탐색 작업은 프런티어 API에 보내고, 반복량이 많은 분류·추출·요약은 자체 모델에 두는 식이다. 모델 선택이 취향 논쟁에서 손익분기점 계산으로 바뀌고 있다는 점이 이번 인터뷰에서 가장 현실적으로 들렸다.
colibrì, 744B MoE를 25GB RAM에서 돌리는 대신 디스크를 택했다
colibrì 프로젝트는 GLM-5.2 744B Mixture-of-Experts 모델을 약 25GB RAM의 소비자용 머신에서 실행하도록 만든 순수 C 엔진이다. 약 17B 규모의 dense 부분은 int4로 양자화해 메모리에 상주시키고, 토큰마다 선택되는 routed expert는 약 370GB 디스크에 둔 뒤 필요할 때 읽는다. GPU와 대용량 RAM을 디스크 대역폭으로 치환한 설계다.
이 프로젝트는 ‘실행 가능’과 ‘실용적으로 빠름’의 차이도 솔직하게 보여 준다. 공개된 WSL2 측정에서는 cold decode가 대략 0.05~0.1 token/s 수준이었다. 한 문장을 기다리는 데도 꽤 오래 걸리는 속도다. 대신 압축 KV cache, expert LRU cache, hot expert 고정, MTP speculative decoding 같은 장치를 넣어 병목이 어디에서 생기는지 확인할 수 있게 했다.
나는 이걸 상용 챗봇 대체재보다 MoE 추론 구조를 손으로 만져 보는 실험 장치로 보는 편이 맞다고 생각한다. 어떤 expert가 자주 불리는지, RAM을 늘렸을 때 디스크 읽기가 얼마나 줄어드는지, speculative decoding이 cold cache에서 오히려 손해가 되는 조건은 무엇인지가 드러난다. 큰 모델을 로컬에서 돌린다는 결과보다, 메모리와 저장장치 사이의 교환비를 측정할 수 있다는 점이 더 재미있다.
장기 에이전트의 기억은 저장보다 ‘언제 끼어들지’가 어려웠다
Remember When It Matters는 장기 작업에서 요구사항, 실패했던 시도, 환경 사실, 열린 하위 목표가 기록에는 남아 있어도 다음 행동을 더는 통제하지 못하는 현상을 behavioral state decay라고 부른다. 나도 긴 코딩 세션에서 에이전트가 앞서 발견한 오류 원인을 잊고 비슷한 명령을 다시 시도하는 장면을 자주 봤다. 컨텍스트에 문장이 존재하는 것과 행동에 실제로 반영되는 것은 다른 문제다.
연구진은 기존 action agent를 바꾸지 않고 옆에 별도의 memory agent를 붙였다. 이 에이전트는 최근 궤적에서 구조화된 기억을 갱신하고, 지금 알림을 주는 것이 도움이 되는지 판단해 필요한 경우에만 memory-grounded reminder를 주입한다. 논문이 보고한 결과는 Terminal-Bench 2.0에서 pass@1이 8.3%포인트, τ²-Bench에서 6.8%포인트 개선됐다는 것이다.
더 흥미로운 부분은 기억을 항상 보여 주는 방식보다 선택적 개입이 나았다는 점이다. 긴 메모를 매 단계 붙이면 토큰을 쓰고 현재 문제에 대한 집중도도 흐릴 수 있다. 그래서 에이전트 메모리의 설계 질문은 ‘무엇을 저장할까’에서 ‘어떤 실패 신호가 보일 때 과거 상태를 다시 활성화할까’로 이동한다. 이 관점은 코딩 에이전트의 체크포인트, 반복 오류 감지, 완료 조건 추적에도 바로 연결된다.
다섯 소식을 한 줄로 연결하면
Apple과 OpenAI의 분쟁은 지식의 이동 경계를, Meta와 colibrì는 메모리 계층의 물리적 비용을, Hugging Face는 모델 운영의 경제성을, Proactive Memory Agent는 장기 실행의 인지적 상태를 다룬다. 서로 다른 뉴스처럼 보이지만 공통 질문은 같다. AI 시스템이 커질수록 무엇을 소유하고, 무엇을 밖에서 빌리며, 어떤 상태를 어느 시점에 다시 불러올 것인가.
이 질문을 실제 아키텍처 리뷰에 옮기면 확인할 항목도 구체적이 된다. 하드웨어와 학습 데이터는 반출 가능한 경계를 정하고, 추론 서버는 빠른 메모리와 느린 메모리 사이의 이동량을 계측해야 한다. API와 오픈 모델은 토큰 단가만 비교할 게 아니라 트래픽 변동, 장애 대응, 버전 고정, 보안 심사 비용까지 합쳐야 한다. 장기 에이전트에는 모든 과거 기록을 밀어 넣기보다 반복 명령, 완료 조건 이탈, 이미 진단한 오류의 재등장처럼 개입해야 할 신호를 따로 정의하는 편이 낫다.
여기서 중요한 건 최적화 단위가 서로 연결된다는 점이다. 저렴한 로컬 모델을 택해도 메모리 계층이 흔들리면 지연 비용이 커지고, 충분한 하드웨어를 확보해도 에이전트가 같은 실패를 반복하면 처리량이 사라진다. 반대로 외부 API가 비싸 보여도 운영 인력이 부족한 팀에는 전체 비용이 더 낮을 수 있다. ‘가장 좋은 모델’이라는 한 줄 결론보다, 팀이 실제로 통제할 수 있는 자원과 실패 모드를 먼저 적는 것이 맞다.
성능 그래프만 보면 이 질문들이 주변부처럼 보이지만, 실제 서비스를 오래 굴리면 주변부가 먼저 비용과 실패를 만든다. 다음 모델을 고르기 전에 데이터 반출 경계, 메모리 계층, API와 자체 서빙의 손익분기점, 장기 작업의 상태 회수 규칙을 같은 설계표에 올려야 한다. 특히 평균 처리량만 보지 말고 실패 후 재시작 비용과 사람이 개입하는 횟수까지 함께 재는 편이 현실적이다. 이번 주말에는 모델 순위표보다 운영 구조를 먼저 보게 된다.