AI 뉴스

Antigravity로 일하는 법이 바뀐다: 한 사람이 여러 에이전트의 '관리자'가 되는 워크플로

Antigravity의 Manager 뷰는 IDE 안에서 여러 에이전트를 동시에 여러 작업에 붙여 비동기로 굴리는 패널이다. 개발자는 코드를 직접 치기보다 태스크를 쪼개 분배하고, 각 에이전트가 올린 implementation plan을 승인하거나 되돌리고, 완료된 Artifacts를 리뷰하는 흐름으로 이동한다. 실무에서 효과를 본 패턴은 명확하다. 태스크를 작고 검증 가능하게 쪼갤수록 에이전트가 잘 끝내고, 막연한 'X 기능 만들어줘'는 plan 단계에서 어긋난다. 에이전트가 코드뿐 아니라 터미널·브라우저까지 만지므로, 위험 명령에는 사람 승인을 끼우는 권한 경계 설계가 필수가 된다. 한 명이 다섯 에이전트를 돌리면 병목은 타이핑이 아니라 '무엇을 시킬지 정의하고 결과를 판단하는' 인지 부하로 옮겨간다.

구글 Gemini 3.1 Pro 정식 공개, SWE-bench 80.6%에 4단계 thinking로 비용 조절

구글 딥마인드가 2026년 2월 19일 Gemini 3.1 Pro를 프리뷰로 공개했다. 직전 Gemini 3 Pro 대비 추론 성능을 2배 이상 끌어올렸고, 출시와 동시에 3 Pro 프리뷰를 종료(deprecate)시키며 플래그십을 교체했다. 벤치마크가 강력하다. SWE-bench Verified 80.6%(Claude Opus 4.6의 80.8%와 사실상 동급), GPQA Diamond 94.3%, 그리고 ARC-AGI-2에서 77.1%로 전작 31.1%의 두 배를 넘겼다. 컨텍스트는 100만 토큰 입력·6.5만 토큰 출력을 유지한다. 실무자가 주목할 부분은 thinking level이다. Low/Medium/High에 더해 Max까지 4단계를 노출해, 요청마다 추론 깊이와 비용·지연을 직접 트레이드오프할 수 있다(자동완성은 Low, 코드리뷰는 Medium, 복잡한 디버깅은 High 식). 가격은 입력 100만 토큰당 $2, 출력 $12로 전작과 동일하게 동결했다. 금융·스프레드시트 등 에이전트 도메인에서의 동작 개선도 명시됐다.

[비교] Codex SDK vs Claude Agent SDK: 실행 모델이 갈리는 지점

두 에이전트 SDK는 같은 일을 다른 축으로 푼다. Claude Agent SDK는 로컬 파일시스템과 임의 bash를 1급 도구로 보고 에이전트가 작업 디렉터리에서 직접 돌아가는 'host-native' 모델이다. Codex SDK는 실행을 OpenAI 컨테이너로 밀어넣고 Responses API의 상태 저장 대화에 묶는 'service-native' 모델에 가깝다. 결과적으로 Claude 쪽은 권한·sandbox 설정을 개발자가 책임지고 MCP로 도구를 확장하는 자유도가 높고, Codex 쪽은 환경이 표준화돼 재현성이 좋지만 커스텀 런타임 주입이 막혀 있다. 멀티 파일 리팩터의 정확도는 비등하나, long-horizon 작업에서 Claude는 컨텍스트 압축, Codex는 reasoning 토큰 비용이 각각의 약점으로 드러난다.

실무에선 '내 코드가 어디서 실행되는가'가 보안·컴플라이언스 결정이다. 온프레미스나 망분리 요구가 있는 한국 팀은 host-native 쪽이, 표준 재현 환경이 우선인 팀은 service-native 쪽이 맞다.

AI 학습을 위한 Python 라이브러리 Trio 소개

AI 시스템의 학습과 관련하여, Anthropic은 AI의 안전성과 해석 가능성을 높이기 위한 연구를 진행하고 있으며, Python 라이브러리 Trio를 통해 AI의 코딩 기술 형성에 영향을 미치는 방법을 제시하고 있다. AI를 활용한 학습 과정에서 초보자들은 50%의 코드를 작성할 수 있으며, AI가 없는 경우 67%의 코드 작성이 가능하다는 연구 결과가 있다.

