2026년 7월 23일 | AI 최신 트렌드
AI 기능이 어디에 배치되고 어떤 검증을 거쳐 실행되는지가 모델 이름만큼 중요한 제품 차이가 되고 있다. 기업용 에이전트는 한 업무와 승인된 행동을 묶기 시작했고, 모바일 에이전트는 앱을 넘나드는 작업을 백그라운드로 옮겼다. 그 아래에서는 GPU 용량을 몇 년 앞서 확보하는 계약이 이어지고, 콘텐츠 플랫폼과 검색 연구는 각각 글의 생성 과정과 문서의 표현 방식을 다시 설계하고 있다.
7월 22일 공개된 소식 다섯 건을 같이 놓고 보니 공통점이 선명했다. 성능 좋은 모델 하나를 붙이는 단계에서 벗어나, 운영 단위·컴퓨팅·출처 표시·인덱스 구조까지 제품의 일부로 끌어들이는 흐름이다. 발표 주체의 수치와 설명은 독립 검증 결과가 아니라 해당 발표와 실험 범위 안에서 읽었다.
1. OpenAI Presence: 범용 챗봇보다 한 업무의 운영 단위
OpenAI가 공개한 Presence는 기업이 음성·채팅 에이전트를 실제 업무에 배치하도록 돕는 제품이다. 첫 배치는 고객 지원, 청구 처리, 보험 청구, 사내 IT 요청처럼 정의된 일 하나에서 시작한다. 에이전트에는 그 일에 필요한 지식과 시스템 접근만 주고, 가능한 행동과 승인 조건, 사람에게 넘길 시점을 기업이 정한다.
눈에 들어온 부분은 모델 호출보다 앞뒤의 운영 장치였다. 출시 전에는 시뮬레이션과 grader로 결과·정책 준수·도구 사용·이관 여부를 평가하고, 출시 뒤에는 프로덕션 세션과 이관 기록에서 빈틈을 찾는다. Codex가 개선안을 제안하더라도 기존 버전과 비교하고 사람이 배포를 승인하는 구조다. 에이전트가 스스로 좋아진다는 표현보다, 변경 제안과 배포 권한을 분리했다는 점이 실무적으로 더 중요해 보인다.
이 발표만으로 장기 운영의 신뢰성이 증명된 것은 아니다. 그래도 기업용 에이전트의 제품 단위가 대화창에서 정책·권한·평가·배포 루프로 넓어졌다는 방향은 분명하다. 내가 새 에이전트를 붙인다면 먼저 “무엇을 답할까”보다 “어떤 한 가지 일을 어디까지 끝낼 수 있나”를 적게 될 것 같다.
운영팀 관점에서는 평가 세트의 버전도 모델 버전만큼 중요해진다. 실제 이관 사례와 정책 위반 사례를 다시 재현할 수 있어야 개선안이 좋아졌는지 확인할 수 있다. 권한 변경과 정책 변경을 모델 프롬프트 수정에 섞지 않고 별도 이력으로 남기는 것도 필요하다. Presence의 가치는 결국 이런 변경을 얼마나 추적 가능하게 만드는지에서 판가름 날 것이다.
2. Gemini Intelligence: 앱을 넘나드는 작업과 최종 확인
Google의 Galaxy Unpacked 발표에서 Gemini Intelligence의 작업 자동화 베타는 40개가 넘는 앱으로 확대됐다. 차량 호출, 음식 주문, 쇼핑, 식당 예약, 여행 상품과 티켓 구매처럼 여러 화면을 거치는 일을 맡기고, 사용자는 진행 과정을 단계별로 볼 수 있다. 작업 중 다른 앱을 쓰거나 폰을 닫아도 실행을 이어가며, 마지막 행동은 사용자가 검토하고 확인하는 방식이다.
모델이 화면을 이해한다는 설명보다 흥미로운 것은 백그라운드 실행과 개입 지점이다. 사용자가 중간에 세부 조건을 바꾸고 다시 넘길 수 있어야 긴 작업을 통째로 맡기지 않아도 된다. Google도 가까이 감독하고 필요할 때 중단하라고 명시한다. 완전 자율 실행을 강조하기보다 작업의 진행 상태와 최종 확인을 인터페이스에 남긴 셈이다.
이 기능은 미국과 한국의 일부 앱·기기·시장, 18세 이상 사용자라는 조건이 붙는다. Galaxy Watch 9의 손목 호출과 하반기 출시 예정인 Samsung 스마트 안경까지 연결되면 에이전트의 입구도 화면 하나에 머물지 않는다. 이제 모바일 AI의 비교 포인트는 답변 품질만이 아니라, 기기 사이에서 작업 상태가 얼마나 자연스럽게 이어지고 사용자가 어느 순간에 통제권을 되찾는가에 가까워지고 있다.
실제 평가는 단순 성공률로 끝내기 어렵다. 예약 조건을 바꾼 뒤 정확히 이어받는지, 앱 하나가 응답하지 않을 때 안전하게 멈추는지, 결제 직전의 확인 화면이 충분한 정보를 보여 주는지를 따로 봐야 한다. 여러 앱을 연결할수록 화려한 데모보다 중단·재개·취소의 품질이 일상 사용을 결정한다.
3. AMD와 Anthropic: GPU 계약이 보여주는 몇 년 뒤의 경쟁
The Verge가 전한 AMD·Anthropic 계약에 따르면 AMD는 Anthropic에 최대 50억 달러를 투자하고, Anthropic은 AMD Instinct MI450 GPU와 Helios 랙 시스템을 최대 2기가와트 규모로 배치할 계획이다. 첫 1기가와트는 2027년 상반기에 구축하는 일정이다. 양사는 여러 해에 걸친 엔지니어링 협업도 진행하고, AMD는 소프트웨어와 제품 개발에 Claude를 활용한다.
여기서 중요한 숫자는 투자액만이 아니다. 아직 배치되지 않은 차세대 시스템을 대상으로 전력 단위의 용량을 먼저 잡았다는 점이다. 모델 회사에는 공급망 다변화와 학습·추론 용량 확보가 필요하고, 칩 회사에는 대규모 고객과 실제 워크로드에서의 공동 최적화가 필요하다. 자본 투자, 칩 구매, 소프트웨어 사용이 한 계약에 묶인 구조라서 단순한 공급 계약보다 관계가 깊다.
다만 최대 투자액과 최대 배치 용량은 확정 사용량이나 성능 우위를 뜻하지 않는다. 구축 일정과 실제 가동률, 전력 조달, 소프트웨어 스택 성숙도는 따로 봐야 한다. 그럼에도 AI 인프라 경쟁이 이번 분기의 GPU 판매가 아니라 2027년 이후의 용량과 공동 개발을 선점하는 싸움이라는 점은 잘 드러난다.
2기가와트급 약속은 하드웨어만 주문한다고 끝나지 않는다. 데이터센터 부지와 전력, 네트워크, 냉각, 컴파일러와 커널 최적화가 같은 일정으로 움직여야 한다. 한 공급사에 맞춘 최적화가 커질수록 다른 가속기로 옮기는 비용도 커지므로, Anthropic이 실제로 어떤 워크로드를 어느 비율로 분산하는지가 다음 관찰 포인트다.
4. Substack의 AI 글 탐지: 판정보다 공개와 이의 제기
TechCrunch 보도에 따르면 Substack은 Pangram을 이용해 게시물·노트·답글·댓글에서 AI 작성 비율을 추정하는 기능을 앱에 넣었다. 100자 넘는 콘텐츠를 대상으로 하며, 작성자는 초안 발행 전에 스캔하고 AI를 어떻게 썼는지 선택적으로 설명할 수 있다. 플랫폼은 AI 사용 자체를 금지하거나 탐지 결과로 제재하지 않는다는 입장이다.
AI 탐지기는 짧은 글, 번역문, 비원어민 문체에서 오탐 논란이 반복돼 왔다. 그래서 탐지 점수보다 운영 방식이 더 눈에 들어왔다. 작성자는 결과가 틀렸다고 판단하면 자신의 글에 붙은 스캔을 신고하고 제거를 요청할 수 있다. 즉 분류 결과, 제작 과정 공개, 이의 제기를 한 세트로 둔다.
이 기능이 신뢰를 높일지는 탐지 정확도만으로 결정되지 않을 것이다. 독자가 숫자를 사실 판정처럼 받아들이지 않도록 표현하는지, 사람이 작성한 글의 오탐을 얼마나 빨리 고치는지, AI 보조와 대량 생성물을 구분할 문맥을 주는지가 중요하다. 플랫폼이 “AI인가 아닌가”를 단정하는 심판보다 제작 과정을 설명할 공간을 만드는 쪽으로 움직인 것은 현실적인 선택으로 보인다.
작성 과정 공개도 한 줄짜리 AI 사용 여부보다 구체적이어야 쓸모가 있다. 아이디어, 자료 조사, 초안, 문장 교정 중 어디에 도구를 썼는지 나누면 독자가 결과를 해석할 단서가 생긴다. 탐지 점수를 노출하는 것과 제작 과정을 설명하는 것은 다른 기능이며, 전자를 후자의 대체물로 쓰지 않는 운영이 필요하다.
5. AutoIndex: 검색 모델을 고정하고 문서 표현을 최적화
AutoIndex 논문은 검색기나 reranker를 바꾸는 대신, 원문을 인덱스에 넣기 전에 어떤 표현으로 변환할지를 최적화한다. 에이전트가 현재 검색 실패를 진단하고 문서 분할, 문맥 보강, 정규화, 가중치 조정, 구조 재배치가 담긴 실행 가능한 프로그램을 제안한다. 후보 프로그램을 실제로 실행해 새 인덱스를 만들고, 검증 성능이 오른 변경만 남긴다.
실험에서는 BM25 검색기를 고정해 표현 단계의 효과를 분리했다. 저자들은 CRUMB의 8개 이질적 검색 과제 모두에서 전체 문서를 그대로 넣은 기준선보다 recall이 올랐고, 평균 개선 폭은 Recall@100에서 8.4%, nDCG@10에서 8.3%였다고 보고한다. 가장 큰 개선은 각각 30.5%, 43.6%였다. 이는 프리프린트의 특정 데이터셋과 검증 절차에서 얻은 결과이므로 일반적인 RAG 성능 보장으로 넓혀 읽으면 안 된다.
그래도 실무 질문은 좋다. 검색 결과가 나쁠 때 임베딩 모델과 reranker부터 바꾸기 전에, 청크에 제목과 상위 문맥이 보이는지, 표와 목록이 검색 가능한 단위로 남았는지, 필드 정규화가 질의를 지우지 않았는지를 먼저 볼 수 있다. 인덱싱 전 표현도 학습하고 평가할 수 있는 프로그램이라는 관점은 RAG 파이프라인의 오래된 전처리 상자를 실험 대상으로 끌어낸다.
자동으로 생성된 표현 프로그램에는 별도 안전장치도 필요하다. 문서 변환 코드를 샌드박스에서 실행하고, 같은 입력에서 같은 인덱스가 나오는지 확인하며, 검증 질의에만 맞춘 과적합을 막기 위해 최종 테스트를 분리해야 한다. 프로그램과 인덱스 산출물, 평가 질의를 함께 버전 관리해야 개선 수치의 원인을 나중에 다시 설명할 수 있다.
다섯 소식은 서로 다른 층을 다루지만 결론은 비슷하다. 에이전트의 업무 경계, 모바일 작업의 확인 시점, 미래 GPU 용량, 글의 제작 과정, 검색용 문서 표현은 모두 모델 바깥의 설계다. AI 제품의 다음 차이는 더 큰 모델 하나보다 모델이 일할 장소와 그 주변의 검증 장치를 얼마나 구체적으로 만들었는지에서 벌어질 가능성이 크다.
확인한 원문
- OpenAI — Introducing OpenAI Presence
- Google — Galaxy Unpacked: Gemini and Samsung are better together
- The Verge — AMD commits up to $5 billion to Anthropic
- TechCrunch — Substack's new tool tells you who's been writing their newsletters with AI
- arXiv — AutoIndex: Learning Representation Programs for Retrieval