2026년 6월 20일 | AI 최신 트렌드
6월 20일 아침 기준으로 눈에 들어온 축은 통신망 안의 AI, 긴 컨텍스트 비용, 기업의 사용량 통제, 에이전트 도구 배포, 툴 호출 상태 관리였다. 모델 성능 경쟁도 계속되고 있지만, 이번 묶음에서는 AI를 실제 조직과 제품에 넣을 때 생기는 운영 문제가 더 크게 보였다.
나는 AI 뉴스를 볼 때 숫자가 크게 붙은 발표보다, 그 숫자를 매일 굴릴 때 누가 책임을 지는지를 더 자주 보게 된다. 통신사는 통화와 앱 안에 AI를 심고, 모델 스타트업은 attention 비용을 낮추겠다고 말하고, 기업은 직원의 AI 사용량을 다시 조이기 시작한다. 한쪽에서는 에이전트가 금융 API를 만지고, 다른 한쪽에서는 논문이 “상태를 prompt에 묻어두지 말라”고 말한다.
1. Reliance Jio: AI가 별도 앱이 아니라 통신망 기능이 되는 장면
TechCrunch 보도에 따르면 Reliance는 Jio Call Agent, MyJio 앱의 AI 기능, Jio TeleFrame 같은 홈 디스플레이를 묶어 발표했다. 핵심은 “AI 앱 하나 더”가 아니라, 5억 명이 넘는 Jio 사용자 기반 위에 AI 기능을 통신망과 서비스 기본값처럼 얹으려는 방향이다. 통화 중 대화 내용을 요약하고, “Hey Jio”로 작업을 시키고, 앱에서 eSIM이나 로밍 설정 같은 일을 자연어로 처리하게 만드는 식이다.
이 소식은 모델 자체보다 분배 경로가 더 중요해지는 장면으로 읽혔다. 일반 사용자가 AI를 쓰기 위해 새 앱을 깔고 계정을 만들 필요가 없다면, 도입 장벽은 꽤 낮아진다. 반대로 통신사 입장에서는 통화, 결제, 예약, 홈 디바이스, 고객 지원 같은 접점을 한 번에 묶을 수 있다. AI가 “검색창 옆의 기능”이 아니라 기존 생활 인프라 안쪽 기능이 되는 셈이다.
다만 이 흐름이 편하기만 한 건 아니다. 통화 요약과 홈 디스플레이는 필연적으로 사적인 데이터를 많이 만진다. 어떤 데이터가 모델 개선에 쓰이는지, 파트너인 Meta나 다른 인프라 제공자와 어디까지 연결되는지, 사용자가 꺼둘 수 있는 범위가 어디까지인지가 더 중요해진다. AI 기능이 통신망에 붙는 순간, UX 질문과 프라이버시 질문이 거의 같은 문장 안에 들어온다.
2. Subquadratic의 SubQ: 긴 컨텍스트 병목을 정말 깼는지 보는 단계
MIT Technology Review는 Subquadratic이라는 스타트업이 LLM의 quadratic bottleneck을 줄였다고 주장하는 SubQ 모델을 소개했다. 요지는 Transformer의 dense attention처럼 모든 토큰 쌍을 다 보지 않고, 입력마다 중요한 관계를 동적으로 고르는 sparse attention 계열 접근이다. 기사에 나온 수치만 보면 1백만 토큰을 넘어 1천2백만 토큰 문맥, 긴 검색 테스트 비용 절감 같은 표현이 꽤 강하게 붙어 있다.
나는 이런 발표를 볼 때 기대보다 먼저 의심부터 든다. 긴 컨텍스트를 싸게 만든다는 말은 언제나 매력적이지만, needle-in-a-haystack류 테스트와 실제 업무 문서 추론은 꽤 다르다. 코드베이스 전체, 법률 문서 묶음, 의료 기록처럼 서로 충돌하는 정보가 많은 환경에서는 단순히 멀리 있는 토큰을 찾는 것보다 어떤 근거를 버리지 않을지가 더 어렵다.
그래도 방향 자체는 중요하다. RAG를 잘 짜는 이유 중 하나도 결국 긴 입력을 전부 모델에 넣는 비용이 너무 크기 때문이다. 만약 SubQ식 접근이 독립 검증을 거쳐 실제 서비스에서도 유지된다면, “검색해서 조금 넣기”와 “통째로 넣고 내부에서 고르기” 사이의 경계가 다시 움직일 수 있다. 다만 지금 단계에서는 breakthrough라는 단어보다, 외부 벤치마크와 공개 사용 사례가 얼마나 따라오는지를 보는 쪽이 맞아 보인다.
3. 기업의 AI 사용량 통제: 이제는 비용 캡도 제품 기능이다
Financial Times는 Amazon, Walmart, Uber 같은 초기 도입 기업들이 AI 사용량을 다시 조이거나 낭비성 활동을 줄이기 시작했다는 흐름을 전했다. Hacker News에도 올라온 이 기사에서 흥미로운 대목은 “AI를 안 쓰겠다”가 아니라, 너무 쉽게 쓰이기 시작한 뒤 비용 장부를 다시 보게 됐다는 점이다.
이건 현업에서 꽤 익숙한 패턴이다. 처음에는 팀마다 AI 도구를 열어주고, 생산성이 좋아지는지 빠르게 실험한다. 그런데 몇 달 지나면 질문이 바뀐다. 누가 어떤 작업에 얼마나 썼는지, 같은 결과를 더 작은 모델로 낼 수 있는지, 자동화 스크립트가 불필요하게 반복 호출을 날리고 있지는 않은지, 실패한 에이전트 루프가 비용을 태우고 있지는 않은지 봐야 한다.
그래서 앞으로 기업용 AI 제품에서 spend control은 부가 기능이 아니라 핵심 기능에 가까워질 것 같다. 모델 라우팅, 캐시, rate limit, 승인 흐름, 부서별 예산, 로그 기반 감사가 한 묶음으로 들어와야 한다. 개인 개발자 입장에서는 “좋은 모델을 붙였다”로 끝나지만, 조직 입장에서는 “이 호출이 왜 필요했고 누가 책임지는가”까지 설명돼야 계속 쓸 수 있다.
4. 토스증권 Agent Skill: 에이전트 도구 배포가 점점 구체 API로 내려온다
GeekNews에 올라온 “토스증권 Open API용 Agent Skill”도 작지만 재미있게 봤다. 저장소 설명을 보면 Codex나 Claude Code 같은 코딩 에이전트가 토스증권 Open API 문서, OpenAPI 스키마, 작업 흐름, CLI 사용법을 참고할 수 있게 만든 Skill이다. 종목 정보, 현재가, 호가, 캔들, 보유 주식, 주문 목록 같은 조회 기능과 주문 요청 생성 흐름이 들어 있다.
여기서 중요한 건 금융 API를 에이전트에 붙였다는 사실 자체보다, 기본값을 dry-run으로 둔 설계다. 주문 생성, 정정, 취소는 `--execute --yes` 같은 명시적 옵션을 요구하고, 주문 생성에는 clientOrderId도 요구하게 해뒀다고 한다. 에이전트 도구가 진짜 외부 상태를 바꾸는 순간, 문서화보다 더 중요한 건 실수 방지 기본값이다.
Agent Skill이라는 배포 형식도 눈에 남는다. 예전에는 “API 문서 읽고 알아서 써”에 가까웠다면, 이제는 에이전트가 읽을 수 있는 작업 설명, 스키마, CLI, 안전장치가 하나의 패키지처럼 묶인다. 이 흐름이 더 커지면 좋은 SDK의 기준도 조금 바뀔 수 있다. 사람 개발자에게 친절한 문서뿐 아니라, 에이전트가 헷갈리지 않고 호출할 수 있는 계약이 같이 필요해진다.
5. LedgerAgent: 툴 호출 에이전트에 상태 장부를 따로 두자는 논문
HuggingFace Daily Papers에 올라온 LedgerAgent 논문은 위의 Agent Skill 소식과 꽤 잘 이어진다. 논문의 문제의식은 단순하다. 툴 호출 에이전트가 대화 기록, 툴 반환값, 정책 문서를 모두 prompt history 안에 섞어 두면, 나중에 중요한 식별자나 제약을 잘못 복원할 수 있다. 특히 환불, 예약 취소, 계정 변경처럼 외부 상태를 바꾸는 호출에서는 작은 상태 오해가 곧 정책 위반이 된다.
LedgerAgent는 그래서 성공한 read tool 반환값을 schema-anchored ledger라는 구조화된 상태 장부에 넣고, write 성격의 tool call이 나가기 전에는 그 ledger를 기준으로 policy gate를 통과시키는 방식을 제안한다. 내가 마음에 들었던 지점은 “LLM을 한 번 더 부른다”가 아니라, 가능하면 결정적인 규칙과 상태 표현을 agent loop 바깥에 세워 두려는 방향이다.
실무에서 에이전트가 무서운 순간은 대답을 조금 틀리는 때보다, 틀린 확신으로 외부 시스템을 바꾸는 때다. 장바구니를 수정하고, 환불을 만들고, 주문을 넣고, 고객 정보를 바꾸는 작업은 “아마 맞겠지”로 넘기기 어렵다. 그래서 앞으로의 에이전트 안정성은 더 큰 모델 하나로만 풀리지 않고, ledger, policy gate, dry-run, 승인 단계 같은 비모델 장치와 함께 가야 한다고 본다.
묶어서 보면
이번 5개를 한 줄로 묶으면 “AI가 들어갈 자리는 늘었고, 그만큼 제어 장치도 같이 필요해졌다”에 가깝다. Reliance는 AI를 통신망과 집 안으로 밀어 넣고, Subquadratic은 긴 문맥 비용을 줄이겠다고 말하고, 기업들은 이미 비용 캡을 고민한다. Toss Agent Skill과 LedgerAgent는 에이전트가 실제 API를 만질 때 필요한 안전장치를 다른 층에서 보여 준다.
AI 트렌드를 계속 따라가다 보면 새 모델 이름만 남기 쉽다. 그런데 이번 묶음에서 더 오래 남는 건 모델 이름이 아니라 운영 표면이었다. 어디에 심을 것인가, 얼마나 싸게 굴릴 것인가, 누가 한도를 정할 것인가, 어떤 호출은 막을 것인가. 결국 AI가 일상 도구가 되는 속도는 성능표보다 이런 운영 질문에 더 많이 묶일 것 같다.
출처
- TechCrunch — Billionaire Ambani wants AI in every call, app, and home
- MIT Technology Review — A startup claims it broke through a bottleneck that’s holding back LLMs
- Financial Times — Companies rein in AI usage as costs strain budgets
- GeekNews — 토스증권 Open API용 Agent Skill
- GitHub — BEOKS/tossinvest-skill
- arXiv — LedgerAgent: Structured State for Policy-Adherent Tool-Calling Agents