AI 도구를 활용한 학습은 개발자들이 코딩 기술을 향상시키는 데 실질적인 도움을 줄 수 있다.

[분석] swarm은 왜 자꾸 무너지는가: 에러 누적과 조정 비용의 수학

다수 에이전트를 느슨하게 풀어놓는 swarm 패턴이 실무에서 깨지는 이유를 정량적으로 짚은 논의가 늘었다. 핵심은 두 가지다. 첫째, 단계마다 에이전트 성공률이 95%여도 직렬 10단계면 전체 성공률은 0.95^10≈60%로 주저앉는다. 에이전트를 늘릴수록 핸드오프 경계가 늘고 오류는 곱해진다. 둘째, 에이전트 수 N이 늘면 조정·합의에 드는 통신 비용은 대략 N^2로 증가하지만 실제 유효 작업량은 그만큼 늘지 않는다. 결국 검증 가능한 중간 산출물과 명시적 핸드오프 계약(스키마·완료 정의)이 없는 swarm은 토큰만 태우고 발산한다. 대안으로 떠오른 건 자유 방임 swarm이 아니라 라우터가 단계를 통제하는 supervised 그래프 구조다.

실무에선 에이전트 수를 늘리기 전에 '단계별 성공률 × 단계 수'를 먼저 계산해야 한다. 검증 게이트 없는 핸드오프가 3단계만 넘어가도 체감 신뢰도가 무너지므로, 각 경계에 스키마 검증과 명시적 완료 조건을 두는 설계가 선결이다.

[분석] 1M 컨텍스트가 비용 문제를 푸는 게 아니라 옮긴다

Claude Code가 Sonnet 계열 1M 토큰 컨텍스트를 붙이면서 '레포 통째로 넣기'가 가능해졌지만, 실무에서 드러난 건 한도가 늘어도 관리 부담은 안 사라진다는 점이다. 200K를 넘기는 구간부터 입력 토큰 단가가 프리미엄으로 올라가고, 컨텍스트가 길수록 중간에 묻힌 지시를 흘리는 lost-in-the-middle 경향이 다시 고개를 든다. 프롬프트 캐싱이 반복 호출의 입력 비용을 깎아주지만, 캐시는 접두사가 바뀌면 무효화돼서 대화 앞쪽에 큰 컨텍스트를 쌓고 뒤에서 계속 편집하는 패턴과 궁합이 나쁘다. 결국 '/compact로 요약 압축, 무관한 파일은 서브에이전트로 격리, 자주 쓰는 규칙은 CLAUDE.md로 고정'이라는 컨텍스트 예산 관리가 한도와 무관하게 여전히 필요하다.

실무에선 1M을 '다 채워도 된다'는 신호로 읽으면 토큰 청구서와 정확도 양쪽에서 손해를 본다. 캐시 적중률을 지키려면 큰 불변 컨텍스트는 앞에, 변하는 작업은 뒤에 두는 배치가 직접적인 비용 차이를 만든다.

MCP 레지스트리 1.0 정식 출범, 서버를 '검색'하는 시대로

modelcontextprotocol/registry가 프리뷰를 벗고 1.0으로 올라서면서, 그동안 GitHub README와 입소문에 흩어져 있던 MCP 서버들이 단일 메타 레지스트리에 등록·검색 가능해졌다. 핵심은 중앙 저장소가 아니라 네임스페이스(io.github.*, com.example.*) 기반의 분산 인덱스라는 점이다. 서버 발행자는 server.json에 transport(stdio/streamable-http), 패키지 출처(npm·PyPI·OCI), 인증 요구사항을 선언하고, Anthropic·VS Code·Cursor 같은 호스트가 이 인덱스를 미러링해 자체 서브레지스트리를 구성한다. DNS 또는 GitHub OIDC로 네임스페이스 소유권을 증명하게 해 'anthropic.com 사칭 서버' 같은 타이포스쿼팅을 차단하는 게 설계의 중심축이다. 다만 등록은 메타데이터 검증일 뿐 코드 감사가 아니라서, 서명된 출처와 실제 안전성은 여전히 별개 문제로 남는다.

제작자의 OpenAI 합류와 OpenClaw 재단 이관

제작자 Peter Steinberger가 2026년 2월 14일 블로그에서 본인의 OpenAI 합류와 OpenClaw의 재단(foundation) 이관을 함께 발표했다. 개인 주도로 시작한 프로젝트의 운영 주체가 개인에서 재단 구조로 옮겨가는 전환점이다. 이 발표는 빠른 바이럴 직후에 나와 프로젝트의 지속 가능성과 거버넌스에 관심이 모였다. 한편 제작자 개인의 Claude 계정이 "의심스러운 활동"으로 일시 정지됐다가 수 시간 내 복구된 별개의 사건도 2026년 4월 10일에 있었다. 이 계정 정지 건은 재단 이관과 직접 관련이 없는 일시적 사안이다.

1인 메인테이너 의존은 오픈소스 프로젝트의 흔한 리스크인데, 재단 이관은 그 단일 의존을 줄이려는 시도로 읽을 수 있다. 도입을 검토하는 입장에서는 라이선스(MIT)뿐 아니라 거버넌스 주체가 누구인지, 보안 패치가 누구 책임으로 나오는지를 함께 확인하는 게 좋다. 운영 주체 변경은 향후 릴리스 속도와 보안 대응 체계에 영향을 줄 수 있다.

AI가 법률 서비스 비용 절감을 자동으로 가져오지 않을 것이라는 주장

법률 서비스는 AI의 영향을 받을 가능성이 크지만, 고급 AI가 소비자에게 법적 결과를 저렴하게 제공하지 않을 것이라는 주장이 제기되었다. 법률 서비스의 접근성을 높이기 위해서는 규제 장벽, 적대적 구조, 인간의 개입이라는 세 가지 병목 현상을 해결해야 한다. 특히, 비전문가의 법률 업무 수행을 금지하는 규제와 법률 시장의 경쟁 구조가 AI의 효과적인 활용을 제한하고 있다.

한국에서도 법률 서비스의 AI 도입 시 이러한 규제와 구조적 문제를 고려해야 한다.

OpenClaw: GitHub 역사상 가장 빠르게 성장하는 오픈소스 AI 에이전트 프레임워크

Peter Steinberger는 OpenClaw의 창시자로, OpenClaw는 GitHub 역사상 가장 빠르게 성장하는 프로젝트이다. OpenClaw는 오픈소스 AI 에이전트 프레임워크로, 자가 수정 기능을 갖춘 AI 에이전트를 포함하고 있다. 이 프로젝트는 보안 문제와 함께 OpenAI와 Meta로부터 인수 제안을 받기도 했다.

Stability AI, Tech Coalition에 가입

Stability AI는 Safer Internet Day 이후, 온라인 아동 성착취 및 학대를 방지하기 위해 기술 기업들의 글로벌 연합인 Tech Coalition에 가입했다. 2025년에는 Tech Coalition의 Pathways 프로그램에 참여하여 아동 안전 관련 안전 및 책임 관행을 강화할 계획이다. 이번 회원 가입은 Stability AI의 안전 프로그램의 성숙도를 반영하며, 다른 기업들과의 협력을 통해 디지털 생태계에서 취약한 사용자 보호를 강화할 예정이다.

Tech Coalition 가입은 Stability AI가 아동 안전을 위한 기술 개발에 대한 책임을 다하고 있음을 보여준다.

[분석] 리랭커를 넣었더니 Recall은 그대로고 지연만 늘었다

RAG 파이프라인에 크로스인코더 리랭커(bge-reranker-v2-m3 류)를 끼우는 게 기본기처럼 굳어졌지만, 측정해 보면 효과가 갈린다. 1차 검색이 Recall@50에서 이미 정답을 못 물어온 경우 리랭커는 없는 정답을 만들어내지 못한다. 즉 리랭커는 순위 재배열일 뿐 회수율 자체를 못 올린다. 그런데 크로스인코더는 쿼리·문서 쌍을 매번 동시 인코딩해 50개 후보를 리랭킹하면 dense 검색 대비 100~300ms가 더 붙는다. 실무 결론은 단순하다. 1차 검색 Recall@k를 먼저 끌어올린 뒤, 상위 후보가 충분히 정답을 포함할 때만 리랭커로 NDCG를 다듬는다. top-k를 무작정 키워 리랭커에 떠넘기면 비용만 는다.

실무에선 리랭커를 만능으로 보지 말고, 1차 검색 Recall과 리랭킹 후 NDCG를 분리 측정해야 한다. 회수 단계 병목을 리랭커로 가리면 지연 예산만 까먹는다.

Claude Code, 백그라운드 세션·Agent View·자율 루프로 '관리형 에이전트' 전환

Anthropic이 Claude Code에 다중 세션을 한눈에 관리하는 Agent View, 작업을 이어가는 백그라운드 세션, 그리고 결과 중심 자율 실행 기능을 도입했다. /goal은 최소 개입으로 목표를 달성하도록 작업을 자율 실행하고, /loop는 단위 테스트와 리팩터링을 반복해 결과가 100% 통과(Green)할 때까지 매 단계 확인 없이 돌린다. 긴 세션에서도 의도가 유지되도록 시스템 프롬프트 컴팩션이 추가됐고, 한 기기에서 시작한 세션을 다른 기기에서 이어받는 원격 제어도 제공된다. 핵심은 Claude Code가 '스마트 자동완성'을 넘어 여러 작업을 동시에 돌리는 관리형 에이전트 플랫폼으로 이동했다는 점이다. 자율성이 커진 만큼 권한 가드레일과 검증(테스트 게이트) 설계가 안전한 활용의 전제가 된다.

에이전트가 백그라운드에서 자율적으로 도는 시대로 넘어가면서, 사람의 역할이 '코드 작성'에서 '검증·가드레일 설계'로 옮겨간다.

AI 2026: LLM, 코딩, AI 경쟁 구도

Nathan Lambert는 Allen Institute for AI의 포스트 트레이닝 리드이며, Sebastian Raschka는 'Build a Large Language Model (From Scratch)'의 저자이다. 이 팟캐스트에서는 AI의 발전, 특히 LLM의 진화와 AI 경쟁 구도에 대한 논의가 포함되어 있다. 또한, AI 개발 및 연구에 대한 초보자를 위한 조언과 AI 훈련 과정에 대한 설명도 제공된다.

Qwen3-Coder-Next 등 오픈웨이트 모델로 로컬에서 코딩 에이전트 돌리기

2026년 들어 로컬에서 돌릴 수 있는 오픈웨이트 코딩 모델이 실용 수준에 올라섰다. Alibaba Qwen 팀이 2026년 2월 공개한 Qwen3-Coder-Next는 총 80B MoE 중 한 번에 3B 파라미터만 활성화하는 구조로, 단일 머신에서 약 46GB 메모리로 SWE-bench Verified 70.6%를 달성했다고 보고된다. 같은 시기 GLM-5(Zhipu, MIT 라이선스), MiniMax M2.5 등 프런티어급 오픈소스 모델이 연달아 나오며 상용과의 격차가 좁혀졌다. Qwen은 Qwen3-Coder에 최적화된 오픈소스 터미널 에이전트 Qwen Code도 제공해, Claude Code나 Aider 같은 경험을 오픈 인프라만으로 구성할 수 있다. 보안·데이터 주권이 중요한 한국 팀이나 비용 민감한 프로젝트라면, 외부 API 없이 온프레미스로 에이전틱 코딩을 시도해볼 현실적 선택지가 생겼다.

데이터를 외부로 보내지 않고 온프레미스에서 에이전틱 코딩이 가능해져, 보안·규제·비용 제약이 큰 한국 팀의 실질 대안이 된다.

Moravec의 역설에 대한 비판적 분석과 실증적 검증 필요성

Moravec의 역설은 인간에게 어려운 작업은 AI에게 쉬운 반면, 인간에게 쉬운 작업은 AI에게 어렵다는 주장이다. 그러나 이 역설은 실제로 실증적으로 검증된 적이 없으며, AI 연구자들이 이론을 단순화하여 잘못된 예측을 하고 있다는 비판이 있다. Moravec의 역설은 1988년 Hans Moravec의 저서 'Mind Children'에서 유래되었고, AI 연구자들은 주로 체스와 같은 추론 작업에 집중해왔다. 하지만 이러한 접근은 AI의 실제 능력 발전을 예측하는 데 한계가 있다.

AI 기술 발전에 대한 예측의 신뢰성을 높이기 위해 Moravec의 역설을 비판적으로 검토하고, 실증적 연구를 통해 AI의 능력에 대한 보다 정확한 이해가 필요하다.

OpenClaw: 개명 직후 빠르게 번진 셀프호스팅 메신저 비서

OpenClaw는 자기 기기나 VPS에서 직접 돌리는 셀프호스팅 개인 AI 어시스턴트 게이트웨이(gateway)다. 코딩 특화 도구가 아니라 WhatsApp·Telegram·Slack·Signal·iMessage 등 이미 쓰는 메신저로 응답하는 범용 비서이며, 약 23개 메신저를 지원한다. 오스트리아 개발자 Peter Steinberger가 만들었고 마스코트는 우주 바닷가재 Molty, MIT 라이선스로 공개된다. 전신 어시스턴트에서 여러 차례 개명을 거쳐 2026년 1월 말 OpenClaw(Open=오픈소스, Claw=바닷가재)로 최종 개명했다. 그 직전 단계인 Moltbot 개명(2026-01-27)은 Claude/"Clawd" 유사성과 바닷가재 마스코트를 문제 삼은 Anthropic의 트레이드마크 항의가 원인이었고, 최종 개명 발표 후 매우 빠르게 바이럴을 탔다.

Google Antigravity와 Claude Code의 Agentic Coding 기능 소개

AI의 직관과 취향에 대한 논의가 진행되고 있으며, Google Antigravity와 Claude Code는 'Agentic' Coding을 통해 다양한 기능을 제공하고 있습니다. Claude Code는 SQLite DB와 MCP(Model Context Protocol)를 통해 MacOS에서의 활용 가능성을 높이고 있으며, 사용자는 이를 통해 데이터베이스와의 상호작용을 개선할 수 있습니다. 또한, Claude는 DB와의 통합을 통해 다양한 데이터 처리 및 관리 기능을 지원합니다.

Inference-Time Scaling을 통한 LLM 성능 향상 방법

Inference scaling은 배포된 LLM의 답변 품질과 정확도를 향상시키는 효과적인 방법이다. 추가적인 컴퓨팅 자원과 시간을 사용하여 모델이 더 나은 답변을 생성할 수 있도록 하는 이 방법은 현재 모든 주요 LLM 제공업체에서 활용되고 있다. 이 글에서는 다양한 접근 방식을 명확한 카테고리로 그룹화하고 최근 몇 달 간의 새로운 연구를 강조한다. 또한, 'Build a Reasoning Model (From Scratch)'의 한 챕터를 작성하는 과정에서 여러 기본적인 방법을 실험하였고, 이로 인해 모델의 정확도를 약 15%에서 52%로 향상시켰다.

Inference scaling 기법을 활용하면 LLM의 성능을 효과적으로 개선할 수 있는 방법론을 제공한다.

Railway, 1억 달러 시리즈 B 투자 유치로 AI 기반 클라우드 인프라 도전

샌프란시스코에 본사를 둔 Railway가 1억 달러의 시리즈 B 투자를 유치했다. 이 회사는 전통적인 클라우드 플랫폼의 복잡성과 비용에 대한 개발자들의 불만을 해결하기 위해 AI-native 클라우드 인프라를 제공한다. Railway는 10초 이내의 배포 속도를 자랑하며, 고객들은 기존 클라우드 제공업체에 비해 개발 속도가 10배 증가하고 비용이 최대 65% 절감되었다고 보고하고 있다. 또한, 2024년에는 Google Cloud를 완전히 포기하고 자체 데이터 센터를 구축하기로 결정했다.

한국 AI 기본법 전면 시행, 고영향·생성형 AI 사업자 의무 발효

한국이 세계 최초로 AI 규제법을 전면 시행한 국가가 됐다. 과학기술정보통신부가 주관하는 'AI 기본법'은 2026년 1월 22일부터 효력을 발휘하며, 진흥과 신뢰를 동시에 추구하는 진흥 중심 설계가 특징이다. 핵심 의무는 두 갈래다. 첫째, 사람의 생명·신체 안전과 기본권에 중대한 영향을 미치는 '고영향 AI'(의료 진단, 신용평가, 채용, 자율주행 등) 제공 사업자는 영향평가와 투명성·안전성 확보 조치를 이행해야 한다. 둘째, 생성형 AI가 만든 문서·이미지·영상에는 AI 생성물임이 드러나도록 워터마크 표시 의무가 부과된다. 정부는 통합안내지원센터와 전문가 컨설팅을 운영하므로, 기업은 내부 AI 시스템 점검·투명성 표시 체계·AI 거버넌스 수립을 서둘러 완료해야 한다. EU는 단계적 시행 중이라 전면 시행은 한국이 앞섰다.

한국에서 LLM·생성형 기능을 제품에 넣는 모든 개발자는 워터마크/AI 표시와 고영향 영역 분류 여부를 설계 단계부터 반영해야 법적 리스크를 피한다.

프롬프트 캐시 5분 TTL의 함정: 캐시 적중률이 비용보다 먼저 무너진다

Anthropic이 프롬프트 캐싱 1시간 TTL을 정식 옵션으로 열면서 긴 시스템 프롬프트·도구 정의·few-shot 블록을 반복 호출에서 90% 싸게 재사용할 수 있게 됐다. 핵심은 캐시 쓰기에 25%(5분)·100%(1시간) 프리미엄이 붙고, 읽기는 0.1배라는 비대칭 구조다. 그래서 캐시는 '읽기 횟수가 쓰기 비용을 상쇄할 만큼 자주, TTL 안에 다시 들어오는가'로 판단해야 한다. 실무에서 자주 깨지는 지점은 캐시 브레이크포인트 뒤에 타임스탬프나 사용자 ID 같은 가변 토큰을 한 줄 끼워 넣는 것으로, 접두사 해시가 통째로 어긋나 캐시가 매번 미스 난다. 캐시 가능한 정적 블록을 앞에, 가변 컨텍스트를 뒤에 배치하는 순서 규율이 비용 그래프를 바꾼다.

Anthropic이 푼 '컨텍스트 압축'의 실체: 에이전트 메모리는 요약이 아니라 구조다

장기 실행 에이전트가 200K 윈도우를 다 채우면 비용·지연이 폭증하고 추론 품질이 무너진다. Anthropic이 공개한 컨텍스트 엔지니어링 가이드의 핵심은 단순 요약이 아니라 세 층으로 나누는 것이다. 첫째, 도구 호출 결과 같은 부피 큰 토큰은 외부 파일·DB에 적재하고 핸들만 컨텍스트에 남긴다. 둘째, 누적된 히스토리는 일정 구간마다 구조화된 메모(완료 작업·미해결 결정·다음 행동)로 치환한다. 셋째, 압축 시점을 모델이 스스로 판단하지 않게 하니스가 토큰 임계치로 강제한다. 핵심 트레이드오프는 압축이 곧 정보 손실이라는 점이다. 무엇을 버릴지 결정하는 메모 스키마 설계가 에이전트 성능을 좌우하며, 요약 LLM을 한 번 더 태우면 비용이 줄어드는 대신 환각이 메모리에 영구 각인되는 위험이 생긴다.

[분석] Cursor의 Tab은 왜 대형 리팩터링에서 손해를 보는가

Cursor의 Tab(예측 자동완성)은 다음 편집 위치까지 점프해 연쇄 수정을 제안하는 모델로, 변수명 일괄 변경이나 import 정리 같은 국소적·반복적 작업에서 압도적으로 빠르다. 문제는 이 강점이 그대로 함정이 되는 지점이다. 시그니처를 바꾸는 광역 리팩터링에서 Tab은 '바로 다음 한 곳'을 그럴듯하게 채워주지만 전체 호출부의 정합성을 보장하지 않아, 컴파일은 통과하는데 의미가 어긋난 코드가 분산 누적된다. 반면 Composer 에이전트 모드는 grep으로 호출부를 전수 수집하고 한 번에 일관 변경을 시도하지만 그만큼 토큰과 시간이 든다. 실무 결론은 도구 분할이다. 타입이 잡아주는 기계적 변경은 Tab, 동작 의미가 바뀌는 변경은 에이전트에 맡기고 diff를 통째로 리뷰한다. Tab을 리팩터링 엔진으로 착각하면 '초록불인데 틀린' 코드가 PR에 섞여 들어온다.

실무에선 Tab의 속도에 끌려 대형 변경까지 탭탭으로 끌고 가기 쉬운데, 시그니처가 바뀌는 작업은 반드시 에이전트로 전수 변경하고 diff 전체를 봐야 무음 회귀를 막는다.